大兴新媒体产业基地有一家做客服系统的小公司，去年上线了一个 AI 客服 Agent，老板本来指望它把 70% 的重复问答接走，结果上线两个月，用户投诉反而多了。最典型的投诉是：用户问”发票怎么开”，Agent 回答了一段”我们的优势是……”；用户问续费价格，它扯起功能介绍来。质检团队把对话记录拉出来一看，血压直接上来了——不是模型不行，是 Agent 压根没搞明白自己在什么场景、面对谁、哪些话能说。后来产品经理把系统提示词翻开，问题一目了然：那一大段提示词里，产品功能描述占了四分之三，边界规则只有三行，输出格式完全没约束。改动不到两个小时，上线两周之后投诉率明显下来了。
这个案例在大兴的 AI 企业里挺有代表性。很多团队习惯把精力放在模型选型、数据准备上，对提示词——尤其系统提示词——的态度是”能跑就行”。但说句实在的，Agent 的每一次输出都是在提示词划定的框架里长出来的，提示词写不清楚，后面再多调优都是给一个方向不明的模型打补丁。这篇文章把提示词工程怎么做、系统提示词怎么管，按一套能落地的流程讲一遍，供做 Agent 的团队对照。
先分清两类提示词：系统提示词和用户进来的话
做提示词工程，头一件事是把”系统提示词”和”用户消息”分清楚。系统提示词是你在后台预设好的那一段指令，它定义 Agent 的角色、目标、知识范围和行为边界，用户永远看不到，也不该被用户的内容覆盖；用户消息是用户当场输入的那句话，是动态的、不可控的。Agent 的最终回答，是模型在”系统提示词约束下的用户消息”上生成的。边界感在这里非常重要：用户消息可能问任何问题，而系统提示词决定了 Agent 面对任何问题时，哪些能答、哪些不能答、按什么口径答。
大兴的团队里有个常见误区：把系统提示词和开场白混为一谈。系统提示词管的是行为逻辑，开场白只是它的外化表现。比如一个电商客服 Agent，开场白是”您好，我是XX旗舰店客服，有什么可以帮您”，而系统提示词里写的是”你是XX旗舰店客服，只回答与商品、订单、售后相关的问题，价格以页面标注为准，不承诺任何额外优惠”。前者用户看得见，后者才是 Agent 行为的总开关。很多 Agent 跑偏，就是因为总开关没写好，开场白再漂亮也白搭。
还有个容易被忽略的点：系统提示词是有”承重”作用的。知识库、工具调用、权限规则，最终都要通过系统提示词跟模型交代清楚——什么时候调知识库、什么时候调用 API、什么时候转人工。提示词工程做得像样的团队，系统提示词不只是几行字，而是一份被当代码来维护的”配置”。带着这个视角，后面每一步都好理解了。
再补一个容易漏的细节：系统提示词是要给团队其他人看的。一个人写的提示词，如果只有自己看得懂，那它就失去了可维护性。好的系统提示词有一个朴素的衡量标准——一个新同事接手这个 Agent，能不能在一刻钟内说清楚它能干什么、不能干什么、改哪里会影响什么。很多团队把提示词写得像密码，换个人就没人敢碰，这种 Agent 的命运基本就是上线即冻结，业务一变，它就废了。写提示词的时候，副驾驶上永远坐着一个未来的接盘同事。
系统提示词写不好，通常是这四个毛病
把常见的问题系统化一下，大概是四类。头一类是”角色目标模糊”。提示词里写”你是智能客服”，等于没写——智能客服是什么？面对谁？答什么？边界在哪？全没交代。第二类是”约束条件缺失”或”约束自相矛盾”。比如前面提了一句”如实回答”，后面又写”产品有问题时不要直接承认”，模型同时收到两条打架的指令，输出就会飘忽不定，时好时坏。
第三类是”输出格式没约束”。别小看这一条，同样一段回答，模型可能一会儿给你列要点，一会儿给你写大段散文，一会儿又把不该给的内部信息兜出来。给 Agent 指定明确的输出结构——先给结论还是先给理由、要不要编号、长度范围、能不能用 emoji——直接决定终端用户的体验是不是稳定。第四类是”提示词里塞了会过期的信息”。有些团队把活动价格、库存数量直接写死在提示词里，活动一结束忘了改，Agent 就继续按旧价格回答，这已经不是提示词写得好不好的问题，是运营事故的前奏。
这四个毛病怎么自查？有个笨办法：把系统提示词打印出来，找两个没参与开发的同事读一遍，让他们说说”这个 Agent 到底能干什么、不能干什么”。如果两个人说法不一致，提示词就该重写了。提示词工程本质上是在跟模型沟通需求，需求说不清，实现必然跑偏。
提示词工程四件套：角色、目标、约束、输出格式
一份合格的系统提示词，至少要有四个部分，缺一不可。角色部分定义”你是谁”：平台、职能、语气基调，比如”你是XX财税平台的顾问，语气专业但不端着，回答控制在 200 字以内”。目标部分定义”你负责解决什么”：这个 Agent 存在的目的，比如”帮用户理解税收政策要点、判断适用情形，不负责具体的申报操作”。目标定清楚，模型才知道往哪个方向使劲。
约束部分是最花心思的：包括知识边界（哪些能答、哪些明确转人工）、行为红线（不承诺、不编造、不泄露）、口径要求（以官方发布为准，拿不准时如实说明）。这一部分宁可写得啰嗦，也别留模糊地带。输出格式部分定义”怎么答”：要不要分点、要不要给例子、长度上限、语气词规范。四件套齐全的提示词，哪怕不完美，Agent 的行为也基本可控，后续迭代也有明确抓手。
给个结构参考：可以用”你是/你的目标/你能做什么/你不能做什么/回答时注意/输出格式”这样的段落把四件套串起来，每段用一句话以内的标题开头，模型解析起来也清楚。注意别把四部分揉成一团，段落分明比文采重要得多。写完之后跑一轮”边界测试”——专门问它不属于服务范围的问题，看它会不会越界——是这个环节的验收动作。
专业领域怎么喂：生物医药基地的场景给提示词出难题
提示词工程里最难的一类，是专业领域强的 Agent。大兴生物医药基地有不少做医疗器械、药品供应链的企业，我也接触过其中两家做院内服务 Agent 的团队，他们的提示词管理比一般客服场景复杂得多。难点在三点：专业术语多、口径必须严谨、出错的代价高——一个跟医生说错的用法说明，后果不是”体验变差”，而是直接影响使用安全。
这类 Agent 的提示词里，通常要放三样东西。头一样是”术语表”：把产品涉及的核心术语、别名、通俗说法对应起来，模型才不会把”说明书”和”操作指南”混为一谈。第二样是”口径清单”：哪些内容必须回到官方数据库取数、哪些场景必须转人工、哪些话术一字不能改，都要写得明明白白。第三样是”风险提示”：告诉模型当答案涉及安全使用、不良反应、禁忌事项时，要格外克制，宁可少说不能说错。
专业场景还有个现实问题：提示词本身会越写越长。长提示词不是问题，问题是没有结构。建议把术语表、口径清单、风险规则拆成独立模块，必要时用”当用户问X时，执行Y”的条件式写法组织，既方便维护，也能减少模型在长文本里”迷路”的概率。生物医药基地的同行经验值得所有做专业 Agent 的团队参考：专业 Agent 的提示词，本质是一份浓缩的合规手册。
提示词的版本管理：改一句，要有记录能回滚
提示词写得再好，不改是不可能的——业务在变，模型在升级，用户反馈也会不断倒逼调整。但”改”这件事，很多团队做得相当随意：产品经理在后台对话框里直接改，改完就生效，改坏了自己都不知道是哪一步造成的。把提示词当成代码来管，是提示词工程从”会写”到”会管”的分水岭。具体来说，给提示词建版本号，每次修改记录变更人、变更时间、变更原因，主版本发布前先在一个测试环境里跑一轮。
版本管理的好处，在回滚那一刻体现得最充分。我们接触过大兴一家做新媒体工具的公司，运营觉得 Agent 回答太死板，让提示词”更活泼一点”，结果改完当天，Agent 开始把表情包和网络用语带进专业回答，客户直接炸了。好在他们做了改动留痕，十分钟之内把上一版提示词回了滚，事故的影响面被压到很小。反过来，如果提示词没有版本，出了事只能凭记忆猜哪句改坏了，恢复就要靠撞运气。
还有一条建议：提示词和知识库、话术库的版本要联动。一个 Agent 的出问题，往往不是提示词单方面错了，而是提示词引用的知识库版本和服务条款版本对不上。把三者放进同一个发布流程里管理，哪次发布出了问题，一次能回滚到一致的组合，比单独回滚提示词靠谱得多。
测试怎么跑：从 20 个用例到回归集
改了提示词怎么知道改对了？靠感觉不行，得靠用例。起步阶段，建议为每个 Agent 准备一份 20 条左右的测试集，覆盖四类情况：正常问题（能答且答对的）、边界问题（勉强够着服务范围的）、越界问题（不该答的）、危险问题（诱导、对抗、要套话的）。每次改完提示词，把这份测试集完整跑一遍，看有没有哪条从”对”变”错”了——这叫回归测试，是提示词工程里投入产出比很高的一步。
测试集要跟着业务长。每出现一类让 Agent 翻车的新问题，就把这个案例补进测试集，防止它下次再犯。三个月下来，20 条的测试集会慢慢长到五六十条，覆盖越来越全，回归的置信度也就越来越高。测试的执行可以交给简单的脚本：把问题和期望回答预先写死，跑完后人工抽查差异，不用上多复杂的技术。
这里有个容易被忽略的细节：测试时的模型版本要和线上一致。同一个提示词，换一个模型版本，输出可能完全不同。大兴不少团队在测试环境里用新模型测，线上还是旧模型，测出来的”通过”根本没有意义。把”线上模型版本+提示词版本+知识库版本”锁成一个测试固定的组合，回归结果才有参考价值。
再往前一步，可以加一道灰度流程：新提示词先在占总流量一成左右的入口上跑几天，观察反馈和指标，没问题再全量。灰度听着麻烦，实际操作很简单，线上配置里把流量切一部分到测试版本就够了，关键是养成习惯。大兴一些团队吃过改完全量上线、第二天又回滚的亏，就是跳过了灰度这一步。提示词改动看着小，影响面往往是全量用户，多一道灰度，等于多一道保险。
把提示词工程当流程建，而不是当文字写
把前面几节串起来，提示词工程其实是一条流程：需求明确（角色目标约束）→ 草稿写作 → 边界测试 → 上线 → 线上监控 → 问题复现补进测试集 → 定期迭代 → 版本发布。这条流程跟软件开发的生命周期高度重合，所以最理想的做法是把它嵌入现有的研发流程里：产品经理负责提需求，工程师负责把提示词结构化和版本化，运营负责从用户反馈里提炼问题，质检负责回归把关。提示词工程不是一个岗位的活，而是一套协作机制。
大兴区这两年 AI 应用企业扎堆，新媒体产业基地、生物医药基地周边，做 Agent 的团队越来越多，但大部分团队在提示词管理上的投入，还停留在”写出来能跑”的原始阶段。眼下的差距，就是未来打磨 Agent 效果的杠杆所在。一个团队如果把系统提示词、测试集、版本管理这老三样做扎实，即便模型不换，Agent 的质量都能肉眼可见地往上涨一截。
这里也想多说一句组织层面的现实：提示词工程的推进，阻力往往不在方法，而在流程轻重。团队小的时候，一个人身兼数职，写提示词、调模型、盯反馈都是他，流程太重反而跑不起来，这时候先保住改前留档、改后测试两条底线就够了；团队上了十个人、Agent 面向的客户多了，再逐步补上版本管理、回归集、灰度这些环节。提示词工程的成熟度要跟团队规模匹配，一上来就照搬大厂的重流程，大概率坚持不了三个月。先把底线立住，再谈锦上添花。
最后给两条实操提醒。一条是：每次改提示词之前，先问三个问题——改什么、为什么改、怎么验证改对了；答不上来就再想想，别急着动手。另一条是：提示词里的每条规则，都要能回答”如果删掉它，最坏会发生什么”；答不上来的规则，大概率是没用的装饰。做 Agent 的团队把这两条当日常习惯，提示词工程就算真正落地了。
需要相关服务？联系我们免费咨询
九五星球企服提供公司注册、代理记账、商标注册、财税咨询、高新申报、网站开发等一站式企业服务。可以先免费咨询看看，觉得合适再合作，不推销。
免费小工具推荐：
联系方式：
- 电话/微信：18510693502
- 扫码添加专业经营合规顾问，免费咨询 ↓
