企业官网建设流程全解析

上个月帮一位做后端的同行改文档，他甩过来两千多字的接口说明，问能不能把这堆文字变成一张能放进技术方案里的流程图。我第一反应是直接把文字丢给模型让它画，结果出来的东西节点乱序、条件分支全糊成一条直线，连"失败重试"这种关键回退都被吃掉了。后来我把这件事拆成两段：先让模型做它真正擅长的语义抽取，把文字变成一份结构化的中间描述；再由一段固定模板的脚本，把中间描述翻译成文本化的图形语法，交给渲染器出图。这套东西跑顺之后，我把它固化成了一个可复用的Skill，配合文本化图形语法，文字改流程图这件事的准确率从"能看"变成了"能交付"。

这篇东西想讲清楚三件事：这套管线为什么这么分层、Skill 里的提示词到底该怎么写、以及把图交给渲染器之前必须做哪些校验。适合三类人看——经常要把需求文档转成流程说明的产品和研发、要写 SOP 图的操作岗，以及正在给内部工具接 AI 能力、但被"生成的图没法用"折磨过的开发者。不需要你会画图，能读懂一段中文流程描述就够了。

1. 为什么要在文字和流程图之间硬插一层 Skill

1.1 直接让模型"出图"的三个翻车现场

我先说说失败的样子，因为大部分人对这事的期待就停在"一句话生成一张图"，而现实是三个坑连着踩。

第一个坑是顺序失真。原始文字里"审核通过后通知客户，未通过则退回补充材料"，模型很可能把"通知客户"和"退回补充材料"画成并列的两个步骤，而实际上它们是同一个判断节点的两条出边。语义上并列和分支是两回事，但模型在生成图形语法时，注意力被"格式化输出"占掉了，语义判断就变糙。

第二个坑是节点粒度失控。同一段文字，有时候它把一整句"校验库存并锁定库存然后生成订单"塞进一个节点框，有时候又把"校验"拆成"读取库存""比较数量""返回结果"三个框。粒度飘忽的图，读者看完比不看还累。

第三个坑是语法不自洽。文本化图形语法对符号很敏感，全角括号、标签里带方括号、ID 用中文、子图没闭合，任何一处出错，渲染器要么报错要么画出一坨谁也看不懂的东西。让模型一边理解业务语义、一边操心排版语法，等于让一个人同时写文章和排版，两头都容易塌。

注意：这三个坑不会因为换个更大的模型就消失。它们是"一岗多责"造成的结构性问题，不是能力问题。

1.2 Skill 的本质是一份可版本管理的窄域说明书

我理解的 Skill，不是一段更长的提示词，而是一份带验收标准的窄域说明书。它至少要说清四件事：什么时候该用它、输入长什么样、输出必须长什么样、做错了怎么自查。这四件事缺一件，它就是个玩具。

跟随手写的提示词比，Skill 有三个实打实的差别。一是可版本管理：改了一版提示词，能对比上一版的输出差异，知道这次改动是变好还是变坏。二是边界清楚：明确写死"只处理流程类文本，不处理状态机、不处理时序交互"，越界就拒答，比让它硬着头皮瞎编强。三是自带验收：输出格式固定到字段级，程序能直接校验，不用人肉看。

举个具体的对比。随手提示词写"请把下面的文字转成流程图"，模型给你什么全看运气。Skill 里写的是"输出必须是一个 YAML 块，包含 nodes 和 edges 两个顶层键，nodes 每项必须有 id、type、label 三个字段，type 只能取 start、process、decision、end、error 五个值之一"。前者是许愿，后者是下单。

1.3 三段式管线：语义抽取、结构校验、语法渲染各归各位

把整件事拆成三段，每段只干一件事，是我试下来最稳的做法。

这么分的好处很直接。可定位：图丑是渲染层的问题，图错是抽取层的问题，一眼能分出来，不用整条链路重跑。可换皮：同一份中间结构，今天渲染成自上而下的主干图，明天渲染成横向泳道图，模型不用重新调用一次，省钱也省时间。可回滚：渲染规则改坏了，退回去就行，抽取结果还在。

反过来，如果你把渲染细节也塞进 Skill 里让模型一起干，那就回到了 1.1 说的老路。我踩过这个坑，当时为了"一步到位"，让模型直接输出带样式类的完整图形语法，结果它花了大量 token 在颜色和形状上纠结，业务逻辑反而错了两处。后来把样式全部移到模板层，抽取准确率立刻回来了。

