「我从不会批准绕过持续集成（CI）的代码合并请求。」一位工程师写道，「但我见过几十支团队——包括我自己待过的——部署提示词变更时，零验证就上线。」
这句话戳中了一个正在蔓延的盲区。当大模型应用从Demo走向生产，提示词（prompt）的部署方式却还停留在「编辑字符串、推送、祈祷」的原始阶段。问题是：提示词变更就是逻辑变更，它改变系统如何处理不确定性、如何在负载下响应、如何应对没人枚举过的边界情况。文本形式不等于安全。
代码与提示词的部署鸿沟
现代软件工程对代码变更有一整套防护机制：自动化测试、代码审查、持续集成、灰度发布。但同样的团队，面对提示词却直接编辑配置文件就推送。
这种双重标准的风险正在放大。随着智能体（agentic）系统规模化，提示词不再只是聊天机器人的开场白，而是驱动多步骤决策的核心逻辑。一个被修改的提示词可能让客服机器人突然承诺无法兑现的退款，或让代码助手生成有安全漏洞的建议。
作者提出的核心观察是：我们对待提示词的方式，既不像代码也不像配置，而是 worst of both——像配置一样随意编辑，又像代码一样执行关键逻辑。这种状态无法持续。
供应链安全的现成答案
解决方案可能来自一个意想不到的领域：软件供应链安全。
过去五年，Sigstore、SLSA、in-toto 等工具解决了一个相关问题——如何密码学证明生产环境的二进制文件就是经过检查的那个。这套机制可以平移到提示词管理：
内容寻址哈希（content-addressable hashing）：用提示词文本的哈希值唯一标识它。两个哈希相同的提示词，字节级完全一致。格式如 prompt[sha256:abc123...]。
签名证明（signed attestations）：密码学声明，记录「该哈希于某日期通过某版本评估套件」。谁见证、什么标准、何时通过，全部可验证。
验证门禁（verification gates）：部署系统拒绝任何缺乏有效证明的制品。没有签名，就无法进入生产环境。
这套流程让「生产环境运行着哪个提示词」有了确定答案，不再依赖Git历史考古或信任配置面板的状态。
模型漂移：被低估的复现难题
但作者刻意指出一个大多数讨论回避的问题：评估可复现性。
当底层模型版本漂移时，上个月的证明可能毫无意义。针对 gpt-4o-2024-08-06 的通过记录，不保证在 gpt-4o-2024-11-20 上的行为一致。这里不存在免费午餐——要么在证明中锁定模型版本（承担停留在旧版本的运维成本），要么每次模型更新都重新评估（承担评估成本）。
另一个更根本的疑问：「通过评估」真的是正确的门禁吗？代码通过测试仍可能带Bug上线；提示词评估更粗糙——它采样行为，而非证明正确性。
身份危机：提示词是代码还是配置？
作者认为，大多数团队尚未回答这个分类问题，这正是混乱的根源。
如果视为代码，提示词应走CI流水线：版本控制、自动化测试、代码审查、构建制品。如果视为配置，则应进入配置管理系统，具备环境隔离、变更审批、快速回滚能力。
当前默认状态——「文本文件，有提交权限的人都能改」——是两种模式的缺点集合。明确选择其中一种，都比现状更安全。
作者提到 Prem Pillai 在 rp1 博客有更详细的架构分析，但原文未展开具体内容。
为什么这件事现在重要
智能体系统的兴起正在改变提示词的角色。从单次对话到多步骤任务执行，提示词承担的决策权重在指数级上升。部署流程的滞后意味着：我们可能在用管理CSS颜色的方式，管理核心商业逻辑的变更。
供应链安全工具的迁移应用提供了一个务实路径——不需要从零发明，而是适配已有成熟方案。但技术方案之外，更需要组织决策：承认提示词的工程严肃性，结束「文本例外论」。
当模型能力持续迭代，提示词工程会不会成为需要专门资质认证的岗位？评估成本与模型更新频率的权衡，会催生新的工具市场吗？
热门跟贴