需求 → 规范 · 通用工作流程（工具无关）

00六条关键认知

这六条不是流程步骤，而是决定流程该怎么设计的前提。它们全部来自实测数据，不是经验之谈——如果不同意其中任何一条，后面的步骤设计都会跟着变。

① 覆盖完整性不构成区分度

三条互不相通的路径分析同一份需求，需求要素覆盖都是 26/26。所以「有没有漏需求」几乎不是流程质量的指标——真正的差异 100% 出现在需求没写的地方。

② 流程越重 ≠ 越能想到边界

用最重拷问流程的那一路产出了最多的未定义点（16 个），却漏掉了「订单指向的框架不存在」；用最简流程的那一路（9 个）抓到了。加流程步骤解决不了这个，只有结构化的边界清单能解决。

③ 未定义点必须带答案

「这里需求没写」是问题清单；「这里需求没写，我推荐这样做，理由是…」才是规范。前者永远无法定稿，只会变成一张待办。

④ 裁决必须写影响面

只说「我选 A」，业务无法拍板；补上「如果选 B，代价是…」，业务才能在 30 秒内签字。影响面是裁决的一部分，不是附注。

⑤ 待确认项不得阻塞开发

把未定事项拆成「有默认值 → 直接做」与「属口径 → 按裁决先行、签字后调整」。这样规范不会变成一张待办清单，开发第一天就能开工。

⑥ 共识项不要重新讨论

被多条独立路径一致确认的结论，重开一次的成本高于收益。把它明确写进文档，能省掉评审会上最贵的 20 分钟。

01流程总览

七个步骤，三个阶段：发散（把事实和未知都摊开）→ 收敛（形成唯一依据）→ 落地（变成可执行、可验收、可评审）。每一步都产出一个文件，每一步都能被下一个人接手。

图 1｜三个阶段、七个步骤。注意 P3 是唯一不可跳过的步骤——它承担了本流程的全部价值增量；P5 有「多路 / 单路」两种走法，单路时退化为反向自查。

输入契约

需求 + 事实源 + 边界

现状取证

每条带 文件:行号

决策台账

9–20

未定义点，每点带推荐答案

待业务确认

不阻塞开发（有裁决先行）

02七个步骤

每步给：目的、做什么、产出、常见失败模式，以及可直接复制的提示词。提示词里的 {花括号} 是替换位。整体基调是「不要让模型停下来问你」——所有不确定性都在产出里标注为假设，人在评审环节一次性裁决。

冻结输入

阶段一 · 发散

目的: 让多路产出可比、让人换手后仍可复现。输入不冻结，后面每一步的「差异」都分不清是方法差异还是语境差异。
做什么: 写一份输入契约，固定六件事：需求原文路径、事实源路径、只读边界、输出语言、编号规则、产出结构约定。
产出: 输入契约一份（如 BRIEF.md），外加需求原文的纯文本版本——原始 .docx 的表格与格式会带来歧义，转纯文本能消掉一部分。
失败模式: 各路人马各自理解边界，合并时必须先逐条对齐语境，成本翻倍；或者事实源被误当成可写目录，产出被污染。

提示词 01 输入契约 · 开场设定复制

输入：
- 需求原文：{路径}
- 事实源（只读，不得修改）：{路径}
- 输出语言：中文

规则：
① 技术断言必须带 `文件:行号`；查不到就写「未找到 + 已检索范围」，禁止用常识或框架惯例填充。
② 需求与事实源冲突时以事实源为准，并列明冲突点。
③ 有疑问不要停下来问我，按最合理方案决定，并标注为「假设 An」。
④ 不写代码片段与文件路径（那是实现阶段的事）。

先复述你对需求的理解（不超过 200 字），再列出你认为最不确定的 3 个点。

第 ③ 条是这套流程能跑起来的关键：把提问权从模型手里收回，改成人一次性评审假设。

事实取证

阶段一 · 发散

