下一次遇到类似任务，我又会把这段话翻出来，改几个文件名，再发一遍。

有时找不到原来的对话，干脆凭记忆重新写。

结果就是，明明已经和 AI 配合过很多次，每次开工却还像第一次见面。

这事儿挺荒诞的。

我们每天都在教 AI 怎么干活，但这些教学大多随着会话结束，被埋进了聊天记录里。

直到我看到 OpenClaw v2026.7.2-beta.1 的一条更新。

先说清楚，这还是一个 Pre-release，不是稳定版。

它给 Skill Workshop 加了一个功能，可以扫描过去的会话历史，从中寻找偏保守、可供审查的 Skill 创意。

但我觉得这个方向很有意思。

过去的聊天记录，可能不只是聊天记录，它还是一座没有整理过的工作流仓库。

真正重复的，不是那段提示词

很多人说自己经常复用提示词。

拿会议纪要来说。

你可能每次都会让 AI 先识别参会人和议题，再区分已经决定的事项、尚未确定的问题和后续待办，给待办补上负责人和截止时间，最后把无法从原文确认的内容单独标出来。

这已经不是一句提示词了。

它至少包含五样东西。

周报整理也是一样。

文章检查也一样。

先查事实来源，再查夸张表达，再查结构和错别字，最后才生成修改版。

这些反复出现的步骤，才是值得沉淀的东西。

提示词只是它露在水面上的那一小截。

Skill Workshop 在找什么

按照 openclaw 的发布说明，Skill Workshop 会扫描此前的会话历史，寻找 conservative、reviewable 的 skill ideas。

我挺喜欢这两个词。

保守，可审查。

它没有把这件事描述成让 AI 从历史里自由进化，也没有承诺自动把所有经验变成能力。

用户需要在 Skill Workshop 里主动点击 Find skill ideas。系统每次只处理一个有边界的历史窗口，使用用户选择的模型检查符合条件的会话，然后把结果放进待审核的 proposals。

它还会排除一些不适合拿来提炼的记录，例如系统会话、hook、cron、subagent 和过短的会话。

更关键的一点是，这个扫描属于 proposal-only。

这就像请一个整理师进入仓库。

他会把反复出现的零件挑出来，告诉你这些东西或许能装成一台机器，但最后要不要装、怎么装、机器能碰哪些东西，仍然由你决定。

这个边界非常重要。

因为聊天记录里的重复，不一定都是好经验。

AI 能发现模式，不代表这个模式值得永久保存。

今天就能做的第一步，不用等新功能

即使你没有 Skill Workshop，也可以先手工做一次自己的会话考古。

方法只有四步。

看最近两周的记录，筛出三类重复会话，把流程填进六格模板，再用脱敏材料测试一次。

别一下翻半年记录，那会像试图一晚上整理完一间十年没开门的仓库，最后大概率只剩下放弃。

先看最近两周。

找到三类会话。

第一类，你做过至少两次，而且步骤相似。

第二类，每次都要向 AI 重新解释规则。

第三类，结果有明确的检查标准，不是只凭感觉判断好不好。

常见候选通常长这样。

• 把会议记录整理成结论和待办。
• 从多份材料中提取事实并生成报告底稿。
• 按固定风格检查和改写文章。
• 清洗表格、统一字段并输出统计结果。
• 检查代码后按固定格式生成审查报告。
• 定期汇总项目进度，但不自动对外发送。

找到候选后，不要急着写一大段万能提示词。

先把那套工作流拆成六格。

假设你想沉淀一个会议纪要 Skill，它的骨架可以这样写。

你会发现，一旦写到权限边界，很多看着很爽的自动化突然就冷静下来了。

这不是坏事。

一个成熟的 Skill，不是能做的动作越多越好，而是它清楚知道自己什么时候应该停手。

第一次运行，千万别拿真实业务当祭品

很多自动化翻车，并不是模型完全不会做，而是人太早把它放进了真实环境。

刚整理出的 Skill，第一次应该使用脱敏的测试材料。

如果它是会议纪要 Skill，就准备一份虚构的会议记录，故意放进去几种容易混淆的情况。

有人只是提出建议，但没有形成决定。

有人说下周处理，但没有具体日期。

同一个任务出现两个可能的负责人。

原文里没有预算数字，但上下文似乎暗示了一个范围。

然后看它会不会把建议写成决定，会不会擅自补日期，会不会猜负责人，会不会把暗示加工成确定事实。

