内容来源：X 社区长文。https://x.com/eyad_khrais/status/2010076957938188661
作者：@eyad_khrais
原发布时间：2026-01-10

Claude Code tutorial source cover

Claude Code 入门工作流：先规划、再执行、再沉淀

很多人第一次使用 Claude Code，会把它当成一个更强的聊天窗口：打开项目、输入需求，然后等它自己把代码写好。这样当然也能得到结果，但稳定性通常不高。真正适合 Claude Code 的方式，是先把任务变成一个可执行的工程流程，再让它进入实现。

这篇社区经验文的核心观点可以压缩成一句话：Claude Code 的效果，不只取决于模型能力，更取决于你给它的任务边界、项目规则、上下文管理和验证方式。

下面按实际使用顺序整理。

先进入规划，而不是立刻开写

使用 Claude Code 时，最容易犯的错误是直接丢一句“帮我做一个登录系统”“帮我重构这块代码”。这类描述给了模型太大的自由度，它可能补很多你没确认过的假设：数据库怎么选、session 怎么存、路由怎么保护、边界错误怎么处理。

更稳的方式是先让 Claude Code 进入规划状态，和它一起把目标拆清楚：

  • 当前系统已有的结构是什么；
  • 这次只改哪些文件或模块；
  • 哪些能力必须做，哪些能力暂时不做；
  • 成功标准是什么；
  • 做完以后用什么方式验证。

比如“做登录系统”可以改成：

基于现有 User 模型实现邮箱和密码登录；session 存到 Redis，过期时间 24 小时；新增 middleware 保护 /api/protected 下的接口；不要引入新的 ORM；完成后运行现有 auth 测试。

这不是提示词写得“更长”，而是把工程约束写清楚。Claude Code 在约束明确时，会更像一个执行工程师；约束模糊时，它会自己当产品、架构和工程负责人，结果就容易跑偏。

把 CLAUDE.md 当成项目入职文档

CLAUDE.md 是 Claude Code 很关键的杠杆点。每次会话开始时，Claude 会读取这个文件，它相当于给 Claude 的项目入职说明。

但 CLAUDE.md 不应该写成一本完整文档。它更适合记录那些“只有这个项目才重要”的规则：

  • 常用启动、测试、构建命令；
  • 不能碰的目录或历史包袱；
  • 数据库迁移、部署、回滚的特殊约束；
  • 团队偏好的代码风格；
  • 常见踩坑点；
  • 为什么要遵守某条规则。

“为什么”很重要。比如只写“使用 TypeScript strict mode”，不如写成“使用 TypeScript strict mode，因为过去线上问题多次来自隐式 any”。前者是命令，后者会影响 Claude 在不确定场景下的判断。

如果你反复纠正 Claude 同一类问题，就说明这条规则应该沉淀进 CLAUDE.md。一个好用的 CLAUDE.md 不像新人培训手册，更像你给“明天失忆的自己”留下的项目备忘录。

上下文窗口不是越满越好

很多人以为只要上下文还没满，Claude Code 就能稳定工作。实际使用中，质量往往会在上下文明显变长后开始下降：对早期约束记忆变弱，重复读取无关信息，或者在错误路径上越走越远。

更好的上下文策略是：

  • 一个会话只做一个明确任务；
  • 不要在同一个会话里连续做不相关功能；
  • 长任务把计划、进度和决策写入 plan.md、SCRATCHPAD.md 这类文件；
  • 会话混乱时及时 /clear，不要强行继续解释；
  • 必要时先 /compact，再把真正重要的信息复制到新会话。

要把 Claude Code 理解成“每次都从你显式给出的上下文开始工作”。它不是长期记忆系统。真正可靠的长期记忆，应该放在项目文件、规则文档、测试和脚本里。

Prompt 的重点是约束、例子和验收标准

提示词不是玄学。它本质上是任务沟通。模糊的请求会得到模糊的实现，具体的请求会得到更可控的实现。

