Cisco 首席工程师：AI 让每个环节变快，瓶颈却不断转移到下一个环节

Cisco 的文档发布平台 PubHub 需要一次安全驱动的强制重写。DevNet 平台工程团队的首席工程师 Neelesh Pateriya 在 2026 年 10 月发表了一篇记录：他们并没有先找到一份 AI-first 开发流程手册再动手，而是试错迭代出来的。他总结出一条贯穿全程的模式——每加速一个环节，瓶颈就转移到下一个环节。

起点不是写代码，而是理解旧系统。PubHub 在超过 15 个仓库里生长了多年，用 Python、Node.js、Go 和 React 写成，当初写这些代码的工程师大多已经离开。边界情况藏在代码里，不在任何文档中。团队先让 AI 读完遗留仓库，为每个服务生成架构、工作流和模块文档，再由领域专家审核。Pateriya 把这称为：重写中 AI 的第一个胜利是理解，而不是代码。

有了旧系统的文档，团队开始写需求。AI 起草的第一版看起来不错，但越写越长——一个用户故事能跑到几十页，从业务需求滑向组件设计、数据流甚至 schema 的 JSON 结构。团队定了一个简单形状：需求只说三件事——业务需要是什么、给谁用、怎么算完成。设计归设计文档。Pateriya 的体会是：AI 让长文档变得廉价，稀缺的是所有人就什么重要达成一致。

工程需要界面时，UX 团队还在摸索 AI。他们反了常规顺序：先让 AI 从需求直接生成一个可用的试点界面，UX 团队再以此为基线展开设计。早期 AI 生成的界面看着对，但不符合 Cisco 的设计标准。于是 UX 团队把设计标准编码成 AI 技能和 MCP 服务器，之后生成的界面从第一天起就合规，不再需要返工。

代码生成工具在项目期间升级了。起初是 VS Code 和 Cursor 里的代码补全，有帮助但不够可靠。Claude Code 可用后，工程师开始把整个功能——包括测试——交给代理从需求直接生成。Pateriya 说，考虑到代码库规模（新的 Go Core、新的 Go Site Engine、新的管理界面），把整个功能交出去而不是打字更快，才是时间节省最大的地方。

然而审查没有变：每个变更仍然需要人工审核。代码来得比人审得快，瓶颈落到了审查环节。团队把 AI 也放到审查者这边：为 Go、Python 和 React 建了审查技能，外加两个审查代理——一个在工程师开 PR 前本地跑，一个在 PR 上跑。它们找问题并解释问题，但审查者仍然拥有决定权和批准权。

测试是最让人睡不着的部分。PubHub 发布数百个文档项目，由数千名技术作者、API 架构师、工程师和技术营销工程师维护。如果新平台构建或渲染内容哪怕有一点不同，就会有人从公开页面上发现。团队用 AI 搭了两层安全网：一个对比框架，把重写生成的数万页与生产版本逐页比对；以及驱动无头浏览器的 AI 代理，把复杂 UI 工作流跑一遍，大幅削减了手工测试量。上线后的结果是：没有报告过严重或高危问题。

Pateriya 把这套做法总结成七条实践：先文档化遗留代码；需求保持简短；先建可用试点再设计；把整个功能交给 AI；安全标准不可妥协；给审查者配 AI；用机器规模测试。他特别强调最后一条：预期瓶颈会移动，移动了就重新规划。

到上线时，团队建了或采用了二十多项技能和两个审查代理。但 Pateriya 指出，现在几乎每个环节都比以前快了，瓶颈落在了环节之间——跨超过 15 个仓库、多年历史的上下文中，把需求连到设计、代码、审查和测试的那条线仍然活在人脑子里。他们下一步要做一个 PubHub 开发者代理，像老团队成员一样了解项目的架构、历史、规则和未关闭问题，把工单推到 PR，但规则不变：人批准每一个变更。