上周日晚上，我给大辰教育「从0到1打造24小时AI助理」训练营的学员们上了最后一节课。

这套训练营课程的本意，是教给学员们如何用好OpenClaw、学会把龙虾养起来，但我更希望每个同学掌握的，其实不是工具本身，而是一套搭建个人工作系统的行为模式。

现如今人们学AI，注意力大多停留在“追逐最好用的工具”上。今天是龙虾，明天是爱马仕，后天可能又迁移到Claud Code、Codex上。

现在AI的发展太快了，几乎每天都有新东西出来。只要你关注这个领域，就很容易产生一种感觉：今天不学，明天就落后了。

我也很担心这次的学员过于关注技术本身，做出来很多看起来很炫，但脱离实际的尝试。

但这最后一次的「学员汇报」，反而给我上了一课。我发现大家把AI融入工作流的意识，比我想象的要强烈得多。

说明我一直想在课程中传递的理念——把AI放进自己的长期工作流里，切实被学员们接收到了。

OpenClaw 只是个入口。真正有价值的，是怎么拆任务，怎么定边界，怎么写 SOP ，怎么沉淀你的知识库，最终把一次性的 AI 对话，变成可以持续复用、持续优化的效率系统。

这个抽象的方法论，但通过学员的分享，刚好把它具象化了。

正好借这个机会，我也把这几个案例分享给大家。

这三个案例都不算大：

• 一个用来整理学习笔记和做抖音短视频。

• 一个用来辅助写 PRD 和做产品原型。

• 一个用来处理制造业项目排期和方案跟踪表。

场景很具体，也有点琐碎，不过正因为琐碎，才更适合 AI 进入真实工作。下面我一个一个来聊聊。

案例一：整理学习笔记和做短视频

第一位同学的案例，我觉得挺典型的。

她之前在国外工作学习生活了六年，去年回国，今年七月准备去深圳入职一家芯片公司。中间这段时间，她给自己安排了很多学习内容，职业规划课程、AI课程、英语、法语、黄帝内经、心理学，内容很多，也很杂。

她最早记笔记的流程很繁琐：先对课程录音，再把录音转成文字，再复制到 DeepSeek 或其他 AI 应用里，让它生成笔记。

最后还要把笔记复制到飞书文档里，再命名、归档、放到对应的位置。

如果你做过类似的事就知道，这套流程每一步都不难，但每一步都要动手。动手次数一多，学习这件事本身就会被消耗掉很多耐心。

后来她给自己养了个 AI 小助手，叫「乔贝」。

现在她的流程变成了：把录音交给它，它会自动转文本、自动生成学习笔记，再自动放进飞书知识库对应的文件内。

这个变化没有解决所有学习问题，也没有让她一下子就拥有一套完美的知识管理系统，但它却用AI接管了一个高频流程。

这就已经足够有价值了。

后来，她还尝试把 AI 用到它的抖音内容创作里。

这个案例也很有意思，她让 AI 根据外语学习素材生成脚本素材，再把素材粘贴进自己提前做好的剪映模板里。因为模板已经固定，她只需要人工对齐文字，几分钟就能产出一条视频。

她自己也说，现在大概四五分钟就可以产出一个视频。

这里有一个特别值得讲的点，在自媒体运营上，她没有强行追求全自动，一个是账号有风控风险，一个是 AI 生成的内容比较干，缺少灵性，流量也不理想。

所以她也做了取舍。

这个判断很重要，很多人学 AI 时，总觉得自动化程度越高越好。最好选题、写稿、配图、发布、复盘，全都交给它。

但真实工作里，越靠近平台规则、账号安全、内容审美和个人表达的地方，越需要人来保留判断。

半自动，有时候反而是最合理的状态。

AI 负责把重复的、标准化的部分先处理掉，人负责最后的判断和表达，这比盲目追求全自动更靠谱。

在次基础上，她还做了一件事，就是把重复工作沉淀成skill。但这个过程的迭代经验，更值得拿出来讲讲。

比如她会发现自己的视频素材提取的 skill 里，缺少提炼重点词汇的功能，就和龙虾对话，让它把这个能力补进去。

这就是正确沉淀Skill的方式：先拆细指令、再及时纠正。每次纠正之后，让 AI 记住这次修改点，下次不要再犯同样的问题。

最后再让 AI 按照 skill 自查几遍。跑一次不稳定，就跑三次。确认输出结果稳定，再把它变成长期可用的skill。

这件事和企业做知识库、做智能体，其实是同一个逻辑。

不要指望系统第一天就直接完全替代人工，先把人的经验写清楚，再让 AI 在清楚的规则里工作。

案例二：辅助写 PRD 和做产品原型

第二个分享的同学目前是在做产品经理，但他的背景很特别，之前是土木工程专业，后来转到产品开发。所在公司也处在数字化、智能化转型过程中，软件团队规模很小，只有他和一位后端工程师。

