这两天刷到 Anthropic 联创 Boris Cherny 发的一串帖子，主题很直白：Claude Code 里那些“隐藏但高频”的功能。

我本来以为又是一波“AI 神器震撼发布，程序员即将失业”的标准互联网戏码，结果认真看完之后发现——还真不是。

因为这串内容最有价值的地方，不是教你怎么让 Claude “一键生成一个商城后台管理系统”，而是告诉你：

怎么把 Claude 真正接进日常开发流程里，变成一个靠谱、能接力、会自查、还能自动干活的工程搭子。

说白了，很多人现在用 Claude Code，还是停留在：

帮我写个函数
帮我改个 bug
帮我解释一下报错
帮我生成个脚手架

这当然也有用，但这就像你花重金请了个高级工程师，最后天天让他帮你改按钮文案。

多少有点浪费。

真正的高阶玩法，是让 Claude 不只是“回答问题”，而是开始参与整个工程流程：能跨设备接力、能自动跑、能验证结果、能长期记住项目习惯，甚至还能并行分身干活。

这才是这串技巧真正值钱的地方。

一、先说结论：Claude Code 最值得学的，不是“提示词”，而是“工作流”

如果你把 Boris 这组技巧串起来看，会发现它们其实都在解决同一个问题：

1. 别把 Claude 困在一个终端窗口里

很多人默认认为 Claude Code = 命令行里那个黑框框。

但实际上，它可以在手机、Web、桌面端、本地终端之间来回接力。你在地铁上想到一个改法，手机先说一嘴；回到工位，电脑继续干；临时出门，手机再接着盯进度。

这就不再是“一个工具”，而更像一个持续在线的工程会话。

2. 别让 Claude 只会被动等你发号施令

更高阶的用法，是让它自己按节奏跑。

比如每 5 分钟检查一次 review comment、自动 rebase、自动补改；或者每天定时扫一遍昨天 merged 的 PR，把文档更新掉；再比如定时看 Slack 里有没有人吐槽线上问题，然后整理成修复任务。

这时候 Claude 不再像“你有空才会叫一声的小助手”，而像一个有排班的工程协作者。

3. 别让 Claude 只靠脑补结果

尤其前端开发最怕这个。

你让它写个页面，它代码写得热血沸腾，最后一跑：按钮飞了、弹窗歪了、表单点不了、移动端直接塌方。

所以 Boris 特别强调一点：一定要给 Claude 一个“验证自己输出”的能力。

比如接浏览器、接 Chrome 扩展、接桌面端的内置 web 测试环境。你一旦让它“看得见结果”，它就不再是瞎改，而是能一轮一轮迭代，直到页面真能用。

4. 别让所有任务都挤在一个 Claude 身上

复杂项目里，最怕上下文全搅成一锅粥。

一个 Claude 改 API，一个 Claude 补测试，一个 Claude 修前端，一个 Claude 清理文档。如果都挤在同一条线里，最后一定会变成大型精神分裂现场。

所以 Boris 提到的 worktree、会话分叉、subagent，本质上都在解决一个问题：

让多个 Claude 并行干活，但彼此别踩脚。

这件事一旦通了，Claude 才真的有点“工程团队”的味道。

二、最值得普通开发者先学会的 6 个技巧

下面这几个，我觉得是最适合大多数工程师先上手的。不需要你搞特别复杂的配置，但收益很大。

1. 手机也能跑 Claude Code：别小看“随手改点东西”这件事

很多人第一反应是： “手机写代码？这不是纯折磨自己吗？”

先别急着嘲笑。

手机端当然不适合你在那里优雅地手写一个红黑树，但它特别适合这些场景：

临时补个小改动
看 diff
改文档
补注释
回 review
写 PR 描述
看一眼 CI 炸在哪
脑子里刚好闪过一个修 bug 思路，赶紧记给 Claude

你会发现，很多工程任务根本不需要你正襟危坐地打开 IDE 才能开始。以前这些零碎灵感，往往都是“等我回去再说”，然后回去就忘了。现在你可以直接手机上把任务丢给 Claude，让它先起跑。

这类能力最香的点，不是“手机写代码有多帅”，而是：

你和项目之间的距离，被压缩到了“想到就能推进”。

这非常值钱。

2. 会话跨设备接力：这才是 AI 工具应该有的样子

这是我觉得特别“未来已来”的一个点。

以前我们用编程助手，默认都接受一个设定： 换设备 = 重开一局。

你手机上想到东西，回电脑得重新讲一遍；网页里聊了一半，终端里再来一遍；桌面端已经跑起来的上下文，到另一个地方又得重新解释项目背景。

这事特别烦，而且烦得很隐蔽。你不一定意识到，但每天都在被它浪费时间。

而 Boris 提到的 teleport、remote-control 这种能力，本质上就是让 Claude 会话能跨设备流转。

