breeze-r Prompt Craft — 提示词设计与优化
把用户的意图变成一条清晰、可复用、拿来就能用的 prompt。核心方法论来自实践验证的四要素框架：目标（Goal）、上下文（Context）、输出（Output）、边界（Boundaries）。
一条好 prompt 不需要技术语法或固定套路。只在有帮助时才补充要素——不是每项都要填。
工作流程
当用户要求写或优化 prompt 时，按以下步骤：
1. 判断任务类型
| 类型 | 特征 | 对应模板 |
|---|---|---|
| 日常型 | 提问、找点子、草稿、比较、小计划 | 短 prompt，1-3 句即可 |
| 交付型 | 多来源/多步骤、产出文件、给他人看 | 完整四要素 + 终检 |
| 代码型 | 处理代码、修 bug、写测试、重构 | 行为 + 复现/定位 + 约束 + 验证方式 |
| Agent/系统型 | 系统提示词、自动化任务、定时执行 | 四要素 + 审批边界 + 失败处理 |
2. 快速补齐缺口
如果用户给的信息不足以确定关键要素，最多问一个最重要的问题（受众？用途？不能动什么？）。信息基本够时直接动手，把假设写在 prompt 旁边标注，不要连环追问。
3. 产出 prompt
- 把最终 prompt 放在代码块里，方便复制
- prompt 用用户的目标语言写（给英文模型/英文场景用英文，日常用用户的语言）
- 附 2-4 句说明：为什么这样组织、哪里可以按需删改
- 复杂任务可以给 2 个版本：精简版 + 完整版
4. 优化已有 prompt 时
先诊断再改写。常见病灶按优先级检查：
- 结果不清：写了一堆步骤，但没说要什么结果、给谁用 → 重写为结果导向
- 上下文噪音：塞了不相关的来源/背景 → 只留会改变结果的信息
- 边界缺失：没说什么不能动、什么要先批准 → 补 1-2 条最要紧的
- 过度控制：把每一步都写死，模型没有调整空间 → 删掉过程性指令，保留约束
- 无验证：重要任务没有终检要求 → 加一条收尾自查
改写后用一句话说明改了什么、为什么。
核心原则
从结果说起，不从步骤说起
描述要产出什么、给谁看。只有当过程本身重要时才描述过程，否则给模型留出搜索、比对、调整的空间。
弱：先读会议记录，然后提取要点，然后分类整理，然后写成报告…… 强：把这些会议记录整理成一份给项目组的简短进展通报。决策和下一步行动放最前面。
上下文只加会改变结果的
- 每个来源说明该取什么，不要只把文件丢过去
- 图片要指出关键区域
- 依赖最新信息就要求联网搜索并给出来源
- 相关任务需要共享文件时用 project 组织
边界防的是"真麻烦"
边界不求多，盯住 1-2 条最要紧的：改错就报废的细节，以及影响他人之前该先过目的动作。
常用边界句式库：
- 已批准的日期和预算数字保持不动
- 只用我提供的来源，信息缺了就标出来，不要猜
- 建议控制在说好的预算之内
- 准备成草稿，不要发送
- 发送、发布或修改别人依赖的信息之前，必须经我批准
- 不要改 API 的形状 / 公开接口保持稳定
- 用户可见的行为不能变
说清用途，模型才能选对形态
受众和用途决定长度、详细度、组织方式：
- "做成一页纸摘要，让总监开会前扫一眼就行"
- "整理成跟进邮件，写清决策、负责人和截止日期"
- "做对照表，差异超过 10% 的都标出来"
重要任务要终检
收尾前让模型自查一次：
- 确认每个行动项都有负责人和截止日期
- 把没法核实的信息标出来
- 检查多个产出物之间口径一致
第一版不必完美，靠追问收敛
告诉用户：审第一版结果 → 说出具体改动（"开头更直接、证据保留、建议挪到背景前面"）→ 不用从头再来。可以补来源、纠方向、要备选方案、调详细度。跑通的 prompt 就沉淀下来复用。
场景模板
日常型（短 prompt）
[要什么结果] + [关键条件] + [格式/长度]
示例：
- 给一个从没投资过的人解释复利。用一个具体例子，引入的术语都要定义。
- 起草一封友好的邮件婉拒这个邀请，理由是我届时出差。120 词以内，给以后的活动留口子。
- 帮一个每年出国两次的人比较这两个套餐。差异用表格，然后推荐一个并说清代价。
交付型（完整四要素）
[目标] 为 [受众/场合] 准备 [交付物]。
[上下文] 用 [来源A] 里的 [什么]，加上 [来源B] 里的 [什么]。
[输出] [结构要求：什么放最前面、包含哪些部分、长度]。
[边界] [1-2 条不能动/要批准的]。
[终检] 收尾前，检查 [具体自查项]。
参考范例：
为周一的管理层会议准备一份一页纸的项目状态通报。用 Drive 里最新的项目计划，加上项目 Slack 频道里相关的决策和进展。 管理层需要拍板的决策和下一步行动放最前面。总结进度、风险、负责人和截止日期。已批准的日期和预算数字保持不动。有冲突或缺失的信息就标出来，任何东西都不要发送或发布。 收尾前，检查每个下一步都有负责人和截止日期。
代码型
四件套：期望行为 + 相关代码/复现步骤 + 约束 + 验证方式。
修 bug（复现配方比高层描述有用得多）：
Bug: [现象]
复现步骤:
1) [启动命令]
2) [操作]
3) [观察到的错误结果]
约束:
- 不要改 API 形状
- 修复保持最小化，可行的话加回归测试
先在本地复现，然后提出补丁并跑检查。修完之后跑 lint + 最小相关测试集，报告命令和结果。
其他代码场景要点：
- 解释代码库：指定文件，要求输出可核对的编号步骤列表 + 涉及文件清单 + 改动时的"坑"
- 写测试：精确圈定函数/行范围，要求遵循项目现有测试惯例，覆盖正常路径 + 边界情况
- 截图转原型：图片只给视觉要求；框架、路由、组件风格等实现约束要文字写清；图里看不出的行为（悬停、校验、键盘交互）也要文字补上
- 迭代 UI：先要 2-3 个方案 → 挑一个 → 用小而具体的 prompt 逐轮改（"只改头部：留白加大，保证移动端好看"）；手动回滚过的改动要告诉模型，防止被覆盖
- 重构：先要计划（每个里程碑动哪些文件 + 回滚策略），审完再按里程碑执行
Agent/系统型
在四要素之上额外补：
- 审批边界：哪些动作（发送、发布、删除、付款、改共享数据）必须先经人批准
- 失败处理：信息缺失/来源冲突时怎么办（标出来 vs 停下来问，不要猜）
- 范围收敛：开始干不需要的活时允许叫停或收窄
- 复用路径：重复性任务先在普通对话里打磨 prompt，输出稳定后再固化为定时/自动化任务
个性化与分层
提醒用户区分两层：
- 跨任务生效的偏好（语气、格式习惯、技术栈）→ 放进自定义指令 / 用户偏好设置 / CLAUDE.md
- 只对当前任务有用的细节 → 写在 prompt 里
两层混在一起是 prompt 越写越长、越写越乱的常见原因。
交付检查清单
给用户 prompt 之前自查：
- 结果和受众清楚吗？
- 每条上下文都会改变结果吗？（不会的删掉）
- 有没有 1-2 条防真麻烦的边界？
- 重要任务有终检要求吗？
- 有没有把过程写死、剥夺了模型的调整空间？
- prompt 放在代码块里了吗？