领域实例
五层统一框架在施工管理和通信工程两个领域的纵向贯穿——从声明式知识资产到 CI/CD 质量左移到可演化验证器套件。
本目录是 统一框架 的领域实例。框架本身是一组抽象的设计决策——它定义了领域知识的类型系统、Agent 运行时、部署形态和演化机制。但框架的正确性不在自洽中验证——在真实领域里、在真金白银的项目现场、在有竞对和事故的压力下。
两个纵向贯穿
施工管理 → CPML / Construction OS。 场-探针-投影框架（知识层）→ aedile Agent 化数字孪生（运行时层）→ 验证器套件演化（演化层）。9.55 亿 EPC 项目现场的实践：将施工活动定义为可计算的时空约束系统，让编译器在开工前发现碰撞和资源争用。让 Agent 维护数字孪生的状态而不是人工同步 Excel。
通信工程 → Engineering as Code (EaC)。 声明式设计 → FS as DB → CI/CD 质量左移。IDC 机房扩容场景的实践：把工程设计蓝图从图纸变成可编译、可版本的声明文件，把协同从"文件锁 + 会审"变成"分支 + PR + 目录所有者"，把质量检查从"出图后有限元"变成"每次提交自动跑 CI"。
两个领域不同——一个处理施工的时空约束，一个处理工程设计的设备拓扑——但它们共享同一套底层逻辑：用可执行的形式化描述替代依赖人肉协同的文档化描述。
| 领域 | 核心问题 | 入口 | |------|---------|------| | 施工管理 | 在不确定环境中按时交付 | 中卫笔记、CPML、Construction OS | | 通信工程 | 多专业协同下的设计一致性 | Engineering as Code |
BIM（建筑信息模型）已经存在了二十年，但它从未真正兑现承诺。模型建好了，躺在服务器里。施工现场仍然靠微信群沟通，进度靠 Excel 追踪，碰撞靠老师傅的经验。
问题不是"数字化程度不够"，而是施工计划从未被定义为一个可计算的问题。
这里记录我在真实 EPC 项目中的实践：如何将施工活动定义为时空约束，如何让编译器在开工前发现碰撞和资源争用，以及 Agent 如何在这个模型中扮演数字孪生的维护者。