AI Coding 时代，真正值钱的已经不是写代码，而是定义什么叫好

过去两天，我连续写了三篇 Eval。

第一篇，我讲什么是 Eval。

我用了一个很简单的比喻：

Eval，就是给 AI 考试。

第二篇，我把 Eval 装进了 Codex。

我开始让 Codex 不只是写代码，而是先跑 Baseline，修改以后再 Eval，出现 Regression 就继续修。

第三篇，我真的找了一个 AI 工作流，把这套东西完整跑了一遍。

结果很有意思。

一个语义素材检索模块，Pass Rate 从 79.17% 提升到了 91.67%。

没有出现新的 Regression。

看起来已经是一轮非常成功的优化。

但最后的 Release Decision 依然是：

FAIL。

因为 High-Risk Pass Rate 还是 80%，还有一个 Critical Failure 没解决。

那一刻我突然意识到：

我这几天一直在研究 Eval，但 Eval 背后真正重要的问题，其实根本不是“怎么测试 AI”。

而是另外一个更大的问题：

当 Codex 已经越来越会写代码以后，人到底应该负责什么？

以前我会觉得，一个 Builder 最核心的能力是：

我能不能把这个东西做出来？

但现在，这个问题正在快速变便宜。

真正开始变贵的是：

你知不知道什么东西值得做？以及，你能不能定义什么才叫做好？

1. Build 正在被快速商品化

过去做一个功能，大量时间花在哪里？

不是所有时间都花在“思考”上。

很多时间其实花在 Implementation。

查文档。

接 API。

写样板代码。

处理状态。

Debug。

改类型。

写测试。

修一个莫名其妙的环境问题。

再部署。

这些事情当然都是工程的一部分，但它们过去占据了大量时间。

Coding Agent 正在压缩这一部分的价格。

现在一个需求足够清楚，你可以把它交给 Codex。

它自己扫描仓库，理解代码结构，找相关文件，提出方案，一次修改几十个文件，再自己运行测试、看报错、继续修改。

这不意味着 Engineering 消失了。

更准确地说：

AI Coding 正在快速压缩 Implementation 的价格。

以前，一个想法和一个真正能运行的东西之间，隔着大量实现成本。

这个成本现在正在下降。

那问题就来了：

当“怎么做”越来越便宜以后，价值会往哪里迁移？

2. 一个模糊的需求，不会因为 Codex 很强就突然变成好需求

假设一个客户对你说：

“给我做一个 AI 客服。”

如果你马上打开 Codex 开始写，我觉得这件事情从第一步就已经错了。

因为“AI 客服”根本不是需求。

它只是一个名词。

客户到底想解决什么？

是人工客服太贵？

晚上没人回复？

售前咨询太多？

重复问题太多？

还是大量线索因为回复太慢而流失？

AI 可以回答哪些问题？

哪些问题必须查数据库？

哪些动作 AI 可以直接执行？

哪些事情绝对不能让 AI 自己决定？

什么时候必须转人工？

一旦答错，最严重的后果是什么？

这些东西没有定义清楚以前，Codex 写得越快，甚至可能越危险。

因为它会非常高效地把一个模糊的方向实现出来。

AI 可以让你更快地得到答案，但如果问题本身定义错了，它只会让你更快地跑向错误方向。

所以 AI Coding 越强，我反而越来越不愿意一上来就问：

“这个东西怎么实现？”

我更愿意先问：

“我们到底在解决什么？”

3. AI Coding 最容易制造的错觉，是把“生成出来”当成“做好了”

这也是为什么 Eval 最近对我影响这么大。

AI Coding 的反馈太快了。

你说一句话。

几十秒以后页面出来了。

再说一句。

接口接上了。

再等一会。

Agent 能回复了。

Workflow 跑通了。

这种反馈很容易产生一种强烈的心理满足：

Done。

但第三篇实验给了我一个很好的反例。

79.17% → 91.67%。

如果没有事先定义 Release Gate，这个数字非常容易被讲成：

“优化成功。”

甚至可以马上截图发出来：

“使用 Eval 后准确率提升 12.5 个百分点。”

但问题是：

那个唯一的 Critical Failure 还在那里。

高风险场景没有变好。

所以 91.67% 虽然比 79.17% 好很多，却仍然没有达到“可以发布”的标准。

这让我越来越在意一个区别：

Better 和 Good Enough，不是一回事。

一个东西变好了，不代表它已经足够好。

而“足够好”的边界，不会自动从代码里长出来。

它必须有人定义。

4. 所以真正重要的问题开始变成：What does good look like?

我现在越来越喜欢在做东西之前先问一句：

What does good look like?

什么才叫好？

看起来很抽象。

其实一旦真正开始回答，它会迅速变得具体。

