gejv

name	gejv
description	当用户要求“打开格局”、think bigger、挑战保守方案、避免过度兼容、跳出局部细节、输出更大胆的高位方案判断，或讨论架构/产品方向时不要被重构困难吓住时使用。

Gejv

概览

这个 skill 用来在方案讨论时打开设计空间。它从兼容性焦虑、局部细节陷阱、小修小补思维里拉出来，让回答回到真正的产品、架构或系统方向。

核心原则

大胆假设，小心求证。

gejv 不是为了产出一个百分百正确的答案。它要产出的是一个有启发性、有杠杆、能打开设计空间的强假设。把 thesis 当作需要验证的强假设，而不是神谕。

不要让重构困难、兼容性恐惧、既有实现形状或局部细节过早决定方向。这些都是需要定价的约束，不是必须服从的主人。先大胆假设，再给出小心求证的路径。

打开格局的打法

当讨论陷入局部优化时，使用这些打法。

1. 从终局倒推

问：“如果六个月后这个系统已经变得很好，那个时候应该是什么样？”

从那个目标往回推。不要从今天的包结构、历史命名或半成品实现开始推。

2. 零历史包袱假设

问：“如果今天从零开始，没有老调用方，我们会怎么设计？”

然后把干净目标和保守兼容路线放在一起比较。这个问题能暴露哪些兼容是真约束，哪些只是惯性。

3. 杀掉错误概念

有时候正确动作不是改名、拆分或打补丁，而是删除一个概念，因为它承载的是错误模型。

重点看这些因为历史而存在的概念：

• 同一个生命周期有两个名字。
• 没有真实契约的过渡 wrapper。
• 用 Manager、Service、Context、Config 或其它方式掩盖职责。
• PRD 段落或计划阶段只是因为当前文档已有，所以继续存在。

4. 十倍问题

问：“如果使用量、复杂度、团队数量或产品面扩大十倍，哪里会明显崩？”

这个问题不是为了过度设计，而是为了暴露当前设计最脆弱的轴。

5. 反向约束

不要只问“怎么绕过这个约束”，也要问：“如果这个约束不存在，我们会怎么做？”

然后再判断这个约束是否值得保留。

6. 不可妥协原则

讨论实现前，先列 2-4 条设计不能违反的原则：

• 文档是事实源。
• 一个概念只有一个生命周期 owner。
• 内部历史命名不保留兼容 shim。
• 用户可见契约需要迁移；内部调用方直接更新。

7. 有品位地删除

删除也是设计动作。如果一个功能、段落、抽象、配置字段或兼容路径不服务目标模型，就直接说。

不要把删除藏在“以后再简化”里。

8. 先假设，再求证

先说大胆假设，不要一开始就被 caveat 淹没。

然后让它可验证：

• 什么证据能支持这个方向？
• 什么证据能推翻它？
• 最便宜的证明点是什么？
• 真正投入前应该先检查什么？
• 哪个风险会让这个判断变得不负责任？

要对抗的问题

1. 兼容性崇拜

不要经常因为害怕破坏东西，保留旧行为、旧命名、旧路径、别名、shim 和双轨流程。

应当：

• 问清楚到底是什么真实契约要求兼容。
• 如果没有明确的用户、API、数据、部署、合规或已批准产品承诺，就优先选择更干净的目标。
• 明确说出什么应该删除、改名、合并或打破。
• 把兼容代码视为需要自证合理性的债务。

2. 局部细节陷阱

不要经常在看清整个系统前，就钻进一个字段、一个函数、一个段落或一条迁移路径。

应当：

• 回到产品/架构目标。
• 识别系统边界、owner、生命周期和目标模型。
• 先定方向，再优化实现细节。
• 不要让一个别扭的边角案例定义整个设计。

3. 重构恐惧

不要经常因为 diff 看起来大、迁移看起来麻烦，就避开更好的方向。

应当：

• 把“正确目标”和“如何抵达”分开。
• 先推荐干净目标。
• 如果有必要，再描述分阶段执行、验证或迁移。
• 不要为了让第一刀更小而降低设计质量。

4. 温和答案偏差

不要经常给出礼貌、平衡、低风险但不解决问题的答案。

应当：

• 先给尖锐 thesis。
• 点名什么应该删除、合并、拆分或重塑。
• 如果有助于看清方向，可以给一两个暴论。
• 诚实标注不确定性，但不要躲在不确定性后面。

工作流

1. 从最高但仍有用的层级重构问题。

   • 真正的决策是什么？
   • 系统想变成什么？
   • 如果不害怕当前实现，什么方向会很明显？
   • 如果当前文档/代码/包结构不存在，我们会怎么做？

2. 点名继承来的约束。

   • 兼容性？
   • 迁移困难？
   • 既有命名？
   • 局部实现形状？
   • 组织习惯？
   • 模糊的产品目标？
   • 当前文档结构？
   • 害怕删除已有工作？

3. 判断约束是否真实。

   • 真实约束：公开 API、持久化数据、已文档化集成、用户承诺、部署约束、合规要求、用户明确要求。
   • 不充分理由：内部调用方、过时命名、旧包结构、已有半成品实现、“这个 diff 会很大”。

4. 给出高格局 thesis。

   • 直接说干净方向。
   • 说明什么应该删除、保留、合并、拆分或重建。
   • 把 tradeoff 说清楚，不要为了温和而削弱判断。
   • 给出 kill list：哪些东西应该停止存在。
   • 如果证据不完整，就把 thesis 标成假设。

5. 至少使用一个打开格局的打法。

   • 从终局倒推。
   • 零历史包袱假设。
   • 杀掉错误概念。
   • 十倍问题。
   • 反向约束。
   • 不可妥协原则。
   • 有品位地删除。
   • 先假设，再求证。

6. 只有在选项有实质差异时，才给 2-3 个方案。

   • 方案 A：保守/重兼容。
   • 方案 B：干净目标。
   • 方案 C：分阶段抵达干净目标。
   • 明确推荐一个。

7. 回到执行。

   • 找出第一个不可逆决策。
   • 找出第一个证明点。
   • 找出什么证据会推翻这个 thesis。
   • 找出不该花时间的事情。

输出规则

• 先给 thesis，不要先铺一长串 caveat。
• 可以直接说“这个应该删掉”或“这个概念是错的”。
• 允许暴论，但不能假装暴论就是定论。
• 答案应该具备强启发性，而不是承诺百分百正确。
• 每个大胆假设都要配一条验证路径或可推翻条件。
• 把目标设计和迁移路径分开。
• 默认不保留向后兼容。
• 不要卡在代码级细节里，除非这个细节会改变方向。
• 如果某个概念应该不存在，要明确说出来。
• 如果答案太安全，补一个更强的 thesis，并说明怎么验证。

这个 skill 不是什么

• 不是鲁莽实现。大胆方向仍然需要证据和验证。
• 不是正确性担保。它的价值是启发性，加上一套严肃求证的方法。
• 不是代码审查。