数据的“干净度”这玩意儿，以前我根本不在乎。爬虫时代，能抓到就是胜利，脏数据扔给实习生洗一洗，或者写个正则糊弄过去。但今天调试一个自动处理设计订单的 Agent 时，它卡在了一个诡异的地方：客户上传的图片背景描述里，有个“RGB(255, 255, 254)”，Agent 死活不认为这是“纯白色”。就差了1个数值，整个流程就僵在那里，等着人工介入。那一刻我后背发凉——这不是 bug，这是埋在自动化流程里的地雷。Agent 没有“觉得差不多就行”这种人类直觉，它的世界是二进制的，对错分明。所以，给它喂的数据，必须达到一种近乎变态的“干净”，这就是“自我审计”的必要性。
我的闭环逻辑是这么搭的，核心是 n8n。飞书多维表格里，客户新提交一条订单记录，触发 n8n 的 Webhook。这里第一个审计点：n8n 节点会先检查这条记录的字段完整性，必填项有没有空，附件的格式（我们要求png或jpg）对不对。不通过就直接打回，并自动给客户飞书发条提醒，这避免了垃圾数据流入核心流程。
通过后，数据进入“理解层”。这里用 GPT-4 API，我写了个特别的提示词：“你是一个严格的产品需求解析器。请从以下用户描述中，提取关键元素：1. 主视觉主题（如：科技感、国风）。2. 核心文案（精确原文，一字不差）。3. 颜色要求（列出所有提及的颜色，并尝试将其标准化为 HEX 码或 RGB 值，如用户说‘天空蓝’，你输出‘#87CEEB’）。4. 图片修改的具体要求（如：去水印、更换背景为XX）。输出必须为严格的 JSON 格式。” 这个提示词本身就是一层审计，强迫 GPT-4 结构化输出，而不是散漫的文本。
拿到结构化数据，进入“执行层”。如果是换背景，调用另一个图像处理的 API（比如 Remove.bg 或自己部署的模型），指令就是“将背景替换为 HEX: #FFFFFF”。看，这里就要求前面提取的颜色 HEX 码必须绝对准确，“白色”不行，“#FFFFFF”才行。处理完的图片，自动上传到云存储，生成链接。
最后是“交付层”。n8n 把成品图链接和整理好的需求摘要，通过 SMTP 节点发送给客户邮箱，同时回写状态到飞书表格：“已完成，邮件已发送”。整个流程，从飞书触发到邮件发出，大概 2-3 分钟。我测试的时候，半夜两点丢了个订单进去，醒来邮箱里已经躺着处理好的图片和确认信了。
这种“睡着觉也能赚钱”的感觉，初看是赛博美学，细想是恐怖故事。它的美感来自于绝对的秩序和冰冷的执行，而恐怖也源于此——任何一个环节的数据“不干净”，整个精密的机器就会在寂静的深夜里无声宕机，没有警报，直到第二天你发现一堆僵死的流程和愤怒的客户。所以，我现在花在构建“审计节点”上的时间，比构建主流程还多。比如在调用 GPT-4 前，加个节点过滤掉描述中的特殊字符；在发送邮件前，校验一遍附件链接是否有效。Agent 不会疲倦，但它极度脆弱。喂养它，得像对待一个有着严重洁癖和强迫症的天才儿童，你得把它周围的世界，擦拭得一尘不染。
