飞书 AI 协作工作台：让调研、写作与验收有序接力

本案例根据 Niall 的《我把飞书做成了我的 AI 协作工作台》整理，呈现原文中的实践与边界。文末检查清单是基于该实践整理的复用建议，不是新增的项目成果。

要解决什么问题

手上有多个 AI 助手，不代表它们自然就会协作。原文作者同时使用 Codex、Qoder CN、Claude Code 和 workbuddy，最消耗精力的事情却是搬运信息：把调研结果粘给写作者，把结构问题带回调研窗口，再把不同版本整理进文档。

问题不只是窗口多，而是任务状态、已确认材料与最终结果分散在不同地方。人既是发起者，又成了上下文中转站。

这次实践把飞书作为共同工作台：讨论在同一个地方发起，材料可以留在文档里，交接有明确负责人，最终交付仍有人验收。

这不是把四个角色同时叫出来各写一篇。在作者的写作流程里，任务沿一条链串行推进：上一环节产出通过验收后，再交给下一位。

作者先为各个 Agent 配置 CLI 与账号授权，再接入协作环境。工作台能做什么，取决于实际接通的工具和授权范围，不能只写一句角色介绍就当作连接完成。

原文强调按需授权：读文档、操作表格、发消息等能力，用到哪类再配置哪类。这里复盘的是作者的连接思路，不把原文中的产品名称、版本和接入列表当作长期有效的安装指南。

作者把积累的 Skill 作为几位 Agent 可以共用的方法库，同时保留各自的独立 Skill。这样换一个执行者时，不需要重新介绍整套做事方式。

但共享 Skill 不等于共享每次任务的上下文。一个新运行未必能看到完整历史，也未必能访问另一个运行的临时文件，所以交接消息必须带上已验收的必要材料。

原文中的派单不仅写“请继续”，还包括本轮目标、已验收输入、必须交付的内容、禁止事项与验收标准。

例如，结构环节需要的是可直接使用的事实包，而不是“调研已经做完了”。写作环节需要的是最新完整提纲和材料，而不是一串无法打开的沙箱路径。

返回时也不能只有“完成”二字：要交出实际成果，并说明尚未解决的问题。负责人读过成果后，再决定通过、返工或补充材料。

任务完成后，调研、复盘和方法写进云文档或知识库。聊天适合推进事情，文档适合保存下一次仍能找到、仍能使用的结果。

作者也把 Agent 以机器人形式放进群聊，用群作为日常发起入口。入口的统一解决的是协作，不要求所有执行步骤都发生在群里。

原文本身就是这条协作链的交付物：在飞书发起文章任务，经过分工、结构整理、核验、写作和汇总验收，形成最终文章。

可以确认的是，作者已经把写作协作规则用于实际任务，并将过程留在同一条任务记录里。原文没有提供可对照的工时、成本或质量评分，因此不把这次实践包装成“效率提升多少倍”的结论。