目的: 把「现状」与「需求」彻底分开。规范里每一条技术断言都要能找到一手来源，否则它就是猜测。
做什么: 只读事实源，查明四类信息：数据从哪里来、现在的过滤/排序/权限怎么写的、需求提到但事实源里不存在的东西、需求描述与代码不一致的地方。
产出: 现状取证一份，每条结论格式为「结论 → 文件:行号」。
失败模式: 把「我没找到」写成「不存在」。实测中有一条路径停在「源码里没有」，于是把一处完全可查证的事实（某个编号没有唯一索引）记成了不可查证——后面的裁决全部建立在错误的「未知」之上。

提示词 02 事实取证 · 只写现状复制

只做取证，不写方案。

从 {事实源} 中查明需求涉及的：
1. 数据来源（表 / 字段 / 类型 / 约束 / 索引）
2. 现有的过滤、排序、权限判定是怎么写的
3. 需求提到、但事实源中并不存在的东西
4. 需求描述与代码实际行为不一致的地方

格式：结论 → `文件:行号`。
查不到就写「未找到（已检索：具体范围）」——禁止把「我没找到」写成「不存在」。

最后那句是本条提示词的全部价值。用「已检索范围」这个词，是在逼模型区分证据缺失与事实为负。

未定义点穷举

核心步骤 · 不可跳过

目的: 这是整个流程的价值所在。需求文档只写正向流程，剩下的全靠这一步挖。实测中三路的需求要素覆盖都是满分，差异全部产生在这里。
做什么: 按结构化的边界清单逐类扫描，每个点给 2–3 个候选方案 + 推荐方案 + 理由。
产出: 决策台账，编号 U-nn。实测三路分别产出 16 / 9 / 16 个点，其中 3 处结论冲突、1 处是其中一路完全没想到的场景。
失败模式: 只列问题不给答案——台账退化成待办清单；或者只扫「正常业务范围」，漏掉边界类。

边界清单（八类）——这才是「想到没想到」的真正分水岭实测证明：靠把流程做重、把追问轮次调多，并不能保证想到边界。用最重拷问流程的那一路漏掉了「上级对象缺失」。真正有效的是把边界固化成一张清单一类一类过：空值 · 边界值（含端点） · 未生效状态 · 上级 / 父对象缺失 · 跨权限边界 · 历史数据 · 重复键 · 极值数据量。

提示词 03 未定义点穷举 · 决策台账复制

列出「需求没写、但实现时必须拍板」的全部点。

每点输出：编号 U-nn｜议题｜2~3 个候选方案（各注明适用场景）｜推荐方案 + 理由。

必须逐类扫描这些边界：
空值 / 边界值含端点 / 未生效状态 / 上级对象缺失 / 跨权限 /
历史数据 / 重复键 / 极值数据量

要求：
- 每点必须给出推荐答案，只提问不算；
- 目标 10~20 个；只有一个候选方案的点不算未定义点；
- 输出表格，不要散文。

「只有一个候选方案的点不算未定义点」这条过滤条件很重要——它挡掉了那些看起来像决策、其实是唯一解的伪条目。

规范成文

阶段二 · 收敛

目的: 把决策固化成可验收的条文。规范的读者有两类：写代码的人、验收的人——他们都要能凭编号指认某一条。
做什么: 按固定结构成文；所有规则编号（需求可追溯的用 FR-nn，边界规则 / 假设用 R-nn）；不写代码与文件路径。
产出: 规范正文，十节固定结构。
失败模式: 条文含糊（「排序合理」）；规则与需求无法一一对应；写成了实现方案。注意：不写技术选型不是遗漏，是刻意留白——选型会掩盖需求本身的模糊。

提示词 04 规范成文 · 固定结构复制

按固定结构写规范：
1 范围与目标｜2 数据模型｜3 输入字段｜4 输出字段｜5 处理规则
｜6 查询语义｜7 权限与数据范围｜8 接口契约｜9 导出与搜索｜10 前端要求

要求：
- 每条规则编号：FR-nn（可追溯需求）／R-nn（边界规则与假设）；
- 每条都能被后文的验收条目引用；
- 需求没写的，引用 P3 的假设编号，不要重新发明；
- 把「空值怎么排序」「无子项怎么显示」这类容易含糊的地方显式写死；
- 不写代码片段与文件路径。

