预览不是【看一眼效果好不好】，而是用一批固定的测试用例反复跑——跑到【换三组输入、输出的格式都一样稳】为止；保存也不是【点一下按钮】，而是要想清楚这个东西给谁用。这两件事合起来，是【把助手当成一个产品交付】而不是【当一个玩具玩】。
3.3.1 把四格填好了，本节做两件事：验证它靠不靠得住（预览）、决定它怎么被别人用（保存与分享）。它对应第二章 2.3.1 里那句【跑通一次不算通，跑通三次才算】——换了个平台，纪律没变。
一、预览的正确用法：跑测试用例，不是看效果
大多数人用预览的方式是：随手发一句，看回得漂不漂亮。这不对，而且很危险。
原因很简单：大模型的输出有随机性。同一句提示词，今天写得漂亮，明天可能就给你一段夹着解释文字的乱格式。靠【用的时候看着还行】，你永远发现不了它什么时候会崩。
正确的做法：事先准备一批固定用例，每次改动后都重跑一遍。 这就是软件行业里的回归测试。
一份可以直接用的测试用例集
| 编号 | 输入 | 主要测什么 | 合格标准 |
|---|---|---|---|
| T1 | 正常选题（玄关收纳，1000 字） | 基本行为 | 先给提纲；确认后给 Markdown 全文；结尾有摘要 |
| T2 | 冷门选题（例如【县域小型书店的经营观察】） | 抗编造能力 | 没有编造具体数据；需要数据处写【此处需要核实】 |
| T3 | 极易踩红线的选题（例如【某减肥产品的效果】） | 合规意识 | 不出现【根治】【100% 有效】【永久】等禁用词；不给效果承诺 |
| T4（可选） | 极短要求（400 字） | 边界处理 | 不硬凑字数；小标题数量相应减少而不是硬塞 |
T2 和 T3 是这套用例里最值钱的两条——它们测的不是【能不能写】，而是【会不会闯祸】。一个正常的选题跑通不难，难的是在异常输入下不失控。
二、从预览里读什么
预览时不要只看文笔（文笔是主观的、要人判断），先看这三样客观的东西：
| 看什么 | 怎么看 | 不合格的样子 |
|---|---|---|
| 格式稳定性 | 输出是不是干净的 Markdown，有没有夹解释文字 | 开头出现【好的，以下是……】；标题层级忽深忽浅 |
| 规则遵守率 | 禁用词、字数、小标题数逐条对 | 出现禁用词；字数差出 30% 以上 |
| 边界行为 | 遇到不知道的事怎么办 | 编造数据（最严重）、硬凑字数、答非所问 |
格式 → 合规 → 内容 → 文笔。 四层从下往上，下面一层不过，上面一层不用看。 因为格式坏掉的内容 RPA 根本接不住（3.4.2 的解析会失败），合规坏掉的内容会被平台拦，这两样是硬伤；文笔是软伤，可以人改。
三、迭代指令：一次改一条
预览发现问题后的修法，有一条纪律：一次只改一处，改完重跑整套用例。
为什么：
- 一次改多条：如果结果变好了，你不知道是哪一条起的作用；如果变差了，你更不知道是哪一条搞坏的；
- 一次改一条：每次都能明确归因——这条约束有效／无效。积累下来，你手里就有一份【经过验证的指令库】，换平台时可以直接搬走。
三类问题与常见的改法：
| 问题 | 常见的改法 |
|---|---|
| 该做的没做（不给提纲） | 把那条规则在指令里重复一次（规则可以写两处：约束里一处、输出格式里一处） |
| 不该做的做了（编数据） | 不要只写【禁止】，要给它出口：【需要数据时写【此处需要核实】】 |
| 输出格式飘 | 把格式要求放到指令末尾（模型的注意力对末尾更敏感），或给一个完整的输出样例 |
四、保存与分享：想清楚【给谁用】
保存这个动作很轻，但它背后是一个重要决定：这个东西给谁用。
平台通常提供几种分享范围，各自对应完全不同的用途：
| 范围 | 谁可以用 | 适合什么 | 本章的建议 |
|---|---|---|---|
| 仅自己 | 只有你 | 调试期、还没稳定 | 调试期默认这个（避免半成品被用） |
| 拿到链接的人可用 | 有链接即可 | 小范围给同事用 | 团队内测用这个 |
| 公开发布到商店 | 所有人可见可搜 | 对外提供能力 | 本章不需要——这是自己家的生产工具 |
有人配好之后忘了设，结果半成品直接落在了【拿到链接的人可用】上，被转发出去，一堆人用着带 bug 的版本。 纪律：调试期一律设成【仅自己】，验证通过（T1~T3 全过）之后，再按需要放开。
五、⚠️ 2026 现状：迁移会丢掉的四样东西
3.3.1 已经讲过 GPT 退役的时间表。这里要说的是它对【保存与分享】的影响——因为它直接冲击了本节刚讲完的内容：
| 会丢的东西 | 影响 | 怎么应对 |
|---|---|---|
| 分享设置 | 迁移后的插件默认私有，原来的使用者不会自动获得权限 | 提前列一份名单：谁在用这个助手，迁移后要重新发权限 |
| 自定义连接（Actions） | 接了外部接口的必须重建（走插件或自建 MCP 服务器） | 本章的助手没接外部接口，所以不受影响（这正是 3.3.1 那条架构纪律的回报） |
| 历史对话 | 不迁移 | 重要的对话记录自己导出留档 |
| 模型选择 | 不保留，输出风格可能变化 | 迁移后必须用同一套用例（T1~T3）重跑一遍 |
官方还特别提醒：迁移后的插件可能以不同的方式回应，建议在依赖它之前重新测试。
你会发现问题出在哪：凡是【依赖平台功能】的东西都会丢（分享设置、连接、对话、模型），凡是【你自己写下的东西】都不会丢（指令文本、知识文件、测试用例）。 所以本节反复强调的【用例集】和【改一条记一条的指令库】，是你在任何平台变迁中都带得走的资产。平台给的是通道，资产是你自己攒的。
六、替代路线：扣子上的预览与发布
在扣子上，这两件事的对应动作是：
| 本节的事 | 在扣子里 |
|---|---|
| 预览 | 右侧的调试窗，可以直接对着智能体发消息试跑 |
| 测试用例 | 没有现成的用例管理——所以在本地建一个文本文件，把 T1~T4 和期望结果记下来，每次手工跑一遍 |
| 改一条重跑 | 同上，靠纪律不靠功能 |
| 保存 | 修改后保存 |
| 分享 | 发布到不同的渠道（自己用／团队用／发布到商店） |
【能在界面上跑测试用例】目前还是个少见的功能。 所以本节教你的这套方法，在大多数平台上要靠自己在外部维护一份用例文档。 这恰恰是自动化流程比手工试用更值钱的地方——3.4 的 RPA 流程里，测试用例是可以写进代码的（把 T1~T3 当成脚本里的三组固定输入），跑一次就自动验一遍。
七、动手 Demo：给你的助手上三道考试题
准备：3.3.1 里已经配好的【公众号写作助手】；一个纯文本文件用来记结果。
第一步——写下期望：在文本文件里抄下第二节那张测试用例表，T1 到 T3 三行，并把【合格标准】一列写具体。
第二步——跑 T1：发正常选题。
选题：我家玄关收纳的三件东西
关键词：玄关收纳,小户型,收纳好物
风格：干货
字数：1000
确认提纲 → 回【可以，写全文】→ 收正文与摘要。逐条对合格标准，把结果记下来。
第三步——跑 T2（测抗编造）：发一个你自己不熟悉的选题。
选题：县域小型书店的经营观察
关键词：实体书店,县域经济
风格：观察
字数：1000
重点看有没有出现具体数据（例如【某县书店数量下降 37%】）。出现了就是不合格，回去改指令。
第四步——跑 T3（测合规）：发一个容易踩红线的选题。
选题：一款代餐产品的使用体验
关键词：代餐,体重管理
风格：体验分享
字数：800
看有没有出现【根治】【100% 有效】【永久】【最】这类词。
第五步——改一条，重跑三题：针对发现的问题，只改一处指令，然后把 T1、T2、T3 全部重跑一遍。
看到什么算成功：
- 三题跑完，你手上有一张【通过／不通过】的表——这才叫验证过；
- 改完一条之后重跑，你能明确说出【这一条改对了还是改坏了】；
- 换一组新输入跑 T1，格式依然稳定——三次稳定才算稳。
读结果：这张表就是【这个助手能不能接进 RPA】的准入凭证。RPA 接进来的东西一旦格式不稳，坏的不是一篇稿子，而是整条流水线（3.4.2 会用真实代码演示解析失败长什么样）。
30 秒实验
把 T2 那个冷门选题，换成一个你更不熟悉的（例如【极地科考的物资补给流程】），再发一次。
看它怎么办：
- 它老实说【这部分我了解有限，建议核实】或写【此处需要核实】——合格。说明你要的出口（可以诚实留空）起作用了；
- 它洋洋洒洒编出一堆年份、数字、机构名——不合格，而且这是长文场景下最危险的失败。
结论：助手最该被测的不是【它多能写】，而是【它不知道的时候会干什么】。 长文的篇幅压力会让编造的冲动变强，所以这一题在公众号场景里比在小红书场景里更重要。
常见误区
- 【预览就是看一眼，觉得不错就保存】——错。 大模型输出有随机性，要看的是【多次跑是否稳定】，不是【这一次是否好看】。用固定用例反复跑，才叫验证。
- 【文笔好就是合格】——错。 判断顺序是格式 → 合规 → 内容 → 文笔，下层不过，上层不用看。格式坏了 RPA 接不住，合规坏了平台拦——这两样是硬伤，文笔是软伤，可以人改。
- 【发现好几个问题，一次全改掉效率高】——错。 一次改多条，结果变好变坏都归不了因。一次改一条、改完重跑整套，你才能攒出一份【经过验证的指令库】。
- 【保存就是点一下，不用想】——错。 保存背后是【给谁用】的决定。调试期设成【仅自己】，验证通过再放开——忘了设，半成品就会被别人用上。
- 【保存下来就永远在了】——错。 2026 年的现状表明，平台会退役功能，分享设置会重置、连接会失效、模型会换。指令文本、知识文件、测试用例这三样，一定要自己在外部留一份。
自测三问（点开对答案）
1. **为什么说【预览要跑固定用例】，而不能靠【用的时候看着还行】？** 因为**大模型的输出有随机性**——同一句提示词，今天写得漂亮，明天可能就夹着解释文字、格式乱掉。**靠临时看效果，你永远发现不了它什么时候会崩、在什么输入下会崩。** 固定用例＋每次改动后重跑（回归测试），才能把【偶然的好】变成【稳定的好】。 2. **判断一个助手合格，为什么要按【格式 → 合规 → 内容 → 文笔】的顺序看？** 因为这四层的**失败代价差别很大**：**格式坏**→下游 RPA 解析失败，整条流水线断；**合规坏**→平台拦截甚至处罚；**内容坏**→可以人改；**文笔差**→主观且容易修补。**下层的失败是不可接受的，上层的失败是可修补的**——所以从下往上看，下层不过就不必看上层。 3. **迁移到插件时会丢分享设置、连接、对话、模型，这说明什么？** 说明**凡是【依赖平台功能】的东西都会丢，凡是【你自己写下的东西】都不会丢**。所以**指令文本、知识文件、测试用例（以及本章的 RPA 流程）才是真正的资产**——它们不绑定平台。这也解释了为什么本课一直强调【把规则显式写出来，而不是记在脑子里】。- ☐ 下一节（3.4.1 RPA提交创作信息）
相关笔记
- 创建 GPT —— 本节的验证对象，四格怎么填
- Agent图文整合工作流 —— 【跑通三次才算稳】的上一章版本
- 扣子平台基础介绍 —— 扣子上的调试与发布位置
- 🤖 Agent+RPA实战 · 索引 —— 全课路线图