制定连贯的人工智能政策

我的第一份大学毕业后工作是在一家有数百名律师助理的律所。他们运行内部工作流系统处理止赎和破产案件。当房地产泡沫破裂时，我幸运地进入了一个蓬勃发展的行业。高峰期我们每年处理超过10万件案件。工作被细分成精细的任务，律师助理从任务队列中领取任务，大部分是重复性的。这就像法院文件的流水线，泰勒主义被应用到法律工作中。在我入职前，一位新高管被请来简化流程。她的计划简单粗暴：拿秒表站在员工身后计时，然后据此制定KPI。结果可想而知——有人盯着时，员工的表现完全不同。她很快意识到这毫无价值。这一切都是为了引出软件工程中最新垃圾KPI——“Tokenmaxxing”，以及我为团队制定的AI政策。Tokenmaxxing是管理层的最新噱头，他们至今仍不明白每个指标都会被钻空子。二十年前那个拿秒表的高管不明白，显然今天仍有未收到通知的领导者。他们通过创建谁使用最多令牌的排行榜来鼓励采用AI工具。工程师立刻钻空子：写一个循环浪费令牌，然后登上榜首；或者仅浪费足够显示“使用”AI的量，而不解释用途。这就是所谓的领导力——创建易被操纵的指标，迅速脱离真正帮助人的初衷。因为归根结底，我们存在的目的是帮助人，对吧？我在这里是为了帮助客户实现目标，而不是使用一定数量的令牌。Tokenmaxxing是伪装成领导力的虚荣指标。我管理一个对AI非常怀疑的团队，这合情合理。我不需要列举伦理问题——已经有很多文章了。我也无需列举生产力问题——在现有大模型时代，你的体验可能从0.1倍到10倍不等，取决于你怎么用。但我确信，当前这代LLM正引发我近二十年职业生涯中最大的颠覆。作为团队经理，我必须对此有立场。经过与团队充分讨论，我很快制定了一份AI哲学指南。令我惊讶的是，许多开发者告诉我他们公司没有此类文档，命令只是“尽可能用AI，然后希望一切顺利”。政策摘要：不强制使用AI；你必须理解AI生成的代码；如果AI工具消失，你仍能胜任工作；关心你的队友和客户。下面详细说明。何时使用AI工具：没有强制要求。你不会因使用量而被评估。但话说回来，这些工具是几十年来行业最大的颠覆。即使你不日常使用，也应了解其演变。这个领域变化极快，六个月前的经验可能已过时。高级工程师被鼓励以最适合自己的方式使用AI，无论是日常流程还是偶尔用于非生产代码的概念验证。AI推动者存在内在矛盾：如果现在不跟上，你就会被抛弃；AI发展太快，你今天所知的一切六个月后都会过时。但这两者不能同时成立。为什么我不能等六个月后使用更好的模型和技术？那时我无需学习只为了规避当前工具不成熟而存在的技巧。我们雇用聪明人并信任他们。我不关心他们用什么操作系统、编辑器或AI工具。我关心他们是否为客户交付价值。但正如政策所说，颠覆是真实的。你的职业责任是偶尔尝试这些工具。2025年6月的工具比2026年1月差很多。我期待2026年6月的工具会更好。仍然是你自己的代码：任何AI生成的代码都是你的代码。无论你的PR中有多少AI写的代码，你都需要理解它的功能。代码应符合现有模式。我们的AGENTS.md文件有帮助，但不保证。你有责任确保提交审查的代码合格。不要给审查者带来不当负担。我们有时都会提交有问题的PR，但这不是借口。最终架构决策由人而非AI做出。当选择更容易被机器理解还是人类理解的代码时，我们优先考虑人类。如果AI工具不断输出不符合编码标准的代码，那么需要改变的是AI工具，可能是改进AGENTS.md。AI最大化主义者读到这会嗤之以鼻——他们已经在Vibe Coding了，对生成的代码几乎不了解。如果我们是个初创公司，我可能也会这么干。但我们的代码库有十年历史，充满不同团队带来的矛盾风格。有时需要完全的代码考古才能弄清楚为什么这样。AI最大化主义的赌注是模型改进速度会超过它们积累的技术债。这类似于初创公司多年来的赌注：代码好坏不重要，重点是找到产品市场契合度。但我们已经有产品市场契合度了。我们关心未来十年能否继续在此代码库上工作。我们的客户关心现有功能是否持续工作。如果你是个AI最大化主义者，瓶颈在何方？是代码审查？是了解客户需求？还是客户能接受的变更速度？理论上能写10倍代码并不意味着为客户提供10倍价值。如果Claude明天宕机，你还能工作吗？你能理解面前的代码吗？如果OpenAI下周破产，你会看着代码库中的恐怖景象哭泣吗？我做了十年咨询，空降过一些极其糟糕的代码库。你选择的LLM某天不可用，不应该让你在试图理解自己创造的AI垃圾中恐惧颤抖。那初级工程师呢？不管你自认为的学习风格如何，我们都是通过实践学习。在软件领域，这意味着写代码。你必须多层面思考代码的含义和细微差别才能真正学习。AI编码工具通过剥夺你的练习机会来短路这一过程。因此，初级工程师应谨慎使用这些工具。长期依赖AI写代码会限制你的成长。你不会获得职业发展所需更深层次的理解。但这不意味着禁止使用。然而，如果明天AI工具消失，你发现自己无法贡献，那就是问题。这可能是政策中我最强烈的部分。我们的行业正在快速抽掉初级工程师的梯子。我们拿走了他们需要学习的工作。你需要重复练习AI擅长自动化的苦活。当前这代AI迅速暴露了大多数人根本不懂学习。学习风格是迷思。你可能偏好某种信息接收方式，但学习是通过实践发生的。学习发生在挣扎中。你必须与概念搏斗，有时必须困惑。这不是可选项。如果你依赖LLM写大部分代码，没有自己重复练习，你将学不到东西。你不会获得更深的理解。初级工程师应该使用多少工具取决于你认为他们在团队中的角色以及你对他们的职业责任。我不期望初级工程师一开始就高效。我期望他们学习如何高效。我期望他们犯错，学习如何学习代码库和领域。如果他们把这大部分外包给LLM，他们就学不会自己思考。当前形式的AI是过于泄漏的抽象，这些细节在合理复杂的代码库或领域中会不断浮现。在那改变之前，初级必须学习，学习通过实践。你应该能够以某种方式阐述初级在你的团队中的角色以及你对他们的成长责任。角色和目标可能与我不同，这应驱动你对工具使用的哲学。我们关心人：最终，我们交付代码是为了帮助客户接触人。我们关心客户。同时，我们在团队内部工作，关心队友。这两个群体时常存在张力。有时为了帮助客户，会有压力交付更多功能。短期可以，但长期会损害队友。在AI世界中，诱惑在于尽可能多地交付AI生成代码让客户更满意。但这不能以代码库中的AI垃圾为代价，否则会损害长期生产力和团队幸福感。工程师不想整天审查AI垃圾PR。Tokenmaxxing与关心人脱节。我关心人，而不是令牌。如果使用令牌能帮你帮助人，那就尽管用。但令牌不是目的，而是手段。我的编辑器是手段，我选择的编程语言也是手段。我的团队是‘人’这个范畴的子集。我关心人，特别是那些被我影响的人。最终，我希望我的团队能为客户提供价值，同时享受工作并成长。这就是我制定这项政策的原因。