一、为什么分步流程在生成式答案里最容易断裂

在所有被生成式引擎调用的内容类型里，操作步骤类是最特殊的一种。它不像参数表那样可以按单元格摘取，也不像观点文那样摘一句也能成立。步骤是一个有方向的结构：第 3 步的含义依赖第 1 步和第 2 步，第 5 步的前提是第 4 步已经完成。一旦摘取过程丢掉中间环节，剩下的内容不但不完整，还会变成错误答案。

更麻烦的是，生成式引擎在组织答案时并不像人那样从头读到尾。它做的是分块、打分、重排、拼接：先把页面切成若干个可独立成立的语义块，再判断哪一块最像用户要的答案，最后把这些块拼成一段话。这个机制决定了——你的步骤如果不在结构上被标记为「一个连续的序列」，它就会被当成「若干条并列的建议」来处理，而并列关系是可以任意取舍、任意排序的。

1.1 一次典型的摘取失败

设想一个真实的场景。某家设备厂商的帮助中心里有这样一段文字：

用户如需报修，可先登录服务大厅，在设备列表中选中故障设备，点击报修按钮，填写故障描述并上传照片，提交后系统会生成工单号。若设备已过保，需先在线支付检测费，支付成功后工单才会进入派单队列。工程师通常会在 24 小时内联系，上门前会电话确认时间。

这段文字对人来说完全可读，但对机器来说，它是一整块没有边界的叙述。当用户问「设备报修怎么弄」，引擎很可能只摘出前两句，给出一段看似完整、实则漏掉关键条件的答案：用户按提示提交了工单，却不知道过保设备还要先付费，工单一直躺在待支付状态里。这就是典型的步骤完整性缺失。

再换一个问法：「报修要多久有人联系」。引擎可能摘到「24 小时内联系」，把它当成答案，但把「需先支付检测费」这个前置条件丢了。用户看到的答案是「24 小时内」，实际体验是三天没人理——因为他的工单根本没进入派单队列。答案本身没有说错任何一个字，但它错在对条件的省略。

1.2 四个必须先统一的术语

讨论步骤类内容的优化，如果不先把术语钉死，后面所有判断都会飘。本文统一使用四个概念，它们同时也是后面自检清单的判定依据。

• 可摘取单元：一段在脱离上下文后仍然语义自足、可以被单独引用而不产生歧义的内容块。一个可摘取单元的边界通常由标题、编号或明显的段落转折来划定。判断标准很简单：把这一块单独拿出来发给一个没看过全文的人，他能不能正确理解。
• 步骤完整性：从触发条件到终态结果的全部环节都被保留，既不缺步，也不把同一步拆成两步造成虚增。完整性不是「字数够多」，而是「必要动作一个不少，冗余动作一个不多」。
• 条件分支：在某一步上因对象属性、账户状态、时间窗口、金额区间等差异而产生不同走向的结构。条件分支的核心特征是「互斥」与「可判定」——用户能根据自身情况明确选一条路走。
• 验收标准：每一步完成后可以观察到的、可验证的结果信号。它是把「我做了」和「我做对了」区分开的东西，也是AI判断这一步是否结束的依据。

这四个词的关系可以这样理解：可摘取单元是容器，步骤完整性是容器里该装的东西有没有装齐，条件分支是容器之间的岔路口，验收标准是每个容器底部的封条。四者齐备，一段流程才真正具备被机器完整搬运的条件。

1.3 为什么这类内容值得优先投入

从投入产出比看，操作步骤类内容是整个内容体系里最容易被生成式引擎反复调用的部分。原因有三：一是问法极其稳定，用户不会用一百种方式问「怎么开发票」；二是答案的可验证性强，用户照着做完就知道对不对，反馈信号清晰；三是这类问题往往对应真实转化路径上的关键节点，被正确回答一次，可能直接带来一次下单、一次续费、一次到店。

反过来说，步骤类内容一旦被截断，伤害也是加倍的。观点文被摘错，用户顶多觉得这段说得不全；步骤被摘错，用户会照着做，然后卡住，然后认定这个品牌不专业。所以在这个类型上，结构的严谨度比文采重要得多。

二、先识别：哪些问题属于操作步骤类

优化的第一步不是写，而是判断。站内几百上千篇内容，不可能每一篇都按步骤体改造。你需要一套快速识别的口径，把真正属于流程型的页面挑出来。

2.1 五类典型句式与它们的共同结构

