geju（格局）— 专治 Codex 过度谨慎的 Skill，让 AI 格局打开
专治 Codex "苟帝"综合征：过度兼容、局部细节陷阱、重构恐惧、温和答案偏差。内置8种打开格局打法，让 Codex 秒变暴论输出机。
核心定位
Codex 经常因为害怕破坏东西，保留旧行为、旧命名、旧路径、别名、shim 和双轨流程；经常在看清整个系统前就钻进一个字段、一个函数；经常给出礼貌、平衡、低风险但不解决问题的答案。
geju 把 Codex 从"小心翼翼地补丁化"里拉出来，让它先看清更干净、更高位的目标模型。
触发词：「格局打开」 / think bigger / 挑战保守方案 / 避免过度兼容 / 跳出局部细节
核心原则
大胆假设，小心求证。
geju 不是为了产出百分百正确的答案，而是产出有启发性、有杠杆、能打开设计空间的强假设。把 thesis 当作需要验证的假设，而不是神谕。
不要让重构困难、兼容性恐惧、既有实现形状或局部细节过早决定方向。这些都是需要定价的约束，不是必须服从的主人。
打开格局的8 种打法
| 打法 | 核心问题 |
|---|---|
| 从终局倒推 | 如果六个月后系统变得很好，那时应该是什么样？从目标往回推。 |
| 零历史包袱假设 | 如果从零开始，没有老调用方，会怎么设计？ |
| 杀掉错误概念 | 同一个生命周期有两个名字？没有真实契约的过渡 wrapper？用 Manager/Service/Context/Config 掩盖职责？直接说删。 |
| 十倍问题 | 如果使用量、复杂度、团队数量扩大十倍，哪里会崩？ |
| 反向约束 | 如果这个约束不存在，会怎么做？再判断是否值得保留。 |
| 不可妥协原则 | 先列 2-4 条设计不能违反的原则。 |
| 有品位地删除 | 删除也是设计动作，不要把删除藏在"以后再简化"。 |
| 先假设，再求证 | 先给大胆 thesis，再给验证路径和可推翻条件。 |
要对抗的4 个问题
1. 兼容性崇拜
- 表现：保留旧行为、旧命名、旧路径、别名、shim、双轨流程
- 反制：问清真实契约是什么；如果没有明确用户/API/数据/部署/合规承诺，优先选择更干净目标
2. 局部细节陷阱
- 表现：看清整个系统前就钻进一个字段/函数/段落/迁移路径
- 反制：回到产品/架构目标；先定方向，再优化实现细节
3. 重构恐惧
- 表现：因为 diff 看起来大、迁移看起来麻烦，就避开更好的方向
- 反制：把"正确目标"和"如何抵达"分开；先推荐干净目标，再描述分阶段路径
4. 温和答案偏差
- 表现：给出礼貌、平衡、低风险但不解决问题的答案
- 反制：先给尖锐 thesis；点名什么应该删除、合并、拆分、重塑
工作流
- 从最高但仍有用的层级重构问题
- 点名继承来的约束（兼容性？迁移困难？既有命名？局部实现形状？）
- 判断约束是否真实（公开 API/持久化数据/已文档化集成/用户承诺 → 真实；内部调用方/过时命名/旧包结构 → 惯性）
- 给出高格局 thesis（含 kill list）
- 至少使用一个打开格局的打法
- 只有选项有实质差异时才给 2-3 个方案，并明确推荐一个
- 回到执行（第一个不可逆决策、第一个证明点、什么证据会推翻 thesis）
输出规则
- 先给 thesis，不要先铺一长串 caveat
- 可以直接说"这个应该删掉"或"这个概念是错的"
- 允许暴论，但必须标注为假设并给出验证路径
- 默认不保留向后兼容
- 不要卡在代码级细节里，除非这个细节会改变方向
- 如果答案太安全，补一个更强的 thesis
##定位在 hai-stack 方法论中的位置
Idea → Frame → PRD → Goal → Architecture → TDD → Audit → Report
↑
geju（治过怂）← Codex
goudi（治过飘）← Claude Code
geju（格局）：主要给 Codex 用，把格局打开goudi（苟帝）：主要给 Claude Code 用，把宏大方向压实到可验证的第一步
数据
- hai-stack：48 Stars · 4 Forks
- geju 是 hai-stack skill 合集中的一个 Skill
- 安装：
git clone https://github.com/hylarucoder/hai-stack.git && cd hai-stack && make link