編碼智能體面臨的一個關鍵挑戰，在於如何讓它們既能測試、又能向監督者展示所建構的軟體。除了自動化測試，我們還需要能展示進度並闡明智能體產出軟體功能的成品。我發布了兩個針對此問題的新工具：Showboat 和 Rodney。
軟體工程師的工作是交付可運行的程式碼，這包括證明其行為符合預期。在使用編碼智能體時，這一點變得更為重要且更具挑戰性。隨著我們透過智能體產出更多程式碼，能減少手動 QA 時間的工具便顯得極具價值。
StrongDM 的軟體工廠模式確保了軟體經過良好測試，儘管其政策是「無人工程式碼審查」，部分原因在於使用了昂貴的 QA 智能體群來執行情境測試。我希望擁有能讓智能體清晰展示其工作成果，同時盡量減少它們作弊機會的工具。
Showboat 是一個 CLI 工具（一個 Go 二進位檔，可選擇用 Python 包裝），幫助智能體建構一份 Markdown 文件，展示其新開發程式碼的功能。它並非設計給人類執行，但以下是一個使用範例：
showboat init demo.md ‘How to use curl and jq’showboat note demo.md “Here’s how to use curl and jq together.”showboat exec demo.md bash ‘curl -s https://api.github.com/repos/simonw/rodney | jq .description’showboat note demo.md ‘And the curl logo, to demonstrate the image command:’showboat image demo.md ‘curl -o curl-logo.png https://curl.se/logo/curl-logo.png && echo curl-logo.png’結果是一份逐步建構的 Markdown 文件，命令輸出會自動加入。image 命令會尋找命令輸出中的圖片檔案路徑，將其複製到當前資料夾，並在文件中引用。
其他命令包括 pop（移除最近新增的區段）、verify（重新執行文件以檢查是否有變更）和 extract（反向工程出用於建立文件的 CLI 命令）。Showboat 很簡單，只有 172 行 Go 程式碼。
你可以使用 uvx showboat --help 來執行它，無需安裝。 --help 文字提供了編碼智能體使用此工具所需的一切資訊，就像一個技能。你可以指示智能體閱讀說明文字並建立一份展示文件。
一個有趣的技巧：設定 Claude 來建構一份 Showboat 文件，可以讓你在 VS Code 中即時觀看預覽窗格的更新，就像同事在分享螢幕一樣。
由 Claude 使用 Showboat 建立的文件範例，包括展示 shot-scraper、sqlite-history-json CLI、row-state-sql CLI、使用 Notes 進行變更分組，以及一個使用 krunsh 的複雜範例。
我已充分使用 Showboat，並確信其實用性。然而，智能體有時會作弊，直接編輯 Markdown 檔案而非使用 Showboat，導致命令輸出與現實不符。
許多專案涉及網頁介面，智能體也常建構新頁面。Showboat 的 image 功能原本就是設計給智能體擷取螢幕截圖，最初使用 shot-scraper 或 Playwright。由於 Showboat 受益於 CLI 工具，我尋找能從 CLI 管理多輪瀏覽器會話的選項，但一無所獲。
Claude Opus 4.6 指引我使用 Rod 這個 Go 函式庫來與 Chrome DevTools 協定互動。它功能全面但缺少 CLI。我因此建構了 Rodney 作為 CLI 工具，其名稱是對 Rod 以及影集《Only Fools and Horses》的致敬。
你可以使用 uvx rodney 執行 Rodney 或安裝它。一個簡單的會話範例：
rodney start # 在背景啟動 Chromerodney open https://datasette.io/rodney js ‘Array.from(document.links).map(el => el.href).slice(0, 5)’rodney click ‘a[href=”/for”]’rodney js location.hrefrodney js document.titlerodney screenshot datasette-for-page.pngrodney stop與 Showboat 一樣，Rodney 是為編碼智能體設計的，而非人類。目標是讓智能體執行 rodney --help 就能看到使用此工具所需的一切。
使用 Showboat 建立的 Rodney 展示文件，包括其原始功能集、新的無障礙測試功能，以及使用這些功能對頁面執行基本無障礙稽核。
我曾是職業生涯中對測試優先開發持懷疑態度的人，但最近開始接受它，認為這是迫使智能體只撰寫必要程式碼的一種方式。許多 Python 編碼智能體會話的開頭，都是指示其執行現有測試並使用紅/綠 TDD 進行建構。這提高了程式碼品質，並增加了智能體以最少提示產出正確成果的可能性。
然而，通過自動化測試並不能保證軟體正常運作。這正是 Showboat 和 Rodney 背後的動機——我從不信任一個功能，除非我親眼看到它運行。在 Showboat 出現之前，我常在智能體會話中加入手動測試步驟。
Showboat 和 Rodney 最初都是透過 Claude iPhone 應用程式，由 Claude Code for the web 專案開始的。大部分後續的功能開發也以同樣方式進行。我對現在能在手機上完成如此多的編碼工作感到驚訝；我估計我推送到 GitHub 的大部分程式碼，都是由我透過 iPhone 應用程式驅動的編碼智能體為我撰寫的。
我最初為非同步編碼智能體環境（如 Claude Code for the web）設計了這些工具，目前看來效果良好。
2026-02-07 引述
David Crawshaw：「我現在比以往任何時候都更享受編程的樂趣，因為我希望有時間編寫的許多程式現在真的存在了。我希望能與那些對智能體帶來的變化感到恐懼的人分享這份喜悅。恐懼本身我能理解，我對我們社會中『智慧隨手可得』的終局有更廣泛的恐懼。但僅限於撰寫電腦程式這個有限領域，這些工具為我的工作帶來了如此多的探索和樂趣。」
Anthropic 透過 Claude Code 中的 /fast 引入了更快的 Claude Opus 4.6 版本，但價格是正常的 6 倍。Opus 通常輸入為每百萬 5 美元，輸出為每百萬 25 美元。快速模式輸入為每百萬 30 美元，輸出為每百萬 150 美元，在 2 月 16 日前有 50% 折扣（即 3 倍）。文件未指定速度，但 Claude 在 Twitter 上表示：「我們的團隊一直在使用一個快 2.5 倍的 Claude Opus 4.6 版本進行建構。我們現在透過 Claude Code 和我們的 API 將其作為早期實驗提供。」
Claude Opus 4.5 有 20 萬個 token 的上下文限制。4.6 提供了一個選項，可在超過 20 萬個 token 後將限制增加到 100 萬個 token，輸入價格為 2 倍，輸出價格為 1.5 倍。這些倍數也適用於快速模式。
Mitchell Hashimoto 的新系統旨在解決開源專案中無價值的 AI 生成 PR 問題，要求貢獻者來自受擔保的用戶。未受擔保的用戶無法貢獻，而非常惡劣的用戶可能會被譴責（封鎖）。用戶透過 GitHub 評論或 CLI 由貢獻者進行擔保或譴責。整合是透過 GitHub Actions 進行。該系統是通用的，適用於各種程式碼託管平台，不侷限於 GitHub。專案自行決定其標準。
2026-02-08 引述
Thomas Ptacek 談漏洞研究與 LLM：「橙色網站上的人們在嘲笑這個，認為這只是廣告，沒什麼內容。我交談過的漏洞研究人員並不認為這是個笑話。作為一個昔日的漏洞研究員：別在這件事上跟 LLM 對賭。」他引用了一篇 Axios 文章：「Anthropic 的 Claude Opus 4.6 在開源軟體中發現了 500 個零日漏洞。」Ptacek 認為漏洞研究非常適合 LLM，因為其模式驅動的特性、大量的公開資料庫、封閉迴路和工具化。前沿實驗室有錢購買漏洞研究成果，何必造假？
朋友兼鄰居 Karen James 為我做了一個鴞鸚鵡馬克杯，上面有一隻極富魅力的鴞鸚鵡、四隻幼鳥（慶祝 2026 年繁殖季）和 rimu 果實。我愛不釋手。
來自柏克萊哈斯商學院的 Aruna Ranganathan 和 Xingqi Maggie Ye 在《哈佛商業評論》中報告了一項對美國科技公司 200 名員工（2025 年 4 月至 12 月）研究的初步發現。AI 引入了一種新的工作節奏，員工同時管理多個活躍線程：手動編寫程式碼的同時 AI 生成替代方案、並行運行多個智能體，或重啟長期擱置的任務，因為 AI 可以在背景處理它們。員工感覺有一個「夥伴」提供動力，但現實涉及持續的注意力切換、頻繁檢查 AI 輸出，以及不斷增長的待辦任務，從而產生了認知負荷和一種疲於奔命的感覺。
作者呼籲組織建立「AI 實踐」來結構化 AI 的使用，避免倦怠，並區分真正的生產力提升與不可持續的工作強度。我們已經顛覆了數十年來關於可持續工作實踐的直覺；找到新的平衡需要時間和紀律。
Damon McMillan 的新論文，探討了使用大型 SQL 綱要（最多 10,000 張表）在不同模型和檔案格式下進行具有挑戰性的 LLM 上下文任務。該研究涉及 9,649 次實驗，涵蓋 11 個模型、4 種格式（YAML、Markdown、JSON、TOON）以及從 10 到 10,000 張表的綱要。前沿模型（Opus 4.5、GPT-5.2、Gemini 2.5 Pro）擊敗了領先的開源模型（DeepSeek V3.2、Kimi K2、Llama 4）。前沿模型受益於基於檔案系統的上下文檢索，但開源模型的結果說服力較低，這強化了檔案系統編碼智能體迴路由開源權重模型處理得不如前沿模型好的觀點。Terminal Bench 2.0 排行榜仍然由 Anthropic、OpenAI 和 Gemini 主導。
一個有趣的細節：針對 TOON（Token-Oriented Object Notation）的「grep 稅」結果。TOON 以極少的 token 表示結構化數據，但模型對其不熟悉，導致需要花費顯著更多的 token 經過多次迭代才能理解它。
Charles Leifer，pysqlite3（一個用於升級 SQLite 版本的 Python sqlite3 模組分支）的維護者，一直在進行一個從頭開始的 Cython 重寫專案，稱為 cysqlite，現在已準備好進行測試。最大的變化涉及交易處理；Charles 解釋了對 sqlite3 實作的不適，它提供了兩種變體，但沒有一種完全符合 SQLite 的自動提交機制。我對支援自訂虛擬表感到興奮，這是我希望在 sqlite3 本身中看到的功能。
cysqlite 提供了一個從 C 編譯的 Python 擴展，通常在 Pyodide 中無法使用。我讓 Claude Code 建構了一個 WASM wheel：cysqlite-0.1.4-cp311-cp311-emscripten_3_1_46_wasm32.whl (688KB)，可透過 micropip.install 在 Pyodide 中載入。