波仔
🐦 第8章 实战案例：图文混合的火爆推文生成器
📄 一句话概括

三件事：给工作流起名、给节点起名、定开始节点的字段。 节点名会被引用（节点名.字段名），所以起名不是审美问题，是接口问题。 开始节点定几个字段有讲究：三个左右，一个必填，两个可选。

📝 本章和前面几章的关系

上一节设计，这一节动手。动手的第一步不是拖节点，是起名。 这一节看着琐碎，但它是后面七节的地基——名字起坏了、开始节点定偏了，后面每个节点都要跟着别扭。 「字段怎么定」这一条第 7.2 节讲过一遍（数据库表），这里是同一个道理， 只不过这次定的是工作流的入参。

一、给工作流起名

工作流的名字是给智能体看的——它靠这个名字加描述判断什么时候调。 「推文生成器」比「workflow_20261030_v3」好。「售后问答」比「测试2」好。 名字要短（四到六个字），因为它在智能体的工具列表里显示。太长了列表里看不全。

别名和描述要分开写。 别名短，描述写触发条件。只写别名，模型不知道该在什么时候用它。 这一条第 8.9 节会量出来。

二、给节点起名

演示里对比了两种：默认名「节点1」到「节点5」，和有意义的名「抓热点」「写文案」等。

风格 五个节点叫什么 能猜出用途的
默认名 节点1、节点2、节点3、节点4、节点5 0 / 5
有意义的名 抓热点、写文案、出图提示词、生成配图、拼装输出 5 / 5

默认名的问题不是难看，是一周后你自己也认不出哪个是哪个。 节点一多，排错的时候日志里写着「节点4 执行失败」——你得回头数第四个是哪个。

三、名字会被引用：这是接口

节点名不只是给人看的。 变量的引用写法是 节点名.字段名，所以节点名改了，所有引用它的地方一起坏。 「抓热点.list」比「节点1.list」好用得多——出问题时日志里写的就是这个名字。 反过来说也成立：改节点名等于改接口。 改之前先搜一遍旧名出现在哪几个节点的入参里。 和第 7.4 节改数据库字段名是同一件事。

所以起名要一次起对。起名的成本是三十秒，改名的成本是半天。

四、开始节点定几个字段

字段数 字段 调用时要传几样
1 topic 一个主题
3 topic、style、length 主题 + 风格 + 长度
5 topic、style、length、platform、avoid 再加平台与禁忌词

字段越多，调用方越麻烦；字段越少，工作流内部越要猜。 经验值：三个左右。 一个必填的主题，两个可选的风格与长度，其余用默认值。 到五个的时候就要警惕了：调用方多半会漏填，而工作流不知道它漏了，于是用了默认值， 结果不对还得回来查。

五、字段的三个细节

一、必填的只留一个。 两个必填，调用方就有一半概率漏填。 二、可选的给默认值。 空着就用默认值，比报错好。 三、名字用英文或拼音。 中文在引用里能拼，但在代码节点里容易出编码问题。

三个细节都不难，但漏一条后面就要返工。

六、这一步做完的样子

一个空画布上只有两个节点：开始、结束。中间是空的。 开始节点里三个字段：topic（必填）、style、length。结束节点先空着——等整条链通了再回来定输出。 这是对的顺序。 一上来就把结束节点定死，中途每改一次输出都要回来改一次。

先让链跑通，再定契约。契约定早了会反复改，定晚了会漏字段。

七、动手 Demo：空画布、起名、连开始节点

对比两种节点命名，看能猜出用途的有几个。 再看开始节点定一到五个字段时，调用方要传几样东西。

NAME_BAD = [u'节点1', u'节点2', u'节点3', u'节点4', u'节点5']
NAME_OK  = [u'抓热点', u'写文案', u'出图提示词', u'生成配图', u'拼装输出']

