为什么每个垂直领域都需要开发一个自己版本的 Claude Code？(2)：以终为始，先确定一个目标

先讲结论：

学习 CC，成为 CC，踢掉 CC！

How-to? CC 只是中间层，只是 Context programming 的一种，只是用好基模的众多方式之一种，所以最终还是要找到一个适合自己场景的基模，想办法微调 ta ，让 ta + 你，来完成对 CC 们的绝杀

以终为始，动手做项目之前先想好这个项目的产出，于我而言，科研领域有一个特别明确且重复度极高的任务：「复现最新的 Paper」，我们就拿这个目标作为 OKR 里的 O，反过来拆解成各个小的 KR，从头设计一个适合实现这个目标的 ”CC“。

说一下项目目标

为实现「复现最新的 Paper」的目标，这里选的是 Paper2Agent 这个工作， 仨原因：

1. 2025.9.8 发布预印，斯坦福出品名门正派，最重要的是它思路很好：不仅仅把论文变成可执行的代码（代码本身还是死的），它是直接把论文变成了 MCP Server，论文变成活的了！直接可以调用！ 这件事情本身难度很高，我们如果能把这个事也办了，别的任务就不在话下。
2. Paper2Agent 这个工作本身完全基于 CC 的 subagent 机制，本身就是一个我们一直大力推广的 subagent 的极好案例，与 CC 的契合度几乎 100%，拿这个例子来反推我们自己的 CC 开发工作简直再合适不过！
3. 论文一作 Jiacheng Miao，在斯坦福的博士后研究方向是 AI+遗传学，主要聚焦于构建可靠的 AI co-scientists 以加速科学发现，是我们需要的背景。

Paper2Agent 本身主要通过 CC 自身的机制，把论文复现这件事情分成了几个 subagent：用 「环境 Agent」 帮论文代码配置隔离、可复现的运行环境，用 「提取 Agent」 把论文逻辑转化为标准化工具调用，再以 「测试 Agent」 迭代验证工具输出，确保和论文结果 100% 匹配。

示例方面，利用 Paper2Agent 成功构建了 AlphaGenome 智能体（2025.6发布），用于解释基因组变异，Scanpy（2018.2 月发布） 和 TISSUE（2024.3 月发布），分别用于开展单细胞数据分析和空间转录组学分析，处理 AlphaGenome 论文时，CC 在 3 小时内生成了 22 个可用的 MCP tools；给 Scanpy 构建单细胞分析代理时，它不仅 45 分钟完成工具开发，还基于论文逻辑自动编写 「质量控制→聚类→注释」的完整工作流指令，用户只需上传数据文件，CC 就能驱动代理完成全流程分析。

• 论文：https://arxiv.org/pdf/2509.06917
• 代码：https://github.com/jmiao24/Paper2Agent

CC 背景相关的几点更新

「Claude Code is not a product as much as it’s a Unix utility」

「Claude Code writes 80% of Claude Code」

1. CC 的第一作者 Boris Cherny（@boris_cherny）和后来加入的 PM Catherine（@_catwu) 5 月份的一个访谈:https://youtu.be/zDmW5hJPsvQ ，里面 Boris 给出了他写 CC 的「初心」：与其说 Claude Code 是一款产品，不如说它是一个 Unix 工具 ，而 Unix 开发哲学是我们都耳熟能详的，这里贴张图（BTW，当前的主要维护者看起来更多的是 Thariq Shihipar @trq212）：

另外，Boris 提到他用 CC 写了 CC 本身大约 80% 的代码，这也从侧面给了我们从头写 CC 更多的信心。

1. 这里还有一个 2025.9.24 日做的，关于 CC 的二号 founding engineer（奇怪的称谓...）Sid Bidasaria @sidbidasaria 的访谈回头大家可以仔细看看：https://newsletter.pragmaticengineer.com/p/how-claude-code-is-built,里面提到很重要的一点:每天有大约 5 个版本发布，并且在两天内就能构建出新特性的多个原型，这意味着我们多年来习以为常的「敏捷开发」已经不再敏捷，现在只要我们有想法，完全可以同时让 CC 实现所有想法，然后从实现好的版本中调一个出来发布，另外 Sid 同学比 Boris 在技术栈方面介绍的更为全面：

• 主要还是 Ink： 一个基于 React 的渲染引擎，用于构建命令行界面（CLI）应用程序。它提供了与 React 在浏览器中相同的组件化 UI 构建体验，但适用于 CLI 命令行应用程序
• Yoga：Ink 拿来做布局引擎，来实现 Flexbox 布局，支持 CSS-like 属性，并且对于熟悉 React 的开发者来说易于上手
• 其它的，Bun 用来做构建，开发语言当然是 Typescript

1. 为了应对 OpenAI 发布 AgentKit，抢夺企业 Agent 编排市场，Anthropic 做了个「艰难的应对」 ：把 Claude Code SDK 改名为 Claude Agent SDK... 如果一定要在 OpenAI AgentKit 和 Claude Agent SDK 之间选择的话那肯定是要选后者，前者还在忙着抄 DIFY、Coze 的后路（这点上能干过中国人就奇了怪了），后者才是真正自下而上、从实践中来到实践中去的好方案.

