夜雨聆风
当资料开始交给 Agent 协作，最先暴露出来的，往往不是模型不够聪明，而是文档没有一个能被找到的入口。
这件事对一个人承担多种工作的主理人尤其明显。选题、信源、文章状态、操作说明和交付边界，如果只存在于某个人的记忆里，下一次协作就很难真正接上。
Blume 提供了一个观察入口
最近看到的 Blume，公开页面把它定位为 Markdown-first、AI-ready 的文档方向。GitHub 仓库、官网和 npm 页面都能看到这个方向的公开信号。
页面还列出了 llms.txt、原始 Markdown、Copy as Markdown、Ask AI 和 MCP 等机器读取或交互入口。
这些信息可以帮助我们看到一个变化：文档正在被要求同时服务于人和机器。
但这里要把边界说清楚。本文没有做本地运行验证，也不把页面列出的每个入口写成稳定功能。blume.new、useblume.dev、GitHub 仓库和 npm 页面之间的完整身份对应关系，当前仍需要继续确认。官网示例中出现的其他内容，也不能直接算作 Blume 的功能。
所以，Blume 在本文里只是一个公开观察入口，不是一份产品测评。
文档的角色正在变化
过去整理文档，主要是为了让人下次能看懂。现在只要它会被 Agent 反复调用，要求就多了一层：
它要让下一位执行者找到入口，理解范围，知道哪些内容可以引用，知道下一步怎么做。
我更愿意把这看成文档结构的变化，而不只是又多了一个工具。
机器可以读文字，不等于它能稳定定位重点。页面有 Markdown 入口，也不等于 Agent 会自动理解版本、来源和事实边界。
文档一旦要参与协作，标题、层级、入口、来源、状态和下一步，都会影响它能不能被正确使用。
先解决“下次接不上”
一份资料最麻烦的状态，不一定是内容少，而是内容明明存在，却没有留下清楚的接续方式。
比如一份 SOP，读者可能需要知道：
- 这份资料解决什么问题；
- 从哪里开始；
- 需要准备什么输入；
- 最后应该得到什么输出；
- 哪些部分来自原始信源；
- 哪些内容只是暂时判断；
- 当前处在草稿、待确认还是已完成状态。
这些内容并不新鲜，却经常分散在标题、正文、聊天记录和个人记忆里。人还能靠经验补全，Agent 没有这层默认经验，结果就容易变成“读到了，但没有真正接上”。
对 45+ 一人公司主理人来说，这不是给文档增加一套漂亮格式，而是减少下一次找资料、解释背景和返工的时间。
AI-ready 的最小结构
如果只整理一份高频资料，我会先看下面几件事。
1. 标题和层级要能定位
标题不要只写一个漂亮的主题词。它最好能让人和 Agent 知道，这份资料处理的是什么问题，适用于哪一个阶段。
小标题也不必追求整齐对称。只要能够说明“这里解决什么”“下一步要看哪里”，就已经比一串没有方向的段落更有用。
2. 入口和适用范围要说清楚
资料的开头应该告诉读者从哪里开始，以及这份资料不负责什么。
一份发布前检查表，不应该被误读成发布工具；一份产品说明，也不应该被当成最新版本的承诺。边界写出来，后面的调用才不容易走偏。
3. 输入和输出要能对上
Agent 需要知道交给它什么，也需要知道完成后应该留下什么。
如果只有“请整理”“请检查”这样的动作描述，却没有输入格式、输出文件或验收条件，协作就很容易回到反复解释。
这也是一个人工作时最容易省略的部分：自己知道下一步要做什么，就以为别人也知道。等到换一个工具、换一次会话，问题才重新出现。
4. 来源和事实边界要保留
能被机器读取的文档，不能因此省略来源。
原始链接、信源名称、发布日期、事实边界和未确认事项，仍然要留在资料里。公开页面写了什么、我们推断了什么、还没有验证什么，最好分开记录。
这样做不是为了把文章写得更像报告，而是为了让下一次协作知道哪些话可以直接用，哪些话必须继续核验。
5. 状态和下一步要落地
一份资料如果没有状态，Agent 很难知道它是草稿、待人工确认，还是已经可以交付。
状态也不需要很多。重要的是让人和机器都能看懂当前停在哪里，下一步由谁决定。
这几项放在一起，才构成一份比较实用的最小资料。单独增加一个 llms.txt，并不能替代内容本身的结构。
机器可读，不等于自动可用
AI-ready 这个词容易让人产生一种错觉，好像只要把文档转成 Markdown，再接上 MCP，问题就解决了。
实际情况没有这么简单。
Markdown 解决的是一种开放格式问题。llms.txt 解决的是入口问题。Ask AI 或 MCP 解决的是某一种读取和交互方式。它们都不能自动保证内容层级清楚，也不能自动保证来源没有过期，更不能自动保证 Agent 不会误读。
同样，公开页面展示了某个能力，也不等于它已经在当前版本、当前环境和当前语言内容上稳定运行。
我会把这件事分成两层看：工具可以提供入口，但资料仍然要自己留下边界。入口越方便，越需要知道它把什么交给了谁。
先整理一份，不要全面改造
一人公司没有必要一开始就重做整个资料库。
可以先挑一份经常复用的 SOP、产品说明或文章资料，补齐标题、入口、输入输出、来源、边界和状态。
然后用一次真实工作检验：下一次的人和 Agent，能不能从同一个入口开始；能不能找到原始来源；能不能知道哪些内容还没有确认；能不能在完成后留下清楚的结果。
如果这一次能接上，再考虑扩大范围。接不上，就先修资料，不急着增加工具。
这件事和 45+ 有什么关系
45+ 学习 AI，最值得保留下来的，往往不是某一个工具的操作顺序，而是已经积累下来的判断：什么资料值得留，什么结果需要复核，什么事情不能交出去。
如果每换一次工具，都要把过去的资料、规则和边界重新解释一遍，时间就会消耗在搬运上。文档结构清楚一些，至少能把一部分积累留在自己掌握的地方。
这不意味着机器会替代阅读和判断。相反，资料越容易被调用，越要把最后的责任边界写明白。
对一人公司来说，文档不是做完就结束。它还要让下一次协作找得到、接得上、用得对。这个要求看起来朴素，却会直接影响返工和交付。
先把一份资料整理好
Blume 的公开定位，让我们看到文档正在从阅读材料走向 Agent 可以检索、引用和调用的接口之一。
但这不等于现在就该迁移工具，也不等于所有入口都已经经过验证。
我会先把一份最常用的资料整理到下一次能找到、能理解、能继续用，再决定是否扩展到更多资料。先把边界留住，工具的选择反而会清楚一些。
