# 写代码一文不值的时代，什么才值钱？

LLMS 索引： [llms.txt](/llms.txt)

---

最近一周没怎么写文章，因为忙着用 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 动嘴输入**](https://mp.weixin.qq.com/s?__biz=MzU5ODAyNTM5Ng==&mid=2247490982&idx=1&sn=789e9d1fdb438574b5014b6187b8a087&scene=21#wechat_redirect)，体验非常好，就像指挥官一样。

![Codex 并行会话操作界面](featured.webp)

但速度只是体验层面的改善，真正让我刮目相看的是 **靠谱程度**。在合理的指挥和提示下，它已经能扮演一个称职的中级程序员了。具体来说，以 Code Review 为例，找 Bug 大概 20 个里面只有一个需要我来人工纠正，粗略估计整体准确率在 95% 左右。

![Codex 审查问题示例](codex-review-accuracy.webp)

不过关于模型能力，老冯从来都不看什么榜单，只相信它们在自己场景上的真实效果。我有一个简单粗暴的评估方法：**交叉扫描**。

[**Pigsty 4.0 发布前**](https://mp.weixin.qq.com/s?__biz=MzU5ODAyNTM5Ng==&mid=2247491076&idx=1&sn=812a90effed5dcc46c9930c953478fad&scene=21#wechat_redirect)，我曾经用 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 代码。

![pig 命令行项目进展](pig-cli-growth.webp)

当然还有其他很多项目都在并行推进，但其中 Pigsty 是最有代表性的一个。

在改进的全程中，我只在开始时进行了几次头脑风暴，给出了项目的整体改进思路。在系统自动循环运转了四天之后，我来进行验收并做了一个冒烟测试，接着将生成的能力提取出来。最后在几轮优化之后，项目就完工了。

整个过程我只是“出嘴”确认几个关键问题，然后不断机械地循环执行以下四轮流程：CreateStory -> DevStory -> CodeReview -> FixThis

![Story 开发与审查循环](story-dev-review-fix-loop.webp)

就这样把活儿给干出来了。**在这个过程中，我没有写过一行具体的代码**。

------

## 当写代码一文不值，什么才值钱？

很多人 Vibe Coding 都是在写 Demo，糊出一个看起来能用的东西很简单，糊出一个 **质量可靠** 的东西相当难。

我的看法是：当“写代码”本身不再稀缺，剩下最有价值的东西只有两样：

1. **你能提出有品位的设计。**
2. **你能进行可靠的工程验收。**

我在实践中总结了两个核心方法。

### 设计：中心法则：从意图到代码的信息级联

这个名字借自分子生物学的中心法则：**DNA -> RNA -> 蛋白质**。在软件工程中，对应关系是：

![从意图到代码的信息级联](central-dogma-software.webp)

具体的工作流是 **BMAD 方法论**，当然实践中我就简化为 BMA 三个缩写了：

1. **Brainstorm**：头脑风暴，讨论要做什么。
2. **Map**：根据头脑风暴产出 PRD，拆解为 EPIC 和 Story。
3. **Act**：循环处理这些 EPIC 和 Story。

![BMAD 工作流示意](bmad-workflow.webp)

这套流程的关键在于：**你不能凭感觉写代码**。不能这里糊一锤子、那里敲一下。你得先有总体纲领（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 替代中级程序员，已经没有任何悬念了。**

[**AI时代，新程序员将何去何从？**](https://mp.weixin.qq.com/s?__biz=MzU5ODAyNTM5Ng==&mid=2247491053&idx=1&sn=e2be2db6fd4045201565d5acb0567b3a&scene=21#wechat_redirect)

半年前的状态是替代初级程序员毫无悬念。到了 2026 年当下，Codex 这个质量水平，批量规模化替代中级程序员已经是现实，至于高级程序员，我感觉也是时间问题。以后可能不会再有“程序员”这个职业，只有“**软件工程师**”。区别在于：

程序员（码农）工作的核心是写代码。而 **软件工程师** 是用工程方法解决“写什么代码、为什么写、怎么验收”的工程问题。

软件行业作为“高科技行业”的时代可能要结束了。我们正处于它向传统行业回归的进程中。互联网/软件行业可能有超过一半的技术岗位会被直接消灭，而溢出的程序员会涌入各行各业，把技术能力扩散出去，进而推高全行业的失业率，也就是这两年的事情。

[AI撕掉了软件的皮](https://mp.weixin.qq.com/s?__biz=MzU5ODAyNTM5Ng==&mid=2247491134&idx=1&sn=abc9089d16faae9215d653aa3633e0d9&scene=21#wechat_redirect)

[软件世界大熔断：当中间层全被压扁](https://mp.weixin.qq.com/s?__biz=MzU5ODAyNTM5Ng==&mid=2247491044&idx=1&sn=731cb7681895f7572b2ed1a0a6a1c161&scene=21#wechat_redirect)

### 谁受益，谁受损？

以前软件行业是“纺锤型”结构：顶尖专家少，中间骨干多，底层新人多。现在 AI 的冲击主要集中在中间层。在大厂里，毕业三五年、P6/P7 这个群体受到的冲击最大。**而资深专家进入一个超级红利期**，这个窗口至少还有两年。再往后说不定超级智能都出来了，现在讨论也没太大意义。

反直觉的是：**聪明的应届生反而大有机会**：工资低、学习快、对旧工具没有路径依赖。我推断，未来一两年软件工程的最佳实践会收敛为 **10 人以下的精炼团队**：1-3 个核心专家，配 6-7 个实习生，人均配备 2-3 个 AI Agent 辅助出活。

如果是顶尖专家，一个人也能通过指挥一堆 Agent 干出了不起的项目，“One Person Company” 会大量涌现。我自己一个人搞出了 Pigsty 这么大的项目，没有 AI 是不可能的。

![One Person Company](featured.webp)

------

老冯没兴趣也没时间到处鼓吹 Vibe Coding，俗话说，闷声大发财是最好的。不过今天正好有空，就口述篇文章聊一聊，把一些实践和判断分享出来。

同行朋友们，时代真的变了，早做打算吧。