让模型执行标注的七步流程与九节规则文档模板

当模型面对自相矛盾的规则时，它不会提问，只会自信地猜。本文作者在视频动作切分项目中踩了6个坑，从“规则打架”到“稳定执行”，磨出一套七步流程和可直接套用的九节模板。如果你也在写Prompt执行文档，这篇能帮你少走弯路。

一、2.5 秒，切，还是不切？

先看一段视频的时间轴：

• 2.0 秒：双手正在把盒子放上桌；
• 2.5 秒：右手松开、离开盒子开始回撤，左手还按在盒子上；
• 2.8 秒：右手回撤到位，停住；
• 3.0 秒：左手松开，盒子留在桌上。

我的规则文档里，明明白白写着两句话：

规则 A：双手变单手，必须切分。 规则 B：右手先松、左手后松，以左手松开为切分点。

那么问题来了：2.5 秒这一刻，到底切不切？

按规则 A，该切。按规则 B，要等到 3.0 秒。

我把视频连同这份规则一起丢给模型。模型给了我一个看起来很聪明的答案——两个位置它都切了。皆大欢喜？并没有。你细想就会发现不对劲：它不是在执行规则，它是在猜。 这次猜对了，下次遇到“A 和 B 都好像适用”的场景，它就会给你第三种答案。

我盯着输出愣了挺久，然后意识到一件事：这份规则文档的问题不是不够详细，而是自相矛盾。模型没有主见，它只会把矛盾原样奉还——顺便用一个自信的语气，让你以为问题解决了。

这篇文章，就是我从“规则自相矛盾”到“模型稳定执行”的完整过程：踩了 6 个坑，磨出一个七步流程，和一份你可以直接抄的模板。

二、先交代背景：三条路都走不通之后

我的工作链路说起来很简单，三步：

• 接到需求：模型团队要一批“视频动作切分”数据，用来训练和评测；
• 把需求写成一份 Prompt 执行文档——告诉模型怎么把一段视频切成一个个动作片段，输出成结构化 JSON；
• 用这份文档批量构建评测集，交给模型团队去优化模型。

看到这你可能会问：这种事，招个实习生干不就完了？

问得好，我一开始也是这么想的。直到我把三条路都走了一遍，一条都不通。

第一条路：人工标注。 慢，贵。但这些都能忍，最要命的是不一致。两个标注员对“停顿算不算一个新动作”能拿出三种理解。评测集一旦不一致，模型学到的就是噪声。

第二条路：现成的标注平台。 Label Studio、CVAT 这类工具，解决的是“框画在哪、点标在哪”的问题。但我的需求不是画框，是判断——“2.5 秒这一刻该不该切”，这是一个判断题，不是定位题。工具能给你画笔，替不了你做判断。

第三条路：让模型自由发挥。 我也试过。模型的产出很漂亮，漂亮得像幻觉。它能切出一堆看起来合理的片段，但你没有任何依据判断它对不对。没有规则的自动化，不是效率，是抽奖。

所以最后只剩第四条路：写一份规则文档，让模型照着做。

但这里有一个大多数人都会踩的坑——你会下意识地，把给人写的标注 SOP 原封不动搬给模型。然后你就会被现实教育：

SOP 是写给“会提问的人”的，规则文档是写给“不会提问、只会执行”的。

三、第一层认知：规则文档不是在告诉模型“标什么”

先说一个类比，这是我整个认知转变的起点。

假设你招了一个新员工。脑子极度好使，学什么都快，但对你所在的业务一无所知。你给他写一份操作手册。

你会怎么写？大概会写：

“遇到情况类似的片段，参考已有标注风格处理。”

这句话对真人有用吗？有用。因为他看不懂会来问你，“参考风格”四个字背后，是你俩的一次对话。一次对话，等于把规则补全了。

但你把同样这句话写给模型，会发生什么？它不会来问你。它会自己编一个“已有风格”，然后处理给你看。更麻烦的是，它编得非常自信，你一眼看不出来。

这就是核心差异：SOP 依赖沟通兜底，规则文档没有这个待遇。 模型不会提问，它只会猜；而且猜得理直气壮。

