我现在基本不看 agent 写的代码，这是我的做法和代价

gpt6-Astra 发布快 1 个月了，第一时间烧了 50 亿 token。夜色渐黑，借此机会和大家谈谈近段时间高强度 AI coding 的感受。我现在基本不看 agent 写的代码，这是我的做法和代价。

相较于之前的模型，gpt6-Astra 体感上差异不大。主要还是像网上说的一样，对 3D 建模和 computer use 的提升确实很多。但对于一个干后端的人来说，这些“智力”上的升级没有带来多少质变。6 代模型发布后，不管是 6sol、6luna，还是 6.1sol，我都没感觉任务完成有多大本质区别：该做的还是能做出来，返工的次数也没见明显减少，反而因为模型更聪明了，可能更会“防御性编程”，笑 :)。更让我诟病的是 OpenAI 的前端审美风格，爱写小字，爱啰嗦，爱用意义不明的蓝绿色，一直没有改善，写出来的文字也晦涩难懂。

我为什么不看代码了

认真地说，最近 agent 写的代码，我基本很少用肉眼审。一部分原因是真的看不懂（C#、Elixir、TS，最近的项目很少有机会写 Java），另一部分是没有时间读。试想一下，AI 一个小时完成 3k 行 diff，不含注释，缩进也没有，你的 review 速度真的赶得上 agent 的产出速度吗？

我目前的做法一般是：先用强模型的 low 模式头脑风暴，得出一份完整的任务书，需求、验收标准、边界全部限定好，可以是一个 issue，也可以是一个持久化的 md 文档。然后交给一个 agent 自动化工作流完成所有的编码，我只负责合并 PR 和视觉上的验收。诚然，这可能是一个彻彻底底的黑盒，但对于快速迭代的产品，这已经是平衡代码质量与快速产出的一个相对优雅的解法。人只负责需求的拆解和最后的验收，剩下交给 agent 自动完成。

我搭的这套自动化

为了实现这个 agent 自动化，我借鉴了 OpenAI 的做法。他们做了一个叫 Symphony 的自动化框架，从 GitHub 的 issue 里拉取真实需求，由 Codex 自动完成。我在它的基础上加入了 review 机制：交给一个 coder agent 去完成，最后由 reviewer agent 验收，两者可以通信。在这个框架下，CI 的编排非常必要。

同时，coder 和 reviewer 选哪个模型也非常讲究。如果用强模型 review 弱模型，可能会“反复找茬，浪费 token，增加返工”；如果用弱模型 review 强模型，则可能有 review 过松的风险。EvoMap 的做法是第二种，如果任务非常难，可能会用两个强模型来完成。最好用不同厂商的模型，避免出现自我偏袒。

黑盒里必须有的东西

在这个黑盒下的编码，自动化测试、CI 检查，包括整套 harness 的部署都显得尤为重要。对于一个长期的工程，怎么保证大模型不发散，人能对基本架构进行编排，对大方向有很好的控制？大模型的底层决定了它只能用概率的方式发散思考，每一个决策都形成一个大的决策树。如何让这棵决策树朝最终目标收束，是当下很值得思考的问题。Agent 驾驭代码，人驾驭 Agent。如果有一天 agent 朝着人不希望的方向发散，之前留下的决策记录就显得非常重要。关键决策必须存档，这也是整套 harness 工程最重要的部分。

为什么头脑风暴用强模型的 low 模式

主要原因不是为了减少成本，而是对速度和质量的综合考虑。使用更高的 effort 不会让模型更聪明，本质是让模型分配更多 token 预算。而头脑风暴这个过程不需要模型反复思考，反而是快速而持续的思维跳跃更重要。试想一下，如果模型进入了“雷霆大思考”，你脑中的想法不能连续输出，反而会导致考虑不清，最终产出低质量的发散代码。

给后来者的一点想法

如果可以比喻的话，第三次工业革命带来了 ChatGPT。在这个时代，元思维非常重要。如果说“学得慢了就可以不用学了”是警钟长鸣，那么对大模型的认识，也就是它能完成哪些工作、哪些工作不能独立完成，将成为人与人之间很大的差异点。

如果把古法编程比作华山派气宗，AI coding 比作剑宗，那对于十年二十年的老资历气宗，大模型简直如虎添翼，天下任我行。但这是否说明，小资历的人应该从头啃底层，用古法编程打好自己的底座？最理想的做法当然是这样，如果你有无限的时间和精力，大可以这么做。但对于浮躁、焦虑，被学校、就业、恋爱压得喘不过气的小登来说，学好用工具比学更底层的东西，直观收益更快。元思维的价值大于编程语言带来的杠杆作用，与其成为半吊子气宗，不如快速兑现收益，得到适当的情绪价值，再用这股劲完成向宗门宗师的转变。

这本是杂谈，也是笔者最近的一些思考，如果思路不够清晰，或者哪些和事实有偏差，还请见谅。