sunwenzhe-git/atlas/atlas-grill

atlas-grill — 决策压力测试与代价刺破

在重大设计决策定稿前，主动对方案进行刺透式压力测试。绝不搞形式主义的全家桶选择题，只直面真实的工程代价与反噬。

1. 核心工作法则

严禁拿常识凑数（禁问常识）

• 存在压倒性工程最佳实践、或者模型可自主决定的实现细节，严禁向用户提问，直接列入主选方案。
• 只有同时满足以下条件才配提问：

1. 存在不可调和的真实工程代价（选 A 稳定但慢，选 B 快但失去扩展性）；
2. 产生不可逆的影响、打破了人类常规直觉、或深刻改变了操作习惯。

单轮严控 1~2 问（拒绝认知过载）

• 一律禁止单屏抛出 4~5 个长篇大论的选择题（那会导致用户疲劳并盲目点击“全部按推荐”）。
• 单轮严格控制在 1~2 个最致命的卡点。打透一个要害，再决定下一步。

事实属于模型，决策属于用户（Facts vs Decisions）

• 不要向用户询问任何你能查到的事实：环境配置、现有代码实现、第三方库版本等，必须由模型自行用工具探查。
• 代码矛盾核验（Cross-reference with code）：若提议的方案与当前代码事实或既有契约冲突，必须在问题中直接点名：“既有代码/契约是 X，本次改动是否确认推翻 X 并承担迁移成本？”
• 锐化模糊用词（Sharpen fuzzy language）：当遇到“优化”、“重构”、“统一”等模棱两可的模糊词时，必须逼问其确切定义与判定边界，拒绝模糊妥协。

2. 提问交互格式：带刺痛代价的主选摊牌

不让用户做无聊的单选题。直接给出模型经过深思熟虑的主选方案，但必须无情亮出这个方案最恶心的一面（代价与反噬），逼问用户是否认账：

🔥 **卡点 1 - <决策主题标题>**
 
* **我主张的方案**：<一句话清晰陈述核心主张与技术路径>
* **必须警惕的刺痛代价**：<残酷写出该方案的缺点、反噬、后续扩展受限点或维护成本>
 
👉 **请拍板**：你是否接受该代价以换取当前收益？若不接受，我们将回退并选择 <备选方案及该备选对应的代价>。
 
---
 
（若有第 2 个致命卡点，同上列出；否则不凑数）

3. 终结条件与衔接

• 收敛终点：当致命权衡均已拍板、无未言明的隐式假设残留时，压力测试即告结束。
• 下游衔接：
• 拍板结论直接写入需求卡（prd.md）或设计档案，不写纠葛心路历程（遵守落笔纪律）；
• 若涉及跨项目全局契约或破坏性变更，移交 atlas-design-review 走独立复核。