企业官网建设流程全解析

上个月把“唤醒”这个内部智能体的提示词从v1一路迭代到v8，中间几乎每两天就大改一版。这两天项目告一段落，我重新把整个过程翻了一遍，趁着记忆还热，把每一步的关键改动、触发原因、真实效果和翻车现场都记下来。如果你也在做智能体开发，尤其是被提示词折磨得“感觉哪里不对但又说不出哪里不对”，这篇笔记应该能帮你少走几轮弯路。

先说清楚“唤醒”是干嘛的。它是一个面向企业内部运营场景的智能体，核心任务是从存量文档、历史工单、项目复盘资料里，把可复用的操作经验“唤醒”成能直接指导行动的建议。上线第一周，我收到的业务反馈几乎是一边倒的差评，运营同事甚至直接甩了一句：“这东西还不如我翻文档快。”当时我很不服气，觉得模型能力没问题啊，后来才明白，问题全出在提示词上——它停留在“幼儿园水平”。这八轮迭代，其实就是一个把提示词从“一句需求描述”打磨成“一套可维护的逻辑系统”的过程。

这篇笔记不会讲什么高深理论，就是实打实的版本演进记录：每一轮为什么改、改了什么、效果怎么样、踩了什么坑。适合正在搭智能体但总觉得差点意思的朋友，也适合那些想系统化梳理提示词工程方法的人。

1. 项目出了什么问题，才让我走上八轮迭代的路

1.1 “唤醒”到底要唤醒什么

很多团队做内部知识库工具，第一反应是做个搜索框。但搜索能帮你“找到文档”，解决不了“该怎么做”的问题。用户真正想问的是开放式、口语化的问题，比如“供应商月结对账老是出错，我怎么处理”，这种问题没法靠关键词规则枚举答案。

所以我们才决定做智能体：让模型去理解问题，从资料库里找出相关内容，再组织成一步步可执行的操作建议。这个定位从一开始就决定了提示词的第一原则——不能只复述资料内容，必须转化成行动指南。后来所有版本的结构调整，源头都在这个定位上。

当时我对智能体的技术路线抱有很大期待，觉得只要把大模型的API接进来，把资料库向量化，再写一段提示词说明任务，就万事大吉。事实证明，我严重低估了“提示词”这三个字的分量。

1.2 初版上线后的真实反馈

v1上线后的用户反馈，我整理了一下，基本可以归成四类：答案像搜索引擎摘要，只是把文档段落拼在一起；车轱辘话多，绕来绕去没有重点；没有具体步骤，只给方向不给操作；一问到细节就断片，比如问“具体在哪个系统哪个菜单操作”，就直接答不上来。

最典型的一个case我记得很清楚。用户问“供应商月结对账错误怎么处理”，v1的回答是：“建议与财务部门核对供应商结算数据，确保双方信息一致，及时处理差异。”从语义上这句话完全没错，但业务方直接吐槽：“这个我也知道，不用它说。”这就是一个典型的“正确但无价值”的回答。

为什么会出现这种情况？因为v1的提示词里没有任何关于操作层次的约束，模型只知道“要回答用户问题”，它最擅长的就是把相关的信息按语言习惯组织成通顺段落，根本不会主动拆步骤、给路径。它以为自己回答得很好，但用户根本没法拿去用。

1.3 我当时踩的两个最基础的坑

复盘的时候，我发现v1到v2之间犯过两个特别基础但也特别典型的错误。第一个是“把提示词当需求文档写”，一上来就堆功能描述，比如“你要准确回答”“你要结合资料”“你要考虑用户身份”，但从来不告诉模型这些要求之间的优先级。模型面对一堆平级指令，只能靠概率猜重点，结果就是每条都执行了一点，但没有一条执行到位。

第二个坑是“只看单轮回答，不看多轮对话”。我测试的时候都是单个问题丢进去，看回答对不对，从来没模拟过“连续聊十轮”的场景。后来业务方反馈“聊着聊着就忘了前面说啥”，我才发现这个问题在提示词层面根本没做任何处理。这两个坑直接促使我决定系统性重写，而不是继续打补丁。

