需要时再介绍可用能力

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

你正在编辑一篇流程说明，读到“账号批准→远端登录”和“本地配置→本地构建”两条独立路径。一个小图可以帮助读者区分依赖与并行；这比未读草稿就列出所有可视化工具更有针对性。

具体做法

先做当前任务的必要工作，看到具体表达困难时再提出可选能力，说明对应章节和读者收益。这里建议一个依赖图，但不把它作为纯文本修订的前置；未回答时继续独立文字工作，确认需要后再按范围加入。必须的权限或可访问性要求不包装成可选附加功能。

反例

未读草稿先让用户选全部可视化、动效和导出功能。选择没回答就停止任何编辑。

改进写法

先修订上述流程段落。这里两条路径容易被误读为一个固定顺序，可提供一个小依赖图，说明它能显示账号审批与本地构建的独立性。把它作为可选增强，未选择时继续纯文本工作，不反复推销；已有明确要求时直接遵循，也不把必需授权降为可选。

为什么这样改

任务中观察到的难点使能力提议有具体用途，用户能判断它是否值得加入。保持可选与必需分离，既减少工具介绍负担，也避免未回答的偏好阻断已明确工作。

如何验证

示意提议指向依赖段落并说明“区分两条独立路径”，而非泛泛问要不要更丰富。未回答时文字修订仍完成；明确不要图则保留文本方案。

检查没有新增不相关动画或导出，也没有把必要访问决定靠默认选项略过。

适用边界

有些任务已明确需要可视化，可以直接执行，不必强行征询一次。可选能力是否可用仍需核验；原文未确认，提议不构成外部服务或付费调用授权。