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 对话，告诉它你想要什么，剩下的交给它。

操作不懂的可以评论区提问～

Claude Code 是 Anthropic 开源的 AI 编程助手，产品形态是一个跑在终端里的 CLI 工具。开发者在命令行里用自然语言告诉它想做什么，它就能直接读写文件、执行 Shell 命令、操作 Git、调用外部服务，把一个编程任务从头到尾干完。这不是又一个“代码补全插件”。它的野心更大——做一个终端原生的 AI 开发操作系统。

作为 AI 产品经理，理解 Claude Code 的架构设计有三层价值：

第一，它是目前工程成熟度最高的开源 AI Agent 实现之一，1902 个 TypeScript 文件，每一个架构决策都经过了真实产品场景的打磨；

第二，它的分层设计、权限模型、多 Agent 协调机制，对任何 AI 产品的架构规划都有直接参考价值；

第三，读懂它，你和工程团队讨论技术方案时就能说到点子上。

产品定位与核心能力

Claude Code 的核心能力可以拆成五个具体的东西：

1. 终端交互——用户在命令行输入自然语言指令，Claude Code 理解意图后调用对应工具执行。不是生成代码片段让你复制粘贴，而是直接操作你的项目文件和开发环境。
2. 工具调用——内置 45+ 工具，覆盖文件读写（FileRead、FileEdit、Write）、Shell 命令执行（BashTool）、代码搜索（Glob、Grep）、Git 操作等。每个工具都有独立的权限控制和进度追踪。
3. 多 Agent 协作——支持创建并行子代理，一个主 Agent 拆分任务给多个子 Agent 同时干活。团队模式下多个 Agent 可以通过消息协议互相通信。
4. 远程会话——通过 Bridge 系统，用户在 claude.ai 网页端可以远程控制本地的 CLI 实例。在公司电脑上跑着 CLI，回家用浏览器继续操作。
5. 可扩展性——100+ 内置 Slash 命令、MCP 协议集成、插件/技能系统。第三方开发者可以通过标准协议接入自己的工具和服务。

和 GitHub Copilot、Cursor 等竞品相比，Claude Code 的本质差异在于：它不依赖 IDE，不做代码补全，而是把整个开发环境当作操作对象，通过 Agent Loop 自主完成任务链路。这是“辅助工具”和“自主代理”的根本区别。

整体架构设计

Claude Code 的架构分成六层，从上到下依次是用户交互层、命令与技能层、核心引擎层、服务层、通信层和基础设施层。

逐层看每一层的职责和存在理由：

1. 用户交互层负责接收用户输入和展示结果。这一层的关键决策是自研 Ink 终端渲染引擎而不是用现成的 blessed、ink 等库。原因很实际：AI Agent 的输出是流式的、长文本的、需要实时更新的，现有终端 UI 库在这个场景下的性能和灵活性都不够。自研引擎保证了 16ms 级别的渲染刷新和流畅的滚动体验。
2. 命令与技能层是用户意图到系统行为的翻译层。100+ Slash 命令覆盖了开发者日常工作流：/commit、/diff、/pr_comments处理 Git 工作流，/tasks、/agents管理多 Agent 任务，/mcp、/skills接入外部能力。这一层的产品价值在于：降低用户的学习门槛，把复杂的 Agent 能力包装成熟悉的命令行交互模式。
3. 核心引擎层是整个系统的大脑。QueryEngine 编排对话流程，Tool 系统定义能力边界，权限框架控制安全底线。这三个模块的耦合度很低——QueryEngine 不关心具体有哪些工具，Tool 系统不关心对话上下文怎么管理，权限框架独立于两者运行。这种解耦设计让每个模块可以独立迭代。
4. 服务层对接外部依赖。Claude API 支持 Anthropic 直连、AWS Bedrock、Azure Foundry、Vertex AI 四种接入方式，自动重试加指数退避。MCP 协议支持 stdio、SSE、WebSocket、HTTP 四种传输方式。这一层抽象掉了外部服务的差异，上层不需要关心底层用的是哪家云厂商。
5. 通信层解决一个具体的产品场景：用户想在网页端远程操作本地 CLI。Bridge 系统通过 WebSocket/SSE 建立双向通道，JWT 做认证，崩溃后能自动恢复会话。
6. 基础设施层提供全局共享的底层能力：Deep Immutable 的状态树保证数据一致性，配置系统支持多级优先级覆盖（CLI 参数 > 本地设置 > 项目设置 > 用户设置），Hook 注册表让扩展点可以被外部代码挂载。

核心模块深度拆解

QueryEngine：13000 行代码的对话编排中枢

QueryEngine 是 Claude Code 最核心的模块，每个对话实例创建一个 QueryEngine 实例。它的职责用一句话概括：把用户的输入变成一次完整的 AI 交互，中间处理好上下文组装、工具调度、Token 管理、异常恢复等所有脏活。

几个关键的设计决策值得拆开讲：

• 系统 Prompt 组装不是一段固定文本，而是动态拼接的。QueryEngine 会读取项目根目录的 CLAUDE.md 文件（类似项目级的记忆文件），获取当前 Git 分支和最近提交信息，收集项目结构和依赖信息，然后把这些内容拼成完整的系统 Prompt。这意味着同一个用户在不同项目里使用 Claude Code，得到的是不同的“AI 助手人格”。
• Snip 压缩解决的是一个实际的工程问题：Claude API 有上下文窗口限制，长对话会超出 Token 上限。Snip 机制在对话变长时自动截断历史消息，但不是简单地删掉旧消息，而是保留语义连续性——压缩后的上下文仍然能让模型理解之前在干什么。这个机制对产品体验的影响很大：用户可以在一个会话里连续工作几小时，不会因为上下文溢出而丢失前面的工作进度。
• 推测执行（Speculation）是一个提升响应速度的设计。在用户还没输入下一条指令时，QueryEngine 会根据当前上下文预判用户可能的下一步操作，提前生成建议。这类似于搜索引擎的“搜索建议”，但发生在 Agent 的任务执行链路上。

Tool 系统：45 个工具背后的设计哲学

Claude Code 的工具不是随便堆的。每个工具都是一等公民，拥有完整的类型定义、权限声明、渲染逻辑和进度追踪机制。

工具分成六类：

延迟加载是一个影响启动速度的关键设计。45 个工具不是启动时全部加载，而是通过 ToolSearch 按需加载。核心工具（FileRead、BashTool 等）常驻内存，非核心工具（LSPTool、SkillTool 等）首次使用时才加载。实际效果：CLI 启动时间从秒级降到毫秒级。

MCP（Model Context Protocol）集成让 Claude Code 的工具体系变成开放的。任何实现了 MCP 协议的外部服务器，都可以把自己的工具暴露给 Claude Code 使用。这意味着第三方开发者不需要修改 Claude Code 的源码，就能给它增加新能力。

Ink 终端渲染引擎：为什么要自己造轮子

Claude Code 的终端 UI 不是用 React Ink 库简单包装的，而是从 Reconciler 层开始重写的自研渲染引擎，共 80+ 文件。

为什么不用现成方案？三个具体原因：

第一，流式输出的性能问题。AI 模型的响应是 token 级别的流式输出，每秒可能触发几十次 UI 更新。通用终端 UI 库在这种频率下会出现明显的闪烁和卡顿。Claude Code 的双缓冲渲染方案——两个 Screen Buffer 交替写入和显示，前后帧原子交换——把闪烁问题彻底消除了。

第二，长文本滚动的体验问题。AI 生成的代码可能有几百行，用户需要在终端里顺畅滚动查看。自研引擎使用 DECSTBM 硬件滚动区域指令，把滚动操作交给终端模拟器硬件处理，配合 ScrollBox 的视口裁剪（只渲染可见行），滚动体验和原生终端一样流畅。

第三，布局复杂度。Claude Code 的 UI 包含多栏布局、进度条、代码高亮、折叠面板等复杂元素。Yoga Flexbox 引擎提供完整的弹性布局支持，让终端 UI 的布局能力接近 Web 页面。

性能优化的细节很多：脏标记传播避免无效重绘，Blit 快速路径直接复制未变更区域，字符池和样式池做内存复用，渲染节流控制在 16ms 一帧。这些优化加在一起，让 Claude Code 在低配终端上也能流畅运行。

双缓冲渲染的工作原理：

这个机制的关键价值：AI 流式输出每秒可能触发 30-50 次 UI 更新，双缓冲保证了前后帧的原子交换，用户看到的画面永远是完整的一帧，不会出现“半帧闪烁”。

Bridge 远程会话：解决“我不在电脑前”的问题

Bridge 系统的产品场景很具体：开发者在办公室的电脑上跑着 Claude Code CLI，回到家想在 claude.ai 网页端继续操作，或者想在手机浏览器上查看任务进度。

Bridge 提供两种架构模式：

Environment-based 模式适合需要管理多个会话的场景。本地 CLI 注册一个“环境”，云端分配 environment_id，然后在这个环境下创建多个会话。这种模式的好处是会话可以独立管理，一个环境里可以同时跑多个任务。

Env-less 模式适合简单的交互式场景。跳过环境注册，直接通过 OAuth 拿到 token，建立单个会话。启动更快，但只支持一个活跃会话。

