❌

普通视图

发现新文章，点击刷新页面。
昨天以前首页

Claude Code vs. Codex：终极指南

✇掘金 前端
作者 jerrywus
2026年3月11日 17:06

翻译自：Claude Code vs. Codex: The Definitive Guide

我用了几个月 Claude Code，后来转投 Codex，最近又换回了 Claude。选它的原因跟 benchmark 跑分无关。我也拿同一个任务测试过两者。

本文内容：我会聊聊 Claude Code 和 Codex 的各个方面，驱动它们的旗舰模型 Opus 4.6 vs. GPT-5.3-Codex 有什么区别，哪些因素真正影响你的 AI 编程体验，以及一个小型案例——我是如何用这两个工具搭建同一个 RAG pipeline 的。

先说清楚，这篇文章大概需要 12 分钟阅读时间。如果你打算每个月花 200 美元订阅其中之一，这时间花得值。

Opus 4.6 vs. GPT-5.3-Codex：任务完成时间跨度

Codex 和 Claude Code 之间有一个可靠的对比维度：任务完成时间跨度（Completion Time Horizon），详见此处。

这个指标回答的问题是：这个模型能可靠地完成多长时间的任务？ 任务完成时间跨度指的是模型以一定可靠性成功完成任务的时长（按人类专家完成时间衡量）。所以一个"2小时跨度 50%成功率"意味着：给你一个人类专家需要 2 小时的任务，AI 大约有五成把握能搞定。

Image

这项研究为每个模型配置了合适的 scaffold，包括 Claude Code 和 Codex。所以虽然焦点在模型本身而非 scaffold，但我们也能借此了解这些 scaffold 有多可靠。它告诉我们这些编程 agent 能处理多难、多长的任务。

如图所示，Opus 4.6 和 GPT-5.3-Codex 之间差距很大。Opus 4.6 在 50% 成功率下的任务完成时长是 12 小时，而 GPT-5.3-Codex 是 5 小时 50 分钟。这个差距在 80% 成功率时有所缩小。

这清楚地表明两个模型之间存在差距，进而也体现在 Claude Code 和 Codex 上——它们处理困难任务的能力有所不同。但这个差距不一定直接映射到你用它们做的事上，心里有点数就行。

Claude Code 更快，但速度没那么重要

Claude 比 Codex 快是出了名的。但跟编程 agent 打交道是长期过程。

如果一个 agent 完成任务只用了一半时间，但之后需要你花 10 分钟调试那破玩意儿，而另一个虽然多花了点时间实现，但完成后不用你盯着——那多出来的时间 100% 值得花。

这不是说 Claude Code 或 Codex 更容易犯错的——只是你自己评估这些 agent，或者听别人吹嘘它们的编程速度时，这句话值得记在心里。

任务类型对 agent 很重要

Codex 和 Claude Code 的表现取决于你用它做什么任务。在 AI 工程任务中，可能一个表现更好；但在 Web 开发任务中，同一个模型可能被吊打。

哪个编程任务更适合 Codex 或 Claude Code？这个研究做得还不够。

比如说，低级编程（low-level programming）该用哪个就不清楚。理想情况下，你应该在简单可验证的环境中先测试两者，再决定all in。但对大多数人来说，花 300-400 美元两个都买下来不太现实。

要全面对比两个 agent 在各种编程任务中的表现，是个有趣的研究方向。但也没那么轻松，因为这些 agent 和驱动它们的模型每隔几个月就会大幅变脸。

两者是如何诞生的

Claude Code 最初是 Anthropic 的 @bcherny 做的副业项目，做了个终端原型，能跟 Claude API 交互、读文件、跑 bash 命令。

内部团队到第五天就有一半人开始用了。然后 Claude Code 在 2025 年 2 月 24 日以研究预览版发布，用的是 Claude 3.7 Sonnet。花了一段时间被开发者大规模采用，之后 Anthropic 也发布了 VS Code 扩展。

OpenAI 这边，最初的 Codex 模型是 12B 参数的 GPT-3 微调版，基于 GitHub 代码，最终驱动了第一版 GitHub Copilot。但新的 Codex 是完全不同的产品。

Codex CLI 在 2025 年 4 月 16 日首发是终端 agent，之后随着更好的模型不断进化。最新版 GPT-5.3-Codex（2026年2月5日）被 OpenAI 称为"第一个参与创造自己的模型"。