中文里询问流程的句式高度收敛，绝大多数可以归入下面几类。它们的共同点是：都隐含一个「从状态 A 到状态 B」的迁移，且这个迁移需要用户执行若干动作才能完成。

• 怎么装 / 怎么安装 / 怎么配置：典型的技术执行型流程，动作之间有严格的先后依赖，前一步的输出是后一步的输入。识别信号是出现「环境」「版本」「依赖」等词。
• 怎么申请 / 怎么开通 / 怎么入驻：典型的手续办理型流程，特点是存在审核环节和材料清单，中间会有等待期。识别信号是出现「材料」「资质」「审核」「工作日」。
• 怎么报修 / 怎么投诉 / 怎么退款：典型的救济型流程，特点是入口隐蔽、条件分支多、用户情绪焦虑。识别信号是出现「故障」「凭证」「时效」「进度」。
• 怎么开发票 / 怎么报销 / 怎么对账：典型的票据型流程，特点是字段多、校验严、错一次要重来。识别信号是出现「抬头」「税号」「金额」「开具」。
• 怎么退换 / 怎么改签 / 怎么取消：典型的逆向型流程，特点是时间窗口决定路径，超时即不可逆。识别信号是出现「天内」「未使用」「原包装」「手续费」。

这五类之外还有一些变体，比如「怎么把 A 导入 B」「怎么从旧版本升级到新版本」「怎么把个人账户转成企业账户」。判断方法一致：看这个问题能不能被拆成一串「做完了没有」的检查点。能拆，就是步骤类；拆不出来，多半是概念解释或对比选择。

2.2 从用户口语翻译成可执行结构

用户的原话往往不适合直接当标题，但它包含了最真实的信息需求。做识别时要养成一个习惯：把口语问法翻译成「对象 + 动作 + 终态」的三段式。

例如「发票开错了能重开吗」，翻译后是「对象：已开具的电子发票；动作：申请红冲并重新开具；终态：拿到正确抬头的发票文件」。这个翻译过程会立刻暴露一个问题——用户真正想知道的不是「能不能」，而是「怎么操作，要多久，要不要收费」。如果你只回答「可以重开」，看起来答了，实际上把最有价值的部分留空了。

再如「装机师傅多久上门」，表面是时间询问，实质是流程询问的切片。只答一个时长数字，用户仍然不知道自己要做什么。正确的处理是把这个切片放回完整流程里，先给全流程，再单独强调时效节点。这一点在后文讲「耗时与成本」时还会展开。

2.3 三种看起来像但不是步骤类的问法

误判的代价是把该讲清楚的对比写成了流程，或者把流程写成了散点。以下三类需要排除。

• 选择型：「A 和 B 哪个好」「该选套餐一还是套餐二」。这类问题的答案是判断依据和适用场景，不是执行序列。如果强行写成步骤，会变成「第一步评估需求、第二步比较价格」这种没有信息量的空壳。
• 概念型：「什么是红冲」「保内保外怎么界定」。这类需要定义、边界和例子，写成步骤会丢掉定义本身。
• 状态型：「我的工单现在到哪了」「为什么还没审核通过」。这类是查询而非操作，正确做法是给查询入口和状态含义对照，而不是给一串动作。

不过要留意，这三类经常和步骤类伴生。一个高质量的流程页面，通常在开头用一小段解释概念，在分支处用一小段做对比，在结尾用一小段说明如何查询进度。区别在于主干是流程，其余是配件，不能让配件挤掉主干。

三、AI 截断的四种典型病理

知道了哪些内容要改，接下来要知道改成什么样。先看清失败模式，比先学写作模板更有效，因为模板只能覆盖常见情况，而失败模式能帮你判断眼前这一篇到底哪里出了问题。

3.1 只摘前两步：开头权重陷阱

生成式引擎在抽取时对段落开头有天然的偏好，因为开头往往承载主题句。当一段流程被写成连续叙述时，前两句通常包含最多的主题词（登录、进入、点击），得分最高；后面的步骤因为用词重复、信息密度下降，得分递减。结果就是答案停在了第二步。

这个病理的根因不是引擎懒，而是你的后几步在语义上和前几步高度同质。「点击保存」「点击确认」「点击提交」这三个动作，在向量空间里几乎重合，引擎没有理由认为第三个比第一个更重要。解决办法是让每一步都携带独有的、可区分的信息——不是「点击提交」，而是「点击提交后页面跳转到工单详情页，顶部显示以 WO 开头的编号」。

3.2 顺序错乱：并列结构冒充顺序结构

