为什么要做这套 SOP
最近一段时间，我在持续用 AI 做软件开发。用得越多，越明显地感受到一个问题：AI 很会写代码，但 AI 开发并不会天然变成一个可靠的软件工程过程。
如果没有清晰的工作方式，AI 很容易出现几类问题：目标漂移、需求散落、设计没有基线、测试滞后、多 AI 互相覆盖、人或另一个 AI 接手困难。
代码是 AI 的产出，文档是 AI 不跑偏的轨道。
这套 SOP 的核心不是让文档变多，而是让 AI 开发过程中的目标、需求、设计、实现、测试、发布和交接可以被追踪、验证和复盘。
AI 开发真正需要治理的链路
目标 -> PRD -> 需求 -> 原型 -> 设计 -> 工作包 -> 代码 -> 测试 -> 发布 -> 运维 -> 复盘每个节点都要有文档，每个文档都要有状态，每个变更都要有依据，每个偏差都要被记录。这样 AI 才不是在聊天上下文里“凭感觉继续”，而是在一个可复用的工程系统里推进。
项目结构
仓库目前包含中文和英文两个版本，以及一一对应的双语模板。
- 中文版：
zh/ - 英文版：
en/ - 中文模板：
templates/zh/ - 英文模板：
templates/en/
治理层级如下：
Portfolio 项目组合
└── Program 项目集
└── Project 项目
└── Phase 阶段
└── Work Package 工作包
└── AI Session 会话
└── Artifact 代码、测试、文档产物不是所有项目都要执行同样重的流程
这套 SOP 的原则是：母版要完整，项目执行要裁剪。小工具不应该被流程拖死，中大型项目也不应该靠聊天记录治理。
| 等级 | 适用场景 | 说明 |
|---|---|---|
| Light | 原型、小工具、个人实验 | 文档轻量，但保留目标、验证、进度和交接 |
| Standard | 正式个人项目、中型应用 | 完整项目层文档，适合长期维护 |
| Strict | 多 AI、多模块、生产系统 | 全生命周期文档、质量门禁、追踪矩阵 |
| Portfolio | 多项目、多产品线 | 增加项目组合和项目集治理 |
最关键的几类文档
PRD.md 定义产品目标、用户、场景、范围、非目标和成功指标。没有 PRD，AI 很容易热心补功能。
SRS.md 和 ACCEPTANCE_CRITERIA.md 把产品意图变成可开发、可测试、可验收的需求。
SYSTEM_DESIGN.md 和 TECHNICAL_DESIGN.md 让 AI 不必每一轮都重新猜系统结构。
TEST_CASES.md 和 TEST_REPORT.md 提供硬证据，避免代码只是“看起来完成”。
AI_WORK_PACKAGES.md 是多 AI 协作的关键，它规定目标、范围、输入、输出、允许文件、禁止变更、验收方式和交接说明。
PROGRESS_LOG.md 和 DEVIATION_LOG.md 记录开发进度、目标偏差、范围偏差、架构偏差、测试偏差和文档偏差。
原型图也应该进入正式流程
如果项目有 UI 或复杂交互，原型图不能只是临时参考。它应该成为正式基线的一部分。AI 做前端时，如果没有原型或交互说明，很容易根据自己的审美自由发挥。
所以 SOP 中保留了 UX_FLOW.md、PAGE_LIST.md、WIREFRAME_INDEX.md、INTERACTION_SPEC.md、UI_ACCEPTANCE_CRITERIA.md、PROTOTYPE_REVIEW_REPORT.md 等文档。
适合谁使用
这套 SOP 适合长期使用 AI 写代码的人，正在尝试多 AI 协作的人，想把 AI 用于中大型项目的人，以及希望把个人 AI 开发经验沉淀成团队方法的人。
我的判断
AI 会改变软件开发，但不会消灭软件工程。相反，当代码生产速度变快之后，目标管理、需求管理、架构治理、测试验证、配置管理、变更控制和质量门禁会变得更重要。
因为代码生产速度越快，偏离目标的速度也越快。
AI Coding SOP 想做的，就是给这种更快的软件生产方式补上一套治理框架。它不是完美答案，也不是必须机械执行的流程。它更像一个母版：可以完整，也可以裁剪，但不能丢掉目标、验证、追踪和交接。