gejv

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

概览

这个 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。
点名什么应该删除、合并、拆分或重塑。
如果有助于看清方向，可以给一两个暴论。
诚实标注不确定性，但不要躲在不确定性后面。

工作流

从最高但仍有用的层级重构问题。
- 真正的决策是什么？
- 系统想变成什么？
- 如果不害怕当前实现，什么方向会很明显？
- 如果当前文档/代码/包结构不存在，我们会怎么做？
点名继承来的约束。
- 兼容性？
- 迁移困难？
- 既有命名？
- 局部实现形状？
- 组织习惯？
- 模糊的产品目标？
- 当前文档结构？
- 害怕删除已有工作？
判断约束是否真实。
- 真实约束：公开 API、持久化数据、已文档化集成、用户承诺、部署约束、合规要求、用户明确要求。
- 不充分理由：内部调用方、过时命名、旧包结构、已有半成品实现、“这个 diff 会很大”。
给出高格局 thesis。
- 直接说干净方向。
- 说明什么应该删除、保留、合并、拆分或重建。
- 把 tradeoff 说清楚，不要为了温和而削弱判断。
- 给出 kill list：哪些东西应该停止存在。
- 如果证据不完整，就把 thesis 标成假设。
至少使用一个打开格局的打法。
- 从终局倒推。
- 零历史包袱假设。
- 杀掉错误概念。
- 十倍问题。
- 反向约束。
- 不可妥协原则。
- 有品位地删除。
- 先假设，再求证。
只有在选项有实质差异时，才给 2-3 个方案。
- 方案 A：保守/重兼容。
- 方案 B：干净目标。
- 方案 C：分阶段抵达干净目标。
- 明确推荐一个。
回到执行。
- 找出第一个不可逆决策。
- 找出第一个证明点。
- 找出什么证据会推翻这个 thesis。
- 找出不该花时间的事情。

输出规则

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

这个 skill 不是什么

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