AI輔助技術寫作：何時停止

在一次C++程式碼維護中，作者發現了一條不斷增長的註釋，最終它比所描述的程式碼還要長。為了精簡程式碼，作者決定使用Claude.ai將註釋轉化為一篇部落格文章，並將解釋從程式碼中完全移除。本以為事情就此結束，但後續的發展卻出乎意料。

作者將草稿交給Google Gemini審閱，結果發現了一個真正的技術錯誤——不是風格上的小問題，而是一個實際的程式設計錯誤。Gemini提出了修復方案，但當作者嘗試實施時，卻發現程式碼無法編譯。這意味著作者在程式碼審查中一直堅持的原始註釋居然是錯誤的，而沒有人發現，因為從未有人真正嘗試編譯過那個反例。

於是，文章從頭重寫。隨後，作者又將其展示給更多的AI：Perplexity.ai、ChatGPT、微軟Copilot等，但文章開始失控。每一輪審閱都會暴露出之前版本中細微的錯誤或未考慮的問題。新的術語被創造出來以區分原本不需要區分的事物；增加了一個白名單機制，以便特意選擇執行時特性的快捷方式可以被標記為“已檢查”而非“假定”。最終，文章從一條註釋變成了一篇部落格，又變成了一份類似實驗室筆記的檔案。

作者認為，這個過程中最值得記錄的部分，是分歧的兩種截然不同的型別，以及作者直到深陷其中才意識到它們的差異。第一種分歧有仲裁者。當AI說“我有更好的主意”而實際並非如此時，編譯器能在十秒內解決爭議。沒有人需要被說服……程式碼要麼能編譯並按預期執行，要麼不能。過程中的所有技術爭議最終都以同樣的方式解決：不是看哪個AI聽起來更自信，而是透過實際驗證。

第二種分歧則沒有仲裁者。當技術內容已經紮實後，作者詢問對文章本身的意見，卻得到了截然不同的反饋。一些模型（尤其是ChatGPT和Copilot）認為文章太長（畢竟AI常被要求總結），而Claude.ai則認為長度合理，因為它展示了錯誤發生的過程，而非僅僅給出修正後的結論。沒有人能透過編譯來解決篇幅問題，因為這裡不存在“指標是否被破壞”那樣的客觀事實。這不是事實性問題，而是關於文章目的的問題。結果發現，在意見開始交鋒之前，沒有人（包括作者）真正明確過文章的目標。

打破僵局的方法不是繼續爭論，而是回到原點，問自己最初想要達成什麼。作者並非想寫一篇在普通讀者中贏得簡潔評價的文章，而是想寫一段可以連結到註釋中的內容，供未來某天開啟檔案並好奇為什麼這樣寫強制轉換的人閱讀。一旦明確了這一點，大部分關於篇幅的爭論自然消散。但仍有一部分保留了下來：一些“過於冗長”的批評實際上是在命名問題上，而非篇幅問題。作者保留了那些正確的部分。

作者認為，可推廣的經驗是：當你無法判斷一個分歧是技術性還是編輯性時，這種混淆本身就值得停下來並命名，因為兩者需要完全不同的解決工具。一種需要編譯器、實驗或事實；另一種需要你大聲說出自己真正想做的事情。當所有參與者（無論是人還是AI）在確認最佳化目標之前就急於最佳化時，這一點很容易被忽略。

“是否完成”沒有編譯器。到了某個時刻，你只能做出決定並繼續前進。因此，在技術準確性達成共識後，作者決定停止修改。如果你覺得文章太長，需要總結，那就去問AI吧。🤖

如果你有改進本文的想法，歡迎在GitHub上提交問題（甚至更好的是提交拉取請求）！