最近一周没怎么写文章，因为忙着用 OpenAI 刚发布的 Codex 3 xHigh 糊东西。趁着双倍额度，我把 200 刀的配额几乎用完了，让它在 Pigsty 的十几个子项目上并行出活：主项目、中英文文档、博客、包管理器、扩展目录、基础设施包、RPM/DEB 构建 Spec、pg_exporter 监控采集器……
目前 Codex 已经成了我的主力工具，Claude Code 作为备用，GLM 作为额度打爆之后的替补。正好今天有点时间，聊聊感想。直接口述，我就不用 AI 生成润色了，比较随意。
Codex 5.3：到底能不能打？#
两个字：能打。之前我不喜欢用 Codex 的一个主要原因就是太磨叽，一个简单的活也要拖很长时间。到了 5.3 版本，不知道是用了 Cerebras 大缓存 SRAM 推理芯片，还是别的技术改进，体感上快了不少。而且这个客户端做得挺不错，我同时开 8 - 10 个左右的 Session，配合 Typelesss 动嘴输入，体验非常好，就像指挥官一样。
但速度只是体验层面的改善，真正让我刮目相看的是靠谱程度。在合理的指挥和提示下，它已经能扮演一个称职的中级程序员了。具体来说，以 Code Review 为例，找 Bug 大概 20 个里面只有一个需要我来人工纠正，粗略估计整体准确率在 95% 左右。
不过关于模型能力，老冯从来都不看什么榜单，只相信它们在自己场景上的真实效果。我有一个简单粗暴的评估方法：交叉扫描。
Pigsty 4.0 发布前，我曾经用 Claude Code 对代码仓库进行了连续两三周的密集扫描：逐日扫描、逐个修复、标记误报，直到它再也扫不出新问题。然后 Opus 4.5 和 Codex 5.3 同时发布，我让两个模型再次扫描同一个仓库：
结果 Codex 5.3 xHigh 又给我揪出了二三十个问题。而 Claude Opus 4.6：表现平平，没能发现更多问题，这就是一种很直观的模型能力对比。
不过 Claude 也有自己的长处，Claude 的优势在于写码速度快、沟通风格直接不谄媚；但在“代码质量”这件事上，特别是 Code Review，Codex 5.3 xHigh 有明显优势。
我用 Codex / Claude 做什么？#
现在有很不少同行以每天烧了多少 Token 为荣，有一种攀比的风气，老冯是懒得玩这种数豆子的无聊游戏。反正我每周基本上都能把 Claude Code / Codex 的额度烧光，主要都用在了 Pigsty 里面的几个项目上。但非要一个量化指标的话，大概每天平均产出在四千行代码左右，基本上达到了正常自己写几十倍的速度，我的体感大约在 20 倍速左右。
最近我在主要折腾的是 pig 命令行工具，我准备把它作为一个 Agent Native CLI 的样板来实现：包装 PostgreSQL，Patroni，Pgbouncer，Pgbackrest 管理能力，主动为 Agent 提供上下文与能力地图，以 yaml/json 格式化输出。然后也加了很多功能，大概 5 天时间，新增了四万行左右的 Go 代码。
当然还有其他很多项目都在并行推进，但其中 Pigsty 是最有代表性的一个。
在改进的全程中，我只在开始时进行了几次头脑风暴，给出了项目的整体改进思路。在系统自动循环运转了四天之后，我来进行验收并做了一个冒烟测试，接着将生成的能力提取出来。最后在几轮优化之后，项目就完工了。
整个过程我只是“出嘴”确认几个关键问题，然后不断机械地循环执行以下四轮流程：CreateStory -> DevStory -> CodeReview -> FixThis
就这样把活儿给干出来了。在这个过程中，我没有写过一行具体的代码。
当写代码一文不值，什么才值钱？#
很多人 Vibe Coding 都是在写 Demo，糊出一个看起来能用的东西很简单，糊出一个质量可靠的东西相当难。
我的看法是：当“写代码”本身不再稀缺，剩下最有价值的东西只有两样：
- 你能提出有品位的设计。
- 你能进行可靠的工程验收。
我在实践中总结了两个核心方法。
设计：中心法则：从意图到代码的信息级联#
这个名字借自分子生物学的中心法则：DNA -> RNA -> 蛋白质。在软件工程中，对应关系是：
具体的工作流是 BMAD 方法论，当然实践中我就简化为 BMA 三个缩写了：
- Brainstorm：头脑风暴，讨论要做什么。
- Map：根据头脑风暴产出 PRD，拆解为 EPIC 和 Story。
- Act：循环处理这些 EPIC 和 Story。
这套流程的关键在于：你不能凭感觉写代码。不能这里糊一锤子、那里敲一下。你得先有总体纲领（DNA），然后再出设计规格（RNA），再由规格生成代码（蛋白质）。这样产出的代码是可追溯的、可验证的：每一行代码都能回溯到它对应的 Story，每个 Story 都能回溯到 PRD，PRD 能回溯到最初的意图。
没有这条信息链，就不是在做工程，而是在做手工艺。每次用小锤子东敲敲西敲敲，做点小型手工软件也没啥问题，但是复杂度一旦上来就完蛋了。
验收：Agent 对抗：让 AI 互相找茬#
只用一个 Agent 来开发加 Code Review，质量是不够的。最佳实践是让不同的 Agent 各司其职，彼此制衡。
我的做法是：Claude Code 做原型与粗活，负责创建和开发 Story，快速出初版代码。Codex 5.3 做 Code Review 审查未提交的修改，逐条提出 P0/P1/P2 级别的问题。在这个过程中，需要人类的判断力介入，判断 Codex 哪些问题要修，哪些是误报。
- 真实问题：确认是 Bug，直接让它修。
- 误判：你认为这是 Feature 而非 Bug，或者错误理解了你的设计意图，就让它写清楚注释，更新设计文档，防止以后重复误报。
Codex Review 完成之后，就进入来回打铁的环节。让 Claude 来 Review Codex 的修改，评价它的 Review 结果。然后不断反复，如有分歧，继续对抗，直到达成共识。
本质上这是管理术中的制衡机制。假设你是一个不懂技术的领导，如何确保技术团队不偷懒、不犯傻？一个简单的办法：让他们互相找茬。经过充分辩论后达成的共识，大概率是靠谱的。
把这个逻辑套到 AI Agent 上同样成立：两个不同架构、不同训练数据的模型，犯同一个错误的概率远低于单个模型。这不是什么高深理论，就是朴素的交叉验证。
实际操作中，一个 Story 我一般会跑 3 到 8 轮 Review/修复循环。如果几轮下来两个 Agent 还是无法达成共识，我就人工介入仲裁。
当然，最后还是要有一个人工验收的环节。你可以事先写好测试用例，定义好边界。如果你很懒的话，另一个取巧的办法就是让 Agent 自己去拉 Docker 设计一个测试环境并设计各种测试用例，然后反复测试。这里面其实就是一个朴素的技巧：你让它来回重复测。每次测完换个角度、换一个测试的焦点，有时候它就能发现一些问题，大力出奇迹。当然最后像 Pigsty，我还是得自己来做冒烟测试。但是前面的很多轮拉扯，基本上都已经把各种问题都提前发现并处理好了。
当然，其实还有很多软件工程的小技巧。比如说，你要及时地去处理技术债：做几个 EPIC 就定期重构，做一次整体的瘦身与代码优化。把降低复杂度当作一个首要的设计与实现目标，及时移除死代码；充分利用级联文档和注释来提高理解的精准程度。这些就不详细展开介绍了。
行业会怎么变？#
上面两个方法的共同指向是：质量控制的核心已经从“写代码”转移到了“设计 + 验收”。既然写代码这件事可以被 Agent 批量完成，行业格局也会跟着变。
我的判断是：AI 替代中级程序员，已经没有任何悬念了。
半年前的状态是替代初级程序员毫无悬念。到了 2026 年当下，Codex 这个质量水平，批量规模化替代中级程序员已经是现实，至于高级程序员，我感觉也是时间问题。以后可能不会再有“程序员”这个职业，只有“软件工程师”。区别在于：
程序员（码农）工作的核心是写代码。而 软件工程师是用工程方法解决“写什么代码、为什么写、怎么验收”的工程问题。
软件行业作为“高科技行业”的时代可能要结束了。我们正处于它向传统行业回归的进程中。互联网/软件行业可能有超过一半的技术岗位会被直接消灭，而溢出的程序员会涌入各行各业，把技术能力扩散出去，进而推高全行业的失业率，也就是这两年的事情。
谁受益，谁受损？#
以前软件行业是“纺锤型”结构：顶尖专家少，中间骨干多，底层新人多。现在 AI 的冲击主要集中在中间层。在大厂里，毕业三五年、P6/P7 这个群体受到的冲击最大。而资深专家进入一个超级红利期，这个窗口至少还有两年。再往后说不定超级智能都出来了，现在讨论也没太大意义。
反直觉的是：聪明的应届生反而大有机会：工资低、学习快、对旧工具没有路径依赖。我推断，未来一两年软件工程的最佳实践会收敛为 10 人以下的精炼团队：1-3 个核心专家，配 6-7 个实习生，人均配备 2-3 个 AI Agent 辅助出活。
如果是顶尖专家，一个人也能通过指挥一堆 Agent 干出了不起的项目，“One Person Company” 会大量涌现。我自己一个人搞出了 Pigsty 这么大的项目，没有 AI 是不可能的。
老冯没兴趣也没时间到处鼓吹 Vibe Coding，俗话说，闷声大发财是最好的。不过今天正好有空，就口述篇文章聊一聊，把一些实践和判断分享出来。
同行朋友们，时代真的变了，早做打算吧。