@GergelyOrosz 做了两个很有意思的采访，分别关于 Claude Code 和 Codex 的开发者，涉及技术栈、开发方式、以及各自是怎么起步的。值得一看。

👉 Codex 是怎么构建的

2025年9月24日

Claude Code 是怎么构建的？Claude Code 自己写 90% 的代码，工程师每天大概提交 5 个 PR，人均 PR 产出比去年增长了 67%，而团队规模翻了一倍。更多细节在今天的深度报道里：newsletter.pragmaticengineer.com/p/how-claud… @bcherny, @_catwu, @sidbid）

技术栈和驱动模型

Claude Code 用 TypeScript 写的，用 React + Ink 做终端 UI。打包成单个 Bun 可执行文件（Anthropic 在 2025 年 12 月收购 Bun 就是为了这个）。它用的 Opus 和 Sonnet 模型都支持 100 万 token 的上下文窗口。

Codex CLI 用 Rust 写的，追求性能、正确性和可移植性。OpenAI 甚至把这个 Rust TUI 库 Ratatui 的维护者挖来了团队。

两个 CLI 工具都是围绕模型包了层薄薄的外壳，通过 API 调用。我注意到用 Claude Code CLI 时有些小"故障"，在 Codex 上不太明显——考虑到技术栈，这也意料之中。

不过这些故障也就是轻微烦人而已，真的不影响编程体验。

Benchmark 很接近，但有细节差异：Token 经济性

最大的性能差异不是准确率，而是 Token 效率。Morphism 的 Opus vs Codex 全面评测 揭示了一个有趣的差距。

Image

在相同任务上，Claude Code 比 Codex 多消耗 3.2–4.2 倍的 Token。 做一个 Figma 插件，Codex 用了 150 万 Token，Claude 用了 620 万。

如果这是真的，意味着你花同样的钱订阅 Claude Code，更容易撞到 Token 上限。

感觉最重要

Claude 像个帮你干活的高级工程师，Codex 像个承包商，你把任务丢给它，然后回来取结果。

这是开发者描述两者差异的普遍方式。

据报 Claude Code 有很强的交互感，还有深度推理能力——这跟 Opus 的定位相符。它会问你问题，展示推理过程，解释它的做法。虽然我那一次对比实验里没这种情况，但从用了好几个月的经验来看，我能确认这是真的。

Codex 以第一次尝试的准确率著称，代价是实现速度稍微慢一点。

话虽如此，如果你在 AGENTS.md 里具体说明你想要什么，两者行为的差异会大幅缩小。如果你明确要求模型在开始干活前跟你确认实现计划，它就会照做——不管你用的是"高级工程师"agent 还是"承包商"agent。

这不是说两者真的没区别——区别是有的。

只是没你在 X 上看到的那么夸张。

快速数据

VS Code Marketplace 上，Claude Code 有 610 万安装量，评分 4/5；Codex 有 540 万安装量，评分 3.5/5。

GitHub 上，Claude Code 大约 65–72K 星，Codex 约 64K 星。

Image

为什么我现在换回 Claude Code

Anthropic 的生态拉力强

选 Codex 还是 Claude Code 不只是编程问题。你订阅任何一个，等于订阅了整个 Anthropic/OpenAI 生态，这个因素值得考虑。

Image

我个人觉得 Claude 正在变成一个像 Apple 那样火热的生态，现在有 Claude Cowork、Claude Chat 和 Claude Code。Anthropic 似乎也在用 Claude app 慢慢搭建一个更安全、更温顺的 OpenClaw（主动式个人 agent），零敲碎打的功能正在逐步推出。

3月7日

今天我们在 Claude Code 桌面版推出本地定时任务。创建一个你想定期运行的任务计划，只要电脑醒着它们就会跑。

OpenAI 这边，目前我没看到什么诱人的东西。除了 Codex，其他的都挺无聊。我没感觉到一个生态，只感觉是零散的碎片，而且外面有更好的替代品。

我已经在用 Claude Chat 而不是 ChatGPT 了。对我来说，跟 Opus 相比，ChatGPT 现在基本没法用。UI、聊天风格、模型选择，没有一个让我有动力用 ChatGPT。

