团队自然语言开发：优化后的流程
本文只讲流程——从一句需求到可复用的成果，中间经过哪几道闸口、每道闸口放行什么。不涉及任何具体项目、具体单位与具体实施细节。
这一篇只讲流程
把一句自然语言需求，变成团队能长期复用的成果，中间不需要一份没人看得懂的规格书，也不需要每个岗位重新讲一遍背景。前提是流程本身是通的。
本文只写这套优化后的流程：有哪些阶段、每阶段的输入与输出、每道闸口的放行条件。不写案例、不写进度、不写报价、不写具体处理动作。流程是通用的，谁来用、用什么工具用，都不影响它成立。
优化前，流程断在哪
| 断点 | 后果 |
|---|---|
| 需求在传递中变形 | 同一句话，不同角色听出不同的事，来回确认占用了大部分时间 |
| 规矩不继承 | 每个任务都从零交代背景与口径，做过的约定留不下来 |
| 成果不回流 | 这一轮做完就结束，下一轮仍从头开始，经验不沉淀 |
三处断点有一共同点：都不是执行能力的问题，是上下文没有被组织起来。优化针对的正是这一层，而不是把每一步做得更快。
优化后的主流程：六道闸口
流程压成六个阶段。每阶段只做四件事：接收输入、执行动作、交出输出、通过放行条件。放行条件比动作更重要——上一道没放行，不进下一道。
| 阶段 | 输入 | 动作 | 输出 | 放行条件 |
|---|---|---|---|---|
| 一 · 定边界 | 一句自然语言需求 | 补齐四项：谁用、卡在哪、要什么、怎样算完成 | 范围卡 | 四项齐全，且没有两种理解 |
| 二 · 装上下文 | 范围卡 | 把统一规则与已有资料归入项目空间，先划权限再放内容 | 可继承的项目配置 | 权限先行，配置可被后续任务自动继承 |
| 三 · 出方案 | 项目配置 | 拆成可执行步骤，列出交付项与验收点 | 执行清单 | 关键取舍经人确认 |
| 四 · 执行自检 | 执行清单 | 按步骤生成、整理、逐项自检 | 可点开的成果 | 自检通过，且不越出授权范围 |
| 五 · 验收 | 成果 | 按清单逐条点开、记录不通过项 | 验收结论 | 四条标准全过（见下） |
| 六 · 沉淀复用 | 验收结论 | 结果回灌资料库、指定维护人、设定巡检 | 下一轮的起点 | 有主、有版本、能追溯 |
第六阶段不是收尾，是下一轮的入口。少了它，前五阶段每轮都要重来一遍。
两条贯穿全程的规矩
判断留在人手上。 定范围、定验收、以及最后那一眼「这样做行不行」，始终由人完成。重复劳动可以交出去，判断不行。
权限先于动作。 先划清谁能看什么，再谈能做什么；人看不到的内容，机器同样读不到；任何改动都要经接受才生效。顺序反了，后面补不回来。
什么时候走这条流程，什么时候退出
三条同时成立才进入：规则固定、材料现成、动作重复。
出现下列任一情况即退出本流程，回到常规工程流程：需要现场判断、需要当面协调、需要签字担责、涉及核心系统改造。退出不是失败，是流程自带的边界。
验收口径
四句话，每轮都要过：
- 可点开：交出的是能直接使用的入口，不是一段说明文字。
- 可复现：同样的输入再走一遍，结果一致。
- 可交接：换个人照着留下的东西能接得住。
- 可回滚：改坏了能退回上一版。
四条里任何一条没过，回到第五阶段，不带病进入沉淀。
流程本身也有版本
流程不是写完就定死。每轮复盘只调整放行条件，不随意增减闸口；确有调整，就更新本文，让所有人看到的仍是同一套做法。
本文在「在做什么」「产品」「服务」三处指向同一个地址，是同一篇，不是三份；三处文字若有出入，以本文为准。