一个 AI Agent 的“好”，可能意味着：不仅能回答问题，还能完成业务任务；高风险错误不能超过某个范围；遇到低置信度情况必须转人工；平均响应时间不能超过用户能够接受的阈值；成本必须低到这个业务模型还能成立。

一篇内容的“好”，也不是：

“写高级一点。”

而是：

谁看？

读者现在知道什么？

我要让他看完以后多理解什么？

哪里必须有证据？

哪些句子应该让人停下来？

最后希望他关注、转发，还是去做一个具体动作？

一个产品的“好”，更不等于：

“UI 做漂亮一点。”

真正的问题是：

谁会用？

他为什么来？

哪个任务是核心任务？

哪一步最容易流失？

什么行为发生以后，我们才能说用户真的拿到了价值？

所以定义“好”，并不是写几个 KPI。

它是在给一个模糊目标建立：

方向、边界和形状。

5. Specification 可能会变成 AI Coding 时代最重要的“代码”之一

过去，代码是人告诉计算机该做什么的主要方式。

你把逻辑写得足够准确，机器就按照逻辑执行。

但当越来越多实现开始由 Agent 完成以后，人需要表达的东西正在发生变化。

你可能不再亲自决定某个函数具体怎么写。

但你必须越来越清楚地告诉 Agent：

目标是什么。

上下文是什么。

哪些约束不能违反。

什么算成功。

什么算失败。

哪些 Case 风险最高。

什么条件下可以 Release。

什么时候必须停下来问人。

也就是：

Goal、Context、Constraints、Definition of Done、Failure Cases、Eval、Release Gate。

这些东西当然不是传统意义上的代码。

但它们越来越像代码。

因为它们决定了 Agent：

往哪里走，

优化什么，

避免什么，

什么时候停。

当 AI 开始负责实现，“成功定义”的质量，就开始决定实现的上限。

所以我越来越觉得，一个很差的 AI Coding Prompt 不是“写得不够长”。

而是：

它把最重要的判断全部留给了模型。

“帮我做个 CRM。”

“帮我把 Agent 做好。”

“帮我优化一下。”

这些 Prompt 最大的问题不是短。

而是没有 Definition of Good。

6. 当 Generation 越来越便宜，Selection 就会越来越贵

以前我们经常把“创造”理解成一种稀缺能力。

因为创造一个东西很贵。

写一篇文章很慢。

设计一个页面很慢。

做十个产品方案更慢。

现在情况正在反过来。

AI 可以给你：

10 个标题。

100 个 UI 方案。

20 套产品架构。

50 个 Logo。

10 个功能实现。

生成能力越来越接近无限。

但无限生成并没有自动带来无限价值。

它只是把问题从：

“我想不出来。”

变成了：

“我到底应该选哪个？”

这就是为什么 Judgment 会越来越贵。

哪个方案只是看起来高级？

哪个方案真的解决用户问题？

哪个功能值得做？

哪个功能应该砍掉？

什么时候应该继续优化？

什么时候应该直接放弃？

什么时候 91% 已经足够？

什么时候 99% 仍然不够？

这些都是 Selection Problem。

当生成成本趋近于零，选择什么、不选择什么，会变得越来越值钱。

这也是我现在理解的 Taste。

Taste 不只是“审美好”。

真正的 Taste 是：

你看过很多好东西以后，知道差距在哪里。

你经历过很多失败以后，知道什么问题值得警惕。

你对用户理解足够深以后，知道一个看起来很聪明的方案为什么没人会用。

AI 能不断给你 Option。

但最后总得有人负责：

Selection。

7. 所以人的角色不是消失，而是在上移

我不太认同一种很简单的叙事：

“AI 会写代码，所以程序员以后没用了。”

这把问题看得太扁平。

更可能发生的变化是：

人的位置上移。

过去大量时间是：

Write → Debug → Test → Implement。

未来越来越可能变成：

人先定义：

Goal、Context、Constraints、Ground Truth、Risk、Good。

Agent 去：

Build、Test、Eval、Analyze、Fix、Re-Eval。

最后人重新回来：

Review、Decide、Take Responsibility。

这不是人退出工程。

而是人越来越多地负责：

质量系统。

你不一定亲手完成所有步骤。

但你必须决定：

系统为什么存在。

它什么情况下算成功。

什么错误可以接受。

什么错误绝对不能接受。

什么时候可以上线。

谁为最终结果负责。

AI 可以接管越来越多执行。

但 Responsibility 不会因为模型变强就自动消失。

8. 这也不意味着“不需要懂代码”

恰恰相反。

我觉得 Coding Literacy 依然会非常重要。

只是它的价值，不一定再主要体现在：

“我一天能手写多少行代码。”

你需要懂代码，是因为你需要理解系统。

