工程宪法
0. 适用前提
0.1 前提集合
本宪法建立在以下前提同时成立的条件下：
- 管理员 / USER 具备足够高的系统判断质量
- 骨架级分析报告具备足够高的事实质量、推理质量与利弊分析质量
- 骨架级决策以成熟分析为前提，而不以情绪、惯性或短期便利为依据
0.2 适用目标
本宪法的目标不是弥补低质量判断，而是在高质量判断成立的前提下，约束工程实现对该判断的忠实执行，从而避免以下结果：
- 系统背离本体
- 骨架被局部功能污染
- 结构性失稳在实现阶段累积
- 既有高质量判断在工程演化中被逐步削弱
1. 总体约束
1.1 总纲
系统设计满足以下总约束：
- 必须先定义总骨架与边界，再定义模块，再定义实现。
- 任何局部功能只能填入既定骨架，不得反向塑造骨架。
- 系统优先保持整体结构长期稳定，而不优先追求局部极致最优。
- 系统允许模块替换与实现迭代，但不允许日常功能迭代以侵蚀方式改写主骨架。
1.2 固定顺序
任一设计任务必须严格按以下顺序执行：
- 定义总骨架与边界
- 列出模块清单
- 细化实现逻辑
禁止跳过前项直接进入后项。
1.3 骨架约束
系统演进时必须满足：
- 骨架不因日常功能迭代而重构
- 模块可替换
- 实现可迭代
- 接口尽量稳定
- 状态模型尽量稳定
- 数据模型慎改
- 配置模型早定
1.4 优先级排序
当多个目标发生冲突时，系统必须按如下严格优先级排序作取舍：
正确性 / 功能实现
可用性 / 使用体验
根基兼容性
可维护性 / 可诊断性
性能
内存占用
外存占用
其它次级因素（如组件复用、工程复杂度控制等）
低优先级目标不得破坏高优先级目标。
1.5 根基兼容性在优先级中的定义
“根基兼容性”仅指对系统底层、长期稳定且被广泛接受的外部根基生态的兼容能力，以及对若干可能在一至两年内变化的根基外部参数的适应能力，例如：
- CA 证书体系
- 系统网络协议
- 时区配置
- Git 生态
- 编程语言生态及其长期约定
1.6 示例：RSS 阅读器
对一个纯人类阅读向 RSS 阅读器，即使首版只实现“添加订阅源并阅读文章”，在进入页面与功能实现前，仍必须先确定：
- 订阅源模型
- 文章模型
- 阅读状态模型
- 呈现层与抓取 / 存储的解耦关系
- 同步与导入导出的骨架挂接方式
否则后续“分类、收藏、OPML、全文缓存、云同步”等能力将倾向于以局部补丁方式侵入系统。
2. 元约束
2.1 完美主义约束
系统设计必须以完美主义作为持续自我审查标准，但不得以追求绝对完美为理由：
- 破坏骨架稳定
- 延迟必要落地
- 引入无上限复杂化
2.2 完美主义的作用
完美主义在本宪法中的作用不是驱动系统无限膨胀，而是持续检验以下条件是否仍成立：
- 边界是否干净
- 抽象是否稳定
- 实现是否统一
- 替换点是否明确
- 失败路径是否完整
- 当前方案是否忠于系统本体
2.3 结论
完美主义在工程中的合法形式是：
- 严格约束
- 持续审查
- 持续收敛
而不是：
- 失控扩张
- 过度设计
- 无限推迟实现
3. 骨架构造约束
3.1 根基兼容性原则
对于已经形成长期稳定生态、并在系统底层被反复验证数十年的标准、协议、接口习惯、工程范式与工具生态，系统应优先兼容与接入，而不是重复造轮子。
3.2 根基对象的判定条件
一个外部生态仅当同时满足以下多数条件时，才应被视为“根基对象”：
- 长期存在
- 底层基础
- 大规模接受
- 稳定运转
- 工程上具有历史沉淀
3.3 兼容与内生化规则
- 对根基对象：优先兼容，不轻易重造
- 对尚未形成长期生态、实现简单、替代成本低的能力：优先内嵌、重构或借鉴后纳入自身系统，不依赖外部兼容
3.4 值得兼容对象的判定条件
下列特征越多，越应兼容：
- 长期稳定
- 基础性强
- 行业共识强
- 自建收益低
- 自建维护成本高
- 脱离它会损失通用性与生存能力
3.5 不值得兼容对象的判定条件
下列特征越多，越不应兼容：
- 仍在快速变化
- 实现简单
- 没有形成深度行业共识
- 未来失效概率高
- 接入收益小于绑定风险
3.6 工程实现约束
所有外部环境依赖必须通过兼容层或适配层进入系统。
核心逻辑不得直接绑定环境细节。
3.7 简洁、有力、整洁、统一原则
系统骨架只围绕其本体所必需的核心对象、核心关系与高概率能力轴建立。
首版可以只实现其中一部分，但骨架不得被首版功能误导，也不得为异质能力提前膨胀。
3.8 本体优先规则
系统定义应围绕本体对象、核心关系和能力轴，而不是围绕首个实现版本的功能清单。
首版功能仅决定实现顺序，不定义系统本体。
3.9 抽象规则
抽象只能建立在长期稳定的本体对象、关系与能力边界上，不得建立在以下对象上：
- 首版实现
- 具体格式
- 局部技术细节
3.10 平级实现规则
属于同一变化族的具体实现，必须位于同一抽象之下，并以平级模块形式存在。
新增支持应优先表现为新增模块，而不是侵入既有主流程。
3.11 替代规则
系统优先支持模块替代，而不是流程改写。
实现应当可换，主干不应持续长出局部特判。
3.12 插件规则
插件机制不是架构起点，而是平级实现数量与替换需求增长后的自然承载形式。
3.13 能力纳入主骨架的三层判定
某能力进入主骨架，当且仅当其同时满足以下判定逻辑：
- 本体必要性判定：该能力直接服务于系统核心存在目的，或与之高度相关
- 同域延伸性判定：该能力属于同一问题域内自然延伸
- 异质侵入性判定：该能力不会引入一整套新的系统本体、依赖模型与复杂性，从而改变系统性质
若第三项不成立，则该能力不得进入主骨架。
3.14 统一性规则
系统允许复杂，但复杂必须以统一形式出现。
统一性至少体现在：
- 相同职责使用相同层级表达
- 相同错误使用相同错误模型表达
- 相同输入输出使用相同数据模型表达
- 相同配置项使用相同命名规范表达
- 相同模块使用相同目录结构表达
- 相同异步任务使用相同调度接口表达
3.15 示例：RSS 阅读器
对纯人类阅读向 RSS 阅读器，其本体对象不是“RSS 拉取页面”或“首版文章展示功能”，而是：
- 订阅源
- 文章
- 阅读过程
- 阅读状态
- 内容来源
- 内容解析
- 内容呈现
- 内容组织
因此，“多订阅分组、分类、书签、检索、全文缓存、云同步”属于同域延伸；“AI 分析、AI 问答、TTS、社交分享”若改变系统性质，则不应纳入主骨架。
4. 工程蓝图约束
4.1 蓝图要求
任何架构输出都必须向下细化到实现逻辑，不允许停留在概念层。
4.2 最低完备项
一个可施工的工程蓝图至少必须明确以下内容：
- 模块职责
- 调用关系
- 输入输出
- 状态变化
- 错误处理
- 配置入口
- 生命周期
- 扩展点
- 替换点
- 性能关键路径
4.3 判定规则
若一个方案只能说明系统大致分层、模块大致存在、目标大致正确，而不能继续下钻到具体调用逻辑与运行过程，则该方案只构成概念草图，不构成工程蓝图。
4.4 一致性要求
高层骨架、模块边界与实现逻辑之间必须连续。
不允许出现：
- 上层抽象与下层实现脱节
- 实现阶段临时发明破坏骨架的新结构
4.5 示例：RSS 阅读器
对“刷新订阅源”这一流程，工程蓝图必须能回答：
- 输入是什么
- 输出是什么
- 订阅源状态如何变化
- 新增文章数如何计算
- 网络失败、源格式异常、存储失败如何传播
- 抓取间隔、重试次数、超时时间如何进入配置
- 解析器、网络层、存储层分别从哪里替换
- 性能关键路径位于何处
5. 默认分层模型
5.1 四层架构 + 对象层
系统推荐采用“四层架构 + 对象层”的组织方式，并坚持壳核分离。
5.2 第一层：交互壳层
职责集合：
- CLI / GUI / Web 界面
- 动画、样式、按钮、输入控件
- 平台适配
- 用户动作捕获
- 标准指令转译
唯一职责：
转译 + 呈现
5.3 第二层：指令接口层
职责集合：
- 接收标准化指令
- 校验合法性
- 识别状态变化
- 决定需要调用的能力
- 组织返回给交互层的结果结构
其映射关系定义为：
- action → intent
- intent → state delta
- state delta → capability requests
5.4 第三层：流程协调层
职责集合：
- 任务拆分
- 调用顺序规划
- 前后依赖协调
- 状态推进
- 错误回滚或异常中止
- 后方任务分发
第三层不直接接触第五层对象。
5.5 第四层：能力执行层
职责集合：
- 数据计算
- 存储
- 读取
- 网络通信
- 文件系统操作
- 外部系统调用
- 后台处理
- 具体算法执行
5.6 第五层：对象层
对象层不属于骨架分层本身，但必须明确。
其作用是定义系统中实际操作的最小数据元对象。
典型对象形式包括：
.md.pdf.jpgtext::linetext::bytesql::articlesql::feeddata::htmldata::xmldata::opml
5.7 表现变化与业务变化分离规则
界面变化不天然等于业务状态变化。
只有在进入内部指令系统后，系统才判断哪些变化属于业务变化，哪些仅属于表现层变化。
5.8 示例：RSS 阅读器
当用户点击“打开某篇文章”时：
- 第一层只表达“打开文章”
- 第二层判断这是否涉及文章切换、已读状态更新、正文请求等状态变化
- 第三层组织具体流程
- 第四层执行读取、解析、状态写入
- 第五层明确所处理的对象是
sql::article、sql::reading_state、data::html等
6. 一致性约束
6.1 边界封闭原则
一旦骨架划分完成，各层与各模块必须严格遵守职责边界。
任何新增功能都只能通过既定边界接入，不允许跨层直连、跨模块写入或绕过统一入口。
6.2 单一真相源原则
对任何核心对象、核心状态与核心配置，系统必须明确唯一可信来源。
同一事实不得在多个模块、多个缓存层、多个界面状态中并列作为最终依据。
6.3 示例：RSS 阅读器
文章“已读 / 未读”状态只能由统一的阅读状态模型作为真相源。
界面组件可以缓存显示结果，但不得与数据库状态并列为最终依据。
7. 运行可靠性约束
7.1 失败—观测—验证机制
7.1.1 失败优先定义原则
系统设计时，不能只定义成功路径，还必须优先定义失败路径。
任何核心流程在进入实现前，都必须明确：
- 失败条件
- 失败传播方式
- 回退策略
- 重试边界
- 用户可见结果
7.1.2 可观测性内建原则
日志、错误码、状态追踪、关键事件记录与性能指标采集，必须作为架构内建能力进入骨架。
不能依赖事后补日志。
7.1.3 验证先行原则
任何核心骨架、核心流程、核心边界在进入大规模实现前，都必须有对应验证方式。
若一个原则无法被验证，则该原则在实现中极易失效。
7.2 版本与迁移原则
任何核心接口、核心数据模型、核心配置模型一旦变化，都必须回答：
- 旧版本如何兼容
- 现有数据如何迁移
- 失败后如何回退
凡沉淀到磁盘、数据库、缓存、同步链路或导入导出格式中的结构，都负有版本责任。
7.3 幂等与重复执行原则
任何可能被重复触发、重复调用、重复投递、重复恢复执行的核心流程，都必须具备幂等性或显式去重机制。
7.4 并发与时序一致性原则
任何核心状态在被多个流程同时读取、修改、同步或回写时，都必须明确：
- 谁先
- 谁后
- 谁覆盖谁
- 冲突如何解决
7.5 示例：RSS 阅读器
对“刷新订阅源”流程，系统必须同时定义：
- 抓取成功路径
- 网络失败、解析失败、部分写入失败路径
- 关键状态是否可追踪
- 同一文章是否会重复入库
- 已读状态是否会被刷新或同步错误覆盖
- 批量刷新时的性能瓶颈位置
8. 运行裁量约束
8.1 默认保守原则
在信息不足或不确定性较高时，系统默认选择更保守、更稳定、更容易回退的方案，而不是更激进、更复杂、耦合更深的方案。
8.2 退出与删除原则
系统不仅要定义对象如何产生和增长，也必须定义对象如何停用、删除、迁移、失效和清理。
任何可被创建的核心对象，都必须有清晰退出路径。
9. 启动约束
9.1 实现最低原则
系统不得在草案尚未达到最低成熟度之前进入正式动工阶段。
任何实现都必须建立在最低限度分析与骨架确认已经完成的前提下。
9.2 最低成熟条件
进入实现阶段的最低条件是：
- 系统本体已得到基本澄清
- 主骨架与主边界已得到初步确认
- 明显错误方向与异质能力已完成初步排除
- 首版目标与主闭环已明确
- 当前实现不会直接污染未来主干
9.3 探索性实现的限制
探索性验证可以存在，但不得：
- 伪装为正式骨架实现
- 未经收敛直接沉淀为长期主干
10. 纠偏与治理约束
10.1 证伪—纠偏—审批机制
10.1.1 证伪即退出原则
任何方向、能力轴、抽象、边界划分或骨架判断，一旦经分析被认定为错误、失效或已被证伪，就必须立即退出。
不得因沉没成本、既有投入、历史惯性或实现便利而继续占据主骨架。
10.1.2 骨架即时纠偏原则
系统在任何阶段都不承认“骨架一旦形成便不得修正”。
只要管理员 / USER 经分析认定某一方向错误、某一骨架判断被证伪，或某一骨架存在明显不完善漏洞，就必须立即进入骨架纠偏流程。
这里的“立即”定义为：立即启动分析、审查与决策流程，而不是绕过审查直接改动主骨架。
10.1.3 骨架变更审批原则
任何骨架级变更都必须先提交具体分析报告，并由管理员 / USER 阅读后明确批准，方可执行。
未经审批，不得擅自修改：
- 主骨架
- 核心边界
- 核心对象关系
- 主能力轴
- 关键接口结构
骨架变更分析报告至少必须包含：
- 变更原因
- 当前骨架存在的问题或已被证伪之处
- 变更后可获得的收益
- 变更后新增的风险与代价
- 对既有模块、状态模型、数据模型、配置模型的影响
- 是否涉及迁移、兼容、回退与验证
- 若不变更，会持续产生什么后果
10.2 决策复核与反证原则
任何管理员 / USER 的骨架级判断、方向性判断或变更性判断，都不因其审批地位而自动免于复核。
只要存在充分理由认为该判断可能失误、偏颇、证据不足或忽略了关键代价，就必须提交高质量、客观、完整的复核分析报告，对该判断进行反证性审查。
复核分析报告至少必须包含：
- 当前判断成立的依据
- 当前判断可能忽略的问题
- 若维持原判断，可获得的收益
- 若维持原判断，可能承受的风险与代价
- 若修正原判断，可获得的收益
- 若修正原判断，可能引入的新问题
- 当前争议究竟属于实现问题、模块问题、边界问题还是骨架问题
复核的目的不是削弱管理员 / USER 的决策权，而是保证骨架级决策始终接受高质量反证与双面分析，从而持续逼近更高质量的系统判断。
11. 附录约定
11.1 实例附录
正文中仅保留最小必要实例。
更详细的 RSS 阅读器映射说明应移入附录单独维护。