在这篇文章中《AI与人协同：开发领域的转型实践与深度思考》，我讨论了 AI 的困境以及利用 AI 编程的一些实践方案 —— 与 AI 结对编程。

早期的 “结对编程” 确实帮我们跳出了思路局限、省下了重复编码的精力，但随着项目场景走向复杂（比如涉及多模块的事务逻辑、需要严格分层的领域层重构），这种 “即兴式协作” 的局限性开始凸显：AI 的概率本质会让错误随任务步骤指数级累积，偶尔突发的 “代码暴走”（比如一次小修改被扩写成千行变更），或是复杂逻辑里的隐形 bug，都可能让半天的工作面临回滚风险。这些实践里的 “踩坑”，让我们意识到：要把 AI 的价值真正落地，不能只停留在 “临时结对”，更需要一套结构化的流程来驯服它的 “不可靠性”。

当大语言模型（LLM）从“新奇工具”变成开发日常，我们对AI协同的认知也正从“即兴结对”走向“结构化范式”。在经历了AI代码“暴走”修改千行、复杂任务错误累积等真实踩坑后，我逐渐沉淀出一套SDD（Solution-Driven Development，方案驱动开发）协同编程范式：以技术方案为契约，通过“方案先行→渐进生成→测试闭环→高频反馈”的结构化流程，把AI的“概率不可靠性”纳入系统设计，让人机协同从“碰运气”走向“可信赖”。

一、范式跃迁：从“即兴协作”到“系统对抗”

早期的AI结对编程更像“头脑风暴式”协作：开发者抛出需求，AI发散思路，再共同收敛到可行方案。但随着项目复杂度提升，这种“即兴模式”的隐患逐渐暴露——AI的概率本质会导致错误随步骤指数级累积（即前文提到的pⁿ成功率衰减），一次看似简单的代码修改可能引发大规模“失控”，而一次性提交大量代码的习惯会让回滚成本高到难以承受。

SDD范式的核心突破，在于把“对抗AI不可靠性”从被动应对变成主动设计。正如我在会员创建功能重构实践中所做的：

1. 先定方案：让AI输出《会员创建功能重构技术方案》，明确“职责分离、降低耦合、可测试性优化”的设计原则，人工审核通过后，把方案作为后续开发的“契约”；
2. 渐进生成：基于技术方案，让AI先根据技术方案生成model层方法，人工校验生成的方法，再让AI根据技术方案生成domain层的方法，人工校验事务边界、错误回滚规则等；
3. 测试闭环：根据方案中定义的“会员已存在、事务异常、手机号为空”等测试边界，让AI生成单元测试用例，人工审核用例覆盖度后，跑通所有测试；
4. 高频提交：每完成一个逻辑块就提交代码，即使AI突发“暴走”修改千行代码，也能通过Git快速回滚到上一个稳定版本，避免工作成果大规模丢失。

这种结构化流程，本质是用“系统设计”对冲AI的不可靠性——通过阶段式校验、高频反馈和版本控制，把AI的错误锁定在局部，避免全局崩溃。

二、SDD协同编程的核心流程与实践

1. 方案先行：用文档锚定“确定性”

技术方案是SDD的“第一契约”，它的核心价值是减少AI的“可能性空间”。

在会员创建重构中，我先让AI输出包含“项目背景、问题分析、设计原则、代码示例”的完整技术方案。人工审核时重点关注：

• 架构合理性：是否符合“领域层与模型层分离”的设计目标？
• 边界清晰度：事务处理、错误回滚的规则是否明确？
• 可落地性：代码示例是否贴合项目的GORM框架与错误处理规范？

只有方案通过人工评审，才会进入代码生成阶段。这一步相当于给AI戴上“缰绳”，避免它在后续代码生成中偏离架构方向，也让开发者对最终产出有明确的预期锚点。

2. 渐进生成：小步快跑，逐段校验

面对LLM的pⁿ成功率衰减，最有效的应对是把大任务拆成“最小可用单元”，让AI逐段生成，人工逐段校验。

在根据技术方案生成代码时，我没有让AI根据技术方案一次性生成所有的代码，而是拆分出三个阶段：

1. model层函数：先让AI根据技术方案文档生成需要依赖的model层方法，人工检查生成的代码是否符合预期；
2. domain层逻辑生成：生成“手机号查重→会员存在判断→创建会员”的核心逻辑，校验查询条件与错误回滚是否正确；
3. 事务处理：补充事务提交/回滚的分支逻辑，内外部事务逻辑，确保异常场景下数据一致性。

每完成一个阶段就提交一次代码，即使AI在某一步出现逻辑错误，也能快速回滚到上一个稳定版本，避免错误累积到后续环节。这种“小步快跑”的模式，让AI的错误影响始终可控。