这是最常见也最隐蔽的一种。当步骤用无序列表、或者用「首先、其次、另外、还有」这类松散连接词写出来时，结构上传递的信号是「这些是并列的要点」。并列关系在摘取时是可以重排的，于是答案里出现「先上传照片再填写描述」这种颠倒。

顺序错乱还有另一种表现：把「准备材料」和「提交申请」合并成一步，或者把「等待审核」省略掉，导致时间轴上出现跳跃。用户按答案操作时会发现，自己提交完就没了下文，不知道还要等，也不知道等多久。

要根治这个问题，必须在结构层面明确声明顺序。有序列表 <ol> 是最直接的顺序信号，编号本身就是语义。如果因为发布系统限制只能用无序列表，那就必须用文字编号把顺序写进内容里，这一点在第五章会给具体写法。

3.3 把条件句当步骤：判断被读成动作

「如果设备已过保，需要先支付检测费」这句话，在人类读者眼里是条件，在机器眼里可能是一个动作步骤。当它被单独摘出来放进步骤序列时，就变成了「第三步：支付检测费」——对保内用户来说，这是彻底的误导。

造成这个问题的原因，是条件句和步骤句在句式上太像：都是「主语 + 需要 + 动词短语」。区分它们不能靠句式，只能靠显式的结构标记。把条件单独成段、用「适用于」「仅当」「若…则跳过」这样的引导词，并且把它放在它所修饰的那一步之前，而不是混在步骤序列中间。

还有一个变体：把「注意事项」写进步骤里。「第三步，填写地址，注意不要填错邮编」。这句里的后半段是校验提示，不是动作。混在一起会让引擎把「注意不要填错邮编」也当成一个待执行项，答出来的内容就显得啰嗦且失真。

3.4 丢验收标准：只留动作不留结果

「提交申请」是一个动作，「提交后页面显示受理编号，同时收到短信」是一个结果。前者只能告诉用户做什么，后者才能告诉用户做成了没有。大量流程文档只写动作，导致被摘取后的答案变成一串动词，用户执行完仍然不确定自己是否成功。

验收标准的缺失还会带来一个连带问题：引擎无法判断流程在哪里结束。没有终态标记的文本，在分块时边界模糊，容易被拦腰切断，或者在末尾拼接上无关的客服话术。

四、步骤内容的六要素写法

下面这套六要素，是把一段口语化流程改造成可被稳定摘取的结构的最小完整集。六个要素不是六个写作技巧，而是六个必须回答的问题。任何一个没回答，流程就有被截断或误读的口子。

4.1 前置条件：把门槛写在门前面

前置条件回答的是「我能不能开始」。它包括四类信息：身份资格（是否为企业账户、是否实名）、物料准备（身份证、订单号、设备序列号）、环境要求（浏览器版本、是否需插网线、是否需关闭代理）、状态要求（订单是否已完成、是否在保修期内）。

写法上有两个要点。第一，前置条件必须独立成段，且位于步骤序列之前。它不是一个步骤，把它编成「第一步：准备材料」会造成两种伤害：一是让真正需要判断资格的用户误以为只要准备材料就行，二是让不需要准备的人多走一步。第二，前置条件要写成可判定的陈述句，而不是模糊的提醒。「企业账户需完成对公打款验证」是可判定的，「建议使用企业账户」不是。

如果前置条件本身带分支，比如个人用户和企业用户入口不同，那么正确的做法是在前置条件段落里就说明分流规则，然后在步骤标题上体现适用对象，而不是让用户在第三步才发现走错了路。

4.2 编号步骤：一步一件事

编号步骤的黄金法则是「一步一个动作，一步一个可观察结果」。判断一步是否过大，可以用一个简单的测试：这一步能不能用一句「做完之后你会看到什么」来收尾。如果不能，说明它其实包含了两步，应该拆开。

反过来，也不要拆得过细。「找到输入框」「点击输入框」「输入内容」是三个动作，但它是一步。过度拆分会让步骤数虚高，用户在答案里看到十二步会直接放弃，引擎也会因为步骤太碎而难以判断主线。

编号本身要连续、不跳号、不复用。分支内部的编号如果重新从 1 开始，必须明确标注它属于哪个分支，例如「A 路径第 1 步」。混编会造成顺序混乱，这是顺序错乱病理的主要来源之一。

4.3 每步验收标准：给每一步一个封条

验收标准是六要素里最容易被忽略、但对摘取质量影响最大的一项。它的写法有固定套路：动作 + 观察点 + 期望值。例如「点击提交后，页面顶部出现绿色提示条，文字为提交成功，同时工单列表新增一条记录」。

