如何用 Claude 把网络拓扑图和 BOM 变成一份部署手册

一句话结论：Claude 可以同时读取导出的网络拓扑图和设备 BOM，起草一份有先后顺序的部署手册——上架顺序、逐端口的布线对照表，以及一份 UAT 验收签字清单——用一个下午，而不是三个晚上。它产出的是一份供部署工程师去修正并承担责任的初稿。它看不见现场。

设计已经签署。采购单三周前就发出去了。四个托盘将在十一天后送到一个新的六十工位办公室，而负责开箱的两名现场工程师手上只有一份网络拓扑图的 PDF、一份四十三行的 Excel BOM，以及一个周一的开工日期。

他们没有的，是一份部署手册——按顺序列出：什么设备上架到哪个 U 位、哪根线接进哪个端口、哪台设备必须先配置好下一台才能测试，以及在任何人签署交接单之前，什么必须被证明是通的。

于是他们凭经验现场发挥，而且做得不错，大部分都很顺利。然后三楼的无线接入点起来时挂在了错误的 VLAN 上，因为交换机端口模板是在现场而不是事先定下来的；标签和图纸对不上；六周之后，没有人能从文档里说清哪个配线架端口喂的是会议室那块显示屏。

这个落差——设计已经完成，而施工却没有被排序——是一个"写文档"的问题，不是一个工程问题，而它恰恰是值得交给模型的那一部分。

为什么"图纸画完了"之后，施工班组还是只能靠猜

拓扑图陈述的是最终状态，部署手册陈述的是操作顺序。第二样并不会自动从第一样里长出来。系统集成商的部署项目经理之所以年复一年在进场前一晚手写手册，是因为这两者之间的转换枯燥，而不是因为它难。

图上画着一台带 WAN 口的防火墙。它不会告诉你：运营商电路的交付日期握在第三方手里，在它落地之前下游任何东西都无法被正经测试，因此班组需要一份明确的"如果延期，第一天干什么"的备用方案。

而对于最消耗现场时间的两样东西——标签规范和端口对照表——图纸只字未提。两者都是当天由拿着标签打印机的那个人临场发明的，而下一个到场的工程师将完全依赖它们。

代价在班组撤场之后才出现。竣工文档要靠某人手机里的照片来还原。UAT 变成了一句"我们测过了，是通的"。半年后的一次变更，要从一轮本不该必要的摸底排查开始。

Claude 能从一张图和一份设备清单里起草出什么

Claude 能读图像和文档，所以从 Visio、Lucidchart 或 draw.io 导出的 PDF 或 PNG 可以直接喂给它，旁边再附上从 Excel 复制成 CSV 的 BOM。它读的是图上标注了的东西。它不评判设计是否成立，也看不见那栋楼。

在这个边界之内，有两样输出确实值一个下午。

一份排好顺序的上架与布线核对清单

给它拓扑图、BOM，以及你自己的机柜排布规范，它会产出一份有序的安装清单：什么装在哪里、按什么顺序、依赖关系写明白——供电与接地先于任何上架动作，核心交换机先于接入层，防火墙先于任何需要联网激活授权的设备。

真正省时间的那部分是端口对照表。从一张标明了设备互联关系的图纸出发，它会起草出这样的清单："SW-CORE-01 端口 1/0/24 接 FW-01 端口 ge0/1，标签 A-24"——每条物理连接一行。这恰恰是没人愿意手敲的那份材料，也恰恰是能让班组在下午四点不必靠猜的那份材料。

要明确指令它：凡是图纸没有规定的地方——一条没有标注的链路、一台没写机柜位置的设备——一律标成"设计未指定"，而不是替你做决定。仅这一条指令，就构成了"一份手册"和"一份负债"之间的大部分差别。

一份与设计所声明功能一一对应的 UAT 测试与签字清单

同样的输入还能产出一份可执行的验收清单，而这正是多数新站点建设真正缺失的文档。如果设计写了上联冗余，清单里就该有一步：拔掉其中一条，确认切换成功。如果写了访客 Wi-Fi 与办公 VLAN 隔离，就该有一步：从访客 SSID 尝试访问一个办公资源，并且预期失败。

一套可落地的流程：从图纸和 BOM 到一份能带进现场的手册

