AI代替了我的右手，而且我再也回不去了！
摔斷了我的手迫使我用 AI 編寫(xiě)了 2 個(gè)月的所有代碼。我再也回不去了。
圖 1 對使用 AI 編碼“豎起大拇指”
（所有意見(jiàn)均為我自己的，不是我雇主的意見(jiàn)）
幾個(gè)月前，我在騎自行車(chē)去舊金山上班時(shí)摔斷了手，只能用左手打字。通過(guò)結合使用語(yǔ)音轉文本和 Claude，我在 Anthropic 的工作中仍然能夠編寫(xiě)大量代碼，包括一周我寫(xiě)了 3,000 多行（誠然，樣板重boilerplate-heavy）代碼！
所有這一切的一線(xiàn)希望是：它迫使我生活在我們人類(lèi)很少編寫(xiě)自己的代碼的未來(lái)。老實(shí)說(shuō)，我喜歡AI。
我的設置
我以前曾使用過(guò) Copilot 等工具生成 AI 代碼，但在事故發(fā)生之前，我主要還是自己編寫(xiě)代碼。我也使用過(guò)語(yǔ)音轉文本，但主要用于手機上的文本消息，從未在我的計算機吉印通行過(guò)。
幸運的是，Mac 內置的語(yǔ)音控制對于自然語(yǔ)言來(lái)說(shuō)非常好，但遺憾的是，在任何與代碼相關(guān)的事情上都很糟糕;符號和詞匯太不合時(shí)宜了。“Eval（評估）”？你的意思一定是“Evil（邪惡）”。
圖 2 我使用語(yǔ)音控制的典型松弛消息。
有像 Talon 這樣出色的特定于代碼的語(yǔ)音轉文本系統，但對代碼生成感到非常興奮，我認為這是我們自己產(chǎn)品的借口！
Copilot Autocomplete 現在對我來(lái)說(shuō)太慢了，因為它需要我寫(xiě)出半行代碼。我的總體目標比開(kāi)始編寫(xiě)代碼本身要容易得多。
我將大部分代碼庫復制并粘貼到 Claude AI 中，并發(fā)出語(yǔ)音命令來(lái)轉換它。例如，我會(huì )說(shuō)“重構 ABC 函數以接受輸入 XYZ”或“為這些新函數 ABC 編寫(xiě)單元測試，并查看 XYZ 的示例測試”。
它并不總是在第一次嘗試時(shí)就成功，但 Claude 愿意接受后續指示和調整。我感覺(jué)就像在結對編程（編者：我常說(shuō)，人機結對編程是未來(lái)常態(tài)），而其他人在驅動(dòng)鍵盤(pán)！
如何使用 Claude
被迫像這樣寫(xiě)代碼，我很快就弄清楚了哪些有效、哪些無(wú)效。有時(shí)這很神奇，但有時(shí)我想把我的電腦扔出窗外。我不得不斷地在我的 IDE 和 Claude 之間復制粘貼，并手動(dòng)將因 Claude 的輸出長(cháng)度限制而截斷的代碼片段拼接在一起。有好幾次，我都因為忘記了我之前的指示而對Claude大聲指責。
圖 3 使用語(yǔ)音控制時(shí)，對計算機生氣會(huì )更令人滿(mǎn)意。
舉例說(shuō)明
如果你給出一個(gè)基本的請求，LLM 會(huì )給你一個(gè)中間的通用答案，這可能不適用于你的特定代碼庫。
如果你給出非常明確的指令（instructions），說(shuō)明你期望什么輸入和輸出、使用什么庫，等等，你就會(huì )得到更好的結果。我運氣最好，將我的指令放在輸入數據和上下文的開(kāi)頭和結尾。
更好的是提供代碼庫中的示例進(jìn)行模擬。這對于樣板代碼（boilerplate code）非常有效，例如編寫(xiě)單元測試或任何模板化（templatized）的東西，但也有助于向模型展示如何使用代碼庫中的內部實(shí)用程序函數。
遷移和重構就是這方面的完美案例。我會(huì )手動(dòng)遷移一個(gè)實(shí)例，然后以此為例，讓 Claude 轉換其余的輸入。通過(guò)遵循這種格式，我能夠非?？焖俚刂貥嫶蠹s 3,000 行代碼。
把Claude放在駕駛座上（而不是副駕駛）
圖 4 我朋友做的遙控機器人！
大多數人把 LLM 作為 StackOverflow 的替代品：他們會(huì )向LLM問(wèn)路，但車(chē)還是他們自己在開(kāi)。我要翻轉過(guò)來(lái)——讓LLM開(kāi)車(chē)。如果你能給 Claude 正確的構建塊，它通?？梢砸淮螄L試 “單次” 完成全部?jì)热?。?/p>
在我和我的朋友 Survy 的一個(gè)周末機器人項目中，我們給了 Claude 代碼片段來(lái)控制單個(gè)電機并讀取我們的藍牙操縱桿。有了這些構建塊，Claude 能夠一次嘗試編寫(xiě)所有代碼來(lái)遠程控制機器人，為我們節省了大量時(shí)間和繁瑣的數據管道（data plumbing）！
令人驚訝的是，這與通常的建議相反，即一次提示 LLM 做一件事！在我不熟悉的環(huán)境中，Claude 經(jīng)常擅長(cháng)分解任務(wù)。過(guò)于具體的請求是可行的，但就像將人類(lèi)建議限制在一個(gè)狹隘的問(wèn)題中而不給出整體背景和目標一樣，可能會(huì )導致你陷入兔子洞！
RTFM == Read This For Me
圖 5 100 頁(yè)的數據表和用戶(hù)手冊...
我們的電機控制器有一個(gè) 100 頁(yè)的數據表，非常密集！但將其上傳到 Claude，然后我們只要提出問(wèn)題，Claude就可以快速解決其中一個(gè)問(wèn)題！而以前，這可能需要幾個(gè)小時(shí)的仔細閱讀和查找相關(guān)術(shù)語(yǔ)和教程。
機械的同情心
“你不必成為工程師才能成為賽車(chē)手，但你必須有機械的同情心（Mechanical Sympathy）”
——Jackie Stewart,3次一級方程式世界冠軍
我開(kāi)始建立一種非常好的直覺(jué)，知道Claude可以做什么樣的事情，以及我自己應該做什么。知道這種區別讓我在兩個(gè)方向上都避免了很多挫敗感。
我學(xué)會(huì )了在哪里可以偷工減料：
“我正在使用一個(gè)名為 pygame 的 Python 庫，然后......” 變?yōu)橹皇?“在 pygame 中......”
“當我運行代碼時(shí)，我收到了此錯誤消息......你認為我現在應該怎么做” 變成了“在堆棧跟蹤中復制。
我了解到，轉換或重構大塊代碼效果很好; 例如，在每行之間添加定時(shí)儀表（timing instrumentation）。
另一方面，我了解到，如果 LLM 不能在兩次嘗試中修復一個(gè)錯誤，那么它永遠不會(huì )。是時(shí)候深入挖掘自己了。
我也非常清楚Claude會(huì )犯什么樣的錯誤。有一次，Claude 給了我們代碼，該代碼循環(huán)了 motor1、motor2、motor2、motor4，但丟失了motor3。我的朋友注意到了這一點(diǎn)，并說(shuō)“哦，這一定是幻覺(jué)！” 但我只能感覺(jué)到“Claude不可能犯這個(gè)錯誤”，果然，當我們檢查輸入時(shí)，那個(gè)錯誤也存在于我們放入Claude的原始代碼中。
為自己打造一次性工具
在帶著(zhù)我們的機器人在后院轉了一圈后，它吐出了一個(gè)包含GPS坐標和其他數據的CSV文件。我們想檢查實(shí)際現場(chǎng)運行的準確性，但我沒(méi)有很好的方法來(lái)查看或檢查它。
以前，弄清楚如何查看和分析這些 GPS 坐標可能需要一個(gè)小時(shí)。我們甚至可能不得不手動(dòng)檢查手機上的 GPS 坐標，并嘗試用肉眼比較這些數字。
現在取而代之的是，我給了 Claude CSV的前兩行，它為我們生成了一個(gè)網(wǎng)絡(luò )應用程序，用于在衛星圖像之上呈現上傳的GPS坐標CSV！
圖 6 Claude 在一個(gè)提示中創(chuàng )建的 GPS 可視化 Web 應用程序
擁有我需要的完美調試工具，而不是依賴(lài)打印語(yǔ)句或預構建的可視化工具，這完全改變了游戲規則。軟件變得如此便宜，以至于它是一次性的！
總的來(lái)說(shuō)，這些實(shí)踐經(jīng)驗使我在使用 AI 編寫(xiě)代碼方面變得更快！回到非 AI 工具，感覺(jué)就像放棄編譯器并手動(dòng)編寫(xiě) Assembly。
這是怎么回事？
圖 7 這一切將何去何從？
在過(guò)去的幾年里，AI在軟件工程中的最大用途是 Github Copilot，用于在 IDE 中自動(dòng)完成，以及 ChatGPT用于回答過(guò)去需要 StackOverflow 的編程問(wèn)題。早期的“智能體” 演示可以在沒(méi)有人工監督的情況下一次操作多個(gè)步驟，但沒(méi)有什么是實(shí)用的。
今年，這三個(gè)領(lǐng)域都在發(fā)生轉變。Zed、Cursor 和各種 VSCode 擴展等 IDE 更深入地集成了 LLM，以提供更好的上下文并處理更大的代碼生成塊。Claude 的 Artifacts 和 ChatGPT 的 Data Analyst 已成為快速原型和一次性代碼的首選解決方案，而不是 Jupyter 筆記本。最后，像 Cognition、Factory 和 CodeGen 這樣的一大批智能體初創(chuàng )公司正在端到端地自動(dòng)化工程工作流程的某些部分。
就我個(gè)人而言，我認為這三個(gè)區域可以融合成一個(gè)產(chǎn)品——“AI 工程師”。這將是一個(gè)可以在自主模式和同步模式之間的連續體中工作的單一系統：
用于明確任務(wù)的自主模式：人工智能將完全獨立工作，能夠編寫(xiě)和運行代碼、使用外部工具、在網(wǎng)上搜索信息、訪(fǎng)問(wèn)內部文檔以及從過(guò)去的錯誤中吸取教訓。它將繼續迭代任務(wù)，直到任務(wù)完成或卡住。這將針對 80% 的工作完成。
用于最困難任務(wù)的結對編程模式：人類(lèi)將在高層次上指導AI，而AI則處理低層次的實(shí)現細節。交互將是高度多模態(tài)的，人類(lèi)和AI在文本描述、視覺(jué)圖表、口頭討論之間流暢切換，并直接操縱彼此的代碼。我們可以共享屏幕并讓 AI 跟隨并為我們提供建議，或者AI可能會(huì )在我們提供編程指導時(shí)共享其屏幕！
AI 工程師將擁有我們所擁有的所有上下文和知識的完全訪(fǎng)問(wèn)權限：無(wú)論是自主操作還是與人類(lèi)結對工作，AI將連接到公司知識庫，可以訪(fǎng)問(wèn)設計文件和客戶(hù)訪(fǎng)談?dòng)涗洠?并將根據需要無(wú)縫提取這些信息以做出決策。AI將是積極主動(dòng)的，而不是諱莫如深的：如果你提出一個(gè)設計，它可能會(huì )顯示一個(gè)用戶(hù)訪(fǎng)談?dòng)涗洠?暗示一個(gè)更好的想法。
自主員工將派遣更便宜的子智能體（sub-agents）來(lái)完成其工作的簡(jiǎn)單和可預測的部分，主要是為了降低計算成本和延遲，就像我們可以瀏覽日志文件而不實(shí)際閱讀每個(gè)單詞一樣。
雖然很難預測未來(lái)的模型將如何表現，但我認為“AI工程師”在特定事情上會(huì )比大多數人類(lèi)工程師更聰明，但偶爾缺乏常識或需要重新關(guān)注和指導。老實(shí)說(shuō)，這與今天經(jīng)理和項目經(jīng)理與工程師合作的方式?jīng)]有太大區別！
我們還需要工程師嗎？
在計算器發(fā)明之前，會(huì )計師將大部分時(shí)間花在進(jìn)行計算上。計算器并沒(méi)有讓他們失業(yè)，只是讓他們在更高的抽象層次上思考。會(huì )計師仍然需要知道如何做數學(xué)運算和理解計算，但計算器和電子表格等工具使他們能夠提供比以前更多的價(jià)值！
我確實(shí)認為AI將降低任何人創(chuàng )建軟件的門(mén)檻，就像任何人都可以使用Excel進(jìn)行自己的個(gè)人會(huì )計一樣。這是一件好事！學(xué)生將在宿舍里啟動(dòng)完整的應用程序和業(yè)務(wù)；夫妻店將創(chuàng )建專(zhuān)為他們量身定制的軟件工具。我希望生活在這樣一個(gè)世界里，人們的創(chuàng )造力是他們創(chuàng )造的唯一瓶頸。
圖 8 我希望未來(lái)是什么樣子
人類(lèi)工程師不會(huì )消失。我們仍然需要推動(dòng)高層次的優(yōu)先級排序，了解問(wèn)題的整體架構和范圍，并審AI的工作，特別是隨著(zhù)系統變得越來(lái)越大。但是，我們會(huì )花更多的時(shí)間思考要構建什么，而較少的時(shí)間花在重復的“如何”構建上。我們最終將實(shí)現夢(mèng)想——只處理問(wèn)題的“固有復雜性”，而不是系統實(shí)施的“偶然復雜性”。
我已經(jīng)不在表演了，再次用雙手打字，但 Claude 仍在編寫(xiě)我的大部分代碼。總的來(lái)說(shuō)，我已經(jīng)弄清楚了如何充分利用這些新的AI工具，我對這個(gè)行業(yè)的發(fā)展方向非常樂(lè )觀(guān)！
