今天看到一位朋友分享他读另一个人 skill 的感受，里面有一句话很打动我：
读来读去，真正学到的，不只是这个 skill 在解决什么问题，而是它背后反映出来的工作方式。
我觉得这句话非常准。
很多时候，我们看到一个 AI skill、一个 prompt、一个 agent 配置，表面上像是在看“一个工具怎么写”，但真正值得学习的，往往不是那个局部功能，而是它背后隐含的上下文组织方式、协作方式，以及它如何让 AI 在复杂任务里不失忆、不跑偏、不黑箱。
最近我越来越觉得，未来每个人大概率都要给自己搭一套 context infra。
这个词如果翻成中文，我更愿意叫它：个人的上下文基础设施。
它不是知识库，不是一堆 prompt，也不是某个神奇 agent 的配置文件。
它更像是：
你给自己的 AI 配的一套工作底座，让它在任何时候都能比较稳定地拿到“该知道的背景、该遵守的规则、该记住的东西、以及该留下的痕迹”。
为什么现在会越来越需要这套东西
以前大家更爱讲 prompt engineering。那时候问题比较简单：怎么写一句更好的话，让模型回答得更像样。
但现在任务越来越不是“一问一答”了，而是要多轮推进、调用工具、跨天持续、查资料、做判断、写产物，甚至要在多个 agent 或多个阶段之间接力。
这时候真正决定结果的，往往不是 prompt 的某一句写得漂不漂亮，而是：
- 这一轮到底该给模型看什么
- 哪些信息该常驻，哪些该临时拿
- 哪些该长期记住，哪些该及时忘掉
- 中间过程要不要留下痕迹
- 任务中断之后怎么继续
换句话说，问题从“写 prompt”变成了“设计上下文系统”。
Context Infra 本质上是什么
如果非要打个比方，我会这么理解：
- 模型像 CPU
- 工具像 I/O
- 上下文窗口像内存
- 文件、记忆、规则、日志像磁盘和配置系统
- 工作流编排像调度器
所以个人 context infra，本质上是在给个人 AI 配一层“操作系统”。
不是为了显得高级，而是因为如果没有这层，AI 每次都像刚入职一天的实习生：不知道你是谁，不知道你想怎么协作，不知道这个项目的规则，不知道哪些旧信息还有效，做完一大段事情，也没有留下可复查的过程。
一切都只能靠聊天临场猜。这在简单任务里还凑合，在复杂任务里就会越来越不稳。
我现在认为最重要的四个重点
1）先搭“工作台”，再谈“智能”
很多人会先追求更强模型、更复杂 agent、更高级自动化。但我现在越来越觉得，真正优先级更高的事情是：先把 AI 开工时要读的那个“工作台”搭起来。
也就是让它一进来就知道：你是谁、我是谁、我们怎么协作、这个项目的边界是什么、默认输出格式是什么、哪些任务应该走哪种流程。
像 AGENTS.md、SOUL.md、USER.md、WORKSPACE.md、COMMUNICATION.md、skills/INDEX.md 这类文件，看起来像文档，实际上更像“AI 的入职手册 + 工作守则 + 项目环境说明”。
它们的价值不是文件名本身，而是它们把原来只能靠聊天临时讲清楚的东西，变成了稳定、可继承、可更新的上下文入口。
这一步做完之后，AI 的状态就会从“每次重新认识你”，变成“带着长期协作框架开始工作”。
2）把记忆分层，不要把 prompt 当硬盘
这是第二个特别重要的点。很多人默认把聊天记录当全部记忆，但这种方式很快就会坏掉。
因为聊天历史天然会越来越长、越来越乱，而且里面混着当前任务信息、临时尝试、旧结论、已经过时的偏好和不再重要的上下文。
如果这些东西都一股脑塞给模型，最后很容易得到的不是更聪明，而是更混乱。
所以我觉得，个人 context infra 必须至少把记忆分成几层：
- 工作记忆：当前这轮正在做什么
- 短期记忆：这个任务最近推进到了哪里
- 长期记忆：你的稳定偏好、长期背景、关键决策
- 程序性记忆：有哪些已经验证过的流程、skill、playbook
最关键的一点不是“记得更多”，而是“记得对”。该长期保留的是稳定信息，不是全部聊天流水。
3）强制中间过程落地，减少黑箱
这是我这次最想强调的一点。一个 AI 系统如果只给你最后结论，而没有留下中间痕迹，它其实很难真正成为可靠的工作伙伴。
因为你不知道：它查了什么、它漏了什么、它中途怎么判断的、它在哪一步开始跑偏的。
所以我越来越认同一种做法：对复杂任务，强制保留中间物。
比如：
scratchpad.mdsearch_manifest.mdnotes.mdbrief.md
这些东西不是形式主义，它们有非常实际的价值：方便复盘、方便纠错、方便跨阶段续做、方便多人或多 agent 接手，也方便把“思考过程”从脆弱的上下文窗口里转移出去。
说白了，它们是在把 AI 的黑箱变成半透明系统。
4）让 context 成为基础设施，而不是一次性喂料
很多人和 AI 的协作方式，本质上还是“一次性喂料”：这次我把背景贴一大段，你先做，做完就散，下次再重新来过。
这种方式的问题是没有复利。而 context infra 的思路，是把这些内容沉成稳定层：
- 规则沉成规则文件
- 偏好沉成用户文件
- 项目背景沉成 workspace 文档
- 阶段状态沉成 brief
- 搜索路径沉成 manifest
- 经验沉成 skill / playbook
这样你不是每次都从头开始，而是在持续建设一个越来越像“个人 AI 工作环境”的系统。
如果让我给一个人从零开始搭，我会建议这样做
我不会一上来建议搞很重的系统。更现实的顺序是：
第一步：先建一个固定 workspace
至少有：AGENTS.md、SOUL.md、USER.md、MEMORY.md、memory/、projects/、skills/、notes/、scratchpads/。
第二步：先把最稳定的协作规则写出来
比如默认怎么汇报、哪些事可以直接做、哪些事要先确认、你更喜欢看到摘要还是完整方案、项目内的基本规范是什么。
第三步：把长期信息从聊天里抽出来
比如你的长期偏好、项目的长期背景、已经做过的重要决策、那些反复重复、值得沉淀的经验。
第四步：对复杂任务默认留中间物
哪怕一开始只有三样也够：search_manifest.md、notes.md、brief.md。一旦这三样开始稳定存在，你的 AI 工作流就会比纯聊天稳很多。
第五步：再考虑异步、多阶段和多 agent
这个顺序很重要。因为很多人一开始最容易犯的错，就是还没把基础文件化，就急着追求很复杂的全自动编排。最后系统很炫，但没人维护得动。
对个人来说，更好的路线通常是：先让规则稳定、记忆可取、过程可查，再逐步增加编排和自动化。
我现在最认同的一条判断
如果要我用一句话总结这次的思考，我会说：
个人 context infra 的重点，从来不是让 AI “知道更多”，而是让它在需要的时候，稳定拿到“最该知道的那一小部分”，并且把过程中真正重要的东西沉淀下来。
所以它的关键不在“堆”，而在分层、筛选、沉淀、检索、追溯和接力。
当这些东西开始成形时，AI 才不再只是一个会聊天的工具，而更像一个真正能长期协作的工作系统。
这大概也是为什么，有时候读别人一份 skill，会突然觉得自己学到的不只是某个招式，而是一种新的工作世界观。