思科给工程师无限AI Token，欲重写98%代码

思科的大胆实验：无限AI Token换代码重写

据Hacker News讨论，思科（Cisco）正在推进一项颇具争议的内部实验：给一位工程师提供无限量的AI Token，目标是用AI重写公司98%的代码。这个数字如果属实，几乎意味着对现有代码库的彻底翻新，而不只是局部优化。

消息在技术社区引发关注，但讨论量并不高（12分、6条评论），说明外界对细节仍缺乏了解。不过，“无限Token”与“98%代码”这两个关键词的组合，已经足够让开发者重新审视AI在大型企业软件工程中的角色。

为什么“无限Token”值得关注

在AI辅助编程的日常实践中，成本始终是绕不开的约束。团队通常会限制上下文长度、控制调用次数，或在复杂重构任务前反复权衡投入产出比。思科给单个工程师开放无限Token，等于把成本约束从工程决策中暂时移除，让“能不能做”取代“值不值得做”成为首要问题。

这种做法在大型企业中并不常见。它更像是一次压力测试：当Token不再稀缺，AI能在多大程度上接管代码理解、迁移与重写工作？答案不仅关乎工具能力，也关乎企业愿意为AI实验承担多大的账单不确定性。

Token是大型语言模型处理文本的基本单位，一个Token大约对应英文的0.75个单词或中文的半个到一个汉字。在AI编程工具中，每次对话、每段代码的生成与理解都会消耗Token，而服务商通常按Token数量计费。因此“无限Token”并非字面意义上的免费，而是企业承诺承担不设上限的调用成本。对于代码重写这类任务，模型往往需要反复读取大段上下文、多次生成与修正，Token消耗可能达到普通辅助编码的数十倍甚至上百倍，这正是“无限”在企业场景中格外罕见的原因。

98%代码重写意味着什么

“重写98%的代码”是一个极具冲击力的表述。在成熟企业里，代码库往往包含大量历史遗留逻辑、隐式依赖和文档缺失的模块。用AI大规模重写，理论上可以统一风格、消除技术债、提升可维护性，但风险同样明显：语义漂移、边界条件遗漏、测试覆盖不足都可能被放大。

从工程角度看，重写比例越高，对自动化测试和代码审查的依赖就越重。AI生成的代码需要通过既有测试套件验证，而测试本身是否完备，决定了这场实验的成败。思科是否配套了相应的验证机制，目前公开信息并未说明。

语义漂移是指代码在重写后行为发生微妙改变：语法正确、编译通过，但在特定输入或边界条件下与原逻辑不一致。大型代码库中大量逻辑并未被文档或测试显式覆盖，AI只能依据上下文推断意图，推断偏差就会累积成隐蔽缺陷。与之相关的是回归测试——一套在修改代码后自动运行、用于确认原有功能未被破坏的测试集合。重写比例越高，回归测试的覆盖率和断言质量就越关键，因为它是判断“重写是否等价”的唯一客观依据。测试薄弱时，语义漂移往往要等到生产环境才暴露。

对AI编程工具市场的信号

如果思科的做法被验证可行，它会向企业市场释放一个明确信号：AI编程工具的采购逻辑可能从“按席位订阅”转向“按任务放开用量”。这对提供AI编程服务的厂商意味着新的定价想象空间，也意味着企业需要更精细地评估AI产出的质量与责任归属。

反过来，如果实验暴露出明显的质量或维护问题，企业客户对“AI重写核心系统”的态度会更谨慎。无论结果如何，思科这一案例都会成为讨论AI在关键软件资产中应用边界时被反复引用的样本。

按席位订阅是目前AI编程工具的主流商业模式，企业为每位开发者按月付费，用量通常设有上限或分级。按任务放开用量则意味着计费锚点从“人头”转向“工作负载”，企业需要预估重写、迁移等重任务的Token预算，并对产出质量建立验收标准。这一转变对厂商的挑战在于收入可预测性下降，对企业的挑战则在于责任归属：AI生成的代码若引发故障，责任在工具提供方、使用工程师还是采购决策者，目前尚无成熟约定，合同与审计机制需要同步演进。

尚待观察的问题

目前公开的信息仅限于标题层面，缺少关于项目范围、时间线、验证方式和实际产出的细节。技术社区的讨论也刚刚开始，尚未形成共识。对于关注AI编程落地的团队来说，更值得追踪的是后续披露：重写后的代码是否通过了完整回归测试，维护成本是否真的下降，以及这位工程师的工作模式能否被复制到其他团队。

在缺乏更多数据前，把思科的做法视为一次高调实验而非成熟范式，是更稳妥的判断。