当AI助手从单一工具演变为协作团队，管理复杂度正成为新的挑战。本文揭秘如何通过本地文件系统打造AI共享工作区，用Markdown文档构建项目四件套与共享记忆库，实现跨工具的无缝协作与知识传承。从临时对话到系统性管理，这套轻量级解决方案正在重新定义人机协作的边界。

这两天，我在自己的电脑上干了一件有点奇怪的事：给AI装修了一间办公室。

不是比喻。

我是真的在D盘建了一套目录结构，写了一批 Markdown 文档，然后告诉 Codex、Claude Code、WorkBuddy这些智能体应用：你们以后共用这个地方工作。

这件事让我意识到，我和AI的关系，正在从「使用工具」变成「管理团队」。

01 做这件事情的起因

起因其实很日常。

我现在不是只用一个AI工具。

• Codex是我的主力Agent，用的是ChatGPT的最新模型，负责绝大多数复杂任务的处理、推进和协调，同时也协助我管理其他AI助手；
• Claude Code是我仅次于Codex的强力助手（接的是DeepSeek v4模型），主要用于处理代码工程、基础内容创作、审查分析等各类复杂任务；
• WorkBuddy是这个”工作室”的助理，则主要用于处理相对简单的日常任务。

它们各有所长，各有边界，我会根据任务需要在它们之间随时切换。

但问题来了：它们经常彼此不知道对方做过什么。

比如，我经常在Codex里说清楚了一个项目的目标、文件位置和后续计划，转头打开 Claude Code去处理这个项目的其他环节时，所有背景又要重新解释一遍。

还有，经常会出现一个项目在一个AI助手那已经整理得很清楚了，但另一个 AI 接手时，它根本不知道该去哪找。

更麻烦的是，不同工具会把输出散落在不同目录。时间一长，连我自己都不知道：这个项目到底在哪？哪个版本是最终版？哪个AI改过？下一步还有什么没做？

这不是AI不够聪明的问题。而是它们缺少一个共同的工作场。

于是我有了一个想法：能不能在本地电脑上，给这些AI搭一个统一的“办公室”？

虽然AI工具各自的能力和运行机制不动，但长期项目、共享背景、协作规则和交接记录，都放到一个共同空间里，这样它们就能各显神通的同时，又能信息共享、高效协作，实现1+1＞N的效果。

我把这套东西叫做 AI Workshop。

AI Workshop：C盘保留工具自己的家，D盘作为共同办公室。

02 为什么是D盘？为什么不动C盘？

这里有一个设计原则，我觉得挺重要：

C盘是各工具的“家”，D盘是它们共同的“办公室”。

Codex、Claude Code、WorkBuddy原本自己的配置、登录状态、缓存、会话记忆和运行文件，一律不动。

因为这些东西是工具自己的“家”，强行迁移可能破坏它们原本的运行机制。

而 D:\AI-Workshop，则是它们共同工作的地方：放共享文档、长期记忆、项目成果、交接记录，以及工作制度和协作要求。

更准确地说，AI Workshop不是要取代某个 AI 工具原有的记忆，而是在它们之上加一层共同事实源。

也就是说，Codex仍然有自己的全局规则，Claude Code仍然有自己的工作方式，但它们都可以通过D盘这个共享空间，理解同一套用户背景、项目索引和协作制度。

有点像一家企业给不同部门的员工建的共享知识库。

每个部门有自己的工作方式，但重要的项目文档、公司制度和客户信息，都放在同一个地方，所有人都能找到，都能快速了解项目信息和进度，实现高效协同。

03 工作区长什么样？

整个AI Workshop的核心，是几份承担不同角色的文档。

你可以把它们想象成一家公司的基础设施：有员工手册，有公司制度，有当前项目白板，还有每个部门的工作说明。

AI员工进到这个办公室后，必须先读这几份文档，就像新员工入职第一天先了解公司一样。

USER.md：记录我的长期用户背景、偏好、业务方向和工作方式。AI进来之前先读这份，它至少知道我是谁。

WORKFLOW.md：多个AI助手必须共同遵守的工作制度，相当于公司员工手册。

