TIWAG 数字能源机会图：从智能产品走向可解释的能源服务层

这是一份独立的 TIWAG 机会分析，不是客户案例，也不是审计。它讨论一个具体的产品问题：根据公开可见的数字能源服务，如果 Wavect 为面临类似挑战的能源供应商提供建议，哪些软件、自动化和 AI 机会值得优先验证？

本文只负责回答 TIWAG 这一特定问题。我们的智慧城市架构指南讨论通用 IoT 与数据平台选择，DACH AI 采用率基准讨论区域市场。两篇文章都不声称分析 TIWAG。

为什么 TIWAG 值得进行数字能源分析

TIWAG 2024 年年度报告描述了消费者向产消者的转变，并将去中心化、数字化和新技术整合列为重塑能源行业的力量。这是该公司当时公开表达的观点，不是我们的推断。参见 TIWAG 2024 年年度报告。

当前公开产品更为具体。TIWAG-smart flex 介绍了针对兼容电动车、热泵、光伏系统和电池的动态价格控制，以及一个集中式仪表板。TIWAG-Ökostrom-Community 页面介绍了注册、EDA 市场通信、参与者管理、计费数据和能源流可视化。其公开的客户门户说明还记录了在线办理用电登记和注销的流程。

能源社区的数据运营具有明确复杂性。奥地利官方协调机构说明，能源分配使用 15 分钟读数，而月中可用的数据可能尚未达到计费验证状态。其计量与分配指南区分持续读数和后续清算。设计仪表板、预测和账单时，这一区分十分重要。

哪些是公开事实、合理推断和假设？

因此，真正值得研究的并不是“增加数字化”或“增加 AI”。公开资料已经显示数字服务。更有价值的问题是：是否能在不替换可靠能源市场系统的前提下，通过一致的服务层改善决策、解释和运营。

我们会调查的五项机会

1. 客户能源决策层

商业问题是相互约束下的选择。客户可能同时拥有电价方案、光伏、电池、电动车、热泵和能源社区资格。下一步取决于资格、设备兼容性、预期使用、同意和商业条款。

我们会先梳理一个旅程，例如“该家庭是否适合动态电价与受控充电？”规则引擎检查产品和设备资格，确定性模拟器用清晰假设比较方案。AI 可以把结果解释成易懂语言，或通过对话收集缺失信息，但不能编造价格、资格或节省金额。

• 所需数据：产品目录、兼容规则、已获同意的分时数据或用户输入画像、设备约束与合同上下文。
• 人工角色：产品与合规负责人批准规则和措辞，客服处理模糊案例。
• 低成本测试：先用合成画像构建可点击原型和场景引擎，再考虑账户集成。

2. 可解释设备编排

优化不仅是排程问题，也是信任问题。用户需要知道系统是否遵守出发时间、舒适度、电池储备、光伏预测和价格约束。优化器可以使用规则、线性规划或模型预测控制。生成式 AI 不应处于控制回路中。

一种方案是为每次排程保存输入、约束、所选动作与反事实。界面可以解释：“02:00 开始充电，因为车辆在 07:00 前需要 32 kWh，这是成本最低的可行窗口。”AI 可以把结构化原因转成自然语言，但底层解释必须来自确定性证据。

• 所需数据：设备状态、用户约束、价格序列、已同意使用的预测和指令结果。
• 人工角色：客户保留手动覆盖，运营人员查看失败指令和异常状态。
• 低成本测试：对小规模自愿用户运行影子建议，不发送实际设备指令。

3. 面向能源社区的异常优先运营台

能源社区运营包含 onboarding、市场通信、电表读数、分配、文档、计费和参与者问题。我们不声称了解 TIWAG 当前如何完成这些工作。对于类似服务，我们会调查共享工作台能否让状态和异常更易管理。

确定性工作流应掌握参与者状态、期限、计量点验证、数据版本、清算状态和计费资格。AI 适合边缘任务：文档分类、提取字段供人工确认、聚类相似请求，或根据已批准指南起草回复。它不应决定计量点是否有效，也不应决定账单是否最终生效。

• 所需数据：流程事件、EDA 回执、数据质量状态、文档类型和处理结果。
• 人工角色：运营人员确认提取字段，并处理有财务或合同影响的异常。
• 低成本测试：重放匿名或合成案例，测量分类准确率、处理步骤和升级质量。

4. 基于已批准来源的服务助手

“增加聊天机器人”不是策略。有效助手解决更窄的问题：从电价、设备、门户步骤和能源社区流程中找到当前批准答案，显示来源，并为客服起草下一条回复。账户变更仍由经过身份验证的确定性工具执行，并要求确认。

检索索引应包含有版本的产品说明、流程指引、兼容列表和服务知识。每个回答都带来源、生效日期和置信信息。来源冲突或问题依赖账户状态时，助手应停止并转交人工。

• 所需数据：已批准知识、版本历史、匿名问题分类和纠正反馈。
• 人工角色：客服审核草稿，内容负责人移除过期来源并分析纠正。
• 低成本测试：先对 50 到 100 个代表性脱敏问题做离线评估。

5. 数字能源产品实验层

公开页面显示了多个产品界面，但公开信息无法说明内部如何衡量表现。我们会调查一个保护隐私的事件模型，将解释或 onboarding 变化与可观察结果连接起来。目标不是监视，而是判断某项产品假设是否帮助客户完成有价值的任务。

事件应描述旅程，而不是暴露原始家庭行为。例如：资格检查完成、解释已打开、手动覆盖使用、文档按原因被拒、转交客服、成功恢复。产品团队比较版本，安全、隐私和无障碍负责人定义采集边界。

一种可能的技术架构

以下架构仅用于说明，不是对 TIWAG 内部环境的描述。

新增服务层不应强制全面替换。我们更倾向于在现有合同周围建立窄适配器，并选择可独立回滚的首个旅程。这也是 Wavect 定制软件开发、生产级 AI 工程与 IoT 工程所采用的产品纪律：控制路径明确，证据可观察，只有当不确定性是真正问题时才使用 AI。

如何在 30、60 和 90 天验证假设

对于高影响流程，90 天可能只能支持一个信息更充分的下一步决策。这同样是有效结果。如果数据访问、用户价值、运营责任或经济性不支持生产，试点就应停止。

潜在商业影响，不虚构 ROI

从外部无法计算 TIWAG 特定的节省、收入或回收期。可信商业案例必须使用内部基线并公开假设。我们会衡量机制，而不是给出虚构百分比：

• 客户价值：知情完成、自动化保留、自助成功、无障碍与信任。
• 运营价值：直通处理、异常量、解决时间、纠正率与重复联系。
• 产品价值：资格到激活的转化、退出、功能采用与各旅程支持需求。
• 技术价值：指令成功、数据新鲜度、重放成功、模型引用准确率、延迟与每项完成任务成本。
• 风险控制：被阻止的未授权动作、被抑制的过期来源答复、人工覆盖和回滚时间。

内部还需要哪些信息？

在建议实施前，我们需要真实业务目标、旅程分析、系统所有权、接口合同、数据质量历史、同意模型、安全要求、监管解释、无障碍需求、供应商限制、服务量、错误成本和负责的产品负责人。缺少这些信息时，架构与经济性仍只是待验证假设。

Wavect 的相关经验也必须与 TIWAG 分开表述。我们的 IKB IoT 案例证明了在连接基础设施领域的相邻经验，但不意味着相同架构或结果适用于本文情境。软件 discovery 指南说明如何在投入开发前，把机会图转成经过验证的范围。