观察：为何软件工程师用AI提效，其他行业却难获收益

前几天，我看着一位朋友用 Claude 干活。她是常春藤名校毕业的文科教授。对话绕来绕去，她始终没把自己的目标说清楚。Claude 的每一条回复，单看它所掌握的信息，都算合理，可每一条都跟朋友真正想要的东西差了一点。于是她去拨一下，Claude 又漂到别处去了。这是我认识的最聪明的人之一，而我就这么看着她在一个工具上挣扎——这工具已经彻底改变了我构建软件的方式。

读到软件行业之外的领域没能从 AI 中获得生产力提升时，我想起了那次对话。营销人员、分析师、管理者、运营人员，靠 AI 起草邮件、总结会议纪要能省点事，然后把省下来的时间花在收拾那些看着像样、其实不太对的输出上。当初承诺的全组织生产力提升，大多没有兑现。对软件工程师来说，变化是天壤之别。Opus 4.5 发布后几周内，我基本就不再写代码了，我认识的几乎每个工程师都有类似的故事。

常见的解释是：模型是在海量代码上训练的；代码是可验证的，要么编译通过、测试通过，要么不通过；AI 实验室把最好的工具投入都放在了编码 agent 上，因为他们自己的员工就是工程师。这些都对。但没有一个能完全解释这个差距，因为我见过别的工程师、也亲身经历过，在跟代码毫无关系的任务上——比如规划旅行、重整预算、起草资助申请——用这些工具取得了极好的效果。

我的解释更简单。把 AI 提示好，就是编程。脑力劳动是一样的，只是语法变了。工程师擅长这件事，是因为他们干了多年；而大多数人从没干过。

想想你写一个函数或类的时候，脑子里在过什么。你决定输入是什么、从哪来。你精确地决定输出应该长什么样。你把问题拆成足够小的步骤，让每一步都显而易见是对的。你考虑边界情况：空列表、缺失的字段、做了你没预料到的事情的用户。你决定怎么判断它跑对了。这些没有一样跟敲分号有关，而所有这些，正是好 prompt 和烂 prompt 的分水岭。起始状态和目标状态，是程序员最先写下的东西，哪怕只写在脑子里。而这恰恰是我朋友那次会话里缺的东西。

非程序员会让 agent“整理一份 Q3 销售报告”。工程师几乎不假思索，问的是另一个问题：哪些数据、在哪个文件里、按什么维度拆分、跟哪个基线比、用什么格式，以及那两个在季度中途重组的区域该怎么处理？工程师并不更聪明。论智力，我朋友能把我认识的大多数工程师转晕。工程师只是被编译器把精确性狠狠揍进了骨头里。

每个程序员都花了多年时间，被瞬间、毫不留情地告知：计算机做的是你说的话，而不是你的意思。非程序员的职业生涯都在跟人沟通，而人会靠共享的上下文和常识补上空隙，糊涂了会回来问一个澄清问题。LLM 也会补空隙，但它填的是最可能的猜测，而且很少发问。含糊的 prompt 不会报错。模型会幻觉出你的意思，递回一个看着差不多对的东西，然后让你自己去发现哪里不对。工程师的本能是不信任看着差不多对的输出。大多数人的本能是接受它。

当输出出错时，差距会拉得更大。工程师会调试。他们提出假设：是我指令里的哪一部分把模型带偏了，改掉那一处，再跑一遍。非程序员倾向于把同一个 prompt 重掷一遍，补一句“请准确一些”，或者得出结论说这工具不行。他们从没养成过这种习惯：把糟糕的结果当作关于自己输入的信息。

这让我 5 月写的东西变得复杂了。我当时主张，领域专业知识才是真正的护城河，一个带着 agent 的领域专家可以出奇地高效，因为他们知道什么是对的。我依然相信“知道什么是对的”很重要。但知道什么是对的是一种评判能力，只有在 agent 已经产出值得评判的东西之后才派得上用场。把它带到那一步，是一种规格说明能力，而这种能力是计算性的。当我观察那些真正从这些工具中获得巨大价值的非工程师时，他们几乎总是有着一颗藏在别的职位头衔下的程序员大脑：用查找表搭复杂电子表格的财务人员，自己写 Zapier 流程的运营经理，因为没别人愿意干而在 R 里折腾数据的研究员。他们一直都在编程。只是没管这叫编程。

这就说回我朋友了。她需要的不是更好的 prompt 模板，也不是一串神奇咒语。她需要的是任何一个大二计算机系学生都不假思索就有的习惯：开始之前先说清楚“做完”是什么样，把工作拆成小到可以检查的块，答案回来不对的时候，问自己指令里的哪一处把它引到了那儿。这些都不需要懂编程语言。但它确实需要多年被编译器纠正的经历，而大多数才华横溢的人，连一个下午都没在编译器那头待过。

自然语言编程当初被推销成让每个人都能编程的办法。到目前为止，它主要是让那些已经像程序员一样思考的人，用英语把编程做得更快。