导读一张故障排查流程图，真正难的不是把英文翻成中文，而是保留节点、分支和箭头关系。我在豆包工作中选择 Seed-2.1-pro-0915，把 Azure Sphere 远程故障排查图交给它处理：先识别流程，再生成一个可直接打开的 HTML 工具，最后通过桌面端和移动端截图检查布局。结果是 16 个节点、15 条连接都被整理出来，页面中的每个节点还可以点击查看作用、条件、下一步和原图英文。
本文 2240 字，阅读约 6 分钟｜先说结果：它交付了一个能打开的工具 → 我先给 Seed-2.1-pro-0915 一个具体任务 → 它先做的不是写页面，而是还原流程 → 然后，它把节点变成了一个能点的页面 → 一次完成：页面可以直接打开 → 这次工具真正解决了什么 → 我的判断：适合把静态资料先变成可用入口
先说结果：它交付了一个能打开的工具
这次最终留下的是一个单文件 index.html：流程图包含 16 个节点、15 条连接和 4 个“是/否”分支标注。点击任意节点，页面会显示节点作用、判断条件、下一步动作和原图英文；桌面端和移动端都做过截图检查，底部还保留了原图对照区和“待确认”清单。
我实际点击过节点，详情面板、节点高亮和出向连线高亮都能正常更新。它不是一张重新绘制的静态图，而是一个可以直接打开、继续查看和继续修改的 HTML 工具。
我先给 Seed-2.1-pro-0915 一个具体任务
很多流程图的问题，不是内容少，而是信息被压在一张静态图片里。读者要先放大图片，再沿着箭头找分支，还要记住每个英文节点到底对应什么动作。遇到故障时，这种阅读方式很容易把“判断条件”和“处理动作”混在一起。
这次我选的是一张 Azure Sphere 远程故障排查流程图。它从“有多少设备出现问题？”开始，先分成“少数设备”和“所有设备”两条路径；后面又分别进入连通性检查、系统更新、应用更新和错误关键词判断。
这个任务正好覆盖多模态 Coding/Agent 的交叉区域：模型既要理解一张视觉流程图，又要把理解结果转成代码和可交付页面，还要保持节点关系不丢。验收标准不只是“翻译得对不对”，而是要看它能不能从输入一路走到最终工具。
图片说明：原图包含 16 个流程节点，以及少数设备、所有设备和多个“是/否”分支。图片来源：Microsoft Learn，Azure Sphere 远程故障排查。
我没有让 Seed-2.1-pro-0915 只做翻译，而是给了一个更具体的任务：读取这张图，把它整理成中文交互式排障工具。每个节点都要能点击，点击后显示节点名称、作用、判断条件、下一步动作和原图英文内容；原图中无法确认的部分，要明确标成“待确认”。任务在豆包工作中执行，界面显示为“豆包 2.1 Pro”，实际使用版本为 Seed-2.1-pro-0915。
我给这次任务设了四个验收条件：流程节点和分支关系不能被改写；页面必须能直接打开并完成节点交互；页面需要留下原图英文、判断条件和下一步动作，方便对照；桌面端和移动端都要经过截图检查，发现截断、遮挡或文字溢出就继续修改。
它先做的不是写页面，而是还原流程
Seed-2.1-pro-0915 在豆包工作中先使用 Glob 定位图片，再用 Read 读取图片中的文字和版面。图片里的文字能被识别出来，但 OCR 不会自动告诉它每根箭头连到哪里，所以它又把图片裁成五个区域放大检查：顶部起始节点、左侧中部、右侧中部，以及两个下方区域。
这一步很关键。流程图里的“少数设备”和“所有设备”只是两个入口，真正决定工具能不能用的是它们后面的连接关系：
“少数设备”进入连通性流程，再获取 2—3 个设备 ID，执行 azsphere tenant download-error-report，之后检查 Description 字段；
Description 中出现 AppCrash、AppUpdate 或 AppExit 时，转向检查客户应用日志；
出现 SystemAppCrash、Kernel Panic 或 Kernel Oops 时，转向联系 Microsoft 支持；
“所有设备”路径分别检查近期是否进行过系统更新和应用更新，再按“是/否”进入后续动作。
对于原图中没有展开的“Check Connectivity Flowchart”，页面保留了原始名称；对于两个更新判断的关系和部分箭头方向，页面都设置了“待确认”说明，让读者可以沿着原图继续核对。
这比单纯输出一段中文摘要更有价值：读者拿到的是一张结构化流程，而不是一串翻译后的节点名称。
然后，它把节点变成了一个能点的页面
流程关系确认后，Seed-2.1-pro-0915 在项目文件夹中生成了单文件 index.html。页面没有使用外部依赖，CSS 和 JavaScript 都内置在文件里，原始图片作为同目录资源保留。
图片说明：项目文件夹中同时保留了原始流程图、生成的 index.html、项目过程记录和页面检查截图，HTML 工具可以直接打开。
页面中的节点由数据驱动渲染，判断节点使用菱形，处理步骤使用浅色圆角框，终点动作使用深色框，分支入口用另一种颜色区分。点击节点后，下方详情面板会同步更新，显示节点类型、节点作用、判断条件、下一步动作和对应的英文原文；选中的节点和出向连线还会高亮。
图片说明：Seed-2.1-pro-0915 在豆包工作中完成项目记录整理，右下角可见“豆包 2.1 Pro”模型入口，右侧保留了项目记录和 HTML 工具产物。
最终页面包含 16 个节点、15 条连接、6 个判断节点和 4 个“是/否”分支标注。底部还保留了原图查看区、识别说明和待确认项清单。这样做的好处是，读者不需要在原图和文字说明之间来回切换，点击一个节点就能看到它在整个流程中的位置。
一次完成：页面可以直接打开
我的实测总结是：类似任务在旧模型上需要多次补充要求和调整结果；这次使用 Seed-2.1-pro-0915，一次就完成了任务，整体完成效率相比之前有大幅提升。最终交付结果是：流程图画布完整显示，分支线和“是/否”标签清晰可见，底部两个关键词判断节点的英文内容也没有重叠。桌面端和移动端截图均已完成，页面可以通过 file:// 直接打开。
图片说明：最终页面在桌面端完整显示流程图，底部两个关键词判断节点的文字已经分开。
这也是我认为 Seed-2.1-pro-0915 在这个任务里比较有价值的地方：它不只产出一个看起来像页面的结果，还把流程结构、节点详情和原图对照一起组织成了可交付工具。最终检查包括控制台错误、资源加载、横向溢出、HTML 标签闭合和移动端显示。
这次工具真正解决了什么
它解决的不是 Azure Sphere 故障本身，而是“如何把一张静态流程图变成更容易使用的排障入口”。原图负责提供流程事实，Seed-2.1-pro-0915 负责识别、整理、生成页面和检查页面，豆包工作提供任务执行环境，最终留下了一个可以双击打开的 index.html。
这条链路里，Seed-2.1-pro-0915 的价值不是一句“支持图片理解”就结束了，而是落实在几个具体动作上：读取图片、核对箭头、建立节点数据、生成交互页面和完成页面检查。少了这些动作，最后就不会有可点击的工具产物。
图片说明：移动端采用纵向页面布局，流程图区域可以左右拖动查看右侧分支。
页面还保留了原图对照区和“待确认”清单：连通性子流程、更新判断关系等内容都能回到原图继续核对。这让工具既方便使用，也保留了工程场景需要的严谨性。
我的判断：适合把静态资料先变成可用入口
如果任务只是把图片里的英文翻译成中文，普通 OCR 就够了。Seed-2.1-pro-0915 的价值，出现在任务还包含结构整理、交互页面生成和页面验收的时候。
这次案例给我的实际分工是：先让它处理图片中的节点和关系，再让它生成一个可操作的页面，同时保留原文、原图和待确认信息。最终页面支持节点点击、详情查看和移动端浏览，读者可以直接从工具中继续了解整个流程。
所以在这个 Case 里，我会把 Seed-2.1-pro-0915 放在“资料到工具”的第一轮：把难读的静态流程整理成一个能打开、能点击、能继续使用的版本。它减少了从图片到初版工具之间的整理成本，也让复杂资料更快变成可以交付和分享的页面。
参考资料
Microsoft Learn：Azure Sphere 远程故障排查：https://learn.microsoft.com/en-us/azure-sphere/app-notes/remote-troubleshooting
本案例项目产物：Azure Sphere 故障排查工具/index.html
— THE END —
文章仅做学术分享，如有侵权请联系删除，非常感谢！