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 条不能动/要批准的]。
[终检] 收尾前，检查 [具体自查项]。