从统一工作台到个人主阵地：AI工作空间的一次战略调整

上周四下午五点半，我坐在会议室里，对着投影幕上画的「统一工作台」架构图发呆。图上标满了各种颜色的箭头、模块、连接线，看起来规整、专业、无懈可击——但有个问题，就是我看着这张图，心里一点兴奋感都没有，反而有种「这东西搭出来，我自己都不想用」的预感。

事情是这样的。前两周我们花了不少精力在企微团队空间里搭了一套基于 OpenClaw 的 AI 协作环境。一开始想的挺好：统一入口、统一规则、统一模板，大家进来就能用，多省事。但实际跑了几天发现不对——就像给一群穿惯了自己鞋子的人，硬塞统一尺码的新鞋，难受。

有人习惯把资料按项目堆在根目录，有人喜欢分层放到十个不同文件夹；有人用 OpenClaw，有人用 Claude Code，有人还在玩 Hermes；有人写提示词喜欢平铺直叙，有人非要写得像武功秘籍。你要统一吧，大家觉得被束缚了手脚；不统一吧，又感觉乱哄哄的没章法。

那天晚上回家，我对着自己那个改了不下十版的 OpenClaw 工作空间——没错，就是你看到的这个 Alan-Workspace，突然想通了一件事：我们搞反了。

团队空间不应该是每个人每天打卡上班的主桌面，它更像公共图书馆。你需要查资料、看模板、学经验的时候去一趟，但平时自己的书桌还是要留在自己家里，怎么舒服怎么摆。

也正是从这个点开始，我慢慢把这段时间围绕 AI 工作空间、工具协作、知识沉淀、测试工程做的事情重新串了一遍。结果发现，真正需要调整的不是某一个脚本、某一份配置，而是整个空间的定位和分工。

一、为什么我开始怀疑「统一工作台」这条路

前半个月，我还在持续推进 teams 空间、治理脚本、权限模型、部署器、规则沉淀这些事情，想把它做成一个统一入口、统一规则、统一模板的 AI 工作台。这个方向本身没错，但真正跑起来后，问题也越来越明显：每个人的工作习惯、目录偏好、提示词风格、工具选择都不一样，强行统一，很容易把“规范”做成“束缚”。

所以到了下旬，思路开始明显收口：团队空间更适合做共享资料区、经验沉淀区、模板和规则入口；真正高频、长期、持续进化的主阵地，还是个人 workspace。

这个转向很关键。它意味着我不再执着于“做一个所有人都得在里面办公的大一统平台”，而是开始接受一个更现实、也更健康的结构：

团队空间负责共享、复用、对齐
个人空间负责沉淀、试验、迭代、长期陪跑

换句话说，团队空间更像基础设施，个人空间才是生产现场。

二、公共图书馆 vs 私人书房：两个空间的重新定位

先聊聊团队空间该做什么，不该做什么。

之前我们把它往「统一工作台」上靠，现在看是走偏了。团队空间更合适的位置是：共享资料区、规则沉淀区、经验入口处。 就像公司里那个带咖啡角的资料室——有人想写个测试报告不知道格式，可以去那里找模板；有人遇到了类似的线上问题，可以去那里查之前的复盘；新人进来想快速上手，可以去那里扫一遍规范。

但你不能要求所有人每天都坐在资料室里办公，把自己的笔记本、草稿纸、水杯都搬过去，那不对。每个人还是要有自己的「书房」——也就是长期维护的 OpenClaw 或 Hermes 工作空间。

这个「书房」的价值，不在于配置有多全，而在于它是跟着你一起生长的。今天加了个新脚本，明天补了个新笔记，后天改了个提示词，这些细碎的改动，累积起来就是你和 AI 之间独特的默契。这种东西，没法统一，也没必要统一。

我自己这个 Alan-Workspace，你别看现在好像有模有样，其实光目录结构就推翻重搭过四次，AGENTS.md 改得我都不好意思看 git 历史。但就是这个不断被推翻、不断被调整的过程，让它变成了真正「好用」的东西——因为每一次改动，都是在解决我真实遇到的痛点，而不是为了满足某个「规范」。

所以结论很简单：团队空间负责共享与沉淀，个人空间负责高频使用与持续进化。 谁也别抢谁的戏。

!image-20260430023627898.png

三、个人工作空间的正确打开方式：不是堆资料，是攒「上下文」

把空间定位想清楚之后，接下来的问题就变成了：个人空间到底该怎么建？

我这段时间想下来，有一条链路越来越清晰：