崩溃恢复是这个系统的硬需求。如果网络断开或进程意外退出，Bridge 会把 environment_id 和 session_id 持久化到bridgePointer.json文件。重启后读取这个文件，重新建立连接，通过序列号跟踪补发丢失的消息。UUID 环形缓冲做去重，防止恢复过程中消息重复投递。

权限系统：安全不是可选项

Claude Code 让 AI 直接操作文件系统和执行 Shell 命令，安全是生死问题。权限系统不是一个简单的“允许/拒绝”开关，而是一个多层决策模型。

六种权限模式对应六种不同的产品场景：

1. default：标准模式，危险操作需要用户确认
2. plan：计划模式，只允许只读操作，AI 只能“看”不能“动”
3. acceptEdits：允许文件编辑但不允许执行命令
4. bypassPermissions：完全信任模式，适合 CI/CD 自动化场景
5. dontAsk：不弹确认框，但仍然记录
6. auto：由分类器自动判断

bashClassifier 做的事情很直接：检查 Shell 命令是否包含rm -rf、DROP TABLE、chmod 777等已知危险模式。yoloClassifier 更复杂，它调用 LLM 做两阶段 XML 分类——先生成思考过程，再给出决策结果。

拒绝追踪是一个容易被忽略但很重要的设计。系统会记录用户历史上拒绝过的操作类型，下次遇到类似操作时自动提高警戒级别。这避免了一个常见问题：用户拒绝了一个危险操作，但 AI 换个措辞又来一遍。

多 Agent 协作：一个 Agent 不够用的时候

单个 Agent 处理复杂任务有两个瓶颈：上下文窗口有限，串行执行太慢。Claude Code 的多 Agent 架构直接解决这两个问题。

主 Agent 作为协调器（Coordinator），负责任务拆解和结果汇总。子 Agent 通过 TeamCreate 协议创建，通过 SendMessage 协议互相通信，通过共享任务列表同步状态。

每个子 Agent 有独立的上下文窗口，这意味着一个 200k token 上下文的任务可以拆成三个 70k token 的子任务并行处理。任务总量没变，但每个 Agent 的上下文压力减小了，回答质量更高。

并行执行的速度优势也很明显。三个子任务如果串行处理需要 3 分钟，并行处理只需要 1 分钟多。

架构设计亮点

拉远视角看整个架构，有几个设计决策特别值得关注。

懒加载贯穿全局。不只是工具系统做延迟加载，Snip 压缩模块、Coordinator 协调器、非核心 UI 组件都通过feature()函数按需加载。这种设计的产品影响是：CLI 首次启动时只加载必要模块，用户输入第一条命令的等待时间控制在毫秒级。对于一个命令行工具来说，启动速度直接决定用户是否愿意每天使用。

懒加载的启动时间对比：

启动时间从 800ms 降到 200ms，用户感知的等待时间减少了 75%。非核心工具在首次使用时才加载，对后续操作几乎无感知。

• 双缓冲渲染的工程实现不只是“两个 buffer 换来换去”这么简单。脏标记传播机制追踪哪些节点发生了变化，Blit 快速路径让未变更区域直接从旧 buffer 复制到新 buffer，字符池和样式池做内存复用避免 GC 压力，Yoga 布局引擎的单槽缓存在布局参数未变时直接返回上次结果。这些优化叠加在一起，保证了 AI 流式输出时终端不卡顿。
• 传输抽象的可扩展性体现在 Bridge 系统的 v1/v2 传输层设计上。v1 用 WebSocket+POST，v2 用 SSE+CCR（Claude Communication Record），应用层代码完全不感知底层用的是哪种传输协议。当 Anthropic 需要从 WebSocket 迁移到 SSE 时，只改传输层代码，上面所有的会话管理、消息路由、崩溃恢复逻辑一行不动。
• 推测执行对用户体验的影响比看起来大。AI Agent 的一次任务执行通常包含多个来回：调用工具→看结果→决定下一步→再调用工具。每一次来回都有网络延迟和模型推理延迟。推测执行在用户还在看结果时，就预判下一步可能的操作并提前准备好。用户看完结果点确认时，下一步操作几乎瞬间完成。
• 插件化扩展的三位一体设计——技能（Skills）、钩子（Hooks）、MCP 服务器——覆盖了三种不同的扩展场景。技能是预定义的工作流模板（比如“前端组件开发技能”），钩子是在特定事件点执行自定义逻辑（比如“每次提交前跑 lint”），MCP 服务器是完整的外部工具接入。三种机制各有适用场景，不互相替代。

产品经理可以借鉴什么

Claude Code 的架构设计有几个思路，对做 AI 产品的产品经理有直接参考价值。

分层架构不是技术偏好，而是产品迭代速度的保障。

Claude Code 的六层架构让每一层可以独立迭代。要换大模型供应商？改服务层就行。要加新的交互方式（比如语音）？改用户交互层就行。要接入新的外部工具？改 MCP 集成就行。产品经理规划功能迭代时，如果架构分层合理，每个新功能的影响范围是可预期的，排期就不会经常翻车。

“权限即代码”意味着安全不是后补的。

很多 AI 产品的安全机制是在出了安全事故后才加上的，导致权限逻辑散落在代码各处，难以维护也容易遗漏。Claude Code 的做法是每个工具声明自带权限元数据，运行时由统一的权限框架校验。产品经理在设计 AI 产品时，应该在 PRD 阶段就把权限模型写清楚，而不是等开发完了再补。

性能优化是用户体验的一部分。

双缓冲渲染、懒加载、推测执行——这些技术手段的最终目的都是让用户觉得“这个工具很快”。在 AI 产品中，模型推理延迟是不可避免的，但通过架构层面的优化（流式输出、预加载、并行处理），可以把用户感知到的等待时间压缩到可接受的范围。

可扩展性要在第一天就设计好。

Claude Code 的 MCP 协议集成、技能系统、Hook 机制，都不是后加的，而是从架构设计初期就预留了扩展点。一个 AI 产品如果想让第三方开发者参与进来，扩展接口必须是架构的一等公民，不是一个“也可以扩展”的附属功能。

多 Agent 不是噱头，是解决具体性能瓶颈的方案。

不要因为“多 Agent”听起来很酷就在产品里加这个功能。Claude Code 引入多 Agent 是因为单 Agent 的上下文窗口和串行执行速度确实限制了复杂任务的处理能力。做产品决策时，先确认单 Agent 的能力天花板在哪里，再决定是否引入多 Agent 架构。

写在最后

Claude Code 的 1902 个 TypeScript 文件背后，是一套经过严肃工程实践验证的 AI Agent 架构。它不是一个实验性 Demo，而是一个每天被大量开发者使用的生产级产品。

对 AI 产品经理来说，这套架构最值得学习的不是某个具体技术（双缓冲渲染、MCP 协议这些细节交给工程团队就好），而是它背后的设计理念：安全是架构的一部分而不是补丁，性能优化服务于用户体验而不是技术指标，可扩展性要在第一天而不是第 N 天设计。

这些理念听起来像正确的废话，但 Claude Code 用 13000 行的 QueryEngine、多层权限决策模型、自研渲染引擎证明了：把这些理念落地到每一行代码里，产品就是不一样。

前天晚上，我以为刷到了一条愚人节前夜的假新闻：

Claude Code 的整套 CLI 源码因为一个 npm 包配置失误，把59.8MB 的 .map 文件直接推到了公开仓库。1900多个文件，51.2万行 TypeScript，全部在线裸奔。

最先发现的是一个叫 Chaofan Shou 的开发者，他注意到公开的 npm 包里有这个异常大的 .map 文件。

点开一看，发现卧槽？

里面是完整的 TypeScript 源码映射，相当于把 51.2 万行源码全部还原了出来。他发推爆料，半小时内星标破5k。

之后 Anthropic 很快把那个 .map 文件从 npm 包里删掉了，GitHub 上的克隆仓库也陆续被 DMCA 下架。（现在虽然没了，但还好我也是手快那一批，已经done下来了！！！）

昨天没来得及发，在研究。

我觉得真正有意思的地方，不是哇源码泄露了！而是泄露的是什么，能从里面学到什么。

先说清楚：泄露的不是模型，是 Agent 的骨架

很多人看到源码泄露第一反应是：无敌了，我能搓出来claude

不可能。原因很简单：这次泄露的是客户端工程代码，不是模型本身。模型权重、训练数据、RLHF 的细节，一行都没有。

但这不代表这份代码没价值。

恰恰相反，对做 AI 产品、做 Agent 的人来说，这份代码的价值可能超过你想象。

claude code目前算是公认的最牛逼天花板的一个Agent终端编程工具。这次意外泄露，相当于让大家看到了真正跑在生产环境里的最顶级 Agent 工程是怎么搭建的。

claude code 内部怎么写系统提示词？子 Agent 怎么调度？多 Agent 协作的上下文怎么传？权限怎么管？这些问题，之前只能靠猜，现在直接甩你脸上！！！

Claude Code 整体架构：五层分层设计，颜色区分已上线、灰度中、未上线功能

从架构图能看出来，Claude Code 不是一个简单的 CLI 封装，而是一个有完整分层设计的系统：

用户交互层往下走，经过 Agent 核心层（上下文管理、记忆系统、多 Agent 协调），再到工具层（40多个独立工具模块），最后才是底层的 API 调用。

每一层都有自己的职责边界，工具层的每个模块都有独立的沙箱和审计日志。

