思科要用无限 Token 在两年内重写 98% 遗留代码

这项实验的四个关键数字是 24 个月、98%、两个人和近乎无限的 Token。27 岁的 Padmanabhan Krishnamurthy（昵称 Paddy）曾于 2023 年联合创办实时翻译初创公司 EzDubs，思科在 2025 年完成收购后，他随之加入思科。他提出组建两人团队、借助 AI 重写思科遗留代码；思科总裁兼首席产品官 Jeetu Patel 给了他无上限 Token 预算。Paddy 已设定四周验证期，24 个月和 98% 则是更长期目标。

98% 目前是目标，不是已经完成的改造比例。当前代码修改体量、试验成效、系统范围、技术方案与测试结果均未披露。 现阶段能够确认的是授权和目标，不能据此认定 98% 的代码已经重写。

无限 Token 增加的是调用与迭代额度，不会自动带来可上线的软件。无上限预算能放宽配额约束，让工程师更快尝试不同生成方案、修复局部问题；但它不会补齐模糊需求、缺失测试、领域知识、复杂依赖或发布责任，调用额度也不能替代工程判断。

“98%”究竟按什么口径计算，是计划中最不明确的部分。遗留代码通常与已停止维护的系统或技术有关，也可能包含为兼容旧功能嵌入现代软件的代码，常伴随技术过时、文档不完整和维护成本高。 现有报道没有说明分母是代码行、文件、模块、业务系统还是业务关键度。“重写”也要先界定是等价迁移、架构替换还是现代化；脱离行为一致性、回归风险、测试覆盖和业务价值，只按生成或修改行数计算，很容易形成漂亮但失真的进度指标。

AI 生成相似代码后，需要经过一套可复用的验证流程：冻结范围，建立或补齐现有行为基线与依赖图；小批量生成并审查，执行单元、集成与回归测试以及安全扫描；人工确认后灰度上线，再通过监控和回滚控制风险。不同类型的旧代码也不能一刀切：可测试、低耦合模块适合试点；业务关键却缺少文档和测试的系统，应先补齐对系统的认知，而不是因为“旧”就盲目重写。这是本文提出的工程路径，并非思科已经公开的方案。

两个人可以组成核心开发团队，但无法覆盖所有验证角色。两人团队目前仍只是 Paddy 的构想，组织配置尚未确认；领域专家、测试、安全和发布负责人仍需独立参与。若让生成者同时充当唯一裁判，AI 提速也可能让错误扩散得更快。

四周验证期最该看的是可复验证据，而不是 Token 消耗量。至少应选择有代表性的模块，展示重构前后的基线测试结果、回归结果、安全问题的排查结果、性能变化、部署与回滚能力。代码变更量可以作为辅助指标，却不该成为唯一成功标准；一次顺利生成或短演示，也不能替代持续验证。

现阶段，这更像一场高风险、高回报的工程实验，而不是已被证明的规模化路径。98% 仍是目标，代码范围、技术方法和测试结果仍未知。后续可观察的是四周验证结果；在证据出现前，既不能把尚未验证的目标说成工程成果，也不能因为目标激进就提前判定它失败。