迭代/项目资料 → 结构化归档 → 图谱/索引生成 → 查询与分析 → 作为判断依据反哺工作

重点不是「我存了多少东西」，而是「我能不能快速把这些东西调出来，变成 AI 能理解的上下文」。

这一点，做测试的同学应该深有体会。比如你要评估一个新需求的影响范围，如果只是把需求文档扔给 AI，它大概率给你一些空泛的回答；但如果你能把：相关的历史 bug、之前的测试用例、那一块的代码结构，一起打包丢进去，出来的东西就完全不一样了。

所以后续要往个人空间里塞的数据，至少得有这几类：业务规则、测试用例、bug 数据、需求文档、还有——代码工程本体。

没错，就是 git clone 下来的完整代码。之前我也觉得，反正有 AI 了，看看文档、聊聊天差不多就行。但真做了几次才发现，没有代码在本地，很多理解只能停留在表面。就像你要了解一座城市，只看地图和照片是不够的，得亲自走一走街道，逛一逛菜市场，才能摸到真正的脉络。AI 也是一样的，给它看完整的代码库，它才能给你更靠谱的判断。

说到这里，插一句不太中听的：AI 出来以后，对测试人员来说，工作量其实是变多了，不是变少了——至少现阶段是这样。特别是那种长业务链的 ToB 产品，或者视觉系的 C 端产品，AI 能帮你写用例、帮你分析，但最后拍板的还是人，而且你还要多操一份心：「AI 是不是漏了什么边界情况？」这事儿，急不来。

四、OpenClaw / Hermes / Obsidian：真正要搭的不是工具堆，而是协作秩序

空间定位一旦变了，对工具协作的理解也会跟着变。

四月另一条很重的线，是继续把 OpenClaw、Hermes、Obsidian、LLM-Wiki 这些东西从“都能接上”推进到“知道谁该干什么”。

月初到月中，做了很多看起来偏配置、偏文档、偏治理的事情：

梳理 OpenClaw / Hermes 的分工边界
补齐共享工作区和协作口径
反复修 OpenClaw / Hermes / group policy / daily / weekly 的真实生效链路
把“现在到底怎么跑”沉淀成可复用说明，而不是只停留在聊天记录里

这些事表面上不性感，但价值很大。因为 AI 工具一多，真正先失控的往往不是模型，而是职责边界。谁是主入口，谁负责调度，谁负责本地执行，规则放哪里，记忆落哪里，失败后怎么回查——这些如果不先讲清楚，后面所有效率都会变成噪音。

所以这段时间其实不是简单“又折腾了一堆 AI 工具”，而是在给这些工具补秩序、补边界、补可维护性。也正因为如此，我才越来越确定：团队空间应该更像协作层和共享层，个人 workspace 才应该是每个人真正长期打磨的主阵地。

五、LLM-Wiki、周复盘、记忆链路：从“能记”走向“能复盘”

如果说前面解决的是“空间怎么分工、工具怎么协作”，那接下来要解决的，就是“内容怎么不丢”。

如果说二月在想“怎么把经验固化成 skill”，那四月就在继续往前推：怎么把经验、对话、文章、笔记、daily、memory、wiki，串成一条能持续复盘的链。

这个月围绕 LLM-Wiki 和复盘机制做了不少实打实的推进：

修 daily / ingest / weekly 的自动化链路
让周复盘不再只扫少量目录，而是纳入文章、笔记、记忆、wiki、对话线索
开始强调“自然日窗口”“真实来源”“可追溯证据”
不只生成复盘，还开始关注复盘的来源口径和验收方式

这件事的意义，不在于多了一篇周报，而在于：

复盘开始摆脱纯手工回忆，转向基于工作空间证据来还原这个月到底做了什么。

这很重要。因为 AI 时代最贵的，不只是产出，更是“别丢”。工具帮你干了很多事，如果最后没有被归档、没有被索引、没有被复盘，那本质上还是一次性消耗。

六、关于 RAG 的一点不一样的看法：先别把系统做得太重

聊到这里，就不得不提 RAG。

传统 RAG 的链路大家都熟：文档 → chunk 切片 → 向量化 → 向量库 → embedding 检索 → LLM 生成回复。这条路当然能走，但我现在越来越觉得，不一定每次都要搞得这么重。

我们现在更认可的思路是把它做轻：RAG → LLM-wiki。能用 grep 纯检索解决的，不一定先上向量库；能用 Markdown 规则文件驱动的，就先试试规则；把 MCP、skill、CLI 逐步串成统一调用链。

