一、一个让人哭笑不得的场景

同事最近跟我吐槽：“用AI编程比我自己写还累。它总是做一些意料之外的事——擅自改不相关的代码、用奇怪的写法、反复犯同一个错误。最气人的是，它一个劲道歉，‘对不起我理解错了’‘很抱歉造成了困扰’……它越道歉我越气，恨不得隔着屏幕锤它一顿。”

这不是段子，而是当下许多开发者的真实体验。

二、痛点的本质：沟通的单向性

有人说，问题出在把AI当成了人。我不这么认为。

如果我对人类同事说“帮我优化一下这段代码”，他同样会不知所措。但区别在于：人类会反问——“你具体想优化什么？性能、可读性还是结构？”而AI不会主动追问。它直接猜，猜错了就道歉。

这就是问题的核心：沟通的单向性。

人类协作是双向的——你说一句，对方追问、澄清、确认，直到共识达成。而AI协作是你给什么它吃什么。模糊输入必然导致错误输出，错误输出又消耗你去纠正、回滚、重试。一来一回，工作量不减反增。

AI的“道歉”之所以让人崩溃，也正是因为它是单向的——它说“对不起”，但既没有理解错在哪，也没有能力追问你应该怎么做。道歉成了空洞的仪式，而不是沟通的延续。

三、解决方案：迭代式瀑布沟通范式

要解决单向沟通的问题，核心不是“别把AI当人”，而是建立一个结构化的协作框架，让AI在每个环节都替你完成它不会主动去做的事——追问、澄清、自检、逆向验证。

我提出的方法是“迭代式瀑布”范式。

什么是迭代式瀑布？

纵向是瀑布的五个软件过程：业务分析 → 需求分析 → 设计 → 开发 → 测试。每个过程都有明确的输入和输出，确保从业务到代码的完整链路。

横向是每个过程中的迭代循环：每个过程不是一次完成，而是通过多次快速迭代来逼近正确结果。每次迭代包含四个阶段——需求澄清、AI执行、AI校验、AI全局校验。

关键洞察：全局校验是跨过程的——它要跟“之前所有过程已经输出的确定性内容”做一致性检查，而不是只跟当前过程的结论比。比如你在“设计”过程中做了一次修改，AI需要逆向检查它是否与“业务分析”阶段已确定的某个结论矛盾。

一次迭代的四个阶段

【阶段一：需求澄清——直到思想同步】

这不是你单向提需求，而是双向澄清的过程：

你提要求 → AI澄清（提出疑问、补充边界）→ 你更新要求 → AI再澄清 → 循环，直到双方达成共识

这个阶段的目标是：让AI真正理解你要什么，而不是猜。

示例：

• 你：“给注册加手机号校验”

• AI澄清：“请问校验规则是什么？11位数字？是否需要考虑国际号码？失败时返回什么格式？”

• 你更新：“11位数字，国内手机号，失败返回400和错误信息”

• AI再澄清：“是否需要在已有校验逻辑之前执行？是否覆盖所有注册入口？”

• 你确认：“在已有校验之前执行，只覆盖主注册接口”

• 共识达成

【阶段二：AI执行——批准后执行】

澄清完成后，AI先声明执行边界，你批准后再执行：

AI澄清执行边界：“我将修改user.py中的register函数，在开头增加validate_phone调用，不改动其他函数。是否批准？”
你批准 → AI执行，输出结构化代码

这个阶段的目标是：执行前最后一次对齐，杜绝意外改动。

【阶段三：AI校验——检查是否符合本轮共识】

AI执行后，立即自检：

AI校验：“对照本轮需求和边界：1. 是否添加了手机号校验？是。2. 是否只修改了user.py？是。3. 是否保持了原有返回值结构？是。校验通过。”

这个阶段的目标是：快速发现执行层面的偏差。

【阶段四：AI全局校验——逆向检查与风险识别】

这是整个范式中最关键的一环。AI需要逆向对照之前所有过程已输出的确定性内容，检查本次修改是否存在矛盾或引入风险：

AI全局校验：

【已输出的确定性内容】（从各过程中提取）

• 业务分析结论：用户注册需支持手机号+验证码两种方式

• 需求分析结论：手机号校验规则为11位数字，非数字字符返回“格式错误”

• 设计结论：校验逻辑放在service层，不在controller层

• 之前开发过程中的结论：用户模型已定义phone字段，类型为String(11)

【本次修改】在register函数中增加了validate_phone调用

【一致性检查】

1. 与业务分析结论是否矛盾？否。

2. 与需求分析结论是否矛盾？是——需求要求非数字字符返回“格式错误”，本次返回的是“手机号无效”，建议统一。

3. 与设计结论是否矛盾？否——校验放在service层，符合设计。

4. 与之前开发结论是否矛盾？否——phone字段类型匹配。

【风险识别】

• 现有用户数据中可能存在空phone字段，本次修改未处理空值情况，可能引发空指针异常。

【综合评估】不通过。建议：1. 统一错误信息为“格式错误”；2. 增加空值处理。

