当AI成为日常工作的协作者，我们却陷入了荒谬的「上下文搬运」困境。本文作者通过重构会员积分系统的实战案例，揭示了传统工作流中AI与人类协作的根本矛盾，并最终构建出一套「Obsidian+飞书」双轨系统与19个AI角色的虚拟团队模型。这不仅是一次工具迭代，更是一场关于如何让AI真正「接手工作」的思维革命。

最近，我在负责重构产品的会员积分系统。

事情很典型，但也极其繁琐：算成本、看竞品、盘逻辑。

为了最高效地推进，我开了三个 Claude 窗口同时在聊：

第一个窗口，我在给它喂财务数据，死磕 ROI 和积分核销的成本模型；

第二个窗口，我在丢截图，让它拆解竞品门的权益差异；

第三个窗口，我在和它推演边缘场景：退款怎么退积分？多场景业务积分怎么抵扣？

聊了大概 40 分钟，所有的卡点都理顺了，思路无比清晰。

然后，我打开了一个新的 AI 写作窗口，准备让它帮我起草 PRD 的主体框架。

我敲下回车：“逻辑理清了，帮我输出一份会员积分系统的 PRD 框架。”

它立刻回复了我一句：

“好的！为了更好地输出，请问我们的积分兑换比例是多少？主要参考了哪些竞品的策略？”

我当时愣了一下。不是因为不会答，而是因为——我刚刚在另外三个窗口里，已经把这些问题盘得清清楚楚了。

接下来发生的事情，每个产品经理应该都很熟：

我开始点开第一个窗口，往上翻聊天记录，找到成本比例，复制，切回来，粘贴；

再点开第二个窗口，找到竞品结论，复制，切回来，粘贴；再用大白话把第三个窗口里的边缘场景重新解释一遍。

那一刻我突然感到一阵烦躁。不是因为累，而是觉得这件事极其荒谬：

我根本不是在用 AI，我是在给 AI 当“上下文搬运工”。

一、我一直在找更好的工具，但问题其实出在“工作现场”

我开始注意自己的工作过程，发现“上下文断裂”是常态。

有时候是在一个窗口讨论需求，另一个窗口讨论技术，真正落地时，没有任何地方能接住这一整段思考；

有时候是认真做过的竞品分析，两周后别人问起，你翻遍文档只找到一句干瘪的结论，当时的权衡过程全丢了。

我一开始以为是工具问题。作为 2 年的重度用户，我经历了大多数产品经理都会走的路：

第一阶段：用 Notion 做“中枢”

想法很简单，把所有东西沉进去。

Notion 极具结构美感，很适合存东西。

但很快我发现，它接不住“正在发生的过程”。你还是要复制、解释、补上下文。

第二阶段：用飞书做“协作”

因为中文阅读体验和多维表格，我把业务搬到了飞书。

飞书的组织协作能力极强，但它的本质是一个“展示结果的地方”，而不是 AI 的“工作现场”。

你写完，放进去，别人再看。整个过程是传递结果，而不是共享过程。

有一天我突然意识到，我应该换个问题：AI 最容易在哪工作？

如果我是 Claude，我希望：不需要别人帮我转述，不需要格式转换，不需要通过 API。

说白了就是，我希望直接看到原始文件。

于是，我把目光投向了 Obsidian。

不是因为它多强，而是因为它就是一堆本地 Markdown 文件。Claude 等本地 AI 工具可以直接“读到我正在做的事情”——不是复制后的，不是整理后的，是原始上下文。

二、不是二选一：我重构了“Obsidian + 飞书”的双轨系统

这里必须澄清一点：我并没有因此抛弃飞书。

真正成熟的工作流，从来不是单工具包打天下，而是工具的分层协作。当我理清了人与 AI 的边界后，我搭出了一套“双轨制”协作系统：

• Obsidian 负责“对内”与“底层”：它是我的个人思考中枢和 AI 协作现场。 所有复杂的预研、代码生成、逻辑拆解，都在本地 Markdown 文件夹里由我和 AI 共同完成。
• 飞书负责“对外”与“共识”：它是团队协作中枢。 当 AI 在 Obsidian 里把一团乱麻理清，并输出结构化的 Markdown 方案后，我一键同步到飞书云文档，用于团队评审、画图对齐、@相关人跟进。

过去，团队是在对齐零散的信息；现在，我用 AI 把信息结构化后，团队是在飞书里直接共享完整的上下文。

三、给 AI 换操作系统的两个核心动作

让这套系统运转起来，我只做了两件微小但致命的事。

动作 1：把“对话结论”变成“最小可行文档（MVD）”

以前做业务决策，我问完 AI 得到结论就结束了。两天后要写逻辑，我和 AI 都忘了为什么这么选，只能重来。现在，我强制自己写一份最小文档：

动作 2：把“聊天记录”变成“状态驱动的 Checklist”

以前 AI 喜欢一次问一堆问题（登录怎么做、数据库怎么选），我靠脑子记，最后总会漏。现在，我让 AI 把问题直接写进项目文件里：

问题从“对话里的信息”，变成了“项目里的状态”。我不用翻聊天记录，AI 也不用重复问，我们共享同一份进度。

四、终极形态：用 19 个角色系统，一个人活成一支团队

当这套本地文件协作机制跑通后，我做了一件更激进的事：我把 Claude 拆开了。

既然 AI 可以读取文件夹，我为什么不给不同的文件夹赋予不同的“岗位职责”？

我参考了优秀开源项目的源码逻辑，在 Obsidian 里构建了一个包含 19 个角色的虚拟团队系统。

实战案例：独立跑通全链路

在这个项目里，我不再是单纯的“写文档的人”，我是“项目经理”：

1. 我唤醒“产品经理”角色（限制它只读取01文件夹），让它输出完整的 PRD。
2. 我唤醒“架构师”角色（限制它读取 PRD），让它输出技术栈和数据库设计。
3. 我唤醒“前端”和“后端”角色，让它们根据架构文档直接写代码。
4. 每个角色都有明确的边界、职责和交接文档（Checklist）。

这套系统的可伸缩性极强。从 1 个人的独立推进，到拆分成 100 个细分任务节点的复杂项目，本质上只是 Markdown 文件和状态流转的增加。

五、写在最后

这篇文章看起来在讲工具，但真正改变我的，是一件更底层的事：

我不再问“怎么用 AI”，而是开始想“怎么让 AI 接手这件事”。

工具可以换，模型会更强。但如果你的工作流还是靠脑子记、靠手动复制、靠反复向 AI 解释背景，那 AI 再强，也只是帮你“更快一点”，而不是帮你“接手工作”。

我不是在换工具，我是在给 AI 换操作系统。