在 Twitter 上看到一个案例。一位律师为了处理法律文件，做了一个自己的 Skill。
他没有一开始就去设计规则，而是像平常一样和 Agent 对话。直接丢需求，让 AI 生成初稿，然后基于自己的专业判断去修改，删减不合理的部分，补充遗漏的条款，重写不够严谨的表达。
这一点看似很常见，但下一步就很有意思了。
在经过了半个月到一个月的时间后，他让 AI 回头分析这段时间的所有对话记录。包括他最初的需求表达、中间的每一次修改、强调的原则、否定过的方向。由 AI 整理出一套 SOP，最后再生成 Skill。
传统 SOP 困境
在“非 AI 时代”，我们习惯于先定义规则，再执行任务。这种思维惯性被带到了 AI 时代通常会表现为：
- 过度设计：在还没开始做之前，就想穷举所有可能的边界情况。
- 知识断层：很多行业直觉和细微偏好（比如你对某个功能逻辑的特殊坚持）是很难在第一时间被显性化描述的。
- 僵硬迭代：预设的规则往往跟不上实际业务中那些“拍脑门”产生的灵感。
这就导致很多人写出来的 Skill/Prompt 看起来很专业，用起来却总觉得无法达到预期效果。因为那只是你以为你需要的流程，而不是你真实在使用的流程。
而他的做法是先执行，再抽象。先在真实工作场景里与 AI 进行磨合，再让 AI 自己去总结规律。
这件事的意义在于，它默认一个前提：在有 AI 的环境下，SOP 不必完全由人先验制定。规律可以从大量互动中自然浮现。
从“对话”到“技能”
我最近做自己的产品时也做了类似的尝试。半个月内，我和 AI 之间产生了大量讨论，反复修改结构，重写功能描述，推翻原有逻辑。有些内容是我最初没有意识到的，写到中途才发现必须补充。有些功能写完后觉得冗余，干脆删除。很多决策并不是一次成型，而是在对话中逐渐收敛。
于是我也做了一件事。我让 AI 自动分析这半个月围绕产品的所有对话记录。不是总结文档内容，而是总结我和 AI 的互动方式，包括修改方向、评价标准、方案的否定理由、优先级的判断方式，而 AI 为我提取出了解决问题的几个稳定结构：
- 问题拆解顺序：通常我会声明我要实现的目标，再限制约束条件，最后才讨论实现路径。
- 内容评估标准：是否可验证，是否可落地，是否和核心目标一致。
- 删减原则：只保留与当前版本相关的内容，不为未来假设做过度铺垫。
这些并不是我提前设定的规则，而是从真实工作中自然形成的行为轨迹。通过 AI 的整理，它们变成可以显性表达的 SOP。这一步完成后，再让 AI 基于这套抽象结构生成 Skill，就顺畅很多。
过去很多 SOP 是在没有 AI 的环境下形成的。那时流程的设计目标，是为了降低人的不确定性，提高执行稳定性。现在 AI 参与其中，执行层的能力结构已经改变。如果继续沿用旧式 SOP，往往会限制 AI 的发挥。例如，传统产品文档流程可能强调固定模板和固定章节顺序，但在与 AI 协作时，动态生成结构往往效率更高，模板反而变成负担。
让 AI 参与 SOP 的形成，本质上是在重构工作方法。与其假设自己知道最佳流程，不如让真实对话积累数据，再由 AI 归纳模式。这样得到的 Skill 更贴近实际使用场景，也更符合当前工具能力。
这种方式还有一个意义，它会迫使用户面对真实决策逻辑。哪些方案是稳定的，哪些只是临时情绪，哪些标准反复出现，哪些只是偶然意见。AI 在归纳时不会考虑自我认同，而是只看行为模式。从个人成长角度看，这种反馈是直接且有益的。
构建 Skill 的三个阶段
1. 混沌期：原始沟通
不要背负任何写好 Prompt 的压力，就像面对一个新来的实习生，直接丢需求，看它的反馈，反馈不好就纠正它。积累足够多的交互记录，确保包含修改、否定、补充、重写等完整过程。
2. 沉淀期：自动回溯
当你完成了一两个实际项目后，让 AI 分析这些记录，抽象出稳定规则、决策顺序和评价标准。比如你可以对 AI 说：
“分析一下我们过去两周关于 [XX 任务] 的所有对话。识别出我最关注的重点、我反复修改的逻辑点、以及我最终认可的表达风格。请为我梳理出一套最高效的协作 SOP。”
3. 固化期：技能生成
基于 AI 总结出的 SOP，再让它将其转化为一个结构化的 Skill，并进行小规模验证。这时候的 Skill 已经经过了实战的洗礼，不再是空洞的指令，而是你个人经验的数字分身。
最后
当 AI 成为日常工具后，Skill 不再只是执行脚本，而更像是人与 AI 之间长期磨合后的协作协议。工作方式正在变化，与其试图一次性设计完整体系，不如允许混乱存在一段时间。AI 的优势之一，就是在海量交互中识别这些模式。
Skill 的沉淀，不一定从定义开始，也可以从记录开始。