你可以理解成：不是“我在不同地方分别用了几个 Claude”，而是“我带着同一个脑回路，到处接着干”。

这个体验一旦习惯了，就很难退回去。

典型场景特别真实：

通勤路上先把需求讲给 Claude
到工位后，直接本地接过来跑测试、改代码
下楼买咖啡时，手机顺手看看它有没有卡住
晚上电脑合上了，还能远程看它在干嘛

这才像一个真正“活着的工作流”。

3. `/loop` 和 `/schedule`：让 Claude 从聊天机器人升级成值班同事

这个能力我非常喜欢。

因为很多开发工作，根本不是“高难度脑力劳动”，而是那种特别烦、特别碎、但又必须有人盯着的活。

比如：

review comment 来了，得补改
branch 落后了，得 rebase
新 PR 合并了，文档可能要更新
Slack 里有人提了线上问题，得有人收集
stale PR、陈年分支、半死不活的任务，得有人清理

这些事你说难吧，也不难。你说不做吧，又迟早会反噬团队。最烦的是，它们还总是打断你本来正在做的正事。

所以 /loop 和 /schedule 真正解决的问题是：

把这些“必须有人盯”的琐碎工程活，交给 Claude 常驻处理。

你可以让它每隔几分钟巡检一次，也可以按天跑定时任务。它不像 cron 那样只是傻执行脚本，而是会“理解上下文后再行动”。

这就很像什么呢？

很像团队里那个最靠谱但也最不爱出风头的同事：平时不怎么抢镜，但脏活累活他都默默收了。等你某天回过神，发现 repo 干净了、PR 顺了、文档也补了。

那个瞬间你会很想请它吃顿饭。

4. Hooks：把“我每次都要提醒它”的事，变成系统默认行为

很多人用 AI 辅助开发都会碰到一个经典问题：

“这事我明明说过很多次了，它怎么还要我重复提醒？”

比如：

启动时先读项目规范
每次执行 bash 命令都记日志
动到危险命令时必须二次确认
Claude 停下来时提醒它继续查，别半途而废
遇到权限请求时别老来弹我，转去别的通知渠道

这些事情，本质上都不属于“每次手动发 prompt”的范畴。它更像是一个系统级规则。

Hooks 的价值就在这儿：

把你的临时口头提醒，升级成稳定的生命周期钩子。

这就好像你终于受够了每次新人入职都要重复说“提交前记得跑测试”，于是直接把 pre-commit、CI、质量门禁全配上。

世界瞬间安静。

对 Claude 也是一样。你一旦把这些共识写进 hooks，它的行为就会变得更工程化、更稳定，也更像你团队里的一员，而不是一个“随机发挥型选手”。

5. 前端开发一定要接浏览器：别让 Claude 盲写 UI

这个必须单独拎出来说。

如果你是前端，或者干过任何一点点偏 UI 的活，你一定懂这种痛：

Claude 写出来的页面，代码看着像那么回事，跑起来像事故现场。

原因非常简单——它没看见。

你让一个工程师闭着眼睛搭网站，然后要求他一次到位，这不是考验能力，这是在考验玄学。

所以 Boris 这条建议特别关键：

给 Claude 一个验证输出的办法。

比如接 Chrome 扩展，或者用桌面端那种能启动 web server 并测试页面的能力。这样 Claude 就不是“猜我写得对不对”，而是“看完效果再继续改”。

这中间差的不是一点点。

你会明显感受到的变化：

布局错误能被发现
样式跑偏能被修正
交互断掉能被迭代回来
移动端炸裂不再靠祈祷

说难听一点，不给 Claude 浏览器验证能力，就让它做前端，多少有点像让实习生蒙着眼做视觉验收。

不是它不努力，是条件确实太苛刻。

6. Worktree / 分叉会话 / 多 Agent 并行：别把所有活都塞一锅里炖

很多人一开始用 Claude，都喜欢把所有事扔进一条会话里解决。

前十分钟还挺开心，越聊越觉得“它懂我了”。两小时后再回头一看，整个上下文已经变成一锅工程乱炖：

这个 bug 说了一半
那个重构又插进来了
测试没补完
文档还没写
另一个方案也想试试
中间还顺手问了两个拼写问题

最后 Claude 看起来像没崩，实际上早就进入“我也不知道我们现在到底在干嘛”的精神状态了。

所以这时候你就需要：

分叉会话：保留主线，分出支线实验
worktree：多个改动在独立工作树里并行推进
subagent：不同代理各做各的活

这个思路其实很工程师：既然人类团队都不会让所有人挤在同一个分支上乱改，为什么要要求 Claude 这样做？

真正成熟的玩法，不是一个 Claude 包打天下，而是让多个 Claude 在清晰边界里各自负责一块。

你会得到两个明显好处：

第一，吞吐量上来了

