提示工程重构智能电表数据标注：从规则引擎到大模型驱动的标注管线实践

智能电表数据标注这活儿，干过的人都知道，是体力活和技术活的混合体。每天面对成百上千条用电负荷曲线，用肉眼找异常、划峰谷、标停电，标到后面眼睛发花，鼠标手都快磨出茧子。传统规则引擎倒是快，但写规则的人永远追不上现场工况的变化。直到我把提示工程（Prompt Engineering）这套方法搬进标注管线，效率才真正上了一个量级——不是省了10%人力那种，而是把标注周期从“天”压缩到“小时”，同时一致性比纯人工标注更高。这篇文章我就把这套思路完整拆开：怎么设计标注Prompt、怎么构造示例库、怎么解决模型幻觉和边界漂移，踩过的坑也一并交代清楚。

先交代背景。我负责某电网数据服务项目里的智能电表数据分析模块，核心任务之一就是把各地台区采集上来的电表量测数据“翻译”成业务可用的标签。这些标签是下游电价策略、配网规划、窃电稽查、设备健康管理的数据底座，质量直接决定分析结论靠不靠谱。而标注本身恰恰是整个链路里最耗时、最枯燥、最容易被低估的环节。本文适合正在做数据标注工具链、做电力数据分析、或者想用Prompt替代规则引擎的工程师参考，我会把设计思路和可直接抄走的模板都放出来。

1. 智能电表数据标注的痛点，比表面看到的更严重

1.1 电表数据标注到底在标什么

很多人以为电表数据标注就是给曲线打个标签“正常”或“异常”，真上手你会发现业务远比这个复杂。智能电表以15分钟或30分钟为间隔采集负荷、电压、电流、电量等量测值，一天一台表就是96条或48条记录。标注工作落在几个层面：最基础的是负荷事件标注，要把一段负荷曲线划分出峰、平、谷时段，标记尖峰负荷出现的时刻区间；再往上是异常模式标注，包括数据缺失、电压暂降、功率突增突降、振荡波动，以及疑似窃电特征；还有设备状态标注，判断电表处于运行、停运、故障还是通信中断状态。

这些任务看似都是“看图说话”，但难就难在判定标准有极强的业务背景。比如峰谷时段，不同地区分时电价政策不同，有的按固定时钟一刀切，有的要根据实际负荷曲线动态划分；再比如窃电疑似特征，可能是用户负荷长期平稳但某天突降，也可能表现为电压异常偏低、电流却不成比例，这些模式在现场数据里千差万别。标注结果直接进分析模型，错了就是“垃圾进垃圾出”。

1.2 规则引擎和人工标注为什么都不够用

传统做法无非两条路。一条靠熟手标注员人工看图打标签，优点是能处理模糊场景，缺点也同样明显：效率太低，一个人一天高强度情况下能标300到500条已经到极限；而且人与人之间判定标准不一致，同一条曲线不同人标的峰谷边界经常错开半个多小时，多人协作后标签体系直接乱掉。另一条靠规则引擎硬编码阈值，比如“功率超过6千瓦且持续15分钟判为尖峰”。规则跑起来确实快，但问题是不同台区、不同季节、不同天气条件下负荷基线差异非常大，一条规则在A台区成立，搬到B台区就完全失真，规则越加越多，维护成本指数上升。

我实际统计过项目里一个标注小组的产能：八个人全职标注，一个月勉强处理完两个台区一个月的数据量，而现场待标注的台区有几十个。规则引擎倒是能覆盖常规场景，但一遇到“大风天光伏出力波动导致负荷振荡”“春节工厂停工造成负荷断崖下降”这类新场景，就得开发临时规则，等规则写好，现场工况又变了。这就是我转向提示工程的根本原因：需要一种能用自然语言描述规则、能快速适配新场景、又能批量执行的方案。

1.3 Prompt介入的切入点：能做什么、不能做什么

把大模型引入标注流程，我的定位很明确：不是让模型“创造”业务规则，而是让模型当一个“能读懂自然语言规则的高效标注执行器”。传统规则引擎把业务知识写成if-else，Prompt则把业务知识写成自然语言指令，配合少样本示例让模型理解判定标准。规则改起来不用动代码，改Prompt文本就行，几天的工作量压缩到几分钟。

