AI 写代码已经很快了。你跟 Cursor 说"做个登录页面"，它十秒甩给你。你跟 Claude 说"这个函数有 bug"，它一眼扫出来。
但写一个完整的项目不是这样的。
真实的过程是：有个模糊的想法→跟人聊清楚到底要做什么→画架构→拆模块→写代码→审查→改→审查→改→验收→合并。AI 只帮了"写代码"那一步。前面想不清楚会偏，后面审不到位会漏。
这就是我做 Forge 的原因。
瓶颈不在写，在写之前和之后
我用 AI 编程快一年了。从 Cursor 到 Cline 到 Codex，最大的感受不是"AI 写得好快"，是"我怎么知道它写对了"。
不是语法对——语法它不会错。是架构对。是模块边界划对了吗，是数据流有没有断头路，是异常路径被覆盖了吗，是这段代码三个月后改起来会不会炸。
这些问题不靠人审是发现不了的。而我自己审有个问题：我参与了设计，我看自己的设计会有盲区。就像写完作文自己检查一遍——你以为检查了，其实是在确认自己没错。
所以我需要一个不参与设计的人来审。在 AI 编程的环境里，这个"人"只能是另一个 Agent——上下文干净、只拿设计文档、独立审判。
Superpowers 给了我启发。它是 obra 做的一套 Agent 技能——比如 brainstorming（动手前先确认你真正要什么）、writing plans（先写计划再执行）。每个都很好用，但它们各自独立。
用了几次我发现一个问题：没人告诉我工序。
brainstorming 之后该干什么？写完架构文档谁来审？审出问题改完怎么确认没引入新问题？审到什么程度算够？这些决策全压在我身上。
Superpowers 是一盒好工具。但它没给我流水线。
把锻造分成四个阶段
锻造（Forge）做的事情很简单：把"有想法"到"代码落地"拆成四个阶段，每个阶段有明确的做什么、谁来做、做完怎么判断通过。
阶段一：需求澄清。 不是说"我要做个天气查询"就动手。是追着问：谁用？什么场景？最简版要哪三个功能？去掉第三个会怎样？拿竞品的功能清单对照查漏。
阶段二：架构设计。 分层结构、模块划分、数据流、接口定义。用具体数据样例跑一遍端到端。设计完不是直接写代码——先审。
阶段三：审查。 这是整条管线最核心的部分。
审查分两层。精审用两把刀：架构裂隙分析（从数据流、失败模式、状态切换、分层检查、运维五个切口捅进去找裂缝）和六维度分析（上下文工程、记忆系统、工具调用、可靠性、成本控制、评估）。逐要点三轮对撞——第一轮对不对、第二轮质疑结论、第三轮能不能更好。
最后有一个收敛判据：必须改的项全修复、建议改的项不再新增、没有新的严重担忧。 这个判据的价值不在于"什么时候结束"，在于你不需要纠结"审够了吗"——条件满足就过，不满足继续。
阶段四：实现和验收。 审查过了，丢给 AI 写。写完代码检查，合并。中间有小审（模块级）和中审大审（系统级）卡着。
四个阶段，每一步都有状态追踪——forge-state.json 记录你在哪个阶段、审了几轮、改了几次。断了能续，不怕"昨天聊到哪了"。
三个设计决策
回头看，有三个决策做对了。每个决策背后都有一个具体的场景——是踩了坑才确定的。
审查隔离：裁判不能是运动员
最开始我没做隔离。同一个 Agent 先设计架构，然后切到"审查模式"审自己刚写的东西。结果永远是"整体合理，几处小建议"。不是它偷懒——是 LLM 的统计本性决定的。它的上下文里全是自己刚输出的设计推理，这些推理在概率分布里占据了巨大权重。让它切换角色去批判，它做不到。
后来我把审查 Agent 拆成子进程——独立启动，不继承任何主对话上下文。它拿到的只是一个 brief 文件：项目描述、架构文档路径、审查类型、审查标准。它不知道设计过程有过哪些争论、哪些方案被否决过、为什么选了 A 不选 B。它能看到的只有最终产出的设计文档。
第一次跑就发现了主对话里审了三轮都没发现的问题——模块间接口签名不兼容，缺少 return type 声明。不是审查 Agent 更聪明，是它没被带偏。
这个设计有一个额外的好处：审查 Agent 的 SKILL.md 和设计 Agent 的 SKILL.md 可以独立维护。审查标准升级不会影响设计流程，反过来也一样。
收敛判据：什么时候算审够了
没有判据之前，审查是薛定谔的。审一轮改一轮，第二轮发现新问题，第三轮说"前三轮提的建议都很合理"——到底什么时候停？
我试过几种方式。让 Agent 自己判断"是否充分"——它永远说不充分，因为说有遗漏比说没问题安全。设固定轮数——有些项目一轮就够了，有些三轮还不够，固定数要么浪费要么不够。
最后的方案是一个硬判据：必须改的项全部修复、建议改的项数量不再增长、没有新增的严重担忧。 三条同时满足→审查结束。任何一个不满足→继续。
这个判据的核心不是"完美"，是"收敛"。漏洞不可能全找到，但审查的边际收益在递减。当建议改的项不再新增，说明审查已经在做无用功了——它在确认自己没漏，而不是真的发现了新东西。这时候停下来，不丢人。
为了防止无限循环，设了一个兜底：五轮上限。到了五轮没收敛，停下来，人介入。但实战中三轮没收敛的情况我还没遇到过。
状态追踪：让 Agent 知道自己在哪
一个容易被忽略的问题：子 Agent 每次启动都是全新的。它没有"上次我被驳回是因为接口签名不兼容"这个记忆。如果你不告诉它上下文，它就会用和第一次完全一样的方式工作——然后被同样的原因再次驳回。
所以我做了两件事。
第一，用 forge-state.json 记录所有运行时状态：当前阶段、当前模块、任务序号、失败次数、被锁定的必须改数量、审查轮数、上次被驳回的原因。一个结构化的 JSON，不靠自然语言，不靠 LLM 理解。
第二，每次派发子 Agent 前用一个确定性脚本把状态注入到 brief 里——不是让 LLM 写状态栏，是脚本读 JSON 直接生成。implementer 看到"连续失败 2/3，上次打回原因：模块间接口签名不兼容"，它就知道这次要重点修复接口问题。product-reviewer 看到"复审模式：上一轮 must_fix=3 项未通过"，它就知道这次要重点复核那三项。
状态追踪的价值不在"记一下"，在传递给下一个 Agent。没有状态传递，流水线就是断的——每个 Agent 都在盲打。
不是一个产品，是一套方法
Forge 不是 pip install 之后就能用的工具。它是一个 Codex 技能插件——你把 skills 文件夹放进项目，对 Codex 说"锻造 天气Agent"，流程就跑起来了。
这也是它现在的局限：绑定了 Codex，没有独立 CLI。但它的核心是一套方法论——阶段定义、审查标准、收敛判据、状态结构——这些换个载体照样能用。
想听听你的直觉反应
我从五月份开始用这个流程跟 AI 协作，从 memory-stability 到项目分析到哨兵项目，确实比"直接让 AI 写"稳了。
但我是自己闷头搞的。我不知道这东西对别人有没有用。
- 你用 AI 编程的时候，会卡在设计不清和审查不到位上吗？
- 工序的问题是你也头疼的，还是你已经有自己的办法了？
- 这种"方法论型开源项目"你愿意试吗？
挺想听听外面的人怎么说。好话坏话都行。
