Claude Code 完整入门：从“先想清楚”到可持续提效

这条“完整教程”如果只被读成一串使用技巧，其实会错过重点。它真正反复强调的是：Claude Code 不是一个会自动产出正确答案的终端，而是一个会把你当前工程方法放大的执行器。任务定义含糊、项目知识分散、上下文失控、验证缺位，这些问题以前就存在，只是 AI 时代会更快暴露。

所以我更愿意把这篇教程压成一句判断：Claude Code 能不能稳定提效，取决于你有没有把任务建模、项目记忆、上下文治理和验证闭环这四件事做成制度，而不是临场发挥。

原帖最核心的建议是，别急着开写，先进入 plan mode 把任务讲清楚。这里的价值不在于“多一步思考显得更专业”，而在于把问题从开放式请求压成可判定的工程任务。

真正该先说清楚的是三件事：

1. 这次要交付什么结果。
2. 明确哪些边界不能碰。
3. 这次怎样才算完成。

比如“做一个认证系统”和“基于现有 User 模型补邮箱密码登录，Session 存 Redis，24 小时过期，并保护 /api/protected 路由”，看起来只是描述更细，但对模型来说差别极大。前者会引出一堆默认假设，后者才有机会被稳定执行。

作者强调先花几分钟在 plan mode 里做方案梳理，本质上是在前置定义 done，而不是把返工留到后面。Claude Code 最大的成本，通常不是写错一行代码，而是沿着错误任务定义连续生成半小时。

第二个值得保留的判断，是别把聊天窗口当成长期记忆。原帖把 CLAUDE.md、SCRATCHPAD.md、plan.md 这类文件放在很高的位置，原因很简单：真正影响实现质量的知识，不该靠你每次重新说一遍。

其中 CLAUDE.md 适合承载稳定的项目级约束，例如关键命令、不能破坏的架构约定、团队明确踩过的坑，以及这些规则背后的原因。它不应该写成新人手册，更不应该把所有常识塞进去。越能区分“项目特有约束”和“通用开发常识”，这个文件越有用。

而对单次复杂任务，作者建议把中间推导、待办和子问题拆到外部文件里。这个建议比看起来更重要，因为上下文窗口一旦混进大量中间态推理，模型会越来越像在旧会议纪要里翻答案，判断力反而下降。

因此我认同原帖的三个操作习惯：

• 一次会话只做一类任务，避免上下文混线。
• 中间推导和计划放到外部文件，不把聊天窗口塞满。
• 任务已经跑偏时，及时 /clear 或 /compact，不要在污染过的上下文里硬修。

原帖还有个很实用的提醒：大多数“Claude Code 乱发挥”的问题，本质上是约束不够，而不是模型不够强。

所以提示词里除了任务目标，还应该写清楚不要做什么。像“保持实现简单，不要新增没要求的抽象”“优先单文件改动，必要时再拆分”这种反约束，对抑制过度设计很有效。它们看起来像小修饰，实际是在替你提前切掉错误搜索空间。

文中还提到一个很现实的分工策略：把高推理成本阶段和执行阶段分开。复杂规划、方案比较、权衡取舍更适合交给 Opus 这类偏推理的模型；当路径已经确定，Sonnet 这类更快的模型往往更合适。这里的重点不是某个型号，而是别让同一个会话既负责定方向，又负责高频实现。

遇到模型反复走偏时，原帖建议优先换策略，不要重复解释。清空上下文、继续拆小任务、给一个最小成功样例，通常都比“再说一遍”有效。这个经验非常工程化，因为模型最不擅长的就是在错误问题建模上自我纠偏。

原帖最后那部分关于 headless、Hooks、MCP 和 slash commands，我认为才是“完整教程”里最容易被低估的部分。前面那些建议解决的是单次会话质量，后面这些机制解决的是能不能把好习惯沉淀成系统。

一旦把 Claude Code 接到格式化、测试、构建、部署检查、MCP 工具和自定义命令上，它就不再只是一个“问答助手”，而是进入受约束的工作流。这样带来的收益不是偶尔惊艳，而是结果开始可复制。

如果必须把这条长线程压缩成一个落地版本，我会保留四条：

1. 任何复杂任务先写计划，再决定是否进入实现。
2. 把 CLAUDE.md 和任务外部记忆当成工程资产维护。
3. 默认用约束、反约束和会话分工控制模型行为。
4. 尽快把验证与重复动作接入自动化，而不是停留在聊天层。

这篇教程最有价值的地方，不是又给了几个小技巧，而是把 Claude Code 的稳定性问题拆成了四个可治理对象。你如果只记命令，收获会很有限；你如果按这四个对象去改自己的工作流，工具才会真正开始放大产能。