介紹
在一個上一篇文章，我寫了以下關於在開發我的新工具中使用 AI 的內容include-tidy(Tidy) 那個使用Libclang, 一個我以前從未使用過的圖書館：
什麼幫助了很多 正在使用人工智慧（嚴格來說，是一個大語言模型），具體是 Google 的 Gemini（因為我太窮了，付不起 Claude 的費用，特別是對於一個我沒有打算賺錢的個人專案）。雖然我可能會寫一篇後續的博客文章來描述我的經驗，但我會簡要地說明人工智慧讓我免於閱讀大量文件、閱讀教學教程、向郵件列表或 Stack Overflow 發布問題，以及等待答案（如果有的話）。
這就是之前提過的跟進博客文章。如果你已經使用 AI 一段時間了，以下內容很可能不會讓你感到意外。在使用 AI 進行 Tidy 之前，我只是用它來處理一些小功能或提出一些特殊情況下的問題。用 AI 進行 Tidy 是我第一次「大型」使用 AI。
若這是你第一次見到我的部落格或是我，你或許會想“這傢伙是誰，我為何要關心他的想法？”我已經對電腦愛好和專業地玩弄了超過四十年，。有些程式設計師，尤其是來自較舊世代的，對於人工智能相當懷疑——經常將其稱為「強化版的自動更正」。雖然這句話裡有技術上的真實成分，但仍然相當令人印象深刻。
訊息提示
雖然我認為「提示工程」這個詞及其相關的「提示工程師」這個頭銜都大大誇大了（後者大致等同於「衛生工程師」），但你需要是詳細且具體 — 就像你在Stack Overflow上提交問題時一樣。
與 Stack Overflow 不同，你無需因問過了相同問題或未閱讀常見問題解答而受責備；你也不會被問及為何要那樣做；你無法得到輕蔑的回答或評論；你無法不得到答案；而且你會在幾秒鐘內得到答案。
雖然聽起來都很好，但你得到的答案可能完全錯誤。有幾次，Gemini 建議我使用一個不存在的 API 函數。在我指出這一點後，它確實糾正了自己，然而。
此外，你得到的答案通常只基於你的 精確問題。如果你把使用 AI 視為像使用一個 猴子之爪，那可能會更好 以免你得到技術上符合你的要求，卻帶來意想不到的後果。
舉個例子，這是我第一次向 Gemini 設計 Tidy 的提示：
寫一個程式使用 clang 的 API，當給予一個 C 或 C++ 源檔案時，列印出每一個符號（巨集、常數、函數、型別、變數等），以及該符號宣告的檔案和行號，如果無法確定則列印 "unknown"。
並且它列印出幾個螢幕的 C 程式碼，顯示來自 Libclang 的哪個檔案#include, 需要呼叫哪些函式來初始化和清理 Libclang, 如何解析來源檔案並迭代其抽象語法樹(AST)。沒錯，我本可以準備好Libclang的。教學教程，但 Gemini 的回應是根據我想要做的事來調整的。
當然，它生成的程式遠遠未完成。它沒有處理命令列選項、設定檔、錯誤、彩色輸出，或是在分析 C 或 C++ 源檔時的所有邊緣情況。這些事情將在未來幾週內完成。但我已經有個良好的開始.
日常任務
使用 AI 的另一個好處是你可以讓它做那些你可以做，但不想被打擾，因為程式碼很無聊。例如，Tidy 需要先掃描命令列參數，尋找那些以...開頭的。-Xtidy要將它們分成兩個陣列：那些是 Tidy 特定的，那些應該原封不動地傳遞給 Libclang。這裡是我的提示：
給定
argc和argv為main在 C 程式碼中，有兩種選項：(1) 一種-Xtidy選項，那就是一個選項。-Xtidy在其前；以及（2）只是一個選項。"選項"可以是短選項或長選項。我想操縱
argc和argv以至所有之前有接的選項-Xtidy被分離出來成為獨立tiny_argv陣列以及tiny_argc留下argv被剝奪所有-Xtidy以及隨後的選項。
而且它 正確地完成了這件事，僅僅用了幾秒鐘，完全不需要我调试我寫代碼時必然出現的off-by-one錯誤。
經驗
如果你是經驗豐富的程式設計師，你就能看著產生的程式碼並快速判斷它是否正確。所以對於經驗豐富的程式設計師來說，AI 是一個非常棒的加速器；如果你是經驗不足的程式設計師（或者甚至不是程式設計師），那麼我猜你只能聽天由命了。
找錯誤
另一件你可以做的事，當你完成了一個特定的 .c 或者.cpp 檔案，上傳它並詢問，“你能找到這段程式碼中的任何錯誤嗎？” 而且它確實。當然你無法判斷它是否找到所有錯誤，所以你仍然應該撰寫單元測試和其他測試.
當然它可以報告偽陽性，就像它對我的c_chan 專案。它認為我使用某個互斥體的方式不對。無疑，這是一種非典型的互斥體使用方式，或許也會讓人類程式設計師感到困惑。但它也確實發現了一些其他真正的錯誤，包括未初始化的結構成員，並注意到一個 tv_nsec 結構的 timespec 結構成員 需要 需要在 0–999999999 的範圍內，所以我應該添加程式碼來檢查溢位。
AI 沒有做什麼
與許多程式碼庫一樣，大部分的程式碼並不直接參與到程式碼庫的主要目的是什麼。在 Tidy 的情況下：
- 只有 18% 的程式碼與掃描
#include指令以及將符號映射到包含檔案有關。 - 26% 只是「實用」程式碼（一些小型函數，讓編寫其餘程式碼更輕鬆）。
- 25% 只是用於解析設定檔（語法上解析TOML，語義上解釋它，檢查錯誤，打印出精確行和列的錯誤訊息）。
- 15% 用於通用數據結構（動態陣列，紅黑樹）。
- 9% 用於命令列解析。
- 8% 用於測試。
我用了AI來協助與 (不)寫) 使用 Libclang 寫程式碼，不是用於工具程式碼或設定檔，僅僅是命令列上的一點點（用來分割參數），而且不是用於測試。
影響
而我的這篇部落格的目的是僅僅描述我對於AI在軟體開發上的印象。me，我可能會在留言中被人問到，以為我對整體軟體開發的影響是什麼，所以我還不如現在就處理這件事。
雖然確實已經有許多關於AI的炒作，正如我所說，它幫助了我很多 配合 Tidy 使用。它對軟體開發來說是革命性的。在經驗豐富的程式設計師手中，它是一種加速器。由於我不再是一個缺乏經驗的程式設計師，我無法直接評論對缺乏經驗的程式設計師來說使用 AI 是什麼樣的。它很可能也是一種加速器，但缺乏經驗（或不具備）的程式設計師在看到錯誤或忽略安全的程式碼時無法察覺。絕對會有更多的數據洩露和訴訟。
你無疑聽說過（而且或許不幸地親身經歷過）科技公司的普遍裁員。正如我 所評論的，是的，確實進行了大量裁員，但我認為人工智能被用作替罪羊，讓CEO聽起來不無能，也讓公司聽起來沒有陷入困境。裁員的原因與以往一樣：
- 公司愚蠢地普遍超額招聘。
- 一個新的產品或服務沒有成功
- 公司正陷入財務困境
這些都讓CEO看起來無能為力。相反地，將責任歸咎於人工智能，反而讓CEO看起來精明，因為他同時採納了先進技術並削減開支——這兩者都受到華爾街的讚賞
此外，我還要補充一個裁員的原因。無能的CEO：
- 可能會實際上相信所有誇張之談並認為他們真的能夠取代開發者。
考慮以下情境。你是某科技公司執行長，該公司銷售一款旗艦軟體產品，擁有龐大的客戶群。公司內有100名開發人員。平均而言，每月新增一項新功能並修復10個錯誤。你希望每月能新增更多功能並修復更多錯誤，但無法負擔招聘更多開發人員的開銷。現在人工智能出現了，你有兩個選擇：
- 繼續每月增加一個新功能並修復 10 個錯誤，但開發人員和開銷更少.
- 使用 AI 作為加速器，以相同數量的開發人員，每月增加兩個甚至三個新功能並修復 30 個錯誤。
有什麼正常的CEO會選擇選項1，認為「我們對目前的發展速度感到滿意，客戶也一樣」？選項2會讓現有客戶更滿意，而且很可能更擅長吸引新客戶。確實，有一些研究支持這一點。
所以如果你受到裁員的影響，或許你可以得到一些安慰 (schadenfreude 在CEO無能的可能性下。
結論
人工智慧非常可能會持續存在。它明顯是開發者加速器。當然，將會有變動、收購，以及一些破產，因為，至少目前來說，運營人工智慧會大量流失資金。讓人工智慧 赚取利潤是另一回事。像 Google 這樣擁有替代性金絲雀（廣告）的龐大玩家可以無限期地資助人工智能；Anthropic 僅僅是剛剛開始獲利頭一次。不清楚他們是否會能夠。繼續要獲利。未來幾年將會證明。