但我也要泼盆冷水：提示工程不是万能的。模型对绝对数值的感知能力弱，你给它一串功率数值让它“感觉一下这是不是异常”，它大概率靠猜；模型也没有时间戳的绝对概念，容易把事件边界标记得“差不多”。所以这套方案能成立的前提，是你要用合适的特征化方式把数据喂给模型，并在输出端加上强校验。这后面我详细展开。

2. 提示工程标定管线的整体架构设计

2.1 五段式管线：别拿原始数据直接问模型

最早做验证实验时，我图省事，直接把一段96点功率序列加上时间戳丢给大模型，问“这段数据有什么异常”。结果模型给出了一大段模棱两可的废话，偶尔能蒙对异常类型，但位置和边界都不准确，完全没法落地。这个失败经历让我意识到一个关键问题：原始数值序列对大模型来说只是一串没有语义的数字，而标注需要的是结构化业务判断。后来我把整个流程重新设计成五段式管线，才真正跑通。

数据接入 → 窗口切分与特征化 → Prompt构造 → 模型标注 → 校验与回填

数据接入层负责从数据库拉取量测记录，清洗缺失值和重复点，按台区和电表维度组织数据。窗口切分与特征化是最核心的一步，决定模型看到的输入长什么样。Prompt构造层把特征化文本、业务规则、少样本示例组装成完整请求。模型标注层负责调用大模型API并处理返回结果。校验与回填层做最后的把关，检查标签合法性和边界一致性，通过后才写入标注结果表。每一层都能独立测试和替换，这为后续排查问题打下了很好的基础。

2.2 序列特征化：如何让大模型看懂几百个数值点

特征化是我整个方案里投入产出比最高的一步，也是最容易被新手忽略的一步。智能电表一天的数据量是96个点（15分钟间隔），一个台区几百台表，如果全部以原始序列传给模型，token开销先不说，关键是模型对数值序列的敏感度极低，给它“2.3, 2.5, 2.1, 2.8...”这样的数字流，它很难理解这是负荷上升还是波动噪声。

我验证下来最有效的做法是把窗口数据转化为统计特征描述文本。对每个分析窗口，计算并生成以下字段：窗口起止时间、采样点数、均值、峰值及出现时刻、谷值及出现时刻、标准差、最大单步变化率及方向、高位持续时间（如超过均值1.5倍的总时长）、低位持续时间、波动次数（功率反复穿越均值区间的次数）。特征化之后的一段输入长这样：

窗口：2024-06-03 00:00 至 2024-06-04 00:00，采集间隔15分钟，共96点 全窗均值：2.3kW，峰值：8.7kW（出现于08:45），谷值：0.4kW（出现于03:30） 标准差：1.6kW，最大单步变化率：3.2kW/15min（08:30-08:45，方向上升） 高位时段：08:00-11:30持续在6.0kW以上，共3.5小时 波动特征：全天功率穿越均值为8次，夜间（23:00-05:00）平稳无波动

这样的文本描述对模型来说，信息密度和可读性都比原始数字序列高太多。它本质上是在“用业务语言描述统计特征”，模型可以直接拿这些特征去做模式识别。token消耗也大幅降低，一天96点原始序列可能需要600到800 token，特征化描述只要150到250 token。在做这件事的过程中我最大的体会是：Prompt工程师的价值不在于把Prompt写得多花哨，而在于知道模型擅长理解什么、不擅长理解什么，在输入端就把脏活累活干完。

2.3 少样本示例库：用边界案例喂出稳定输出

只有指令没有示例的Prompt，模型输出会飘。这个结论我在多个模型上反复验证过：纯指令模式下，同一段数据重复问两次，峰谷划分结果能差出一个小时。加入少样本示例后，输出稳定性明显改善。我把示例库逻辑设计成按任务类型管理，每个任务准备6到10个示例，覆盖三类情况：典型正常模式、典型异常模式、边界模糊模式。

