尊重使用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關於在開發過程中增加摩擦的建議（或你日常工作的等效建議）。

構建這些指南

如果你決定這樣做，最後一個建議：假設你的公司有一些公司價值觀，當你制定這樣的政策和指南時，回溯這些價值觀始終是個好主意。抽象地說越短越好是一回事，但如果你能將其與公司的價值觀聯絡起來，它會更有共鳴。例如，如果我在亞馬遜，我可能會考慮將“越短越好”與領導力原則“發明和簡化”聯絡起來。既然越短越好，而這篇已經太長了，我就在這裡結束。

喜歡這篇文章？你可能會喜歡我的書《經理的路徑》和《平臺工程：技術、產品和人員領導者指南》。