第一步：选任务
优先选输出结构清楚、判定标准一致的任务，例如摘要、分类、字段抽取、回复起草。创意写作与战略判断缺少稳定判据，很难验收。任务选错，后面所有优化都没有着力点，团队也会失去信心，最后把问题都归到模型身上。
第二步：建评测集
从真实使用记录里抽一百到三百条输入，配上经业务确认的期望输出，标注合格判定与拒答边界。样本要覆盖长输入、空输入、多语言与敏感内容。否则上线后才发现这些情况没人管，临时补样本既慢又容易失真。
第三步：写模板并校验
模板固定目标、约束、示例与输出格式，变量单独注入。凡是能程序化校验的输出，都要配解析与重试；不能校验的部分，写明由谁复核。模板上线前跑一遍评测，通过率与错误类型要存档，作为后续改动的对照基线。
第四步：上线运营
上线不等于结束。要记录模板版本、模型版本与评测结果，按月收集失败案例回补评测集，按季度清理过期示例。没有运营的模板会在半年内退化成个人经验，最终又回到靠人改稿的状态，前期投入也打了水漂。
验收看什么
验收看三件事：核心场景的通过率是否达到约定阈值、失败是否集中在可修复的类型、人工接管是否有明确规则。不承诺具体百分比，但阈值与统计口径必须在项目确认单里写清，验收时按同一批样本复跑比对。
适用与不适用
适合谁
- 有稳定文本任务与真实使用记录的团队
- 希望把个人经验转成团队能力的部门
- 准备把提示接入业务系统前的准备阶段
不适合谁
- 尚无真实样本、只能凭想象设计场景的项目
- 要求一次投入长期不用维护的团队
典型场景
某物业公司的报修工单摘要项目按四步推进：先选工单摘要这一可判定任务，再从历史工单抽两百条建评测集，模板限定三段结构与必填字段，上线后按月回补失败案例。第三个月把模板从八段精简到五段，通过率未降，维护成本反而下降，团队才敢推广到投诉工单。
可执行步骤
- 按可判定性给候选任务排序，先选一个高频场景，再确定验收人与指标，形成一页纸
- 抽真实输入并由业务确认期望输出，按场景分层，建成评测集并记录来源
- 写模板并加输出校验，先跑一遍完整评测，再把结果与版本一起存档便于回溯
- 上线后按月回补失败案例，按季度精简模板，并重跑一遍评测做回归比对
常见坑
- 跳过评测直接上线，效果好坏全凭几个人感觉，出问题也无法判断是哪次改动导致，最后只能整体停用。
- 评测样本只挑简单案例，通过率很好看，真实流量一上来就崩，返工更贵，团队对系统的信任也一次耗尽。
- 模板与代码耦合，改一句话要发版，业务方渐渐绕过系统自己写，资产重新碎片化，治理也就无从谈起。
- 把提示工程当成一次性项目，没有版本与回补机制，半年后无人维护，只能推倒重来，投入变成沉没成本。
自检与验收清单
- 任务是否有可判定的输出标准，并明确指定验收人
- 评测集是否覆盖边界、空输入与敏感三类真实样本
- 模板改动是否先跑评测，通过后再上线并留记录
- 是否有版本记录，以及按月的回补安排与责任人
常见问题
一定要先做评测集吗？
建议先做，哪怕只有几十条。没有评测，改动就无法比较，团队会陷入各说各话。评测集不必一次完备，可以从真实失败案例开始积累，边用边补，成本远低于反复试错，也更容易说服业务方。
模板该由谁来写？
由最懂业务判定的人主笔，工程侧负责结构化与校验。让工程师独立写业务模板，容易写出格式漂亮但判定错误的内容；让业务单独写，又常缺少对模型行为的理解，两者配合最稳，交接也清楚。
多大规模适合做提示工程？
与规模关系不大，与任务重复度关系更大。每天几十次但结构固定的任务也值得沉淀模板；偶发且每次不同的任务则不必，直接人工处理更快，勉强工程化反而增加负担，还会拖慢交付。