自從 2022 年 AI 程式設計開始流行以來，我一直對它持懷疑態度。後來，我改變了主意：我不再手動編寫大部分程式碼，而是讓 AI 產生 90% 的程式碼。說實話，我喜歡這種速度。

2023 年，我使用 ChatGPT 產生了大約 40% 的程式碼。這種體驗令人沮喪。我花在向 ChatGPT 解釋程式碼庫的時間比實際編寫程式碼的時間還多。LLMs (LLM) 給出的解決方案幾乎無法適應我的專案結構。我主要複製貼上樣板程式碼並調整數值。

然而，ChatGPT 在後端工作方面表現出色。當我建立我的第一個 Python 套件drf-api-key時，ChatGPT 處理了大約 60% 的工作。它搞清楚了 Fernet 加密，合理地建立了程式碼結構，為我節省了數小時的研究時間。

真正的突破發生在我八個月的休假期間，當時我發現了Cursor 。我接觸了這個工具，它幫助我快速建立了樣板化的啟動後端並處理了基礎設施工作。最初的那些體驗感覺就像魔法一樣。

Cursor 能夠以 ChatGPT 無法企及的方式理解現有程式碼庫。它可以讀取模式、保持一致性，並真正改進程式碼，而不僅僅是產生程式碼。

但即使是 Cursor 也有局限性。它難以相容於較新的框架，也無法存取更新的文件（現在Context7已經可以實現這一點）。我仍然會手動編寫配置，因為 Cursor 會產生完全錯誤的設定。

然後到了2024年11月。 MCP伺服器上線，Anthropic改進了他們的編碼模型，Claude Code問世， Gemini 2.5也確實非常有效率。現在我90%的程式碼都來自AI，而且我已經找到了除了寫函數之外的其他使用方法。

如果您尚未充分利用 AI 進行編碼，那麼您應該從以下方面開始。

在我們深入探討之前，我想先說一下：我寫的文章主要涉及 AI 輔助開發、產品建置和軟體工程。如果您想了解更多類似的內容，請訂閱我的電子報。

人工智慧編碼感覺像魔術，但你就是魔術師

在使用人工智慧進行編碼並觀察其他開發人員為此苦苦掙扎的 12 個月後，我意識到了一些令人不安的事情：你在人工智慧編碼方面的經驗反映了你作為軟體工程師的實際水平。

我不僅僅談論你的編碼技能。我談論的是一切：

• 如果你沒有條理，你給人工智慧的指令就不會起作用。人工智慧會產生垃圾，因為你的要求是垃圾。

• 如果你不了解自己的程式碼庫，就無法引導人工智慧保持一致性。你得到的只是孤立執行的程式碼，卻破壞了其他一切。

• 如果你忽略了準備和規劃，AI 就會完美地建構出錯誤的東西。你會浪費數小時去除錯那些你從未正確定義過的問題的解決方案。

• 如果您沒有耐心並且想要立即得到結果，那麼您會在第一次提示失敗後就放棄，而不是反覆尋找正確的解決方案。

• 如果您的程式碼審查習慣較差，您就會發送 AI 生成的錯誤，因為您認為 AI 做對了。

一開始我靠「魔眼」打轉，以為AI應該知道我想要什麼。結果卻讓我很沮喪。我申請LLMs的時候，結果平平無奇，然後就怪罪工具。

現實情況：AI 代理就像初級開發人員，速度極快，但需要明確的方向。你不會告訴初級開發人員「讓這個功能實現」然後就走人。你會解釋程式碼庫，向他們展示模式，並提出具體要求。

80/20 規則在這裡完美適用。軟體工程通常 80% 的準備工作，20% 的編碼工作。大多數開發人員會跳過準備工作，直接跳到提示。然後他們就會懷疑為什麼 AI 會產生垃圾程式碼。

我的工作流程正好相反：我使用人工智慧來幫助完成 80%（規劃），這使得 20%（編碼）變得微不足道。

當我接到一個任務時，我不會直接開始寫程式碼。我會讓人工智慧參與準備階段。我會給它關於問題、程式碼庫和約束條件的背景資訊。然後，我會讓它幫我起草一份詳細的計劃，幫我思考具體方法。

我請代理商幫我起草詳細的產品需求文件 (PRD)。我不用自己寫 PRD，而是向代理商提供背景訊息，然後由代理商制定計劃。這迫使我思考我真正需要什麼，而代理商會以一種讓實施變得顯而易見的方式組織它。

我的工作流程：

1. 向代理商提供您的票證描述、Figma 設計和文件。

2. 讓其起草PRD和實施計劃。

3. 共同審查並完善計劃。

4. 讓代理人做飯，並重複工作。

在準備階段，你其實是在扮演魔術師的角色。你要教導人工智慧你需要什麼、如何思考、什麼是好的。之後的編碼幾乎就變成機械式的了。

改變我一切的工具

我目前的 AI 編碼堆疊：

游標

我的主要編碼環境。它擅長理解大型現有程式碼庫。

