当大多数人还在用聊天窗口与AI交互时，Claude Code等工具已经展现出更强大的协作潜力。本文揭秘如何通过7天实战搭建AI工作台，将11个冗余目录精简至5个核心模块，提炼出9种工作模式和7个关键skill。从CLAUDE.md的8次迭代到skill体系的自然生长，揭示高效AI协作的底层逻辑——减法比加法更能创造价值。

最近在交流AI使用的时候，发现一个有意思的现象——很多人跟 AI 协作的方式，还停留在”打开网页聊几句”的阶段。

今天聊完了，明天打开又得从头说。文件夹建了一大堆，但真正用上的没几个。跟 AI 之间没有积累、没有记忆、没有标准化流程。

为什么会这样？因为你只是在”用 AI”，而不是在一个有结构的 AI 环境里工作。

像 Claude Code、Codex 这类工具，它们的能力远不止聊天。它们能读取整个文件夹、理解项目配置、记住你的偏好、执行标准流程——但前提是你得给它们一个”能工作的地方”。这个地方就是AI 工作台。

说白了，AI 工作台就是一套文件夹结构 + 配置文件 + 技能包，让 AI 打开就知道”你是谁、你在做什么、该怎么做”。没有它，你跟 AI 的协作是每次从零开始；有了它，AI 直接进入工作状态。就像你不会每次写代码都重新搭 IDE 一样，你跟 AI 协作也不该每次从头”聊”起。

所以我花了 7 天时间，用 Claude Code 给自己搭了一套 AI 工作台。

最终的结果是：11 个目录精简到 5 个，CLAUDE.md 迭代了 8 版，沉淀出 9 个工作模式和 7 个 skill。

整个过程走下来，让我收获最大的不是”搭好了”，而是”砍掉了什么”。这篇文章我就聊聊这个精简过程和背后的决策逻辑。

一、好的架构不是”加”出来的，是”砍”出来的

很多人搭工作台的第一反应是：”我应该建哪些目录？”

我的经历告诉我，这个问题应该反过来问：”哪些目录是可以砍掉的？”11 个目录到 5 个

最初规划了 11 个目录：

ai-workspace/
├── skills/   ├── memory/     ├── agents/
├── rules/    ├── workflows/  ├── prompts/
├── tools/    ├── knowledge/  ├── assets/
├── sessions/
└── templates/

看起来挺全面的对吧？但实际用起来发现一个问题——很多目录是”我觉得应该要”，而不是”我真的需要”。

第一次精简去掉了 rules/、workflows/、templates/。原因很简单：

•  rules/ 的功能被 skill 替代了 — 规则只有通过 skill 调用才有价值，单独放一堆规则文件没人看
• workflows/ 被 skill 的 scripts/ 吸收了 — 复杂流程直接嵌入 skill 内部
• templates/ 的格式直接融入 skill 指令 — 不需要单独管理

第二次去掉了 prompts/。通用提示词融入了 memory/，场景化的素材归入 assets/。

最后一次去掉了 agents/ 和 tools/——这两个目录一直空着，没有任何实际引用。

最终只剩下 5 个：skills/ — 核心：可复用的能力单元memory/ — 持久化知识文件knowledge/ — 外部文档和领域规范assets/ — 原始素材sessions/ — 对话归档

砍掉 6 个目录，不是因为它们没用，而是因为它们的价值可以被其他方式替代。

认知破壁：好的架构不是”加”出来的，是”减”出来的。你问”要不要加”永远有理由加，你问”能不能砍掉”才会真正思考每个东西存在的必要性。

二、CLAUDE.md 不是说明书，是行为驱动引擎

如果说目录是工作台的”骨架”，那 CLAUDE.md 就是它的”大脑”。

我在这份文件上迭代了 8 版，每一次迭代都在验证同一个原则：只写驱动行为的约束，描述性内容不写。8 版迭代的进化

v1→v2：去掉标题，直接进入角色。最开始有”AI Workspace 项目配置”这种标题，后来发现它不驱动任何行为。去掉标题后第一行就是”我是小瑞，你的 AI 助手”——打开文件就知道谁在跟你说话。

v3：加入工作模式。这一步是整个工作台的转折点。工作模式的概念出现后，CLAUDE.md 从一个”关于文件”变成了”操作手册”——每个模式对应一种任务类型，直接告诉 AI 该怎么做。

