Clawdbot開發者：未來一大批應用都會消失，提示詞就是新的interface

Founder Park 聯合釦子，舉辦了一場 Skill 招募大賽。如果你手裏有一套在用、能交付結果的方法論，很適合來試試！

• 可落地的 Skill 搭建方法
  從一個想法或一套 SOP，拆解成真正能跑起來的 Skill

• Skill 的展示與放大通道
  不只是自己用，而是被更多人看到、用到

• 被看見後的實際激勵
  好的 Skill，有機會獲得明確回報

主持人：你是怎麼開始做 Clawdbot 這個項目的？我看你之前也做了不少有意思的東西項目？

Steinberger：說實話，我的核心信條就是「我要玩得開心」。學習這些新技術的最好方式就是去玩、去折騰。所以我做了很多有意思的小東西，嘗試了不同的語言和方法。

我管這個叫 agentic engineering，我不太喜歡 vibe coding 這個詞。當然，有時候我也開玩笑說，白天搞「agentic engineering」，凌晨三點就開始 vibe coding，然後第二天就後悔當時怎麼沒去睡覺。

其實早在去年五月份，我就有了做個人 Agent 的想法，那會兒 GPT-4 被 GPT-4o 替代，當時覺得模型還不夠好，但我當時又覺得，這事大公司未來幾個月肯定會做，我幹嘛要費這個勁呢？我等着他們做得更好就行了。

所以當時我更多探索怎麼用 Agent 來更快地構建軟件。我的技術背景主要集中在做 iOS 和 macOS 開發，但對於最新的項目，我非常想做一些 Web 相關的東西。距離上一次做 Web 開發已經過去太久了。你知道那種感覺，當你在一個領域是專家，換到另一個領域卻要從最基礎的東西搜起，非常打擊自尊心。

AI 的出現正好是完美的契機，我越用越上癮，也越來越懂怎麼跟這些工具打交道。

直到去年 11 月，我發現市面上還是沒有我想要的個人智能體。尤其是我在用 Codex 做一些長時間任務時，總得有人在那盯着，然後不斷輸入「continue」。有段時間，我感覺自己就像一台「continue」打字機。我當時就想，為什麼不能讓一個 AI 來幫我幹這件事呢？「為什麼我沒有一個智能體來照看我的其他智能體呢？」這基本上就是 Clawdbot 項目的起點了。

主持人：所以是為了解決自己這個痛點，然後動手做了？

Steinberger：對。當時我想，能不能在 WhatsApp 上跟我的電腦聊天？這樣當我的智能體在跑任務時，我去廚房倒杯水也能隨時看看進度，或者給它發點小指令。

於是，我花了一個小時就搞定了基礎的 WhatsApp 集成：接收消息，調用 Claude，然後返回結果，一次成功。所有的構建模塊其實都是現成的，我用了一個開源項目來處理 WhatsApp 協議，用了 Claude Code 的命令行工具來調用模型，我主要寫的就是些「膠水」代碼。大概花了一兩天時間就讓它跑起來了，基本功能實現只花了一個小時。

Steinberger 的 Github 主頁，開源項目是真不少

主持人：所以你其實是把手裏已經有的現成工具直接組合了起來？

Steinberger：沒錯。因為我平時更喜歡用包含文字和圖片提示詞，所以後來我又花了五個小時加上了圖片支持。之後又加上了音頻，因為我想直接給它發語音，也讓它用語音回覆我。

有一次我去馬拉喀什旅行，我發現自己用這個工具的頻率遠超了預期，但不是用來編程，更多是用來查餐廳、問路之類的。因為它集成了谷歌搜索，在路上特別方便。

最神奇的一次是，我當時根本沒做語音消息支持，但我下意識地給它發了條語音。我看到輸入狀態顯示「正在輸入」，結果 10 秒後，它直接回復了我。我驚呆了，問它：「你到底是怎麼做到的？」

它回覆說：「你發來的消息裏只有一個文件連結，沒有擴展名。我檢查了文件頭，發現是 Opus 格式，就用你 Mac 上的 FFmpeg 把它轉成了 Wave 格式。我想用 Whisper，但發現沒裝，安裝還報錯了。不過，我在你的環境變量裏找到了 OpenAI 的密鑰，所以就用 curl 命令把文件發給了 OpenAI，拿到轉錄文本，然後才回復了你。」

