AI编程需求对齐：追问式与文档化方案怎么选

一、对比背景：为什么“对不齐”是AI编程的第一杀手

AI编程工具普及之后，开发流程中最脆弱的一环暴露得越来越明显：需求还没真正想清楚，代码已经写出来了。某资深开发者维护的一套开源AI编程skill（短时间内获得数万星标）在其说明文档中直接点出：软件开发最高频的失败模式是misalignment——对不齐。这套skill共17个，并非功能堆砌，而是每一个都瞄准AI编程流程中一个容易跑偏的环节，逐个设卡。

对不齐的代价不是“写得慢”，而是“写得对但方向错了”。脑子里有个模糊想法就甩给AI，AI立刻开干，500行代码摆在面前，你看着代码才意识到要的不是这个——但此时你已经被它的方案带着走了。重新想清楚自己要什么，往往比一开始就想清楚还难。

本文聚焦其中最靠前的两个环节——需求澄清与任务投喂，围绕两组对象展开对比：

• 对比组一：纯追问式需求澄清（下称方案A）vs 文档化追问式需求澄清（下称方案B）；
• 对比组二：一次性大需求投喂 vs 拆解式小步投喂。

两组对比共同回答一个问题：把活交给AI之前，人和AI之间到底应该怎样完成对齐。

二、对比对象定义

方案A：纯追问式需求澄清

这类skill的交互形态可以概括为“把你架在火上烤”。它不夸你、不顺着你说，而是持续追问：为什么这么设计、边界条件怎么处理、如果用户反过来用会怎样。追问一直持续到决策树的每个分支都被你自己回答清楚为止。它的产出物不是代码，而是一份被逼出来的清晰需求理解——只存在于当前对话上下文中。

方案B：文档化追问式需求澄清

这是方案A的工程化版本。拷问逻辑相同，但多了一步沉淀：追问的同时，把对齐结果写进项目的两份文档——一份统一术语表文档，用来锁定核心概念的口径；若干条架构决策记录（ADR，业界通用的工程实践），用来记录“为什么这么决策”。它的产出既有对话中的共识，也有可持久化、可被后续会话读取的文档。

投喂方式：一次性大需求 vs 拆解式投喂

需求澄清完成后，下一个分叉点是怎么把需求喂给AI。一次性投喂指把一个大特性整包丢给AI，例如要求它做一个同时支持邮箱登录、社交登录、双因素认证的用户系统；拆解式投喂则把它切成若干端到端可验证的小单元，逐个交付。

三、相同点分析

方案A与方案B形态不同，但技术逻辑高度一致：

1. 目标一致：都是在写第一行代码之前，把模糊想法收敛成清晰决策，直接对抗misalignment。
2. 机制一致：都依赖多轮问答逼近真实需求，而不是被动接受用户的第一句描述。
3. 介入时机一致：都发生在编码之前，属于“前置投入换后置返工”的交换——多花十分钟问答，省掉数小时返工。
4. 对AI交互模式的修正一致：常规AI对话倾向于顺从，用户说什么都先肯定再执行，顺到让人误以为自己已经想清楚了。两者都刻意打破这种顺从，把AI的角色从“执行者”前置为“质询者”。

四、核心差异分析

1. 结论的留存方式不同（最本质差异）

方案A的对齐结论只活在当前会话的上下文里：会话一长，早期结论被后续内容稀释；会话一关，结论即告蒸发，下次要么靠人肉复述，要么重新被问一遍。方案B把结论写入持久化文档，跨会话、跨任务仍可读取和注入。一句话概括：方案A解决“这次想清楚”，方案B解决“每次都记得上次想清楚的结果”。

2. 团队协作支持度不同

方案A天然是单人视角。方案B的术语表和ADR是团队资产：新人接手先读文档建立口径；新开的AI会话可以直接挂载这些文档作为约束，避免每个成员、每个会话各自重新对齐一遍。

3. 维护成本不同

方案A用完即走，几乎没有维护成本。方案B引入了文档腐化风险：需求变更后若不同步更新，过期文档反而会把AI带偏。它的隐性成本不是“写文档”，而是“持续让文档保持为真”。

4. 对后续环节的支撑强度不同

方案B沉淀的ADR记录的是决策依据而非结论本身。后续编码环节遇到边界情况时，可以回溯“当初为什么这么定”，而不是凭空猜测。方案A在这一点上没有抓手。

5. 实践反馈的差异点

