Claude Code又被大漏勺，说是要更新网页自动截图，代码扫描，一次性设计多种风格，还能把好几个代码仓库合到一个界面里统一管理，这波Cursor都汗流浃背了。

我要抢在这些上线前，先把前段时间的更新都消化了。上周在线下黑客松跟人聊的时候就发现有的人已经把CC内置的命令玩出花来了，

分支对话/btw，双击esc回退被改坏的代码，还有新内置在CC里的交互课程/powerup随便用。

极与极，有的人还在一步步按确认。

你也可以试试看随机考朋友一个基础点的，知不知道Claude Code更新了Auto Mode（自动模式）。

上线三周了，还在用claude –dangerously-skip-permissions的朋友可以都切换成claude –permission-mode auto了，不至于闭着眼把权限全批了，执行到高风险动作还是提醒的。

还有个省token的小技巧，比起我们复制黏贴大段大段文字，直接给CC发文件目录让它用grep获取上下文会更省钱，等等等等。

所以我一口气整理了这段时间觉得最有用的十个命令和技巧，全分享出来。提示语们也整理到文档了，回复CC就好了。

Here we go！

01 /powerup

我们先从获得感比较高的命令开始，

这些命令不需要去装Skill，去做额外的配置，因为它们就是内置在原生的Claude Code里，随时可以用。

/powerup就相当于Claude Code版的多邻国，它一共分十关，每一关都会教你几个核心技巧，从怎么和代码库（项目）对话，怎么撤销操作，到怎么把任务放后台运行，怎么让CC记住你的偏好，甚至于怎么制作子Agent，怎么用手机远程控制等等。

说白了，就是Anthropic帮我们划好了重点。与其去看零散的教程，不妨先把这十关打通。

02 /btw

这个命令是我用的最高频的一个，

/btw，就是by the way（顺便说一句）的缩写。

想象一下，你正让Claude Code写一个复杂的项目，对话已经进行了几十轮，上下文窗口快到200k了。这时候，突然想确认一个细节，

比如，它现在写的这段，是不是按了我们上次定好的开发日志走的？

如果你选择直接在当前对话里问，这样会污染整个上下文，影响模型开发。那如果新开一个窗口，就会丢失了当前的上下文，模型一秒失忆。

/btw解决了这个问题，比方说我可以，/btw 刚刚提交的版本里面有加上readme吗？因为后面会做成公开项目

回答这个临时问题的同时，CC也不会暂停手里的主线任务。当我们确认完，按一下回车，这段临时的对话就会消失。而且/btw复用了当前的提示缓存，提问几乎不消耗token。

03 双击ESC

谁说AI界没有后悔药的，/rewind就是，不过我更习惯双击ESC，这样我们会看到一个菜单，可以选择只回退改坏的代码，还是连对话一起回退。

只回退代码的话，CC就会记得刚才的代码尝试是失败的，这样我们就不需要重新提一遍需求，完全可以直接说，

OK，我们来尝试下一个方向。

 04/05 Hook 和 /insight

这个顺序其实我纠结了一会，到底要不要把Hook（钩子）和 /insight 放一起。

/insight会生成一份过去一个月我使用Claude Code的习惯报告。这份HTML报告里会反映出你最常用的命令是什么，哪些操作模式是高度重复的。它还会推荐一些可以自定义的命令或者现成的Skill。

我就发现Claude Code有时候会修改太多文件，我还可以把常见的TypeScript工作流打包成新Skills。

如果说/insight是主动触发的话，那Hook就是被动触发的。我不需要去记隔个月运行一下/insight，Hook就是在我们有特定的明确的事件触发时，自动执行某个操作。

我常用的就有两个比较实用的Hook，

一个是当一次对话里工具调用次数大于 8 次时，就让CC输出优化建议，让它来教我把刚刚的一连串操作沉淀成Skill。

如果你想先适应适应这个Hook的话，可以让它先在项目（也就是当前的文件夹）里生效，后面再把它拓展成为全局。

我刚开始还有一个坏习惯，就是在对话开始时，扔给它一大段零散，未经思考的需求，说白了就是语音输入一大段文本。很多时候AI理解偏差，一来一回浪费了我时间。所以我做了另一个Hook，

如果我单次输入的文本超过200个token，就启动Plan模式。先引导我把这个长需求确认好，结构化，拆解成清晰的步骤，再开始动手开发。

也不用担心设置hook的时候表达不清晰，CC会进一步细化，给出优化建议。

Hook省了我大量的心力。

我不需要费脑子去想，这个操作是不是值得做一个Skill，也不担心一是不是开始的需求没想清楚，导致后面返工。

我们可以利用hook的这个特点，去做很多有意思的自动化。我就还有一个Hook，每次准备git提交开源的时候，都会触发一个动作，把所有commit信息写到一个可视化的网页上，等我预览确认没问题后，再真正提交。

这样就不担心因为模型抽风，把项目里的说明文件写得一团糟了。

06 /loop

这个命令很简单，就是让Claude Code定时重复执行某个任务。

比方我刚刚开源了一个新Skill，我一个人用可能没啥bug，但用的人多就容易出新问题。所以我用/loop来定时看看只要有人提bug，就自动修复并提交，用的话就是在任务前加一个loop和时间间隔就可以了，

/loop 24h 检查一下这个项目（github.com/LearnPrompt/ai-news-radar）有没有人提交Issue或是PR，有的话自动修复后更新项目

CC会每隔24小时检查一次状态。

loop的好处就是轻量，七天后这个任务就会自动过期并删除，不会一直占用本地资源。如果需要一个长期运行的任务，可以用schedule在云端运行的，只要不取消就一直会跑。

07 Ralph Wiggum插件

同样是循环，Ralph Wiggum（我们就简称为Ralph吧）就是一个有停止条件的单一任务循环。

如果我想要长时间运行同一个任务，但是这个任务又可能不是一次运行就能成功的，

Ralph就能在我睡觉期间用满我的模型额度，比方说重构一个项目的UI，我常用的就是给这个任务设置最多循环10-15次，然后让CC自己给自己出一个验收标准，

08 求助Codex

Opus 4.6最近降智有点严重，

所以我在Claude Code里用Codex的频率也升高了，OpenAI开源的这个codex-plugin-cc内置了/codex:review，用人话来说就是可以把现在的工作进度丢给Codex做代码审查。

 https://github.com/openai/codex-plugin-cc

而且当时一出来的时候，我就觉得，既然能够发给Codex做代码检查，那我为什么不能把它当作为一个在Claude Code里随时随地调用Codex完成其他任务的入口呢？

所以我直接原汤化原食，

让Codex自己在项目里面新增了一个叫Codex Ask的功能，这样我可以把开发任务全部给Claude Code做，到了写开发计划，或者是文本写作的时候，还可以用到 GPT 5.4 high。

PS：也可以不用改，把/codex:rescue当通用Agent用

这一步，我其实还做了一个让它们记忆共享的Skill，在后面的文章里面会开源出来。

09 –add-dir和-c

OK啊，当你把上面这几个命令都玩熟了，再配上几个从/insight里学到的Skill，

我可以保证，你已经比很多人用得溜了。

但我们还可以再讲究点。接下来的这几个参数，不是命令，是在我们开启一段新对话时，就能用上的开场白，就像游戏开局时，你可以选择的几个被动技能，选对了会省很多时间。

-c就是continue，

如果不小心把终端关了，或者电脑没电，总之就是各种各样的意外，导致你这次的对话突然中断的话，我们都可以加-c恢复。最近一次的对话记录，像游戏读档一样。

接下来，也是我开头提到的，省token小妙招，这个参数叫–add-dir。

比方说，我们在A文件夹里写代码做知识管理，但同时，我又需要参考我电脑另一个角落里，Obsidian文件夹里的一些个人笔记和设计规范。

那我只要在启动的时候，用–add-dir参数把Obsidian的路径加进来。这样CC就能直接读取那个文件夹里的所有内容，我不需要再复制粘贴任何文本，它就能理解我的所有黑话和个人习惯。

10 Sub-agent 与 Agent Teams 

前面九个技巧，都是在让你用主Agent的时候变得更强。第十个，也是最后一个技巧，我就要拿出多Agent了。

可能很多人一听到这个词就头大，会觉得要新设置很多东西，会影响主Agent的表现之类的。实际上Claude Code已经把入门的门槛降得很低了。

我们先说简单的，Sub-agent（子智能体）。

你可以把它理解成一个临时工。有些任务，比如去网上搜资料，或者去翻几十个日志文件，直接在当前对话里提问的话会产生大量没用的中间过程，把主对话上下文搞得乱七八糟。

这时候就可以派subagent去干。它会在自己的工作空间里，默默地完成这些脏活累活，最后把一个干净整洁的摘要报告，交回到你的主对话里。

我们只需要先用/agents命令，就可以用大白话，创建一个自己的子代理，比方说，

创建一个灵感Agent，它会扫描当前开发项目，使用superbrainstrom skill和office hour skill，给出新角度建议。

创建的过程很简单，CC会问你要用什么样的模型去驱动，然后它是一个只读Agent，还是执行Agent，是把所有的Tools都开放给它用，还是只开放一部分。

BTW，superbrainstrom和 YC总裁开源的office hour都是两个跟头脑风暴相关的Skill，非常互补，都是我比较推荐的Skills。

 github.com/obra/superpowers/tree/main

 github.com/garrytan/gstack/tree/main

Agent Teams把分工玩法带到了一个新高度。

不再是主Agent和临时工的关系，是一个真正的多Agent团队。我们可以一次性创建多个不同角色的Agent，让它们并行地，从不同角度去解决一个复杂问题。我有一个新产品的想法，就可以这样说，

我正在设计一个 CLI 工具，帮助开发者追踪整个代码库里的TODO。组建一个 Agent 团队，从不同角度来探索这个方向：一个成员负责用户体验，一个成员负责技术架构，另一个成员专门负责挑刺。

然后，我就啥都不用干，围观一场头脑风暴。这三个Agent会开始互相讨论，分享发现，甚至会给对方的观点挑毛病。

我们还可以像项目经理一样去管理这个团队，比如提前结束某个队友的对话，二次分配新的任务，或者让它们先出方案，等你批准了再执行。

这种多 Agent 协作会比单 Agent 更适合复杂任务，因为它能降低模型一条路走到黑的概率，也能在早期就发现问题。

好了，十个技巧，全部分享完了。

我知道，这时候肯定会有朋友觉得记这些太麻烦了，不如直接去GitHub上，把Everything Claude Code那个超级大合集项目，一把梭哈，156个Skill，48个Agent，72个Command全装上。

真的真的真的千万别这么干。

全装，意味着你的Claude Code会突然多了几百个你根本不了解的文件。可能连hook的用法都还没摸熟，就直接复用了别人的工作流。结果发现，别人用的我们平时根本用不上。

其实就是给模型增加了记忆负担。

我的建议是，

如果你是刚开始用Claude Code，那什么都别装。先用，用上了就会有痛点。痛点就是你最需要配置的第一条规则，第一个Skill。

如果你已经有了自己的工作流，想参考一下别人的配置。那就从那些大合集里，选适合你的。比如，通用的规则，会话保存的模板，最常用的Skill，就够了。

毕竟在AI加持之下，产品的进化速度太快太快了。

我现在已经用Codex设置了一个长期定时任务帮我每天去监控Claude Code的更新日志了，

这些就等我之后玩熟了再来继续分享。

睡了睡了（其实是熬穿了），

希望起来Claude没有更新。

3月1日那天，我跟 Claude Code 发了 9,259 条消息，一天，从早到晚。那天是阿布（Abu）的首个版本发布。

从那天起的 6 周时间里，我用 Claude Code 写了一款叫阿布的 AI 桌面应用。到今天为止，8.5 万行代码、386 个文件、222 次 commit、1,362 个测试。

作为一个不懂技术、不会编程的产品经理，我写代码的方式是描述需求，让 Claude 帮我写。这 6 周里我跟 Claude Code 总共交互了 62,376 条消息、45,004 次工具调用，花了大约 1 万块钱（订阅 5,740 + API 5,000+）。

如果你也「想用 AI 写自己的工具但不知道从哪开始」，或者「看到别人发产品很心动但觉得自己不行」，我想把我这 6 周经历的完整链路拆开给你看。一个真实案例、一套可复用工作流、一些避坑经验。

6 周以前我也是从”我不会编程”开始的。

这篇文章会讲这些事：

1. 我做了一款什么产品：阿布能干什么、使用场景、当前规模

2. 我的工作流：从需求到代码到上线，5 步循环怎么跑

3. 用好 Claude Code：CLAUDE.md、/plan、/insight、/simplify 等我每天在用的功能

4. 工作示范：从 0 加一个”让阿布操作浏览器”的功能，完整演一遍

5. 怎么做 UI：怎么让 AI 写出审美在线的界面

6. 怎么可持续构建：分支纪律、版本管理、提交检查，附真实事故

7. 怎么写测试：1,362 个测试是怎么长出来的，附注册表实践

8. 怎么评估：自建 eval 框架的思路、23 个评测 case、跨模型对比

9. 几件让我重新理解 AI Coding 的事：4 个真实故事

10. 能做到什么程度：边界、成本、给小白的 6 条建议

跟着这篇实战记录走一遍，你也能用 Claude Code 从 0 做出自己的产品。文末我也放上了阿布源码以及设计文档，你可以从中学习。

1. 我做了一款什么产品

我做的东西叫阿布（Abu），一个 AI 桌面应用，你用自然语言告诉它要做什么，它在你的电脑上替你做。

阿布具备性格自定义、长期记忆、自进化能力，可写文档、做报表、操控电脑和浏览器，支持多Agent（智能体）并行和定时任务运行，所有数据本地运行。

常见的使用场景：

• 操作本地文件。发票整理，读取开票时间和金额，批量重命名并汇总统计。Excel 数据分析，不用写公式，自然语言描述需求直接输出新表。跨文件信息提取，从多份合同里摘出付款条款，整理成对比表格。
• 网页数据抓取。让阿布替你看网页、提取信息、填表单。它直接操作你已经登录的浏览器，不需要重新登录任何系统，不需要你懂爬虫。
• 7×24 小时自动化。接入飞书、钉钉、Slack 机器人，有人在群里 @阿布 它就自动处理。支持定时任务，比如每月第一个工作日自动跑一份数据汇总。
• 自进化。阿布不是一个用完就忘的工具，它会根据聊天内容自动 Review 并沉淀为记忆，还能根据对话上下文自动创建定时任务和 Skills 技能卡片。你教它一次“每月第一个工作日帮我跑数据汇总”，它自己会把这件事变成一个定时任务 + 一张技能卡片，下次不用你再说。用得越多，它越懂你。

说完场景，说说阿布在技术上做到了什么程度。这些听起来像是一个工程团队干的事，但确实是我一个 PM 用 Claude Code 搭出来的：

• 双协议 LLM 适配：同时支持 Anthropic（Claude）和 OpenAI 协议，一套代码接两套 API，retry、成本统计、错误分类全部统一
• OS 级沙箱：macOS 用 Seatbelt（苹果自家的进程隔离）、Windows 用 ConstrainedLanguage，不是在应用层“假装”安全，是操作系统层面真的把危险操作拦住
• Computer Use + 5层安全防御：AI 能看屏幕、点鼠标、敲键盘。但有敏感 app 黑名单、危险按键拦截、全局停止快捷键、会话超时、双中止通道，5 层独立兜底
• MCP 协议：对接外部工具服务器的标准协议，支持 stdio 和 HTTP 两种传输。阿布的浏览器操控就是通过 MCP 接入的
• 多 Agent 编排：主 Agent 可以把大任务拆给多个子 Agent（Subagents）并行执行，每个子 Agent 独立上下文，完成后汇总
• Skills 技能系统：把重复性 SOP 沉淀成 Markdown 格式的技能卡片，AI 自动识别何时激活
• 4 种触发器引擎：HTTP webhook、Cron 定时、文件变更、IM 消息，四种方式触发 Agent 执行
• IM 多平台集成：飞书（WebSocket 长连接）、钉钉（event callback）、Slack（socket mode），一套抽象层适配三个平台
• 文件化记忆系统：Agent 的长期记忆不是塞进一个大文件，而是文件化目录结构，自动迁移、跨设备同步
• 自建 Eval 框架：23 个评测 case，跨 provider 对比工具选择准确率，结构化报告可追踪趋势
• 1，362 个自动化测试：76 个测试文件，8 秒跑完，覆盖工具安全、消息归一化、数据迁移、IM 去重等

几个数字：

• 开发周期：6 周（3 月 2 日 → 4 月 12 日）
• 代码规模：386 个源文件，约 8.5 万行（7 万行 TypeScript + 4，000 行 Rust + 1.5 万行测试）
• Claude Code 交互量：62，376 条消息，45，004 次工具调用
• 总花费：约 1 万元（订阅 5，740 + API 5，000+）
• 峰值日：3 月 1 日，单日 9，259 条消息

看到这你可能会想，这些东西我也能做到？能。这些功能不是我一次性设计出来的，是一周一周长出来的。每一个听起来很”工程”的东西，背后都是一个具体的产品需求 + 一段跟 Claude 的对话。后面我会一步步拆给你看怎么做到。

2. 我用 Claude Code 写代码的工作流

这一节是核心干货。我把”我每天怎么做”拆开给你看，你看完可以直接照着来。

2.1 一个功能从想到做完，我做的几件事

5 步循环：想清楚 → 写一段需求描述 → 让 Claude 写 → 我 review → 跑测试 + 真机验证。

听起来简单，但重点在比例。我花在“想”上的时间，比花在“写”上多得多。Claude 写一个功能可能 10 分钟，但我想清楚”这个功能到底要解决什么问题、用户使用链路是什么”可能要一个晚上。这个比例跟传统开发完全反过来了。

2.2 多窗口并行：一个人同时推多个模块

这是我用 Claude Code 之后发现的最大提效点。

传统开发一个人一次只能写一个模块，你在写 A 的时候，B、C 只能排队。，但 Claude Code 不一样。你可以同时开多个终端窗口，每个窗口跑一个独立的 Claude Code session，并行开发不同模块。

