Agent 寫代碼，經驗分享

作者：Peter Steinberger

原文：https://steipete.me/posts/just-talk-to-it

最近我在這兒比較安靜，因為我正埋頭于最新項目。Agentic 工程已經強大到幾乎 100% 的代碼都由它代寫。可我卻看到很多人還在繞彎子、搞花活，而不是把事辦成。

這篇文章部分靈感來自昨晚在倫敦的 Claude Code Anonymous[1] 上的交流，部分則是因為 距離我上次更新工作流已經過去整整一個“AI 年”[2] 了，是時候做個回顧。

所有核心理念依然適用，所以我不會再贅述像上下文管理這類基礎內容。請先閱讀我的 《最佳 AI 工作流》文章[3]作為入門。

上下文與技術棧

我獨自開發，當前項目是一個約 30 萬行 TypeScript React 代碼庫，包括一個 Chrome 擴展、一個 CLI、一個基于 Tauri 的客戶端應用，以及一個用 Expo 開發的移動應用。網站托管在 Vercel，每次 PR 大約 2 分鐘即可部署新版本供測試；其余（應用等）尚未自動化。

使用方式與總體思路

我已完全把codexcli 當作主力工具，每天同時跑 3–8 個實例，排列成 3×3 的終端網格；大多數放在同一目錄[4] ，部分實驗則另開文件夾。我試過 worktrees、PR 等方式，最終都回到這套配置，因為它最快出結果。

我的 agents 自己會做 git 原子提交[5] 。為了保持相對干凈的提交歷史，我對 agent 文件[6]迭代了很多次，這讓 git 操作更精準，每個 agent 只提交它改過的文件。

沒錯，Claude 可以用 hooks，而 codex 暫時還不支持；但模型極其聰明，只要它們鐵了心， 任何 hook 都攔不住[7] 。

我以前被嘲笑，被稱為垃圾生成器[8] ，很高興看到并行代理慢慢成為主流[9] 。

模型選擇器

我幾乎用 gpt-5-codex 的中等配置構建所有東西。它在智能和速度之間是很好的折中，并且會自動調整思考深度。我發現過度糾結這些設置并不會帶來有意義的結果，不用操心_超思考_也挺好。

爆炸半徑

工作時，我總會考慮“爆炸半徑”。這個詞不是我發明的，但我非常喜歡。想到一個改動時，我大致能判斷它會耗時多久、會動到多少文件。我可以往代碼庫里扔很多“小炸彈”，也可以扔一顆“胖子”再補幾個小的。如果同時扔多顆大炸彈，就無法做隔離提交，一旦出錯也更難回退。

觀察 agent 時，這也是個好指標。如果耗時超出預期，我直接按 Esc，問一句“進度如何”，拿到狀態后再決定幫模型找準方向、中止還是繼續。別怕中途打斷，文件變更是原子的，它們很擅長從斷點續上。

拿不準影響范圍時，我會用“先給我幾個方案再動手”來評估。

為什么不用 worktrees？

我只跑一個開發服務器，隨著項目演進，我會點來點去，一次驗證多處改動。如果每個改動都建分支/樹，速度會慢很多；開多個 dev server 也很快讓人抓狂。Twitter OAuth 還有域名限制，我只能注冊少數幾個回調域名。

那 Claude Code 呢？

我曾經很愛 Claude Code，現在完全受不了（ 盡管 codex 是它的粉絲[10] ）。它的語氣、那種 “絕對正確”[11]、測試全掛卻告訴你“100% 生產就緒”的口吻——我真的受夠了。Codex 更像內向的工程師，默默推進，把事情搞定。它開工前會讀更多文件，所以哪怕提示很短，通常也能一次到位。

我時間線上幾乎所有人都認同：codex 才是正道[12] 。[13]

Codex 的其他優勢

• 約 23 萬可用上下文，對比 Claude 的 15.6 萬。沒錯，如果你運氣好或愿意按 API 價付費，也能用到 Sonnet 1M，但現實是 Claude 在耗盡上下文前早就“犯傻”了，根本沒法真正利用那么長的窗口。