2. 拆解输入：把一段人话切成节点和边

2.1 节点识别的三条启发式规则

让模型"理解"一段文字很容易，让它"切"出正确的节点很难。我后来总结出三条启发式规则，写进 Skill 之后效果稳定很多。

第一条，谓语优先，虚动词剥壳。中文流程描述里大量出现"进行审核""做校验""执行派单"这类结构，真正的动作藏在后面那个名词化的动词里。规则就是：遇到"进行/做/执行/开展"这类虚动词，把它剥掉，后面的词才是节点名。所以"进行库存校验"要变成节点"校验库存"，而不是节点"进行库存校验"。这一步做完，节点标签会短一截，图立刻清爽。

第二条，判断词触发菱形。只要句子里出现"是否""能否""有无""够不够""满足……吗"，这个位置就是一个判断节点，必须以问号结尾。这条规则最大的价值是防止模型把判断画成普通处理框——判断框和方框在视觉上是完全不同的信息层级，画错了读者会误以为那是要执行的动作。

第三条，角色名收敛为泳道，不进节点。一段文字里反复出现的"客服""仓库""财务"，是角色不是动作，它们应该变成泳道或子图的标题，而不是节点。我见过太多图把"客服"画成一个方框，然后画一条线指向"审核"，读起来莫名其妙——审核的不是客服这个人，是客服这个角色执行的动作。

提示：这三条规则建议直接抄进 Skill 的"抽取规则"段落，用编号列出，比一大段自然语言描述管用得多。

2.2 关系抽取：顺序、条件、并行、回退四种边

节点切对了，边画错了照样白搭。中文里表达关系的词其实很有限，我按四类做映射。

顺序边由"然后、接着、之后、随后、再"这些词触发，方向是单向的。这里有个细节：如果原文完全没写连接词，只是靠逗号并列，默认按书写顺序连成链，这是最符合直觉的兜底策略。

条件边由"如果、若、一旦、当……则"触发，从判断节点分出两条或更多出边，每条边必须带标签。标签优先用业务语义词而不是"是/否"，比如"库存充足"和"库存不足"，比"是/否"信息量大得多。

并行边由"同时、并行、各自、分别"触发。这里有个容易忽略的点：并行之后必须有汇合。原文里经常不写汇合点，但图里如果不汇合，读者会以为流程断头了。我的处理是自动补一个"汇合"标记节点，或者把两条并行支路直接连到下一个共同的后继节点上。

回退边由"重新、退回、回到上一步、再次提交"触发。这类边必须用虚线，而且要明确指回哪个节点。回退边是最容易被模型吞掉的一类，因为它在文字里往往只是短短一句"不通过则退回修改"，藏在长段落末尾。

2.3 命名与编号的硬约束

命名这件事看着琐碎，实际上决定了后面所有自动化能不能跑起来。我给自己定了四条硬约束，全都写进了 Skill。

ID 用英文加数字，标签用中文。比如S1、P3、D2，前缀表示类型，数字表示顺序。中文 ID 在某些渲染器里会出问题，而且肉眼排查时中英混排的 ID 极难对齐。

每个标签不超过 14 个汉字。超过就说明这个节点该拆了，或者该把修饰语挪到边标签上。14 这个数不是拍脑袋——按常见文档字号和节点内边距估算，14 个汉字大约占 200px 宽，横向排 4 到 5 个节点刚好填满一屏，再多就得缩字号，缩完就没人看得清了。

判断节点标签必须以问号结尾。这条是强制的，因为它能同时起到两个作用：让读者一眼识别，也让校验脚本能自动检查。

动宾结构优先。"校验库存"优于"库存校验"，"生成订单"优于"订单生成"。动宾结构读起来是一个动作，名词结构读起来像一个东西，而流程图的主语是动作。

3. 中间描述层怎么写：让图形语法替你做校验

3.1 为什么中间层选结构化数据而不是图形语法

这里有个关键决策：Skill 的输出到底是图形语法，还是更原始的结构化数据？我选了后者，理由有三条。

