Addy Osmani 的 agent-skills 真正值得抄的不是24个Skill，而是“AI不准跳过验证”的工程合同
AI编程最危险的时刻，不是它不会写代码。 而是它看起来已经写完了。 测试“后面再补”，边界情况“应该没问题”，重复代码“先这样”，README里写“已完成”，真实项目一跑却不是那么回事。 Addy Osmani 的 agent-skills 之所以值得研究，不是因为仓库里有多少个Prompt，而是它把软件开发过程拆成了必须留下证据的阶段。 当前官方仓库已经不只是原帖描述的那一个版本：仍
Addy Osmani 的 agent-skills 真正值得抄的不是24个Skill，而是“AI不准跳过验证”的工程合同
AI编程最危险的时刻，不是它不会写代码。
而是它看起来已经写完了。
测试“后面再补”，边界情况“应该没问题”，重复代码“先这样”，README里写“已完成”，真实项目一跑却不是那么回事。
Addy Osmani 的 agent-skills 之所以值得研究，不是因为仓库里有多少个Prompt，而是它把软件开发过程拆成了必须留下证据的阶段。
当前官方仓库已经不只是原帖描述的那一个版本：仍然保留 /spec、/plan、/build、/test、/review、/ship 等主生命周期，同时还扩展了性能、简化等命令和更多Agent兼容。
所以最该提炼的是稳定原则，而不是死记命令数。
1. 真正的问题：Agent会合理化“为什么可以不做”
人类工程师也会偷懒。
Agent更特别的是，它可以在几秒钟内生成一段听起来非常合理的解释：
“为了效率，先跳过测试。” “这个改动很小，不需要完整review。” “已有类型系统能保证安全。” “先实现功能，重构以后再说。”
这类话的问题不是语言，而是它在替自己降低验收标准。
agent-skills里很有意思的一类设计，就是把这些常见合理化提前列出来，并要求Agent反驳它。
这可以抽象成：
Rationalization → Counter-rule → Required Evidence。
不是告诉Agent“认真一点”。
而是明确：
如果你想跳过这一关，要先拿出什么证据。
2. DEFINE → PLAN → BUILD → VERIFY → REVIEW → SHIP
这条链真正强的地方，是每一步的输出不同。
DEFINE
把“做一个功能”变成： 用户目标； 范围； 非目标； 验收； 风险。PLAN
把规格拆成可检查的小步骤，而不是直接开始写。BUILD
增量实现，每次只承担有限范围。VERIFY
跑测试、构建、lint、类型检查或项目特定验证。REVIEW
从实现正确性、可维护性、安全、性能等角度反向攻击结果。SHIP
不是“代码写完”，而是所有交付证据齐全后再进入发布。这和我们 alphahole 的 FINAL/MERGE/REJECT 有一个共同点：
状态由证据决定，不由“我感觉做完了”决定。
3. 但“写进Skill”不等于真的不能跳过
这里必须给项目降温。
Prompt/Skill里的“必须测试”仍然只是行为约束。
真正不可绕过的门应该尽量放到工具层：
CI必须绿； required checks； branch protection； typecheck； security scan； test threshold； artifact checksum； deployment approval。
所以最佳结构是：
Skill Contract + Tool-enforced Gate。
AI负责遵守流程，人类和CI负责让关键门不能靠一句话绕过。
4. 24个Skill不是越多越好
B47我们刚总结过 Stack Complexity Budget。
如果一个团队把仓库里所有Skill全装上，却没有明确： 什么时候触发； 什么时候不触发； 输入是什么； 输出是什么； 谁有权限； 失败怎么办； 验收是什么；
最后只会得到更多上下文冲突。
所以每个Skill仍然必须有：
Trigger； Anti-trigger； Inputs； Workflow； Permissions； Human Gate； Output； Acceptance； Failure； Evals； Version。
agent-skills可以作为参考库，不是“24个全部开启”的理由。
5. 专家角色也不能变成多Agent表演
代码review、安全、性能、测试专家角色有价值。
但四个Agent都读同一份错误上下文，然后一致说“没问题”，不是独立审查。
真正的 Independent Review 需要： 证据独立； 检查维度独立； 最好有工具结果； 冲突有裁决。
所以： Security Agent ≠ security scanner； Performance Agent ≠ benchmark； Reviewer ≠ CI。
角色只是视角。
证据才是Gate。
6. 最值得借鉴：交付必须有“Done Contract”
我会把工程Done定义成：
Spec Exists； Plan Traceable； Code Changed； Tests Executed； Build/Lint/Typecheck； Review Findings Resolved； Security/Performance where relevant； Docs/Changelog； Rollback； Release Evidence。
如果项目不需要其中一项，也应该明确写 N/A + reason。
这比“AI自己说任务完成”可靠得多。
7. 商业机会
这个方向非常适合并入现有 Skill Trust Workbench 和 AI MVP Build Loop。
可收费的不是“给你安装agent-skills”。
而是：
- 盘点现有AI编码流程；
- 找最常见的跳步；
- 把Skill Contract写清；
- 把关键门搬进CI；
- 建项目级验收；
- 做回归Eval；
- 记录Agent失败模式。
企业真正愿意付钱的，是降低返工、线上事故、review时间和不可解释改动。
8. V3怎么验证
不要看“用了以后Agent输出更专业”。
看四个数字：
任务返工率； 漏测率； PR review时间； 发布后缺陷。
如果Skill越来越复杂，却这四个指标没改善，按Kill/Merge Rule继续删。
Stop Rule
如果某个工程Skill： 增加大量上下文； 让Agent输出更长； 却没有增加任何可验证证据；
它不是质量系统。
只是更长的提示词。
AI工程化真正的升级，不是让Agent像资深工程师说话。
是让它和资深工程师一样，对“完成”负责。