大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



我在 Amazon、Disney 和 Capital One 担任软件工程师已有 7 年。我上线的代码服务数百万用户，我构建的系统不容有失。现在，我是一家为企业构建 AI 智能体的初创公司的 CTO，而 Claude Code 是我的日常主力工具。

这是一份你可能会觉得有用的新手指南，其中包含了我使用 Claude 构建能够处理大公司复杂工作负载的稳健系统后所学到的一切。

大多数人认为，使用 Claude Code 和其他 AI 工具时，首先需要做的就是打字（或开始说话）。但这可能是新手最容易踩的坑。实际上第一步应该是思考。

十次里有十次，我使用 plan mode 得到的输出都比我直接开口、一股脑地将所有想法灌输给 Claude Code 的结果要好得多。两者效果天差地别。

对某些人来说，这可能说起来容易做起来难。你可能没有多年的软件工程经验，让你能够独立思考这些问题。对此，我有两条建议：

1. 开始学习。哪怕一次只学一点点，如果你从不掌握编程技能，就是在给自己设置障碍。
2. 与 ChatGPT/Gemini/Claude 进行深入的来回交流，在其中你精确地描述你想构建什么，向大语言模型 (LLM) 询问在系统设计方面有哪些不同的选项，最终你们共同敲定一个解决方案。你和 LLM 应该互相提问，而不是单向输出。

这一点适用于所有事情。这也包括像总结邮件这样非常小的任务。在你要求 Claude 构建一个功能之前，先思考一下架构。在你要求它重构某些东西之前，先思考一下最终状态应该是什么样子。在你要求它调试之前，先思考一下你对问题真正了解多少。你在 plan mode 中提供的信息越多，你的输入质量就越高，因此你的输出质量也就会越好。

这个模式是统一的：先思考，再输入，这比先输入然后期望 Claude 自己搞明白，能产生好得多的结果。

这就引出了我的下一点：架构。架构设计，尤其是在软件工程中，有点像只给一个人最终的输出结果，而没有提供任何其他信息。这为如何达到这个输出结果留下了巨大的操作空间，而这基本上就是 AI 生成代码的问题所在。如果你说一句像「给我构建一个认证系统」这样非常宽泛的话，而不是「使用已有的 User 模型构建电子邮件/密码认证，使用 Redis 存储会话，有效期为 24 小时，并添加中间件来保护 /api/protected 下的所有路由」，你就能看出其中的差别。

只需要两次 shift + tab，就进入了 plan mode。相信我，这只会花费你 5 分钟的时间，但会为你节省后续数小时的调试时间。

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 知道什么是 components。告诉它那些特殊的东西，比如真正重要的 bash 命令。所有属于你工作流程的部分都应该放进去。

告诉它为什么，而不仅仅是什么。 Claude 在这方面有点像人类。当你给出一条指令背后的原因时，Claude 会比你只告诉它做什么执行得更好。「使用 TypeScript 严格模式」是可以的。「使用 TypeScript 严格模式，因为我们曾遇到过由隐式 any 类型引起的生产环境 bug」则更好。「为什么」为 Claude 提供了上下文，以便它能做出你未曾预料到的判断。你会惊讶于这实际上是多么有效。

持续更新。 在工作时按下 # 键，Claude 会自动将指令添加到你的 CLAUDE.md 中。每当你发现自己第二次纠正 Claude 同一个问题时，这就是一个信号，说明它应该被写进这个文件里。随着时间的推移，你的 CLAUDE.md 会成为一份关于你代码库实际工作方式的动态文档。

糟糕的 CLAUDE.md 像是为新员工编写的文档。而优秀的 CLAUDE.md 则像是你为明天会失忆的自己留下的笔记。

例如，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 是无状态的。每次对话都是从零开始，除了你明确给它的东西。请根据这一点进行规划。

人们花费数周时间学习框架和工具，却花零时间学习如何与那个实际在为他们生成代码的东西进行沟通。

提示词并非某种神秘艺术。它可能是最基础的沟通形式。和任何沟通一样，清晰的表达比含糊其辞能获得更好的结果。每一次都是如此。

真正有效的方法是：

具体说明你想要什么。 「构建一个认证系统」给了 Claude 它会滥用的创作自由。「使用这个已有的 User 模型构建电子邮件/密码认证，将会话存储在 Redis 中，并添加中间件来保护 /api/protected 下的路由」则给了 Claude 一个明确的目标。即使这样也还不是完美的。

