CC成功的秘诀到底是什么？遵循Unix 哲学、核弹级生产力：我用ClaudeCode+Obsidian，造了一个“第二大脑” 原创

编辑 | 听雨

出品 | 51CTO技术栈（微信号：blog51cto）

AI 工具千千万，但能让人上瘾的，只有 Claude Code。

最近，小编关注到一篇拍案叫绝的文章——作者是 Alephic（一家以 AI 为核心的咨询公司）的联合创始人 Noah Brier。他坦言：

“Claude Code 不只是一个写代码的工具，而是一种全新的操作系统思维。”

他用 Claude Code 打造了一个属于自己的“AI 操作系统”——

它能写代码、能记笔记、能自己思考，还能帮他打理邮件、整理知识、规划行程。

简单来说，Claude Code 已经不只是“会写代码的聊天机器人”，

而是一个能与你协作的数字同事。

他还总结了Claude Code 的强大之处：不在于“写得多快”，而在于它遵循了 Unix 哲学——让每个工具只做一件事，并把这件事做到极致。

小编为大家整理了文章的核心内容，enjoy:

1.从工具到操作系统：我的 Claude Code 故事

如果你最近和我聊过 AI，那你肯定听过我长篇大论地赞美 Claude Code 的神奇之处。它最初只是我在编程时与其他工具并行使用的一个辅助工具，如今却已经进化成我完整的“智能代理操作系统”，能支持各种各样的工作流程。

最典型的例子就是我用来记笔记的工具：Obsidian。它与 Notion 或 Evernote 的最大区别在于：所有笔记文件都是存储在你电脑上的纯文本 Markdown 文件。你可以同步、设定样式、保存它们，但归根结底，它仍然只是硬盘上的一个文本文件。

几个月前，我突然意识到，这一点让我的 Obsidian 笔记和研究内容成为 AI 编程工具的一个特别有趣的应用场景。最初，我只是尝试在 Cursor 中打开我的笔记库，但很快，这个尝试演变成了一个类似“笔记操作系统”的东西。我对它的依赖程度越来越高，最后甚至在家里搭建了一台服务器，这样我就能通过手机用 SSH 连接到我的 Claude Code + Obsidian 环境，在外出时也能随时记笔记、读笔记、整理思考。

图片

现在我对Claude Code 又有了一些新的体会，今天想和大家聊聊这些。

2.为什么Claude Code 特别？它到底比Cursor 好在哪里？

这个问题其实让我纠结了很久。老实说，我也不确定 Claude Code 在所有方面都优于 Cursor。但我确信，它有一组彼此协作、异常出色的特性组合——正是这些特性，让我如今在要构建任何东西时，都会第一时间想到 Claude Code。

而且越来越多的时候，我使用它并不是为了改造现有代码库，而是直接在它的功能之上创造全新的东西。

那它的秘诀是什么？部分答案在于Claude Code 对“工具”的独特理解。

作为一个基于终端的应用程序，它牺牲了一些易用性，却换来了更强大的能力：对 Unix 原生命令的深度集成。

“Unix 哲学” 的奠基人Doug McIlroy 曾经的那段经典表述，完美地诠释了这一点。他于 1978 年在《Bell System Technical Journal》中首次提出：

• 让每个程序只做好一件事。如果要做新的任务，就从头开始构建，而不是通过不断添加新“功能”来让旧程序变得复杂。
• 预期每个程序的输出都能成为另一个（可能尚未出现的）程序的输入。不要在输出中夹杂无关信息。避免过度严格的表格或二进制输入格式，也不要强制要求交互式输入。
• 设计和构建软件（甚至是操作系统）时，应尽早进行尝试，理想情况下几周内就能测试。不要犹豫，笨拙的部分要果断舍弃并重建。
• 在编程任务中，优先使用工具而不是人工帮手来减轻负担——即使这意味着你得绕路去先造好工具，而且用完后可能就得扔掉。

后来，Peter H. Salus 在 1994 年出版的《A Quarter-Century of Unix》中将其概括为三条简洁的原则：

• 编写只做一件事、但能把这件事做到极致的程序。
• 编写能协同工作的程序。
• 编写能处理文本流的程序，因为文本是通用的接口。

这些已有半个世纪历史的原则，恰好与大语言模型使用工具的方式完美契合。

如果你观察这些模型实际调用工具的过程，会发现它们不断在“管道化”——把一个命令的输出接到另一个命令的输入（当然，中间会带上一点它们特有的“模糊推理”）。（顺带一提，在 Unix 中，| 命令正是用于将一个命令的输出“串联”到另一个命令的输入中。）

而当模型在“焊接”工具时出问题，几乎总是因为这些工具本身太复杂了。

图片

Claude Code 之所以如此令人惊叹，第一个原因在于：Unix 所依赖的那些命令，天生就非常适合被大语言模型使用。

原因有二：一是这些命令足够简单；二是它们文档极其完备，这意味着模型在训练时就有大量的资料可学到这些命令的来龙去脉。

但这还不是全部。另一个关键因素，显然是Claude Code 最初强大的代码生成能力——而且最近，它在写作（至少对我来说）方面也同样出色。然而，虽然像 ChatGPT 或 Claude 这样的应用同样能生成文本或代码，但 Claude Code 却有着本质上的不同。那就是——文件系统访问权限。