那一刻，我真的感覺「哇」的一下，就像被打通了。只要你給這些模型足夠的權限，它們真的是非常聰明、足智多謀的「野獸」。從那以後我就徹底迷上了，用它做了各種奇怪的事。

我認為這個項目既是技術，也是一種藝術和探索。從技術上說，它只是「膠水」，把已有的東西粘合在一起。但從另一個角度看，它提供了一種全新的交互方式，因為所有的技術細節都消失了。你不需要考慮新的會話、上下文壓縮、用哪個模型（可能 token 費用還是會讓你稍微考慮一下），但通常這些都會被忽略。你只是在和一個朋友，或者說一個「幽靈」交談。

主持人：你的項目在一週內經歷了現象級的爆火，過去幾天你是怎麼過來的？

Steinberger：從睡眠上來說，很糟糕。但這也無比令人興奮。我認為去年是「編程智能體」之年，而今年將是「個人助理」之年。我感覺我喚醒了人們對它的真實需求。

我不知道 Clawdbot 是否是最終答案，但它應該為人們指明瞭方向。我敢肯定這個領域會出現大量產品，也肯定有很多人正在瘋狂地開發。這將是一個非常有趣的領域。

從 Twitter 爆火，到我們的 Discord 服務器以我前所未見、無法處理的方式增長，各種事情接踵而至。到後來，我只能把 Discord 上的問題複製粘貼到 Codex 裏，讓它生成回答。再後來，我乾脆把整個頻道的內容都扔進去，說：「回答這 20 個最常見的問題。」因為人們沒意識到，這背後不是一個公司，只是一個在家圖個樂子的傢伙。

當然，你看代碼提交記錄，可能確實像個公司。但這只是因為現在的智能模型太強大了，如果你能駕馭它們，理解它們的「語言」，一個人就能達到一年前一個團隊的產出。

主持人：你的項目可以讓用戶輕鬆切換使用所有模型，包括他們的競爭對手。他們是什麼反應？

Steinberger：我這個項目的一個前提就是，每個模型都應該能用，包括本地模型。對我來說，這是一個遊樂場，一個絕佳的學習方式。我認為每個人都應該嘗試構建一個智能體循環，探索記憶機制，這裏面有很多有趣的方面。我把它設計成插件化的，這樣人們就可以專注於自己的小模塊，而不用去動整個核心。這有點像 AI 黑客的天堂，而且因為它是個性化的，所以非常有趣。

主持人：現在很多人都在追求那種能獨立運行幾十個小時的超長任務智能體。你怎麼看這個方向？

Steinberger：我覺得，那種「我們要做一個能獨立跑 20 個小時的東西」的思路，對我來說有點像個虛榮指標。我的瓶頸從來不是讓智能體跑得更久，真正的瓶頸通常是我自己：我的提示詞，以及我下一步該讓它做什麼的思考。

我更喜歡一種參與感更強、更迭代的方式來構建軟件。我希望自己能 in the loop，隨時測試它正在構建的東西，看看方向對不對。比如，當它在幫我寫一個網頁服務時，我給它一部分需求，就能親眼看着這個功能在瀏覽器裏一點點成形。這個過程本身就會激發我的新想法，讓我知道接下來還能加點什麼、可以往哪個方向走。我可以隨時去點一點，去感受它。

這種迭代的開發方式，遠比你坐下來從理論上把一個功能規劃到完美要好得多。因為等你真的把它做完了，你又會有新的想法了。所以，長時程運行當然是一個值得探索的方向，但在今天的實際應用裏，它根本不是瓶頸所在。

主持人：去年大家都在聊 Agent，但焦點好像都在瀏覽器上。我用了 Clawdbot 之後，感覺大家都搞錯方向了。如果能直接跟一個跨所有應用的智能體對話，誰還關心瀏覽器呢？

Steinberger：是的。我在做這個項目之前，大部分的準備工作就是構建各種小巧、獨立的命令行工具（CLI）。我的前提是：MCP這東西很糟糕，擴展性不強。人們圍繞它做了各種奇怪的搜索功能，但真正具備擴展能力的是命令行。智能體天生就懂 Unix 系統，你可以在電腦上放一千個小程序，它們只需要知道程序的名字，調用一下幫助菜單，就知道該怎麼用了。