告诉它不要做什么。 Claude 有其倾向性。特别是 Claude 4.5 喜欢过度工程化——额外的文件、不必要的抽象、你并未要求的多余灵活性。如果你想要一些极简的东西，就说「保持简单。不要添加我没要求的抽象。如果可能，只用一个文件。」另外，一定要交叉检查 Claude 生成的内容，因为你不想最终留下技术债，特别是当你正在构建一个非常简单的东西，而它却为一项实际上只需几行代码就能解决的任务创建了 12 个不同的文件时。

你必须记住的一点是，AI 的设计初衷是加速我们的工作，而不是完全取代我们，尤其是在高度专业的软件工程时代。Claude 仍然会犯错。我确信它会继续犯错，即使它会随着时间的推移变得越来越好。因此，能够识别这些错误将真正解决你的许多问题。

给出关于「为什么」的背景信息。 「我们需要这个功能速度快，因为它在每个请求上都会运行」会改变 Claude 解决问题的方式。「这是一个我们之后会丢弃的原型」则会改变哪些权衡是合理的。Claude 无法读懂你心中那些未曾提及的约束条件。

记住：输出决定一切，但它只来源于输入。如果你的输出很糟糕，那说明你的输入就很糟糕。这是无法回避的。

当人们得到不好的结果时，他们会责怪模型。「Claude 不够聪明」或者「我需要一个更好的模型。」

现实是：是你自己不行。如果你用像 Opus 4.5 这样的好模型却得到糟糕的输出，那就意味着你的输入和你的提示词很糟糕。就是这样。

模型很重要。实际上，非常重要。但模型质量此时已是基本门槛。瓶颈几乎总是在人类这边：你如何组织你的提示词，你如何提供上下文，你如何清晰地传达你真正想要的东西。

如果你持续得到不好的结果，解决方法不是换模型。解决方法是提升以下方面的能力：

你编写提示词的方式。 具体 > 模糊。约束 > 开放式。示例 > 描述。

你组织请求的方式。 将复杂任务分解为步骤。在实施前先就架构达成一致。审查输出并进行迭代。

你提供上下文的方式。 Claude 需要知道什么才能做好这件事？你做了哪些 Claude 看不到的假设？

话虽如此，不同模型之间确实存在差异：

Sonnet 更快、更便宜。它非常适合执行路径清晰的任务——编写样板代码、根据具体计划进行重构、实现你已经做出架构决策的功能。

Opus 更慢、更贵。它更擅长复杂推理、规划以及需要 Claude 深入思考权衡的任务。

一个有效的工作流程是：使用 Opus 进行规划和架构决策，然后切换到 Sonnet（在 Claude Code 中按 Shift+Tab）进行实现。这将取决于你的任务，有时你也可以使用 Opus 4.5 进行实现。不过，如果你通过 API 使用量计费，那成本会非常高。你的 CLAUDE.md 确保了两个模型在相同的约束下运行，因此交接过程是顺畅的。

Claude 拥有数量惊人的功能。MCP 服务器、Hooks、自定义斜杠命令、Settings.json 配置、Skills、Plugins。

你不需要全部都用。但你真的应该去尝试和实验，因为如果你不实验，你可能正在浪费时间或金钱。我保证 Claude 至少有一个你不知道的新功能正在推出，如果你关注 Claude Code 的创始人 Boris，你就能了解到。

MCP 让 Claude 能够连接到外部服务。Slack、GitHub、数据库、API。如果你发现自己经常把信息从一个地方复制到 Claude，那很可能有一个 MCP 服务器可以自动完成这件事。有大量的 MCP 市场，如果没有现成的 MCP，它也只是一种获取结构化数据的方式，所以你可以为你需要的任何尚不存在的工具创建自己的 MCP 服务器。不过，如果你真的发现了一个不存在的 MCP，我会非常惊讶。

Hooks 让你可以在 Claude 做出更改之前或之后自动运行代码。想让 Prettier 格式化每个克劳德接触的文件？用 Hook。想在每次编辑后进行类型检查吗？用 Hook。这能立即发现问题，而不是让它们堆积起来。这实际上也有助于消除技术债。如果你在每千行代码后设置一个特定的 hook，你就有可能让一个安全功能来清理你的代码。当 Claude 审查你的 PRs 时，这应该会非常有帮助。

