Token 预算没有上限，就能两年重写 98% 遗留代码吗？
采集摘要称思科给一位工程师无上限 Token 预算，并设定 24 个月重构或重写 98% 遗留代码的目标。这是投入与目标的报道，完成比例还要结合统计范围、业务行为和上线结果判断。
怎么判断？
先把“重写多少”改成能验收的交付清单，再讨论扩大 AI 产出。两条同主题采集摘要称，思科总裁兼首席产品官 Jeetu Patel 指派一位 27 岁工程师负责遗留代码改造，提供无上限 Token 预算，并设定 24 个月完成 98% 重构或重写的目标。摘要没有提供已完成比例、上线质量或维护成本；不能把这个目标写成已经实现的生产成绩。
先约定 98% 究竟统计了什么
统计代码行、文件、模块或业务功能，得到的完成比例可能完全不同。建议先列出改造范围、外部调用方和暂时保留的部分，并记录每一项怎样才算完成。生成了新的实现、通过代码审查和真正切换到生产，也应在交付清单上分别留痕。
这两条摘要围绕同一事件，不能当作两次独立复现。标题中的 98% 和 24 个月都是报道里的目标口径，不能推出每个月应有多少交付，也不能用改写行数代替原有业务已经正常运行的证据。
先挑一条真实业务链比较新旧行为
可以先选择边界清楚、能够保留旧版的业务链，把输入、预期输出、失败反馈和外部依赖整理成一组固定检查。让旧实现和新实现分别运行，发现差异时先判断是修复旧问题、需求变化，还是无意中改变了行为，再决定是否接受。
切换前再看调用方是否仍能使用原来的约定，出现问题时能否回到旧版。涉及状态保存的部分还需要单独设计迁移与恢复检查，不能因为代码编译成功就直接覆盖原有记录。这是给自有项目的验收建议，不是对思科系统架构的描述。
预算放开以后，瓶颈还要用交付记录找
建议把模型生成、人工审查、等待测试和修复回归的时间分开记录。如果生成越来越快，等待审查的改动却越堆越多，下一步应缩小变更批次、补齐业务样本，而不只是继续增加同时生成的代码。是否推进，要看已验收的功能和未解决的问题。
只有目标和资源安排，还不足以证明这条路线已经节省人力或适合所有遗留项目。本文没有查阅原报道、运行思科代码或测量 Token 消耗；可以借鉴的是把大改造拆成可回退、能对照的交付，而非照搬报道中的比例和期限。
资料链接
以下为采集记录附带的资料链接；本文依据摘要做独立分析，未逐条核验原文，也不代表本站实测。