绩效考核异常巡检 Agent
把重复核验落实为自动取数、规则检查与统一 HTML 报告
原本分散在个人表格里的重复核验，改由程序按既定规则执行；报告负责把核查线索组织到位，业务判断与校正仍由人完成。
项目
以28条检查规则、5个Skill组织检查，按业务域输出HTML报告。程序承担重复检查，组内同事结合业务情况判断，再校正产品数据或反馈规则问题。
考核组需要检查绩效产品中的目标值、实际值、人员与考核方案及分数是否符合业务口径。我参与将这些检查整理为可重复执行的巡检：在团队共同定义的口径上补充字段、业务例外和验证实例，复核输出并反馈修改；AI辅助代码实现与修改。
运行与交付概览
披露的异常分布与质控记录（四项不同口径，不合并计算）
实际值缺失、维度与传输等情形
口径：总览卡「异常占比」口径
覆盖次月收集、指标未开发、指标维度欠缺、指标传输异常等情形，报告按业务域给出明细。
披露的两张总览卡中占比较高的一类
口径：总览卡「异常占比」口径
以目标值未设定与目标值维度欠缺为主；后者需核对考核维度与底表维度是否一致，是人工核查的主要入口。
行级空值检测改为维度级均值检查
口径：2026-06-22 历史修改记录
提示数量下降是检查精度的修正，不等于在产品中修复了对应的业务问题。
补齐异步分页结果后 E-2 输出收敛
口径：2026-06-29 历史修改记录
属取数与检查层代码修复，不是在产品端消除了对应的业务配置。
从反复导表核验，到程序先检查、人工再判断
原业务流程通过「产品看板导出—Excel核验—错误调整」开展数据监控；绩效计算还涉及数据补充、核验、计算、复核和留存。项目按影响广度、发生频率和自动化可行性评估异常，先把适合规则化执行的检查落地：取数、底表比对、异常分类和报告汇总交给程序，人工继续负责业务判断与产品校正，而不是把全部考核工作交给AI。
报告先看总体，再定位到具体指标与验数对象
报告由总览、重点提示、业务域汇总、模块分类和具体记录构成。使用者可以先看检查提示集中在哪些业务域和分类，再查看指标、考核维度、底表维度及验数对象。
报告的顺序与人工核查的顺序一致：先看哪些业务域和分类提示集中，再定位到具体指标、考核维度、底表维度与验数对象，最后回到业务上判断是否属实。例如「目标值维度欠缺」这类提示，会把考核要求的维度与底表实际覆盖的维度并排列出，给出人工继续核查的线索，不直接替人判定根因。核实为产品问题，在产品内校正；属于误报，则把具体记录和判断依据反馈给巡检维护。
查看报告层级与字段脱敏说明
报告层级：左侧为模块导航（总览、四类模块、次月收集、按业务域明细），主体自上而下为标题与数据快照条、总览四卡、重点关注问题、业务域 × 检查分类矩阵、分类明细表。本图按同一层级重绘，不替换层级，也不把明细压缩成流程框。
字段脱敏：图中「指标甲」「业务域甲」为代称，原表字段名称转为中文解释；占比沿用原表口径，未重新计算。
复用已有能力，把取数、检查和报告连接起来
项目以已有SQL执行／验数能力为基础，复用在线指标查询、指标口径判断和SQL模板等能力，通过Python组织检查与报告输出。人岗体系检查先核对人员与方案及维度覆盖；实际值与目标值检查交叉比较相关底表；分数模块检查总分超限、体系重复和达成率极端；报告规范将结果统一组织成可阅读的HTML。
我在其中提供业务条件和例外，检查实际输出与业务含义是否一致，再把调整依据反馈给AI辅助修改。这里既包含开发与修改时的人机协作，也包含运行时由SQL／Python执行的检查，两者不是同一条流程。
不只让程序跑起来，还要修正不合理的检查结果
2026年6月的开发记录中，一项指标210行里有208行有值，仍因2行为空被整体标红。项目将该处行级空值检测调整为维度级均值检查；该轮「传输异常」提示由30变为6。这个例子说明：检查粒度不符合业务需要时，运行成功也可能产生不合理提示。
另一处业务例外与离线验证（6组案例）
同一人名下六个指标、权重合计100%，是经用户解释确认的正常配置场景；「六个指标」不是历史明细数量。
历史上另有6组记录曾被提示为一人多套考核方案；按业务定义及指标、权重、分数关系判断为正常分摊后，反馈补充识别条件。同一数据日期的两版报告中，这6组不再命中，其余63个「业务域×问题分类」汇总项数值未变。该对照依据已有报告对照记录整理，非代码摘录。
复盘补做离线验证：分摊识别17个构造用例、另一维度9个独立构造用例，均符合各自预期。仅说明这些输入下的表现，不代表总体准确率，也不用于验证本节两项历史修改。
更多运行与维护改进（依据历史实现说明整理）
同一批历史记录还记载：SQL偶发错误的兜底处理（出错不中断运行）、报告空行与空区块的处理、复制按钮异常处理、巡检结束前的自检，以及代码与Skill说明的版本同步。
以上为历史记录中的工程与维护事项，统一以项目记录表达，不含逐项个人归属。
已改变的是工作分工，运行与验证记录提供补充依据
巡检把部分重复取数、比对和汇总动作交给程序，把需要核查的对象集中到报告中；人的工作继续是理解业务、判断异常、校正产品和反馈规则修改。现在拿到报告，先确认提示集中在哪个业务域和哪一类检查，再决定是校正产品配置、补充业务数据，还是把误报和判断依据反馈回去修改规则。
已有定时与按需执行方式，留存12周、62次成功落盘记录；14份日志的单次墙钟耗时中位为483秒（约8分03秒）。这是机器运行样本，不含同事后续核查处置时间，也不是节省工时的测量值，只用于说明程序侧的单次执行量级。
沉淀可复验的检查资产，而不是把一次判断包装成自动化
把原本分散在个人表格中的重复核验动作，收敛为可重复执行的检查规则与 Skill 组织方式。程序负责把待核查对象全量、规整地呈现出来，人负责对其中的异常做出业务判断。
建立从误报反馈到规则修改的响应路径
巡检的难点不在于让代码跑通，而在于面对业务例外时能否被及时修正。核实为产品问题的，在产品内校正；核实为误报的，把具体记录与判断依据反馈为检查条件的补充，再用离线构造用例确认不影响既有结果。
后续演进方向（规划中，不列入已完成）
异常处理闭环：从静态报告走向「提示—认领—纠偏—销项」的跟踪；按维度做归因分析；把常见问题沉淀为可复用的答疑口径。
查看实现口径与补充依据
实现范围：28条检查规则之外，另有1条展示规范和2条质控机制，合计31个实现条目。5个Skill是实现组织层级，与规则条数不是同一种计数；早期的11条历史异常口径与现行28条不是同一统计序列。
运行记录：14份运行日志的单次墙钟耗时中位数为483秒。样本不包含主批次三版，完整尝试次数未知，因此不计算运行成功率，也不与人工月投入换算提效比例。
重复运行与验证范围：已有三对重复运行记录仅支持被比较的部分字段一致。离线用例用于检查给定输入，报告对照用于核查所比较的输出范围，不能据此宣称所有输出长期完全稳定。
独立补充交付：另曾整理95条、4字段的目标值收集清单交业务方使用，属于独立补充场景，不是日常巡检的主要使用方式；报告中的次月收集清单由业务方补充数据，不计入异常统计，不表示程序自动补齐业务数据。
口径红线与核验边界备忘
交付清单口径：全量实现为 28 条检查规则、1 条展示规范、2 条质控机制，合计 31 个实现条目；另曾向业务方独立交付 95 条、4 字段的目标值收集清单作为外部输入支持。
| 口径红线 | 边界说明 | 禁止动作 |
|---|---|---|
| 异常提示 ≠ 业务坏账 | 报告中的标红只是「待人工核查线索」，可能属于正常业务分摊或尚未同步的数据。 | 严禁直接定性或扣罚 |
| 误报减少 ≠ 问题修复 | 检查粒度由行级调整为维度级导致提示数下降，是检查精度的修正，不是业务配置已被解决。 | 严禁混淆质控与修复 |
| 次月收集 ≠ 程序补数 | 次月待补清单用于提醒业务方补充录入，程序不改写底表数据。 | 严禁脱离人工数据源 |
| 机器耗时 ≠ 工时节约 | 483 秒为 Python 与 SQL 批处理的时间跨度，不含人工后续判断时间。 | 严禁虚构 ROI 测算 |
| 规则版本不可交叉 | 早期 11 条历史异常口径与现行 28 条规则不属于同一演进阶段，不可直接同环比。 | 严禁口径串用 |
| 维度不得强行对齐 | 考核维度与底表维度是两套体系；底表粒度不足时应并排展示线索并推动数仓扩充，不能映射成同一套。 | 严禁失真对齐 |
| 离线用例防范回归 | 因业务例外调整检查逻辑后，须回归运行复盘补做的 17 个与 9 个离线构造用例。 | 严禁未经测直接生效 |
| 展示必须脱敏 | 对外展示的报告须对组织节点、人员标识、业务域与指标名称做脱敏处理。 | 严禁泄露内部口径 |