你有没有这种体验？

早上打开微信、即刻、Product Hunt、Hacker News，信息刷了三页，收藏也存了一堆，越看越焦虑，但真正坐下来准备写东西的时候，脑子里只有一个问题：

所以，我今天到底该讲什么？

我曾经在这个环节卡了很久。

工具越用越多，信号源越接越多，平台越铺越开，但“今天说什么”这件事，并没有因为工具更多而自动变简单。

而只要这一步不稳定，后面所有动作都会开始漂：

  • 文章会写成信息堆积

  • 视频会做成另一套逻辑

  • agent 协作会越来越像接力赛，而不是同一条线

  • Agent助手再多，也只是在放大混乱

所以这套系统真正的起点，不是“怎么提高产能”，而是一个更朴素的问题：

怎么让我每天开工之前，先锁定一句值得发出去的判断。

这套选题系统的三次进化：先解决信号太多选不过来，再解决内容协作，最后把核心读写拉回本地。

这套选题系统不是先有完整架构图，再一步步照着搭出来的。它是被三次真实摩擦，硬生生逼出来的。

一、第一步：先把“今天讲什么”变成一个可以重复回答的问题

最开始，我面对的是一种很典型的内容混乱。

每天能看到的东西很多：Product Hunt、Hacker News、GitHub Trending、海外创作者频道、中国平台反馈、社群讨论，全部都在往同一个工作台上涌。

如果只看表面，你会以为问题是搜集不够快、归纳不够多、工具不够强。

但实际跑下来，真正会让节奏断掉的，不是“没有素材”，而是：

没有一个统一的决策起点。

后来我逼自己先写一句带判断的话。我内部把它叫做 thesis，你也可以把它理解成：当天最核心的判断。

它不是主题，不是栏目，不是标签，而是一句明确到足以驱动后续动作的话。

从这里开始，Daily Thesis Brief 的第一版才真正成形。它不是一个“为了看起来完整而做得很满的模板”，而是一个最低可运行单元：先把每天最关键的几个决策逼出来。

它后来逐渐变成一套检查清单，但真正最关键的，其实只有前四项：

  • 今天到底要说什么

  • 为什么偏偏是今天说

  • 这句话说给谁听

  • 中国读者能从中得到什么

剩下的文章结构、视频拆法、交付安排，本质上都只是围绕这句判断展开。

这一步看起来像是在做模板，但本质上不是。

我真正修复的，是“工具很多，但每天没有开工总开关”这个问题。

也正因为这样，这套系统从第一天起就不是“工具优先”，而是“判断优先”。

二、第二步：光有模板不够，我还得让文章、视频和状态走在同一条线上

当“先锁判断”这一步成立之后，新的问题很快就出现了。

模板能让一个人更快开工，但它不能自动保证整条生产线是顺的。

很快我发现，真正会反复出错的地方有三个：

  • 信号收集和正式简报之间断层很大

  • 文章和视频经常围着同一个题目，却没有围着同一个判断

  • 生产状态只能靠聊天记忆，今天推进到哪一步并不透明

于是系统开始进入第二层：从“一个模板”，长成“一个能跑起来的内容层”。

当时我做的动作很简单，就是把系统拆成两个容器：

  • Content Ideas Inbox：负责接住原始信号

  • Daily Thesis Brief Tracker：负责承接正式执行

这一步很重要，因为它第一次把“灵感”和“生产”分开了。

以前最容易发生的事，是一个新信号刚出现，大家就开始写、开始做、开始讨论形式，最后一半时间花在返工上。

而有了候选池和正式简报之后，链路第一次变清楚了：

  • 原始信号先进入候选池

  • 候选池里的东西先被判断

  • 只有被选中的判断，才进入正式简报

  • 一旦进入正式简报，文章和视频就共享同一个核心判断、同一组论点

这一步带来的最大变化，不是“效率提升了多少”，而是：

文章和视频终于不再像两个平行项目，而是开始像同一个判断的两种表达。

三、第三步：内容开始跑顺之后，agent 协作反而成了新的瓶颈

接下来，系统遇到的就不再是内容问题，而是协作问题。

一旦我不再满足于“有人手动把简报写出来”，而是想让 Maia、Claude、Codex 这样的不同 Agent 角色真的配合起来，新的摩擦就会立刻冒出来：

  • prompt 到底谁在维护

  • 任务到底谁来派

  • 谁负责查资料，谁负责搭系统

  • 结果到底回到哪里，才不会淹没在聊天记录里

如果这些问题没有显式结构，Agent 角色一多，看起来很强，实际运行起来却很虚。

所以到了 2026 年 3 月中旬，这套系统又往上长出了一层。我后来把它理解成：Agent 协作的调度层。

它把原本散落在对话里的协作规则，拆成了几种看得见的对象：

  • 角色名册

  • 提示词库

  • 任务队列

  • 结果回收区

这时系统第一次不只是“管理内容”，还开始“管理协作本身”。

而其中最重要的一条规则，其实只有一句话：

只有 Maia 负责派发。

也就是说：

  • Maia 负责分发任务

  • Claude 和 Codex 作为执行角色

  • prompt 不再靠临时口头转述

  • 结果不再只存在聊天窗口里

这一步看起来更像工程设计，但它背后解决的，仍然是一个非常实际的生产问题：

如果任务、角色、输出和状态都不显式，Agent 角色越多，流程越容易失控。

四、真正逼我从 Notion 切到 Obsidian 的，不是偏好，而是稳定性

