给 AI 自动化设置 CRM 字段写入边界

AI 把客户随口提到的启动时间写进 CRM，后续排期就可能把它当成正式承诺。原文给出的办法很直接：给每个字段划定写入权限，再由工作流统一执行，不能只靠提示词约束模型。

这套方案面向 n8n 和 Make，重点是把自动写入、人工审批和禁止修改分开。对正在把 AI 接入业务系统的程序员，它最有用的地方，是把「模型能提取信息」和「系统允许修改记录」拆成两件事。

为什么一句「可能」会变成正式承诺

原文引用了 r/automation 的一则讨论：AI 会议记录工具把客户仅仅提议过的 kickoff date，也就是项目启动日期，写进了 CRM；随后，一名没有参加通话的人批准了这个日期。

问题并不只在信息提取。模型处理的可能只有当前这次通话或邮件，看不到之前的约定。客户说「也许下个月」，日期字段却只能接收一个确定日期，含糊的意向就被压成了精确值。

审批也未必能兜底。没参加对话的人缺少上下文，很难判断这个日期是承诺还是猜测。一旦错误值进入 CRM，它就带上了正式记录的外观，其他自动化还会继续使用它。

真正需要控制的，是提议进入正式记录的那一步。

字段能不能写，要由工作流决定

作者建议给每个 CRM 字段分配三种标签：

• 允许自动写入，提议可以直接提交到 CRM。
• 只允许建议，必须由人审批后才能写入。
• 禁止修改，自动化丢弃相关提议，并留下日志。

规则需要集中存放。原文给出的落点是 n8n 的 Set 节点，或者 Make 的 data store，保存字段名与对应标签。模型负责提供候选信息，工作流根据标签决定去向。

这样做的原因是，提示词只是给模型的指令，无法充当写入前的权限检查。即便模型输出了不该修改的字段，后面的过滤步骤仍应拦住它。

不过，原文虽然提到要调整字段表，提供的内容里并没有实际表格，也没有列出哪些业务字段应归入哪一类。因此，这是一套分类方法，还不是可以直接照抄的字段清单。

一次提议至少要带上原话和审批记录

作者建议让 AI 返回 JSON，包含字段、建议值，以及支持这个值的一小段来源原话。原文没有给出具体 JSON 示例，也没有规定键名。

随后，工作流在写入前按标签分流。自动写入字段进入 CRM；仅建议字段进入表格、Slack 消息或 CRM 任务等审核列表；禁止修改的字段被丢弃并记录。Make 可以使用 router，为每种标签配置 filter，无需为这一步编写代码。

进入审核列表之前，还要检查提议是否附有准确原话。模型找不到原文依据，就不送审。作者认为这能去掉大部分编造的日期，但没有提供测试数据。

有引文仍然不等于有承诺。「可能在三月开始」确实提到了三月，却不能证明启动日期已经确定。因此，建议应交给负责这笔交易的人审核，而不是随便找一个有空的人。批准后，把审批人和时间写进该条 CRM 记录的备注，方便追溯。

作者还给了一个验收场景：输入客户说「我们可能在三月开始，但还没确定」的通话转录。如果 kickoff date 没经过审核就发生变化，说明过滤流程没有正确接好。

我的判断

我赞成把写入规则放到工作流里。和只在提示词里写「不要擅自改日期」相比，这个方案能明确检查每个字段的去向，也方便追查是谁批准了修改。

但人工审批要发挥作用，有两个前提：审核人理解业务上下文，并且能看到支撑提议的原话。否则，审核列表很容易变成另一个机械点击入口。

引文检查也只能证明「来源里出现过这些话」，不能自动证明建议值准确表达了承诺。作者指出了问题，却没有展开如何判断语气、条件和历史约定。

标题标注了 2026，正文并未说明这一年份对应什么新能力。「约 30 分钟落地」和「去掉大部分编造日期」都没有实测记录或对照数据，应当视为作者的经验判断。原文还推广了 Make 免费计划，并披露部分链接为联盟链接；这不影响方案本身的讨论，但不能据此判断免费额度是否够用。

能拿来做什么

• 在现有 n8n 或 Make 流程里，先列出 AI 可能修改的 CRM 字段，为每个字段明确分配三种标签，再接入统一的写入过滤。
• 把 AI 输出改成「字段、建议值、来源原话」的提议格式，并让审核列表同时展示这三项，方便负责人判断。
• 用「可能在三月开始，但尚未确认」这类输入检查流程，确认模糊意向不会绕过审核直接修改 kickoff date。
• 给审批写入保留审批人和时间，同时记录被禁止的字段提议，让后续排查有据可查。