geju

格局

面向中文读者，请参阅 SKILL.zh_CN.md。英文版 SKILL.md 是执行依据。

概述

在方案讨论中打开设计空间：推荐合适的目标模型，而不是最小补丁。输出是一份格局判断——鲜明的论点，加上严谨的验证方法。

核心原则

大胆假设，小心求证。

Geju 不会给出保证正确的答案，而是提出一个高杠杆、富有挑衅性的假设，以此打开设计空间。将论点视为有力的待验证假设，而非神谕：先大胆判断，再制定审慎的验证路径。

重构难度、兼容性顾虑、现有实现形态和局部细节都是需要权衡的约束，不是必须服从的主宰。不要让它们过早决定方向。

打开思路的方式

选择一两种能揭示受困假设的方法，不要把整套方法都用一遍。可用的方法包括：从终态倒推、零遗留代码设想、消除错误概念、十倍问题、约束反转、不可妥协的原则、有品位地删除，以及假设优先验证。当某种方法需要更完整的指导或示例时，请阅读 references/frame-opening-moves.md。

要对抗的问题

这些失败模式会让答案停留在小修小补。请用上述方法和工作流逐一应对，不要把它们稀释成四平八稳、回避问题的答案。

陷阱	表现	应对方法
盲目崇拜兼容性	因担心破坏现状，就保留旧行为、名称、路径、别名、垫片和双流程	追问真正的契约；若没有明确的用户、API、数据、部署、合规或产品承诺，就优先选择更简洁的目标，并明确指出应删除的内容。把兼容性代码视为必须自证合理的债务。
局部细节陷阱	尚未了解整个系统，就深挖某个字段、函数、段落或迁移路径	退一步回到产品／架构目标；先确定系统边界、责任方、生命周期和目标模型；不要让某个棘手的边缘情况定义设计。
害怕重构	因为差异看起来很大或迁移不便，就回避更好的方向	将“正确的目标”与“如何实现”分开；先推荐简洁的目标；只有在有帮助时才描述分阶段迁移；绝不要为了缩小第一个补丁而降低设计标准。
温和答案偏见	答案礼貌、平衡、缺乏分量，回避真正需要做的决定	明确提出鲜明的论点；指出应删除、合并、拆分或重新界定的内容；如果能澄清问题，就给出大胆的判断；诚实标明不确定性，但不要借此回避问题。

工作流

1. 在最有用的高度重新审视问题。 真正需要做出的决策是什么？系统试图变成什么？如果我们不害怕当前的实现，或者今天的文档／代码／包布局不存在，什么会显而易见？

2. 说清继承而来的约束。 兼容性、迁移难度、现有命名、本地实现形态、组织习惯、模糊的产品目标、本地文档结构，或是害怕删除已有工作。

3. 判断约束是否真实存在。 这是这项技能的核心操作——就在这里准确应用。

   • 真实约束：公共 API、持久化数据、已记录的集成、对用户的承诺、部署约束、合规要求，或明确的用户指示。
   • 还不够构成约束：内部调用方、过时的命名、旧的包布局、已有的部分实现、“改动会很大”。

4. 提出高格局论点。 直截了当地说清简洁的方向。说明要删除、保留、合并、拆分或重建什么。明确说明取舍，不要弱化建议。列出清除清单（哪些东西应该停止存在）。证据不完整时，将论点标注为假设。

5. 至少采用一种「拓展视野的方法」。

6. 只有在选项有实质差异时才给出 2-3 个选项，并使用标准标签：保守路径 / 简洁目标 / 分阶段实现简洁目标。推荐其中一个。

7. 回到执行层面。 指出第一个不可逆决策、第一个验证点、什么情况会推翻论点，以及哪些事情不值得花时间。

输出

使用 references/output-template.md 生成一份格局判断。对于快速的方向性问题，保留相同的决策字段，但将其收束为「论点 / 陷阱 / 方向 / 验证」。只有在提案较为全面或用户要求报告时，才使用完整的章节集合。

• 论点 — 犀利、杠杆效应高，用 1-3 句话表达；不要将其说成必然正确。
• 信心 — 标明程度（高 / 中 / 低），并说明为何不能确定。
• 陷阱 — 继承而来的约束、它是否真实存在，以及原因。
• 高格局方向 — 简洁的目标模型。
• 拓展视野的方法 — 使用了哪一种或两种方法，以及它们揭示了什么。
• 大胆判断 — 有理有据的大胆主张；说明要删除／合并／拆分／重命名什么，以及不该保留什么。
• 选项 — 使用表格列出保守路径 / 简洁目标 / 分阶段实现简洁目标，并为每一行给出结论。
• 不要做什么 — 应避免的局部优化、兼容垫片或细节陷阱。
• 首个验证点 — 能证明该方向的最小产物。
• 推翻条件 — 什么证据会证明论点错误。
• 收益账单（Payoff Ledger） — 完整报告中必须包含：现在付出的代价、具体消除的痛点或解锁的能力，以及何时能看到收益。

章节本身未涵盖的输出要求：

• 开头先说论点，不要先长篇铺垫。可以大胆主张，但不要假装它们确定无疑。
• 将目标设计与迁移路径分开。
• 默认不要保留向后兼容性——每个兼容垫片都应视为债务，必须明确指出它所保护的真实契约才能保留。
• 除非代码层面的细节会改变方向，否则不要陷入其中。
• 如果答案显得过于稳妥，就再提出一个更有力的论点，并说明如何验证它。

何时改用其他技能

• 已选定大胆方向，现在需要对可行性／落地风险进行压力测试——使用 goudi，让方案可执行并降低落地风险。geju 和 goudi 是一组互补的立场：geju 拓展视野，goudi 则让方案落地。
• 问题是这个想法是否值得做（做 / 砍掉 / 延后）——使用 hai-idea。geju 假定这项工作值得做，只质疑其范围和高度。
• 用户希望进行实现质量审查——使用 code-review-and-quality。
• 用户希望进行 APoSD 级别的架构评审（模块边界、抽象深度）——使用 hai-architecture。
• 输出是 PRD——使用 hai-prd。

此技能不是什么

• 不是不计后果地实现。大胆的方向仍需证据和验证。
• 不保证正确性。其价值在于提供灵感，并以严谨的方式检验假设。