Claude Code 新手避坑指南：桌面版上手与6个关键设置

Claude Code 的安装门槛刚刚被彻底拆掉了。过去要装 Node.js、跑 NPM、再配一个 Cursor 才能看到文件，现在只要去官网下载桌面应用，双击安装、登录就能用。B站这条中英双语教程把从零到跑通完整项目的过程压缩成了一条清晰的路径，其中真正值钱的不是「怎么点按钮」，而是几个决定效率与安全边界的设置习惯。

动手之前：付费门槛与模型选择

视频开头就点明了一个容易踩空的坑：Claude Code 需要 Pro 及以上的付费计划，免费版根本打不开这个入口。装好应用后，视线要落到发送按钮旁边的模型下拉框——这是整条工作流里最值得反复操作的地方。

作者给出的核心方法论是「一个模型规划，另一个模型施工」。规划阶段用 Opus，它推理更慢更深，能在文件还没生成时就把边界情况和文件清单想清楚；即便 Opus 5.5 降价后，它的单 token 成本仍高于 Sonnet。施工阶段切到 Sonnet，写代码快、单价低，适合照图施工。作者特意强调，规划阶段是改主意成本最低的时刻——在计划里挪一个章节不花任何代价，等代码写完再改就贵了。做单页小站时这个交接显得有点小题大做，但在更大的项目上，这套分工几乎每次都用得上。

Opus 与 Sonnet 的定位差异源自 Anthropic 的 Claude 模型家族分层：Opus 是旗舰级，参数规模与推理深度最大，适合复杂规划与长链条推理；Sonnet 是均衡级，速度与成本更优，编码能力足以应对大多数实现任务。两者的计价按输入/输出 token 分别计算，Opus 的单 token 价格通常是 Sonnet 的数倍，这也是「规划用贵、施工用便宜」分工的经济学基础。需要注意的是，模型下拉框中的可选项会随订阅档位变化，Pro 档在高峰期可能对 Opus 有更严格的用量限制。

最关键的一步：给对文件夹

打开 Code 标签页、选择 local、指定一个文件夹，从那一刻起 Claude 就把这个目录当作工作区，可以读取、修改、运行里面的一切。作者的建议是每个项目新建一个独立空文件夹，不要把桌面或下载目录直接丢给它。聚焦的目录既能给模型正确的上下文，也把它隔离在无关文件之外。

验证连接的方法很简单：输入「这个项目里有哪些文件」，如果它能列出内容或告诉你文件夹是空的，说明链路通了。

这一步的隐含风险值得多说一句。工作区权限是 Claude Code 能力的来源，也是它可能误伤文件的来源。作者在后面专门用一整段讲审批规则：安装知名包、启动本地服务器、跑测试属于常规操作，可以快速放行；涉及删除文件、覆盖数据、推送上线的命令则要慢下来读清楚。能轻易撤销的就风险小，不能撤销的就花十秒钟确认。

工作区（workspace） 是 Claude Code 的权限边界：被选中的目录及其子目录构成模型可读写、可执行命令的文件系统范围，之外的路径它既看不到也改不了。这与 IDE 打开文件夹的概念相似，但差别在于 Claude Code 会主动在该目录内运行 shell 命令、安装依赖、启动服务，因此目录选择直接决定了「爆炸半径」。业界通行的做法是为每个项目建立独立 git 仓库再交给它，这样任何改动都能通过版本控制回滚，把不可撤销操作变成可撤销操作。

三个项目串起的完整循环

教程用四个由小到大的项目演示了同一套节奏。第一个是播客单页站，用来看清「空文件夹到浏览器里能看的东西」的完整闭环。第二个是 Chrome 扩展：选中网页句子、右键保存为引用，弹窗里带着原文、页面标题和链接，一键复制成干净的笔记。这个项目作者直接跳过规划步骤切到 Sonnet，理由是范围小且清晰——知道什么时候不用贵模型，本身就是这套方法的一半。

第三个项目没有界面，是一个 Python 脚本，盯着下载文件夹，按文件类型把 PDF、图片、安装包、表格分别归入子文件夹，重名文件加数字而不是覆盖。这个项目动的部件多，所以回到 Opus 做计划，再切 Sonnet 施工。也正是在这里，Claude 不再是聊天框：它自己执行命令，先展示要装哪些包、要启动什么，等你批准，输出就在同一个窗口里滚动。

第四个项目是纯浏览器端的订阅追踪器，单文件 HTML，双击即开，数据只留在本机浏览器里。作者故意加了一条「全部塞进一个文件」的约束，防止项目膨胀成它不需要的样子。跑通之后再提一个小需求——7 天内续费的标红、月度总计旁边加年度总计——diff 显示只动了列表样式和总计计算，其余没碰。这正是使用这个工具会陷入的循环：先快速交付一个能用的版本，再用一句句短请求把它磨成自己的东西。