3. 测试闭环：用验证锚定“质量底线”

测试用例是SDD的“最后一道防线”，它不仅验证代码正确性，更是对AI输出的二次校验。

Model层测试：

• 测试 CustomerModel.Create 方法：验证数据插入是否正确
• 测试 CustomerModel.GetByPhone 方法：验证查询逻辑是否正确
• 测试 RankModel.GetInitialRank 方法：验证初始等级获取是否正确

Domain层测试：

• 使用 gomonkey mock Model层方法
• 测试 CustomerDomain.CreateCustomer 方法的各种场景：
  • 新会员创建成功（内部事务）
  • 新会员创建成功（外部事务）
  • 会员已存在
  • 等级获取失败
  • 会员创建失败
  • 事务回滚场景
  • 异步处理场景

人工审核用例时，我会重点检查场景覆盖度、预期结果合理性，再通跑通所有测试。这一步让“质量”从“主观判断”变成“可量化指标”，也能发现AI生成代码时遗漏的逻辑细节。

4. 高频反馈：版本控制作为“安全网”

频繁提交代码是应对AI“不可预测错误”的关键。我在实践中保持“每完成一个模块就提交”的习惯。

就像那次AI“暴走”修改千行代码的经历，正是因为我在上一个逻辑块提交了代码，才得以快速回滚，避免了几天的工作成果丢失。这种“高频快照”的模式，相当于给开发过程装上了“自动保存”，让AI的任何“失控”都能被快速纠正。

三、底层逻辑：用系统设计驯服“概率本质”

SDD范式的有效性，源于它精准针对LLM的“概率预测器”本质，构建了三层防御体系：

1. 契约化约束：减少AI的“自由发挥”

LLM的输出依赖上下文，技术方案作为“书面契约”，给AI明确的输入边界，让AI的生成更聚焦、更可控。这对应前文提到的“减少可能性空间”原则——选择越少，错误概率越低。

2. 阶段式校验：打断错误累积链条

pⁿ衰减的核心是“错误随步骤指数级增长”，而阶段式校验相当于在错误累积前“止损”。比如AI生成事务初始化代码时，人工发现isInternalTx的判断逻辑有问题，及时修正后，后续的数据库操作就不会基于错误逻辑生成，从源头避免了错误扩散。

3. 高频反馈：用版本控制对冲风险

Git的提交与回滚机制，是应对AI“突发错误”的“安全网”。高频提交让每个阶段的工作都有快照，即使AI出现大规模错误，也能快速回滚到上一个稳定状态，避免“一次性提交大量代码”带来的回滚灾难。

四、SDD范式的落地关键原则

要让SDD真正成为团队级的协同范式，需要遵循四个核心原则：

1. 文档即契约

技术方案必须经过人工评审，明确架构边界、技术选型、错误处理规则，避免AI“想当然”生成不符合项目规范的内容。

2. 最小化迭代

代码生成按“最小可用单元”拆分，每个单元仅实现一个核心逻辑（如一个函数、一个分支判断），便于快速校验和回滚。

3. 自动化验证

测试用例尽可能自动化，通过CI/CD pipeline跑通所有测试，确保每个阶段的质量可追溯、可量化。

4. 版本安全网

保持高频提交（如每1-2小时提交一次），用Git的分支、标签功能保护工作成果，应对AI的不可预测错误。

五、从个体范式到团队能力

SDD不仅是个人的编程实践，更可以推广到团队层面，成为组织级的AI协同能力：

• 沉淀方案模板：把常见场景（如领域层重构、批量写入优化）的技术方案做成模板，让AI生成方案时更贴合团队规范；
• 构建协同工具链：整合代码生成、测试用例生成、版本控制的工具链，让团队成员都能复用SDD流程；
• 规范AI使用：明确AI在各阶段的角色（如方案生成、代码填充、用例生成），避免滥用或依赖AI完成核心逻辑。

结语：AI是伙伴，流程是保障

SDD驱动的AI协同编程，本质是构建“人主导、AI辅助、流程保障”的系统。它不是“让AI干活，人来擦屁股”，而是通过方案锚定方向、小步迭代控制风险、测试验证保障质量，最终让AI从“不可靠的工具”变成“可信赖的伙伴”。

在AI技术快速迭代的今天，我们无需纠结“AI是否会替代开发者”，更重要的是思考“如何用系统设计驯服AI的不可靠性”。SDD范式正是这一思考的落地实践——它让我们在享受AI提效红利的同时，守住质量与效率的平衡，在人机协同的浪潮中，真正实现“1+1>2”的价值。