(本文整理自 2026-05-07 到 2026-05-13 之间我和 Codex 的 53 次本地会话，加上事后自己的复盘。文字部分由 Claude 协助打磨。)
写在前面
我先把这一周里发生的事用一段话讲一遍。
5 月 7 号那天我刚装好 Obsidian，本来是想找个新的 Notion 替代品，记记知识、做做清单。一周以后，这个东西已经变成了某种我自己也没预想过的形态——它在替我管理饮食、衣橱、健康、财务、读书、游戏、影视，甚至连家里冰箱里有什么、上周哪天穿了什么、最近哪只信用卡的开卡奖快达标了，它都知道。每天晚上自动跑一遍整理任务，把当天产生的碎片塞回该去的位置。我把这个状态叫做"赛博影分身"——它不是另一个我，但它替我盯着一切我不想每天盯着的东西。
让我自己更意外的是搭的过程让我重新想了一遍一个老问题：之前我一直以为"想到一个需求，做一个 App"是这一代 AI 工具最自然的玩法，因为 vibe coding 让 MVP 的成本压到太低了。这一周我反向走了一遍，几乎所有原本想做成独立 App 的东西，最后都收回到了 Obsidian 里。为什么会这样，下面慢慢讲。
如果你也在折腾 PKM、个人 AI agent 这条线，希望这篇能省你一点弯路。
一、装 Obsidian 之前，我其实已经为这些需求做过几个失败的 App
时间线得稍微往前推几个月。
那段时间 vibe coding 刚火起来。我自己也跟着热闹了一波——AI agent 把 MVP 的成本压得太低了，一个晚上能起 Next.js + Supabase，第二天能跑 OAuth，再过两天能把第三方商店的数据抓回来塞进数据库。看上去脑子里每个念头都值得被做成 App。
我先后认真试过几个方向：一个穿搭管理工具，一个饮食追踪工具，一个爱好/小物记录工具。功能演示都能跑，前端也都做出来过。我甚至专门为它们租过 AWS、买过域名，写过爬商品页的脚本去补图。
但真用起来就尴尬了，问题不在功能本身，而是产品壳。登录、云同步、移动端、跨设备状态、部署、数据库、备份、迁移——为了让一件本来只是"我自己想知道我有什么"的事情跑在一个 SaaS 形态里，我得维护半个产品。如果是面向大众的，市面上下厨房、Vinted、Goodreads 这些早就把整个生态做完了，我做的复制品没有任何理由让别人用；如果只是面向自己的，那这一堆 cloud infra 显然过载。
把 App 的壳剥掉以后，剩下的真正东西其实非常简单：
- 衣橱核心上就是一张物品表，加几个字段：品牌、类别、价格、状态、上次穿、穿了几次、有没有评价。
- 冰箱核心上是库存批次表加消耗事件表。
- 饮食是餐厅、菜品、个人口味偏好。
- 游戏是一个个游戏条目加玩后体验。
这些都是 Excel 加一点文字说明能解决的问题。真正缺的其实是另一样东西：一个能让我"想到了顺手说一句，剩下让程序帮我归档"的系统。“App"反而是绕路。
我跟人聊起这段时通常会用一句更直接的话总结：这一代 AI 让做 App 变便宜了，但没让"需要被做成 App"这件事变多。 私人数据天生主观、私密、碎片化，越往云端搬反而越累。
二、装好 Obsidian 的当晚，方向就变了
5 月 7 号晚上我刚装好 Obsidian，第一条问 Codex 的是字面意义上的"obsidian 和 notion 有什么区别？好用么”。
第一轮搭出来的骨架很朴素：一个 00 Inbox 收散东西，下面跟着每日记录、知识库、私人记录、项目与计划、清单、旅行、购物、模板。每个文件夹塞几张种子页面、几个模板。这套结构如果只看截图，跟所有 PKM 教程里画的没什么差别。
但坐下来准备开始用的那一刻，方向其实就变了。我突然意识到，我想要的根本不是"另一个笔记软件"。我真正想要的是：我突然想到什么，可以直接跟 AI 说一句，剩下让它帮我决定该归到哪里去。手写归档对我来说是有摩擦力的事情，每次坐下来"整理一下笔记"都是心理负担。
所以当晚我在那个朴素的骨架旁边加了一个新的文件夹，专门给 AI 用。它后来改了好几次名字，最终叫"AI 书记"。一开始里面只有三样东西：一个收件箱（所有 AI 暂时不知道往哪放的东西先丢这里）、一份写入规则（明确告诉 AI 哪些情况能直接写、哪些必须落待确认）、一份给 ChatGPT/Codex 用的入口提示词。
也是从那一刻起，我每次往里加内容都会多问一句：这条结构、这个字段、这种命名，AI 一个月后能不能找回来。这个心理动作后来贯穿了整周。
三、用旧博客把过去的自己塞进来
很多 PKM 教程从"分类怎么分"开始讲。但对一个空 vault，最关键的一步其实是把过去的自己导进来。
我从 2015 年开始陆陆续续写博客，文章存在本地的 Documents/myblog 里。我没让 Codex 把它们一股脑塞进"归档"目录，而是按主题打散：计算机科学的实验和课程笔记进知识库，旅行游记进旅行，西雅图的本地美食记录进饮食的"本地探索"分支，2020 年那段关于 SDE 入职焦虑的反思进私人记录。
更有用的是反向操作：让 Codex 把这些旧文章读一遍，提炼出几张索引——我的经历时间线、去过的地方、我知道的东西、本地生活资料索引。这一步之后，vault 不再只是"我未来要写的东西"的容器，而是"过去的我"和"现在的我"之间的一座桥。
后来我加新内容时反复体会到好处。比如加 Nico（我家猫）的档案时，Codex 会主动去交叉引用这些索引，跑回来问我：“是不是该在你的『重要的人和事』里也提一下 Nico？"；又比如加身体健康那个区时，它会提醒我"你 2022 年的爬山博客里提到过的扭伤，要不要补一条历史伤病？“这种自动联想之所以可能，全靠最初冷启动时把过去的内容当地基用过一遍。
所以这段我想留个判断给自己以后看：公开写过的东西，反而帮私人系统打了地基。 博客这种公开写作有个意外的副作用——它逼着你在过去的每个时间节点上留下一些自己后来能读懂、AI 也能读懂的上下文。
四、把 AI 当"机委书记”，而不是当聪明的小机器人
第三天我把那个最初叫"AI 记录系统"的文件夹改名为"AI 书记”，因为它的定位变了。它不再只是个 inbox，而是整个系统的维护层。
到最后定型时它里面装了几样东西：
- 一份写入规则：每个区的入口、能不能直接写、写入的最小信息要求、哪些事情不能编造、新增餐厅要联网核实、新增 Switch 游戏要写哪些字段、私人对象哪些不可公开。
- 一份自动化流程说明：每日 / 每周 / 月度的整理任务怎么跑，每一步要扫哪些页面、产出哪些日志。
- 一组 scripts/：所有维护脚本，主要是 Node.js (
.mjs)。命名规律verb-noun-detail.mjs，比如import-weread.mjs、generate-wardrobe-landing.mjs、sync-pantry-consumption.mjs。 - 一个收件箱：暂时不知道往哪放的内容先落这里，定期被回扫。
- 一份 memory.md：给 Codex 的 Scheduled Tasks 当运行 memory，记录上次跑到哪里、跳过了哪些条目。
这里有一个我后来反复跟朋友安利的判断：个人知识库不是靠完美分类维持的，是靠防漏流程维持的。
差别非常本质。完美分类是一种静态承诺，第一周还行，第二周就开始失守——因为现实里你写下的东西从来不会刚好落在某个文件夹里。防漏流程则是动态兜底：
- 每日整理回扫的窗口是"今天 + 昨天"。22:30 之后写的内容经常会被深夜任务错过，多扫一天就能补回来。
- 每周复盘回扫的窗口是"最近 10 天"。即使每日任务在某天意外失败、跳过、跑挂了，每周任务也能兜住。
- 整理任务永远先跑一遍 dry-run，把"有什么新东西、能匹配上什么、需要待确认的有哪些"列清楚，确认完才正式写入。
- 待确认的条目都带 checkbox，等我手动勾选过后，对应脚本才会把它们迁进正式区。
另一组我反复强调的边界：
- 能确定的直接写。Gmail 收据里清晰的金额、品牌、日期，不用等我确认。
- 不确定的进待确认池。淘宝标题里像某个品牌但又不确定的、视频抽帧看不清的卡牌名、邮件里被截断的 SKU，全部先存疑。
- 凭空想象的不写。这条是最重要的一条。我宁可让一格空着，也不要让 AI 编出来一个数字或一段评价。否则三个月后我会陷入"这条到底是我写的还是 AI 编的"的内耗。
五、衣橱是这个系统里最像"小型数据产品"的一块
如果只挑一块展开技术细节，我会选衣橱。它是整个 vault 里最像小型数据产品的部分，也是踩坑最多的一块。
5.1 一开始的乱
最早的需求很直接：把淘宝订单导出来扔进 vault。结果是：商品名是 SEO 长句，一条标题占满半行；表格特别宽根本没法看；淘宝 link 跳不回商品页（去 redirect 早就失效了）；一个订单可能对应多件物品，但表格是按订单平铺的；同一件衣服在 记账软件、快递单、Gmail 收据里出现三次，归不到一起。
显然不能就这么放着。
5.2 账本 vs 使用感：把两件事分开
我做的第一件事是把"购物记录"和"衣橱"拆开。
购物记录这一块只放原始购买事件，来自 Gmail / 淘宝 / 官网收据。它按时间排序，能算出"上个月在 Nordstrom 花了多少"。它不写主观评价，只保留事实。这一区类似账本。
衣橱那一块按物品和使用状态组织，每一件物品一个 markdown，记录"这件东西现在还在不在、好不好用、穿过几次、是不是可以清理"。它是我真正打开看的地方。
拆开以后两边都清爽了很多。账本天然是按事件，衣橱天然是按物品，硬塞在一起两边都会变形。
5.3 淘宝标题改成人能看的名字
进衣橱的条目必须改名字。原始的"2024 秋冬新款慵懒风韩版 chic 奶白色 oversize 圆领套头针织毛衣女学生"会被我手动 + AI 协作改成"奶白色 oversize 毛衣"，再用 description / source 字段保留必要的原始信息。这一步看似小事，但直接决定了一年后我打开衣橱页时还愿不愿意看下去。(这里Claude喝假酒乱编了,我根本没有这么一件衣服😆)
5.4 商品图：用 Chrome DevTools 录 HAR 这个 trick
衣橱不能没有图。但商品图这件事极其麻烦：直接登录态访问淘宝、把 cookie 给脚本？不行，太危险；手动 DevTools 截图？效率极低；把图下载到 vault？Obsidian Sync 容量根本不够（我只买了 1GB，下面会专门说）。从品牌官网找同款？很多淘宝的东西品牌官网根本搜不到。
后来折腾出来一个我觉得挺通用的 trick：用 Chrome DevTools 录 HAR。
具体流程是：
- 浏览器登录淘宝，打开"已买到的宝贝"页面；
- 开 DevTools 的 Network 面板；
- 滚动 + 翻页，把订单都 lazy load 出来；
- “Save all as HAR with content”，得到一个 HAR 文件；
- 把 HAR 丢给 Codex。
HAR 里有什么呢？我后来发现淘宝订单接口叫 mtop.taobao.order.queryboughtlistv2，response 里有商品标题、SKU、店铺、日期、价格，以及 img.alicdn.com 上的商品图 URL。
import-taobao-thumbs.mjs 就是围绕这个写的，几条铁律：
- 只读 HAR 的 response content，绝不输出 request headers、cookies、authorization。这一点很重要，因为 HAR 文件里其实有完整的登录态，处理时必须只看响应不看请求。
- 优先从订单 JSON 里抽商品图；抽不到再退回到普通 HTML 上下文里找
alicdn.com链接。 - 不直接按顺序硬塞，而是用标题、SKU、价格、店铺、日期等上下文，跟衣橱里已有的物品做模糊匹配。
- 匹配上以后给条目补
thumb、image_source、image_checked字段；信心不够的进待确认池。
Gmail 这边的 Nordstrom、adidas、Nike、Lululemon、Nintendo 收据走的是另一套类似流程：Codex 用 IMAP / Gmail API 搜对应品牌的收据邮件，把订单金额日期归到购物账本，把有长期使用价值的物品同步到衣橱或娱乐区；能从官网或品牌页查到同款图的就补 product_url 和 thumb，查不到或不确定的不硬填。
这里有个经验我后来很认：AI 适合做"搜索、比对、补字段"，不适合做"凭空认图、凭空猜同款"。 一旦让它猜，就会出现把一双白色 Veja 匹配到 Common Projects 这种灾难。
5.5 物品页是 frontmatter，展示页是脚本生成的
我真正打开看的衣橱总览页不是手写表格。每件物品有自己的单页，frontmatter 长这样：(yaml没错,内容是Claude编的,哪来的1850rmb的Miu Miu啊)
| |
然后 generate-wardrobe-landing.mjs 扫所有 type: wardrobe 的 markdown，把它们汇总成四块：卡片式 grid（按 category 分块、状态高亮、缩略图、价格、穿着次数）、好物点评（review 写得长或被标了 favorite 的）、闲置柜（status: idle 的，可考虑清理）、家居服与日用消耗品（专门一个分类，不掺进主图）。
也就是说，日常维护只改单页 frontmatter，不手写展示页。一年后我有新物品只要新建一个 md；想加"颜色"字段就改 schema + 生成脚本；想筛"最近 30 天没穿的"在脚本里加一个分组就行。
这套做法背后的心得是这样：淘宝订单不是衣橱，衣橱是从订单、图片、评价和穿着记录里生成出来的。 把购买痕迹（收据、HAR、邮件）当原料，把使用痕迹（OOTD、review、wear_count）当主轴，把展示页当派生产物。
这套思路后来直接被搬到 Switch 游戏库（每个游戏一个 md，frontmatter 写 type: switch_game、status、platform、thumb，封面走外链代理）和冰箱（下面会单独讲）。
六、影视、游戏与"AI 怎么把我的体验问出来"
游戏这一块我想单独留两段。
我玩完 Stray 后随手写了几行体验，觉得太干瘪，又不知道接下来该写什么。于是和 Codex 商量了一个访谈流程：先让它读已有笔记和这款游戏的公开资料；然后让它出 3–5 个具体问题引导我回忆——比如"第几关让你印象最深？最后一段的城市灯光有没有让你想起西雅图哪个角落？你觉得猫这个 POV 选择改变了哪些游戏机制？"；我打字回答，它把答案整理回我的玩后感页，保留我的原话风格，不去统一改成"流畅书面语"。
最后流程跑顺以后我让它把这套问法保存成一个可复用的 skill，下次再有新的玩后感、观后感、读书笔记可以直接调用。
让我意外的反而是 AI 在这种场景下扮演的角色。它跳出了总结器、速记员这一类被动定位，开始主动给我搭脚手架——把我没想清楚的部分用问题逼出来。我后来对其他 AI 工具的态度也因此变了：能让它问出我自己也没想清楚的东西，才算它真在我这边干活。
另一段是 Slay the Spire 的视频抽帧。我玩这个游戏录过几段手机视频。让 Codex 用 ffmpeg 抽帧、识别角色、分数、层数、死因/胜利、看得清的卡牌和遗物，最后整理出 2026-05-07 到 2026-05-10 之间 13 局有效战绩，2 局胜利、6 局开局放弃。
它整理完丢回给我时附了一句：
视频反光和模糊比较明显，所以卡牌/遗物名只记录了看得清的构筑线索；角色、日期、分数、层数和死因/胜利相对可靠。下一步最值得补的是两局胜利局单独复盘，以及两局静默猎手 50 层失败的对比。
这句话里包含的东西比战绩本身有用：可见性边界（“看得清的”）、置信度评估（“相对可靠”）、下一步建议（“最值得补”）。这正是我希望 AI 在维护我个人系统时的样子——不要交一份漂亮的总结就跑，要把"哪些事情其实没那么确定"的判断责任明确传回给我。
七、饮食区从餐厅到冰箱：为什么最后是批次模型
饮食这一块从 2026-05-08 开始长起来，最初只是几张餐厅卡片，后来扩展成餐厅、个人饮食偏好、做过的菜、冰箱与零食柜。
我让 Codex 在新增餐厅时主动联网查公开信息：优先 Google Maps / Yelp / 官网，查不到就用其他公开来源，必须标注查询日期。这一条听上去鸡毛蒜皮，但西雅图很多店开开关关，2019 年导入的旧博客美食记录里有一半要标"已闭店"。三年后我看到一个"营业到 22:00"的字段，如果没有日期，我不知道它到底是 2019 年的事实还是 2026 年的事实。
中间还有一段挺有意思的小故事，5 月 10 号晚上我在 Bellevue 的深夜食堂吃饭，烧鸟串里加了紫苏叶。我老公说他们老家那边不吃紫苏。回家以后我跟 ChatGPT 聊了几句紫苏的食用习惯，让 Codex 把这段对话整理进 vault。它做了两件事：在知识库下面建了一张"紫苏食用习惯"的小卡，记中日韩三地的差异、烧鸟里出现紫苏叶的来历；又把"深夜食堂 Bellevue"升级成一张正式餐厅记录，关联到当晚的日记和紫苏卡。
我每次回看都觉得这件事代表了我希望 vault 长成的样子——从烧鸟串、墙上的照片、购物袋、游戏结算画面这些东西里长出来的活物，而不是一套先想好的抽象体系。
冰箱那一块走的弯路更典型。
加冰箱的那天我一开始就想做个"清单"：列出冰箱里有什么。但写到一半就发现这是个伪解法。清单解决不了几个真实的问题：
- 同样是"草莓果酱"，我有一罐 4 月买的快过期了，又有一罐 5 月新买的没开封——它们应该是两条记录还是一条？
- 我今天早上吃了两片培根，下午做菜又用了一段，这两个事件怎么反扣回库存？
- 我希望追踪"我吃各种东西的频率"，“喜欢的零食"就不只是一个开关，而是一组消耗事件的统计。
所以冰箱一开始就被设计成批次模型。采购记录按时间排（一张小票一次购物）；库存批次按同款同保质期合并、不同保质期拆分（4 月那罐草莓酱和 5 月那罐是两条 batch）；消耗事件记吃了多少、做菜用了多少、扔了多少、什么时候；食材档案只给高频复购或做菜常用的食材建一张档案页，写口味偏好、推荐用法、复购倾向。
配套两个脚本：sync-pantry-consumption.mjs 扫日记里类似"吃了 xxx"的句子，把消耗事件反扣到对应批次的库存；check-pantry-expiry.mjs 每天扫一遍批次保质期，把临期的列到首页"近期到期"那块。
这套模型解决的真正问题是会计意义上的：“我有什么"和"我用了什么"是两件事，不能塞在一张表里。 这跟资产负债 vs 损益的区别其实是一回事，只是换到了食物的语境里。
八、健康和财务这两块，写作上的克制比技术更难
我做了健康区和财务区，但这一节是这篇文章里我最不打算展开细节的部分。
健康区里我导入了 MyChart 的诊疗记录、化验结果、趋势 PDF，做了一页中文说明与建议、一页身体指标、若干睡眠和运动的入口。但我打定主意：这块的所有内容绝对不公开。这篇文章只留一句结构经验——健康数据进 vault 时一定要分"原始资料"和"我的复盘"两层。原始资料只本机存，复盘里只写自己看得懂的高层结论和下一步行动；任何具体化验值、诊断细节、用药剂量都不要摊在公开页。
财务区也类似。导入了记账软件 CSV 摘要、信用卡羊毛追踪、账单订阅、资产负债索引。但任何具体账户号、订单号、收据号、信用卡尾号一律不公开；羊毛追踪只写"哪张卡的开卡 bonus 什么时候达标"这类规则，不写"我现在卡了多少钱在哪”；整体净资产趋势可以放在 vault 里给自己看，不进任何公开博客。
这一段我能给读者的最实在的建议是：健康和财务的技术上跟饮食衣橱没有区别，但写作上完全不一样。 不要为了凑一篇博客里的细节就把这块掺进去。等真做完一遍你会很庆幸自己一开始就划清了这条线。
九、RSS：从订阅器到注意力配额
RSS 这一块我装了 Obsidian 上现成的 RSS Dashboard 插件，订阅了一堆源：朋友动态、YouTube、中文深度、AI 与技术、本地生活、潮玩。装完以后很快出了两个新问题，我让 Codex 帮我写了两个非常薄的小插件来解决。
第一个问题：RSS Dashboard 本身像个独立 reader，要切到那个标签页才能看。但我希望的是打开 vault 主页时顺手扫一眼有什么新东西。
所以写了一个叫 home-rss-panel 的小插件。它注册一个 Markdown code block processor：我在主页里写一段 rss-home 代码块，它就去读 .obsidian/plugins/rss-dashboard/data.json，按配置抽取条目，渲染成首页的「新鲜事雷达」。
配置长这样：
| |
这里有一个我后来很喜欢的小设计：不同信息源的权重不一样。原因来自一次很具体的崩溃。某一天我打开 vault，发现首页雷达全是"潮玩 X"那几个推主的内容——这个 folder 里订阅的几个潮玩资讯账号本来就发推很频繁，按时间排就压满了首页。这显然不是我想看到的"今天的世界”。
所以加了 folder-max: 潮玩 X=1 让潮玩最多出现一条；加了 folder-min: YouTube=1, 中文深度=2 给长视频和中文播客至少保留位置。说白了就是把注意力当成一个有限预算来分：高频来源不该挤占低频但珍贵的来源。
第二个问题更微妙：RSS Dashboard 能把整篇文章 save 到 vault，但 save 进来的是文章本身，不是我对它的反应。听一段播客时突然有感而发的两句话、看一篇长文时被击中的某段、想为它配上的"此刻情绪"，全没地方放。
所以又写了一个叫 rss-annotation-capture 的小插件。它在 RSS reader 的操作区塞了一个 highlighter 按钮，也提供命令面板命令。点击后弹一个 modal，可以记录：文章划线片段、当下短评、播客当前时间点（按 audio element 的 currentTime 取）、音频 URL 和原文链接。
保存时它做两件事：确保这篇 RSS 条目在 vault 里有一个对应的 markdown 笔记（默认在 RSS 暂存 目录），然后在笔记里追加 ## 我的划线 / 批注，并把 annotation 同步写回 RSS Dashboard 的 data.json——这样回到阅读器时也能看到已有批注数量。
这条线后来给了我一个挺扎实的判断：传统 RSS reader 解决的是"我看到什么"，但个人知识库真正需要的是"我当时为什么被它击中"。 划线和短评不是正式知识，没资格直接进知识库；但它们很适合先落到 inbox 或随笔区，由 AI 书记在每日 / 每周整理时判断要不要提炼成知识卡片、阅读随笔、博客素材，还是只保留为一条当时的阅读痕迹。
十、主页这条线踩了无数坑
主页是这一周里折腾时间最长的一块。
最初我说"参考 Blue-topaz-example 做个看起来像个人空间的主页"。Codex 装了 Blue Topaz 主题，按示例做了几张卡片、横幅、kanban，截图发我看。
然后就开始崩。
HTML 内的 [[wikilink]] 渲染不稳，移动端、Reading View、Live Preview 三种模式表现都不一样。嵌套 callout 在某些版本里直接被渲染成纯文本。CSS snippet 和主题 CSS 打架，调一个位置另一个位置就坏。frontmatter 没被 hide，露在页面顶上。
反反复复改了三四轮，最后我接受一个朴素结论：markdown 必须是底座，CSS 只能锦上添花。任何只能靠 CSS / HTML 才能稳定渲染的效果，都意味着以后某次 Obsidian 更新或某次移动端兼容会炸。所以我把主页的视觉降了一档：保留卡片化、保留分区、保留缩略图，但所有数据都用 markdown 写或者由脚本生成 markdown。
降完以后主页就从一个装饰问题变成了信息架构问题。日记入口必须只有一个，并且能自动打开 / 创建当日日记（用一个小命令插件实现）；首页信息过多就裁，只保留常用入口和需要顺手看一眼的状态；接入 Visual Crossing weather 插件，给三天天气预报；首页 KPI（OOTD 件数、衣橱物品数、Switch 游戏数、读过的书数）用 update-home-kpi.mjs 跑出来，避免变成假装动态的占位符；天气卡片做了横排三列，桌面和手机分别适配。
现在我打开 Obsidian 看到的主页就是一张"今日仪表盘"：天气、当日日记入口、新鲜事雷达、几个常用总览入口、一两个待办亮灯。它视觉上不算特别漂亮，但每天都能用，而且都准确。
总结起来：主页不是展示柜，是日常开机画面。
十一、Claude 和 Codex 在我这边各自坐在哪个位置
这一周里我同时在用 Claude 和 Codex，所以顺便讲讲它们俩在我的工作流里的分工。这不是"哪个 AI 更强"的争论，是"两个工具放在哪个位置最合适"的小经验。
Claude 在几件事上明显更好用：主页布局的整体气质、卡片层次、阅读节奏；衣橱 grid、物品详情页、餐厅卡片的视觉编排；文案语气的微调，特别是写"读起来像人写的"那种段落；把一个复杂功能页拆成 UI 层次。它的局限是 20 美元 plan 的额度消耗特别快，重度设计调整下基本每天只能认真磨一个局部。所以我会有意把 Claude 的时间留给"今天最值得有人审美一次的那一页"。
Codex 在另一类事情上极其稳：写脚本（导入、迁移、生成、批处理）；写 Obsidian 小插件；解析 HAR / CSV / PDF / Gmail 收据；修 frontmatter、跑批量校验、扫死链、清理重复条目；跑每日 / 每周的自动化整理。它对"反复细调一个视觉"的耐心不如 Claude，但对"把一个流程稳定化、可重复化"特别在行。
最后形成的工作模式是这样：Claude 帮我把一页做得有"人会愿意打开看"的样子，决定它该长什么样、读起来舒服不舒服；Codex 接手把它变成可重复生成的机制——脚本、frontmatter、批处理、HAR 抽图、外链代理、nightly run。
我自己呢，干三件事：决定什么进系统、决定哪些内容能公开、决定这一页"看起来像不像我"。
十二、博客和 vault 的回流闭环
最后一节，也是当前这个系统的闭环。
我的博客一直在 Documents/myblog，是个 Hugo 项目。冷启动时，vault 已经把旧博客文章读了一遍并打散到各个区。但反过来，新博客发布以后怎么自动回流到 vault？
我让 Codex 写了 myblog/scripts/sync-to-obsidian.mjs。它的逻辑很克制：扫 myblog/content/post 下所有 draft: false 且 date 在某个窗口里的文章；把每篇拷贝到 vault 的 blog post 待归档 目录，保留 frontmatter；只做单向归档，不自动拆入正式区——交给 AI 书记或我自己再决定它该出现在哪里；按 slug + date 判重，跳过已经导入过的旧文。
这一步意义不大但分量挺重。它意味着我公开写作和私人系统之间形成了一个回路：旧博客冷启动 vault → vault 里长出的反思和素材 → 写成新博客 → 新博客发布后回流到 vault → vault 上下文更新 → 下一篇博客。
你正在读的这篇就是这个回路的产物。它的草稿叫《Obsidian 建库长文线索》，存在我 vault 的随笔区里；素材来自 Codex 那 53 次会话和 vault 里散落的笔记；发布以后会被 sync-to-obsidian.mjs 抓回到归档目录；过几周我再回看时，AI 书记可能会问我：“这篇里提到的几个脚本，要不要单独建几张知识卡片？”
十三、说几个目前的真实局限
这一周的成果听上去挺漂亮，但说实话现在这个系统离"全自动"还差不少。讲几个目前真实存在的问题，免得这篇看上去太像广告。
第一个最重的限制：它非常依赖每日记录和我手动跑脚本。
整个体系背后的假设是"我每天会写一段日记，AI 会从里面把碎片捞回来"。一旦哪几天我没写日记，整个数据流就开始空转——衣橱不会更新穿着次数，冰箱不知道我吃了什么，娱乐总览也不会有新条目。AI 书记的"防漏扫"能兜住部分情况，但兜不住"压根没素材"的情况。
类似的，几个关键的视图（衣橱总览、Switch 总览、首页 KPI、近期到期、新鲜事雷达）都依赖脚本主动跑一遍才会刷新。我现在的做法是接到 Codex 的 Scheduled Tasks，每天晚上自动触发；但只要某天 Codex 任务跑挂了或者跳过了，第二天首页 KPI 就还是旧的。系统本身不会自我修复，需要人去 review 任务执行日志。
第二个限制：KPI 不能自动更新。
首页那几个数字看上去像 Dashboard，但其实是脚本写进 markdown 的，并不是 live query。同一时刻不同设备打开看可能是同一份"昨晚 23:00 跑完的快照"。要做到真正的 live query，需要 Obsidian 的 base 视图或 Dataview，但 Dataview 在 frontmatter schema 灵活的情况下性能很糟糕，base 又还在 early 阶段，整体不够稳。所以暂时妥协成"每天刷新一次"。
第三个限制：Codex Scheduled Tasks 跑的还是远端 Codex。
每次跑一次整理任务其实会消耗模型额度，长期看不便宜，而且每一次自动化都需要把 vault 里相关页面送进上下文。这意味着两件事：一是隐私上，我得相信 OpenAI 的隐私策略；二是成本上，未来如果整理频率加大、vault 体量翻倍，这是一个会越来越贵的依赖。
长期想法是：等本地模型 + 本地 agent 成熟以后，把每日 / 每周的整理任务迁到本地跑。
理想形态大概是这样：本地跑一个长期 agent（参考 Codex / Claude Code 的 agent loop），定时扫 vault 里所有可能需要处理的事件——日记里新写的内容、Inbox 里新增的条目、待确认池里被勾选的 checkbox、各种 frontmatter 是否需要补全、脚本是否需要重新跑——能本地处理的本地处理，需要 reasoning 的才走云端模型。这样既能解决隐私问题，又能解决频率问题，还能在没有人主动触发的情况下让系统持续自检。
但这要等到本地能跑的小模型在 tool use 和长 context 上都足够好。目前 7B-30B 那一档的本地模型，做日常的"分类、归档、补字段"应该 OK，做"看一篇微信读书的画线然后判断要不要进知识库"还不够稳。等什么时候本地模型能稳定吃下 100k context 又能跑 agentic loop，这一步就可以真正落地。
第四个限制，也是和上面相关的：Obsidian Sync 的容量。
我选 Obsidian Sync 而不是自建是有理由的。它是端到端加密的——服务端拿到的是密文，加解密都在我自己的设备上完成。这一点对我来说比"自建一套 Syncthing"重要得多，因为这个 vault 里现在已经有日记、健康记录、财务摘要、私人关系备忘这些内容了，我不太希望它走任何明文的同步通道。我也不想自己运维一台服务器去处理这套事情——多一个我可能哪天就不维护的东西。
但 Sync 的容量是按订阅档位的。我当时图便宜买了 1GB 那档，结果一周下来已经在精打细算每一兆。这也是为什么衣橱图、游戏封面、餐厅照片全部走外链，不下载到本地的根本原因。图片在 vault 里很容易迅速吃掉几百兆，而 Sync 的 1GB 是给 markdown / frontmatter / 关键附件用的，不能浪费在能外链的东西上。
凡是能外链解决的图片资源，我现在的处理方式是：要么用品牌官网原图链接，要么用代理过的 CDN 链接（避免直接暴露第三方原始链接，也避免对方某天换 CDN 我这边全部失效）；要么走我自己未来要搭的小 S3 桶。如果某张图必须存本地（比如自己拍的 OOTD 照片、Nico 的照片），就尽量先压一遍再放进 attachments，并且打 tag 方便以后批量清理。
未来想升级 Sync 容量吗？大概会，但优先级不高。目前的策略是"精打细算 + 优先外链"，反而逼着我把 vault 维持在一个轻量的状态。容量约束某种程度上是好事，避免我把这里搞成一个"什么都往里塞"的垃圾场。
第五个限制：vault 的可信度本身是脆弱的。
这一点最难讲清楚。当一个系统里既有我手写的、也有 AI 写的，那么"信任"本身就成了它最重要的 schema。所以我前面那些铁律——能确定的直接写、不确定的进待确认池、凭空想象的不写——并不只是工程纪律，而是这个 vault 能不能长期被我信任的根本。
但即便有这些规则，系统也并不完美。Codex 偶尔仍会写出"看上去合理但其实是它脑补"的句子；偶尔会把两个相似条目错误合并；偶尔会在某个 frontmatter 字段里塞一个奇怪的默认值。我现在做的事情是：每周复盘时随机抽查几条最新写入，看看有没有这种情况；以及把"AI 写入审计"列入待办，未来想做一个独立脚本，专门检查 frontmatter 字段的可信度和 review 文本的语气一致性。
十四、写在最后
总结一下这一周到底改变了什么。
结构上，AI 书记从一个 inbox 长成了维护层；饮食区从餐厅扩到冰箱与零食柜；娱乐区从 Switch 购买记录扩到游戏库、玩后感、影视；财务和健康区作为半私密板块加进来；衣橱和爱好物品区承接淘宝、Gmail 收据、OOTD、review、外链缩略图、闲置清理；随笔与草稿区承接还不稳定的写作种子。
工作流上，我从"为每个生活模块各做一个独立 App"改成了"把这些数据统一沉淀到 Obsidian"；从"写完再整理"改成了"先进 inbox，再回扫"；从"每条都问"改成了"能确定的直接写、不确定的待确认"；从"页面手工维护"改成了"frontmatter 加脚本生成"；从"图片存进 vault"改成了"优先外链"；从"购买就是购物记录"改成了"账本和使用感分两个区"；从"一个 AI 做所有事"改成了"Claude 做审美方向、Codex 做执行落地"。
但说实话，比这些改变更重要的是一个心态上的转变。
以前我看到一个生活上的小痛点，第一反应是"做个 App 吧"。现在我看到这种痛点，第一反应是"塞进 vault 里、写两行 frontmatter、跑个脚本能不能解决"。如果能，就到此为止；如果不能，再考虑下一步。
这种转变背后是一个更朴素的判断：对私人数据来说，AI 真正能帮的是替我接住所有的碎片，并在我没空的时候替我维护一个能继续生长的我。 它不需要给我变出一个产品。把碎片接住、把上下文维护好、把信任的 schema 守住，剩下"产品形态"那一层，对个人来说大多是噪音。
如果你也在搭类似的东西，最后送三句我最想跟一周前那个空白 vault 的我说的话：
第一句：先想清楚未来要读你的人是谁。 是未来的你，还是 AI 同事？两边其实差不多，但只要心里有了这个对象，写 frontmatter 时不会偷懒。
第二句：永远先做防漏，不做完美分类。 完美分类是一个会让你两周后放弃 vault 的承诺；防漏流程是一个会让你忍受 vault 不完美的能力。
第三句：不要让 AI 编。 宁可空着、宁可待确认池里堆一堆 checkbox，也不要在 vault 里留一句是 AI 凭空写出来的话。这条值千金。个人系统不像生产系统，没有 unit test 兜底——信任就是 schema。
写完了。如果你也在搭，vault 里见。