很多人写提示词写着写着就卡住了：明明句式很漂亮，换个人用同一句话效果就崩；明明模型答得不对，却不知道是词没选好还是流程没搭好。这篇不讲玄学，先把「工程」和「写作」这两件事拆开，说清各自解决什么问题、什么时候用哪一种、什么情况下这套分法其实不适用。
很多人写提示词写着写着就卡住了：明明句式很漂亮，换个人用同一句话效果就崩；明明模型答得不对，却不知道是词没选好还是流程没搭好。这两件事经常被混着说，结果就是练了半天不知道自己在练什么。
这篇不讲玄学，先把「工程」和「写作」拆开，说清各自解决什么问题、什么时候往哪边使劲、什么情况下这套分法其实不适用。判断标准给到能直接用的程度，最后给一个可以照着练的推进顺序。
先把两件事各自的活儿说清楚
提示词写作解决的是「这一次输出要好看、要贴合语气和人群」，交付物是一段文字，读者是人。提示词工程解决的是「同一套输入在多次调用里稳定出结果」，交付物是能复用、能改参数、能接进流程的结构，读者是下次调用它的你或系统。两边的验收标准根本不一样：一个看读起来舒不舒服，一个看跑十次是不是都差不多。
判断方法很简单：只跑一次、结果自己看，偏写作；要跑很多次、结果要被人或程序验收，偏工程。两者不是先后关系也不是高下关系，同一份提示词里常常两件事都占：一段负责定调，一段负责定规则。
| 对比项 | 提示词写作 | 提示词工程 |
|---|---|---|
| 解决的问题 | 这一次输出好不好看 | 多次调用稳不稳定 |
| 交付物 | 一段文字 | 可复用、可改参数的结构 |
| 读者 | 看结果的人 | 下次调用它的你或系统 |
| 验收方式 | 读一遍觉得对了 | 同一组输入反复跑，偏差可控 |
| 典型适用 | 文案、邮件、起标题 | 固定格式整理、批量生成同类内容 |
什么时候该往哪边使劲
判断不适用的情况也要说清：任务本身没有稳定标准（比如「写个有意思的标题」），再怎么工程化也压不住偏差，因为连你自己都不知道什么算合格。这时应该先收窄目标，而不是继续加规则。加规则只会让提示词越来越长，效果越来越飘。
- 一次性的活：写文案、改邮件、起标题，把力气花在词句、语气、示例上，投入产出比最高
- 要重复出结果的活：按固定格式整理材料、批量生成同一类内容，把力气花在结构、变量、输入输出边界上
- 目标还没想清：先别动提示词，先写一句「什么算合格」，写不出来就说明还没到优化阶段
- 拿不准的时候：先按写作来一遍，跑三次看偏差落在哪，偏差集中在格式就补结构，集中在语气就补表达
这个分法也有失效的时候：如果你只是偶尔用一次、结果好坏自己心里有数，那纠结「我这算工程还是写作」纯属浪费时间，直接用就行。分法是为了帮你决定往哪投入，不是给你贴标签。
被叫做「工程」的那部分，具体在工程什么
- 结构的固定
- 哪一段是背景、哪一段是约束、哪一段是示例，位置换来换去结果就不稳，固定下来才好复用
- 变量的抽离
- 把每次都变的（对象、风格、长度要求）拎出来单独放，正文骨架不动，改一处不牵连全篇
- 边界的声明
- 输出格式、不要做什么、超出范围怎么办，这些不写清，模型就会自己发挥
- 可验证
- 每次改完拿同一组输入再跑一遍对照，而不是凭感觉说「好像好点了」
- 第一步 拆骨架把手上那段提示词按「背景 / 任务 / 约束 / 示例 / 输出格式」切成块，看哪一块每次都在变。变的那块就是候选变量。
- 第二步 标变量变量单独放一行，用统一写法标出来，比如对象、风格、字数要求各占一行。正文骨架里不再出现任何具体值。
- 第三步 定边界明确写出输出格式和「不要做什么」。超出范围的情况也给一句：信息不够时直接说缺什么，别硬编。
- 第四步 做对照固定三到五组输入当测试集，每次改提示词都跑一遍，记录哪几组变好、哪几组变差。测试集别只留成功案例。
这套下来产出的东西，别人拿去能直接用，换个对象只改一行。至于用哪组输入做测试集、怎么记录偏差，可以到 /tools/quality-check 挑一个顺手的对照方式，比人肉记感觉靠谱。
被叫做「写作」的那部分，具体在写什么
语气的定调是核心：这段话说给谁听、要什么态度，词选得对不对直接决定读起来像不像人写的。同一句指令，把「请帮我写」换成「给我写一段」，出来的东西气质就不一样。这不是玄学，是词感问题，练的是你对词的敏感度。
- 信息的排序：先说什么后说什么，读者在哪一句会失去耐心，这是写作的基本功，跟模型没关系
- 示例的挑选：给一两个正例比写十条规则管用，但示例选偏了会把模型带跑，选之前先想清「它要模仿的是哪一点」
- 术语别混着用：分不清的概念可以到 /ai-dict/category/tips 随手对一下口径，避免自己给自己造歧义
- 别堆形容词：想要「专业」就写清专业体现在哪，光说「请专业一点」等于没说
写作这一侧的练习有个好处：不依赖工具，随时能练。同一件事写三版不同语气的提示词，对比输出，三次下来你就知道哪些词是真正起作用的。这个过程不需要任何额外环境，也不需要花钱。
想进阶，按这个顺序推自己一把
最怕的是顺序反了：一上来就研究调用参数、成本、接入方式，结果提示词本身还没写明白，一直在调无关的东西。先把词写好，再把结构立住，最后才谈接入。
- 第一步 先练写作同一件事写三版不同语气的提示词，对比输出。练的是对词的敏感度，判断标准是自己读起来有没有明显差异。
- 第二步 再练工程把上面那版里会变的部分挖出来做成变量，自己换着填，看结果稳不稳。判断标准是换三次变量，输出格式有没有走样。
- 第三步 练验证固定一组输入当测试集，每次改动都跑一遍，别只挑成功的那次看。判断标准是你能说出这次改动让哪几组变好、哪几组没动。
- 第四步 再考虑接入要把提示词接到程序里跑，再去关心参数、调用口径和成本。判断标准是提示词本身已经稳定到换个人用也不崩。
走到第四步的时候，其实已经不太纠结「这算工程还是写作」了，因为你手里有测试集、有骨架、有验证习惯，两边的东西自然都在。真要说数据，参数口径和成本这类会变的东西，别记在脑子里，到 /price-watch 核对当时的数字更省事。
下一步如果你正卡在「改了不知道有没有变好」，先别继续改提示词，先去搭一组固定输入当测试集；顺手可以到 /tools/quality-check 看看别人是怎么做对照的。→常见问题
写提示词需要会编程吗？
不用。上面说的「工程」指的是结构和可复用，不是写代码。你会不会用变量、会不会固定格式，跟你用不用编程语言完全是两回事。当然要接到程序里批量跑，就绕不开接口参数那一层，那是另一步的事。
同一个提示词别人用得好我用不好，是我不行吗？
大概率不是。提示词效果跟模型、上下文长度、你这边的历史对话都有关系，同一句话换个环境就是会变。先确认你们用的是不是同一个模型和同样的前置设定，再谈是提示词的问题还是环境的问题。
市面上那么多框架和模板，必须学一个吗？
不必须。框架的价值是把结构固定下来方便复用，如果你手上就一两个一次性任务，直接写反而更省事。真要学，挑一个能解释清楚「每一段为什么放这儿」的，比挑名字响的更有用。