两个容易被忽略的习惯

第一个是 claude.md。用到第四个项目和时会发现，你总在重复同样的话：用纯 JavaScript、别加库、命名写清楚。Claude 本身不跨会话记忆，每个新对话都从零开始。解决办法是在项目根目录放一个 claude.md，它每次在这个项目里干活时都会读取，你的常驻规则在敲第一个字之前就已在上下文里。懒得手写也行，直接在对话里让它扫一遍项目、起草一份，再自己补充几条。作者给订阅追踪器定的规则只有四行，但效果立竿见影。

第二个是会话卫生。两种陷阱都来自长时间的对话：一是让会话无限增长，几小时后上下文拥挤，Claude 开始重复自己或忘记早前的决定，此时输入 compact 让它压缩出关键决策、丢掉噪音；二是同一个 bug 连续修三次还不好，通常说明对话本身已经成了阻力，里面全是错误的猜测。这时开一个新会话，干净描述问题、贴完整报错、指向具体文件，短而干净的上下文几乎总能打败充满失败尝试的长上下文，而 claude.md 会跟着你进入新会话，什么重要的都不会丢。

上下文窗口（context window） 是模型单次对话能容纳的 token 总量上限，包含系统提示、历史消息、文件内容和命令输出。对话越长，早期信息被挤出或被压缩得越厉害，模型对先前决策的召回就越不可靠，表现为重复提问、前后矛盾或忘记约定。compact 命令的作用是把历史对话摘要成一段浓缩上下文，保留关键决策与结论、丢弃冗长的试错过程，从而在不丢失主线的前提下释放窗口空间。这也是为什么「短而干净的新会话」往往优于「塞满失败尝试的长会话」。

进阶：计划模式、任务简报与云端并行

计划模式把前面手工的「Opus 规划」内置进了工具：开启后 Claude 只读项目、写计划、不改文件，你审完计划再放行施工。任何涉及两三个以上文件的改动都适合先走这一步，避免它写到一半发现需要重构刚建好的东西。

再往上一步是整包交接：给 Claude 一个多步骤任务，让它不必每写完一个文件就等你。这依赖一份合格的简报，包含四部分——目标、约束、什么算完成、明确不要加什么。作者用一个内容日历举例，一条消息之后它依次规划、搭结构、建表单、周视图、发布开关和删除按钮，这时 auto 模式才真正有用：常规命令自动通过，只有带风险的操作才停下来问。完成之后你的角色切换成验收，打开预览把简报里的四个动作挨个测一遍。

还有一个仍处于 beta 的新功能：云端并行跑多个这样的交接任务，各自独立线程。作者的态度很实在——新手别从这里开始，每个并行任务都是多一份你要审的结果，而审阅始终是你这半边的事。

auto 模式指的是让 Claude Code 对工具调用（执行命令、写文件、装包等）自动放行而不再逐条询问的审批策略，与之相对的是每条命令都要人工确认的默认模式。它的价值在于减少高频低风险操作的打断，但代价是把判断权交给了模型：一条看似常规的 rm 或 git push 可能造成不可逆后果。因此通行实践是先用默认模式建立对模型行为模式的直觉，再对边界清晰的项目开启 auto，并对删除、覆盖、部署类命令保留白名单以外的确认。云端并行任务则把每个交接跑在独立线程与独立环境中，彼此不共享上下文，审阅成本随任务数线性增长。

关于边界与成本的实话

作者没有把工具吹成万能。银行后台、有严格安全要求的医疗平台这类工作，需要深层的架构决策和多年领域知识，Claude Code 替代不了工程团队，桌面版也没有改变这一点。它改变的是谁能开始：如果你的工作流里有个具体问题市面上没有应用能解，这里就是起点；如果一个想法不确定值不值得花钱请开发者，用一个下午做个粗糙版本，给几个真实用户看看再决定。只需要可点击的原型给谁看的话，普通 Claude 对话自带的 artifacts 就够了，连项目文件夹都不用建。

成本上，Claude Code 包含在付费计划里，Pro 档约每月 20 美元，每周用几次的话这是合适的起点；老是撞用量上限再考虑约 100 美元起的 Max。按 token 付费的 API 听起来便宜，但一次长时间 Opus 规划本身就可能花掉几美元，等摸清真实用量再切过去。

作者说如果只改一个默认设置，就是 auto 模式——新手应该先看到每一条命令，而不是让 Claude 跳过询问。

整套看下来，你的工作已经从写代码变成了决定建什么、砍什么、结果到底好不好。Claude 造得快，但它对文件名是否合理、播客页面看起来是否廉价没有任何意见。那份判断始终在你手上。