好的验收标准有三个特征。可观察：用户能用眼睛看到、用耳朵听到、在邮箱里收到。可区分：成功和失败的信号不一样，不会出现「无论成败都显示已处理」。有位置：明确告诉用户去哪里看，而不是笼统说「系统会提示」。

把验收标准写进每一步，还有一个额外好处：它天然地把「失败分支」引出来。因为一旦你定义了什么叫成功，就必然要回答「没看到这个信号怎么办」。

4.4 耗时与成本：把不确定性变成数字

用户在流程类问题上的焦虑，八成来自不知道要花多久、要花多少钱。这两项信息如果不给，引擎在回答「要多久」这类追问时只能给出模糊表述，而模糊表述在答案竞争里几乎没有胜算。

耗时要分层给：单步耗时（填写约 3 分钟）、环节耗时（审核 1 个工作日）、全流程耗时（从提交到收到，一般 3 到 5 个工作日）。分层的意义在于，用户卡在某一步时能定位自己是否正常。如果只给总时长，用户在第二步等了两个小时就开始怀疑。

成本要区分显性成本和隐性成本。显性成本是费用本身，要写清金额、计费方式、是否可退。隐性成本包括：是否需要邮寄（邮费谁承担）、是否需要到场（交通与请假）、是否需要重新排队（超时后是否要重新提交）。把这些写出来，答案的实用度会明显高于同题竞争者。

4.5 失败分支：为每一种卡住给出口

失败分支不是「如有问题请联系客服」这一句万能话。有效的失败分支必须满足三个条件：能定位、能自救、能升级。

• 能定位：描述具体的失败现象，而不是笼统的「操作失败」。例如「提交按钮置灰」和「提交后提示资质不符」是两个完全不同的问题，对应完全不同的处理。
• 能自救：给出用户自己可以尝试的一到两个动作，例如「清除浏览器缓存后重新进入」「确认发票抬头中不含特殊符号」。
• 能升级：自救无效时的下一个动作，包括联系渠道、需要提供的凭证、预期响应时间。凭证要具体到「订单号 + 截图 + 设备序列号」，而不是「相关材料」。

失败分支的位置很重要。它应该紧跟在可能失败的那一步之后，而不是全部堆在文末。堆在文末的分支，在摘取时最容易整段丢失，因为它离主步骤太远，语义关联被稀释。

4.6 完成后状态：明确终点在哪

流程必须有终点，而且要写得像终点。「完成后状态」要回答三件事：你现在拥有什么（凭证、编号、文件、权限）、系统里发生了什么（订单状态变更、权限生效、工单进入队列）、接下来会发生什么（谁在什么时候联系你、你需要做什么）。

这一段的写法建议用清单式短句，避免长段落。因为它是用户最可能截图保存的部分，也是引擎最喜欢引用的部分——它信息密度高、结论性强、可以独立成立。

举个反例：「流程完成后即告结束」。这句话等于没说。正例：「完成后，你会在账户的发票管理中看到一张状态为已开具的记录，可随时下载 PDF；同时该邮箱会收到一封含下载链接的邮件，链接有效期为 30 天。」两者的差别不在于字数，而在于是否给出了可验证的终态。

五、HTML 结构建议：能不用 ul 就别用 ul

内容写对只是第一步，结构标记决定了引擎如何理解这些内容的关系。这一步经常被忽视，但它的收益往往比改文字更快见效。

5.1 真实站点应该用 ol 而不是 ul

在标准 HTML 里，有序列表是 <ol>，无序列表是 <ul>。这两者的差别不是样式，而是语义：<ol> 明确告诉解析器「这些条目有顺序，顺序有意义」，<ul> 则告诉解析器「这些条目是并列的，顺序可以变」。对于操作步骤，正确的选择永远是 <ol>。

很多站点的编辑器默认把列表按钮做成无序列表，运营人员也就顺手用了。这在视觉上靠 CSS 加个序号就能掩盖，但语义上丢掉了最关键的信息。如果你的发布系统支持源码编辑，务必把步骤列表改成 <ol>；如果支持自定义模板，让技术同事在步骤区块的组件里默认输出 <ol>。

需要说明的是，本文所在的发布环境只允许使用 <ul> 与 <li>，无法输出 <ol>。这不是推荐做法，而是约束条件下的妥协。在真实站点上，正确的做法是 <ol> 加 <li>，并确保序号由标签本身产生，而不是把序号写死在文字里再套一个 <ul>。

