Hello啊朋友们，我是Simonlin，用通俗易懂的语言，手把手带你玩转AI，提升10倍效率！
不知道你有没有这种感觉？
- Obsidian里笔记越攒越多，Inbox里堆了一堆 “先放着回头整理” 的东西，结果一放就是两个月。
- 标签体系越来越乱，有些笔记连 frontmatter 都没有。
- 想找一篇两个月前存的好文章，搜半天搜不到，最后发现它躺在 Inbox 最底层，标题还是默认的 “未命名”。
说实在的，我之前就是这么个状态。
在我的Obsidian仓库里，总共有305篇笔记，Inbox里躺着4篇 “过两天再整理” 的东西，最早的已经放了61天。
其复杂程度，让我每次打开Obsidian想整理，看了一眼Inbox，又默默关掉了。
直到前两天，我看到 Addy Osmani 发了篇博客，标题叫《Loop Engineering》。
看完之后...我傻了。
不是因为这是个新鲜概念，是因为我突然意识到一件事：
我一直在手动给知识库当保姆，而这套loop架构，就是让知识库自己管自己的。
一、Loop Engineering 是个什么东西
先解释一下这个词是啥意思。
Loop Engineering 是 Google 工程师 Addy Osmani 在2026年6月提出来的一套架构思路，核心就一句话：
你不再亲手调AI，而是设计一个循环系统，让这个系统替你调AI。
以前你跟AI的交互方式是一问一答，也就是你写提示词，AI干活，你检查结果，不对就调整提示词再来一轮。
这个流程里面，你全程在场，手没离开过键盘，看似只需要验收就好，实际上从第一次输入，到最终得到满意的效果，其实已经不知道迭代多少次了。
痛啊，太痛了！
而Loop Engineering的提出，就让这件事变得不再那么复杂。
简单来说，就是：
你设计一个循环，这个循环自动触发、自动分配任务、自动检查结果、自动记录状态、自动进入下一轮。
你在旁边看着就行，不需要每一轮都下场。
它是由五个组件，再加一个记忆层组成的：
- 1. Automations，定时触发器。每天8点自动启动，不用你喊。
- 2. Worktrees，并行隔离。两个AI同时干活不会互相踩文件。
- 3. Skills，项目知识。把规则写死在文件里，AI每次跑之前先读，不用你重复解释。
- 4. Connectors，连接真实工具。不只是读写文件，还能调API、发消息、操作数据库。
- 5. Sub-agents，子代理。一个负责探索、一个负责执行、一个负责审核。写的人和审的人分开，自己做自己的质检。
然后再加一个 Memory，一个文本文件记录状态：哪些处理了、哪些还在等、上次跑到哪了。
这六个东西拼在一起，就是一个“你睡觉它干活”的无人值守系统。
Boris Cherny，Anthropic 那边 Claude Code 的负责人，发表了一个观点，还是很戳到我的：
我不再亲手调Claude了。我的工作是写loop。
我当时就想...我的知识库，能不能也这么搞？
二、把 Loop 套到知识库上
想清楚之后，我发现知识库维护这件事，跟loop架构简直是天作之合。
你看知识库的日常维护，翻来覆去无非就那么几件事：
新笔记归档到正确的目录、打上合适的标签、找到关联笔记加双向链接、更新索引页、清理重复内容。
每一件都是 “技术上极其简单、意志力上极其消耗” 的事。
Loop架构映射过来，是这样的。
Automations是定时器任务，要做的是每天早上8点，自动扫描Inbox有没有新笔记。
四个规则文件放在知识库根目录，每个管一类规则：
- KB-STRUCTURE.md定义什么内容归哪个Area
- TAG-TAXONOMY.md定义标签怎么打
- NAMING-CONVENTIONS.md管文件名格式
- TROVE-SYNC.md（就是我之前提到的Trove AI）管外部内容怎么入库。
AI每次干活之前先读这四份文件，规则就在那里，不需要我每次重复。
Sub-agents（子代理），构成了三层流水线：
- Explorer扫描Inbox找新笔记
- Organizer读内容判断归属打标签找关联
- Reviewer审核Organizer的判断是否靠谱
做的人和审的人不是同一个，主打一个互相制衡。
Memory，其实是一个状态文件，里面记录我每次跑了什么、处理了哪些、还有什么待处理。
就这套逻辑，我试着让Codex帮了我一把，搭完之后我自己都有点不敢相信。
它的核心逻辑，其实就是一个加了记忆层的流水线。
看起来不复杂对吧？
但是以前，我确实从来没想过，可以把知识库维护这件事自动化到这个程度。
突然感觉之前的自己像个傻子(
三、实际跑一遍
搭好之后，我没有马上让它直接移动文件。
这一步,我一定要跟大家说清楚：
知识库不是测试玩具，里面很多笔记都是长期资产。
所以AI判断得再像那么回事，也不能第一天就给它开太过于自由的权限，不然它哪天把你搜集的文章、素材、提示词啥的乱塞一通，你还得自己去废墟里考古。
所以我第一轮只开 dry-run。
Explorer 先上场，扫一圈 Inbox，把待处理笔记列出来，然后 Organizer 读取 KB-STRUCTURE.md 和 TAG-TAXONOMY.md，它只做判断，不会去改动你的文件。
最后它会给出一张建议清单，长这样：
- 这篇建议放到哪个目录
- 建议加什么标签
- 可以关联哪几篇旧笔记
- 判断理由是什么
- 置信度高不高，需不需要人工确认
比如一篇 Claude 深度使用技巧的翻译笔记，它会判断这不是普通网页剪藏，而是可以长期复用的参考资料，更适合放进 AI工具助手，而不是一直躺在Trove AI的中转站。
这一步跑完，Inbox 不会被清空，文件也不会被移动，你得到的是一份“整理建议报告”。
这听起来虽然没有“一键全自动”那么爽，但它更靠谱。
So...我的思路是：
第一阶段先让系统学会看，第二阶段再让系统动手。
因为我想，宁可慢一点，也不要让大家一上来就把自己的 Obsidian 搞乱。
AI时代，判断力还是得有的。
四、然后我干了件事
跑通之后，我设了个 Cron任务。
每天早上8点，自动触发这个 Loop：
Explorer 扫描 → Organizer 分析 → 生成建议报告 → 发给我。
注意，现在还不是自动去处理文件的阶段，不能一上来就给AI放权，而是等这套流程真的稳定下来了，再慢慢松开缰绳，让它策马奔腾~~~
我的 cron 里专门写了几条硬限制，不移动、不重命名、不删除、不写 frontmatter、不更新索引、只读扫描，只给建议。
这样，我该干嘛就干嘛，然后每天早上打开电脑的时候，顺便瞄一眼就行，然后自己下判断，要不要去采纳它给我的建议。
这件事之后，我想明白了一个道理。
以前我总觉得自己是 “没时间整理知识库” ，其实不是没时间，是每次打开Inbox看到那些待处理的笔记，就会一阵头大，结果需要消耗的意志力，反耳比时间多得多。
Loop Engineering 解决的恰恰是这个，它不是帮你省时间，是帮你省意志力，换句话说，节省你的“思维资源”。
有了这样的一套循环之后...
- 1. 你不需要每天提醒自己 “该整理知识库了” ，系统会先把整理建议推到你面前。
- 2. 而且你不需要每次打开Inbox都做心理建设，因为第一步的判断已经有人替你做了。
- 3. 你不需要记住标签体系和归档规则，Skills文件替你记着。
你才真的是你自己知识库的主人，而不是像个苦哈哈自己PUA自己的碳基牛马。
五、怎么自己搭一套
好，讲完了我的，说说你怎么搭你自己的。
不需要是工程师，但你至少要能复制一段脚本、改一个路径（实在不会也没有关系，直接把我文章发给你的Agent助理就好，AI时代嘛~）。
听着唬人，其实就是改一行字的事。会用 Obsidian，有一个能跑定时任务的 AI 助手，就够了。
整个搭建分五步。
第一步：写你的 Skill 规则文件
这是整个 Loop 的灵魂。
因为AI 不是神，你不告诉它你的知识库怎么组织的，它就瞎猜，不告诉它你要什么不要什么，它就瞎搞。
你要做的是，在知识库根目录建一个 KB-STRUCTURE.md，把你自己的目录结构和归类逻辑写进去。
我给你一个填空模板：
# 我的知识库结构规则
## 目录结构
00-Inbox/ ← 所有新笔记先放这
01-写作/ ← 我的文章和草稿
02-学习/ ← 读书笔记、课程笔记
03-工作/ ← 工作相关
04-归档/ ← 不再活跃的
## 归类规则（优先级从高到低）
1. 标题里有「文章」或「草稿」关键词 → 01-写作/
2. 内容是读书笔记 → 02-学习/
3. 内容涉及工作项目 → 03-工作/
4. 以上都不匹配 → 留在 Inbox，标记 needs-review
## 禁止操作
- 不删除任何笔记
- 不改正文内容
- 不创建新目录把上面的目录名和规则换成你自己的就行。
再建一个 TAG-TAXONOMY.md，定义你想用的标签体系：
# 我的标签规范
- #writing/article → 文章
- #writing/draft → 草稿
- #learning/note → 笔记
- #work/project → 工作项目
- #type/reference → 参考资料两份文件写好，都得放在知识库根目录。
这活看着简单，但这俩文件是整个系统里最重要的东西。
只要你规则写清楚，后面全是自动的，AI 每次开工前先读这两份，你的规则就是它的边界。
第二步：Explorer 扫描脚本
这一步需要一个脚本，每天早上扫一遍你的 Inbox，输出“有哪些待处理的笔记”。
如果你用 Cola，这段 Python 放到 Cola 能访问的位置（比如 ~/.cola/scripts/explorer_scan.py），其它的本地Agent也是一样的：
import json
from datetime import datetime
from pathlib import Path
KB = Path.home() / "你的知识库路径"
INBOX = KB / "00-Inbox"
defscan():
items = []
for f insorted(INBOX.rglob("*.md")):
if f.name.startswith("KB-") or f.name.startswith("TAG-"):
continue# 跳过规则文件自身
age = (datetime.now() - datetime.fromtimestamp(f.stat().st_mtime)).days
items.append({
"name": f.name,
"age_days": age,
"path": str(f.relative_to(KB))
})
return items
if __name__ == "__main__":
result = {
"scan_time": datetime.now().isoformat(),
"inbox_pending": scan()
}
print(json.dumps(result, ensure_ascii=False, indent=2))把“你的知识库路径”底下的路径， 换成你自己的。
真的，别被代码吓到，你不需要看懂每一行，只需要改那个路径字符串。
跑一遍 python3 explorer_scan.py，你会看到类似这样的输出：
{
"scan_time":"2026-06-16T08:00:00",
"inbox_pending":[
{"name":"一篇没整理的文章.md","age_days":23,"path":"00-Inbox/..."},
{"name":"上周的读书笔记.md","age_days":5,"path":"00-Inbox/..."}
]
}第三步：Organizer，让 AI 读规则、只出建议
脚本扫出来待处理列表后，接下来是 AI 出场。
你告诉 AI（Cola、Claude、Codex 都可以）一段指令：
读取知识库根目录的 KB-STRUCTURE.md 和 TAG-TAXONOMY.md。然后读取 Inbox 里每一个待处理文件，根据规则判断应该移到哪个目录、打什么标签。对每一篇给出：目标目录、建议标签、50字摘要、2-3篇关联笔记、判断理由和置信度。本轮只输出建议，不移动、不重命名、不删除、不写 frontmatter。
这段指令就是你的 Organizer。
AI 会先读你的规则文件，再逐一分析每篇笔记，最后给你一个操作清单。
说实话，我第一次跑这一步的时候，看着它给的分类建议，有种很奇怪的感觉...它居然比我自己还清楚每篇笔记应该放哪！
你先看两三天，确认它的判断稳定，再考虑把 “确认后执行移动” 加进去。
第四步：设定时任务，但先用 dry-run
最后一步，把上面三步串成一个定时任务。
直接设一个 cron：
每天早上8点，运行 explorer_scan.py 扫描 Inbox。如果有待处理笔记，读取 KB-STRUCTURE.md 和 TAG-TAXONOMY.md，逐一分析并给出归类建议。本轮是 DRY-RUN 安全模式：不移动、不重命名、不删除、不写 frontmatter、不更新索引。只汇报建议清单和需要人工判断的项目。
工具不同，逻辑一样。
设好之后，你每天早上醒来看到的消息，就是“今天有2篇待整理，建议放到哪里，为什么”。
等这个 dry-run 跑稳定了，再开自动执行。
第五步：稳定之后，再开放自动执行
自动执行不是第一天就开的东西，我自己是这么做的——
- 第一周，只 dry-run。每天看它给的建议，重点看错分、乱打标签、过度自信这三类问题。
别急着开自动执行，我知道你会想开的，忍住！多看几天它的判断结果，你才知道它哪类笔记判断准、哪类容易翻车。
- 第二周，可以只开放低风险动作。比如只处理 Inbox 里的新笔记，只移动置信度高的笔记，遇到目标目录不确定、同名文件、跨领域内容，一律标记 needs-review。
- 第三阶段，再考虑让它写 frontmatter、更新索引、补双向链接。每加一个能力，都先 dry-run 几天。
说到底，Loop Engineering 不是某个工具独占的东西。
它是一种思维模式，把你的规则写下来，让 AI 照着跑，但权限要一层一层放——
你负责定方向，也负责给系统上护栏。
而这套模式，在我看来，自有它另一层价值：
用“每天自动循环”的方式，倒逼你每天必须学点什么，必须看点什么，必须往知识库里，存点什么。
结语
Addy Osmani 在博客最后写了句话，我特别想拿来做结尾：
Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.
设计这个循环。但要像一个打算继续当工程师的人那样去设计，而不是像一个只负责按按钮的人。
知识库这件事也一样。
Loop 替你跑腿，但知识库怎么组织、什么内容值得存、标签怎么打...这些判断还是你的。
AI不会替你做这些决定，它只是让你终于有精力去做这些决定。
感谢你看到这里。
我建了一个 AI 交流群，群的信息密度很高，也有很多AI行业的从业者。
如果你是以下选手：
一线 AI 从业者——工程师、产品经理、创业者、投资人
正在把 AI 融入自己的业务或工作流
对 AI 工具、Agent、大模型落地有真实的经验和困惑
不只是想"学 AI"，而是想和同行交流、找资源、找合作
我是 Simonlin，下次见。
