过去两周，X 平台上两条关于 Graph Engineering 的长推文火了。一条拿下了 110 万的浏览量，另一条也高达 46.8 万。
而 Loop Engineering 这个词在 X 上出圈，也就是六月初的事。短短六周，AI 圈的热词就又翻篇了。
所以说，论造词速度，哪个圈子都不如 AI 圈。
这次带节奏的还是同一拨人。六月初，OpenClaw 的作者 Peter Steinberger 还在呼吁大家别写提示词了，去设计循环。仅隔了六周，7 月 18 号他就发了句调侃：咱们还在聊 Loop，还是已经转到 Graph 了？下方，Obsidian 的负责人 kepano 神补刀：“一直都是在用 Graph”。
我把那两条百万级浏览的推文都仔细读完了。先说结论：它们挂着同一个词，却讲着两件完全不同的事。一件教你如何在笔记库里高效检索，另一件则是给反馈环配置监工。放在一起，容易让人误以为 AI 圈又搞出了什么惊天大新闻。
不过，在深入拆解之前，先把词面意思捋清楚。Graph 就是“图”，不是图片的图，而是数据结构里的那个图：一堆节点加上一堆连线。节点存东西，连线管关系，顺着线就能从一个节点走到下一个。我们过去讲机器学习，里面的贝叶斯网络、隐马尔可夫这些都是图模型。深度学习里的 GNN 图神经网络自然也是一种图模型。
简单来说，Graph Engineering 就是在动手之前，先把知识、规则、反馈这些东西拆解成节点，谁依赖谁、谁盯着谁用线连起来。之后，让 AI 顺着这张图来走，而不是每件事都指望模型临场发挥。从构词上看，它跟 Prompt Engineering、Context Engineering、Loop Engineering 一脉相承，都在回答同一个问题：功夫该花在哪？前几轮的答案是提示词、上下文、循环，这一轮轮到了图。
先看那条 46.8 万浏览的推文，作者是 @unicodef1wn，场景锚定在 Obsidian。一个拥有 2000 条笔记的平铺式笔记库，问 AI 助手 Fable 5 一个问题，它会把整个库通读一遍，花掉几十万 token 才换来一个答案。作者自己都吐槽，这还有一半的概率会抓错文件。
他管这种库叫“囤积癖”：什么都留着，什么都得靠全量查找。而所谓的 Graph Engineering，就是在笔记库里搭起四样东西，把“囤积癖”改造成“图书管理员”。
第一样是 ROUTER.md，一个每次会话都会优先读取的路标文件。它被严格控制在 500 token 以内，只写哪类文件放在哪。第二样是 index.md，每行对应一条笔记，格式就是“名字 + 链接 + 一句话描述”。笔记本身得按“一个文件一个主题”的原则拆开，千万别搞那种巨型笔记——为了引用其中一行，就得把十个主题的内容全吞下去，这是第三样。最后一样是“边”，也就是 Obsidian 的双链，但它强调只链接一条笔记真正依赖的那几条。
整套方案里最值钱的观点，是他排在第 9 步的思考：找文件是个匹配问题，不需要智能，因此也不该消耗模型调用。问题被剥成关键词，仅凭索引文件给每条笔记打分，一个文件都不打开；只开分数最高的那一个，只读答案所在的小节，最多再跟一条链接。前面这些全是脚本就能干的逻辑活，模型只在证据到手之后跑一次。作者给出的数据是，从全库扫描直接降到了每次只开 2 到 3 个文件。
这条推文里，我最喜欢他引用的一句实践者原话：“漂亮的图是给你看的，索引则是给 Fable 5 用的。”
上面这套东西，做过后端开发的人肯定看着眼熟：router 就是路由表，index 是简化版的倒排索引，边则是指针。往前翻，微软在 2024 年开源的 GraphRAG，就在用大模型给文档自动建图再检索；再往前，2019 年前后国内知识图谱火过整整一轮，图数据库和图谱构建岗位满天飞，后来大模型一来，不少团队原地转型。用图来管知识，从来不是什么新鲜事。
他的新意，恰恰在反方向：不上向量库，不做 embedding。整张图就是几个手写的 markdown 文件加上纯逻辑匹配，检索环节一次模型都不调。省钱、可控，但代价是索引得靠人肉维护。每加一条笔记就得添一行，偷懒一个月，它就退化回一堆散文件。这一点，对于日常重度使用 Obsidian 的我来说，深有同感。
对照他的 11 步，我翻了翻自己的库。这个技术公众号的全部文章和素材，就管理在一个 Obsidian vault 里。CLAUDE.md 里的内容路由表，就是他口中的 router；选题 brief 和每周 focus 文件算是 state，但 index 是缺失的。Claude Code 每次帮我查旧文，还是靠文件名 grep 整个目录。写这篇稿子做查重时，它就实打实扫了一遍。
再看那条 110 万浏览的长文，来自 Carlos E. Perez。他是接着 Steinberger 那句调侃写的，标题很直接：《From Loop Engineering to Graph Engineering?》。
他先讲了个故事。一个客服团队给 AI 客服搭了反馈环，盯的指标是工单解决率，每周都测。指标一掉，就调提示词和策略。经过五个月的连涨，结果订单续签数据出来——客户流失率翻了一倍。
复盘才发现，bot 学会了靠劝退来结单：快速关闭对话，不鼓励追问，把用户自己放弃的问题全标成“已解决”。环没有任何故障，它只是把它唯一能看到的那个数字做上去了。
这就是古德哈特定律（Goodhart's law）：当一个指标被足够用力地优化后，它就不再能度量它原本想度量的东西了。
Perez 说，单个反馈环的死法有四种，全是结构上注定的。
第一种，就是上面客服故事里的“指标被玩坏”。环的眼里只有那一个数字，它总会找到最省事的路把数字做上去，哪怕这条路背叛了数字的本意。
第二种，是目标没人管。环只负责朝目标跑，没能力回头怀疑目标本身对不对。就像空调的恒温器不会问“26 度合不合适”。评测环也一样，benchmark 很可能是很久以前某人拍脑袋定的，它照跑不误，从不问这个分数跟用户的真实感受有没有关系。
第三种，是环和环打架。Perez 举的例子是一栋楼里空调控制器没对齐，一台在制热，隔壁一台在制冷。单看每一台都运转良好，合起来却永远在互相抵消。放到 AI 产品上，就是优化响应速度的环，在拆优化回答质量的环的台。
第四种最隐蔽，度量本身会烂掉。传感器会漂移，数据管道会腐化，指标定义悄悄变味。最后，检查数据变成拿一张报表核对另一张报表，没有一个数字再触及真实世界，仪表盘上却还是一片绿。
Graph Engineering 在他这里的意思，不是修一个更好的环，而是搭一张环的网络。每个优化环，配一个盯对手指标的监督环，比如解决率配留存率；快环的目标由慢环定期审查；打架的环上面，放一个管取舍的仲裁环；再加专门的审计环，只干一件事——定期查其他环的数字还接不接地气。
说到底，MLOps 里这套机制早就有了：冠军-挑战者上线机制、数据漂移监控、自动回滚，还有训练环永远看不到的保留测试集。可靠性不住在任何一个环里，它住在环和环的连线上。
做增长的朋友看到这应该也觉得眼熟。北极星指标配护栏指标，国内大厂的 A/B 实验平台就是这么设计的，护栏指标就是他说的“对手指标”。
但这篇长文真正的分量，在后半段：图也会死，而且死得更体面。审计环查运营的数，运营的数出自财务同源的系统，调参的环看的仪表盘又建在这一切之上。每个环都在核对别的环的报表，没有一个环碰到地面。整张图自洽得很，却没有一处经过验证，绿灯能一路绿到崩盘。
所以他说，图需要“锚点”，一些不容争辩的数字：到账的钱，真正跑过的测试，真正留下来的客户。需要“冻结节点”，一些优化环永远不许碰的规则，就像训练环永远不许看保留集。而最根上那个问题——“到底什么算更好”，图自己回答不了，只能由人来给。因为图里的每个环，都是在这个前提之上转的。
把两种 Graph 放在一起看，公约数是：都在把不需要智能的部分从模型手里拿回来，交给结构。笔记库那版，找文件是逻辑活，模型只负责最后的思考；Perez 那版，监督和仲裁靠的是环和环怎么连线，不靠模型的自觉。方向上，跟我上个月聊过的上下文工程是一路的——模型越强，外围越该做减法。
但“图”这个形式本身，真的一点都不新。LangGraph 名字里就带着 Graph，两年前就在用图来编排 agent 工作流；在 Dify、扣子甚至 ComfyUI 上拖过 workflow 画布的同学，每天连的那些节点和线，就是图。
Perez 文里还有句无意的幽默。他说，把单个环搭干净是上一个时代的手艺，然后在括号里标注——“也就是一个月前”。
我的看法是，没有对应的应用场景，这个词就没必要追。笔记才几十条，全量扫也花不了多少 token；手里连一个跑着的指标优化环都没有，环的网络更用不上。六周前大家还在聊 Loop，六周后不知道又轮到什么。在云栈社区里常有人讨论这类热点，但追词是追不完的。
真要落地，也就两件便宜事：笔记库大的，补一个 index.md（原作者在附言里说，11 步只做一件，就做它）；跑着优化环的，给指标配个对手指标。剩下的，等真头疼了再说。
正应了那句话：AI 圈的很多东西，只要你学得慢，很多就不用学了。
发表于 1 小时前
|
查看: 2|
回复: 0