5.2 只能用 ul 时，如何把顺序写进内容

当结构上无法表达顺序时，就要用文字把顺序「焊死」，让顺序信息成为内容的一部分，即使被拆开也不会丢。有三种可行写法，可靠性依次递减。

• 前缀编号法：每条 li 以「第 1 步：」开头，编号与步骤名同时出现。这样即使列表被拆成独立片段，每个片段仍自带位置信息。编号用汉字还是阿拉伯数字不影响效果，但要全文统一。
• 依赖声明法：在步骤描述里显式写出依赖关系，例如「在第 2 步拿到受理编号后，回到首页…」。依赖词（之后、之前、完成后、在此之前）是顺序的强信号，比编号更难被忽略。
• 状态衔接法：用上一步的终态作为下一步的起点，例如「页面跳转到支付页后，选择对公转账」。这种写法把顺序编码进了状态变化，即便重排也会立刻暴露逻辑矛盾。

三种方法可以叠加使用，效果最好的是「前缀编号 + 状态衔接」。编号给出显式位置，状态衔接给出隐式因果，两者互为校验。

5.3 标题层级与片段边界

片段边界决定了内容被切在哪里。切割位置越合理，每个片段越自足。给流程类内容划边界，遵循三条规则。

• 一个 h2 只承载一个完整流程。不要把「开票流程」和「退换流程」放在同一个 h2 下，哪怕它们同属售后。
• 流程内部的阶段用 h3 切分，阶段名要包含动作与对象，例如「提交申请与材料上传」，而不是「申请阶段」这种空泛命名。
• 不要用加粗文字代替标题。加粗只是视觉强调，不产生结构边界；引擎看不到你的视觉设计，只看到标签。

5.4 四个常见的结构错误

这四点在审查时最常被查出，且都能在一分钟内修好。

• 把整段流程塞进一个段落，用逗号和句号连接。段落是最弱的边界，几乎必然导致截断。
• 用分割线或空行代替标题来分隔阶段。视觉上分开了，语义上没有。
• 步骤里再嵌套多层列表。嵌套超过两层后，层级关系在摘取时极易丢失，宁可直接展开成平铺步骤。
• 同一个流程在不同页面重复出现且版本不一致。这会让引擎在多源比对时无法确定哪一版为准，最终可能都不采用。

六、改造前与改造后：一段完整对照

理论说再多，不如看一遍真实的改写。下面这段原文来自一个典型的帮助中心页面，主题是「怎么申请开具电子发票」。原文不长，但几乎踩中了前面提到的所有问题。

6.1 改造前的原文

用户可以在订单完成后申请开具电子发票。登录官网后进入个人中心，找到发票管理，输入订单号，选择开票类型，然后提交。如果订单完成超过 30 天，需要联系客服处理。开具成功后可以下载 PDF。企业用户需要填写税号，个人用户不需要。发票金额以实付金额为准，不含运费。

这段文字的问题可以逐条数出来。第一，步骤与条件混在一起，「如果订单完成超过 30 天」夹在流程中间，极易被当成一个步骤。第二，没有编号，顺序信号只靠「然后」一个词，第二步和第三步可以被任意调换。第三，没有验收标准，「提交」之后发生什么完全空白。第四，耗时与成本缺失，用户不知道要等多久、要不要钱。第五，失败分支只有一句「联系客服」，没有说联系谁、带什么。第六，终态描述太轻，「可以下载 PDF」没有说在哪里下载、有效期多久。

更关键的是，这段文字被写成了一整段。在分块时，它要么被整段采用（那还好），要么被从中间切断，切点完全不可控。如果切在「如果订单完成超过 30 天」这里，后面的内容就成了孤立的注意事项，前面的步骤则失去了条件说明。

6.2 改造后的文本

适用对象与前置条件

本流程适用于已在官网完成支付、且订单状态为已完成的用户。开始前请确认三件事：订单完成时间在 30 天以内；账户已完成实名认证；知道开票抬头与税号（企业抬头必须填税号，个人抬头不需要）。若订单完成已超过 30 天，不要走本流程，请直接跳到文末的超期处理分支。

操作步骤

