🌊 专注 AI 大模型与前沿科技深度解析，习惯从工程师视角拆解技术热点，让我们一起在技术浪潮中保持清醒与好奇 🚀

当AI治理从“写制度”变成“写代码”：一个普通开发者该看懂什么

去年秋天，我给一个做客服机器人的小团队帮忙。他们的模型上线三周，被用户诱导着泄露了一段内部提示词，还在一次对话里给用户“承诺”了一个根本不存在的退款政策。复盘会上，产品经理拍着桌子说：“我们明明写了《AI使用规范》啊！”

规范确实写了，整整十二页，躺在共享盘里。但模型在运行时，一个字都没读到它。

这件事让我开始认真琢磨一个正在发生的转向：AI治理正在从“政策层面”下沉到“运行时执行”。过去我们谈治理，谈的是原则、红线、评审委员会；现在越来越多的团队在问：这些原则，怎么变成模型跑起来那一刻真正生效的代码？

30 秒结论

• 本文判断：AI治理的有效性，正在从“文档写得好不好”转移到“运行时拦不拦得住”。政策是意图，运行时执行才是事实。
• 适用对象：在校学生、转行者，尤其是正在做第一个带 LLM 的项目、需要把“安全/合规”写进作品集的人。
• 不适合谁：已经在做大规模模型对齐研究、或需要完整企业级治理平台方案的读者——本文只讲清原理和最小可用做法，不覆盖组织级流程。
• 一句话能力：你能在项目里加一层“运行时护栏”，并说清楚它拦什么、怎么拦、拦错了怎么办。这比在 README 里写一句“本项目遵循负责任 AI 原则”有用得多。

关键证据

证据一：政策与执行之间存在结构性缺口。 一份治理文档描述的是“应该发生什么”，而模型输出是概率采样出来的“实际发生了什么”。两者之间没有自动映射。任何只停留在文档层的治理，本质上都是“事后追责”，而不是“事中拦截”。

证据二：提示词注入让“信任模型自觉”彻底失效。 当用户输入可以覆盖系统指令时，模型的行为边界就不再由开发者单方面决定。这意味着治理必须放在模型之外的一层——输入进来先过筛，输出出去再校验，而不是指望模型“记住规矩”。

证据三：运行时执行是可测试的。 这是最关键的一点。政策无法写单元测试，但一个输入过滤器、一个输出分类器、一条规则引擎，都可以写成测试用例。可测试，才可迭代；可迭代，才谈得上治理。

展开说明：运行时护栏到底长什么样

把治理落到运行时，最小可用的形态是“三层夹心”：输入侧、生成中、输出侧。对个人项目来说，不必三层都做，但要知道每层管什么。

输入侧——先挡住不该进来的。 最典型的是提示词注入和越权请求。一个朴素但有效的做法是维护一个“意图分类器”，在请求进入主模型前判断它是否属于允许的意图集合。下面是一个极简示意（伪代码，重点是结构不是语法）：

ALLOWED_INTENTS = {"查询订单", "咨询政策", "闲聊"}

def guard_input(user_text: str) -> bool:
    intent = classify_intent(user_text)   # 可先用小模型或规则
    if intent not in ALLOWED_INTENTS:
        return False
    if contains_injection_pattern(user_text):  # 如“忽略以上指令”
        return False
    return True

这段代码的价值不在于它多聪明，而在于它可被测试：你可以为 contains_injection_pattern 写十几个用例，跑 CI。面试里如果被问“你怎么保证模型不越界”，能说出“我在入口做了意图白名单并写了测试”，比背原则强得多。

生成中——给模型一个可执行的约束。 系统提示词里写“不要承诺退款”，模型可能照做也可能不照做。更稳的做法是把关键约束变成结构化输出要求，比如强制模型返回 JSON，其中 commitment 字段只能是枚举值。这样约束从“自然语言请求”变成了“schema 校验”。

输出侧——最后一道闸。 输出过滤是最容易落地的一层：敏感词、PII（个人身份信息）正则、以及一个轻量的输出分类器判断“这段话是否包含未经授权的承诺”。拦下来之后不要直接报错给用户，而是走兜底话术。这里有个常被忽略的点：兜底路径本身也要被测试，否则护栏触发时反而制造了新的坏体验。

一个完整的请求链路大致是：输入过闸 → 主模型生成 → 输出过闸 → 兜底或放行。每一道闸都是一个可以独立测试的函数，这就是“治理变成代码”的实质。

落地建议：今天就能做的 3 件事

1. 给你的项目加一个 guardrails/ 目录，里面至少放两个函数：check_input 和 check_output，并为它们各写 5 条测试用例（正常 3 条、恶意 2 条）。这一步就能让作品集里多出一个“可验证的安全层”。

2. 把一条治理原则翻译成一条可执行规则。比如“不泄露内部信息”→ 输出侧正则匹配内部字段名；“不越权承诺”→ 输出 schema 里加枚举字段。选一条，做透，别贪多。

3. 记录拦截日志。每次护栏触发，记下输入摘要、触发规则、时间。这既是调试依据，也是你向别人解释“我的系统怎么防”的证据。日志字段设计本身就是个不错的面试话题。

风险与反例

反例一：护栏过严，把正常用户挡在门外。 意图白名单最容易误伤——用户问了一句边界模糊的话就被拒。所以护栏必须有“降级放行 + 人工/日志复核”的通道，而不是一刀切。治理的目标是降低风险，不是消灭交互。

反例二：把运行时执行当成万能药。 护栏能拦已知模式，拦不住新颖的对抗样本。它降低的是“常见事故”的概率，不是提供绝对保证。任何声称“上了护栏就安全”的说法都值得怀疑。

反例三：只做输出过滤，不做输入过滤。 输出过滤是事后补救，注入已经发生、上下文已被污染。对涉及工具调用（比如模型能触发退款 API）的场景，输入侧和“生成中”的结构化约束才是关键。

最后回到那个客服机器人的故事。他们后来做的事很朴素：在入口加了意图白名单，在输出加了承诺字段的 schema 校验，把十二页规范压缩成了两个函数和十几条测试。规范还在，但它第一次真正跑了起来。

治理不是写给别人看的文档，是跑在请求链路里的那几行代码。你不需要一个大平台才能开始，你只需要一个 check_input 和一个 check_output。