claude-code-usage

Claude Code 最佳实践

语言规则

• 始终使用用户所用的语言回复。 如果用户用中文提问，就用中文回复；如果用英语提问，就用英语回复。

上下文管理规则

规则	原因
一个窗口 = 一个任务	混合任务会污染上下文，降低输出质量
优先使用 /clear，而非 /compact	重新开始比压缩上下文更可靠
复杂任务后使用 /clear	防止旧上下文干扰新工作
将关键信息复制到新窗口	不要依赖上下文延续——粘贴关键细节

任务执行策略

任务类型	推荐方法
小型错误修复（几行代码）	直接描述，让 Claude 就地修改
大型功能 / 重构	/plan → 审查方案 → /clear → 粘贴计划 → 分步执行
多文件变更	必须使用 /plan 工作流——绝不要在没有计划的情况下修改多个文件
代码分析 / 学习	直接让 Claude 分析——无需计划
调试	提供错误消息 + 文件路径 + 相关代码——询问根本原因

提示词技巧

应该这样做

• 提供具体路径：“修改 src/MyToken.sol 中的 _transfer 函数”
• 给出示例：“输入：100 个代币；预期：扣除 5% 手续费后剩余 95 个代币”
• 设定边界：“只修改这个函数，不要动其他代码”
• 引用测试：“修复后应能通过 test_transfer_feeDeduction”

避免这样做

• 含糊的指代：“修改那个 transfer 函数”——哪个函数？在哪里？
• 没有限制条件的开放式请求：“让它变得更好”
• 在一条消息中提出多个无关任务

消除歧义——指令不明确时

当用户的指令含糊、开放式，或可能有多种解释时，不要猜测后直接执行。应主动分析指令，并在采取行动前列出所有可能的解释供用户确认。

触发条件

当指令符合以下任一模式时，启动消除歧义流程：

模式	示例
未指定目标	“优化一下”——优化什么？
可能涉及多个范围	“加个检查”——哪个函数？检查什么？
边界不明确	“改一下权限”——添加还是移除？针对哪个角色？
上下文隐含	“跟上次一样处理”——“上次”指什么？
存在冲突的可能性	“处理一下安全问题”——哪个漏洞？需要达到什么程度？

分析维度

检测到歧义时，从以下维度进行分析：

1. 范围——可能影响哪些文件 / 合约 / 函数？
2. 操作——预期进行什么操作？（添加 / 修改 / 删除 / 重构 / 修复）
3. 技能匹配——哪些技能相关？将每种解释映射到适用的 /skill
4. 影响——每种解释可能产生哪些副作用？
5. 约束——用户可能默认了哪些隐含边界？

输出格式

以编号列表的形式呈现分析结果：

我检测到你的指令存在多种可能的解读，在开始之前需要确认边界：

**可能的解读：**

1. **[解读A]** — [具体描述]
   - 涉及：[files / contracts]
   - 关联 skill：/skill-name
   - 影响范围：[scope]

2. **[解读B]** — [具体描述]
   - 涉及：[files / contracts]
   - 关联 skill：/skill-name
   - 影响范围：[scope]

**请确认：**
- 你想要哪个解读？（可多选）
- 是否有额外的约束条件？

示例

User: "处理一下这个合约的安全问题"

AI: 我检测到你的指令存在多种可能的解读：

1. **运行 Slither 静态分析** — 用 slither MCP 扫描，修复高危问题
   - 关联 skill：/solidity-security
   - 影响范围：仅修复工具检测到的问题

2. **手动安全审计** — 按审计清单逐项检查（重入、权限、输入验证等）
   - 关联 skill：/solidity-audit
   - 影响范围：完整审查，可能涉及较多修改

3. **修复已知漏洞** — 你已知有特定安全问题，需要定位并修复
   - 关联 skill：/solidity-security
   - 影响范围：仅限特定问题

4. **DeFi 安全加固** — 添加防鲸鱼、防闪电贷等保护机制
   - 关联 skill：/defi-security
   - 影响范围：可能改变合约接口

请确认你想要哪个方向？

