一个 Skill 的诞生：从实战反馈到 V0.3.1 的快速迭代

写在前面

2026 年 4 月 1 日，我用 6 个小时完成了一个 AI Skill 的完整开发周期：

• 14:00 - 大模型生成 V0.1 初稿
• 15:00 - 实战测试（OpenClaw 研究分享案例）
• 17:00 - 基于 7 个实战问题修复到 V0.2
• 17:30 - 用户提出三个新需求，增强到 V0.3
• 17:45 - 增加中场休息能力，迭代到 V0.3.1
• 20:00 - 研究完成，输出完整版报告 + PPT Prompt
• 21:00 - 博客文章发布

这篇文章，我想记录这个从实战中"长"出来的 Skill的完整诞生过程。

V0.1：大模型生成的起点

需求定义

一切始于一个想法：我想要一个框架驱动的渐进式研究协作 Skill。

为什么？因为我发现现有的 AI 研究助手有个共同问题：

你给它一个课题，它直接吐出一份报告。但你不知道这份报告是怎么来的，也不知道有没有更好的角度。

我想要的不是"研究执行者"，而是"研究协作者"——先和我搭建框架，然后逐节点辩论，最后整合成报告。

V0.1 初稿

我让一个大模型生成了初稿，核心功能包括：

• 研究类型识别（A-F 六种类型）
• 全流程阶段定义（课题录入→逐节点辩论→进度同步→整合输出）
• 辩论规则（AI 应该坚持/让步的情况）
• 特殊情况处理（课题模糊、跳过节点等）

看起来挺完整的，对吧？但我知道，真正的考验是实战。

实战测试：OpenClaw 研究分享案例

研究课题

我要给多个部门分享 AI 项目攻坚组怎么去研究 openclaw，
并且对我们以往的 AI 应用开发项目带来帮助的课题

研究框架

生成了 5 个节点的研究框架：

1. OpenClaw 到底是什么——建立准确认知
2. 与现有技术栈的能力错位分析
3. 回溯已有项目——哪些环节 OpenClaw 能带来改善
4. 落地门槛与风险评估
5. 面向多部门的分享策略

辩论过程

接下来是5 个节点的深度辩论，持续约 3 小时。

• "攻坚组铺路、各部门使用"的分层模式
• OpenClaw 是"放大器"而非"赋能器"
• 人机协同透明度三档模型（vibe coding 黑盒 < Dify DSL 可视 < Skills 双方可读）
• "人辅助 AI"新范式（AI 作为思考中枢，人作为经验源）
• B 端 C 端 AI 结构性博弈（服务端 AI vs 客户端 Agent）
• Superagent Eats the Interface（SaaS 界面层价值正在被 Agent 侵蚀）

看起来一切顺利？不，问题开始暴露了。

7 个实战问题的暴露

问题 1：概念前置缺失

研究进行到节点 2 时，用户突然说："这里有一个很重要的概念没有去声明——Skills。"

原来，我们在讨论 OpenClaw 和 Dify 的区别时，频繁提到"Skills"这个概念。但听众如果不理解 Skills 是什么，后续所有讨论都缺乏基础。

问题 2：类型刚性

研究开始时，识别主线类型为"B（技术选型对比）"。但节点 2 的辩论中，浮现了"D（抽象理论研究）"的特征——关于"人辅助 AI"的思考。

问题 3：开场格式太重

节点 1 的辩论，AI 用了完整的四板块开场格式：判断→论据 1/2/3→薄弱点→讨论点。体验还行。

但到了节点 2 和节点 3，对话越来越深入后，这个格式开始显得机械。

问题 4：用户注入信息无处理

辩论过程中，用户多次注入大量 AI 未掌握的一手信息：

• 个人部署体验（Win vs Linux 能力差异）
• 听众画像（文科背景、学 Dify 一年仍半吊子）
• 组织洞察（两类项目不做区分导致设计问题）
• 行业判断（B 端 C 端 AI 隐性博弈）

这些信息不是对 AI 判断的"回应"，而是全新的输入，直接改变了讨论的走向。

问题 5：框架变更呈现被动

节点 2 辩论中，新增了一个节点 1.5（Skills 概念澄清）。这是辩论中最有价值的产出之一。

但 V0.1 的设计是"如果辩论过程中框架有调整就说明变了什么"，这是一个被动的记录行为，作为收尾模板的一个字段一笔带过。

问题 6：跨节点洞察缺失

讨论中出现了几个贯穿多个节点的重要洞察：

• "人辅助 AI 而非 AI 辅助人"
• "透明度是衡量人机协作质量的关键维度"
• "OpenClaw 是万能胶水层"

这些洞察不属于任何单一节点，而是在多个节点的讨论中逐渐浮现的。但 V0.1 没有机制来捕捉和积累这类跨节点洞察。

问题 7：隐性信息无处理

