直接回答
Config 是构建 Miniserver 项目的工程环境：房间、功能、输入输出、逻辑、日程与界面都在这里配置。好的组态讲究结构、命名与文档，让另一位工程师能读懂。重点不是逻辑块多巧妙，而是建筑行为可见、可测、可安全修改。
项目是建筑的模型
Config 按房间与功能组织项目，而不是按端子的平铺清单。一个房间包含它的灯、遮阳、空调与传感器；一个功能描述这个房间做什么。这种结构决定了项目以后能不能维护，还是一堆碰巧能跑的块。点位命名要从建筑视角出发，前缀统一，房间与功能层级与点位表对齐。命名一旦漂移，后面的每件事都会变慢：告警、趋势、图形、移交与排障都依赖同一套名字。一个有用的检验是把项目树交给从未到过现场的人，让他在不用搜索的情况下找到三楼会议室。
- 项目树与房间表保持一致
- 从第一天起使用统一命名规范
- 图形与告警沿用同一套名称
分层写逻辑
简单行为放在设备附近：灯跟随开关，阀门跟随房间设定值。跨房间、跨系统的行为放在明确标识的建筑层；报表与优化再往上。分层可以避免一次小房间修改波及整个项目，也让测试可以分片进行。有明确状态的顺序用状态机表达，而不是层层嵌套、只有作者看得懂的条件。每个不直观的逻辑块都写一句注释：做什么、由什么触发、传感器故障时怎样。如果一个逻辑块需要一段话解释，这段话就应放在块旁边的项目注释里，而不是没人会打开的独立文档。
- 设备、房间与建筑逻辑分开
- 多步顺序使用状态机
- 每个不直观的逻辑块都写注释
要测试证据，不要凭感觉
项目不是在 App 看起来正常时就算完成。逐个测试输入，强制传感器故障，检查告警路由，跨日类型验证日程，确认覆盖会自动失效。结果要记录在点位表上，而不是记在某个人脑子里。还要测试故障路径：总线设备掉线、电表不再应答、网络中断时会发生什么。一张简短的测试表比一场长时间演示更有价值，因为它能经受人员更替，也让下一次服务更便宜。也要考虑人的路径：凌晨两点出现告警时，运维知道该做什么吗？这条指引是在移交资料里，还是只在安装商脑子里？
- 按点位表逐项测试输入输出
- 强制故障并记录结果状态
- 验证日程、覆盖与告警路由
移交与变更控制
移交项目文件、软件版本、备份、网络图、点位表与变更记录。项目凭据应由业主掌控，而不是随安装商离开。约定变更如何申请、测试与记录。如果远程访问与权限设计得当，一次日程小改不必到现场。衡量组态好坏的标准不是写了多少逻辑，而是工程师离开后，业主团队能否有信心地运行和修改这栋建筑。一个无法被他人恢复、解释和修改的项目，不算真正移交，只是被通电运行。
- 凭据与授权由业主掌控
- 书面的变更申请与测试流程
- 最终移交前做一次恢复测试
组态分层
5 行| 层 | 包含内容 | 测试证据 |
|---|---|---|
| 设备 | 输入、输出与本地失效安全行为 | 逐点输入输出测试 |
| 房间 | 照明、遮阳、空调与房间场景 | 房间场景与设定值测试 |
| 建筑 | 日程、联动、告警与能源逻辑 | 顺序、告警与故障切换测试 |
| 用户界面 | App 页面、触摸控制与角色视图 | 基于角色的权限与可用性检查 |
| 移交 | 备份、版本、注释与变更记录 | 恢复测试与竣工复核 |
项目图景
3 张图片
常见问题
01Config 算编程还是组态？
两者都是。它是图形环境，但工作本质是工程：结构、逻辑、命名与测试。名称之争不如结果是否可读、可维护重要。
02需要写代码吗？
多数项目用原生功能块完成。特殊顺序可以使用自定义逻辑，但要有文档与理由，因为它提高了后续维护的技术门槛。
03另一家集成商能接手维护吗？
可以，前提是项目文件、命名规范、注释与凭据都妥善移交。这应是合同要求，而不是完工后的情分。
04多久备份一次？
每次变更前后以及移交时都要备份。把副本存放在控制器之外，并测试能否恢复。未测试的备份只是希望。
05App 可以按用户定制吗？
可以。用户页面与权限可以按角色组织，让运维、技术人员与住户看到不同层级的信息和控制项。
下一步
把建筑交给我们。
告诉我们建筑类型、纳入范围的系统，以及你需要的结果。我们会给出通往可用系统的最短路径。