从一句话到模块化v8：智能体提示词工程的完整迭代实录-北京尧图网络

上次出的活让我意识到“会写提示词”和“能把提示词这个活干好”是两件事。2026年9月29日我把手头这个代号“唤醒”的智能体项目推送到了v8版提示词顺手把前因后果整理了一遍。一开始真的只是一段“你是一个客服”打天下的故事到后面变成了角色设定、边界治理、示例驱动、结构输出、自检回调、模块版本管理的完整流水线。把这八次迭代拆开看大部分问题不是模型笨是提示词工程没跟上。这篇笔记不打算讲高深理论就把我项目里真实发生的改版过程、每次为什么会改、改了之后指标怎么变、踩了哪些坑原原本本记下来。如果你的智能体也卡在“响应不稳定、偶尔幻觉、不按格式输出、多轮对话会忘事”这类问题上这篇内容应该能当一份现成的排查手册用。1. 为什么一个提示词要迭代八版1.1 项目背景与初始设定“唤醒”这个智能体起初的定位是一个面向售后场景的工单处理助手。用户把问题用自然语言抛进来它需要完成三件事第一从对话里抽取关键字段产品型号、故障描述、用户联系方式第二查询知识库定位可能的解决方案第三输出一段用户看得懂的、可直接执行的回复并且按预设格式写入工单系统。这个定位本身很明确但实际跑起来之后前几版提示词连“能用”都谈不上。用户问“我买的水壶底座漏水”它回了一长篇散文字段抽出来的是“水壶”和“漏水”用户真正想知道的“是否影响保修”“该联系哪个渠道”一概没回应。这类问题反复出现我才意识到不能再用写文案的思维写提示词得把它当成一个稳定运行的系统来设计和维护。1.2 提示词迭代的四个维度回看八个版本每次改版本质上都在四个维度里打转结构维度从一段话到大段落分区再到模块化模板和运行时变量拼接。边界维度从“什么都管”到“什么该管、什么不该管、管不了时怎么说”。能力维度从纯文本对话到少样本示例、工具调用、JSON Schema 强制输出。质量维度从靠运气到引入自检、回退、评测集和回归机制。这条主线是逐步清晰起来的不是一开始就设计好的。v1 时代的我根本没想过边界问题觉得提示词写得热情一点、话多一点模型就会好好干活。实际教训是热情不能约束行为只有明确的指令结构和可验证的输出约束才能。2. v1 → v8 版本演进实录2.1 v1 → v2从“一句话提示词”到结构化v1 的完整提示词就这么一句你是一个客服助手请根据用户问题回复。效果当然惨不忍睹。没有角色约束、没有输出要求、没有任何反幻觉机制模型会自由发挥用户问“这产品多少钱”它可能从训练数据里编一个价格出来。最要命的是不同轮次回答风格完全不同上午还称呼“您”下午就变成了“亲”。v2 的改动是周结构化。我把提示词拆成了几个区块角色定义、任务说明、输出要求、注意事项用 Markdown 的二级标题和列表明确分隔。虽然模型不一定会严格遵守但它给自己树立了一个“上下文框架”输出开始有了基本形状。这个版本的收益立竿见影至少不会答出散文了但格式还是忽好忽坏偶尔仍然会编造知识库中不存在的信息。这里有个体会结构化提示词不是为了好看而是给模型一个稳定的“工作台”。当你说清楚你是谁、要干什么、输出长什么样模型才不至于每次都在自由发挥的边缘试探。v2 的不足之处在于只有骨架没有血肉——它不知道好答案长什么样子也没有被明确告知什么情况不该答。2.2 v3 → v4边界约束与示例驱动v3 解决的是“越权”问题。我明确加上了适用范围和拒绝机制你只能处理本产品线售后相关问题。超出范围时请明确告知“不在支持范围”并建议用户转人工不要自行推测或编造。同时给出了一个判断清单含产品型号查询、故障排查、保修政策的属于可处理涉及价格谈判、人身伤害赔偿、攻击性内容的一律转人工。这版改完答非所问的比例明显下降但还有一个问题频繁出现模型有时会给出“看似合理但完全不打算执行”的建议比如“建议您把水壶放进冰箱冷冻两小时”。这种话术放在真实客服场景里是要出事故的。v4 引入了第一批 few-shot 示例。我给每个典型场景写了两到三组“用户输入 → 期望输出”的对照重点挑那些容易踩雷的输入比如模糊描述、多问题混杂、情绪化表达。示例的效果比我在提示词里写一百句“请注意不要胡编”都好使。为什么因为示例是在展示行为的参考坐标系模型通过类比学习到的是“这种输入应该对应这样质量的输出”而不是抽象地理解“要靠谱”。示例设计也有讲究不是随便找几条聊天记录塞进去就行。我后来总结出三个层次见后文 3.2 节。v4 在这个阶段只做到了第一个层次覆盖典型场景、教会模型输出格式和口吻。2.3 v5 → v6多轮状态管理与工具化输出v5 解决的是“失忆”问题。单轮回答看着没问题一旦用户追问“我刚才说那个型号还有吗”模型完全不记得上一句里提到的型号。这个问题的根因在架构提示词里只定义了单轮回答规则没有定义对话历史如何参与上下文。我的做法是引入显式的对话状态结构在每次请求时把最近五轮对话整理成历史消息列表当前用户输入数据库返回的上文关键字段三个部分按固定模板灌进提示词。同时要求模型在回答前先从上下文中提取“已确认信息”和“待确认信息”这样多轮追问时至少有一条记忆线索。v6 是本项目最重要的一个转折点把输出改成工具调用模式。我不再让模型自由生成一段话而是要求它先输出一个 JSON 字段抽取结果再输出一个生成回复的动作最后由代码层组装显示{ intent: query_product_info, slots: { product: XX-100, fault_desc: 底座漏水 }, action: search_kb, fulfillment: 您好XX-100 底座漏水通常与密封圈老化有关请先尝试更换密封圈……, need_human: false }这个改动的本质是把“思考”和“表达”解耦。模型先做受限的信息抽取动作确定以后再生成话术幻觉和乱答的空间被压缩了一大截。配合知识库检索我还会把检索到的候选答案片段原样拼进提示词要求模型只在给定片段内取信息源进行回复这条规则对防编造非常有效。2.4 v7 → v8自检机制与模块化工程v7 在 v6 基础上加了自检环节。具体做法是让模型在正式输出前先产生一段内部推理过程说明“用户真正要什么、我已确认什么、还缺什么信息、依据哪条知识库内容”然后再进入 JSON 输出。相当于让模型先把底牌亮给自己看把回答理由和证据链显式化再落到最终话术上。那段内部推理不会展示给用户只用于决定动作分支和降级逻辑。这一版最明显的收益是在欧盟那种“请立刻删除我的数据”之类的敏感请求当然我这里是售后场景下类似的超范围请求出现时模型不再硬着头皮答而是先识别出“不在支持范围”再走转人工分支。行为可解释性提高了很多。v8 干的是工程化的事。我把提示词从一大坨单文件拆成了模块化模板基础系统提示词、业务域规则、安全边界、少样本示例库、输出格式定义、运行时变量区。业务域规则和示例库独立存放运行时通过代码拼接注入当前用户信息、知识库摘要和历史消息。每一版都用 Git 打 tag每次修改都会跑一遍固定的回归评测集。到 v8 这个阶段提示词已经从“一段话”真正变成了一个工程制品。改动一行示例可以只影响示例库模块不牵动全局模板。这是我认为最值得借鉴的经验迭代到后期管理提示词的方式比提示词本身更重要。3. 提示词工程的核心技法拆解3.1 角色、边界、任务三件套任何任务型智能体提示词里至少要回答三个问题你是谁你能做什么不做什么你现在要产出什么。缺一个模型就会用自己的“常识”补一个而补出来的往往不是你想要的。角色设定要具体。不写“你是助理”而写“你是 X 产品线售后智能体隶属于 XX 客服系统负责产品参数查询、故障排查、保修政策解答”。这种身份细节会引出后续肯上浮的行为倾向比如更谨慎、更正式。边界设定要列举。光说“不要越权”没用要给出正面清单和负面清单。正面清单写清可以被处理的问题类型负面清单写清触发转人工的场景外加一句兜底无法判断时默认转人工不要猜。这种兜底指令能够明显减少模棱两可的回答。任务定义要产出导向。不要写“帮助用户解决问题”要写“根据以下步骤处理先抽取字段再查知识库再判断是否需要人工最后输出话术”让模型看到一个执行序列而不是一个目标口号。3.2 少样本示例设计的三个层次示例不是越多越好也不是随便找记录就能用。我后来把示例库分成三层第一层标准常规示例。每个高频场景两三条比如查询保修期、故障排查、查询参数。目的是教模型“正常回答长什么样”。第二层边界兜底示例。专门挑那些容易引发幻觉或越权的输入例如“这个能装汽车上吗”“你帮我骂一下隔壁客服”“我怀疑产品有质量问题要投诉媒体”。这些示例的期望输出往往是“不在支持范围转人工”。模型见过这类输入对应的正确行为后遇到类似情况就不容易自由发挥。第三层格式规范示例。挑一些包含多个问题、需要分点回应的输入示范如何在 JSON 的fulfillment里分条组织话术以及什么时候用列表、什么时候用段落。三层加在一起也就一二十条不会让提示词变得臃肿。我建议示例库独立成文件用“输入-期望输出-推理说明”三条字段组织运行时可裁剪注入不要所有示例全部堆进每次请求。3.3 结构化输出与指令遵循如果你的智能体要对接系统务必把输出格式定义成 JSON Schema 或类似结构并且写清楚每个字段的含义、类型、允许值。比在 prompt 里写“请以 JSON 返回”更强的是把字段名、枚举值、示例值全都显式列出。输出格式严格遵守 { intent: 枚举值query_product / troubleshoot / warranty / offline / other, slots: { product: 字符串用户提到的产品型号未提则填 null, fault_desc: 字符串故障描述摘要不得超过 20 字 }, source_ids: [知识库引用ID数组最多3个], need_human: 布尔值true 表示需要转人工, fulfillment: 字符串面向用户的最终回复200字以内 }这个格式配上代码层 JSON 解析和校验能保证即使模型偶尔格式漂移代码也能捕获并触发重试。v8 之后我还加了一条“若输出无法解析不要向用户展示直接按默认话术降级并告警”的兜底逻辑让系统在最坏情况下也不会把一坨错误 JSON 暴露给用户。4. 迭代过程中的评测与回归4.1 搭建私有评测集提示词迭代最大的坑是“修了这个问题另一个问题冒出来你甚至发现不了”。要解决它必须建立私有评测集而且这个评测集要在 v2 阶段就开始攒不要等全部完成。我的做法是整理 80 条左右的评测问题分五类常规查询、模糊描述、多问题混杂、超范围请求、情绪化表达每条都标注期望行为和最低接受标准。比如“用户问 XX-100 的水壶能泡茶吗”期望行为是“输出产品材质和适用场景如果知识库没有则明确说不确定”最低接受标准是“不得编造耐高温等指标”。评测集不只用于打分还用于交付验收和改版回归。每次改提示词我要跑一遍这 80 条人工看结果把每条标记为通过、部分通过、不通过并且记录不通过的原因。这样每次改版都有客观依据不再拍脑袋。4.2 跑批与人工抽样复核跑批我用的是最朴素的办法写一个批量脚本把评测集逐条喂给智能体每次随机打乱顺序并把温度设置到低档位收集输出到 JSONL 文件。然后我会用一段辅助脚本自动做关键字检查比如检查 JSON 能否解析、是否包含“转人工”等预期字段、输出是否超过字数限制。自动检查过了还得人工读一遍。说实话前几版很多“评分很高但实际像智障”的输出都是人工读出来的。我建议跑批的时候顺便把模型日志、提示词版本、知识库返回片段都记录下来。没有这些上下文你看到一条奇怪回答根本不知道它是哪来的排查成本高得离谱。这个过程现在有个时髦词叫“智能体行为审计”但本质就是追溯一条回答的产生链路。4.3 回归测试如何拦住“修了A坏了B”从 v5 开始我每次改提示词后都会跑回归。最大的体感是“没有回归测试你根本没胆量动示例库”。有几次我为了优化某个场景的输出把示例顺序调整了一下结果常规场景的话术风格全变了自动检查和人工复核一起拉响警报才没把问题带上线。我养成的习惯是任何改动哪怕只是改一个标点都要建一条分支、跑一遍评测集、记录分数变化然后合并。这里面最有价值的不是形式而是“可重放”的能力。提示词不是写出来就完事的它和代码一样需要审计、回滚和复现。5. 常见问题与排查技巧实录5.1 提示词越长效果反而越差这是反复遇到的现象。新增的规则太多模型抓不住重点或者被中间某段带偏。处理办法有三招把最关键的约束放到提示词的开头和结尾、把长示例拆到独立模块按需注入、每轮对话只注入与当前意图相关的规则区块而不是一股脑全塞。另外指令的优先级要明确。我会在最前面写一句“以下所有规则冲突时以【安全边界】最高优先级为准”。这句话看着土但能显著减少模型取巧绕开约束的情况。5.2 多轮对话“失忆”问题这个问题解法在 v5 已经讲过了这里补充一个细节不要只把对话历史原始文本堆进上下文而是先做一轮摘要或字段强化。也就是在喂给模型之前代码先把历史里已经出现的型号、地址、联系方式等实体抽出来放到“已确认信息”区。模型生成当前回复时直接引用这些字段而不是重新理解整段历史。这样既省 token又改善稳定度。5.3 模型不按格式输出如果模型偶尔输出非法 JSON先不要加更多提示词先看上下文长度是不是超了。上下文接近上限时模型尾部输出的质量下降得很快JSON 结构最容易坏掉。其次是温度设置尽量在 0.2 以下。再有就是重试机制代码检测到 JSON 解析失败时把错误信息拼回提示词让模型“看到了请修正后重新输出”。这个办法实测很有效比反复调提示词省钱多了。5.4 幻觉与编造信息幻觉的根因往往是知识来源不明确。只写“请根据知识库回答”没用因为模型不知道哪条知识库内容是可用的。我的解决方法是把检索结果原文分段编号后放进提示词并明确说你的回答只能在给定片段中找事实依据片段里找不到就说“资料库暂无相关信息”然后建议转人工。防幻觉不是靠道德说教是靠切断事实来源外的信息通路。6. 我踩过的坑与最后的经验回看 v1 到 v8我最后悔的不是开头太简单而是没有在第一天就建评测集。如果早点把 80 条测试问题攒起来能省下至少一半的瞎试时间。很多人觉得写提示词是个创作活试几轮就能出来但实际上它更像测试驱动开发改一点测一遍看变化再改一点。还有一个经验是提示词迭代到一定阶段瓶颈往往不在提示词本身而在数据流和系统设计。v6 的工具调用、v7 的自检、v8 的模块化其实都是系统结构问题不是文字问题。如果你发现怎么调提示词都没用建议停下来看架构是不是该把某个功能拆成函数调用或者把某些逻辑从提示词里挪到代码里。最后一个实用小技巧给每次迭代留下一条“现场快照”。不只是保存提示词还要保存当时用的知识库片段、测试集输出、失败案例。过三个月回看这些快照会告诉你当年为什么做了那个决策比任何复盘笔记都直观。“唤醒”项目做到 v8离“完美”还远但已经是一个可以被维护、被评测、被信赖的系统了。下一步我打算把示例库改成自动扩充机制用线上失败样本反向生成新评测用例让系统越用越稳。如果你也在折腾自己的智能体希望这份迭代笔记能让你少踩几个我踩过的坑。

从一句话到模块化v8：智能体提示词工程的完整迭代实录

相关推荐

市场营销课程论文AI生成：4步拿到理想分数的实操流程

2026成都宠早早宠物美容培训创新办学模式研究

论：人工智能=描述+算法！

更多资讯

deadline前两周，我靠这个工具把论文从大纲补到终稿

毕业论文图表画到崩溃？这个科研绘图工作台帮我三天搞定全部数据图

Design Review 插件功能总结：用 Skills 与 Canvas 搭建前端设计质量审查工作流

五：Agent 可观测性与成本优化——从“能跑”到“好管”，TaoToken 统一 Key 下的链路追踪与 Token 账本

Moli是什么：专为AI Agent打造的Rust开源无头浏览器终极指南

tldr 别名页机制与 docker stop 完整指南：从保加利亚语别名声明到 docker container stop 实战用法

今日更新

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？