---
title: "如何把经验装到Skills"
source_url: "https://mp.weixin.qq.com/s/GIpqXfAT8ESR7c50yctpRQ"
ingested: 2026-04-30
type: raw
tags: [agent-skill, skill-writing, case-study, saas, product-management]
review_value: 7
review_confidence: 6
review_recommendation: worth-reading
review_stars: 3
sha256: "{pending}"
created: 2026-05-10
updated: 2026-05-10
---
# 原文存档：如何把经验装到Skills
## 文章信息
- **来源**：微信公众号文章
- **主题**：SaaS 产品经理调试"需求工作量评估" Skill 的三轮回炉过程
## 核心内容
### 调试背景
SaaS 产品经理每周评估 1-10 家客户定制需求工作量，少则 1 小时，多则一整天。既重复又高频还费时间，但认真做完后真正付费的客户可能不到 5%。这是一个典型适合用 Skills 解决的场景。
### 第一轮调试：Skill 干太多事
**做法**：一个 Skill 同时输出解决方案、用户故事、流程图 + 工作量评估。
**问题**：
- 评估基准飘了：经验判断约 15 人天的需求，Skill 给出 30-59 人天
- 拆得太细太技术化，研发内部内容直接暴露给客户
**根因**：一个 Skill 同时承担"方案设计"和"工作量评估"两种不同职责，一个偏发散，一个偏收敛，不该混在一起。
### 第二轮调试：只给约束，不给方法
**做法**：拆成两个 Skill，测试 Skill 专门负责评估工作量。给出硬性比例约束（测试工作量是后端 1/3-1/2、前端是后端 1/2 等）。
**问题**：Skill 非常"听话"地照着比例套用，结果教条——15 人天的经验判断，Skill 套出来 44 人天（后端 18+前端 9+测试 9 天），数字规整但结果不对。
**根因**：只给比例不给判断框架 = 告诉新人很多规则但没让他建立判断框架。AI 会认真执行约束，但不理解为什么这样约束。
### 第三轮调试：给经验，更给判断逻辑
**核心改变**：不再给死规则，而是把真正的方法论讲清楚。
四条关键原则：
1. **需求是 1，方案是 1**：需求没搞清楚之前不能评估工作量；方案没定下来之前不能给时数
2. **明确的拆解路径**："需求 → 场景 → 模块 → 功能 → 原子任务"链路，一个功能点只做一件事，链路要闭环
3. **五步法**：按需求→场景→业务→最小功能点→任务的顺序逐层展开，不按角色拍脑袋
4. **给经验参考系，不给铁律**：测试工作量通常是后端的一半；产品按需求复杂度浮动（小需求 0.5 天，复杂需求 3-5 天）
**后续微调**：输出形式从"按角色评估"改为"按场景组织"（一行一个用户场景，客户更易读）；产品/测试改为场景级汇总而非逐功能点细拆。
### 最终判断标准
| 标准 | 说明 |
|------|------|
| 颗粒度合适 | 不能粗到只剩总人天，也不能细到全是不懂的技术项 |
| 结果符合经验 | 经验判断 10 人天 → 上下 20% 波动可接受，翻倍或离谱则无意义 |
### 核心结论
**Skills 不是替你"发明"工作经验，而是帮你把已有经验稳定地复用出来。** Skill 的价值 = 你讲清楚多少判断标准和方法论，而非给出多长的提示词。
## 补充视角
本文从**使用者视角**（产品经理把经验装进 Skill）补充了技能系统的方法论，与 `agent-skill-writing` 的**设计者视角**（Skill 格式规范、渐进式披露、评估方法）形成互补。