我用 Graphify 重构了自己的 AI 工作流之后

 AII

我意识到，我们从一开始就理解错了「效率」

文 / 一只阿木木

前几周，我在跟一个朋友聊 AI 工作流。他问我：「你现在平均每天在 AI 上花多少时间？」

我说：「很多，差不多四五个小时吧。」

他说：「那你有没有算过，这四五个小时里，真正在产出的时间有多少？」

我愣了一下。

然后我认真回想了一下我典型的一天——

打开 Claude，粘贴项目背景，等它读完，开始提问。对话进行到一半，发现需要补充一个上周做的决策，翻文件，复制，再粘贴。换一个新话题，重新开一个窗口，重新粘贴背景……

我粗略估算了一下：四五个小时里，大概有将近一个小时，我在「喂背景给 AI」。

一个小时。每天。

如果你也是重度 AI 用户，我建议你现在停下来，认真算一算这个数字。

因为这一篇文章，就是关于那一个小时的。

一、我的 AI 工作流演进史：一段并不光彩的历程

在说 Graphify 怎么用之前，我想先说说我是怎么走到今天的。

因为我发现，很多人以为自己的工作流已经很先进了，但实际上，我们大多数人都在用一种「看起来很 AI」但本质上很原始的方式工作。

我自己就是最好的反面教材。

2023年：复制粘贴的蛮荒时代

那时候我刚开始认真用 AI。工作方式极其粗暴：把文件打开，全选，复制，粘贴进对话框，然后问问题。

文件太长？截断。信息不够？再粘一段。

效率奇低，但我没有意识到问题在哪，因为 AI 给出答案的那一刻太令人兴奋了，以至于我完全忽视了准备过程有多低效。

那个阶段我给自己的定义是：「AI 用户」。

2024年：搭了一套 RAG，感觉自己很工程师

看了很多教程，搭了自己的向量数据库，用 Chroma 存了几千份文档，写了一个简单的检索管道。

那段时间我特别得意，觉得自己终于从「普通用户」升级成了「AI 工程师」。

但用了几个月之后，我发现一个问题：它对「找信息」很有用，对「理解结构」完全无效。（具体为什么，上一篇文章已经拆解过了。）

那个阶段我给自己的定义是：「AI 工程师」。但其实我只是搭了一个稍微复杂的搜索引擎。

2025年：上下文窗口变大了，我又回到了暴力时代

Claude 3.5 出来，上下文窗口大幅扩展。我的第一反应是：太好了，RAG 不用了，直接塞！

于是我把之前费心搭的 RAG 管道扔掉了，重新开始全文塞入。只不过这次能塞得更多了。

事后回想，这个决策真的挺荒诞的——我用更贵的方式，解决了一个本质上应该用更聪明的架构解决的问题。

那个阶段我给自己的定义是：「务实主义者」。但其实我只是选择了最懒的方式。

2026年：图谱记忆，我第一次感觉 AI 真的「认识我的项目」

用 Graphify 之后，有一天我打开 Claude Code，什么都没有粘贴，直接问：

「我们上次讨论的那个数据清洗模块，现在如果要加一个异常处理机制，最优先需要修改哪三个地方？」

它直接给了我答案。

没有「请先提供项目背景」，没有「根据您提供的信息……」，没有任何需要我补充上下文的停顿。

它知道。因为图谱在那里。

那一刻我忽然明白：效率的本质，不是让 AI 跑得更快，而是让 AI 记得更久。

前者是速度问题，后者是记忆问题。而我在过去三年里，一直在解决错误的问题。

二、重新定义「效率」：你真正在浪费的是什么？

在讲具体用法之前，我需要先建立一个认知前提。

大多数人把 AI 效率问题，理解为「响应速度」的问题。

响应慢？换更快的模型。 输出质量低？调优提示词。 Token 贵？压缩一下文件。

这些都是在优化「这一次对话」的效率。

但有一个成本，几乎所有人都没有认真核算过——

跨会话的重复上下文成本。

每一次你打开新对话，重新介绍你的项目，你在支付两种成本：

显性成本： Token 消耗。那几百、几千个 Token，你每天付好几次。

隐性成本： 认知切换。你在「工作者」和「背景提供者」之间反复切换，这种切换本身会打断你的深度思考状态。心理学研究表明，从一次打断中完全恢复专注，平均需要23分钟。

你每次「喂背景给 AI」，不只是在浪费 Token，你是在谋杀自己的专注力。

Graphify 真正节省的，是后者。

