最近我们在做一轮内部 AI 工作流梳理，牵扯的团队很多：内容同学拿它改邮件和文案，销售拿它看表格，研发拿它改代码和补测试，项目经理则更关心长文档总结、会议材料整理和基于资料问答。
一开始我们把问题想简单了。我们以为只要整理一份“高频提示模板库”，把“写周报模板”“写 cold email 模板”“改简历模板”“总结 PDF 模板”分门别类发下去，大家的输出质量就会稳定下来。结果两周不到，这条路就跑不动了：同一个模板，换个业务背景就失效；同一个模型，换个人来写提示，结果能差出一大截。
后来我才意识到，我们卡的根本不是“缺几个好句式”，而是没有把 AI 当成一个需要明确输入契约的系统。作者在课程里提到的一个视角非常犀利：提示工程本质上是**“用自然语言在编程”**。你没有在写 Python 或 JavaScript，但你仍然在描述任务目标、输入边界、执行限制和输出形态。区别只是，传统程序通过语法和类型系统约束机器，而提示词通过自然语言和上下文去约束模型。
OpenAI 和 Google 的官方文档其实都在讲同一件事：提示工程不是背诵固定咒语，而是为了让模型持续输出符合要求的结果，去设计更清楚、更可执行的输入，而且这个过程天然就是迭代式的。(OpenAI Developers)
提示工程知识地图
我们将这套从“模板”转向“工作流”的思考模型拆解成了三个核心模块。如果你在业务中也遇到了模型输出不稳、长文档处理丢重点或复杂逻辑推理跑偏等问题，可以按序阅读：
- 底层逻辑：模型怎么工作、预算怎么管
- 进阶模式：骨架搭建与进阶推理路径
- 业务落地：复杂附件处理与 RAG 的工程化思维
我们先推翻的，就是“万能模板”这件事
模板当然有用，但它只在一个前提下有用：你已经把任务边界想明白了。
我们最早沉淀的那批模板，最大的问题不是写得不够长，而是抽象得太早。比如“帮我写一篇关于咖啡的博客”“帮我润色这封邮件”“帮我分析这个表格”，这种提示看起来什么都能做，实际上什么都没说清楚。模型只能自己脑补受众、风格、长度、重点和禁区，输出自然飘。
真正有复用价值的不是模板表面长什么样，而是你有没有通过 Steering（引导） 而非仅仅是 Commanding（命令） 来收窄模型的猜测空间。
- Commanding（直接命令）：比如
summarize this。这种写法只交代了任务名，长度、风格、重点都扔给了模型，结果往往泛泛而谈。 - Steering（方向引导）：通过设定目标、重点和边界去引导输出。比如“以执行助理身份总结，只保留决策和行动项，用 4 条要点呈现”。
为了实现高质量的 Steering，我们要求提示词必须包含这几件事：
- 现在它是以什么身份工作；
- 这件事发生在什么业务场景里；
- 它到底要完成哪一个具体任务；
- 哪些内容必须出现，哪些内容不能乱写；
- 最后用什么格式交付。
我们后来内部复盘时，把这件事叫做“任务定义前移”。一旦任务定义模糊，模型并不是不聪明，它只是被迫替你做了太多本该由人决定的选择。
我们一开始整理了很多“高频模板”，后来发现模板一旦脱离具体目标、附件内容 and 输出格式，就会退化成一堆看起来很专业、实际很难复用的句子。真正能迁移的是任务拆解方法，不是那几行固定文案。
迭代式提示开发，才是我们真正每天在做的事
如果只让我保留一个最实用的结论，那就是这个：提示工程本质上是迭代，而不是创作一条“终极提示”。
Google 的官方文档直接写着，prompt design is iterative；OpenAI 的文档也一直在强调试验、观察和修正。(Google AI for Developers)
这和我们线上使用的体验完全一致。复杂任务里，第一版提示的作用往往只是帮你暴露问题：
- 输出太空；
- 格式跑了；
- 忽略了附件里的关键字段；
- 口吻太像营销文；
- 结论和证据没对上；
- 它替你补了不该补的背景。
我们后来做法很固定：
- 先写一个能跑通任务的粗版本；
- 看它错在哪里；
- 只追加必要约束，不一次堆满所有要求；
- 把表现好的段落留下，把跑偏的部分重写；
- 对可重复任务，把示例和输出格式沉淀下来。
这个过程和调接口、调 SQL、调告警阈值其实很像。没有谁会指望第一版配置就永远正确，提示也一样。
为了提高提示词的细节密度，我们鼓励团队尽量用语音说提示，而不是手打。详细提示通常更有效，但手打很累人。使用工具（如 Wispr Flow）进行智能听写，可以自动处理口头禅并格式化，让你在几秒钟内完成一个具备角色、背景和约束的高质量提示。(Wispr Flow)
我们试过把会议纪要、需求文档、旧邮件、表格说明、风格要求一次性扔进去，结果模型反而抓不住重点。后来效果更稳的做法是：先缩任务，再补证据，再限定输出。
继续阅读： 下一篇：Token 与上下文的工程边界