写在前面

用 Dify（或者 Coze、扣子这类低代码 LLM 平台）搭应用，前 10 个的时候是真爽——拖拖拽拽，prompt 一填，接口就出来了。爽到你根本不会去想「治理」两个字。

然后应用数量开始涨。业务方每来一个需求，最快的交付方式就是复制一个现成应用改改 prompt。等我们回过神，Dify 上已经躺着 134 个应用：5 个正式在用的、一堆历史版本、各种实验分支。

问题来了：这 134 个应用里，有几十个共享同一套「评分标准/话术规范/审核规则」。当这套标准要改一个字，我得去 134 个应用里一个个找、一个个改。改到第 20 个的时候我就知道，今天肯定有漏网的。

这篇讲的就是这个坑——低代码 LLM 平台的「规则漂移」，以及我们怎么用工程手段把它收敛的。不是 Dify 教程，是治理方法论，换成任何同类平台都成立。

背景：我们在公考赛道做内容和 AI 产品，Dify 上跑着批改、面试追问、内容审核、客服问答等一堆应用。很多应用共享同一套底层规则（比如评分档位、敏感内容红线），这些规则的一致性直接决定产品质量。

一、为什么应用一多，规则必然漂移

先把病因说清楚，不然治标不治本。规则漂移不是谁偷懒，是低代码平台的结构性问题：

1. 复制式扩张：新需求最快的交付是「复制一个改改」。复制的瞬间，规则就有了一个副本。副本一多，真源就消失了——没有哪一份是「权威版」。
2. prompt 即副本，没有引用机制：传统代码里，公共逻辑抽成函数，所有调用方 import 同一份。但 Dify 里，规则是写死在每个应用 prompt 文本里的字符串，没有「引用同一个规则模块」这回事。改函数，所有调用方自动更新；改 prompt，你得手动同步 N 份。
3. 没有编译期校验：代码写错了编译不过、测试挂掉。prompt 改错、漏改、改串了，平台不会报错——它照样跑，只是悄悄给出了错误结果。漂移是静默发生的，等你发现，往往是用户投诉了。
4. 人肉记忆不可靠：「这套规则用在哪几个应用里」这种关系，早期靠人记。人一多、时间一长，这张关系图就没人说得清了。

一句话：低代码平台把「创建应用」的成本降到极低，却没有把「维护一致性」的成本一起降下来。 应用数量和规则熵是同步涨的。

二、核心原则：规则的 single source of truth

治理的总纲只有一句：任何一条规则，在整个系统里只能有一个权威定义（single source of truth，SSOT）。所有应用都是这个真源的「投影」，不是「副本」。

这句话拆成可执行的，就是三步：抽离、检测、闭环。

第一步：把规则从 prompt 里抽出来，落成结构化真源

第一件事，是把散落在各应用 prompt 里的规则，抽离成独立的、版本化的规则文档。

我们的做法是：每一类规则（评分档位、审核红线、话术模板……）在代码仓库里有且仅有一份 Markdown/YAML 定义，Git 管理版本。举例，评分规则真源长这样：

# rules/scoring/shenlun.yaml  —— 申论评分规则 · 唯一真源
version: 2026.06
dimensions:
  - name: 论点
    max: 10
    levels:
      - {range: [9, 10], desc: "中心论点明确，分论点逻辑自洽，无偏题"}
      - {range: [7, 8],  desc: "中心论点明确，分论点基本扣题，个别游离"}
      - {range: [5, 6],  desc: "有中心论点但表述模糊，或分论点明显脱节"}
      - {range: [3, 4],  desc: "论点不清，通篇复述材料"}
      - {range: [0, 2],  desc: "跑题或无明确论点"}
  # ...其余维度

关键动作：Dify 应用里的 prompt 不再手写这套规则，而是由这份真源渲染生成。改规则 → 改这一份 YAML → 用脚本重新渲染 prompt → 推到对应的一批应用。真源永远只有一份，应用永远是它的下游产物。

# 从真源渲染出 prompt 片段，注入到 Dify 应用
import yaml

def render_rubric(rule_file: str) -> str:
    rule = yaml.safe_load(open(rule_file, encoding="utf-8"))
    lines = [f"评分标准 v{rule['version']}："]
    for dim in rule["dimensions"]:
        lines.append(f"\n【{dim['name']} · 满分{dim['max']}】")
        for lv in dim["levels"]:
            lo, hi = lv["range"]
            lines.append(f"- {lo}-{hi}分：{lv['desc']}")
    return "\n".join(lines)

这一步做完，「改规则」这个动作从「翻 134 个应用」变成「改 1 个文件 + 跑一次渲染脚本」。

第二步：漂移检测——定时比对线上应用与真源

抽离真源只解决「新的怎么改」，但历史上已经漂移的应用、以及有人绕过流程直接在控制台手改的情况，你得能发现。

Dify 支持通过 API 导出应用的 DSL（配置 + prompt 的完整定义）。我们写了个漂移检测脚本：拉取每个应用的 DSL，把里面的规则片段抽出来，和真源渲染出的标准片段做比对，不一致就报警。

import hashlib, requests

def fetch_app_dsl(app_id: str, token: str) -> str:
    r = requests.get(
        f"{DIFY_BASE}/console/api/apps/{app_id}/export",
        headers={"Authorization": f"Bearer {token}"}, timeout=25,
    )
    r.raise_for_status()
    return r.json()["data"]  # YAML 文本

