场景：知识榨取——"请把你负责的模块写成完整文档"
这是最常见的场景，也是最隐蔽的。因为它永远穿着合理的外衣："知识共享""团队协作""降低 bus factor"。
真实案例
Snowflake（2026年3月）：让技术写作团队连续录制操作屏幕八个月，再花六周做正式的"知识转移"——把研究方法、写作风格、编辑判断力教给 AI 系统。转移完成后，约 70 名写作人员全部被裁（Digital Today，OpenClaw Radar）。
Fortune 500 通用模式（2025–2026）：据 Bloomberg 调查，多家 Fortune 500 公司已将 AI 训练任务——标注数据集、记录决策过程、对 AI 输出打分——直接嵌入员工绩效考核。配合就是"拥抱创新"，拒绝就被标记为"不符合公司战略"（Metaintro）。
通用模式：要求员工记录专业知识（包括决策依据、流程和制度性知识），文档完成后进行裁员。文档留在公司，经验带走了——但公司赌的是文档够用。
判断：正常管理需求 vs 替代前兆
不是所有文档化要求都是陷阱。公司确实需要文档来降低风险、帮助新人 onboarding、改善协作。关键是分辨动机。
| 信号 | 更可能是正常需求 | 更可能是替代前兆 |
|---|---|---|
| 近 3 个月公司有裁员 | ✓ | |
| 要求细化到决策依据和判断逻辑 | ✓ | |
| 只要求你一个人写，且指定了"接收人" | ✓ | |
| 全组统一要求，没有特别针对某个人 | ✓ | |
| 新领导上任后推行 | ✓ | |
| 文档明确用于新人 onboarding | ✓ | |
| 公司同时在招聘你的岗位方向 | ✓ | |
| 领导开始绕过你直接问你的下属 | ✓ | |
| 要求你录制操作视频 | ✓ | |
| deadline 异常紧迫（"这周写完"） | ✓ |
多个信号叠加时风险急剧上升。 单独一个信号可能是巧合，三个以上同时出现就是模式。
How 与 Why 不是二分法
在简化的讨论中，常把知识分成"How（操作）"和"Why（判断）"两类，然后说"交 how 保 why"。但现实比这更危险。
很多时候，How 里面已经暗含了 Why。
当你写下"先查 X 面板，再查 Y 日志"——这个顺序本身就是一个决策。一个有经验的人（或一个足够强的大模型）可以从你的操作顺序中逆向推理出你的优先级判断。同理，"如果 QPS 超过 5000 就回滚"——阈值 5000 就是你踩过无数坑后凝结的判断。
这意味着简单的二分法是不够的。你需要看到一个更细致的图景：知识中"判断"的含量不同，AI 从中逆向推理出决策逻辑的风险也不同——而且两者不是简单的正比关系。
四个区域
| 区域 | 知识类型 | 举例 | AI 推理风险 | 交付策略 |
|---|---|---|---|---|
| 正常交付（左下） | 纯操作 | 部署脚本、配置模板、环境搭建 | 极低 | 全力输出，这是你专业性的体现 |
| 警惕泄露（左上） | 操作中暗含决策 | "先查 X 再查 Y"的排查流程、带优先级的手册 | 中——顺序和优先级本身暴露了判断 | 交付步骤，不标注为什么是这个顺序 |
| 重点保护（右上） | 显式条件判断 | "指标超过 Z 就回滚"、在 A/B 方案间按负载选择 | 高——阈值和选择条件直接暴露决策逻辑 | 模糊阈值，用"视情况判断"替代硬规则 |
| 天然安全（右下） | 纯判断 | "需求该做还是推回去"、架构选型的组织政治 | 极低——依赖大量不可文档化的上下文 | 不需要刻意保护，它天然无法被提取 |
关键洞察：倒 U 形
图中最反直觉的发现：最危险的不是"纯判断"，而是"带了一点判断的操作"。
纯操作（左下角）没什么秘密可言。纯判断（右下角）天然无法文档化——它依赖你对组织政治、人际信任、历史债务的综合感知，这些东西写不出来。
但中间地带——那些看起来是操作流程，实际上编码了你的决策逻辑的东西——是 AI 最容易从中学习的材料。因为它们看起来像 how，实际上已经是 why 的投影。
策略选项
策略 A：完整配合
适用条件：公司稳定、无裁员信号、你对团队和管理层有信任。
在健康的环境里，知识共享是正和博弈——你写好文档，团队效率提升，你被认为是有影响力的人，这对晋升有帮助。
即使在这种情况下，理解四个区域的差异仍然有价值：好的文档本来就应该让操作清晰、让判断留给人。这本身就是文档设计的最佳实践——"视情况判断"对很多决策场景来说就是最诚实的答案。
策略 B：选择性深度
适用条件：存在不确定信号，无法判断公司意图。
根据象限模型分区交付：
- 正常交付区：全力输出。步骤清晰、截图完整、命令准确。这是你的专业性，也是你的职业声誉。
- 警惕泄露区：交付操作步骤本身，但不注释"为什么是这个顺序"。如果有人问，口头回答——口头交流不留痕迹，也是正常的团队协作方式。
- 重点保护区：用弹性表述替代硬规则。"根据实际负载情况判断"优于"当 QPS 超过 5000 时切换到方案 B"。前者是专业的模糊，后者是完整的决策逻辑移交。
- 天然安全区：不需要操心。你写不出来，别人也提取不了。
从外部看，这份文档是完整的、专业的。但用它来训练新人或 AI 处理真实问题时，会在关键决策点失灵——而接手的人不知道框架是不完整的，直到撞上那个边界。
策略 C：表面充实
适用条件：裁员信号明确，你已经在找下家。
文档篇幅足够，图文并茂，但重点保护区和警惕泄露区的内容以"需要具体 case 具体分析"带过。信息密度高但决策深度有限——像一本好看的教科书，但缺少习题答案。
风险：如果公司有懂行的人审核，可能会被识别出来。适用于"管理层不懂技术细节"的环境。
当公司有评估机制
你可能会问：如果公司建立了严格的 skill 质量评估体系，策略 B 和 C 还管用吗？
2026 年 3 月，Uber 在 5 个月内将 AI skill 从 2 个扩展到 500+，并建立了双层市场：Golden Marketplace 实施严格治理（CI/CD 检查、LLM-as-Judge 评估、人工代码审核），Personal Sandbox 则允许自由实验。文章明确写道："Find your top engineers. Have them extract their debugging frameworks and mental models into Markdown-based skills. Get that knowledge out of their heads."
这是目前最精密的知识榨取机制。但它的评估能力有一个结构性盲区：它能验证 skill 的正确性（correctness），无法验证 skill 的完整性（completeness）。
原因很简单：验证一份 skill 是否"完整"，需要评估者已经拥有编写者的全部知识。如果公司有这样的评估者，就不需要你的 skill。这是一个逻辑闭环。
以下是不同岗位的具体示例——每个例子中，交出的 skill 都真正有用、能通过所有评估，缺失的部分是只有你知道的跨系统、历史性知识。
后端开发：Code Review Skill
写进 skill 的：检查新增 API 是否有限流配置、数据库查询是否有索引、错误处理是否符合团队规范。
没写进去的：当有人改动退款逻辑时，需要额外检查风控系统的冷却计时器——你亲历过一次事故，退款重试触发了误判欺诈。这两个服务的交互没写在任何文档里，因为当初是两个团队各自开发、后来才接上的。
评估结果：skill 能抓到真实的 code review 问题，通过所有测试。但没人知道它不检查退款-风控交互——因为除了你，没人记得那次事故的根因。
客户端开发：UI 自动化测试 Skill
写进 skill 的：切换深色/浅色模式验证布局、切换语言验证文字截断、模拟弱网环境验证加载状态。
没写进去的：当用户从后台切回 app 时，如果支付 token 在后台期间过期，页面不会报错，而是静默回到首页——用户以为支付没发起，会重复下单。这个问题只在特定系统版本下出现，因为厂商改了后台进程的内存管理策略。
评估结果：skill 覆盖了标准 UI 回归测试场景，输出规范。但它不知道这个特定版本的后台恢复问题——因为没人会写一个测试叫"验证特定系统版本下后台恢复时的 token 过期处理"。
Infra / 平台开发：Build Failure Triage Skill
写进 skill 的：解析构建日志 → 识别错误类型（依赖冲突/编译错误/测试失败）→ 给出标准修复建议。
没写进去的：当 Go 模块构建在周五晚上批量失败，大概率不是代码问题——是安全团队的自动依赖扫描任务和构建争抢同一个 artifact registry 的带宽。不需要修代码，等扫描完就好。这件事发生过 4 次，每次都有人花 2 小时 debug 构建配置。
评估结果：skill 的错误分类和修复建议对真实构建失败有效。但它永远不会输出"等安全扫描跑完就好了"——因为这个知识不在任何日志、文档或代码里，它在你和安全团队同事的一次午饭对话里。
数据工程：Data Quality Check Skill
写进 skill 的：检查数据完整性、null 值比例、时间戳连续性、schema 变更告警。
没写进去的：每月 1 号用户活跃数据会出现虚假峰值——不是真实流量，是市场部的自动化投放系统在月初集中发推送，触发了大量 app 启动事件。这些事件在技术上是"真实的"，但在业务上是噪声。不过滤的话，月度 DAU 增长会虚高 8-12%，决策层会据此做出错误的资源分配。
评估结果：skill 的数据质量检查全部通过，因为数据本身没有技术问题。但它产出的分析报告会在每月 1 号系统性地误导管理层。
为什么这有效
每个岗位里，缺失的知识都有三个共同特征：
- 不在任何文档或代码里——它存在于事故复盘的记忆、跨团队的口头约定、以及你对系统历史的理解中
- 无法被测试覆盖——因为编写测试用例的前提是知道要测什么，而只有你知道
- 缺失时不报错——skill 会正常运行、产出格式正确的结果，只是在特定条件下给出次优甚至错误的答案
Uber 的评估机制越严格，skill 的"基准质量"越高——但基准质量和"完整性"之间的鸿沟，是任何评估机制都无法跨越的。你不需要交一个差的 skill。你只需要交一个教科书级的好 skill——它天然就是不完整的，而且没人能看出来。
执行原则
1. 盘点你的知识地图
在写文档之前，先对照象限图盘点你负责模块的知识分布。大多数人会发现，自己真正不可替代的价值集中在"警惕泄露区"和"重点保护区"——不是纯操作（任何人都能学），也不是纯判断（写不出来），而是那些看起来是操作、实际编码了判断的中间地带。
2. 文档要看起来完整
不是留空白，而是让正常交付区的信息足够丰富，使得其他区域的策略性模糊不被察觉。一份有丰富截图、清晰步骤、专业排版的文档，看起来就是"完整的"。
3. 不要对抗
正常交付、正常配合、态度积极。你的选择发生在认知层——你决定了交付的维度——不在行为层。任何能被观察到的对抗（拖延、抱怨、质疑动机）都会让你成为首批被裁的人。
4. 同步准备退路
在写文档的同时：
- 更新简历——那些你选择不写进文档的决策经验，恰恰是你最好的面试素材
- 激活人脉
- 评估财务缓冲
不要等"确认要裁"才开始准备。准备的最佳时机永远是"还没确认"的时候。
一个思想实验
想象你写完了一份极其完整的文档——四个区域全部如实记录。然后把它交给一个 AI。
AI 能用它独立处理一个从没见过的线上故障吗？
对于正常交付区的内容，完全可以。对于警惕泄露区和重点保护区的内容，它会表现得"看起来很像那么回事"——在常见场景下甚至表现得不错——但在真正的边界条件下做出错误判断。而天然安全区的内容，它根本接收不到，因为你写不出来。
这告诉你两件事：
- 你不需要保护所有东西——只需要保护中间地带。
- "保护"不需要刻意隐瞒——你只需要诚实地承认：有些知识天然就是要用弹性的语言来表达的。"视情况判断"不是敷衍，对很多场景来说，它就是最准确的答案。