先画全链路，再切分期：我做 ERP/WMS/MES/QC 需求的方法

需求阶段最贵的错误不是写错一个字段，而是把系统的边界划错了。

起步时只做一个 MES，后来发现划小了

最初的范围是一个独立的 MES：生产订单、工序、报工、质检。写到流程部分就卡住了——生产计划从哪来？物料齐套谁来判断？成品入库之后怎么出库？

这些问题的答案都不在 MES 里。它们分别属于 ERP（销售订单、MRP、采购）和 WMS（收货、上架、拣货、出库）。

所以我停掉了单系统设计，改成先把 ERP、WMS、MES、QC 四条链合起来画一遍端到端流程。这个决定的代价是前期多花了大量时间，收益是后面每一份需求文档都不需要猜"上游给我什么、下游要我什么"。

编号体系是流程文档的地基

合并多份基线文档时，最大的风险不是内容重复，而是同一个节点被两套编号指代。我的做法是先定编号规则，再动内容：

这里有个很容易踩的坑：采购链本来就有 P09 来料检验，质检链又要加 Q01 来料 IQC，看起来是重复建站。

解法是把职责拆开，并在文档里写明重编逻辑：

• P09 是采购链上的检验任务（一个待办事项）；
• Q01 是质检能力节点（真正执行检验、出判定结论的动作）；
• P10 保留为判定分支节点（合格入库 / 不合格退货让步）。

任务与执行分离，重复感就消失了。如果不在编号规则章节写清楚这件事，后面每个读文档的人都会重新困惑一次。

分支条件必须显式编号

端到端流程里真正麻烦的不是主干，是分支。我把分支也编号，并且在节点明细和流程图里同时标注：

• N03 MRP 运算完成，若缺料 → 自动进入 P01 采购需求，到货后汇合回 N04；
• N06 齐套检查缺料 → 等待采购，或触发补料；
• N08 生产执行首检不合格 → 停线/调整；
• Q03 巡检异常 → 隔离/返工；
• Q04 完工检验不合格 → 返工/让步/报废；
• Q05 出货检验不合格 → 拦截出货/返工；
• P10 来料检验不合格 → 退货/让步接收。

分支不定编号，讨论时只能靠描述，两个人说的"那个不合格分支"很可能不是同一个。

插拔与撤回：把可配置性当成需求

这个方案要能作为模板交付给不同客户，所以流程节点必须能插拔——某个客户的业务里没有 FQC，就关掉 Q04，流程自动跳过。

插拔开关本身是需求，不是实现细节。文档里要回答的是：

• 关掉这个节点后，上下游怎么衔接？
• 谁能开关？
• 开关变更要不要留痕？

撤回则要分级，而不是简单允许/不允许：

硬闸点固定为三个：N12 销售出库过账、P12 三单匹配过账、P13 采购付款。过了这三处，纸质/财务事实已经发生，系统里唯一正确的处理方式是生成反向单据，不是"撤回"。

质检判定通过之后的撤回单列一条规则：可以撤，但需要权限，并且要保留判定记录——因为检验结论是质量追溯的证据，不能凭空消失。

先把范围收口成里程碑，再逐流程写需求

全链路画完之后，不要立刻开始写全部需求文档，那样会失控。先按里程碑把实施范围切开：

• M1 主数据与权限底座；
• M2 销售与采购主干；
• M3 生产执行与报工；
• M4 质检全链路；
• M5 出入库与财务过账衔接。

每个里程碑产出一份实施清单，写清楚依赖关系、验收口径和不做的东西。然后再按流程顺序，一份一份产出需求设计文档——销售订单 → MRP → 采购 → 来料 → 生产 → 完工 → 出货。

这个顺序的好处是：每份文档的上游接口都已经定稿，不需要预留一堆"待定"。

需求阶段只聊业务，不聊代码

这条是我的红线。需求文档里出现 entity、service、DTO 这类词，说明设计已经越界到了实现层，而实现层的信息会在开发阶段过期，最后文档既不能给业务看，也不能给开发用。

需求文档要回答的是：谁在什么状态下能做什么动作、数据从哪来、判定规则是什么、异常怎么处理、怎么验收。

代码级别的约定（表结构、接口路径、状态字段类型）放到开发提示词里，单独维护。两者分开，文档才能活得久。

小结

需求阶段真正要交付的不是文档量，是一套不会自相矛盾的边界：编号不重复、分支能指认、闸点不可逆、插拔有约定、分期可交付。

把这些先钉死，后面的设计文档就只是填内容；反之，每一份文档都要重新吵一次同样的架。