需求反问：把体检结果变成可回答的问题

好的工程师不是被动接需求，而是把没想清楚的地方提前暴露出来——并且带着选项和建议去问。

上一章的八维体检会产出一批待确认问题。这一章解决三件事：哪些问题该问谁、怎么问才专业、问完之后怎么追踪。

一、为什么反问是工程动作，不是沟通技巧

产品需求天然不完整。不是产品不专业，而是产品负责业务结果，工程师负责把业务结果落到真实系统里——两个视角看到的世界不一样。当业务说"把旧 GMV 清洗逻辑迁到 Java"时，往往默认旧口径天然正确、各平台规则相同、失败后可以直接重跑、部分成功也能刷新汇总。这些默认在产品语境里成立，在工程语境里全是事故来源。

AI 时代这件事的性质变了。以前一个未确认的假设，会在缓慢的实现过程中被撞见；现在的传导链是：

每一个未确认的假设，都会变成 AI 的一个自由度；每一个自由度，都会被训练分布里最常见的答案填上。

假设数量没变，但假设变成代码的速度快了两个数量级。反问因此不再是"沟通中的好习惯"，而是拦在假设和代码库之间的最后一道人工闸门。行业工具的演化印证了这个判断：GitHub 的 Spec Kit 把"澄清"做成了工作流里的独立环节（/specify 之后必须过 /clarify 才进入方案设计），AWS Kiro 的规格流程同样把需求确认放在生成代码之前——"先澄清再生成"正在从个人素养变成工具的默认形态。

二、分流：哪些问题问产品，哪些问题自己判断

体检掉出来的问题不能一股脑丢回产品。专业分流的依据是问题的决定权在谁手里：

问题类型	决定权	例子
业务规则	产品 / 业务	同一范围重跑采用覆盖、追加还是先清理后重建
业务口径	产品 / 业务	销售、退款、日期、类目与部门分别取哪个字段
用户体验	产品 / 设计	失败后页面提示什么
系统约束	架构 / 开发	是否已有执行器契约、目标表白名单和汇总服务
数据约束	后端 / DBA	是否已有唯一键、历史数据是否干净
验收标准	产品 / 测试	哪些场景必须测过才算完成
运维要求	运维 / 负责人	是否需要监控、告警、灰度、回滚预案

规则很简单：业务语义问产品，技术事实自己查，技术方案自己定再同步。 把"是否多实例部署"拿去问产品，和把"平台销售与退款口径"自己拍板，是同一种不专业的两个方向。

成熟的节奏是：先自己完成工程扫描并查清技术事实，再把真正需要业务决定的问题，集中、结构化地一次抛出。

三、好问题的三条质量标准

反问最容易失败在表达上。这样问会把协作变成对抗：

这个需求没写清楚，你们补一下。

一个能被快速回答的问题要满足三条标准：给出选项、说明影响、附带默认建议。 对比：

❌ 重复请求怎么办？

✅ 同一平台与日期范围重跑时，有两种处理方式：
   A. 按确认规则清理并重建该范围，同时保留运行记录
   B. 拒绝重复执行，要求先显式确认重建
   这个选择影响写入策略、运行记录和下游汇总，建议先核对旧逻辑再确认。

三条标准背后的原理：

• 给出选项——把开放题变成选择题，回答成本从"思考"降到"确认"；
• 说明影响——让对方知道这不是抠细节，而是会改变方案和风险的分叉点；
• 附带默认建议——即使对方暂时不回复，开发也有一个被声明过的假设可以先行，事后纠偏有据可查。

按这个标准组织一次完整的反问：

生态店铺 GMV 清洗迁移做了一次工程体检，有 5 个点影响实现方案和上线风险，需要确认
（每条都附了建议默认值，如无异议按默认执行）：

1. 重跑语义：覆盖 / 追加 / 清理后重建？【必须核对旧逻辑】
2. 日期口径：九个平台分别按哪个时间字段统计？【逐平台确认】
3. 金额口径：销售、退款、优惠、运费如何计入？【逐平台确认】
4. 部分失败：继续其余平台 / 立即停止？【由 continueOnError 控制】
5. 汇总门禁：是否仅在所选平台全部成功后刷新？【建议：是】

你呈现的不是"需求差"，而是风险清单加决策请求——问题数量可控、每条可直接回答、答案直接落进方案。

四、分级追踪：P0 / P1 / P2

问出去的问题必须可追踪，否则答案会散落在群聊里再次丢失：

【待确认问题清单】

P0 - 阻塞开发（不确认不能开工）
1. 同一平台与日期范围重跑：覆盖 / 追加 / 清理后重建？
2. 平台与日期参数限制：哪些状态允许执行平台 GMV 清洗？

P1 - 影响方案（影响表结构和架构，开工前应确认）
3. 日期范围、平台选择和目标表由谁控制？
4. 是否需要生成后发布事件？

P2 - 可后置（不影响本期结构，可进入后续迭代）
5. 是否需要手动作废功能？
6. 是否需要后台操作审计查询？

分级的判据是答案对系统结构的影响半径：P0 决定业务语义，P1 决定表结构和契约，P2 只影响后续迭代。P0 未确认就开工，等于让 AI 替产品做业务决策。

这份清单确认完毕后，连同澄清表一起进入下一章，翻译成正式规格。

五、反问的边界：两个反向信号

反问也有失效形态，出现以下信号时该换动作，而不是继续问：

问题太多、且多为业务语义。 一次反问超过十条 P0/P1 级业务问题，说明需求还在探索期——业务自己也不知道答案。此时逼产品逐条拍板，得到的是随口决定，之后还会翻。正确动作是先做低成本原型，用可见的东西收敛讨论。

把该带方案的问题问成了开放题。 "并发怎么处理"不该问任何人——那是工程师自己的专业领域。问出去的每个问题都应该是"业务二选一"，而不是把工程判断外包给不该做这个判断的人。反问清单的质量，反映的是提问者的工程判断力。

六、本章小结

• 每个未确认假设都是 AI 的一个自由度，会被训练分布里最常见的答案填上——反问是假设和代码库之间的最后一道人工闸门，行业工具（Spec Kit、Kiro）已把它做成默认流程。
• 分流依据是决定权：业务语义问产品，技术事实自己查，技术方案自己定再同步。
• 好问题三条标准：给出选项、说明影响、附带默认建议——把开放题变成选择题。
• 待确认问题按影响半径分 P0（业务语义）/ P1（结构契约）/ P2（可后置）追踪，P0 不确认不开工。
• 两个反向信号：业务问题过多说明该做原型收敛，而不是继续追问；工程问题不该被问出去。

下一章 从需求到规格，把确认后的需求翻译成 AI 可执行、测试可验证的工程规格。

---

参考资料

• GitHub, Spec Kit——将需求澄清（clarify）设为代码生成前的独立工作流环节。
• AWS Kiro——以规格（requirements / design / tasks）驱动的 AI IDE，需求确认前置于代码生成。