• 第 1 步：登录官网后进入个人中心，在左侧菜单点击发票管理。完成标志：页面右侧出现发票列表，顶部有申请开票按钮。耗时约 1 分钟。
• 第 2 步：点击申请开票，在弹窗中输入订单号。完成标志：订单信息自动带出，显示商品名称与实付金额。若提示订单不存在，先核对订单号是否含空格，仍失败则走订单号异常分支。
• 第 3 步：选择抬头类型并填写信息。企业抬头需填公司全称与税号，个人抬头只需填姓名。完成标志：税号输入框下方出现校验通过的绿色标记。耗时约 2 分钟。
• 第 4 步：核对开票金额。金额以实付金额为准，不含运费与优惠券抵扣部分。完成标志：金额栏数字与订单详情页的实付金额一致。
• 第 5 步：点击提交。完成标志：弹窗关闭，发票列表新增一条状态为开具中的记录，同时预留邮箱收到受理通知。系统处理通常在 10 分钟内完成。
• 第 6 步：下载发票。状态变为已开具后，点击该条记录的下载按钮获取 PDF。完成标志：本地得到一份 PDF 文件，文件内的抬头、税号、金额与提交内容一致。下载链接在账户内长期有效，邮件中的链接有效期为 30 天。

分支一：订单完成超过 30 天

超过 30 天的订单无法自助开票，需提交人工申请。准备订单号、付款凭证截图、开票信息三项材料，通过在线客服提交，人工处理时间为 3 个工作日。处理完成后发票会直接出现在发票列表中，不会另行邮件通知，请自行查看。

分支二：提交后长时间停留在开具中

正常情况下 10 分钟内完成。若超过 2 小时仍为开具中，先刷新列表；仍无变化则说明税务端回调异常，需联系客服并提供订单号与提交时间，由后台重新推送。此过程不影响已提交的开票信息，无需重复申请。

完成后状态

你会在发票管理中看到一张状态为已开具的记录，可随时下载 PDF；预留邮箱会收到含下载链接的邮件。该发票可用于报销与抵扣，如需红冲或重开，需在开具后 90 天内发起，且每张发票仅支持重开一次。

6.3 逐项差异说明

对比两版，改动可以归为五类，这五类也构成了后面自检清单的骨架。

• 边界：从一整段变成六个带标题的区块，每块都能独立成立。原来不可控的切点，现在由标题决定。
• 顺序：从「然后」连接变成显式编号，并叠加状态衔接（拿到受理编号后才进入下载）。即使结构标签失效，顺序仍然可读。
• 条件：从夹在中间的条件句，变成独立的「适用对象与前置条件」段落加两个独立分支段落。条件不再是步骤，而是分岔口。
• 验收：每一步都补了完成标志，用户能在每一步自检，引擎也能判断这一步在哪里结束。
• 终态：从「可以下载 PDF」扩展为「在哪里看到、收到什么、有效期多久、后续还能做什么」，把终点写成了可验证的状态。

值得注意的是，改造后的字数大约是原来的三倍，但信息并没有变多，只是把原本隐含的判断、等待、校验全部显性化了。这些显性化的内容，恰恰是引擎最需要、用户最容易卡住的地方。

七、条件分支的写法：让判断和动作各归其位

条件分支是步骤类内容里最容易出错的部分，因为它同时涉及结构和语义。写好了，答案能精准命中不同人群；写不好，所有人都会看到不属于自己的那条路。

7.1 分支前置：条件写在它所修饰的步骤之前

一条稳定的规则是：条件永远出现在动作之前，而不是之后。原因很实际——用户需要在动手前知道自己的路径，而不是做到一半才发现走错。对引擎而言，前置的条件更容易和后续步骤建立修饰关系，后置的条件则常常被当成补充说明而丢弃。

分支的组织方式有两种。垂直式是把分支放在主流程之后独立成段，适合分支较少、且分支内部步骤较短的情况。水平式是在主流程的某一步内直接标注「若 A 则做 X，若 B 则做 Y」，适合分支只影响单步的情况。选择哪种，取决于分支影响的步数：影响一步用水平式，影响多步用垂直式。

7.2 分支内部编号的重置规则

这是一个细节，但它直接决定答案读起来是否清楚。当分支内部有多个步骤时，编号必须重置并从属于分支，例如「超期分支第 1 步、第 2 步」，而不是接着主流程编成「第 7 步、第 8 步」。后者会让读者以为超期用户要走完前面六步，实际上他们应该直接跳到分支。

同时要在分支开头明确写一句「若你属于此类，请跳过上述步骤，从本节第 1 步开始」。这句话看起来啰嗦，但它是防止误读的最有效手段，也是引擎判断路径切换的锚点。

7.3 异常与失败的三种写法

异常处理和失败分支不是一回事，写作时要分开。异常是「本不该发生但发生了」，失败是「这一步没通过」。两者对应的用户动作完全不同。