如果聰明一點，就應該按照模型已經習慣的方式去構建工具，為模型設計，別為人類設計。比如，如果模型習慣調用 --log 參數，那你就構建一個 --log 參數。這是一種「智能體驅動」的開發思路，你按照它們的思維方式去構建，一切都會順暢得多。在某種程度上，是一種全新的軟件。

所以，對大多數事情我都不需要瀏覽器。我為谷歌服務、Sonos 音響、攝像頭、家庭自動化系統都構建了相應的工具。每增加一個小小的命令行工具和技能，我的智能體就變得更強大、更有趣。到我開始做 WhatsApp 集成的時候，這些功能很多都已經有了，我就是這樣被迷住的。

但有個問題，我覺得這東西很神奇，可當我在 Twitter 上討論它時，反響卻很平淡，感覺人們沒有理解它的價值。但我把它展示給我的朋友，包括那些非技術背景的朋友，他們都搶着想要。所以我知道，我做對了方向，只是科技圈的人還沒反應過來。

我一直在持續開發，因為我自己也在用，我就是為自己做的。這是一個開源項目，我的動機是尋找樂趣、激勵他人，而不是為了賺大錢，因為我已經有很多錢了。

主持人：我同意你的看法，確實很奇怪為什麼沒有更多公司在做個人化智能體。我也能預見到，在不久的將來，每個人口袋裏都會有一個個人化智能體，作為他們的助理。

但我想問，這麼強大的個人助理，肯定要給它很多權限，比如攝像頭、郵箱。你是怎麼平衡這種便利和它帶來的巨大安全風險的？

Steinberger：好問題，當你用 ChatGPT 或者 Claude 時，它們本身就有集成功能。大多數人早就把郵件、日曆、Google Drive 都授權給它們了。所以，這些模型已經掌握了我們的數據，這是一個既成事實。

我給我的 Claude 一個可以訪問 Gmail 的 MCP，和你直接在 Claude 官網上添加 Gmail 集成，這兩者之間沒有任何區別。實際上，我認為直接在官網集成風險更高，因為你根本無法控制它在後台做什麼。但如果它運行在我的電腦上，我至少還能看到日誌。所以，我甚至覺得，直接把所有權限交給那些大公司，比通過我的系統來授權更危險。

主持人：MCP 這個話題最近在工程師圈子裏也很有爭議。你怎麼看？

Steinberger 此前曾在一篇博客文章中談論他對於 MCP 的看法：

Steinberger：我總說，MCP 是唯一一種開發者比用戶還多的軟件。你想想看，在大多數情況下，MCP 只是對 API 的一層包裝。大多數 MCP 都應該被直接做成 CLI（命令行工具）。CLI 是我可以調用並獲得返回的東西，而且它是可組合的。

想象一下，你有一個天氣服務，可以返回一個所有城市的列表。如果它是一個 MCP，我調用 get_cities，然後得到全部 500 個城市的數據，模型就得在它的上下文中處理這些。但如果它是一個 CLI，我就可以調用這個函數，然後用管道符加上 jq 進行過濾，可能最後只得到符合我條件的 5 個城市。這樣我就節省了 495 行的上下文垃圾。而且我可以立刻把這 5 個城市的結果通過管道傳給下一個工具，進行二次處理，也許是再為這 5 個城市分別調用一次天氣服務，所有這些操作都在一次調用中完成。

所以，在幾乎所有情況下，CLI 都比 MCP 要好。MCP 唯一的好處是它能保持 state，但這種情況你極少需要。即便需要，通常也可以用磁盤來臨時存儲。所以我不會說 MCP 完全沒用，但從實際應用來看，它最大的貢獻可能就是推動了一些以前沒有 API 的公司去構建了 API。

MCP 的存在更多是為了讓市場部門高興。我構建了另一個叫 MC Porter 的項目，它基本上就是把一個 MCP 轉換成一個 CLI。這樣，我的智能體就可以按需發現工具，我也不用為往上下文中塞滿垃圾而付出代價。

