Appearance
如何把经验装到Skills：三轮调试的完整方法论
AI已经这么强了，为什么还要把经验喂给它？你不是在教AI变聪明，而是给它边界、约束、参考。告诉它什么叫符合你的业务现实，什么叫符合你的判断标准，什么才是你真正想要的输出。
真实场景：SaaS产品经理的痛点
每周评估1-10家客户的定制需求工作量，少则1小时，多则一整天。认真做费时间，不认真做客户追问"评估依据"。
矛盾：真正付费定制的客户可能不到5%。
这就是一个典型适合用Skills解决的问题。
第一轮：一个Skill干太多事
设想：输入需求，同时输出解决方案、用户故事、流程图、工作量评估。
问题：
- 评估结果偏差大：经验判断15人天，它给出30人天甚至59人天
- 拆得太细太技术化：日志管理、数据映射配置直接摊给客户
教训：一个Skill同时承担"方案设计"和"工作量评估"两种职责，一个偏发散，一个偏收敛，不该混在一起。
第二轮：拆开职责，但只给要求不给方法
改进：拆成两个Skill——一个负责设计方案，一个负责评估工作量。
加了约束：
- 测试工作量通常是后端的1/3到1/2
- 前端一般是后端的一半
- 产品和设计最小，简单需求1天，复杂不超过5天
结果：15人天的需求被评到44人天。它特别"听话"，完全照着比例套：后端18天、前端9天、测试9天。
问题：只给比例不给方法，它会认真执行约束，却不理解为什么这么约束。
类比：给新人很多规则，对方每条都记住了，但做出来的还是不对。问题不在执行力，而在没有建立判断框架。
第三轮：给经验，更要给判断逻辑
推倒重来，从0到1重写Skill，只做一件事：工作量评估。
核心方法论
| 原则 | 说明 |
|---|---|
| 需求是1，方案是1 | 需求没搞清楚不能评估；方案没定下来不能给时数 |
| 拆解路径 | 需求→场景→模块→功能→原子任务 |
| 五步法 | 按需求、场景、业务、最小功能点、任务逐层展开 |
| 经验是参考不是铁律 | 测试是后端的一半，产品按复杂度浮动，但只是参考系 |
微调输出形式
第一次微调：
- 把"UI"换成"产品"角色
- 表格按场景组织：每行一个用户场景，功能点聚合在同一格
- 允许0.2、0.4天，不必从0.5起跳
第二次微调：
- 产品和测试从"功能级逐项评估"改成"场景级汇总评估"
- 这两个角色通常没必要在每个小功能点上拆那么细
最终结果终于符合预期，正式投入工作。
怎么判断一个Skill"可用"了
| 标准 | 说明 |
|---|---|
| 评估颗粒度合适 | 拆成若干场景，场景下再拆若干功能点 |
| 结果符合经验 | 10人天上下20%波动可接受，翻倍或压得离谱不行 |
本质：Skills不是替你"发明"工作经验，而是帮你把已有经验稳定地复用出来。
几个重要经验
1. 一个Skill只做一件事
写需求文档是一个Skill，探索方案是一个Skill，输出正式方案是一个Skill，评估工作量是一个Skill，画原型是一个Skill，写上线公告也是一个Skill。
分得越清楚，越容易稳定。
2. 把每个Skill当成刚入职的聪明实习生
它能力很强，执行也很快，但不是你肚子里的蛔虫。你不给背景它只能猜；你不讲标准它只能按"通用理解"做。
3. 把经验和方法论当上下文告诉它
AI学过很多知识，但不代表它天然知道你的行业、团队、工作的判断标准。你可以直接把方法论讲给它。
4. 工具和模型的选择会影响结果
免费工具足够尝鲜，但如果想把Skills当成生产力而非玩具，好工具、好模型确实会让你少走很多弯路。
总结
| 要点 | 说明 |
|---|---|
| 核心原则 | 一个Skill只做一件事 |
| 角色定位 | 把它当成刚入职的聪明实习生 |
| 经验注入 | 把方法论当上下文直接告诉它 |
| 工具选择 | 好工具好模型让体验更稳定 |
你现在写进去的，究竟只是任务说明，还是已经开始把自己的经验装进去了？
这两者的差别，决定了Skills最终是玩具，还是生产力。
关键词：Skills编写, AI经验注入, 工作量评估, 方法论, 提示词调试, Skills最佳实践