示例不是随便找几条数据凑数。每个示例都要包含完整的特征化描述、标注结果和简短判定理由。特别重要的是边界案例，比如一条曲线在平段和峰段交界处功率逐渐爬升没有明显拐点，这种数据最容易让模型犯迷糊，但恰恰是实际标注中最常见的。我甚至会把“容易混淆的正反例”做成对比式示例，明确告诉模型“这个情况为什么是平段而不是峰段”。示例库跟随Prompt一起做版本管理，业务规则调整时同步更新示例，比维护代码规则库清爽得多。

3. 三类核心标注任务的Prompt模板与参数调优

3.1 峰谷时段划分：把“动态规则”讲给模型听

峰谷时段划分标注分两种场景：一种按固定时段规则划分，这个用代码处理就好，没必要让模型参与；真正需要Prompt介入的是按实际负荷曲线动态划分的场景，比如工业用户双班制、商场节假日负荷模式变化，这些动态特征用固定规则根本无法覆盖。模型需要做的事情是：根据负荷曲线特征，把一天切分成若干个“峰”“平”“谷”区间。

我设计的系统提示长这样：

你是一位电力负荷分析专家，负责根据台区负荷曲线的统计特征，将一天划分为峰、平、谷三种时段。 峰段特征：功率明显高于当日均值，通常超过均值1.3倍，持续时间不少于1小时； 平段特征：功率围绕日均值上下波动，无明显持续高位或低位； 谷段特征：功率明显低于当日均值，通常低于均值0.7倍，持续时间不少于1小时。 输出要求：返回一个JSON数组，每个元素包含开始时间、结束时间和时段类型。 必须覆盖全天24小时，相邻区间时间上连续，不允许重叠。

需要特别强调“连续覆盖全天”，否则模型常会跳过凌晨和深夜这种“没有特征”的时段。Few-shot示例里我会固定给一条完整的输出格式示例。实际使用中，单条窗口请求返回的JSON解析成功率在95%以上，失败的多半是模型把时间格式写错或类型枚举值拼错，这个靠后置校验兜底。

3.2 异常模式标注：置信度与证据字段缺一不可

异常模式标注是直接服务于窃电稽查和设备运维的任务，输出质量要求比峰谷划分更高。我在Prompt里规定了严格的输出结构，每一项异常必须包含异常类型、发生时间区间、置信度（0到1）和证据描述。置信度和证据字段是花了实际项目教训换来的设计。早期版本我只让模型输出“异常类型+时间段”，结果模型对一段轻微波动也可能给出“振荡异常”的高置信判断，下游稽查人员拿着标签去现场核查，十个里七个没问题，严重消耗信任。

加入证据要求后，模型被迫把判定依据说清楚，比如“电压从220V骤降至198V并在12个采集点后恢复”。有了证据描述，后续人工复核只需要检查证据是否成立，效率提高一大截。Prompt中对异常类型枚举做了严格限定：DATA_LOSS（数据缺失）、VOLTAGE_DIP（电压暂降）、SURGE（功率突增）、DROP（功率突降）、OSCILLATION（振荡波动）、OTHER（其他）。枚举值使用固定大写编码，是为了后置校验方便，避免模型输出“voltage dip”“电压暂降”“Dip”等各种写法导致的解析混乱。

3.3 设备状态标注与多标签约束输出

设备状态标注需要同时处理多个标签，比如一台表既处于“故障”状态又伴随“通信中断”。多标签场景下，如果Prompt不约束输出结构，模型很容易把多个状态合并成一个自创的“故障且中断”标签，给下游数据应用造成麻烦。我的做法是输出外层用一个数组包裹所有命中标签，每个标签内部再带置信度：

{"device_id": "M202406001", "labels": [{"state": "FAULT", "confidence": 0.92, "evidence": "电压持续为零，功率异常归零，持续2小时"}, {"state": "COMM_LOSS", "confidence": 0.78, "evidence": "最后一条有效数据后出现连续4个采集间隔缺失"}]}

这里有个细节值得提：JSON Schema约束不是所有模型都严格遵循，我在系统提示里除了给出schema定义，还会在提示末尾加一句“直接输出JSON对象，不要包含注释或说明文字”。这听起来像是废话，但实测不加这句话时，部分模型会输出“以下是标注结果：json {...}”这种带了markdown代码块的内容，解析时得额外处理。加上明确指令后，输出纯净度显著提升。

