配套案例与练习扩展
本页为《AI Native Builder：把 AI 变成组织能力》补充一组内部实践材料。主案例已经删除可识别信息，并对人物、时间和事件顺序作了教学重构；它不改变第 0—11 章的主学习路径，也不替代贯穿全书的“澄川工业”案例。
澄川案例负责完整展示标准方法；实践案例负责展示需求怎样混合业务、产品和工程问题，以及团队如何通过分流、状态、质量检查和人工责任修正路径。
建议阅读顺序
- 先读 实践案例｜从多维表需求到 MR 与上线，理解完整案例。
- 阅读第 5—10 章时，对照 实践旁注｜Skill 仓库交付闭环。
- 在真实项目中使用 练习册扩展｜需求分流与自动交付 保存可复核证据。
与正文的对应关系
| 阶段 | 正文章节 | 实践案例补充 |
|---|---|---|
| 发现 | 第 5 章 | 区分局部字段需求与 Skill Package 这类新业务概念 |
| 重构 | 第 6 章 | 保留多维表入口，把 Agent 放到后台执行面 |
| 业务约束 | 第 6A 章 | 把触发、分流、人审、禁止动作和异常恢复写成业务约束版 |
| 构建 | 第 7 章 | 需求对象、状态机、MR 工具、checkpoint 和恢复 |
| 评估与治理 | 第 8 章 | 分别检查需求、代码、测试和业务结果 |
| 采用 | 第 9 章 | 持续运行仍需记录分流、人工介入和净负担 |
| 复用 | 第 10 章 | 从单一维护者转向 Owner、版本、回归和第二维护者复用 |
案例用于展示什么
- 业务人员怎样继续在协作多维表提交反馈；
- 边界明确的小需求怎样进入分析、代码修改、MR、审核、测试和部署；
- 复杂需求为什么会因对象、关系、权限或验收未定义而失败；
- 团队怎样使用“快车道 / 探索车道”进行分流；
- 哪些运行数据、失败事件和人工介入需要在实际项目中另外记录。
当前不能证明什么
- 不能声称已经实现全自动研发；
- 不能声称对所有 Skill 和产品需求有效；
- 不能用少量成功需求推导生产级成功率；
- 尚未用完整数据证明总体 ROI；
- 尚未完成第二团队低依赖复用，因此不能声称已经形成组织复用证据。
如果读者把这套方法用于实际项目，应另外保存授权范围、运行数据、失败事件、维护者人工介入时间，以及第二维护者或第二团队复用记录。