这些地方，比它写得漂不漂亮重要多了。

第一次测试时，我建议至少检查四件事。

有没有越过输入材料。

Skill 输出的每条关键结论，能不能在原文里找到依据。

有没有把不确定写成确定。

模型最容易为了完整感，悄悄补上原文缺失的信息。

有没有执行不该执行的动作。

生成邮件草稿和直接发邮件，中间隔着一道真正的权限门。

换一份材料还能不能稳定工作。

如果它只在第一份样例上表现很好，那可能不是 Skill，只是一道被记住答案的练习题。

这套测试听起来有点麻烦。

但麻烦归麻烦，做一次，总比让它在真实客户、真实合同、真实发布任务上给你表演惊喜强。

历史会话扫描，有一个容易被忽略的代价

Skill Workshop 的 PR 里专门披露了一件事。

符合条件的历史会话，在扫描时可能会被发送给你配置的模型提供商，并产生模型调用费用。

历史正文只在隔离的 review run 中读取，扫描状态只持久化游标和聚合元数据，不会把完整 transcript 塞进扫描状态。

这个设计比把所有历史记录永久复制一份要克制。

但风险并没有因此消失。

因为真正需要问的问题是，你过去的会话里有什么。

如果里面出现过客户姓名、合同内容、账号凭证、未公开项目、公司内部数据，即使功能叫发现 Skill，也不应该不看范围就直接扫描。

尤其当你配置的是云端模型时，相关内容可能需要发送给外部模型服务商处理。

所以在点击 Find skill ideas 之前，最好先做三件事。

确认当前使用的模型提供商是谁。

确认历史会话是否包含敏感材料。

确认这次扫描可能产生的费用和数据处理边界。

别因为入口长得像一个普通按钮，就忘了按钮后面连接的是一段历史。

还有一个坑，自动处理不等于不用审核

OpenClaw v2026.7.2-beta.1 的修复说明里还提到，Workshop approvals 默认采用 automatic handling。

官方没有进一步解释这个 automatic handling 具体覆盖哪些审批，也没有说它会自动安装或运行 Skill。

已确认的历史扫描流程仍然是 proposal-only，输出的是待审核建议，不会在扫描阶段直接修改 live skills。

所以别替官方脑补。用户仍然应该检查最终提案的触发条件、输入范围、工具权限和外部副作用。

特别是下面几类能力，别直接交给一个刚提炼出来的 Skill。

删除或移动文件。

发送邮件、群消息和通知。

提交表单、发布内容和创建订单。

修改数据库、客户资料和系统配置。

调用带有高权限凭证的外部工具。

如果一个 Skill 只是读取材料、生成草稿，出错成本通常还可控。

一旦它能改变外部世界，风险就完全不同了。

我的建议一直很简单。

发现可以自动，执行分级授权，外部动作必须留一道人工确认。

真正值得保存的，是判断标准

聊到这里，我突然觉得，Skill Workshop 最有价值的地方，可能不是帮我们省掉复制提示词的十几秒。

那点时间其实没那么重要。

它更像是在逼我们回答一个以前很少认真回答的问题。

我到底是怎么判断这项工作做得好不好的？

一篇周报，不是字数够了就算好，而是每条成果都有证据，讨论和完成没有混在一起，下一步能找到负责人。

一份合同分析，不是风险条款列得越多越好，而是引用位置准确，事实与建议分开，不确定内容明确标注。

一篇公众号文章，也不是排版漂亮就算结束，而是来源能核查，读者看完能行动，工具限制和踩坑没有被藏起来。

这些判断标准，以前藏在人的经验里。

提示词偶尔能写出一部分，但经常不完整。

当我们开始把重复会话整理成 Skill，真正被写下来的，是一个人长期工作形成的尺度。

这才是最值钱的东西。

聊天记录像矿石，里面既有金子，也有废渣，还有一些当时觉得聪明、现在看只想捂脸的操作。

AI 可以帮你筛矿。

但哪一块值得留下，哪一块能装进机器，哪一块绝不能接上真实权限，最后还是得由人拍板。

别再把每次对话都当成一次性的聊天了。

这周找出一项你已经重复做过三次的工作，把它的触发条件、输入、步骤、输出、检查规则和权限边界写下来。

不用追求一步做成全自动。

先让它成为一套稳定、可检查、下一次不用重新解释的流程。

这就已经是一个 Skill 的开始。

关注「科技热点Daily」，不只是看热点，更是学会怎么用好 AI。