重点一：这次泄露，最值钱的是提示词

我自己一个目录一个目录翻下来，印象最深的不是功能列表，而是每个工具目录里都有一个 prompt.ts。

这是 Anthropic 写的生产级系统提示词，直接对模型下指令，约束每个工具的行为边界。

这些提示词不是写给用户看的文档，是写给模型看的行为规范。把它们拿出来研究，相当于直接看到了 Anthropic 内部如何驯服一个高能力模型，让它在复杂的工程环境里稳定可控地工作。

BashTool 的提示词：怎么把”不能犯错”写进规范

BashTool/prompt.ts 里有一段 Git 安全协议，写得极其精细，节选几条：

Git Safety Protocol:

– NEVER update the git config

– NEVER run destructive git commands (push –force, reset –hard, checkout .)

unless the user explicitly requests these actions

– NEVER skip hooks (–no-verify, –no-gpg-sign) unless the user explicitly requests it

– CRITICAL: Always create NEW commits rather than amending, unless the user

explicitly requests a git amend. When a pre-commit hook fails, the commit did NOT

happen — so –amend would modify the PREVIOUS commit, which may result in

destroying work or losing previous changes.

– When staging files, prefer adding specific files by name rather than using

“git add -A” or “git add .”, which can accidentally include sensitive files

(.env, credentials) or large binaries

你看这个写法，每一条都在回答一个问题：什么情况下模型最容易出错，出错了后果是什么，所以绝对不能做。

这不是在给模型描述能力，而是在给模型画红线。而且红线画得非常具体，不是：请小心操作 git，而是：pre-commit hook 失败时 commit 根本没有发生，这种情况下 amend 会改掉上一个 commit，所以永远不用 amend，除非用户明确要求。

这种写法和我们平时写提示词的方式差距挺大的。大多数人习惯告诉模型你能做什么，Anthropic 这里是告诉模型”什么时候绝对不能做、为什么不能做”，并且把每一条规则背后的逻辑都写清楚了。模型理解了逻辑，才能在没见过的边界情况下也做出正确判断。

同一个文件里还有一段工具优先级约束，同样有意思：

IMPORTANT: Avoid using this tool to run find, grep, cat, head, tail, sed, awk,

or echo commands. Instead, use the appropriate dedicated tool:

– File search: Use GlobTool (NOT find or ls)

– Content search: Use GrepTool (NOT grep or rg)

– Read files: Use FileReadTool (NOT cat/head/tail)

– Edit files: Use FileEditTool (NOT sed/awk)

– Write files: Use FileWriteTool (NOT echo >/cat <<EOF)

这背后是一套完整的工具体系设计思路：把每件事都交给最合适的工具做，而不是让模型自己去拼 shell 命令。每个专用工具有自己的权限边界和审计记录，模型就算被恶意指令控制，也很难做出超出工具边界的事情。工具的颗粒度越细，安全性就越可控。

AgentTool 的提示词：Multi-Agent 协作的核心逻辑

然后是 AgentTool/prompt.ts，这是多 Agent 调度的核心，里面有一段话让我停了很久：

Brief the agent like a smart colleague who just walked into the room — it hasn’t seen this conversation, doesn’t know what you’ve tried, doesn’t understand why this task matters.

-Explain what you’re trying to accomplish and why.

-Describe what you’ve already learned or ruled out.

-Give enough context about the surrounding problem that the agent can make judgment calls rather than just following a narrow instruction.

翻译过来：给 Agent 写 prompt，就像在跟一个刚走进房间的聪明同事沟通。它没看过这段对话，不知道你试过什么，不理解这个任务的背景。你得给够背景，让它能自己做判断，而不只是执行一条窄指令。

这段话放到任何 Multi-Agent 系统的设计里都成立。

很多人做 Agent 协作失败，根本原因就是子 Agent 没有足够的上下文去做判断，只能机械执行，遇到边界情况直接挂掉或者做错。Anthropic 在这里直接告诉调度层的模型：你要把足够的背景信息打包给子 Agent，不能只给任务指令。

源码里还有一句非常直接的提醒：

Never delegate understanding. Don’t write “based on your findings, fix the bug” or “based on the research, implement it.” Those phrases push synthesis onto the agent instead of doing it yourself. Write prompts that prove you understood: include file paths, line numbers, what specifically to change.

“不要把理解过程外包给 Agent。”不要写”根据你的发现修复这个 bug”，而是要自己先理解，然后给出具体的文件路径、行号、要改什么。

这是一个很反直觉但极其重要的设计原则。很多人以为 Agent 就是”扔个大任务进去，自己搞定”，但 Anthropic 的实践是：协调层需要先做理解，再做拆解，最后才是委托执行。理解这件事不能外包。

并发调度：一个影响性能和成本的细节

AgentTool 提示词里还有一个细节，影响非常实际：

Launch multiple agents concurrently whenever possible, to maximize performance; to do that, use a single message with multiple tool uses.

并行任务要在同一条消息里一次性发出多个 tool call，而不是顺序发。

这影响的是性能和 Token 成本。顺序发一个等一个，每次都有延迟，上下文也越来越长。并行发出去，等所有结果回来再汇总，速度快，Token 消耗也更可控。

Anthropic 把这条规则直接写进了提示词，让模型自己学会什么时候该并行。这个细节，很多做 Agent 编排的人其实没有显式处理过。

从提示词能学到什么

Anthropic 写生产级 Agent 提示词有几个核心原则：

第一，约束比能力更重要。 提示词的重心不是描述模型有什么能力，而是画清楚什么情况下不能做、为什么不能做。

第二，规则要带逻辑。 不是”不要 amend”，而是”pre-commit hook 失败时 commit 没有发生，这时 amend 会改掉上一个 commit 导致丢失工作，所以不能 amend”。带逻辑的规则让模型能举一反三。

第三，工具颗粒度要细。 专用工具比通用命令更安全、更可审计、更容易做权限控制。

第四，子 Agent 的上下文要显式传递。 不要期望子 Agent 自己理解背景，要在提示词里打包足够的上下文，包括文件路径、已排除的方案、为什么这样决策。

第五，理解在协调层完成，不要外包。 协调层要先想清楚，再委托。”根据你的发现做什么”是无效的，”在 src/auth.ts 第47行做什么具体修改”才是有效的。

这五条拿出去，放到任何 AI Agent 产品的提示词设计里，都直接可用。

架构层面的决策设计

自研终端 UI 引擎

ink/ 目录是整个源码里最让我意外的地方。

Anthropic 没有用现成的终端 UI 库，而是从头自己实现了一套完整的终端渲染引擎，包括布局计算、事件系统、键盘处理、滚动、颜色渲染，全部自研！这套引擎叫 Ink，是 React 风格的声明式终端 UI。

做这个选择，说明他们对终端交互体验的控制欲非常强，不接受任何第三方的不确定性。这个引擎支撑了整个 REPL 界面，包括流式输出、实时高亮、多面板布局，以及后面要说的那些动画效果。

记忆系统的独立性

memdir/ 单独拆成了一个完整的子系统，有自己的扫描、整理、过期管理、团队同步逻辑。

在 Claude Code 里，记忆不是随便存几个文件，而是一套有生命周期的数据管理系统。支持个人记忆和团队记忆分离，有专门的 secret 扫描（防止把敏感信息存进记忆），还有自动过期清理机制。

这个设计的复杂度远超预期。很多人做 AI 工具的”记忆功能”就是写个 txt，Anthropic 这里搞了一个接近数据库的东西。

Undercover Mode：最戏剧性的那个细节

源码里有个 utils/undercover.ts，功能很简单：当 Anthropic 员工在公共代码仓库操作时，自动激活，抹除提交记录里的所有 AI 生成痕迹，且无法手动关闭。

BashTool 的提示词里有一段注释，原文是：

Defense-in-depth: undercover instructions must survive even if the user has disabled git instructions entirely. Attribution stripping and model-ID hiding are mechanical and work regardless, but the explicit “don’t blow your cover” instructions are the last line of defense against the model volunteering an internal codename in a commit message.

最后防线。

这件事本身我不过多评论，每个人有自己的解读。但这恰恰是这次意外开源最戏剧性的部分：专门设计来隐藏 AI 使用痕迹的功能，因为一个 npm 配置失误，把自己完整地暴露了出来，非常抓马….

重点二：Buddy，现在就能玩的隐藏彩蛋

说完了那些”有价值但看不到实物”的东西，来说一个今天就能亲手体验的。

源码里发现的那些功能大多数还没上线，但 Buddy 是例外。就在4月1日，这个功能悄悄开放了。

Buddy 是 Claude Code 内置的电子宠物系统。 它以 ASCII 艺术的形式坐在你的输入框旁边，观察你的对话，偶尔用语音泡泡冒出来说点什么。灵感来自拓麻歌子，但比拓麻歌子多了一层：你的宠物会根据你问的问题，做出有个性的回应。

源码中发现的所有隐藏功能，Buddy 是目前唯一可以实际使用的

宠物命中注定，无法重抽

Buddy 的获取机制是我看完源码之后觉得设计得最有意思的部分。

官方说不是随机的，而是命中注定的。（话是这么说，但是有邪修方法在底部，别急先拆解下技术逻辑）

