🐒 大家好，我是阿衡，一年经验用了十次的游戏后端开发，辞职后成为自由职业、独立游戏开发者。 非专业 AI 玩家，日常关注 AI 编程方向的内容。
👀 原文地址：x.com/eyad_khrais…
我做了 7 年软件工程师，在 Amazon、Disney 和 Capital One 工作过。我发布的代码服务数百万用户，构建的系统不容有失。现在我是一家企业 Agent 初创公司的 CTO，Claude Code 是我的日常开发工具。
这里是一份新手教程，包含我使用 Claude 构建稳定系统（处理大公司复杂工作负载）过程中学到的所有经验。如果对你有帮助，欢迎在下方留言反馈。
先思考
大多数人认为使用 Claude Code 和其他 AI 工具时，第一件事是开始打字（或说话）。但这可能是你一开始就会犯的最大错误之一。你真正需要做的第一件事是思考。
十次里有十次，我使用 Plan Mode（规划模式）得到的输出都显著优于直接开始说话并将所有内容倾倒给 Claude Code。这根本没法比。
对某些人来说，说起来容易做起来难。你可能没有多年软件工程经验来独立思考这些问题。对此我有两条建议：
- 开始学习。如果你永远不掌握这一点，你就是在自我限制，哪怕每次只学一点点。
- 与 ChatGPT/Gemini/Claude 进行深入对话，详细描述你想构建的内容，询问 LLM 在系统设计上可以采取的各种方案，最终两者一起敲定解决方案。你和 LLM 应该相互提问，而不是单向沟通。 这适用于所有事情。即使是总结邮件这样的小任务也一样。在让 Claude 构建功能之前，先思考架构。在让它重构代码之前，先思考最终状态应该是什么样。在让它调试之前，先思考你对问题的实际了解。在 Plan Mode 中信息越充分，输出就越好，因为输入会更好。
规律是一致的：先思考再打字，产生的结果远远好于先打字再希望 Claude 能搞明白。
这就引出我的下一个要点：架构。 架构，尤其在软件工程中，有点像只给一个人结果，其他什么都不说。这会在如何达成结果上留下大量模糊空间，这本质上就是 AI 生成代码的问题所在。如果你说一些超级宽泛的东西，比如"给我构建一个认证系统"，而不是"使用现有的 User 模型构建邮箱/密码认证，将 Session 存储在 Redis 中并设置 24 小时过期，添加中间件保护所有 /api/protected 下的路由"，你能看出区别。
按两次 Shift + Tab，你就进入了 Plan Mode。相信我，这只会占用你 5 分钟时间，但会为你节省数小时的调试时间。
CLAUDE.md
CLAUDE.md 是一个 Markdown 文件。Markdown 是一种文本格式，AI 模型处理起来极其高效，而 Claude 处理它的能力比我测试过的大多数其他模型都要好。
当你启动 Claude Code 会话时，Claude 做的第一件事就是读取你的 CLAUDE.md 文件。该文件中的每条指令都会影响 Claude 如何处理你的项目。它本质上是 Claude 在每次对话前都会阅读的入职材料。
大多数人要么完全忽略它，要么塞满垃圾内容，让 Claude 变得更糟而不是更好。有一个阈值：信息太多或太少都意味着更差的模型输出。
以下是真正重要的内容：
保持简短。 Claude 一次只能可靠地遵循大约 150 到 200 条指令，而 Claude Code 的系统提示已经使用了其中约 50 条。你添加的每条指令都在争夺注意力。如果你的 CLAUDE.md 像小说一样长，Claude 会开始随机忽略内容，而你不会知道它忽略了哪些。
针对你的项目具体化。 不要解释 components 文件夹是什么，Claude 知道组件是什么。告诉它那些奇怪的东西，比如真正重要的 Bash 命令。你工作流程中的所有内容都应该放进去。
告诉它为什么，而不仅仅是做什么。 Claude 在这方面有点像人类。当你给它指令背后的原因时，Claude 的实现效果比你只是告诉它做什么要好。
"使用 TypeScript strict 模式"——还可以。 "使用 TypeScript strict 模式，因为我们曾因隐式 any 类型在生产环境出现过 Bug"——更好。 这个"为什么"为 Claude 提供了上下文，让它能在你没有预料到的情况下做出判断。你会惊讶于这实际上有多有效。 持续更新它。 在工作时按 # 键，Claude 会自动将指令添加到你的 CLAUDE.md 中。每次你发现自己在同一件事上纠正 Claude 两次，这就是一个信号：它应该被写进文件。随着时间推移，你的 CLAUDE.md 会成为一份记录你代码库实际运作方式的活文档。
糟糕的 CLAUDE.md 看起来像是为新员工写的文档。优秀的 CLAUDE.md 看起来像是你知道自己明天会失忆时给自己留的笔记。
Context Window（上下文窗口）的局限性
例如，Opus 4.5 有 200,000 Token 的上下文窗口。但大多数人没有意识到的是：模型在你达到 100% 之前就开始退化了。 （这取决于你是通过 API 还是桌面应用使用）
在大约 20-40% 的上下文使用率时，输出质量就开始下降，即使不明显。如果你曾经遇到过 Claude Code 压缩后仍然给你糟糕的输出，这就是原因。模型在压缩发生之前就已经退化了，压缩并不能神奇地恢复质量。（使用 /compact 进行压缩）
你发送的每条消息、Claude 读取的每个文件、它生成的每段代码、每个工具结果——所有这些都会累积。一旦质量开始下降，更多上下文会让它变得更糟，而不是更好。所以这里有一些真正有助于避免糟糕上下文的做法：
限定对话范围。 一次对话对应一个功能或任务。不要在同一个对话中既构建认证系统又重构数据库层。上下文会混在一起，Claude 会困惑。我知道你们中至少有一个人读到这里时心虚了。
使用外部内存。 如果你在做复杂的事情，让 Claude 将计划和进度写入实际文件（我使用 SCRATCHPAD.md 或 plan.md）。这些会跨会话保留。当你明天回来时，Claude 可以读取文件并从上次停下的地方继续，而不是从零开始。附注：如果你有文件的层次系统，将这些放在最顶层可以让它们在你决定构建的每个任务/功能中都起作用。
复制粘贴重置。 这是我经常使用的技巧。当上下文变得臃肿时，我从终端复制所有重要内容，运行 /compact 获取摘要，然后 /clear 完全清除上下文，只粘贴回重要的内容。全新的上下文，关键信息保留。这比让 Claude 在退化的上下文中挣扎要好得多。
知道何时清除。 如果对话已经偏离轨道或累积了一堆无关上下文，直接 /clear 并重新开始。这比试图在混乱中工作要好。Claude 仍然会有你的 CLAUDE.md，所以你不会丢失项目上下文。十次里有九次，使用 clear 实际上比不使用更好，尽管这听起来违反直觉。
有效的心智模型：Claude 是无状态的。 每次对话都从零开始，除了你明确给它的内容。相应地做计划。
Prompt（提示词）就是一切
人们花几周时间学习框架和工具，却不花时间学习如何与真正生成代码的东西沟通。
Prompting 不是什么神秘的艺术，它可能是最基本的沟通形式。就像任何沟通一样，清晰表达会比模糊表达得到更好的结果。每次都是如此。
真正有帮助的做法： 对你想要的东西具体化。 "构建一个认证系统"给了 Claude 创作自由，它会用得很糟糕。 "使用这个现有的 User 模型构建邮箱/密码认证，将 Session 存储在 Redis 中，添加中间件保护 /api/protected 下的路由"给了 Claude 明确的目标。即使这样仍然不完美。 告诉它不要做什么。 Claude 有倾向性。Claude 4.5 特别喜欢过度设计——额外的文件、不必要的抽象、你没要求的灵活性。如果你想要简单的东西，就说 "保持简单。不要添加我没要求的抽象。如果可能的话，一个文件搞定。"
另外，始终交叉检查 Claude 生成的内容，因为你不想最终背上技术债，尤其是如果你在构建超级简单的东西，结果它为一个实际上只需几行代码就能解决的任务构建了 12 个不同的文件。
你必须记住的是，AI 的设计是为了加速我们，而不是完全取代我们，尤其在非常专业的软件工程时代。Claude 仍然会犯错误。我确信它会继续犯错误，即使随着时间推移会变得更好。所以能够识别这些错误实际上会解决你的很多问题。
给它关于为什么的上下文。 "我们需要保证这个的效率，因为它在每个请求上运行"——会改变 Claude 处理问题的方式。 "这是一个我们会丢弃的原型"——会改变哪些权衡是合理的。 Claude 无法读懂你没有提到的约束。
记住：输出就是一切，但它只来自输入。 如果你的输出很烂，你的输入就很烂。这无法绕过。
糟糕的输入 == 糟糕的输出
人们在得到糟糕结果时责怪模型。"Claude 不够聪明"或"我需要一个更好的模型。" 现实检查：是你不行。 如果你在使用像 Opus 4.5 这样的好模型时得到糟糕输出，这意味着你的输入和 Prompting 很烂。就这样。
模型很重要，实际上非常重要。但模型质量现在是基本条件，瓶颈几乎总是在人这一边：你如何组织提示词、如何提供上下文、如何清晰地传达你真正想要的东西。
如果你持续得到糟糕的结果，修复方法不是换模型。修复方法是在以下方面变得更好：
如何写提示词。 具体 > 模糊；约束 > 开放式；示例 > 描述。 如何组织请求。 将复杂任务分解为步骤；在实现之前就架构达成一致；审查输出并迭代。 如何提供上下文。 Claude 需要知道什么才能做好这件事？你在做什么 Claude 看不到的假设？
话虽如此，模型之间确实存在真正的差异： Sonnet 更快更便宜。 它非常适合路径清晰的执行任务——编写样板代码、基于特定计划进行重构、实现你已经做出架构决策的功能。 Opus 更慢更贵。 它更适合复杂推理、规划以及需要 Claude 深入思考权衡的任务。
一个有效的工作流程：使用 Opus 进行规划和架构决策，然后切换到 Sonnet（在 Claude Code 中按 Shift+Tab）进行实现。 这取决于你的任务，有时你也可以使用 Opus 4.5 进行实现。不过如果你通过 API 使用，考虑卖肾吧。你的 CLAUDE.md 确保两个模型在相同约束下操作，所以交接是干净的。
MCP、工具和配置
Claude 有大量功能。MCP 服务器、Hooks、自定义 Slash 命令、settings.json 配置、Skills、插件。
你不需要所有这些，但你应该实际尝试和实验，因为如果你不实验，你可能在浪费时间或金钱。我保证 Claude 中至少有一个你不知道的新功能正在推出，如果你关注了 Claude Code 的创始人 Boris，你可以了解到这些。
MCP (Model Context Protocol) 让 Claude 连接到外部服务：Slack、GitHub、数据库、API。 如果你发现自己经常将信息从一个地方复制到 Claude，可能有一个 MCP 服务器可以自动完成。有大量 MCP 市场，如果不存在某个 MCP，它只是一种获取结构化数据的方式，所以你可以为你需要添加的、目前不存在的任何工具创建自己的 MCP 服务器，不过我会非常惊讶你找到了一个不存在的 MCP。
Hooks 让你在 Claude 做出更改之前或之后自动运行代码。 想在 Claude 处理的每个文件上运行 Prettier？Hook。 想在每次编辑后进行类型检查？Hook。 这会立即捕获问题，而不是让它们堆积。这实际上也有助于消除技术债。如果你在每千行代码后设置一个特定的 Hook，这个安全功能就有可能帮你规整代码。当 Claude 帮你审核代码合并请求（PR）时，这个机制应该会非常管用。
自定义 Slash 命令 只是你重复使用的提示词，打包成命令。 创建一个 .claude/commands 文件夹，添加包含你提示词的 Markdown 文件，现在你可以用 /commandname 运行它们。如果你经常运行同一种任务——调试、审查、部署——把它做成一个命令。 如果你有 Pro Max 计划（我付 200 美元/月），为什么不尝试 Claude 提供的所有功能？看看什么有效什么无效。反正你都在付费。
这里有一点：如果某件事第一次没成功，不要气馁。这些模型基本上每周都在改进，一个月前不起作用的东西现在可能能用了。作为早期使用者，就意味着要保持好奇心，并且反复去测试各种功能。
当 Claude 卡住时
有时候 Claude 就是会陷入循环。它反复尝试同样的操作，失败了又重来，如此周而复始。还有的时候，它会信心满满地写出一段完全错误的代码，你得花上二十分钟的时间，去跟它解释错在哪里。
遇到这种情况时，人的本能反应就是继续施压 —— 追加更多指令、补充更多修正意见、提供更多背景信息。但事实是，更有效的做法是彻底更换思路。
可以从简单的步骤做起 —— 清空对话记录。不断累积的上下文信息，很可能已经让它陷入了混乱。输入 /clear 指令，就能开启全新的对话。
简化任务。 如果 Claude 在复杂任务上挣扎，将其分解为更小的部分。在组合它们之前让每个部分都能工作。但实际上，如果 Claude 在复杂任务上挣扎，这意味着你的 Plan Mode 不充分。
展示而不是告诉。 如果 Claude 一直误解你想要什么，自己写一个最小的示例。"这就是输出应该的样子。现在将这个模式应用到其余部分。" Claude 非常擅长理解成功的标准是什么样子，并实际能够遵循它们。
尝试新思路。 尝试不同的角度。有时候，你对问题的表述方式，和 Claude 的理解逻辑根本不匹配。调整一下表述方式就能推进进度，比如把 “处理好这些状态转换”，换成 “把这个功能实现为一个状态机”。
这里面的核心技巧，是尽早识别出自己正在陷入无效循环。如果你已经把同一个问题解释了三遍，Claude 还是没能理解，那再多的解释也是徒劳。此时一定要做出改变。
构建系统
能从 Claude 身上榨取最大价值的人，从来不会只把它用来处理一次性任务。他们会搭建一套系统，让 Claude 成为其中的一个组件。而 Claude 的代码功能，还能发挥出更强大的作用 —— 它自带一个-p参数，可用于启用无界面模式。在这种模式下，它会直接执行你输入的指令并输出结果，无需进入交互式操作界面。这意味着你可以为它编写脚本，将它的输出内容传递给其他工具，与 Shell 命令串联使用，或是把它集成到自动化工作流中。
企业正利用这项功能实现诸多自动化场景：自动审核 PR、自动回复客户支持工单、自动完成日志记录与文档更新。所有操作都会留存日志，可供审计追溯，并且系统会根据实际使用中的成效不断迭代优化。
这里存在一个良性循环：Claude 出现失误后，你查看相关日志，然后优化CLAUDE.md文档或配套工具，下一次 Claude 的表现就会更出色。这种优化效果会不断叠加。
目前我正在推进一项工作，让 Claude 能够自主优化它自身的CLAUDE.md文档。经过数月的迭代打磨，用这种方式搭建的系统，相比最初上线时已经有了质的飞跃 —— 底层模型没有变，只是通过更优的配置实现了升级。
如果你还只停留在交互式使用 Claude 的阶段，那就是在白白浪费它的潜力。不妨思考一下，在你的工作流中，有哪些环节可以让 Claude 在无需人工值守的情况下自动运行。
总结
先思而后行。 规划产生的结果比直接开始说话好得多。CLAUDE.md 是你的杠杆点。保持简短、具体，告诉它为什么，并持续更新。这一份文档，会影响你与 Claude 的每一次交互。
上下文在 30% 就开始退化，而不是 100%。 使用外部记忆、限定对话范围，不要害怕清除，使用“复制粘贴重置”技巧重新开始。
架构比什么都重要。 你不能跳过规划。如果一开始就没琢磨清楚整体结构，最终产出的结果肯定不尽如人意。
输出质量取决于输入质量。 如果你在使用好模型时得到了糟糕的结果，你的 Prompting 需要改进，要学着更精准地传达需求。
尝试工具和配置。 MCP、Hooks、Slash 命令。既然订阅了 Pro Max 付费版，就该把所有功能都摸索一遍。即便初次尝试屡屡碰壁，也要保持好奇心。
**陷入僵局时，及时调整思路。**切勿陷入无效循环。记住这几个办法：清空对话、简化任务、示范引导、重构表述。
构建系统，而不是一次性任务。 Headless 模式、自动化、依托日志记录实现长期的迭代优化。
无论你是用 Claude 开发个人项目，还是搭建生产级系统，以上这些原则，将决定你是在跟工具较劲，还是在顺势而为。
💬 你平时是怎么使用 Claude Code 的？欢迎在评论区分享你的方法和感悟。
👍 觉得有用的话，记得点赞收藏，让更多人看到这篇文章。
我们下期见。
#公众号：阿衡的AI日常
#小红书：阿衡的AI日常
#CSDN：DebugEve
#掘金：阿衡Eve