所以规则文档要写的，不是“应该怎么做”，而是“在什么条件下，做什么，输出什么”。每一个“视情况”，都必须被替换成一条条能执行的条件。

我文档里有一条规则，前后两版的变化特别能说明问题：

第一版：“双手协作发生变化时切分。”——这是描述。

第二版：“当一只手开始或结束操作、而另一只手仍在操作时，在手开始/结束操作的事件点切分；切分后，另一只手仍在进行的动作，必须在新片段里继续描述。”——这是条件。

看出区别了吗？第一版告诉模型“按什么分”，第二版告诉它“凭什么判断，以及分完之后别人怎么办”。模型要的是后者。这个区别，就是你文档质量的分水岭。

四、第二层理解：我踩的 6 个坑

认知转变之后，我把第一版文档的问题全揪了出来，一共 6 个。按”第一版怎么写 → 模型怎么翻车 → 第二版怎么改”排列：

这 6 个坑背后其实是同一条规律，我后来把它总结成了一句话：

你不是在告诉模型“世界是什么样的”，你是在告诉它“每一个边界情况，输出什么”。

翻译一下：写规则的时候，脑子里要始终绷着一根弦——“这句话，模型有没有可能理解出第二种意思？”只要答案是“有”，这句话就没写完。

顺便说一句，这 6 个坑不是我坐在办公室里想出来的，是我和协作的 AI 工具反复“写一版 → 跑一批视频 → 看输出 → 定位是哪条规则出了问题 → 改一版”磨出来的。每一轮循环，都有一条规则被改写成条件句。

五、第三层认知：一份靠谱的规则文档，是七步磨出来的

坑踩完了，说方法。下面这个七步流程，是我从“定粒度”到“回测”的完整闭环。我的建议是：下一个项目开始时，按这个顺序走一遍，比直接复制一份现成的 Prompt 可靠得多。

这里面有几步，值得单独说。

第一步，定粒度，是整个文档的地基。 “切多细”没有标准答案，只有项目选择。开篇双手放盒子的例子，第二版之所以敢在 2.5 秒切，是因为我们明确选了“以任意一只手的状态变化为切点”这个粒度。换个项目，完全可能选“双手都完成了才切”。没有对错，但必须显式。文档里必须有一行字，写清楚你的标注单位是“操作阶段”“完整操作”还是“完整任务”。

第二步，找分歧，是我认为最被低估的一步。 为什么要两个人独立标同一批样本？因为两个人标不一样的地方，就是规则没写到的地方。 这跟考试双阅卷是同一个道理：两个老师分差大的题，往往不是老师有问题，是题目有问题。你的分歧案例表，就是规则文档的 TODO List。

第三步，写判断条件，是整套方法的心脏。 “这里应该切”是判断，“满足什么条件时切”才是规则。前者的主语是人，后者的主语是条件。只有后者，模型才执行得了。

第四步，补反例。 每条规则都要配一个“形似而神不似”的反例。为什么？因为模型的泛化能力太强了，强到会把你没说的也一起执行。“右手回撤”和“右手停顿后回撤”是两回事，你不写反例，它就当成一回事。

第七步，回测，是闭环的关键。 规则改完一定要回测：同一批视频、同一个模型、同一套配置，只看修改前后。而且只看一件事——错误的变化：哪些原来的错题变对了，哪些原来的对题被改坏了。没有这一步，你改规则全靠信仰。

六、可以直接抄的：规则文档的九节结构

流程讲完，上干货。这是我磨到第二版定下来的结构。你不需要照抄我的内容，但这个骨架建议直接拿走：

你是[项目名称]的视频标注员。

一、任务目标

输入：[视频类型、可用视角、是否有音频等]

输出：[动作切分、skill、caption 等]

标注单位：[操作阶段 / 完整操作 / 完整任务，明确选择]

时间覆盖：[全视频覆盖 / 只标有效操作区间]

只描述视频提供的可确认信息，不补写画外或遮挡中的过程。

“操作意图”指可观察的当前操作，不指心理活动或最终任务目的。

二、切分规则

遇到以下变化时切分：【逐条列出本项目认可的变化】

以下情况保留在同一段：【同一操作内部允许的调整、往返、停顿、重试等】

