OpenSpec开发曲线：AI编程实战解析

OpenSpec 开发曲线梳理

统计口径：基于 openspec list --json、各 change 的 .openspec.yaml created 字段、tasks.md 完成度，统计时间点为 2026-04-03。当前 openspec/changes/archive 为空，因此本次曲线基于现有 29 个 change。

咱们先聊聊项目背景。ECMS 是个建筑能耗管理系统，干的不是单纯的数据展示——说白了，它是围绕建筑的水、电等能源消耗，从采集、监控、分析、告警到运营管理，搭一整套闭环。目标是把能耗数据做成“可看、可查、可管、可控”的系统，支撑日常监管、节能分析、异常发现、设备台账和业务上报。

从当前 OpenSpec 和设计文档来看，项目核心业务可以归纳为6条主线：

1. 能耗总览与可视化大屏：Dashboard 展示总能耗、分类能耗、碳排放、趋势和排名。
2. 实时监控与区域查看：看各建筑、区域、设备的实时能耗、日曲线和区域详情。
3. 数据分析与报表：历史趋势、同环比、指标分析、排名分析、报表导出和图表发布。
4. 采集与设备基础配置：管理采集器、计量器、采集项、区域绑定、网关接入、设备台账等。
5. 告警、通知与系统运营：实时告警、通知中心、运维总览、静态数据维护等。
6. 用户、权限与安全治理：登录认证、后台管理、用户组、区域权限、个人中心、会话超时控制。

所以说，这条 OpenSpec 开发曲线反映的不是一个普通后台页面的开发顺序，而是一个“建筑能耗数字化运营平台”从底座搭建，到数据链路打通，再到治理和产品化收口的演进过程。

1. 总览

• change 总数：29
• 已完成 change：20
• 进行中 change：9
• 任务总数：792
• 已完成任务：733
• 总体完成率：92.6%

整体看，开发曲线不是均匀推进，而是明显的四段式：

1. 2026-03-16 到 2026-03-18：高强度搭底座，同时把核心业务模块一起铺开。
2. 2026-03-23 到 2026-03-25：围绕硬件采集、设备建模、区域作用域继续扩面。
3. 2026-03-26 到 2026-03-27：进入系统治理与实时能力补强。
4. 2026-03-30 到 2026-04-03：转入体验收口、运维可视化和安全细化。

2. 时间轴曲线

说明：下图按“change 创建当天所承载的任务规模”估算，█ 越多表示当日开启的开发面越大。

2026-03-16█████████████████8 changes / 346 tasksphase1-foundation、module1-dashboard、module2-monitor、module3-data-analysis、module3-data-tools、implement-info-module、implement-admin-module、implement-upload-module2026-03-17██ 3 changes / 43 tasksreport-and-charts-enhance、monitor-area-list、device-auto-control2026-03-18████ 3 changes / 84 tasksmulti-level-permission-system、device-detail-drawer-upgrade、add-chart-publish2026-03-23██ 3 changes / 47 tasksdb-models-hardware、collector-meter-crud、collection-items-area-binding2026-03-24█████3 changes / 99 tasksdevice-ledger-to-equipment、gateway-data-integration、sys-static-data-management2026-03-25█2 changes / 27 tasksarea-manager-conservative-crud、analysis-pages-area-scope2026-03-26█1 change/ 15 tasksper-user-notification-inbox2026-03-27█1 change/ 18 tasksreal-alert-engine2026-03-30███2 changes / 51 tasksrestructure-na vigation、add-profile-center2026-04-01█1 change/ 24 taskssystem-operations-overview2026-04-02█1 change/ 14 tasksauth-session-timeout2026-04-03█1 change/ 24 tasksadmin-light-screen-dark-theme

3. 各 Change 业务说明（按时间顺序）

2026-03-16

