最近在深度使用Skills的过程中，我发现了一个有趣的现象：很多人在写Skills时，往往陷入一个误区——要么期待AI自动理解所有背景，要么过度依赖硬性约束来"驯服"AI的输出。但经过几轮真实项目的调试，我逐渐认识到，问题的核心不在AI的能力，而在于我们如何定义和传递工作的判断标准。
这篇文章记录的，就是我如何把一个看似简单的工作量评估需求，调试成真正能投入生产工作的Skills的全过程。或许能帮你理解，什么样的经验和方法论，才值得装进Skills里。
问题背景：为什么需要把经验"装进"Skills？
你可能会问：AI已经这么强了，为什么还要强调把自己的经验喂给它？
答案很直接：你不是在教AI变聪明，而是在给它一个边界、一个约束、一个参考。你在告诉它：
- 什么才叫符合你的业务现实
- 什么才叫符合你的判断标准
- 什么才是你真正想要的输出结果
否则，AI当然也能给你答案，而且往往很完整、很漂亮、很像那么回事。但那些内容可能未必属于你，未必适合你的场景，甚至只是"高大上"，却和实际工作没什么关系。
一个真实场景
作为SaaS产品经理，我每周要评估1-10家客户的定制需求工作量。这件事既重复、又高频、特别费时间。关键是：
- 不认真评估，客户会追问依据
- 认真评估，真正付费的客户连5%都不到
这是一个典型的"高重复、高专业度、低转化"的工作——完全适合用Skills去优化。
第一轮调试：一个Skill干太多事的陷阱
初始想法
最开始，我的思路很直接：一个Skill一次性解决所有问题。输入需求，同时输出解决方案、用户故事、流程图，再给出工作量评估。听起来很"一步到位"。
结果暴露的问题
虽然能出东西，但问题明显：
| 问题类型 | 具体表现 | 根本原因 |
|---|---|---|
| 评估结果偏差大 | 经验判断15人天的需求，输出可能是30-59人天 | 评估基准已飘离实际 |
| 拆解过于技术化 | 暴露日志管理、数据映射等研发内部细节 | 没有区分客户视角和技术视角 |
| 职责混淆 | "方案设计"（发散）和"工作量评估"（收敛）混在一起 | 一个Skill承载了两种不同的思维模式 |
关键认知：一个Skill最好只做一件事。这不仅是设计原则，也是稳定性的保证。
第二轮调试：拆开职责，但陷入了新问题
调整策略
这一轮我做了两个改变：
- 拆分职责：一个Skill负责设计方案，一个专门评估工作量
- 加强约束：明确告诉AI一些经验判断
- 测试工作量 = 后端的1/3到1/2
- 前端工作量 = 后端的1/2
- 产品和设计：简单需求1天，最复杂5天
验证案例
需求背景：新增审批流功能，支持审批通过后自动同步Excel表附件数据到系统。系统已有两种导入方式，但还不支持通过审批流程导入。
经验判断：约15人天
AI输出：44人天（后端18天、前端9天、测试9天）
问题诊断
结果反而更离谱。为什么？因为我只给了比例，没有给方法。AI非常"听话"，几乎完全照着比例去套，看起来逻辑自洽，但结果完全不对。
这时我才意识到：只给规则不给框架，AI会过度执行约束，却不一定真的理解为什么。这就像给新人一堆规则，对方每条都记住了，但做出来还是不对——问题不在执行力，而在没有建立判断框架。
第三轮调试：把方法论讲清楚
根本转变
前两轮失败后，我意识到一个核心问题：我对AI有不切实际的期待。我希望它像"肚子里的蛔虫"，既能自动读懂需求，又能自己掌握拆解方法。但现实是，这等于期待一个刚入职的同事，在不了解业务、不熟悉系统的情况下，直接产出完全符合预期的结果。
所以第三轮，我从0到1重新写了一个全新的Skill，只做一件事：工作量评估。
核心改变：传递方法论而非硬约束
这一次的关键不是加强约束，而是把真正的方法论讲清楚：
第一：遵循"需求是1，方案是1"的原则
需求没搞清楚前，不能直接评估；方案没定下来前，也不能直接给时数。必须经过这个链路：
需求确认 → 方案确定 → 工作量评估
第二：建立明确的拆解路径
我给出的拆解维度链路是：
需求 → 场景 → 模块 → 功能 → 原子任务
配套拆解原则：
- 一个功能点只做一件事
- 链路要闭环
- 不要为了拆而拆
第三：给出分步拆解的方法
工作量评估定义为"五步法"，按顺序逐层展开：
- 需求理解：明确输入输出
- 场景划分：区分不同业务场景
- 业务梳理：跨模块依赖分析
- 功能拆解：最小功能点识别
- 任务评估：按角色分配工作量
而不是一上来就按角色拍脑袋报数。
第四：经验可以给，但不要给死
参考系而非铁律：
| 需求复杂度 | 产品工作量 | 测试工作量规则 |
|---|---|---|
| 小需求 | 0.5天 | 后端的1/2 |
| 常规需求 | 1天 | 根据链路覆盖范围浮动 |
| 中等需求 | 2天 | - |
| 复杂需求 | 3天 | - |
| 超级复杂 | 最多5天 | - |
持续微调阶段
虽然这一轮好多了，但输出形式还是不符合工作习惯。于是继续微调：
第一次微调：改变输出组织方式
- 把"UI"改成"产品"角色
- 表格逻辑从"角色维度"改成"场景维度"
- 每一行 = 一个用户场景
- 功能点聚合在同一格
- 后端、前端、产品、测试分别展示工作量
- 最后一行汇总总人天
- 允许0.2、0.4天这样的细粒度评估，不必强行从0.5起跳
第二次微调：优化产品和测试的评估粒度
- 产品：从"功能级逐项评估"改成"场景级汇总评估"（因为产品更多按需求复杂度判断）
- 测试：从"逐项评估"改成"整体链路和风险范围评估"（因为测试不需要在每个小功能上拆得那么细）
什么样的Skill才算"可用"？
真正决定一个Skill能否进工作流，我只看两个标准：
标准一：评估颗粒度要合适
- ❌ 太粗：只剩一个总人天 → 无法向客户交待
- ❌ 太细：全是技术细节 → 客户看不懂
- ✓ 恰好：需求拆成若干场景，场景下再拆功能点
- 场景负责让客户看懂
- 功能点负责支撑细节
标准二：工作量结果要符合常识
- 经验判断：10人天
- ✓ 可接受：8-12人天（20%浮动范围内）
- ❌ 不可用：5人天或20人天（翻倍或腰斩）
关键认知：Skills不是替你"发明"工作经验，而是帮你把已有经验稳定地复用出来。
写Skills时，应该怎么想这件事？
原则一：一个Skill只做一件事
别贪心。系统化地拆分职责：
- 写需求文档 = 一个Skill
- 探索方案思路 = 一个Skill
- 输出正式方案 = 一个Skill
- 评估工作量 = 一个Skill
- 画原型 = 一个Skill
- 写上线公告 = 一个Skill
分得越清楚，越容易稳定。
原则二：把Skill当成很聪明的实习生
它能力强，执行快，但：
- 它不是你肚子里的蛔虫
- 你不给背景，它只能猜
- 你不讲标准，它只能按"通用理解"做
原则三：把方法论当成上下文
AI学过很多知识，但不代表它天然知道：
- 你所在行业的判断标准
- 你团队的工作方法
- 这份工作的隐含规则
你完全可以直接把方法论讲给它，而不是期待它自己猜中。
就像这次工作量评估用到的拆解思