但领导希望他们快速能做出产品 MVP。

这类场景我可太熟悉了……人少、活多、节奏快，还要尽快拿出可以让老板看到希望的东西。

而这位同学给自己的龙虾定位很明确：帮他写 PRD 文档，画产品原型，做文档管理。

他演示的是一个前端学习小程序的 PRD 生成流程。

他会先告诉 AI，自己要做什么产品，目标用户是谁，需要哪些功能，要符合什么 UI 设计规范，文档应该放到飞书知识库的哪里。

这套提示词已经比很多人清楚得多了。

我当时给他的建议是，可以再往前走一步：写 PRD 这件事，很多时候不适合一次性丢给 AI 生成。

更好的方式，是让 AI 先和你反复沟通，把你的想法补全。

比如，你想做一个基于费曼学习法的前端知识小程序，这个方向听起来没问题。

但继续往下问，还会有很多细节：

• 目标用户是完全零基础，还是已经学过一点前端？

• 学习路径按知识点组织，还是按任务组织？

• 费曼学习法在产品里到底怎么体现？

• 用户讲不清楚时，系统怎么反馈？

• 技术架构是否符合真实部署环境？

这些问题如果不提前想清楚，AI 一次性生成的 PRD 看起来完整，后面修改成本反而会很高。

所以我更建议他把 AI 当成一个可以参与前期讨论的产品搭档。

先让 AI 扮演专业产品经理，不断追问你，你像老板一样，把想法讲出来。

AI 负责补问题、补结构、补可能遗漏的维度。

等你们把这个想法聊透，再让它生成 PRD。

这样出来的文档，才更接近真实工作需要。

这里也有一个思路供大家参考：

过去我讲产品经理用 AI，大多还是单点提效。比如让AI写用户访谈大纲、分析调研问卷、写 PRD、生成竞品分析报告等等。

这些当然有用，但它们仍然是一个个点。

OpenClaw 这类工具出现之后，我们完全可以尝试把这些单点串起来，变成一条工作流。

从需求讨论，到文档生成，到知识归档，到后续修改，再到原型和 Demo。

这一条线如果能跑顺，产品经理的角色会发生很大变化。

我在课上提到一个词，product builder。

未来一部分产品经理，可能会从设计者变成建造者。他们不只停留在写需求、画原型、提想法上，还可以直接借助 AI 编程工具，把一个 Demo 搓出来。

这个 Demo 可能还不能直接交付客户，但它能让老板、客户、团队更快看到方向。

在资源有限的团队里，这件事很有价值。

当然，这里也要有边界。

AI 生成的东西不能直接替代正式研发交付。但它可以帮助你更快验证想法，让团队少在空中讨论，多看真实结果。

案例三：项目管理助手

第三个案例，是我整节课里最想拿出来讲的案例，因为它非常接近企业 AI 落地的真实状态。

分享第三个案例的同学，在一家自动化设备公司，主要做项目管理。公司出于人均效率考虑，没有很多专职的项目经理，所以大量项目信息都压在她这个岗位上。

一年几百台设备，几十条大线。技术中心光机械设计师就有 60 多名。

信息来源也很杂，邮件、内部系统、聊天记录、技术经理口头沟通，都有。

她每天要处理各种项目排期、进度更新、方案跟踪的事项，还要经常给领导汇报。

这才是真实企业里的 AI 场景。

还有个很现实的限制：公司内网和外网隔离，部分成本和财务数据属于敏感信息，不能拿到外网处理。

她现在只能半自动处理，在内外网之间切换，把适合处理的信息交给 AI，不适合的继续留在内网。

这也是我觉得这个案例特别好的地方。

她没有把 AI 用成一个炫技工具，而是一直在判断边界：哪些数据可以给 AI、哪些环节能自动化，哪些环节必须由人确认。

在企业里，这种判断，比会写几个提示词重要得多。

她目前做了两个场景。

第一个是新项目排期。

新项目来了之后，技术经理有时会指定设计师，有时不会指定。她需要结合 60 多名机械设计师的级别、能力、擅长行业、在手项目、下图时间、项目周期、设备难度，快速给出排期。

这件事过去高度依赖人的经验。

她做的第一步，是先和 AI 一起定义排期规则。她还为了写了上千字的一份规则文档，包括：项目怎么命名、工序怎么识别、不同等级设计师适合什么工序、不同难度工序需要多少周期等等。

还规定了边界范围的判断原则，比如整线设备数量超过 15 台时，出图时间如何安排。比如设备少于 5 台时，为什么下图时间不能相差太多等等。

这些规则听起来很细、很琐碎。但这恰恰是 AI 真正能干活的前提。

她把这些经验规则写进文档，再让 AI 基于文档形成排期 skill。

遇到规则冲突时，AI 会反过来问她，然后她再修正。

这其实就是一套非常完善的工程化人机协作流程。

