每一次 AI 对话都以相同的方式开始。你解释你是谁。你解释你在做什么。你粘贴你的风格指南。你重新描述你的目标。你给出和昨天一样的上下文，和前天一样，和大前天一样。然后，40 分钟后，模型忘记了你的声音，开始像写新闻稿一样写作。
我受够了这些。于是我构建了一个系统来修复它。
我称之为 Personal Brain OS。这是一个基于文件的个人操作系统，存在于 Git 仓库中。克隆它，在 Cursor 或 Claude Code 中打开，AI 助手就拥有了一切：我的声音、我的品牌、我的目标、我的联系人、我的内容管线、我的研究、我的失败。没有数据库，没有 API 密钥，没有构建步骤。只有 80 多个 Markdown、YAML 和 JSONL 文件，人类和语言模型都能原生读取。
我分享完整的架构、设计决策和错误，这样你可以构建你自己的版本。不是复制我的，而是你自己的。你的具体模块、文件结构、技能定义会根据你的工作有所不同。但模式是通用的。为 AI Agent 整理信息的原则是通用的。取你需要的，忽略你不需要的，然后交付一个让你的 AI 真正有用而不是泛泛而助的东西。
以下是我如何构建它、为什么架构决策很重要，以及我踩过的坑。
1) 核心问题：上下文，而不是提示
大多数人都认为 AI 助手的瓶颈在于提示。写出更好的提示，得到更好的答案。对于单次交互和生产的 Agent 提示来说确实如此。但当你希望 AI 在数周数月内像你一样完成数十个任务时，这套就失效了。
注意力预算：语言模型的上下文窗口是有限的，而且其中并非所有内容都是平等的。这意味着把你知道的一切都塞进系统提示不仅仅是浪费，还会主动降低性能。你添加的每个 token 都在争夺模型的注意力。
我们的大脑运作方式类似。当有人在你开会前给你介绍 15 分钟，你会记得他们说的第一件事和最后一件事。中间的部分会模糊。语言模型也有相同的 U 形注意力曲线，不同的是他们的曲线是可以数学测量的。Token 位置影响召回概率。新模型在这方面越来越好了，但仍然，你在分散模型对最重要事物的注意力。知道这一点改变了你为 AI 系统设计信息架构的方式。
我没有写一个巨大的系统提示，而是把 Personal OS 分成 11 个独立的模块。当我让 AI 写博客时，它加载我的风格指南和品牌文件。当我让它准备会议时，它加载我的联系人数据库和互动历史。模型在内容任务时永远不会看到网络数据，在会议准备时也永远不会看到内容模板。
渐进式披露：这是让整个系统工作的架构模式。系统不是一次加载所有 80 多个文件，而是使用三个层级。第一级是一个轻量级的路由文件，始终加载。它告诉 AI 哪个模块是相关的。第二级是模块特定的指令，只有在该模块需要时才加载。第三级是实际数据——JSONL 日志、YAML 配置、研究文档——只在任务需要时才加载。
这就像专家的运作方式。三个层级创建一个漏斗：先广泛路由，然后模块上下文，然后具体数据。在每一步，模型都拥有它需要的 exact 内容，不多不少。
我的路由文件是 SKILL.md，它告诉 Agent"这是一个内容任务，加载品牌模块"或"这是一个网络任务，加载联系人"。模块指令文件（CONTENT.md、OPERATIONS.md、NETWORK.md）各有 40-100 行，包含文件清单、工作流序列和该领域的<instructions>行为规则。数据文件最后加载，只在需要时加载。AI 从 JSONL 逐行读取联系人，而不是解析整个文件。三个层级，最多两跳就能找到任何信息。
Agent 指令层级：我构建了三层指令来界定 AI 在不同层级的行为方式。在仓库层级，CLAUDE.md是入职文档——每个 AI 工具都先读取它，获得项目的完整地图。在大脑层级，AGENT.md包含七条核心规则和一个决策表，将常见请求映射到精确的操作序列。在模块层级，每个目录都有自己的指令文件，包含领域特定的行为约束。
这解决了困扰大型 AI 项目的"指令冲突"问题。当一切都存在于一个系统提示中时，规则会互相矛盾。内容创建指令可能与网络指令冲突。通过将规则限定在它们的领域内，你消除了冲突，给 Agent 清晰、不重叠的指导。层级结构也意味着你可以更新一个模块的规则而不必担心回归到另一个模块的行为。
我的 AGENT.md是一个决策表。AI 读到"用户说'给 Z 发邮件'"，立刻就能看到：
模块级文件如OPERATIONS.md定义优先级（P0：今天做，P1：本周，P2：本月，P3：待办），让 Agent 能够一致地分类任务。Agent 遵循我使用的相同优先级系统，因为系统是成文的，而不是隐含的。
2) 文件系统即记忆
我做过最违反直觉的决策之一：不使用数据库。没有向量存储。除了 Cursor 或 Claude Code 的功能外没有检索系统。只有磁盘上的文件，用 Git 版本控制。
格式-功能映射：系统中的每种文件格式都是出于特定原因选择的，与 AI Agent 如何处理信息有关。JSONL 用于日志，因为它的设计是追加写入的、对流友好（Agent 逐行读取而不必解析整个文件），且每行都是独立的有效 JSON。YAML 用于配置，因为它能干净地处理层级数据，支持注释，对人和机器都可读，不会像 JSON 括号那样嘈杂。Markdown 用于叙事，因为 LLM 原生读取它，它在任何地方都能渲染，在 Git 中产生干净的 diff。
JSONL 的追加写入特性防止了一类 bug，即 Agent 意外覆盖历史数据。我见过用 JSON 文件发生这种事——Agent 写入整个文件，丢失了三个月的联系人历史。使用 JSONL，Agent 只能添加行。删除是通过将条目标记为"status": "archived"来完成的，这保留了完整的历史用于模式分析。YAML 的注释支持意味着我可以为我的目标文件添加 Agent 会读取但不会污染数据结构的上下文。Markdown 的通用渲染意味着我的风格指南在 Cursor、GitHub 和任何浏览器中看起来都一样。
我的系统使用 11 个 JSONL 文件（帖子、联系人、互动、书签、想法、指标、经历、决策、失败、参与度、会议）、6 个 YAML 文件（目标、价值观、学习、圈子、节奏、启发式）和 50 多个 Markdown 文件（风格指南、研究、模板、草稿、待办）。每个 JSONL 文件以 schema 行开头：{"_schema": "contact", "_version": "1.0", "_description": "..."}。Agent 在读取数据之前总是先知道结构。
情景记忆：大多数"第二大脑"系统存储事实。我的也存储判断。memory/模块包含三个追加写入的日志：experiences.jsonl（关键时刻及情绪权重评分 1-10）、decisions.jsonl（关键决策及推理、考虑的备选方案和追踪的结果）和failures.jsonl（哪里出了问题、根因和预防步骤）。
拥有你的文件的 AI 和拥有你的判断的 AI 是有区别的。事实告诉 Agent 发生了什么。情景记忆告诉 Agent 什么才是重要的，我会有什么不同的做法，以及我如何权衡取舍。当 Agent 遇到与我的日志相似的决策时，它可以参考我过去的推理而不是生成泛泛的建议。失败日志是最有价值的，它编码了真正付出痛苦才获得的模式识别。
当我决定是否接受 Antler Canada 的 25 万美元投资或加入 Sully.ai 担任 Context Engineer 时，决策日志记录了两个选项、每个选项的推理和结果。如果出现相似的职业权衡，Agent 不会给我泛泛的职业建议。它参考我实际上如何思考这些决策的："学习 > 影响力 > 收入 > 增长"是我的优先级顺序，"我能触碰一切吗？我会在能力边缘学习吗？我尊重创始人吗？"是我的公司加入框架。
跨模块引用：系统使用扁平文件关系模型。没有数据库，但结构化程度足以让 Agent 跨文件连接数据。interactions.jsonl中的contact_id指向contacts.jsonl中的条目。ideas.jsonl中的pillar映射到identity/brand.md中定义的内容支柱。书签为内容想法提供信息。帖子指标为周报提供信息。模块在加载时是隔离的，但在推理时是连接的。
没有连接的隔离只是一堆文件夹。跨模块引用让 Agent 在需要时遍历知识图谱。"准备我和 Sarah 的会议"触发一个查找链：在联系人中找到 Sarah，获取她的互动，检查涉及她的待办事项，汇编一份简报。Agent 跨模块跟踪引用而不必加载整个系统。
我的会前工作流链接三个文件：contacts.jsonl（她是谁）、interactions.jsonl（按 contact_id 过滤的历史）和todos.md（任何待办事项）。Agent 生成一页简报，包含关系上下文、上次对话总结和待跟进事项。无需手动组装。数据结构使工作流成为可能。
3) 技能系统：教 AI 如何做你的工作
文件存储知识。技能编码流程。我按照 Anthropic Agent Skills 标准构建了技能，这是结构化的指令，告诉 AI 如何执行具有内置质量门的特定任务。
自动加载 vs 手动调用：两种类型的技能解决两个不同的问题。参考技能（voice-guide、writing-anti-patterns）在 YAML 前置 matter 中设置user-invocable: false。Agent 读取描述字段并在任务涉及写作时自动注入它们。我从不调用它们，它们每次都静默激活。任务技能（/write-blog、/topic-research、/content-workflow）设置disable-model-invocation: true。Agent 不能自行触发它们。我输入斜杠命令，技能成为该任务的完整指令集。
自动加载解决了一致性问题。我不必每次要求草稿时都记得说"使用我的风格"。系统为我记住。手动调用解决精确性问题。研究任务的质量门与博客文章不同。将它们分开可以防止 Agent 混淆两种不同的工作流。YAML 前置 matter 是机制，几个元数据字段控制整个加载行为。
当我输入/write-blog context engineering for marketing teams时，五件事自动发生：风格指南加载（我如何写作）、反模式加载（我从不写什么）、博客模板加载（7 部分结构及字数目标）、检查角色文件夹是否有受众画像、检查研究文件夹是否有现有主题研究。一个斜杠命令触发完整的上下文组装。技能文件本身说"读取brand/tone-of-voice.md"，它引用源模块，从不复制内容。单一事实来源。
语音系统：我的声音被编码为结构化数据和一点氛围。语音档案在 1-10 分制上评估五个属性：正式/休闲（6）、严肃/有趣（4）、技术/简单（7）、内敛/表达（6）、谦逊/自信（7）。反模式文件包含 50 多个禁用词，分为三层，禁用开头、结构陷阱（强制三段论、避免系词、过度修饰）和每段一个破折号的硬限制。
大多数人来描述他们的声音用形容词："专业但平易近人。"这對 AI 没用。技术/简单上的 7 分告诉模型 exactly 要落在哪里。禁用词列表更强大；定义你不是什么比你是什么更容易。Agent 检查每个草稿与反模式列表的重合，并重写任何触发它的内容。结果是内容听起来像我，因为 guardrails 防止它听起来像 AI。
每个内容模板每 500 字包含语音检查点："我是否以洞见开头？我是否用数字具体化？我真的会发布这个吗？"博客模板内置 4 遍编辑流程：结构编辑（钩子是否抓住注意力？）、语音编辑（禁用词扫描、句子节奏检查）、证据编辑（声明有来源吗？）和朗读测试。质量门是技能的一部分，而不是事后添加的。
作为结构脚手架的模板：五个内容模板为不同内容类型定义结构。长篇博客模板有七个部分（钩子、核心概念、框架、实际应用、失败模式、入门、结尾），每部分有字数目标，总计 2,000-3,500 字。推文串模板定义了 11 帖结构，包含钩子、深度探讨、结果和行动号召。研究模板有四个阶段：景观映射、技术深入、证据收集和差距分析。
模板不仅约束创造力，也约束混乱。没有结构，Agent 产生无定形的文本块。有结构，它产生有节奏、有进展和有回报的内容。每个模板还包括一个质量清单，让 Agent 在展示草稿之前可以自我评估。
研究模板输出到knowledge/research/[topic].md，格式为：执行摘要、景观地图、核心概念、证据库（统计、引用、案例研究和论文均注明来源和日期）、失败模式、内容机会和按可靠性分级 HIGH/MEDIUM/LOW 的来源列表。那份研究文档然后馈入博客模板的大纲阶段。一个技能的输出成为下一个技能的输入。管道自我构建。
4) 操作系统：我实际上如何使用它
架构没有执行就等于零。以下是系统在实际中如何运行。
内容管线：七个阶段：想法、研究、大纲、草稿、编辑、发布、推广。
- 想法被捕获到
ideas.jsonl，使用评分系统，每个想法在定位、独特洞察、受众需求、时效性和努力与影响方面评分 1-5。如果总分达到 15 或更高则继续。 - 研究输出到知识模块。
- 草稿经过四遍编辑。
- 已发布内容被记录到
posts.jsonl，包含平台、URL 和参与度指标。 - 推广使用推文串模板创建 X 公告和 LinkedIn 适配版。
我在周日批量创建内容：3-4 小时，目标输出 3-4 篇起草和outline的帖子。内容日历将每天映射到一个平台和内容类型。
个人 CRM：联系人按四个圈子组织，有不同的维护节奏：内部（每周）、活跃（双周）、网络（每月）、休眠（季度重新激活）。每个联系人记录有can_help_with和you_can_help_with字段，启用双向匹配系统。交叉引用这些字段发现对双方都有价值的介绍。互动记录带有情感追踪（正面、中性、需要关注），所以关系健康一目了然。
大多数人在脑海中保存联系人，让关系因忽视而衰败。stale_contacts脚本交叉引用联系人（他们是谁）、互动（我们上次交谈何时）和圈子（我们应该多久交谈一次）来发现外联需求。每周 30 秒的扫描向我展示哪些关系需要关注。
circles.yaml中的专门群体——创始人、投资者、ai_builders、创作者、导师、学员——每个都有明确的关系发展策略。对于 AI 构建者：分享有用内容、在开源上协作、提供工具反馈、放大他们的工作。对于导师：带具体问题来、更新之前建议的进展、寻找回馈价值的方式。当我问"这周我应该联系谁？"时，这些是 Agent 遵循的操作指令。
自动化链：五个脚本处理 recurring 工作流。它们链接在一起进行复合操作。周日周报按顺序运行三个脚本：metrics_snapshot.py更新数字、stale_contacts.py标记关系、weekly_review.py生成总结文档，包含完成与计划对比、指标趋势和下周优先事项。内容想法链读取最近的书签、检查未开发的想法、生成新建议，并与内容日历交叉引用以发现排期缺口。这些不是 cron jobs——当我要 review 时 Agent 运行它们，或者我通过npm run weekly-review触发它们。
以 Agent 可读格式输出到 stdout 的脚本闭环数据和行动。周报脚本不仅仅告诉我发生了什么——它参考我的目标并识别哪些关键结果在轨道上、哪些落后以及下周要优先什么。脚本从 Agent 正常操作时读取的相同文件读取，所以没有数据重复或同步问题。
运行周报后，Agent 拥有更新下周todos.md、调整goals.yaml进度数字和提出与表现不佳的关键结果一致的内容话题所需的一切。review 不是一份报告——它是下周规划的开始。自动化创建反馈循环：目标驱动内容、内容驱动指标、指标驱动 reviews、reviews 驱动目标。
5) 我做错了什么以及我会如何不同做
- 我的第一版 schema 过度设计了。我的初始 JSONL schema 每个条目有 15+ 个字段。大多数是空的。Agent 与稀疏数据搏斗——它们试图填充字段或评论缺失。我将 schema 精简到 8-10 个必要字段，只在真正有数据时才添加可选字段。更简单的 schema，更好的 Agent 行为。
- 风格指南一开始太长了。
tone-of-voice.md第一版有 1,200 行。Agent 会强力开头，然后到第四段漂移，因为语音指令落入了"中间丢失"区域。我重新构建它，将最独特的模式（签名短语、禁用词、开头模式）前置到前 100 行，更长的例子放在后面。关键规则需要在顶部，而不是中间。 - 模块边界比你想象的更重要。我最初把 identity 和 brand 放在一个模块。当 Agent 只需要我的禁用词列表时，它会加载我的整个简介。将它们拆分成两个模块将纯语音任务的 token 使用量削减了 40%。每个模块边界都是一个加载决策。弄错它们，你就会加载太多或太少。
- 追加写入是不可协商的。我 early 丢失了三个月的帖子参与度数据，因为 Agent 重写了
posts.jsonl而不是追加。JSONL 的追加写入模式不仅仅是一个约定——它是一个安全机制。Agent 可以添加数据。它不能销毁数据。这是系统中最重要的架构决策。
6) 结果及其背后的原则
真正的结果比任何指标都简单。我打开 Cursor 或 Claude Code，开始对话，AI 已经知道我是谁、我如何写作、我在做什么、我关心什么。它用我的声音写作，因为我的声音被编码为结构数据。它遵循我的优先级，因为我的目标在一个 YAML 文件中，它在建议我做什么之前读取。它管理我的关系，因为我的联系人和互动都在它可以查询的文件中。
这一切背后的原则是：这是上下文工程，而不是提示工程。提示工程问"我如何更好地措辞这个问题？"上下文工程问"这个 AI 需要什么信息来做出正确的决定，以及我如何构建这些信息以便模型真正使用它？"
从优化单个交互转变为设计信息架构。它就像写一封好的电子邮件和建立一个好的文件系统之间的区别。一封好的邮件帮助你一次。一个好的文件系统帮助你每一次。
整个系统装在一个 Git 仓库中。克隆到任何机器上，将任何 AI 工具指向它，操作系统就运行了。零依赖。完全可移植。而且因为是 Git，每次更改都被版本化，每次决策都可追溯，没有任何东西会真正丢失。
Muratcan Koylan 是 Sully.ai 的 Context Engineer，在那里为医疗 AI 设计上下文工程系统。他的上下文工程工作（GitHub 8,000+ 星）在学术研究中与 Anthropic 一起被引用。之前在 99Ravens AI 担任 AI Agent Systems Manager，构建处理每周 10,000+ 交互的多 Agent 系统。