第一条，职责分离。图形语法是给人看的排版语言，里面混着方向声明、节点形状、连线样式、子图嵌套，这些都是排版决策。让模型同时做语义抽取和排版决策，等于让它一心二用。中间层只描述"有哪些节点、谁连谁"，排版交给模板，各干各的。

第二条，可程序化校验。YAML 或者 JSON 能被脚本直接解析，能查空节点、查重复 ID、查悬空边、查没有被任何边指向的孤岛。图形语法是一段字符串，程序校验起来要么靠正则（脆），要么靠渲染器报错（晚）。

第三条，复用性。同一份中间结构，能渲染成流程图、泳道图、状态机图、检查清单表格。我甚至用它直接生成过一份纯文字的步骤表给不习惯看图的同事，五秒钟的事。

中间结构大概长这样，字段我控制在最少：

meta: title: 工单处理主流程 direction: TD nodes: - {id: S1, type: start, label: 收到工单} - {id: P1, type: process, label: 自动分类打标} - {id: D1, type: decision, label: 是否属于售后类?} - {id: P2, type: process, label: 转售后队列} - {id: P3, type: process, label: 转技术支持队列} - {id: E1, type: end, label: 工单归档} edges: - {from: S1, to: P1} - {from: P1, to: D1} - {from: D1, to: P2, label: "是"} - {from: D1, to: P3, label: "否"} - {from: P2, to: E1} - {from: P3, to: E1}

这段东西的好处是：任何一个字段缺了，脚本立刻报错；任何一个节点名太长，脚本能量出来；任何一条边指向不存在的 ID，脚本能拦住。所有问题都在"还没画图"的阶段暴露。

3.2 关键字与结构的对照表

真正做渲染的时候，文本化图形语法的关键字其实没几个，我列一张对照表，够用了。

这张表里最容易出事的是带标签实线那一行。标签里的竖线、方括号、圆括号、分号，全部会破坏解析。我的做法是在渲染脚本里做统一转义：先把标签里的半角符号替换成全角，或者干脆用双引号包起来。这一层处理做在脚本里，比让模型小心谨慎靠谱一万倍。

还有一个细节：节点文本里如果出现括号，很多渲染器会把它当成形状声明，导致后半句被吞掉。所以渲染前必须扫一遍所有 label，把中文括号内容保留但整体加引号，把半角括号替换掉。这类问题不写进脚本，靠人工检查永远会漏。

3.3 分支、循环、并行三种结构的落地写法

分支结构的关键是"判断节点只有一个入边、两条以上出边，且每条出边都有标签"。校验脚本要专门查这一条：入边数量必须等于 1，出边数量必须大于等于 2，出边 label 不能为空。缺了 label，图就成了谜语。

循环结构在流程描述里通常表现为"不通过则退回重做"。落地时有三条边：进入循环的边、循环内的边、跳出循环的边。最容易被漏掉的是跳出边——原文写"反复修改直到通过"，模型可能只画一条指回去的线，然后就没了。校验规则是：每个被回指的目标节点，必须存在至少一条不指回去的后续路径。

并行结构是"同时做 A 和 B，之后汇合做 C"。落地时要有一个分叉点和一个汇合点，中间两条支路。如果原文没写汇合，按"两条支路都指向 C"处理，视觉上就是汇合。这里有个小技巧：分叉和汇合如果用两个明确的节点（比如"分派"和"汇总"），图会更容易读；如果直接用连线分叉，主干会看起来突然变粗。

提示：三种结构不要混在同一层里。分支套并行再套循环，图会立刻变成蜘蛛网。我的经验是，同一张图最多允许两种结构嵌套，超过就拆图。

4. Skill 提示词的完整写法，可以直接照着改

4.1 骨架：角色、输入约定、输出契约、自检清单

一份能用的 Skill，我固定写四段，顺序不乱。

第一段，角色与边界。一句话说清它是什么，再用两句话划边界。比如"你是一个流程文本结构化工具，负责把自然语言描述的业务流程转成节点边列表。你只处理有明确先后关系的流程类文本；遇到状态机、时序交互、组织结构描述，直接返回拒绝并说明原因。"边界写清楚，比写十句"请仔细分析"有用。

第二段，输入约定。明确告诉它原文可能长什么样：可能带序号、可能不分段、可能有口语填充词、可能一句话里塞了三个动作。再告诉它预处理原则：先把长句按动作切短，再标出判断词，再标出连接词。这套"先切后标"的流程写进 Skill，模型执行时会稳很多。

