The following article originally appeared on Medium and is being republished here with the author’s permission.以下文章最初发表于 Medium，经作者许可在此转载。
As companies adopt AI tools, a lot of time is spent on thinking about AI policies from a security, compliance, or even cost-focused angle. But many leaders are neglecting to address how their teams should work with AI in the context of the team as a whole. This creates a lot of unresolved tension, and it’s time for leaders to step up and set some guidelines not just for how to use AI in an “approved” sense but how to use it respectfully.随着企业采用 AI 工具，大量时间被用于从安全、合规甚至成本的角度思考 AI 政策。但许多领导者忽略了在团队整体背景下，团队成员应如何与 AI 协作。这造成了许多未解决的矛盾，现在是领导者站出来制定一些准则的时候了——不仅要规定如何以“获批”的方式使用 AI，还要规定如何尊重地使用它。
When I say respectfully, I am not talking about the baseline appropriate workplace behavior (bullying, abuse, harassment, etc.). Instead, I’m concerned that many of us haven’t considered that the ways AI can make an individual more productive (literally enabling them to produce more outputs) can have an overall negative impact on the team’s productivity. Leaders can’t just sit around and expect that their teams will know that they can’t just produce slop and send it to others; if you haven’t set up a thorough policy yet, here are some suggestions on what to cover.当我提到“尊重”时，指的不是职场中基本的行为准则（如反对欺凌、虐待、骚扰等）。相反，我担心的是，我们许多人没有意识到，AI 提高个人生产力的方式（字面上使其产出更多内容）可能会对团队的整体生产力产生负面影响。领导者不能坐视不管，指望团队成员会自觉意识到不能随意生成垃圾内容并发送给他人；如果你还没有制定详尽的政策，以下是一些建议，供你参考涵盖的内容。
Elements of respectful AI use尊重使用 AI 的要素
Don’t ask someone to read/review what you haven’t read or reviewed yourself.不要让别人阅读或审查你自己都没有阅读或审查过的内容。
This is one of the most common frustrations I hear amongst people working on AI-heavy teams. Whether it’s code that the owner didn’t really bother to understand before submitting for review or documents that they generated and didn’t bother to read, too often people try to steal productivity from their colleagues by streamlining their production of work while asking their colleagues to do all of the quality control themselves. It’s great to have a loop of AI code generation → AI code review → AI fixes → final human review, but if the person prompting the AI doesn’t bother to review that code first, they’re putting a huge validation tax onto their teammate, who has to trust both that you prompted well AND that the AI understood the context and problem well enough to get a sustainable solution.这是我在 AI 密集型团队中听到的最常见的挫败感来源之一。无论是提交审查前所有者根本没打算理解的代码，还是他们生成后懒得阅读的文档，人们往往试图通过简化自己的工作流程来“窃取”同事的生产力，同时却要求同事承担所有的质量控制工作。拥有“AI 代码生成 → AI 代码审查 → AI 修复 → 人工最终审查”的循环固然很好，但如果提示 AI 的人自己都不去审查代码，他们就会给队友增加巨大的验证负担，因为队友不仅要信任你的提示词写得好，还要信任 AI 充分理解了上下文和问题，从而得出了可持续的解决方案。
Documents are an even bigger temptation than code, because AI is so verbose and most of us hate writing and editing. It’s easy to get into a loop where you ask the AI some questions, skim the answers, output a document and send it to others. I’m guilty of this myself! But what makes sense when you’re skimming one answer at a time may not make for a good overall document, and there is a big difference between answering individual questions and writing for a human reader. In particular, the context that you have in your own head as you are talking to the AI may not come out at all in the document; if you don’t bother to read it thoroughly before sending it out, you won’t catch the gap in framing.文档比代码更具诱惑力，因为 AI 非常啰嗦，而我们大多数人讨厌写作和编辑。很容易陷入这样一种循环：向 AI 提问，略读答案，输出文档，然后发送给他人。我自己也犯过这种错！但当你一次略读一个答案时觉得合理的内容，拼凑在一起未必是一份好的文档；回答单个问题与为人类读者写作之间存在巨大差异。特别是，你在与 AI 对话时脑海中拥有的背景信息，可能完全没有体现在文档中；如果你在发送前不仔细阅读，就无法发现其中的逻辑缺口。
Even worse, sometimes people don’t even understand what the document they prompted is trying to say. Can you describe this document, and have a conversation about the concepts it presents with others and why it makes sense? If not, you have no business sending it along without at minimum the huge caveat “This is AI-generated and I still don’t really understand this space, please help me.”更糟糕的是，有时人们甚至不理解他们所提示生成的文档到底想表达什么。你能描述这份文档，并与他人讨论其中提出的概念及其合理性吗？如果不能，你就没有理由在没有至少加上“这是 AI 生成的，我对此领域仍不太了解，请帮帮我”这一重大免责声明的情况下将其发送出去。
Many people have reached the point where they won’t read something a person didn’t bother to write themselves, and who can blame them when so many don’t even bother to read their output before sending it on?许多人已经到了这样的地步：他们拒绝阅读别人懒得自己写的东西。当那么多人甚至在发送前都不愿阅读自己的输出时，谁又能责怪他们呢？
Shorter is better.越短越好。
Part of the annoyance of reviewing AI-generated work is that the AI can be painfully long-winded. AI code often looks like tutorial code, with much more verbosity than human developers would bother with. Add in the temptation to one-shot big changes rather than thinking about how to break the code down into pieces, and you can end up with stacks of thousand line pull requests. The documents AI produces are so thorough that something that should be 3 pages turns into 10 or 20. And for those who have fully embraced AI for all of their text-based interactions, you start to see the LLM-generated wall of text chat messages or emails.审查 AI 生成工作带来的烦恼之一是 AI 可能极其冗长。AI 代码看起来往往像教程代码，比人类开发者会写的要啰嗦得多。再加上倾向于一次性进行大规模更改，而不是思考如何将代码拆解，最终可能会产生堆积如山的千行代码合并请求（PR）。AI 生成的文档非常详尽，本应 3 页的内容变成了 10 页或 20 页。对于那些在所有基于文本的交互中完全拥抱 AI 的人来说，你开始看到 LLM 生成的“文字墙”聊天消息或电子邮件。
This is, frankly, just rude. It goes hand in hand with not bothering to review your own work, but even if for some reason you convince yourself that you really did read and edit that giant PR/document/message, you’re still asking so much more of the audience than you probably put into the exercise in the first place. When it comes to code, I encourage you to honestly ask yourself: If this broke at 3:00am and none of the AI tools were working, would you be able to look at the PR context and the change and debug it? If not, it is probably too much. When it comes to a big document, at a minimum, have you at least summarized the important points up-front? If someone is just going to ask an AI to summarize the document themselves, you should probably do more work to provide that value before handing it off.坦率地说，这很不礼貌。这与不愿审查自己的工作如出一辙。即使出于某种原因，你确信自己确实阅读并编辑了那个巨大的 PR/文档/消息，你对受众的要求仍然远高于你自己在该任务中投入的精力。对于代码，我鼓励你诚实地问自己：如果这在凌晨 3 点坏了，且所有 AI 工具都无法使用，你是否能够查看 PR 上下文和更改并进行调试？如果不能，那可能就太复杂了。对于大型文档，至少你是否在开头总结了重点？如果别人还要自己去问 AI 来总结你的文档，你可能应该在交付前多做些工作来提供价值。
Finally, if you’re writing long-winded emails or chat messages with AI-assistance in order to painstakingly try to explain something, perhaps you actually need to have a meeting or call instead. Increasingly long text exchanges have always been a sign that people need to stop and talk face-to-face, and AI logorrhea hasn’t changed that.最后，如果你为了费力解释某事而使用 AI 辅助撰写冗长的电子邮件或聊天消息，也许你实际上应该开个会或打个电话。越来越长的文本交流一直是一个信号，表明人们需要停下来面对面交谈，而 AI 带来的“语言多动症”并没有改变这一点。
AI is not an excuse to turn off your brain, or your heart.AI 不是让你关闭大脑或心灵的借口。
Signs we’ve switched off our brains and our hearts include: not reviewing the AI-generated work, not taking the time to do human editing, not breaking the changes down into chunks, and avoiding real conversations through AI-mediated text exchange. This guidance is about respectful use of AI because if you have empathy for your colleagues and respect for their time and skills, you will show them the courtesy of giving them work that you are proud of, that you stand behind, that you have thought through and can explain. The AI may have produced a lot of the output, but you thought about all of the pieces that needed to be done, and used the extra productivity to make something better: more reliable, simpler, well tested, whatever. If you find yourself not thinking at all and just mindlessly prompting, accepting output, and moving forward, it’s a warning sign that something is wrong. Perhaps take some advice from Vicki Boykis on adding friction to your development process (or whatever the equivalent is of your day-to-day work).我们关闭大脑和心灵的迹象包括：不审查 AI 生成的工作、不花时间进行人工编辑、不将更改拆解成块，以及通过 AI 中介的文本交换来回避真正的对话。这份指南旨在倡导尊重地使用 AI，因为如果你对同事有同理心，并尊重他们的时间和技能，你就会给予他们应有的礼遇——提供你引以为傲、愿意背书、经过深思熟虑且能解释清楚的工作成果。AI 可能生成了大部分输出，但你需要思考所有需要完成的部分，并利用额外的生产力让成果变得更好：更可靠、更简洁、经过充分测试等等。如果你发现自己根本没有思考，只是机械地输入提示词、接受输出并继续前进，这是一个危险信号，说明出了问题。也许可以参考 Vicki Boykis 关于在开发过程中增加“摩擦力”的建议（或者你日常工作中等效的做法）。
Framing these guidelines构建这些准则
If you decide to do this, one final tip from me: Assuming your company has some sort of company values, it’s always a good idea to call back to these values when you create policies and guidelines like this. It’s one thing to abstractly say that shorter is better, but if you can tie that to a value for your company, it will resonate more strongly. As an example, if I were at Amazon I might consider tying “shorter is better” to the leadership principle Invent and Simplify. And since shorter is better and this is already too long, I leave you here.如果你决定这样做，我最后给出一个建议：假设你的公司有某种企业价值观，在制定此类政策和准则时，回顾这些价值观总是一个好主意。抽象地说“越短越好”是一回事，但如果你能将其与公司的价值观联系起来，它会产生更强烈的共鸣。例如，如果我在亚马逊，我可能会考虑将“越短越好”与“发明与简化”（Invent and Simplify）这一领导力原则联系起来。既然越短越好，而且这篇文章已经太长了，我就在此打住。
Enjoy this post? You might like my books The Manager’s Path and Platform Engineering: A Guide for Technical, Product, and People Leaders.喜欢这篇文章吗？你可能也会喜欢我的书《经理人的路径》（The Manager’s Path）和《平台工程：技术、产品和人员领导者指南》（Platform Engineering: A Guide for Technical, Product, and People Leaders）。
