AI研发流程初步实践（一）：用流程约束驯服不确定性

发表于 更新于 分类于 ，
四阶段流程、文档分层、双重审核、熔断机制、看板管理与TDD红绿循环如何让AI输出从不可预测变为可控可追溯

如果你试过让AI写代码，大概率遇到过这种情况：第一次对话时AI给出了漂亮的方案，你点头说”好，就按这个做”，但执行起来AI开始自由发挥——跳过测试、在计划文档里塞实现代码、同一个错误反复试十遍、做到一半又推翻自己前面的设计。这不是AI不够聪明，而是你缺少一套约束它的工作流。AI的输出天然不可预测，靠”仔细写prompt”远远不够，需要用流程把不确定性管起来。

一、概览：为什么需要工作流约束

理解AI辅助开发工作流的价值，首先要认清一个事实：大语言模型本质上是概率生成器。同样的输入，两次输出可能完全不同。同一个任务，AI可能第一次走了一条完美路径，第二次在同一个坑里反复跌倒。

这和人类开发者有本质区别。人类开发者有一个”内心模型”——你知道自己在做什么、为什么这么做、做到哪一步了。AI没有这个内心模型。它每一轮推理都是从当前上下文重新开始，没有”我记得之前已经决定过X”的连续性。如果你不给它结构化的流程约束，它的行为就类似”每次翻开同一本书的不同页”——全局上缺乏一致性。

工作流约束的价值就在这里。它不是限制AI的能力，而是给AI一个决策框架。四个阶段（brainstorming → spec → plan → TDD实现）本质上是在不同的抽象层级上做决策，让AI在正确的层级上做正确的事：

  • brainstorming 阶段解决”我们应该做什么”——对齐目标，列出选项，做出选择。
  • spec 阶段解决”系统应该长什么样”——固化设计决策，划清范围边界。
  • plan 阶段解决”第一步做什么、第二步做什么”——拆解执行步骤，设定验收标准。
  • TDD实现阶段解决”代码怎么写”——用红绿循环驱动代码正确诞生。

每个阶段只关注一个核心问题，不跨层决策。brainstorming阶段不讨论代码怎么写，spec阶段不讨论执行顺序，plan阶段不写实现代码。这种分层约束让AI的输出从”自由散漫”变成”可预测推进”。

二、通用设计方案：四阶段流程

一套成熟的AI辅助开发工作流，通常由四个核心阶段组成。每个阶段产出不同的文档，解决不同层面的问题。

2.1 brainstorming：在动手之前对齐目标

brainstorming阶段要回答的问题是：”我们到底要做什么？”听起来简单，但在实践中，这是整个流程里最容易被跳过的环节，也是跳过之后代价最高的环节。

brainstorming的标准产出是一份决策表。每一条开放问题，列出所有可选方案、选中方案的决策依据、以及为什么排除其他方案。比如”用户数据存哪里”这个问题：选项包括SQLite、PostgreSQL、JSON文件、云端API。决策表会分析每个选项的优劣，然后给出明确结论。

决策表的价值不在于”记录”，而在于迫使命名思考。当你把”为什么选A不选B”写下来的时候，常常发现自己其实没想清楚。决策表让模糊的想法变成清晰的判断。

2.2 spec：设计决策的宪法

brainstorming产出决策表之后，进入spec（规格说明）阶段。spec把决策表中的每一条选择，固化为系统的设计承诺。

一份完整的spec包含：功能范围（in scope / out of scope）、架构概览、文件结构、关键接口签名、数据模型、测试策略、验收标准。它是后续一切工作的”宪法”——plan不能违反spec，实现不能偏离spec。

spec阶段最重要的动作是双重审核：

  1. self-review：AI自己按检查清单过一遍——是否存在placeholder残留、前后是否一致、范围是否合理、是否有歧义表述。这一步能挡掉大部分低级错误。
  2. user review gate：self-review通过后，spec提交用户审核。用户没点头之前，不允许进入下一步。这道门不是形式主义——AI写spec时经常把”未来版本”的内容写进当前spec，或用模糊词（”大致””可能””看情况”）掩盖未决策的开放问题，user review是把这些问题逼出来的最后机会。