提示词 05 要素覆盖核对 · 后置校验复制

把需求原文拆成最小可验证要素，逐条编号，输出表格：
编号｜要素原文｜规范中对应条款｜状态（已覆盖 / 部分 / 缺失）

规则：
- 禁止先合并同类项再计数（否则覆盖数是假的）；
- 状态为「部分 / 缺失」的必须单独列出并说明原因；
- 最后给出「已覆盖 x / 共 y」。

这条提示词是规范定稿前的最后一道闸。它同时给出了一个可对外汇报的数字：覆盖 x/y。

合并与分流

阶段二 · 收敛

多路走法: 拿到 N 份独立规范后，不要取并集——把冲突的两条并列，等于什么都没做。按三分处理：共识（直接采纳）、分歧（逐条裁决 + 影响面）、缺项（只有一份提到、其余没意识到的）。
单路走法: 只有一份规范时，这一步退化为反向自查：拿提示词 05 和边界清单反过来问「哪些边界我没扫到」，并补写缺的规则。实测表明这一步不能省。
分流: 把全部未定事项拆成两个集合：A-nn 有合理默认值 → 开发直接实施；C-nn 属业务口径 → 写清裁决与代价，开发按裁决先行，业务签字后如需调整再改。
产出: 唯一依据（合并规范或 v2 规范）+ 待确认清单（可直接打印签字）。
失败模式: 取并集；把待确认项当阻塞项、开发停工等答复；裁决只写结论不写代价。

提示词 06 多路合并 · 三分裁决复制

有 {n} 份独立规范。不要取并集，按三分处理：

1 共识：所有规范答案一致 → 列表，直接采纳；
2 分歧：答案不一致 → 表格：议题｜各方主张｜裁决｜理由｜若采纳另一方案的代价；
3 缺项：只有一份提到、其余未意识到 → 单独列出，判断是否应升格为规则。

裁决优先级：需求原文 > 事实源现状 > 数据结构自洽 > 行业惯例。
每条裁决必须写「不采纳那一方的影响面」，否则视为未完成。

第 3 类「缺项」是三分里最容易被忽略、价值却最高的一类——它抓的是独有发现，往往是真正的边界漏洞。

提示词 07 未定事项分流 · 假设与待确认复制

把规范中所有未定事项分成两类：

A-xx 已有合理默认值（开发可直接实施）→ 写：默认值 + 理由；
C-xx 属业务口径、必须由业务拍板 → 写：议题｜裁决（开发按此先行）｜
      若选另一方案的代价｜确认签字栏。

要求：
- C 类不得阻塞开发，开发一律按裁决值先行；
- C 类按是否阻塞开工排序，标出哪一项是硬阻塞；
- 代价一栏必须具体到「改动点在哪、影响谁」。

A / C 分流是「规范不变成待办清单」的关键。实测中 4 项待确认全部不影响开工——其中 3 项初稿里被当成了阻塞项。

垂直切片与验收

阶段三 · 落地

目的: 让规范变成可执行、可验证的计划。切片方式和验收口径决定了这份规范是被人用还是被人挂在墙上。
切片规则: 垂直切，不水平切。每一片要从数据打通到界面，能独立演示、独立验收。「数据层一片、服务层一片、界面一片」是反模式——三片都做完之前，什么都演示不了。
验收三件套: 最小种子数据（覆盖全部边界）+ 验收场景（操作 / 期望 / 覆盖的规则编号）+ 可度量标准（必须含数字）。
失败模式: 验收写「正确显示」「符合预期」——不可判定，等于没写；切片按层拆，等到最后才发现集成问题。

提示词 08 垂直切片 + 依赖图复制

把实现拆成垂直切片。每片给：编号｜目标｜依赖（Blocked by）｜落点｜验证方式。

约束：
- 垂直切片 = 从数据打通到界面的一条窄链路；
  禁止按层拆（schema 一片、service 一片）；
- 每片必须能独立演示与独立验收，写不出验证方式的片不算合格；
- 标注哪一片是 MVP、哪一片是硬前置；
- 最后画出依赖图，指出哪些片可以并行。

提示词 09 验收标准 · 可判定复制

