$ man context-wiki/context-repository

上下文仓库是 GitHub 仓库中的一组 Markdown 文件，包含你的 AI 系统需要知道的一切。产品、角色画像、消息框架、语音指南、工作流文档、合作伙伴详情。你更新一次这些文件，每个触及你仓库的 AI 代理都会自动获取最新版本。无需在聊天窗口中复制粘贴上下文。无需每次会话都重新解释你的业务。仓库就是上下文。我的整个 GTM OS 仓库就是一个上下文仓库。每个技能文件、每份语音指南、每个合作伙伴研究文件夹。它不是我在工作之外另外维护的东西。它本身就是工作。

模式

阶段 1：我做，AI 协助起草。你写内容，AI 建议修改。大多数人停留在这里。 阶段 2：AI 监控并发现偏差。AI 监视你的仓库查找不一致之处。消息框架变了但邮件模板没更新？AI 标记出来。 阶段 3：AI 做更改，我通过 PR 审批。AI 提出更新，你审查并合并。这是最佳平衡点。90% 的效率加上 100% 的控制。你不是在交出钥匙。你是在审查工作。 阶段 4：AI 做所有事，无需人类审查。全自动驾驶。对面向客户的内容来说风险较高。对内部自动化（如仪表板和数据同步）很有用。 我的大多数工作流运行在阶段 3。Claude 写代码、写内容、写营销文案。我审查、调整、批准。上下文仓库使阶段 3 成为可能，因为 Claude 有足够的上下文来产出值得审查的工作。

模式

至少需要：一个 CLAUDE.md（环境默认值和代码风格）、一份语音指南（你的表达方式）、产品文档（你卖什么）、ICP 定义（你卖给谁）、角色画像层级（你和谁对话）、以及工作流文档（你怎么运作）。在此之上：带有研究资料的合作伙伴文件夹、每个重复工作流的技能文件、文件特定模式的规则文件、内容草稿和已发布存档、以及营销文案模板。你放得越多，需要解释的就越少。解释越少，速度越快。我的仓库有 40 多个技能、完整的语音系统和每个合作伙伴的研究文件夹。Claude 不需要简报。它直接读文件。

专业技巧

Markdown 是带有简单格式的纯文本。人类可读，AI 可解析，可在 Git 中进行版本控制，可渲染为 HTML。没有需要担心的专有格式。没有平台锁定。没有转换步骤。你在任何文本编辑器中编写，提交到 Git，每个 AI 工具都能原生读取。我见过团队试图用 Notion 或 Google Docs 作为上下文层。问题在于访问。AI 代理在工作流中无法方便地读取 Notion 页面。但它们可以即时读取你仓库中的 Markdown 文件。保持简单。保持在仓库中。