def readable(names):
    u'''命名可读性替身：名字里有没有实义词、长度是不是超过两个字。'''
    ok = 0
    for n in names:
        if len(n) >= 3 and not Q.re.match(u'^节点\\d+$', n):
            ok += 1
    return ok

实跑输出：

--------------------------------------------------------------------
空画布、起名、连开始节点
--------------------------------------------------------------------


  ① 五组名字，两种命名
  --------------------------------------------------------------------

| 风格 | 五个节点叫什么 | 能猜出用途的 |
|---|---|---:|
| 默认名 | 节点1、节点2、节点3、节点4、节点5 | 0 / 5 |
| 有意义的名 | 抓热点、写文案、出图提示词、生成配图、拼装输出 | 5 / 5 |

  默认名「节点1」到「节点5」，一个星期后你自己也认不出哪个是哪个。

  ② 名字会被引用
  --------------------------------------------------------------------
  节点名不只是给人看的。变量的引用写法是 节点名.字段名，所以节点名改了，所有引用它的地方一起坏。
  「抓热点.list」比「节点1.list」好用得多——出问题时日志里写的是这个名字。

  ③ 开始节点定几个字段
  --------------------------------------------------------------------

| 字段数 | 字段 | 调用时要传几样 |
|---:|---|---|
| 1 | topic | 一个主题 |
| 3 | topic、style、length | 主题 + 风格 + 长度 |
| 5 | topic、style、length、platform、avoid | 再加平台与禁忌词 |

  字段越多，调用方越麻烦，但工作流内部越不用猜。
  经验值：三个左右。 一个必填的主题，两个可选的风格与长度，其余用默认值。

  ④ 工作流起名的规矩
  --------------------------------------------------------------------
  工作流的名字是给智能体看的——它靠这个判断什么时候调。
  「推文生成器」比「workflow_20261030_v3」好。「售后问答」比「测试2」好。
  还有一个细节：别名和描述要分开写。 别名短，描述写触发条件。
  只写别名，模型不知道该在什么时候用它。
  ! 这一节看着琐碎，但它是后面八节的地基。
  名字起坏了、开始节点字段定偏了，后面每个节点都要跟着别扭。

①第一张表两行：默认名 0 / 5，有意义的名 5 / 5。 判据很土，但结论不会错——「节点3」这个名字里没有任何信息。 ②第二段讲引用：节点名会写进 节点名.字段名 里，改名等于改接口。 ③第三张表是开始节点定几个字段。一行一个方案，最后一列是「调用时要传几样」。 ④五个字段那一行最值得看：调用方要传五样，漏一样就出错，而工作流不知道它漏了，会用默认值继续跑。 ⑤最后那段讲顺序：先让链跑通，再回来定结束节点的输出。一上来就定死，中途每改一次都要回来改。

30 秒实验

  1. 打开你现有的工作流，看有几个节点叫「节点N」。全部改成有意义的名字。
  2. 数一下你的开始节点有几个字段。超过五个的，砍到三个。
  3. 给你的工作流补一段描述，写清「用户说什么话时该调用它」。

常见误区

  1. 「名字无所谓，能跑就行。」日志里写的是节点名，出问题时你数不过来第几个。
  2. 「开始节点字段越多越灵活。」调用方会漏填，而工作流不知道它漏了，会用默认值继续跑。
  3. 「先把结束节点定死。」中途每改一次输出都要回来改。先跑通，再定契约。
自测三问（点开对答案） 1. 为什么说节点名是接口？ —— 引用写法是 `节点名.字段名`。改名之后所有引用它的地方一起坏，和改数据库字段名一样。 2. 开始节点定几个字段合适？ —— 三个左右。一个必填，两个可选带默认值。到五个就要警惕调用方漏填。 3. 为什么先不急着定结束节点？ —— 中途会反复改输出。先让链跑通，再回来定契约，省的是一遍遍返工。

地基好了，下一节装第一个真模块：抓热点。 它要用插件，而插件那一侧随时可能挂——这一节量「挂了怎么办」。

相关笔记