71.5 倍的 Token 节省是可以算出来的数字，但那背后每天被你悄悄放弃的深度思考时间，从来没有人帮你算过。

三、五种工作心智：从「会用」到「用好」

好，现在进入实操部分。

但我不想只给你一堆命令和截图。我想用一种不一样的方式讲这五个功能——

每个功能背后，对应一种工作心智的转变。

因为工具会迭代，命令会变，但心智一旦建立，会跟你很久。

心智一：「异步认知」——让 AI 在你工作时悄悄学习

对应功能：--watch 实时监听模式

用法很简单，在你的项目目录下，开一个后台终端，运行：

Bash

graphify --watch

然后忘掉它，去做你自己的事。

它会在后台静默监听你的文件变化。每次你保存一个代码文件，它立刻触发 AST 重建——不需要调用任何 AI，纯本地计算，几乎零延迟。每次你保存一个文档或图像，它会提示你下次运行 --update 来触发 LLM 处理。

听起来只是一个「自动同步」功能，但它背后的心智转变，是这样的——

传统工作流： 我工作 → 工作结束 → 我更新 AI 的知识 → 下次对话

异步认知工作流： 我工作 → AI 同步学习 → 下次对话时它已经跟上了

前者，你是知识的搬运工。 后者，AI 是你的跟班学徒，它自己在学。

这个心智转变，小到可以忽略，大到改变你和 AI 的整个协作关系。

心智二：「知识民主化」——让每一个 Agent 都能读懂你的世界

对应功能：--wiki 知识库生成模式

运行命令：

Bash

/graphify . --wiki

它会为你的知识图谱里，每一个社区和每一个核心节点，生成一篇 Wikipedia 风格的 Markdown 文章。所有文章通过一个 index.md 串联起来。

这有什么用？

当你只有一个 AI 助手的时候，你可以直接查询 graph.json，问题不大。

但如果你开始搭建 多 Agent 工作流——一个 Agent 负责写代码，一个负责测试，一个负责文档，一个负责代码审查——你怎么让每一个 Agent 都快速理解你的项目？

Wiki 模式的答案是：给它们一个入口。任何 Agent 只需要读 index.md，就能通过文件读取的方式，导航你整个知识库的全貌。不需要解析 JSON，不需要专门的 API，普通的文件读取即可。

传统工作流： 每个 Agent 各自为政，对项目全貌一无所知

知识民主化工作流： 每个 Agent 都能从同一个知识源出发，形成统一的上下文理解

这不只是一个效率问题。这是多 Agent 协作能否真正落地的基础设施问题。

心智三：「认知自动化」——知识更新与代码提交同频

对应功能：graphify hook install Git Hook

运行这条命令，Graphify 会在你的项目里安装两个 Git 钩子：post-commit 和 post-checkout。

之后，每次你 git commit，图谱自动重建。每次你切换分支，图谱自动切换。

如果重建失败，钩子返回非零退出码，git 会暴露错误，而不是静默继续——你的图谱和你的代码，永远保持同步，任何不一致都会被显式暴露。

我第一次用这个功能的时候，有一种微妙的感受——

以前，「更新代码」和「更新 AI 知识」是两件事，我需要记得去做后者。

现在，它们是同一件事。代码更新的那一刻，AI 的记忆就更新了。

传统工作流： 代码是代码，AI 知识是 AI 知识，手动同步，经常滞后

认知自动化工作流： 代码和 AI 知识共享同一个时间线，始终一致

这个心智，我把它叫做「认知自动化」——不是任务的自动化，而是知识更新的自动化。

在一个代码每天都在变化的项目里，这是至关重要的。

心智四：「认知边界」——你选择让 AI 知道什么，同样重要

对应功能：.graphifyignore 精准排除

在你的项目根目录，创建一个 .graphifyignore 文件，语法和 .gitignore 完全一样。

写进去你不想被索引的目录或文件，Graphify 会完全忽略它们，不索引、不处理、不出现在图谱里。

这个功能听起来最平淡，但它对应的心智，我认为是五个里面最被低估的：

我们花了很多时间思考「让 AI 知道什么」，但我们很少思考「不让 AI 知道什么」。

哪些内容不应该进入 AI 的知识图谱？

测试数据？临时文件？实验性代码？敏感配置？还是那些你不想让 AI「先入为主」的早期草稿？

认知边界，是知识图谱工程里一个被严重忽视的设计维度。