所以呢，因为我已经在高频使用 Claude Chat，打算折腾 cowork，目前没看到从 Claude Code 迁移到 Codex 有什么决定性的改进。换回 Claude Code、每月省下 200 美元，这决定做得相当轻松。

这成了影响我决定换回 Claude 的重大因素。

价格

Claude Code 和 Codex 的价格基本一样：

入门：都是 20 美元/月

高级用户：Claude Code 有个 Max 5x 档，100 美元/月

重度用户：都是 200 美元/月

Claude Code 真正亮眼的是它有个 100 美元的中档，而不是从 20 美元疯涨到 200 美元。而且我相信 Max 5x 计划（100 美元/月）对大多数开发者来说足够了。

所以可以说，Claude Code 实际上更便宜，因为它允许你选一个更便宜且够用的档，而不是逼你爬上价格阶梯。

技能和插件：开发者生态

技能（Skills）在 Claude Code 和 Codex 之间是兼容的，所以用哪个都感觉不出差别。但大多数技能中心和仓库都以 Claude Code 命名，可能有点混淆。

其他大多数事情也这样。你在 Reddit、X 或博客上看到的关于编程 agent 的帖子，大多关于 Claude Code 而不是 Codex——尽管两者原理相同。这本身就说明了很多问题：受欢迎程度和社区规模。

Codex 比 Claude Code 晚很久才支持技能和插件。但插件没有技能那么兼容。而且 Codex 的插件支持刚起步，没多少可用。

也就是说，很多开发者，包括我，根本不用插件。所以除非你特别需要各种插件支持，这方面不用纠结，也别把它当作选择依据。

RAG Pipeline：案例研究

我选了一个可以量化评估的任务来对比。问题是做一个落地页这种任务没法量化：一个人可能觉得好看，另一个可能说是紫色渐变的垃圾。

所以我选了个简单的 RAG pipeline 任务，因为生成的答案可以用数字衡量准确性。

如果你想做类似的对比，其他好想法包括：训练 vision model 或微调 LLM，或者测量低级程序的性能。

搭建检索 pipeline 是 AI 工程师的常见任务，你工作中可能用到 Claude Code 或 Codex。我让这两个编程 agent 给我搭一个论文问答 RAG pipeline。流程很简单：

  1. 取一批论文，提取文本
  2. 把内容分块（chunk）
  3. 把每块 embedding 到向量空间
  4. 用户提问时，找到跟问题 embedding 最接近的块
  5. 以原始形式检索出相关块（不是 embedding）
  6. 用这个上下文回答用户问题

这个任务足够简单，可以一次session 做完，但细节很复杂，对输出影响很大：用哪种分块策略、选什么 embedding 模型、用什么向量存储、如何处理"哪个块更接近查询"的置信度、是否重写用户问题来帮助找到更相似的块……

实验设置

我从 @huggingface 过去一周的每日论文里选了 5 篇，建了一个测试集（100 道题及标准答案），用来测试 Claude 或 Codex 的实现质量。

对两个 coding agent，我都是这么要求的：

  • 做一个 Python RAG pipeline
  • 用 PyMuPDF 处理所有 PDF
  • 为这个用例选一个好的分块策略
  • 创建 embedding 和持久化本地向量索引（你选）
  • 用 llama-3.1-8b-instant 生成最终答案
  • 如果没有足够证据，不要 hallucinate，返回 fallback

对 Codex 和 Claude Code，我都用了最流行且默认的模型：gpt-5.3-codex 和 Opus 4.6，都用 High effort（推理深度）。都没有 AGENTS.md。

它们怎么实现的 pipeline

我没注意到两个 agent 思考任务的方式有什么明显差别，除了 Codex 更啰嗦，会解释它的计划以及要做什么。Claude 直接写文件，执行命令，不说那么多。

Codex 完成任务比 Claude 花了更长时间。

更重要的是，Claude 端到端测试了脚本，确保 pipeline 能用。

Codex 则是做完了实现，但没有测试或运行程序，只是告诉我 pip install 依赖然后运行脚本。自然，我跑的时候报错了，Codex 解决了。Claude 的脚本跑起来一点问题没有。

我注意到 Codex 有这个模式：很多脏活累活它留给你做，而不是自己动手。