我经常的状态是：左边窗口让 Claude 写 IM 适配层，右边窗口让它写工具安全规则，中间窗口在跑测试。三条线同时推进，我在它们之间切换做 review。等 A 窗口的代码写完我还没 review 完，B 窗口已经出了初稿。

这种工作方式有几个要注意的：

• 模块之间要解耦。两个窗口同时改同一个文件会冲突。所以并行开发的前提是你把功能拆成了不会互相踩脚的模块
• CLAUDE.md 是共享的。所有窗口都会读同一份 CLAUDE.md，所以你的规范和纪律会被统一遵守
• 最后统一跑一遍测试。并行写完之后，关掉多余窗口，在主窗口跑一遍全量测试确认没有互相影响

说实话这种体验很接近”我是一个技术负责人，手下有三个工程师同时在干活”。只不过三个工程师都是 Claude，不需要开会对齐。

2.3 不止让 AI 想技术，要让它先想产品方案和用户链路

这是我做阿布最深的一个体会。

很多人用 Claude Code 的方式是：”帮我加一个 XX 功能”。Claude 马上开始写代码。可能写得还挺对，但做出来之后你会发现”好像不是我想要的”。

问题不在 Claude，在你。你跳过了”想清楚用户场景”这一步。

我的做法是：每次加新功能，第一段对话完全不提技术。我会先聊：

• 用户什么时候会用到这个功能？
• 用户做这件事之前在哪、做完之后到哪？
• 用户怎么知道“做对了”？
• 有什么边界是不能碰的？

想清楚这些之后，技术方案自然就会浮出来。如果跳过这一步，Claude 会默认用”技术上最合理”的方案，但技术上最合理的方案往往不是产品上最合理的。

后面工作示范那节我会用一个真实案例详细演给你看。

2.3 怎么向 Claude 描述需求

我用一个简单的公式：

作为 [角色]，我想要 [功能]，以便 [价值]。

比如：”作为一个要整理发票的运营，我想要一个能批量读取发票图片并按日期重命名的功能，以便我每月不用手动处理 30 张发票。”

这不是什么高级技巧，就是 User Story 的标准格式。但你会发现，你把这段话写清楚的过程本身就在帮你想清楚。写不出来的地方就是你还没想清楚的地方。

反例：如果你只说”帮我做一个发票功能”，Claude 可能做出一个全自动的发票识别系统 —— 又大又复杂又不是你要的。

2.4 怎么做迭代：不是”重写”，是”理解了再改”

阿布不是一次性写完的，每个功能都经过好几轮迭代。我觉得迭代过程要使用文档记录问题、预期功能，我会在Claude开发间隙，自己去写文档记录。

但我踩过一个大坑：直接说”帮我重构 XX 模块”，Claude 不知道之前的代码为什么这么写，上来就改，结果把之前踩过的坑又重新踩了一遍。

现在我的习惯是，每次大改之前，先让 Claude 写一段“迭代分析”：

• 第一步：「先读一下这个文件，告诉我它现在的设计是什么、为什么这么做」
• 第二步：「如果我要加 XX 功能 / 改 XX 行为，有哪些方案？每个方案的利弊和风险是什么？」
• 第三步：我看完它的分析，觉得它理解对了，才让它开始写

这个多出来的 5 分钟回报非常大。Claude 理解了上下文之后，生成的代码质量高很多，而且不会把之前的修复”无意识地撤销”。

2.5 我怎么 review 它写的代码

说实话，我看不看得懂语法？大致能看懂，但这不是重点。

我 review 的时候真正在看的是 4 件事：

• 逻辑对不对：不是语法层面，是“这段逻辑跟我想的需求一致吗”。Claude 经常写出来的代码“能跑”但“不是我要的”
• 边界条件有没有想到：比如“如果用户传了空字符串会怎样”。这是 AI 最容易漏的
• 跟其他模块的耦合影响：Claude 看不到全局，它不知道改了这个文件会不会影响另一边。我会问它：“这段改动会影响哪些模块？有没有 breaking change？”
• 安全和用户体验：哪些路径不能碰、哪些操作需要用户确认、交互细节是不是顺畅

关键实践：我几乎不会一次就通过。一个方案或一段代码，我通常会 review 2-3 轮。第一轮看大方向对不对，第二轮看边界和耦合，第三轮看细节。每一轮我都会把问题直接丢回去让 Claude 解释或修改：

• 「这段逻辑在 XX 情况下会怎样？」
• 「这个改动会影响 XX 模块吗？影响的话怎么处理？」
• 「这个方案的风险是什么？有没有更稳的做法？」

不要怕多问几轮。Claude 不会不耐烦，而且每多问一轮，它给出来的方案就更完善。很多 bug 不是写出来的，是 review 没抓住的。多轮 review 的成本远低于事后修 bug。

反过来，Claude 比我强的地方：算法选型、性能优化、跨平台兼容这些事我都听它的。术业有专攻。

这倒是让我重新理解了产品经理的价值 ——在 AI 能写所有代码的时代，PM 真正的工作不是不写代码，而是知道什么时候不能让 AI 自由发挥。

2.6 出了 bug 我怎么跟它聊

三条原则：

第一，把报错原文贴回去，不要描述。不要说”有个地方报错了”，直接把终端里的 error trace 粘过去。Claude 能从报错信息里定位问题比你用文字描述精准得多。

第二，让它先解释根因再修。不要一上来就说”修一下”。先让它分析 bug 是怎么产生的，确认分析对了再动手。否则它可能只是在”糊”一个补丁，根因没解决。

第三，修完之后让它顺便写一条测试。提示词：「这个 bug 你刚才修了，请写一个最小的测试用例覆盖它」。这件事几秒钟，但 6 个月之后当 Claude 又要”优化”这段代码时，那条测试会拦下它。

3. 用好 Claude Code 的几个功能

Claude Code 不只是一个”帮你写代码的聊天框”。它有一些功能如果你不知道就会错过，知道了效率会翻倍。

3.1 CLAUDE.md：你和 Claude 之间的合同

这是我觉得 Claude Code 最值钱的功能。

在项目根目录放一个叫 CLAUDE.md 的文件，每次 Claude 开始工作都会先读它。你在里面写什么，Claude 就会遵守什么。

我的 CLAUDE.md 现在有 273 行，里面写了这些事：

• 技术约束：用什么框架、什么语法不许用（比如不许用 enum，要用联合类型）
• 命名规范：变量用英文、UI 文字用中文、commit message 中英双语
• 踩过的坑：比如「必须用 npm run tauri：dev（冒号），空格版会污染正式数据」。这条是我被坑过一次之后加上去的
• 分支纪律：禁止在 main 上直接开发，所有工作在 dev 分支

核心心法：每次踩坑就更新一条。你的 CLAUDE.md 会越长越厚，Claude 的表现会越来越好，因为它每次都在读你所有的”教训”。

3.2 /plan：先想清楚再让它写

输入/plan，Claude 进入”只规划不动手”模式。它会列出方案、分析利弊，但不会写一行代码。

我的工作流：复杂功能先/plan出方案 → 我审 → 同意之后再让它写。这样避免”它写了 500 行代码然后你说不是我要的”的尴尬。

3.3 /insight：每月让 AI 看看你怎么用它

这是一个分析你过去 30 天使用 Claude Code 数据的功能，它会生成一份报告，告诉你”你的工作模式是什么、摩擦点在哪、CLAUDE.md 应该加什么规则”。

我自己每个月跑一次 /insight，然后把它给的建议直接应用到 CLAUDE.md 里。相当于让 Claude 帮你回顾”你跟它的协作效率哪里可以提高”。

3.4 /simplify：让 AI 自己 review 自己

每次写完一个大功能之后，我会跑一遍/simplify。它会扫描你改过的代码，找复用机会、质量问题、效率优化点，然后自动修。

你可以理解为”让 Claude 做自己的代码审查”。它写代码时是在往前赶，/simplify 时是在回头看。这两步节奏配合起来，代码质量比”只管写不管审”好很多。

3.5 /btw：不打断工作流的随手提问

有时候你在写一个功能写到一半，突然想问 Claude 一个不相关的问题，比如”这个 API 的参数是什么意思”。直接问的话会打断当前的开发上下文。

/btw解决这个问题。它开一个”旁白通道”，你随便聊什么都不影响当前的代码开发。聊完了回到主线继续写。像是在结对编程的时候侧过头问搭档一句话。

3.6 /resume：第二天接着写

Claude Code 的上下文在你关闭之后就没了。但如果你昨天写到一半，今天想接着来，输入/resume就能恢复上一次会话的上下文。

跨设备、跨时间段的开发，这个命令非常救命。

4. 工作示范：从 0 加一个”让阿布操作浏览器”的功能

上面讲了方法论，这节用一个真实案例演一遍。

4.1 起心动念

某天我想让阿布”帮我整理需求管理系统里的待评审需求清单”。阿布当时只能读本地文件，没法看网页。 我心里想，能不能让 AI 也操控浏览器去获取数据？

4.2 先想产品方案，不想技术

按照前面说的，我跟 Claude 的第一段对话完全没提技术。聊的全是用户场景：

• 用户什么时候需要让 AI 操作浏览器？填表、数据抓取、操作内部系统后台
• 用户希望 AI 看到的是什么？用户已经登录的页面，不是干净浏览器
• 用户怎么知道 AI 做对了？要看见过程
• 用户的隐私边界在哪？哪些 Cookie 不能碰

想清楚这些之后，一个核心设计决策自然浮出来—— 必须接入用户已有的浏览器，复用用户的登录态。不能启动一个新的浏览器实例。

这一步如果跳过，Claude 默认会推给我 Playwright 方案：启动一个干净的 Chrome、用户得重新登录，跟 Computer Use 没本质区别。产品方案不对的时候，技术写得再漂亮也是白做。

4.3 让 Claude 帮我拆解方案

想清楚用户场景之后，我跟 Claude 说的大概是这个意思：「我想让阿布能操作用户正在用的浏览器，不是打开一个新的，而是直接操作用户已经登录的那个。你帮我想想这件事要拆成哪几块来做。」

Claude 给了我一个方案，拆成了三件事。我看了一下觉得合理：

第一件：做一个 Chrome 浏览器插件。装在用户的 Chrome 里，它能看到用户打开的所有网页，能帮阿布点按钮、填表单、提取页面上的文字。你可以理解为伸进浏览器的一只”手”。

第二件：做一个中间桥接程序。这个程序负责在阿布和浏览器插件之间传话。阿布说”帮我点一下那个按钮”，桥接程序翻译成浏览器插件能听懂的指令，然后把结果传回来。Claude 用的是 MCP 协议（一种让 AI 调用外部工具的标准协议），一共封装了 17 个操作：截图、点击、填写、提取表格等等。

第三件：写一份 Skill 说明书。这份”说明书”是给阿布自己看的，告诉它”什么时候应该用浏览器工具、17 个操作各是干什么的、用错了怎么办”。没有这份说明书，阿布虽然有了工具但不知道什么时候该用。

这三件事 Claude 帮我拆的。我做的事情是：看它拆得对不对、有没有漏、用户视角通不通。比如我追问了一个问题：「用户装这个插件复不复杂？能不能做到一键装好？」这种问题 Claude 自己不会主动想到。

4.4 跟 Claude 怎么聊这个需求

拆完方案之后，我分三轮跟 Claude 聊，每轮解决一件事。

第一轮，我大概这么说的：「我要做一个 Chrome 浏览器插件，用户装上之后，阿布能通过它看到用户打开的网页、帮用户点按钮和填表单。先帮我把这个插件写出来。」

Claude 写完之后会生成一份”通信格式”的定义（就是插件和外部程序之间怎么传消息的约定）。

第二轮，我把这份定义贴给 Claude，说：「现在帮我写桥接程序。它要能跟刚才那个插件对接，把阿布的指令翻译成插件能执行的操作。对接的格式就按刚才那份来。」

第三轮，我说：「现在帮我写一份 Skill 说明书，教阿布什么时候用浏览器工具、什么时候不该用、每个操作是干什么的。」

关键技巧就一个：先让 Claude 定好“两边怎么对话”的规则，再分别写两边的代码。这样写出来的东西自然能对上，不会出现”插件发的消息桥接程序听不懂”的情况。

4.5 写出来后我怎么验证

真机测试：

1. 把 Chrome 插件手动装到浏览器里
2. 启动桥接程序
3. 让阿布“打开一个网页、提取标题”
4. 看是不是真的能跑通

第一次跑就遇到两个坑：一个是插件和桥接程序之间的身份验证没对上（连不上），另一个是某些网页内容是动态加载的，插件去找的时候页面还没渲染完。都是”我本地测通了、换个网页就翻车”的经典场景。

修复之后我做了跟每次一样的事，让 Claude 给这两个坑各写了一条测试。

做这个功能让我意识到一件事。做“让 AI 操作工具”类产品，最难的不是让工具能跑，而是让 AI 知道什么时候该用。所以那份 Skill 说明书比代码本身更重要。一个看起来是”技术功能”的需求，从想到做完，技术只占 30%，70% 是想清楚用户场景和工具边界。

5. 怎么让 AI 写出审美在线的 UI

这是小白最容易踩的坑之一。你让 Claude 写 UI，它默认给你的是灰色背景、蓝色按钮、Bootstrap 既视感。不是 Claude 不会写好看的，是你没告诉它”什么叫好看”。

5.1 怎么给 AI 描述”审美”

三种方式：

贴截图。找一个你喜欢的产品（Linear、Vercel、Notion），截一张图发给 Claude，说”这个风格”。它能从截图里识别出颜色、间距、圆角、字体的感觉。

定 design token。颜色、间距、圆角、字体先约定好，写进 CLAUDE.md。阿布的 design token 是：主色用克莱因蓝系、背景用柔白、文字用温暖灰、圆角 8/12/16 三档。每次 Claude 写新组件都自动套用。

指定参考库。”用 shadcn 的组件风格”、”间距参照 Apple HIG”。一句话就能框定审美范围。

关键：不要说“做漂亮一点”。这句话对 AI 来说没有任何信息量。你要给具体参照。

5.2 约定一旦定下来，AI 会自己保持一致

这是一个”复利效应”。你在 CLAUDE.md 里定好 design token 之后，后面每加一个组件、每做一个页面，Claude 都会自动套用同一套视觉语言。你不用每次都重复说”用那个蓝色”。

几轮迭代之后，它甚至能理解你的审美偏好。比如我偏好暗色主题、毛玻璃质感、细边框，它后来自己做出来的东西就已经很接近我想要的了。

AI 不会变美，是你要教它什么叫美—— 但你只需要教一次。

6. 怎么可持续构建

很多人用 AI 写代码的方式是”一口气写完、扔上去就跑”。这在做 demo 的时候没问题，但如果你想做一个能持续迭代的产品，从第一天就需要一套框架。

我在做阿布的过程中摸索出来的框架大概是这样的，5 条纪律，覆盖从”每天开始写代码”到”发版给用户”的全链路：

纪律 1：分支隔离。dev 分支写代码，main 分支给用户。绝不在 main 上直接开发。

纪律 2：版本号同步。发版时所有版本号一起改，不能漏。

纪律 3：提交前检查。build 能过、lint 没报错、测试全绿，才允许 commit。

纪律 4：commit 纪律。每个有意义的变更单独 commit，格式 conventional commits，中英双语。

纪律 5：发版清单。版本号 → merge 到 main → 打 tag → push → 写 changelog。

听起来像是”正确的废话”，但每一条都是事故教出来的。下面讲几个我真实踩过的坑。

6.1 一个关于 main 分支的事故

某次发完版之后，我忘了切回 dev 分支，直接在 main 上继续写代码了。等我发现的时候已经在 main 上提交了好几个 commit，跟 dev 的代码产生了冲突。

那一次手动解决合并冲突花了不少时间。修完之后我做了一件事，把这条规则写进了 CLAUDE.md：

禁止直接在 main 上开发或 push commit。所有工作在 dev 分支进行。

每次开始工作前必做：

1.git branch –show-current —— 确认当前分支

2.如果在 main，先 git checkout dev

3.git pull origin dev —— 拉取最新代码

从那以后 Claude 每次开始工作都会先检查当前分支。CLAUDE.md 不只是约束你自己，也是约束 AI 的。

6.2 三处版本号没同步，发版翻车

阿布有三个地方存版本号：package.json（前端）、src-tauri/tauri.conf.json（Tauri 配置）、src-tauri/Cargo.toml（Rust 构建）。发版时三处必须同时改。

有一次我只改了 package.json 的版本号，忘了改另外两处。结果构建出来的安装包版本号对不上，自动更新检测失效，用户那边怎么都收不到新版本。

修完之后这条也进了 CLAUDE.md：

三处版本号必须同步更新：package.json、src-tauri/tauri.conf.json、src-tauri/Cargo.toml。

然后发版流程也被固化成了一个清单：

1.确保 dev 分支 build + lint + test 全绿

2.三处版本号同步更新

3.git checkout main && git merge dev

4.git tag vX.Y.Z

5.git push origin main –tags

6.在 GitHub 创建 Release

每次发版我让 Claude 按这个清单走，它比我自己记得牢。

6.3 提交前检查：build + lint + test 三连

这也是被坑出来的。有一次我改了一段代码，什么都没检查就提交了，结果代码有语法问题，整个应用构建失败。

现在的规则是，每次提交代码之前必须跑三样检查：

第一，编译检查（build）。让程序试着把你的代码”翻译”成计算机能跑的版本。如果代码里有语法错误、类型写错了，这一步就会报错。相当于”你写的东西能不能被机器读懂”。

第二，规范检查（lint）。自动扫描你的代码有没有违反预设的编码规范，比如变量命名不统一、有未使用的代码、格式不对。相当于”你写的东西符不符合团队约定”。

第三，测试检查（test）。跑一遍全部 1,362 个测试，看有没有哪个功能被你这次改动”误伤”了。相当于”你改完之后，原来能用的东西还能不能用”。

三样加起来不到 20 秒。20 秒换一个”不会把有问题的代码推上去”的保证，我觉得这是做产品最便宜的保险。

6.4 commit 节奏和双语 message