第三段，输出契约。字段级写死，一个不许少，一个不许加。写明类型枚举、ID 命名规则、标签长度上限、边标签必填条件。这一段是整个 Skill 的核心，写得越死，输出越稳。

第四段，自检清单。让它输出前自己过一遍：有没有节点没连边、有没有判断节点只有一条出边、有没有节点标签超过 14 字、有没有边指向不存在的 ID。自检不过就重来一次。这一段能消掉大概六成的低级错误。

4.2 输出契约：固定中间格式的三个必填项

输出契约里我坚持三个必填项，缺一个就退回。

节点类型枚举。只允许 start、process、decision、end、error 五个值。为什么不给更多？因为再多就没人记得住，模型会乱用。这五个值覆盖了绝大多数业务流程，够用。

ID 前缀对应类型。S 开头是开始，P 是处理，D 是判断，E 是结束，X 是异常。这样光看 ID 就能猜出节点性质，排查问题时省一半时间。

边标签的必填条件。从判断节点出发的边必须有标签，其余可省。这条规则简单但有效，因为它把"该说说清楚的地方"圈出来了。

还有一个我后来加上的约束：节点总数超过 15 个时，必须输出拆图建议。不是硬拆，是建议，比如"建议按角色拆成两张图，第一张覆盖接单到分派，第二张覆盖处理到归档"。这条约束让模型在结构太复杂时主动示警，而不是硬着头皮画一张谁都看不懂的图。

4.3 自检与重试：让模型自己抓自己的错

自检机制我做了两层。

浅层自检在模型内部完成，就是 4.1 说的那段清单。它便宜、快，能拦住大部分格式错误。

深层校验放在脚本里，模型输出之后立刻跑。检查项包括：ID 唯一性、边端点存在性、判断节点出边数量、孤岛节点检测、标签长度、循环闭合性、并行汇合检测。任何一项不过，把校验报告原样喂回模型，让它只修报告里指出的问题，不要重写全文。

这个"只修不重写"的约束很关键。早期我让它收到错误就重新生成，结果修好一处、弄坏两处，来回几轮还不如第一版。改成增量修复之后，通常一两轮就能收敛。

def validate(graph): errors = [] ids = [n["id"] for n in graph["nodes"]] if len(ids) != len(set(ids)): errors.append("存在重复 ID") id_set = set(ids) for e in graph["edges"]: if e["from"] not in id_set or e["to"] not in id_set: errors.append(f"悬空边 {e}") reached = {e["from"] for e in graph["edges"]} | {e["to"] for e in graph["edges"]} for n in graph["nodes"]: if n["id"] not in reached and len(graph["nodes"]) > 1: errors.append(f"孤岛节点 {n['id']}") for n in graph["nodes"]: if n["type"] == "decision": outs = [e for e in graph["edges"] if e["from"] == n["id"]] ins = [e for e in graph["edges"] if e["to"] == n["id"]] if len(outs) < 2: errors.append(f"判断节点 {n['id']} 出边不足") if len(ins) != 1: errors.append(f"判断节点 {n['id']} 入边不是 1") if any(not e.get("label") for e in outs): errors.append(f"判断节点 {n['id']} 出边缺标签") return errors

这段逻辑不复杂，但它把"图能不能读"这个主观判断，变成了几条可执行的客观规则。这是整套东西能稳定跑起来的地基。

4.4 一份完整示例：从客服工单描述到成图

拿一段真实的描述性文字举例，原文大概是："客服收到工单后先做分类打标，如果属于售后类就转售后队列，否则转技术支持队列。两个队列处理完之后统一归档，归档失败的工单退回重新处理。"

按 Skill 跑一遍，抽出来是 7 个节点、8 条边。节点分别是：收到工单（起点）、分类打标（处理）、是否售后类（判断）、转售后队列（处理）、转技术支持队列（处理）、统一归档（处理）、工单归档（终点），加上一条从"统一归档"回到"分类打标"的虚线回退边和一条异常边。

这里有个细节值得说：原文说"归档失败的工单退回重新处理"，但它没说退回哪里。模型第一版直接丢掉了这条边。我在 Skill 里加了一条规则——遇到"退回/重新"但没写目标时，默认指回最近的判断节点，并在边的标签上标注"退回重处理"。改完之后这条边就稳定出现了。

