尊重使用AI的指南

以下文章最初发表在Medium上，经作者许可在此转载。

随着公司采用AI工具，大量时间花在从安全、合规甚至成本角度考虑AI政策上。但许多领导者忽视了如何让团队在整体团队背景下使用AI的问题。这造成了大量未解决的紧张局势，领导者是时候站出来制定一些指南了，不仅关于如何以“批准”的方式使用AI，还要如何尊重地使用它。

当我提到“尊重地”时，我指的不是基本的适当职场行为（欺凌、虐待、骚扰等）。相反，我担心我们许多人没有考虑到，AI让个人更高效（实际上使他们能够产生更多产出）的方式可能会对团队的整体生产力产生负面影响。领导者不能坐等团队知道不能只生产垃圾然后发送给别人；如果你还没有制定全面的政策，这里有一些建议可以涵盖。

尊重使用AI的要素

不要要求他人阅读/审查你自己都没看过的内容。

这是我在AI密集型团队中听到的最常见的挫折之一。无论是代码所有者提交审查前并未真正理解的代码，还是生成后并未阅读的文档，太多人试图通过简化自己的工作流程来从同事那里窃取生产力，同时让同事承担所有的质量控制。拥有AI代码生成→AI代码审查→AI修复→最终人工审查的循环很好，但如果提示AI的人不先审查代码，他们就是在给队友施加巨大的验证负担，队友必须既相信你提示得好，又相信AI足够理解上下文和问题以得到可持续的解决方案。

文档比代码更具诱惑力，因为AI非常啰嗦，而我们大多数人不喜欢写作和编辑。很容易陷入这样的循环：你问AI一些问题，浏览答案，输出文档并发送给他人。我自己也犯过这种错！但当你一次浏览一个答案时，那些有意义的内容可能不会构成一份好的整体文档，而且回答单个问题和为人类读者写作之间存在巨大差异。特别是，你与AI对话时脑海中拥有的上下文可能根本不会在文档中体现；如果你在发送前不仔细阅读，就不会发现框架上的缺失。

更糟糕的是，有时人们甚至不理解他们提示的文档试图表达什么。你能描述这份文档，并与其他人在概念上进行讨论，并解释为什么它有意义吗？如果不能，你至少应该在发送时附上巨大的免责声明：“这是AI生成的，我仍然不太理解这个领域，请帮忙。”

许多人已经达到了不再阅读别人自己都不写的文档的程度，当这么多人在发送前都不阅读自己的输出时，谁又能责怪他们呢？

越短越好。

审查AI生成作品的部分烦恼在于，AI可能异常冗长。AI代码看起来像教程代码，比人类开发者愿意编写的要冗长得多。再加上一次性做出大改动的诱惑，而不是思考如何将代码分解成小块，你最终可能会得到上千行的拉取请求堆栈。AI生成的文档非常详尽，本应3页的内容变成了10或20页。对于那些完全依赖AI进行所有文本交互的人来说，你会看到LLM生成的聊天消息或电子邮件文本墙。

坦率地说，这很不礼貌。它与不审查自己的工作紧密相关，但即使出于某种原因你说服自己确实阅读并编辑了那个巨大的PR/文档/消息，你仍然在要求观众付出比你最初投入练习多得多的东西。对于代码，我鼓励你诚实自问：如果这个代码在凌晨3点出现问题，而所有AI工具都不工作，你能查看PR上下文和变更并调试吗？如果不能，那可能太大了。对于大型文档，至少，你是否在前面总结了重要点？如果别人只能自己要求AI总结文档，你可能应该在交付前做更多工作来提供这个价值。

最后，如果你借助AI写冗长的电子邮件或聊天消息来费力解释某事，也许你实际上需要开会或打电话。越来越长的文字交流一直表明人们需要停下来面对面交谈，AI的冗长并没有改变这一点。

AI不是关闭大脑或心灵的借口。

我们已经关闭大脑和心灵的迹象包括：不审查AI生成的作品，不花时间进行人工编辑，不将变更分解成小块，以及通过AI中介的文字交流避免真正的对话。这个指南是关于尊重使用AI的，因为如果你对同事有同理心，尊重他们的时间和技能，你会向他们展示礼貌，给予你引以为豪、你支持、你已经思考过并能解释的作品。AI可能产生了大部分输出，但你想到了所有需要完成的片段，并利用额外的生产力让某件事变得更好：更可靠、更简单、经过充分测试等。如果你发现自己在完全不思考的情况下盲目提示、接受输出并继续前进，这是一个警示信号，表明出了问题。也许可以采纳Vicki Boykis关于在开发过程中增加摩擦的建议（或你日常工作的等效建议）。

构建这些指南

如果你决定这样做，最后一个建议：假设你的公司有一些公司价值观，当你制定这样的政策和指南时，回溯这些价值观始终是个好主意。抽象地说越短越好是一回事，但如果你能将其与公司的价值观联系起来，它会更有共鸣。例如，如果我在亚马逊，我可能会考虑将“越短越好”与领导力原则“发明和简化”联系起来。既然越短越好，而这篇已经太长了，我就在这里结束。

喜欢这篇文章？你可能会喜欢我的书《经理的路径》和《平台工程：技术、产品和人员领导者指南》。