• 更高效的 token 利用率。不知道 OpenAI 做了什么優化，但我的上下文消耗速度遠慢于 Claude Code。以前用 Claude 時經?？匆姟罢趬嚎s…”，換成 Codex 后幾乎沒撐爆過上下文。

• 消息隊列。Codex 支持 排隊發消息 [14] 。Claude 原本也有，但幾個月前他們改成讓新消息“引導”模型。如果想引導 Codex，我只需按 Esc 再回車就能發新消息。兩種模式任選顯然更好。我常把相關功能任務排成隊列，它總能穩定地一件件完成。

• 速度OpenAI 用 Rust 重寫了 Codex，效果立竿見影——快到離譜。用 Claude Code 時，我經常遇到幾秒卡頓，進程內存直接飆到 GB 級，終端還狂閃，尤其是 Ghostty。Codex 完全沒有這些毛病，輕盈又迅捷。

• 語言。這對我的心理健康真的很重要。 [15] 我曾無數次對著 Claude 咆哮，卻很少對 Codex 發火。哪怕 Codex 模型差一點，單憑這點我也會選它。兩者各用幾周，你自會明白。

• 不會再有隨機 Markdown 文件到處躺尸 [16] 。 懂的都懂 [17] 。

在我看來，最終用戶和模型公司之間幾乎沒有中間地帶。我用訂閱制最劃算。目前我有 4 個 OpenAI 訂閱和 1 個 Anthropic 訂閱，每月總共約 1k 美元，基本無限 token。如果用 API 調用，費用大概貴 10 倍。別跟我摳數學，我用過 ccusage 這類 token 計數工具，數據都不精確，但就算只貴 5 倍也是血賺。

我喜歡 amp、Factory 這類工具，只是不看好它們能長期存活。codex 和 claude code 每次更新都在進步，功能和思路越來越趨同。也許某家在待辦列表、引導或輕微 dx 特性上暫時領先，但我不認為它們能顯著跑贏大型 AI 公司。

amp 已經不再把 GPT-5 當作主推模型，現在把它稱為 “oracle”[18]。與此同時，我用的是 codex，基本上一直在和這個更聰明的模型——oracle——并肩工作。 當然有基準測試[19] ，但鑒于使用數據嚴重偏斜，我并不相信那些結果。codex 給我的效果遠比 amp 好。不過 session 共享這點我得給他們點贊，他們確實在推進一些有趣的想法。

工廠，還是不信。他們的視頻有點尷尬，不過我的時間線上確實有不少好評，盡管還不支持圖片，而且帶有標志性的閃爍[20] 。

Cursor 的 Tab 補全模型在業界領先，前提是你還親自寫代碼。我主要用 VS Code，但挺欣賞他們在瀏覽器自動化和計劃模式上的推進。我確實試過 GPT-5-Pro，可 Cursor 那些五月就煩過我的老 bug 還在[21] 。聽說在修，所以我把它留在 Dock 里。

像 Auggie 這樣的工具在我時間線上只冒了個泡，之后再沒人提起。歸根結底，它們都不過是套了 GPT-5 和/或 Sonnet 的殼，隨時可換。RAG 對 Sonnet 或許有用，但 GPT-5 的檢索能力太強，根本沒必要再給代碼建獨立向量索引。

最有盼頭的是 opencode 和 crush，尤其是搭配開源模型。你完全可以用自己的 OpenAI 或 Anthropic 訂閱（ 靠點小技巧[22] ），不過這么做是否合規存疑，而且把為 Codex 或 Claude Code 優化的模型塞進一個更弱的套殼里，意義何在？

那 $openmodel呢？

我一直關注中國的開源模型，它們追趕的速度令人驚嘆。GLM 4.6 和 Kimi K2.1 都是強有力的競爭者，正逐步逼近 Sonnet 3.7 的水準，不過我依然不把它們當作日常主力[23] 。

基準測試只能說明一半。在我看來，智能體工程在五月隨著 Sonnet 4.0 的發布，從“這玩意兒不行”躍升到“這還不錯”；而 gpt-5-codex 的出現，則讓我們從“不錯”直接飛躍到“這也太神了”。

規劃模式與方法