Codex 会告诉你并主动处理环境问题或实现困难，Claude 则自行修复——这取决于你的偏好，可能是好事也可能是坏事。

我还注意到，Codex 在新会话中第一个 token 的响应时间可以高达一分钟，Claude Code 这边短得多。

Claude Code vs. Codex 实现

两个 coding agent 的方案惊人地相似：

  • 都选了 all-MiniLM-L6-v2 作为 embedding 模型
  • 都选了 k=5 做 Top-K 检索
  • 都在 system prompt 里限制 LLM 只准用提供的上下文

但这些地方它们走了不同的路：

  • 向量存储：Claude Code 选了 ChromaDB，Codex 选了 FAISS——一个更底层的相似度搜索库，更省内存更快。
  • 分块：Claude Code 用了递归字符分割。先试 \n\n，然后 \n，然后 "."，然后 " "。目标是 1000 字符，200 字符重叠。Codex 用了句子级别的词分割，每块最多 220 词，40 词重叠。Claude Code 按结构分割（段落→行→句子→词），按字符计量。Codex 先按句子切，然后打包进词预算的箱子里。Codex 的方法尊重句子边界，避免句子中间切断，但 220 词对这种上下文可能太小（学术文本）。
  • 检索：两者都选了 Top-5 块。Claude Code 返回原始 L2 距离，Codex 返回内积（cosine）分数。
  • 置信度：Claude Code 对最佳 L2 距离用单一阈值（>1.2 = 不相关），然后检查低置信度与高置信度块的距离平均值。Codex 用多标准三档：强、中等、不足。
  • 代码架构：Claude Code：扁平函数，各模块常量，无模型一致性输入验证。Codex：OOP pipeline 类，集中配置，dataclasses，argparse CLI，模型一致性验证。Codex 明显工程化程度更高、可配置性更好。在更大更严肃的代码库里，这很关键。

结果

用 gpt-4 做 LLM-as-a-judge，两个 pipeline 的答案按四个标准比较：正确性、完整性、相关性、简洁性。

Image

100 道题中，Claude Code 赢了 42 道，Codex 赢了 33 道，25 道平手。 Claude 赢主要是因为它的置信度阈值更松，可能还有生成温度稍高（0.2 vs Codex 的 0.1）。

加点盐

这只是个非常简单的设置。我主要是好奇两个 coding agent 实现同一个封闭任务时有什么不同的做法。在专业环境里，是开发者拍板整体架构：分块方法、向量数据库、检索策略等。而且在专业环境里，做这类系统需要更多测试和迭代改进，以及更可靠的测试集和验证。

不过可以预期，一个不太有经验的初级开发者做 RAG pipeline，会把这些决策交给 AI。

选一个吧

我觉得选 Claude Code 还是 Codex，没有绝对错误的选择。两者都比现有格局的模型强，完成任务的水平差不多。

我的两大因素是：Anthropic 生态，以及 100 美元/月的价位段。即使我需要升到 200 美元/月 档位，还是会为了前者留在 Anthropic 的 Claude Code。

最重要的是你用这些 scaffold 做什么，以及怎么用。

这个比任何 benchmark 都能更好地判断哪个更适合你——没有标准答案，只能凭感觉。你把两个都试过之后，哪个用起来更舒服，答案就在你心里。

有开发者比如 @steipete 坚决站 Codex，也有人相信 Opus 就是被 OpenAI 模型吊打。

我觉得两边都对，因为他们的工作流不同，对这些 coding agent 的"品味"也不同。

如果你犹豫不定，建议先试两个的 20 美元/月 版本，用跟你相关的编程领域，最好在几个可验证的任务上测试。

最后，跟其他 AI 相关的东西一样，格局几个月就变一次。你现在喜欢哪个，三个月后 agent 行为可能漂移，或者新模型出来了。

AI 领域很少有全球通用的标准答案，这个话题也不是 ;)

为什么每个程序员都应该试试 cmux：AI 加持的终端效率革命

✇掘金 前端
作者 jerrywus
2026年3月6日 10:49

一个来自 lazygit 作者的终端管理神器，让你的终端效率直接起飞

前言