舉個例子，如果我的智能體需要用到 Chrome 開發者工具，它的定義文件大概有 13000 個 token。我總不能每次對話都為這 13000 個 token 付費吧。當需要時，它會調用 MC Porter 來獲取開發者工具的幫助文檔，就像你使用任何 CLI 一樣。它讀取幫助文檔，學會如何使用這個工具，然後就去調用它。基本上，我用一次額外的調用，換來了不必一直拖着這些累贅，避免讓每個會話都變得更笨、更短。

我不知道為什麼這種做法沒有被更廣泛地採用。我認為這遠比現在的方式更合理，也更有擴展性。我可以擁有 500 個工具，但我的初始上下文依然是零。這東西在 Unix 系統裏已經存在 40 年了，智能體非常非常擅長使用 CLI。當然，這會增加一些風險，所以你要麼構建一個只運行你自己的 CLI 的沙箱，要麼使用容器。這些問題都是可以解決的。

Steinberger：同時，我還觀察到的一個非常有趣的現象是：一大批應用將會逐漸消失。比如，我為什麼還需要 MyFitnessPal 這種健身應用？我只要拍張食物的照片，我的智能體已經知道我正在麥當勞做一個糟糕的決定。結合這些信息，它能完美匹配出我吃了什麼，甚至可能會反過來調整我的健身計劃來確保我還能達標。所以，我不再需要那個 App 了。

一大批應用都會消失，因為你與事物的交互方式會變得完全不同，大多數應用會被簡化為 API。接下來的問題是，如果我可以把數據存在別的地方，我甚至還需要那個 API 嗎？

Steinberger 在社交平台 Mastodon 發佈的帖子：

「Apps will melt away. The prompt is your new interface.」

主持人：這個轉變聽起來很顛覆。但你覺得非技術背景的普通人，真的會為了這個去自己折騰部署這些東西嗎？門檻會不會太高了？

Steinberger：我剛參加完一個線下聚會，碰到一個來自印第安納州的設計機構的人，他沒有寫過一行代碼。他說他去年 12 月初就發現了我的項目，然後開始使用 Clawdbot。

他說：「我們現在已經有了 25 個網絡服務，我們可以為自己需要的任何東西構建內部工具。」他完全不懂代碼，他只是通過 Telegram 和他的智能體交談，然後智能體就為他構建東西。

所以，這裏有一個巨大的轉變：你不再需要訂閲那些只提供通用功能的初創公司的服務。你擁有自己超個性化的軟件，它能精確解決你的問題，而且還是免費的。非技術人員也在這樣做，因為它非常自然。你只需要說出你的問題，然後這個東西就會為你構建解決方案。而且別忘了，現在的模型是它們有史以來最差的狀態，未來只會變得越來越好，越來越簡單，越來越快。

主持人：在這麼多模型裏，你自己最常用或者最喜歡的是哪個？

Steinberger：從模型能力上來說，Opus 遙遙領先，是最好的。OpenAI 的模型非常可靠，我甚至覺得它作為「員工」更可靠。在編程方面，我更喜歡 Codex，因為它能駕馭大型代碼庫。我真的可以只給它一個提示，然後直接把代碼推送到主分支，我有 95% 的把握它能正常工作。

而用 Claude 的話，你需要更多的技巧和「表演」才能達到同樣的效果。兩個都很好，但我用 Codex 能更快地並行工作，因為它需要的「手把手指導」更少。

但從「性格」上來說，我不知道他們用什麼數據訓練的模型，裏面有多少 Reddit 的內容，但模型在 Discord 裏的表現非常棒，很像個人類。它不會在每條消息下都刷屏，而是像在傾聽對話，然後偶爾會拋出一個金句，真的能讓我笑出來。你知道，這其實很難，因為 AI 的笑話通常都很爛。這種體驗我只在 Opus 上感受過。所以這是我最喜歡的模型。

這也是為什麼當我收到 Anthropic 的郵件，要求我給項目改名時，會覺得有點諷刺。

不過，值得稱讚的是，他們非常友好，沒有派律師來，而是派了內部人員溝通。但時間線有點緊，給一個有這麼大流量的項目改名，簡直是一場災難。當時我面臨一些額外的壓力，就想：「管他呢，現在就改！」就像那個「我們直播搞定」的梗一樣。結果我這邊剛在 Twitter 上改完名，那邊的新賬號瞬間就被加密貨幣的機器人搶注了。

