从提示工程到治理工程：AI安全的范式转变

从提示工程到治理工程

近日，一位开发者在 Reddit 上分享了一项名为「hazard scan（危险扫描）」的新功能，并发出挑战："能破解就来破解（break it if you can）"。这个看似简单的帖子背后，折射出 AI 应用开发正在经历的一个重要范式转变——从「提示工程」（Prompt Engineering）走向「治理工程」（Governance Engineering）。

过去两年，随着大语言模型（LLM）的普及，「提示工程」成为最热门的技能之一。开发者们精心设计输入指令，试图让模型输出更符合预期的结果。然而，这种做法本质上是一种「输入层」的优化，它并不能从根本上保证系统的安全性、合规性与稳定性。当 AI 从演示走向生产环境时，仅靠精妙的提示词远远不够。

什么是治理工程？

超越提示词的系统性思维

「治理工程」这一概念的核心在于：将 AI 系统的安全与合规视为一套可工程化、可验证、可持续运行的系统性机制，而非依赖单点的提示技巧。

如果说提示工程关注的是「如何让模型说对的话」，那么治理工程关注的是「如何构建一套机制，确保模型在任何情况下都不会说出危险的、违规的或有害的话」。两者的核心区别在于：

• 提示工程是被动的、脆弱的，容易被越狱（jailbreak）攻击绕过；
• 治理工程是主动的、系统的，通过多层防护机制来兜底。

这种转变类似于软件开发中从「写好代码」到「建立完整测试与 CI/CD 流程」的演进。单纯写出好代码不够，你还需要一整套保障质量的工程体系。

hazard scan 的定位

从帖子描述来看，这位开发者创建的「危险扫描」功能，正是治理工程理念的一次具体实践。它的作用大概率是在 AI 系统的输入或输出环节，主动扫描并识别潜在的危险内容——例如恶意注入、越狱尝试、有害信息生成等。

这种「扫描器」的思路，本质上是在模型之外增加一道独立的安全检查层。它不依赖模型自身的「自律」，而是通过外部机制进行强制约束。这正是治理工程与提示工程最根本的区别所在。

为什么「治理」比「提示」更重要？

提示注入攻击的现实威胁

近年来，提示注入（Prompt Injection）和越狱攻击层出不穷。攻击者通过精心构造的输入，诱导模型忽略系统指令、泄露敏感信息或生成有害内容。仅靠系统提示词（System Prompt）中的"你不能做某某事"这类约束，在面对足够狡猾的攻击时往往形同虚设。

开发者"break it if you can"的公开挑战，实际上就是一种**对抗性测试（Red Teaming）**的思路。通过邀请社区成员尝试破解，可以在真实攻击场景中检验防护机制的鲁棒性。这种开放式的安全验证，本身就是治理工程实践中不可或缺的一环。

从合规角度看治理的必要性

随着全球各地 AI 监管法规的落地——例如欧盟《AI 法案》——企业部署 AI 系统时面临的合规压力越来越大。仅靠提示词无法满足审计、可追溯性和责任界定的要求。治理工程提供了一套可记录、可审查的机制，让 AI 系统的每一次决策都有据可查、有规可依。

治理工程的实践要点

对于希望将 AI 应用部署到生产环境的团队来说，可以从以下几个维度构建治理体系：

1. 输入防护层：在请求到达模型前，进行内容扫描、意图识别与危险模式检测（如本文提到的 hazard scan）。
2. 输出校验层：对模型生成的内容进行二次审查，过滤有害、违规或不合规的输出。
3. 持续对抗测试：通过 Red Team 演练，主动发现并修补系统漏洞。
4. 可观测性与审计：记录关键决策路径，确保系统行为可追溯、可解释。
5. 多层冗余机制：不依赖单一防护点，构建纵深防御体系。

结语：AI安全是一场持续的工程实践

这位 Reddit 开发者以「破解挑战」的形式推出危险扫描功能，其价值不仅在于工具本身，更在于它传递了一种理念：AI 的安全不是一次性的提示词优化，而是一项需要持续投入的工程实践。

随着 AI 深入到企业核心业务，「治理工程」很可能会像当年的「DevOps」和「安全工程」一样，成为 AI 应用开发的标配能力。对于开发者而言，是时候把注意力从「如何写出更好的提示词」，转向「如何构建一个足够可靠的治理体系」了。

你可能没注意到，由于该功能目前仅来自单一开发者的分享，其实际防护效果尚待社区的对抗测试来验证。但无论如何，这种从提示工程迈向治理工程的思路转变，代表了 AI 落地过程中一个值得关注的方向。