Decision guardrails for natural language programming.
自然语言编程降低了实现成本，但没有降低判断成本。你让 Agent 写代码，它会很快；问题是它也会很快把错误需求、错误边界和错误抽象写进系统里。
自然语言编程里最危险的失败，往往不是模型不会写代码，而是决策发生在了错误的抽象层：
- 需求还没判断是否成立，就开始写 PRD、建接口、生成代码。
- 自然语言描述听起来合理，但用户、场景、边界、验收标准都没有锚定。
- 一个 badcase 反复出现，却不断靠 prompt、关键词、if/else 打补丁。
- 架构问题被当成单点 bug 修，系统越来越难控。
- 没有 eval、回放和复盘闭环，只能靠感觉判断“修好了”。
Failure Stack 把这些问题拆成一套可复用的失败诊断框架，并提供对应的 Agent skills。
Demand Layer 需求层 该不该做
Specification Layer 规格层 到底要做什么
Architecture Layer 架构层 应该在哪一层修
Execution Layer 执行层 Agent 如何稳定完成
Evaluation Layer 评估层 怎么证明真的变好
在开工前判断一个需求是否配存在。
它关注的不是“PRD 怎么写得更漂亮”，而是：
- 真实用户是谁？
- 他们卡在哪个具体时刻？
- 现在怎么解决？
- 新体验是否真的覆盖旧体验和替换成本？
- 当前证据是否配得上资源投入？
当系统开始反复补丁化时，把单点 case 提升为机制层修复。
它处理的问题包括：
- prompt 越修越长
- 同类 badcase 反复出现
- 工具/模式路由靠表层词命中
- if/else、关键词、正则规则不断扩散
- 缺少 eval，无法判断修复是否真实有效
每个 skill 都要回答两个问题：
- 它主要拦截 Failure Stack 的哪一层？
- 它解决哪一种自然语言编程失败模式？
常见失败模式：
| Failure Mode | 中文 | 典型信号 |
|---|---|---|
| Bad Demand Loop | 错误需求循环 | 还没验证就开始做，做完又解释价值 |
| Ambiguous Specification | 规格边界不清 | "做一个智能助手"但没有角色、场景、验收 |
| Patch Spiral | 补丁螺旋 | 同一个问题不断追加 prompt、关键词、分支 |
| Wrong-Layer Fix | 错层修复 | 架构问题被当成 bug，产品问题被当成技术问题 |
| Context Collapse | 上下文坍塌 | 单轮正常，多轮/跨文件/跨会话失败 |
| Eval Blindspot | 评估盲区 | 只能说"感觉好点了"，无法回归验证 |
更完整的框架见 docs/the-failure-stack.md。
把对应 skill 目录复制到你的 Agent skill 系统中，或直接把 SKILL.md 作为任务流程使用。
git clone https://github.com/Longfellow1/failure-stack.git
cd failure-stackClaude Code / Codex / 自定义 Agent 都可以使用这些 skill。这个仓库会优先维护平台无关的决策流程，再补平台适配说明。
failure-stack/
├── README.md
├── README.en.md
├── docs/
│ ├── the-failure-stack.md
│ └── skill-guide.md
├── examples/
│ ├── architecture-whack-a-mole.md
│ ├── bad-demand-loop.md
│ └── eval-blindspot.md
└── skills/
├── deep-fix/
└── product-judgment/
- 先判断，再实现：自然语言让实现太便宜，所以判断必须前置。
- 先归层，再修复：不要把产品问题、规格问题、架构问题都塞进 prompt。
- 少补丁，多机制：重复出现的问题，应沉淀为流程、模块、skill 或 eval。
- 平台无关优先：skill 的核心是决策结构，不是某个工具的语法。
- 可验证才算修好：没有 eval 或回归证据，修复只是主观印象。
这个仓库不会收集"某个模型某个版本的临时咒语"。每个新增 skill 必须有清晰的失败模式、适用层级、反模式、边界和验证方式。
贡献规则见 CONTRIBUTING.md。
Apache-2.0