提示词工程 编辑复核
任务型提示词结构生成器
把自然语言需求编译成角色、上下文、任务、约束、输出和验收条件，减少模糊指令。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名提示词设计师。请把一项真实任务设计成可复用模板，先确认任务和边界，不要靠堆砌形容词提高专业感。
输出：任务、受众和成功标准；必要上下文与变量表（名称、类型、示例、是否必填）；角色、步骤、约束、输出格式和不确定性处理规则；一个完整示例输入与期望输出骨架；失败案例、人工验收项和版本记录建议。
模板必须能在 {{model_scope}} 中使用。没有证据支持的能力不要写成承诺，变量缺失时先询问而不是猜测。
原始任务：{{task}}
输入材料：{{inputs}}
已知限制：{{constraints}}HOW TO USE
使用说明
- 先审查变量和验收标准，再让模型填入更具体的任务内容。
- 模板上线后用真实失败样例迭代，不要只用模型自评决定版本。
WHEN IT FITS
适用判断
适合这些情况
- 要从零写一条提示词，不知道该包含哪些部分。
- 需求清楚但不知道怎么组织成提示词。
- 要建立团队统一的提示词结构。
换个做法更好
- 已有提示词要改进：用《提示词优化器》。
- 需求还没想清楚：用《提示词需求访谈》先理清。
- 任务很简单：直接一句话说明白就够了。
FAILURE MODES
常见翻车与修正
- 结构套得很全，但每部分都是空话。
要求每个部分必须有实质内容，没内容的部分直接删掉而不是填模板话。
- 角色设定写了一大段，对输出几乎没影响。
角色设定的作用有限。要求角色只写影响输出取向的部分，具体要求放到任务和约束里。
- 约束条件之间互相冲突，模型只能挑一个满足。
要求排查约束间的冲突，冲突的给出优先级，说明冲突时以哪条为准。
ACCEPTANCE
怎么判断输出合格
- 每个部分都有实质内容，没有填充式模板话。
- 角色设定简短，具体要求在任务和约束里。
- 约束之间无冲突，或已给出优先级。
- 包含了输出格式和验收标准。
SAFETY BOUNDARY
使用边界
- 提示词里写的约束不是强制执行的规则，涉及权限和安全的限制必须在应用层实现。
- 模板中的示例和默认值不要写入真实的客户信息和内部数据。