2. v1到v3：从“一句话需求”到“像个助手”

2.1 v1：一句话描述，上线即翻车

v1的提示词其实写得特别随意，核心就一句话：

你是一个智能助手，请根据知识库内容回答用户问题，回答要准确、完整。

当时我心里想的是：大模型这么聪明，给它一个目标，它自己会想办法。结果上面已经说了，输出大而空。

现在回头看，问题在于“准确、完整”是典型的模糊指令。模型确实知道要“准确”，但什么叫准确？它只能理解成“不要瞎编”，于是就从知识库里挑相关段落拼起来；确实知道要“完整”，但什么叫完整？它只能理解成“多写一点”，于是各种正确的废话全出来了。

打个比方，这就像你让一个新同事“把情况了解一下，跟客户沟通一下”，不给背景、不给边界、不给流程，他只能按自己理解发挥。模型也是这样。它不缺能力，缺的是约束。

这个阶段我学到的最重要一课是：提示词的质量不能用“写了多少字”衡量，而是看“约束是不是具体”。

2.2 v2：立人设，学会说话但开始胡编

v1翻车之后，我干的第一件事是给“唤醒”立人设。v2提示词增加了角色设定：

角色：你是“唤醒”智能体，一名企业运营专家顾问。 沟通风格：专业、简洁、有同理心，先给结论再给理由。 回答要求：结合知识库资料，给出操作建议。

效果是立竿见影的。回答的语气从“搜索引擎摘要”变成了“有人味的话”，业务方第一次反馈说“听起来舒服多了”。我当时还挺得意，觉得角色设定果然有用。

但得意没持续多久，新问题就冒出来了：模型开始胡编。为了维持“专家顾问”这个人设，它在知识库根本没有覆盖的地方，也会硬着头皮补出流程。有一次用户问一个内部系统报错，知识库里没有记录，它居然编出一套“联系管理员重新配置权限”的步骤，流程看起来合理，但完全是编的。我管这个叫“幻觉式服从”——角色设定越强，模型越不愿意承认自己不知道。

后来我调别的模型时经常用一个经典测试用例验证这种问题：你给模型设定“你是一只鹈鹕”，它会很听话地扮演鹈鹕，但如果提示词里没有明确“骑自行车”这个动作约束，让它在画面里自由发挥时，它可能会漏掉动作，也可能会凭空补充动作。文本智能体一模一样。角色设定解决的是“用什么语气说话”的问题，解决不了“什么能说什么不能说”的事实边界问题。

所以v2阶段的结论是：角色有用，但只能用来定语气，不能用它来代替事实约束。这为v3的改动埋下了伏笔。

2.3 v3：结构化模板，把回答格式焊死

v3的核心改动，是把回答格式用Markdown模板固定下来。提示词里不再是抽象的文字描述，而是一段明确的结构指令：

## 回答结构 1. 问题诊断：用一两句话概括用户的问题本质，不要复述问题本身。 2. 操作步骤：最多给出5步，每步包含“做什么”和“为什么”。 3. 注意事项：列出最常见的2-3个可能出错的点。 4. 补充资料：如果有相关资料，附上链接。

为什么要用Markdown结构？因为我发现大模型对“格式”有一种天然的敏感，你把结构写清楚，它就会严格按结构输出，这比任何文字描述都管用。模型的自由度从“任意组织段落”收敛成“往槽位里填空”，输出的稳定性大幅提升。

这轮的效果可以量化：格式合格率从v2的72%提升到了85%，至少回答看起来像模像样，而且“先做问题诊断”这个设计，阻止了模型上来就贴百科式答案，用户能更快看到重点。

但副作用也随之而来。模板把答案框得太死，所有回答都像一个模子刻出来的，有用户反馈“太像客服机器人了”。这其实暴露了一个更深的问题：结构约束住的是骨架，但骨架里的语言组织、详略安排，还需要留出余地。v3让我意识到，结构化要做，但不要结构到每条肉的纹理。

3. v4到v6：从“像个助手”到“能干活”

3.1 v4：用少样本示例教它写标准答案

