提示词工程 编辑复核
提示词需求访谈
在写提示词前先澄清用户、输入、输出、成功标准和失败代价，减少“写得很长但不能用”。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名提示词产品经理。请通过少量高价值问题把一个模糊需求转成可测试的提示词 Brief，不要直接开始堆指令。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 用户角色、触发场景和真实任务
2. 允许输入、不可输入和上下文来源
3. 理想输出、格式、长度和语言
4. 错误、风险、人工复核和成功标准
5. 最小测试样例与后续版本计划
输入变量：
- 原始需求（{{request}}）：提供使用者的原话和背景。
- 使用者（{{users}}）：说明谁会运行提示词以及经验。
- 输入资料（{{inputs}}）：说明资料来源、格式和敏感信息。
- 质量标准（{{quality}}）：说明什么结果算可用和什么错误不可接受。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 先让实际使用者回答问题，再编写第一版模板。
- 高风险任务应把人工复核写进成功标准。
WHEN IT FITS
适用判断
适合这些情况
- 需求方说不清要什么，需要问出来。
- 要写提示词但边界和验收标准不明。
- 避免做完才发现理解错了。
换个做法更好
- 需求已经清楚：直接用《提示词结构搭建器》。
- 你就是需求方且想得很明白：自问自答浪费时间。
- 任务很小：访谈成本超过任务本身。
FAILURE MODES
常见翻车与修正
- 问题一口气列了三十个，需求方看到就不想回了。
要求按优先级分批，第一批只问决定方向的少数几个问题，后续按回答展开。
- 只问了要什么，没问不要什么。
要求包含边界类问题：哪些情况不处理、什么样的输出算不合格、有没有禁止的做法。
- 没问验收方式，做完还是各说各话。
要求明确问出验收标准：拿到输出后按什么判断合格，谁来判。
ACCEPTANCE
怎么判断输出合格
- 问题分批，第一批聚焦方向性问题。
- 包含边界问题，问清了不要什么。
- 问出了验收标准和判定人。
- 每个问题都能推动决策，没有为问而问的。
SAFETY BOUNDARY
使用边界
- 访谈会问出业务细节和内部流程，记录的留存和分享范围要事先约定。
- 模型整理的需求是对回答的复述，落地前要请需求方确认没有理解偏差。