2.3 plan：拆解为可执行任务

spec审核通过后，进入plan阶段。plan把spec拆成具体的subtask清单。每个subtask包含三要素：做什么、如何验证、依赖什么。

plan有一条硬规则：plan里不允许写实现代码。这条规则的价值需要特别强调：

  • plan阶段的代码无法验证——没有测试驱动，代码的正确性全凭AI脑补
  • plan里的代码会固化实现思路，让TDD红绿循环失效
  • plan里的代码会让看板失真——“subtask完成”变成”代码已粘贴”而非”测试全绿”

plan中唯一允许出现的”代码”是TDD命令描述（比如”运行 npx vitest run xxx.spec.ts，预期RED”）和验证命令。其余代码一律在TDD实现阶段写。

plan的另一个关键机制是看板管理。每个subtask前面一个checkbox，完成的标 [x]，进行中的标 [~]。这套机制在AI辅助开发里有不可替代的价值：它让进度可见、支持断点续传、提供明确的完成判定标准。

2.4 TDD实现：红绿循环驱动代码

plan确认后，进入TDD实现阶段。这是唯一允许写代码的阶段。TDD在此处不是”最佳实践建议”，而是唯一允许的编码方式。

TDD的红绿循环结构：

  1. RED：先写测试，运行，必须在终端看到失败。看不到RED就写实现，等于没写测试。
  2. GREEN：写最小代码让测试通过。不许多写一行”顺便”的代码。
  3. REFACTOR：测试通过后才能重构，重构后再跑一次测试确认仍绿。

为什么必须先见证RED？因为AI经常写”看起来对但永远通过”的测试——断言写错变量名、测试根本没调用被测函数、mock配置让任何输入都通过。先跑一次看到RED，证明测试真的在测你想测的东西，GREEN阶段才有意义。

GREEN阶段的”最小代码”同样关键。AI倾向于”一步到位”写出完整实现，包括各种未要求的扩展。这不但违反YAGNI（You Aren’t Gonna Need It），也会让后续subtask无活可干。

2.5熔断机制

AI重复尝试失败方案是高发问题。同一个测试连续失败3次，必须熔断——停止当前subtask，记录失败原因，跳过，回顾。

熔断不是放弃，是止损。3次失败通常意味着AI进入了”换种方式重试”的死循环——改了个变量名、调了个参数、调整了import顺序，但根本思路没变。继续试下去只是消耗token和时间。熔断后回顾环节要问的不是”下次怎么试”，而是”是不是这个subtask本身拆错了”或”是不是spec的某条决策有问题”。

熔断记录要保留。一段时间后回看熔断记录，能发现AI的系统性盲区——比如总是误判某个API的签名、总是忽略某种边界条件。这些模式是后续优化提示词与约束规则的依据。

2.6工作流总览

下图展示了上述四阶段流程的完整闭环：

AI辅助开发工作流

从brainstorming出发，经过spec审核gate、plan拆解、TDD实现、再到完成收尾，每一个阶段都有明确的产出物和质量门。这套流程的核心思想是：把不可预测的AI输出，装进可预测的流程管道里。

三、市面其他方案对比

理解了四阶段工作流的设计，再来看市面上其他几种常见的AI辅助开发方式。这里将它们归纳为三种方案，分别对比它们的适用场景与局限性。

3.1方案A：自由聊天式

这是最直观的用法——打开聊天窗口，直接告诉AI”帮我写一个用户登录功能”，AI直接输出代码，你复制粘贴用起来。

设计特点：

  • 零流程：没有brainstorming、spec、plan，直接进入编码
  • 一次性对话：所有上下文在单次聊天里完成，关掉窗口就丢失
  • 完全依赖AI的即兴发挥：AI基于训练数据里的”通用最佳实践”做决策
  • 用户被动响应：AI输出什么，用户确认什么，没有审核门