CURRENT.md：当前状态白板。最近在推进什么，哪些已经完成，哪些风险还悬着，随时更新。

AGENTS.md / CLAUDE.md / WORKBUDDY.md：不同AI助手的入口说明，让它们知道进入这个工作区后应该如何协作。

为什么不用一份统一的 Agent 文档？

我们一开始也考虑过。

但现实是，不同工具对入口文件的识别方式不一样：Codex更适合通过 AGENTS.md 接收规则，Claude Code 更适合读 CLAUDE.md，WorkBuddy本身则没有那么清晰的工程型入口。

最后评估下来，决定采用的方案是：共享核心文档 + 各助手专属入口文件。

共享事实集中放，各AI入口只做适配和指引（相当于告诉AI，每次干活前必须先去”办公区”转一圈了解一下最新动态和要求）。

04 最关键的设计：轻量启动，按需加深

不过这套系统要想持续高效运转，就必须要解决算力成本和运转效率的问题。

也就是说如果每次打开 AI，新对话都要求它读取所有规则、所有项目、所有历史文档，token成本会很高，效率也会变差。

但如果什么都不读，AI又什么都不知道。

怎么办呢？后来我就借鉴了AI调用Skill的方式：Agent调用 Skill 时，不是一开始把所有Skill的内容都读进来，而是先只浏览一遍所有skill的名称和描述，判断应该调用哪一个。这样就能避免每次AI都要把所有skill的Prompt都读一遍，而极大浪费token。

所以，我就把这个思路迁移到了这套系统上：

日常任务：只读USER.md+CURRENT.md+当前AI的入口文件。它知道我是谁，知道现在在什么阶段，知道自己应该怎么工作，够用了。

跨Agent协作/制度相关：再加载WORKFLOW.md。

涉及具体项目：先查PROJECTS.md轻量索引（就像调用skill前先看名称和描述），通过项目名、路径、状态和简介判断是不是要找的目标项目，确认了之后，才进去深度查看项目的细节和文档。

通过这种方式，就能有效控制长期使用中的上下文成本。

后面即使项目越来越多，AI也不需要每次扫描所有文件夹的内容，而是先看索引，再决定是否深入。就像图书馆的检索系统，不是把所有书都搬到你面前，而是先告诉你书在哪一个书架的哪一排。

05 项目四件套：让项目可以被接手

每一个正式项目，都会要求AI创建并维护四份文档：

1. PROJECT.md：项目档案卡。这个项目是什么，从哪里来，谁负责，现在是什么状态。
2. INDEX.md：文件索引。哪些是最终成果，哪些是素材，哪些是中间产物。
3. CHANGELOG.md：修改记录。每次重要改动都记下来，避免不同 AI 接手时不知道谁改过什么。
4. TODO.md：下一步待办、风险和需要确认的问题。

这组四件套文档的意义，是让项目具备可接手性和延续性。

以前一个项目可能只存在于某个AI助手的某个聊天窗口里，窗口一关就断了。

现在只要四件套维护得好，任何一个AI助手进入项目后，先读这几份文件，就能快速恢复上下文。

它不一定能看到旧会话里每一句话（也不现实），但能恢复到足够继续工作的状态。

就像一个的随时留痕的项目管理手册，有了它，不管谁来接手，都能快速上手。

我们现在要做的，就是在每个项目上，给AI也都创建一套这样的项目管理手册，接手的AI助手在完成了项目任务或修改后，也会自动把四件套的文档进行更新维护，方便自己下一次或下一位AI能精准接盘。

06 共享记忆：让 AI 越用越了解我

除了项目层面，我们还建立了共享memory。

这里不是把所有聊天都存下来，而是只沉淀长期稳定、跨项目有价值的信息：

1. preferences.md：我的沟通偏好和工作方式
2. business-context.md：业务背景和长期方向
3. decisions.md：关键决策和判断依据
4. glossary.md：常用术语和定义

这样做的目的，是让多个AI助手能够同步了解我，而不是只让某一个工具在自己的封闭记忆里了解我。

不仅如此，以后如果再有其他的AI智能体加入时，也能够通过这些文档快速了解“公司”发展和老板的情况，从而能快速融入，不需要再从零开始磨合。就像一个团队里，新人入职会读公司文化手册、了解业务背景一样。