• phase1-foundation：核心是搭建 ECMS 的基础工程底座——前后端脚手架、数据库迁移、认证、模拟数据和部署能力。它的业务边界是“提供所有后续模块共用的基础设施”，不负责具体业务模块的完整功能实现。
• module1-dashboard：建设能耗总览大屏，面向驾驶舱场景展示总能耗、分类能耗、趋势和告警。边界很明确：Dashboard 单独这条大屏展示链路，不覆盖实时监控、分析中心或后台管理。
• module2-monitor：实时监控业务——分类实时能耗、日曲线和区域详情。边界是“看当前和当日”的监控场景，不延伸到深度历史分析、报表和告警引擎。
• module3-data-analysis：数据中心里的分析型页面——同环比、历史查询、指标分析和能耗排名。边界是分析查询与图形展示，不包含报表导出、报警处置和操作型工具。
• module3-data-tools：数据中心里的工具型业务——功率跟踪、节能管理、报表和报警管理。边界是分析工具和操作工具，不负责总览大屏或实时监控主流程。
• implement-info-module：信息发布模块及其周边业务——通知中心、设备台账、维护记录、设备能耗和计费管理。边界是“信息发布与设备信息管理”这一业务域，不负责硬件采集层配置和系统权限体系。
• implement-admin-module：综合管理域——建筑、区域、费率、用户、角色权限和操作日志。边界是后台主数据和组织权限管理，不覆盖采集器/计量器等硬件采集配置。
• implement-upload-module：数据上传模块——上报任务、上报日志、全局对接配置和定时调度。边界是对外上报链路和上传运行状态，不覆盖站内分析或监控展示。

2026-03-17

• report-and-charts-enhance：补齐报表定制和图形种类，确保报表和分析页面满足验收对“多种图形展示”的要求。边界是对现有报表和分析页做增强，不引入新的业务域。
• monitor-area-list：为实时监控补区域列表入口，让实时曲线具备自动刷新。边界是监控模块内的入口补齐和体验增强，不改变监控数据模型。
• device-auto-control：让节能策略从“静态配置”升级为“可执行的自动控制规则”，形成设备自动化控制闭环。边界是基于时间规则的设备控制和执行日志，不扩展为更大的运维编排系统。

2026-03-18

• multi-level-permission-system：建立真正生效的数据权限体系——按用户/用户组、区域、用能类别控制可见范围。边界是数据访问控制，不处理登录会话安全或认证超时问题。
• device-detail-drawer-upgrade：把设备基本信息、说明书、维护记录、运行记录和能耗图表收敛为统一设备档案视图。边界是设备详情体验与资料归档，不改变设备台账底层建模。
• add-chart-publish：新增“图表发布”业务，能耗信息可以带趋势图、饼图、柱状图一起按渠道发布。边界是发布任务编排和预览发送，不负责真实信息/邮件网关打通。

2026-03-23

• db-models-hardware：建立硬件采集升级所需的数据模型——采集器、计量器、采集项、采集映射和区域绑定等表结构。边界是数据库和 ORM 基础层，不直接提供前端页面或业务流程。
• collector-meter-crud：交付采集器和计量器的完整配置管理能力。边界是硬件设备主档 CRUD 与测试连接，不包含采集项映射和真实数据接入。
• collection-items-area-binding：补齐采集配置链路最后一环——采集项定义、寄存器映射和区域绑定。边界是配置关系建立，不负责把网关真实数据接入业务查询。

2026-03-24

• device-ledger-to-equipment：把旧 devices 升级为统一 equipment 台账总账，并与采集器、计量器自动联动。边界是设备台账口径统一和跨模块联动，不负责真实能耗数据查询替换。
• gateway-data-integration：把 Dashboard、监控、分析等能耗查询从模拟数据切换到网关 MySQL 真实数据。边界是“读侧数据源替换与聚合编排”，不涉及对网关反向写入或硬件控制。
• sys-static-data-management：把监测库里的 sys_static_data 纳入系统内管理。边界是静态字典数据的查询和维护，不改动底层字典表设计。

2026-03-25

• area-manager-conservative-crud：把新区域配置页补到“可实际维护”的状态——支持默认选中、默认展开以及新增/编辑/删除。边界是保守 CRUD，不引入拖拽排序、复杂字段编辑或级联删除等高级能力。
• analysis-pages-area-scope：让同环比分析和指标分析具备建筑/区域作用域切换能力。边界只覆盖这两个分析页面及其接口过滤，不改造整个数据中心所有页面。

2026-03-26

• per-user-notification-inbox：把通知系统改造成“按用户收件箱”模型——每个用户有自己的已读/未读状态和未读数。边界是通知内容、受众展开和回执模型，不扩展到复杂审批流或外部消息系统。

2026-03-27

• real-alert-engine：补齐告警规则自动评估引擎——基于网关真实数据触发报警并推送站内通知。边界是“规则评估到报警生成”的闭环，不包含完整工单化处置体系。