输出三部分：
1 最小种子数据：必须覆盖空值 / 未生效状态 / 无子项 / 跨权限边界 / 重复键，
  做成表格，标出每条数据「用来验什么」；
2 验收场景 V1…Vn：操作｜期望结果（具体到数字或可见元素）｜覆盖的规则编号；
3 可度量标准 SC-nn：必须能用数字判定（如「越权行数为 0」「偏差为 0」「3 秒内」）。

禁止出现「正确显示」「符合预期」这类不可判定的措辞。

种子数据那一段最容易偷懒。要求「标出每条数据用来验什么」是刻意的——没有对应的场景，这条数据就不该出现在种子集里。

评审

阶段三 · 落地

目的: 把评审会从自由讨论变成逐项勾选，并且让每条意见都能落到具体编号上。
做什么: 三份清单：技术评审（指向最容易做错的实现点）、业务评审（只列需要拍板的口径问题）、不建议重开的问题（已被多路一致确认的结论）。
产出: 检查清单，每条带编号与影响。
失败模式: 评审意见没有编号 →「我觉得那个地方要改」，然后没人找得到是哪个地方；或者把已达成共识的结论重开一遍，吃掉大半会议时间。

提示词 10 评审清单 · 带编号复制

生成评审检查清单，分三部分：
1 技术评审：指向最容易做错的实现点，每条带规则编号；
2 业务评审：只列需要业务拍板的口径问题，每条带确认项编号；
3 不建议重新打开的问题：已被多份规范一致确认的结论，
  注明「重新讨论的成本高于收益」，并要求变更方提供新依据。

所有条目必须带编号，便于评审时直接指认改动位置。

03提示词速查

十条提示词按流程顺序排列。前五条（01–05）决定规范质量，中间两条（06–07）只在特定情形下需要，后三条（08–10）决定规范能不能落地。

表 3-1｜十条提示词总表
编号	名称	所属	用在什么时候	产出	必需性
`01`	输入契约	P1	每次任务开始时，一次性设定	输入契约 + 首轮理解	必需
`02`	事实取证	P2	需要以存量系统为依据时	现状 + 文件行号	必需
`03`	未定义点穷举	P3	取证完成后，成文之前	决策台账 U-nn	必需
`04`	规范成文	P4	决策台账定稿后	规范正文 FR / R	必需
`05`	要素覆盖核对	P4	规范定稿前的最后一道闸	覆盖矩阵 x/y	建议
`06`	多路合并裁决	P5	只有跑了多路独立分析时	三分表 + 裁决	条件
`07`	未定事项分流	P5	台账中有口径类问题时	A 表 + C 表	条件
`08`	垂直切片	P6	规范进入排期前	任务 + 依赖图	必需
`09`	验收标准	P6	与切片同步产出	种子数据 + 场景 + 指标	必需
`10`	评审清单	P7	评审会前一天	三份清单	建议

最小可用组合如果只记四条，记 01 → 02 → 03 → 04。这四条串起来就是「设定边界 → 查清现状 → 挖出未定义点 → 写成条文」，已经能产出比多数人手写更好的规范。其余六条是围绕它做的加固与落地。

04八条铁律

这些是从实测中付出代价换来的。前六条各对应一次具体的错误或一次具体的返工；第七条是整个流程的地基。

#	铁律	为什么
1	「查不到」不等于「不存在」	必须写「已检索范围」。实测中一条路径停在「源码里没有」，把一处完全可查证的事实记成了不可查证，导致后续裁决建立在错误的未知之上。
2	多路必须互不可读	一旦互相能看到，第二路就会锚定第一路的结论，多路的全部价值（发现差异）当场归零——退化成一次分析加两次润色。
3	未定义点必须带推荐答案	只列问题 = 待办清单，永远无法定稿；带答案 = 可评审、可裁决、可直接进规范。
4	裁决必须写影响面	不写「如果选另一方案会怎样」，业务无法在不知道代价的情况下拍板，评审必然反复。
5	待确认项不得阻塞开发	每条未定项都要有可先行的裁决值。实测中初稿里被当作阻塞的 3 项，实际都不影响开工。
6	共识项不重新讨论	被多条独立路径一致确认的结论，重开的成本高于收益。明确写进文档，并要求变更方提供新依据。
7	技术断言必须带 `文件:行号`	这是整个流程的地基。没有它，取证退化成「我记得应该是这样」，规范的权威性无从谈起。
8	验收标准必须可判定	「正确显示」「符合预期」是无效标准。必须含数字、含具体可见元素，否则无法验收，也无法回归。

