先理解 Claude Code 到底和普通聊天机器人有什么不同
很多人第一次打开 Claude Code，会把它当成“会写代码的聊天窗口”。这个理解不算完全错误，但很容易导致后续体验很差。普通聊天工具的工作方式是你提问，它返回一段文字；而 Claude Code 的价值，在于它能直接进入项目工作流：读取文件、理解代码结构、修改项目、连接外部工具、辅助部署，甚至把一个模糊需求逐步推进成可上线的实际产品。
这意味着，你不能只把它当成“问答工具”，而要把它当成一个带执行能力的协作型工程环境。你给得越清楚，它做得越稳定；你表达得越模糊，它就越容易替你做假设，而这些假设一旦偏掉，返工成本会很高。
这篇教程不做视频摘要，也不复述时间轴，而是把这套方法拆成一套可以直接复制到自己工作里的实战流程：从首次打开界面、挑选模型、使用 Plan 模式、写出高质量提示词、配置 CLAUDE.md、连接 MCP、管理上下文，到最后部署上线，再扩展到 Skills、Hooks 和 Routines，形成一个可重复执行的工作系统。
开始之前：先把使用环境和目标说清楚
根据素材中的演示流程，你需要先具备几个前提条件。第一，使用 Claude 桌面应用，并且账户可以访问 Code 标签页。第二，手头要有一个准备让 Claude 读取和处理的项目目录，或者至少明确知道你要从零开始创建什么。第三，如果你打算像示例里那样把项目直接发到线上，那么最好提前准备好部署平台账号，例如 Vercel。
实际开工前，建议你先完成下面这些准备动作：
- 打开 Claude 桌面应用，并确认能进入
Code标签页。 - 准备一个本地工作目录，不要在一个完全空白、没有项目上下文的会话里直接乱问。
- 确认你后面可能用到的服务已经登录，例如 Vercel、自动化平台、GitHub、表格工具等。
- 先写一句“本次要产出的结果是什么”，不要上来就让 Claude 自己猜。
- 想清楚你现在是要做探索、实现、调试，还是部署，因为这会直接影响模型和思考强度的选择。
很多新手一开始最容易犯的错误，就是根本没有定义好交付目标。例如“帮我做一个 app”这种话，从人类角度看好像很自然，但从 Claude Code 的执行逻辑看，它必须在背后默默补全一整套产品假设：这个 app 给谁用、核心流程是什么、界面长什么样、是否需要登录、是否需要数据库、部署到哪里、性能要求如何。你没说，它就只能猜。
更好的做法，是先用一句话写清楚目标。例如：
“做一个给小团队使用的任务管理面板，支持看板拖拽、工作量预警、移动端可读。”
这句话虽然短，但已经为后续所有决策提供了判断基线。之后无论是建页面、定结构、加功能，还是做部署，你都能回到这句话判断：当前变更是不是在服务这个目标。
模型别乱切：把 Sonnet、Opus 和混合模式当成工程资源来用
素材里强调了一个非常实用的点：Claude Code 不是永远开最高配置就最好，模型选择本身就是成本控制和效率优化的一部分。
视频里提到的基本分工是：
Sonnet：日常主力，速度快，适合大多数任务。Opus：深度推理、复杂逻辑、架构设计、顽固 bug 排查时再用。- 混合模式：先用更强推理做规划，再用更快模型做执行。
真正重要的不是名字，而是你要理解它们分别适合什么类型的工作。
什么时候优先用 Sonnet
如果你已经知道自己要改什么，任务范围也相对清晰，那么 Sonnet 往往是最划算的选择。比如：
- 修改按钮文案、标题、布局细节。
- 给已有页面补一个筛选条件。
- 修一个明显的样式问题。
- 给组件增加一两个字段。
- 做一段简单的前端或 API 调整。
这种任务的特点是：目标清晰、约束明确、错误成本低、需要快速来回迭代。用 Sonnet，节奏会更顺。
什么时候该切到 Opus
如果问题本身复杂，或者你并不确定“应该怎么做”，那就应该考虑 Opus。典型场景包括：
- 一个 bug 横跨多个文件，你根本不知道根因在哪里。
- 你要从零搭一套结构，希望 Claude 先比较几种架构方案。
- 一个功能同时涉及状态流、数据结构、权限逻辑、界面交互和部署影响。
- 之前已经让 Claude 改过几轮，但每次都只修了表面，没解决本质问题。
这种场景如果还用快节奏、低推理的方法，Claude 往往会给出“看起来像解决了，实际上还埋雷”的答案。Opus 在这类任务上更值得花成本。
一套比较稳的使用策略
建议你形成这样一套习惯：
- 先用较快模型做探索和小改动。
- 当任务进入复杂推理、结构设计或深度排错，再切上去。
- 方案稳定以后，再切回速度更快的模型继续实现。
这能同时兼顾成本、节奏和结果质量。很多人之所以觉得 Claude Code“贵”或者“慢”，并不是工具本身有问题，而是没有做任务分层，简单问题也一直用最重的配置硬跑。
/effort 不是装饰项，而是影响结果质量的核心控制杆
素材里还提到了 /effort，这点特别值得展开。它本质上是在控制 Claude 在回答前愿意花多少“思考预算”。如果你把模型选择理解为“选谁来干活”，那么 effort 就是在决定“让它为这件事想多深”。
可以把它理解成一个工程版的风险控制开关：
Low：适合低风险、低复杂度的小任务。Medium：适合一般实现类工作，速度和质量相对平衡。High：适合大多数正式功能开发，是比较稳妥的默认值。Max：只在最难的问题上开，不适合全程常驻。
怎么根据任务判断 effort 级别
一个简单实用的判断原则是：错误代价越高，effort 就越应该往上调。
比如改个颜色、修个错别字，就算答错了也只要几秒钟改回来，那 Low 足够。可如果你现在要 Claude 重新梳理应用结构、判断部署失败根因、处理多步骤依赖，浅层思考的代价就很高，因为一旦方向错了，后面可能白做几十分钟。
示例：高风险任务这样写
使用 high effort。先检查当前项目结构，找出任务卡拖拽后状态没有更新的可能原因，说明你判断的依据，再在最小改动原则下提出修复方案，最后再开始修改。
这个提示的关键不只是“high effort”，更重要的是它要求 Claude 先解释判断，再实施修改，这样你就能提前发现它有没有真的理解问题。
示例：简单任务这样写
示例：使用 low effort。把工作量预警标签从亮黄色改成偏琥珀色，保持其余行为完全不变。
这里明确标注“示例”，是因为这类命令只是写法参考。真正执行时，要根据你的具体项目内容替换描述。
常见坑：把高 effort 当默认常开
很多人觉得“既然高 effort 更强，那我一直开高甚至 max 不就好了”。这通常不是好策略。原因有三点：
- 会变慢，削弱你与 Claude 的交互节奏。
- 会更耗额度或成本。
- 简单问题反而容易被过度思考，输出冗长甚至偏题。
真正高效的做法，是让 effort 跟任务难度走，而不是跟焦虑程度走。
最重要的起手习惯：不要直接让它“开始做”，先让它“先规划”
素材里反复强调，新手最容易吃亏的地方，就是一打开 Claude Code 就直接说：“帮我做个应用。”
这种提示的最大问题不在于“太短”，而在于它默认 Claude 会替你完成所有需求定义工作。结果就是它的确会做，但做出来的东西未必是你要的。
正确起手方式应该是：先让 Claude 进入规划视角，而不是直接进入编码视角。你需要先给它一份最小化但明确的任务简报。至少要覆盖这些信息：
- 目标：最终要交付什么。
- 用户：这个东西给谁用。
- 核心流程：用户必须完成哪些关键动作。
- 约束：用什么技术、部署到哪里、偏好或禁用哪些方案。
- 质量标准：移动端、响应速度、错误处理、可维护性等有什么要求。
一个更靠谱的规划型提示词长什么样
Plan mode。我想做一个轻量级团队任务看板，目标用户是 5 到 20 人的小团队。必须包含任务列表、看板列、工作量概览、逾期预警和移动端可用性。技术栈尽量简单，方便部署到 Vercel。现在先不要写代码，先给我架构方案、文件结构、数据模型和实现顺序，并说明各自取舍。
这个提示词的好处在于：
- 先要规划，不急着出代码。
- 明确了用户和场景。
- 列出了必备功能。
- 提前给出了部署约束。
- 要求解释取舍，而不是只给一个单线答案。
看完规划后，不要立刻全盘接受
Claude 给出的规划不应该被你机械照单全收。你要做的是审一遍，看有没有以下问题：
- 它有没有自己偷偷扩大需求范围？
- 它选的技术是不是和你的部署目标冲突？
- 它有没有把本该后置的功能放进第一版？
- 它有没有交代数据从哪里来、状态怎么维护？
- 它说的结构是不是能支撑后面的迭代？
如果你觉得整体可行，再用第二条提示确认方向，例如：
按你刚才的结构继续，但第一版先只用本地数据，不引入数据库，优先保证移动端布局清晰。
这一步的作用，是把“讨论中的方案”变成“批准执行的方案”。很多人跳过这一层，就会在后面反复抱怨 Claude 总是“自作主张”。
Plan 模式真正的价值：提早暴露假设，而不是等代码写完再返工
Plan 模式不是为了让回答显得更专业，而是为了在成本最低的时候，先发现理解偏差。
在项目开始阶段，最贵的不是多写几行代码，而是方向错了以后整轮推翻。Plan 模式能让你在真正创建文件、改结构、写逻辑之前，就看清楚 Claude 准备怎么理解你的任务。
建议你在规划阶段主动追问这类问题：
- 最简单但能上线的方案是什么？
- 哪些功能必须在第一版完成，哪些可以第二版再加？
- 哪些地方未来最容易因为复杂度失控？
- 当前阶段哪些数据应该先 mock，哪些值得直接接真实来源？
- 如果现在就要部署，最大风险点在哪？
审查一份规划时的实用清单
一份值得继续执行的规划，最好至少满足这些条件：
- 能说清楚大概率会创建哪些模块或文件。
- 能解释为什么选这个技术方案。
- 知道部署目标会带来哪些限制。
- 有明确的数据来源和状态处理思路。
- 能区分“必须做”和“可以以后做”。
如果这几点里有两三项都说不明白，那最好别急着让 Claude 开始大量生成代码。
第一版做出来以后，不要重开，要学会“带着已有结果继续迭代”
素材里展示的一个重要思路，是 Claude 做出初版以后，并不是就此结束，而是继续通过清晰的迭代提示，把东西慢慢推到可用状态。
很多人使用 AI 开发时有个坏习惯：只要第一版不够理想，就把整个对话推倒重来。这样做最大的问题，是你每次都在丢弃已经有效的上下文和实现基础。
更合理的做法，是把第一次结果当成一个“可定位的中间版本”，然后围绕它精准迭代。
先按层次评估第一版
你看到 Claude 第一次做出来的东西时，先不要急着评价“好不好看”，而要按下面顺序判断：
- 核心流程有没有跑通？
- 结构是不是合理？
- 主要交互能不能用？
- 哪些地方缺了、错了、弱了？
- 哪些地方可以在不破坏现有功能的前提下增强？
糟糕的迭代提示是什么样
不太对，你重新做一下。
这种话最大的问题是：它没有保留任何已有资产，也没有告诉 Claude“哪里要保留、哪里要变”。Claude 最终只能再猜一轮。
更好的迭代提示是什么样
保留当前任务看板布局，但新增三个变化：增加工作量概览面板，把负载过高成员标成红色，并为可能延期的任务显示黄色预警标识。不要破坏现有拖拽行为。
这类提示的优势非常明显：
- 先指出什么要保留。
- 再列出具体变化项。
- 最后明确不能被破坏的现有能力。
它不是在表达情绪，而是在管理变更范围。
进一步提高稳定性：让 Claude 先解释自己现在怎么做的
在做较大改动前，你还可以先让它复述当前实现逻辑：
先不要改代码。先说明当前工作量预警是怎么计算的，哪些文件控制了颜色显示，再告诉我最小改动的增强方案。
这一步常常能避免“改了，但其实没理解”的低质量迭代。
CLAUDE.md 是高频项目最值得建立的长期记忆层
素材中提到的 CLAUDE.md，是从“偶尔用一下 Claude”升级到“把 Claude 变成稳定工作流成员”的关键。
你可以把它理解成项目级操作说明书。它的作用不是介绍项目背景，而是把那些你每次都会重复说、而且确实会影响实现决策的规则，固定下来。
CLAUDE.md 里最值得写什么
一个有用的 CLAUDE.md，通常应该覆盖这些内容：
- 产品目的和目标用户。
- 技术栈和允许使用的框架。
- UI 和交互上的基本原则。
- 编码约束与工程规则。
- 测试、检查、提交流程。
- 部署目标和发布前要求。
- 明确禁区，例如暂时不要引入数据库、不要重构目录等。
一个实用的内容结构示例
# Project Rules
## Purpose
面向小团队的移动友好型任务管理面板。
## Stack
Next.js、TypeScript、Tailwind。早期版本先使用本地数据或轻量存储。
## UI Rules
界面清晰、信息密度适中、移动端优先，不添加无意义动画。
## Engineering Rules
尽量采用小步修改；做结构性改动前先解释原因；优先保留现有文件组织方式。
## Deployment
目标平台是 Vercel，只有在确认生产构建通过后，才可视为可部署完成。
项目级规则和全局规则不要混
素材还提到，你可以设置更广义的全局偏好。但要注意区分两类东西：
- 项目级规则：只对当前仓库或项目有效。
- 全局偏好：跨项目都想保留的个人习惯。
比如“这个项目优先面向移动端”“这个项目不要引入数据库”，这些都应该写在项目规则里。像“我希望 Claude 在大改前先解释方案”“我偏向先做小步改动再重构”，这类更通用的偏好才适合放全局层。
最常见的误区：把 CLAUDE.md 写成空泛宣言
如果你写的是“保持代码高质量”“写得优雅一些”“尽量现代化”，这种内容对执行帮助非常有限。真正有价值的规则，一定是能改变技术决策的。比如：
- “优先兼容 Vercel 部署。”
- “所有新增页面必须先保证移动端纵向阅读顺序。”
- “不允许为了一个小功能引入新的重型状态管理库。”
规则越具体，Claude 在多轮会话中的表现越稳定。
MCP 的意义：不要只让 Claude 写代码，要让它接入你真实在用的系统
素材中非常关键的一段，是对 MCP 的介绍。MCP 全称是 Model Context Protocol。对实际使用者来说，不必先纠结协议细节，更值得理解的是它的业务意义：它让 Claude Code 可以和外部工具、服务、自动化流程建立连接，从“只会生成代码”升级成“能参与真实工作流”。
视频示例里提到的连接对象包括自动化平台、表格、GitHub、数据库、API 等。你可以把 MCP 看成 Claude 的“工具接口层”。没有它时，Claude 只能在你提供的本地项目和文本描述里工作；有了它，它就能读取、写入、触发、整合外部系统的信息。
什么时候应该考虑上 MCP
不是每个项目一开始都需要 MCP。真正适合引入的场景通常有这些：
- 你不想再手动输入演示数据，希望接真实数据源。
- 你希望 app 中的操作能触发外部动作。
- 你希望 Claude 协助搭建跨工具的自动化流程。
- 你已经有成熟团队工具，希望 Claude 基于这些工具做整合，而不是孤立地造一个新系统。
素材中的连接思路可以抽象成这几步
根据给出的内容，基础连接流程大致是：
- 打开自定义或连接器设置。
- 添加自定义连接器。
- 粘贴连接地址或对应链接。
- 完成授权或连接确认。
- 再通过提示词明确告诉 Claude 要如何使用这个工具。
关键原则：先定义工作流，再去连接工具
这里最容易犯的错误，是把“连接某个工具”本身当成目标。比如“接 Slack”“接表格”“接自动化平台”，这些都不是需求本身。
真正的需求应该是这类表达：
- 当任务逾期时，自动发一条消息给负责人。
- 当表单提交新任务时，自动清洗字段并进入任务池。
- 当项目状态变化时，同步更新团队周报数据。
也就是说，先明确：
- 触发条件是什么。
- 需要执行什么动作。
- 最终期望输出是什么。
只有先定义好这三件事，MCP 才会真正提高效率；否则你只是把系统接上了，但并不知道拿来做什么。
一个更强的 MCP 提示方式
使用已连接的自动化工具，创建一个工作流：当新项目任务被提交时，自动校验并标准化任务字段，再把任务同步到应用的数据源中。先说明需要哪些字段、错误如何处理、是否需要重试，然后再开始实现。
这样的提示能显著降低“连上了，但做得很空”的问题。
上下文管理比很多人想象中更重要：项目越长，越要主动控场
到了中后段，很多人会开始误以为“Claude 变笨了”。实际情况经常不是模型能力下降，而是上下文质量变差了。会话越长、改动越多、目标越频繁漂移，Claude 接收到的信息就越容易混乱：旧要求和新要求混在一起，已经废弃的思路还停留在上下文里，多个目标同时推进，结果就是输出开始失焦。
所以，长期会话里必须有“上下文管理”意识。
实用的上下文管理习惯
- 尽量让每条提示只推动一个主要目标。
- 大改前让 Claude 先总结当前实现状态。
- 能固化进
CLAUDE.md的规则，不要每次都写在聊天里。 - 做了几轮大改以后，主动重新锚定当前目标。
- 不要把修 bug、改架构、接外部工具、上线部署混成一句模糊指令。
重新锚定会话的提示示例
先暂停修改。总结当前应用已经实现了什么、还缺什么、哪些点存在风险，并给出下一步最值得做的事情。先不要编辑文件。
这种提示特别适合长会话中段使用。它的作用有三个：
- 帮你确认 Claude 和你对当前状态的理解是否一致。
- 帮你清理掉已经不重要的信息噪音。
- 帮你决定接下来是继续迭代、换线程、还是准备部署。
素材里还提到了 extended thinking。实际落地时，不需要把它神秘化。你只要记住一句话：只在任务真的有多层依赖和隐含逻辑时，给它更大的思考空间；如果任务本身很直，就不要把会话拖成深度推理大会。
部署不是收尾动作，而是产品是否真正可用的分界线
很多教程停在“本地跑起来了”。这对个人练习也许够，但对真实工作场景是不够的。素材中很有价值的一点，就是没有把“看到界面了”当成结束，而是继续推进到“拿到可分享的线上地址”。
这其实反映了一个更成熟的工作标准：一个功能或应用，只有在目标环境中可访问、可验证，才算真正可交付。
用 Claude 推动部署时，建议这样提
把这个项目部署到 Vercel，并返回一个可分享的线上 URL。部署前先检查生产构建会不会失败，列出可能阻碍上线的问题，再执行部署。
这类提示优于“帮我部署一下”的原因，在于它把“部署前检查”也纳入了任务，而不是默认一键上线一定会成功。
正式部署前必须检查的内容
你可以手工检查，也可以让 Claude 帮你检查，但下面这些点最好一个都别漏：
- 项目在生产模式下能否构建通过。
- 是否存在只在本地机器上可用的环境变量。
- 有没有把本地路径、测试账号、临时密钥写死在代码里。
- API 地址是否已切换到正确的生产环境。
- 静态资源与依赖声明是否完整。
- 主要页面在手机端是否仍然可用。
- 如果有外部连接器，线上环境是否也具备访问条件。
最常见的部署坑
本地能跑、线上失败，通常逃不出以下几类原因：
- 本地环境里有变量，但部署平台没配。
- 用了演示数据或本地文件路径，线上根本不存在。
- 构建命令、输出目录或运行配置没定义清楚。
- 服务端依赖被误放到客户端代码里。
- 预览面板里看起来没问题，但正式路由或资源路径在生产环境下失效。
上线后要像运营人员一样验证，而不是像作者一样“看一眼就算”
部署完成以后，建议你至少做一轮真实使用视角测试：
- 用无痕窗口打开线上地址。
- 在桌面端走一遍主流程。
- 在手机端走一遍主流程。
- 检查空状态、加载状态、错误提示是否合理。
- 如果接了真实工具，确认线上环境里这些连接仍然有效。
只有这一步过了，项目才真正从“看起来完成”变成“实际可用”。
Skills：把你常说的要求，变成 Claude 能长期复用的能力块
素材在后段提到了 Skills。它的实际价值，不在于“功能名很高级”，而在于你终于可以把那些经常重复出现、而且有明确模式的要求，沉淀成可复用的指令包。
哪些内容适合做成 Skill
以下这些都非常适合：
- React 组件的编写约定。
- 提交信息格式规范。
- 改动后的测试要求。
- 代码审查检查表。
- 某类 API 接入的统一模式。
- 团队约定的 UI 组件使用策略。
什么样的 Skill 才是有效的
“写干净一点的代码”不是好 Skill，因为它不可操作。有效 Skill 必须具体到能约束行为。例如：
- 修改 React 组件时优先保留现有 props 结构。
- 新增组件后运行对应模块测试。
- 做结构性重构前先解释影响范围。
- 前端页面默认先检查移动端可读性。
这样的规则 Claude 才能在合适时机自动调用，并产出稳定结果。
一个提醒：Skill 也会过期
如果你把旧项目的约束、已经不再适用的流程、或者写得很死板的规则长期保留，Skill 反而会变成干扰项。所以做得越多，越要定期复查这些沉淀下来的能力块是否仍然适用。
Hooks：把“我希望它顺手做的事”自动化，而不是每次口头提醒
素材中提到的 Hooks，是把某些行为触发后的动作自动化。它的意义在于，你不必每次都对 Claude 说“顺便格式化一下”“顺便跑个测试”“顺便通知我一下”，而是把这些动作绑定到特定事件上，让系统自动执行。
素材里提到的几个典型例子
- 每次编辑文件后自动格式化。
- 每次完成任务后发送通知。
- 每次新建组件后自动跑测试。
刚开始怎么用更稳
建议先从低风险、收益明确的 Hook 开始：
- 文件变更后自动格式化。
- 某些目录下修改后自动跑 lint。
- 新组件生成后跑一轮对应测试。
不要一上来就把所有事情都钩住，否则会有两个问题：
- 每次修改都变得很慢。
- 你可能很快对整个自动化链产生厌烦，因为它总在打断迭代节奏。
好的 Hook 不是“越多越好”，而是“刚好能拦住最常见的人为疏漏”。
Routines：把周期性维护工作从你脑子里搬到云端
素材最后提到 Routines，这部分尤其适合已经开始把 Claude 用在持续工作流中的人。Routines 的核心价值是：它不是你当下手动触发一次，而是把某件重复性、周期性的工作安排成计划任务，在云端自动运行。
素材里提到的使用方向
- 夜间自动审查 pull request。
- 每周一自动整理 bug 列表。
- 定期检查文档并标记可能过时的内容。
这些任务有个共同点：都重要，但很容易因为忙别的事情而拖延。Routines 能把它们从“想起来才做”变成“按计划发生”。
一个好 Routine 应该具备三件事
- 有清晰的执行时间或频率。
- 有明确边界，不是无限泛化的模糊任务。
- 有固定输出形式，方便你查看结果。
例如“每天检查项目”就太宽泛了，最好改成这种：
每个工作日早上 8 点，检查当前所有打开的 pull request，汇总改动区域，标记缺失测试和高风险变更，并输出一段简短审核摘要。
这样它才真正可执行、可评估、可长期复用。
素材里还提到不同计划的使用次数限制。实际应用时，这意味着你应该把 Routines 留给那些确实值得自动化的持续任务，而不是把任何零散动作都塞进去。
一套可以长期复用的 Claude Code 工作闭环
如果把整篇教程浓缩成一套最实用的操作顺序，我建议你用下面这个闭环：
- 先用一句话定义最终交付物。
- 进入 Plan 模式，让 Claude 先给架构、模块和取舍。
- 审规划，确认方向，不满意就先改规划。
- 根据任务难度选择模型和
effort。 - 让 Claude 做第一版实现。
- 用精准增量提示继续迭代，而不是重开。
- 把稳定规则沉淀进
CLAUDE.md。 - 当项目需要真实数据或真实动作时，再接入 MCP。
- 多轮迭代后主动重新锚定上下文。
- 部署前检查生产环境风险，再发到线上。
- 证明工作流有效之后，再逐步引入 Skills、Hooks、Routines。
这套闭环看起来不复杂，但它能挡住绝大多数初学者最常见的问题：方向模糊、频繁返工、上下文漂移、上线失败、每次都从头说明规则。
几个会在后面持续省时间的配置决策
有些选择当下看起来不起眼，但会直接影响之后几十轮会话的顺畅度。
1. 一个项目最好只有一个清晰目标
不要把完全不同用途的实验都堆进一个目录里。Claude 在读取项目时，很依赖结构和命名来建立理解。项目目标越混，后续建议越容易失焦。
2. 提示词尽量写“结果”，少写空泛形容词
“做得现代一点”“优化一下体验”都太虚。更有效的说法是：
- “确保这个界面在手机上不用横向滚动。”
- “保留当前拖拽板块，在右侧新增工作量分析面板。”
- “先不要引入数据库，第一版只用本地数据。”
这些约束都是可以验证的，因此 Claude 的执行质量会高很多。
3. 做大改前，先让 Claude 解释它打算怎么改
这不是为了拖延，而是为了防止误改。越是涉及多文件、结构调整、部署相关变更，越值得先让它解释方案。
4. 第一版范围一定要收紧
很多问题不是 Claude 做不好，而是你一开始就让它同时做太多事：要好看、要协作、要统计、要接 Slack、要自动部署、要权限控制、要移动端、要上线。结果每个点都只做了半截。更稳的策略是：第一版先跑通核心流程，第二版再增强外连和自动化。
最终操作检查清单
在一次 Claude Code 构建会话结束前，建议你至少对照下面这份清单过一遍：
- 当前项目的目标是否仍然明确，没有中途漂移。
- 你现在使用的模型是否匹配任务复杂度。
- 当前
effort是否匹配“做错的代价”。 - 在大规模生成代码前，规划是否已经审过。
- 最新一轮提示是否明确写出了“要改什么”和“不能破坏什么”。
- 应该长期保存的规则是否已经写进
CLAUDE.md。 - 外部工具是否只在有明确工作流需求时才接入。
- 如果会话已经变长变乱，是否做过一次上下文重新锚定。
- 部署前是否检查了生产构建、环境变量和外部依赖。
- Skills、Hooks、Routines 是否只加在真正能减少重复劳动的地方。
- 上线后是否从真实用户视角完成了一轮访问验证。
如果这份清单里你能稳定做到八成以上，Claude Code 的使用质量通常就会非常不一样。你不会再把它当成一个“碰运气的 AI 工具”，而会把它纳入一个可控、可迭代、可沉淀的开发系统里。
来源说明
本文基于 YouTube 教程素材整理撰写：Zinho Automates 发布的 “Claude Code Tutorial: Beginner to Advanced in 20 Minutes”。来源链接：https://www.youtube.com/watch?v=ujHXnlSVheI