每个有意义的变更单独 commit，不要积累一大堆一次性提交。格式用 conventional commits：feat:新功能 /fix:修 bug /refactor:重构 /docs:文档 /test:测试。

我还有一个习惯，commit message 写中英双语。英文在上面给社区开发者看，中文在下面给我自己 6 周之后看。举个真实例子：

feat(computer-use): sensitive app blocking + dangerous key interception

每个操作前检查前台 app 和按键组合安全性。敏感 app 用 bundle_id 匹配（跨语言）。

你可能觉得”我又不开源”，但我跟你说，git log 是你未来最好的回忆。你 3 个月后想知道”我当时为什么改了这段代码”，就靠 commit message。

Claude 不会自动管这些纪律，你得替它想。但好消息是，你只需要把规则写进 CLAUDE.md 一次，之后每次它开始工作都会自动遵守。这套框架本质上就是你和 AI 之间的流程合同。

7. 怎么写测试

我原来根本不写测试。「测试是个文件、跟代码放一起」这种事是做阿布之后才知道的。现在阿布有 76 个测试文件、1,362 个用例，跑全量 8 秒。下面讲我的实践 —— 不是”正确的做法”，是”我被坑出来的做法”。

7.1 为什么写：Claude 会反复修同一个 bug

这是我开始写测试的直接原因。Claude 在改一段相关代码的时候，会把之前的修复”无意识地”撤销，因为它没有那次修复的记忆。一条测试就是用来对抗这种遗忘的：下次它想”简化”这段代码，测试会立刻变红。

7.2 怎么让 AI 帮你写

我的做法极简：每修一个 bug，让 Claude 顺便写一条最小测试。提示词就一句：「这个 bug 你刚才修了，请写一个最小的测试用例覆盖它」。几秒钟的事。

测试文件和源码放同一个目录，chatStore.ts旁边就是chatStore.test.ts。约定一旦定下来，Claude 自己会保持一致。

7.3 真实实践：版本注册表

举一个我觉得最有价值的测试实践。

先说背景：阿布会把用户的设置、对话历史、定时任务等 10 类数据存在用户的电脑本地。问题是，我经常会让 Claude 改这些数据的格式（比如加一个新字段、改一个字段名）。每次改格式，都必须同时做一件事：写一段”把老格式自动转成新格式”的代码（叫 migrate），否则老用户打开 Abu 就会因为格式对不上而崩溃。

我被这件事坑过一次之后（参见前面”搞炸用户数据”那个故事），做了一个机制：把所有会被存到本地的数据模块，登记在一张清单里。

这张清单大概长这样：设置（已改 16 次）、对话（已改 4 次）、定时任务（已改 3 次）、触发器（已改 4 次）…

清单有什么用？它跑两个自动检查：

第一个检查：版本号对不对。每次改格式都要把版本号 +1。如果有人改了格式但忘了 +1，检查会报错。

第二个检查：有没有漏登记的。自动扫描所有存在本地的数据，只要发现有数据不在清单里（说明有人加了新数据但忘了登记），立刻报错。

第二个检查是真正救命的。它意味着，只要 Claude 悄悄加了一个新的会被存到本地的数据类型，但忘了登记和写 migrate，提交代码的时候就会被自动拦下来。

“设置”这类数据在短短 6 周里改了 16 次格式。如果没有这张清单，这 16 次里有任何一次忘了写格式转换，都会让一批用户的本地数据炸掉。

这个做法的核心启发是：最好的测试不是测“功能对不对”，而是测“我有没有忘了某件事”。

7.4 测试分布：76 个文件都在守护什么

按模块分：工具系统 10 个文件、IM 集成 8 个、LLM 适配 7 个、Agent 引擎 7 个、上下文管理 5 个、数据持久化 10 个、跨模块集成 4 个。

其中用例最多的几个：工作流提取器 80 个 case（消息流解析规则多到吓人）、路径安全 42 个（每条对应一个目录穿越/敏感路径场景）、消息归一化 30+ 个（覆盖各种”模型可能返回的奇怪消息形态”）。

每一个数字的背后都有一个真实的事故。我不会为了”覆盖率”去写测试，只会在被坑了之后写。

7.5 跑得越快越好

阿布 1,362 个测试跑全量 8 秒。这个数字很关键，如果跑一次要 5 分钟，我大概率就懒得跑。8 秒意味着我每次提交前都会跑一遍，提交前检查不会变成负担。

6 周，从 0 到 1,362 个测试。不是因为我爱写测试，是因为不写真的会翻车。测试是我跟 Claude 之间的合同 —— 你想改什么都可以，但这些东西不能动。

8. 怎么评估

AI 产品有一件事跟传统软件不一样：你不知道它今天是不是变笨了。

你换了模型、改了 prompt、加了新工具，怎么知道效果是变好还是变差？传统软件测试是”输入 A 期望输出 B”，AI 产品是”输入 A 期望模型做出大致正确的判断”，这种事没法精确断言。

我做了一件当时觉得”是不是太工程了”的事，自己搭了一个评估器。做完之后发现这可能是阿布里最值钱的一部分基础设施。

8.1 构建思路：从”我想知道什么”倒推

搭 eval 的第一步不是写代码，而是想清楚”我到底想知道什么”。

我最担心的问题是：阿布有 26 个内置工具，用户说一句话，模型选对工具了吗？比如用户说”帮我看看桌面的文件列表”，模型应该选list_directory还是run_command？用户说”把这段文字写进 note.txt”，模型应该选write_file还是edit_file？

这个”选工具”的准确率直接决定产品体验。选错了，用户等半天发现阿布做了一件完全不相关的事。

想清楚要评估什么之后，设计就自然了：

输入：一句用户消息（比如”帮我看看 ~/Documents/report.md 的内容”）模型行为：模型决定该调哪个工具、传什么参数判断标准：必须调的工具调了没有？禁止调的工具有没有误调？参数传对了没有？

这三条判断标准就是 eval 的核心，不需要真的执行工具，只看模型”选了什么”，不看”做得怎么样”。

8.2 我的真实实践：23 个评测 case

我给阿布写了 23 个评测 case，分成 8 个类别：

文件操作（4 个）/ 搜索（8 个）/ 命令执行（4 个）/ 多步任务（2 个）/ 记忆（2 个）/ 网页（1 个）/ 知识（1 个）/ 代理委派（1 个）

每个 case 长这样（用大白话讲）：

Case：file-read-01用户说：「帮我看看 ~/Documents/report.md 的内容」 期望：模型必须调用read_file工具 难度：easy

Case：file-edit-01用户说：「把 src/config.ts 里的 API_URL 从 localhost 改成 production.api.com」 期望：模型必须先调read_file（先看看文件内容），不能直接调write_file（不然会覆盖整个文件） 难度：medium

你看，定义这些 case 不需要懂代码，需要的是“想清楚什么情况下算对”。这是 PM 的强项。

按难度分：13 个 easy、8 个 medium、2 个 hard。先把简单的覆盖全，再逐渐加难的。跟做产品一样的优先级思路。

8.3 跨 provider 对比：同一组 case 跑在不同模型上

eval 最有价值的用法是：同一组 23 个 case，分别跑在 Claude、OpenAI、国产模型（比如 MiniMax）上，对比通过率。

跑的方式很简单，一行命令：

tsx src/eval/run.ts tool-selection –provider anthropic –model claude-sonnet-4-20250514

换一个 provider 就换一下参数：

tsx src/eval/run.ts tool-selection –provider openai –model gpt-4o

结果会自动生成一份报告，按类别和难度拆开看通过率。两份报告还能 diff，你一眼就能看到”换了模型之后哪些 case 变差了”。

8.4 eval 不是工程师的专利

先说 eval 这个词。Eval 是 evaluation（评估）的缩写，在 AI 行业里指的是：写一组“考试题”来测 AI 做得对不对。就像老师出一套试卷考学生一样，你出一套试卷考你的 AI 产品。

具体怎么做？三步：

第一步，出题。想几个典型的用户场景，写下来。比如”用户说帮我看看桌面的文件列表”。

第二步，写标准答案。每道题写清楚”AI 应该做什么才算对”。比如这道题的标准答案是”AI 应该调用读取目录的工具，不应该去执行命令”。

第三步，让 AI 答题，自动判分。把题目喂给 AI，看它选的工具跟标准答案对不对。对了就 pass，错了就 fail。跑完 23 道题出一份报告，一眼看到通过率。

你可能觉得”PM 搞这个是不是小题大做”。但做完之后我发现，eval 的本质不是技术，是“想清楚怎么判断对错”。

出题需要什么能力？

• 描述一个用户场景（PM 天天干的事）
• 定义“做对了”长什么样（PM 的核心能力）
• 定义“做错了”有哪些常见模式（PM 的踩坑经验）

代码部分全是 Claude 帮你写的。你只需要想清楚那 23 道题应该考什么，这件事恰恰是 PM 最擅长的。

PM 在 AI 时代真正不可替代的能力，是替模型定义”什么叫做对了”。

9. 几件让我重新理解 AI Coding 的事

6 周里有 4 件事让我印象深刻。不是技术细节，是”我对 AI Coding 的理解被改变了”的瞬间。

那一晚模型试图打开我的钥匙串。阿布有一个 Computer Use 功能，模型能看屏幕、点鼠标。某天晚上我在 dev 环境跑测试，模型截屏看了一圈，然后在 Spotlight 搜索框里输入了”Keychain Access”。那一瞬间我意识到，模型完全有能力打开我电脑上任何 app。第二天我从早上写到深夜，连发 5 个 commit，一次性加了敏感 app 黑名单、危险按键拦截、全局停止快捷键、会话超时。那是我做阿布以来最有”产品恐惧感”的一天。

我发了一次版搞炸了用户数据。改了一个字段名，我本地测了没问题就发版了。当晚用户说”打开是空白”。因为老用户存在硬盘上的是旧字段名，新代码读不到。从那以后我做了”版本号 + migrate + 注册表”三道锁，到现在设置数据结构已经改了 16 次，再没出过这种事。

在 main 分支上直接开发。发完版忘了切回 dev，直接在 main 上继续写了好几个 commit。等发现的时候已经跟 dev 冲突了。手动解决合并冲突花了不少时间。从那以后 CLAUDE.md 里多了一条硬规则。

3 月 1 日单日 9，259 条消息。从 stats 里看到这个数字的时候我自己也吓了一跳。那天从早到晚就没停过，从一个空文件夹开始，到晚上已经有了一个能跑的桌面应用。那种”想法变成产品”的速度，以前是不可能的。

AI Coding 不是让你写代码更快 —— 它逼你直面那些以前可以装看不见的问题。安全、数据迁移、分支管理 —— 这些事你以前可以说”等有工程师了再想”，现在你就是那个工程师。

10. 能做到什么程度 + 给小白的建议

说实话写到这里我自己也觉得有点不真实。一个产品经理，6 周，8.5 万行代码，一个有完整安全体系、跨平台（Mac + Windows）、1,362 个测试、多模型适配、IM 集成、浏览器操控的桌面应用。

但我想诚实地说一下边界。

能做到什么：一个从 0 到 1 的、真实可用的完整产品。不是 demo，是能发版、有用户在用的东西。从产品设计到架构到实现到测试到发版，一个人全链路。

不能做到什么：极致性能优化（编译器层面的事我搞不定）、原创算法设计（什么时候该用 BFS 我不知道）、百万 QPS 级别的分布式系统（这不是一个人能做的事）。

需要付出什么：

• 钱：约 1 万元。订阅 5，740 + API 5，000+。第一周会觉得烧得很快，别慌，节奏稳下来之后消耗会下降
• 时间：我这 6 周里有 34 天在写，平均每天 4-6 小时。峰值日干了一整天
• 心理建设：第一周会被 Claude 搞崩 N 次。报错看不懂、改了又坏、越改越乱。这是正常的。撑过第一周就好了
• 最重要的：愿意“想清楚”。Claude 把“写代码”从瓶颈里拿掉了，但它没把“想清楚要什么”从瓶颈里拿掉。前者是工程师的事，后者一直是 PM 的事

想说给小白的你

如果你也想开始，这是我给过去自己的几条建议：

第一，先选一个你自己天天会用的小工具去做。不要做”大产品”，做”我自己每天会用的东西”。动力来自你自己的需求，做完了你就是第一个用户。

第二，第一周不写测试，找感觉。前期是做 demo 的阶段，写测试反而拖慢你。等你第一次被 bug 坑了再补，那时候你会自然而然地想写。

第三，成本会比你预期的高 3 倍。第一周烧 1000 块是正常的，别慌，Claude Code 的消耗量跟你想象的不一样，Pro 额度很快就不够用。

第四，从第一天就建 CLAUDE.md。你跟 Claude 的每一次磨合都是在往这个文件里加一条”合同条款”。越早开始，后面越顺。

第五，不要追求一次性做大功能。一个一个加，每个加完都跑一遍测试。小步快跑比大步摔跤强。

第六，让 Claude 先想产品再想技术。这是我做阿布最深的体会。它默认会直接进入”怎么实现”，你要把它拉回来：”先告诉我用户是谁、场景是什么、做完之后是什么状态。”

你不需要学会编程，你需要学会跟一个会编程的伙伴说话。

用Claude Code写论文的一整套流水线，有人打包开源出来了。

完全戳中了学生党的痛点，github星标直达6.4k。

academic-research-skills

项目名叫academic-research-skills（以下简称ARS），是一套Claude Code技能包。

里面涵盖4个skill，分别对应论文的研究、写作、审稿、定稿。

只需两行命令安装，直接一条龙串起整套学术研究流水线。

academic-research-skills

只能说，我读研的时候怎么没碰到这种好东西呢…

示意图

4个skill，跑通整套科研流程

ARS的核心架构由4个skill组成，它们各司其职，拼在一起就是一条从选题到交稿的完整链路。

我这里还做了图，大家可以看得比较直观：

△

Deep Research是一支13个Agent的研究团队。

它负责文献调研、研究问题构建、方法论设计，还能写系统性的PRISMA综述。

团队里有专门做文献溯源的Agent，会调用Semantic Scholar API验证每一篇引用的真实性。

有苏格拉底导师Agent，通过对话引导研究者理清思路。

还有魔鬼代言人Agent，专门挑刺，防止研究者在早期就陷入思维定式。

△

Academic Paper是一支12个Agent的写作团队。

从大纲设计、论证构建、草稿撰写，到双语摘要生成、图表可视化、引用格式转换，全流程覆盖。

特别值得一提的是风格校准功能，AI会学习你过往作品的写作风格，让输出更像你自己写的，而不是千篇一律的AI味。

输出格式支持Markdown、DOCX、LaTeX，最终可以编译成APA 7.0或IEEE格式的PDF。

△

Academic Paper Reviewer是一支7个Agent的审稿团队。

模拟真实学术期刊的评审流程，由主编EIC带领三位领域审稿人，再加上一个魔鬼代言人，从方法论、学科视角、跨学科价值等多个维度打分。

评分采用0到100的量化标准，80分以上接受，65到79小修，50到64大修，50以下拒稿。

审稿团队还会输出详细的修改路线图，告诉作者下一步该做什么。

△

Academic Pipeline是流程编排器，把前面三个团队串联成一条10阶段的流水线。

从研究、写作、完整性检查、同行评审、修订、最终检查，到发表准备和流程总结，每个阶段都有明确的产物和检查点。

你可以在任意阶段插入，比如已经有了初稿，就从Stage 2.5的完整性检查开始；收到了审稿意见，直接从Stage 4的修订切入。

费用参考也很透明，一篇1.5万字的论文，全程跑下来大约4到6美元。

△

比较有意思的设计

用Claude Code做学术研究的开源项目已经很多了，但是深扒之后，我发现ARS在底层设计上还是有些过人之处。

可以简单总结为一句话：系统性防止AI搞砸学术研究。

第一，引用核验。

AI写论文最忌讳的，就是幻觉引用。

不只是编造不存在的文章，还包括标题相似但作者年份全错、DOI真实但内容对不上等更隐蔽的情况。

ARS在Deep Research阶段就埋了一个引用核验机制，每一篇文献都要过Semantic Scholar API的存在性确认。

不是简单查一下标题对不对，而是用Levenshtein相似度算法做模糊匹配，阈值设在0.70以上才算通过。

△

第二，完整性闸门。

在流水线的Stage 2.5和Stage 4.5，有两道不可跳过的完整性闸门，会运行一份7项AI失败模式检查清单。

这份清单直接来自2026年Nature上发表的一项全自主AI科研研究，其中总结了7种翻车模式，覆盖引用幻觉、数据捏造、方法论造假等情形。

7种翻车模式

任何在2.5被标记为SUSPECTED的问题，必须在4.5变成CLEAR，或者由人工手动覆盖并留下记录。

设计逻辑是：把「我相信AI不会出错」变成「我要求AI证明它没出错」。

实测中，这套机制在一篇真实论文里抓到了15个伪造引用和3个统计错误。

第三，反谄媚协议，让AI敢于说不。

大多数AI工具都有一个隐形毛病，讨好用户。你让它改，它就改，哪怕改得更差。

所以ARS在审稿环节专门设计了反谄媚机制。

审稿团队里有一个Devil’s Advocate，也就是魔鬼代言人，职责是挑刺。

但挑完刺之后，还有一个让步阈值协议。

DA的反驳会被评分1到5，如果低于4分，写作团队不允许承认。

△

换句话说，AI不能为了显得好合作就轻易让步。

同时，攻击强度在修订过程中必须保持。如果第一轮审稿把方法论批得体无完肤，作者修订后不能让审稿人突然变得温柔。

评分轨迹也会被追踪，任何维度的分数下降都会被标记为回归。

这和软件工程里的不引入新Bug原则一样，改一个地方不能搞砸另一个地方。

第四，三层数据隔离，不让AI偷看答案。

ARS把数据流严格分成三层：

Layer 1是原始输入，默认不可信，可能幻觉、过时、带偏见。

Layer 2是通过完整性验证后的产物。

Layer 3是评分标准、参考答案和金标数据，这层材料永远不能出现在写作AI的上下文中。

具体实现上，写作团队和审稿团队分两次独立调用，中间有阶段边界隔离。