基準測試忽略了“模型+測試框架”在收到提示時所采取的策略。Codex 遠比其他模型謹慎，在決定行動前會讀取倉庫中的更多文件。 當你提出一個愚蠢請求時，它會更有力地反駁。[24] Claude 等智能體則急切得多，先隨便試_點什么_再說。這可以通過規劃模式和嚴格的結構化文檔來緩解，但對我來說這像是在給破系統打補丁。

我現在幾乎不用大規劃文件與 Codex 協作。Codex 甚至沒有專門的規劃模式——但它對提示的遵從度高得多，我只需寫“我們先討論”或“給我幾個選項”，它就會耐心等我拍板，不需要任何測試框架的花招。直接跟它說話就行。

但 Claude Code 現在有了插件[25]

你聽到遠處那聲嘆息了嗎？是我。真是一坨大寫的廢話。這讓我對 Anthropic 的重心徹底失望。他們試圖用插件給模型的低效打補丁。沒錯，為特定任務維護好文檔是明智之舉——我在 docs 文件夾里放了一大摞有用的 Markdown 文檔。

可是子代理啊！??！

但關于這場子代理的整段舞蹈，總得說兩句。早在五月，它還叫子任務，主要是一種在模型不需要全文時把任務甩到獨立上下文里的做法——核心目的是并行化，或減少像嘈雜構建腳本這類場景的上下文浪費。后來他們重新包裝并升級為子代理，于是你帶著幾條指令就能優雅地甩出一個任務。

使用場景沒變。別人用子代理做的事，我通常靠開幾個獨立窗口搞定。如果我想研究點什么，就在另一個終端面板里做完，再貼到另一個面板。這樣我能完全掌控并看見我所設計的上下文，而子代理卻讓你更難查看、引導或控制回傳的內容。

我們還得聊聊 Anthropic 在博客中推薦的那個子代理?？纯催@個 “AI 工程師”代理[26] 。它是一鍋大雜燴，提到 GPT-4o 和 o1 的集成，整體就像自動生成的詞語濃湯，努力裝作有意義。里面沒有任何實質內容能讓你的代理成為更優秀的“AI 工程師”。

這到底是什么意思？如果你想得到更好的輸出，告訴模型“你是一名專注于生產級 LLM 應用的 AI 工程師”并不會改變什么。給它文檔、示例和“做/不做”清單才有用。我打賭，如果你讓 agent 去“Google AI agent 構建最佳實踐”并讓它加載一些網站，效果會比這堆廢話好得多。你甚至可以說這種垃圾就是上下文毒藥[27] 。

我如何寫提示

當初用 claude 時，我（當然沒有， 我說話[28] ）會寫非常冗長的提示，因為這個模型“懂我”，我給的上下文越多越準。雖然對任何模型都成立，但我發現用 codex 后提示詞明顯變短了。往往只有一兩句話+ 一張圖[29] 。這模型讀代碼庫的能力驚人，直接就能 get 到我。我有時甚至回歸打字，因為 codex 理解所需的上下文實在太少了。

添加圖片是一個絕佳的技巧，可以提供更多上下文，模型非常擅長精準定位你展示的內容，它能找到字符串并匹配，直接抵達你提到的地方。我敢說，至少 50% 的提示里都有截圖。我很少做標注，那樣效果更好，但速度較慢。把截圖拖進終端只需 2 秒。

帶語義修正的 Wispr Flow[30] 依然是王者。

基于網頁的 Agent

最近我又折騰了一番網頁 Agent：Devin、Cursor 和 Codex。Google 的 Jules 看起來不錯，但配置過程實在煩人，而且 Gemini 2.5 現在已經算不上好模型了。等 Gemini 3 Pro[31] 發布，情況可能會迅速改變。唯一留下來的是 codex web。它同樣難配置且問題多多，目前終端加載不正常[32] ，但我用了一份舊環境鏡像，總算跑了起來，代價是啟動更慢。

我用 Codex Web 當臨時問題跟蹤器。出門在外想到什么，就在 iOS 應用里丟一句話，回頭在 Mac 上統一處理。當然，我完全可以做更多，甚至直接在手機上審閱/合并，但我選擇不。工作已經夠上癮了，出門或見朋友時我不想再被拉進去。嘿，這話出自一個花了快兩個月做工具、只為讓手機寫代碼更方便[33]的人。