v3之后，格式是稳定了，但还有一类问题没解决：模型知道格式了，但不知道“内容质量的标准答案”长什么样。比如同样一个步骤，它可能写得啰嗦，也可能写得过于简略。

v4的思路很直接：与其用规则告诉模型“你要写具体步骤”，不如直接给它看两三个标准答案。这就是少样本示例（few-shot）的基本思路。我在提示词里加了一段：

示例： 用户问题：供应商月结对账错误怎么处理？ 标准回答：先登录结算系统，导出上月全部对账明细，核对差异项；然后按差异类型分类，供应商单价不符的，发起调价申请；数量不符的，联系仓库确认入库记录；最后在系统内提交对账异常工单，附上核对截图。

原理其实一句话就能说清楚：模型对上下文中最近出现的文本模式极其敏感，给它看一个标准答案，比给它写十条规则都管用。示例本身就是最强形式的规则。效果也很明显，尤其是格式要求严格的场景，高频任务的“可执行性”上来了，不再只是“说人话”。

但这轮我也踩了坑：示例选不好会反噬。一开始我放了五六个示例，每段还特别长，结果上下文被示例占满，模型后续回答开始变得特别啰嗦，因为它在模仿示例篇幅。后来我把示例精简到2-3条，每条只覆盖一种典型结构，这个问题才解决。

3.2 v5：动态上下文注入，解决“聊着聊着就断片”

v4阶段还有一个老问题没有真正解决，就是多轮对话的记忆。用户聊到第三轮、第五轮，模型经常忘了前面说过什么。原因不在模型本身，而在于我的提示词是静态的：每次请求发过去，模型只看到“新输入+固定提示词”，前面聊过的内容要么被截断，要么被稀释。

v5做了一次关键转变：提示词从“静态脚本”变成“动态模板”。在每次交互前，程序会把当前会话的关键状态主动拼进提示词：

当前会话状态： - 用户身份：{user_role} - 最近一次问题：{last_question} - 已完成步骤：{completed_steps} - 未解决问题：{pending_issues}

这个设计的本质，是给模型配了一张“小抄”。它不需要靠上下文推理去回忆前面聊了什么，而是由程序把高价值信息直接摆在它面前。效果非常直观，用户连续聊十轮，模型依然能记住前几轮提到的业务背景。

但代价也很明显：提示词不再是纯文案，而是和代码强耦合。你必须在程序侧维护会话状态、决定哪些字段拼进去、拼在哪个位置。这算是提示词工程从“写作文”走向“写程序”的分水岭。也正是从这轮开始，我开始纠结一个更深的问题：要不要离开可视化平台，直接用代码编排整个智能体链路？这个问题拖到v7才真正解决，后面专门用一章说。

3.3 v6：把工具接进提示词，从“背书”到“查书”

v5解决了记忆问题，v6解决的是知识准确性问题。之前不管提示词怎么调，模型都是在靠资料库的向量召回“背知识”，一旦资料更新不及时，或者召回片段不完整，它就很容易答错。更麻烦的是，它有时候会把“背过的东西”和“自己脑补的东西”混在一起，用户根本分不清哪句是来源可靠的。

v6的改动是给“唤醒”接入了真正的工具能力：知识库检索、用户信息查询、工单状态API。提示词里新增了工具调度规则：

工具调用规则： - 当用户问题涉及最新制度或流程时，调用 knowledge_search 工具。 - 当用户需要核对账号或权限信息时，调用 user_info 工具。 - 禁止根据聊天记录猜测用户数据，必须通过工具获取。

这轮之后，“唤醒”的定位从“背知识”变成了“查知识”。模型不再需要记住每一个细节，它只需要做选择题：这个问题要不要调工具？调哪个工具？拿到结果之后再组织回答。引用准确性因此上了一大步，回答里出现的每一个操作节点都可以追溯到知识库的某个来源。

到v6结束时，整体的任务可执行性已经从v1的“惨不忍睹”提升到了可以内部小规模试用的水平。但此时另外一个问题越来越刺眼：每次改动提示词，我都是凭感觉判断效果，没有一套评估机制。这直接催生了v7。

