提示工程本质是编程：为何工程师更善用AI

一位常春藤盟校教授与 Claude 协作时陷入困境：对话循环往复，模型回复虽语境合理却偏离实际需求，微调提示反而导致结果更远。这位极具智慧的用户所面临的困扰，折射出当前 AI 生产力应用的巨大鸿沟。

市场营销、分析及运营人员虽能用 AI 起草邮件或总结会议，但节省的时间往往耗费在清理“看似合理却无法完全满足需求”的输出上，此前承诺的全组织生产力提升并未真正落地。相比之下，软件工程师的体验天壤之别。自 Opus 4.5 发布后的几周内，作者已基本停止手写代码，身边工程师亦有同感。

主流观点认为，模型在海量的可验证代码上训练，且 AI 实验室优先优化编码代理，因此工程师受益更多。这虽属实，却不足以解释全部差距。作者发现，工程师在处理旅行规划、预算重组等非代码任务时，同样能获得极佳结果。

核心理论更为简单：优秀的 AI 提示本质上是编程。心智劳动相同，仅语法改变。工程师擅长此道，源于多年训练形成的思维习惯，而大多数人从未经历这种磨砺。

编写函数时，程序员会明确输入来源、精确构想输出、将问题分解为可验证的小步骤，并预判边缘情况。这与敲击分号无关，却是区分好坏提示的关键。起始状态和目标状态的明确定义，正是前述教授会话中缺失的核心要素。

面对“整理第三季度销售报告”的需求，非程序员往往给出模糊指令；工程师则会本能地追问数据源、细分维度、基线对比及异常处理逻辑。这种差异并非智力高低所致，而是职业习惯使然。程序员历经数年教育，深知计算机执行的是“所说的话”而非“本意”；而非程序员习惯于人类沟通中的常识填补与澄清提问。

LLM 倾向于用最合理的猜测填补空白且极少发问。模糊提示不会报错，模型返回“大致正确”的结果，留待用户排查。工程师的本能是怀疑并调试，假设指令偏差并修正重跑；非程序员则倾向于重新生成或归咎工具，未将糟糕结果视为输入反馈。

这一现象修正了作者五月的观点：当时认为领域专业知识是护城河，拥有代理的领域专家因知晓“正确答案”而效果惊人。如今看来，“先知”（Oracle）式的评判技能固然重要，但让代理产出值得评判的内容，需要一种计算性的规范技能。

观察那些从 AI 中获益的非工程师，他们往往是“披着不同头衔的程序员”：构建复杂电子表格的财务人员、编写自动化流程的运营经理、用 R 语言处理数据的研究员。他们早已具备编程思维，只是未以此自称。

回到最初的案例，那位教授需要的并非魔法提示词模板，而是计算机科学学生习以为常的习惯：事前定义“完成”标准，将工作分解为可检查模块，出错时反思指令偏差。这些无需掌握编程语言，却需要经年累月被编译器纠正的经验。