7 个实战问题教会我的 AI Skill 设计原则

写在前面

过去一周，我完成了一个 AI Skill 的完整开发周期：从大模型生成初稿，到实战测试，再到基于反馈快速迭代到 V0.3.1 版本。

这个过程让我深刻意识到：好的 AI Skill 不是设计出来的，而是从实战中"长"出来的。

今天我想分享的，不是这个 Skill 有多厉害，而是实战中暴露的 7 个问题，以及它们教给我的7 个设计原则。这些原则不仅适用于我正在开发的 research-framework Skill，也适用于任何 AI Skill 的设计。

背景：一个 Skill 的诞生

这个 Skill 叫 research-framework，定位是"框架驱动的渐进式研究协作"。

简单来说，它不是直接给你一份研究报告，而是：

1. 先和你一起搭建研究框架
2. 然后逐节点辩论（AI 先表态，然后和你辩论）
3. 最后整合成完整报告

听起来很美好，对吧？但实战测试中，它被"打"得遍体鳞伤。

问题 1：概念前置缺失

场景还原

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

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

最后我们不得不回填一个节点 1.5，专门解释 Skills。

问题本质

框架生成逻辑有一个盲区：只考虑"研究课题本身的子命题"，没有考虑"理解这些子命题所需的前置概念"。

设计原则 1：概念前置自检

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

• 框架生成后增加自检环节
• 识别核心概念（如 Skills、Agent、Pipeline 等）
• 主动询问用户："是否需要先解释 XX 概念？"

问题 2：类型刚性

场景还原

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

这些不是作为独立节点出现的，而是嵌套在其他节点的辩论过程中自然涌现的。

问题本质

研究类型在开头一次性锁定，但实际讨论是动态演化的。

设计原则 2：动态标签优于静态分类

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

• 课题层面：识别主线类型（可复合），向用户确认
• 节点层面：每个节点标注自己的类型倾向，不要求和主线一致
• 动态调整：如果辩论过程中类型特征发生变化，AI 自然切换讨论方式

问题 3：开场格式太重

场景还原

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

但到了节点 2 和节点 3，对话越来越深入后，这个格式开始显得机械——有时候一个节点的判断本身就很复杂需要分几段话来表达，硬塞进"一段话表达立场"反而会丢失细节。

问题本质

单一格式无法适配不同深度的讨论场景。

设计原则 3：轻重模式自适应

开场格式分轻重两种模式：轻模式用于信息确认型节点（直接给判断 + 关键依据 + 讨论点），重模式用于需要深度辩论的节点（保留完整的四板块结构）。AI 根据节点的预估深度自动选择。

• 轻模式（用于轻度节点）：

  🔍 节点 X：[名称]
  【判断】[简要立场]
  【依据】[关键支撑，1-2 条]
  【讨论点】[一个具体问题]
  

• 重模式（用于中度/重度节点）：

  🔍 节点 X：[名称]
  【我的判断】[可以分多段表达]
  【支撑论据】1/2/3
  【薄弱点】[主动暴露不确定处]
  【讨论点】[引导辩论]
  

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

场景还原

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

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

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

但 AI 的流程设计是"AI 开场→用户回应→辩论→收尾"，隐含假设是 AI 先说、用户后说。

问题本质

缺少处理"用户主动注入信息导致讨论维度扩展"的机制。

设计原则 4：走向 D 机制

当用户提供了 AI 未预料到的一手信息时，AI 不应该急着收拢到原来的讨论点上，而应该先消化这些信息、评估其对当前节点乃至整个框架的影响，然后再决定是继续当前讨论点还是调整方向。

• 辩论过程增加"走向 D"：用户注入新信息导致维度扩展
• AI 响应流程：消化信息 → 评估影响 → 显性说明"你提供的信息改变了我的判断方向" → 决定继续或调整
• 如果新信息需要触发框架调整，走向 C（命题重新定义）

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

场景还原

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

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

问题本质

框架变更往往是辩论中最有价值的产出，不应该只是收尾时的一句附注。

设计原则 5：变更单独成段说明

每个节点收尾时，如果有框架变更，应该单独成段说明变更的原因和对后续节点的影响，而不是作为收尾模板的一个字段一笔带过。如果没有框架变更，也可以主动说明"经过本节点讨论，现有框架依然适用，无需调整"，这样用户对框架的稳定性也有感知。

• 有变更时：

  【框架变更】
  变更内容：[具体变了什么]
  变更原因：[为什么需要变]
  对后续影响：[哪些节点的讨论角度或重心因此调整]
  

• 无变更时：

  【框架状态】经过本节点讨论，现有框架依然适用，无需调整。
  

问题 6：跨节点洞察缺失

场景还原

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

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

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

问题本质

缺少超越单一节点的、贯穿性重要判断的捕捉机制。

设计原则 6：洞察积累板块

在进度同步时，除了展示各节点状态外，增加一个"研究洞察积累"板块，用来记录讨论过程中浮现的、超越单一节点的重要判断。这些洞察在最终整合输出时会成为报告最有价值的部分。

• 进度同步增加"💡 研究洞察积累"板块
• 只记录超越单一节点的、贯穿性的重要判断
• 每条洞察用一句话概括
• 最终整合输出时，从"研究洞察积累"中整理

问题 7：隐性信息无处理

场景还原

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

这是关于组织内部的政治洞察（领导觉得商业价值普世性应用更重要，员工提效会导致老板派更多活）。用户不希望这些信息出现在最终的研究产出中。

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

问题本质

缺少处理"用户标记为背景理解用"的隐性信息的规则。

设计原则 7：隐性信息内化但不外显

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

• 识别用户隐性信息标记（"你懂就好"、"不用拿出来说"等）
• 作为判断的隐性输入，调整判断角度和表达分寸
• 不在节点结论或最终报告中显性引用

总结：7 个原则一张表

写在后面

这 7 个原则，不是我在办公室里想出来的，而是实战中被打出来的。

它们可能不适用于所有 AI Skill，但我相信其中蕴含的思维方式是有价值的：

• 框架先行，但框架是活的
• 用户主导，但 AI 要表态
• 格式服务于内容，而非内容迁就格式
• 用户的智慧应该被充分吸纳
• 高价值洞察要持续积累
• 用户信任比完整输出更重要

如果你也在开发 AI Skill，希望这些原则能给你一些启发。如果你有不同的经验，欢迎交流。