AI 让生产变容易了，但让工作变难了

我的日常工作已经面目全非

半年前我还在写代码。现在我一天的工作大概是这样的：定义一个任务的边界，写清楚验收条件，把它交给 agent，等结果回来，验收，不对就让它修，修完再跑。循环往复。

有时候我同时开着好几个 agent 并行推进不同的任务。一天下来 commit 量是过去一周的水平。但如果你问我今天写了几行代码，答案可能是零。

一开始我以为这叫「AI 辅助编程」。后来发现这个词完全不对。辅助意味着我还是那个写代码的人，AI 在旁边帮忙。实际发生的事情是角色互换了：AI 在写代码，我在做决策和验收。

这不是效率提升，是工种更替。

我现在真正花时间的事情是三件：决定 API 的形状，定义什么该做什么不该做，然后验证产出是否符合预期。实现本身完全交出去了。经验没有消失，它从语法和框架层面迁移到了判断力层面。你需要知道什么是对的，但不需要亲手把它写出来。

这个转变最微妙的地方在于，它让「会不会用 AI」这件事变得不那么重要。真正拉开差距的是你会不会验 AI。写 prompt 的技巧有上限，但设计验证闭环的能力没有上限。能在一个短平快的任务里快速判断产出质量的人，和只会把需求丢给 ChatGPT 然后接受第一个回复的人，产出差距是数量级的。

我对「可靠」的理解被颠覆了

传统软件工程有一个根深蒂固的信念：可控的过程产生可控的结果。代码审查、流程规范、分支策略，这些都是在约束过程。过程越规范，结果越可靠。

我以前也信这个。直到我开始大量用 agent 写代码后，发现一件反直觉的事：我越试图控制 AI 的执行过程，结果越不稳定。

在 system prompt 里写「你必须先写测试再写实现」，AI 有时候照做，有时候不照做。加更多约束条目，AI 的注意力就从完成任务偏移到遵守约束。你管得越细，它越容易出问题。这是一种约束膨胀的困境。

后来我换了一个思路：不管过程，只管结果。把验收标准写死，把隔离边界定好，过程随便。

具体来说，就是把 test 当成唯一的硬约束。test 要么过要么不过，没有中间态。AI 在 test-fail-fix 循环里做的事情，本质上是一种搜索：每次 fail 给它明确的 error signal，每次 fix 缩小搜索空间。只要验收框架够硬，AI 用什么路径到达正确结果都无所谓。

这在工程哲学上是一个很大的转变。以前写代码的重点是实现步骤，现在写代码的重点是约束、验证和隔离。以前可靠性来自过程的确定性，现在可靠性来自结果的确定性。

我把这个叫做「结果确定性」范式。它的前提是你能精确定义什么叫「对」。如果你定义不了，那 AI 帮不了你，因为它没有收敛的目标。而定义什么叫「对」这件事本身，恰恰是工程判断力最集中的体现。

这个思路往前推一步，multi-agent 架构的设计也变得更清晰了。很多人把 multi-agent 想象成一群有不同角色的专家在协作，像 PM 和前端和后端各一个 agent。我试过，效果不好。因为 AI 不是人，按人类角色切分 agent 没有理论基础。真正需要解决的问题是上下文怎么拆分、怎么在 agent 之间同步、怎么汇总。把拟人化拿掉，剩下的是一个 context management 问题。

但我比以前累多了

这是我最没预料到的一件事。

AI 接管了写代码的工作后，我以为自己会更轻松。毕竟产出量上去了，体力劳动减少了。实际体验完全相反：我比以前累得多。

仔细想了想原因。以前写代码的时候，有大量时间是在做低认知负荷的事情：琢磨一个正则表达式，写一小时，写出来了松口气；查 StackOverflow，从三个答案里选一个最合适的；跑 build，等两分钟，期间听个播客。这些看起来是工作的一部分，实际上是隐性的认知休息。大脑在执行简单任务的间隙里恢复。

AI 把这些间隙全部填满了。现在一整天都是高密度决策：这个任务怎么拆，这个验收条件对不对，这个产出质量行不行，下一步做什么。没有发呆的时间，没有听歌的时间，没有等 build 的时间。

伯克利有一项很扎实的实证研究，在一家 200 人的公司嵌入了 8 个月，结论是 AI 工具的引入没有减少工作时间，反而让人工作更多了。这和我的体感完全一致。