反铁律（实测中最容易犯的三个错） ① 用流程复杂度代替边界清单。把追问轮次从 8 加到 16，并不会让你想到「上级对象缺失」。② 用并集代替裁决。把两份冲突的规范并列放进文档，看起来谁都没得罪，实际上把决策推迟到了编码阶段。③ 用「未找到」代替「不存在」。前者诚实且可继续追查，后者会永久关闭一条调查线。

05各工具在此流程中的位置

下面这张表用来证明这套流程确实与工具无关——它的每一步都只是「一件事」，而主流方法体系只是给这件事准备了不同的容器。选哪个容器不影响步骤本身。

表 5-1｜通用步骤 × 三种主流方法体系的对应关系
通用步骤	A · 技能链式	B · 增量规格式	C · 阶段流水线式
P1 冻结输入	公用输入目录 + 输入契约	工作区 + 提案前置	项目工作区 + 宪法
P2 事实取证	调研技能	提案文档的现状段	研究阶段
P3 未定义点穷举	拷问技能（人在环）	设计文档的未定义点段	澄清阶段（有提问数上限）
P4 规范成文	成文技能（固定模板）	需求 / 场景条目	规格阶段（刻意不写技术栈）
P4 后置 · 覆盖核对	—（靠人复核）	严格校验按机检执行	交叉分析阶段
P5 合并与分流	决策台账 + 补充说明	增量规格的归档	澄清记录表
P6 切片与验收	票据拆分（垂直切片 + 阻塞边）	任务清单（每项自带验证）	任务阶段 + 快速验证清单
P7 评审	—	机检护栏	宪法门禁

三个体系各有其独有能力，也各有实测短板：A 的拷问机制能产出最细的决策台账，但流程本身不保证想到边界；B 的机检护栏能零成本拦住格式错误，但在结构化信息密度上并无额外增量；C 的宪法层与三方交叉检查对治理类需求价值高，但用在整个团队的表单类需求上，用户故事的粒度偏粗。

结论这套七步流程是它们的最小公倍数。选工具时真正该问的不是「哪个流程更完整」，而是「我的需求里，未定义点由谁负责挖、挖出来的分歧由谁裁决」——这个问题在三个工具里都没有默认答案，它始终是人的工作。

06按需求规模裁剪

七个步骤全跑一遍是有成本的。按需求规模裁剪——但有一条底线：P3 永远不跳。

需求规模	保留步骤	用哪几条提示词	说明
单点改动半天–2 天	P2 → P4 → P6	`02 03 04`	跳过合并与评审。P3 仍需跑，但目标数量降到 5 个以内——单点改动照样有空值与权限边界。
一个功能页 1–2 周	全部七步，单路	`01 02 03 04 05 08 09`	不加 06（没有多路可合）。但 07 仍建议跑：口径类问题的分流对单路同样适用。
跨模块 / 有存量系统 2 周以上	全部七步，多路	全部十条	这是本流程的完整形态。多路并行的成本主要体现在 P2/P3，而价值也在那里——实测中三路的最大分歧恰好落在权限与数据口径上，那是最不该出错的地方。

什么时候该跑多路

① 需求涉及权限、金额、合规口径；② 要在存量系统上做、事实源不完整；③ 这份规范会被另一支团队实施。三条占一条，多路的成本就值。

什么时候单路就够

全新的、自己团队实施的、不涉及权限与金额口径的功能。此时单路 + 提示词 05 的反向自查已经能抓住绝大部分问题。

永远不要省的

P3 未定义点穷举，与提示词 02 里那句「查不到写已检索范围」。前者是价值来源，后者是可信度来源——省掉任何一个，后面的产出都不可复核。