一张没有边界的图谱，不是更丰富，而是更嘈杂。噪音越多，信号越弱。

想清楚你的 .graphifyignore，其实是在想清楚：你想和 AI 共享一个什么样的「认知空间」？

心智五：「知识共享层」——从个人图谱走向团队协作

对应功能：--mcp MCP 服务模式 + --neo4j-push 图数据库推送

这两个功能，是 Graphify 从「个人工具」走向「团队基础设施」的接口。

--mcp 让 Graphify 作为一个 MCP stdio 服务器运行，任何支持 MCP 协议的工具都可以连接进来，查询你的知识图谱。

--neo4j-push 则可以把你的本地图谱直接推送到 Neo4j 数据库，让整个团队共享同一张图谱。

个人工作流的终极问题是：知识只活在个人的图谱里。

你的 AI 认识你的项目，但你的队友的 AI 不认识。你的 AI 知道某个设计决策为什么这样做，但新加入团队的工程师不知道。

MCP 和 Neo4j 推送，是把「个人认知资产」变成「团队知识基础设施」的那个接口。

传统团队协作： 知识在 Notion、Confluence、各种文档工具里分散存放，AI 每次都从零开始

知识共享层工作流： 整个团队的 AI 助手，共享同一张持续更新的知识图谱，从同一个认知起点开始工作

这不只是效率的升级，这是团队协作模式的根本性改变。

四、三个差点让我踩进去的坑

好，说完进阶用法，说说坑。

这三个坑，是我自己踩过的，或者差点踩进去的。写出来，希望你能绕过去。

坑一：把 /update 当成万能刷新按钮

这是我见过最多人犯的错误，我自己也犯过。

Graphify 有两种更新方式：

/update： 增量更新，处理新增或修改的文件，合并进现有图谱。

完整重建 /graphify .： 清空旧图谱，从零开始重新索引整个项目。

大多数情况下，/update 就够了——你新加了几个函数，改了几段文档，增量处理就行。

但有一种情况，你必须跑完整重建，而不是 /update——

当你做了结构性重构的时候。

重命名了模块？重构了调用关系？把三个类合并成了一个？把一个大函数拆成了五个小函数？

这些情况下，如果你只跑 /update，旧图谱里的那些陈旧关系不会被删除，它们会静静地留在那里，和新的结构并存。

图谱开始漂移。

你的 AI 开始给你混乱的答案。你以为是 AI 犯蠢，但其实是图谱腐化了。

判断标准很简单： 只新增内容，用 /update；任何重命名、重构、架构调整，用完整重建。

坑二：在错误的项目阶段引入图谱

有一次，一个朋友跟我说，他用 Graphify 索引了自己的一个项目，但感觉帮助不大，有点鸡肋。

我问他：「这个项目现在有多少代码？」

他说：「大概五六个文件吧，刚开始做。」

这就是问题所在。

Graphify 的价值，和你项目的规模、复杂度、以及文档的丰富程度，是正相关的。

一个五六个文件的新项目，结构一目了然，你根本不需要图谱来理解关系——你自己看一眼就清楚了。这时候引入 Graphify，不只是杀鸡用牛刀，它的冷启动成本（安装、索引、学习如何查询）反而成了负担。

什么时候引入 Graphify 最合适？

根据我的实践经验，大概是这样的判断标准：

• 项目文件超过20个，开始出现「我记不清这个函数在哪里被调用」的感觉
• 项目里有 PDF 文档、设计文档、或者研究论文需要和代码关联理解
• 你开始频繁在新会话里重复喂同样的背景
• 团队超过2个人，开始出现「我不知道这个决策为什么这样做」的问题

如果你还没有达到这些信号，先把项目做起来，再想图谱的事。

工具要在合适的时机引入，早了是负担，晚了是浪费。

坑三：忘记了 PyPI 包名和命令名不一样

这个坑纯粹是技术细节，但我看到太多人在这里卡住了，值得单独说一下。

安装 Graphify 的时候，PyPI 上的包名，临时是 graphifyy（多一个 y）：

Bash

pip install graphifyy   # ← 注意是两个 y

原因是 graphify 这个包名已经被别的项目占用了，团队正在申请收回。

但安装完之后，CLI 命令和技能命令，用的仍然是 graphify（一个 y）：

Bash

graphify install        # ← 一个 y
/graphify .             # ← Claude Code 里用一个 y

安装时两个 y，使用时一个 y。

这个不一致很反直觉，第一次用的人几乎百分之百会在这里迷惑几分钟。