1. 把图纸导出为 PDF，并检查它在实际阅读的尺寸下是否清晰。模型读图纸和工程师读图纸遇到的是同一个问题：如果端口标注是压在交叉线下面的四号字，就一定会被读错。用合理的比例导出；如果图纸有多个页签，分别导出成不同文件，并说明每一张是什么。

2. 上传前先清洗，每一次都要做。站点地址、客户的法定名称、公网 IP 段、电路编号，以及任何看起来像凭据的东西，先删掉。这里面大部分是一次查找替换，换成"站点 1"和"客户 A"。把它定成一条硬性规则，而不是一次判断——因为在赶工期的时候，最先失效的就是判断。

3. 给它你自己的规范，而不是让它给"最佳实践"。把你公司实际使用的机柜排布规则、设备命名标准、标签格式和手册模板贴进去。"写一份部署手册"产出的是泛泛之物；"用这些命名规则填充这个模板"产出的才是你的工程师认得、并且真的会带进现场的东西。

4. 先单独生成安装顺序。要求编号步骤，写明依赖关系，每一步注明责任人。让它把任何依赖第三方的步骤单独标出来——运营商交付、业主方竖井开放、楼宇电工——因为正是这些步骤会延期，它们需要出现在计划的最前面，而不是埋在第三十四步。

5. 端口对照表作为第二轮，单独生成。窄指令的多轮处理，好过一次要它把什么都办了。这一轮要求：每条物理连接一行，设备名称一字不差地沿用图纸上的，凡是图纸没有端口号的地方写"未指定"，绝不编一个看起来合理的出来。

6. UAT 清单作为第三轮生成，只依据设计中明确声明过的能力。每一行是一个测试、一个预期结果、一个签字位。同时要求它单独列出那些它无法转成测试的内容——这份清单通常很短，而且是给设计负责人的一组很有用的问题。

7. 在它离开你的桌面之前，你自己对着图纸读一遍。你在查两样东西：接错的连接，以及那些写得很笃定、但图上根本没有的连接。第二种更难发现，恰恰因为它读起来是对的。

8. 把每一处"未指定"变成一条编号问题，发给设计负责人。这是整件事里价值最高的产物。在进场之前得到解答的十二个具体问题，就是十二个不会由一个疲惫的工程师在周五傍晚六点、一手还拿着标签打印机的时候拍板的决定。

9. 把它打印出来带到现场，用笔在上面批注。批注过的那一份就是竣工记录。撤场前拍照留存，再让同一个模型把它转录回手册文档——这就是在没有任何人主动贡献一个晚上的前提下，拿到竣工文档的办法。

AI 起草的手册 vs 持证部署工程师的手册 vs 到现场再随机应变

• AI 起草的手册。几小时而不是几个晚上，在枯燥的部分——端口表、UAT 条目、标签清单——上面极其详尽，而且因为是从模板生成的，站点之间保持一致。它没有现场认知、不承担任何专业责任，而且除非你明确禁止，否则它会对一条图上从未出现过的连接写得很笃定。正确用法：作为部署工程师去修改并承担责任的初稿。
• 持证部署工程师的手册。一位在真实楼宇里装过设备的人判定了这个顺序能跑通，并且已经把那条已经塞满的竖井、那部只到四楼的电梯、以及只有周二在场的电工都算了进去。那份判断才是真正的交付物——这恰恰说明为什么"转录"那一半值得自动化，而"判断"那一半不值得。
• 到现场再随机应变。比这个行业愿意承认的更常见，而且通常也能成，因为优秀的现场工程师本来就擅长这个。它的代价当天看不见，之后却很贵：没有端口表、没有 UAT 记录、竣工文档靠回忆拼凑，而第二个站点和第一个站点没有任何共用的规范。

它在哪些地方不够用

它看不见现场，而部署恰恰是在现场翻车的。那条已经塞满的竖井、那间只有一个十三安插座的弱电间、那扇被线槽画着直穿过去的防火门——这些都不在图纸上，所以也都不在手册里。文档会看起来很完整，同时漏掉决定这一天成败的那个约束。

编造出来的"精确"是它的典型失效方式。当被要求产出一份看起来专业的手册时，模型会补上似是而非的细节：一个没人指定过的端口号、一个由它默默做出的假设推出来的 U 位。它读起来和正确的那些行一模一样，而这正是它在一个没人对照图纸复核的现场上的危险之处。

