在實施氣象站系統時，我問自己：如果我用人工智慧重新建構它，會怎麼樣？
我的想法是比較同一個專案分別用兩種方法實現的效果。人工智慧開發真的像宣傳的那麼快嗎？程式碼品質如何？使用人工智慧時我會面臨同樣的挑戰嗎？身為開發者，我的感受會更好還是更糟？
在本文中，我將盡可能誠實地解釋我是如何再次使用人工智慧來建立我的天氣監測系統的，以及我的感受。
實驗背景
組成部分
-
感測器讀取器：一個 Python 程序，用於讀取感測器的天氣資料、顯示當前讀數並將資料發送到 Web 應用程式。
-
Web 應用程式：儀錶板和 API ：一個 PHP + Symfony Web 應用程式，用於接收來自氣象站的資料並在儀表板中顯示。
人工智慧設定
我不想花錢使用人工智慧，所以我嘗試了Gemini 、 OpenRouter和Ollama的免費套餐，也嘗試了本地部署。但是 Gemini 和 OpenRouter 的令牌消耗太快，而 Ollama 在我的電腦上運作不正常。
所以，在同事的推薦下，我最後使用了OpenCode及其預設模型：Big Pickle。
我必須說，無論最終結果如何，效果都相當不錯。
原始碼
您可以在這裡查看兩種方法的源程式碼：
-
感測器讀取器
-
Web應用程式
重寫方法
的確，重建專案時無需反覆試驗，因為你清楚自己想要什麼。為了彌補這一優勢，我嘗試忽略那些「手工」專案的存在，同時扮演一個「憑感覺編程」的人，也就是說，我只希望它能執行，而無需編寫任何程式碼，也無需關心它是如何建置的。
花費時間
我透過給每次提交程式碼的時間分配 2 小時來衡量所花費的時間。
| 專案 | 非人工智慧 | 人工智慧 |
|-----------|:-----------:|:-----------:|
|感測器讀取器| 42小時 | 14小時 |
| Web應用| 28小時 | 12小時 |
“哇！使用人工智慧速度提升了四倍！！”
但現實情況是，在開發過程中，由於沒有人工智慧，我不得不學習Python以及Pimoroni庫的工作原理。此外，我對程式碼結構也沒有清晰的思路。在學習如何應用Python最佳程式設計實作的過程中，我多次重構程式碼。
另一個需要考慮的因素是我在兩種方法中如何使用版本控制系統。使用 AI 時，我的提交次數比不使用時少，原因如下：
-
如果沒有人工智慧，我會踏出我認為可以接受的每一小步。
-
使用 AI 時，我提交的請求數量較少，但每次提交的請求量更大，因為我需要等待整個功能正常運作。
關於Web應用程式專案，我大約花了16個小時完成。剩下的時間，直到28個小時，我都在反覆迭代，思考我想看到哪些統計天氣資料以及當前值，以及如何展示這些資訊。我直接應用了先前為非AI方法確定的解決方案，並使用了人工智慧技術。
考慮到這一點，以及作為一名憑感覺編寫程式碼的人，我沒有花時間審查程式碼，我的「直覺」告訴我，這些數字可能並不像看起來那麼令人印象深刻。
程式碼品質
我使用 SonarQube 獲取了一些關於程式碼品質的指標，例如可維護性、安全性、可靠性和程式碼重複率。使用 AI 是否更好？讓我們拭目以待。
感測器讀取器
這個非人工智慧專案因為沒有遵循snake_case命名規範而出現了 45 個可維護性問題。我決定採用駝峰命名法，可能是因為我主要從事 Java 和 PHP 開發。對我來說，這並不是問題，所以我將它們標記為誤報。
我還修復了Weather Hat 顯示類別中的一些問題，因為它只是 Pimoroni 範例的封裝副本。我只做了一些修改，使其成為DisplayInterface的實作。
考慮到這一點，以下是未使用人工智慧的結果：
這就是人工智慧帶來的結果：
AI 專案出現的不可靠性問題是factory.py檔案中的一個無用賦值造成的。
在我看來，沒有人工智慧的品質似乎更好，但確實沒有太大的區別。
關於複雜性和技術債，這就是結果。
| | 非人工智慧 | 人工智慧 |
|-----------|:-----------:|:-----------:|
|環路複雜度| 72 | 87 |
|認知複雜度| 19 | 87 |
技術債| 50分鐘 | 7分鐘 |
AI 程式碼更難理解（87 行 vs 19 行），但由於我 Python 知識不足，非 AI 專案的技術債更高。 Python 中沒有介面的概念，而我處理得也不對。
Web應用程式
結果非常相似，但人工智慧方法存在 3.6% 的重複程式碼。
複雜性和技術債結果如下：
| | 非人工智慧 | 人工智慧 |
|-----------|:-----------:|:-----------:|
|環路複雜度| 70 | 72 |
認知複雜度| 10 | 16 |
|技術債| 30分鐘 | 1小時43分鐘 |
在這些指標上，人工智慧顯然更差，技術債是原來的三倍多，程式碼也更難理解。
發展經驗
我對人工智慧的使用感受很複雜。一方面，它能用簡單的需求實現如此強大的功能，令我驚嘆不已；另一方面，我又感到不知所措，對最終結果也頗有疑慮。
人工智慧在幾個重要方面都遇到了困難，最後我必須解釋問題出在哪裡，因為它無法找到解決方案。
在感測器讀取器專案中，AI錯誤地應用了溫度偏移量。它沒有在讀取感測器之前將偏移量值傳遞給Pimoroni庫，而是在讀取溫度之後才應用了該值。因此，相對濕度值出現了錯誤。經過多次迭代，我告訴AI結果有誤並要求它查閱Pimoroni文件後，最終不得不向AI解釋如何解決這個問題。
我在網路應用程式中遇到了幾個身份驗證問題：
-
第一次執行，用戶身份驗證失敗。人工智慧不得不接連修復多個問題：404 和 500 錯誤、登入表單無限循環存取等等。在其中一個迭代中，人工智慧建議我移除登入表單中的 CSRF 令牌！
-
在身份驗證問題解決後，註銷功能卻無法正常運作，由於人工智慧無法實現，我不得不自己實現註銷功能。
-
引入 JWT 身份驗證後，AI 移除了基於使用者會話的身份驗證！
-
AI 無法使 JWT 身份驗證與基於會話的身份驗證協同工作。它多次堅持認為問題出在 Apache Web 伺服器的配置上。但實際上，問題就出在專案需要在 Apache Web 伺服器上執行的設定。最終，我不得不自己動手解決這個問題。
這非常令人沮喪，有好幾次我都氣得不行。
SDD（規範驅動開發）體驗也令人沮喪。
自然語言本質上是不精確的。真正的開發者能夠運用自身的判斷力和領域知識來填補規範文件中的空白。而人工智慧則只會憑空想像。為了盡可能避免這種情況，編寫規範時必須極為精確。而且，恕我直言，這遠比寫程式碼複雜得多。
最後，我決定讓AI一步一步地完成這些操作，而不是直接告訴它使用規範文件。
結論
人工智慧有助於解決一些有限的任務和問題，例如尋找錯誤、實作介面或連接到端點。但要根據規範文件建立整個專案則完全是另一回事。任務有限時，程式碼審查比較容易，對結果也更容易承擔責任。但如果要審查大量程式碼，我就感覺到對最終結果的掌控力下降了。
別誤會，人工智慧是個好工具，非常棒，但你還是需要會寫程式碼。而我所知的唯一提升人工智慧使用技巧的方法，就是繼續自己解決問題。
關鍵在於找出哪些問題應該由我們自己解決，哪些問題可以委託給人工智慧解決。
原文出處：https://dev.to/nandofm/ai-vs-non-ai-building-the-same-project-twice-4073
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
