工程師不擅長下提示

Theo Browne 是產品工程師，也是 T3 Code 代理客戶端的開發者。他主張工程師把提示過度工程化，卻低估了代理現有的能力——使用者要求的多數「功能」，其實只是可以開口問到的資訊。本集前半談這套提示論，用 T3 Code 的實機示範展示代理如何按需求產出工具呼叫稽核、上下文視窗視覺化工具與子代理編排；後半談這套思維帶回產品工程後會改變什麼：一個除錯工具從數千行程式碼縮到五行程式碼加一份 markdown 操作手冊，以及把電子郵件等資料來源接進代理的理由。

Browne 的立論基礎，來自他每天實際發布 T3 Code、親自稽核自己的代理對話紀錄；他也明白表示，自己在這套做法上仍處於早期階段。讀者讀完應該帶走三樣東西：一套具體的心智模型，判斷何時該動手開發、何時該用提示解決；一組有名有姓的例項（T3 triage、上下文視覺化工具、Codex 電腦操作能力清單）；以及 Browne 對「AI 讓人腦腐化」批評的回應——值得解的工程問題變得更深，而不是更淺。

多數功能需求該用提示解決，而不是做成功能

Browne 的核心主張是：工程師被困在「工程框架」裡，總以為要從工具得到某樣東西，工具就得把它做成功能。代理打破了這個假設，因為使用者口中的功能，很多其實是資訊，而資訊只要開口問就能取得。他謹慎地把這定位為對過度工程的批評，而不是鼓吹多做提示工程——他一開場就乾脆否定「提示工程」的炒作：「對，那些全是垃圾。」

用來舉例的軼事，是他和一位剛透過 Y Combinator 創業的朋友的對話。Browne 提到，他稽核 Claude 的工具呼叫後發現，在他自己的 Linux 機器與 Mac 上失敗率偏高，原因是 Claude 寫出的 ripgrep 指令用了 bash 相容的語法與換行格式，被 zsh 拒絕。朋友說，他早就希望 T3 Code 有個功能，能拆解工具呼叫的耗時，好找出最慢的指令來最佳化環境。Browne 回答：「我們早就有了」——連手機 App 都有。他接著當場示範：開一個新討論串，在「ultra fast」模式下選 GPT-6 Astra，貼上需求，拿回一份報告。其中一次家目錄搜尋跑了 41.7 分鐘，另一次也跑了將近 10 分鐘。

同樣的模式也生出一個上下文視窗視覺化工具。Browne 要 T3 Code 拆解目前討論串的上下文用量，並「做個好看的視覺化工具」，結果就拿到了。他指出這個示範之所以確定可行，是因為他前一天才跑過，並發現 Railway 代理設定錯誤，讓他每一次請求都被塞進 70,000 個 Token 的上下文——而他大約兩個月都沒察覺。T3 Code 確實有上下文用量按鈕，但藏在一個舊版旗標後面；他的結論是，使用者根本不該需要手動管理上下文。

Browne 也自我檢討。他一直在做一個替代儀錶板，用來管理所有進行中的工作——列出每項任務的狀態，並配一個代理，能重新命名討論串、關閉討論串、合併 PR，還能建議 40 個討論串裡哪 20 個該合併、哪 20 個該關閉、其餘該怎麼重新分類。他為每個動作不斷加按鈕。後來他領悟：「我可以為人們所有想用的方式把這些全做出來，或者，我可以把它變成一個聊天」——一個能連到他各環境中每一個 T3 Code 例項的元討論串，你只要開口要儀錶板，它就幫你建一個。

「我們習慣了要工具裡先有這個功能，才能從工具得到這個東西，但現在我們只要開口問就有，這非常不一樣。」

底下的經濟邏輯是：有些東西原本永遠不值得開發，但對某一個人當下卻有獨特價值；一旦取得成本崩跌，人們就會做得多得多。Browne 舉的例子包括：為了想通單一 bug 而做的視覺化工具，以及一個把他聽音樂的資料和 Last.fm 舊播放紀錄合在一起的個人平臺。

