作为一名长期使用Claude Code的开发者，我在与这款工具的互动中逐渐意识到：大多数人对AI代码助手的使用方式，本质上是一种"被动倾倒"。
他们期待Claude像魔法一样理解模糊的需求，殊不知最大的瓶颈往往不在模型本身，而在于我们如何与它沟通。
这是一份来自亚马逊、迪士尼等顶级科技公司前工程师Eyad的实战指南
这份指南吸引了200万围观和近7000次点赞，核心观点值得每一位使用Claude的开发者深思。
一、规划优先于执行
最常见的误区是：打开Claude Code就开始输入。实际上，这是最低效的用法。
正确的流程是：思考架构 → 规划方案 → 进入规划模式 → 清晰表述需求。在"规划模式"（按Shift+Tab两次进入）中提供的信息质量，直接决定了输出质量。这个过程看似浪费5分钟，却能节省后续数小时的调试时间。
对比示例：
- ❌ 模糊需求："给我建一个认证系统"
- ✅ 清晰需求："基于现有User模型实现邮箱/密码认证，将session存储在Redis中设置24小时过期，并添加中间件保护/api/protected下的所有路由"
两种表述方式下，Claude的输出质量差异巨大。
二、CLAUDE.md——你的项目说明书
将CLAUDE.md视为Claude在每次对话前必读的"入职材料"。
这个Markdown文件会直接影响它对整个项目的理解方式。
编写CLAUDE.md的四大要素：
| 要素 | 原则 | 说明 |
|---|---|---|
| 长度控制 | 150-200条指令为上限 | Claude系统提示已占50条，过多指令会导致随机忽略 |
| 内容针对性 | 只记录项目特有的规则 | 不要解释通用概念，记录那些真正重要的bash命令和工作流 |
| 解释原因 | "为什么"比"做什么"更重要 | 例：不只说"使用TypeScript严格模式"，要说"因为隐式any类型曾导致生产bug" |
| 持续更新 | 活文档，不是一次性文件 | 发现第二次纠正同一问题，就应该写进文件 |
好的CLAUDE.md看起来像：你为"失忆后的自己"留下的笔记，而不是为新员工写的文档。
三、上下文窗口的隐性衰退
Opus 4.5有20万token的上下文窗口，但鲜为人知的是：模型性能在达到20-40%使用率时就已开始衰退。
这解释了为什么有时即使执行了/compact命令，输出仍然糟糕——因为衰退早已发生。
防止上下文质量下降的策略：
- 限定对话范围：每个功能使用独立对话。不要在同一对话中既构建认证又重构数据库
- 使用外部记忆：让Claude将计划写入SCRATCHPAD.md或plan.md，跨会话持久保存
- 复制-粘贴重置法：当上下文臃肿时，运行/compact获得摘要，然后/clear清空，只粘贴关键信息。这优于让Claude在退化的上下文中挣扎
- 及时清空：十次中有九次，/clear是更好的选择。Claude仍会读取CLAUDE.md，所以项目上下文不会丢失
心智模型：Claude是无状态的。每次对话从零开始，除了你明确提供的信息。
四、Prompt工程即沟通能力
人们花数周学习框架，却花零时间学习如何与代码生成工具沟通。
Prompt工程并非神秘艺术，它就是最基本的沟通形式——清晰明确总优于含糊不清。
三大有效做法：
- 具体说明目标："构建认证系统"给Claude过度的创作自由；而"使用现有User模型、Redis存储session、保护/api/protected路由"给了清晰目标
- 说明不该做什么：Claude 4.5倾向过度工程化。直言："保持简单，不要添加未要求的抽象，优先单文件方案"
- 提供背景信息："这个功能在每个请求上运行，需要快速"会改变Claude的解决方式；"这是会被丢弃的原型"则改变它的权衡考量
核心原则：输出源于输入。坏输入必然导致坏输出。
五、模型选择与工作流
不同模型适配不同场景，无需盲目追求最强模型：
| 模型 | 特点 | 适用场景 |
|---|---|---|
| Sonnet | 快速、便宜 | 路径明确的任务——样板代码、按计划重构、实现已定方案 |
| Opus | 慢速、昂贵 | 复杂推理、架构规划、需要权衡分析的任务 |
高效工作流：用Opus进行规划和架构决策，切换到Sonnet（Shift+Tab）进行实现。
CLAUDE.md确保两个模型在相同约束下运作，使交接顺畅。
六、当Claude卡住时的破局方法
Claude有时会陷入循环——重复尝试同样的失败方案，或自信地实现完全错误的东西。
人的直觉是提供更多指令，但正确做法是改变方法：
- 清空对话（/clear）：累积的上下文可能造成混淆，全新开始往往更有效
- 分解任务：将复杂问题拆成小部分，逐个验证。如果Claude在复杂任务上挣扎，通常说明规划模式做得不充分
- 展示范例：自己写最小化例子。"输出应该长这样，现在把这个模式应用到其余部分"——Claude擅长从成功范例推广
- 重新表述问题：有时是表述方式与Claude的"思维"方式不匹配。比如从"处理状态转换"改为"实现状态机"可能打开僵局
及早识别循环：如果同一件事解释了三遍Claude仍不理解，更多解释无济于事——改变方法才是关键。
七、从一次性任务到系统化流程
从Claude获得最大价值的做法，不是完成一次性任务，而是将Claude构建成系统的组件。
无头模式的力量：Claude Code的-p标志支持无头模式，可运行Prompt并输出结果，无需交互界面。这使得：
- 用脚本调用Claude，与bash命令链接
- 集成到自动化工作流（自动PR审查、支持工单回复、日志更新）
- 所有操作被记录和审计
- 形成飞轮效应：错误 → 审查日志 → 改进CLAUDE.md → 下次更佳
复合改进：如果只在交互模式使用Claude，就在浪费它的潜力。思考工作流的哪些环节可以让Claude无监督运行。
八、工具与配置的实验
Claude提供MCP服务器、钩子、自定义命令等丰富功能。
如果是付费用户（如Pro Max月付200美元），应该系统地尝试：
- MCP (Model Context Protocol)：连接Slack、GitHub、数据库。如果发现自己频繁复制信息到Claude，可能有对应MCP能自动完成
- 钩子（Hooks）：在Claude修改前后自动运行代码。如Prettier自动格式化、每次编辑后类型检查，及时捕获问题
- 自定义斜杠命令：重复使用的Prompt打包成命令，存储在.claude/commands文件夹中
重要提示：不要因第一次失败就放弃——这些模型几乎每周改进，一个月前行不通的，现在可能就可行。
总结
经过深入使用和研究Claude Code，我的核心体会是：模型的能力上限远高于我们的使用上限。
如果你持续得到糟糕的输出，问题不在Claude，而在于：
- 你的规划模式是否充分（先思考，后动手）
- 你的CLAUDE.md是否准确反映项目特性（杠杆点）
- 你的Prompt是否足够具体（沟通能力）
- 你是否及早识别并打破循环（破局意识）
- 你是否将Claude从一次性工具升级为系统组件（价值释放）
瓶颈几乎总是在人这一边。投资在这些能力上，远比等待更好的模型更有收益。
我现在的工作流已经能让Claude在很大程度上自我改进，这正是将AI从生产力工具升级为生产力乘数的转折点。
原文地址：https://x.com/eyad_khrais/status/2010076957938188661?s=20