在AI编码工具里加一个“反思环节”，到底能多大程度改善生成代码的质量？这个问题，我用了将近一个月的时间来回答。

先说结论：我把反思机制嵌进 OpenCode 的 OpenSpec 工作流之后，DeepSeek-V4-pro 在该环境下的表现，已经拉到了跟 Claude Opus 4.6 差不多的水平。代价仅仅是多花一点审阅时间和一些令牌消耗——这买卖很值。

打开网易新闻 查看精彩图片

我接触 AI 编码有一阵子了，相比直接用 Claude Code，我更愿意基于 SDD（规范驱动开发）的理念，用 OpenCode 和 OpenSpec 搭建自己的编程环境。借助 OpenSpec 的“探索→提议→实施→验证→归档”这个循环，我们终于可以让大模型去处理比较复杂的项目开发了。

但麻烦也跟来了：甭管我用的是 GPT 5.5 还是最新的 DeepSeek-V4-pro，哪怕已经套上了 SDD 这套流程，AI 还是会悄无声息地制造隐藏缺陷，或者堆出一堆让人不敢上线的烂代码。一开始我想到的补救办法，是在 /opsx-apply 阶段之后叫一个“审查员”子智能体出来，让它对着改动做一轮代码审查。这招有时管用，能抓住一些架构或者实现层面的问题，但整体效果有限。往往是我用着用着项目才发现不对：某个场景没覆盖，边缘情况被漏掉，或者只改了一处代码，相关联的模块却没跟着动。

后来我退后一步，重新打量整个 AI 编码流程，这才看见了真正的症结所在。我们写程序时总盯着“代码好不好”这个维度，所以很自然地会从代码层面去看问题。但所有人都忽略了一个更上游的东西——OpenSpec 生成的提议文件，质量到底过不过关？我们常常是聊完需求、生成提议文件，就让 AI 撸起袖子直接写代码了。输入侧埋下的 bug，就是这样被带进去的；等出了问题，我们又转头去责怪模型。

你回想一下，在纯人工编码的年代，产品经理把需求文档交过来之后，我们动手写代码前有一个雷打不动的步骤：需求评审。需求文档或者设计文档里的每一个疑点没搞明白，我们绝不会去碰键盘。那为什么到了 AI 编码时代，这个步骤就被遗忘了呢？恰好，今天我要做的，就是把这个环节重新塞回 OpenSpec 的工作流里：加上需求评审这个步骤，再看它能把 AI 生成的代码推向什么水准。

SDD 这套东西并不神秘。你要是熟悉多智能体系统的设计模式，一下子就能认出来——所谓 SDD，本质上就是“计划-执行”模式。一个智能体把用户的任务拆成一连串步骤写进计划文件，另一个智能体再照着这份计划去落地执行。这样一来，智能体系统就能处理比单次对话复杂得多的任务了。