v5→v8：不断删减”不驱动行为”的内容。沟通约定？删掉。迭代进化原则？删掉。各目录使用指引？删掉。

最终只剩 4 章：

🤖 角色设定 — 我是谁，我怎么沟通
👤 用户画像 -> memory/user-profile.md
📁 工作区目录结构 — 5 个目录快速一览
🎯 工作模式（9 个） — 驱动所有行为的入口

其中”工作模式”是核心，9 种模式覆盖了从文档写作到产品设计到 Coding 的所有日常任务。每种模式引用对应的 skill 或 memory，CLAUDE.md 本身保持极简。

认知破壁：CLAUDE.md 的作用不是介绍项目，而是定义”我该怎么跟你协作”。你往里面写的内容，每一行都要问自己——”这句话驱动行为吗？”

三、Skill 不是写出来的，是”长”出来的

Skill 体系是工作台最有价值的部分，但最开始的技能并不是设计出来的——它们是从实际做事过程中”长”出来的。

从 0 到 7 个 skill

第一个 skill 是文件处理。因为经常要处理不同格式的文档（Word、PDF、PPT、Excel），每次都要告诉 AI “用这个库、那个方法”，太累了。于是写了一个 file-processor，把所有文件格式的处理方法打包在一起。

然后是产品管理。做 PRD、产品定型、PRD 审查这些事重复太多次了，整理成 pm skill，一次写好反复用。

再然后是 spec-kit。做开发项目需要规范驱动开发的工具链，干脆把 uv 和源码打包进 skill 目录，复制到新电脑就能用。

每一个 skill 都是因为”这件事我做了至少两遍，不想再做第三遍”的冲动。

关键设计原则

随着 skill 越来越多，总结出几条经验：

索引入口模式。同类 skill 聚合在一个父目录下，通过 SKILL.md 索引。比如 file-processor 下面有 docx/pdf/pptx/xlsx 四个子模块，pm 下面有产品定型、PRD 编写、PRD 审查等子模块。入口只有一个，里面怎么组织都行。

数据可流转。前一个 skill 的产出可以作为后一个 skill 的输入。比如调研结果可以直接喂给产品定型 skill。

可离线自包含。工具链打包在 skill 目录内，复制到新电脑后一条命令重建。不依赖系统环境。

砍掉不必要skill

不是所有 skill 都保留了下来。knowledge-refiner 和 session-archiver 两个 skill 后来被砍掉了——因为 AI 本身具备知识提炼和会话归档的能力，不需要专门写一个 skill 来指导。

这和学习目录精简是同一个逻辑：不是为了有而保留，而是为了有价值才保留。

认知破壁：Skill 不是”规划”出来的，是在做重复劳动时自然”生长”出来的。如果你没有”这件事我做够了”的冲动，你其实不需要这个 skill。

四、AI 工作台搭建的 5 条原则

回头看这 7 天的搭建过程，可以总结出 5 条原则。

原则一：CLAUDE.md 只写驱动行为的约束。

这句话被我反复验证了无数次。描述性内容不驱动行为，删掉。迭代进化原则不驱动行为，删掉。沟通约定不驱动行为，删掉。只有当你打开 CLAUDE.md 看到一行字就知道”哦，这时候我应该这么干”，它才是有价值的。

原则二：工作模式是入口，skill 是执行单元，memory 是沉淀。

这三者构成了工作台的核心运转逻辑。工作模式告诉你”现在要做什么”，skill 告诉你”怎么做”，memory 告诉你”之前积累了什么”。各司其职。

原则三：先做再优化，不追求一次性完美。

我的 11 个目录不是设计出来的吗？是。但最终留下的 5 个不是推演出来的，是用了之后砍出来的。先有一个能跑起来的版本，然后在实际使用中不断精简，比坐在那里空想要有效得多。

原则四：同类聚合，索引管理。

不要让你的 skill 散落一地。同类能力聚合到一个目录下，通过一个入口文件管理。这样既不会在需要的时候找不到，也不会重复造轮子。

原则五：自包含大于依赖安装。

能打包进去的就不要依赖系统环境。复制到新电脑能直接用的工具，比需要重新配置半天的工具，实用价值高 10 倍。

AI 工作台不是一个文件夹，它是一套你如何与 AI 协作的操作系统。

这套操作系统不需要一次性搭好，但需要你边用边迭代。关键是记住一点：每次打开文件夹，看到的东西应该驱动你做事，而不是让你困惑”这玩意儿是什么”。