TLDR
-
打字前先想想。plan 模式产生的结果比一上来就给出实现的 prompt要好得多。
-
CLAUDE.md是您的杠杆点。保持简短、具体，说明原因，并不断更新。这个文件会影响每一次交互效果。 -
上下文降级为30%，而不是100%。使用外部存储，圈定会话范围，不要害怕使用复制粘贴重置技巧去清除并重新启动一个新的会话。
-
架构思维比什么都重要。你不能跳过 plan 步骤。若你们不先考虑结构，输出就会很差。
-
输出来自输入。如果你用一个好的模型得到了糟糕的结果，那就证明你的 prompt 写得有问题了。得好好钻研一下 prompt 工程了。
-
尝试使用工具和配置。MCP、 hook 、斜线命令等等。如果你为Pro Max付费，尝试一切。即使事情第一次不起作用，也要保持好奇心。
-
遇到困难时，学会换个角度去思考并尝试。不要继续钻牛角尖。清除上下文、任务拆分、给出示例、重新来过。
-
构建AI系统，而不是只做一次性任务。无头模式、自动化、随时间记录的改进。
如果你正在使用Claude进行构建——无论是你自己的项目还是生产系统——这些因素决定了你是在与工具抗争还是与之共存。
Think First
大多数人认为，使用Claude Code和其他人工智能工具，你需要做的第一件事就是打字输入（或语音输入）。但这可能是你直接犯下的最大错误之一。你真正需要做的第一件事就是思考。
10次中有10次，我在 plan 模式下得到的输出比我一上来就并将所有内容都输入给 Claude Code时要好得多。两种方式的输出甚至相差甚远。
现在对你们中的一些人来说，说起来容易做起来难。你可能没有多年的软件工程经验，无法独立思考这个问题。在这方面，我有两条建议：
- 开始学习。如果你从未意识到这一点，即使只是一次一点点，你也是在妨碍自己的进步。
- 与ChatGPT/Gemini/Claude进行深入的交流，在那里你确切地描述了你想要构建什么，你向LLM询问你在系统设计方面可以采取的各种选择，最终你们俩确定了一个解决方案。你和 LLM 应该互相问问题，而不仅仅是单向的。
这适用于一切。这也包括一些非常小的任务，比如：
- 总结电子邮件。在让Claude构建功能之前，请先考虑一下架构。
- 在要求它重构某些东西之前，想想最终状态应该是什么样子。
- 在让它调试之前，想想你对当前问题的实际了解有多少。
你在 plan 模式中产生的信息越多，你接下来的输出实际上就越好，因为输入就越好。
这种模式是一致的：先思考，然后打字。这种方式产生的结果比先打字并寄望于 Claude 能懂你，然后帮你处理得妥妥当当要好的多。
这就引出了我的下一个在架构方面的观点。架构，尤其是在软件工程中，有点像给一个人输出，仅此而已。这为如何获得输出留下了很大的回旋余地，这基本上就是人工智能生成代码的问题所在。如果你说一些超宽泛的话，比如“为我构建一个身份验证系统”，而不是“使用现有的用户模型构建电子邮件/密码身份验证，将会话存储在24小时到期的Redis中，并为/api/protected下所有的路由添加中间件”，你可以看到其中的区别。
你点击shift+tab两次，就进入了计划模式。相信我，这会占用你5分钟的时间，但会为你以后节省数小时的调试时间。
CLAUDE.md
CLAUDE.md是一个markdown文件。Markdown是一种人工智能模型处理得非常好的文本格式，尤其是Claude比我测试过的大多数其他模型处理得更好。
当您开启一个 Claude Code 会话时，Claude 做的第一件事是读取您的Claude.md文件。该文件中的每一条指令都塑造了claude 处理你项目的方式。这基本上是 claude 在每次开启一个新的会话前必定要读取的入门初始信息。
大多数人要么完全忽略它，要么往里面塞满了垃圾，让 claude 变得更糟而不是更好。这里会有一个阈值，信息太多或太少都会导致模型输出更差。
以下是真正重要的事情：
- 保持简短。Claude一次只能可靠地遵循大约150到200条指令，而Claude Code的系统提示符已经使用了大约50条指令。你添加的每一条指令都在争夺注意力。如果你的
CLAUDE.md字符数量多到像一本小说一样， claude 会开始随机忽略一些事情，而要命的事你也不知道是哪些事情。 - 描述要跟你的项目强相关。比如，不要解释什么是组件文件夹。 claude 知道什么是组件。你要告诉它那些奇怪的东西，比如真正重要的bash命令。所有属于你心流的东西都应该写进
CLAUDE.md。 - 告诉它为什么，而不仅仅是什么。 claude 在这方面有点像人类。相比于你只是告诉它该做什么，告诉它当前这条指令背后的初衷的时候，Claude会表现得更好。比如，相比于“使用TypeScript严格模式”，“使用TypeScript严格模式，因为我们有隐式任何类型的生产错误”会更好。“为什么”为 claude 提供了做出你没有预料到的判断的背景。你会惊讶于这种做法的实际效果是有多棒。
- 持续更新。工作时按
#键，Claude将自动向Claude.md添加指令。每次你发现自己在同一件事上纠正 claude 两次，这就是一个信号 - 一个将这种指令写入Claude.md文件的信息。随着时间的推移，您的CLAUDE.md将成为您的代码库实际工作方式的动态文档。 差劲的CLAUDE.md看起来像是为新员工编写的文档。优秀的CLAUDE.md就像你今天知道明天就会失忆而在留下的便条。
上下文窗口的局限性
例如，Opus 4.5有一个 200k 个 token 上下文窗口。但这是大多数人没有意识到的：在你达到100%之前，模型就开始恶化了。（这取决于您是否通过API还是通过桌面应用程序使用）。
在20-40%左右的上下文使用率下，输出质量开始下降，即使不是显著下降。如果你经历过「使用了claude code 上下文压缩，但是输出效果还是糟糕」，那么这就是原因 - 在压缩上下文之前，模型已经退化，此时的压缩已经为时已晚了。（压缩上下文的命令是/compact）。
你发送的每一条消息， claude 读取的每一个文件，它生成的每一段代码，每一个工具结果——所有这些都会累积起来。一旦质量开始下降，更多的上下文只会使情况变得更糟，而不是更好。那么接下来这些做法是有助于我们避免糟糕的上下文：
-
圈定你的会话范围。最好一个feature或者 task 就创建一个会话，保持会话的干净性。不要在同一个会话中既构建您的身份验证系统，然后也重构您的数据库层。不同需求的上下文融合在同一个会话中， claude 会感到困惑。我知道你们中至少有一个人这么干过。
-
使用外部存储。如果你正在处理复杂的事情，让Claude编写计划并将进度写入实际文件（我使用
SCRATCHPAD.md或plan.md）。这些问题在会话期间持续存在。当你明天回来时， claude 可以阅读文件并从你上次停止的地方继续，而不是从零开始。旁注：如果你有一个文件的层次结构系统，把这些文件放在最顶层。这就你在构建每个task/feature 的时候让这些东西继续发挥效果的秘诀之所在。 -
复制粘贴重置。这是我经常使用的伎俩。当上下文变得臃肿时，我从终端复制所有重要的内容，运行/compact以获取摘要，然后完全清除上下文，只粘贴重要的内容。保留关键信息的新上下文。这比让 claude 在退化的上下文环境中挣扎要好得多。
-
知道什么时候清理。如果一段对话偏离了轨道或积累了一堆不相关的上下文，请直接执行
/clear去重新开始。这比试图在混乱的上下文中工作要好。Claude仍然保存着你的Claude.md，所以你不会失去你的项目上下文信息。十有八九，使用/clear实际上比不使用要好，虽然这听起来很违反直觉。 -
有效的心理模型： claude 是无状态的。每一次会话都是从零开始的，除非你明确地给出了什么并相应地制定了计划。
prompts 就是一切
人们花费数周时间学习框架和工具。他们却不花费时间学习如何与实际生成代码的东西（LLM）进行通信。
prompt不是什么神秘的艺术。它可能是最基本的沟通形式。就像任何沟通一样，清晰比模糊能让你得到更好的结果:
-
明确你想要什么。“构建一个认证系统”给了 claude 创作自由，但使用起来会很糟糕。“使用此现有的用户模型构建电子邮件/密码身份验证，将会话存储在Redis中，并为
/api/protected下的所有路由添加一个鉴权的中间件”为Claude提供了一个明确的目标。即使这样也不是完美的。 -
告诉它不要做什么。 claude 有这种倾向。Claude 4.5特别喜欢过度设计——额外的文件、不必要的抽象、你没有要求的灵活性。如果你想要一些最小的东西，可以说“保持简单。不要添加我没有要求的抽象。如果可能的话，一个文件搞定。”此外，始终交叉引用Claude生成的内容，因为你不想最终背负技术债务，特别是如果你正在构建一个超级简单的东西，它最终为一个任务生成了12个不同的文件，而这个任务实际上可以用几行代码来修复。
你必须记住的是，人工智能的设计是为了加快我们的速度，而不是完全取代我们，尤其是在非常专业的软件工程时代。 claude 仍然会犯错误。我相信，即使随着时间的推移会变得更好，它也会不断犯错。因此，能够认识到这些错误并且能让 claude 记住，实际上会解决你的很多问题。
-
给出指令背后的初衷。“我们需要它快速运行，因为它在每个请求链路上运行”改变了 claude 处理问题的方式。“这是一个我们要扔掉的原型”改变了权衡的意义。 claude 无法读懂你对你没有提到的约束的想法。
记住：输出就是一切，但它只能来自于输入。如果你的输出很糟糕，那么你的输入也很糟糕。这是我们无法避开的。
糟糕的输入 == 糟糕的输出
当人们得到糟糕的结果时，他们会责怪这个模型。“ claude 不够聪明”或“我需要一个更好的模特。”
事实是：你真差劲。如果像Opus 4.5这样的好模型输出的结果不好，这意味着你的输入和提示很糟糕。
模型很重要。但是实际上，模型质量是赌注，控制权不在我们手上。提升表现结果的瓶颈几乎总是在人的这一边：
- 你如何组织你的 prompt？
- 你如何提供上下文？
- 你如何清楚地传达你真正想要的东西？
如果你总是得到糟糕的结果，那么解决办法不是换型号。解决的方法是：
-
写出更好的 prompt。具体的法则是 具体>模糊，约束>开放式；示例>描述。
-
优化 prompt 的组织方式。将复杂的任务分解为步骤。在实施之前就架构达成一致。审查大模型的输出并迭代。
-
在恰当的时机提供恰当的上下文信息。 claude 需要知道什么才能做好这件事？你做了什么 claude 不知道的假设？
不过话说回来，模型之间也存在真正的差异：
-
Sonnet更快更便宜。它非常适合路径明确的执行任务。比如，编写样板、根据特定计划进行重构、在已经做出架构决策的地方实现功能。
-
Opus的速度较慢且价格较高。它更适合复杂的推理、计划和任务，在这些任务中，你需要 claude 深入思考并权衡。
一个有效的工作流程：使用Opus来规划和做出架构决策，然后切换到Sonnet（ claude code 中的Shift+Tab）进行实现。这将取决于你的任务，有时你也可以使用opus 4.5来实现（如果你是通过API使用的话，请考虑卖肾吧）。CLAUDE.md确保两个模型在相同的约束下运行，因此切换模型也不会污染上下文。
MCP、工具和配置
claude 的 feature 多到令人发指：
- MCP server，
- hook
- 自定义斜线命令。
- Settings.json配置
- skill
- plugin
虽然你不需要同时使用所有的这些。但是，你实际上应该尝试它们并进行实验。因为如果你不进行实验，你就白白浪费掉你的钱了。我向你保证，Claude中至少有一个你不知道的新功能，如果你关注 Claude Code 创始人Boris的 twitter，你可以实时地了解到它。
MCP（模型上下文协议）允许Claude连接到外部服务。比如，Slack、GitHub、数据库、API。如果你发现自己不断地将信息从一个地方复制到Claude中，可能这就意味着你需要一个 MCP服务器来帮助你自动完成。有很多MCP市场，如果在这些地方没有找你想要的MCP，你完全可以自己实现自己的 mcp server。 不过，如果你发现一个不存在的东西，我会非常惊讶。
Hooks允许您在Claude进行更改之前或之后自动运行代码。想让Prettier对 claude 接触的每个文件都运行吗？hook！每次编辑后都要进行类型检查吗？hook！上面的做法会立即发现问题，而不是让问题堆积起来。这实际上也有助于消除技术债。如果你在每千行之后设置一个安全审计的 hook，那么那么当 claude 审查你的 PR 时，你会发现这很有帮助。
自定义斜线命令只是将您重复使用的提示打包为命令。创建.claude/commands文件夹，使用提示添加markdown文件，现在您可以使用/commanname运行它们。如果你经常运行同一种类型的任务，比如调试、审查、部署，可以把它变成一个自定义命令。
如果你有Pro Max计划（每月支付200美元），为什么不试试 claude 提供的一切呢？看看什么有效，什么无效。不管怎样，你都要为此付出代价 - 要么是时间，要么是金钱。
重要提示：如果第一次尝试不起作用，不要停止探索的脚步。这些模型基本上每周都在改进。一个月前做不到东西现在可能做到了。要想成为早期采用者，意味着你要保持好奇心并不断地重试。
当 claude 进入了死胡同
有时 claude 会进入恶性循环。它尝试同样的事情，失败，再试一次，失败，然后继续前进。或者它自信地实施了一些完全错误的东西，你花了二十分钟试图解释原因。
当这种情况发生时，你的惯性思维是继续在原有的思路上去尝试。于是，你会写更多的说明，指出更多需要更正的地方，给出更多的上下文。但是更好的做法往往是反其道行之 - 换种思路，彻底从零开始。
-
从简单开始——执行
/clear命令，清除上下文。累积的上下文可能会让你感到困惑。/clear会给你一个新的开始。 -
简化任务。如果 claude 正在努力完成一项复杂的任务，请把它分解成更小的部分。在组合之前，先让每一个小任务先并行地跑着。但实际上，如果 claude 接到的是一项复杂的任务，这意味着你的计划模式做得不够充分。
-
给出示例代码而不是只是干说。如果 claude 一直误解你想要的东西，你自己要写一个最小的例子。然后告诉它：“我想要的输出应该是什么样子的。现在将这种模式应用于其余部分。” claude 非常善于理解好的指标是什么样子，并且能够真正遵循好示例中给出的指引。
-
换个思路。尝试不同的角度。有时，你提出问题的方式与 claude 的工作方式并不完全一致。你不妨换一个角度来提问题：重构——“将其作为状态机实现”与“处理这些转换”——可以解锁进度。
上面的这些技巧是建立在一个 meta-kill 之上：尽早识别出你是否是处于循环中。如果你已经对同一件事解释了三次，但 claude 仍然还是犯糊涂，那么此时你大概率是碰到 claude 进入了死胡同了。这个时候，不妨按照上面技巧，做出一些改变性的尝试。
构建一个 AI 系统
一次性任务并不能让 claude 发挥出最大价值。聪明的人正在构建以 claude 为组成部分的系统。但 claude code 比这要好得多。它有一个-p标志位用于无头模式。它运行您的提示并输出结果，而无需进入交互式界面。这意味着您可以编写脚本来对接它。将它的输出连接到其他工具。用bash命令将其链接起来。将其集成到自动化工作流程中。
企业正在使用这种模式进行自动PR审查、自动支持工单响应、自动日志记录和文档更新。所有这些都记录在案，可审计，并随着时间的推移根据哪些有效，哪些无效进行改进。
飞轮效应： claude 犯了一个错误，你检查日志，改进Claude.md或工具， claude 下次会做得更好。这样就闭环了。现在我正在让Claude改进自己的 Claude.md 文件。经过数月的迭代，以这种方式构建的系统比发布时要好得多——同样的模型，只是配置得更好了而已。
如果你只是交互式地使用Claude，那么你远远没有把 claude 的价值榨干。想想 claude 在你的工作流程中的哪个环节可以在你不监督的情况下也可以运行。请来用 claude code 的无头模式把这个环节自动化掉。