07 迁移历史项目时，学到的一件事

搭这套系统的过程中，有一个很现实的问题让我卡了一会儿。

旧会话窗口绑定的是C盘原始项目路径，当原路径被清理后，旧窗口会提示“当前工作目录缺失”。

如果旧窗口里还有没做完的任务，这就很麻烦。

为了解决这个问题，我们用目录联接做了兼容入口：让旧路径看起来仍然存在，但实际是把AI引到D盘的新项目目录（相当于在这个AI助手的老宅里创建了一扇任意门，AI打开老宅的门就直接穿越到新的办公室的指定档案柜，然后继续工作。 突然觉得还挺科幻的，哈哈）。

这样旧窗口可以继续工作，写入的文件也会自动落到D盘的workshop，不会重新制造两套文件。

其实，迁移这件事本身也是有讲究的：不是简单一股脑地搬文件就完事儿了，而是要从建立新秩序的角度综合考虑哪些该迁移那些不能迁，哪些能删哪些暂时不能删。

比如之前AI工具产出的报告、脚本、HTML、素材就需要迁移；node_modules、缓存、安装产物通常不需要迁，因为它们在新的共享工作区可以重新生成。

在给AI搬家的时候，我会让AI把每一次迁移和清理的动作，都更新到migrations\MIGRATION_LOG.md，避免以后忘了哪个项目原来在哪、有没有清理过、有没有待办等等。

这件事让我意识到：

真正可用的AI工作系统，不是一次性设计出来的，而是在真实使用中不断修补迭代出来的。

08 最后，把它封装成了一个 Skill

当这套系统基本跑通之后，我们把整个搭建过程封装成了一个Skill。

这意味着它不再只是我电脑上的一次性工程，而变成了一份可复用资产。

里面包含部署流程、安全规则、迁移手册、文档职责说明、token 成本控制策略、项目模板、共享记忆模板和脚手架脚本。

如果以后要在另一台电脑上搭建同样的系统，或者有人也想搭自己的本地 AI 工作室，也可以调用这个Skill，让自己的AI Agent按照同样的逻辑一键部署。

工具可以复用，经验也可以复用。

这件事真正的价值是什么？

回头看，这次搭建最有价值的地方，不是我建了几个文件夹，也不是写了几份 Markdown 文档。

而是我开始从“使用 AI”转向”管理 AI”。

以前使用 AI，更像是打开一个工具，问一个问题，等一个答案。

现在我开始思考的是：AI 的工作目录在哪里？长期记忆如何沉淀？项目如何被索引？不同 AI 如何分工？文件如何迁移？上下文如何交接？历史成果如何资产化？

对我而言，这也是我的个人工作系统的一次大升级。

AI 越强，对于复杂的长期项目来说，越不能只靠临时对话来管理。

因为临时对话会断，窗口会关闭，上下文会压缩，文件会散落。

真正能留下来的，是结构、规则、索引、文档和可复用流程。

我越来越觉得，未来深度使用AI的人，都需要搭建一套自己的AI工作基础设施。

它不一定复杂，也不一定要产品化，但至少要回答几个问题：

• AI如何理解我和我要做的事？
• 如何找到项目？
• 如何知道当前状态？
• 如何接手之前的工作？
• 如何把一次次任务沉淀成长期资产？

过去，我们整理文件夹，是为了让自己找得到东西。

现在，我们整理文件夹，也是为了让 AI 找得到东西。

过去，我们写项目文档，是为了交接给人。

现在，我们写项目文档，也是在交接给 AI。

过去，一个人想拥有团队，需要招人、培训、管理。

现在，一个人也可以先从管理自己的 AI 助手开始，逐步搭建一套轻量但可持续的本地 AI 工作系统。

这次，我给本地 AI 搭了一间办公室。关于这套系统，还有很多细节，因为篇幅有限，这次就暂时不展开了。如果感兴趣，欢迎私信交流。

本文的目的主要是想分享一个趋势判断，在AI时代，管理AI，比使用AI更重要。

我接下来要做的，就是让这支AI团队真正参与到我的长期工作里，这套系统也会持续迭代和成长。