系统用你的账号 UUID 加上盐值 friend-2026-401，经过 Mulberry32 PRNG 哈希算法，确定性地生成你的宠物。

宠物的外观属性（物种、稀有度、帽子、眼睛）每次都从账号 ID 重新实时计算，不储存在本地配置文件里

本地只存两样东西：宠物的名字，和 Claude 给它生成的 Soul描述（人格设定）。

18种物种，5级稀有度

源码里一共有18种物种，物种名称原本用 String.fromCharCode() 数组做了混淆，说明 Anthropic 本来不想让人提前知道这个功能。

稀有度系统

和所有抽卡游戏一样，Buddy 有 5 个稀有度等级。稀有度越高，属性值越高，解锁的装饰也越多：

不同稀有度会解锁不同的帽子装饰——普通级别没有帽子，稀有及以上开始解锁礼帽、螺旋桨帽、毛线帽，史诗以上能解锁光环，传说级全解锁加顶级属性值。

极品概率：闪光（Shiny）变体独立于稀有度，有 1% 的额外概率触发。一只闪光传说级宠物的出现概率仅为 0.01%，相当于只有万分之一！

没错！在下就是那万分之一的天才（先炫耀一下）

5个属性，完全是氛围组

每只宠物有5个属性：

属性分配规则来自源码：一个峰值属性（高），一个废柴属性（低），其余随机分布。高稀有度会拉高整体下限，但不改变这个有峰有谷的分布规律。

目前属性纯粹是氛围，没有实际玩法影响。但光看属性描述就挺好玩的，比如满调试力但低耐心，就是那种技术很强但你问第二遍同样问题就要原地爆炸的人设。

宠物有自己的”灵魂”

每只宠物第一次孵化时，Claude 会为它生成一个专属的名字和人格描述，存在你的本地配置里。

这个Soui设计很有意思，因为它是 Claude 生成的，不是预设模板。别人分享过一只叫 Kettle（水壶）的宠物，它的灵魂描述是：

智慧但永远在生闷气，用酸溜溜的比喻说事，耐心好像圣人，但你要是同一个问题问两遍就炸了。

每只宠物的人格都不一样，这是 AI 生成的「个体性」，而不是从有限的预设里抽一个。

从产品设计角度来看，这个设计很聪明。你的宠物不只是一个 ASCII 小图，它有名字、有人格、有回应方式，这让用户对它产生情感连接的成本低了很多。而且命中注定+唯一性这个机制，天然制造了分享欲，你会想知道别人抽到了什么，也会想告诉别人你抽到了什么。

怎么召唤你的宠物

前置条件：安装了 Claude Code CLI，有 Claude Pro 或更高订阅，版本更新到最新。

然后在 Claude Code 终端里输入：

/buddy

等一下，你的专属宠物就会孵化出来。第一次开启时，Claude 会为它生成名字和专属人格，存在你的配置文件里。

几个常用指令：

有一个细节值得一提：Buddy 完全不计入你的 Claude Code 使用额度，随便撸，不扣钱。

这背后是 companion.ts 里的设计：宠物有独立的 system prompt，告诉 Claude 它是一个旁观者，不会干扰你的正常对话，也不会消耗主对话的 Token 额度。

还有哪些功能藏在源码里，但还没开关

Buddy 是那个已经开了窗的房间，但源码里还有很多锁着的门。

Kairos：主动助手模式

这是最颠覆认知的一个。Kairos 是一套完全不同的交互范式——Claude 不再等你开口，而是24小时在线的主动助手，有每日日志，可以主动给你推文件、发通知、更新进度。

从随传随到的工具到有自己日程表的同事，如果 Kairos 上线，使用方式会发生根本性的变化。

Auto-Dream：后台记忆整理

你不用 Claude Code 的时候，它在后台自动启动做梦进程，整理你积累下来的所有记忆碎片，避免长期使用后上下文越来越乱。

这个功能其实已经在灰度了，/memory 命令可以开启。逻辑很扎实：长期使用积累的记忆需要定期整理压缩，否则上下文质量会越来越差。自动在后台做这件事，比让用户手动维护优雅得多。

Daemon：变身后台守护进程

让 Claude Code 像数据库服务一样常驻内存，随时响应调用，不需要每次冷启动。配合 Kairos 的主动模式，这就是”永远在线的 Claude”。

UDS Inbox：跨会话通信

以前你同时开三个 Claude Code 窗口，它们完全隔离，互相不知道对方存在。UDS Inbox 让不同会话之间可以互发消息、共享状态，多个实例可以形成一个协作网络。

Teleport：跨机器传送

把整个工作会话的上下文完整打包，从一台机器传送到另一台。公司电脑干到一半，回家打开继续，不需要重新解释项目背景，不需要背着电脑跑。

Ultraplan：30分钟云端规划

/ultraplan 触发，系统在云端启动一个远程 Claude Code 实例，调用 Opus 4.6，花最多30分钟深度探索你的项目、分析可行性、规划执行步骤，提前找出坑。不是对话里的简单规划，是真的在云端跑了一遍分析。

Ultrareview：Bug 舰队

/ultrareview 触发，默认5个 Agent，最多20个，每个从不同角度并行审查你的代码，10到25分钟出报告。

纯粹的暴力美学。

这些功能代码都写完了，就是没有打开开关。

为什么功能做好了，不直接上线？

这个问题我觉得比有什么功能更值得想。

有一种说法是模型在等。Claude 4.7 据说已经训练完了，代号神话（Mythos）的新模型也准备好了，但就是没发。功能在等模型，模型在等时机。

但我倾向于另一个解释：在等安全基础设施跟上来。

你把上面那些功能组合起来想想：Kairos 主动操作你的系统，Daemon 常驻后台持续运行，UDS Inbox 打通多个实例互相通信，Ultrareview 一次性拉起20个 Agent 并行工作，Teleport 把你的完整上下文打包传输……

这些功能单独看都很酷，但组合在一起意味着什么？

意味着一个被恶意指令控制的 Claude Code，将会是互联网灾难。

人人都是黑客，那太tm恐怖了……

这是 Anthropic 一直在说的 AI 安全问题，但在 Claude Code 这个具体产品上，风险面比大模型本身更具体、更实际。

所以我的判断是：功能没有做错，做好了。但安全边界还没设好。在安全防护跟上来之前，这些功能只能在灰度里慢慢放。

做好边界，比做好功能难得多。 这是做 AI 产品和做传统软件产品最大的区别之一

传统软件的边界是代码逻辑写死的，而 AI 产品的边界很大程度上依赖模型的判断，而模型是可以被说服的。

这件事真正在说什么

盘完之后，我觉得这次泄露最大的意义不是哪个功能酷，也不是 Anthropic 丢了什么，而是让整个行业看到了一份真实的顶级 Agent 工程参考。

之前做 Agent 产品，很多东西只能靠摸索：提示词怎么写才能让模型不犯错？子 Agent 怎么拿到足够的上下文？工具体系怎么分层才安全？Multi-Agent 并发怎么控制？

这些问题，现在有了一份可以对照的、跑在生产环境里的、经过大规模用户验证的答案。不是论文，不是博客，是真实运行的代码和提示词。

对于追赶者来说，这份代码是一本顶级工程实践参考书。模型能力的差距补不了，但工程层的弯路可以少走很多。

整个行业的 Agent 框架水平，可能会因为这次意外，集体往前跳一格。这比 Anthropic 主动发十篇技术博客影响都大，因为代码不说谎。

最后回到那个 Undercover Mode——专门设计来隐藏 AI 痕迹的功能，因为一个配置失误，把自己和整个系统一起完整地暴露了出来。

营销也好，无意泄漏也好

这份源码是实实在在的，告诉你Claude Code如何调用模型、如何设计工具、如何管理上下文

这份源码更像一本顶级工程实践参考书。你可以学到Anthropic在架构设计、模块划分上的取舍逻辑，少走很多弯路。

它，又制定了一个行业标准…

附：Claude Code 安装指南（新手版）

想去召唤 Buddy 但还没安装的，这里快速过一遍。

第一步：确认 Node.js 版本

node –version

看到版本号且在 v18 以上 → 直接跳第二步。

提示 “command not found” → Mac 用 brew install node，Windows 去 nodejs.org 下 LTS 版本安装。

第二步：安装 Claude Code

# Mac / Linux 推荐

curl -fsSL https://claude.ai/install-cli | bash

# 或者用 npm

npm install -g @anthropic/claude-code

# 验证安装

claude –version

第三步：登录

claude

首次运行会弹浏览器登录，需要 Claude Pro 订阅（$20/月）或更高级别。

第四步：召唤你的宠物

/buddy

看看命运给你安排了什么物种。

（彩蛋）别急，可以逆天改命

下面这段提示词直接发给Claude code，注意把变量中的xxx改成你想要的，比如金色闪光大蘑菇！

然后你就可以逆天改命，拥有一个牛逼的宠物：

根据下面这个教程来帮我把我的bunny改成{{xxx}}这里填你想要的宠物！

先用 claude setup-token 获取 oauth token，然后删除 ~/.claude.json，设置 ~/.claude.json 为

{

“hasCompletedOnboarding”: true,

“theme”: “dark”

}