用户在辩论中明确说过："这是我的心里话，你懂就好不用显性拿出来说。"

这是关于组织内部的政治洞察。用户不希望这些信息出现在最终的研究产出中。

但 V0.1 没有这个机制——AI 收到的所有信息默认都会被用于讨论和输出。

V0.2：基于实战反馈的重大修订

针对 7 个问题，我逐一修复：

修复 1：概念前置自检

在框架生成后增加自检环节：

AI 审视框架，判断：讨论这些节点是否依赖某个尚未被显性定义的核心概念？如果有，主动建议插入"概念澄清"节点。

修复 2：动态标签制

研究类型改为动态标签：

主线类型用于确定框架骨架，但每个节点可以有自己的类型倾向。讨论方式根据实际走向自适应，不在开头一次性锁死。

修复 3：轻重模式自适应

开场格式分轻重两种模式：

• 轻模式（用于轻度节点）：判断 + 依据 + 讨论点
• 重模式（用于中/重度节点）：完整四板块结构

修复 4：走向 D 机制

辩论过程增加"走向 D"：用户注入新信息导致维度扩展：

AI 先消化这些信息，评估其对当前节点和整体框架的影响，不急于收拢到原来的讨论点上。

修复 5：变更单独成段说明

节点收尾框架变更单独成段：

• 有变更时：详细说明变更内容、原因、对后续影响
• 无变更时：主动说明"现有框架依然适用，无需调整"

修复 6：洞察积累板块

进度同步增加"💡 研究洞察积累"板块：

只记录超越单一节点的、贯穿性的重要判断，每条洞察用一句话概括。

修复 7：隐性信息处理规则

增加隐性信息处理规则：

当用户明确标记某些信息为"背景理解用"时，AI 将其作为判断的隐性输入，可以调整判断角度和表达分寸，但不在节点结论或最终报告中显性引用。

V0.3：用户提出的三个补丁

补丁 1：多种触发关键词

用户说："唤起的方式可以更多样化一点。"

于是增加了 5 个新触发词：

• 超级研究
• 框架研究
• 交互式研究
• 互动式研究
• 项目式研究

补丁 2：Idea-Pad 零碎思路记录

用户说："对话过程中随时发现零碎思路，要能随时记录。"

于是增加了 Idea-Pad 功能：

• 对话过程中随时记录灵感、待验证假设、延伸方向
• 每条 Idea 标注状态：待闭环 / 已纳入节点 X / 已舍弃
• 整合输出前进行闭环检查，确保有价值的思路不丢失

补丁 3：双格式输出

用户说："完成报告后，需要两种不同的格式。"

于是增加了双格式输出：

• 完整版研究报告：结构性强、内容深入、篇幅完整
• PPT Prompt 分页导出：按页分格的 PPT 生成指令，可直接用于生成演示文稿

V0.3.1：中场休息能力

用户问："有没有类似在比较长的交流过程中，中场休息一样的对过去的内容的阶段性总结的能力？"

于是增加了中场休息能力：

• 用户可随时触发阶段性总结（"中场休息"、"阶段性复盘"、"方向校准"）
• AI 展示完整进度、复盘关键洞察、检查 Idea-Pad、校准方向
• 支持研究快照保存，跨会话恢复进度
• AI 主动建议信号：已完成≥5 节点、单节点≥10 轮、用户疲劳信号、框架重大变更后

方法论总结：框架驱动的 Skill 开发流程

回顾整个过程，我总结出一套框架驱动的 Skill 开发流程：

阶段 1：大模型生成初稿

• 明确核心定位和差异化价值
• 让大模型生成完整初稿
• 不追求完美，先有骨架

阶段 2：实战测试

• 选择真实研究课题进行测试
• 完整跑完所有流程
• 记录所有问题和反馈

阶段 3：问题归纳

• 将问题分类（概念缺失、流程缺陷、体验问题等）
• 识别优先级（高/中/低）
• 逐一制定修复方案

阶段 4：快速迭代

• 基于修复方案修改 Skill
• 更新版本号（V0.1 → V0.2）
• 记录变更日志

阶段 5：用户反馈增强

• 收集用户使用中的新需求
• 评估需求价值
• 增强功能（V0.2 → V0.3）

阶段 6：细节打磨

• 修复小问题
• 优化体验
• 完善文档（V0.3 → V0.3.1）

阶段 7：输出成果

• 完整版研究报告
• PPT Prompt 分页导出
• 博客文章分享

写在后面

这个 Skill 的诞生过程，让我深刻意识到：

好的 AI Skill 不是设计出来的，而是从实战中"长"出来的。

V0.1 的 7 个问题，如果我不做实战测试，永远不会发现。 V0.3 的三个补丁，如果我不听用户反馈，永远不会想到。 V0.3.1 的中场休息，如果我不问"还有什么可以改进"，永远不会添加。

如果你也在开发 AI Skill，希望这个诞生故事能给你一些启发。