主持人：大家都想知道，你自己用 Mac Mini 嗎？你怎麼看 Mac Mini？

Steinberger：我的智能體有點像個「小公主」，它不用 Mac Mini，它用的是頂配版的 Mac Studio，512GB 內存，所有配置都拉滿了。因為我也想玩玩本地模型，這樣我就可以運行 MiniMax M2.1，我認為這是目前最好的開源模型。當然，一台機器是不夠的，你可能需要兩三台。我有點想等蘋果發佈新品。

主持人：從宏觀角度看，你認為這種自己運行硬件的「黑客文化」模式，未來會有多大比例保留下來？人們最終會轉向雲託管、一鍵部署這種更簡單、技術門檻更低的方式嗎？

Steinberger： 我不認為未來會是每個人都為了這個去買一台 Mac Mini。但我確實看到，舊有的模式必須改變。比如，一個公司想要接入 Gmail，審批流程繁瑣到初創公司寧願去收購另一家已經有許可證的公司。但如果你在本地運行，就可以繞過所有這些問題。我做過很多命令行工具，就是直接把網站丟給 Codex，說「給我做一個 CLI」。有時候這可能違反了服務條款，但說實話，我不太在乎。這在某種程度上是對大科技公司不願開放的數據的一種解放。

就連 WhatsApp 的集成也是一個「黑客」手段，它模擬了桌面端使用的協議。我真的嘗試過支持官方接口，但官方接口是為企業設計的。我作為個人用戶很快就被封了，最後我一氣之下把官方接口的支持代碼全刪了。

目前還沒有適合這種個人用例的模式，我認為這需要改變。

主持人：那麼，接下來有什麼計劃？

Steinberger：現在有很多來自安全研究員的郵件。問題在於，我做這個是為了好玩，為我自己在一對一的環境中使用。現在，人們把它用在了不被信任的公共環境中。所以，所有我之前不在乎的安全威脅模型現在都出現了。

我正被各種報告轟炸，其中很多還是針對我並不關心的用例。我還不確定如何處理這個問題，因為整個體系都「壞掉」了。

不過幸運的是，我正在組建一個團隊，確實有很多人非常關心這個項目。所以我認為它最終會成為一個非常安全的產品，因為現在全世界都在「拆解」它。

說實話，這整個項目都是「Vibe Coding」出來的，我只是想向人們展示一種可能性，而不是一個企業級的成品。我甚至覺得，可能沒有公司敢碰這個，因為我們還沒解決一些根本性問題，比如「提示注入」就沒有解決方案。這其中存在絕對的風險，我也努力在網站和啓動提示裏明確說明了：「能力越大，責任越大」。

現在我正努力把它打造成一個社區，它應該比我個人更長久。我也需要幫助，工作量太大了，我不可能一直不睡覺。

主持人：有想過成立一個真正的公司嗎？還是說你想讓它永遠保持一個「黑客社區」的狀態？

Steinberger： 相比於公司，我更傾向於成立一個基金會或者非營利組織。不過，我還沒下定決心。

Steinberger 作為一個有十多年經驗的資深工程師，近期常在博客中分享他在做 Agentic Engineering 的經驗。

其中，他提到一點，非常有意思，叫：「Just Talk To It」。開發者不應該被編寫複雜的「提示詞工程」或者繁冗的工作流框架所限制住，更多地是應該學會「直接與 AI 交談」。

以下是他的部分博客內容：

六月份之前我確實這麼做。設計一個龐大的規格說明書（Spec），然後讓模型構建它，理想情況下讓它跑上幾個小時。在我看來，那是構建軟件的舊思維。

我目前的方法通常是：開始與 Codex 對話，粘貼一些參考網站、一些想法，讓它閲讀代碼，然後我們一起充實一個新功能。如果是棘手的問題，我會讓它把所有內容寫成一份 Spec，交給 GPT-5-Pro 審查，看看有沒有更好的主意（令人驚訝的是，它經常有，這極大地改進了我的計劃！），然後把我認為有用的部分貼回主上下文以更新文件。