关键规则

规则	原因
绝不猜测	错误猜测比多问一轮更浪费时间
展示技能关联	将每种解释映射到相关的 /skill，让用户了解会触发哪种工作流
尊重确认	用户说“就按第 2 个来” → 立即执行，不再追问
根据上下文跳过	如果对话历史已经消除了歧义，就跳过此流程，直接执行

元提示——出错时

当 Claude 的回复不尽如人意时，不要只是换种说法再试。使用元提示（反向提示），让 Claude 诊断问题所在，然后在补全上下文后重新提问。

四种提示词类型

类型	使用时机	模板
诊断	答案错误或不完整	"我刚才的提问中缺少了哪些关键信息，导致你没能一次性给出正确答案？请逐条列出。"
改写	不知道如何改进问题	"请帮我重写刚才的问题，补全你认为缺失的上下文，使你能一次性给出正确答案。"
模板	避免下次犯同样的错误	"对于这类问题，我应该提供哪些信息你才能一次性解决？请给我一个提问模板。"
预检查	Claude 开始工作之前	"在你开始写代码之前，列出你还需要我提供的所有信息。"

推荐流程

Step 1: Ask your question
        ↓ (answer is wrong or incomplete)
Step 2: Use [Diagnose] — "我的问题中缺少了什么？"
        ↓ (Claude lists missing info)
Step 3: Use [Rewrite] — "帮我重写这个问题"
        ↓ (Claude outputs a complete, self-contained prompt)
Step 4: Copy the rewritten prompt, `/clear`, paste and send
        ↓ (clean context + complete prompt = correct answer)

实际示例

# Round 1 — incomplete question
User: "帮我写一个 staking 合约"
Claude: (generates a basic staking contract, but missing reward logic)

# Round 2 — diagnose
User: "我刚才的提问中缺少了哪些信息？"
Claude: "你没有说明：
  1. 质押代币和奖励代币是否相同
  2. 奖励分发机制（按时间/按区块/固定APR）
  3. 是否需要锁仓期
  4. 是否需要紧急提取功能
  5. 管理员权限范围"

# Round 3 — rewrite
User: "帮我重写这个问题"
Claude: "请帮我写一个 Staking 合约，要求如下：
  - 质押代币：ERC20 TOKEN_A，奖励代币：ERC20 TOKEN_B
  - 奖励机制：按质押时长线性释放，年化 12%
  - 锁仓期：7 天最短锁仓
  - 紧急提取：支持，但扣除 10% 罚金
  - 管理员：可更新奖励率，不可触碰用户质押资金
  - 安全：使用 ReentrancyGuard + SafeERC20
  请基于 OpenZeppelin 5.x，Solidity ^0.8.20，Foundry 项目结构。"

# Round 4 — /clear, paste rewritten prompt, get correct result

核心原则

不要猜测自己遗漏了什么——让 Claude 告诉你。 一轮元提示词就能省去多轮试错。

更正后的规则

• 每次纠正错误后，都要以这句话结尾："Update your CLAUDE.md so you won't make the same mistake again." 这样可以将经验教训保存到项目记忆中，防止未来会话中再次出现同样的错误。

Git 操作规则

• 提交前始终运行 git diff 以检查更改
• 只提交——除非明确要求，否则不要推送
• 切勿直接推送到 main/master 分支
• 仅暂存指定文件——在 Solidity 项目中切勿使用 git add .（有提交 .env 的风险）

Foundry 专用工作流

操作	命令
提交前	forge fmt && forge test
修改合约后	使用 forge build 检查编译
PR 前	使用 forge test --gas-report 检查 Gas 影响
调试失败的测试	使用 forge test --match-test <name> -vvvv 查看完整跟踪

快速命令参考

命令	用途
/clear	清除上下文，重新开始
/plan	进入规划模式——修改前先分析
/help	查看所有可用命令
/compact	压缩上下文（建议改用 /clear）

项目级配置

在项目根目录中创建 .claude/instructions.md，写入项目专属规则。Claude 会在每次对话开始时自动读取，无需手动加载。