Codex Web 原本不計入用量上限，但這種好日子已經屈指可數[34] 。

智能體之旅

聊聊工具。Conductor[35]、Terragon[36]、Sculptor[37]，還有上千個同類。有的是興趣項目，有的泡在 VC 的錢海里。我試了一大堆，沒有一個留下。在我看來，它們都在繞開當下的低效，并推行一種并不最優的工作流。更別提，大多數把終端藏起來，不讓用戶看到模型輸出的全部內容。

大多數只是 Anthropic SDK 的薄殼 + 工作樹管理，沒有護城河。我甚至懷疑你是否真的想在手機上更方便地調用編程智能體。它們帶給我的那點用例，codex web 已完全覆蓋。

我確實注意到一個模式：幾乎每位工程師都會經歷一段“造自己的工具”的階段，大多因為好玩，也因為現在做起來太容易了。除了造那些（我們以為）能讓以后造工具更簡單的工具，還能造什么呢？

但 Claude Code 支持后臺任務！

沒錯。codex 目前確實少了些 Claude 的花哨功能，最痛的缺失是后臺任務管理。雖然它該有超時機制，但我已多次遇到 CLI 任務卡住的情況，比如啟動 dev server 或陷入死鎖的測試。

這就是我又轉回 Claude 的原因之一，但鑒于該模型在其他方面實在蠢得離譜，我現在用 `tmux`[38]。這是個老工具，可在后臺持久會話里跑 CLI，模型里也有充足的世界知識，所以你只需“用 tmux 跑”。無需定制 agent md 的瞎折騰。

那 MCP 呢

關于 MCP，別人已經寫了很多。在我看來，大多數只是給市場部打勾炫耀用的。幾乎所有 MCP 其實就該是 CLI。說這話的人， 我自己就寫了 5 個 MCP[39]。

我可以直接通過名稱調用 CLI，無需在 agents 文件里寫任何說明。代理第一次調用時會隨便敲個 $randomcrap，CLI 會彈出幫助菜單，于是上下文立刻就掌握了全部用法，之后一路順暢。不像 MCP 那樣持續燒錢、把垃圾塞進上下文，我無需為任何工具付費。用 GitHub 的 MCP，一次就燒掉 23k token——他們后來優化過，剛上線時差點 50k。換成ghCLI，功能幾乎一樣，模型本來就會用，上下文稅為零。

我把部分 CLI 工具開源了，比如 bslog[40] 和 inngest[41]。

我現在用 `chrome-devtools-mcp`[42] 來閉環[43] ，它已取代 Playwright 成為我調試網頁的首選 MCP。雖然用得不多，但真要用時，它能很好地閉環。我給自己的網站做了設計：可以生成 API Key，讓模型通過 curl 查詢任意端點，幾乎所有場景下都更快、更省 token，所以連這個 MCP 也不是天天需要。

但代碼就是一坨屎！

我大約把 20% 的時間[44]花在重構上。當然，這些全由智能體完成，我可不會手動浪費時間。重構日非常適合在我精力不足或疲憊時進行，因為無需太多專注或清晰思考也能取得顯著進展。

典型的重構工作包括：用jscpd查重、用 `knip`[45] 清理死代碼、跑eslint的react-compiler和廢棄插件、檢查能否合并新引入的 API 路由、維護文檔、拆分過大的文件、為棘手部分補測試和注釋、更新依賴、 升級工具鏈[46] 、調整目錄結構、找出并重寫慢測試、引入現代 React 模式并重寫代碼（例如你可能不需要 `useEffect`[47]）?？傆惺虑榭勺?。

你可以說這些應該在每次提交時就做，但我發現“快速迭代→維護改進”這種階段式節奏——也就是償還技術債——反而更高效，也更有趣。

你采用“先寫規格再開發”嗎？

我六月份還這么做[48] 。先設計一份大規格，然后讓模型照著敲代碼，最好一口氣跑幾個小時。在我看來，這已經是老派的軟件開發思路了。

現在我通常直接跟 Codex 開聊：把網頁、點子貼進去，讓它讀代碼，我們一起把新功能揉出來。如果邏輯比較繞，我就讓它把所有內容寫成一份規格，扔給 GPT-5-Pro 審一遍（通過 chatgpt.com），看看有沒有更好的主意（出乎意料地，計劃常常因此大幅改進！），再把我覺得有用的部分貼回主上下文，更新文件。

