我让 AI 写脚本时，为什么先检查解析方式

我观察到，Agent 在生成自动化脚本时，有时会直接选择最直观的字符串切分、正则或固定行号。它们可能很快让当前样例通过，但一旦输入格式稍微变化，脚本就会悄悄得到错误结果。

我不再把这个现象概括成“LLM 总是喜欢规则解析”。更准确的说法是：在缺少约束时，模型可能优先产出表面上直接可用的规则代码，而不是先确认是否存在更可靠的结构化接口。

先问数据到底是什么

一个文件如果本质上是 JSON、CSV、XML、数据库、图片、音频或某种专用格式，就应该先按它的真实结构处理。我的检查顺序通常是：

1. 有没有标准库可以直接读取？
2. 有没有官方 API 或成熟的领域库？
3. 格式是否有版本、编码、嵌套和转义规则？
4. 输入异常时，脚本能不能明确失败？
5. 只有在没有结构化工具时，才考虑自己写规则。

这一步不一定增加很多代码，反而常常能减少后续维护。

规则解析为什么危险

规则解析的隐患不只在“格式变了会报错”。更危险的是它可能继续运行，但提取到了错误字段。对于批量迁移、账单、日志、配置或内容导入，静默错误比直接崩溃更难发现。

另一个问题是，规则通常把样例的外观当成格式的定义：第几行是标题、某个字符串后面就是值、遇到某个标记就截断。它依赖的是偶然特征，而不是数据模型。

什么时候规则可以接受

规则并非绝对不能用。一次性的、输入已经严格冻结的临时脚本，或者格式极其简单且有充分测试覆盖的任务，可以选择轻量规则。关键在于把这个范围说清楚，而不是让临时方案伪装成通用解析器。

我会要求 Agent 同时给出适用边界、失败方式和最小验证样例；如果任务会进入长期运行或批量处理，就优先升级为结构化解析。

我现在给 Agent 的约束

在生成脚本之前，我会先让它回答：输入的真实格式是什么，现成的解析能力在哪里，当前方案依赖哪些假设，如何证明结果没有静默偏差。

这不是拒绝 AI，而是把关键判断提前。Agent 可以帮我写实现，但不应该替我决定“什么算正确地理解了输入”。

对我来说，可靠脚本的起点不是更复杂的正则，而是先尊重数据本身的结构。