运维 Copilot
查询设备、计量、环境与告警数据，回答中标明数据来源和时间范围。
先确认业务与数据条件
数据在系统里，判断仍散落在人和页面之间
真正的难点通常不是模型能不能回答，而是设备数据、业务口径、权限和现场动作能否形成安全、可追溯的链路。
设备状态、计量、告警和工单分散，回答一个问题要跨多个系统查找
报告依赖个人经验，口径、时间范围和数据来源难以复核
EMS、IoT、边缘侧与运营后台各自演进，跨系统影响难判断
远程操作、参数调整或升级风险高，缺少明确授权与回滚路径
已经有 AI 原型，但没有接入真实数据和生产责任人
异常诊断可以辅助，但最终处置必须有人工接管和操作留痕
从真实系统开始
让 AI 成为生产系统的一部分，而不是旁边的演示层
先建立数据与工具边界，再用真实样本验证。高风险动作长期保留人工确认，所有输出和变更都能追溯。
数据问答与报告
把跨页面查询组合成结构化分析，并将结果写回现有运营系统。
故障诊断辅助
基于批准的数据和规则给出判断依据；证据不足时停止并交给人。
Agent Workflow
连接工单、审批和报告流程，低风险步骤受控执行，关键动作人工确认。
EMS / IoT 集成
从现有 API、消息与数据模型进入，不为使用 AI 强行替换成熟系统。
边缘与 OTA 治理
把协议、版本、分批升级、授权、审计和回滚一起纳入架构判断。
低风险入口
AI Agent 生产就绪审查与路线图
围绕一个明确业务问题，审查现有数据、系统边界、关键动作与生产风险。它共用 AgentKick 的生产就绪审查方法，但不会预设最后一定要做 Agent。
- 时间
- 按范围确认
- 商务方式
- 按业务范围报价
固定交付物
- 业务问题、责任人和可验收结果
- 现有 EMS / IoT / 数据访问路径
- 权限、人工接管、审计与回滚边界
- P0 / P1 / P2 风险清单
- 分阶段生产路线图与投入判断
- 一次最终 Review 会议
范围确认后按业务范围报价。审查结束后，再决定是否进入建设或持续顾问合作。
讨论能源 / 工业场景个人项目经历（已授权公开）
新能源与工业物联网：可公开的经历与能力边界
以下是 Sam 的个人项目经历，公司与具体项目名称不公开。经历用于说明工程能力，不代表这些项目均为 AgentKick 承接的客户委托。
新能源运营数据 Agent
Sam 的项目经历包括新能源运营数据 AI 对话与报告系统：在既有平台 API 上连接设备、发电量、告警等查询，回答标明数据来源与时间范围，复杂分析生成结构化报告。
新能源运营管理平台
Sam 的项目经历包括新能源运营管理平台：连接监控、计费、设备接入、报表、工作流与移动端，统一多服务构建、开发到生产的部署流程和跨服务架构文档。
设备自研固件、多协议与 OTA
Sam 的项目经历包括设备自研固件与 OTA 运维平台：基于 Linux 的边缘固件可部署到网关及适配的客户硬件，协议支持经历包括 Modbus RTU/TCP、IEC 60870-5-104、SunSpec、DLMS/COSEM、DL/T 645/698、M-Bus、CAN BMS / J1939；支持设备识别、数据模型统一、签名升级、分批发布、回滚及远程运维。
完整物联网平台：设备、边缘与云端
Sam 的项目经历包括完整的新能源物联网平台：从现场设备采集、自研采集固件和多协议接入，到云端数据接收、时序存储、多租户权限、监控告警、工单和移动端运维，覆盖设备侧、边缘侧与云端业务平台。
经验不等于无限自治
个人经历帮助理解设备与运行约束，但生产级 AI Agent 仍需单独定义权限与验收边界。每个生产 Agent 都应写清六类运行边界：业务结果与负责人、允许处理的数据与知识、允许调用的工具与动作、验收样本、评测与质量门槛、人工确认与升级路径、审计、预算、降级、回滚与持续运营。高风险工作可以长期保留人工确认。
交付物支持内部接手
标准交付构成包括生产代码、测试、文档、验收方法和运行边界，目标是方便客户内部团队接手； 这不构成对任何特定项目结果、服务等级或接手效果的承诺。
以一份运营周报为例
先判断怎样做，再判断由谁交付
同样是减少手工查数，有时补一张报表就够了，有时需要跨系统组织查询。下面三种情况，是讨论建设范围时的起点。
字段和版式固定
每周查同一批字段，按固定规则汇总。先评估现有报表、定时查询或脚本；需要的是可靠的数据与计算，不一定需要 Agent。
已有平台，团队能维护
接口、权限和流程已经清楚，内部有人负责开发与运行。可以先在现有平台验证一段查询，把失败处理和检查样本一起留下。
跨系统查询，结果还要解释
提问会变化，数据来自多个系统，报告需要说明来源、缺项和后续处理。先审查这段工作的接口、口径和责任，再决定 Agent 与确定性计算各做什么。
拿到报告后，可以怎样核对
以下为公开模拟样例：三处虚拟站点，统计周期为 2026 年 8 月 24 日至 30 日，按北京时间记录。 数据与预期结果用于说明核对方法，不是客户数据、真实系统截图或效率测试。下方另附一次实际模型生成记录；输入仍是这三组模拟数据，没有连接电站。
三站数据齐全
30,000 kWh
12,000 + 10,000 + 8,000。三站均为同一周、同一单位；报告保留各站来源记录。
核对方法：核对三个组成项、统计周期与合计。
C 站未返回
已到数据合计 22,000 kWh
只计算 A、B 两站。C 站标记待补，不能填成零，也不能将当前数值写成三站完整合计。
核对方法：缺项提示与部分合计同时保留，补齐后重新生成。
C 站返回上一周的数据
先核对周期
虽然收到一个数，但它不属于本周。先列出周期冲突，重新查询或交给负责人，不能直接加进本周合计。
核对方法：收到数据不等于数据可用；周期不符时不交付完整合计。
模型实际输出了什么，也可以自己复核
2026 年 9 月 7 日，我们将三组输入分别交给 glm-5.3-flash，保留了完整提示和未经改写的原始输出。人工预期没有发送给模型；独立脚本根据输入重新计算，核对覆盖站点、统计周期、合计与来源记录。
- 数据齐全：返回三站完整合计 30,000 kWh，保留三个来源。
- C 站缺数：返回已到数据合计 22,000 kWh，完整合计留空，明确缺 C 站。
- C 站跨周：排除上一周记录，完整合计留空，列出周期冲突。
三个样本的上述结构化字段均通过核对。这是报告输出的有限示例，不能据此推算总体准确率或生产效果。它没有测试工具选择和自主执行；正式系统的数值计算应交给确定性代码，模型负责组织查询与解释。
照着四步，验收你手上的报告
先写请求范围
设备或电站名单、统计起止时间、时区与单位一起写清。数值相同但覆盖范围不同，也不能当作同一份结果。
逐项对照来源
把报告的组成项对应到数据记录，记下查询时间和数据版本，再核算合计。先核数字，再看解释。
检查缺项和冲突
没有返回、无权查看、记录确实为零是不同情况。缺数时报告实际覆盖范围；周期或口径冲突时先核对。
记录结论与复测
写明能接受什么、还缺什么、谁补齐。数据修正后保留旧版本，用同一范围重新生成和核对。
验收记录包括请求范围、实际覆盖、来源、可报告数值、限制、禁止结论、负责人和记录时间。模板已经填入上面三种模拟情况；实际运行结果与验收签字留空，供你用自己的授权材料检查。
下载三种验收示例与空白模板Sam 做过的相关工作
在个人参与建设的新能源运营数据系统中，Sam 将 AI 对话接入既有平台 API，查询设备、发电量和告警，并给回答附上来源与时间范围，复杂分析生成结构化报告。此经历与上面的模拟样例分别说明。
阅读个人项目经历与关键实现讨论合作前，先准备三份材料
- 一份去掉公司与人员信息的周报样本，标出最费时间的一段。
- 这一段用到的系统、字段与统计口径，说明当前能否通过接口查询。
- 谁核对结果、缺数时找谁，以及上线后由谁接手维护。
AgentKick 的首次合作是 AI Agent 生产就绪审查与路线图：确认可做范围、主要问题和下一阶段路线。建设前再明确接口变更、交接材料与维护责任；报价依据确认后的范围。
先把边界讲清楚
关于能源与工业 AI 的常见问题
这里集中回答交付对象、适用场景、上线控制和合作起点。展开问题即可查看完整边界。