design-philosophy

name	design-philosophy
description	系统级设计哲学——围绕"系统统一性"的宏观设计原则。覆盖碎片化消除、设计语言统一、设计思路统一、机制同构、模块配合模式统一、系统一致性先于局部便利、宏观设计反思。任何项目、任何子系统设计取舍时对照。Triggers on 设计审查, 碎片化, 设计语言统一, 设计思路统一, 系统一致性, 机制统一, 配合模式, 宏观设计反思, 设计取舍, design philosophy.

设计哲学（Design Philosophy）

从长期协作中提炼的用户设计取舍原则。通用，任何项目可用。 核心关切：系统级的统一性——当系统变大、模块变多时，如何防止碎片化、割裂、各搞一套，让用户与内核始终感受到"这是一个统一系统"而非"一堆拼凑的模块"。 用途：设计评审、机制设计、模块间配合设计、方案取舍时对照自检。

一、单一权威源（反碎片化）

任何系统级概念，只能有一个权威模型、一个权威查询入口。禁止同一事实/同一对象在两处维护或两处可取。

• 系统级概念示例：任务/执行单元状态、配置、事件、资源生命周期、类型身份。
• 反例：同一类对象的状态散落两处维护，且两个查询入口返回不一致结果；同一事实在两个模块各存一份，改一处忘另一处。
• 自检：
  • "这件事"全系统只有一处能问出权威答案吗？
  • 两个入口查询同一状态，结果会一致吗？
  • 有没有"双写真相"（同一事实两处写）？
• 判定：只要出现"两个入口 / 两处维护同一概念"，即为碎片化，必须收敛为单源。

二、统一的设计语言

用户与内核观察到的系统，应呈现统一的语义形态：同一种概念，全系统用同一种形态表达，不因模块不同而割裂。

• 概念示例：状态、结果、错误、生命周期、句柄。
• 反例：同类对象在不同模块用不同名字（同物多名）；同一概念一处用"返回值容器"表达、另一处用"异常"表达；用户接触第二个模块时明显感到"和第一个模块不是一回事"。
• 自检：
  • 用户在模块 A 学到的概念/写法，在模块 B 是否同样成立？
  • 同类概念全系统是否有统一命名与统一形态？
  • 有没有"同物多名"或"同名不同物"？
• 判定：用户在两个模块间迁移时若有认知跳跃，就是设计语言割裂。

三、设计思路统一

同类机制的"设计思路"全系统一致：生命周期管理、等待、错误处理、状态查询等，各实现应同构、同一骨架。

• 反例：同类机制一处用句柄方法、另一处用关键字语句；一处阻塞等待、另一处协作等待（无理由的差异）；状态查询一处暴露裸属性、另一处提供完整状态方法。
• 自检：
  • 把"生命周期管理"这类机制抽象出来，各实现的骨架是否相同？
  • 新机制的差异是"本质需求差异"还是"随手实现差异"？
• 判定：同类机制的差异若只是"各写各的"，即为设计思路割裂，须统一。

四、机制同构（复用统一模式）

同类机制应复用同一个模式实现，不重复造轮子、不各搞一套变体。

• 反例：A 模块手写了一套等待逻辑，B 模块又写了一套语义相近但不同的；同一抽象在两处有不同契约。
• 自检：
  • 新机制是否复用了系统既有的同类模式？
  • 有没有"同一语义两种实现"（双通道）？
• 判定：能用既有模式实现的，不新增平行模式；出现"双通道"即为违背。

五、模块配合模式统一

子系统之间的协作方式应统一：走既定配合模式（协议 / 事件 / 句柄 / 队列），不因模块不同而临时拼装。

• 反例：两个子系统协作时，A→B 用协议、B→C 用隐式约定；某子系统与外界交互的方式和其余子系统不一致。
• 自检：
  • 模块间交互是否都走既定模式？
  • 有没有"为这个模块单独发明一种配合方式"？
• 判定：协作方式的差异若无本质理由，即为配合模式割裂。

六、系统一致性先于局部便利

当"方便某处"与"全系统一致"冲突时，以一致性为准。

• 反例：为某个模块的便利引入与全系统不一致的形态（如别人用句柄、它用关键字）；为局部省事打破既有契约。
• 自检：
  • 这个"便利"是否以破坏系统一致性为代价？
  • 用户会不会因为这一处不一致而感到困惑？
• 判定：局部便利若损害全系统一致性，应拒绝；一致性是更高优先级的取舍基准。

七、宏观设计反思

设计每个新机制前后，都做"系统级一致性"审计，而不是只看"能不能工作"。

• 设计前：问"系统里已有的同类机制是什么样？新机制与它们一致吗？会不会引入碎片化？"
• 设计后：做全系统一致性检查——命名、形态、配合模式、等待/错误/状态语义是否统一。
• 反例：只验证"功能可用"就交付，从不检查新机制是否与系统其余部分割裂。
• 自检：
  • 我是否做过"这个机制放进整个系统后，系统还统一吗"的检查？
  • 有没有"功能上能跑、但设计上与系统割裂"的部分？

八、概念命名与粒度统一

一个概念一个名字，全系统统一；不允许同名不同物或同物多名。

• 反例：同一个词既指语言级类型又指内部数据结构（同名不同物）；同一类对象在不同模块有不同名字（同物多名）。
• 自检：
  • 全系统搜同一个概念，是不是只有一个名字？
  • 这个名字在用户语境与内核语境是否指同一物？
• 判定：命名冲突 / 命名漂移即为设计割裂，须收敛。

---

使用时机

• 设计新机制/新模块前：逐条对照本哲学，尤其"单一权威源""统一设计语言""机制同构"。
• 模块间配合设计时：对照"配合模式统一""系统一致性先于局部便利"。
• 设计评审/自我质询（self-grill）时：用本哲学作为系统级取舍的裁决基准。
• 方案陈述给用户时：明确引用本哲学哪一条支撑推荐。

本哲学是系统级统一性的检查清单；与"能工作"正交——先问"统一吗"，再问"能用吗"。