AI为何只提升了程序员效率：提示工程本质是编程

前几天，我看着一位朋友用 Claude。这位朋友是常春藤名校毕业的文科教授。对话绕来绕去，始终没讲清楚目标是什么。Claude 的每次回复单看被交代的内容都算合理，但每次都跟朋友真正想要的差了一点，于是朋友稍微推一下，它就飘到别处去了。这是我认识的最聪明的人之一，而我眼看着他在一个彻底改变了我构建软件方式的工具上犯难。

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

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

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

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

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

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

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

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

这让我回到我那位朋友身上。他们需要的不是更好的提示模板，也不是一串神奇咒语。他们需要的是任何一个大二计算机系学生都不假思索就有的习惯：开始之前先说清楚“完成”是什么样子，把工作拆成小到可以检查的块，当答案出错时，问自己指令里的哪一部分把它引到了那里。这些都不需要会一门编程语言。但它确实需要多年被编译器纠正的经历，而大多数才华横溢的人从未花过一个下午去承受这种纠正。

自然语言编程当初被宣传为让每个人都能编程的方式。到目前为止，它主要是让那些已经像程序员一样思考的人，用英语编得更快。