附录 C 提示词速查表
| 场景 |
提示词模板 |
难度 |
| 新项目探索 |
给我一个这个代码库的概览 |
🟢 |
| 理解架构 |
解释 @src/auth 目录的认证架构 |
🟢 |
| 查找代码 |
找到处理用户认证的文件 |
🟢 |
| Bug 修复 |
错误信息: [粘贴]。找到根因，写失败测试，修复它 |
🟢 |
| 写测试 |
为 @path/to/file 编写测试，覆盖边界情况。不用 mock |
🟢 |
| 代码审查 |
审查 @path/to/file 的安全性、性能和一致性 |
🟢 |
| 重构 |
将 @path/to/file 重构为使用 [新模式]，保持行为不变 |
🟡 |
| 创建 PR |
用描述性消息提交更改并创建 PR |
🟢 |
| 性能分析 |
分析 @path/to/file 的性能瓶颈并建议优化 |
🟡 |
| 文档生成 |
为 @src/api/ 的公共函数添加 JSDoc 注释 |
🟢 |
| 子代理调查 |
用子代理调查 [模块A] 和 [模块B] 的交互 |
🟡 |
| 并行研究 |
使用独立的子代理并行研究 [A]、[B]、[C] |
🔴 |
| 采访模式 |
我想构建 [功能]。用 AskUserQuestion 对我进行详细采访 |
🟡 |
| 挑战方案 |
grill me on these changes and don’t make a PR until I pass your test |
🟡 |
| 证明有效 |
prove to me this works. diff main 和 feature branch 的行为差异 |
🟡 |
| 推倒重来 |
knowing everything you know now, scrap this and implement the elegant solution |
🟡 |
| 零切换修 Bug |
这是 Slack 上的 bug report：[粘贴]。Fix it. |
🟡 |
| 修 CI |
Go fix the failing CI tests. |
🟢 |
| 并行算力 |
[你的请求]。Use subagents. |
🟡 |
| Git 历史 |
查看 @file 的 git 历史，总结它的 API 如何演变 |
🟡 |
| 深度思考 |
/model → 调高 effort level → 输入复杂任务描述 |
🔴 |
| 批量 Lint |
claude -p “检查相对 main 的变更，报告拼写错误” |
🔴 |
附录 D 精选资源
官方文档（必读）
| 资源 |
说明 |
| Best Practices |
官方最佳实践，本文档的主线来源 |
| CLAUDE.md 指南 |
记忆系统详解 |
| 常用工作流 |
调试、测试、PR 等实操指南 |
| Hooks 指南 |
钩子系统详解 |
| Skills 系统 |
自定义技能详解 |
| Sub-agents |
子代理详解 |
| Settings |
完整配置参考 |
| GitHub Actions |
CI/CD 集成 |
| 功能扩展总览 |
Skills/Hooks/MCP/Subagents 选择指南 |
官方博客
| 资源 |
说明 |
| How Anthropic Teams Use Claude Code |
内部团队案例 |
| Using CLAUDE.md Files |
CLAUDE.md 使用指南 |
| Skills explained |
Skills 与 Prompts、Projects、MCP、Subagents 的对比 |
社区精选
| 资源 |
说明 |
| everything-claude-code |
完整配置集合（50K+ Stars） |
| claude-code-best-practice |
practice made claude perfect |
| Boris Cherny’s Workflow (Thread 1) |
Claude Code 之父Boris的的工作流分享（12 条推文） |
| Boris Cherny’s Tips (Thread 2) |
Claude Code 之父Boris的进阶技巧分享 |
| Boris Cherny’s Tips (Thread 3) |
Claude Code 之父Boris的最新实践分享 |
| Shipping Faster with Worktrees |
http://incident.io 的 worktree 实战 |
附录 E 使用哲学速查卡
核心心法
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| 1. 验证 > 信任
给 Claude 验证手段，不要盲目信任输出
2. 上下文是最贵的资源
/clear 是你最好的朋友，子代理是你的上下文防火墙
3. 具体 > 模糊
一次精准的指令胜过三次模糊的修正
4. 先探索再编码
Plan Mode 不是开销，是投资
5. 配置是长期杠杆
在 CLAUDE.md / Hooks / Skills 上花的时间，每次会话都在回报你
6. 预批准而非跳过权限
/permissions 白名单 > --dangerously-skip-permissions
7. 犯错后更新规则
每个错误都是改进 CLAUDE.md 的机会
|
成长路径速览
Boris Cherny Pro Tips 索引
| 编号 |
Tips |
章节 |
| B1 |
Opus + High Effort for everything |
1.2 |
| B2 |
验证是 2-3x 质量的关键 |
3.1 |
| B3 |
Plan Mode 是基础而非可选 |
4.1 |
| B4 |
语音输入（fn×2）比打字快 3x |
5.2 |
| B5 |
团队共维 CLAUDE.md + @claude 更新 |
6.1 |
| B6 |
/permissions 预批准而非 skip |
6.2 |
| B7 |
PostToolUse Hook 自动格式化 |
6.5 |
| B8 |
/commit-push-pr 每天几十次 |
6.6 |
| B9 |
挑战式提示 “grill me” / “prove to me” / “elegant solution” |
7.3 |
| B10 |
5 个并行 Claude + 系统通知 + –teleport 拉回本地 |
8.7 |
| B11 |
3-5 worktrees、42h 最长运行、analysis worktree |
9.5 |
| B12 |
犯错后让 Claude 更新 CLAUDE.md |
10.3 |
| B13 |
每个人的 statusline 都不一样 |
6.9 |
发展你的直觉
本指南中的模式不是一成不变的——它们是在一般情况下有效的起点。
有时你应该让上下文积累，因为你正在深入一个复杂问题，历史记录很有价值。有时你应该跳过计划直接让 Claude 动手，因为任务是探索性的。有时模糊的提示才是正确的，因为你想看看 Claude 如何解读问题。
注意观察什么有效。当 Claude 产出优秀结果时，回忆你做了什么：提示词结构、提供的上下文、使用的模式。当 Claude 挣扎时，问为什么：上下文太嘈杂？提示词太模糊？任务太大不适合一轮完成？
随着时间推移，你会发展出任何指南都无法捕捉的直觉——你会知道何时该具体、何时该开放，何时该计划、何时该探索，何时该清空上下文、何时该让它积累。