def rule_fingerprint(text: str) -> str:
    # 归一化：去空白、统一标点后再算指纹，避免格式噪音误报
    norm = "".join(text.split()).replace("，", ",").replace("：", ":")
    return hashlib.md5(norm.encode()).hexdigest()[:12]

def detect_drift(apps: dict, expected: str):
    exp_fp = rule_fingerprint(expected)
    drifted = []
    for name, app_id in apps.items():
        dsl = fetch_app_dsl(app_id, TOKEN)
        seg = extract_rule_segment(dsl)      # 从 DSL 抠出规则段
        if rule_fingerprint(seg) != exp_fp:
            drifted.append(name)
    return drifted

挂到定时任务上，每天跑一遍，哪个应用的规则和真源对不上，早上就进报警。从「等用户投诉才发现漂移」变成「漂移当天自动暴露」。

有几个工程细节值得说：

指纹要做归一化：直接比字符串会被空格、全半角标点这种噪音搞出一堆假阳性。先归一化再算指纹。
只比规则段，不比整个 DSL：应用之间本来就有差异（模型参数、变量名），只抽「受真源约束的那一段」来比。
超时放宽：批量拉 DSL 时单个请求别卡太死，我们踩过 timeout=10 把稍慢的响应掐断、误判成「服务挂了」的坑，后来放到 25s + 重试。

第三步：badcase 回灌闭环——让每个坑只踩一次

真源 + 检测解决了「一致性」，但规则本身对不对，是另一回事。规则是活的，会因为新出现的 badcase 而需要迭代。

我们建了个闭环：线上发现 badcase → 定位是哪条规则不到位 → 改真源（而不是在单个应用打补丁）→ 重新渲染分发到所有相关应用。

关键点在「改真源，不打补丁」。早期我们图快，遇到 badcase 就直接在出问题的那个应用 prompt 里加一句「补丁」。结果就是：同样的 badcase 换个应用又犯，因为补丁只打在了一个副本上。回灌真源，才能让所有下游应用一次性都获得修复——一个坑只踩一次。

badcase → 归因到 rules/xxx.yaml 的具体某档 → 改真源 + 提 version
        → 渲染脚本重跑 → 推送到该规则关联的应用组 → 漂移检测确认对齐

三、治理前后对比

给几个能落地衡量的指标（我们内部实际口径）：

指标	治理前	治理后
改一条规则要动的地方	手翻 N 个应用 prompt	1 份真源文件
改一次规则耗时	半天起，且必有漏改	分钟级，渲染脚本批量推
漂移发现方式	用户投诉倒查	每日脚本自动报警
同一 badcase 复发	换个应用又犯	回灌真源，一次修复全量
「规则用在哪些应用」	靠人记，说不清	真源→应用组映射表，明确

最大的变化其实是心态：以前改规则是「今天要花一天，还提心吊胆漏改」，现在是「改一处、跑一下、看报警确认」。规则不再是负债，而是可控资产。

四、踩过的坑

坑1：权限模型没理清，脚本读不到 DSL。 用默认账号的 token 去批量拉应用 DSL，一堆应用返回 403——默认账号对很多应用根本没权限。教训：治理脚本要用有全量读权限的服务账号 token，别用你顺手的那个个人账号。权限这一层不理清，后面全是假数据。

坑2：DSL 版本升级，导出结构变了，解析脚本全崩。 平台升级后，导出的 DSL schema 变了，extract_rule_segment 抠不到东西，检测脚本静默返回空、还报「全部一致」。教训：解析结果要做非空校验，抠出来是空的应当报错而不是当成「没差异」。别让脚本用「假的一致」骗你。

坑3：改完真源直接全量推线上，没灰度。 有一次规则渲染模板本身有个 bug，直接推到全部相关应用，等于一次性把所有应用弄坏。教训：真源→应用的分发要先灰度一两个应用验证，再全量。SSOT 让你「一处改动影响全局」，这是优点也是风险——影响面大了，更要有灰度闸门。

坑4：把「控制台手改」当成正常操作。 只要还有人能绕过流程、直接在 Dify 控制台手改线上应用的规则，真源就守不住。我们后来立了条硬规矩：线上规则的唯一合法修改路径是「改真源→渲染→分发」，控制台手改一律视为漂移，会被检测脚本揪出来。 治理不只是技术，也是流程纪律。

五、小结

低代码 LLM 平台让「造应用」变得极便宜，代价是「维护一致性」变得极贵。应用数量一过临界点，规则漂移是必然，不是意外。

治理的核心就一条 SSOT 原则，落成三步：

• 抽离：规则从 prompt 抽出来，落成结构化、版本化的单一真源，应用是真源的投影而非副本
• 检测：写漂移检测脚本，定时比对线上应用与真源，让漂移当天暴露
• 闭环：badcase 回灌真源而不是打补丁，让每个坑只踩一次

这套思路不绑定 Dify——Coze、扣子、n8n，任何「用低代码平台维护大量 LLM 应用」的团队都会遇到规则漂移，也都能套这套单一真源的治理框架。

核心一句话：别让平台的「创建便利」变成你的「维护地狱」，用工程纪律把规则钉在一个地方。