JSON 变更审查与规范化工作流

目标与适用范围

固定 JSON 或 JSONL 输入，和基线或环境配置比较，解释质量信号，并交付有记录可追溯的规范化结果。
本指南将当前任务范围转化为可复核的交付结果。请保留源文件、中间产物和关键判断，让后续协作者能够理解检查了什么以及为什么这样处理。

准备证据并作出选择

• 保留一份脱敏且未改动的 JSON 或 JSONL 原始副本，并标明其负责人。

• 提供获批准的基线，或要比较的具名环境配置包。

• 先写清哪些字段可被标准化，哪些值必须原样保留。

• 决策点: 当前首先要回答配置变更还是记录质量？. 若要查缺失、修改或意外出现的配置键，走基线与环境比较路径；若问题是记录格式错误、缺失、重复或漂移，走日志和数据集分析路径。

• 决策点: 清洗规则能否明确为确定性规则？. 映射、大小写、日期和空值处理已有定义时使用规则化规范化。只有面对异构文本或格式时才使用 AI 辅助，并逐项抽样复核建议的转换。

按步骤完成工作流

1. 固定并格式化证据

在不改变字段值的前提下格式化脱敏源文件，让审查者能对照保留的原始副本检查嵌套、数组、空值和可疑键。 使用 json-formatter.

2. 显化基线与环境差异

先将格式化后的载荷与获批准基线比较，再隔离不同环境中的缺失键、变更值和新增项，避免把所有差异都误判为数据缺陷。 使用 pretty-json-diff, environment-config-diff-visualizer.

3. 解释记录级质量信号

把 JSONL 或结构化事件解析为字段，并剖析完整性、重复行、推断类型、格式漂移和数值离群，区分真实模式与一次性差异。 使用 structured-log-analyzer, dataset-quality-profiler.

4. 按可追责策略规范化

规则已明确时采用确定性清洗；模糊脏字段才使用辅助规范化，并抽样对照保留源文件，记录未解决的例外。 使用 data-normalizer, ai-data-normalizer.

交付前验收结果

• 交付中明确原始输入、比较基线和审查范围。
• 每一项已接受差异都被归类为有意差异、按已记录规则修复，或保留为例外。
• 规范化输出保持有效 JSON 结构，抽样比较未发现意外字段丢失。
• 交付说明标明规范化路径及仍需负责人审查的记录。

常见问题

• JSON 差异能判断某项变更一定错误吗？ 不能。它只显示结构和值的不同。基线负责人应判断每项差异是获批准的环境差异、必须修复的问题，还是需要保留的例外。
• 何时应分析日志而不是单个 JSON 文档？ 证据是 JSONL 或重复事件，并且需要跨记录提取字段时，使用结构化日志分析。单个载荷应先与其基线进行审查。
• 何时适合使用 AI 辅助规范化？ 当不一致的自由文本或混合来源格式无法安全写成确定性规则时才适合使用。必须保留原始数据、抽样检查变更，并记录采用的策略。