超越 Tokenmaxxing：为工程团队构建连贯的 AI 政策

人工智能与软件工程的融合已经超越了“新奇”阶段，进入了系统性动荡的时期。然而，随着 AI 工具的普及，许多组织陷入了经典的管理陷阱：试图通过容易被操纵且与价值交付根本脱节的代理指标来衡量生产力。

其中一种趋势是 “tokenmaxxing”——通过基于令牌使用量创建排行榜来鼓励 AI 采纳的做法。这种做法是 “秒表经理” 的现代变体，焦点从结果质量转向活动数量。正如任何有经验的工程师所知，当一个指标成为目标时，它就不再是好指标。Tokenmaxxing 并不推动创新；它促使工程师创建浪费令牌的循环，以攀登排行榜。

为避免这些陷阱，领导层必须超越虚荣指标，制定连贯的 AI 政策。可持续的政策并非关于强制或限制，而是关于定义所有权、学习和职业责任的理念。

以人为本的 AI 政策支柱

对于管理长期代码库的团队——尤其是那些拥有十年或更久技术债务和不断演进的架构模式的团队——采用 “快速行动、破坏一切” 的 AI 方法是危险的。相反，连贯的政策应建立在若干关键支柱之上：

1. 无强制，仅提升认知

当前 AI 热潮周期中存在根本矛盾：一方面声称必须立即采用 AI 否则被淘汰，另一方面又声称今天所掌握的一切将在六个月后过时。如果后者成立，最理性的做法是保持对工具的认知，而不对其不成熟的版本产生过度依赖。

信任聪明的工程师自行选择工具——无论他们是将 AI 作为工作流的核心部分，还是仅用于偶尔的概念验证——比强制采用更具生产力。目标是为客户交付价值，而不是使用特定工具。

2. 绝对代码所有权

AI 生成的代码并非 “AI 代码”；它是工程师的代码。对每一行 Pull Request（PR）的理解、维护和论证的责任仍然归属于提交的人工。

在已有的代码库中，出现 “AI slop” 的风险很高——即看似正确却忽视深层架构细节或引入细微 bug 的代码。押注模型改进速度快于技术债务累积的赌注是绿地初创公司可以承担的，但成熟公司则不能。当机器更易生成的代码与人类更易维护的代码之间存在选择时，人类必须始终获胜。

3. 保护学习曲线

也许 AI 采纳最关键的风险是对初级工程师成长的 “短路”。软件工程的学习通过挣扎实现——即与概念搏斗、犯错并手动实现解决方案的过程。

通过外包 AI 擅长的 “繁重工作”，初级开发者可能失去构建系统深层心智模型所需的关键 “练习”。连贯的政策应鼓励初级工程师审慎使用 AI，确保即使工具消失，他们仍能贡献并进行批判性思考。

反驳观点：AI 作为能力倍增器

虽然强调所有权和手动技能至关重要，但一些从业者认为 “无需 AI 的工作能力” 正在逐渐成为不必要的要求。一种观点认为 AI 使工程师能够使用他们未正式掌握的语言或框架，将瓶颈从语法转移到架构和需求收集上。

“我一直在使用这些东西，但我并没有学会 Go；我太忙于专注 AI 无法为我完成的部分，比如真实的需求收集、架构、细节打磨……如果把工具拿走，我就再也做不了这部分工作，抱歉。”

这凸显了行业中的一种张力：目标是培养能够理解底层机制的多语言工程师，还是培养能够利用 AI 在任何技术栈上交付结果的 “系统编排者”？答案可能取决于团队的风险容忍度以及产品的性质。

结论：关注人，而非令牌

归根结底，AI 政策是团队价值观的映射。无论团队是绿地初创公司还是拥有十年代码库的受监管企业，政策都应把代码库的长期健康和编写代码的人的职业成长放在首位。

领导层的职责不是统计令牌或监控使用日志，而是提供一个清晰的框架，使工程师能够在不牺牲软件工程可持续职业所需的智力严谨性的前提下交付价值。随着行业演进，最成功的团队将是把 AI 视为达成目标的手段，而非终点本身的团队。