在生成数据口径文档的过程中，一个最容易被忽视但却决定成败的关键点在于：字段定义写得再详细，如果缺乏清晰的判断标准，后续的协作依然会陷入混乱。统一且明确的判定依据，是避免下游开发、BI取数、业务方三方反复扯皮的核心保障。因此，沟通的第一步就是要求AI优先输出判断标准，再基于此标准撰写字段定义。简而言之，如果让AI直接罗列字段清单，结果往往等于无效输出。
换句话说，高效的口径文档写作，必须让AI先亮出判断标准，再围绕它填充字段定义。这样做能大幅减少后续的核对与返工成本。
引导豆包AI优先输出判断标准，再生成完整文档
第一步：在提示词的开头，用强制指令锁定“判断标准前置”这个核心动作。
举例来说，你可以在提示词中明确提出：“请先明确本数据口径文档的【判断标准】，然后基于该标准输出完整文档。判断标准必须包含三项硬性条件：①数据来源系统唯一性（限定只从哪个系统/表/接口获取数据）；②时间范围生效逻辑（明确T+0/T+1/自然日/业务发生日等规则）；③空值与异常值处理规则（例如‘-999’视为缺失值、负值强制归零等）。”
第二步：通过反向约束，阻止AI跳过这一关键步骤的惯性路径。
很多AI模型会不自觉地将判断标准混入字段说明中，或者使用“通常”“一般”这类模糊表达。为此，需要加上一句限制：“禁止将判断标准混在字段说明中；禁止使用‘通常’‘一般’等模糊表述；禁止在未输出判断标准前就着手编写字段定义。”
第三步：绑定具体的业务场景，防止AI输出泛化通用的内容。
例如，当你需要计算月度活跃用户数（MAU）时，数据源是APP埋点日志表 user_event_log_v3，业务要求剔除测试账号（uid以‘test_’开头）和机器人流量（ua包含‘HeadlessChrome’）。将这些具体约束写入提示词，AI就不容易偏离方向。
判断标准是否合格的三个验证关卡
方法一：检查标准的可执行性。
拿到AI生成的判断标准后，问自己一个最务实的问题：开发人员能否依据这条标准，写出确定的SQL WHERE条件？如果出现“视情况而定”“需人工确认”这类措辞，说明标准不合格，必须退回重写。
方法二：进行反向压力测试。
将AI给出的判断标准单独复制出来，作为新的提示词输入豆包：“请按照以下判断标准生成一条违反它的示例数据：【粘贴刚刚输出的标准】”。如果AI能够成功生成反例，说明标准的边界足够清晰；如果它提示“无法构造”，则表明标准本身模糊不清或存在内部矛盾。
【关键陷阱】这里特别容易混淆“数据更新频率”与“时间范围生效逻辑”。前者是ETL调度周期，例如每天凌晨2点执行数据刷新；后者决定某条记录是否计入当月的MAU，比如要求事件发生日 ≤ 统计日 且 ≥ 统计日-29天。两者绝不能混为一谈。
带判断标准的数据口径文档结构模板
- 判断标准（独立章节，置于文档最前方）
- 适用场景（用一句话说明该口径用于解决什么业务问题）
- 字段清单（每个字段包含：名称、定义、计算逻辑、示例值、来源表字段映射）
- 常见问题（仅收录真实发生过的歧义案例，例如“为什么A用户在BI看板中没有计入，但日志里却有事件？”）
注意：字段清单中的“计算逻辑”必须引用判断标准中的条款编号。例如：“按照判断标准第②条，仅保留 event_time ≥ ‘2026-05-01’且 ≤ ‘2026-05-31’的记录”。
操作步骤非常简单：将你整理好的三段提示词组合在一起，直接粘贴到豆包对话框即可。