问题：人走了，项目就出问题
传统工程有一个结构性缺陷，大多数团队已经习以为常了：
核心成员离职，项目就进入危险期。
代码留下来了，文档可能也有。但真正让项目能持续演进的东西——这个设计为什么这样做、那个坑是怎么踩出来的、下一步应该往哪走——全部在人脑里，随着人的离开一起带走。
这不是管理问题，是知识存储位置的问题。
根源：知识住在哪里
传统工程的知识结构：
判断力、经验、决策依据 → 在人脑里 → 项目依赖人
所以人员流动直接等于能力流失。新人接手，只能靠老人口口相传，或者自己重新踩一遍坑。
AI 工程做对了之后，知识结构变了：
判断力、经验、决策依据 → 在系统里（提示、流程、Agent 规范、上下文）→ 项目依赖系统
人换了，系统还在。新人接手的不是一个需要靠老人解释才能运作的项目，而是一个可以被读懂、被修改、被延续的系统。
这是 AI 工程最大的价值——不是效率，是组织的知识不再随人员流动而流失。
两个层次，难度不同
“人员流动不影响项目”，听起来是一个目标，实际上是两件难度不同的事：
| 目标 | 需要什么 |
|---|---|
| 能稳定运行 | 流程文档、操作手册、Agent 规范 |
| 能正确演进 | 决策记录、判断依据、失败模式 |
前者容易实现，后者才是真正的挑战。
一个新人可以照着文档跑起来项目，但如果他不知道”这条规则是在什么情况下加进来的”、”Agent 为什么这样设计而不是那样”，他遇到新情况时，要么不敢改，要么改错方向。
能运行，但不能演进——这是”形式上交接成功、实质上能力已断层”。
所以完整的目标不是让项目能跑，而是：
让判断力可以被传递，而不只是让操作步骤可以被复制。
Agent 可修改性是核心测试
Agent 的可修改性，是整个体系能不能真正对抗人员流动的关键测试。
如果一个 Agent 只有创建它的人才敢改，说明知识还在人脑里，只是换了一种形式包装。表面上系统化了，实质上还是人依赖。
真正做对的 Agent 应该具备：
- 输入输出契约：它接收什么、产出什么、边界在哪里，有明确定义
- 判断边界：它能处理什么情况、哪些情况必须升级给人，有记录
- 修改历史：改过什么、为什么改、改之前是什么，可追溯
满足这三条，任何人都可以接手修改，不依赖原作者在场解释。这才是 Agent 化真正的意义——不是自动化，是让能力从个人转移到系统。
判断体系是否真的建立
一个检验标准：新人独立上手需要多久，不依赖老人带？
- 需要老人陪跑一个月以上——知识还在人身上
- 两周内能独立判断常见情况——体系初步建立
- 一周内能开始贡献修改——体系成熟
这个指标不需要专门测，日常感受就能判断：新人总是问同样的问题，说明答案还没有落入系统；新人能自己找到决策依据，说明积累有效。
本质
传统工程让项目依赖人，AI 工程让人依赖系统。
最大的价值不是提升个人效率，而是把效率的来源从”找到对的人”变成”建好对的系统”——这才是组织层面真正可持续的能力。