大概就是这么个感觉：即时通讯软件 → OpenClaw / Hermes → CLI → Codex / OpenCode / Claude Code 等工具能力。目标不是做一个「大一统平台」，而是让能力能够可打包、可复制、可迁移、可共享。

这也是为什么后面会自然出现「同事.skill」「名人.skill」这种形态——本质上，就是在沉淀一类可复用的 AI 能力模块。

七、测试这条线，开始找到更扎实的落点了

除了 AI 工作流本身，另一个让我觉得越来越有价值的变化，是测试这条线开始往“可沉淀、可分析、可辅助判断”的方向走。

下旬围绕测试知识图谱、影响分析、代码关系、历史 Bug 复用这块，思路明显更具体了：

不只是讲“AI 可以帮测试”
而是开始认真设计：资料怎么归档、图谱怎么建、影响范围怎么查、历史 Bug 怎么召回、代码 diff 怎么接进来

这背后的思路我很认同：

测试工作真正缺的，不是一个会说漂亮话的 AI，而是一套能把需求、Bug、用例、代码、变更关系串起来的证据系统。

也正因为如此，前面讲的“个人 workspace 要攒上下文”在这里就特别落地。因为测试不是缺一个会聊天的模型，而是缺一套能把上下文召回出来、辅助判断、还能留下证据链的工作方式。

八、单点能力也要有边界感：以测试报告自动化为例

聊完大的，再说个小的——就是那个禅道测试报告自动化的项目。

这个项目目标很简单：给一个执行 ID，直接产出并发送测试报告。现在已经跑通了：自动拉取执行、任务、Bug 数据；自动生成 HTML 报告；支持 Exchange 发邮件；LLM 写总结，写崩了还有规则模板兜底。

但有意思的是，这个项目最让我满意的地方，不是它能做什么，而是它清楚自己不能做什么。

维度	当前范围
数据源	禅道 API（执行、任务、缺陷）
报告格式	HTML
邮件通道	Exchange EWS（`exchangelib`）
总结能力	LLM + 规则回退
入口	`main.py`（唯一主入口）

包括测试报告自动化这条线，也开始更清楚它的边界：

目标就是“给一个执行 ID，自动产出并发送测试报告”
数据源、报告格式、邮件通道、总结方式、入口，都有明确范围
不再一上来追求大而全，而是先把一个可交付的小系统做扎实

这种「边界感」很重要。很多自动化项目做着做着就做重了——今天加个新数据源，明天加个新报告格式，后天再加个新功能，最后变成谁都维护不起的巨无霸。这个项目我们不打算这么干，后续就是把它做成 skill 和 html-tool，小巧、好用、能搬就行。

这种“知道自己先做什么、不做什么”的感觉，比一味铺功能更像真工程。

九、三个关键认知：这次调整到底让我想明白了什么

把上面这些东西连起来看，这段时间至少有三个认识越来越清晰。

第一，个人空间比统一空间更值得长期投入。 别总想着搞一套「所有人都能用的标准配置」，这不现实。更有价值的，是鼓励每个人维护自己的 workspace/vault——资料在里面，文档在里面，规则在里面，复盘也在里面。这个空间不是一次搭完就结束的，是要持续修、持续长、持续迭代的。我自己的都改了多少版了？数不清了，而且现在还不满意，还在调。

第二，skill 比一次性提示词更适合复用、传递和共享。 你费劲心思写了一条绝妙的提示词，用完就丢在聊天记录里太可惜了。应该沉淀成 skill 包、简单实用的 html-tool、或者 CLI 化的可调用能力。这些东西不会被某个平台、某个窗口、某次对话绑死，今天你能用，明天换个环境照样能用。

第三，AI 工作流的核心，不是模型，而是「如何把上下文组织起来」。 很多人一上来就纠结：「我用 GPT-4 还是 Claude 3.5？」其实真到了干活的时候，你会发现：模型差那一点，远不如「资料有没有进空间」「规则有没有写清楚」「技能是不是可以复用」「调用链是不是足够统一」「查询路径是不是足够短」来得重要。这也是为什么我们现在越来越重视 LLM-wiki、skill、CLI、workspace 这些基础层。

从这个角度看，这次调整表面上是在谈空间设计，实际上是在重排一整套 AI 工作方式的优先级。

十、内容产出没有停，反而更像一条稳定生产线了

这套思路一旦稳定下来，内容产出反而更顺了。

四月的内容产出量其实很猛。从工作区里看，01-Articles/ 下仅带 2026-04 日期的正式文章/稿件就有 207 篇（包含同主题多版本延展），20-Knowledge/ 下四月沉淀的知识素材有 532 份，本月 git 提交 69 次。

