提示即编程

前几天，我看见一位常春藤盟校毕业的文科教授在使用Claude，对话兜圈子，他们从未阐明目标。 Claude的每条回复都合理，但都偏离了朋友实际想要的结果，于是他们调整，它又漂移到别处。 这是我所知最聪明的人之一，我看着他们挣扎于一个彻底改变了软件构建方式的工具。 当读到软件以外行业未从AI中获得生产力提升时，我想起了这次互动。 营销人员、分析师、管理人员和运营人员得到一些帮助起草邮件和总结会议，然后花时间清理看似合理但并不完全满足需求的输出。 组织范围内的生产力提升大多未实现。 对软件工程师来说，变化是天壤之别。

我几周内就停止在Opus 4.5发布后编写代码，我所知道的几乎每个工程师都有类似的故事。 通常的解释是模型在大量代码上训练，代码因为要么编译通过测试要么不通过而可验证，AI实验室将最好的工具努力投入到编码代理中，因为他们的员工是工程师。 所有这些都属实。 但它们都无法完全解释差距，因为我见过其他工程师，也亲身体验过，在这些工具上完成与代码无关的任务，如计划旅行、重组预算或起草拨款提案，并取得良好结果。 我的理论更简单：良好地提示AI就是编程。 脑力工作相同，只是语法变了。

工程师擅长它是因为他们多年来一直在做它，而大多数人根本没做过。 考虑一下你写函数或类时脑海中会想什么。 你决定输入是什么以及它们来自哪里。 你决定输出应该精确地是什么。 你将问题分解成足够小的步骤，每一步都明显正确。 你考虑边缘情况：空列表、缺失字段、用户做了你未预料到的事情。 你决定如何知道它是否起作用。 所有这些都与打分号无关，而所有这些正是区分好提示和坏提示的东西。 起始状态和目标状态是程序员首先写下的，即使只是在脑海中。 它们正是我朋友会话中缺少的东西。 非程序员让代理“准备一份关于第三季度销售额的报告”。

工程师，几乎不经思考，问了一个不同的问题：哪些数据，在哪个文件中，按什么分解，与什么基线比较，以什么格式，以及两个在季度中重组的地区应该怎么办？ 工程师并不更聪明。 我朋友在智力上可以绕过我所知道的绝大多数工程师。 工程师只是被编译器无情地敲打，要求精确性。 每个程序员都花了数年被告知，计算机做你说的而不是你意味着的。 非程序员们花了一辈子与人类沟通，人类用共享的背景和常识来填补空白，并在困惑时回来澄清。 大型语言模型也填补空白，但它用最可能的猜测来填补，很少询问。 模糊的提示不会出错。

模型想象你想要什么，交回看起来差不多正确的东西，然后让你去发现哪里不正确。 工程师的直觉是不信任看起来差不多正确的输出。 大多数人的直觉是接受它。 当输出错误时，差距会扩大。 工程师会调试。 他们形成一个假设，关于哪部分指令导致了模型的偏差，改变那一点，然后再次运行。 非-