做 AI agent 开发的人应该都有这个体验：系统提示词写在一个巨大的文本块里，改一次提心吊胆一次。
一个生产环境的 agent，提示词动辄几百行。里面塞了角色设定、工具描述、输出格式约束、few-shot 示例、安全限制、异常处理……但凡多一个工具或少一个参数，就得在那一大坨文本里翻来找去。更可怕的是，多人协作的时候，两个开发者改了同一个提示词的不同部分，合并时直接冲突——而且没有 diff 可看。
Google Cloud 最新的一篇博客提出了一个方案：Prompts-as-Code，把提示词当代码管理。
过去的问题在哪
先说清楚为什么传统的提示词管理会出问题。
AI agent 进生产之后，系统提示词不再是"写一次就不动"的东西。它会随着 agent 功能的迭代、工具接口的变化、安全策略的调整而频繁改动。在一个典型的 agent 项目里，提示词改动的频率可能比业务代码还高。
但问题是，提示词的存储形式是一个巨大的文本文件。没有模块化、没有依赖管理、没有类型检查。改了一行，你不知道会不会影响其他部分的功能。更糟的是，很多团队直接把提示词写在代码里或者数据库里，版本控制全靠手动标记。
怎么说呢，这种做法在 demo 阶段没问题，但进了生产就是定时炸弹。
我见过一个真实的案例：某个 agent 因为系统提示词里一个工具的描述文本少了一个参数说明，导致 agent 反复调用错误的 API，每次调用都返回 400，但 agent 不报错，只是重试——白白烧了三个小时的 API 费用。
这就是配置漂移（configuration drift）的典型表现。没人注意到那行描述被改过，因为改的人只是"顺便调整了一下格式"。
模块化的思路
Prompts-as-Code 的核心想法其实不复杂：把提示词拆成模块化的 skill 文件，每个文件负责一个功能，然后用构建时的 transpiler 把它们组合起来。
举个例子，一个客服 agent 的提示词可以拆成：
一个是角色定义文件（`role.prompt`），描述 agent 的身份和沟通风格。一个是工具描述文件（`tools.prompt`），列出所有可用 API 的定义。一个是安全约束文件（`safety.prompt`），规定 agent 不能做什么。还有一个是输出格式文件（`format.prompt`），控制返回结构。
每个文件独立维护，独立版本控制。改工具描述的时候，不会影响到角色定义。这看起来基本到不值得说，但说实话，大部分团队连这步都没做到。
构建时校验的价值
真正有意思的是后面的部分。Google Cloud 的方案里，transpiler 在构建时会做静态验证——检查 prompt 里引用的工具是否都存在、参数是否匹配、有没有未闭合的模板变量。
翻了下原文，发现了一个有意思的细节：这种构建时校验能捕捉到运行时才能发现的问题。比如一个 tool 的 description 里写了一个 JSON schema，但这个 schema 和实际 API 的 schema 不一致——按以前的写法，agent 会构造出错误的参数，直到调用失败才发现。用了 transpiler 之后，构建阶段就能警告你 schema 不对齐。
这里容易被忽略的是，这种验证不是简单的文本匹配。它需要理解 prompt 里引用的工具、参数、约束之间的关联关系。本质上是在提示词层引入了编译的概念。
CI/CD 集成
模块化之后，下一步就是把提示词纳入 CI/CD 流程。
一个常见的做法是：每个 prompt 文件变更都触发 review -> 构建时校验 -> staging 环境的 agent 测试 -> 灰度发布 -> 全量上线。整个过程和普通代码发布的流程一致。
但事情没有这么简单。提示词的测试比代码测试难搞得多。你没法写一个"断言这个 prompt 输出正确"的单元测试，因为 agent 的行为是概率性的。Google Cloud 的方案提到的是用 EvalOps 来做评估——在 staging 环境跑一组测试用例，对比前后两个版本的 agent 输出质量。
不过，真正的问题不在技术，而在习惯。很多团队把 prompt 当成"配置"而不是"代码"，所以不会用代码的流程来管理它。Prompts-as-Code 改变的不只是工具链，还有开发者的 mindset。
对开发者的实际影响
对个人开发者来说，这套方案看起来有点重。你一个人维护一个 agent，搞什么 CI/CD、模块化 prompt，确实有点过。
但如果是团队协作，差别就很大了。几个关键收益：
一个是 code review 终于有意义了。以前 review prompt 的改动，就是看一个几百行的文本 diff，根本看不出改了哪里。模块化之后，diff 只显示你真正改的那个文件。
另一个是回滚变得简单。某个 prompt 改坏了？直接把那个文件 revert 到上一个版本就行，不会影响其他部分。
还有就是多人协作不会踩到彼此。两个开发者可以同时分别改 role 和 tools 文件，merge 的时候不会有冲突——因为根本不在一个文件里。
还没解决的问题
那问题来了，这套方案有没有边界？Prompts-as-Code 方向是对的，但有几个边界情况还没见到好的方案。一个是动态 prompt 怎么办？很多 agent 的提示词是运行时拼接的，根据用户输入动态插入上下文。这种动态部分怎么模块化？另一个是多模态 prompt 的管理——图片、音频、视频输入的描述怎么和文本 prompt 统一管理？
这些问题等更多实践出来了再看看。但起码现在，提示词不再是一坨无法管理的大文本了。
关于维基框架
维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。
官网：framewiki.com
Gitee：gitee.com/wiki-framework
GitHub：github.com/wiki-framework
示例项目：gitee.com/cdkjframework/framewiki-example
📄 许可证：MulanPSL-2.0（木兰宽松许可证，第2版）