安全与电气合规不是文档问题。负载计算、接地、桥架、高空作业，以及任何涉及楼宇供电的事情，属于有资质的电工和当地法规，而不属于一份模型产出的清单。这些内容留在手册里的形式应当是"通知对应工种介入"的指令，绝不能写成让人照做的操作步骤。

它没有资格签署任何东西。一份 UAT 表之所以有价值，是因为一位具名的、有能力的人在他真正跑过的测试旁边签下了名字缩写。一份大家在漫长一天结束时统一打勾的生成清单，比没有清单更糟，因为它看起来像证据。

把这件事做对——设计文件的机密性、版本控制，以及什么时候该让 IT 介入

网络拓扑图是一份安全文件。它展示了拓扑、分段、管理 VLAN，经常还有地址规划，而且必然包含边界设备的厂商与型号。它对攻击者来说是一份真正有用的材料，而它却经常作为附件被邮件发来发去、被上传到聊天工具，并留在三台笔记本的下载文件夹里。

搞清楚你上传的到底是哪个工具的哪一档。个人版、团队版和企业版在数据留存以及内容是否可能用于训练上是不同的，而且条款会变——请查阅你公司所用的那个具体套餐的当前官方文档，不要靠假设。然后在公司层面定一条规则：哪些工具可以接收客户的设计文件。在多数专业服务公司里，这是最大的一块失控的 AI 风险，而它是治理问题，不是技术问题。

版本控制在这里比平时更要紧。这套做法会产出看起来已经完成的早期文档。在合格的工程师签字之前，在文档顶部放一行可见的状态——"AI 辅助初稿，未经审阅"——并把手册放在一个受控位置，比如 SharePoint 或 Confluence，而不是作为附件在邮件里流转。班组带进现场的那一版，必须是任何人能找到的唯一一版。

决定 AI 在交付流程里该占哪个位置、写好那些模板、并定下"什么可以上传"这条规则，是 AI+ 支持的工作；底下的访问控制、设备管理和数据处理，则是常规的管理型 IT 支持。而真正不能自动化的那部分，是 IT 基础设施部署本身——那些做上架、布线、勘测和调试的持证现场工程师，让设备到场时就已配置好的场外预配置，以及在 UAT 表上签字的那个人。如果你要记录的是搬迁而不是新建，我们关于用 AI 起草办公室搬迁手册的文章覆盖了这个问题的"迁移版"，而把摸底沟通变成 HLD 和 BOM覆盖的正是这份手册所承接的设计阶段。

常见问题

这能取代持证现场工程师吗？

不能。客户在一次部署里买到的，是一位有资质的人判定了这个顺序在那栋楼里能跑通，并在交接时为结果背书。模型无法承担这份责任。它取代的是手敲端口表和 UAT 表的那两三个晚上——是设计与施工之间的转录工作，不是施工本身。

现场和图纸对不上怎么办？

现场几乎总有对不上的地方，而这恰恰是手册要打印出来带到现场的原因。工程师标注偏差、写明原因，那份批注过的副本就成了竣工记录。一份在现场不允许被推翻的手册，就是用错了；它的职责是让偏差显形，而不是假装偏差不会发生。

输入的图纸需要详细到什么程度？

详细到在设备和连接关系上没有歧义即可。有端口级标注当然最好，但不是必需——一张没有端口号的逻辑图仍然能产出有用的安装顺序和 UAT 清单，只是会产出一份更长的"未指定"清单，而那本身也是有用的。唯一会真正拖垮输出质量的输入，是标注读不清的低分辨率导出图。

它事后也能生成竣工文档吗？

能，而且这是这套流程里被低估的另一半。把批注过的手册拍照，连同原始版本一起喂回去，要求它产出一份"计划 vs 实际"的对照文档，逐条列出所有偏差。那是转录工作，正是它擅长的。让实际施工的那位工程师复核——转录是机械的，但判断某个偏差要不要紧不是。

实际操作下来要花多久？

对本文这种规模的单站点办公室建设，大约一个下午，而同样的文档手写要两三个晚上——第一次会更慢，因为你要边做边把模板写出来。更大的收益在于：端口表和 UAT 清单终于存在了，而在这类站点上，老实说它们通常并不存在。