关于 improving-prompts
improving-prompts 是依据 Anthropic 已发布指南改进现有提示词的技能。它先确认具体行为问题,再说明修改理由,并保留已有成效的内容。
主要功能
- 01诊断具体提示词问题
- 02应用 Anthropic 文档指南
- 03保留有效内容
- 04解释修改建议
适用场景
- 01优化 CLAUDE.md 或 AGENTS.md
- 02调整自定义命令提示词
- 03改进技能说明
- 04将提示词迁移到 Claude 4.x
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ joshuadavidthomas/ agent-skills --skill improving-prompts安装后在 Claude Code 中输入/improving-prompts确认已加载。
附带文件references/anthropic-best-practices.md
详细介绍
改进提示词
概述
将 Anthropic 当前已记录的最佳实践应用于现有提示词。不要凭空编造“改进”——应使用实际指南。
适用场景
- 优化 CLAUDE.md 或 AGENTS.md 文件
- 改进自定义命令提示词
- 优化技能说明
- 将提示词迁移到当前 Claude 模型(4.x)
不适用场景
- 从头编写新提示词(直接遵循最佳实践即可)
- 提示词运行良好,且用户未指出问题
核心问题
缺少此技能时,Agent 会:
- 根据一般知识编造“最佳实践”
- 不先询问哪里出了问题,就进行结构调整
- 认为结构越多越好,从而增加复杂性
- 为了展示价值而修改内容,而不是为了解决问题
发现自己有以下想法时,请停下来
这些都是失败模式。如果你有以下任何想法,请停下来,先确认具体问题。
| 想法 | 实际情况 |
|---|---|
| “太含糊/不符合最佳实践/不一致” | 不可执行。具体哪种行为有问题? |
| “我掌握的信息够了”/“我就假设用户想要……” | 如果你说不出具体问题,那就说明信息还不够。请询问。 |
| “我是专家”/“我会这样写” | 专业权威不能替代具体问题。你不是用户。 |
| “根据一般最佳实践……” | 使用有文档依据的实践。引用相关指南。 |
| “结构总是更好” | 结构只能解决结构问题,不能解决所有问题。 |
| “时间紧迫——明天就要演示” | 最容易在时间压力下做出糟糕的修改。 |
| “这显然是改进” | 对你来说显而易见 ≠ 解决了用户的实际问题。 |
| 对一个简短提示词做出 10 项以上修改 | 停下来。你要解决的具体问题是什么? |
必须遵循的流程
第 1 步:先理解,再修改
进行任何修改之前:
- 询问哪些具体行为表现不佳
- 询问提示词应实现什么目标,而它目前还做不到
- 如果用户说“总体上改进一下”——请至少询问一个具体问题
以下属于“具体问题”:
- “Claude 忽略了我要求它简洁的指示” ✓
- “Claude 会提出修改建议,但不会实际执行” ✓
以下不属于具体问题:
- “太含糊” ✗(具体哪里含糊?)
- “不符合最佳实践” ✗(是哪项实践?具体有什么问题?)
不要基于假设进行泛泛的“改进”。
第 2 步:参考实际最佳实践
完整参考内容请见 references/anthropic-best-practices.md。核心原则:
明确说明指示: 当前模型会按字面遵循指示;含糊的要求会被狭义、字面地解读。如果你希望它“做得超出预期”,请明确提出。
明确说明范围: 当前模型不会默默将你只给出一次的指示推广到其他部分。“将此应用于每个部分,而不只是第一部分。”
补充背景/动机: 解释规则存在的原因,而不只是说明规则内容。Claude 会根据解释进行泛化。“绝不使用省略号” → “绝不使用省略号,因为文本转语音引擎无法读出它们。”
谨慎使用示例: 模型会精确模仿示例,包括其中无意传达的模式。请在 <example> 标签中提供 3–5 个与目标行为一致的示例。
思考与投入程度: 优先使用通用指示(“深入思考”;“完成前依据[标准]核验答案”),而不是手写的分步指示。过去那条“未启用 extended thinking 时避免使用 think 一词”的规则已不再适用——当前模型使用自适应思考和 effort。
明确控制冗长度: Opus 4.7 会根据任务感知复杂度调整输出长度。如果工作流需要固定长度或工具调用后的摘要,请明确说明。
工具使用: “你能提出修改建议吗” → 只给建议。“进行这些修改” → 执行编辑。请明确说明是执行还是建议。
降低过于强硬的触发措辞: 优先使用“在有帮助时使用 X”,而不是“紧急:你必须使用 X”——当前模型会因强硬措辞而过度触发并进行过度探索。
第 3 步:保留有效内容
- 不要重构没有问题的章节
- 除非是为了解决明确提出的问题,否则不要增加复杂性
- 除非有明确要求,否则不要改变语气或风格
- 如果用户的示例展示了正确行为,就予以保留
第 4 步:提出修改并说明理由
对于每项修改,请说明:
- 应用了哪项具体的最佳实践
- 解决了什么问题
- 修改前/修改后
不要在未关联到已记录指导原则的情况下进行修改。
速查:问题 → 修复方法
| 问题 | 修复方法 |
|---|---|
| 输出范围过窄/缺乏概括性 | 明确说明范围(“每个章节”“所有情况”) |
| Claude 不解释推理过程 | 要求它解释推理过程,或提高 effort |
| Claude 过于冗长 | 使用“简洁回答”或“用 X 句话回答” |
| Claude 过于简短 | “提供详细解释” |
| Claude 只提出建议,不采取行动 | 将“你能……”改为命令式的“执行……” |
| 未遵循指令 | 补充说明原因 |
| 示例与输出不符 | 确保示例展示了完全符合要求的格式 |
| CLAUDE.md 太长/被忽略 | 删除那些即使删掉也不会导致错误的行(目标:少于 200 行) |