Cisco 重建 PubHub：AI-first SDLC 逐环节消除瓶颈（第二部分）

Cisco DevNet 的 PubHub 文档发布平台经历了一次强制性重写。第一部分曾介绍 AI 辅助开发让项目提前 3.5 个月交付；本文则从工程视角拆解软件开发生命周期各环节的具体做法。团队没有现成 playbook 可循，这些实践是在试错中逐步形成的。 重写启动前，PubHub 已横跨 15 个以上仓库，涉及 Python、Node.js、Go 和 React 服务，而多数原始作者已离开，边界情况只存在于代码里。团队曾尝试手工迁移，因成本过高放弃。于是 AI 的第一项任务不是写代码，而是通读遗留仓库，为每个服务补写此前缺失的架构、工作流和模块文档，再由领域专家审阅，成为产品、设计和工程的共享参考。 需求阶段，AI 起草的用户故事一度膨胀到数十页并混入设计细节。团队随后确立固定结构：业务需求、用户画像、验收标准，设计内容归入设计文档。UI 环节则反过来，先由 AI 依据需求做出可运行试点界面，作为 UX 团队基线；早期生成界面虽外观接近但不符合 Cisco 设计标准，UX 团队将标准转化为 AI 技能和一个 MCP server，使生成界面从第一天起即合规。 工程侧工具从 VS Code 中的 GitHub Copilot 与 Cursor 代码补全，演进到 Claude Code 按需求交付带测试的完整功能，这也是节省时间最多的转变。安全不可妥协，新服务遵循 Go 最佳实践并基于统一安全基础镜像。代码产出加快后审查成为瓶颈，团队为 Go、Python、React 构建审查技能，并设两个审查智能体：一个供工程师在提交 PR 前本地运行，一个审查 PR 本身，但审批决定仍由人做出。 测试被视为最令人担心的环节：PubHub 承载数千名技术作者撰写的数百个文档项目，任何渲染差异都会被公开页面暴露。团队用对比框架将重写后构建的数万页面与生产版本逐一比对，并用 AI 智能体驱动无头浏览器跑复杂 UI 工作流，大幅压缩人工测试量。上线后未出现严重或高危问题。到发布时，团队已构建或采用 20 多个技能和两个审查智能体，覆盖需求、UI/UX、代码审查、测试和 SDLC 指引，编码本身与运维尚无专用技能。 团队发现，每加速一个环节，瓶颈就移到下一个；如今瓶颈位于环节之间的空隙。项目记忆文件只在单个仓库内有效，跨 15 个以上仓库、连接需求、设计、代码、审查与测试的上下文仍留在人脑中。下一步是构建一个熟悉项目架构、历史、规则和未决问题的 PubHub 开发者智能体，从 issue 推进到 PR，并同样遵循人工审批每次变更的规则。