这组数字本身不代表质量，但至少说明一件事：这个月不是“想法很多但没落地”，而是真的持续在写、在改、在整理、在沉淀。

更重要的是，四月内容方向比之前更收敛了，主线越来越清楚，基本集中在几类：

OpenClaw / Hermes / 多 Agent 协作
LLM-Wiki / workspace / 个人知识工作流
Skills / CLI / 可复用能力封装
测试工程、影响分析、代码理解、知识图谱
AI 工具评测与方法论整理

也就是说，内容不再只是“看到什么写什么”，而是在围绕自己的真实工作系统持续扩写。这样写的好处是：文章、笔记、方案、脚本、工作实践，彼此是能互相喂养的。

十一、这个月最大的收获，不是新工具，而是判断更稳了

回头看，四月最明显的变化，其实是判断方式变了。

以前遇到新工具、新玩法，很容易先兴奋，先上手，先看看能不能接进来；这个月虽然还是在持续试，但明显更在意这些问题：

当前真实生效链路是什么？
这东西是长期资产，还是一次性爽点？
它能不能落到 skill / CLI / 文档 / 图谱 / workspace 里？
它是降低复杂度，还是只是换了个地方堆复杂度？

这是一种挺重要的转变：从“会不会用 AI”，慢慢走向“会不会管理 AI 带来的复杂性”。

而这件事，可能比单点工具能力更值钱。

十二、问题也很明显：版本分叉、稳定性、生活记录都还没彻底解决

当然，这次调整也不是没有代价和问题。

1）版本分叉还是重

同一主题经常会同时出现文章版、手册版、演讲版、PPT 版、笔记版。虽然这是产出的必经阶段，但维护成本也在变高，后面还得继续收敛主线文档。

2）自动化能跑，不等于长期稳定

这个月已经多次验证：最怕的不是脚本报错，而是“你以为它在跑，其实它早断了”。所以后面必须继续补验收、日志、失败提示和检查机制。

3）生活线素材不够厚

和一二月比，四月这次能直接拿来写进复盘的生活记录偏少。说明这段时间更多精力确实压在工作系统、文档沉淀和 AI 工具链上了。不是坏事，但也提醒自己：之后如果想让月复盘更完整，daily 和生活侧记录还是得补起来。

十三、后续该往哪走：一些学习路径和行动建议

如果把这次调整当成一个阶段性结论，那后面其实已经很清楚了。

值得立刻开始做的

持续完善你自己的 OpenClaw / Hermes 工作空间，别嫌麻烦，改就是了
试试把高频做法沉淀成 skill 包，哪怕一开始很粗糙
把 git clone 工程代码作为理解项目的常规步骤，别只看文档
围绕测试、产品、研发协作场景，继续积累可复用工具

可以持续关注的

openclaw、hermes agent、harness、openspec、superpowers、opencode、LLM-wiki 这些工具的进展
多 agent 协作的玩法，比如拉三个 bot 进群，调度→开发→测试，互相 @ 互相协作

如果你想搞点项目练手

开发一个小程序
开发一个 to-B 平台
开发一个官方网站

我自己 5 月想继续做的事

继续收敛个人 workspace 结构，把高频资料、脚本、规则真正养熟
把可复用能力继续沉淀成 skill / CLI / 模板，而不是散落在对话里
推进测试知识图谱和影响分析，让它真正服务实际评审与测试设计
给自动化补验收和日志，减少“以为在跑”的幻觉
补厚 daily / 生活记录，让复盘不只剩下工作系统这一条线

十四、结尾：这次战略调整，真正调整的不是目录，是工作方式

如果一定要给这一轮调整挑一个关键词，我会选：收口。

不是停下折腾，而是开始把折腾出来的东西摆回正确的位置：

团队空间，不再幻想成所有人的主桌面
个人 workspace，正式成为长期主阵地
LLM-Wiki、memory、daily、weekly，不再各跑各的，而是开始尝试连成闭环
测试、知识图谱、代码理解，不再停留在概念层，而是开始找具体落点

四月并没有给我一个“大功告成”的结果，但它做了一件更重要的事：把接下来这套 AI 工作方式，往更稳、更长、更像自己的方向，推了一大步。

从统一工作台到个人主阵地，表面上看只是空间设计的调整；但往深了说，它其实是在提醒我：AI 时代真正值得长期投入的，不是追一个万能平台，而是慢慢养出一套属于自己的、可复用、可迭代、可沉淀的工作系统。