【AI编程】OpenSpec 开发曲线

OpenSpec 开发曲线梳理

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

0. 项目背景

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 tasks
            phase1-foundation、module1-dashboard、module2-monitor、
            module3-data-analysis、module3-data-tools、
            implement-info-module、implement-admin-module、implement-upload-module

2026-03-17  ██                 3 changes / 43 tasks
            report-and-charts-enhance、monitor-area-list、device-auto-control

2026-03-18  ████               3 changes / 84 tasks
            multi-level-permission-system、device-detail-drawer-upgrade、add-chart-publish

2026-03-23  ██                 3 changes / 47 tasks
            db-models-hardware、collector-meter-crud、collection-items-area-binding

2026-03-24  █████              3 changes / 99 tasks
            device-ledger-to-equipment、gateway-data-integration、sys-static-data-management

2026-03-25  █                  2 changes / 27 tasks
            area-manager-conservative-crud、analysis-pages-area-scope

2026-03-26  █                  1 change  / 15 tasks
            per-user-notification-inbox

2026-03-27  █                  1 change  / 18 tasks
            real-alert-engine

2026-03-30  ███                2 changes / 51 tasks
            restructure-navigation、add-profile-center

2026-04-01  █                  1 change  / 24 tasks
            system-operations-overview

2026-04-02  █                  1 change  / 14 tasks
            auth-session-timeout

2026-04-03  █                  1 change  / 24 tasks
            admin-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-navigation：核心是重构系统信息架构和导航壳层，把菜单按业务域重新组织，并收敛采集配置入口和通知面板交互。业务边界是导航结构、布局承载和入口体验，不改变具体业务功能本身。
• 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-navigation：信息架构收口。
  • 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：

Change	已完成	总任务	剩余
device-auto-control	0	16	16
device-ledger-to-equipment	48	58	10
phase1-foundation	55	64	9
gateway-data-integration	22	30	8
admin-light-screen-dark-theme	19	24	5
module3-data-analysis	28	32	4
module3-data-tools	37	41	4
analysis-pages-area-scope	14	16	2
auth-session-timeout	13	14	1

当前尾项的结构很清楚：

• 一类是“设备/采集链路未彻底收口”：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 快速搭出系统全貌，再把重心压到硬件采集与数据链路，随后补齐治理和实时能力，最后进入体验、安全、运维与主题体系的产品化收口阶段。