Claude Agent SDK 的核心设计理念就是「Giving Claude a computer」（我猜这就是为什么 kimi 新出的功能叫 kimi computer 的原因...）使其能够像人类一样执行任务。这意味着代理可以使用程序员日常使用的工具，如编辑文件、运行代码、调试和迭代直至成功。通过这种方式，Claude Agent SDK 不仅支持编码任务，还能够执行各种非编码任务，如阅读 CSV 文件、搜索网页、构建可视化、解释指标等。这种设计理念旨在使代理更加通用和高效，能够在多种工作流程中发挥作用

替代方案分析

1. Gemini-code：

超长上下文是核心优势，百万 tokens 的上下文相当于 1500 页文档！ 另外多模态支持也非常好，真价钱便宜量又足，适合快速原型和大项目全局理解，但代码质量和自动化深度不及 CC

1. cursor-agent：

多模型支持和灵活的工具调用，适合终端操作和脚本自动化，但缺乏 CC 的 subagent 协作, git 相关 tools 也木有，感觉更像是应对 CC 的仓促之举

1. Qwen-code

fork 自 Gemini-code ，主要目的是推广 Qwen 家大模型们，中规中矩，PR 稿上说有 MCP 和 类 subagent 支持，实际上手体验远不及 CC

1. iFlow

同样是阿里系通义出品，主打一个场景通用性，眼光够。同样支持多模型和宣称的 subagent，内置市场扩展能力强，但整体流程自动化和代码质量管控比 CC 弱

1. CodeBuddy

这种事当然少不了腾讯大企鹅，CodeBuddy 更传统一些，更聚焦于代码补全与智能文档生成，适合开发者辅助，定位更 copilot，subagent 直接留了个命令，运行完了之后提示正在开发中，，，一个字，绝！自动化流程依赖基模，这个不能太强求 CodeBuddy 本身

1. ampcode

据说评测里面跟 CC 同属 S 级，效果用下来感觉确实不错，优点是支持团队多人协作，每个对话的 session 都可以选择团队共享，算是一个「个人长期记忆」和「团队共享长期记忆」的雏形

1. codebuff

开源（CC 逼得...)，做的很早，YC 毕业，创始人工作狂据说 007，初心是 auto 模式，就是解决问题过程尽量不需要用户参与，多专家代理协同编辑，在局部修改精度上优秀，且比 subagent 更进一步提出了 agent store 的概念，缺点是过于强调端到端，没有 CC 的 ToDoWrite 工具，个人观点是这个工具很大程度上让 CC 于其他追随者拉开了距离。

1. droid(最看好这个)

推荐！2B 定位准，可私有部署，跟 CC 不同的是不完全依赖基模，而是通过层次化的 Agent 设计，力求超越 CC。提供了 5 种 Agent：Code Droid，主打写代码；Knowledge Droid，提供深度研究等类 RAG 体验；Reliability Droid，着眼于 Debug ，事故原因、复盘报告，都是实际需求；Product Droid，PRD撰写和项目管理，类似 linear 的 PM 的活；Tutorial Droid，这个是最有特色的，帮助用户学习如何使用 Factory 平台这个事情作为核心的 5 个场景之一，很有市场洞察力，总之他家的思路我个人是非常看好的

1. OpenCode

这个看的不多，虽然 github 上 star 挺多，但似乎主要关注的点在 TUI 的交互上，让「界面党」同学们感觉爽，但 CC 给的是效果，是疗效，单单要爽的话可能还真不需要找 OpenCode...

1. Aider

资格最老，类似 OpenCode，没有更多想法

1. Warp

这个很神奇，最早关注到 Wrap 是因为他们的初衷是 AI 化终端界面，给人的感觉是想通过加入 AI-native，做一个「更好的 iTerm」，由于大部分代码是 Rust 写的，速度确实很快，体验也有写不同，但在「更好的 iTerm」这个点上反正我是用了一段时间后又乖乖回到了 iTerm 身边，因为 iTerm + Simon Willison 的 llm 工具已经完胜。但在 CC 出来以后，Warp 其实是放弃了原先的定位转而主攻 CC 的场景，效果不错，而且给了很多 credits，吃人嘴短，也没啥好说的了😂

1. Kode

这个是最野的一个！最初是由于 Boris 发布 CC 的时候有一个版本不小心把 source-map 文件也发出来了，玩 js 的大神们看到这个肯定就明了了，有了这个就相当于有了源码，Kode 的前身就是一帮小伙伴们基于特定版本的 CC 「逆向」了一下，反推出了大部分 CC 那个版本的 code，所以研究这个版本反而是了解 CC 最原始最正宗的方法

新鲜感悟

1. 最近反复说的一句话是：不要把 CC 视为一种工具和方法，要把 CC 视为一种方法论，把 ta 掰开揉碎吸收到设计原理，反过来从问题出发，重新导出适合自己垂类业务的 CC
2. 在尝试着从类似 OpenCode、codebuff 这种大而全的方案出发之后，还是决定从头开始构建，一开始可以短平快的通过 Python 构建，但最终还是需要用 go 或者 typescript，因为早晚有一天用户会因为当前大模型慢吞吞的吐 token 而心生怨念的...

上一篇我们说了为什么每个垂类行业都应该有一套自己的 CC 的原因，这一次我们介绍了背景，下一次，我们就要真正上手搓代码，实现一个 1000 行以内的 CC 雏形。

(广播：为表明贯彻 AI 落地垂类之决心，花了 300 块大洋准备把本公众号的名字改成 「AI 生物设计」，倒要看看 AI 这把锤子到底能敲掉多少生物设计领域的钉子！ 😄)