現在，我對哪些任務佔用多少上下文心裏很有數，而且 Codex 的上下文空間相當充裕，所以通常我就直接開幹了。有些人像信教一樣，堅持每次都用帶有計劃的新上下文——在我看來這對 Sonnet 有用，但 GPT-5 處理大上下文的能力強得多，那樣做只會給每件事增加 10 分鐘的開銷，因為模型必須慢慢重新抓取構建功能所需的所有文件。

更有趣的方法是做基於 UI 的工作時。我經常從簡單的東西入手，故意把需求描述得很模糊，看着模型構建，實時觀察瀏覽器的更新。然後我把額外的修改排入隊列，迭代打磨功能。通常我也不完全確定某個東西該長什麼樣，這種方式讓我可以把玩創意，不斷迭代，看着它慢慢變得生動起來。我經常看到 Codex 做出了我甚至沒想到的有趣設計。我不重置，我只是迭代，把混亂一步步塑造成我想要的樣子。

通常在構建過程中，我會產生相關交互的想法，並在其他部分進行迭代，那部分工作我會交給另一個智能體。一般來說，我會同時處理一個主功能和幾個相關的次要任務。

就在我寫這篇文章的時候，我正在我的 Chrome 擴展裏構建一個新的 Twitter 數據導入器，為此我正在重構 GraphQL 導入器。因為我不確定目前的方案是否正確，所以我把它放在一個單獨的文件夾裏，這樣我可以查看 PR，判斷那個方案是否有意義。主倉庫正在進行重構，所以我可以專心寫這篇文章。

常用的 Slash Commands

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

• /commit（自定義文本，解釋多個智能體在同一個文件夾中工作，只提交你修改的部分，這樣我能得到乾淨的註釋，而且 GPT 不會對其他變更大驚小怪，也不會在 Linter 失敗時試圖回滾所有東西）

• /automerge（一次處理一個 PR，對機器人的評論做出反應，回覆，讓 CI 變綠，並在變綠時壓縮合並）

• /massageprs（與 automerge 相同但沒有壓縮步驟，這樣如果我有很多 PR，我可以並行處理）

• /review（內置命令，偶爾用，因為我在 GH 上有審查機器人，但也算有用）

即使有了這些，通常我也只輸入 "commit"，除非我知道有太多髒文件，沒有指引智能體可能會搞砸。當我確信當前上下文足夠時，沒必要搞那些花架子浪費上下文。再說一次，你會對這些產生直覺。目前我還沒發現其他真正有用的命令。

還有什麼其他技巧？

與其絞盡腦汁寫完美的提示詞來激勵智能體完成長期任務，不如用點懶人變通法。如果你在做一個大的重構，Codex 經常會以「工作進行中」的回覆暫停。如果你想走開不管，只看結果，那就把「繼續（continue）」的消息排進隊列。如果 Codex 做完了又收到更多消息，它會愉快地忽略它們。

讓模型在每個功能/修復完成後編寫測試。使用相同的上下文。這會產生質量更高的測試，而且很可能在實現過程中發現 Bug。如果是純 UI 調整，測試可能意義不大，但對於其他任何事情，一定要寫。AI 通常不擅長寫好的測試，但有總比沒有強，老實說——你會為你做的每個修復手動寫測試嗎？

讓模型保留你的意圖，並「在棘手的部分添加代碼註釋」，這對你自己和未來的模型運行都有幫助。

當問題變得棘手時，在提示詞里加一些觸發詞，比如「慢慢來」、「全面一點」、「閲讀所有可能相關的代碼」、「提出假設」，能讓 Codex 解決哪怕是最棘手的問題。

Just Talk To It

不要把時間浪費在 RAG、子智能體、Agents 2.0 或其他大多隻是「花架子」的東西上。直接跟它對話。去把玩它。培養直覺。你與智能體協作得越多，你的結果就會越好。

Simon Willison 的文章提出了一個極好的觀點：管理智能體所需的許多技能，與你管理工程師時所需的技能如出一轍，幾乎所有這些都是高級軟件工程師的特質。

是的，編寫好的軟件依然很難。僅僅因為我不再親手寫代碼，並不意味着我不去深入思考架構、系統設計、依賴關係、功能特性或如何取悦用戶。使用 AI 只是意味着，我們對交付成果的期望值變高了。