1. 这篇写给谁，看完能解决什么

如果你是日常写代码的开发者、带项目的技术负责人，或者做研究/原型验证的人，这篇适合你：你可能已经“能让 AI 写点代码”，但经常卡在三类问题上：频繁权限确认打断节奏、复杂需求容易写崩、越用越贵还不知道钱花在哪。

看完你会拿到一套可复用的 Claude Code 工作流：

• 1 分钟启动并接续上次会话的命令套路。
• 用 Plan Mode 先把方案想清楚，再让它动代码，降低返工率。 code.claude
• 多任务并行的组织方式（一个终端一个工作区/树）。
• 把“常用长提示词”做成 commands / skills / subagent，减少重复沟通。
• 用 ccusage 把 token/费用可视化，知道贵在哪里。

---

2. 快速上手：启动、续聊、看最近会话

三个最常用的入口命令

• 启动并跳过每次“是否执行”的确认：claude --dangerously-skip-permissions。
• 紧接上次对话：claude -c。
• 查看/继续最近聊天：claude -r（claude --resume）。

我对 --dangerously-skip-permissions 的态度：能不用就别用

这条参数本质是“跳过所有权限确认”，用起来确实爽，但风险也是真实存在的：一旦模型误解了指令，它可能在没有二次确认的情况下执行修改/删除等操作，破坏环境的代价很高。 社区里也有人专门提醒它“危险不是口号”，属于你必须知道后果再开的开关。 reddit

更稳的策略是：日常保持可控权限；只有在隔离环境、可随时重建的场景里，才考虑“跳确认”这种模式。 claudelog

---

3. 核心工作流：Shift+Tab 的 Plan Mode，先规划再动手

“中间过程先 Shift+Tab 切 plan 模式，讨论与设计，然后再按 task 拆任务并跟踪”，这是非常靠谱的使用姿势。 Claude Code 官方文档也明确：你可以在会话中用 Shift+Tab 在不同权限模式间循环切换，其中就包括 Plan Mode。 code.claude

3.1 Plan Mode 到底解决什么问题

Plan Mode 的价值很简单：把“想清楚”放在“改代码”之前，让你先看到它准备怎么改、改哪些文件、按什么步骤做，再决定要不要让它执行。 对复杂改动（重构、多文件联动、引入新依赖）尤其有效，因为你可以在它开干前就把方向纠正掉。 code.claude

3.2 一个你可以直接照抄的指令模板

你在 Plan Mode 里可以这样下指令（示例）：

• “先不要改代码。用 Plan Mode 给我一份实施方案：目标、需要改的文件清单、步骤、风险点、回滚方案、验证/测试点；最后列一个任务列表，每个任务可独立提交。” code.claude

这样做的好处是：你把“可控性”拉回来了，避免它一股脑改完一堆文件，你再去猜它改了啥。 code.claude

---

4. 把大任务拆成可跟踪的 task（以及 .claude 的作用）

Plan 模式讨论完后，“要求分 task 创建任务（区别之前的 todo，会放到 .claude 里），进行任务完成与跟踪”。 这背后的方法论是：让 AI 不只是输出代码，而是像一个能自我检查的工程助手，能把工作拆小、能逐项交付、能持续对齐。

你可以把 task 设计成“最小可验收单元”，每个 task 都带上：

• 输入：背景/约束/已有代码位置
• 输出：改动文件 + 提交点（或变更摘要）
• 验收：如何验证（单测、集成测试、手工步骤）
• 风险：可能破坏什么、怎么回滚

这类 task 的意义在于：你随时可以中断、调整优先级，也能把它接到团队的真实流程里（比如 PR、Code Review、CI）。

---

5. 多任务并行：一个终端一个 tree（别把所有事情塞一个会话）

多任务并行时“创建 git 树，一个终端一个 tree”。 不管你具体用的是 git worktree、还是你习惯的多分支/多目录，本质都是一件事：让不同任务的上下文和代码改动隔离，避免互相污染。

一个实操建议：

• 任务 A（修 bug）：一个工作区 + 一个 Claude 会话
• 任务 B（加特性）：另一个工作区 + 另一个 Claude 会话
• 每个任务独立提交、独立测试、独立 PR

你会发现它不仅并行更快，回滚也更干净。

---

6. 文本与图片粘贴：别小看“输入效率”