我使用 Claude Sonnet 4.5進行實際編碼，使用 Gemini 2.5 Pro 進行 PRD 起草或除錯複雜問題。 Cursor 在某些方面表現不佳，例如跨多個檔案的大規模重構，它可以修改程式碼，但並非總是考慮更廣泛的架構影響。

MCP 伺服器

這是 2025 年的遊戲規則改變者。 MCP（模型上下文協定）將LLM連接到外部工具和 API，賦予它們超越文字生成的真正能力。

我的 MCP 設定：

• Figma MCP - 代理直接讀取設計並了解元件結構。

• Context7 - 讓代理可以存取任何框架的最新文件。

• AWS CloudWatch、Sentry、Resend - 用於基礎設施監控和通知。

克勞德·科德

它負責基礎設施和部署工作。

我在專案根目錄中儲存了一個CLAUDE.md文件，它定義了我的基礎架構標準和部署工作流程。文件頂部如下所示：

# Deployment Workflow
- Create timestamped database backup in /root/.backups-db/
- Pull latest changes from git (main branch)  
- Rebuild and restart Docker containers
- Run Django migrations and collect static files
- Verify all containers are healthy and services respond

## Critical Rules
- Never expose secrets in code or commits
- Always backup before deployment
- Use placeholders in documentation

當我部署時，Claude Code 會讀取這個檔案並嚴格遵循工作流程。它會備份資料庫、部署必要的更新、執行健康檢查，並透過電子郵件向我發送報告。

我還設定了一個 cron 任務，每 6 小時執行一次健康檢查。整個可觀察性管道由 Claude 程式碼和 Markdown 指令管理。

人工智慧的優勢（以及劣勢）

後端：人工智慧的最佳點

LLM 非常擅長處理後端開發。 API、資料庫模式、業務邏輯：這些都是具有清晰模式的結構化問題，而這正是 AI 的優勢所在。

關鍵在於為你的 AI 代理提供關於程式碼庫的完整上下文。記錄你的模式、程式碼標準和架構決策。當代理商理解你的專案結構時，它就能在各個功能之間保持一致性。

對於集成，我將 API 文件提供給我的編碼代理。它會讀取文件，理解身份驗證流程，並實現整合。如果供應商提供 MCP 伺服器（例如 Sentry），代理可以直接研究實作模式。否則，Context7 會允許代理程式存取任何框架的文件。

注意事項

務必檢查代理程式產生的內容。它可能會建立可以執行但無法擴展的程式碼，或者在未設定明確約束的情況下過度設計簡單的任務。

告訴代理該做什麼，更重要的是，不該做什麼。否則，它們往往會變得過於複雜，並產生不必要的解決方案。具體說明你的限制：“使用現有的身份驗證中間件，不要建立新的”，或“控制在 50 行以內”。

前端：很棒，但還不夠好

人工智慧的前端開發很複雜。我現在的前端編碼速度提高了 5 倍，但編寫不可維護程式碼的風險也更高了。

我的方法

我從小處著手。我讓代理建立單一元件，而不是整個功能。建立一個按鈕元件，了解它的工作原理，然後將其組合成更大的結構。

對於複雜的功能，我使用 Figma 的 MCP 伺服器為代理提供視覺上下文。但不要指望它能從一張截圖理解完整的設計系統。應該將設計分解成元件，然後逐一實現。

帶有 AI 的前端比後端需要更多迭代。您需要仔細檢查產生的程式碼，並根據需要不斷優化提示。如果這聽起來很繁瑣，請堅持手動建立元件。

基礎建設：出奇的強大

這最讓我驚訝。 AI代理在基礎設施任務方面表現出色。

當我使用 Claude Code 或 Cursor 建立 VPC、配置安全性群組或編寫 CloudFormation 範本時，它們比我手動操作更能準確完成所有細節。基礎架構非常複雜，即使是經驗豐富的工程師也很少能一次部署成功。

我實際建造的東西

自動交易系統（7小時）

我從2018年開始研究市場走勢，最近還參加了演算法交易的課程。演算法交易的真正工作是製定自己的策略：理解指標、回測參數，並找到在真實市場中真正有效的策略。這需要數月的專注學習。

但我不會等六個月才開始交易。

我的方法如下：首先建立基礎設施（資金管理、執行、監控），使用第三方訊號作為訓練輪，然後在開發完成後換入我自己的演算法。

手動建立交易基礎設施的問題在於：整合數量之多。 Telegram API、訊息解析、 MetaAPI執行、電子郵件監控、資料庫追蹤以及部署自動化。每一項可能需要數天才能正確實施。

借助人工智慧，我花了7個小時就完成了所有搭建。現在，在系統執行外部訊號的同時，我還可以研究技術指標並制定自己的策略。準備好後，我只需插入我的演算法，整個基礎設施就已經經過了實戰檢驗。

我現在正在建立無聊的部分，以便我可以專注於有趣的部分：實際的交易策略。

它的作用：

• 讀取來自交易頻道的電報訊息。

• 使用 OpenAI 代理程式將訊號解析為我想要的格式。

• 執行前驗證交易。

• 透過 MetaAPI 自動進行交易。

• 監控部位並調整停損/獲利水準。

• 每 6 小時發送一次健康報告。