作为一名程序员，你是否经历过这样的场景：

  • 同时开着多个项目，每个项目都要开一个终端窗口
  • 切换分支的时候手忙脚乱，鼠标在终端和 Git GUI 之间来回穿梭
  • 想看日志又不想关掉当前的开发环境，只能硬着头皮开新标签页
  • 文件管理靠 cd + ls，每次都要输入一长串路径

以上这些破事我全遇到过。传统终端的操作方式真的该淘汰了。今天要介绍的工具叫 cmux，来自 lazygit 的作者，用完之后你会觉得以前的日子简直是原始人。

cmux 是什么？

cmux（Composite Mux）是一个终端复用器，类似于 tmux 但更加现代化。它的目标是：让你在一个终端窗口里完成所有操作，再也不用来回切换窗口。

直接看效果：

image.png

左边是项目导航，右边是终端面板，底部还集成了浏览器。一个窗口就是一个完整的工作空间，不用再满屏幕找窗口了。

核心功能一览

1. 项目分类导航

左侧边栏可以按项目维度组织终端会话。比如你有三个项目，每个项目开 2-3 个终端，切换项目就像在文件管理器里切换目录一样。项目再多也不乱。

2. 终端灵活拆分

这是 cmux 最实用的功能：

操作 快捷键
纵向拆分（上下排列） Ctrl + Shift + D
水平拆分（左右排列） Ctrl + D
新建标签页 Ctrl + T
跨终端切换 Ctrl + Option + 方向键

上面跑着开发服务器，中间写着代码，底部开着数据库终端。一个窗口搞定全部，不用满世界找窗口。

3. oh-my-zsh 无缝集成

cmux 能自动识别你的 oh-my-zsh 配置，包括主题和插件。之前配置的个性化设置直接迁移，不用重新折腾。

4. 内置浏览器

没错，cmux 还带了个小型浏览器。查文档的时候不用再切换到 Chrome，看完直接切回来继续干活。

image.png

插件生态

cmux 支持自动识别终端里的各种效率工具。装上这几个插件，你的终端会变得特别好用。

lazygit - 终端里的 Git 客户端

官方网站: github.com/jesseduffie…

image.png

用命令行操作 Git 的痛点：

  • 想看某个文件的修改历史，要敲 git log --oneline --graph --all -- filename
  • 想看某次提交的具体内容，grep 半天找不到重点
  • 合并分支的时候提心吊胆，生怕冲突没处理好
  • 只想看哪些文件改了，也要输入 git status

lazygit 就是为了解决这些问题而生的。

安装和使用：

# 安装
brew install lazygit

# 运行
lazygit

lazygit 能做什么？

  • 单个文件内部分行暂存：按空格键暂存选中行，v 键选择多行，a 键暂存整个 hunk
  • 交互式变基：按 i 键进入变基模式，可以 squash、fixup、drop、edit 提交，还能调整提交顺序
  • Cherry-pick：shift+c 复制提交，shift+v 粘贴
  • 二分查找：按 b 键开始 git bisect，精确定位问题提交
  • 强删工作区：shift+d 可以一键清空所有未提交的修改
  • 修正旧提交：shift+a 可以用当前暂存的修改去修正历史提交
  • 筛选视图：按 / 键筛选分支、提交等列表
  • Worktree 管理：按 w 键创建 worktree，多分支并行开发
  • 撤销/重做：z 撤销，ctrl+z 重做
  • 提交图：窗口够大时会显示彩色提交图
  • 比较提交：shift+w 比较两个提交之间的差异

我用 lazygit 之后，再也没打开过 SourceTree。键盘操作确实比鼠标快太多了。

在 cmux 中装上 lazygit，你可以一边写着代码，一边用 lazygit 管理版本。遇到需要提交的时候，Ctrl + Option + 方向键 切换到底部终端，输入提交信息，一气呵成。

fresh - 现代终端文本编辑器

image.png

官方网站: github.com/sinelaw/fre…

很多开发者习惯用 VS Code 或 Sublime Text 这种图形化编辑器，但有时候在终端里工作更高效。fresh 就是为了解决这个问题——把 VS Code 的体验带到终端里。

安装和使用：

# 快速安装
curl https://raw.githubusercontent.com/sinelaw/fresh/refs/heads/master/scripts/install.sh | sh

# 或者用 homebrew
brew tap sinelaw/fresh
brew install fresh-editor

# 运行
fresh