第二个场景是方案跟踪表更新。

她原来的跟踪表有 100 多个字段，后来压缩成 66 个核心字段。每天、每周都要不断更新，信息来自邮件、系统、截图和聊天记录。

她的做法是：

把整个大表交给龙虾，让它识别字段、字段说明、信息来源和更新方式。

然后她再基于龙虾输出的内容做人工调整，和它讲清楚，哪些字段可以由 AI 维护、哪些字段需要和技术经理当面确认、哪些字段从邮件标题里提取、哪些字段从截图里识别。

规则定义清楚后，之后她就只需要把邮件内容或截图丢给龙虾，龙虾就能按照约定规则输出字段，最后她再复制到原表里。

这个过程仍然是半自动，但它已经把最繁琐的查找、提取、整理环节交给 AI 处理了。

我当时听完她的分享，给了一个判断：未来每一个项目，都值得为AI撰写一份工程化的操作手册。

很多企业一开始做AI智能体，总喜欢先看模型能力，看平台功能，看演示效果。

但到了真实业务里，真正决定效果的，经常就是这些看起来冗长，但信息却足够完善的操作手册。

你要写清楚规则怎么定义、字段怎么解释、输入来自哪里、输出给谁看、遇到冲突怎么处理。

这些事情不先讲清楚，AI 再强也很难稳定干活。

那天我还顺手讲了一个我用龙虾管理飞书知识库的例子。

很多人让龙虾操作飞书知识库时，会遇到一个问题，龙虾不知道文档应该放在哪里。

原因很简单：飞书知识库的结构和普通文件夹不一样，它更像文档套文档。对人来说，你看一下左侧目录，大概知道结构。对 AI 来说，它需要一个明确的说明。

所以我现在自己做飞书知识库管理时，会先给每个知识库单独建一个「使用指南」。

这个使用指南是写给 AI 看的。

它会说明这个知识库是干什么的，下面有哪些节点，每个节点放什么内容，常见使用场景是什么，新增文档时应该先读哪里，再写到哪里，写完之后要不要更新索引。

这样处理后，AI 再去做增删改查，准确率会高很多。

这样做带来的变化是：

过去我们开发系统、做文档管理，主要是给人看。但现在很多系统，也是要开发给 AI 操作的。而既然 AI 要操作你的系统，就要有面向 AI 的说明、索引、规则和维护机制。

我在讲企业知识库建设时也说过，找一个系统，把文档传进去，只能算开始。真正麻烦的地方，是把知识源、目录、标签、准入标准、更新机制、权限边界、使用说明都整理清楚。

个人用 AI 也是一样。

你想让一个智能体长期帮你干活，也要给它建立可理解的工作环境。它要知道你是谁、它自己是谁，哪些事它能做、哪些事不能做。以及遇到问题什么时候要和你确认，什么时候可以继续执行。

这就是我在课程里讲的：从会用，到会管。

会用 AI，已经不难了。

会管 AI，才是下一阶段的分水岭。

不过我们到也不用追求一次就能完全管好你的 AI 搭子，可以尝试先挑一个场景，走完从识别、沉淀到治理的小闭环。哪怕很简单，只要这个闭环跑顺了，再扩展第二个场景。

这比一上来就设计一个大而全的自动化系统更可靠。

因为真实工作流里的问题，只有跑起来才会暴露：

• 你会发现小红书自动化有风控风险。

• 你会发现飞书知识库不会按预期新建位置。

• 你也会发现内外网隔离让很多自动化只能半自动。

也正是这些问题，能让 AI 从玩具进入工作。

这套训练营完整讲下来，我会发现，AI 提效最重要的能力，就是学会把自己的工作拆开，思考哪些环节高频重复、哪些环节有明确规则、哪些环节依赖人的判断、哪些结果必须人工二次确认，以及哪些经验值得沉淀成 skill。

这些问题想清楚，工具反而没有那么重要。

今天是 OpenClaw，明天可能是别的 Agent。

今天用飞书，明天也可能换成企业微信、钉钉或其他系统。

工具会变，但拆任务、定边界、写 SOP、管理知识库、控制风险、持续复盘这些能力，会一直有用。

我认为未来真正产生岗位溢价的地方，是谁能把 AI 放到自己的业务场景和工作流里，让它长期稳定地产生价值。

• 对个人来说，这会变成你的效率系统。

• 对团队来说，这会变成团队的协作系统。

• 对企业来说，这会变成 AI 真正落地的基础设施。

你不用急着追下一个工具。先回到自己的工作里，找一个真实、高频、可控的小场景。

把它拆开，把规则写清楚、把流程跑一遍，让 AI 做一小段，发现问题，再修。

修完之后，沉淀成 skill，再让它进入下一次工作。

这就是一个人真正开始拥有 AI 助手的过程。

也是 AI 从热闹的工具，进入长期工作流的过程。