写作AI只能收到审稿AI的自然语言反馈，比如「第二章论证跳跃，建议补充对比实验」。

但它看不到原始的评分标准，也不知道每个维度占多少分。

这个设计的灵感来自于Anthropic今年的w2s-researcher研究，其中也用了同样的三层隔离模型。

结论是当AI能读取标签数据时，结果可能不是真的泛化，而是在优化表面特征。

解决方案不是更好的提示词，而是结构上的隔离。

△

最后一点，诚实文档化，「我不保证能复现」。

学术界经常遇到「这个结果我复现不了」的问题。ARS给每个产物生成一个repro_lock文件，记录运行时的完整配置。

但文件里有一段强制声明，LLM输出不是字节级可复现的，模型提供商会更新权重而不改模型ID，外部API每天返回不同的数据。

这个文件只是配置文档，不是重放保证。

△

在更新日志上，可以看到ARS已经经历了很多轮迭代。从2月上线到现在，提交的commit数达到了三百多次。

从每次版本更迭中，也能看出作者对AI学术研究系统风险有着深刻理解。

这也是我觉得目前学术研究AI工具的关键所在——

让AI帮你写论文并不难，重点是如何防止它出错、讨好，让整个流程变得更系统更可靠。

ARS的设计哲学，可以总结为README里那句话：

「AI是你的副驾驶，不是飞行员。」

如何安装

安装方式很简单，如果你已经在用Claude Code，只需要两行命令：

/plugin marketplace add Imbad0202/academic-research-skills/plugin install academic-research-skills

验证安装是否成功，运行：

/ars-plan

然后描述你正在写的论文主题，ARS就会启动苏格拉底对话，帮你梳理论文结构。

如果你偏好单条命令测试，也可以用：

/ars-lit-review “你的研究主题”

不过最简单的安装办法，其实是直接把SKILL.md上传到claude.ai项目知识库。

不需要安装Claude Code，打开浏览器就能用。

不过要注意，这种方式不支持多Agent并行，功能上是单Agent版本，适合轻度体验；想跑完整流水线还是需要Claude Code。

还有一点，项目支持繁体中文和英文。

那么，又到了大家最关心的，要花多少钱的环节。

作者推荐使用Claude Opus 4.7搭配Max订阅计划。

完整跑完10个阶段，单次可消耗超过20万输入token和10万输出token，单独使用某个子模块则少得多。

Max订阅计划分两档，每月100刀或200刀，相当不便宜。

但如果你的科研经费可以报销的话，那…

示意图

作者：关注前沿科技

来源：量子位

当AI编程工具的选择被简化为‘0-1用Claude Code，1-N用Codex’时，我们是否忽略了项目的真实复杂性？本文通过真实案例揭示中型SaaS项目中模块的阶段性差异，拆解两种工具背后的工程哲学，并给出‘规则稳定度’这一更具操作性的选型维度。从CLAUDE.md的宪法主义到AGENTS.md的联邦制，你的选择实则是团队工程纪律的镜像。

项目阶段不是项目的属性，是模块的属性

一个真实的场景。

某个中型 SaaS 团队，主仓库迭代了两年。代码量大约 30 万行，模块清晰，CI/CD 流水线齐整，是典型的”1-N”阶段——稳定生长。

半年前，他们启动了一个 AI 客服模块。结构还在调，API 来回改，连命名约定都还没完全定下来。是典型的”0-1″阶段——从零摸索。

图 1

这个团队最近在选 AI 编程工具。摆在桌面上的是 Claude Code 和 Codex。

技术决策最流行的回答是这样的：

“看主仓库的阶段。主体是 1-N 就选 Codex，主体是 0-1 就选 Claude Code。”

这个回答最近在中文技术圈相当流行——逻辑漂亮、对仗工整、决策清晰。Claude Code 是”治理派”，Codex 是”执行派”；CLAUDE.md 用于”建模”，AGENTS.md 用于”扩张”。听起来一切都解决了。

我的判断是：这个问题，从一开始就问错了。

不是答案错。是问题本身偷了懒。

先承认这个对仗找得真准

要先把好话说完。

把 Claude Code 和 Codex 的核心差异概括为”治理 vs 执行”——这个对仗确实精确。两个工具在指令机制层面的设计哲学完全相反。

图 2 CLAUDE.md 与 AGENTS.md：两套指令机制 · 两种工程哲学

Claude Code 的核心是一个文件：CLAUDE.md。放在项目根目录，每次会话开始时被完整加载。它配套一整套结构：CLAUDE.local.md（个人偏好，自动 gitignore）、.claude/子目录下的settings.json、rules/、agents/、skills/、hooks/。所有这些被设计成一个整体——一份”项目宪法”，团队共享，commit 到 git，长期沉淀。

Codex 的核心是另一种东西：AGENTS.md。它不在根目录”独占”，而是可以放在任意子目录下，按 cwd 路径逐层向上发现。Codex 还允许AGENTS.override.md（个人覆盖）、配置project_doc_max_bytes限制每个文件的读入量、用project_doc_fallback_filenames指定备选文件名。整套机制被设计成”分层注入”——你在哪个目录，就读哪一层的规则。

把这两套机制拍在一起看，差异就出来了：

• CLAUDE.md 假设你的项目有一套”全局共识”。它鼓励你把规则集中、统一、可被所有人读到。
• AGENTS.md 假设你的项目没有完全的全局共识，或者全局共识不该管所有事。它鼓励你按目录把规则散下去。

一个是”立宪”，一个是”分治”。

“治理 vs 执行”是表面的说法。底层是”共识驱动 vs 容器驱动”。Anthropic 信前者，OpenAI 信后者。

到这里为止，原文的对仗成立。

但好的对仗有一个副作用——它会让人误以为，这是个二选一的问题。

真实项目里：阶段不是项目的属性，是模块的属性

绝大多数试图替你做选择的文章，最终都会落到一个简化的二元划分上。

“你是 0-1 项目？选 Claude Code。”

“你是 1-N 项目？选 Codex。”

这个推论的前提是：一个项目在某个时间点，整体只处于一个阶段。

图 3 “0-1 / 1-N”这个划分偷了懒

这个前提在现实里几乎不成立。

回到开头那个 SaaS 团队。主仓库 1-N、新模块 0-1，这种结构不是个例，是绝大多数中型团队的常态。三五年的老项目几乎都是”主体稳定 + 新模块持续探索”。完全 0-1 的项目只在创业前六个月存在；完全 1-N 的项目只在生命末期存在。中间几年——也就是绝大多数项目的绝大多数时间——是两个阶段共存。

再往细里看，”阶段”这个词本身可能就用错了。

电商主仓库迭代两年，结构稳定，是 1-N。但里面”营销活动模块”每三个月推倒重来一次，每次都是 0-1。

一个 3 年的内容平台，整体 1-N。但今年突然要做 AI 重构，老的内容审核管道完全保留（极度 1-N），新加的 AI 审核流是从零开始（彻底 0-1）。两条管道并行跑在同一个仓库里。

开源项目更明显。React 是 1-N 还是 0-1？主分支当然 1-N，但experimental/子树里的新特性永远在 0-1。

所以”项目阶段”这个概念，真实指代的不是项目，是项目里某一个模块或某一条功能线。

按”项目阶段”来选工具，等于强迫你为整个项目挑一个标尺，而项目里至少有 5-10 个模块在不同标尺上。

会发生什么？

按原文的逻辑硬选一边，一定有一边吃亏。

选了 Claude Code 的团队：新模块那边用得很顺——团队需要快速形成共识，CLAUDE.md 把目录约定、命名习惯、API 规范一次性沉淀进去，Claude 每次会话都读到，写代码符合规约。但是老模块那边痛苦。两年的项目积累，CLAUDE.md 写到 3000 行就停不下来了。每次会话 Claude 都要全量读这 3000 行，token 烧得心疼，更糟糕的是上下文被噪声填满，真正重要的规则反而被淹没。新人接手，光读这份 CLAUDE.md 比读代码还累。

选了 Codex 的团队：老模块那边用得很顺——稳定的目录结构对应稳定的 AGENTS.md，规则随代码长，简单直接。但是新模块那边痛苦。AI 客服模块的目录结构还在变，今天叫agents/，明天改名pipelines/，AGENTS.md 跟着重构跑，每次重构都要重写规则。更尴尬的是 AI 经常自作主张创建新文件夹放代码——因为它看到 AGENTS.md 只覆盖了已有目录，新增的地方没有规则约束。

这两种痛苦不是工具不好用，是工具的预设跟项目的真实结构不匹配。

项目阶段不是项目的属性，是模块的属性。

真正的选型维度是”规则稳定度”

不要问”这个项目是 0-1 还是 1-N”。

要问的是另一个问题：”这个模块的工程规则稳不稳定”

这是一个更落地、更可操作、更接近你日常体感的维度。

图 4 3 分钟自检：你的模块在 0-1 还是 1-N

什么叫”规则稳定”？

• 接口已经定型（半年没大改了）；
• 文件结构不会经常重构（命名约定、目录划分都定下来了）；
• 新人按照现有约定就能上手（不需要每次跟一个老人复述”为什么这里这样写”）；
• 代码里反复出现的模式可以被一句话固化（”接口必须 Pydantic、错误处理走 raise_for_status 风格”）。

这些信号叠加起来，说明你这个模块进入了”规则可以下沉”的阶段。

这种模块上 Codex 会非常顺。AGENTS.md 跟着目录走，规则跟着代码长，AI 在局部范围内做局部修改，不需要每次都把全局拉一遍。

什么叫”规则不稳定”？

• 这周还叫service.py，下周可能被拆成service/handler.py和service/processor.py；
• 团队还在讨论”什么放 model，什么放 schema”；
• 你给 AI 一个任务，写代码之前必须先解释三段背景（”我们这个项目跟一般 Python 项目不一样，我们的 model 不是 ORM 的 model……”）；
• 每写一个新功能，team review 都会冒出”这个该归到哪类”的争论。

这种模块上 Claude Code 才合适。CLAUDE.md 把团队还在形成共识的那些规则集中沉淀，每次会话都全量给 AI 看一遍，避免它在没有共识的地方乱写。

判断可以再简化——给你一个”3 分钟自检清单”：

1. 这个模块最近 3 个月，文件结构有过大调整吗？
2. 你给一个新人写过这个模块的入门文档吗？写完没有？
3. 你能用 3 行规则讲清楚这个模块的核心约定吗？
4. AI 上一次写错代码，是因为它没读到全局规则，还是因为它没读到这个目录的局部规则？

如果 1 是”有”、2 是”没写完”、3 是”不能”、4 是”全局规则”——这个模块还在 0-1 阶段，用 Claude Code。

如果 1 是”没有”、2 是”写完了而且不需要更新”、3 是”能”、4 是”局部规则”——这个模块进入了 1-N，用 Codex。

同一个项目里有的模块得 1、有的模块得 4，完全正常。

正常解读：你的项目本来就不是单一阶段。两个工具应该共存。

选错工具会发生什么——实战信号清单

图 5 选错了怎么识别 · 两种失败的早期信号

原文最缺的是反话。

“什么时候你选错了”、”怎么从日常使用中识别出选错了”——这些没人告诉你。

我把两种选错都拆给你看，附上具体信号。下次踩到，你能立刻反应过来。

信号一：1-N 模块硬上了 Claude Code

最常见的早期信号是 CLAUDE.md 文件本身的膨胀。

刚开始可能只有 200 行——技术栈、目录约定、几条 review 清单，很舒服。

半年后你打开看，1500 行了。新加的规则一条一条往里塞，旧的没人删。

一年后变成 4000 行。你已经记不清里面写了什么，但每次会话都全量加载，每条 prompt 都要重新塞进去。

team 里有人开始抱怨”Claude 怎么又忘了我们的规则”，但其实不是 Claude 忘了，是 CLAUDE.md 里有 50 条互相冲突的规则，Claude 在选最近读到的那条。

这个信号背后的真实问题是：你的项目已经成熟到，”全局共识”撑不住单文件治理了。规则需要按模块分散下去，每个目录管自己的事。继续用 CLAUDE.md，是在用一份开国宪法管理一个治理结构已经分层的国家。

信号二：0-1 模块硬上了 Codex

最常见的早期信号是 AGENTS.md 跟着目录重构跑。

刚开始你按 Codex 推荐的方式，在每个子目录放一份 AGENTS.md，看起来很整齐。

两周后你把agents/改名成workers/，跟着要把agents/AGENTS.md改到workers/AGENTS.md。git diff 一片红绿。

一个月后，你不耐烦了，开始把规则统一塞到根目录的 AGENTS.md 里——但 Codex 是按目录加载的，根目录的规则只在 cwd 是根目录时生效。AI 在子目录里跑就读不到这些规则。

你发现 AI 经常自作主张创建新文件夹，因为它看的那一份 AGENTS.md 没有覆盖到新增的位置。

这个信号背后的真实问题是：你这个模块还没到”规则可以下沉到目录”的阶段。结构本身还在变，规则跟着结构跑等于自找麻烦。这种阶段需要的是一份”全项目通看”的指令系统——把还在变动的约定集中放在一个地方，每次都全量给 AI 看。

这两种失败的共性

不是工具不好用。

是你的工程纪律没跟上你选的工具的预设。

Claude Code 假设你能维护一份”项目宪法”——这是个工程纪律要求，能不能维护，取决于你团队有没有人定期 review 和裁剪这份文件。Codex 假设你能维护”按目录的局部规则”——这也是个工程纪律要求，能不能维护，取决于你的目录结构稳不稳定。

工具选错了，本质上是你选了一个”超出你团队工程纪律承载能力”的预设。

这不只是工具选择

图 6工具背后是两个问题 · 两种治理哲学

把视角再往深一层。

选 Claude Code 还是 Codex，其实是在选两种工程治理哲学。

Claude Code 是宪法派。它相信全局共识可以形成、可以沉淀、可以让所有人遵守同一份文档。这是 Anthropic 的工程哲学——单点高杠杆、共识驱动、长期记忆。背后假设是：好的团队应该能写出一份让所有人都认可的”项目说明书”。

Codex 是联邦派。它假设全局共识形不成，或者即使形成了也不该管所有事。每个目录管自己的、每个模块有自己的规则、个人覆盖凌驾于团队默认。这是 OpenAI 的工程哲学——分层注入、容器驱动、按需局部。背后假设是：好的团队应该把治理切碎到能管得过来的颗粒度。

这两种哲学没有对错，只有匹配度。

匹配你团队的标志：

• 如果你团队有那种”愿意花两小时把一个争论写成文档”的人，且这种文档能被其他人持续维护——CC 的宪法派路线适合你。
• 如果你团队更习惯”写代码的时候顺手把规则写在注释和 README 里”，且很难凑齐时间集中讨论全局规则——Codex 的联邦派路线适合你。

这是工程文化问题，不是技术能力问题。

更深一层看，这两个工具其实都在逼着团队”长大”，只是逼的方向不同。

CC 逼着你形成共识。如果你用 CC 一段时间，CLAUDE.md 永远只有空洞的”写好代码、follow best practice”这种废话，说明你的团队还没有真正形成可写下来的共识。这时候 AI 给你写的代码风格永远飘忽，那是 CC 在用”你的工程治理还没长出来”这件事告诉你结果。

Codex 逼着你稳定结构。如果你用 Codex 一段时间，发现 AGENTS.md 总在跟着目录重构跑、规则永远写不稳定，说明你的工程结构本身还没定型。这时候 AI 自作主张乱建文件夹，那是 Codex 在用”你的工程结构还没定型”这件事告诉你结果。

工具不会替你解决治理问题。它只是把这个问题摆到你面前，让你看见。

所以真正的问题是

你打开 Claude Code 或者 Codex 那一刻，你以为你在选一个 AI 编程工具。

你其实在选你对自己团队工程纪律的承认。

• CLAUDE.md 在问你：”你们团队能形成共识吗？能形成的话，沉淀成一份文档让所有人共用吗？”
• AGENTS.md 在问你：”你们团队的目录结构稳定吗？稳定的话，把规则下沉到目录里吗？”

这两个问题，你心里有什么答案，决定了哪个工具能帮上你。

回到开头那个 SaaS 团队。主仓库 1-N、新模块 0-1。它们的正确解法不是从两个工具里挑一个，是同时用两个——

老模块上 Codex，让规则跟着稳定的目录长。

新模块用 Claude Code，让团队边写边形成共识。

如果团队不愿意接受两个工具并行的工程成本——那是另一个问题：选一个能力强的工具凑合用，但要预期它在不匹配的那一半模块里会持续摩擦。

但没必要假装这种摩擦是工具能解决的。

软件项目永远不是 0-1 然后 1-N。它是 N 个模块各自处于不同阶段。

真正应该问自己的不是”我的项目在哪个阶段”，是另一个更难的问题：

哪些模块我可以立宪，哪些模块我必须分治？

这个问题答好了，工具自己就选好了。

答不好这个问题，选哪个工具都会觉得不顺。

写代码的人多多少少都有过这种瞬间：

AI 在屏幕上哗啦啦输出一大段，你眼睛盯着光标跳，脖子越来越僵，三十分钟后回过神来——刚才到底在看什么？

那天我也是。窗外天黑了，屋里只剩屏幕的光，Claude Code 又在往外吐字。我突然冒出一个念头：

它要是能念给我听就好了

不用多花哨，就像有个人坐在旁边，一边敲代码一边把要紧的话讲出来。这样我可以靠在椅子上闭一会儿眼，可以去倒杯水，可以伸个懒腰——它该说的话我一句不落

我查了一圈，官方没这个功能。但 Claude Code 有个东西叫Hooks，是它在会话开始、结束、每次回答完之后会自动触发的”钩子”。理论上，我可以写几个脚本挂上去，让它每次回答完就调用 macOS 自带的say命令把内容念出来

折腾了一个周末，改了 6 个版本，写了 6 个 Shell 脚本，加起来四百多行。最后真做成了

现在我的 Claude Code 一边写代码一边说话，听上去像电台主播，别说，开始还有点不习惯

这篇文章就把整套配置完整写出来。不会写代码也没关系，我尽量把每一步都讲到能复制粘贴就跑通的程度

你需要先有什么

