最近有个观点很流行：“用 AI Agent 时，尽量简要描述，让它自行探索。”
这个说法在通用任务上确实有效——比如让 Claude Code 写个贪吃蛇、解析个 JSON、调个 API。
但在私有化的工作和开发流程中，这个建议几乎完全失效。
🎯 通用任务 vs 私有流程
通用任务的特征：
| 特征 | 说明 |
|---|---|
| 标准输入输出 | 输入明确，预期结果清晰 |
| 无上下文依赖 | 不需要了解项目历史或团队规范 |
| 技术栈成熟 | 有海量训练数据可供参考 |
| 容错率高 | 跑不通可以再来一次 |
典型场景：
1
2
3
"写个快速排序"
"把这个 JSON 转成 Java 类"
"解释一下这段代码"
私有流程的特征：
| 特征 | 说明 |
|---|---|
| 隐性规则多 | 团队约定、历史包袱、环境约束 |
| 上下文敏感 | 依赖项目结构、配置文件、部署流程 |
| 质量要求高 | 不能随便”试试”，必须一次做对 |
| 流程固定 | 有明确的审批、测试、发布环节 |
典型场景：
1
2
3
"按照我们团队的规范，新增一个 API 接口"
"修复这个 Bug，要走完整的测试流程"
"把这个服务部署到测试环境"
通用任务靠探索，私有流程靠规范。
🤖 为什么 AI 不懂你的私有流程
AI 不知道的事情：
- 你的代码规范是什么
- 变量命名用 camelCase 还是 snake_case？
- 异常处理是 throw 还是 return error？
- 日志格式有什么特殊要求？
- 你的发布流程是什么
- 需要先跑 lint 吗？
- 测试覆盖率要求多少？
- 部署到哪个环境？
- 你的技术栈约束是什么
- 能不能引入新依赖？
- 数据库用 MySQL 还是 PostgreSQL？
- 微服务之间怎么通信？
没有这些信息，AI 只能产出通用代码。
能跑就行，不问出处。
但这在生产环境是绝对不行的。
📋 解决方案：将工作流显性化为 Skills
Skills 的本质：
1
Skills = 工作流的标准化 + 流程的结构化 + 约束的可执行
一个完整的 Skill 应该包含：
| 组成部分 | 说明 | 示例 |
|---|---|---|
| 触发条件 | 什么场景下使用 | “修复 Bug”、”新增 API” |
| 输入参数 | 需要什么信息 | Bug 描述、API 需求 |
| 执行步骤 | 按什么顺序做 | 定位 → 分析 → 修复 → 验证 |
| 输出标准 | 什么是”完成” | 通过 lint、测试覆盖 |
| 约束条件 | 不能做什么 | 不能改核心配置、不能引入新依赖 |
示例：Bug 修复 Skill
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# Bug 修复流程
## 触发
用户报告 Bug 或测试失败
## 步骤
1. 定位 Bug 位置（读错误日志、看调用栈）
2. 分析根因（查相关代码、问用户预期行为）
3. 制定修复方案（说明思路，等待确认）
4. 执行修复（小步提交，每步验证）
5. 运行验证（lint → build → test）
## 约束
- 不能改核心架构
- 不能引入新依赖
- 必须通过现有测试
🛠️ Skills 的创建策略
策略 1：从实际场景中提炼
不要凭空想象 Skills，从已有的工作流程中提取。
| 场景 | 提炼为 Skill |
|---|---|
| 每次新增 API 都走同样流程 | api-generator |
| Bug 修复有固定步骤 | bug-fix-flow |
| 发布前有检查清单 | release-checklist |
| 代码审查有标准 | code-review-template |
策略 2：借助工具简化创建
不用一开始就写得很完美，可以借助 tools 迭代优化。
1
2
3
4
1. 手动执行流程 → 记录步骤
2. 用 skills-creator 整理结构
3. 实际使用 → 收集反馈
4. 持续优化 → 形成最佳实践
策略 3：分层设计 Skills
| 层级 | 说明 | 示例 |
|---|---|---|
| L1: 原子操作 | 单一功能 | run-tests、deploy-env |
| L2: 流程组合 | 多个原子操作串联 | bug-fix、api-release |
| L3: 场景模板 | 完整业务场景 | new-feature、hotfix |
📊 实际效果对比
没有 Skills 时：
1
2
3
4
5
6
用户："修复这个 Bug"
AI：（开始探索）
- 读了 5 个文件，发现不是问题所在
- 改了配置，导致其他测试失败
- 问了 8 个问题，用户越来越烦
- 最后修复了，但引入了新 Bug
有 Skills 后：
1
2
3
4
5
6
7
用户："修复这个 Bug"
AI：（执行 bug-fix 流程）
1. 定位：读取错误日志，定位到 UserService.java:142
2. 分析：空指针异常，缺少 null 检查
3. 方案：添加 Optional 包装，等待确认
4. 修复：小步提交，每步验证
5. 验证：lint ✓ build ✓ test ✓
从”不知道做什么”变成”按流程执行”。
🔑 核心洞察
1. AI 不懂隐性规则
团队里的”常识”，对 AI 来说是黑盒。必须显性化。
2. 流程即代码
Skills 不是文档，是可执行的流程定义。
3. 标准化是前提
没有标准化的流程，AI 无法稳定产出。
4. 工具是加速器
skills-creator 等工具不是为了替代思考，而是为了加速沉淀。
💡 给实践者的建议
如果你刚开始用 AI Agent
- 别指望”简单描述”就能搞定复杂工作
- 通用任务可以探索
- 私有流程必须定义清楚
- 先整理你的工作流
- 把重复性工作列出来
- 写下每一步做什么
- 定义什么是”完成”
- 从小 Skills 开始
- 先做原子操作
- 验证有效后再组合
- 不要一开始就搞大流程
如果你已经有一定经验
- 检查你的 Skills 是否结构化
- 触发条件明确吗？
- 步骤可执行吗？
- 约束可验证吗？
- 持续优化
- 每次使用后记录问题
- 根据反馈调整流程
- 让 Skills 越来越完善
- 分享最佳实践
- 团队内部共享 Skills
- 统一工作流程
- 降低协作成本
🌅 尾声
“简要描述，自行探索”是通用任务的捷径。
“详细定义，流程执行”是私有工作的正道。
AI 不懂你的隐性规则，不懂你的团队规范，不懂你的质量要求。
这不是 AI 的错，是人类工作的复杂性决定的。
最好的系统，不是不能再加东西，而是不能再减东西。
Skills 的意义，就是把那些”不可减”的工作流程，标准化、结构化、可执行化。
这才是 AI Agent 在企业场景真正落地的关键。
