50 条 Claude Code 日常使用技巧与最佳实践
## 50 条 Claude Code 日常使用技巧与最佳实践。。
50 条 Claude Code 日常使用技巧与最佳实践
如果你已经把 Claude Code 用了一段时间，那你大概已经知道它确实能干活。接下来想要的，无非是再多抠一点效率出来。我整理了 50 条自己每天都在用的 Claude Code 经验和技巧。无论你才上手一周，还是已经深度用了几个月，里面都能挑到有用的东西。内容参考了 Anthropic 官方文档、Boris Cherny（这个产品的核心构建者）、社区实战经验，以及我自己这一年里的日常使用体会。
1. 先把 cc 这个别名配上
我每次开 Claude Code 会话，第一步都是这个。把下面这段加到你的 ~/.zshrc（或者 ~/.bashrc）里：
alias cc='claude --dangerously-skip-permissions'
执行 source ~/.zshrc 让配置生效。之后你输入 cc 就行，不用每次敲 claude，也能跳过权限确认。这个 flag 的名字故意起得很吓人，原因也很简单：只有你真的清楚 Claude Code 能对代码库做什么，再去开它。我在这篇 customizing Claude Code 里还写了更多实用别名。
2. 在命令前加 !，直接内联跑 bash
输入 !git status 或 !npm test，命令会立刻执行。命令本身和输出结果都会进上下文，所以 Claude 能看到结果并继续处理。很多时候，这比你先用文字叫 Claude 去运行命令要快得多。
3. 按 Esc 停下 Claude，按两次 Esc 直接回退
Esc 可以在 Claude 执行到一半时停下来，而且不会丢上下文。你可以立刻改方向。
Esc + Esc（或者 /rewind）会打开一个可滚动菜单，里面是 Claude 创建过的所有检查点。你可以恢复代码、恢复对话，或者两者一起恢复。直接说一句 “Undo that” 也行。恢复方式一共四种：恢复代码和对话、只恢复对话、只恢复代码、或者从某个检查点开始做摘要继续往后。
这意味着你可以放心试那些自己只有四成把握的方案。成了就留下，不成就回退，代价很小。唯一要注意的是：检查点只记录文件编辑。bash 命令带来的改动，比如数据库迁移、库操作，不会被收进去。
如果你想接着上次的会话继续，claude --continue 会恢复最近一次对话，claude --resume 会打开会话选择器。
4. 给 Claude 一个自检回路
让 Claude 能自己验证自己的结果，这件事很值。你可以在提示词里顺手带上测试命令、lint 检查，或者期望输出。
Claude 会自己跑测试，看到失败后再继续修，不用你一直盯着。Boris Cherny 说过，光这一条就能把质量拉高 2 到 3 倍。如果是 UI 改动，最好把 Playwright MCP server 也配上，这样 Claude 可以直接开浏览器、操作页面、确认界面是不是按预期工作。很多单元测试抓不到的问题，靠这个反馈回路反而能揪出来。
5. 给你的语言装一个代码智能插件
LSP 插件的作用很直接：每次 Claude 改完文件，诊断信息会自动跟上来。类型错误、没用的 import、缺失的返回类型，这些问题它会在你发现之前先看到并修掉。就影响力来说，这是最值得装的一类插件。
选好对应语言后，直接跑安装命令就行。
C#、Java、Kotlin、Swift、PHP、Lua、C/C++ 这些语言也有现成插件。输入 /plugin，去 Discover 标签页里翻完整列表。别忘了，系统里还得先装好对应的 language server 二进制；如果没装，插件会提醒你。
6. 用 gh CLI，也顺手教会 Claude 其他 CLI
gh CLI 能直接处理 PR、issue 和评论，不需要额外再起一个 MCP server。相比 MCP，CLI 工具更省上下文，因为它不会把整套工具 schema 塞进上下文窗口。jq、curl 这类常规命令也是一样的道理。
至于 Claude 还不会用的工具，你可以直接这样说：Use 'sentry-cli --help' to learn about it, then use it to find the most recent error in production. 它会先读 help 输出，摸清命令语法，再自己把命令跑起来。哪怕是很偏门的内部 CLI，通常也能学会。
7. 复杂问题前加一句 ultrathink
这是一个关键字，会把 effort 调到 high，并在 Opus 4.6 上触发更强的自适应推理。Claude 会根据问题复杂度自己分配思考量。架构决策、棘手调试、多步推理，或者任何你希望它先认真想一轮再动手的场景，都适合加这句。
你也可以用 /effort 长期设定思考强度。简单任务就把 effort 调低，速度和成本都更合适。思考量要和任务匹配，变量重命名这种事，没必要烧一堆 thinking tokens。
8. 用 skills 按需补知识
Skills 本质上是 Markdown 文件，用来按需扩展 Claude 的知识。和每次会话都会加载的 CLAUDE.md 不一样，skills 只有在当前任务相关时才会加载，所以上下文会更干净。
你可以把 skill 放进 .claude/skills/，也可以直接安装带预制 skills 的插件（跑 /plugin 就能看到）。这特别适合放一些“不是每次都要用，但偶尔必须知道”的领域知识，比如 API 约定、部署流程、编码习惯之类。
9. 用手机远程控制 Claude Code
执行 claude remote-control 启动一个会话，然后去 claude.ai/code 或 iOS/Android 上的 Claude App 连进去。实际会话是跑在你本地机器上的，手机或浏览器只是一个窗口。你可以远程发消息、批准工具调用，也可以随时看进度。
如果你已经按第 1 条配好了 cc 别名，Claude 本来就有完整权限，不需要每一步都等你批准。这样远程控制会更顺：把任务甩给它，人先走开，等它做完或者遇到异常，再拿手机回来看看。
10. 把上下文窗口拉到 100 万 tokens
Sonnet 4.6 和 Opus 4.6 都支持 100 万 token 的上下文窗口。Max、Team 和 Enterprise 计划里，Opus 会自动升级到 1M context。你也可以在会话中途用 /model opus[1m] 或 /model sonnet[1m] 直接切模型。
如果你担心超大上下文下的质量波动，可以先从 500k 开始，慢慢往上加。上下文越大，触发 compaction 的时机会越晚，但回复质量还是会随任务类型变化。你可以用 CLAUDE_CODE_AUTO_COMPACT_WINDOW 控制何时开始压缩，用 CLAUDE_AUTOCOMPACT_PCT_OVERRIDE 调整阈值百分比。最终还是得自己试出最顺手的点。
11. 不确定怎么做时，就开 Plan Mode
碰到多文件修改、不熟悉的代码，或者架构类决策时，Plan Mode 很值。前面多花几分钟，能避免 Claude 花 20 分钟一本正经地解决错问题。
如果任务本身小、范围也清楚，那就别开。只要你能用一句话说清这次改动，大多数时候直接做更快。你也可以随时按 Shift+Tab 在 Normal、Auto-Accept 和 Plan 这几种权限模式之间切换。
12. 不相关的任务之间，记得 /clear
一个干净的会话，加上一个聚焦的提示词，往往比一个乱糟糟跑了三小时的会话更有效。换任务了？先 /clear。
我知道这看起来像是把进度清空了，但重新开始通常结果更好。会话会逐渐变钝，因为前面堆积的上下文会慢慢淹掉你现在真正关心的指令。花 5 秒 /clear 再重新写个更聚焦的开场，通常能帮你省掉后面 30 分钟的低效拉扯。
13. 别替 Claude 解读 bug，直接把原始数据贴给它
你自己先用文字描述 bug，往往很慢。Claude 会先猜，再修正，再继续猜，来回折腾。
直接贴错误日志、CI 输出，或者 Slack 讨论串，然后说一句 “fix”。Claude 其实很擅长直接读分布式系统日志，再顺着线索找问题在哪。你自己先做一层解释，反而容易把关键细节抹掉。把原始数据给它，然后让开。
CI 也是同样的路子。像 “Go fix the failing CI tests”，再附上 CI 输出，这类模式我用下来一直很稳。你也可以直接贴 PR 的 URL 或编号，让 Claude 去看失败的检查项并修掉。只要你装了第 6 条提到的 gh CLI，后面它自己能接住。
你也可以直接把终端输出 pipe 进去：
14. 用 /btw 问临时小问题
/btw 会弹出一个临时浮层，让你问个小问题，而且不会把内容写进主对话历史。我经常拿它来问当前会话里的澄清问题，比如：“你为什么选这个方案？”或者“另一个方案的取舍是什么？”
回答会显示在一个可关闭的浮层里，主上下文不会被冲脏，Claude 还能继续做它原本的事。
15. 用 --worktree 起隔离分支，并行跑多个任务
claude --worktree feature-auth 会创建一个隔离的工作副本，并带一个新分支。Claude 会顺手把 git worktree 的创建和清理都处理掉。
Claude Code 团队把这个叫作 最能拉开生产力差距的功能之一。你可以同时开 3 到 5 个 worktree，每个 worktree 跑自己的 Claude 会话。我自己一般会并行开 2 到 3 个。每个 worktree 都有独立会话、独立分支、独立文件系统状态。
本地 worktree 的上限，最后还是看你机器扛不扛得住。多个 dev server、构建进程和 Claude 会话一起抢 CPU，很容易把本机拖慢。Builder.io 的做法是把每个 agent 放到单独的云容器里，再配浏览器预览，这样你本机就能留给真正需要你自己动脑的工作。
16. 用 Ctrl+S 暂存提示词草稿
你长提示词写到一半，突然想到有个小问题要先确认。按 Ctrl+S，当前草稿就会先被暂存起来。你可以先问那个小问题，提交后，刚才那段草稿会自动恢复。
17. 长时间运行的任务，用 Ctrl+B 扔到后台
当 Claude 启动一个很耗时的 bash 命令，比如测试套件、构建或者迁移时，按 Ctrl+B 可以把它送去后台。Claude 会继续工作，你也能接着聊天。等进程跑完，结果会自动回来。
18. 加一条实时状态栏
状态栏本质上是一个 shell 脚本，会在 Claude 每一轮结束后执行。它可以把实时信息显示在终端底部，比如当前目录、git 分支、上下文使用量，以及窗口快满时的颜色提醒。
最快的配置方式，是在 Claude Code 里直接运行 /statusline。它会问你想显示什么，然后帮你把脚本生成出来。我在 customizing Claude Code 里也写了完整配置和可直接复制的脚本。
19. 用 subagents 保住主上下文的干净度
比如你可以说：Use subagents to figure out how the payment flow handles failed transactions. 这会拉起一个独立的 Claude 实例，拥有自己的上下文窗口。它会去读文件、理解代码，再回报一份简洁摘要。
这样你的主会话还能保持清爽，留足空间继续实现功能。一次深入调查，很容易先吃掉半个上下文窗口，代码还没写就已经臃肿了。subagents 能把这部分成本隔离出去。内置类型里有 Explore（Haiku，适合快速找文件）和 Plan（只读分析）。想看完整玩法，可以读这篇 subagents and agent teams。
20. 用 agent teams 做多会话协作
这个功能还算实验性质，但确实很猛。先在设置或环境变量里打开 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS，然后直接告诉 Claude：Create an agent team with 3 teammates to refactor these modules in parallel. 团队负责人会把任务分发给不同成员。每个成员都有自己的上下文窗口，也共享一份任务列表。成员之间还能直接互相发消息协调。
建议先从 3 到 5 个队友开始，每人分 5 到 6 个任务。别把会改同一批文件的任务塞给不同人，两个人同时改一个文件，很容易互相覆盖。刚开始最好先拿研究类和 review 类任务练手，比如 PR review、bug 调查，别一上来就并行改实现。
21. 用明确指令引导 compaction
上下文压缩时，不管是自动触发还是你手动 /compact，都可以提前告诉 Claude 哪些信息必须保留。比如：/compact focus on the API changes and the list of modified files.
你也可以把这类要求写进 CLAUDE.md，例如：“When compacting, preserve the full list of modified files and current test status.” 这样每次压缩时，它都会尽量保住你真正关心的东西。
22. 用 /loop 做周期性检查
/loop 5m check if the deploy succeeded and report back 会在后台安排一个循环提示任务，只要当前会话还开着，它就会按间隔重复执行。时间间隔是可选的，默认 10 分钟，支持 s、m、h、d 这些单位。你也可以循环其他命令，比如：/loop 20m /review-pr 1234。
这些任务是跟会话绑定的，3 天后会自动失效，不会永久跑下去。它很适合用来盯部署、盯 CI 流水线，或者轮询外部服务状态，而你自己可以去忙别的。
23. 用语音输入，把提示词讲得更完整
执行 /voice 开启按住说话模式，然后按住空格开始口述。语音会实时转成提示词，而且你可以在同一条消息里混用语音和键盘输入。和打字相比，口述往往会自然带出更多背景、约束和真实意图，因为人说话时没那么容易为了省字把信息砍掉。
这个功能需要一个 Claude.ai 账号，而不是 API key。你也可以在 ~/.claude/keybindings.json 里把按住说话快捷键改成 meta+k 这种组合键，省掉长按识别的等待。
24. 同一个问题纠正两次还没好，就重开
如果你和 Claude 围着同一个坑已经来回纠正了两轮，问题还是没解决，那当前上下文里大概率已经塞满了失败尝试，下一次反而更容易被带偏。这时最有效的办法通常不是继续补丁上补丁，而是 /clear，然后用一个更清楚的开场提示重新开始，把刚才踩过的坑吸收进去。
干净会话配更准的提示词，通常就是比一段被死路拖累的长对话更好用。
25. 直接告诉 Claude 该看哪些文件
用 @ 可以直接引用文件：@src/auth/middleware.ts has the session handling. @ 前缀会自动解析成路径，所以 Claude 能立刻知道该看哪里。
它当然也能自己 grep、自己搜代码库，但它还是得先缩小范围、再判断哪个文件才是目标。每一次搜索都在花 token、吃上下文。你要是能一开始就把文件指准，能省掉很多无效消耗。
26. 遇到陌生代码时，可以故意提得模糊一点
像 “What would you improve in this file?” 这种模糊提示，其实很适合探索。并不是每次都要把提示词写得特别具体。你想借一双新眼睛看现有代码时，留一点开放空间，Claude 反而更容易指出你自己不会主动想到的问题。
我刚接触一个不熟的仓库时，经常这么用。它会把模式不一致、结构怪异或者值得改进的地方先拎出来，省得我第一遍阅读时漏掉。
27. 用 Ctrl+G 直接编辑计划
当 Claude 先给出一个计划时，按 Ctrl+G 会直接在你的编辑器里打开这份计划。你可以手动加约束、删步骤、调整方向，在它还没写一行代码之前就把路线修正好。
如果计划整体上是对的，只是有几处你想动，这个方式会比重新长篇解释一遍省事得多。
28. 先跑 /init，再把生成结果砍掉一半
CLAUDE.md 是项目根目录下的一个 Markdown 文件，用来给 Claude 提供持久指令，比如构建命令、编码规范、架构决策和仓库约定。每次会话开始时，Claude 都会先读它。/init 会基于项目结构帮你生成一个起步版本，顺手带出构建命令、测试脚本和目录布局。
问题是，它生成的内容通常偏肿。如果你说不清某一行为什么必须存在，那就删掉。把噪音砍掉，再补上真正缺的内容。关于怎么写得更好，我在这篇 how to write a great CLAUDE.md file 里讲得更细。
29. 给每一行 CLAUDE.md 做个压力测试
判断标准很简单：如果没有这一行，Claude 会不会犯错？
如果它本来就会做对，那这一行大概率只是噪音。每多一条没必要的说明，真正重要的规则就会被稀释。经验上，大概 150 到 200 条指令之后，遵循度就会开始下滑，而系统提示本身已经先占掉差不多 50 条额度。
30. Claude 出错后，让它顺手更新 CLAUDE.md
当 Claude 犯了一个你不想让它重复犯的错，直接说：update the CLAUDE.md file so this doesn't happen again.
它会自己把规则写进去。下次开新会话时，这条规则就已经在那儿了。
久而久之，CLAUDE.md 会变成一份由真实错误慢慢雕出来的活文档。为了不让它无限膨胀，可以用第 32 条提到的 @imports，把更详细的模式和修复经验拆到像 @docs/solutions.md 这样的文件里。主文件保持轻，细节按需读。
31. 用 .claude/rules/ 放“只在特定场景生效”的规则
把 Markdown 规则文件放进 .claude/rules/，可以按主题拆分说明。默认情况下，每个规则文件都会在会话开始时加载。如果你只想让某条规则在 Claude 处理特定文件时再加载，可以加上路径 frontmatter：
这样你的主 CLAUDE.md 就不会被塞得太满。TypeScript 规则在它读 .ts 文件时加载，Go 规则则只在读 .go 文件时进来。它不用每次都在一堆无关约定里打转。
32. 用 @imports 给 CLAUDE.md 减肥
你可以引用像 @docs/git-instructions.md 这样的文档，也可以引用 @README.md、@package.json，甚至 @~/.claude/my-project-instructions.md。
Claude 会在需要的时候再去读这些文件。可以把 @imports 理解成一句话：“额外信息在这里，要用时自己去拿。” 这样就不用把所有内容都塞进每次会话必读的主文件里。
33. 用 /permissions 把安全命令加入白名单
像 npm run lint 这种你已经点了上百次批准的命令，就别再浪费注意力了。/permissions 可以把你信任的命令加进 allowlist。之后只有白名单外的命令才会再弹确认。
34. 想让 Claude 放开手做事，就用 /sandbox
执行 /sandbox 可以打开操作系统级别的隔离。写操作会被限制在项目目录内，网络请求也只允许访问你批准过的域名。macOS 下用的是 Seatbelt，Linux 下是 bubblewrap，所以限制会作用到 Claude 拉起的所有子进程。
如果你开的是 auto-allow 模式，那么在沙箱内部，命令可以不经过反复确认直接执行，基本就是“有护栏的高自主性”。如果你想让 Claude 无人值守跑长时间任务，比如隔夜迁移或者试验性重构，最稳的做法还是放进 Docker 容器里。容器提供更完整的隔离，也更好回滚。
35. 为重复任务创建自定义 subagents
这和第 19 条“临时调用 subagents”不是一回事。自定义 subagents 是预先配置好的 agent，保存在 .claude/agents/ 目录下。比如你可以做一个安全审查 agent，用 Opus 模型加只读工具；也可以做一个 quick-search agent，用 Haiku 提速。
输入 /agents 就能浏览和创建。你还可以配置隔离方式，比如让某些 agent 运行在独立 worktree 里。
36. 先挑对你的技术栈最值的 MCP servers
值得优先上的 MCP server，我的排序大概是：Playwright，用来做浏览器测试和 UI 验证；PostgreSQL / MySQL，用来直接查 schema；Slack，用来看 bug 报告和讨论上下文；Figma，用来做设计到代码的衔接。
Claude Code 支持动态加载工具，所以 server 只有在需要时才会把定义载入。想看更完整的名单，可以看看这篇 the best MCP servers in 2026。
37. 把输出风格调成你顺手的样子
执行 /config，选择你喜欢的输出风格。内置选项有 Explanatory（详细、一步一步来）、Concise（短、偏行动导向）和 Technical（更精确、更偏术语）。
你也可以在 ~/.claude/output-styles/ 里自己写自定义风格文件。
38. 建议写进 CLAUDE.md，硬性要求交给 hooks
CLAUDE.md 更像建议，Claude 大概会遵守八成。hooks 则是确定性的，接近 100%。如果某件事必须每次都发生，不能靠自觉，比如格式化、lint、安全检查，那就别只写在 CLAUDE.md 里，直接上 hook。
如果只是“你最好考虑一下这个习惯”，那 CLAUDE.md 就够了。
39. 用 PostToolUse hook 自动格式化
每次 Claude 编辑文件后，让格式化器自动跑一遍，这事应该尽量自动化。你可以在 .claude/settings.json 里加一个 PostToolUse hook，让它在 Claude 写完文件后自动执行 Prettier（或者你自己的 formatter）：
|| true 的作用是避免 hook 失败把 Claude 整体流程卡住。你也可以再串一个 npx eslint --fix 之类的命令。
如果你本地编辑器也正开着同一批文件，Claude 工作时最好考虑先关掉 format-on-save。有些开发者反馈，编辑器自动保存会让 prompt cache 失效，Claude 又得重读文件。让 hook 接管格式化，通常更稳。
40. 用 PreToolUse hook 拦住危险命令
像 rm -rf、drop table、truncate 这种命令，完全可以在执行前就拦掉。给 Bash 配一个 PreToolUse hook，Claude 连尝试都不会尝试。
把它加到项目里的 .claude/settings.json。你可以用 /hooks 交互式配置，也可以直接告诉 Claude：“Add a PreToolUse hook that blocks rm -rf, drop table, and truncate commands.”
41. 用 hooks 在 compaction 后把关键信息补回来
长会话里一旦触发上下文压缩，Claude 有时会忘掉眼前到底在做什么。一个带 compact 匹配器的 Notification hook，可以在每次 compaction 发生后，自动把关键上下文再塞回来。
你可以直接这样说：“Set up a Notification hook that after compaction reminds you of the current task, modified files, and any constraints.”
适合重新注入的信息包括：当前任务描述、已修改文件列表，以及那些绝对不能忘的硬约束，比如 “不要改 migration 文件”。
这个在多小时、深水区会话里尤其有用。做到一半丢线索，代价很高。
42. 登录、支付、数据改动这些地方，一定要人工复查
Claude 写代码没问题，但这类决策必须由人来兜底。认证流程、支付逻辑、数据写入、会改数据库结构的危险操作，都该你自己过一遍。
原因很现实：一个权限范围配错的 auth、一个 webhook 配错的支付回调，或者一个悄悄把列删掉的迁移，都可能直接让你丢用户、丢钱、丢信任。自动化测试再多，也兜不住所有这类问题。
43. 用 /branch 试另一条路，不丢当前进度
/branch（或者 /fork）会把当前对话在此刻复制出一个分支。你可以在分支里大胆试那个高风险重构。成了就保留，不成也没关系，原始对话完全不受影响。
这和第 3 条的 rewind 不一样。rewind 是回到旧状态，而 /branch 是两条路径都保留着。
44. 当你自己也说不全需求时，让 Claude 反过来采访你
你知道自己想做什么，但总感觉手里的信息还不够完整，不足以让 Claude 把功能做扎实。这时候别硬写规格，直接让 Claude 来提问。
等规格补完整之后，再开一个新会话去执行。这样上下文是干净的，规格也是完整的。
45. 让一个 Claude 写，另一个 Claude 审
先让第一个 Claude 实现功能，再让第二个 Claude 用 staff engineer 那种 fresh context 视角来 review。审查的这个 Claude 不知道实现过程中走过哪些捷径，所以它会更愿意把这些捷径一个个挑出来。
这套思路做 TDD 也成立。A 会话先写测试，B 会话再写通过测试的代码。
46. 用“对话式”方式做 PR review
不要只把 PR review 当成一次性输出（当然你真要一把梭也可以）。更好的方式是把 PR 打开，然后围着它聊。
比如问：“这个 PR 里最危险的改动是什么？”“如果它并发执行，会坏在哪里？”“这段错误处理和仓库里其他地方一致吗？”
对话式 review 更容易挖到关键问题，因为你能顺着真正重要的地方往下追。一次性 review 往往更容易抓到样式小毛病，却放过架构级问题。
47. 给会话命名，再配个颜色
/rename auth-refactor 可以给当前会话加一个标签，显示在提示栏上，方便你分辨。/color red 或 /color blue 可以顺手改提示栏颜色。可选颜色有：red、blue、green、yellow、purple、orange、pink、cyan。
当你同时跑 2 到 3 个并行会话时，花 5 秒命名和上色，能有效避免你把消息发进错误终端。
48. Claude 完工时，放个提示音
加一个 Stop hook，在 Claude 回复完成时播放系统提示音。你可以把任务丢给它，切去做别的，等听到 “叮” 再回来。
49. 用 claude -p 批量 fan-out
你可以在非交互模式下遍历一批文件。--allowedTools 能限制 Claude 在单个文件上允许做什么操作。再配合 & 并行起来，吞吐量会很高。
这种做法很适合批量格式转换、全仓统一改 import，或者那种“每个文件之间彼此独立”的重复迁移工作。
50. 自定义 spinner 的动词，纯属好玩，但确实挺解压
Claude 思考时，终端 spinner 会显示类似 “Flibbertigibbeting...” 和 “Flummoxing...” 这样的动词。你可以把它们全换成自己喜欢的风格。直接告诉 Claude：
Replace my spinner verbs in user settings with these: Hallucinating responsibly, Pretending to think, Confidently guessing, Blaming the context window
你甚至不用自己列清单，只说一种氛围也行。比如：“Replace my spinner verbs with Harry Potter spells.” Claude 会自己生成一套。
这不是什么刚需，但等待时确实会更有趣一点。
收尾
你没必要 50 条全上。先挑一条，最好是刚好能解决你上一次使用时最烦的那个点，明天就试试。
真正有用的，通常不是你收藏了 50 条技巧，而是其中哪怕只有 1 条，真的进了你的日常流程。