52wuya思科给年轻工程师不限量AI额度，计划两年重构98%旧代码
思科总裁兼首席产品官 Jeetu Patel 在 Fortune 的一次圆桌晚宴上透露，他把一项大规模代码重构任务交给了一位27岁的年轻工程师，并给予其不限量的 AI token 额度。据 Fortune 报道，这位工程师名叫 Padmanabhan Krishnamurthy（昵称 “Paddy”），于2025年随思科收购实时翻译初创公司 EzDubs 加入思科，曾是该公司联合创始人。Patel 称他此前“被埋在组织里做不太有战略性的工作”，后来被安排主导遗留代码重构，目标是24个月内重构思科98%的遗留代码，并给自己四周时间先证明可行性。
以下内容中，凡标注“据 Fortune 报道”或“来源称”的，为来源资料中的事实性表述；其余为编辑分析或建议，不代表思科官方立场。来源未说明具体代码规模、重构范围、技术栈、衡量标准、安全审查流程以及“不限量 token”的成本与配额管理方式。
背景：AI 编码工具进入遗留系统改造场景
遗留代码重构长期是工程组织中的高成本事项。它往往涉及大量历史模块、隐式依赖、缺失的测试和文档，以及只有少数资深工程师才熟悉的知识。传统做法通常依赖小规模专家团队、逐步替换和长期维护，节奏慢但风险可控。
据 Fortune 报道，思科的这一安排把两个变量同时放大：一是把任务交给年轻、缺乏大公司层级经验的工程师；二是用不限量 AI token 支持其完成重构。Patel 在报道中表示，他给这位工程师“unlimited tokens”，并说“go nuts”，即放手去做。报道还提到，Patel 认为即使是团队中最积极使用 AI 的人，也未必会这样设想。
这一案例的行业背景是，生成式 AI 编码助手正在从“补全单行代码”走向“理解代码库、生成重构方案、批量修改和测试生成”。但来源并未提供任何工具名称、模型选择、准确率、缺陷率或性能数据，因此不能据此推断某类工具已经具备大规模重构遗留系统的成熟能力。
核心变化：人才策略与 AI 资源分配同时调整
据 Fortune 报道，Patel 的人才观点是：年轻员工能提出资深员工不会想到的问题，组织需要“张力”来挑战现状。他提到自己把每位实习生当作“反向导师”，并在高校演讲中寻找“hungry”的学生。报道还提到一位名叫 Baya 的学生，通过每月邮件跟进获得实习机会，并重新设计了资深员工未能解决的“某样东西”。来源未说明该设计的具体内容和技术细节。
从编辑分析角度看，这一案例的核心变化不在于“27岁”或“不限量 token”本身，而在于组织把 AI 资源从按人头配额转向按任务目标分配。传统上，AI 编码工具的许可证和 token 预算通常按团队或席位统一管理，强调成本可控；而思科这一案例显示，至少在一个高优先级重构项目中，资源分配逻辑变成了“目标优先、额度放开”。
但需要谨慎的是，来源只描述了管理层的表态和项目目标，没有说明该工程师实际使用了多少 token、是否设置了成本上限、如何评审 AI 生成的代码，以及是否出现回滚或事故。因此，这一做法目前只能视为一个公开报道中的管理实验，不能视为已被验证的最佳实践。
影响：对开发、运维与工程治理的启示
对开发团队而言，这一案例提示 AI 编码工具的使用方式可能从“个人辅助”转向“项目级批量改造”。如果团队计划类似尝试，首先需要明确重构边界：哪些模块允许 AI 参与生成或修改，哪些模块必须人工主导。来源未说明思科如何划分边界，因此这部分需要各团队自行定义。
对运维团队而言，大规模代码重构会直接影响构建、部署、监控和回滚能力。AI 生成的重构代码即使通过单元测试，也可能改变日志格式、错误码、配置项或性能特征。建议在项目早期就把可观测性纳入验收标准，例如要求关键路径的日志字段、指标名称和告警阈值保持兼容，或明确变更清单。
对工程治理而言，最大的风险不是 token 成本，而是评审吞吐量与责任归属。如果 AI 生成大量重构提交，代码评审者是否具备足够上下文？谁对合并后的缺陷负责？来源未说明思科的评审流程，因此不能假设其已有成熟方案。编辑建议是：为 AI 辅助重构设立独立的变更类别，要求每个批次附带变更说明、影响范围、测试证据和回滚方案，并由至少一名熟悉该模块的工程师签字确认。
此外，来源提到思科以24个月重构98%遗留代码为目标。这个数字在报道中属于管理层目标，来源未说明统计口径，例如是按代码行数、模块数量还是服务数量计算。团队在设定类似目标时，应避免直接套用百分比，而应先定义可审计的度量方式。
建议：面向开发者与运维人员的行动清单
第一，先做小范围试点。选择依赖清晰、测试覆盖较好、影响面可控的模块，用四周左右验证 AI 辅助重构的质量与评审成本。来源中 Patel 也提到给自己四周时间证明可行性，但来源未说明试点结果。
第二，建立“AI 生成代码”的评审规范。要求提交者标注哪些部分由 AI 生成、哪些部分人工修改，并强制附带测试运行结果。对于安全敏感模块，应额外要求人工逐行审查，不应仅依赖自动化测试。
第三，把成本监控和额度管理分开。不限量 token 不等于不监控。建议按项目记录 token 消耗、生成代码量、评审意见数和缺陷数，用于后续判断投入产出比。来源未提供任何成本数据，因此团队应自行采集基线。
第四，为运维侧准备回滚与兼容性检查。重构批次应支持独立回滚，关键接口和配置项应做兼容性验证，避免一次性大面积合并。
第五，谨慎对待“年轻员工挑战现状”的管理叙事。编辑分析认为，让缺乏经验的工程师主导大规模重构，需要配套导师机制和清晰的升级路径，否则“张力”可能变成无人兜底的风险。来源中 Patel 也承认代际协作可能产生摩擦，但未说明具体的导师或评审安排。
总体来看，思科这一案例的价值不在于提供一个可直接复制的模板，而在于把 AI 资源分配、人才结构和遗留系统改造放在同一个管理决策中讨论。对于开发与运维团队，更稳妥的路径是把 AI 视为加速器而非责任主体：目标可以激进，但评审、测试、回滚和责任归属必须同步到位。
资料来源
本文由自动化系统筛选公开技术信息，并经 AI 辅助整理。
本文转载自 fortune.com，版权归原作者所有。
抓取时间：2026年11月2日
本文采用 original 索引策略。