一个高质量请求通常包含四类信息：

  • 目标：要实现什么；
  • 边界：不要做什么；
  • 上下文：为什么要这么做；
  • 验收：怎么判断完成。

尤其要写清楚“不要做什么”。Claude Code 有时会倾向于补抽象、补配置、补扩展能力。如果你只想要一个小修复，就直接说：

保持简单。不要新增抽象层，不要引入新依赖，优先在现有文件内完成。完成后说明改了哪些行为。

这会显著减少不必要的工程膨胀。

模型选择可以按“规划”和“执行”拆开

原文提到的一个实用思路是：复杂任务先用更强的模型做规划和架构判断，再用更快、更便宜的模型执行清晰任务。

这个思路不依赖某个具体模型名称。关键是把任务分层：

  • 不确定性高、涉及架构权衡、需要排查根因：适合强推理模型；
  • 目标明确、路径清楚、主要是批量修改或补样板：适合执行型模型；
  • 已经有测试和验收标准：可以让执行模型反复迭代。

不要把“换模型”当成第一反应。如果输出持续不好，先检查任务边界、上下文、示例和验证方式。很多时候问题不是模型不够强，而是输入没有给出工程决策所需的信息。

MCP、Hooks、Slash Commands 要按痛点引入

Claude Code 的扩展能力很多，但不需要一次性全上。更合理的方式是看你在哪些环节反复手工搬运、反复纠错、反复执行命令。

如果你经常把 GitHub、数据库、Slack、内部 API 的信息复制给 Claude，可以考虑 MCP，把外部系统变成 Claude 可调用的工具。

如果你经常提醒 Claude “改完要格式化”“改完要跑测试”“别忘了类型检查”，可以考虑 Hooks，把这些检查放进自动流程。

如果你经常重复同一种任务，比如代码审查、排障、发版检查、生成迁移说明，可以把提示词沉淀成自定义 slash command。这样团队成员不必每次重新组织语言。

扩展能力的原则很简单：先找到重复动作，再把重复动作工具化。

Claude 卡住时，换方法比继续解释更有效

当 Claude Code 在同一个问题上循环失败时，继续追加上下文往往只会让局面更乱。更有效的处理方式是：

  • 清空会话，重新给最小上下文；
  • 把复杂任务拆成更小步骤；
  • 手写一个最小示例，让 Claude 按模式扩展；
  • 换一种问题表达，比如从“修复这段逻辑”改成“把它建模成状态机”；
  • 先让 Claude 解释当前失败原因，再决定是否继续。

如果同一个点解释三次还没有理解，就不要继续堆提示词了。此时更可能是上下文污染、目标不清或任务拆分不合理。

从一次性使用，走向可复用系统

Claude Code 的价值不只在交互式写代码。它也可以进入自动化流程，例如：

  • 自动 PR Review；
  • 生成或更新文档；
  • 批量检查日志和报错；
  • 根据模板处理支持工单；
  • 在 CI 或内部脚本中执行固定任务。

这类场景的关键不是“让 Claude 自己发挥”，而是把流程做成可记录、可审计、可迭代的系统：Claude 出错后，人查看日志，更新 CLAUDE.md、命令、测试或 Hook，下次同类任务就更稳。

这会形成一个正循环：工具犯错，流程吸收错误，规则变清晰，后续输出变好。

小结

对新手来说，Claude Code 最重要的不是掌握所有命令，而是先建立正确工作流：

  • 先规划，再实现；
  • 用 CLAUDE.md 固化项目规则；
  • 控制上下文，不要让会话无限膨胀；
  • 用明确的目标、边界、示例和验收标准写请求；
  • 按痛点引入 MCP、Hooks 和 Slash Commands；
  • 卡住时换方法，而不是继续堆解释；
  • 把重复任务沉淀成自动化系统。

当你用这种方式使用 Claude Code，它就不只是一个“帮我写代码”的工具，而会逐渐变成项目工程流程的一部分。