fresh 能做什么？

  • 零配置：安装后直接能用，不需要任何配置
  • 熟悉的热键：Ctrl+S、Ctrl+Z、Ctrl+F 这些标准快捷键都能用
  • 完整鼠标支持：像图形编辑器一样用鼠标操作
  • 命令面板：一个快捷键就能搜索文件、运行命令、切换标签页、跳转到任意行
  • 多光标编辑：同时选中多处进行批量编辑，和图形编辑器一样的体验
  • 文件管理：内置文件浏览器，支持标签页、git 状态显示、模糊搜索
  • LSP 支持：跳转到定义、引用、悬停显示文档、代码诊断、自动补全
  • 内置终端：集成终端模拟器，支持键盘捕获模式和会话持久化
  • Vim 模式：也支持 Vim 风格的 Normal/Insert/Visual 模式
  • 主题系统：内置多套主题，支持可视化主题编辑器
  • 插件系统：用 TypeScript 编写插件，Sandboxed QuickJS 环境运行
  • 多语言：支持 11 种以上语言，包括中文

这是一个终端文本编辑器，和 VS Code/Sublime Text 体验类似，但运行在终端里。特别适合那种想在终端里完成所有工作的人。

yazi - 快到飞起的终端文件管理器

官方网站: github.com/sxyazi/yazi

image.png

传统的终端文件管理：

cd /long/path/to/some/directory
ls -la
cd subfolder
ls
cd ..

每次都要 cd，路径一长简直崩溃。

yazi 带来了全新的体验，基于 Rust + 异步 I/O，速度极快。

安装和使用：

# 安装
brew install yazi

# 运行
yazi

或者直接作为命令行工具用：

# 用 yazi 打开当前目录
yazi .

# 选择文件后自动 cd 进入
yazi

yazi 的核心特性：

  • 全异步支持：所有 I/O 操作都是异步的，CPU 任务分布在多个线程
  • 内置图片预览：支持多种终端协议（kitty、iTerm2、WeTerm 等）
  • 内置代码高亮：结合预加载机制，文件加载速度极快
  • 插件系统：用 Lua 编写插件，支持 UI 重写、功能扩展
  • 虚拟文件系统：支持远程文件管理、自定义搜索引擎
  • 数据分发服务：基于客户端-服务器架构，实现跨实例通信和状态持久化
  • 包管理器：一条命令安装插件和主题
  • 集成 ripgrep、fd、fzf、zoxide
  • Vim 风格交互：输入、选择、确认、通知组件，cd 路径自动补全
  • 多标签页支持：跨目录选择、可滚动预览（视频、PDF、压缩包、代码、目录等）
  • 批量重命名：批量修改文件名
  • 归档解压：直接在终端内解压文件
  • Git 集成：显示文件修改状态
  • 主题系统：支持鼠标、回收站、自定义布局

yazi 最惊艳的功能是预览，支持图片、代码高亮、Markdown 渲染、PDF、压缩包等内容直接预览。

在 cmux 中，按 Ctrl + Option + 方向键 切换到文件管理面板，用 yazi 快速定位文件，确认后自动在当前目录执行操作。整个过程行云流水，完全不需要鼠标。

为什么选择 cmux？

特性 tmux iTerm2 cmux
学习曲线 高 中 低
项目导航 需要配置 一般 原生支持
终端拆分 需要配置 原生支持 原生支持
插件集成 需要配置 需要配置 自动识别
内置浏览器 ❌ ❌ ✅

说白了：cmux 就像给 iTerm2 装上了项目管理器和插件市场，让终端真正变成了 IDE。

安装与配置

# macOS
brew install cmux

# Linux
# 参考官方文档

首次启动后，按照提示配置 oh-my-zsh 路径，cmux 会自动识别你的主题和插件。

写在最后

很多人觉得终端就是「古老的命令行」，用起来糙。但 cmux 证明了：终端也可以很现代，也可以很高效。

如果你也受够了窗口开太多、切换太麻烦的问题，试试 cmux + 这三个插件的组合。工具选对了，效率才能翻倍。

参考链接

前端老哥的救命稻草：用 Obsidian 搞定 Claude Code 的「金鱼记忆」

✇掘金 前端
作者 jerrywus
2026年3月2日 17:51

写在前面