到現在，我對哪些任務需要多少上下文已經心里有數，而 codex 的上下文容量相當不錯，所以我常常直接開干。有些人很“虔誠”，每次都清空上下文重新規劃——我覺得這對 Sonnet 有用，但 GPT-5 處理大上下文強得多，那樣做反而每次得多花 10 分鐘，讓模型慢慢把構建功能所需的文件重新拉一遍。

更有趣的做法是做 UI 相關的工作時，我往往從極其簡單、嚴重缺需求的請求開始，看著模型實時構建、瀏覽器同步刷新。接著我把后續改動排隊進去，持續迭代功能。很多時候我根本不確定最終該長什么樣，這樣就能邊玩邊試，看著它慢慢成形。我常見 codex 做出我壓根沒想到的有趣效果；我不重置，只是不斷迭代，把混沌一點點捏成我覺得對的樣子。

構建過程中，我常會蹦出相關交互的靈感，順手把別的部分也改了；這部分我交給另一個 agent 處理。通常我主攻一個核心功能，再捎帶幾個沾邊的小任務。

我一邊寫這篇文章，一邊在 Chrome 擴展里新建 Twitter 數據導入器，為此我重構了 graphql 導入器。因為不確定方案是否合適，我把它放在獨立文件夾，方便提 PR 時回頭審視。主倉庫在做重構，所以我能專心寫這篇文章。

讓我看看你的斜杠命令！

我只有幾個，而且很少用：

• /commit（自定義提示，說明多個 agent 在同一目錄工作，只需提交你的改動，這樣我就能得到干凈的提交信息，gpt 不會因為其他改動而崩潰，也不會在 linter 報錯時試圖回滾）

• /automerge（一次處理一個 PR，回應機器人評論、回復，讓 CI 變綠，并在變綠后 squash）

• /massageprs（與 automerge 相同，只是不 squash，這樣如果 PR 很多，我可以并行處理）

• /review（內置，偶爾用，因為 GitHub 上已有 review 機器人，但有時仍有用）

即便有了這些，我通常還是只打“commit”；除非明知臟文件太多，不給點提示代理可能會搞砸。當我確信這幾個字就夠了，就不必再玩花樣/浪費上下文。你會慢慢培養出直覺。我還沒見過其他真正有用的命令。

你還有哪些別的技巧？

與其絞盡腦汁寫出完美提示來驅動 Agent 完成長時間任務，不如用“懶人方案”。做大重構時，Codex 經常半路就停下來。如果你想走開等結果， **直接連發幾條“繼續”消息**[49]即可。Codex 完成后若再收到消息， 它會愉快地無視[50] 。

讓模型在每個功能/修復完成后立刻寫測試，用同一份上下文。這樣測試質量會高得多，還能揪出實現里的 bug。純 UI 微調就沒必要寫測試，其他情況都建議寫。AI 寫測試普遍一般，但聊勝于無——說實話，你自己會給每個小修復都補測試嗎？

讓模型保留你的意圖，并“在復雜處加注釋”，對你和未來的模型運行都有好處。

當遇到難題時，只需提示并加入一些觸發詞，如“慢慢來”“全面”“閱讀所有可能相關的代碼”“提出可能的假設”，就能讓 Codex 解決最棘手的問題。

你的 Agents/Claude 文件長什么樣？

我有一個 Agents.md 文件，通過符號鏈接指向 claude.md，因為 Anthropic 決定不做標準化。我知道這很別扭，也不理想，畢竟 GPT-5 偏好的提示方式[51] 與 Claude 差異很大。如果你還沒讀過它們的提示指南，現在先停下來去讀。

Claude 對 全大寫尖叫命令 [52] 反應良好——比如威脅它“如果執行命令 X 就意味著徹底失敗，100 只小貓會死”——但 GPT-5 會被嚇到（理所當然）。所以把這些都扔掉，像人類一樣說話。這也意味著這些文件無法最優共享。但對我不是問題，因為我主要用 Codex，并接受在極少數讓 Claude 上場時，指令可能偏弱。