3.4 参数设置：温度低是底线，其他按任务微调

参数设置上我踩过不少坑，最后收敛出一套组合。Temperature直接拉到0.1以下，我通常用0。这不是保守，而是标注任务要求确定性输出，同样的输入必须产出同样的标签，温度高了一点都会带来随机波动。Top_p保持默认的0.9即可，这个参数在标注任务里影响不大。Max_tokens要按输出规模预估，峰谷划分任务输出较短，给500到800足矣；异常标注带证据描述，给1000左右；设备状态多标签任务输出长度不稳定，给到1200以上。

并发参数同样关键。批量标注时，如果同时发起几十个请求，很容易触发API限流，然后进入重试死循环。我把请求改成小批量并发，每批5到10个请求，批次间留300毫秒间隔，失败请求做指数退避重试，重试上限设3次。这套参数跑下来，单批处理速度在10秒级别，比纯串行快了一个数量级，也基本不会撞限流。

4. 衡量Prompt标注效果：指标、成本与调参逻辑

4.1 三种标注方式的横向对比

上线这套Prompt标注管线前，我用一个台区半个月的真实数据做了对比测试，三种方式对同一批500条数据的表现如下：

Prompt标注的一致率能到94%，比我预想高不少。但这有个前提：特征化做得细致，示例库覆盖了边界场景，校验层挡住了明显的幻觉输出。去掉任何一个环节，一致率都会掉到90%以下。这里的“一致率”以专家标注结果为基准，而不是以模型自身输出一致性为基准，后者没有实际业务意义。

4.2 token成本与并发吞吐估算

成本是老板们最关心的问题。我按实际运行数据给出一笔账：单条数据特征化输入约200到300 token，模型输出约150到400 token（取决于任务类型），加上系统提示和示例分摊的成本，单条约消耗600到800 token。处理5000条数据大约400万token。按照主流商用大模型API的计价，折算下来每万条的标注成本是人工成本的十分之一左右，这还是保守估算，没有把管理成本算进去。

并发吞吐方面，实际验证结果是一天处理一万条完全不费力。数据预处理和特征化步骤用Python脚本批量跑，模型调用走并发队列，每一批处理完自动写入结果表，整个流程只需要最后做一次抽样复核。这个产能对日常台区数据标注已经绰绰有余了。

4.3 参数调优总结：先定确定性问题，再谈效率

调参这件事，我的经验是先抓住“确定性问题”这个牛鼻子。也就是先把温度降到0、把输出格式约束死、把校验逻辑做扎实，让标注结果可复现，然后再去优化并发和成本。顺序反了会非常痛苦：模型输出飘忽不定的时候，你连问题都定位不到，更谈不上调优。所以我的推荐顺序是：先调温度到极低，后设计JSON输出结构，再做特征化和示例库迭代，最后才调并发参数。

5. 排坑实录：五个让我返工的问题

5.1 模型幻觉：标注了不存在的时间点

上线第一周就遇到最棘手的问题：模型在证据字段里描述了一个功率达到15kW的尖峰，但回查原始数据，当天功率峰值只有9.2kW，尖峰时间点甚至不在分析窗口内。这就是典型的模型幻觉，它可能参考了示例库里的某些表述，编造出“合理但不存在”的细节。这个问题的危害在于，下游如果直接拿标注结果做分析，会得到完全错误的数据画像。

解法分两层：第一是在特征化描述里把峰值、出现时刻写得精确到分钟，让模型没有编造空间；第二是在校验层加“时间戳合法性检查”和“数值范围检查”，所有标注里出现的时间点必须落在窗口范围内，所有引用的功率值不得超出特征化给出的最大最小值。这两道防线一起，幻觉率大幅下降。我在实际使用中发现，即使模型偶尔幻觉，校验层也能精准拦截，不会污染最终标注结果。

5.2 边界“差不多先生”：事件起止时间漂移

人工标注常见的边界问题在模型身上同样存在，表现为事件起止时间和真实拐点差一两个采集点。比如功率在09:02开始上升，模型标成09:00开始。单个点影响不大，但如果要做峰谷电量统计，半小时误差会直接造成分时电量归错时段。这个问题最初让我很头疼，因为往回看示例库，我自己给出的标注边界也不够精确，等于在教模型“差不多就行”。