前端开发中常见这些问题：

  • 每次写代码都要翻一遍同样的规范
  • 踩过的坑，过段时间又忘了
  • 项目规范写在文档里，但开发时根本想不起来
  • 想沉淀经验，但不知道从哪下手
  • Claude Code 有时候不按规范写（上下文丢失）

这篇文章讲讲我们怎么用 Obsidian + Claude Code 来解决这些问题。

整体方案

三层结构：

Memory 文件（200行左右）→ Smart Context Skill → Obsidian docs/

工作流程很简单：

  1. 你给 Claude Code 一个编程任务
  2. Smart Context 自动触发
  3. 自动查 Obsidian 里的相关规范和踩坑记录
  4. 带着上下文开始写代码

步骤一：创建 Obsidian 文档结构

在项目根目录建 docs/ 文件夹：

docs/
├── 00-索引.md
├── 01-快速开始.md
├── 02-开发规范/
│   ├── index.md
│   ├── API规范.md
│   ├── 组件使用.md
│   ├── 命名约定.md
│   └── 页面开发.md
├── 03-架构设计/
│   ├── index.md
│   ├── 目录结构.md
│   └── 分包策略.md
├── 04-开发笔记/
│   ├── index.md
│   └── 踩坑记录.md
└── 05-Claude相关/
    ├── index.md
    └── 规则文件说明.md

示例：踩坑记录

docs/04-开发笔记/踩坑记录.md：

# 踩坑记录

## Taro 相关

### scroll-view 下拉加载不触发
**问题**: @scrolltolower 事件不触发
**原因**: scroll-view 高度未设置
**解决**: 设置 scroll-y 和 height: 100vh

### 内联 SVG 不支持
**问题**: svg 标签不渲染
**解决**: 使用图片 URL 或 IconFont

示例：API 规范

docs/02-开发规范/API规范.md：

# API 开发规范

## 函数命名
- query: 查询/获取
- add: 新增
- edit: 编辑
- delete: 删除
- toggle: 切换状态
- do: 执行操作

## 标准模式
1. try/catch 包裹
2. 检查 code === EResponseCode.Succeed
3. 从 context 提取数据
4. catch 中使用 getHttpErrorMessage

步骤二：Memory 文件

这个是claudecode自带的，/memory去开启即可

文件位置：

~/.claude/projects/-项目名-/memory/MEMORY.md

内容首次微调到精简到 50 行以内 (因为后续cc会自动往里面加记忆)：

# Project Memory

## 知识库架构

> Memory（200行核心）→ Obsidian docs/（完整知识）

| 层级 | 存储 | 用途 |
|------|------|------|
| Memory | 核心规范摘要 | 始终加载 |
| Obsidian | 完整文档/踩坑记录 | 检索使用 |

## 核心规范

- **页面**: SafeLayout 根容器，列表 graybg/详情 whitebg
- **API**: query/add/edit/delete/toggle/do + try/catch
- **组件**: 优先 src/components/，禁 SVG 用 IconFont

## 常见避坑

1. scroll-view: 设 scroll-y + height
2. 小程序禁 SVG: 用图片 URL
3. NutUI 样式: 查 auto-import
4. ref template 不需 .value

## Obsidian 检索

```bash
obsidian search query=页面开发 # 搜索
grep -r "xxx" docs/ # 失败时才用 Grep
知识 文件
踩坑 docs/04-开发笔记/踩坑记录.md
API docs/02-开发规范/API规范.md
页面 docs/02-开发规范/页面开发.md

触发条件

编程任务自动检索：新增/修复/重构/询问"怎么做"/业务模块

## 步骤三：创建 Smart Context Skill

在项目 `.claude/skills/` 目录下创建：

.claude/skills/smart-context/
└── skill.md

内容：

---
name: smart-context
description: |
  智能上下文增强技能。自动检索本项目 Obsidian 知识库（docs/）中的项目规范、踩坑记录。
  触发条件：(1) 实现新功能/创建页面/添加API (2) 修复bug/解决报错 (3) 重构代码
  (4) 询问"怎么做" (5) 提到业务模块（提货/结算/销售/会员等）。
  优先使用 obsidian-cli 搜索 Obsidian 文档，失败才使用 Grep。
---

# Smart Context - 智能上下文增强

## 核心原则

1. 以 Obsidian 为知识库，obsidian-cli 为检索工具
2. 当用户说"把这个加入知识库"时，优先使用 obsidian-cli 增加

✅ obsidian search query=文档关键词 ❌ grep -r "scroll-view" docs/


## 工作流程

### 第一步：分析任务意图
- 任务类型：新增/修改/修复/查询
- 业务模块：提货/结算/销售/会员
- 技术领域：API/页面/组件

### 第二步：检索 Obsidian
```bash
obsidian search query="{关键词}"