我的 Agent 文件目前約有 800 行，感覺像是一堆組織留下的“疤痕”。不是我寫的，是 Codex 寫的；每當發生什么事，我就讓它在里面添一句簡明備注。我遲早得清理，但盡管龐大，它卻出奇地好用，GPT 也確實大多會遵從里面的條目——至少比 Claude 靠譜得多。（給點面子的話，Sonnet 4.5 在這方面有進步。）

除了 git 指令，它還包含對我的產品的說明、我偏好的命名和 API 模式、關于 React Compiler 的筆記——往往是我用的技術棧太前沿，超出了模型世界知識范圍的東西。我預計隨著模型更新，又能精簡不少。例如，Sonnet 4.0 得靠我指點才能理解 Tailwind 4，而 Sonnet 4.5 和 GPT-5 已經內置了這部分知識，于是我把那些廢話全刪了。

重點部分包括我偏好的 React 模式、數據庫遷移管理、測試、 使用并編寫 ast-grep 規則[53] 。（如果你不了解或沒用過 ast-grep 作為代碼庫檢查工具，請先暫停，讓你的模型把它配置成 Git 鉤子以阻止提交。）

我也嘗試過并開始使用基于文本的“設計系統”[54] 來規范外觀，目前尚無定論。

所以 GPT-5-Codex 就完美了？

當然不是。有時候它會重構半小時，然后崩潰[55]并全部回退，你得像哄小孩一樣重新運行并安撫它，告訴它時間足夠。有時它會忘了自己還能執行 bash 命令[56] ，需要一點鼓勵。有時它會用俄語或韓語[57]回復。 有時這家伙一滑，把原始思考發給了 bash。[58] 但總的來說這些情況相當罕見，它在其他方面簡直好得離譜，所以我可以忽略這些小毛病。人類也不完美。

我對 codex 最大的煩惱是它“丟”行，快速往上滾時部分內容會消失。我真希望這排在 OpenAI 的 bug 清單首位，因為它是我有時不得不放慢速度、以免消息消失的主要原因。

結論

別把時間浪費在 RAG、子代理、Agents 2.0[59] 這類多半只是噱頭的玩意兒上。直接跟它聊，玩起來，培養直覺。你跟代理打得越多，結果就越好。

Simon Willison 的文章說得極是[60] ——管理代理所需的很多技能，跟管理工程師[61]差不多——幾乎全是資深軟件工程師的特質。

沒錯， 寫好軟件依舊很難[62] 。我不再手寫代碼，不代表我就不再深入思考架構、系統設計、依賴、功能，或者怎樣讓用戶驚喜。用 AI 只是意味著大家對交付的期望值更高了。

PS：這篇文章 100% 有機手寫。我熱愛 AI，也承認有些事還是老派[63]來得好。保留錯別字，保留我的聲音。??[64]

參考資料

Claude Code Anonymous: https://x.com/christianklotz/status/1977866496001867925

距離我上次更新工作流已經過去整整一個“AI 年”: https://x.com/pmddomingos/status/1976399060052607469

《最佳 AI 工作流》文章: https://steipete.me/posts/2025/optimal-ai-development-workflow

放在同一目錄: https://x.com/steipete/status/1977771686176174352

[5]

原子提交: https://x.com/steipete/status/1977498385172050258

[6]

agent 文件: https://gist.github.com/steipete/d3b9db3fa8eb1d1a692b7656217d8655

[7]

任何 hook 都攔不住: https://x.com/steipete/status/1977119589860601950

[8]

垃圾生成器: https://x.com/weberwongwong/status/1975749583079694398

[9]

慢慢成為主流: https://x.com/steipete/status/1976353767705457005

[10]

盡管 codex 是它的粉絲: https://x.com/steipete/status/1977072732136521836

[11]

“絕對正確”: https://x.com/vtahowe/status/1976709116425871772

[12]

codex 才是正道: https://x.com/s_streichsbier/status/1974334735829905648

[13]

。: https://x.com/kimmonismus/status/1976404152541680038

[14]

排隊發消息: https://x.com/steipete/status/1978099041884897517

[15]

這對我的心理健康真的很重要。: https://x.com/steipete/status/1975297275242160395

[16]