适用场景：一次性脚本、快速原型验证、个人小工具。当代码用完即弃，不需要长期维护时，这套方式最高效。

局限性：任何需要多轮迭代、跨会话协作、多人团队、长期维护的项目都会失控。AI可能在第三次迭代时推翻自己第一次的设计，而你已经记不清当初为什么那么做了。

3.2方案B：单次prompt工程

这种方式比自由聊天更进一步——用户精心编写prompt，把需求、约束、技术栈、输出格式一次性交代清楚，让AI在单次响应里完成完整功能。

设计特点：

  • 精心设计prompt：用户花时间组织需求细节，预判AI可能犯错的地方，在prompt里提前约束
  • 单次生成：依赖AI一次输出完整正确的代码，不需要多轮交互
  • 对简单任务高效：当任务足够简单、边界足够清晰时，单次prompt可以产出一段可用的代码
  • 对复杂任务不可靠：任务越复杂，AI一次生成正确的概率越低

适用场景：中等复杂度的独立功能（如”写一个CSV解析器”、”实现JWT中间件”），边界清晰、依赖简单、一次生成即可使用的任务。

局限性：真实项目很少有”一次生成即可用”的任务。复杂的业务逻辑需要多轮推敲、测试才能稳定。单次prompt在出错后没有恢复路径——报错了怎么办？你得从头写一个更长的prompt重试。而且prompt越长，AI注意力的”中间丢失”问题越严重，核心约束可能被淹没在长篇prompt中间。

3.3方案C：结构化工作流

这就是本文前面详述的四阶段工作流——用文档分层、审核门、熔断机制、TDD约束把AI的输出管起来。

设计特点：

  • 四阶段分层：brainstorming → spec → plan → TDD实现，每层只关注一个核心问题
  • 文档驱动：每阶段产出结构化文档，跨会话保留项目记忆
  • 双重审核：self-review + user review gate，保证每阶段产出质量
  • 熔断机制：3次失败止损，不浪费token
  • TDD红线：先写测试再写实现，保证代码和测试一一对应
  • 看板管理：subtask进度可见，支持断点续传

适用场景：复杂长期项目、多人协作、需要持续迭代的产品级代码。

代价：流程成本最高。写spec、做review、维护看板都需要额外时间。一个简单的bug修复走完整套流程可能不划算。

3.4对比总结

维度 方案A（自由聊天） 方案B（单次prompt） 方案C（结构化工作流）
流程成本 最低 低 高
可追溯性 无 低 高
跨会话记忆 无 无 有
质量保障 依赖AI即兴发挥 依赖prompt质量 多层约束
复杂项目适用性 差 中 好
简单任务效率 最高 高 低
出错恢复 重头再来 重写prompt 熔断 + 回溯

没有绝对最优的方案，关键看场景。写一个用完即弃的脚本，方案A最快；实现一个边界清晰的独立模块，方案B够用；但面向长期迭代的项目，方案C是唯一可持续的选择。

四、aptbot的设计特点

aptbot作为一个开源学习型AI Agent项目，在设计工作流时做出了明确的选择：采用方案C，但根据项目定位做裁剪和优化。

4.1选择方案C的理由

aptbot的定位是”学习型个人助理”——这意味着它既要能处理真实开发任务，又要代码架构清晰到能作为教材。这两个目标都需要高质量、可维护的代码输出。方案A和方案B无法满足这一要求。

具体来说，方案C的以下特性与aptbot的定位高度匹配：

  • 可追溯性：每份spec和plan都是学习材料，读者可以回溯”为什么这么设计”
  • 质量保障：TDD红线保证每个功能有测试覆盖，适合教学示范
  • 看板管理：subtask的推进过程就是开发过程的教学示例
  • 审核门：展示”设计决策需要审核”的工程实践