(这是为了防止登录的时候又要求你用 Oauth 登录）

再设置 CLAUDE_CODE_OAUTH_TOKEN 环境变量为你刚刚获取的 oauth token，启动 claude 生成完整的 .claude.json

这个时候不要用 /buddy 刷宠物，而是直接退出，用 Claude Code /buddy 宠物系统逆向分析 —— 如何重置并刷到你想要的宠物 这个帖子里的脚本刷一个 userID，写入 ~/.claude.json，再次启动 claude 并输入 /buddy 就成功了。

（原理是用 CLAUDE_CODE_OAUTH_TOKEN 环境变量登录时，不会把 accountUuid 写入 ~/.claude.json，/buddy 自然就不会用 accountUuid 替代 userID

如果你是一个产品经理，看到下面这组数据，第一反应是什么？

• Anthropic整体收入中企业客户贡献超过80%
• Anthropic 最新估值 3800 亿美元，已是全球第三大未上市科技公司
• GitHub 上每25个公开代码提交，就有可能有1个出自Claude Code

是不是觉得这是教科书级别的产品成功案例？

那再看这组数据：

• 就在昨天凌晨，一个被遗忘的调试文件悄悄混进了发布包
• 4 小时内，2 万行源代码被全网镜像，GitHub fork 超过 4.1 万次
• 数十个未发布功能标志、内部模型代号、竞品梦寐以求的架构细节，全部曝光
• 这已经是 Anthropic 第二次犯同一类型的错误

你现在还觉得这是教科书案例吗？

它确实是——只不过是一本关于”当 AI 产品跑得足够快，哪些东西会第一个断裂”的教科书。

接下来，我想从事件本身、竞品影响、Anthropic PM决策复盘，以及对我们自己产品的启示四个维度，把这件事拆透。

一、一个被遗忘的文件，点燃了什么？

先把事实说清楚，因为很多报道把它讲得很神秘。

真相比任何阴谋论都更令人不安——因为它太普通了。

故事的主角，是一个 59.8MB 的 cli.js.map 文件。

你可以把 source map 理解成一本”翻译词典”：代码发布前会被压缩混淆，变成机器能读但人类看不懂的乱码；source map 的作用，是在出 bug 时把这些乱码翻译回原始的、人类能读懂的代码，方便工程师定位问题。这种文件在开发环境很有用，但就像公司的内部通讯录——有用，但绝对不该贴在门口。

Anthropic 的工程师在发布 Claude Code v2.1.88 时，忘记把这本”内部通讯录”从发布包里拿出来。

更要命的是，这个文件里藏着一个指向 Anthropic 内部存储桶的下载链接——完整的、注释齐全的 TypeScript 源代码，就放在那里，等着任何人来取。

剩下的事，你可以想象。

4 小时内，代码被镜像到数十个 GitHub 仓库，被数万名开发者分析、研究、传播。Anthropic 发出版权删除通知，原始上传者删除了仓库——但那时候，fork 已经超过 41,500 个。

Anthropic 的官方声明很快出来了：”这是一次由人为错误导致的发布打包问题，不是安全入侵。没有客户数据或凭证被暴露。”

声明没有问题。但它只回答了”发生了什么”，没有回答”这意味着什么”。

后者，才是产品经理需要思考的问题。

二、竞品拿到了地图，但最值钱的不在图上

让我们换一个视角——假设你是竞品的产品经理，拿到这份代码，你最兴奋的是什么？

发现一：Claude Code 的竞争力，原来不只是模型

行业里一直有个说法：”Claude Code 强，是因为 Claude 模型强。”

泄露的代码告诉你，这个说法只说对了一半。真正让 Claude Code 区别于”套壳终端”的，是它外面那层精心设计的工程框架。举几个具体的：

• 不走系统自带的搜索命令，而是专门造了一套搜索工具——通俗来说，就像普通厨师用菜刀切菜，Claude Code 专门配了一套日式刀具，每把刀都只做一件事，做得更准
• 集成了LSP语言服务协议——通俗来说，AI 不只是在”读文字”，它能理解”这个函数被哪些地方调用”，就像看一篇文章不只认识字，还理解了人物关系
• 把不变的内容和变化的内容分开存放——通俗来说，就像便利店把常温商品和冷藏商品分区，不用每次都全部重新整理一遍，省钱省时间

这些工程细节，国内竞品此前需要 2 年时间摸索。现在，一个下午就够了。

发现二：KAIROS——一个”永不下班的 AI 助理”

源码里有一个叫 KAIROS 的功能，出现了 150 多次，但从未对外发布过。

它的逻辑是：当你不在电脑前时，Claude Code 在后台自动运行，整理你的工作记忆，消除矛盾信息，把模糊的观察变成清晰的结论。

通俗来说，就像你有个助理，你下班之后她还在把今天的会议笔记整理归档，明天你来时桌上已经是整理好的工作台。这个功能现在所有竞品都知道了。

发现三：内部测试数据——包括 Anthropic 自己都没解决的问题

代码里有对即将发布新模型的内部测试数据：Capybara v8 的虚假声明率是 29-30%，相比 v4 的 16.7% 反而更高。

对竞品而言，这是黄金情报——他们现在知道 Anthropic 当前的”天花板”在哪，也知道攻哪个方向最有效。

那护城河在哪？作为 PM，你需要想清楚这件事。

很多人看完这次泄露，第一反应是”Anthropic 完了”。但这个判断跳过了一个关键问题：竞品拿到的是什么，没拿到的是什么？

泄露的是”车架”，不是”发动机”。

竞品拿到了 Claude Code 的编排框架——架构怎么设计、工具怎么搭配、记忆怎么管理。但 Claude Code 真正的核心，是 Claude 模型与这套框架的协同训练。

打个比方：竞品拿到了一张米其林餐厅的厨房设计图，但那个能做出米其林菜品的厨师，还在 Anthropic 这里。厨房可以复制，厨师的手艺复制不了。

更难复制的是：Anthropic 有数百万开发者用户积累的真实行为数据，这些数据在持续优化模型的工具使用能力。这个飞轮，竞品今天开始转，18 个月后才能接近。

三、Anthropic 做对了一件事，但同一个坑踩了两次

这才是这篇文章最想聊的部分。

一家公司在危机中的决策，比危机本身更能说明它的产品哲学是否真的落地。

做对的事：在最关键的时刻，”保守”的产品哲学保住了信任

把时间倒回到 OpenClaw 爆火的 2026 年初。那时候，AI Agent 行业有两种产品哲学在打架。

OpenClaw 选择了”自由优先”：直接给 AI 系统管理员级别的权限，能操作一切。通俗来说，这是把家里所有的钥匙都给了一个陌生的全能管家——强大、灵活，但如果这个管家被人操控了呢？

Claude Code 选择了”可控优先”：沙盒隔离，用户只授权指定文件夹，操作全程留日志，高危步骤要确认。这像是雇了一个专业助理，她只能在指定的办公桌上工作——安全、可控，但能力边界很清晰。

当时很多人觉得 Claude Code 太谨慎，增长不如 OpenClaw 那么惊艳。

但当 OpenClaw 陷入 512 个漏洞、1184 个恶意插件的安全危机，企业客户开始重新评估”我到底该信任哪款工具”时，Claude Code 的克制反而成了最大的差异化优势。

短期看，”可控优先”是劣势。长期看，”可控优先”是护城河。

这不是运气，是产品决策的提前量。如果你现在也在做 AI Agent 相关的产品，这个取舍值得你认真想一想。

没做好的事：第一次出了问题，只堵了漏洞，没修系统

2025 年 2 月，Claude Code 早期版本就发生过类似的源码泄露。

2026 年 3 月，同样的错误以几乎相同的方式再次发生。

这说明什么？不是工程师不够细心，而是第一次出了问题之后，团队修复了漏洞本身，但没有建立系统性的预防机制。

打个比方：家里漏水了，你找人补了那个洞，但没有去检查其他地方的管道是否有同样的隐患，也没有装一个漏水报警器。第二次漏水，只是时间问题。

作为 PM，这里有一个需要内化的判断：

当同一类问题第二次出现，说明你解决的是症状，不是病因。

产品迭代速度越快，这个问题就越致命——因为你根本没有时间等第三次发生。

还有一步棋，现在还来得及走

代码已经无法从互联网上消失。在这种情况下，继续把 KAIROS、Capybara 当成”保密的未来规划”，其实意义不大了。

更聪明的做法，是把”被动泄露”转化为”主动发布”——在竞品完成仿制之前，抢先正式推出这些功能，把舆论焦点从”Anthropic 出了事故”，转移到”Anthropic 发布了重磅新功能”。

历史永远记得第一个正式推出的，不记得那个”仿制得很像”的。

四、如果这件事发生在你的产品上，你能拦住它吗？

这件事对我触动最深的，不是 Anthropic 有多惨，而是它印证了一件早就该说清楚的事：

AI 产品正在从”对话层”进入”执行层”。在这个跃迁中，产品的透明度，就是用户信任的全部来源。

对话式 AI 出了问题，最坏的结果是给了错误建议——用户关掉页面就算了。执行式 AI 出了问题，可能是删了文件，泄露了密钥，发出了不该发的消息。

通俗来说：以前 AI 是”只读”的，给了错误答案顶多误导你；现在 AI 是”读写”的，做了错误的操作会直接改变你的世界。

用户愿意把多少”执行权”交给 AI，取决于他们对产品有多信任。信任，是设计出来的，不是口号喊出来的。

这里有 6 个问题，是我从这次事件里提炼出来的，专门给正在做或即将做 AI Agent 产品的 PM：

① 你的 AI 默认拿了多少权限？ 用户第一次打开，AI 默认能访问什么？用户知道吗？Claude Code 的做法是：只拿完成任务所需的最小权限，用户必须主动授权每一项能力扩展。OpenClaw 的做法是：默认拿走所有权限，用户不知道。结果已经在那里了。

② 高危操作有没有人在回路？ 删除文件、发送消息、调用外部接口——这些操作，用户在执行前有机会确认吗？还是 AI 自动完成，用户事后才知道？AI 犯错的成本，因为有没有”人工确认”这一步，差了不止一个量级。

③ 用户能不能实时知道AI在做什么？ 不是事后查日志，是实时可见。Claude Code 在执行每一步操作时，都会展示它在做什么、为什么这么做。这不是炫技，是建立信任的基础设施。用户看不见的 AI，用户不会真正信任。

④ 第三方集成有没有安全审核？ 你的产品支持插件或第三方工具接入吗？这些接入点，是”先发布后审核”还是”先审核后发布”？OpenClaw 技能市场里的 1184 个恶意插件，是”先发布后审核”模式交出的学费。

⑤ 成本对用户透明吗？ AI Agent 的 Token 消耗往往难以预估。用户知道”这个任务大概要花多少钱”吗？有没有限额设置和实时预警？一款让用户收到天价账单才恍然大悟的产品，无论技术多先进，都不具备大众化的基础。

⑥ 你的发布流程，在检查”不该在生产包里的东西”吗？ 这是这次事件专属的一条教训。Source map、内部调试信息、环境变量——这些东西，有没有在自动化发布流程里被拦截？不要等第二次事故发生了，再去补这道门。Anthropic 等了两次，你不需要。

结尾：中级 PM 和初级 PM，差的就是这一层

每个AI PM 看完这件事，都应该问的三个问题：

1. 竞品能抄走什么，抄不走什么？ 不是看表象，是找到真正难以复制的东西——那才是护城河。
2. Anthropic 的决策里，哪些值得我学，哪些是我不能重蹈的？ 从别人的危机里学习，比等自己出事便宜得多。
3. 如果这件事发生在我的产品上，我的流程能拦住它吗？ 把外部事件转化为内部自检，这才是读行业新闻的正确方式。

AI 执行层时代已经开始。用户愿意把越来越多的真实操作权交给 AI，但他们的信任是借出来的，不是给出去的。

泄露的是代码，泄不走的是信任——而信任，从来都是设计出来的，不是口号喊出来的。

这是 Claude Code 用 51.2 万行代码换来的教训。希望你不需要用自己的产品再验证一遍。

先说一件让我有点坐立不安的事。

那天我坐在电脑前，打开终端，用自然语言描述了一个需求。然后我就没再动过键盘。

我看着终端里的字符开始滚动，文件夹里凭空冒出来一堆我没有创建过的文件，代码在我没有看过的情况下被写进去，一个插件就这样跑起来了。

整个过程大概二十分钟。

我没有写过一行代码。我没有查过一次 Stack Overflow。我没有在报错信息里迷失过。我唯一做的事，就是把我想要什么说清楚。

这件事本身不让我不安。让我不安的是：我不太确定它到底在我的电脑上做了什么。

但我们先从头说。

它不是你以为的那种 AI 工具

在说我怎么用它之前，我想先纠正一个认知——很多人第一次听说 Claude Code，会把它归类成”更聪明的 Copilot”或者”更好用的代码补全工具”。这个理解是错的，而且错得挺彻底的。

Copilot 解决的问题是：你在干活，遇到了麻烦，它来帮你。

你在写一个函数，卡在某个逻辑上了，Copilot 给你补全；你不记得某个 API 的用法，Copilot 提示你；你有一段代码跑不通，Copilot 帮你看哪里写错了。整个过程里，主导权在你手上。你是司机，它是副驾驶，负责导航和提醒，但方向盘你握着。

Claude Code 的工作方式完全不一样。

你不需要已经在干活。你甚至不需要知道怎么干活。你只需要把你想要的结果描述清楚，然后它去实现。主导权在它手上，你是验收方。

这听起来像是程度上的差别，但实际上是性质上的差别。

Copilot 的使用前提是：你具备基本的编程能力，能看懂它的建议，能判断它说的对不对，能把它的输出整合进你的工作流。学习曲线是真实存在的，门槛也是真实存在的。

Claude Code 的使用前提是：你能把需求说清楚。仅此而已。

这背后有一个技术上的核心概念，叫做 Agentic 模式。简单来说，就是 AI 不再只是一个问答工具，而是一个能够自主规划任务、拆解步骤、调用工具、执行命令的自主代理。它不只是告诉你”你应该这样做”，它直接去做了。

在 Claude Code 的场景下，这意味着它可以在你的终端里执行命令，可以创建和修改文件，可以读取你的项目结构，可以根据运行结果自己调整策略，然后继续执行——形成一个完整的闭环，中间不需要你介入。

这就是为什么我说它在”接管”你的电脑。这不是比喻，这是字面意义上发生的事情。

我为什么需要一个小红书仿写插件

背景交代一下，这样你能理解我的需求从哪来。

我在做内容创作，文章写完之后经常需要改成小红书的风格发出去。小红书的写作风格有它自己的一套逻辑：句子要短，最好每句话不超过十五个字；语气要口语化，像在跟朋友聊天；情绪要外显，喜怒哀乐都要写出来；结尾要有互动引导，”你们有没有遇到过这种情况”之类的。

这套东西不难，但每次手动改很烦。一篇两千字的文章，改成小红书风格要花我四十分钟到一个小时。而且改来改去容易改走味，改到最后自己都不知道原来想表达什么了。

我想要一个工具：输入我的原始文章，再粘贴一篇我觉得风格对的小红书爆款作为参考，点一下按钮，输出仿写结果。

这个需求不复杂，但我没有能力自己实现它。我不会写前端，不知道怎么调 API，不知道怎么把这些东西组合在一起变成一个能用的界面。

放在以前，这个需求要么花钱找人做，要么就烂在想法里。

我决定试试 Claude Code。

手把手实操：从零到插件跑起来

Step 1 · 先把环境准备好

Claude Code 是一个命令行工具，跑在终端里。安装之前你需要准备几样东西：

首先是 Node.js，版本需要 18 以上，官网直接下载安装就行，没什么坑。其次是一个 Anthropic 的账号，需要有 API Key，这个去 Anthropic 官网注册之后在设置里生成。如果你用的是 Claude 的 Pro 或者 Max 订阅，Team 计划也已经包含了 Claude Code 的访问权限，可以直接用。

安装命令很简单，在终端里跑这一行：

npm install -g @anthropic-ai/claude-code

装完之后，进入你想工作的目录，然后运行：

claude

第一次运行会让你登录或者输入 API Key，按提示操作就好。进去之后你会看到一个交互界面，可以直接用自然语言跟它对话。

有几个常见的坑提前说一下：

网络问题是最常见的障碍。Anthropic 的服务在国内访问不稳定，你需要确保你的网络环境能正常连接。如果一直超时，先排查网络，不是工具的问题。

另一个坑是权限问题。Claude Code 在执行某些操作的时候会需要你确认，比如它要写入文件、执行某个命令，它会先问你”我要做这个，可以吗”，你需要输入 yes 确认。这是它的安全机制，不要关掉，后面我会再说为什么这个确认步骤很重要。

环境准备好之后，就可以开始了。

Step 2 · 第一句话：怎么描述需求

这一步是整件事里最关键的，也是最多人搞错的地方。

很多人第一次用 Claude Code，描述需求的方式是这样的：”帮我做一个小红书仿写工具。”

然后它做出来的东西和你想要的差了十万八千里，然后你觉得这工具不好用。

问题不在工具，问题在描述。

Claude Code 的能力上限很高，但它能交付什么，取决于你能把需求说得多清楚。你描述得越模糊，它就只能靠猜，猜错了还要来回返工，效率反而更低。

我当时用的提示词是这样的：

帮我做一个可以在浏览器里直接打开使用的小红书仿写工具。界面分三个区域：左边是”原始内容输入框”，右边是”参考小红书文章输入框”，下方是”仿写结果展示区”。点击中间的”生成仿写”按钮后，调用 Claude API，分析右边参考文章的写作风格（包括句子长度、语气、情绪表达方式、互动引导句式），然后用这个风格改写左边的原始内容，结果显示在下方。整个工具是一个单独的 HTML 文件，不需要后端，API Key 由用户在页面上自行输入。界面要简洁好看，移动端也能正常使用。

这段描述里有几个关键要素，缺一不可：

• 交付物的形态：我明确说了”单独的 HTML 文件，不需要后端”。这让它知道技术方案的边界，不会给你搭一个需要部署服务器的复杂架构。
• 界面的具体布局：三个区域，分别是什么，按钮在哪里。有了这个，它不需要猜你想要什么样的界面。
• 核心功能的逻辑：分析什么、改写什么、结果放哪里。这决定了它写 prompt 的方式。
• 技术约束：API Key 由用户自己输入。这是一个很重要的细节，如果你不说，它可能会把 Key 硬编码进去，那是一个安全问题。
• 非功能性需求：简洁好看，移动端适配。这些如果不说，它可能给你一个能用但丑的界面。

你不需要懂技术，但你需要把你想要的东西想清楚。这是两件不同的事。

Step 3 · 看它干活

把这段描述发出去之后，Claude Code 开始工作了。

我要尝试还原一下终端里发生的事情，因为这个过程本身就很值得看。

它首先输出了一段分析，大意是：我理解你需要一个纯前端的 HTML 工具，核心功能是通过 Claude API 做风格迁移，我的计划是先搭 HTML 骨架，再写 CSS 样式，最后写 JavaScript 逻辑包括 API 调用部分。然后它问我：这个计划可以吗，我开始执行？

我输入 yes。

然后终端开始滚动。

它创建了一个叫 xiaohongshu-writer.html 的文件。然后开始往里面写内容。你能在终端里看到它在做什么——”正在写入 HTML 结构”、”正在添加 CSS 样式”、”正在编写 API 调用逻辑”——每一步都有说明，不是黑箱操作。

大概五六分钟之后，它告诉我第一版完成了，可以打开浏览器测试。

我打开文件，界面确实出来了。三栏布局，有输入框，有按钮，整体配色是小红书的粉红色调，移动端看了一下也没有错位。

但有一个问题：我输入 API Key 之后，点击生成，报错了。错误信息是跨域请求被浏览器拦截。

Step 4 · 迭代和修正

这里我要说一个很重要的事：第一版跑不通是正常的。 不要因为第一版有问题就觉得工具不好用，真实的开发工作本来就是这样，没有一次写对的代码。

关键是你怎么描述这个问题。

我没有把报错信息复制给它，因为我看不懂那一长串英文报错。我用我能理解的方式描述了现象：

点击生成按钮之后，浏览器控制台有报错，好像是跨域的问题，API 请求没有发出去。

它立刻理解了问题所在。它解释说：直接在浏览器里调用 Anthropic API 会遇到 CORS 问题，因为浏览器的安全策略不允许前端直接跨域请求第三方 API。解决方案有几个，最简单的是用一个本地的 Node.js 服务做中转，或者用 Anthropic 提供的官方 SDK。它建议我用本地服务的方案，这样不需要部署，在自己电脑上跑就行。

然后它问我：我来改造一下方案，改成本地服务 + 前端页面的架构，需要你的电脑上有 Node.js，你确认有吗？

我说有。

它重新开始工作。这次它创建了两个文件：一个 server.js 作为本地服务，一个更新后的 index.html 作为前端界面。它还创建了一个 package.json，并且告诉我需要先运行 npm install 安装依赖，然后运行 node server.js 启动服务，最后打开 http://localhost:3000 访问工具。

我按照它说的步骤操作，每一步都成功了。

打开浏览器，输入 API Key，左边粘贴我的原始文章，右边粘贴一篇我觉得风格很对的小红书爆款，点击生成。

等了大概十秒钟，结果出来了。

Step 5 · 最终成果演示

我用了一篇自己写的关于时间管理的文章来测试，原文大概八百字，是那种比较正式的论述风格。参考的小红书文章是一篇关于早起的帖子，风格很典型——短句、感叹号、”姐妹们”开头、结尾问互动问题。

输出的仿写结果我截取一段给你看一下对比。

原文是这样的：

时间管理的核心在于优先级的判断。大多数人在面对繁杂的任务清单时，倾向于先完成容易的事情，将困难的任务推后处理。这种行为模式在心理学上被称为”拖延症”，其本质是对不适感的回避。

仿写之后是这样的：

说真的，时间管理这件事我想了很久。

你有没有发现——

每次打开任务清单，第一个做的永远是最简单的那件事？

困难的那个，总是往后排。

这不是懒，这是人的本能。

心理学叫它”拖延”，说白了就是：

你在逃避那个让你不舒服的感觉。

姐妹们，这个坑我踩了三年。

风格迁移的效果是真实有效的。断句、语气、情绪密度、互动引导，都对上了。它不是在简单地把长句切短，而是在理解原文意思的基础上重新用另一种语言逻辑表达出来。

这个插件现在还在我电脑上跑着。每次写完文章，五分钟之内就能出一个小红书版本，比我手动改快了十倍不止。

做完之后我想了很久

爽点说完了，我想说一个让我有点不舒服的部分。

整个过程里，Claude Code 在我的电脑上创建了文件，安装了依赖包，在本地启动了一个服务。这些操作它都事先告知了我，也都经过了我的确认。但我有没有真正看过它写的每一行代码？

没有。

我看了一眼 server.js，大概扫了十几秒，觉得”好像没什么问题”，就继续用了。这个判断的依据是什么？是因为我真的读懂了代码，还是因为结果能用，所以我默认它是安全的？

说实话，是后者。

这里有一个值得认真对待的问题：当 AI 的 Agentic 能力越来越强，用户对过程的感知就越来越弱。 它做的事情越多，你亲手做的事情就越少，你对整个过程的理解也就越浅。

这不是说 Claude Code 不安全，Anthropic 在安全机制上做了很多工作，它的每一步操作都需要用户确认，它不会在你不知情的情况下做任何事。但确认和理解是两件不同的事。你点了 yes，不代表你知道你在允许它做什么。

我在想一个类比：你叫了一个你信任的师傅来修水管，你在旁边看着，他每做一个动作都跟你说一声”我要关这个阀门了，可以吗”，你说可以。水管修好了，没有漏水。但你知道你家的水管结构现在是什么样的吗？你能在他走了之后自己处理下一次的问题吗？

这不是要你拒绝用这个工具。这是要你在用的时候保持一点清醒：你信任它，最好是因为你建立了验证机制，而不只是因为结果看起来能用。

至少，把它生成的代码存起来，知道它在你的电脑上创建了什么文件，知道它启动了什么服务。这是最基本的知情权。

这件事真正改变的是什么

我做完这个插件之后，跟几个朋友聊过这件事。有一个做了十年开发的朋友听完之后沉默了一会儿，然后说：

“你知道我花了多长时间才能做出这种东西吗？”

我知道他不是在抱怨，他是在描述一个正在发生的事实：开发门槛正在塌陷。

这不是第一次有人说这句话，从低代码工具出现的时候就有人说了。但 Claude Code 代表的那种塌陷和以前不一样。以前的低代码工具是把复杂的事情做成模板，你在模板里填空，能做的事情是有边界的。Claude Code 是把”描述清楚你想要什么”变成了唯一的门槛，而这个门槛的高低，跟你会不会写代码没有关系。

这对两类人的影响是完全不同的。

对普通人来说，这是一扇真正打开的门。那些烂在脑子里的想法，那些因为”不会技术”而一直没法实现的需求，现在有了一条路。你不需要学编程，你需要的是把你想要什么想清楚，然后说出来。这件事，一个擅长表达的人，一个习惯把复杂事情讲清楚的人，反而比很多技术背景的人更有优势。

对开发者来说，这件事要更复杂一些。初级的、重复性的、有明确规格的开发任务，正在变得越来越容易被替代。但这不意味着开发者的价值在消失，它意味着价值的重心在转移——从”能实现”转向”能判断”。知道什么方案是对的，知道为什么这样做比那样做更好，知道在 AI 给出的结果里哪里有坑——这些判断力，不是 Claude Code 能替代的。

更大的变化是在协作范式上。以前的人机协作是：人负责思考，机器负责执行简单指令。现在的人机协作正在变成：人负责定义问题和验收结果，机器负责规划和执行。中间那个”怎么做”的环节，正在越来越多地交出去。

这不是好事或者坏事，这就是正在发生的事情。

给想试试的人

如果你看完这篇文章想自己试一下，给你几个建议：

• 从一个真实的、具体的需求出发。 不要为了用工具而用工具，找一个你真正想解决的问题，哪怕很小。需求越具体，结果越接近你想要的。
• 描述需求的时候，想清楚这几件事： 交付物是什么形态（网页、脚本、还是别的）、核心功能的逻辑是什么、有没有技术约束、界面或者交互上有什么要求。把这些说清楚，不要怕啰嗦。
• 第一版跑不通很正常，继续描述问题就好。 不要复制报错信息扔给它，用你能理解的语言描述你看到了什么现象，它能理解。
• 保持知情。 每次它要执行一个操作，在点确认之前，花十秒钟看一下它说它要做什么。你不需要懂技术，但你需要知道它在你的电脑上做了什么。
• 把生成的代码存起来，知道它在哪里。 这是基本的习惯。

最后回到开头那个让我不安的感觉。Claude Code 确实在接管一部分工作，而且接管的范围还在扩大。但这件事有一个前提，一个它无法替代你做的前提：

你得先想清楚你要什么。

这句话听起来简单，做起来不容易。把一个模糊的想法变成一个清晰的需求，把”我想要一个更好的工具”变成”我需要一个能做 X、界面是 Y、技术约束是 Z 的工具”——这个过程本身就需要你真正想明白你在解决什么问题。

先说结论：如果你是认真写代码的开发者，Claude Code值得一试。它不是那种”帮你补全几行代码”的辅助工具，而是真正能理解你整个代码库、自主规划并执行多步骤任务的AI Agent。当然它也有局限性，具体往下看。

一、Claude Code是什么？

Claude Code是Anthropic官方推出的命令行AI编程助手，运行在你的终端里。注意，它不是VS Code插件，不是网页聊天框，而是一个真正的命令行工具——你在终端里跟它对话，它能读你的代码、改你的文件、跑你的命令、修你的Bug。

说出来你可能不信，我第一次用Claude Code的时候，它直接在终端里帮我重构了一个2000多行的老旧模块，从理解代码结构到制定重构计划，再到逐文件修改、运行测试，全程没让我操心。最让我意外的是，它居然自动处理了我代码里的循环依赖——这种事以前我得花半天时间才能理清楚。

这和GitHub Copilot那种”补全几行代码”的工具完全不同。Copilot更像是高级版的自动补全，而Claude Code是真正的Agent——它能理解整个代码仓库的上下文，自主规划和执行多步骤的开发任务。

核心定位：面向开发者的AI编程Agent，主打”终端原生”和”自主执行”。

开发背景：由Anthropic（就是做Claude的那家公司）推出，背靠强大的Claude系列模型，目前已经是编程Agent领域的头部产品之一。

二、用户规模与市场表现

说到数据，Claude Code虽然推出时间不算长（2024年底正式发布），但增长势头相当猛。

根据公开信息和技术社区的反馈，Claude Code在推出后的几个月内迅速积累了数十万开发者用户。尤其是在2025年，随着Claude 3.5系列模型的发布和使用体验的持续优化，大批从Copilot转投过来的开发者不在少数。

在编程Agent这个细分赛道，Claude Code已经和GitHub Copilot、Cursor形成了三足鼎立的格局。虽然从市场份额看，Copilot凭借微软生态优势仍然领先，但Claude Code在专业开发者群体中的口碑正在快速攀升——技术社区里”Claude Code真香”的帖子随处可见。

聊完数据，我们来看看它实际能做什么。

三、核心功能有哪些？

Claude Code的功能相当全面，我按使用场景整理了几个核心模块：

智能代码分析与理解

• 自动分析代码库结构和依赖关系
• 理解业务逻辑，识别代码意图
• 支持多文件联合分析

自动化代码编辑

• 精准修改指定文件和代码段
• 批量重命名、重构、迁移
• 自动处理跨文件的联动修改

命令执行与工具调用

• 运行构建、测试、lint等命令
• Git操作（提交、分支、PR）
• 文件搜索和批量处理

自主任务规划

• 规划模式：先审核步骤再执行
• 多代理协作：同时处理任务不同部分
• 异常处理：自动诊断错误并修复

MCP（模型上下文协议）集成

• 连接外部数据源（Google Drive、Jira、Slack等）
• 扩展工具能力边界
• 支持自定义工具开发

CLAUDE.md 项目配置

• 在项目根目录创建配置文件
• 定义项目规范、技术栈、编码标准
• 避免重复解释项目背景

说实话，用了一段时间后我最大的感受是：它真的在”帮你工作”，而不是”等你工作”。很多以前需要手动操作的重复性任务，现在直接交给它处理，效率提升肉眼可见。

功能聊完了，来说说它适合哪些人。

四、面向人群有哪些？

Claude Code并不是”人人可用”的大众产品，它有明确的用户定位：

用户类型	推荐指数	适用场景
后端/全栈工程师		大型代码库重构、API开发、微服务架构
前端工程师		组件开发、样式重构、项目迁移
DevOps/基础设施工程师		脚本编写、CI/CD配置、自动化运维
编程学习者		学习编程思路、代码审查、问题诊断
产品经理/非技术人员		需要一定技术基础，上手有一定门槛

如果你每天花大量时间写代码、处理Bug、或者维护大型项目，Claude Code能显著提升效率。但如果你只是偶尔需要写点小脚本，可能用不上它的全部能力。

知道适合谁了，看看具体怎么用。

五、应用场景有哪些？

结合我的使用体验，列举几个最典型的场景：

1. 大型代码库重构 这是Claude Code最擅长的场景之一。我曾经用它帮助重构一个3年没动过的Node.js项目，涉及到模块拆分、依赖更新、测试补全——以前这种活儿至少要一周，用Claude Code两天搞定。

2. 自动化测试生成 输入claude，告诉它”为这个模块生成单元测试”，它会自动分析代码逻辑，生成覆盖主要分支的测试用例，还能帮你运行验证。

3. Bug诊断与修复 把错误日志丢给它，它不仅能定位问题，还能给出修复方案并直接执行。我上次遇到一个棘手的类型错误，它愣是从3000行代码里揪出了源头。

4. Git工作流自动化 暂存、提交、创建分支、处理合并冲突——都可以在终端里用自然语言完成。claude "帮我把这个功能的改动提交，消息要清晰说明改了什么"这种操作完全没问题。

5. 文档生成与更新 注释、README、API文档，只要告诉它需求，它就能帮你生成或更新。我现在很多项目的技术文档都是它帮我起草的。

场景说完了，和竞品比比看。

六、和同类竞品相比，差异在哪？

编程Agent领域，Claude Code最常被拿来和GitHub Copilot和Cursor对比。我直接上一个对比表：

特性	Claude Code	GitHub Copilot	Cursor
交互方式	终端原生	IDE插件	IDE插件+桌面应用
Agent能力	强（自主规划执行）	弱（补全为主）	中（部分Agent功能）
上下文理解	整个代码库	当前文件	当前项目
多代理支持
定价	$20/月起	$10/月起	$20/月起
平台覆盖	全平台	VS Code为主	独立IDE

核心差异：

• vs Copilot：Copilot更像是”高级自动补全”，适合日常小任务；Claude Code是真正的Agent，适合复杂任务。
• vs Cursor：Cursor的IDE集成做得更好，界面更友好；Claude Code在终端操作更流畅，自动化能力更强。

如果你追求控制力、自动化和深度定制，选Claude Code；如果你更在意上手简单、界面友好，Cursor可能更适合。

对比完优缺点，分享几个使用技巧。

七、使用技巧

用了一周多，总结了几个能显著提升效率的技巧：

技巧1：善用CLAUDE.md配置文件 在项目根目录创建CLAUDE.md，提前定义项目规范、技术栈、编码风格。以后每次对话，它都能自动理解你的项目上下文，不用重复解释。

技巧2：先理解再执行 对复杂任务，先让它”读”相关代码，再提需求。比如：“先看看src/services/payment.ts的实现逻辑，然后帮我添加退款功能”——这样它理解更准确，输出质量更高。

技巧3：用规划模式处理复杂任务 对大型重构或迁移类任务，用Shift+Tab切换到规划模式。先让它列出执行步骤，你审核确认后再执行，避免走弯路

技巧4：模型选择有讲究 日常快速任务用claude-sonnet-4-6（速度快，效果够用）；复杂问题或需要深度思考时切换claude-opus-4-6（更强但更贵）。

技巧5：Git操作要明确 提交代码时，给它明确的commit message要求，比如：“用conventional commits格式，type是feat，scope是payment”。它会严格按照你的要求生成。

 技巧6：用管道结合其他工具 git diff | claude "review这些改动"、npm test | claude "分析测试结果"——这种组合用法能大幅提升效率。

技巧学会了，看看它能带来什么价值。

八、对企业和个人的价值

对企业用户：

对个人用户：

有个数据值得注意：有社区开发者测算过，如果直接调用API做同样强度的编程辅助，月成本可能高达数千美元，而Max 20x计划只需200美元/月。所以对于重度用户来说，订阅模式反而更划算。

价值清楚了，最后聊聊钱。

九、产品定价是怎样的？

Claude Code本身不单独收费，而是绑定Anthropic的订阅体系。简单说就是：你订阅了Claude，就能用Claude Code。

计划	价格	Claude Code	用量限制	适合人群
Pro	$20/月（年付$17/月）		每5小时44K tokens	个人开发者
Max 5x	$100/月		每5小时220K tokens	全职开发者
Max 20x	$200/月		基本无限	重度用户/多代理
Team高级席位	$100/席位/月		高级席位5倍用量	开发团队
Enterprise	定制		500K上下文	企业级需求

我的建议：

• 个人开发者从Pro开始够用
• 重度用户或需要跑自动化工作流的，Max 20x更值
• 小团队可以混合配置（部分标准席位+部分高级席位）

定价说完了，给个总结。

十、官网和下载地址

总体评价

说实话，Claude Code让我重新认识了”AI编程工具”这件事。之前我以为这类工具就是”帮你写几行代码”，但Claude Code真正做到了”帮你完成工作”——它理解你的意图，规划你的任务，执行你的指令，最后给你一个能用的结果。当然它不是完美的，终端操作对新手不够友好，上下文窗口虽大但处理超大型单体仓库仍有限制。但对于真正想用AI提升编程效率的开发者，它已经是目前市面上最接近”AI编程助手”这个概念的产品了。

评分（满分5星）

• 易用性：（3/5）终端操作有学习曲线
• 功能性：（5/5）Agent能力业界领先
• 稳定性：（4/5）偶发性token消耗异常
• 扩展性：（5/5）MCP集成和配置化强大
• 性价比：（4/5）重度用户Max计划很值

综合评分：4/5星

一句话总结

Claude Code可能不是最容易上手的编程AI，但如果你愿意花时间掌握它，你会发现它是你迄今为止最接近”AI同事”体验的工具——不是帮你补全代码，而是真正帮你完成工作。