第三步：按需读取

obsidian read path=docs/04-开发笔记/踩坑记录.md

第四步：注入上下文执行

检索关键词

任务 搜索词
创建页面 页面开发、SafeLayout、列表页
添加 API API规范、query、try catch
修复报错 踩坑、{报错关键词}
提货相关 提货、pickup

示例

用户输入：帮我创建一个退款订单列表页面

自动执行：

  1. 分析：创建页面，销售/退款
  2. 搜索：obsidian search query=页面开发
  3. 搜索：obsidian search query=列表页
  4. 读取踩坑记录
  5. 注入上下文，开始实现

注意事项

  • 必须使用 obsidian-cli，禁止 Grep 搜索 docs/
  • 按需读取，不要整个文件加载
  • 实现前先查踩坑记录，避免重复踩坑

步骤四：验证和使用

obsidian前置配置

在obsidian软件设置->关于-> 打开"允许命令行和obsidian交互“， 然后重启cc会话即可。

同时安装一下mcp服务：

mcp-obsidian.org/install/

同时再安装下obsidian skills

请打开：obsidian skills

验证配置

重启 Claude Code，然后测试：

帮我创建一个订单列表页面

观察 Claude 的行为：

  1. 自动触发 Smart Context
  2. 使用 obsidian search 搜索相关文档
  3. 读取关键片段
  4. 注入上下文后开始实现

实际效果

左边 Claude Code 正在工作，右边 Obsidian 里的搜索结果同步显示。它自动检索到了相关规范，比如页面开发、SafeLayout 这些关键信息。

再看另一个角度：

左边继续从 Obsidian 拉取踩坑记录，右边代码已经写上了。Smart Context 把规范和避坑信息注入上下文，Claude 直接沿着正确方向写，不需要你中途打断去纠正。

添加新知识

遇到新踩坑时，直接告诉 Claude：

把这个加入知识库：Taro 项目上传图片时，如果使用本地路径不显示，
需要使用 require() 或者用 COS 托管的图片 URL

Claude 会自动：

  1. 使用 obsidian-cli 找到踩坑记录文件
  2. 追加新的踩坑内容
  3. 可选的，同步更新 Memory 文件

常见问题

Q0: 如何启用obsidian-cli

在obsidian软件设置->关于-> 打开"允许命令行和obsidian交互“， 然后重启cc会话即可。

同时安装一下mcp服务：

mcp-obsidian.org/install/

再安装obsidian skills

请打开：obsidian skills

Q1：为什么要用 obsidian-cli 而不是 Grep？

  • obsidian-cli 是 Obsidian MCP 工具，专门用于搜索和操作 Obsidian 文档，速度极快
  • Grep 搜索会破坏 Obsidian 的双向链接和知识图谱
  • obsidian-cli 支持更智能的搜索

Q2：Memory 文件太长怎么办？

  • 减少memory篇幅，只放核心规范（约 50-200 行）
  • 详细内容通过双向链接指向 Obsidian 文档
  • 用表格和列表，减少段落

Q3：Obsidian 需要手动打开吗？

不需要。Claude Code 通过 obsidian-cli MCP 工具直接操作，Obsidian 可以关闭，只是一个存储软件，实际cc调用效果如下图：

比如我让他修改文档

总结

配置完成后，你得到一个自动化的知识增强系统：

功能 实现方式
记忆增强 Obsidian 持久存储 + Memory 始终加载
规范约束 Smart Context 自动检索
避坑提醒 踩坑记录 + 自动查询
知识更新 自然语言告诉 Claude "加入知识库"

核心思路：让 Claude Code 在每次编程时自动检索相关规范，而不是靠人工记忆。

关于obsidian更多用法，请关注后续写新的文章～

❌
❌