一、先校验，再跑

连完先点校验。四道检查：有环、孤儿、悬空出口、结束节点个数（第 4.3 节）。 演示里这条链校验通过。但通过不等于能用——校验只查结构，不查数据。 校验查不出的三类：引用写错（取到空值）、条件写反（走错分支）、字段名对不上。

这三类只能靠真跑发现。所以校验后面一定跟一次真跑。

二、跑长文案

七步全跑：开始、抓热点、判长度、选择器、改写、出图提示词、结束。 改写节点生效了，输出的文本尾巴带着「（已口语化）」。 结尾节点的两个字段都有值：text 和 prompt。

这个结果是对的。 但你要看的不只是「对不对」，还有「每一步吐了什么」—— 轨迹表的「输出端口」那一列就是为这个存在的。

三、跑短文案：看分支

换一段六个字的短文案，再跑一遍。 这次「改写」那一行标着跳过，七步里有一步没走。 但「出图提示词」照样跑了。跳过的只有那一个节点，不是整条后面的枝。

这就是第 8.1 节讲的「按边判跳过」。 按节点判的话，选择器判成短，整条下游都会被跳过，出图提示词也跟着没了。

四、要盯的三个中间值

三个里第一个最要紧。抓热点返回空列表，后面写什么都白搭。 第二个决定分支。判长度这一步用的是「字数」，这个阈值定多少，直接决定哪条路走得多。 第三个容易被忽略：提示词超过八十个字，画图模型会忽略后半段。这条链里它已经有八十字了。

五、要跑几种输入

至少三种：一条正常的长文案、一条短的、一条抓不到热点的。 第三种最容易被忘。它的意思是：接口挂了，兜底生效。这时候链能不能走完？ 三条都跑过，你才知道分支对不对、兜底有没有生效。只跑一条的，等于只测了三分之一。

如果还有「文案里有数字」「文案特别长」「文案是英文」这些边缘情况，也各跑一条。 每条边缘情况都是你上线后会被用户碰到的那一次。

六、结果对了还要看什么

一、中间值有没有空。 结果对了但中间某个字段是空的，说明它是靠默认值蒙对的。 二、耗时分布。 哪个节点慢。慢的那个是插件调用还是大模型，处理方式不一样。 三、失败时的表现。 故意断网跑一次，看报错写得清不清楚。

第三件最少人做，也最值钱。上线后出问题时，你只有那条报错能看。

七、端到端测试的产物

一份中间值样本（每个节点吐了什么），一份耗时记录，一份失败日志。 三样东西里第一样最有用：以后调任何一个节点，都拿它当输入（第 8.5 节）。 第二样用来找瓶颈。第三样用来改进报错信息。

这三样都不交给人，是留给你自己的。 这就是「测试」和「验工」的区别。

八、动手 Demo：端到端跑，盯中间值

七个节点的完整链：抓热点、判长度、选择器、改写、出图提示词、结束。 先校验，再跑长文案，再换短文案跑一次，对比两张轨迹表。

f.link(u's', u'hot').link(u'hot', u'len').link(u'len', u'sel')
f.link(u'sel', u'rw', when=u'long').link(u'sel', u'pg', when=u'short')
f.link(u'rw', u'pg').link(u'pg', u'e')

print(f.check())            # 四道校验
g,  rec  = f.run({})                      # 长文案
g2, rec2 = f.run({u'_hot': u'芯片短缺缓解'})  # 短文案

实跑输出：

--------------------------------------------------------------------
端到端跑，盯中间值
--------------------------------------------------------------------


  ① 校验
  --------------------------------------------------------------------
  校验：通过

  ② 长文案跑一遍
  --------------------------------------------------------------------

| 步 | 节点 | 类型 | 输出端口 | 毫秒 |
|---:|---|---|---|---:|
|  1 | 开始 | 开始 | q | 0.0 |
|  2 | 抓热点 | 插件 | t | 0.0 |
|  3 | 判长度 | 代码 | n | 0.0 |
|  4 | 选择器 | 选择器 | （无输出） | 0.0 |
|  5 | 改写 | 大模型 | t | 0.0 |
|  6 | 出图提示词 | 代码 | p | 0.0 |
|  7 | 结束 | 结束 | prompt、text | 0.0 |

  七步全跑。改写节点生效了，输出的文本尾巴带着「（已口语化）」。

  ③ 短文案跑一遍
  --------------------------------------------------------------------

| 步 | 节点 | 类型 | 输出端口 | 毫秒 |
|---:|---|---|---|---:|
|  1 | 开始 | 开始 | q | 0.0 |
|  2 | 抓热点 | 插件 | t | 0.0 |
|  3 | 判长度 | 代码 | n | 0.0 |
|  4 | 选择器 | 选择器 | （无输出） | 0.0 |
|  5 | 改写 | 大模型 | 跳过 | — |
|  6 | 出图提示词 | 代码 | p | 0.0 |
|  7 | 结束 | 结束 | prompt、text | 0.0 |

  短文那一支跳过了改写节点——7 步里「改写」那行标着跳过。
  但出图提示词照样跑了。跳过的只有那一个节点，不是整条后面的枝。

  ④ 盯三个中间值
  --------------------------------------------------------------------

| 节点 | 看什么 | 不对就怎么办 |
|---|---|---|
| 抓热点 | list 有几条 | 0 条就停，别往后走 |
| 判长度 | n 是多少 | 决定走哪一支 |
| 出图提示词 | p 有多长 | 太长画图模型会忽略后半段 |

  三个值里第一个最要紧。抓热点返回空列表，后面写什么都白搭。

  ⑤ 端到端要跑几种输入
  --------------------------------------------------------------------
  至少三种：一条正常的长文案、一条短的、一条抓不到热点的。
  三条都跑过，你才知道分支对不对、兜底有没有生效。
  只跑一条的，等于只测了三分之一。
  ! 端到端测试的价值不在「跑通了」，在「知道每一步的中间值是什么」。
  轨迹表比结果更有用——结果对了但中间值是空的，迟早会出事。

①校验通过。但校验只查结构不查数据——引用错、条件反、字段名不对它都查不出。 ②长文案那次七步全跑，「改写」那一行有输出端口 t，说明它真跑了。 ③短文案那次「改写」标着跳过，但「出图提示词」照样跑。跳过的只有那一个节点，不是整条后面的枝。 ④两张轨迹表并排看，差别就在第五行。这就是分支测试的全部意义。 ⑤第四张表三个中间值。第一个最要紧：抓热点返回空列表，后面写什么都白搭。

30 秒实验

1. 把你的链按三种输入各跑一遍：正常的、极短的、上游返回空的。
2. 把每个节点的中间值复制一份存起来，它就是以后调单节点的测试样本。
3. 故意断一次网跑，看那条报错写得能不能让你一眼知道哪儿坏了。

常见误区

1. 「跑通一次就行了。」只证明这一条路径通，另一条可能一直坏着。至少跑三种输入。
2. 「校验通过就能发布。」校验只查结构。引用错、条件反、字段名不对，它一个都查不出。
3. 「结果对了就没问题。」中间值可能是空的，靠默认值蒙对的。要看轨迹表。

链跑通了，最后一节把它交给用户：创建一个智能体，挂上这条工作流。难点全在那段「说明」上。

• ☐ （本篇完，下一篇 8.9 创建智能体调用工作流）

相关笔记

• 图文工作流设计思路：按边判跳过
• 文案生成测试：单节点先试跑
• 扣子工作流的逻辑结构：四道校验
• 🐦 扣子开发 AI Agent · 索引