小編精選 - 技術文章翻譯 · 05月07日

AI 不是笨，是你的設定有問題。🛠️

標題：人工智慧並不笨，笨的是你的設定。 🛠️

已發布：是

描述：最基本的 AI 編碼工作流程——選擇正確的模型，先做好計劃，為智能體而不是人類編寫 AGENTS.md，並在指責工具之前在 LLM 之間進行交叉檢查。

標籤：人工智慧、智能體、生產力、教程

封面圖：https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8ddakzjuqx24c2ayunsn.jpg

我最近聽到的言論通常是這樣的：“我試用了[本周流行的智能體]，結果一團糟。人工智慧被高估了。”

我的回答是：「不。你讓你的修車工蓋房子，卻忘了提供藍圖。」🦄

問題不在於代理，而在於設定。以下是真正有效的流程。這套流程並不高明，而且我花在學習上的時間比我願意承認的要長得多。

選擇適合任務的型號。性能比感覺更重要。 🪛

Haiku 就像短跑運動員一樣，它會毫不猶豫地嘗試建立你的分散式系統架構——只是最終給出的方案可能無法直接交付。你的任務是找到與實際工作相符的模型。

如果問題定義明確——規範清晰、驗收標準明確、邊界情況列舉清楚——Sonnet 就能很好地處理。雖然評審時間會更長，但能真正省錢。此外，你還能更快發現自身規範的缺陷，這本身就是一大優勢。

如果這個功能錯綜複雜，你無法（或不願意）將其分解，那也沒關係。直接把整個工程交給 Opus 就行了。你不必逐一分析每個子問題，但你必須定義整個解決方案。「讓它能運作」並不是一個合理的要求——這只是一個代理無法理解的無奈願望。

價格低廉但配置出色的機型，每次都能勝過價格昂貴但氛圍和感覺不錯的機型。

在聊天中製定計畫。最後再修改程式碼庫。 🪞

在程式碼庫中出現任何字元之前，我都會花上好幾個小時——真的好幾個小時——來討論問題。人工智慧就像我的橡皮鴨/研究助手，它有點個性——沒錯，我把它加進程式碼裡，因為那些煩人的讚譽會分散我的注意力，讓我偏離目標：制定一個完善的計劃。

語言？無所謂。我都能看懂（雖然我可能不會）。套件管理器？我更不在乎——只要在根目錄下放個 Makefile 文件，指令就都一樣了。時間軸？有時候會考慮，但答案通常是「昨天」。真正重要的是：

有意義的技術堆疊
預期結果
驗收標準
測試場景——陽性、陰性、錯誤、臨界、異常、已發現
明確的非目標（你不會去建造的東西，這樣它們就不會被偷偷地建構出來）

跳過這些步驟，直接提示「給我做一個東西」？你確實會得到一個東西，但它不會是你想要的那種。

只接受一個權威來源。停止抄襲指令。 🪧

AGENTS.md 、 copilot-instructions 、 CLAUDE.md 、 GEMINI.md任選其一。我以AGENTS.md作為權威文件，然後在其他文件中加入指向它的單行 Markdown 連結。這樣就只需要管理一個文件，而不是四個。

如果一條規則在所有情況下都成立——無論是對你這個操作員還是對整個專案——它就不應該被放在技能裡。技能會在觸發時被呼叫，而指令則會始終載入。你需要知道你真正需要的是哪一個，並據此使用。我專門寫了一篇部落格文章來深入探討這個概念，如果你想了解更多，可以去看看。

模型應該在執行過程中維護AGENTS.md檔案—無需單獨建立MEMORY.md檔案來混淆視聽。當模型反覆違反同一條規則時，不要加入新的規則，而是直接修改它。如果你詢問，你的代理程式會準確地知道它在哪裡出錯，並且它已經知道如何修復它。

要為經紀人寫作，而不是為讀者寫作。 🪶

如果使用預設設置，模型會將你的說明編寫成一份詳細的新使用者培訓文件。包含章節標題、友善的介紹以及「本文件概述…」等語句。這些文字寫得文采斐然，卻根本不會有人閱讀。

每回合指令都會根據上下文載入。每個字都會消耗代幣，並影響指示的清晰度。因此，請針對實際受眾—您的代理人—進行最佳化。

直截了當地說：

僅供人工智慧閱讀——不考慮人類可理解的框架和敘事流程。
保留每一個有意義的細節。精煉文字，但切勿偏離主題。
刪除重複項。如果兩條規則表達的是同一個意思，但表述方式不同，則合併它們。
消除歧義。「嘗試」和「考慮」都是乾擾項－直接說出所需內容。
剔除所有可從合理程式碼修改推斷出的內容。如果 grep 指令能給出答案，那就刪掉它。

一份精心編寫的新使用者引導文件相當於你發送的每個提示訊息都要繳納一筆稅。與其每次都重複支付，不如在編寫文件時一次性支付。

💡專業提示：這些說明應該成為一項技能，因為代理商只會在更新AGENTS.md時使用它們。

技能並非魔法。請明確地稱呼它們。 🪄

技能的設計初衷是可以自動觸發——沒錯。理論上是這樣……或者說，如果技能描述與提示足夠契合，而且恰好是星期二行星連珠的話。如果你必須使用某個技能，那就必須在提示中明確指出。否則，你就是在碰運氣。

請不要因為技能名稱聽起來有趣就盲目地從應用程式商店安裝所有技能。如果您記不清技能的確切名稱，請將其刪除（並做好備份）。使用技能建立工具記錄您實際運作的工作流程。其他的就別管了。輸入垃圾，輸出的也是垃圾。

在本地安裝 MCP。全域變數會佔用每個提示符號的資源。 🪺

在全球範圍內啟用 20 個 MCP 對您來說很方便，但對您的代理商來說卻是一場上下文污染的噩夢。每個連接的 MCP 都會消耗令牌。

問題很簡單：我是否在所有地方、所有時間都使用它？如果是，那麼全域安裝是合適的。如果不是——而通常答案是否定的——那麼只需將其安裝在真正需要的五個專案中即可。符號連結和絕對路徑可以解決重複安裝的問題。只需確保代理程式有權存取該目錄即可。

不要複習，直接測試，然後再測試一次。 🩻

我不再逐行審查人工智慧產生的程式碼了。我做得不好，速度慢，而且讀到第三個文件時就眼花撩亂了。正確的做法是進行測試——廣泛、頻繁地測試，並且在程式碼停止執行的那一刻就進行測試。而不是三天後你提交 PR 時才進行測試。

單元測試、整合測試、端對端測試、效能測試、無障礙測試、Sonar 測試、Semgrep 測試等等。然後使用 GitHub Actions 實現自動化執行。確保模型涵蓋正向路徑、負向路徑、錯誤路徑、邊界狀況以及你在規劃階段定義的驗收標準。（你確實定義了這些標準，對吧？）將你在測試過程中發現的任何問題都明確地加入到模型中，以避免再次發生。

然後進行模型間的交叉驗證。讓 Codex 測試 Claude 模型，然後讓 Copilot 測試 Codex 模型。每個模型都有不同的盲點和關注點——在控制劑量下進行對比測試本身就是驗證。一個 LLM 模型是單點故障，三個模型則足以確保結果的可靠性。