这套方案目前只在Mac 电脑上能用（Windows 和 Linux 需要改脚本，本文先不展开）

打开你的”启动台”，找到一个叫”终端”的应用——黑黑的，图标像个小窗口。这是后面所有操作要用的地方。不要怕，照着复制粘贴就行

接下来检查两样东西：

第一，你装了 Claude Code 吗？如果在终端里输入claude然后回车，看到提示就说明装了。没装的话先去 Claude 官网装一下，回头再继续

第二，你装了 jq 吗？jq 是个处理 JSON 数据的小工具。在终端里输入：

brewinstalljq

如果提示command not found: brew，说明你电脑上还没有 Homebrew（Mac 上最常用的软件管家），先去 brew.sh 网站照首页那一行命令装一下，再回来执行上面这句

装完之后，准备工作就完成了

第一步：建一个文件夹放脚本

打开终端，复制这一行进去，回车：

mkdir-p~/.claude/hooks

这句话的意思是：在你的用户目录下建一个.claude/hooks文件夹，专门放后面这些脚本

没有任何反应是正常的。终端的哲学就是”没消息就是好消息”，一旦报错它会很大声地告诉你

第二步：写 6 个脚本

下面 6 段命令，一段一段复制进终端，每段回车一次。每一段都是cat > 某个文件 << ‘EOF’开头、EOF结尾的格式——这是 Shell 的一种写法，意思是”把中间这一坨内容原封不动地写进这个文件里”

注意一定要连同最后那个EOF一起复制进去，不然终端会一直等你输完，光标卡在那儿不动

脚本 1：会话启动时叫醒”播音员”

cat > ~/.claude/hooks/tts-start.sh <<‘EOF’#!/bin/bashset-uMONITOR=”$HOME/.claude/hooks/tts-monitor.sh”DEBUG_LOG=”$HOME/.claude/hooks/tts-start-debug.log”log() {echo”$1″>>”$DEBUG_LOG”; }log”=== Starting TTS monitor at$(date)===”VOICE_ENABLED=$(jq -r’.voiceEnabled // false’”$HOME/.claude/settings.json”2>/dev/null ||echofalse)if[“$VOICE_ENABLED”!=”true”];then log”Voice disabled, not starting monitor” exit0fiINPUT=$(cat)TRANSCRIPT_PATH=$(echo”$INPUT”| jq -r’.transcript_path // empty’2>/dev/null)[“$TRANSCRIPT_PATH”=”null”] && TRANSCRIPT_PATH=SESSION_ID=$(echo”$INPUT”| jq -r’.session_id // .conversation_id // .sessionId // .conversationId // empty’2>/dev/null)[“$SESSION_ID”=”null”] && SESSION_ID=[ -z”$SESSION_ID”] && SESSION_ID=”session-$(date +%s)-$”if[ -z”$TRANSCRIPT_PATH”];then PROJECT_DIR=$(echo”$INPUT”| jq -r’.cwd // .workspace_roots[0] // empty’2>/dev/null) [“$PROJECT_DIR”=”null”] && PROJECT_DIR= if[ -n”$PROJECT_DIR”];then TRANSCRIPT_DIR=”$HOME/.claude/projects/$(echo “$PROJECT_DIR” | sed ‘s///-/g’)” SPECIFIC=”$TRANSCRIPT_DIR/$SESSION_ID.jsonl” [ -f”$SPECIFIC”] && TRANSCRIPT_PATH=”$SPECIFIC” fifiPID_SAFE=$(echo”$SESSION_ID”| tr -cd'[:alnum:]-_’| head -c 120)[ -n”$PID_SAFE”] || PID_SAFE=”unknown”PID_FILE=”$HOME/.claude/hooks/tts-monitor-$PID_SAFE.pid”if[ -f”$PID_FILE”];then OLD_PID=$(tr -d’ n'<“$PID_FILE”) if[ -n”$OLD_PID”] &&kill-0″$OLD_PID”2>/dev/null;then kill-TERM”$OLD_PID”2>/dev/null ||true sleep 0.15 kill-KILL”$OLD_PID”2>/dev/null ||true fi rm -f”$PID_FILE”fiSPAWN_LOG=”$HOME/.claude/hooks/tts-monitor-spawn.log”nohup”$MONITOR””$TRANSCRIPT_PATH””$SESSION_ID”>>”$SPAWN_LOG”2>&1 </dev/null &log”Started monitor PID $!”exit0EOF

这是会话开始时第一个被叫醒的脚本。它的工作是检查”语音开关”是不是打开的，然后在后台启动真正干活的”监控员”——也就是下面这一个

脚本 2：真正干活的”监控员”

这是最长的一个，也是最核心的。它负责盯着 Claude Code 的对话记录文件，一旦有新内容就读出来

cat > ~/.claude/hooks/tts-monitor.sh <<‘EOF’#!/bin/bashset-uif[“$#”-ge 2 ];then TRANSCRIPT_PATH=”$1″ [“$TRANSCRIPT_PATH”=”null”] && TRANSCRIPT_PATH= SESSION_ID=”$2″else TRANSCRIPT_PATH=”” SESSION_ID=”unknown”fiPID_SAFE=$(echo”$SESSION_ID”| tr -cd'[:alnum:]-_’| head -c 120)[ -n”$PID_SAFE”] || PID_SAFE=”unknown”PID_FILE=”$HOME/.claude/hooks/tts-monitor-$PID_SAFE.pid”DEBUG_LOG=”$HOME/.claude/hooks/tts-session-$PID_SAFE.log”log() {echo”$1″>>”$DEBUG_LOG”; }VOICE_ENABLED=$(jq -r’.voiceEnabled // false’”$HOME/.claude/settings.json”2>/dev/null ||echofalse)[“$VOICE_ENABLED”!=”true”] &&exit0resolve_by_session() { find”$HOME/.claude/projects”-maxdepth 15 -name”$1.jsonl”-typef 2>/dev/null | head -1}extract_speakable() { echo”$1″| jq -r’ (.message // {}) as $m | ($m.content | if type == “array” then . elif type == “string” then [{“type”:”text”,”text”: .}] else [] end) as $c | ([$c[]? | select(.type == “text”) | .text] | join(” “)) as $t | if ($t | length) > 0 then $t else ([$c[]? | select(.type == “thinking”) | .thinking] | join(” “)) end’2>/dev/null | head -c 500}log”=== Monitor PID $ at$(date)===”echo$ >”$PID_FILE”WAIT_COUNT=0while[“$WAIT_COUNT”-lt 180 ];do [ -n”$TRANSCRIPT_PATH”] && [ -f”$TRANSCRIPT_PATH”] &&break if[ -n”$SESSION_ID”] && [“$SESSION_ID”!=”unknown”];then if[“$((WAIT_COUNT % 3))”-eq 0 ];then RESOLVED=$(resolve_by_session”$SESSION_ID”) if[ -n”$RESOLVED”] && [ -f”$RESOLVED”];then TRANSCRIPT_PATH=”$RESOLVED” break fi fi fi sleep 1 WAIT_COUNT=$((WAIT_COUNT + 1))doneif[ ! -f”$TRANSCRIPT_PATH”];then rm -f”$PID_FILE” exit0filog”Tailing:$TRANSCRIPT_PATH”LAST_LINE=$(wc -l <“$TRANSCRIPT_PATH”| awk'{print $1+0}’)whiletrue;do sleep 0.4 [ ! -f”$TRANSCRIPT_PATH”] &&break CURRENT_LINES=$(wc -l <“$TRANSCRIPT_PATH”2>/dev/null | awk'{print $1+0}’) if[“$CURRENT_LINES”-gt”$LAST_LINE”];then tail -n +$((LAST_LINE + 1))”$TRANSCRIPT_PATH”|whileIFS=read-r line;do ROLE=$(echo”$line”| jq -r’.type // empty’2>/dev/null) if[“$ROLE”=”assistant”];then TEXT=$(extract_speakable”$line”) if[ -n”$TEXT”] && [“${#TEXT}”-le 2000 ];then if!printf’%s’”$TEXT”| grep -q’^“`’;then CLEAN=$(printf’%s’”$TEXT”| sed’s/“`[^`]*“`//g; s/**//g; s/*//g; s/`//g’| tr -d’n’| head -c 320) [ -z”$CLEAN”] && CLEAN=$(printf’%s’”$TEXT”| tr -d’n’| head -c 320) if[ -n”$CLEAN”];then (/usr/bin/say”$CLEAN”2>/dev/null) & fi fi fi fi done LAST_LINE=$CURRENT_LINES fidonerm -f”$PID_FILE”EOF

它会自动过滤掉代码块（不然念起代码来你会想砸电脑），只朗读 Claude “真正要说的”话

脚本 3：会话结束时让”播音员”下班

cat > ~/.claude/hooks/tts-stop.sh <<‘EOF’#!/bin/bashDEBUG_LOG=”$HOME/.claude/hooks/tts-stop-debug.log”echo”=== Stopping at$(date)===”>>”$DEBUG_LOG”INPUT=$(cat 2>/dev/null ||true)SESSION_ID=$(echo”$INPUT”| jq -r’.session_id // .conversation_id // .sessionId // .conversationId // empty’2>/dev/null)if[ -z”$SESSION_ID”] || [“$SESSION_ID”=”null”];then exit0fiPID_SAFE=$(echo”$SESSION_ID”| tr -cd'[:alnum:]-_’| head -c 120)[ -n”$PID_SAFE”] || PID_SAFE=”unknown”PID_FILE=”$HOME/.claude/hooks/tts-monitor-$PID_SAFE.pid”if[ -f”$PID_FILE”];then OLD_PID=$(tr -d’ n'<“$PID_FILE”) if[ -n”$OLD_PID”] &&kill-0″$OLD_PID”2>/dev/null;then kill-TERM”$OLD_PID”2>/dev/null ||true sleep 0.3 kill-KILL”$OLD_PID”2>/dev/null ||true fi rm -f”$PID_FILE”fiEOF

注意它只关掉当前这个窗口的监控，不影响你开着的其他 Claude 窗口。这是踩了好几个坑之后才改成这样的

脚本 4：一键开关语音

cat > ~/.claude/hooks/voice-toggle.sh <<‘EOF’#!/bin/bashSETTINGS_FILE=”$HOME/.claude/settings.json”CURRENT=$(jq -r’.voiceEnabled // false’”$SETTINGS_FILE”)if[“$CURRENT”=”true”];then jq’.voiceEnabled = false’”$SETTINGS_FILE”> /tmp/settings.json.tmp mv /tmp/settings.json.tmp”$SETTINGS_FILE” pkill -f”tts-monitor.sh”2>/dev/null ||true rm -f”$HOME/.claude/hooks/tts-monitor-“*.pid 2>/dev/null ||true killall say 2>/dev/null ||true echo”✓ 语音播报已关闭”else jq’.voiceEnabled = true’”$SETTINGS_FILE”> /tmp/settings.json.tmp mv /tmp/settings.json.tmp”$SETTINGS_FILE” echo”✓ 语音播报已开启”fiEOF

之后想开就开、想关就关，跑一次这个脚本即可

脚本 5：Stop 钩子的“占位脚本”

cat > ~/.claude/hooks/stop-speak.sh <<‘EOF’#!/bin/bashDEBUG_LOG=”$HOME/.claude/hooks/tts-debug.log”VOICE_ENABLED=$(jq -r’.voiceEnabled // false’”$HOME/.claude/settings.json”2>/dev/null ||echofalse)[“$VOICE_ENABLED”!=”true”] &&exit0KILL=$(jq -r’.env.TTS_KILL_ON_STOP // empty’”$HOME/.claude/settings.json”2>/dev/null)if[“$KILL”=”true”] &&command-v killall >/dev/null 2>&1;then killall say 2>/dev/null ||truefiEOF

这个脚本默认什么都不做。别小看它——之前的版本一旦 Claude 暂停就把朗读全部杀掉，结果话还没说完声音就断了，特别恼火。所以这个版本让它对 Stop 视而不见，朗读该念完就念完

脚本 6：自检小工具

cat > ~/.claude/hooks/tts-selftest.sh <<‘EOF’#!/bin/bashset-euo pipefailMON=”$HOME/.claude/hooks/tts-monitor.sh”UUID=”aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee”TMP=$(mktemp /tmp/tts-selftest.XXXXXX)trap”rm -f$TMP$HOME/.claude/hooks/tts-monitor-$UUID.pid 2>/dev/null || true”EXITVOICE=$(jq -r’.voiceEnabled // false’”$HOME/.claude/settings.json”2>/dev/null ||echofalse)if[“$VOICE”!=”true”];then echo”请先开启语音再自检” exit0fiprintf’%sn”{“type”:”user”,”message”:{“role”:”user”,”content”:”ping”}}’>”$TMP””$MON””$TMP””$UUID”&MP=$!sleep 0.8printf’%sn”{“type”:”assistant”,”message”:{“role”:”assistant”,”content”:[{“type”:”text”,”text”:”自检通过”}]}}’>>”$TMP”sleep 2kill-TERM”$MP”2>/dev/null ||trueLOG=”$HOME/.claude/hooks/tts-session-$UUID.log”ifgrep -qE’Tailing|Speakable’”$LOG”2>/dev/null;then echo”OK: 监控正常”else echo”FAIL: 没有抓到内容” tail -20″$LOG”2>/dev/nullfiEOF

这个用来在不开 Claude 的情况下，单独验证脚本本身有没有问题

第三步：给脚本”通行证”

刚写完的脚本是一堆”无权限”的文件，得手动告诉系统这些是可以执行的程序。一行命令搞定：

chmod +x~/.claude/hooks/tts-*.sh~/.claude/hooks/voice-toggle.sh~/.claude/hooks/stop-speak.sh

第四步：让 Claude Code 知道这些脚本的存在

光写完脚本不够，还得告诉 Claude Code：”会话开始时调用这个、结束时调用那个”。这一步要修改它的配置文件

把下面整段复制进终端运行——它会自动帮你改好配置，不需要你手动写 JSON