子代理的選擇靠提示，不靠設定下拉選單

有使用者要求 T3 Code 在編排層加上子代理模型選擇器，Browne 用反例回應：選子代理的是模型本身，所以你直接告訴它就好。他示範切到 GPT-6 Soul（依逐字稿）的中快速模式，要它開兩個 Opus 5.5 代理去探索 T3 Code 的效能改善空間、彙整發現，再開一個新討論串用 Grok 4.7 實作——還能選擇要在哪臺機器上跑。Codex 訂閱啟動了工作，兩個 Claude Code 例項在討論串裡執行，最後帶著結果開了一個新討論串。

他對「重複的提示何時該變成基礎設施」的判準是：當你發現自己一遍又一遍講同一件事，那就是該調整 skills 和你的代理或 Claude.md 檔案的時機——而不是在那之前。

最好的除錯工具是五行程式碼加 30 行 markdown

Browne 最有力的產品例子是 npx t3 triage，這是 T3 CLI 內建的診斷工具，刻意放在終端機裡，這樣即使桌面 App 開不起來也能用。他原本預期要做一個精巧的 doctor 式功能，從 T3 Code 的每個角落蒐集資料。它實際做的事是：把一段提示送進 Claude Code 或 Codex（由使用者選擇執行框架），讓模型自己跑完整個流程。

那段提示要代理扮演支援工程師：請使用者用自己的話描述出了什麼問題、直接請對方提供截圖、描述含糊時追問、讀取匯出的機器資訊、檢查有沒有更新的操作手冊（公開連結，因為 T3 Code 是開源專案）、clone 原始碼找 bug、查上游有沒有修正，最後提出處理方式——必要時開 GitHub issue，先移除機密資訊，而且重複問題優先留言而不是另開新 issue。

Browne 原本一直想讓 T3 triage 支援貼上圖片，好把圖片正確分流，後來才想到：直接讓 Claude 或 Codex 請使用者貼圖就好。他歸納出的通則是：很多流程太動態、分支和缺口太多，不適合做成複雜功能；而且如果他早就知道 T3 Code 所有可能的失敗方式，他早就全部修好，根本不需要這個工具。

| 做法 | 預估規模 | 失效模式 |
|---|---|---|
| 精巧的 T3 triage 功能，含分階段問答流程與圖片分流 | 數千行程式碼 | 涵蓋不了未知的失效模式；App 開不起來時就失效 |
| 把提示送進 Claude Code 或 Codex，搭配 markdown 操作手冊 | 約 5 行程式碼 + 約 30 行 markdown | 使用者必須先裝好執行框架 |

問代理它會什麼，再補它缺的基礎元件

Browne 把代理自己的上下文視窗當成產品情報來源。為了規劃 T3 Code 的電腦操作功能，他要 ChatGPT Codex 桌面 App「詳細描述你能使用的電腦操作能力」，再把這段描述貼進 T3 Code 的 Opus，指示它盡可能照做。產出的 PR 至今仍未合併。他整理出的能力清單包括：探索並開啟應用程式、讀取介面、截圖而不只是讀結構化文字、滑鼠操作（點選、雙擊、右鍵、拖曳、捲動）、鍵盤輸入、欄位編輯、瀏覽器分頁、檔案處理，以及驗證自己的結果——同時讀取無障礙樹與截圖。

他把同一招延伸到診斷代理本身：你為什麼沒在這份 PR 加截圖、以後什麼工具能幫你做到、你為什麼找不到這個 bug、你能不能讀另一個討論串的對話紀錄。「你可以對你的提示下提示，也可以對你的程式下提示。」

反面則是：用提示會暴露缺少的基礎元件。Browne 要視覺化工具時，代理產出一個 HTML 頁面，他得在 T3 Code 之外開啟——他可以用內建瀏覽器（但他把它關了），而 Codex 已經能直接在對話裡渲染視覺化內容，T3 Code 還不行。他想打造的正是補上這個缺口，而不是再加一顆按鈕：讓使用者自己建構動態功能的工具。

