来源: CONTRIBUTING.md doc/design-balance-lore/design-doc.md doc/design-balance-lore/design-gameplay.md doc/design-balance-lore/design-user-experience.md commit d32b9cc880a8 docs-explanation

设计原则

CCB 设计受可观察行为、兼容性、可维护性和项目自身方向约束。历史设计文档提供背景； 当前 CCB 源码、测试、治理与维护者决定哪些仍适用。

评估提案

1. 先说明玩家或贡献者问题，不预设实现。
2. 定义可观察成功条件、非目标、受影响人群和失败模式。
3. 增加引擎复杂度前，检查 JSON、EOC 或受支持 Lua API 是否能表达需求。
4. 明确所有权、生命周期、不变量、序列化、性能热点、UI/无障碍、本地化与平台影响。
5. 区分共同上游行为和 CCB 有意分歧。
6. 优先选择可逆、可测试并有清楚兼容政策的小步修改。

数据驱动不能隐藏语义

只有 loader 能验证、错误可操作且作者能理解生命周期时，把行为移入数据才有价值。 灵活 JSON 或 Lua 表面仍需要约束文档和测试。不要只为避免 C++ 修改就把不稳定内部 hook 发布成公共扩展点。

平衡与内容

机制和平衡提案需要示例、受影响场景与衡量目标结果的方法。技术修复中避免混入大范围 无关再平衡。尊重项目 lore 与内容政策；尚未在 CCB 确认的历史上游指导应明确标记， 不能当作当前规则。

最终决定应保留在 Issue 或经审阅 PR 中，使理由、取舍和 Responsible human 可审计。