文件系统改变了一切。ChatGPT 和 Claude 的网页版都有两个致命缺陷：

• 对话之间没有记忆；
• 上下文窗口太有限。

而文件系统则同时解决了这两个问题。

Claude Code 能给自己写笔记、积累知识、持续记录进展。它拥有“状态”和“记忆”。它不再被限制在单次对话之中——它能进行连续的、长期的思考。

3.潜力滞后：AI 能做的，还没被完全释放

早在 2022 年，我第一次尝试使用 GPT-3 API 时就曾说过一句话：“即使这些模型的能力从此不再提升，我们也还需要至少十年时间去真正发掘它们的应用场景。”

后来事实证明，模型确实变得更强了——推理能力的提升让工具调用变得可靠。但最近我对“文件系统”的发现，也再次印证了当初的观点。

我之所以提到这件事，是因为Claude Code 初始版本的创建者 Boris Cherney 也用到了一个类似的概念来描述他的“顿悟时刻”：

在AI 领域，我们有一个词叫 “产品过剩潜能”。

它的意思是：模型其实已经具备某种能力，但运行它的产品还没被设计成能充分利用这种能力的形态。

当我发现Claude 能够访问并操作文件系统时，那完全就是一个典型的 product overhang ——模型早就能做到这些，只是我们一直没有一个能真正释放这种能力的产品！

我也同意他的观点，不过我认为关键不只是文件系统，而是文件系统 + Unix 命令的结合。

核心在于：这些能力其实早已存在于模型之中，只不过在过去，它们还“沉睡”着。而一旦被激活，我们就迎来了真正的飞跃。

Claude Code 的意义正在于此——它为构建可靠的智能体系统提供了一个清晰的蓝图：不是通过复杂的多层接口去限制模型，而是让产品去捕捉并释放模型原本就拥有的能力。

4.不止写代码：让 AI “活”在你工作流程里

之前我提到过我的Claude Code + Obsidian 整合环境。其实，我又更进一步——我已经将它开源，项目名叫“Claudesidian”。

Github链接：https://github.com/heyitsnoah/claudesidian

它整合了我在自己的 Claude Code + Obsidian 环境中常用的一系列工具与命令，

同时也扩展了更多实验性的功能，成为我进行各种尝试的“试验田”。

其中最有意思的一项，是我构建了一个升级工具：如果项目主版本有更新，你可以一键拉取最新改动，AI 会自动帮你检测本地是否修改过相关文件，如果有，它还会尝试智能合并你的改动与新的更新内容。

这两个项目都遵循相同的Unix 哲学原则：

简单、可组合的工具；各自做好一件事，然后协同工作。

这正是Claude Code 的魅力所在——它让这种“由简生智”的构建方式成为可能，也让我重新发现了构建应用程序的新范式。

 我还做了另一个项目，暂时称之为“Inbox Magic”。

它是一个Claude Code 仓库，内置了一系列 Gmail 工具，以及大量提示与命令，让它能像你的个人邮件助理一样运作。

目前，它的功能还比较基础：

可以代你搜索邮件、发送邮件；

还能进行收件箱分类；

甚至可以训练模型学习你的邮件语气与写作风格，从而更自然地帮你撰写邮件。

与普通的 ChatGPT 或 Claude 不同，它们通常只能一次访问一两封邮件；而这个系统因为能写入文件并执行更复杂的操作，所以可以完成更智能的任务，比如：

“找出我收件箱里所有与旅行相关的邮件，并据此建立一个我的旅行习惯档案，然后用这个档案作为提示，让ChatGPT / Claude 在帮我做旅行规划时，更贴合我的个人偏好。”

总之，这个项目还在完善中。如果你感兴趣、想提前体验，可以发我你的GitHub 用户名，等我准备好测试版本时，会第一时间邀请你试用。

5.给你的几点建议与启示

我一向不太喜欢下结论，但这里有几条值得特别强调的体会：

1）文件系统是一种极其有效的方式，能绕过大语言模型缺乏“记忆”和“状态”的限制——它值得被更广泛地使用。

2）如果你在研究或实现工具调用，关键是要遵循 Unix 哲学。——让每个工具保持简单，只做一件事，并能与其他工具协作。

3）Claude Code 提供了一个面向未来智能体系统的蓝图：以“文件系统 + Unix 哲学”为核心，去构建可靠、可调试的 AI 代理，而不是陷入当下那些过度复杂的多智能体框架。

从实操角度来说，这意味着：当你在自己的项目中构建工具调用时，要保持简单，让主模型线程去“管道化”各个工具之间的连接。（顺带一提，目前所有智能体/聊天机器人系统都面临的一个大问题是：如何让这些“管道”传递信息时，不必经过上下文窗口。）

4）如果你还找不到 LLM 的应用场景，那就说明你还没认真去尝试。

参考链接：

​​https://www.alephic.com/writing/the-magic-of-claude-code​​

​​https://newsletter.pragmaticengineer.com/p/how-claude-code-is-built​​

 本文转载自51CTO技术栈，作者：听雨