THESIS / 核心主张
需求没有写出的地方不会保持空白，模型会自动用常见假设补齐；体检的作用是把这些隐性决定提前暴露。
OPERATING STEPS / 执行动作
把原则变成可以检查的动作。
- 确认目标用户与业务动作
- 列出输入、输出、数据来源和唯一标识
- 补齐状态变化、幂等和权限
- 枚举部分失败、重试和恢复
- 明确量级、环境与验收样本
OUTPUTS / 交付物
每个阶段都要留下可复用的产物。
APPLIED CASE / 项目映射
这条方法如何落到真实项目？
GMV 原始目标被展开为平台范围、日期来源、销售与退款口径、目标表、预览/写入和汇总刷新条件。
FULL CHAPTER / 完整正文
从结论摘要，继续读到判断依据和执行细节。
正文保留 site-v3 的完整论证结构，并将贯穿示例改写为生态店铺 GMV 清洗迁移；原作者身份、原演示案例和未经证实的个人成果不进入本站。
需求体检：AI 写代码前，人先审需求
需求体检不是沟通技巧，而是工程动作。它的产物不是一段聊天记录，而是一份可执行规格的原材料。
这一章是整套方法论的核心动作。在 AI 动手之前，人必须先审需求。
一、为什么 AI 时代需求缺陷的代价反而更高
软件工程有一条经受了四十年检验的结论：缺陷发现得越晚，修复成本越高，且随阶段呈数量级增长（Boehm 在《Software Engineering Economics》中的经典分析）——需求阶段一句话能改掉的问题，到生产环境就是事故复盘。
AI 没有改变这条曲线，但改变了另一件事：它拆掉了一道天然的需求防线。
在手写代码的年代，实现本身很慢，而实现过程也是被动澄清过程——写到平台分支时会停下来确认口径，写到落库与汇总时会确认失败边界。需求缺口在实现途中不断被撞见、被补上。
AI 把实现压缩到分钟级之后，这个"实现途中撞见问题"的过程消失了。AI 不会停下来问，它会用默认假设把每个缺口无摩擦地补完，然后给你一份看起来完整的代码。需求缺陷第一次可以不经任何阻拦，直达代码库。 这正是 DORA 2024 观察到"AI 采用度上升、交付稳定性反而下降"的一种合理解释（数据见认知篇）。
所以结论是：AI 越快，需求体检越不能省——它是曲线上唯一还便宜的环节。
二、原则：产品需求不是工程规格
原始需求：
把旧的生态店铺 GMV 清洗逻辑迁移为 Java 链路。
产品说"执行平台 GMV 清洗"，表达的是业务意图。工程师要交付的不是意图，而是一个在真实系统里可运行、可维护、可验证的实现。两者之间隔着一层翻译：
把业务语言翻译成工程约束，把隐性场景变成显性规格。
AI 可以根据规格写代码，但它很难替你判断规格是否完整——因为很多缺口不在代码里，而在业务现场、系统历史和线上风险里。那些信息只在你这里。
三、八维体检：每一维都对着 AI 的一个默认假设
拿到需求后按八个维度扫描。这八维不是随手列的——每一维都对应 AI 最常替你做默认假设的一个位置。扫描的产出只有两种：有明确答案，或进入"待确认问题"清单。
| 维度 | 要确认的问题 | 你不说，AI 的典型默认假设 |
|---|---|---|
| ① 上下文与架构 | 单体还是多实例？涉及哪些已有服务和表？有无历史兼容要求？ | 单机部署、绿地项目、没有历史包袱 |
| ② 唯一标识与幂等 | 平台、日期范围与目标表规则？分布式唯一怎么保证？重复请求的语义？幂等键是什么？ | 自增主键即编号；每次请求都是新请求 |
| ③ 并发与一致性 | 并发量级？共享资源竞争？强一致还是最终一致？用什么手段？ | 请求串行到达；synchronized 够用 |
| ④ 数据与性能 | 数据量级？索引？分页/批量/导出？金额精度和舍入规则？ | 数据量很小；double 存金额 |
| ⑤ 异常与边界 | 下游失败怎么办？部分成功如何回滚？重试有无副作用？空单/零额/超大金额？ | 万事顺利；异常打日志后吞掉 |
| ⑥ 安全与权限 | 谁能操作？是否校验数据归属？敏感信息和审计？ | 调用方可信；权限在别处已处理 |
| ⑦ 可观测与运维 | 关键日志和指标？出问题如何定位？要不要灰度、开关、回滚预案？ | 能跑就行，出事再说 |
| ⑧ 验收标准 | 正常、重复、并发、失败、越权分别怎么验？ | 有几条 happy path 测试就算测了 |
第三列就是这张表的价值所在：它把认知篇的核心判断——"AI 在你没说清的地方按训练分布做默认假设"——变成了逐项可查的清单。训练语料里大多数代码是单机 demo，所以 AI 的默认世界就是单机 demo 的世界。
以"把旧的生态店铺 GMV 清洗逻辑迁移为 Java 链路"为例过一遍这张表，至少会掉出九个待确认问题：部署形态、平台、日期范围与目标表规则、重复请求语义、防重手段、事务范围、失败回滚、权限归属、量级、验收用例。这些问题不问，AI 也会写完——只是每个问号都被换成了默认假设。
四、模板：可复制的需求澄清表
体检结果沉淀为结构化文档，而不是留在对话里：
【业务目标】
为指定平台与日期范围执行平台 GMV 清洗，结果用于经营分析、对账和下游汇总。
【系统上下文】
- Spring Boot 服务承载新的总控与平台执行器
- 旧规则分散在历史文档、任务、SQL 和数据库调用关系中
- 已有平台源表与下游汇总，不允许在迁移中擅自改口径
【核心规则】
- 九个平台分别保留销售、退款、日期和归属规则
- save=false 仅预览；save=true 才允许按白名单目标表写入
- 运行范围由平台集合、开始日期、结束日期和目标表组成
- 任一平台失败都不刷新完整汇总
【边界场景】
- 未知平台 / 无效日期范围
- 单平台失败后继续或停止
- 目标表不在白名单
- 预览模式出现写入副作用
【非功能要求】
- 关键链路按平台记录行数、耗时、状态和失败原因
- 总控不直接依赖平台 Mapper
- 所选平台全部成功后才刷新完整汇总
【验收标准】
- preview 无写入副作用
- 未知平台与无效日期在执行前拒绝
- 失败策略符合 continueOnError 配置
- 非白名单目标表被拒绝
- 新旧链路可按同范围核对差异
【待确认问题】
- 同一范围重跑采用覆盖、追加还是清理后重建？
- 每个平台分别使用哪个日期和退款口径？
- 汇总刷新和下游通知的准确触发条件是什么？
注意最后一栏：体检允许有答不上来的问题，但不允许有没被发现的问题。 待确认清单怎么分级、怎么问出去，是下一章的内容。
五、例子：澄清前后对比
澄清前：
把旧的生态店铺 GMV 清洗逻辑迁移为 Java 链路。
澄清后：
在 Spring Boot 服务中，将九个平台的旧 GMV 清洗规则迁移为总控 + 平台执行器。
总控只处理平台选择、日期校验、失败策略、结果聚合和汇总门禁。
save=false 不产生写入；save=true 只能写入配置白名单中的目标表。
平台结果返回读取/写入行数、耗时和错误原因；任一失败都不刷新完整汇总。
必须覆盖未知平台、无效日期、预览、两种失败策略、目标表白名单和全量成功测试。
用同平台、同日期范围的新旧结果核对销售额、退款额、行数和关键维度差异。
需求体检的价值不是让 AI"更听话"，而是让 AI 拿到的问题本身更正确。喂给模型的问题质量，决定了产出质量的上限。
六、体检的边界：不是所有需求都值得八维全扫
体检本身有成本，专业的做法是按风险裁剪：
- 核心链路需求（涉及资金、状态、存量数据）：八维全扫，缺一维都是隐患；
- 常规业务需求：重点扫②幂等、⑤异常、⑧验收三维，其余快速过；
- 探索性需求 / 原型：不做体检，直接让 AI 快速实现——此时需求本身就处于"做出来看看才知道要什么"的阶段，审一个必然要变的需求是浪费。这类任务的处理方式见执行篇的任务分级。
另外要警惕反向失效：如果一次体检掉出的待确认问题超过十几个，且多数是业务语义问题，信号往往不是"需求写得差"，而是业务本身还没想清楚——此时该推动的是业务讨论或原型验证，而不是逼产品逐条填表。
七、本章小结
- 缺陷修复成本随阶段数量级增长，而 AI 拆掉了"实现途中被动澄清"这道天然防线——需求缺陷第一次可以无摩擦直达代码库，所以体检是曲线上唯一还便宜的环节。
- 八维体检的每一维都对着 AI 的一个典型默认假设，把"AI 会替你猜"变成逐项可查的清单。
- 产物是结构化澄清表 + 待确认问题清单：允许有答不上来的问题，不允许有没被发现的问题。
- 体检按风险裁剪：核心链路全扫，常规需求扫重点，探索性任务不扫。
下一章 需求反问清单，讲怎么把待确认问题分流、分级、专业地问出去。
参考资料
- Barry Boehm, Software Engineering Economics（1981）——缺陷修复成本随发现阶段数量级增长的经典分析。
- DORA, Accelerate State of DevOps Report 2024——AI 采用度上升与交付稳定性下降并存，数据详见认知篇。