渲染出来的结构大致是：顶部起点，向下到分类打标，分叉到两个队列，两条支路汇到统一归档，最后到终点，另有一条虚线上指。整个过程从输入文字到拿到可用图形语法，熟练之后五分钟以内。

5. 排版与美观：让自动生成的图能直接进文档

5.1 方向、分组与泳道的选择依据

自动生成的图最容易犯的毛病不是错，是丑。丑的核心原因通常是方向选错。

主干节点在 5 到 8 个之间，用自上而下。这个区间里纵向排布视觉重心稳，横向排会显得飘。主干超过 8 个，改用自左向右。因为纵向拉太长，一屏放不下，读者得滚动，滚动就断了阅读节奏。我自己算过一笔账：节点高度按 40px 计，加上连线间距 30px，8 个节点纵向约 560px，正好是一屏可视区的舒适范围，再多就得横过来。

分组用子图，但子图层级不要超过两层。一层子图表达角色或模块，两层表达"模块下的阶段"。三层以上，边框会把图切成碎片，缩略图状态下完全看不清。

泳道图慎用自动生成。泳道要求每个节点严格归属一个角色，而自然语言描述里角色经常是隐含的。我的做法是：只有当原文明确反复出现角色词时才启用泳道，否则一律用普通流程图加子图分组，视觉上够用了。

5.2 语义配色：四类节点四种色，别超过

配色这件事，我的原则是"宁少勿多"。整套图只用四类颜色：起点终点一类（浅灰）、处理步骤一类（浅蓝）、判断节点一类（浅黄）、异常与回退一类（浅红）。四类之外再加任何颜色，都会让读者开始猜"这个颜色是什么意思"，一旦开始猜，图就失败了。

落地方式是用样式类，而不是逐个节点写样式。样式类定义在图形语法的末尾，节点上只挂类名。这样改配色只改一处，几十个节点一起变，而且中间层数据里完全不用出现颜色信息——颜色是渲染层的事，不该污染语义层。

classDef startEnd fill:#eef1f5,stroke:#9aa5b1; classDef step fill:#e8f1fb,stroke:#6f9fd8; classDef decision fill:#fff6e0,stroke:#d8b26f; classDef warn fill:#fdecec,stroke:#d88f8f; class S1,E1 startEnd; class P1,P2,P3 step; class D1 decision; class X1 warn;

对比度也得留意。浅色填充配深色描边，文字用接近黑的深灰，这是最保险的组合。我试过用饱和度高的填充色，投影到会议大屏上直接糊成一片，字都看不清。

5.3 节点数量控制与拆图策略

一张图能承载多少信息，是有生理上限的。我的经验值是主干不超过 15 个节点，分支深度不超过 3 层，单张图连线不超过 25 条。超过这三个数里任何一个，读者的理解成本会指数上升。

超了怎么办？三条拆法。按阶段拆：接单、处理、归档各一张，图与图之间用"见下图"的标记节点衔接。按角色拆：每个角色一张，只画它参与的环节和它与别人的交互点。按异常拆：主干一张只画正常路径，所有异常和回退单独一张，标题写"异常处理分支"。第三种拆法我用了最多，因为正常路径通常很短，异常路径才是真正复杂的地方，混在一起两边都不清楚。

注意：拆图之后一定要在每张图顶部保留同一个总标题和"第 X 张，共 Y 张"的标记，否则读者拿到散图会不知道从哪张看起。

6. 常见问题与排查实录

6.1 高频问题速查表

这张表里，我遇到频次最高的是第一条和第五条。第一条几乎每次接入新环境都要踩一遍，因为不同渲染器对符号的宽容度不一样。第五条是纯经验问题，多画几十张就有手感了。

6.2 几个容易被忽略的坑

坑一：把"用户点击提交"当成处理节点。界面操作和业务动作是两回事。一段描述里如果混着"用户点击""页面跳转""弹窗提示"这类交互细节，全部要过滤掉，只保留业务动作。不然图画出来像一份交互稿，不是流程图。我在 Skill 里加了一条"过滤 UI 交互词"的规则，效果立竿见影。

坑二：时间状语被当成节点。"每周一自动汇总""三日内完成审核"里的时间信息，应该变成节点的附注或边标签，而不是独立节点。我见过把"每周一"画成一个菱形判断的图，读起来极其费解。处理办法是：识别到时间词就挂到最近节点的 label 后面加括号，不新增节点。