4. v7到v8：评估、回归与最终形态

4.1 v7：建立评估集，把提示词当代码改

v7之前的迭代，本质上都是“我觉得这样会更好”。这种方式在前期没问题，因为起点太低了，怎么改都有提升。但到了v6以后，改动经常变成“改好了A类问题，又改坏了B类问题”，因为没有客观标准。

v7我做的最重要的一件事，就是建立评估集。从真实用户会话里抽了100条用例，分成了四桶：高频问题40条、边界问题25条、多轮对话20条、异常输入15条。每条用例都定义了通过标准：不只是“答案正确”，而是“答案是否具备可执行性”——用户拿到回答后能不能按步骤直接操作。

评估集里的用例长这样：

输入：供应商月结对账错误怎么处理？ 通过标准： - 必须给出登录哪个系统、操作哪个模块。 - 必须区分“单价不符”和“数量不符”两种场景。 - 必须包含异常上报的方式。 - 否决项：空洞建议（如“与财务核对”），无具体操作步骤。

这个做法带来的最大变化，是提示词从“文案”变成了“代码”。每次改动之后，我都把评估集完整跑一遍，对比通过率变化。效果很直接：v7这轮的回归测试帮我抓出了好几个“改了A但B变差”的问题，这是纯靠感觉根本发现不了的。

我强烈建议所有做智能体的人，无论项目多小，都至少要建一个几十条的评估集。它不用很复杂，就是为了让你在改提示词的时候有个“照妖镜”。

4.2 v8：分层提示词架构，提示词只留“必要的话”

v7保证了“每次改动可验证”，v8则是对提示词本身的“减负”。经过前七轮的累积，提示词已经膨胀得非常夸张，接近两千字。里面堆满了历次迭代加的规则，很多互相覆盖，甚至互相冲突。有一次我在评估集上跑测试，发现一段规则加进去之后，整体通过率反而降了三个点，就是因为新规则和旧规则打架。

v8的改动是重构，把提示词拆成三层：

• 系统级指令层：角色定义、价值观、回答边界、什么情况必须转人工。这部分基本固定。
• 业务规则层：回答结构、工具调度规则、禁止事项。这部分随业务调整。
• 动态上下文层：每轮注入的变量，用户身份、会话进度。这部分由程序生成。

这个分层结构解决了几个之前纠缠在一起的问题。角色设定只负责“说话方式”，不再掺和业务流程；业务流程只约束“怎么做”，不负责“是什么身份”；动态上下文则彻底留在代码侧，和提示词模板解耦。

结果很有意思：提示词从两千多字精简到六百多字，回答质量反而更稳了。因为很多冗余规则删掉之后，模型被分散的注意力重新集中到了关键约束上。信息浓度比信息长度重要得多，这是我八轮迭代下来最深的一个体会。

4.3 八轮迭代的最终效果

把八轮的灰度测评数据整理成一张表，趋势非常直观。说明一下，这是团队内部定义“答案可执行性”的通过率，样本量不算大，但足以说明问题：

从37%到89%，关键不是某一轮的“神操作”，而是每一轮都在解决上一个阶段最核心的短板。如果硬要说哪个版本最重要，我会选v7，因为没有评估机制，后面所有优化都是盲人摸象。

5. 平台编排 vs Python自建：中途的一次痛苦选型

5.1 为什么会纠结

v6开始接工具之后，我在可视化平台上的操作越来越别扭。三个问题特别突出：评估集没有地方挂，只能导出对话记录到线下跑；版本管理基本靠手动复制，改崩了想回滚很麻烦；复杂工具和自定义逻辑的接入总要绕一圈。

同时团队里有同事在用Python搭智能体，走的是LangGraph那类框架，灵活性的确高。但我也很清楚，纯Python自研的代价很大：光是对话状态管理、工具调用、人机交互界面，就够一个小团队忙几周。于是开始正儿八经对比方案。

5.2 三种方案的横向对比

我把当时对比的三个方向整理成一张表：

看下来没有绝对的好坏，只有匹配不匹配。这件事折磨了我大概一周，最后想明白一个道理：选型的本质不是选技术，是选“你团队未来三个月把精力花在哪里”。