2026-03-30

• restructure-na vigation：重构系统信息架构和导航壳层——菜单按业务域重新组织，并收敛采集配置入口和通知面板交互。边界是导航结构、布局承载和入口体验，不改变具体业务功能本身。
• add-profile-center：新增个人中心——补齐个人信息维护、密码修改和登录历史查询。边界是用户自服务能力，不涉及管理员视角的用户组织管理。

2026-04-01

• system-operations-overview：新增管理侧系统运营总览——集中看资源总量、状态分布、异常提醒和跳转钻取。边界是“系统运营驾驶舱”，它不是建筑能耗大屏，也不是具体资源管理页的替代品。

2026-04-02

• auth-session-timeout：补齐服务端会话生命周期管理——空闲超时、绝对超时、会话撤销和多标签页一致性。边界是认证会话安全与体验，不改变角色权限和数据权限模型。

2026-04-03

• admin-light-screen-dark-theme：建立“后台浅色 + 大屏深色”的双主题体系——统一布局、组件和图表主题来源。边界是视觉主题和承载方式治理，不引入新的业务能力或接口。

4. 阶段判断

第一阶段：平台底座 + 六大模块并行起盘（2026-03-16 到 2026-03-18）

• 3 天内启动 14 个 change，规划 473 个任务——属于典型的“先把系统骨架和主业务面全部撑起来”。
• 核心特征不是逐模块串行，而是“底座 + Dashboard + 监控 + 数据分析 + 数据工具 + 信息发布 + 后台管理 + 上传模块”并行推进。
• 这说明当时的主策略是先快速建立可运行全貌，再通过后续 change 分段修正细节。

第二阶段：采集链路和设备域深化（2026-03-23 到 2026-03-25）

• 8 个 change，规划 173 个任务——重点集中在硬件模型、采集器/计量器、区域绑定、台账升级、网关接入和分析范围控制。
• 这是从“页面功能已可跑”转向“数据来源是否真实贯通”的阶段。
• 3 月 24 日是这一段的峰值日——device-ledger-to-equipment 和 gateway-data-integration 两个 change 说明系统开始从业务展示层回压到底层设备数据链路。

第三阶段：治理与实时能力补齐（2026-03-26 到 2026-03-27）

• 节奏变窄，但方向更深——单用户通知收件箱、实时告警引擎。
• 这一段的变化是从“功能可用”走向“系统可运营、可感知、可闭环”。

第四阶段：体验收口 + 安全/运维增强（2026-03-30 到 2026-04-03）

• 5 个 change，规划 113 个任务。
• 重点已不是扩展主业务版图，而是对现有系统做结构整理和体验治理——
  • restructure-na vigation：信息架构收口。
  • add-profile-center：用户自服务能力补齐。
  • system-operations-overview：系统运行可视化。
  • auth-session-timeout：认证会话安全治理。
  • admin-light-screen-dark-theme：前端主题体系化。
• 这代表开发曲线已经从“功能建设期”进入“产品化与可维护性强化期”。

5. 这条曲线的几个拐点

拐点一：2026-03-16

不是从单点功能试水，而是直接把一期底座和主要模块一起立起来——前期爆发力很强。

拐点二：2026-03-24

开发重心从页面和模块，明显下沉到设备台账、网关接入、静态数据治理——系统开始处理“真实数据链路”问题。

拐点三：2026-03-30

导航、个人中心、运维总览、会话安全、双主题陆续进入——标志着项目从“做出来”转向“用起来更稳、更顺、更可运营”。

6. 当前剩余坡度

截至 2026-04-03，未完成任务共 59 个，主要集中在 9 个 change：

当前尾项的结构很清楚：

• 一类是“设备/采集链路未彻底收口”：device-auto-control、device-ledger-to-equipment、gateway-data-integration
• 一类是“早期大 change 的验证和扫尾”：phase1-foundation、module3-data-analysis、module3-data-tools
• 一类是“近期治理型 change 的最后一公里”：auth-session-timeout、admin-light-screen-dark-theme、analysis-pages-area-scope

7. 一句话结论

OpenSpec 的开发曲线呈现出非常清晰的路径：先用大规模并行 change 快速搭出系统全貌，再把重心压到硬件采集与数据链路，随后补齐治理和实时能力，最后进入体验、安全、运维与主题体系的产品化收口阶段。