坑三：异常路径和主干混画。一段文字里如果既有正常流程又有"如果超时则……""如果数据缺失则……"，全画在一张图上会非常乱。我的做法是抽取阶段就打标记，异常节点统一用 error 类型，渲染阶段可以选择"只画主干"或"分两张画"。这个开关放在渲染脚本的参数里，一行配置的事。

坑四：改了原文没重跑校验。这个是流程问题。中间结构是人工改过的，原文一改，结构就过期了，但很多人忘了重跑。我的习惯是中间结构和原文放在同一个目录，原文文件加个校验和，脚本启动时对一下，不一致就警告。

坑五：过度追求一张图讲完所有事。这是最根本的坑。流程图的价值在于让人快速建立心智模型，不是把所有细节都塞进去。一张图讲一件事，剩下的用文字补充，比一张密密麻麻什么都有的大图有用十倍。

7. 场景落地与能力边界

7.1 三个真正跑得起来的场景

场景一：需求文档转流程说明。产品写了两千字的需求描述，研发看完还是不清楚分支条件。用这套管线跑一遍，五分钟出一张主干图，挂在需求文档顶部，评审会上省掉大量"这里到底怎么走"的来回。这个场景的关键是原文质量——描述越结构化，抽出来的图越准；如果原文本身就是散的，先让写文档的人补上顺序词和条件词，比事后让模型猜强。

场景二：SOP 手册配图。操作类手册里大量"先做 A，若 B 成立则做 C，否则做 D"的段落，纯文字读起来极其痛苦。批量转成流程图之后，新人上手时间能明显缩短。这个场景我建议加一道人工确认：机器出的图先给流程负责人过一遍，确认无误再进手册。因为 SOP 的错代价高，不能全信自动结果。

场景三：故障排查决策树。排查步骤天然是树状结构，用这套管线把排查文档转成决策树，值班的人顺着图往下走就行，不用在长文档里翻找。这个场景有个额外好处——决策树结构对"分支未闭环"特别敏感，校验脚本一跑，哪些排查分支没有给出结论一目了然，反过来还能帮着补全文档。

三个场景的共同点是：输入是有明确先后关系的描述性文字，输出是给人看的结构图。只要满足这两条，这套管线就有价值。

7.2 什么时候别用它

原文本身没有流程。一段讲概念、讲原理、讲架构的文字，硬转流程图只会得到一堆互相之间没有因果关系的方框。判断标准很简单：如果原文里找不到三个以上的顺序词或条件词，就别转了，那是说明文不是流程文。

流程需要精确的时序表达。多角色之间的消息往来、带时间轴的交互，用流程图表达会失真，这类内容需要的是另一种图形语言。Skill 里我明确写了边界：遇到时序交互描述直接拒答，并提示换用合适的表达形式。

涉及需要人工判断的合规内容。有些流程涉及资质审核、材料核验这类需要人工把关的环节，自动出图只能当草稿，绝不能当最终交付物。这不是技术问题，是责任问题。

图会被当作执行依据的场景。如果这张图会被拿去配置自动化流程、当作系统实现的输入，那必须有人工复核环节，而且复核人要签字确认。自动生成的图适合沟通，不适合当规范。

我自己在实际操作中的体会是，这套东西最大的价值不是"省了画图的时间"，而是"逼着写文档的人把流程想清楚"。很多时候图出不来，不是模型不行，是原文本身就逻辑断裂、条件缺失、步骤含糊。图在这里起到的是一面镜子的作用，照出的是文档的问题。

最后分享一个我常用的小技巧：让 Skill 在输出中间结构的同时，额外输出一份"存疑清单"，列出它在抽取过程中拿不准的地方，比如"第三段提到退回，但未说明退回目标，已默认指回分类节点，请确认"。这份清单经常比图本身还有用，因为它把模糊地带显性化了，评审会上直接照着清单逐条确认，比对着图猜要高效得多。

后续如果想把这件事做得更细，可以在中间层加一个"责任人"字段，渲染时自动生成泳道；也可以在渲染脚本里加一版 PDF 输出，直接嵌进周报模板。这些都是在同一套结构上长出来的枝叶，主干不用动。