后来我在示例里专门增加边界判定说明，写明“边界时间必须落在功率曲线实际拐点所在采集时刻，按15分钟对齐”，并给出一个上升沿缓慢爬坡的边界示例和对应的精确对齐结果。同时在解析阶段对边界做后处理：将模型输出的时间对齐到最近的15分钟刻度，如果输出落在两个刻度的中间且前后功率差值小于阈值，则采用更保守的判定。这套组合拳之后，边界漂移从平均误差2.3个采集点降到0.6个。

5.3 输出格式解析失败：不是模型笨，是你的约束不够

峰值任务初期我遇到的JSON解析失败率在5%到8%，最典型的错误包括：时间格式写成“8:45”而非“08:45”、类型值写成“峰段”而非“峰”、输出被markdown代码块包裹。这些问题都不是模型笨，而是我没有在示例和指令里把格式规范做到位。

解决措施是给Prompt加了一个极简JSON Schema定义，并在每个任务类型里都放了正确格式示例和错误格式示例。解析端则做了容错处理：先把输出里的markdown代码块标记剥掉，再做JSON解析，解析失败时去掉返回文本中的非法字符尝试二次解析，仍然失败就丢进人工复核队列。这几步下来，解析成功率提升到99%以上，剩余1%的人工复核成本完全可接受。

5.4 规则更新与历史结果不兼容

项目运行到第三个月，业务方调整了峰段判定阈值，从“等于均值1.3倍”改为“等于均值1.2倍”。我改了Prompt后跑出新结果，但历史几天已经用旧规则标注过的数据就和新规则的结果对不上了。这个问题的本质不是技术问题，而是工程管理问题：Prompt和代码一样，必须有版本管理和可追溯性。

我引入了规则版本号，每次修改Prompt和示例库时递增版本，并在标注结果表里冗余一个rule_version字段。需要重新标注时，按版本号筛选历史数据重新批次处理。这对标注类业务非常重要，因为标注结果通常会被多个下游任务引用，标签源头的版本混乱会让整个数据链路失去可信度。

5.5 并发限流与成本失控

并发调优时我经历了一次意外：把并发数调到50后，大量请求触发API限流，重试逻辑疯狂重试，token消耗飙升了一倍，一个批次的任务成本直接超预算。这就是“性能优化”和“成本控制”失衡的典型教训。后来我改成“小批量、低并发、保守重试”的策略，并发降到5到10，重试上限压到3次，并且加了整体熔断：如果连续5个请求都因限流失败，暂停30秒再恢复。

这个改动让单批处理时间从8秒拉长到12秒，但换来的稳定性是值得的。在数据标注这种高吞吐场景下，系统稳定远比极限速度快重要。成本叠加限流惩罚会成倍放大，控制不住的并发不是优化，是事故。

写在最后：几个可能救你一命的细节

把整套管线跑完并稳定运行几个月后，我复盘出几个实际使用中才体会到的经验，最后分享出来。第一，所有标注输出都加上ai_confidence字段，哪怕任务再简单。这个字段在抽样复核时能帮你快速圈定“低置信度优先人工看”的样本，复核效率翻倍。第二，Prompt里永远牺牲一部分“自由度”换取“可解析性”，宁可让模型输出啰嗦一点，也要保证输出结构严格可校验。第三，模型版本升级后必须跑回归测试，不要迷信“新版本更好”，我在一次模型版本切换后遇到过峰谷结果和旧版对不上十几处的情况。

这套方案最大的价值不是省掉了人工，而是让标注流程从“边标边模糊”变成了“标完可追溯、可重算、可版本回滚”。如果你想在自己的数据集上复现，我的建议是从最简单的峰谷划分任务开始，把五段式管线的最小闭环跑通，再逐步扩展任务类型。数据标注不是一个一步到位的工程，它是一个不断对抗“模型不确定性”和“业务规则漂移”的持续过程，提示工程给了我们一个应对这种不确定性的新工具，但工具终究要结合扎实的工程校验才能发挥真正效能。