拥有一致的 AI 政策

# 制定连贯的AI政策 来源：https://brianmeeker.me/2026/05/14/have-a-coherent-ai-policy/ 2026-05-14 - 领导力 (https://brianmeeker.me/tag/leadership) - AI (https://brianmeeker.me/tag/AI) 我大学毕业后的第一份工作是在一家有数百名律师助理的律师事务所。他们运行着一套内部工作流系统来处理止赎和破产案件。当房市泡沫破裂时，我幸运地进入了一个繁荣行业。在高峰期，我们每年处理超过10万件此类案件。 工作被切分成极其精细的任务。律师助理们从任务队列中领取工作，大部分任务类型相似。这就像法庭文件的装配线；泰勒主义被引入了法律工作。 在我入职之前，公司请来了一位新的高管。她的任务之一是简化流程。她的计划很简单：站在员工身后，拿着秒表计时他们完成任务的时间。然后基于这些测量结果设定KPI。 结果可想而知。当高管拿着秒表站在身后时，人们不会像平时那样完成任务。她很快就发现这毫无价值。 以上所有内容都是为了引出软件工程领域最新的垃圾KPI——tokenmaxxing，以及我为我们团队写的AI政策。 ## Tokenmaxxing是什么鬼？ Tokenmaxxing是最新的管理时尚，而在主历2026年的今天，管理层仍然不明白：所有指标都会被钻空子。二十多年前，那个拿着秒表的高管就不懂，而今天显然还有领导没收到这份备忘录。 它的理念是公司通过创建一个谁使用最多token（令牌）的排行榜来鼓励采用AI工具。就像任何其他天真的指标一样，工程师们立刻开始钻空子 (https://blog.pragmaticengineer.com/the-pulse-tokenmaxxing-as-a-weird-new-trend/)：只需创建一个浪费token的循环，就能冲到排行榜顶部。或者浪费刚好足够的token来显示你在“使用”AI，但又少到无需解释你的用法。 这居然能算领导力？为你的团队创建易于钻空子的指标，而这些指标很快与真正帮助人们脱节。因为归根结底，我们在这里就是为了帮助别人，对吧？你在这里是为了帮助别人，对吧？我在这里就是为了这个。我在这里是为了帮助我们的客户实现他们的目标，而不是为了使用特定数量的token。Tokenmaxxing是一种伪装成领导力的虚荣指标。 ## 为什么需要AI政策？ 我管理的团队对AI非常怀疑，而且理由充分。我无需一一列举伦理方面的担忧——这方面的文章已经够多了。 我也无需列举生产力方面的担忧。取决于风向和木星在黄道上的位置，这些工具对你有多有用，结果因人而异。你能找到可信的例子，显示生产力从0.1倍到10倍不等，全看你怎么用。 但我确信的是，当前这一代LLM正在引起我近二十年职业生涯中最大的软件工程变革。作为团队经理，我的职责之一就是对此要有立场。因此，经过与团队的多次讨论，我很快拼凑了一份指南，描述我们的AI理念。 自从制定这份指南以来，我惊讶地发现，我交谈过的很多开发者所在的公司都没有这样的文档。上面的指令仅仅是：尽可能狠地用AI，然后希望一切顺利。 ## 太长不看 - 没有强制使用AI的要求 - 你必须理解AI生成的代码在做什么 - 如果你的AI工具消失，你必须能继续完成工作 - 关心你的队友和我们的客户 我们来详细讨论这些要点。 > 没有强制使用AI工具的要求。你不会因为使用这些工具的程度而被考核。话虽如此，这些工具是我们行业几十年来最大的变革。即使你不每天使用它们，了解它们的演变也很有好处。这个领域变化如此之快，你六个月前的经验很可能已经过时了。这种技能快速更迭的一个副作用是，任何你没在六个月前获得的专业知识，今天可能都已无关紧要。鼓励高级及以上工程师以最适合自己的方式使用这些工具。这可以是日常工作中不可或缺的一部分，也可以只是偶尔用于非生产代码的概念验证工具。 AI鼓吹者中存在一个内在矛盾。 1. 如果你现在不上AI的船，你就会被抛在后面。 2. AI发展太快，你今天知道的一切在六个月内都会变得一文不值。 “我现在必须成为AI最大主义者”和“我今天知道的一切在六个月内都会变得一文不值”这两者不可能同时为真。为什么我不能等到六个月后 (https://www.ufried.com/blog/not_left_behind/)，使用更好的模型和技术呢？那样我就不必遗忘那些仅仅为了绕开当前工具不成熟而存在的技巧了。（说的就是你，Ralph Loops。） 我们雇用聪明人，并相信他们能完成工作。我不在乎他们用什么操作系统，不在乎他们用什么编辑器，不在乎他们用什么LSP，也不在乎他们用什么AI工具。我不在乎他们是只在原型上小试牛刀，还是火力全开（Gas Town）地全力运行。我在乎的是他们为我们的客户交付了成果。 但正如政策所说，变革是真实存在的。你确实有职业责任偶尔尝试这些工具。我在2025年6月尝试的工具比我在2026年1月回来时使用的工具差得多。我预计2026年6月我正在使用的工具还会更好。 ## 代码依然是你的代码 > 任何由AI工具生成的代码都是你的代码。无论你的PR中有多少是由AI为你编写的，你都应该理解代码的作用。代码应遵循我们现有的模式。我们的AGENTS.md文件应该对此有所帮助，但并不能保证什么。你有责任确保你提交审查的代码足够合格。不要给审查者带来不必要的负担。我们有时都会提交有问题的PR——可能因为处理生产环境严重bug时的时间限制，或者因为我们正在探索新的设计空间。但这仍然是PR提交者的责任，需要明确指出这一点。使用AI工具不是将你的所有PR标记为有问题的借口。最终，是由人类做出架构决策，而不是AI。当需要选择接受机器更容易理解的代码还是人类更容易理解的代码时，我们更倾向于人类。如果AI工具不断吐出不符合我们编码标准的代码，那么需要改变的是AI工具，可能是通过改进我们的AGENTS.md文件。 AI最大主义者读到这里会嗤之以鼻。他们已经在凭感觉写代码（vibe coding），几乎不知道生成的代码长什么样。如果我们是一个从零开始的初创公司，我可能也会采取这种方法。但我们不是初创公司。我们有一个十年的代码库，里面充满了不同团队带来的相互矛盾的风格。有时候需要彻底进行代码考古 (https://speakerdeck.com/arthurdoler/digging-into-the-matrix-practicing-code-archaeology) 才能弄清楚某段代码为什么是现在这个样子。 AI最大主义者的赌注是，模型的改进速度将超过它们所累积的技术债务。这和初创公司多年来的赌注类似：初始代码多烂无所谓，重点是找到产品市场契合点，以后再担心可持续性。但我们已经有了产品市场契合点。我们在意的是未来十年能够继续在这个代码库上工作。我们的客户在意的是我们现有的功能持续可用。 如果你是AI最大主义者，那么瓶颈会转移到哪里？是代码审查吗？是知道客户到底想要什么吗？是客户能接受的变化速度吗？理论上能写10倍的代码，并不意味着你能为客户提供10倍的价值。 如果明天Claude宕机了，你还能完成工作吗？你能理解眼前的代码吗？如果下周OpenAI破产了，你会看到代码库中那些恐怖的东西而痛哭吗？ 我当了十年的咨询顾问。我曾空降到一些真正糟糕的代码库。你心爱的LLM某天不能用，不应该让你在试图理清你自作自受的AI垃圾代码中五种不同日期格式化函数的使用方式时，恐惧得发抖。 ## 那初级工程师怎么办？ > 不管你认为自己的学习风格如何，我们所有人都是通过实践来学习的。在软件领域，这意味着动手写代码。你必须从多个理解层次思考你所写代码的细微之处和影响，才能真正学会。AI编码工具通过剥夺你的练习次数，绕过了这种学习过程。因此，初级工程师应该审慎使用这些工具。依赖AI工具为你写代码，长期来看会限制你的成长。你无法获得进阶职业、接手更大项目所需的深层理解。这并不意味着初级工程师不能使用这些工具。但是，如果你的AI工具明天消失了，而你自己无法做出贡献，那就是个问题。 这可能是我感受最深的部分。我们的行业正在迅速抽掉初级工程师的梯子。我们正在拿走你需要用来学习的那类工作。你需要大量的练习——那种AI擅长自动化掉的繁琐工作。 当前这一代AI迅速暴露了一个事实：大多数人根本不知道学习是如何发生的。学习风格是个神话。你可能在如何获取信息上有偏好，但真正的学习是通过实践发生的。学习发生在挣扎之中 (https://ergosphere.blog/posts/the-machines-are-fine/)。你必须与一个概念搏斗。你有时必须感到困惑。这不是可选的。如果你依赖LLM来写大部分代码——那些你没有亲自写过练习的代码——你就不会学会。你不会获得更深的理解。 你认为初级工程师应该使用这些工具到什么程度，取决于你对团队中初级工程师角色的定位，以及你对他们的职业发展负有什么责任。我不期望初级工程师一开始就能高效产出。我期望他们学会如何变得高效。我期望他们犯错。我期望他们学会如何学习一个代码库。我期望他们学会如何学习一个领域。而如果他们把这些大部分外包给LLM，他们就不会学会自己思考。 当前形式的AI作为一个抽象层，漏洞太多，以至于这些细节在任何合理复杂的代码库或领域中都会不断冒出来。在这一点改变之前，初级工程师必须学习，而学习是通过实践发生的。 你应该能够以某种方式阐述你对团队中初级工程师角色的定位，以及你对他们的成长所负的责任（如果有的话）。你对他们的角色和目标可能与我的不同。这应该驱动你对初级工程师应该使用多少工具的看法。 ## 我们关心人 > 归根结底，我们交付代码是为了帮助我们的客户触达人们。我们关心客户。同时，我们在团队内部合作。我们关心队友。这两个受众群体常常相互矛盾。有时会有压力，要为客户交付更多功能，帮助他们触达人们。为了合理的理由，短时间这样是可以的。但过度的话，随着技术债务的积累，会伤害我们的队友。这在我们的AI世界中很有关系。为了取悦客户，可能会有诱惑去尽可能多地交付AI生成的代码。但这不能以代码库中充斥AI垃圾为代价。这会损害团队的长期生产力和幸福感。工程师们不想整天审查AI垃圾PR。 Tokenmaxxing 与关心人脱节。我关心人，而不是token。如果使用token能帮助你帮助人，那么请随意使用token。但token不是最终目的。Token是手段。我的编辑器是手段。我选择的编程语言是手段。 我的团队是"人"这个类别的一个子集。我关心人，所以我也关心我的团队。这意味着强迫我的团队每天使用那些让他们很恼火的工具，是一件坏事。 我可能是错的。也许AI会好到让我们被竞争对手埋葬。或者也许它太好了，以至于当前的经济体系也会崩溃。我不知道这一切会走向何方，但我确实知道我关心人。AI不是人。 ## 这适用于我的团队吗？ 每个团队和公司都不同。这个政策适用于我的团队。它可能也适用于你的，也可能不。我们有一个十年的代码库，这些年经历了很多变动。我们所在的监管环境随着时间的推移变得复杂得多。我们有长期客户，如果我们为了匆忙采用AI工具而到处搞坏东西，他们不会高兴。你很可能也不希望你依赖的工具现在就这么干。 你的约束条件不同，所以你的政策很可能也应该不同。我知道如果我在一个从零开始的初创公司，和同一团队一起工作，约束条件会截然不同，那么我们使用AI的方式也会相应地改变。 但你应该对你试图实现的目标有某种连贯的理念。Tokenmaxxing 不连贯。它只是又一次数代码行数，只不过这次还多了一项特权——为你那狗屁指标向第三方支付数千美元。如果这也算领导力，也许下一个我们就能用AI智能体来替代你了？你欠你的团队（也欠你自己）一个更好的样子。 © 2022 Copyright: Brian Meeker