Prompt Craft

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. 上下文噪音：塞了不相关的来源/背景 → 只留会改变结果的信息
3. 边界缺失：没说什么不能动、什么要先批准 → 补 1-2 条最要紧的
4. 过度控制：把每一步都写死，模型没有调整空间 → 删掉过程性指令，保留约束
5. 无验证：重要任务没有终检要求 → 加一条收尾自查

改写后用一句话说明改了什么、为什么。

---

核心原则

从结果说起，不从步骤说起

描述要产出什么、给谁看。只有当过程本身重要时才描述过程，否则给模型留出搜索、比对、调整的空间。

弱：先读会议记录，然后提取要点，然后分类整理，然后写成报告…… 强：把这些会议记录整理成一份给项目组的简短进展通报。决策和下一步行动放最前面。

上下文只加会改变结果的

• 每个来源说明该取什么，不要只把文件丢过去
• 图片要指出关键区域
• 依赖最新信息就要求联网搜索并给出来源
• 相关任务需要共享文件时用 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 放在代码块里了吗？

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: breeze-r
• Source: breeze-r/claude-prompt-craft-skill
• License: MIT

Install and usage instructions live in the source repository linked above.