为什么这个 Agent 慢？

为什么 RAG 召回错？

为什么 API 明明成功了，业务却失败？

为什么工具调用进入死循环？

为什么数据库状态不一致？

为什么换了一个模型成本突然翻了几倍？

为什么 Codex 给出的架构短期可以跑，长期却很难维护？

如果你连系统运行的基本逻辑都不理解，很难真正判断 AI 给你的方案到底好不好。

所以我更看好的一类人，不是两个极端：

不是只会手写代码、拒绝 AI。

也不是完全不懂技术，只会写 Prompt。

而是：

懂技术，懂业务，会判断，又会用 AI 放大自己。

这也是我越来越理解 FDE / AI Builder 这类角色价值的原因。

他们真正做的，并不是“会调用几个模型”。

而是在真实业务里把：

问题 → 系统 → 标准 → 结果

连起来。

9. 我自己给 Codex 下任务的方式已经开始改变

以前我很容易直接说：

“帮我把这个东西做出来。”

现在我开始强迫自己先回答几个问题。

为什么做？

给谁做？

最终希望改变什么？

哪些限制不能突破？

什么结果代表成功？

什么错误不能接受？

怎么验证？

什么条件下才能算 Done？

这些东西确定以后，我反而开始减少自己对实现细节的控制。

具体哪个函数怎么写。

目录怎么拆。

某段逻辑如何重构。

很多时候可以让 Codex 自己判断。

于是出现了一个很有意思的变化：

我减少了对“怎么写”的控制，反而增加了对“什么叫对”的控制。

我越来越觉得，这可能才是使用 Coding Agent 真正成熟的方向。

不是你每一步都遥控 AI。

而是：

你给它一个清楚的目标空间。

给它足够上下文。

给它明确边界。

给它可以验证的标准。

然后让它自己寻找实现路径。

10. AI Coding 时代真正稀缺的能力，可能会收敛到四件事

如果一定让我把这些东西压缩下来，我会保留四个词：

Problem Framing。

你能不能找到真正的问题，而不是拿到一句需求就开始做？

Context。

你是否真的理解业务、用户、数据和约束？

Judgment。

面对十个都“可以”的方案，你能不能判断哪个值得继续？

Evaluation。

你能不能证明它真的有效，并且在证据不足的时候敢说：

不上线。

我甚至会把 AI Coding 的杠杆粗暴地理解成：

AI Coding Leverage ≈ Problem Quality × Context Quality × Judgment × Evaluation × Agent Capability

这当然不是数学公式。

它只是提醒我：

Agent Capability 会越来越普及。

今天 Codex 强一点。

明天 Claude Code 强一点。

后天又会有更强的 Agent。

工具能力最终会越来越接近。

但前面几项，不会因为你订阅了一个更强的模型就自动出现。

11. Build 依然重要，只是不再是终点

我并不是想说：

写代码不值钱了。

更准确的说法是：

“把东西实现出来”在整个价值链里的相对稀缺性正在下降。

过去：

“我把它做出来了。”

本身就已经是一个很大的成就。

未来越来越多时候：

做出来只是第一步。

接下来还有：

Does it matter?

它重要吗？

Does it work?

它真的有效吗？

Is it reliable?

它可靠吗？

Is it worth shipping?

它值得上线吗？

甚至还有更前面的一个问题：

Should we build it at all?

我们到底应不应该做它？

AI Coding 正在把实现能力变成一种越来越强的基础设施。

而基础设施越强，人的判断力就越容易暴露。

以前一个差想法可能因为做不出来而死掉。

以后一个差想法，也许真的可以在一天之内被完整做出来。

这未必是好事。

最后

第一篇里，我把 Eval 理解成：

给 AI 考试。

第二篇里，我把它变成：

给 Codex 建立验收制度。

第三篇里，Release Gate 在系统从 79.17% 提升到 91.67% 的情况下，依然告诉我：

FAIL。

跑到这里，我越来越觉得：

Eval 背后真正重要的，可能从来都不是“测试”本身。

真正重要的是：

你有没有能力定义什么叫好。

只有定义了好，

AI 才知道往哪里优化。

Codex 才知道什么时候应该停。

团队才知道什么时候可以 Release。

客户才知道为什么值得相信。

代码正在越来越容易生成。

但方向不会自动出现。

标准不会自动出现。

判断也不会自动出现。

所以如果问我，AI Coding 时代什么能力会越来越值钱，我现在的答案已经不只是：

“会不会写代码。”

而是：

你能不能找到真正值得解决的问题，给它足够的上下文，定义清楚什么叫好，然后让 AI 在这个质量系统里把它做出来。

AI Coding 时代真正稀缺的，不是让 AI 生成更多，而是定义什么值得生成，以及什么才算做好。