从实际使用看，纯追问进行到第三轮左右，原本以为已经想清楚的需求，通常会被问出至少两个从未考虑过的死角——这一步A与B效果相当；差异出现在问答结束之后：A的共识随会话衰减，B的共识成为项目的一部分。

6. 投喂方式的差异根源

一次性大需求投喂有两种典型死法：一种是“铺架子”——前端、后端、数据库各铺一层薄架子，跑完哪一块都没有真正可用；另一种是“猛写一块”——挑一个模块深写，其余全部烂尾。两种死法的共同根源是：任务粒度超出了单次AI交付能被有效验证的范围。拆解式投喂把验证点前移，每一步都产出端到端可运行的最小闭环，返工面被收敛在单步之内。

五、对比表格

方案A vs 方案B：

对比维度	方案A：纯追问式	方案B：文档化追问式
交互方式	多轮追问，只问不记	追问同时沉淀文档
结论留存	会话上下文，易衰减丢失	术语表 + ADR，持久化
跨会话可用性	弱	强
团队协作	单人适用	多人、多会话适用
维护成本	接近零	需持续保持文档有效
决策可回溯性	无载体	可沿ADR回溯取舍理由
适用周期	短周期、一次性任务	长周期、持续迭代项目

投喂方式对比：

对比维度	一次性大需求	拆解式小步投喂
产出形态	浅层铺架或单点烂尾	每步端到端可用
验证时机	交付末端才能验证	每步即时验证
返工成本	高，方向性返工	低，局部修正
上下文压力	大，关键约束易被稀释	小，约束集中

六、典型场景选择

• 个人脚本、一次性原型：方案A足够。任务生命周期短，结论不需要跨会话留存，追问本身就能把死角问出来。
• 团队长期迭代的项目：优先方案B。多会话、多成员环境下，没有持久化文档，对齐成本会随人数和会话次数线性增长。
• 涉及多模块的大特性：方案B + 拆解式投喂组合。先锁定术语与决策口径，再按“邮箱登录端到端 → 社交登录 → 双因素认证”的顺序逐个交付，每步可验证、可回滚。
• 调用大模型能力辅助开发时（无论通过百度智能云等平台的模型服务，还是本地部署的模型）：模型能力越强，越要把约束前置到流程里，而不是依赖模型自觉。

七、选型建议

1. 看任务生命周期：一次性任务选A，长周期项目选B。
2. 看协作人数：单人快跑选A，多人协作选B。
3. 看需求变更频率：变更频繁的项目选B的同时，必须建立文档同步机制，否则文档会从资产变成负债。
4. 看交付粒度：无论选A还是B，只要单个需求大到“一次交付无法端到端验证”，就应该拆解投喂。
5. 避免形式主义：文档的价值取决于“会被再次读取”。一份写完后再也没人读的ADR，维护成本就是纯损耗。

八、迁移与使用注意事项

从方案A迁移到方案B，或从一次性投喂迁移到拆解式投喂，需提前评估以下几点：

1. 文档结构先行：迁移前先约定术语表与ADR的目录结构和格式，避免各写各的。ADR可参考如下通用骨架：

## 决策标题：登录模块分阶段交付
- 背景：一次性投喂导致各层均未达到可用状态
- 备选方案：整包交付 / 按登录方式分阶段交付
- 最终决策：先交付邮箱登录最小闭环，再叠加社交登录，最后接入双因素认证
- 取舍理由：每阶段可独立验证，返工面收敛在单步内
- 影响范围：认证模块、会话管理、前端路由

1. ADR写“为什么”而不是“是什么”：只记录结论的ADR无法支撑后续决策回溯，必须带上背景、备选方案与取舍理由。
2. 建立腐化检查点：迭代回顾时同步检查文档是否仍与现状一致，过期条目及时归档。
3. 拆解粒度以“端到端可验证”为界：拆得太细增加协调成本，拆得太粗退回“铺架子”的老问题；判断标准是每一步都能独立运行并验证。
4. 保留追问环节：即使有了文档，新会话开始时仍应让AI先读文档再追问缺口，文档不能完全替代拷问。

九、总结

纯追问式与文档化追问式方案解决的是同一个问题——需求对不齐；差异在于对齐结论能不能留存、能不能被团队复用。一次性大需求与拆解式投喂的差异，则在于验证时机与返工面的收敛程度。选型的核心判断只有两条：任务是否需要跨会话、跨人传承对齐结论；单次交付是否小到可以被完整验证。想清楚这两条，“逐环节设卡”的思路就可以被裁剪成任何团队都用得起的最小流程。