记住它，别在这里浪费时间。

五、「认知自动化」不只是一个功能，是一种新的工作哲学

好，走到这里，我想停下来，说一件更重要的事。

这三篇文章里，我一直在用「Graphify」这个词。但如果你只记住了这个工具的名字，你其实只得到了这系列文章价值的5%。

Graphify 会迭代，会有竞争者，甚至可能有一天被更好的工具取代。

但有一个认知，我希望你能带走——

我们正在经历一次「AI 工作哲学」的根本性转变。

旧哲学是：「如何让 AI 更好地服务于每一次任务。」

新哲学是：「如何让 AI 更好地理解你这个人，以及你正在做的事情。」

前者是单次优化，后者是复利积累。

前者的极限是：每次对话都完美。 后者的极限是：AI 越来越了解你，你们的协作效率随时间持续提升。

这两件事，看起来方向相似，但哲学上截然不同。

旧哲学下，你是 AI 的「使用者」，你每次调用它完成任务。 新哲学下，你是 AI 的「建造者」，你持续地为它补充记忆、丰富上下文、建立认知地图。

这种转变，我把它叫做「认知自动化」。

不是任务的自动化——那个已经在发生了。

而是知识积累的自动化：你工作的过程，同时也是 AI 学习你的过程。你提交代码的那一刻，图谱在更新；你整理文档的那一刻，语义在扩充；你做出一个决策并记录下来的那一刻，AI 的记忆里多了一个节点。

你不只是在用 AI，你在建造一个越来越了解你的 AI。

这两件事，听起来结果相似，但本质是两种完全不同的人机关系。

六、然后，我看到了 Graphify 背后的东西

写这个系列的最后，我想聊一件让我很兴奋、但还没有对太多人说过的事。

Graphify 本身，只是图谱层。

但 Graphify 的团队，在它之上，正在构建一个叫做 Penpax 的东西。

它的目标，是一个设备端的数字孪生——把你的会议记录、浏览历史、文件、邮件、代码，连接成一个持续更新的知识图谱。

完全在设备上运行。不上云。不训练你的数据。

我读到这个的时候，沉默了很久。

因为它在描述的，是我在第一篇文章里说的那个终极目标——

一个真正「认识你」的 AI 协作者。

不只是认识你的代码，而是认识你的思维方式、工作习惯、决策逻辑——你这个人的完整认知图谱。

这个东西存不存在，我不知道。Penpax 能不能做到，我也不知道。

但它在尝试解决的那个问题，是真实的——

在 AI 时代，「理解一个人」这件事，应该不只是发生在人类之间。

七、写在最后：三篇文章，一个判断

从第一篇到现在，我讲了 Karpathy 的 /raw 文件夹，讲了 48 小时的社区响应，讲了为什么 RAG 有架构性局限，讲了图谱如何把「关系」变成一等公民，讲了五种工作心智，讲了三个真实的坑。

但如果你问我，这三篇文章想说的最重要的一件事是什么——

是这个：

过去三年，我们用「无状态 AI」做「有状态工作」，然后用人力填补中间的鸿沟。我们把这种填补叫做「工作」，但它其实是一种浪费。

而现在，这个鸿沟开始有了工程化的解法。

那些今天就开始认真思考「如何为我的工作建立持久化认知层」的人，正在进入一种新的工作模式——他们的 AI 协作者，有历史，有记忆，有上下文。

而那些还在每天重复粘贴背景的人，使用的已经是另一种 AI 了。

不是工具不同，是工作哲学不同。

这是 Graphify 系列的第三篇，也是最后一篇。

第一篇： 「外部记忆的诞生——人类终于开始为 AI 建造海马体」

第二篇： 「RAG 还没死，但它正在被超越」

第三篇： 「我用 Graphify 重构了自己的 AI 工作流之后」

三篇文章，一条完整的认知路径：发现问题 → 理解本质 → 重建工作流。

如果你一路跟下来，谢谢你。

如果这三篇文章里，有任何一句话让你重新想了想自己和 AI 的关系——

那就够了。

如果你已经开始用 Graphify，或者你正在考虑，欢迎在评论区告诉我：你遇到的最大障碍是什么？

我会在后续内容里，持续跟踪这个方向的进展。

—— 一只阿木木

一个相信工具会过时、判断力不会的内容创作者。记录 AI 时代真正重要的事。

💬 如果这个系列对你有价值，转发给同样在思考 AI 工作流的朋友。 📌 关注我，我们继续挖。