自定义斜杠命令 只是你重复使用的提示词，被打包成了命令。创建一个 /.claude/commands 文件夹，在里面添加带有你提示词的 markdown 文件，现在你就可以用 /commandname 来运行它们了。如果你经常运行同一种任务——调试、审查、部署——就把它做成一个命令。

如果你拥有 Pro Max 计划，为什么不尝试 Claude 提供的所有功能呢？看看哪些有效，哪些无效。反正你已经为此付费了。

而且要注意一点：如果某项功能第一次尝试不成功，不要就此放弃。这些模型基本上每周都在改进。一个月前行不通的东西，现在可能就可以了。作为早期采用者，意味着保持好奇心并重新测试事物。

有时 Claude 会陷入循环。它尝试同样的事情，失败，再试，再失败，然后继续下去。或者它自信地实现了一些完全错误的东西，而你花了二十分钟试图解释为什么。

当这种情况发生时，人的本能是继续施压。更多的指令。更多的修正。更多的上下文。但现实是，更好的做法是完全改变方法。

从简单的开始——清空对话。 累积的上下文可能正在迷惑它。/clear 给你一个全新的开始。

简化任务。 如果 Claude 在一个复杂任务上挣扎，就把它分解成更小的部分。在将它们组合起来之前，先让每个部分都能正常工作。但实际上，如果 Claude 在一个复杂任务上挣扎，那意味着你的 plan mode 是不充分的。

展示而非告知。 如果 Claude 一直误解你想要什么，就自己写一个最小化的例子。「这是输出应该看起来的样子。现在把这个模式应用到其余部分。」Claude 非常擅长理解成功指标是什么样的，并且能够真正遵循一个好的例子。

发挥创造力。 尝试一个不同的角度。有时候你构建问题的方式并不适合 Claude 的思维方式。重新构建问题——比如用「将此实现为一个状态机」替代「处理这些转换」——可能会打开僵局。

这里的元技能是及早识别出你正陷入循环。如果你已经解释了同一件事三次，而 Claude 还是不明白，更多的解释是无济于事的。改变点什么吧。

从 Claude 中获得最大价值的人不是用它来完成一次性的任务。他们正在构建以 Claude 为组件的系统。但 Claude Code 的能力远不止于此。它有一个用于无头模式的 -p 标志。它会运行你的提示词并输出结果，而无需进入交互式界面。这意味着你可以用脚本来控制它。将输出通过管道传递给其他工具，用 bash 命令将其链接起来，将其集成到自动化工作流中。

企业正在用它来进行自动 PR 审查、自动支持工单回复、自动日志记录和文档更新。所有这些都被记录、可审计，并根据有效和无效的经验随时间不断改进。

这种飞轮效应体现在：当 Claude 犯了一个错误，你审查日志，改进 CLAUDE.md 或工具，Claude 下次就会做得更好。这种改进会产生复利效应。不过，我现在正在研究如何让 Claude 能够自己改进它的 Claude.md 文件。经过数月的迭代，以这种方式构建的系统比刚上线时有了显著的提升——用的是相同的模型，只是配置得更好。

如果你只在交互模式下使用 Claude，那你就在浪费它的价值。思考一下在你的工作流程中，哪些地方可以让 Claude 在无人监控的情况下运行。

• 先思考，再输入。 规划比直接开始对话能产生好得多的结果。
• CLAUDE.md 是你的杠杆点。 保持简短、具体，告诉它为什么，并持续更新。这一个文件影响着每一次交互。
• 上下文在 30% 时就开始退化，而不是 100%。 使用外部记忆，限定对话范围，不要害怕使用复制-粘贴重置技巧来清空和重启。
• 架构比任何事情都重要。 你不能跳过规划。如果你不先仔细考虑结构，输出就会很糟糕。
• 输出源于输入。 如果你用一个好的模型却得到糟糕的结果，那你的提示词需要改进。提升你的沟通能力。
• 实验工具和配置。 MCP、hooks、斜杠命令。如果你正在为 Pro Max 付费，就去尝试一切。即使事情第一次不成功也要保持好奇。
• 当卡住时，改变方法。 不要循环。清空、简化、展示、重新构建问题。
• 构建系统，而非一次性使用。 无头模式、自动化、随时间记录并改进。

无论你是在用 Claude 构建个人项目还是生产系统，这些原则将决定你是在与工具对抗还是与之流畅协作。