人工智慧如何提供協助

Cursor 在幾個小時內建立了 Django 後端（PostgreSQL + Celery）。我提供了架構文件和需求，它產生了 API、資料庫模型和後台任務。

Claude Code 負責部署和監控。我有一個 cron 任務來執行健康檢查：

claude --dangerously-skip-permissions --print "Perform a health check for the trading application and send an email report. Read /root/MONITORING_EMAIL_PROMPT.md to understand the format and information required. Use the sender email [email protected] and recipient [email protected]. Important: Approve all file read operations and email sending automatically."

以下是我收到的電子郵件範例：

Claude Code 會閱讀監控指令，檢查系統狀態，並透過電子郵件向我發送詳細報告。整個可觀察性流程無需人工幹預即可運作。

我甚至在Gram上搭建了一個 MCP 伺服器。我只需要我的 OpenAPI 文件，其中包含我想要公開的端點，Gram 就會產生 MCP 伺服器。

現在我可以直接從 Claude Desktop 監控或進行交易。

我必須解決的問題

讓 Claude Code 處理部署帶來了一些有趣的問題。我使用 Telethon 接收來自 Telegram 的訊號，這會建立一個會話檔案。每次部署時，該檔案都會被刪除，導致我的 cron 作業在嘗試讀取訊息時失敗。

原來是 Claude Code 清理了文件以保持乾淨狀態。除錯它花了大約一個小時。我的解決方案是：將會話檔案移出專案目錄，然後在容器建置時複製進去。

我遇到的其他問題：

• 幻象函數： Cursor 偽造了不存在的驗證函數。我不得不強制它讀取 Context7 的實際文件並修復它。

• 錯誤的環境配置： Claude 在生產環境中設定了USE_SQLITE=true ，所以我的資料被寫入檔案而不是 PostgreSQL。還好，我在每次部署前都執行了備份，並恢復了資料。

MCP 配置產生器（45 分鐘）

我建立了很多 MCP 伺服器，並且厭倦了手動為不同的工具編寫設定檔。

我把 MCP 規格和我寫的設定範例交給了 Cursor。它產生了一個工具，可以輸出我需要的任何 MCP 伺服器的有效配置。這 45 分鐘的工作量讓我每次啟動新專案時都能節省 15-20 分鐘。

我從不違反規則

我把人工智慧運用到各方面：建構技術寫作的POC、開發後端和前端，以及部署基礎架構。以下是我始終遵循的兩條規則：

規則 1：深入了解專案、程式碼庫和需求

如果你不知道自己要去哪裡，就無法給予正確的方向。人工智慧代理會增強你的理解力，但不會取代它。如果你不了解你的架構，你的程式碼代理就會產生今天能用，明天就崩潰的程式碼。

規則 2：永遠不要授予 AI 代理破壞性權限

我配置了 IAM 策略，以便我的編碼代理可以建立和更新資源，但絕不會刪除它們。當出現問題時（這種情況肯定會發生），代理人會先嘗試幾種解決方案。但多次嘗試失敗後，它會預設使用最核心的選項：刪除並重新建立。這就是資料遺失的原因。

我有一個例外：為了實現基礎設施自動化，伺服器上需要 sudo 存取權限。這雖然有風險，但對於部署腳本來說卻是必要的。不過，在生產環境中，我從來不會這麼做，因為在生產環境中我會建立特定的使用者角色並定義權限。

最後的想法

寫程式碼從來都不是我在軟體工程中最喜歡的一部分。我真正在意的是解決問題。人工智慧讓我可以花更多時間在這上面，而不是在樣板程式碼上浪費時間。

我花了7個小時建立一個交易系統，如果手動操作的話，這得花上幾週時間。現在，我把時間都花在完善策略上，而不是除錯Django模型。這就是人工智慧程式設計真正帶給你的好處：減少繁瑣的工作，更專注於真正重要的事情。

選一個你一直拖延的事情，因為它感覺設定工作太多了。讓人工智慧產生結構，然後把它變成你自己的。你很快就會明白人工智慧的優勢所在，以及你需要介入的地方。工具就在這裡。問題在於你是否願意改變你的工作方式。

如果您已經使用 AI 編寫了大部分程式碼，請在評論中分享您的經驗：您的方法、工具以及您學到的知識。

如果您喜歡這篇文章並希望獲得更多類似的見解，請訂閱我的時事通訊，每週都會將提示、教學和故事直接發送到您的收件匣！

資源

本文提到的工具：

• Cursor－人工智慧程式碼編輯器。

• Claude Code – 與 Claude 一起實現基礎設施自動化。

• Context7 ——AI 代理程式的文件存取。

• MCP 協定－模型上下文協定規範。

• Gram – MCP 伺服器託管。

延伸閱讀：

• Gareth Dwyer 撰寫的《Claude Code Is All You Need》 ——深入探討基礎設施自動化。

• MCP 快速入門指南– 開始使用 MCP 伺服器。

• 人擇提示工程指南－編寫更好的提示。

原文出處：https://dev.to/koladev/i-think-you-should-let-ai-write-your-code-2jgj