3.3 调参与发布：从调试间走上前台

3.3 调参与发布：从调试间走上前台

发布不是点按钮，是验收。参数定稿、十连问稳定、外部设备访问正常、日志面板有记录——四项全过，首搭才算交付。本节把"调参"从玄学变成推理，把"发布"从动作变成清单。

四拍的最后两拍。3.2 节的说明书已过三类探针，本节让它经受更苛刻的稳定性考验，然后正式把小艺送到真实用户面前——这是两周期限的第一个交付点。

一次十连问暴露的问题

先看一个真实翻车现场。说明书过探针后，我在调试面板连问了十个变体问题：换问法、加错别字、口语化、两句并一句。第 7 问"退货那啥…七天还是十五天来着"，小艺回答了一大段"关于退货的注意事项"——结构正确，但没直接回答天数。第 10 问把两次咨询塞进一句话，回答只处理了后半个问题。

这类问题提示词能治一部分（规则段加"先给结论"），另一部分要靠参数治：模型输出越"发散"，越压不住。于是进入参数区。

四个参数的推理式选择

模型参数区有一排滑杆，客服场景只需要推理四个：

温度的物理意义可以这么理解：它调的是模型"选词时的犹豫程度"。温度高，排名靠后的词也有机会上场，回答多样但容易跑偏；温度低，模型永远选最稳的词，回答一致但呆板。客服要一致，0.3 是我给小艺的定稿值。创作类应用反过来，0.7 起步去找惊喜。

上下文轮数是 token 账单的第二大项（第一是每轮都要发的系统提示词）。轮数从默认 10 压到 5，单轮输入 token 直接省一小半，而客服对话几乎不受影响——超过五轮还没闭环的对话，3.2 节的规则 3 已经建议转人工了。参数之间要联动看，这是"调参是推理不是拼凑"的含义。

小艺参数定稿（记录进迭代日志）
temperature 0.3 | 上下文 5 轮 | 最大返回 512
依据：政策问答求一致；客服对话短；结构化答案 512 够用
对照：温度 0.7 时探针二边界反例再次翻车，佐证低温选择
​

最后跑一遍验收探针加十连问，全绿才进发布。

发布的三种形态

点右上角"发布"，Dify 给出三种交付形态，对应三种集成深度：

WebApp。一个现成网页链接，自带会话界面与开场白。零代码，发个链接就能用——首搭验收用它。链接可以设访问权限（公开、指定人、私密码），内测期建议私密码。

嵌入。一段嵌入代码，把对话窗口嵌进你自己的网站（比如帮助中心页）。产品经理要的"嵌到帮助中心"就是它。嵌入有浮窗与内嵌两种形态，代码在发布页复制即可，粘贴位置由你的前端同事决定。

API。第 7 章的主角，这里先把应用密钥拿到手：发布页进入"访问 API"，创建一个密钥并妥善保存。这把钥匙就是未来一切系统集成的基础凭据。

四项发布验收

发布不是终点站，验收才是。用非搭建者的设备（手机最好）过四项：

发布验收单
[ ] WebApp 链接在外部网络可打开，开场白与建议问题正常显示
[ ] 首屏变量 member_level 出现且必填生效
[ ] 三类探针 + 十连问在真实页面复跑通过
[ ] 对话完成后，控制台"日志"里出现这条会话记录
​

第四项最容易被忽略，它验证的是观测链路：发布后的会话进日志，你才有了第 7 章运营迭代的数据来源。如果日志里空空如也，先确认访问的是发布链接而不是调试面板（3.1 节讲过的差异）。

⚠️ 常见坑：发布后不再回来更新。Dify 的发布是"发布一个版本"，之后你在编排面板的修改不会自动同步到已发布的 WebApp——需要再次点击更新发布。很多团队第一天上线、第二天改了提示词、第三天用户反馈"怎么还是老答案"，就是这个机制没吃透。嵌入代码与 API 调用则始终指向最新已发布版本。

首搭复盘：你已经走过的路

到这里，两周期限的第一周交付完成。复盘这条线：骨架（3.1）→ 说明书（3.2）→ 参数定稿与发布（3.3），中间反复横跳的是迭代环路。值得写进团队文档的三条经验：探针先行，改任何东西都用同一组探针回归；参数即业务约束的翻译，不靠手感；发布是验收清单不是按钮。

参数速查卡与温度实验记录

把本节参数知识压成一张随手可查的卡片，再加一段我留下的小型实验记录，供你复现：

参数速查卡（客服场景）
温度        0.2-0.4   政策一致性优先；创作类应用 0.7 起
上下文轮数  4-6       按业务对话长度；越少越省 token
最大返回    400-800   结构化答案够用；截断即调高
其余参数    默认      top_p 与温度二选一调整，不同时动

温度对照实验（固定同一组十连问）
0.1  回答刻板，边界反例全过，但口语问题答得像法条
0.3  结论先行结构稳定，追问应对自然 —— 定稿值
0.7  探针二再次翻车（开始闲聊公司愿景），答案长度方差变大
结论：温度每 +0.2，边界类探针的失败率大约翻一倍（本组样本内）
​

实验记录的写法值得多说一句：固定问题集、只动一个变量、记录三档对比。这套方法与 4.3 节的召回验收一脉相承——凡是被"感觉"统治的地方，都值得换成一张这样的表。

问题：发布之后发现问题，改动会中断正在进行的对话吗？

不会。已发布版本的会话按旧版本继续走完，新发布的版本对下一条新消息生效——用户无感知。但要注意"调试面板的修改未发布"与"已发布未更新"是两种状态：前者对用户完全不可见，后者是改了没同步。拿不准时看发布按钮的状态提示，或直接在真实 WebApp 里问一句验证。

💡 关键直觉：首搭的质量天花板由提示词决定，参数只决定稳定地下限。把 80% 时间给说明书，20% 给滑杆，比例反过来就是本末倒置。

本节要点回顾

• 十连问是稳定性的试金石：换问法、错别字、复合问题，比三类探针更接近真实用户；
• 四参数推理：低温求一致、轮数按对话长度、返回上限按结构化答案长度，联动权衡 token；
• 三种交付形态：WebApp 零代码、嵌入进自有页面、API 面向系统，首搭验收用 WebApp；
• 发布有版本语义：后续修改要点"更新发布"才生效，这是最高频的上线后疑问；
• 四项验收：外部访问、变量生效、探针复跑、日志落库，观测链路从这里开始建立。

小艺上线了，但它对政策内容还一无所知——政策都写在你的文档里。第 4 章把文档喂给它。