• 可自愈异常：给一个明确的重试动作和重试次数上限，例如「刷新后重试，最多两次」。写清上限是为了避免用户无限重试。
• 需人工异常：给渠道、凭证、时限三件套。渠道要具体到入口名称，凭证要具体到字段，时限要给出承诺的响应时间。
• 不可恢复失败：明确告知此路不通，并给出替代路径。最忌讳的是含糊其辞，让用户反复尝试。直接说「此订单已超过可开票期限且已红冲，无法重开，请申请新的订单发票」比十句安慰有用。

八、与图文视频素材的配合

纯文字能覆盖流程的逻辑，但覆盖不了界面的样子。用户在「找不到按钮」这类问题上，需要的是视觉定位。图文与视频不是装饰，它们是步骤内容的一部分，只是以另一种媒介承载。

8.1 视频章节标记：让视频也能被按步摘取

视频本身对引擎是不透明的，但章节标记可以把它变成可索引的结构。做法是给视频配上带时间戳的章节列表，每个章节对应一个步骤，章节标题与文字步骤的标题完全一致。

这里的关键是标题一致性。如果文字写「提交申请」，视频章节写「上传资料并确认」，引擎无法判断两者是同一件事，也就无法把视频段落和文字步骤关联起来。统一命名看起来是小事，实际上是跨模态对齐的基础。

章节粒度也要匹配。文字有六步，视频就切六个章节，不要切成三个，也不要把一步拆成三个章节。粒度不一致会让用户在两套材料之间来回找，体验反而更差。

8.2 图文与步骤的一一对应

配图的原则是「一图一步，图随步走」。每一步配一张能说明该步关键界面的截图，截图上标注需要点击的位置。不要用一张全屏大图配六步说明，因为用户无法从一张图里定位六个动作。

图片的替代文本要写成动作描述而不是文件名。「点击发票管理进入列表页」是好的替代文本，「截图 2026」不是。替代文本既是无障碍要求，也是引擎理解图片内容的唯一通道。

对于界面会随版本变化的场景，建议在步骤里写明界面版本或时间，例如「以下界面适用于 2026 年 9 月版」。这样即使截图过期，用户也能判断差异来源，而不是认为自己走错了流程。

8.3 素材缺失时的降级写法

不是每个流程都能配齐素材。缺图时不要留空，用文字做视觉定位：「在页面右上角、头像左侧，有一个蓝色按钮，文字为申请开票」。位置、颜色、文字三个要素组合，足以让用户找到目标。

缺视频时，用带时间感的文字替代：「整个操作约 3 分钟，其中填写信息占 2 分钟」。这类时间描述能让用户建立预期，效果接近视频的进度条。

九、八项自检清单

内容发布前，用这套清单过一遍。八项全部通过，基本可以保证这段流程被完整、按序、无遗漏地摘取。任何一项不通过，都建议先修再发。

9.1 清单本体

• 一、是否有独立的前置条件段：身份、物料、环境、状态四类信息是否齐全，且没有被编成步骤。
• 二、步骤是否一步一事：每步是否只有一个主动作，能否用一句完成标志收尾，是否存在一步包办三件事的情况。
• 三、每一步是否都有验收标准：是否写出了观察点与期望值，成功与失败的信号是否可区分。
• 四、顺序信号是否双重保险：是否同时具备结构顺序（ol 或文字编号）与语义顺序（状态衔接、依赖词）。
• 五、条件是否与步骤分离：所有「如果」「仅当」「超过」是否都放在独立段落或明确的分支标题下，没有混在步骤序列中。
• 六、耗时与成本是否分层给出：单步、环节、全流程三个层级的时长是否都有，费用与隐性成本是否说明。
• 七、失败分支是否可执行：是否做到能定位、能自救、能升级，凭证是否具体到字段。
• 八、完成后状态是否可验证：是否说明了拥有什么、系统里发生了什么、接下来会发生什么。

9.2 判定口径与常见误判

清单容易写，判定容易松。以下三种情况最常被误判为通过。

第一种是「有编号就算有序」。编号只是形式，如果编号之间没有状态衔接，顺序仍然是脆的。判定时要问：把第 3 步单独抽出来，读者能不能知道它前面应该发生什么。

第二种是「有客服入口就算有失败分支」。客服入口只解决了升级，没解决定位和自救。判定时要问：用户在看到这个分支时，能不能先自己试一次。

