为什么 AI 写代码越来越像开盲盒?6A 工作流给出的答案很现实

最近在 Trae、Cursor、Claude Code、Codex 这些 AI 编程场景里，6A 工作流开始频繁出现。很多人把它当成一个新 prompt，或者当成某个工具自带的高级模式。我觉得这两个理解都偏了。

6A 真正有意思的地方，不是让 AI 更聪明，而是让它没那么容易直接开写。

这句话听起来有点别扭，但做过复杂开发的人，大概都知道问题在哪。现在很多 AI 编程返工，不是因为模型一句代码都不会写，而是因为它太容易在需求还没对齐、边界还没确认、方案还没收敛的时候，就开始往前冲。结果往往是：代码先出来了，方向后面才发现错了。

真正贵的不是那几百行代码，而是后面一连串的回滚、补洞、重写和解释。

6A 就是冲着这个毛病来的。

目前能看到的社区实践里，6A 基本都被拆成六步：Align、Architect、Atomize、Approve、Automate、Assess，也就是需求对齐、方案设计、任务拆分、人工审批、自动执行、验收复盘。

几篇流传较广的中文实践文和规则仓库，对这六步的定义基本一致，差别主要在细节严不严、模板写得细不细。

Trae 官方文档能确认它本身覆盖从编码、调试到测试、重构、部署的一整条开发流程，但在 Trae 官方站和文档里，并没有把“6A 工作流”当成正式产品名来定义；现阶段更接近社区沉淀出来的一套规则框架。

这一点其实很关键。

因为很多人第一眼会把 6A 理解成“Trae 官方方法论”。但更准确的说法应该是：Trae 这类 AI IDE 给了它生长土壤，6A 则是社区为了约束 AI 交付而长出来的一套流程骨架。这意味着你不该把它当成某个产品的专属功能，而应该把它看成一种越来越典型的协作方式。

真正值得注意的，不是六个英文单词本身，而是它背后的交付哲学：文档先行、阶段闸门、人工兜底。

社区实践里，这套东西通常不是一句 prompt 就结束，而是要求 AI 在不同阶段留下不同文档。

比如 Align 阶段会生成 ALIGNMENT 或 CONSENSUS 类文档，把原始需求、边界、疑问和澄清点先写清；Architect 阶段出 DESIGN，把架构图、接口契约、数据流和异常处理策略写出来；Atomize 阶段出 TASK，把任务拆成可独立验证的原子块；Automate 阶段通常会结合 ACCEPTANCE 逐项实现；Assess 阶段再补 FINAL 和 TODO，把总结、遗留问题和交付确认收口。

换句话说，6A 的本质并不是“提醒 AI 多想想”，而是强制它留下每一步的中间证据。

这类变化最容易被忽略的地方在于，它看起来像流程变重了，实际是在给返工降成本。

很多人现在对 AI 编程的误解，是把“出代码快”当成核心指标。可一旦任务稍微复杂一点，真正拖垮效率的常常不是写得慢，而是写得太早。需求没对齐就写，后面就得返工；方案没定就写，后面就得重构；任务没拆清就写，后面就会上下文混乱、测试缺失、文档不同步。

6A 把这些“本来应该在写之前暴露的问题”尽量提前暴露，这才是它的实用价值。

我更在意的其实不是 Align，也不是 Automate，而是中间那两个不太讨喜的步骤：Atomize 和 Approve。

因为这两个步骤最像真正的工程现实。

Atomize 逼着你把任务拆成可独立执行、可独立验证的小块，要求写清输入契约、输出契约、依赖关系和验收标准；Approve 则明确要求人工检查完整性、一致性、可行性、可控性和可测性。

说白了，它不相信 AI 会天然自觉，也不假设“只要模型够强就能自动守规矩”。这种不信任感，我觉得反而是成熟信号。

所以，它影响的不是谁？

不是那种偶尔让 AI 生成一个小脚本、补一个函数、写几条 SQL 的轻度用户。对这种场景来说，6A 确实可能显得重，甚至有点形式主义。你为一个十分钟的小修补去写一堆对齐文档，投入产出比不一定好。

它真正影响的，是已经碰到“AI 一写大活就开始发散”的人。尤其是多模块任务、已有代码库改造、需要测试和文档同步的项目。

因为这些场景里，AI 最大的风险从来不是不会写，而是在没有共识和边界的情况下，看起来写得很顺。这也是为什么社区规则仓库会强调，6A 适合把 AI 编程从“随手试试”提升到“可复用、可约束、可持续迭代”的工作方式。

我对 6A 的判断是：它未必会成为未来所有 AI IDE 的统一标准名词，但它代表的那种方向，大概率会留下来。

这个方向就是：AI 编程的竞争，正在从“谁更会生成代码”转向“谁更能被纳入工程流程”。

以后真正有价值的，不一定是让模型一次把答案写完，而是让它按阶段交付、按文档留痕、按验收标准收敛。名字可以叫 6A，也可以叫别的，但“直接开写”这件事，本身正在失去正当性。

所以如果你问我，6A 值不值得学？

我的答案不是“把这六步背下来”，而是先看你是不是已经被返工折腾过。只要你用 AI 写过稍复杂一点的任务，大概率都遇到过：方向不对、上下文丢失、测试忘写、文档不同步、做完才发现边界错了。

到了这个阶段，你真正缺的往往不是更强的 prompt，而是一套能让 AI 别那么早乱跑的流程约束。

这也是为什么我觉得 6A 值得单独写一篇。

它不是一个新鲜术语，而是在提醒我们：AI 编程真正难的，已经不只是“生成”，而是“交付”。