標題：“AI 結對程式設計的 12 個教訓（180 天 AI 實踐，零炒作）”
已發布：真實
描述：“在實際開發中與 AI 編碼代理配對 180 天后，本文分享了 12 條實用經驗——哪些方法有效，哪些方法無效，以及如何真正讓 AI 在日常工作流程中發揮作用。從工具疲勞到程式碼信任問題，獲取你在營銷演示文稿中找不到的見解。”
標籤： webdev、程式設計、javascript、ai
經過六個月的日常 AI 結對編程，跨越多個程式碼庫，以下是真正發揮作用的方法。拋開炒作，這就是實際操作。
TL;DR
規劃與流程：
-
先寫一個計劃；在編碼之前讓人工智慧對其進行批評
-
使用編輯測試循環：寫失敗測試→AI 修復→重複
-
頻繁提交小的更改以獲得可讀的差異
快速工程：
-
保持提示簡短，具體上下文膨脹會降低準確性
-
在編寫程式碼之前要求逐步推理
-
使用檔案引用（@path/file.rs:42-88）而不是程式碼轉儲
情境管理：
-
在重大更改後重新索引您的專案以避免幻覺
-
使用 gitingest.com 等工具取得程式碼庫摘要
-
使用 Context7 MCP 與最新文件保持同步
-
將 AI 輸出視為初級開發人員的 PR；審查所有內容
無效的方法：
-
將整個程式碼庫轉儲到提示中
-
期望人工智慧理解隱含的要求
-
無需審查即可將安全關鍵程式碼託付給人工智慧
-
從書面計畫開始（認真地講，先做這個）
讓你的人工智慧為正在建構的功能起草一份 Markdown 計畫。然後完善它：
-
詢問有關邊緣情況的澄清問題
-
讓其批評自己的計畫是否有漏洞
-
重新產生改進版本
將最終計劃儲存為instructions.md ，並在每個提示中引用它。光是這一步就能避免 80% 的「AI 中途出錯」的情況。
真實範例：
Write a plan for adding rate limiting to our API. Include:
- Which endpoints need protection
- Storage mechanism for rate data
- Error responses and status codes
- Integration points with existing middleware
Now critique this plan. What did you miss?
-
掌握編輯-測驗循環
這是 TDD，但由 AI 來實現：
-
讓人工智慧寫一個能夠準確捕捉你想要的內容的失敗測試
-
自己檢查測試－確保測試正確的行為
-
然後告訴人工智慧：“讓這個測試通過”
-
讓人工智慧進行迭代——它可以自動執行測試並修復故障
關鍵在於實施前審查測試。糟糕的測試會導致程式碼無法滿足要求。
-
要求逐步推理
將其加入到您的提示中：
Explain your approach step-by-step before writing any code.您可以在錯誤的假設變成錯誤程式碼之前將其捕捉到。能夠「自發性思考」的人工智慧模式會減少犯下愚蠢的錯誤。
-
停止拋棄背景訊息，開始進行整理
大型專案會分散 AI 的注意力。解決方法如下：
使用 gitingest.com 取得程式碼庫摘要
-
前往 gitingest.com
-
輸入你的 repo URL（或將任何 GitHub URL 中的「github.com」替換為「gitingest.com」）
-
下載產生的文字摘要
-
引用此文件而不是複製貼上文件
無需將 10 個文件貼到提示中
執行以下操作：“查看附件的 codebase_summary.txt 以了解專案結構”
對於文件：使用 Context7 MCP 或 Live Docs 的替代方案
Context7 MCP 透過顯示文件的「最新頁面」使 AI 與最新文件保持同步。
何時使用：當您的文件頻繁更改時，請參考 MCP 連接，而不是每次都貼上過時的片段。
5.版本控制是你的安全網
-
使用
git add -p進行細微提交，使差異保持可讀性 -
永遠不要讓未提交的更改堆積如山：乾淨的 git 狀態可以更輕鬆地隔離 AI 引入的錯誤並乾淨地回滾
-
使用有意義的提交訊息：它們幫助 AI 理解變化背景
-
保持提示的聚焦
錯誤：“這是我的整個程式碼庫。為什麼身份驗證不起作用？”
正確做法：“當 JWT 格式錯誤時， @src/auth.rs第 85 行會因為None引發混亂。請修復此問題並加入適當的錯誤處理。”
具體的問題有具體的解決方案。模糊的問題會產生幻覺。
在提示中使用程式碼術語：引用程式碼庫中的準確標識符，而不是通用的商業術語。例如，呼叫createOrder()和processRefund()而不是“下訂單”或“發放退款”，或使用UserEntity而不是“帳戶”。這種精確性有助於 AI 應用正確的抽象，並避免領域語言和程式碼之間的不匹配。
🚀嘗試 AI Shell
>
您的智能編碼伴侶可無縫整合到您的工作流程中。
-
重大變更後重新索引
如果您使用具有專案索引的 AI 工具，請在進行重大重構後重建索引。過時的索引是 AI「找不到」確實存在的函數的原因。
大多數工具都會自動索引，但當出現問題時會強制刷新。
-
使用文件引用，而不是複製貼上
大多數 AI 編輯器都支援類似@src/database.rs引用。使用它們代替貼上程式碼塊。
好處：
-
AI 看到的是目前檔案狀態，而不是過時的快照
-
更少的 token 使用量 = 更高的準確率
-
減少提示混亂
注意：語法因工具而異（Forge 使用@ ，有些使用#等）
-
讓AI寫測試，但你寫規範
告訴人工智慧到底要測試什麼：
For the new `validate_email` function, write tests for:
- Valid email formats (basic cases)
- Invalid formats (no @, multiple @, empty string)
- Edge cases (very long domains, unicode characters)
- Return value format (should be Result<(), ValidationError>)一旦你指定了案例，AI 就擅長產生測試樣板。
-
使用診斷報告進行除錯
當遇到困難時，要求有系統地分解：
Generate a diagnostic report:
1. List all files modified in our last session
2. Explain the role of each file in the current feature
3. Identify why the current error is occurring
4. Propose 3 different debugging approaches這迫使人工智慧有系統地思考，而不是猜測和檢查。
-
設定清晰的樣式指南
給你的AI一個簡短的系統提示：
Code style rules:
- Use explicit error handling, no unwraps in production code
- Include docstrings for public functions
- Prefer composition over inheritance
- Keep functions under 50 lines
- Use `pretty_assertions` in test
- Be explicit about lifetimes in Rust
- Use `anyhow::Result` for error handling in services and repositories.
- Create domain errors using `thiserror`.
- Never implement `From` for converting domain errors, manually convert them一致的規則=一致的程式碼品質。
-
像高級工程師一樣審查一切
將每一次 AI 變更視為初級開發人員的 PR：
安全審查：
-
檢查注入漏洞
-
驗證輸入有效性
-
尋找硬編碼的秘密
績效考核：
-
觀察 N+1 查詢
-
檢查演算法複雜度
-
尋找不必要的分配
正確性審查：
-
手動測試邊緣情況
-
驗證錯誤處理
-
檢查是否有偏差一錯誤
AI 很聰明，但並非明智。你的經驗很重要。
什麼行不通（從我的錯誤中學習）
「魔法提示」謬誤
不存在完美的提示，能讓 AI 永不犯錯。更好的工作流程勝過更好的提示。
期待讀心術
人工智慧無法推斷你未提出的需求。 「使其投入生產」如果沒有具體細節，就毫無意義。
信任人工智慧的架構決策
AI 擅長實現你的設計，但在高級系統設計方面卻很糟糕。你負責架構，AI 負責實現。
忽略特定領域的上下文
除非您告知，否則 AI 不會知道您的業務邏輯、部署約束或團隊約定。
爭議觀點：AI 結對程式設計比人類結對程式設計更好
對於大多數實施任務。
人工智慧不會疲倦，沒有自我，不會爭論程式碼風格，也不會評判你的谷歌搜尋習慣。它就像一個擁有無限耐心和完美記憶力的初級開發人員。
但它也無法捕捉邏輯錯誤，無法理解業務背景，也無法抵抗糟糕的想法。棘手的事情還是需要人類來解決。
最終現實檢驗
AI 程式設計工具可以顯著提升生產力，但前提是你必須有系統地使用它們。那些獲得巨大利益的工程師並非依靠神奇的提示，而是依靠規範的工作流程。
首先制定計劃，測試一切，像你的生產系統依賴它一樣進行審查（因為確實如此），並記住：人工智慧是你的實習生，而不是你的架構師。
編碼的未來並非人類與人工智慧的對決，而是擁有人工智慧的人類與沒有人工智慧的人類的對決。請明智地選擇你的陣營。
原文出處：https://dev.to/forgecode/12-lessons-from-ai-pair-programming-180-days-with-ai-zero-hype-2ijh
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式