第三种是「写了大概时间就算有时效」。大概、通常、一般这类词在答案里几乎没有价值。判定时要问：用户能不能用这个数字判断自己当前是否异常。

9.3 使用建议

这套清单适合两类场景。一是新内容发布前的强制检查，尤其是帮助中心、售后指引、开户流程这类高流量页面。二是存量内容的分批改造，可以先按访问量排序，优先改造前十页，再逐步铺开。

不建议一次改造全站。步骤类内容的改造工作量集中在信息核对上——你必须真的去走一遍流程，才能写出准确的验收标准和耗时。这个成本降不下来，所以节奏要按人力来定，不要按页面上线时间倒推。

十、发布后的观察与迭代

结构改完不等于结束。步骤类内容的特殊性在于，它会随着产品版本、政策口径、界面改版而失效，而失效往往是静默的——页面还在，内容已经错了。

10.1 观察三类信号

第一类是答案形态信号：在生成式引擎里提问，看返回的答案是否覆盖了全部步骤、顺序是否正确、条件是否被误读。这类检查建议按固定问法做，每次用同样的五到八个问题，便于对比。

第二类是用户行为信号：页面停留、步骤区域的点击热区、客服工单里反复出现的卡点。如果某个步骤对应的工单量突然上升，通常意味着该步骤的说明与实际界面脱节了。

第三类是内容一致性信号：同一流程在不同页面、不同渠道的表述是否一致。不一致会稀释可信度，也会让引擎在多源比对时犹豫。

10.2 什么时候必须重写

有三种情况不建议修补，直接重写更快。一是流程的步骤数变化超过三分之一，结构已经变形；二是入口路径变了，所有截图和位置描述同时失效；三是政策口径变化导致条件分支重排，原有编号体系不再适用。

除此之外的小改动，就地修补即可。修补时记得同步更新耗时数字和验收标准，这两个字段最容易在改版后被遗忘，也最容易造成用户误判。

十一、常见问题

操作步骤类内容一定要写成编号列表吗

不一定，但编号是最低成本的顺序信号。如果流程只有两步且因果关系极强，用连贯段落也能表达清楚。一旦超过三步，或者中间存在等待、审核、条件判断，就必须用编号或有序列表把结构显性化。判断标准是：读者能否在任意位置中断后重新找到自己的位置。

只有三步的短流程也需要六要素吗

需要，但可以压缩。三步流程的前置条件通常一句话就够，耗时可以合并成一个总数，失败分支可以只保留最常见的一种。唯一不能省的是验收标准，因为它是用户判断成败的唯一依据。六要素是完整性框架，不是字数要求。

条件分支很多时会不会让内容变得很长

会，但长不等于差。分支多的流程，正确的做法是把主干写短、把分支写成独立小节，让不需要分支的用户快速通过。真正伤害体验的是把所有分支都塞进主干，导致每个人都要读完所有情况。分层组织和篇幅长短是两件事。

步骤里的截图多久更新一次

跟随界面改版节奏，而不是按固定周期。更实际的做法是在步骤文字里写清界面版本或时间标识，这样即使截图滞后，用户也能自行判断差异。同时建立一条反馈通道，让用户能一键报告截图过期，这比定期巡检更有效。

视频章节标记需要多细

与文字步骤一一对应即可，不要更细也不要更粗。文字六步就切六个章节，标题与文字完全一致。过细会让章节失去概括力，过粗则无法定位。如果某一步操作时间很短（十秒以内），可以并入相邻章节，但要在章节标题里体现这一步的存在。

如何判断步骤是否被完整摘取

用固定问法做对比测试。准备一组问法，覆盖全流程、单步、时效、条件四类，定期在主流生成式引擎里提问，记录返回的步骤数与顺序。如果答案长期缺尾部步骤，说明后段内容的独立信息量不足；如果顺序错乱，说明结构信号不够强。这是最直接的验证手段。

改造成本高，怎么排优先级

按三个维度排序：流量、转化关联度、错误代价。流量高且直接关联成交的流程优先改，例如开户、下单、开票；错误代价高的流程次优先，例如退款、报修、安全设置。纯说明性的流程可以最后做。不要按页面新旧排序，那和收益无关。

结构改好了但答案仍然不完整怎么办

先排查三个常见原因。一是内容分散在多个页面，引擎只抓到了其中一页，需要在主页面做完整的流程闭环；二是关键信息藏在图片或折叠区里，抓不到；三是同一流程存在多个版本，引擎无法确定权威版本，干脆不用。这三点都属于内容治理问题，不是写作技巧能解决的。