Clawdbot（最近改名叫 Maltbot），目前最熱門的 AI 項目，不光是在 X 上「一夜成名」，在谷歌上的搜索量更是直接超過了 Claude Code、Codex。

X 上的網(wǎng)友制作了一張 Clawdbot 在 Github 的標星增長趨勢對比圖，幾乎是直線上漲，現(xiàn)在已經(jīng)到了 98K。

Clawdbot 背后的開發(fā)者 Peter Steinberger，是一個特別有意思的老哥。iOS 生態(tài)系統(tǒng)最早的一批開發(fā)者之一，開發(fā)經(jīng)驗可以追溯到 iOS 2.0 時代。在開源社區(qū)貢獻了非常多項目。

2011 年，Steinberger 創(chuàng)立了 PSPDFKit，用 13 年時間把它從開發(fā)者工具搞成了 B2B 軟件巨頭。以超過 1 億歐元的價格賣掉后，實現(xiàn)財富自由的 Steinberger 感到非常破碎、空虛，甚至通過排隊、派對、心理治療各種方式填補空虛。

于是，「退休」三年后，Steinberger 重新回來了。Steinberger 在最新采訪中提到，

早在去年五月份，我就有了做個人 Agent 的想法，那會兒 GPT-4 被 GPT-4o 替代，當時覺得模型還不夠好，但我當時又覺得，這事大公司未來幾個月肯定會做?？墒堑鹊搅?11 月，我發(fā)現(xiàn)市面上還是沒有我想要的個人智能體。 于是，我決定自己搞。這基本就是 Clawdbot 項目的起點了。

在最近的采訪中，Steinberger 分享了很多有趣的觀點：

• 今年將是「個人助理」之年。我感覺我喚醒了人們對它的真實需求。我認為每個人都應該嘗試構建一個 Agent，探索記憶機制。

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

• GUI 這東西很糟糕，擴展性不強。人們圍繞它做了各種奇怪的搜索功能，但真正具備擴展能力的應該是 CLI。

• 如果聰明一點，就應該按照模型已經(jīng)習慣的方式去構建工具，為模型設計，別為人類設計。

• 大多數(shù) MCP 都應該被做成 CLI。MCP 的存在更多是為了讓市場部門高興，唯一的好處是它能保持 state，但這種情況你極少需要。但 CLI 是可以調(diào)用并獲得返回的東西，而且是可組合的。

• 未來一大批應用會消失，提示詞就是新界面。因為你和事物的交互方式會變得完全不同，大多數(shù)應用會被簡化為 API。

• 你不再需要訂閱那些只提供通用功能的初創(chuàng)公司的服務。你擁有自己超個性化的軟件，它能精確解決你的問題，而且還是免費的。

??關注 Founder Park，最及時最干貨的創(chuàng)業(yè)分享

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

歡迎飛書掃碼加群：

進群后，你有機會得到：

• 可落地的 Skill 搭建方法

  從一個想法或一套 SOP，拆解成真正能跑起來的 Skill

• Skill 的展示與放大通道

  不只是自己用，而是被更多人看到、用到

• 被看見后的實際激勵

  好的 Skill，有機會獲得明確回報

01從解決自己的問題出發(fā)，

一個小時搞定原型

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

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

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

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

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

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

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

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

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

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

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

主持人：所以你其實是把手里已經(jīng)有的現(xiàn)成工具直接組合了起來？

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

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

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

它回復說：「你發(fā)來的消息里只有一個文件鏈接，沒有擴展名。我檢查了文件頭，發(fā)現(xiàn)是 Opus 格式，就用你 Mac 上的 FFmpeg 把它轉(zhuǎn)成了 Wave 格式。我想用 Whisper，但發(fā)現(xiàn)沒裝，安裝還報錯了。不過，我在你的環(huán)境變量里找到了 OpenAI 的密鑰，所以就用 curl 命令把文件發(fā)給了 OpenAI，拿到轉(zhuǎn)錄文本，然后才回復了你?！?/p>

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

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

022026 年，將是 Personal Assistant 之年

主持人：你的項目在一周內(nèi)經(jīng)歷了現(xiàn)象級的爆火，過去幾天你是怎么過來的？

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

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

從 Twitter 爆火，到我們的 Discord 服務器以我前所未見、無法處理的方式增長，各種事情接踵而至。到后來，我只能把 Discord 上的問題復制粘貼到 Codex 里，讓它生成回答。再后來，我干脆把整個頻道的內(nèi)容都扔進去，說：「回答這 20 個最常見的問題?！挂驗槿藗儧]意識到，這背后不是一個公司，只是一個在家圖個樂子的家伙。

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

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

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

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

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

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

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

03CLI First，Not GUI

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

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

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

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

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

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

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

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

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

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

04大多數(shù) MCP 都應該被做成 CLI

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

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

別人已經(jīng)寫了很多關于 MCPs 的文章了。在我看來，這大多是市場部門為了湊個功能清單好拿出去吹噓的東西。幾乎所有的 MCPs 其實都應該是 CLI 工具。這可是我這個自己寫過 5 個 MCPs 的人說的肺腑之言。

我完全可以直接按名字調(diào)用一個 CLI。在我的智能體文件里不需要任何解釋。智能體會在第一次調(diào)用時嘗試運行它，CLI 會展示幫助菜單，上下文里就有了關于它如何工作的所有信息，從此咱們就暢通無阻了。我不必為任何工具付出額外代價，不像 MCPs，在我的上下文中就是持續(xù)的成本和垃圾。用一下 GitHub 的 MCP，眼看著 23k Token 就沒了。天哪，他們確實優(yōu)化過了，因為它剛推出時幾乎要消耗 50k Token。或者直接用 gh cli，功能基本一樣，模型也知道怎么用，而且不需要交任何「上下文稅」。

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

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

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

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

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

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

05未來一大批應用會消失，

提示詞就是新界面

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

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

Steinberger 在社交平臺Mastodon 發(fā)布的帖子：

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

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

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

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

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

06Opus 是最好的模型，

Codex 編程是最靠譜的

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

07Agent 的開發(fā)范式很簡單：

Just Talk To It

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

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

以下是他的部分博客內(nèi)容：

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

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

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

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

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

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

常用的 Slash Commands

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

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

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

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

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

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

還有什么其他技巧？

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

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

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

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

Just Talk To It

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

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

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

轉(zhuǎn)載原創(chuàng)文章請?zhí)砑游⑿牛篺ounderparker