mcpField
I
improving-prompts

improving-prompts

github.com/joshuadavidthomasAgent 工作流6062 次安装14 周前更新
代码仓库

关于 improving-prompts

improving-prompts 是依据 Anthropic 已发布指南改进现有提示词的技能。它先确认具体行为问题,再说明修改理由,并保留已有成效的内容。

主要功能

  1. 01诊断具体提示词问题
  2. 02应用 Anthropic 文档指南
  3. 03保留有效内容
  4. 04解释修改建议

适用场景

  1. 01优化 CLAUDE.md 或 AGENTS.md
  2. 02调整自定义命令提示词
  3. 03改进技能说明
  4. 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 步:先理解,再修改

进行任何修改之前:

  1. 询问哪些具体行为表现不佳
  2. 询问提示词应实现什么目标,而它目前还做不到
  3. 如果用户说“总体上改进一下”——请至少询问一个具体问题

以下属于“具体问题”:

  • “Claude 忽略了我要求它简洁的指示” ✓
  • “Claude 会提出修改建议,但不会实际执行” ✓

以下不属于具体问题:

  • “太含糊” ✗(具体哪里含糊?)
  • “不符合最佳实践” ✗(是哪项实践?具体有什么问题?)

不要基于假设进行泛泛的“改进”。

第 2 步:参考实际最佳实践

完整参考内容请见 references/anthropic-best-practices.md。核心原则:

明确说明指示: 当前模型会按字面遵循指示;含糊的要求会被狭义、字面地解读。如果你希望它“做得超出预期”,请明确提出。

明确说明范围: 当前模型不会默默将你只给出一次的指示推广到其他部分。“将此应用于每个部分,而不只是第一部分。”

补充背景/动机: 解释规则存在的原因,而不只是说明规则内容。Claude 会根据解释进行泛化。“绝不使用省略号” → “绝不使用省略号,因为文本转语音引擎无法读出它们。”

谨慎使用示例: 模型会精确模仿示例,包括其中无意传达的模式。请在 <example> 标签中提供 3–5 个与目标行为一致的示例。

思考与投入程度: 优先使用通用指示(“深入思考”;“完成前依据[标准]核验答案”),而不是手写的分步指示。过去那条“未启用 extended thinking 时避免使用 think 一词”的规则已不再适用——当前模型使用自适应思考和 effort。

明确控制冗长度: Opus 4.7 会根据任务感知复杂度调整输出长度。如果工作流需要固定长度或工具调用后的摘要,请明确说明。

工具使用: “你能提出修改建议吗” → 只给建议。“进行这些修改” → 执行编辑。请明确说明是执行还是建议。

降低过于强硬的触发措辞: 优先使用“在有帮助时使用 X”,而不是“紧急:你必须使用 X”——当前模型会因强硬措辞而过度触发并进行过度探索。

第 3 步:保留有效内容
  • 不要重构没有问题的章节
  • 除非是为了解决明确提出的问题,否则不要增加复杂性
  • 除非有明确要求,否则不要改变语气或风格
  • 如果用户的示例展示了正确行为,就予以保留
第 4 步:提出修改并说明理由

对于每项修改,请说明:

  1. 应用了哪项具体的最佳实践
  2. 解决了什么问题
  3. 修改前/修改后

不要在未关联到已记录指导原则的情况下进行修改。

速查:问题 → 修复方法

问题修复方法
输出范围过窄/缺乏概括性明确说明范围(“每个章节”“所有情况”)
Claude 不解释推理过程要求它解释推理过程,或提高 effort
Claude 过于冗长使用“简洁回答”或“用 X 句话回答”
Claude 过于简短“提供详细解释”
Claude 只提出建议,不采取行动将“你能……”改为命令式的“执行……”
未遵循指令补充说明原因
示例与输出不符确保示例展示了完全符合要求的格式
CLAUDE.md 太长/被忽略删除那些即使删掉也不会导致错误的行(目标:少于 200 行)

评论

支持 Markdown