规则同时命中时：【明确哪条例外优先，不能只写”视情况处理”】

三、动作定义

为每个核心动作填写：动作名称 / 判定依据 / 开始事件 / 结束事件 / 同一动作内部允许的变化 / 容易混淆的动作及区别 / 需要切的例子。

只标实际出现的阶段，不为凑齐流程补造阶段。

四、多主体规则

使用[统一时间轴 / 分主体时间轴]。

一个主体变化时：[是否触发全局切分、具体在什么事件处切]

其他主体尚未结束的动作：[如何在新片段中继续描述]

同段多个动作的 skill：[主要动作选择方法及冲突时的处理]

五、不确定和异常情况

遮挡：[处理方式]

视频开头或结尾截断：[处理方式]

失败与重试：[合并和拆分条件]

静止与持续持有：[如何区别]

无法辨认：[允许使用的标签和 caption 写法]

六、Caption

描述顺序：主体 + 当前动作 + 对象/部位 + 必要属性 + 位置/方向。

完成状态：只看到过程时使用过程表达；只有结果可见时才描述已完成。

禁止：补写不可见结果、猜测属性、把同时发生写成先后发生、遗漏仍在持续的主体动作。

七、标签与时间

允许的 skill：[固定词表或明确扩展策略]

标签歧义：[相近标签如何区分]

时间单位、区间规则、最短时长、未知区间：逐一约定。

八、输出

字段：[固定字段名、类型]

仅输出合法 JSON，并提供一个与上述规则一致的完整示例。

九、输出前检查

切点是否符合本项目粒度？是否漏掉持续动作？是否把过程写成完成？

是否猜测不可见信息？skill 是否与当前动作一致？时间轴和 JSON 是否满足约定？

三个写作细节，单独提醒：

• 禁止项必须配替代写法。 只写“不要把同时发生写成先后发生”没用，要写“同时发生时，两个动作写在同一个片段的 caption 里”。禁而不替，模型还是会回到老路。
• 示例要覆盖到边界。 给模型的示例，不能只有干干净净的成功案例。遮挡的、截断的、只拍到半只手的，都要有。模型学示例，比学规则快得多。
• “输出前检查”是性价比最高的一节。 它相当于让模型交卷前自查一遍，很多低级错误在这一步就被拦下来了。

七、对产品经理意味着什么

写到这里，方法论已经讲完了。但如果你是把这篇文章当“AI 产品经理手艺”来读的，还有三件事值得带走：

第一，规则文档是 AI 产品的隐性资产。 大多数团队把 Prompt 当“聊天记录”，随手一写随手一扔。但一份能跑的规则文档，本质上是你把业务判断标准显式化的结果——它可版本管理、可回滚、可交给任何人复现。这和“把经验留在老师傅脑子里”是两种组织能力。

第二，这套方法不止适用于视频标注。 任何“用模型批量生产数据”的场景——内容审核、客服质检、摘要评分、对话评估——套路完全一样：先定标准，再找分歧，然后把标准写成没有第二种解释的条件。变的只是第九节模板里的业务内容，不变的是“条件化”这个动作。

第三，它重新定义了“需求评审”。 以前评审需求，评审的是“做什么”；现在多了一个问题——“这条需求，模型有没有可能理解出第二种意思？”能把这个问题问出口的产品经理，比会写十条提示词技巧的产品经理更稀缺。

八、写在最后

回头看，这件事给我最大的认知冲击是：

写规则文档的人，天然以为自己在“描述一个流程”；但模型需要的是“一个没有第二种解释的决策系统”。

描述可以留白，决策不能。留白的地方，就是模型猜的地方；模型猜的地方，就是你数据里的噪声。噪声进了评测集，评测集进了训练，最后变成模型上一个你说不清来源的 badcase。

所以我现在判断一份规则文档好不好，标准只有一个：

随便抽一个片段，两个理解这份文档的模型，会不会给出同一个答案？

不会，就接着改。

模型不会提问。但你可以，提前把它的每一个问题，写进规则里。

如果你也在用大模型做数据生产或评测集构建，欢迎在评论区聊聊你踩过的坑——我猜第 3 条“规则打架”和第七条“留给模型猜”，中招的人不会少。

本文由 @洋洋 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议