4.2 aptbot的独特之处

aptbot在工作流上并非全盘照搬方案C，而是在几个维度上做了自己的选择：

  • TDD作为唯一编码方式：方案C中的TDD是”推荐实践”，aptbot将其升级为”硬约束”——通过 test-driven-development skill工具化执行，agent试图跳过测试会被拦截。这让TDD从”提示词里的建议”变成”系统层面的红线”。

  • subagent任务委派：aptbot实现了主agent + 子agent的分层架构。主agent负责规划和调度，子agent负责执行具体subtask。这种隔离性让每个子agent只看到自己的上下文，不被全局噪音干扰。方案C的典型实现通常用单agent串行完成所有任务，上下文越来越长，跑偏概率递增。

  • 熔断机制的记录与分析：aptbot把熔断记录沉淀为可分析的数据，用于后续优化提示词和约束规则。这已经带有”元学习”的色彩——不仅做完当前任务，还从失败中学习改进工作流本身。

  • 教学优先的文档风格：aptbot的spec和plan除了作为执行依据，还额外承担教学功能——文档会解释”为什么这么选”而不只是”选了什么”，让学习者理解设计背后的权衡。

4.3与其他方案的差异

和三种方案相比，aptbot最大的差异在于”把流程约束本身当作产品功能“。方案A和方案B把流程当作使用者的个人习惯，方案C把流程当作项目规范，aptbot则更进一步——流程被编码为工具和skill，agent在流程约束下运行，而不是在”自由发挥”后被review纠正。

这意味着在aptbot中，brainstorming、spec review、TDD红绿循环这些动作不是人和AI之间的”约定”，而是AI运行时环境的硬约束。agent无法跳过spec review直接写plan，无法在没看到RED的情况下写实现代码。这种”工具化约束”比”口头约定”可靠得多。

五、发展方向

AI辅助开发工作流仍在快速演进。以下几个方向值得关注：

更智能的阶段跳转：当前四阶段是线性推进的，但实践中有些场景可以跳过或合并阶段。未来可能根据任务复杂度自动判断”这个改动不需要写spec，直接从plan开始”，降低小改动的流程成本。

自动化审核：self-review目前还是AI自己review自己的产出，存在盲区。未来可以引入”双agent互审”——一个agent写spec，另一个agent扮演挑剔的架构师review。视角转换能暴露更多问题。

熔断的智能升级：当前的3次熔断是静态规则。未来可以基于历史熔断数据训练一个”预判模型”——在AI开始走错误路径之前发出预警，而不是等3次失败后再止损。

跨session的流程记忆：当前每个任务的工作流是独立的。未来可以把流程中产生的决策、失败模式、成功模式沉淀为长期记忆，让AI在后续任务中自动复用。

工作流可视化：当前subtask看板是markdown清单，比较原始。未来可以生成可视化的进度图和依赖图，让人类更直观地掌握AI的开发进度。

小结

AI辅助开发工作流的核心命题是同一个：如何让不可预测的AI输出变得可控。这篇文章从三个层面展开了这个命题：

  1. 为什么需要流程约束：AI没有内心模型，缺乏连续性，需要结构化框架来保证决策一致性。
  2. 通用设计方案：四阶段流程（brainstorming → spec → plan → TDD实现）加上文档分层、双重审核、熔断机制、看板管理和TDD红绿循环，共同构成一套完整的约束体系。
  3. 方案对比：方案A（自由聊天）最快但最不可控，方案B（单次prompt）中等，方案C（结构化工作流）最可靠但流程成本最高。aptbot选择方案C，并将流程约束工具化、红线化。

工作流约束不是为了限制AI，而是给AI一个可预测的运行轨道。在这个轨道上，AI可以安全地发挥其创造力，而不会被自身的概率性带偏。下一篇文章，我们把焦点从流程转向质量——TDD、版本控制、UAT如何协同，把AI写的代码从”能跑”提升到”可信”。