梯子整個下午都壞了，感覺與世界脫節。

最先進的一批AI模型寫的程式碼不差，模組級別遠超人類程式設計師的平均水平，寫出來的爛程式碼先看看選的什麼模型，上下文是不是充分，提示詞是不是要優化。 跨模組的程式碼，受限於上下文窗口長度，可能需要人類輔助設計規劃一下，如果專案結構合理，AI一樣可以重用現有程式碼保持DRY。

仔細想了一下，AI之所以寫代碼爛，不是因為他不會寫，而是因為他不會讀。人會因為做一個feature去看很多表面上不相關的東西，但是正是這些看起來毫不相關的東西給你提供了讓項目保持DRY的可能。AI要能成為頂樑柱，必須先學會這個不可 🤪

別提菩薩了。 如果你在野外快餓死了...看到路邊墳墓上的供品。你鞠躬說："抱歉，我快餓死了，可以拿一個供品來吃嗎？" 我不認為任何人或任何鬼會為難你...

怎麼感覺AI工程研究越來越偏向語言哲學了？

深以為然：1. 多智能體並行協作不如單線程穩定； 2. RAG 不可靠還不如傳統檢索；3. 提示詞裡面的指令越多模型越不知道該怎麼選。 ——原推翻譯如下—— 在構建 AI 智能體（AI Agent）的道路上，我們團隊 @Cline 識別出了三種“思維病毒”。所謂“思維病毒”，就是那些聽起來很高明，但在實踐中卻壓根兒行不通的誘人想法。 這三種病毒是： * 多智能體協作 (Multi-Agent Orchestration) * 檢索增強生成 (RAG) * 指令越多 = 效果越好 讓我們來一探究竟！ 1. 多智能體協作 那種科幻電影裡的場景——“後方智能體、軍需智能體、分析智能體、指揮智能體”分派出一大群子智能體，最後再將結果彙總起來——聽起來確實很酷。但現實是，絕大多數有用的智能體工作都是單線程的。 複雜的協作流程很少能帶來真正的價值，反而常常製造混亂。要知道，僅僅是讓模型在單線程裡穩定工作就已經夠難的了，更別提去處理那些並行的協作邏輯了。這不僅增加了實現的複雜度，更讓模型的理解和決策過程變得異常複雜。 2. 用 RAG 來構建智能體 RAG，即檢索增強生成 (Retrieval Augmented Generation)，也是一種思維病毒。它在理論上看起來很強大，但在實踐中，尤其是在智能體場景下，有時候連 GREP 這種基礎的文本搜索命令都比它好用。 為什麼 RAG 的光環在實際的智能體工作流中會褪色？因為它檢索到的信息往往是零散的片段，無法讓模型形成一個連貫、有用的“理解”。 更好的方法幾乎總是：讓模型自己去列出文件，用類似 grep 的方式進行搜索，然後打開並閱讀整個文件（就像人類一樣）。@Cline 團隊很早就開始這麼做了，後來我們看到 @Amp — Research Preview 和 @Cursor 也都轉向了這種更務實的方法。 3. 指令越多 = 效果越好 有一個流傳很廣的誤解：在系統提示詞 (system prompt) 裡堆砌越來越多的“指令”，就能讓模型變得更聰明。這完全是錯的。 給提示詞“注水”只會讓模型感到困惑，因為更多的指令往往會導致建議相互衝突和信息過載。 結果就是，你不得不像玩“打地鼠”遊戲一樣，不停地修補模型的各種奇怪行為，而不是得到真正有用的輸出。對於如今大多數前沿模型而言，最好的方法是別擋它們的路，而不是在旁邊不停地大喊大叫，試圖把它們引向某個特定的方向。請珍惜你的每一個字（或者說 Token）。 總而言之，以上這三種想法都極具誘惑力。如果你不是整天和 AI 打交道，你可能會覺得它們都非常有道理——然而事實並非如此。當然，隨著底層模型能力的提升，我們對這些方法的看法未來也可能會改變。