更深一层的原因是，AI 消除了自然的「等待恢复」窗口。以前手写代码时的发呆、查文档、跑测试，这些是节奏内置的喘息。现在节奏是连续的，人被允许在「只剩一点点脑力」的时候继续推进工作，因为 AI 降低了每个单步的执行成本。于是不知不觉，你就把自己用到了更极限的状态。

这带来一个很现实的问题。如果一个工具提升了产出但加剧了消耗，那它到底是在让每个人更有价值，还是在加速每个人的燃尽？当一天能解决 50 个问题但工资没变，和以前一天解决 5 个问题的时候相比，每个问题的单价在下降。这不是 AI 特有的现象，历史上每一轮生产力工具的升级都面临同样的分配问题。但 AI 的速度让这个问题来得特别快。

我现在的应对办法很朴素：8 小时到了就关电脑。写代码那个「放空大脑」的步骤没了，一天能维持高质量决策的时间就变短了。承认这一点，比硬撑着假装自己还能再来一轮更理性。

值钱的东西正在迁移

如果代码可以被随时重写，prompt 技巧有上限，那什么东西的价值在上升？

我观察到的趋势是 context 组织能力。

举个例子。同样用 Claude Code，有的人每次都从零开始：打开聊天框，描述需求，拿到结果，关掉。下次再来一轮。这是消耗型用法，每次交互的 context 归零。

另一种用法是把和 AI 协作的上下文当成基础设施来经营。我自己在做的事情是把项目的 rules、skills、记忆、公理全部结构化成 AI 可消费的 markdown 文件，放在一个 monorepo 里。每次 agent 启动，它读到的不是空白，是我过去几个月积累的所有决策、偏好和判断力。

这个差距随着时间推移会越拉越大。消耗型用法的天花板取决于单次交互的 prompt 质量。投资型用法的天花板取决于你能把多少长期语义资产变成 agent 可调用的操作系统。前者是线性的，后者是复利的。

再往上一层，比 context 组织更稀缺的是 taste。AI 可以生成任何东西，但判断什么值得生成、什么方向是对的、什么质量够好，这些是训练数据里学不到的。执行层 IC 面临替代，taste 层被放大。AI 越强，有 taste 的人杠杆越大，没有 taste 的人越容易被 AI 的平均水平取代。

蒸馏项目是容易的，把一个项目的规范、流程、决策逻辑写成 agent 可读的文档，大多数人都能做到。蒸馏人是难的，因为架构品味、设计直觉、对什么该做什么不该做的判断，这些东西很难被规则完全定义。它们存在于大量实践的积累里，表现为「看一眼就知道对不对」的能力。

这让我对自己的时间投资有了更清晰的优先级。与其花更多时间学新的 prompt 技巧或追新模型，不如把精力投在两件事上：一是把已有的经验和判断力结构化成可复用的 context 资产，二是继续在真实项目里积累那些只有动手才能长出来的 taste。

软件工程不会消失，它在变形

有一个很流行的叙事是 AI 会让软件工程消失。我的判断正好相反：AI 让软件工程的核心问题变得更重要了。

理由很简单。设计模式抽象的不是功能，是变化。接口隔离、依赖注入、分层架构，这些东西解决的不是「代码怎么写」，而是「需求变了之后代码怎么改」。AI 可以一把生成整个功能，但如果不做隔离，第一次修改就会把问题扩散到全局。

而且 AI 本身也受 context window 限制。隔离做得好，每次修改需要的上下文就少，AI 的表现就更稳定。隔离做得差，AI 需要一次性理解整个系统才能做一个局部修改，失败概率指数上升。

好的架构以前是让人类工程师少加班，现在是让 AI agent 少犯错。目标变了，原则没变。

如果你把这个思路推到底，会到达一个很有意思的地方：给 AI 写基建，本质上是新时代的编译器开发。编译器作者从来不写应用代码，他们写的是让别人能更高效写代码的基础设施。现在 AI 越来越多地承担写应用代码的角色，那给 AI 设计约束、搭脚手架、建 context infrastructure 的人，就是这个时代的编译器作者。

这个类比给了我一个很清晰的定位。我不需要跟 AI 比谁代码写得更快，这场比赛已经结束了。我需要做的是把自己的判断力变成 AI 能消费的基础设施，让 AI 在我设定的边界内，比它在别人那里跑得更好。