improving-prompts
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseImproving Prompts
提示词优化
Overview
概述
Apply documented Claude 4.5 best practices to existing prompts. Do not invent "improvements" - use the actual guidance from Anthropic.
将Anthropic官方文档中针对Claude 4.5的最佳实践应用于现有提示词。请勿自行“创造”改进方案——严格遵循Anthropic的实际指导内容。
When to Use
适用场景
- Optimizing CLAUDE.md or AGENTS.md files
- Improving custom command prompts
- Refining skill instructions
- Migrating prompts from older Claude models to 4.5
- 优化CLAUDE.md或AGENTS.md文件
- 改进自定义命令提示词
- 完善技能说明
- 将旧版Claude模型的提示词迁移至4.5版本
When NOT to Use
不适用场景
- Writing new prompts from scratch (just follow best practices directly)
- The prompt is working well and user hasn't identified issues
- 从零开始撰写新提示词（直接遵循最佳实践即可）
- 提示词运行正常且用户未指出任何问题
The Core Problem
核心问题
Without this skill, agents:
- Invent "best practices" from general knowledge
- Make structural changes without asking what's broken
- Add complexity assuming more structure = better
- Change things to demonstrate value rather than solve problems
如果没有此技能，智能体（Agent）会：
- 从通用知识中“发明”所谓的“最佳实践”
- 在未明确问题的情况下对提示词进行结构性修改
- 主观认为结构越复杂越好，无端增加复杂度
- 为了体现自身价值而修改内容，而非解决实际问题
Common Rationalizations (Do Not Fall For These)
常见错误借口（请勿轻信）
| Rationalization | Reality |
|---|---|
| "The user said it's too vague" | "Too vague" isn't actionable. What specific behavior fails? |
| "I'm the expert, trust me" | Authority doesn't bypass the need for concrete issues |
| "Time pressure - demo tomorrow" | Pressure is when agents make the worst decisions |
| "The spirit of the skill is to help" | Violating the letter IS violating the spirit |
| "I have enough context" | If you can't name the specific failure, you don't |
| "Structure is always better" | Structure solves structure problems, not all problems |
| "This is obviously an improvement" | Obvious to you ≠ solving the user's actual problem |
| 错误借口 | 实际情况 |
|---|---|
| “用户说这个提示词太模糊了” | “太模糊”不具备可操作性。具体是哪部分行为不符合预期？ |
| “我是专家，相信我” | 权威不能替代对具体问题的明确界定 |
| “时间紧迫——明天要演示” | 压力往往是智能体做出最差决策的时候 |
| “这个技能的初衷就是提供帮助” | 违反规则本身就是违背初衷 |
| “我已经掌握足够上下文了” | 如果你无法明确指出具体的问题，说明你并没有足够上下文 |
| “结构化总是更好的” | 结构化只能解决结构性问题，而非所有问题 |
| “这显然是一个改进” | 你觉得明显≠解决用户的实际问题 |
Required Process
必选流程
Step 1: Understand Before Changing
步骤1：先理解再修改
Before ANY modifications:
- Ask what specific behaviors are underperforming
- Ask what the prompt should achieve that it currently doesn't
- If user says "just improve it generally" - ask for at least one concrete issue
What counts as a "concrete issue":
- "Claude ignores my instruction to be concise" ✓
- "The examples I provide don't match the output format" ✓
- "Claude suggests changes but doesn't implement them" ✓
What does NOT count:
- "It's too vague" ✗ (vague about what?)
- "It doesn't follow best practices" ✗ (which practice? what fails?)
- "It's inconsistent" ✗ (inconsistent how? show examples)
Do NOT proceed with generic "improvements" based on assumptions.
在进行任何修改之前：
- 询问用户具体哪些表现未达预期
- 询问用户期望提示词实现但当前未实现的目标
- 如果用户说“只是整体优化一下”——请至少让用户指出一个具体问题
什么是“具体问题”：
- “Claude无视我要求简洁的指令” ✓
- “我提供的示例与输出格式不匹配” ✓
- “Claude只提出修改建议但不执行” ✓
什么不属于“具体问题”：
- “它太模糊了” ✗（具体哪里模糊？）
- “它不符合最佳实践” ✗（哪项实践？具体哪里不符合？）
- “它不一致” ✗（怎么不一致？请举例说明）
请勿基于假设进行笼统的“改进”。
Step 2: Reference Actual Best Practices
步骤2：参考官方最佳实践
See for the complete reference. Key principles:
references/claude-4.5-best-practices.mdBe explicit with instructions:
- Claude 4.5 follows instructions precisely - vague requests get literal interpretations
- If you want "above and beyond" behavior, explicitly request it
- Example: "Create a dashboard" → "Create a dashboard. Include relevant features and interactions. Go beyond basics."
Add context/motivation:
- Explain WHY a rule exists, not just WHAT the rule is
- Claude generalizes from explanations
- Example: "NEVER use ellipses" → "Never use ellipses because the text-to-speech engine cannot pronounce them"
Be vigilant with examples:
- Examples are followed precisely - ensure they demonstrate desired behavior
- One excellent example beats many mediocre ones
Avoid "think" without extended thinking:
- When extended thinking is disabled, "think" triggers unwanted behavior
- Use alternatives: "consider," "evaluate," "assess," "determine"
Control verbosity explicitly:
- Claude 4.5 defaults to efficiency/conciseness
- If you want summaries or explanations, request them explicitly
Tool usage patterns:
- "Can you suggest changes" → Claude suggests but doesn't implement
- "Make these changes" → Claude implements
- Be explicit about whether to act or advise
完整参考内容请查看。核心原则如下：
references/claude-4.5-best-practices.md指令要明确：
- Claude 4.5会精准遵循指令——模糊的请求会被字面解读
- 如果你想要“超出基础要求”的表现，请明确提出
- 示例：“创建一个仪表盘” → “创建一个仪表盘，包含相关功能和交互，超出基础要求”
添加背景/动机：
- 解释规则存在的原因，而不仅仅是规则内容
- Claude会从解释中进行泛化学习
- 示例：“绝对不要使用省略号” → “绝对不要使用省略号，因为文本转语音引擎无法识别它们”
谨慎使用示例：
- Claude会严格遵循示例——确保示例能展示期望的行为
- 一个优秀的示例胜过多个平庸的示例
避免无扩展思考的“think”指令：
- 当扩展思考功能被禁用时，“think”会触发意外行为
- 使用替代词汇：“consider”“evaluate”“assess”“determine”
明确控制冗长程度：
- Claude 4.5默认以高效/简洁为原则
- 如果你需要总结或详细解释，请明确提出
工具使用模式：
- “Can you suggest changes”（你能提出修改建议吗？）→ Claude只会提出建议，不会执行
- “Make these changes”（执行这些修改）→ Claude会执行修改
- 明确说明是要提供建议还是直接执行
Step 3: Preserve What Works
步骤3：保留有效的内容
- Do NOT restructure sections that aren't problematic
- Do NOT add complexity unless solving a stated problem
- Do NOT change tone/voice unless specifically requested
- Keep the user's examples if they demonstrate the right behavior
- 请勿对没有问题的章节进行结构调整
- 除非是为了解决明确的问题，否则不要增加复杂度
- 除非用户明确要求，否则不要改变语气/风格
- 如果用户提供的示例能展示正确行为，请保留
Step 4: Propose Changes with Rationale
步骤4：附带理由提出修改方案
For each change, state:
- What specific best practice it applies
- What problem it solves
- Show before/after
Do NOT make changes without connecting them to documented guidance.
对于每一项修改，需要说明：
- 应用了哪项具体的最佳实践
- 解决了什么问题
- 展示修改前后的对比
请勿在未关联官方文档指导内容的情况下进行修改。
Red Flags - You're About to Fail
危险信号——你即将犯错
- "Based on general best practices..." → STOP. Use documented practices.
- "Structure is always better..." → STOP. Ask if structure is the problem.
- "I'll assume the user wants..." → STOP. Ask.
- Making 10+ changes to a short prompt → STOP. What specific problem are you solving?
- "This is how I would write it..." → STOP. You're not the user.
- “基于通用最佳实践……” → 停止。请使用官方文档中的实践。
- “结构化总是更好……” → 停止。先询问是否是结构问题。
- “我假设用户想要……” → 停止。去询问用户。
- 对简短的提示词进行10+项修改 → 停止。你到底在解决什么具体问题？
- “我会这么写……” → 停止。你不是用户。
Quick Reference: Claude 4.5 Improvements
快速参考：Claude 4.5提示词改进方案
| Issue | Fix |
|---|---|
| Claude takes things too literally | Add "Go beyond basics" or explicit scope |
| Claude doesn't explain reasoning | Add "Explain your reasoning" or "Think through this step by step" |
| Claude is too verbose | Add "Be concise" or "Respond in X sentences" |
| Claude is too terse | Add "Provide detailed explanations" |
| Claude suggests but doesn't act | Change "Can you..." to imperative "Do X" |
| Instruction isn't followed | Add context for WHY the instruction matters |
| Examples not matching output | Ensure examples show exact desired format |
| 问题 | 解决方案 |
|---|---|
| Claude过于字面化解读指令 | 添加“超出基础要求”或明确的范围说明 |
| Claude不解释推理过程 | 添加“Explain your reasoning”（解释你的推理过程）或“Think through this step by step”（逐步思考） |
| Claude过于冗长 | 添加“Be concise”（保持简洁）或“Respond in X sentences”（用X句话回复） |
| Claude过于简洁 | 添加“Provide detailed explanations”（提供详细解释） |
| Claude只提建议不执行 | 将“Can you...”改为祈使句“Do X”（执行X操作） |
| 指令未被遵循 | 添加指令背后的原因背景 |
| 示例与输出不匹配 | 确保示例展示了完全符合要求的格式 |
Common Mistakes
常见错误
Overengineering: Adding categories, numbered lists, XML structure to simple prompts that were working fine.
Changing voice: The user's CLAUDE.md reflects their personality. Don't make it sound like documentation.
Assuming problems: Making changes without knowing what's actually broken.
Inventing practices: Claiming something is a "best practice" without reference to actual guidance.
过度设计： 为原本运行良好的简单提示词添加分类、编号列表、XML结构等。
改变风格： 用户的CLAUDE.md体现了他们的个人风格，不要让它听起来像官方文档。
假设问题： 在不知道实际问题的情况下进行修改。
自创实践： 在未参考官方指导的情况下，声称某内容是“最佳实践”。