让 Agent 在动手之前，先做对判断。
Failure Stack 是一组面向产品与 AI / Agent 工程实践的判断型 Skills。
- 俞军 Skill：需求到底值不值得做？
- 大道至简 Skill：问题到底应该在哪一层修？
Judge before building. Fix the layer, not the case.
| 俞军 Skill | 大道至简 Skill | |
|---|---|---|
| 核心问题 | 该不该做？ | 该在哪一层修？ |
| 典型入口 | Idea、需求、Roadmap、PRD 前评审 | Badcase、Prompt 膨胀、规则堆叠、路由失败 |
| 核心动作 | 用户场景 → 用户价值 → 假设与证据 → 判决 | Case → Pattern → Mechanism → Eval |
| 主要输出 | BUILD / VALIDATE FIRST / DE-SCOPE / REFRAME / KILL | case / rule / mechanism / module / skill / harness / migration |
| 方法来源 | 《俞军产品方法论》核心思想的 Agent 化实现 | 来自真实 AI / Agent 工程实践的独立方法总结 |
| 位置 | skills/product-judgment |
skills/deep-fix |
flowchart LR
A[需求 / 想法] --> B[俞军 Skill<br/>该不该做]
B -->|BUILD| C[实现]
C --> D[Badcase / Eval]
D --> E[大道至简 Skill<br/>该在哪一层修]
E --> F[机制修复 + 回归验证]
F --> C
E -->|根因是需求 / 边界问题| B
这不是两个互不相关的 Prompt。
产品判断负责阻止错误需求进入系统；大道至简负责阻止错误修复继续污染系统。 当工程问题反复暴露出需求、边界或价值定义错误时，重新回到产品判断。
不是帮你把 PRD 写得更漂亮，而是在写 PRD、排 Roadmap、投入工程资源之前，先判断这个需求是否成立。
它会持续追问：
- 真实用户是谁？
- 用户卡在哪个具体时刻？
- 今天是怎么解决的？
- 新体验是否真的覆盖旧体验与替换成本？
- 当前证据是否配得上资源投入？
核心判断之一：
用户价值 = 新体验 - 旧体验 - 替换成本
并通过 L0–L4 证据等级、假设审讯和失败预演，给出明确判决，而不是一句“看情况”。
方法来源说明：本 Skill 基于《俞军产品方法论》中关于用户模型、用户价值、交易模型与产品决策的核心思想，由本项目重新整理并转化为适用于 AI Agent 的执行流程。非俞军官方作品。
一个 badcase 最容易得到的答案，是再加一句 Prompt、一个关键词、一条规则或一个 if/else。
大道至简关心的是另一件事：
这个 case 是孤立问题，还是系统缺失了一个正确抽象？
它会先检查重复次数、逻辑分散程度、Eval 是否存在、上次修复是否引入副作用，再决定修复应该停留在 case，还是上升到 rule、mechanism、module、skill、harness 或迁移方案。
case → pattern → mechanism → reusable skill/module → evaluation loop
核心原则：
好的修复让系统忘记这件事，而不是记住更多例外。
它不是“重构优先”。真正的一次性 edge case 可以直接修；过早抽象本身也是反模式。
方法来源说明：大道至简 Skill 来自本项目作者在 AI / Agent 工程中的实际使用经验与复盘，不依附于单一书籍或既有框架。
输入：
竞品 App 上线了 AI 搜索，我们也要跟进，不然用户会流失。
俞军 Skill 不会先讨论模型、入口和排期。 它先把“竞品动作”还原成用户问题：谁真的需要？在哪个场景失败？现在如何解决？“用户会流失”到底是数据还是猜测？
如果证据仍停留在“竞品有 / 老板担心 / 用户可能流失”，当前更接近 L0–L1，典型结果是：
VALIDATE FIRST / 先验证
先证明现有搜索问题真实存在，并且值得用 AI 搜索解决，再投入工程资源。
完整示例：examples/bad-demand-loop.md
输入：
Agent 又选错工具了。上次加了关键词规则，这次用户换了说法又走错了。
我们再补几个 trigger？
大道至简不会默认接受“再补规则”这个解法。 它先检查：同类问题出现过几次？判断逻辑散落几处？有没有 Router Eval？上次修复有没有让其他 case 变差？
当同类失败持续出现时，问题会被从单点 case 提升为 Routing / Patch Spiral / Wrong-Layer Fix，目标从“补上这句话”变成“让这一类表达变化不再击穿系统”。
完整示例：examples/architecture-whack-a-mole.md
两个 Skills 背后共享同一个判断：失败往往不是没修，而是修错了层。
| Layer | 核心问题 | 当前 Guardrail |
|---|---|---|
| Demand | 该不该做？ | Product Judgment |
| Specification | 到底要做什么？ | Roadmap / Contributions welcome |
| Architecture | 应该在哪一层修？ | Deep Fix |
| Execution | Agent 如何稳定完成？ | Roadmap / Contributions welcome |
| Evaluation | 怎么证明真的变好？ | 两个 Skill 均要求 Eval；独立 Guardrail 在 Roadmap |
更完整的模型见 docs/the-failure-stack.md。
git clone https://github.com/Longfellow1/failure-stack.git
cd failure-stack直接使用对应的 SKILL.md，或把整个 Skill 目录复制到你的 Agent Skills 系统中：
skills/product-judgment/SKILL.md
skills/deep-fix/SKILL.md
核心流程保持平台无关，可用于 Claude Code、Codex 或自定义 Agent 工作流。
- 先判断，再实现：实现越来越便宜，错误判断反而越来越贵。
- 先归层，再修复：不要把产品、规格和架构问题全部塞进 Prompt。
- 少补丁，多机制：重复出现的问题应该沉淀成稳定能力。
- 证据改变判断：权力、进度和沉没成本不是证据。
- 可验证才算修好：没有 Eval 或回归证据，修复只是主观印象。
Failure Stack 不收集“某个模型某个版本的临时咒语”。一个 Skill 要进入这里，至少需要清晰的失败模式、适用边界、反模式和验证方式。
贡献规则见 CONTRIBUTING.md。
Apache-2.0