角色一：任务负责人
由业务侧指定一人对输出质量负责，写清合格标准与否决项。没有这个角色，模板会变成谁都能改、谁都不负责，最后只剩下一堆没人敢用的版本，出了问题也找不到该找谁，项目很难持续下去，也留不下可复用的东西。
角色二：模板作者
需要既懂业务又愿意读模型行为的人，通常是业务骨干而非纯工程。其职责是把判定标准翻译成指令与示例，并维护变量清单，避免把个案写成通用规则，也要负责与工程对齐输出格式与异常处理。
角色三：评测与工程
负责搭评测脚本、做输出校验、管版本与灰度。工作量不大但必须有人认领，否则模板改动无法比较，线上问题也无法定位。这个角色可以是兼职，但不能空缺，缺了它前两个角色的工作都无法被验证。
数据条件：真实输入
样本要来自真实使用记录，覆盖长文本、缺字段、多语言与错别字。用整理干净的样例调出来的模板，遇到脏输入就会失效，这是上线后效果落差的主要来源，也是团队最容易低估的一环，补起来很费时间。
数据条件：边界与授权
拒答样本、敏感内容与超范围问题要单独准备，并确认样本的授权与脱敏。涉及个人信息或客户数据的样本，须经合规确认后才能进评测集，留存期限也要写清，这部分不能由技术团队自行决定，需法务参与。
适用与不适用
适合谁
- 准备把提示模板纳入日常运营的部门
- 已有真实会话或文档沉淀的业务团队
- 需要向管理层说明人员投入的负责人
不适合谁
- 无人愿意承担判定标准、也不设复核人的部门
- 样本涉及客户数据但无法完成授权的项目
典型场景
某电商公司的售后回复模板由一个三人小组维护：售后主管定合格标准，资深客服写模板与示例，数据分析师搭评测脚本并做版本记录。每周例会用半小时过一遍新增失败案例，决定是否改模板，改动记录保留在共享表格里。
可执行步骤
- 指定任务负责人，并把合格标准写成可判定的条目，逐项与业务确认，避免口头标准
- 由业务骨干担任模板作者，维护指令、示例与变量清单，并记录每次改动的原因
- 指定工程接口人，负责评测脚本、输出校验与版本管理，接口要写进项目计划
- 整理真实输入样本，标注敏感信息，并完成授权与脱敏确认，留存审批记录
常见坑
- 由工程单独定义合格标准，模板格式漂亮却不符合业务口径，上线后被一线弃用，返工还要重做，时间也浪费了。
- 样本只挑干净整齐的案例，遇到错别字与缺字段就失效，团队误判为模型能力不足，方向被带偏，试错成本上升。
- 评测脚本没人维护，模板改了几轮后无法比较，只能凭印象决定用哪一版，争论无法收敛，上线后只能靠猜。
- 把客户数据直接放进评测集而未脱敏，合规评审阶段被迫全部重做，上线时间被迫推迟，返工从零开始。
自检与验收清单
- 是否指定了任务负责人与合格标准，并留存书面记录
- 模板作者是否懂业务，并能读懂模型输出与报错
- 评测与版本管理是否有人认领，并列入排期与考核
- 样本授权与脱敏是否完成确认，并留存审批记录
常见问题
一个人能兼顾这三类角色吗？
小团队里常由一人兼两职，但任务负责人与评测人最好分开，否则容易自己评自己。若确实只有一人，至少把合格标准提前写下来，并定期请业务方抽查，避免标准随个人习惯漂移。
需要多少人投入？
起步通常一到一个半人力即可，关键在分工清楚而非人数。模板作者投入最多，评测与工程是阶段性工作。随着模板数量增加，维护与回归的时间会上升，需要提前排进排期。
没有历史数据怎么办？
可以从近期真实业务中补录，或先用少量人工处理的案例做冷启动。没有历史数据时更应小范围试点，边用边积累，不要一次性铺开，否则评测与回补都跟不上，问题会集中爆发。