但这时候我踩了一个更大的坑。

系统的大脑放在 Notion 上，看起来很整齐，展示起来也很好看，但真跑起来的时候，最脆弱的地方根本不是页面设计，而是：

Agent 角色到底能不能稳定地把这套系统读起来、写下去。

在 Notion 作为主要运行面的时候，系统的确已经很像一个完整平台。

以 Notion 为主的时期，内容数据库、Agent 调度层和协作状态都挂在外部工作台上。

以 Notion 为主的时期，系统看起来已经很完整，但真正决定它能不能跑下去的，不是页面多漂亮，而是 Agent 角色能不能稳定读写这一层外部工作台。

真正的问题在这里：

  • Agent 角色通过 MCP 这层连接框架去读 Notion 数据库，本身就很脆弱

  • MCP 这一层并不稳定，经常会失败

  • 某些线程里，读库和写库会突然断掉，或者授权失效

  • 一旦日常读写不能稳定交给 agent，系统就会退回到手工 copy-paste

以 Notion 为主的工作流里，原始信号到正式简报、正式简报到文章和视频、状态到协作之间都容易失真。

以 Notion 为主的工作流里，真正难的不是把页面搭出来，而是让判断、产出和状态真的走在同一条线上。

所以真正逼我切走的，不是我突然更喜欢本地笔记，也不是因为 Obsidian 的界面更好看。

真正的原因很直接：

Agent 角色通过 MCP 读取 Notion 数据库这件事，太脆弱、太不稳定，而且经常失败。

一次真实的 Notion 查询失败现场：Subagent 超时，未能获取 Notion 数据。

一次真实的 Notion 查询失败现场。问题不是理论上会失败，而是真的会在日常运行里直接断掉。

这也是为什么，2026 年 3 月 17 日，这套系统出现了最关键的一次转向：

从以 Notion 为主，切到本地优先、以 Obsidian 为主。

这个决定的意义，不在于“换了一个工具”，而在于我终于把日常运行依赖的核心读写，从一条经常失败的外部链路，拉回到了最稳定、最可控、最容易修复的本地文件层。

现在这套本地化结构大致是：

  • Ideas/

  • Briefs/

  • Tasks/

  • Reports/

  • Prompts/

  • Indexes/

  • Schemas/

切到 Obsidian 之后的本地架构：本地文件仓成为核心数据层，Agent 角色直接围着 markdown 与脚本工作。

切到 Obsidian 之后的本地架构：核心状态回到本地文件层，Agent 角色终于能够稳定地直接读写。

关系不再依赖外部数据库里的隐式关联，而是落在文件头标签和本地脚本里。

也就是说，系统开始从“把结构托管给外部工具”，转向“把结构写回我自己能控制的文件层”。

切到 Obsidian 之后，idea、正式简报、执行任务、结果回收与 dashboard 开始互相回写。

切到 Obsidian 之后，idea 先进池，正式简报锁判断，执行任务和结果回收承接中间过程，最终再把结果和状态写回同一个系统里。

这次迁移最重要的变化，不是界面更漂亮，而是 Agent 角色终于不用再隔着一层脆弱的 MCP 链路去读写核心数据库。

五、这套系统今天到底是什么

如果用一句话概括它现在的状态，我会说：

它是一套从“每日判断”出发、以本地 Markdown 为核心数据层，让内容生产和 agent 协作落在同一条工作线上运行的系统。

它今天不是一个单纯的写作模板，也不是一个抽象的多 agent 协作平台。

它更像一条被真实摩擦打磨出来的工作链：

  • Ideas 负责接住原始信号

  • Briefs 负责锁定当天判断

  • Tasks 负责派发执行

  • Reports 负责回收结果

  • Prompts 负责固定角色边界

  • Indexes 负责让人一眼看到当前状态

如果你只看最终结构，它会显得很整齐。

但只有回头看它怎么长出来，你才会发现：

这套系统每一层都不是“为了完整而加的”，而是“因为上一层已经开始不够用了”。

六、回头看，这个开发过程其实给了我四个很硬的教训

四种真实摩擦，逼出四条系统原则。

这套操作系统真正的设计文档，不只是架构图，而是它一路修过来的失败模式。

  • 做内容系统的起点不是工具清单，而是每日判断。只要判断不清楚，后面的文章、视频、封面、分发都只是在堆动作。

  • 文章和视频不能只共享主题，必须共享同一句核心判断。真正稳定的产出，不是同题多做，而是一条判断的多种表达。

  • 多个 agent 协作，必须有明确分工、明确任务入口、明确结果回写。否则“协作”最后只会变成更复杂的聊天。

  • 不要把日常运行的核心状态放在一条经常读写失败的链路上。只要 MCP 这一层不稳定，系统迟早会退回手工流程。

七、如果你问我，这套系统到底是怎么被开发出来的

我的答案不会是：

“我先想做一个很先进的内容操作系统。”

真正的答案更朴素：

我只是先想解决一个很具体的问题：

怎么让明天早上 10 点之前，就能说出一句值得发布的判断。

后面的模板、追踪器、任务队列、提示词库、本地文件仓，全部都是围绕这句话一点点长出来的。

所以如果你今天也想搭自己的版本，别急着买工具、建数据库、配自动化。

明天早上 10 点之前，先做这一件事：

写下一句判断。

让这句话能同时回答三个问题：

  • 文章写什么

  • 视频拍什么

  • 团队怎么分工

只要这一步稳住了，后面的系统，会自己长出来。