flowchart TD
    A["使用者想要一個結果"] --> B{"這是代理能取得的資訊嗎？"}
    B -->|是| C["用提示取得"]
    B -->|否，代理沒有存取權| D["打造基礎元件：MCP、資料管線、內嵌渲染器"]
    C --> E{"反覆被要求嗎？"}
    E -->|是| F["寫成 skill 或 Claude.md"]
    E -->|否| G["繼續用提示"]
    D --> C

接上資料管線——從電子郵件開始

Browne 最強烈的實務建議，是把電子郵件帳號連結到 ChatGPT。他描述自己有五個信箱，其中四個必須主動盯；多年來對 Superhuman（「最好的郵件客戶端，卻慢慢爛掉」）和 Gmail 網頁介面滿腹怨氣；大約四年間屢次差點自己動手做郵件 App。真正推他一把的，是手受傷後沒辦法那麼輕鬆地用電子郵件工作。一次連結多個帳號後，他從一天檢視收件匣約十次，降到約一天一次，其餘交給代理處理。

會複利成長的例子：告訴代理留意 Amazon 的來信，因為有一筆大額 AWS 帳單要來；帳單到了，就請它進 AWS 儀錶板查出費用為何偏高、幫忙壓低，再讓它開更多代理接手，通常是在 T3 Code 裡。因為他把 T3 Code 的 MCP 接上了 Codex，Codex 和其他工具就能在 T3 Code 裡啟動 Claude 討論串。這套模式是刻意設計的：先建好管線和資料存取，再讓提示發揮更大作用。

他預期有人會說這是「腦腐化」，並用電子郵件的類比回應——當年人們也這樣說電子郵件之於書信；重點不在取代當面接觸，而在於觸及那些你原本根本懶得處理的事。

低谷的盡頭是更難的工程，不是更少的工程

Browne 對那些覺得工藝正在流失、框架和語言越來越不重要的工程師說話。他描述自己也曾陷入低潮，並說那種感覺是低谷，不是終點。他的證據很個人也很具體：他今年做了大約五個 Rust 應用程式，對現代記憶體管理的理解比以往更深，動力來自一個代理將在隔離環境中以近乎免費的算力執行的未來。他正在為自己的雲端打造自己的 JavaScript 執行環境。他不再逐一思索每一條 SQL 查詢，但他會思索資料庫與伺服器層之間的連線方式，以及如何在不拉高成本的前提下讓連線保持熱度。

「我現在的工程強度是我這輩子最高的，我的腦袋也比以往任何時候都轉得更兇。」

他對批評者毫不客氣：看到他在一個測試完善的事案裡接受「Claude 垃圾產出」就斷定他腦袋腐化的人，「根本不懂我們現在能做的工程工作多了多少」。他認為最大聲的批評者自己正身處低谷——花了整個職涯爬到高點，卻被 AI 弄得一文不值。他最後對那些說他被 OpenAI 收買的懷疑者補上一刀：「如果你繼續這樣想，我等著看你失業。」

本集留下的未解問題

整場簡報有兩股張力始終沒有化解。第一，提示與功能的界線取決於代理能觸及什麼，而 Browne 自己的例子就顯示這條界線在移動——他想要的內嵌視覺化工具還不存在，電腦操作的 PR 也還沒合併。第二，triage 工具的五行程式碼設計，取決於使用者已安裝 Claude Code 或 Codex，也取決於模型能穩定遵循一份長篇 markdown 操作手冊；Browne 斷言它「好用得多」，卻沒提供任何失效資料。值得持續觀察的是：T3 Code 會不會推出代理即時生成的內嵌 UI，以及他在 Codex、ChatGPT 與 T3 Code 之間搭起的 MCP 橋梁，會成為標準做法，還是停留在進階玩家的自訂配置。