cp~/.claude/settings.json ~/.claude/settings.json.backup2>/dev/nullpython3<<‘PYTHON_SCRIPT’import json, ossettings_path = os.path.expanduser(‘~/.claude/settings.json’)home = os.path.expanduser(‘~’)try: withopen(settings_path,’r’)asf: settings = json.load(f)except FileNotFoundError: settings = {}settings.setdefault(‘voiceEnabled’, False)settings.setdefault(‘hooks’, {})hooks_to_add = { ‘SessionStart’:f'{home}/.claude/hooks/tts-start.sh’, ‘SessionEnd’: f'{home}/.claude/hooks/tts-stop.sh’, ‘Stop’: f'{home}/.claude/hooks/stop-speak.sh’,}forevent, script in hooks_to_add.items(): settings[‘hooks’].setdefault(event, []) exists= any( h.get(‘hooks’, [{}])[0].get(‘command’,”).endswith(os.path.basename(script)) forh in settings[‘hooks’][event] ) ifnot exists: settings[‘hooks’][event].append({ ‘hooks’: [{‘type’:’command’,’command’: script}] })withopen(settings_path,’w’)asf: json.dump(settings,f,indent=2)print(“✓ 配置完成”)PYTHON_SCRIPT

看到 “✓ 配置完成” 就说明搞定了

第五步：开机仪式

现在所有零件都装好了，但语音开关还是关着的。打开它：

~/.claude/hooks/voice-toggle.sh

终端会回复你✓ 语音播报已开启

然后做一个最朴素的测试：

say”你好，我是 Claude，从今天开始我会念给你听”

如果你听到 Mac 用一种特别人工的腔调把这句话念了出来——恭喜，硬件层面没问题

接着关掉所有 Claude Code 窗口，重新打开一个。这一步很关键，因为 Hooks 配置只在新会话启动时生效

新开一个会话之后，随便问 Claude 一个问题，比如”你好”

如果一切顺利，你会听到它一边在屏幕上打字，一边把内容念了出来

用起来之后你可能想问的问题

怎么换个声音？

Mac 里其实藏着几十种语音。在终端里输入say -v “?”能看到全部清单，里面”Ting-Ting”是普通话女声，”Sin-Ji”是粤语女声，还有日语英语德语各种口音的

想换声音的话，打开~/.claude/hooks/tts-monitor.sh（用 VS Code 或者随便什么文本编辑器），找到/usr/bin/say “$CLEAN”这一行，改成/usr/bin/say -v “Ting-Ting” “$CLEAN”就行

它念得太快/太慢怎么办？

同一行里加个-r参数，后面跟一个数字：/usr/bin/say -r 200 “$CLEAN”。默认 175，越大越快，能调到 500，也能慢到 100

想暂时关掉怎么办？

~/.claude/hooks/voice-toggle.sh

这一句话是开关，再跑一次就重新打开

完全不想要了怎么删？

rm ~/.claude/hooks/tts-*.shrm ~/.claude/hooks/voice-toggle.shrm ~/.claude/hooks/stop-speak.shcp~/.claude/settings.json.backup ~/.claude/settings.json

干净利落

如果它没动静

第一招：看看开关

cat~/.claude/settings.json |grepvoiceEnabled

应该是true。如果是false，跑一次voice-toggle.sh

第二招：自检

~/.claude/hooks/tts-selftest.sh

看终端的输出。”OK”就说明脚本本身没问题，问题在 Claude Code 那一端，重启一下窗口大概率能好

第三招：看日志

ls-t ~/.claude/hooks/tts-session-*.log| head -1| xargs tail -50

这一句会把最新的会话日志最后 50 行打出来。里面如果出现Speakable len=字样，说明监控员抓到内容了，但可能say没跑起来——检查一下系统音量、输出设备是不是被切到了别的设备（比如蓝牙耳机断了之后没回到电脑）

第四招：核武器

pkill-f”tts-monitor.sh”rm -f ~/.claude/hooks/tts-monitor-*.pid

把所有残留进程清空，重新打开 Claude Code 窗口。99% 的疑难杂症这一招就能搞定

写在最后

配好这套东西后，写代码的感觉确实有点不一样

不知道是声音让它多了点什么。屏幕上的字我可以随时划走，但它念出来的时候，我会不自觉地听完。明明内容一样，感觉就是不一样

有时候它在念一段很长的解释，我靠在椅背上，没有去看屏幕，就这么听着。念完了，我才回过神来——哦，刚才在工作

当然，它不会变得更聪明，也不会变得更快。但总觉得屏幕和我之间的那道墙，消失了

总之，你也想体验一下，可以花10分钟给它配上“嘴”，相信我，你会爱上它的

配置文件清单

~/.claude/hooks/

├── tts-start.sh 会话开始时叫醒监控

├── tts-monitor.sh 真正干活的监控员

├── tts-stop.sh 会话结束时让监控下班

├── voice-toggle.sh 一键开关

├──stop-speak.sh Stop 钩子（默认装聋）

└── tts-selftest.sh 不开 Claude 也能自检

觉得有用的话，欢迎点赞转发收藏，遇到任何问题都可以留言或私信，就这样，下期见

DeepSeek版Claude Code爆了！

智东西5月6日消息，今日，美国独立开发者Hunter Bown的开源项目DeepSeek-TUI在GitHub上爆了，冲上GitHub热榜第一，今天Star数上涨2434，总Star数已超10.2k。

这一项目是基于DeepSeek-V4的终端原生编程Agent，其允许开发人员直接在终端与DeepSeek聊天、编辑文件、运行shell命令、管理任务，甚至协调代码库中的子Agent。

今早，DeepSeek-TUI更新了0.8.13新版本，聚焦运行时和TUI相关问题修复，提示词规范优化、运行轨迹日志、Anthropic接口兼容支持以及大规模界面整理优化，均已延后至后续版本发布。

值得一提的是，DeepSeek-TUI的开发者并不是专业人士，Bown的本硕专业与编程无关，Bown 2015年获得北得克萨斯大学音乐教育学士，2019年在南方卫理公会大学获得音乐教育硕士，目前就读于美国南方卫理公会大学Dedman法学院。

该项目2026年1月发布，伴随今年4月底DeepSeek-V4升级、Bown在X上发帖想和中国开发者建联而走红，他称中国开发者为“鲸鱼兄弟”。

X上网友分享，Bown已经成功拥有微信账号，并和中国开发者交流起来了。

在DeepSeek-TUI开源主页的贡献者名单中，还有Claude、Gemini。

一站式全能调度智能Agent终端Tday开源项目的作者发帖称，他成功将DeepSeek-TUI集成到Tday后，其体验表现出极高的稳健性，配合DeepSeek-v4-flash时，速度非常接近开源AI编程智能体OpenCode。

Claude Design的开源替代方案Nexu作者称，这是首次在代码智能Agent的终端环境中直接运行DeepSeek-V4，他们测试的效果相当不错。

有网友在下面称赞，这么好的项目必须支持。

还有网友询问Bown帖子里说的“鲸鱼兄弟”来源，感觉这个称呼很有喜感。

不过，也有网友认为DeepSeek-TUI火得莫名其妙：“为什么要抛弃一个已有成熟方案的产品，转向没有稳定的产品？”

01.基于DeepSeek-V4构建，还专门发了中国开发者友好版本

DeepSeek-TUI是基于DeepSeek-V4构建的终端编程智能体，具备100万token上下文窗口、流式推理块和前缀缓存感知成本报告的能力。

具体而言，其可读取与编辑文件、执行终端命令、联网检索、管理Git版本库，并能在键盘交互的终端界面（TUI）中调度多个子智能Agent协同工作。

网友评价DeepSeek-TUI的界面布局一目了然，但缺点是对话区中AI输出和用户输入的分界不明显。

有网友用DeepSeek官方API进行了对比，相比Claude Code，DeepSeek-TUI在跑长时长任务时，缓存命中率会下降。

DeepSeek-TUI的架构如下：DeepSeek调度命令行→DeepSeek-TUI配套程序→终端图形界面↔异步引擎↔兼容OpenAI协议的流式客户端。

工具调用通过类型化注册中心流转，包含终端命令、文件操作、Git版本管理、联网检索、子智能体、MCP协议、RLM大模型，执行结果以流式方式回写到对话日志中。

引擎负责管理会话状态、对话轮次、持久化任务队列，还内置LSP语言服务子系统；代码编辑完成后，会先把语法诊断信息送入大模型上下文，再进行下一步逻辑推理。

DeepSeek-TUI的开源主页还有对中国开发者的镜像友好安装版本：

02.共三大运行模式，还能自适应调整推理等级

在开源项目主页，Bown专门用中文写了README.zh-CN.md文件，其中提到DeepSeek-TUI的主要特点包括：

自动模式：用户可以通过model auto指令启用自动模式，该工具会在每一轮交互中自动适配选择合适大模型，并匹配对应的推理思考等级。

切换推理等级：用户可以通过按下Shift+Tab快捷键循环切换推理等级，分别为关闭推理→高推理强度→最高推理强度。

推理流式输出：其会将模型进行思考推理的过程进行实时流式展示，可直观看到DeepSeek的完整逻辑推理步骤。

全量工具能力：内置完整工具集，支持文件读写操作、终端命令执行、Git版本管理、网页搜索与网页浏览、补丁应用、子智能Agent调度，以及MCP协议服务器连接。

百万token上下文：具备上下文内容追踪、手动/自动配置内容压缩功能，同时提供前缀缓存监控统计能力。

内置三大运行模式：规划模式（仅只读查阅项目代码与文件）、Agent模式（交互操作且需手动审批）、极简自动模式（全部操作自动审批执行）。

会话保存与接续：支持为长时间运行的工作会话创建检查点，随时保存进度，后续可一键恢复接续会话继续工作。

工作区版本回滚：项目会内置独立快照Git机制，在每轮操作前后自动生成项目快照，通过/restore和revert_turn命令即可回滚操作，不会改动项目原生的Git仓库配置。

持久化任务队列：后台运行的任务支持持久化保存，程序重启后，未完成的后台任务可自动继续执行。

HTTP/SSE运行接口：支持通过deepseek serve—http启动服务，提供HTTP、SSE接口，适配无图形界面的无头自动化代理工作流。

MCP模型上下文协议：可连接Model Context Protocol模型上下文协议服务器，扩展更多第三方工具能力。

原生RLM批量查询：内置rlm_query原生能力，复用同一API客户端，调用轻量化低成本的deepseek-v4-flash模型，高效完成批量代码与数据分析任务。

LSP代码诊断：依托rust-analyzer、pyright、typescript-language-server、gopls、clangd等主流语言服务工具，每次编辑代码后，都会在界面内实时展示代码错误与警告信息。

用户个性化记忆：用户可开启持久化备注文件功能，自定义的偏好设置会注入系统提示词，实现跨会话保留个人使用习惯与配置偏好。

多语言界面本地化：支持英文、日文、简体中文、巴西葡萄牙语四种界面语言，可自动识别系统语言适配切换。

实时费用统计：实时统计每一轮交互及整个会话的token消耗、预估使用成本，同时细化展示缓存命中与缓存未命中的明细数据。

技能扩展系统：支持从GitHub安装、组合自定义指令技能包，可灵活扩展工具能力，全程无需依赖额外后端服务。

今早，DeepSeek-TUI更新了0.8.13新版本，聚焦运行时和TUI相关问题修复：

额外更新包括在压缩前对无LLM工具结果进行剪枝：在付费摘要处理之前，对旧的详细工具结果进行机械式摘要。重复读取保留最新的完整数据体，并将旧的副本替换为单行摘要；如果这样能使会话大小回到压缩阈值以下，则完全跳过LLM摘要调用。

重复工具防环保护装置：每个用户回合都会生成(tool_name,args)对参数。在第三次相同的调用时，它会插入一个合成的纠错工具结果，而不是再次运行相同的工具而不做任何更改；如果某个工具出现故障，则会在三次调用时发出警告，并在八次调用时停止。

V4缓存命中遥测兼容兜底适配：用量解析现已支持识别 usage.prompt_tokens_details.cached_tokens字段，因此底部状态栏现有的缓存命中标识组件，既能适配DeepSeek-V4自动前缀缓存的遥测数据，也能兼容旧版明确的缓存命中/未命中字段格式。

03.结语：想打造Claude Code平替，但稳定性存疑

Claude Code这样的专有系统通常需要付费API访问，且运行在较为封闭的生态系统中，而DeepSeek-TUI的出现或能为打破这种局面提供参考，依托DeepSeek的低成本模型堆栈，以更低成本提供类似的工作流程。但开发者仍然不能这类不稳定开源项目背后的风险。

不过，这一开源项目的爆火，无疑也从侧面印证了DeepSeek-V4的影响力，其为更多开发者提供了低成本搭建终端智能编程体、自主定制开发工作流的全新可能。

作者：程茜，编辑：李水青

来源：智东西

这两天把 Codex App 从头到尾跑了一遍，我原本只是想整理一篇保姆级教程。

但越用越觉得，这件事不只是教程问题。

AI 编程工具的竞争，已经不能只看谁更会写代码了。

Claude Code 当然很强。它在终端里非常顺手，能读项目、改文件、跑命令、接 MCP，也有权限控制、沙箱、子 agent、桌面端和 Web。对很多工程师来说，它就是一把很锋利的刀。

但 Codex App 给我的感觉不太一样。

它不是单纯把刀磨得更快，而是把砧板、刀架、备菜区、出菜口都摆好了。

你拿到的不只是一个会写代码的 AI，而是一套能让 AI 被安排、被约束、被审查、被交付的工作台。

我觉得这才是 Codex 最值得聊的地方。

沙箱：先把边界画出来

很多人用 AI 写代码，真正怕的不是它写不出来。

怕的是它太能干。

你让它改一个小需求，它顺手动了好几个文件；你让它跑一下测试，它想联网装依赖；你让它整理项目，它可能碰到你根本没打算让它碰的目录。

嘴上说“交给 AI”，身体却很诚实，一直在旁边盯着。

因为你不只是在看它会不会写代码。

你是在看它会不会越界。

Codex App 让我眼前一亮的第一点，就是它的权限控制是围绕沙箱展开的。它会把当前项目文件夹作为一个沙箱来管理。默认情况下，Codex 可以直接读写沙箱内的文件，不会每改一个文件都跑来问你。

这点很重要。

如果 AI 在项目文件夹里正常开发，每一步都要你确认，那最后用户很快就会变成权限弹窗管理员。

但 Codex 又不是完全放开。默认情况下，它不能修改沙箱外的文件，也不能联网。需要访问项目外目录、下载依赖、执行更高权限操作时，它会发起提权申请，也就是 escalate。

这套机制最舒服的地方在于，它不是让你审每一步，而是先把边界画出来。

边界内，AI 自己干。

边界外，停下来问你。

这就把“过程监督”变成了“边界监督”。前者很累，你要一直盯着它下一步想干嘛；后者轻很多，你只需要知道它在哪个盒子里工作，以及什么时候想跑出盒子。

我自己比较推荐自动审查模式。低风险提权自动放行，高风险操作再让人确认。日常用下来，它在安全和效率之间的平衡感比较好。

这也是我觉得 Codex 和 Claude Code 体验差异最大的地方之一。

不是说 Claude Code 没有安全机制。Claude Code 也有权限控制、沙箱配置、allow/ask/deny 规则，这些能力都很强。

但 Codex 把沙箱放在了整个产品体验的底层。你从打开项目开始，工作区、权限、审批、联网、上下文都围绕这个沙箱运行。

它不是一个“高级设置里的安全选项”。

它是你敢不敢放手的前提。

它不是聊天框，而是任务列表

Codex App 的三栏布局，看起来很朴素，但我越用越觉得它抓住了一个关键点。

左侧是任务列表，中间是对话窗口，右侧是多功能区域。

你可以在不同项目里开多个任务，也可以在同一个项目里开多个对话。我测试的时候，同时开了三个任务：一个项目做 HTML 单页宠物洗护店网页，一个项目做 React 待办事项工具，另一个对话单独问 React 框架问题。

三个任务一起跑，左侧能看到状态。有的正在执行，有的等待批准，有的已经完成。

这不是简单的界面好看。

它意味着 Codex 没有把 AI agent 当成一个聊天窗口，而是当成一组可以管理的工作任务。

以前我们用 AI 编程，经常是“我和模型聊一个问题”。到了 Codex 这里，更像是“我在调度几个 agent 干活”。

这个变化对产品经理、小团队负责人、内容团队会很友好。

他们未必天天待在终端里，也未必想通过一堆命令管理任务状态。他们需要的是一个能看懂、能切换、能接管的工作台。

Codex App 在这点上比传统 CLI 工具更像产品。

Plan 和 Steer，让 AI 别一路跑偏

复杂任务最怕 AI 一上来就开干。

比如你让 Codex 把一个项目改造成 Next.js。如果它直接动手，路线很容易跟你想的不一样。

Plan 模式就是为这种任务准备的。开启以后，Codex 不会马上改代码，而是先给你一份计划。它还会用问题卡片跟你对齐一些关键选择，比如用 App Router 还是别的形态，样式要不要迁到 Tailwind，要不要同时启动本地开发服务器验证。

计划确认后再动手，返工风险会小很多。

Steer 则是另一个很实用的功能。

我测试门店地图时，本来希望 Codex 调用 AI 生图能力，生成一张可爱风格的地图。结果它一开始用 SVG 画了一个很粗糙的示意图。

这种时候，最好的办法不是等它全部做完再返工，而是在执行过程中直接接管方向盘。

我截图告诉它，这图不行，应该调用 AI 绘图能力。Codex 被引导后，很快改用生图方式重新生成，并替换到了网页里。

Plan 是开工前把方向对齐。

Steer 是跑偏时接管方向盘。

这两个功能放在一起，Codex 就不只是一个执行器，而是一个可以被管理的协作者。

AI agent 最麻烦的地方，有时候不是不会干活，而是它会沿着错误方向越干越认真。Codex 至少给了你两个刹车点。

Git、回滚和 Worktree，解决“干完怎么收场”

AI 编程真正进入生产流程后，最关键的问题不是“它能不能写”，而是“写完以后怎么收场”。

我测试的时候，让 Codex 在宠物洗护页面里新增“期望到店时间”字段。做完以后，用 Git 提交保存。后来我又让它调整字段位置，结果看起来更别扭，想当作无事发生。

这时候只回滚对话是不够的，因为代码已经变了。

Codex 的对话分叉可以回到某个对话节点，再配合 Git 把代码回退到对应提交。这样一次不满意的改动，就能从对话历史和代码状态两个层面一起撤回。

这件事很重要。

AI 做得越多，回滚能力就越重要。用户如果不敢撤回，就不敢试错；不敢试错，就不敢让 AI 多做。

Worktree 更进一步。

我创建了两个独立工作树：一个优化客户评价模块，一个优化门店信息布局。两个分支在不同文件夹里并行开发，互不干扰，完成后再合并回主干。

这其实就是给不同 agent 分配独立工位。

以前说多 agent，很多时候只是多开几个聊天窗口。但真正的问题是：多个 agent 同时改代码，现场会不会被污染？做完以后怎么合并？做坏了怎么丢弃？

Worktree 给了一个工程化答案。

每个任务有自己的工作区。做成了就合并，做坏了就移除。

这也是 Codex 更像工程工作台的地方。它不只关心生成，还关心隔离、审查、合并和回滚。

Cloud、插件、Skills、MCP，让 Codex 开始像平台

如果只看本地开发，Codex 已经挺完整了。

但它更大的想象力，是把 AI agent 变成一个可以连接外部世界的平台。

Cloud 模式就是一个例子。

把代码同步到 GitHub 后，Codex 可以在云端运行任务。比如我让它把首页的“期望到店日期”默认设置成明天早晨 9:30，它会初始化云端环境，拉取 GitHub 代码，完成修改，然后创建 Pull Request。

你可以在 GitHub 上审查代码，确认后合并，再同步回本地。

这意味着你不一定非得坐在电脑前才能让 agent 干活。出门在外，用手机审批一下，云端任务也能继续往前推进。

后面还有 agents.md、插件、Skills 和 MCP。

agents.md 解决项目记忆问题。复杂项目里，每次新对话都重新交代背景很低效。把项目规则、作者偏好、技术栈、注意事项写进去，Codex 新开对话时就能自动读取。

插件解决外部服务连接。比如 GitHub、Gmail、Netlify。

Skills 解决专业工作流封装。你可以调用 Remotion skill 做动画，也可以安装网页 PPT skill，把文案生成适合演讲的页面。甚至可以用 Skill Creator，把“视频字幕转图文教程”这种重复工作封装成自己的 skill。

MCP 则把外部工具变成标准化接口。比如通过 Supabase MCP，让 Codex 创建预约业务表，改后端接口，再把表单数据写进数据库。

这些能力叠在一起，Codex 就不只是代码助手了。

它开始像一个 agent 工作平台。

能写代码，能接插件，能固化工作流，能连数据库，能部署网站，能跑自动化，甚至在 Mac 上还能通过 Computer Use 操作电脑。

这才是 Codex 值得重视的地方。

它不是只在增强“写代码”这一个动作。

它是在把 AI agent 干活所需要的环境，一点点收进同一个产品里。

所以，Codex 强在哪？

如果只看模型能力，Codex 和 Claude Code 的差距未必总是很明显。

真正的差异在产品形态。

Claude Code 更像给工程师的一把锋利工具。它贴近终端，配置空间大，适合熟悉命令行、权限、脚本和工程自动化的人。

Codex 更像一个可控工程工作台。它把沙箱、权限、任务、计划、引导、浏览器验证、Git、Worktree、Cloud PR、插件、Skills、MCP 和自动化放进同一个体验里。

这让它对更广泛的用户更友好。

尤其是产品经理、创业者、小团队负责人、内容团队、运营团队。这些人不一定想成为终端专家，但他们确实想把一块工作交给 AI，并且希望自己看得懂它做了什么、知道它有没有越界、确认结果能不能合并。

过去评价 AI 编程工具，我们常问：

• 它会不会写？
• 它写得对不对？
• 它能不能跑通？

现在我会多问几句：

• 它在哪里写？
• 它越界时会不会停？
• 它写完以后，能不能被团队接住？

这才是 Codex 让我眼前一亮的地方。

它不是简单多了几个功能。

它是在告诉用户：你可以把 AI 放出去干活，但不必把整台电脑、整个项目、全部判断权都交出去。

未来真正重要的 AI 编程产品，可能不是那个最会写代码的 agent。

而是那个最能让人放心把工作交出去的系统。

前几天，OpenAI 正式发布了全新的大模型 GPT-5.4-Cyber。和很多网友的感受一样，这个模型也给我们带来了一种极其强烈的既视感。

这款新模型在目标用户群、应用场景甚至宣发策略上，几乎完全对标了 Anthropic 前些天发布的 Claude Mythos。这种「贴身肉搏」的态势已经到了毫不掩饰的地步。就连《纽约时报》都在最新的报道标题中一针见血地指出：「与 Anthropic 一样，OpenAI……」。

这种同质化的趋势绝不仅仅停留在最底层的基座模型上。如果你把目光投向这两家公司近期发布的一系列产品，你会发现它们正在成为彼此的镜像！

在资本市场的无影灯下，这种趋同更加明显。目前两家公司在二级市场上的估值咬得非常紧，Anthropic 甚至在近期凭借其在企业级市场的狂飙突进，价格略高于 OpenAI。资本的嗅觉最为灵敏，在他们眼中，这两只独角兽正在长出相同的犄角。

看起来，底层大模型的同质化必然会导致上层应用的趋同。

今天，我想和大家探讨的，正是代表着当今 AI 辅助编程最高水平的两个标杆工具： OpenAI 的Codex和 Anthropic 的Claude Code。从曾经的分道扬镳，到如今的殊途同归，它们是如何一步步长成了同一副模样的？

从分道扬镳到殊途同归：双雄的演进史

把时间拨回几年以前，Codex 和 Claude Code 完全是两种不同技术哲学的产物。

Codex 的底层逻辑是「天下武功唯快不破」。它就像是一个跟在你身后、随时准备补全代码的 5 年经验高级开发。

在 OpenAI 的构想中，Codex 是一个轻量级、高互动的终端智能体，它主打快速迭代和交互式编程。它的执行速度极快，在 Cerebras WSE-3 硬件的加持下，能够达到每秒 1000 个 token 的吞吐量。在具体的工作流中，Codex 提供建议、自动编辑和全自动三种明确的审批模式，让开发者始终保持在循环之内。这种设计思路非常符合那些需要快速构建原型、处理高频交互的极客开发者。

反观 Claude Code，它从诞生之初就自带一种高冷且克制的「架构师」属性。

Anthropic 为它注入了处理极端复杂任务的基因。它依赖高达 100 万 token 的庞大上下文窗口，以及独特的「压缩」技术来实现无限对话。Claude Code 的信条是「全局掌控，谋定而后动」。在执行任何动作之前，它会先使用智能体搜索技术吃透整个代码库的脉络，然后协调多文件进行一致性修改。对于那些涉及数万行代码迁移的企业级重构任务，Claude Code 展现出了惊人的统治力。

然而，随着时间的推移以及应用场景的不断下探，这两个原本性格迥异的工具，开始互相抄作业。

图源：MorphLLM

在处理复杂项目时，单体 AI 模型面临的最大瓶颈就是上下文污染。你让 AI 重构鉴权模块，它读了 40 个文件之后，往往就忘记了第一个文件的设计模式。为了解决这个痛点，两家公司给出了几乎一模一样的答案：为每个子任务分配独立的上下文窗口。

OpenAI 很快推出了全新的 macOS 桌面端应用，将任务按项目隔离在不同的线程中，并在云端沙盒里独立运行。Anthropic 则推出了智能体团队架构，允许开发者派生出多个子智能体，它们共享任务列表和依赖关系，并在各自的独立窗口中并行工作。你会发现，无论是叫「云端沙盒」还是叫「智能体团队」，它们在工程实现上的核心理念已经完全重合。

在基准测试的成绩单上，它们也呈现出一种微妙的平衡。GPT-5.3-Codex 在终端任务 Terminal-Bench 2.0 中以 77.3% 的得分领先。Claude Code 则在复杂的 SWE-bench Verified 榜单上拿下了 80.8% 的成绩。它们都在自己的优势区间里做到了极致，同时又在拼命弥补自身的短板。

OpenClaw 效应：推倒高墙的无形之手

如果说两家公司的内部战略决定了它们走向同质化的内因，那么整个开源生态的倒逼则是不可忽视的外力。在这里，我们必须要提到 OpenClaw 给整个 AI 编程工具赛道带来的深远影响。

作为开源社区推出的工作流框架，OpenClaw 的出现可以说是推倒了巨头们辛苦建立的生态高墙。它将大模型与本地终端工具链的交互过程进行了标准化。过去，如何让大模型优雅地调用本地 Git 提交、如何安全地在沙盒中运行测试脚本、如何进行多步推理验证，这些都是 Codex 和 Claude Code 各自引以为傲的专有「黑科技」。

但 OpenClaw 将这些流程抽象成了通用的协议。这意味着，开发者不再需要为了某一种特定的协同模式而被绑定在特定的平台上。开源社区的狂欢让标准化成为了不可逆转的洪流。面对这种情况，无论是 OpenAI 还是 Anthropic，都不得不放低姿态去兼容这种开放的标准。

当底层的技术壁垒被 OpenClaw 这种开源力量拉平，当所有的高级特性都成为了行业的标准配置，Codex 和 Claude Code 唯一的出路，就是在更细微的用户体验层面进行无止境的内卷。这也是为什么我们会觉得它们越来越像，因为在标准化的框架下，最优解往往只有一个 —— 就像是生物的趋同演化。

Codex 正在追赶 Claude Code

虽然 Claude Code 与 Codex 正在趋同演化的道路上，但两者的差异依然存在，甚至 Codex 在某些方面已经更受开发者青睐。

前两天，在 r/ClaudeCode 社区，一位拥有 14 年经验、曾在科技巨头工作的高级工程师 u/Canamerican726 分享了一份极其硬核的测评。

具体而言，他在一个包含 8 万行代码的复杂项目中，分别投入 100 小时使用 Claude Code 和 20 小时使用 Codex。

在他的视角里，使用 Claude Code 就像在指导一个被截止日期追赶的工程师，它冲刺速度极快，却经常会无视开发者在 CLAUDE.md 中写下的规范，并且喜欢在现有文件里不断堆砌代码来完成任务，缺乏重构思维。

相比之下， Codex 给他的感觉更像是一个拥有 5 到 6 年经验的沉稳老手。它的处理速度虽然要慢上 3 到 4 倍，但会在中途主动停下来思考并重构代码，并且严格遵守指令边界。这种高度的自主性，让这位工程师敢于把任务直接扔给它，然后放心地去做其他事情。

同样的声音也出现在 X 等社交网络上。研究员 Aran Komatsuzaki 结合自己的使用体验提到，在前端领域 Claude Code 依然占优，但在后端规划和保持信息更新方面，高频调用网络搜索的 Codex 显然更加扎实。

评论区里充满了真实业务场景下的血泪总结。有开发者极其犀利地指出，基于 Opus 的模型虽然跑得快，但往往会给项目积攒下大量的「代码清洁债务」，Codex 动作慢，却能在前行的同时顺手把地扫干净。我甚至看到有用户总结出了一条生存法则，建议大家在上下文窗口的使用率达到 70% 时立刻开启新会话，否则极其容易收到系统附赠的隐蔽 bug。

这些来自一线的真实吐槽清晰地表明，当两大神器的能力面板越来越重合时，决定开发者最终阵营归属的，往往就是这些关乎「填坑成本」和「维护心智」的微小体验差距，当然对于中国用户还有一些特殊的困难，比如：

冷思考：同质化背后的生态暗战

当然，Codex 和 Claude Code 和优劣还在于各位开发者自己，也要看开发者自身的能力，正如上述 u/Canamerican726 的评测报告总结的那样：如果你不懂软件工程，这两个工具都会输出糟糕的结果，工具并不等同于技能。

这句话戳破了 AI 编程工具长期以来营造的某种幻觉。我们曾经以为，只要有足够强大的 AI 助手，哪怕是没有任何基础的 Vobe Coder 也能单枪匹马打造出企业级应用。但现实是，Claude Code 需要一个极其专注且技能过硬的「驾驶员」，否则它很容易在庞大的代码库中迷失方向。Codex 虽然更加独立，但它同样需要开发者提供精准的系统上下文才能发挥最大效用。

那么，在工具能力高度同质化的今天，这两家公司的护城河究竟转移到了哪里？

答案藏在那些枯燥的财务报表和定价策略里。在相同的任务下，Claude Code 消耗的 token 数量往往是 Codex 的 3 到 4 倍。使用成本更高。对于企业团队来说，使用 Claude Code 每个月需要为每位开发者支付 100 到 200 美元的费用。而 Codex 则将其能力打包进了价格更为亲民的订阅计划中，并且通过庞大的 GitHub 社区积攒了大量基础用户。

图源：MorphLLM

Anthropic 的野心在于将 Claude Code 深度嵌入到那些不缺钱的科技巨头的工作流中。比如 Stripe 就让 1370 名工程师使用 Claude Code，在 4 天内完成了一项原本需要 10 个人工作数周的跨语言代码迁移。Ramp 公司更是依靠它将事件响应时间缩短了 80%。OpenAI 则依靠其无孔不入的生态渗透率，让 Codex 成为了许多普通开发者的默认选择。

这不再是一场单纯的技术竞赛，而是一场关于生态绑定、定价策略以及用户习惯重塑的消耗战。

开发者的十字路口

回望这一年来的技术演进，GPT-5.4-Cyber 的发布只是这场漫长战役中的一个微小注脚。Codex 和 Claude Code 正在走向「同一张面孔」，标志着 AI 编程工具从早期充满变数和猎奇色彩的测试阶段，正式迈入了成熟且乏味的工业化生产阶段。

现在，Claude Code 每天会自动生成 13.5 万次 GitHub 提交，这个数字已经占到了全网公开提交量的 4%。我们可以预见，在不久的将来，大部分的样板代码、基础测试用例以及常规的代码重构，都会由这些长得越来越像的 AI 智能体在后台默默完成。

图源：MorphLLM & SemiAnalysis / GitHub Search API

面对两个在能力上无限趋近、在体验上相互模仿的超级工具，我们作为人类开发者的核心价值还剩下什么？或许，工具红利期即将彻底结束。当每个人手中都握着同样锋利的武器时，真正决定胜负的，将不再是谁拥有更好的代码补全速度，而是谁能更好地定义问题、谁拥有更宏大的系统架构视野，以及谁能在这个被 AI 填满的代码世界里，找到那份属于人类独有的不可替代性。

话说回来，你选哪个？

作者：机器之心

来源：机器之心

来不及解释了，

Claude Code又被大漏勺，说是要更新网页自动截图，代码扫描，一次性设计多种风格，还能把好几个代码仓库合到一个界面里统一管理，这波Cursor都汗流浃背了。

我要抢在这些上线前，先把前段时间的更新都消化了。上周在线下黑客松跟人聊的时候就发现有的人已经把CC内置的命令玩出花来了，

分支对话/btw，双击esc回退被改坏的代码，还有新内置在CC里的交互课程/powerup随便用。

极与极，有的人还在一步步按确认。

你也可以试试看随机考朋友一个基础点的，知不知道Claude Code更新了Auto Mode（自动模式）。

上线三周了，还在用claude –dangerously-skip-permissions的朋友可以都切换成claude –permission-mode auto了，不至于闭着眼把权限全批了，执行到高风险动作还是提醒的。

还有个省token的小技巧，比起我们复制黏贴大段大段文字，直接给CC发文件目录让它用grep获取上下文会更省钱，等等等等。

所以我一口气整理了这段时间觉得最有用的十个命令和技巧，全分享出来。提示语们也整理到文档了，回复CC就好了。

Here we go！

01 /powerup 

我们先从获得感比较高的命令开始，

这些命令不需要去装Skill，去做额外的配置，因为它们就是内置在原生的Claude Code里，随时可以用。

/powerup就相当于Claude Code版的多邻国，它一共分十关，每一关都会教你几个核心技巧，从怎么和代码库（项目）对话，怎么撤销操作，到怎么把任务放后台运行，怎么让CC记住你的偏好，甚至于怎么制作子Agent，怎么用手机远程控制等等。

说白了，就是Anthropic帮我们划好了重点。与其去看零散的教程，不妨先把这十关打通。

02 /btw 

这个命令是我用的最高频的一个，

/btw，就是by the way（顺便说一句）的缩写。

想象一下，你正让Claude Code写一个复杂的项目，对话已经进行了几十轮，上下文窗口快到200k了。这时候，突然想确认一个细节，

比如，它现在写的这段，是不是按了我们上次定好的开发日志走的？

如果你选择直接在当前对话里问，这样会污染整个上下文，影响模型开发。那如果新开一个窗口，就会丢失了当前的上下文，模型一秒失忆。

/btw解决了这个问题，比方说我可以，/btw 刚刚提交的版本里面有加上readme吗？因为后面会做成公开项目

回答这个临时问题的同时，CC也不会暂停手里的主线任务。当我们确认完，按一下回车，这段临时的对话就会消失。而且/btw复用了当前的提示缓存，提问几乎不消耗token。

03 双击ESC

谁说AI界没有后悔药的，/rewind就是，不过我更习惯双击ESC，这样我们会看到一个菜单，可以选择只回退改坏的代码，还是连对话一起回退。

只回退代码的话，CC就会记得刚才的代码尝试是失败的，这样我们就不需要重新提一遍需求，完全可以直接说，

OK，我们来尝试下一个方向。

 04/05 Hook 和 /insight 

这个顺序其实我纠结了一会，到底要不要把Hook（钩子）和 /insight 放一起。

/insight会生成一份过去一个月我使用Claude Code的习惯报告。这份HTML报告里会反映出你最常用的命令是什么，哪些操作模式是高度重复的。它还会推荐一些可以自定义的命令或者现成的Skill。

我就发现Claude Code有时候会修改太多文件，我还可以把常见的TypeScript工作流打包成新Skills。

如果说/insight是主动触发的话，那Hook就是被动触发的。我不需要去记隔个月运行一下/insight，Hook就是在我们有特定的明确的事件触发时，自动执行某个操作。

我常用的就有两个比较实用的Hook，

一个是当一次对话里工具调用次数大于 8 次时，就让CC输出优化建议，让它来教我把刚刚的一连串操作沉淀成Skill。

如果你想先适应适应这个Hook的话，可以让它先在项目（也就是当前的文件夹）里生效，后面再把它拓展成为全局。

我刚开始还有一个坏习惯，就是在对话开始时，扔给它一大段零散，未经思考的需求，说白了就是语音输入一大段文本。很多时候AI理解偏差，一来一回浪费了我时间。所以我做了另一个Hook，

如果我单次输入的文本超过200个token，就启动Plan模式。先引导我把这个长需求确认好，结构化，拆解成清晰的步骤，再开始动手开发。

也不用担心设置hook的时候表达不清晰，CC会进一步细化，给出优化建议。

Hook省了我大量的心力。

我不需要费脑子去想，这个操作是不是值得做一个Skill，也不担心一是不是开始的需求没想清楚，导致后面返工。

我们可以利用hook的这个特点，去做很多有意思的自动化。我就还有一个Hook，每次准备git提交开源的时候，都会触发一个动作，把所有commit信息写到一个可视化的网页上，等我预览确认没问题后，再真正提交。

这样就不担心因为模型抽风，把项目里的说明文件写得一团糟了。

06 /loop 

这个命令很简单，就是让Claude Code定时重复执行某个任务。

比方我刚刚开源了一个新Skill，我一个人用可能没啥bug，但用的人多就容易出新问题。所以我用/loop来定时看看只要有人提bug，就自动修复并提交，用的话就是在任务前加一个loop和时间间隔就可以了，

/loop 24h 检查一下这个项目（github.com/LearnPrompt/ai-news-radar）有没有人提交Issue或是PR，有的话自动修复后更新项目

CC会每隔24小时检查一次状态。

loop的好处就是轻量，七天后这个任务就会自动过期并删除，不会一直占用本地资源。如果需要一个长期运行的任务，可以用schedule在云端运行的，只要不取消就一直会跑。

07 Ralph Wiggum插件 

同样是循环，Ralph Wiggum（我们就简称为Ralph吧）就是一个有停止条件的单一任务循环。

如果我想要长时间运行同一个任务，但是这个任务又可能不是一次运行就能成功的，

Ralph就能在我睡觉期间用满我的模型额度，比方说重构一个项目的UI，我常用的就是给这个任务设置最多循环10-15次，然后让CC自己给自己出一个验收标准，

08 求助Codex 

Opus 4.6最近降智有点严重，

所以我在Claude Code里用Codex的频率也升高了，OpenAI开源的这个codex-plugin-cc内置了/codex:review，用人话来说就是可以把现在的工作进度丢给Codex做代码审查。

 https://github.com/openai/codex-plugin-cc

而且当时一出来的时候，我就觉得，既然能够发给Codex做代码检查，那我为什么不能把它当作为一个在Claude Code里随时随地调用Codex完成其他任务的入口呢？

所以我直接原汤化原食，

让Codex自己在项目里面新增了一个叫Codex Ask的功能，这样我可以把开发任务全部给Claude Code做，到了写开发计划，或者是文本写作的时候，还可以用到 GPT 5.4 high。

PS：也可以不用改，把/codex:rescue当通用Agent用

这一步，我其实还做了一个让它们记忆共享的Skill，在后面的文章里面会开源出来。

09 –add-dir和-c 

OK啊，当你把上面这几个命令都玩熟了，再配上几个从/insight里学到的Skill，

我可以保证，你已经比很多人用得溜了。

但我们还可以再讲究点。接下来的这几个参数，不是命令，是在我们开启一段新对话时，就能用上的开场白，就像游戏开局时，你可以选择的几个被动技能，选对了会省很多时间。

-c就是continue，

如果不小心把终端关了，或者电脑没电，总之就是各种各样的意外，导致你这次的对话突然中断的话，我们都可以加-c恢复。最近一次的对话记录，像游戏读档一样。

接下来，也是我开头提到的，省token小妙招，这个参数叫–add-dir。

比方说，我们在A文件夹里写代码做知识管理，但同时，我又需要参考我电脑另一个角落里，Obsidian文件夹里的一些个人笔记和设计规范。

那我只要在启动的时候，用–add-dir参数把Obsidian的路径加进来。这样CC就能直接读取那个文件夹里的所有内容，我不需要再复制粘贴任何文本，它就能理解我的所有黑话和个人习惯。

10 Sub-agent 与 Agent Teams

前面九个技巧，都是在让你用主Agent的时候变得更强。第十个，也是最后一个技巧，我就要拿出多Agent了。

可能很多人一听到这个词就头大，会觉得要新设置很多东西，会影响主Agent的表现之类的。实际上Claude Code已经把入门的门槛降得很低了。

我们先说简单的，Sub-agent（子智能体）。

你可以把它理解成一个临时工。有些任务，比如去网上搜资料，或者去翻几十个日志文件，直接在当前对话里提问的话会产生大量没用的中间过程，把主对话上下文搞得乱七八糟。

这时候就可以派subagent去干。它会在自己的工作空间里，默默地完成这些脏活累活，最后把一个干净整洁的摘要报告，交回到你的主对话里。

我们只需要先用/agents命令，就可以用大白话，创建一个自己的子代理，比方说，

创建一个灵感Agent，它会扫描当前开发项目，使用superbrainstrom skill和office hour skill，给出新角度建议。

创建的过程很简单，CC会问你要用什么样的模型去驱动，然后它是一个只读Agent，还是执行Agent，是把所有的Tools都开放给它用，还是只开放一部分。

BTW，superbrainstrom和 YC总裁开源的office hour都是两个跟头脑风暴相关的Skill，非常互补，都是我比较推荐的Skills。

 github.com/obra/superpowers/tree/main

 github.com/garrytan/gstack/tree/main

Agent Teams把分工玩法带到了一个新高度。

不再是主Agent和临时工的关系，是一个真正的多Agent团队。我们可以一次性创建多个不同角色的Agent，让它们并行地，从不同角度去解决一个复杂问题。我有一个新产品的想法，就可以这样说，

我正在设计一个 CLI 工具，帮助开发者追踪整个代码库里的TODO。组建一个 Agent 团队，从不同角度来探索这个方向：一个成员负责用户体验，一个成员负责技术架构，另一个成员专门负责挑刺。

然后，我就啥都不用干，围观一场头脑风暴。这三个Agent会开始互相讨论，分享发现，甚至会给对方的观点挑毛病。

我们还可以像项目经理一样去管理这个团队，比如提前结束某个队友的对话，二次分配新的任务，或者让它们先出方案，等你批准了再执行。

这种多 Agent 协作会比单 Agent 更适合复杂任务，因为它能降低模型一条路走到黑的概率，也能在早期就发现问题。

好了，十个技巧，全部分享完了。

我知道，这时候肯定会有朋友觉得记这些太麻烦了，不如直接去GitHub上，把Everything Claude Code那个超级大合集项目，一把梭哈，156个Skill，48个Agent，72个Command全装上。

真的真的真的千万别这么干。

全装，意味着你的Claude Code会突然多了几百个你根本不了解的文件。可能连hook的用法都还没摸熟，就直接复用了别人的工作流。结果发现，别人用的我们平时根本用不上。

其实就是给模型增加了记忆负担。

我的建议是，

如果你是刚开始用Claude Code，那什么都别装。先用，用上了就会有痛点。痛点就是你最需要配置的第一条规则，第一个Skill。

如果你已经有了自己的工作流，想参考一下别人的配置。那就从那些大合集里，选适合你的。比如，通用的规则，会话保存的模板，最常用的Skill，就够了。

毕竟在AI加持之下，产品的进化速度太快太快了。

我现在已经用Codex设置了一个长期定时任务帮我每天去监控Claude Code的更新日志了，

这些就等我之后玩熟了再来继续分享。

睡了睡了（其实是熬穿了），

希望起来Claude没有更新。

每天在飞书里写文档、做协作，在 Obsidian 里沉淀笔记、构建知识图谱。两个平台之间一直隔着一道墙——现在，可以让 AI 自己把墙拆了。

一、AI 产品经理的知识焦虑

做 AI 产品经理有一个很实际的痛点：知识散落在太多地方了。

飞书是团队协作的主战场——PRD、会议纪要、竞品分析、项目文档，全在上面。但飞书的文档更像是”流水”，适合协作，不适合沉淀。你很难在飞书里回溯半年前的某个灵感，也很难把散落在不同知识库里的内容串联成知识图谱。

Obsidian 恰好相反。它是个人知识管理的利器，双向链接、标签体系、图谱视图，天然适合做深度的知识沉淀和关联。但它是本地工具，不擅长协作。

所以日常工作就变成了一个尴尬的循环：白天在飞书里产出文档 → 想要沉淀到 Obsidian → 需要手动一个个下载 → 格式还得重新整理 → 图片得单独保存 → 表格排版全乱了 → 算了，改天再说吧。

“改天再说”说了半年，知识库依然是两个互不相通的孤岛。

直到最近，我在折腾飞书 CLI 的时候，偶然发现了一条全新的路。

二、为什么飞书 CLI 是打通这一切的关键

在聊具体怎么做之前，得先说一个让我眼前一亮的东西：飞书开源的 CLI 工具。

CLI 是什么？30 秒讲清楚

你平时打开飞书 App，看到的界面——按钮、菜单、拖拽——这叫图形界面（GUI）。你得用眼睛看、用手去点，一步一步操作。

CLI 是另一种操作方式：你在一个黑色窗口里敲一行文字命令，电脑直接执行。 没有按钮，没有菜单，一行指令解决一个问题。

打个比方：GUI 像是你走到餐厅前台，看着菜单一道一道点；CLI 像是你直接给后厨发了一张纸条——”宫保鸡丁一份，少辣”——菜就做出来了。

对人类来说，GUI 显然更友好。但对 AI 来说，情况完全反过来——AI 根本不会“看”按钮和“点”菜单，它天生就是靠文字指令工作的。 CLI 就是 AI 操控软件的天然接口。

飞书 CLI 意味着什么

飞书把自己的 CLI 开源了，覆盖了日历、消息、文档、多维表格、邮件、会议等几乎所有功能，提供了 200 多个命令。

这意味着：你可以让 AI 通过终端，直接对飞书下指令——查日程、发消息、读文档、建表格，全部用文字命令完成，不需要打开飞书 App 点任何按钮。

而且飞书 CLI 专门为 AI 场景做了一层封装，提供了 19 个”AI Skills”。装上之后，你甚至不需要知道具体命令是什么。你用中文告诉 Claude”帮我看看今天有什么会”，Claude 会自动选择对应的 CLI 命令去执行。你负责说人话，AI 负责翻译成机器能懂的指令。

这件事的意义，后面会越来越清楚——正是因为有了这个 CLI，我才能让 Claude 直接把飞书知识库的文档批量爬到本地。

三、从零开始：安装配置全流程

下面是我实际走过一遍的完整安装流程，踩过的坑也一并标出来了。

环境准备

唯一的前置要求是电脑上有 Node.js。如果还没装，去Node.js官网下载LTS版本，安装过程一路默认即可。

安装三件套

打开终端（Mac 用 Terminal，Windows 用 PowerShell），依次执行三条命令：

① 安装 Claude Code，在终端输入：

npm install -g @anthropic-ai/claude-code

② 安装飞书 CLI，输入：

npm install -g @larksuite/cli

③ 安装 AI Skills（给 Claude 装上飞书“技能包”）

npx skills add larksuite/cli -y -g

第三步容易被忽略，但非常关键。没有这些 Skills，Claude 不知道飞书 CLI 有哪些命令可用，等于给了它一把钥匙但没告诉它锁在哪。

踩坑提醒：如果安装过程报网络错误，大概率是 npm 源的问题。执行 npm config set registry https://registry.npmmirror.com 切换到国内镜像后重试。

创建飞书应用

接下来需要在飞书开放平台创建一个”应用”——可以理解为给 AI 在飞书里注册了一个身份，后续所有操作都通过这个身份执行。

lark-cli config init –new

终端会弹出一个链接，打开后按提示创建应用：起个名字、选个头像、确认。创建完成后回到终端，配置会自动同步。

授权登录

lark-cli auth login –recommend

–recommend 会自动勾选常用权限，省得你逐个选。终端输出授权链接，打开后用飞书扫码完成授权。验证是否成功：

lark-cli auth status

能看到你的用户名和权限状态就说明全部就绪。

踩坑提醒：企业飞书用户可能会遇到”应用审批中”的提示，需要等管理员审批通过才能继续。个人版飞书一般没有这个问题。

最重要的一步：重启 Claude Code

安装完上面所有东西后，必须重启 Claude Code。不重启的话，Claude 感知不到新装的 Skills，你跟它说什么飞书相关的指令它都会一脸懵。

重启之后，直接用中文下达任务就可以了：

“帮我创建一下待办事项”

“给XXX发一条消息：中午吃什么”

“帮我创建一个多维表格，标题叫项目进度表”

Claude 会自动把你的自然语言翻译成飞书CLI 命令，执行前会让你确认一下——点”同意”就完事了。到这一步，飞书的”控制台”就算正式交给 AI 了。

四、进阶玩法：让 Claude 直接爬取飞书知识库

安装完成后，基本的日程查询、消息发送、文档创建都不在话下。但让我真正兴奋的，是接下来这个发现。

第一次尝试：翻车现场

我脑子里突然冒出一个想法：既然 Claude 可以通过CLI 操控飞书，那能不能直接让它把整个知识库的文档爬下来？

说干就干。我给了一个简单粗暴的指令：”帮我把飞书知识库的文档都下载下来”。

几分钟后，80 多个 .md 文件哗啦啦出现在我的本地文件夹里。

打开一看——一团乱麻。

所有文件平铺在同一个目录下，没有任何层级结构。文档里的图片全部丢失，只剩下空的引用链接。飞书里排版整齐的表格，变成了一堆无法解析的HTML标签。

踩坑复盘：三个关键问题

冷静下来分析，我意识到三个问题：

问题一：结构丢失。 飞书知识库是有层级的——知识库 → 父文档 → 子文档，但直接爬取会把所有文件拍平，丢失目录关系。而且 CLI 只能识别直属的知识库 ID，不会自动递归子文档。

问题二：图片不下载。 飞书文档里的图片是云端链接，导出 Markdown 时只保留了 URL 引用，不会自动下载图片到本地。一旦离开飞书环境，图片全部失效。

问题三：表格格式损坏。 飞书的表格导出后是 <lark-table> 自定义标签，不是标准的 Markdown 表格语法，需要额外转换。

解决方案：一个结构化的 Prompt

经过反复测试，我终于摸索出了一套完整的结构化 Prompt，能够一次性解决上面所有问题。这个 Prompt 你可以直接复制使用：

我想把飞书云文档按知识库分类批量下载到本地，要求如下：

1. 分类结构：按飞书知识库的层级结构（知识库→父文档→子文档）创建对应的文件夹，不要把所有文件平铺在一起

2. 表格处理：飞书导出的 <lark-table> 标签需转换为标准 Markdown 表格格式（| col | col |）

3. 图片处理：

– 有图片的文档，建一个以文档名命名的子文件夹，结构为 文档名/index.md + 文档名/images/

– 无图片的文档直接输出为 文档名.md

– 图片下载后替换 MD 中的引用为本地相对路径

4. 跳过规则：BITABLE（多维表格）和 SHEET（电子表格）类型跳过，只下载 DOCX/DOC 文档

5. 工具：使用 lark-cli，已安装并完成授权

6. 知识库范围：只下载以下知识库——[替换成你的知识库名称]

请先写脚本，支持 –space 参数指定单个知识库测试，确认效果后再全量下载。

效果：98 个文档，271 张图片，一键搞定

Claude 拿到这个 Prompt 后，先写了一个 feishu-download.py 脚本，支持 –space 参数指定单个知识库测试。我先拿”AI 健身教练-卡卡”这个知识库试水，确认效果没问题后，再全量下载。

最终结果：

• 成功下载 98 个文档
• 跳过 12 个（BITABLE/SHEET 类型）
• 下载图片 271 张
• 全部按知识库 + 层级归类，图片在各自文档文件夹内

整个过程大约 5 分钟，完全自动化，零手动操作。

这个过程中 Claude 的工作链路是这样的：首先通过飞书 API 批量获取所有文档的节点信息，然后用这些信息重建完整的目录树（208 个文档），接着按照目录结构创建文件夹、下载文档内容、转换表格格式、下载并替换图片引用。

五、更大的图景：飞书 × Obsidian 双向赋能

下载到本地只是第一步。真正让我觉得”这条路走对了”的，是想清楚了两个平台各自该放什么、怎么联动、以及如何避免内容重复。

首先要解决的问题：不是搬运，是”翻译”

很多人第一反应是”把飞书文档全部同步到 Obsidian”，但这样做只会制造两份一模一样的内容，维护成本翻倍，还不如不同步。

正确的思路是：飞书的内容到了 Obsidian，要经过一次“翻译”——从协作态转化为知识态。

什么意思？举个例子。一篇飞书上的”Q2 竞品分析报告”，里面有大量协作过程中的讨论痕迹、待办事项、@某某同事的备注。这些在飞书里是有用的上下文，但搬到 Obsidian 就变成了噪音。

Claude 可以帮你做这个翻译：提取核心结论和洞察，去掉协作噪音，重新组织成适合个人知识体系的结构，再补上 Obsidian 的 frontmatter 元数据（tags、category、related），让它能和你已有的知识网络产生链接。

两个平台的边界：什么该放哪里

经过实践，我摸索出了一个清晰的分工原则——飞书放“过程”，Obsidian 放“结果”。

只留在飞书的内容：

• 日常会议纪要（协作上下文强，离开团队就失去意义）
• 进行中的项目文档（需要多人实时编辑）
• 即时沟通和审批流（天然属于飞书的领地）
• 多维表格和数据看板（飞书的强项，Obsidian 做不了）

只留在 Obsidian 的内容：

• 个人方法论和思维框架（比如你对 AI Agent 架构的理解）
• 读书笔记、学习记录、灵感捕捉
• 长期积累的知识卡片（概念定义、原理解析）
• 每日日记和复盘

需要“翻译”后从飞书迁移到 Obsidian 的内容：

• 已结项的 PRD → 提炼成产品方法论笔记
• 竞品分析报告 → 提炼成行业洞察卡片
• 技术方案文档 → 提炼成架构知识笔记
• 复盘文档 → 提炼成经验教训清单

关键词是”提炼”而不是”复制”。Claude 帮你做的不是 Ctrl+C / Ctrl+V，而是把一篇 3000 字的项目文档浓缩成一张 500 字的知识卡片，同时自动关联到 Obsidian 里已有的相关笔记。

Claude 在中间做的三件事

第一件：入库时做清洗和提炼。 飞书文档批量下载后，让 Claude 逐篇阅读，去掉协作噪音，提取核心内容，补上 Obsidian 的 frontmatter（tags、category、related、status），统一格式。这一步把”飞书文档”转化成了”Obsidian 笔记”。

第二件：建立知识图谱关联。 Claude 可以通读你整个 vault，识别笔记之间的语义关联，自动添加双向链接。比如它发现”AI 健身教练 PRD”里提到了”用户留存策略”，而你的 vault 里恰好有一篇”留存指标体系”的笔记，它就会在两篇之间建立 [[]] 链接。时间一长，你的知识图谱会从散点变成网络。

第三件：反哺工作产出。 这是最容易被忽略的一步，也是真正的”双向赋能”。当你在 Obsidian 里积累了足够多的知识笔记后，下次用 Claude Code 写飞书文档时，可以让它先读取 Obsidian 的知识库。比如你要写一份新的 PRD，Claude 可以调取你之前沉淀的竞品洞察、用户画像方法论、技术架构笔记，产出的内容会比从零开始写专业得多。

这就形成了一个正循环：飞书产出 → Claude 提炼入 Obsidian → 知识积累 → Claude 调取写飞书 → 更高质量的产出 → 继续提炼……

避免重复的增量同步策略

日常使用中，不需要每次都全量下载。我建议的节奏是：

• 周频同步： 每周花 5 分钟，让 Claude 增量下载本周飞书新增或修改的文档。它会自动识别哪些是新内容，只处理增量部分。
• 同步后立即分流： 下载完不要直接扔进 Obsidian 的正式目录。先放到一个”收件箱”文件夹（，让 Claude 做一轮筛选——哪些值得提炼入库，哪些只是过程性文档不需要保留。
• 保留溯源链接： 每篇从飞书迁移过来的 Obsidian 笔记，在 frontmatter 里加一个 source 字段，记录原始飞书文档的链接。这样你既不需要在两边保留完整内容，又能随时溯源到飞书原文查看完整的协作上下文。
• 定期清理： 每月让 Claude 扫一遍 Obsidian vault，识别内容高度重复的笔记（比如同一份 PRD 被导入了两次），合并或删除冗余。

六、写在最后：AI 产品经理的工具观

这次折腾给我最大的启发不是某个具体的技术方案，而是一个思维方式的转变：

不是工具多就好，而是工具之间能不能用 AI 串起来。

过去我们评价一个工具好不好用，看的是它自身的功能有多强。但在 AI Agent 的时代，评价标准变了——一个工具好不好用，取决于它有没有给 AI 留接口。

飞书做对了一件事：它把 CLI 开源了，给 AI 留了一个”控制台”。这意味着飞书不再只是一个人类用的协作工具，它同时也是一个 AI 可以操控的基础设施。

这个趋势会越来越明显。未来的 SaaS 工具竞争，不只是比谁的 GUI 好看、功能多，更是比谁的 API 和 CLI 对 AI 更友好。因为在 AI Agent 的世界里，能被 AI 调用的工具，才是有生命力的工具。

对于 AI 产品经理来说，现在是一个非常好的时间点去建立自己的”AI + 工具链”工作流。不需要会写代码，你只需要学会和 AI 对话，告诉它你想要什么，剩下的交给它。

操作不懂的可以评论区提问～