夜雨聆风写在前面的话：
这不是一篇唱衰 OpenClaw 的文章。
恰恰相反，我认为，OpenClaw 可能是这一波智能体产品化里最重要的拐点之一。
它第一次把很多人嘴里的“Agent”，从概念、Demo 和少数人的高配玩法，真正变成了可以被更多人直接上手的产品。
但真正把它放进业务之后，我越来越觉得：
对于 OPC（One-Person Company）和小团队来说，问题可能不是“有没有一个更聪明的助手”，而是“有没有一套能承接它的主工作流”。
一、我们确实认真用过 OpenClaw
从过年前还叫Clawdbot，到后来被广为人知的OpenClaw，这段时间里，我们前后搭过 3 套，飞书、Slack、微信，都接过。它们不是没用。只是直到现在，我们还是把它当成一个个人助手来用。
它在我们这里最常用的场景，主要是这几类：
每日信息摘要和筛选 业务相关内容资产的沉淀 基于知识库的轻量问答 一些偏个人效率的辅助型任务
如果只看这些场景，OpenClaw 已经是一个非常好的产品了。
它降低了很多人第一次真正“用智能体干活”的门槛，也让行业从“聊天机器人”往“个人助手”又走近了一步。
但问题也正是在这里开始出现。
我们认真搭了，也认真用了，但最后没有把它放到主工作流的核心位置。
二、这不是能力问题，而是位置问题
我后来越来越觉得，讨论 OpenClaw，有一个很容易被混淆的问题：
很多人讨论的是“它强不强”，但真正更重要的问题其实是“它应该放在哪一层”。
在我的理解里，至少可以把 AI 工作分成三层：
第一层，个人助手层：帮一个人更快地拿信息、生成内容、处理轻任务 第二层，主工作流层：承接正式项目、长期任务、多人协同、文档更新和版本演进 第三层，组织基建层：决定 AI 的能力能不能被持续复用，而不是每次从聊天记录里重新开始
OpenClaw 对第一层非常有价值。
但对我们来说，它暂时还不适合被放到第二层和第三层的中心。
这不是因为它不强，也不是因为它没用。
而是因为：个人助手和主工作流，本来就不是一回事。
但我现在会补一个更重要的判断：
这并不意味着 OpenClaw 在第二层、第三层没有价值。恰恰相反，一旦组织底层的主工作流先搭好，OpenClaw 这类产品的记忆系统、可成长性，反而更有机会被真正用起来。
因为那时候，它承接的就不只是某个人零散的聊天习惯，而是一个有正式文档层、有版本链路、有协作边界的组织系统。
记忆不再只是“记住我上次聊了什么”，而会开始变成“记住这个组织是怎么做事的”；成长也不再只是把一个助手调得更顺手，而是让它逐步适配整个团队的知识结构和工作方式。
为了避免把“治理”说得太抽象，我后来会用一个更简单的区分方式去看它们：
三、我们真正卡住的，是“不敢放权”
如果一定要说，这段时间我们使用 OpenClaw 时最核心的问题是什么，我的答案很简单：
不是不会用，而是不敢放权。
我们也确实想过，把更多真实业务交给它。
但一旦任务开始碰到正式业务，犹豫就会出现：
这份输出会不会进入正式文档？ 如果它改错了，谁来发现？ 它这次基于的上下文，下次还能不能复用？ 多人都在用的时候，版本怎么管理？ 一次效果不错，能不能变成稳定流程？
这些问题，只要有两个回答不上来，人就会本能地把权力收回来。
对于小团队来说，这不是一个抽象风险，而是非常具体的日常代价。
比如，一段 AI 生成的 PRD 修改，看起来只是帮你补了几段内容，但如果没人说清这版是草稿、那版是已确认版本，后面再往下衍生 SPEC、评审结论和开发任务时，整个链路就可能从一开始就建立在错误版本上。
再比如，一段口径还没统一的对外文案，如果只是被顺手发进群、发到草稿区，最后又被人误当成正式版继续流转，问题也不是“它写得好不好”，而是没人知道哪一版才算数。
而一旦权力收回来，OpenClaw 能承接的事情就会越来越往外围走：
摘要 整理 问答 辅助查询 轻量执行
这些事情当然有价值。
但它也意味着，它更像一个前台助手，而不是一个真正承接团队主工作的系统。
所以，回头看我们这段时间的体验，我现在更愿意这样描述它：
OpenClaw 在我们这里不是不好用，而是“好用，但还不足以让我们把主工作流放上去”。
四、回头看，我们的问题可能不只是助手本身
这也是我这段时间最大的一个阶段性判断。
一开始我以为，这个问题可能来自模型能力、skill 数量、调用链路，或者提示词工程。
但后来我越来越觉得，问题可能不只是助手本身，而是主工作流的治理层还没有被解决。
这里的“治理”，听起来很像大公司的词，但其实小团队反而更需要。
因为大公司可以用人和流程兜底，个人可以用自己的脑子兜底，只有 OPC 和小团队最尴尬：
没有大公司的治理层 又承受不起主文档混乱、上下文丢失、版本失控的代价
换句话说，小团队看起来轻，实际上更没有犯错预算。
这也是为什么我后来会觉得：
个人助手的默认逻辑，通常是“先好用，再补约束”；但主工作流的默认逻辑，应该反过来，是“先可治理，再逐步放权”。
这和工具是不是先进，没有直接矛盾。
只是它们解决的，本来就不是同一个问题。
五、所以我们开始换一种搭法
我们并没有放弃 OpenClaw。
相反，我们现在的做法更像是：把它重新放回它最适合的位置。
它继续做个人助手。
而主工作流，我们开始放在一套更克制、也更可治理的架构上。
这套东西如果只看工具名，其实并不性感：
用 Obsidian 做本地知识库 用 GitHub 做版本、同步和协同 用终端里的大模型对话做高密度生成、改写和执行 用 skills 把高频任务固化成可复用流程 用分层文档结构，把正式文档、内容资产、日报、线索、参考资料分开管理
但我越来越相信，真正重要的不是“工具酷不酷”，而是：
它能不能让 AI 从一个会聊天的助手，变成你工作系统里的一个稳定节点。
至少在我们现在这套系统里，商业计划、项目规划、PRD、SPEC、评审、营销框架、社媒运营规范，会进入正式文档层；日报、产品调研、公司分析、公众号草稿、已发布内容，则进入各自对应的沉淀层。
也就是说，很多内容不再停留在聊天框里，而是开始进入一个可版本化、可关联、可持续更新的系统里。
举个更具体的例子。
如果现在我们要写一个新的 PRD，它不会直接停在一次对话里。更常见的流转方式是：
先在终端里把需求讨论清楚，形成第一版草稿 草稿进入本地知识库，成为一个明确位置的文档对象 GitHub 负责记录版本变化，而不是靠人回忆“哪版是最新的” 评审意见继续挂到这条链路上，后面再往下衍生 SPEC、设计和执行文档
这样做的意义，不是流程更复杂，而是尽量避免“前面改了一处，后面所有人都还在看旧版本”。
我们把知识库从飞书迁到 Obsidian，也是基于同样的考虑。飞书对人很友好，但 Obsidian 在很多时候对 AI 更友好。而文档存储这件事，纯线上不行，纯本地也不行。
我们现在更倾向于的是一条中间路线：
本地知识库沉淀 + 云端版本同步 + 本地拉取协同 + 终端生成执行。
至少到目前为止，这条路在我们这里越来越顺。也正因为这套底座开始变清楚了，我现在对 OpenClaw 后面的价值，反而比前一阵子更乐观一些。
以前我们对它的犹豫，更多是因为它前面缺了一层可治理的主工作流；但如果这层先搭起来，OpenClaw 的很多能力就不该只停留在个人助手层，只是当前我们这么用。
它的记忆、上下文延续、基于长期使用不断长出来的“组织感”，其实都更适合被接进整个组织体系里，而不是只服务某一个人的聊天窗口。
六、AI 真正进入业务，不是靠“会做事”，而是靠“能被管理”
今天很多团队都在卷 skill，卷工具，卷自动化，卷多智能体。这件事本身没问题。但我自己的一个很强烈的感受是：
很多时候，我们像是花了很高的 token 成本，请了一个非常聪明的博士生，给他配了一堆工具，也教了他很多业务知识和做人的道理，最后却只敢让他做摘要、整理、排期这类外围工作。
这不是因为大家保守。而是因为，一旦你想让 AI 进入真正的业务主链路，你就会发现，真正缺的不是“它能不能做”，而是：
它做完之后落在哪里 谁来接手 怎么复盘 怎么迭代 怎么避免一处改动、处处失控
所以对我来说，AI 时代真正重要的一步，可能不是继续追一个更强的助手，而是先搭一套能承接它的系统。
这其实也在反过来影响我对 GenGrowth 的理解。
我现在越来越不把它理解成“再做一个更强的 AI 助手”，而更倾向于把它理解成：怎么把 AI 的能力真正接进业务系统，让它能被管理、被追踪、被复用。
个人助手解决的是“我今天能不能更省力”。
主工作流解决的是“这个团队下个月还能不能稳定地产出”。
这两件事，看上去都叫“AI 工作流”，但底层逻辑其实差得很远。
七、对 OPC 和小团队来说，主工作流比个人助手更值得先搭
如果你只是个人使用，那么一个足够聪明、足够顺手的助手，已经很有价值。
但如果你正在带一个很小的团队，或者你本身就是一个正在往小团队演化的 OPC，你迟早会碰到同一个问题：真正决定你上限的，不是你能不能调出一个厉害的 Agent，而是你有没有一套让它持续接入业务的工作系统。
这套系统至少要回答几个问题：
AI 怎么理解你的真实业务上下文？ 它的输出怎么进入正式系统，而不是散落在聊天记录里？ 多人协同时，怎么避免互相污染？ 在还不敢完全放权的情况下，怎么逐步扩大它的作用范围？
这些问题不性感，也不热闹。但我现在反而越来越相信，它们才是 OPC 和小团队真正的基建问题。
如果你问我今天对 OpenClaw 的态度是什么，我会给一个很明确的回答：我高度认可它，也会继续用它。
但至少在 GenGrowth 目前这个阶段，它更适合先放在“个人助手”的位置，而不是直接承担“主工作流”的位置。
这并不是一个偏保守的结论，反而我越来越觉得，只要组织底层的主工作流先搭清楚，OpenClaw 后面真正值得期待的，恰恰不是“还能不能再帮我多做几个小任务”，而是它能不能把记忆系统、可成长性和长期上下文，真正接进整个组织的工作体系里。
我们现在更想先搭清楚的，不是一个更会干活的 AI，而是一套能把 AI 能力稳定接进业务的系统。这套系统我们还远远没有打磨完。但它至少让我们开始从“怎么让 AI 更聪明”，慢慢转向“怎么让 AI 真正变成生产力”。
下一篇，我会把我们现在这套更适合 OPC / 小团队的工作流架构，拆开来讲。
如果你也在做类似的尝试，或者你也有过那种“它很好用，但就是不敢把主工作流放上去”的感觉，也许下一篇会更有参考价值。
写于 2026 年 3 月