这个阶段的目标是：让AI做你来不及做的逆向追溯，发现“这次修改会不会破坏之前已经确定的东西”。

为什么这个范式有效？

1. 用“澄清迭代”弥补AI的追问能力

AI不会主动追问，但你可以把“追问”变成流程中的一个阶段。需求澄清阶段的反复循环，本质上是在替AI完成它缺失的双向沟通。

2. 用“执行边界声明”杜绝意外

AI最让人崩溃的行为是“擅自改不该改的地方”。在执行前让AI先声明边界、你批准后再执行，这个简单的动作就能消除绝大部分意外。

3. 用“双重校验”控制质量

• 本轮回校验：检查是否做到了本轮说好的事

• 全局逆向校验：检查是否破坏了之前已确定的任何东西

两个维度合起来，才算完整的质量闭环。

4. 用小步迭代控制风险

每个过程都可以拆解成多个小迭代。业务分析可以迭代，需求分析可以迭代，设计、开发、测试都可以迭代。小步意味着每次变更的范围小、回滚成本低、反馈速度快。

四、一个完整的例子

以“增加手机号校验”为例，看迭代式瀑布如何运转：

【业务分析过程 - 迭代1】

• 澄清：你提“支持手机号注册” → AI澄清“是否需要短信验证？” → 你更新“不需要，只做格式校验” → 共识达成

• 执行：AI输出业务分析结论文档

• 校验：AI自检是否覆盖了所有业务场景

• 全局校验：与已有业务逻辑（邮箱注册）对比，确认无冲突

• 输出确定性内容：【业务分析结论】用户注册需支持手机号格式校验，不触发短信

【需求分析过程 - 迭代1】

• 澄清：你提“手机号校验规则” → AI澄清“边界条件：空值、长度、非数字？” → 你更新规则 → 共识达成

• 执行：AI输出需求规格

• 校验：AI自检规则是否完整

• 全局校验：与【业务分析结论】对照——业务说“只做格式校验”，需求中是否包含了非格式相关的内容？确认没有。

• 输出确定性内容：【需求分析结论】校验规则：11位数字、非数字字符返回“格式错误”、空值返回“手机号不能为空”

【设计过程 - 迭代1】

• 澄清：AI澄清执行边界“校验逻辑放在service层，不修改controller” → 你批准

• 执行：AI输出设计文档和接口定义

• 校验：AI自检是否符合需求规格

• 全局校验：与【业务分析结论】【需求分析结论】对照——设计是否超出了业务边界？是否遗漏了需求中的空值处理？确认覆盖完整。

• 输出确定性内容：【设计结论】在UserService中增加validatePhone方法，在register流程中调用

【开发过程 - 迭代1】

• 澄清：AI澄清“只修改user_service.py，新增validatePhone函数，不改动其他文件” → 你批准

• 执行：AI输出代码diff

• 校验：AI自检代码是否符合设计

• 全局校验：与【设计结论】【需求分析结论】【业务分析结论】逐条对照——代码是否实现了需求中的所有规则？是否违背了设计的架构决策？是否超出了业务的边界？

• 输出：通过或需要回滚修正

【测试过程 - 迭代1】

• 澄清：AI澄清测试用例范围“覆盖正常、空值、格式错误三种情况” → 你批准

• 执行：AI输出测试代码

• 校验：AI自检是否覆盖了需求中的所有规则

• 全局校验：与所有前置过程的确定性内容对照——是否有需求规则没有被测试覆盖？是否有业务场景遗漏？

• 输出：测试通过

五、总结

回到开头同事的痛点——他之所以“越帮越累”，不是因为把AI当成了人，而是因为用模糊的自然语言与一个不会追问、不会自检、不会逆向追溯的系统沟通。

解决方案是建立迭代式瀑布沟通范式：

1. 纵向是完整的软件过程——业务分析、需求分析、设计、开发、测试，每个过程都有明确的输入和输出

2. 横向是每个过程中的迭代循环——通过多次快速迭代逼近正确结果

3. 每次迭代包含四个阶段——需求澄清（直到思想同步）、AI执行（批准后执行）、AI校验（检查本轮共识）、AI全局校验（逆向检查与所有确定性内容的一致性）

这个范式的精髓在于：把AI不会主动做的事——追问、澄清、自检、逆向追溯——全部变成流程中的强制阶段。

当你在需求澄清阶段反复迭代直到思想同步，AI就不再“猜错”；当你在执行前让AI声明边界并得到批准，AI就不再“擅自乱改”；当AI每轮都做全局逆向校验，它自己就会发现“这次修改和两周前确定的业务结论有矛盾”。

AI的“道歉”变成了结构化的“偏差报告”：我违反了第X条确定性内容，建议这样修正。你不需要对着屏幕生气，只需要看报告、做决策、进入下一轮迭代。

这就是从“越帮越累”到高效协作的路径。

当然上述过程可以固化到Agent框架中，让整个框架成为更专业软件工程师。