代码正在变便宜，Taste、Intent 和 Eval 变贵了

关于 AI 和软件开发，现在有一种焦虑我觉得看错了方向。它通常是这样表达的：如果 AI 已经能写代码，那开发者还剩下什么价值？

这个问题可以理解。模型可以生成组件、修 bug、起草架构图、写测试、解释陌生代码，也能根据几段描述拼出一个看起来合理的 MVP。过去看起来稀缺的软件生产单位，比如一个函数、一个页面、一个脚本、一条 migration，正在变得越来越便宜。

但这并不会让开发者不重要。它只是改变了价值所在的位置。

稀缺能力不再只是“产出代码”。真正稀缺的是围绕代码运转的完整闭环：知道什么是好，把自己想要的东西表达得足够清楚，让 AI 系统可以执行，并且判断结果是否真的达到了标准。

我把它理解为 AI-native developer 的核心 loop：

Taste → Intent → Eval

三个环节缺一不可。任何一个薄弱，整个 loop 都会断。

Taste

Taste 是判断力。

AI 可以给你十种实现。它不能可靠地告诉你，哪一种简单得刚刚好，哪一种会老得更好，哪一种符合产品的气质，哪一种只是看起来厉害，哪一种会悄悄引入复杂度，让团队以后付出代价。

低 taste 的开发会说：能跑就行。

高 taste 的开发会继续问更难的问题：

• 这是不是过度设计了？
• 这个交互自然吗？
• 这个抽象能撑住下一个功能吗？
• 它是在解决真实用户问题，还是只是在展示能力？
• 它像一流产品，还是像一个合格 demo？

Taste 不只是视觉审美。它是技术 taste、产品 taste、交互 taste、商业 taste，甚至也是写作 taste。它是一种长期积累出的辨别能力：能区分“只是可用”和“真正好”。

AI 进入工作流之后，这件事只会更重要。AI 会放大 taste。一个 taste 强的开发者，可以用 AI 探索更多可能性，更快穿过粗糙阶段，并把最终结果拉到更高标准。一个没有 taste 的开发者，也会变快，但大概率只是更快地产出一大堆平均水平的东西。

这就是陷阱。AI 让平庸可以规模化生产。

问题不是模型能不能生成一个看起来完整的东西。它通常可以。问题是：当“完整”正在遮住弱点时，你能不能看出来。

Intent

Intent 是把模糊愿望变成清晰方向的能力。

过去，开发者大部分时间是在和编程语言沟通。现在，开发者越来越多是在和一整套系统沟通：代码库、agent、设计界面、数据库、产品需求、测试、指标和用户。

在这样的世界里，关键动作不只是写指令，而是让意图变得可执行。

我们到底想构建什么？为什么是这个，而不是别的？系统应该优化什么？应该避免什么？第一版可以忽略什么？什么才算完成？

这也是为什么“prompt engineering”这个词一直显得太窄。更深的能力其实是 intent engineering。重要的不是写一个聪明 prompt 的技巧，而是把混乱、模糊和愿望转化成可以执行的形状。

比较下面两个请求：

帮我做一个 AI 网站。

和：

做一个面向独立开发者的 AI idea management 工具。核心不是记笔记，而是把零散想法持续沉淀成可执行项目。第一版包含 idea capture、自动总结、标签、粗略价值评分和下一步行动建议。设计气质更接近 Linear + Notion + ChatGPT，而不是笨重的知识库。

第二个请求更好，不是因为字数更多，而是因为它带着产品理论。它定义了用户、问题形状、第一版边界、期望气质，以及系统不应该变成什么。

这才是工作本身。

在 AI-native development 里，大量价值会前移。开发者要负责把混乱变成 intent：

• 一个模糊想法变成需求。
• 一个需求变成 spec。
• 一个 spec 变成任务序列。
• 一个任务变成 agent instruction。
• agent 的输出再被拉回真实目标。

Intent 越清楚，AI 输出的天花板越高。模型不是方向感的替代品。它是方向感的放大器。

Eval

Eval 是判断结果是否真的好的能力。

这一点会比很多人预期的更重要。AI 系统非常擅长生成“看起来合理”的东西。代码读起来不错，架构图看起来专业，文档显得完整，UI 有精致的表面特征，测试也确实存在。

但 plausible 不等于正确。Complete 不等于可靠。一个能跑一次的 demo，不等于能进 production 的系统。

当 AI 写下越来越多代码，开发者就必须成为更强的评估者。

你需要问：

• 模型是不是误解了需求？
• 它是不是走了一个只覆盖 happy path 的捷径？
• 它有没有引入安全问题？
• 它有没有违背现有架构？
• 它是不是因为某个抽象看起来高级，就把它加进来了？
• 它写的测试是在挑战假设，还是在确认自己的假设？
• 它解决的是用户问题，还是只解决了 prompt？

Eval 不只是测试。测试只是 eval 的一种形式。更大的范畴还包括产品 review、代码 review、用户体验 review、指标 review、安全 review 和 taste review。

对 AI 系统来说，eval 还必须变成架构的一部分。一个严肃的 agent 系统不应该只是生成系统。它周围需要有 harness：检查、benchmark、反例、review artifacts 和反馈 loop。

这个 loop 不应该是：

AI 生成 → 人类接受

而更应该是：

AI 生成 → AI 自检 → 工具验证 → 人类抽样 → 指标反馈 → 系统改进

我认为下一波真正重要的工具会出现在这里。不是更好的 chat box，而是更好的 evaluation harness。系统能够创建 benchmark，对照真实样本，暴露不确定性，并知道什么时候必须让人类介入。

未来的优势不只是：我能让 AI 生成东西。

而是：

我能判断 AI 生成的东西是否真的好。

这个闭环

Taste、intent 和 eval 不是三个孤立能力。它们形成一个 loop。

Taste 决定标准。

Intent 让标准变得可执行。

Eval 判断输出是否达到了标准。

如果你有 intent 但没有 taste，你可以很清楚地把 AI 指向一个平庸目标。如果你有 taste 但没有 intent，你可能知道什么是好，却无法把它变成可执行任务。如果你有 taste 和 intent 但没有 eval，你可以生成看起来很厉害的东西，却不知道它是否稳固。如果你有 eval 但没有 taste，你可能能检查正确性，却错过优秀。

强的 AI-native developer 能同时握住这三件事：

他知道什么值得做，能把它定义清楚，能用 AI 快速推进，也能在 polish 面前保持判断，不被表面完成度欺骗。

这和上一代开发者的画像不完全一样。当然，写代码仍然重要，深层技术理解仍然重要。但重心发生了移动。

开发者会变成一部分产品思考者，一部分系统设计师，一部分 AI operator，一部分工作流设计师，一部分评估者。

普通问题是：

这个功能怎么做？

更好的问题是：

这个功能值得做吗？它到底应该成为什么？AI 应该怎样帮助生产它？我又如何知道它已经足够好？

差别就在这里。

代码正在变便宜。Taste、intent 和 eval 正在变贵。