5.3 我的最终选择及理由

最终我选了混合路线：对话编排和提示词调试留在可视化平台上，快速出效果；评估脚本、版本管理、特殊工具全部放到代码侧，通过API和平台联动。

这个选择基于两个现实。第一，团队规模小，没有人力去维护一套完整的对话编排系统，可视化平台的调试效率是我们的生命线。第二，模型效果和版本安全又是硬需求，所以把“评估和版本”两个环节强制放在代码侧，用git管理提示词文件，用脚本跑评估集。

最后给个建议：不要盲目追求“全代码自建”。如果你被问“平台搭建的智能体和用Python搭建的智能体有什么不一样”，别急着站队。等你真的同时踩过两条路，你会发现核心差异不在技术，而在“谁能更快地把模型能力变成产品能力”。平台方案的系统逻辑很清晰，框架路线的系统逻辑也很清晰，真正模糊的是你的团队边界和发布节奏。把这几个问题想清楚，方案自然就出来了。

6. 迭代路上最常见的五个坑

6.1 提示词膨胀失控

v5阶段提示词膨胀到两千多字，越加越不稳定。原因是每次遇到问题，我都习惯往提示词里补一条规则，规则越堆越多，彼此冲突。后来强制自己“新增必删旧”，每次加一条规则，必须删掉一条不再必要的，这才刹住车。提示词和代码一样，会有技术债。

6.2 幻觉式服从

角色设定过强时，模型会为了维持人设而编造流程，这是我在v2踩过的坑。解法也很简单，在系统级指令里显式声明一条边界：“未在资料中找到的内容，必须向用户说明不清楚，或转人工处理，不得自行补充流程细节。”把这条写死，比任何“加强真实性”的要求都管用。

6.3 上下文超限与记忆丢失

动态上下文解决了“对话前三轮丢记忆”的问题，但用户聊到十几轮以后，即使主动拼字段也会超过上下文限制。我的做法很朴素：只保留高价值字段，不保留全部聊天记录。比如用户已经确认过的信息、已经执行完的步骤，就不往提示词里塞了，只留下“待办事项”和“当前问题”。实在必要，还会做一层会话摘要再拼进去。

6.4 评估集过拟合

v7的评估集用了两个月之后，出现了一个新问题：通过率很高，但真实用户满意度没有同步提升。原因很简单，评估集里都是“已知问题”，模型在反复跑这些用例之后，已经学会了针对性地输出“标准答案”，但真实世界的提问方式永远比你评估集更刁钻。解法是把评估集当活数据，每周从真实对话里补充新用例，同时给每个桶设置一定的随机替换比例。

6.5 改提示词不看日志

早期改提示词完全不记录版本，出了问题都不知道该回滚到哪一版。后来我把提示词文件全部收到git仓库，每版改动都写commit message，关联当时的评估通过率和上线时间。没有git条件的，至少也要用平台自带的版本保存功能，并在保存时写明改动原因。提示词一旦进入“工程化管理”，很多玄学问题都会变成可追踪的普通问题。

这里再把五个坑汇总成一份速查表，方便你直接存下来：

回头再看这八轮迭代，我最大的感受是：提示词工程不是一个“写文案”的活，而是一个“建系统”的活。你写的每一段提示词，本质上都是在给模型搭建一套决策框架。模型有没有理解不重要，它只要能稳定按照框架输出，就已经完成任务了。

我现在已经养成一个固定习惯：任何一次提示词改动，不管多小，都要走四步——先写下“为什么改”，再跑一遍评估集，然后部署上线，最后抽读二十条真实对话记录。这四步基本杜绝了“凭感觉改、上线就翻车”的循环。

最后再分享一点个人体会：提示词对我来说，不是给模型的说明书，而是产品经理、业务运营、代码之间的一份翻译件。把提示词当成你在带一个不爱说话的新同事，沟通越具体，边界越清晰，它就越靠谱。反过来也成立：它一旦开始胡言乱语，先别急着怪模型，回头看看你给它的上下文里，是不是又混进了一堆没说清楚的话。