不會再有隨機 Markdown 文件到處躺尸: https://x.com/steipete/status/1977466373363437914

[17]

懂的都懂: https://x.com/deepfates/status/1975604489634914326

“oracle”: https://ampcode.com/news/gpt-5-oracle

當然有基準測試: https://x.com/btibor91/status/1976299256383250780

標志性的閃爍: https://x.com/badlogicgames/status/1977103325192667323

[21]

Cursor 那些五月就煩過我的老 bug 還在: https://x.com/steipete/status/1976226900516209035

[22]

靠點小技巧: https://x.com/steipete/status/1977286197375647870

[23]

日常主力: https://x.com/imfeat7/status/1977246145278583258

[24]

當你提出一個愚蠢請求時，它會更有力地反駁。: https://x.com/thsottiaux/status/1975565380388299112

[25]

插件: https://www.anthropic.com/news/claude-code-plugins

[26]

“AI 工程師”代理: https://github.com/wshobson/agents/blob/main/plugins/llm-application-dev/agents/ai-engineer.md

[27]

上下文毒藥: https://x.com/IanIsSoAwesome/status/1976662563699245358

[28]

我說話: https://x.com/steipete/status/1978104202820812905

[29]

一張圖: https://x.com/steipete/status/1977175451408990379

[30]

Wispr Flow: https://wisprflow.ai/

[31]

Gemini 3 Pro: https://x.com/cannn064/status/1973415142302830878

[32]

加載不正常: https://x.com/steipete/status/1974798735055192524

[33]

花了快兩個月做工具、只為讓手機寫代碼更方便: https://steipete.me/posts/2025/vibetunnel-first-anniversary

[34]

這種好日子已經屈指可數: https://x.com/steipete/status/1976292221390553236

[35]

Conductor: https://conductor.build/

[36]

Terragon: https://www.terragonlabs.com/

[37]

Sculptor: https://x.com/steipete/status/1973132707707113691

[38]

tmux: https://x.com/steipete/status/1977745596380279006

[39]

我自己就寫了 5 個 MCP: https://github.com/steipete/claude-code-mcp

[40]

bslog: https://github.com/steipete/bslog

[41]

inngest: https://github.com/steipete/inngest

[42]

chrome-devtools-mcp: https://developer.chrome.com/blog/chrome-devtools-mcp

[43]

來閉環: https://x.com/steipete/status/1977762275302789197

[44]

20% 的時間: https://x.com/steipete/status/1976985959242907656

[45]

knip: https://knip.dev/

[46]

升級工具鏈: https://x.com/steipete/status/1977472427354632326

[47]

你可能不需要useEffect: https://react.dev/learn/you-might-not-need-an-effect

[48]

我六月份還這么做: https://steipete.me/posts/2025/the-future-of-vibe-coding

[49]

直接連發幾條“繼續”消息: https://x.com/steipete/status/1978099041884897517

[50]

它會愉快地無視: https://x.com/steipete/status/1978111714685063640

[51]

GPT-5 偏好的提示方式: https://cookbook.openai.com/examples/gpt-5/gpt-5_prompting_guide

[52]

全大寫尖叫命令 : https://x.com/Altimor/status/1975752110164578576

[53]

使用并編寫 ast-grep 規則: https://x.com/steipete/status/1963411717192651154

[54]

基于文本的“設計系統”: https://x.com/steipete/status/1973838406099874130

[55]

崩潰: https://x.com/steipete/status/1973834765737603103

[56]

bash 命令: https://x.com/steipete/status/1977695411436392588

[57]

用俄語或韓語: https://x.com/steipete/status/1976207732534300940

[58]

有時這家伙一滑，把原始思考發給了 bash。: https://x.com/steipete/status/1974108054984798729

[59]

Agents 2.0: https://x.com/steipete/status/1977660298367766766

[60]

Simon Willison 的文章說得極是: https://simonwillison.net/2025/Oct/7/vibe-engineering/

[61]

管理工程師: https://x.com/lukasz_app/status/1974424549635826120

[62]

寫好軟件依舊很難: https://x.com/svpino/status/1977396812999688371

[63]

老派: https://x.com/Alphafox78/status/1975679120898965947

[64]

??: https://x.com/rohanpaul_ai/status/1977005259567595959