一个修 bug、一个补测试、一个整理文档、一个改前端，大家互不耽误。

第二，事故率下来了

不容易改着改着把上下文搞乱，也不容易“为了修 A 顺手把 B 改炸”。

这对中大型项目尤其重要。

三、这些技巧到底能带来什么实际收益？

很多文章写到这里就开始上价值，什么“重塑开发范式”“定义下一代人机协同”之类。说实话，听多了脑子会自动防抖。

咱们就讲点朴素的。

这套玩法真正带来的收益，我觉得主要是 4 个：

1. 减少“重新进入状态”的成本

开发最贵的，不一定是写代码那几分钟，而是重新找回上下文。

跨设备接力、记忆、CLAUDE.md、远程控制，这些能力的共同目标，就是让你别老重开状态机。

你少解释一次项目背景，少重新翻一次文件，少再讲一遍“我们这套服务的依赖关系”，一天能省下来的注意力是很惊人的。

2. 把碎活从主线程剥离出去

review comment、文档收尾、日志排查、分支清理、变更同步、问题巡检…… 这些工作不是不重要，而是特别适合从你脑子的“主线程”里移出去。

Claude 一旦能自动跑，人的脑子终于能干更值钱的事。

3. 提高输出质量，不再靠运气

尤其是前端和复杂重构。

能验证结果、能跑测试、能看页面、能多轮迭代，这些都意味着 Claude 输出不是“一次性彩票”，而是更接近真正工程过程。

它不一定第一次就对，但它有机会自己修正。

这跟“写一坨代码然后祈祷它能跑”完全不是一回事。

4. 让 AI 更像队友，而不是更高级的搜索框

这是最关键的。

一个只能一问一答的 AI，再聪明，也更像搜索工具。但一个能记住上下文、跨设备接力、自动巡检、并行处理、还能验证结果的 Claude，才开始有点队友感。

而“队友感”，恰恰是 AI 工具真正会改变工作方式的那个临界点。

四、如果你现在就想上手，我建议按这个顺序来

别一上来就把所有高级功能配满。大概率你会在配置页里迷失自我，然后开始怀疑人生。

更务实的顺序是这样的：

第一步：先让 Claude 记住你的项目

把项目规则、常用命令、测试方式、代码规范写进 CLAUDE.md。先解决“它每次都像失忆”这个问题。

第二步：让它能验证结果

如果你做前端，给它接浏览器验证链。如果你做服务端，也至少让它能稳定跑测试、看日志、看结果。

第三步：学会会话分叉和 worktree

别把所有任务都堆一条线里。一旦任务复杂起来，你很快就会发现“隔离”有多重要。

第四步：挑一个重复动作做自动化

比如 review 收尾、文档同步、PR 清理。从一个最烦但最标准化的动作开始，配成 loop 或 schedule。

第五步：再上 hooks

等你真的开始依赖自动化了，再去补生命周期规则、权限策略、日志记录这些工程治理能力。

这个顺序的好处是： 每一步都能立刻感受到收益，不会学了一堆名词却落不了地。

五、最后说句大实话：AI 编程真正省下的，不是“写代码时间”，而是“工程摩擦”

我现在越来越觉得，Claude Code 真正厉害的地方，并不是“10 秒生成 300 行代码”。

因为老实讲，今天能生成代码的工具已经很多了。真正拉开差距的，是谁能更好地处理这些开发里的隐形摩擦：

上下文丢失
任务切换
碎活打断
结果无法验证
多任务并行互相踩踏
明明是重复动作却每天还在手工点点点

这些东西，才是程序员日常里真正耗神的部分。

而 Boris 分享的这套技巧，价值就在于它们不再盯着“怎么写出更多代码”，而是在回答另一个更成熟的问题：

怎么让 Claude 真的融入工程工作流，替你吃掉那些最烦的摩擦。

这事一旦做成，AI 才不只是一个“偶尔挺好用的工具”，而会慢慢变成你开发环境里那个默认存在的协作层。

到那时候，你再回头看今天这种“帮我写个函数”的用法，就会有一种感觉：

——也不是不能用。 ——只是，确实有点屈才。

六、给没时间细看的朋友，一个超短总结

如果你只想记住一句话，那就是：

Claude Code 最强的地方，不是帮你写代码，而是帮你把开发流程变得更连续、更自动、更可验证。

如果你只想先学 5 个最值的，我建议优先上：

项目记忆（CLAUDE.md / Memory）
跨设备接力（teleport / remote control）
结果验证（浏览器 / Chrome 扩展 / Desktop 测试）
自动巡检（/loop / /schedule）
并行隔离（worktree / branch / subagents）

学会这几个，你对 Claude Code 的理解会从：

“哦，它会写代码。”

升级成：

“行，这东西已经能开始参与我真正的工程流程了。”

而这两者之间，差的不是一点点。