当你读完我之前的一篇文章创建你的第一个 SKILL并去创建了你第一个 SKILL 后……
Claude 的 Code Skills 很强，但也很“野”。 上个月，我让 CreatePage Skill 帮我建个用户管理页
它自信回复：“✅ 成功！”—— 结果页面空白，Mock 缺字段，CI 全红。
这不是模型不行，而是我们把确定性任务交给了概率系统。
经过三轮迭代，我们总结出一条清晰路径：从自由生成 → 规则约束 → 原子交付。最终实现零人工修复、15 秒交付、99.9% 成功率。
如果你也在被“假自动化”困扰，这篇复盘值得一看。
问题出在哪
传统软件是确定性系统：输入 A，永远输出 B，可以用 ASSERT 验证。
Agent（AI 智能体）是概率性系统：输入 A，可能输出 B、C、D……每次轨迹都不同，无法用传统断言判断对错。
这是范式冲突： 前端工程交付，本质上是一个强确定性需求 ；但大模型生成代码，却是一个概率采样过程
知道这个后，我把 SKILL 纪律分为三个阶段
第一阶段：自由生成 —— 快，但内容不稳定
🛠️ 典型做法
就像我们最开始一样用简单对话自动生成的 SKILL 去跑业务
- 自动化直接写入 Vue 文件
- 读取路由配置，以字符串拼接方式追加新路由
- 根据经验模板生成 Mock 数据
✅ 优势
- 上手快：让大模型自己生成，效果还不错。
- 适合探索：临时需求、原型验证、非关键路径
- 看起来高效：一次调用，完成多项操作
⚠️ 但问题很快暴露
- 结果不稳定：相同输入，多次执行结果不一致
- 错误静默：工具报告成功，实际漏了关键步骤
- 难以验证：没有断言机制，只能人工检查
第二阶段：规则约束 —— 给自由加上护栏
当错误开始影响交付节奏，我们的第一反应是：加校验、定流程、限权限。
🛠️ 典型做法
- 强制执行顺序（先问参数，再操作）
- 对输入参数做格式校验（如路径必须以
/开头） - 展示正确格式跟错误格式指导输出
- 错误处理
- 增加后置验证步骤（如检查文件是否存在）
模板如下
---
# 文档前置信息
---
# [简要用途说明 - 1–2 句话]
## 概述
[描述此技能的功能、使用场景及所提供的价值]
## 前置条件
[列出所需的工具、文件或上下文]
## 操作步骤
### 步骤 1：[第一步操作]
[使用祈使句给出明确指令]
[必要时提供示例]
### 步骤 2：[下一步操作]
[使用祈使句给出明确指令]
### 步骤 3：[最后一步操作]
[使用祈使句给出明确指令]
## 输出格式
[说明结果应如何组织]
## 错误处理
[当出现问题时的应对措施]
## 示例
[提供具体的使用示例]
## 相关资源
[引用随附的 references/、assets/ 等内容]
✅ 收益明显
- 错误率下降：成功率提升至 ～95%
- 行为更可预测：执行路径被显式约束
- 团队信心增强：至少知道“应该怎么做”
持续维护文档
- 主动的：用多了会抽象总结的更好；对业务理解的更深
- 被动的：工具能力在提升 （模型的、Claude的），文档描述需要删除或者升级；业务变化
打造你团队 SKILL 飞轮
第三阶段：原子化脚本 —— 把确定性交给程序
真正的可靠性，来自原子化的、可验证的程序单元。
🛠️ 核心思想
- 前端交互层只负责收集参数并触发执行
- 所有工程逻辑由独立脚本完成：文件生成、路由配置（AST）、Mock 注册、验证、回滚
- 脚本是黑盒：输入参数，输出唯一结果，失败则自动还原
✅ 当前终极解
- 可靠性极高：脚本是确定性程序，支持单元测试
- 成本更低：执行仅需 15 秒，无冗余交互
- 维护简单：业务逻辑变更只需改脚本，调用方零改动
- 可审计：每一步可记录、可回放、可回滚
📊 实测数据
- 成功率：>99.9%
- 平均耗时：15 秒
- 人工修复率：<0.1%
参考
我上一篇文章Claude Code Skills 的混合自动化方案
为你的 SKILL 选择合适的阶段
现实中，有些操作确实难以封装：
- 需要动态推理（如“根据日志建议修复方案”）
- 涉及多系统联动（如“查监控 + 查代码 + 提 PR”）
- 依赖上下文风格（如“按上周的组件风格改这里”）
对这类任务，第二阶段（规则约束）是合理过渡。
但关键在于：要有意识地识别哪些操作“未来可标准化” ，并预留接口。
工程纪律不是“一刀切”，而是“分层治理”：
- 能原子化的 → 立刻封装为脚本
- 暂不能原子化的 → 加强约束 + 监控
- 永远无法标准化的 → 接受其不确定性，仅用于辅助决策
如何判断该停在哪一阶段？
这个任务是否有明确、固定的输出规则？
├─ 否 → 保持在 Stage 1 或 2（接受不确定性）
└─ 是 → 能否封装成单一入口脚本？
├─ 否 → 用 Stage 2（强约束 + 验证）
└─ 是 → 升级到 Stage 3（原子化脚本）
目标不是“所有自动化都脚本化”，而是“所有确定性操作都不依赖文本拼接或经验推测”。
总结
自动化工具的价值，不在于它能“智能生成”，而在于它能稳定交付符合规范的结果。
真正的工程纪律，是清晰划分：
- 哪些环节可以依赖启发式逻辑（如需求理解、草稿生成）
- 哪些环节必须由确定性程序保证（如文件写入、配置变更）
通过 自由生成 → 规则约束 → 原子交付 的三阶段演进，
我们不是在追求“全自动”，而是在构建一个可信赖、可维护、可扩展的自动化体系。
因为只有当每一次自动化输出都可预期、可验证、可回滚，
它才真正成为团队的生产力，而不是负担。
最后，也是预告
SKILL 很强，如果不生效，等于裸奔。又回到运气编程。
我们团队在使用时做过一个统计：在不干预的情况下， AI 主动调研项目 Skills 的概率只有 40%左右。也就是说，你规范写得再好依旧有 60% 的时间在裸奔。
怎么办，且看我下篇文章 用 Hooks + Commands + Agents + Skills 打造超溜的Claude Code工作流