在 Mac 上粘贴图片用 control+v，文本粘贴用 command+v。 这种技巧看起来小，但在你频繁贴报错截图、架构图、日志片段时，能明显减少打断感。

---

7. 把“长提示词”做成可复用资产：项目系统提示词、skills、commands、subagent

7.1 项目系统提示词：让它长期记住你的代码标准

项目系统提示词需要维护，“每次有修改直接说让他自己更新和修改就行”。 你可以把它当成项目的“编码宪法”，内容尽量具体，例如：

• 代码风格（lint/format）、目录结构约定
• 前后端接口风格、错误码规范
• 日志与监控埋点约定
• 测试要求与覆盖范围

这样你不用每次从头讲一遍，它输出也更稳定。

7.2 skills：让它按任务驱动做“文档更新、提交、审查”

skills 的一些方向：任务驱动文档更新、git 提交、代码审查，并提到网上有很多 skill 分享站点可以直接搜来用或复制。 你可以把 skills 理解成“把常见工程动作产品化”，例如：

• “生成变更说明 + 更新 README + 补迁移文档”
• “按团队 PR 模板自查并输出 Review 清单”

7.3 commands：把你最常用的长 prompt 固化成一个命令

常用的 prompt 可以做成自己熟悉的 command，把文档要求、前后端标准、执行计划模板、测试策略等都预置进去；使用时像 /lettery:start+内容 这样触发即可。

这是提升稳定性的关键：你不是每次临场发挥，而是把“你认可的写法”固化成工具能力，输出自然更一致。

7.4 subagent：省主会话上下文，让主会话只做调度

预设常用写代码要求，用 subagent 主要为了“节省主会话上下文”，主会话只负责调用拿结果，不用在主会话做一长串操作。

更直白点说：

• 主会话：当项目经理，负责目标、验收、决策
• subagent：当执行者，按你预设的标准产出代码/文档/测试

这会让你的主会话更“干净”，也更不容易越聊越乱。

---

8. 直接用别人的开发规范：插件化复用（但要会“读懂再改”）

社区有很多封装好的 plugin，下载后就能用别人的 commands、skills、agent；作者的学习方法是“先用、看他们怎么用、理解后再改”。 这条路线非常现实：你不需要从零造轮子，先跑起来，再把它改成符合你团队习惯的版本。

包括 trellis、openspec、superpower，以及一个 Claude 黑客松获奖的 evething-claude-code。

---

9. 成本与用量：用 ccusage 把 token 花费看清楚

装 ccusage 看自己的 token 使用情况，命令是 npm install -g ccusage 然后运行 ccusage。 在 npm 上，ccusage 的定位就是分析 Claude Code 的 token 使用与成本（从本地 JSONL 文件分析），并提供包括实时监控等能力。

9.1 你应该怎么用它（最小动作）

• 安装：npm i -g ccusage。
• 运行：ccusage 查看默认报告，或用它的子命令做更细分析（例如 daily、实时 blocks 等）。 claudelog

当你觉得“今天怎么这么贵”时，先别猜，让数据告诉你是哪个会话、哪类任务最烧钱，然后再决定要不要拆分会话、减少上下文、或者把重复工作做成 commands/skills。 claudelog

---

10. 一个可落地的日常流程（把上面全串起来）

你可以把每天用 Claude Code 的节奏固定成下面这套，基本不会翻车：

1. 新任务先开 Plan Mode：让它给方案、文件清单、风险点、验收方式。 code.claude
2. 把方案拆成 3～8 个 task：每个 task 都能独立提交、独立验证，并按任务跟踪推进。
3. 并行任务用隔离工作区：一个终端/一个 tree 对应一个任务，避免上下文与改动互相污染。
4. 稳定输出靠资产化：项目系统提示词维护起来；常用要求做成 commands；执行型工作下沉到 subagent。
5. 每周看一次 ccusage：找出最贵的会话类型，针对性优化（拆会话、减少无效上下文、复用命令）。

---

结语：追求“快”的前提是“可控”

核心其实就一句话：让 Claude Code 快起来，但别失控——先计划、再拆任务、隔离并行、把常用套路固化成命令和 agent，再用 ccusage 盯住成本。 真要开 --dangerously-skip-permissions 这种强力开关，也尽量放在可重建、无重要数据的隔离环境里，把风险关在笼子里。 claudelog