Clawdbot开发者：未来一大批应用都会消失，提示词就是新的interface

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

X 上的网友制作了一张 Clawdbot 在 Github 的标星增长趋势对比图，几乎是直线上涨，现在已经到了 98K。

Clawdbot 背后的开发者 Peter Steinberger，是一个特别有意思的老哥。iOS 生态系统最早的一批开发者之一，开发经验可以追溯到 iOS 2.0 时代。在开源社区贡献了非常多项目。

2011 年，Steinberger 创立了 PSPDFKit，用 13 年时间把它从开发者工具搞成了 B2B 软件巨头。以超过 1 亿欧元的价格卖掉后，实现财富自由的 Steinberger 感到非常破碎、空虚，甚至通过排队、派对、心理治疗各种方式填补空虚。

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

早在去年五月份，我就有了做个人 Agent 的想法，那会儿 GPT-4 被 GPT-4o 替代，当时觉得模型还不够好，但我当时又觉得，这事大公司未来几个月肯定会做。可是等到了 11 月，我发现市面上还是没有我想要的个人智能体。 于是，我决定自己搞。这基本就是 Clawdbot 项目的起点了。

在最近的采访中，Steinberger 分享了很多有趣的观点：

• 今年将是「个人助理」之年。我感觉我唤醒了人们对它的真实需求。我认为每个人都应该尝试构建一个 Agent，探索记忆机制。

• 「我们要做一个能独立跑 20 个小时的东西」，对我来说有点像个虚荣指标。我的瓶颈从来不是让智能体跑得更久，真正的瓶颈通常是我自己：我的提示词，以及我下一步该让它做什么的思考。

• GUI 这东西很糟糕，扩展性不强。人们围绕它做了各种奇怪的搜索功能，但真正具备扩展能力的应该是 CLI。

• 如果聪明一点，就应该按照模型已经习惯的方式去构建工具，为模型设计，别为人类设计。

• 大多数 MCP 都应该被做成 CLI。MCP 的存在更多是为了让市场部门高兴，唯一的好处是它能保持 state，但这种情况你极少需要。但 CLI 是可以调用并获得返回的东西，而且是可组合的。

• 未来一大批应用会消失，提示词就是新界面。因为你和事物的交互方式会变得完全不同，大多数应用会被简化为 API。

• 你不再需要订阅那些只提供通用功能的初创公司的服务。你拥有自己超个性化的软件，它能精确解决你的问题，而且还是免费的。

⬆️关注 Founder Park，最及时最干货的创业分享

Founder Park 联合扣子，举办了一场 Skill 招募大赛。如果你手里有一套在用、能交付结果的方法论，很适合来试试！

欢迎飞书扫码加群：

进群后，你有机会得到：

• 可落地的 Skill 搭建方法

  从一个想法或一套 SOP，拆解成真正能跑起来的 Skill

• Skill 的展示与放大通道

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

• 被看见后的实际激励

  好的 Skill，有机会获得明确回报

01从解决自己的问题出发，

一个小时搞定原型

主持人：你是怎么开始做 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 费用还是会让你稍微考虑一下），但通常这些都会被忽略。你只是在和一个朋友，或者说一个「幽灵」交谈。

022026 年，将是 Personal Assistant 之年

主持人：你的项目在一周内经历了现象级的爆火，过去几天你是怎么过来的？

Steinberger：从睡眠上来说，很糟糕。但这也无比令人兴奋。我认为去年是「编程智能体」之年，而今年将是「个人助理」之年。我感觉我唤醒了人们对它的真实需求。

我不知道 Clawdbot 是否是最终答案，但它应该为人们指明了方向。我敢肯定这个领域会出现大量产品，也肯定有很多人正在疯狂地开发。这将是一个非常有趣的领域。

从 Twitter 爆火，到我们的 Discord 服务器以我前所未见、无法处理的方式增长，各种事情接踵而至。到后来，我只能把 Discord 上的问题复制粘贴到 Codex 里，让它生成回答。再后来，我干脆把整个频道的内容都扔进去，说：「回答这 20 个最常见的问题。」因为人们没意识到，这背后不是一个公司，只是一个在家图个乐子的家伙。

当然，你看代码提交记录，可能确实像个公司。但这只是因为现在的智能模型太强大了，如果你能驾驭它们，理解它们的「语言」，一个人就能达到一年前一个团队的产出。

主持人：你的项目可以让用户轻松切换使用所有模型，包括他们的竞争对手。他们是什么反应？

Steinberger：我这个项目的一个前提就是，每个模型都应该能用，包括本地模型。对我来说，这是一个游乐场，一个绝佳的学习方式。我认为每个人都应该尝试构建一个智能体循环，探索记忆机制，这里面有很多有趣的方面。我把它设计成插件化的，这样人们就可以专注于自己的小模块，而不用去动整个核心。这有点像 AI 黑客的天堂，而且因为它是个性化的，所以非常有趣。

主持人：现在很多人都在追求那种能独立运行几十个小时的超长任务智能体。你怎么看这个方向？

Steinberger：我觉得，那种「我们要做一个能独立跑 20 个小时的东西」的思路，对我来说有点像个虚荣指标。我的瓶颈从来不是让智能体跑得更久，真正的瓶颈通常是我自己：我的提示词，以及我下一步该让它做什么的思考。

我更喜欢一种参与感更强、更迭代的方式来构建软件。我希望自己能 in the loop，随时测试它正在构建的东西，看看方向对不对。比如，当它在帮我写一个网页服务时，我给它一部分需求，就能亲眼看着这个功能在浏览器里一点点成形。这个过程本身就会激发我的新想法，让我知道接下来还能加点什么、可以往哪个方向走。我可以随时去点一点，去感受它。

这种迭代的开发方式，远比你坐下来从理论上把一个功能规划到完美要好得多。因为等你真的把它做完了，你又会有新的想法了。所以，长时程运行当然是一个值得探索的方向，但在今天的实际应用里，它根本不是瓶颈所在。

03CLI First，Not GUI

主持人：去年大家都在聊 Agent，但焦点好像都在浏览器上。我用了Clawdbot之后，感觉大家都搞错方向了。如果能直接跟一个跨所有应用的智能体对话，谁还关心浏览器呢？

Steinberger：是的。我在做这个项目之前，大部分的准备工作就是构建各种小巧、独立的命令行工具（CLI）。我的前提是：图形用户界面（GUI）这东西很糟糕，扩展性不强。人们围绕它做了各种奇怪的搜索功能，但真正具备扩展能力的是命令行。智能体天生就懂 Unix 系统，你可以在电脑上放一千个小程序，它们只需要知道程序的名字，调用一下帮助菜单，就知道该怎么用了。

如果聪明一点，就应该按照模型已经习惯的方式去构建工具，为模型设计，别为人类设计。比如，如果模型习惯调用 --log 参数，那你就构建一个 --log 参数。这是一种「智能体驱动」的开发思路，你按照它们的思维方式去构建，一切都会顺畅得多。在某种程度上，是一种全新的软件。

所以，对大多数事情我都不需要浏览器。我为谷歌服务、Sonos 音响、摄像头、家庭自动化系统都构建了相应的工具。每增加一个小小的命令行工具和技能，我的智能体就变得更强大、更有趣。到我开始做 WhatsApp 集成的时候，这些功能很多都已经有了，我就是这样被迷住的。

但有个问题，我觉得这东西很神奇，可当我在 Twitter 上讨论它时，反响却很平淡，感觉人们没有理解它的价值。但我把它展示给我的朋友，包括那些非技术背景的朋友，他们都抢着想要。所以我知道，我做对了方向，只是科技圈的人还没反应过来。

我一直在持续开发，因为我自己也在用，我就是为自己做的。这是一个开源项目，我的动机是寻找乐趣、激励他人，而不是为了赚大钱，因为我已经有很多钱了。

主持人：我同意你的看法，确实很奇怪为什么没有更多公司在做个人化智能体。我也能预见到，在不久的将来，每个人口袋里都会有一个个人化智能体，作为他们的助理。

但我想问，这么强大的个人助理，肯定要给它很多权限，比如摄像头、邮箱。你是怎么平衡这种便利和它带来的巨大安全风险的？

Steinberger：好问题，当你用 ChatGPT 或者 Claude 时，它们本身就有集成功能。大多数人早就把邮件、日历、Google Drive 都授权给它们了。所以，这些模型已经掌握了我们的数据，这是一个既成事实。

我给我的 Claude 一个可以访问 Gmail 的 MCP，和你直接在 Claude 官网上添加 Gmail 集成，这两者之间没有任何区别。实际上，我认为直接在官网集成风险更高，因为你根本无法控制它在后台做什么。但如果它运行在我的电脑上，我至少还能看到日志。所以，我甚至觉得，直接把所有权限交给那些大公司，比通过我的系统来授权更危险。

04大多数 MCP 都应该被做成 CLI

主持人：MCP 这个话题最近在工程师圈子里也很有争议。你怎么看？

Steinberger 此前曾在一篇博客文章中谈论他对于 MCP 的看法：

别人已经写了很多关于 MCPs 的文章了。在我看来，这大多是市场部门为了凑个功能清单好拿出去吹嘘的东西。几乎所有的 MCPs 其实都应该是 CLI 工具。这可是我这个自己写过 5 个 MCPs 的人说的肺腑之言。

我完全可以直接按名字调用一个 CLI。在我的智能体文件里不需要任何解释。智能体会在第一次调用时尝试运行它，CLI 会展示帮助菜单，上下文里就有了关于它如何工作的所有信息，从此咱们就畅通无阻了。我不必为任何工具付出额外代价，不像 MCPs，在我的上下文中就是持续的成本和垃圾。用一下 GitHub 的 MCP，眼看着 23k Token 就没了。天哪，他们确实优化过了，因为它刚推出时几乎要消耗 50k Token。或者直接用 gh cli，功能基本一样，模型也知道怎么用，而且不需要交任何「上下文税」。

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 的沙箱，要么使用容器。这些问题都是可以解决的。

05未来一大批应用会消失，

提示词就是新界面

Steinberger：同时，我还观察到的一个非常有趣的现象是：一大批应用将会逐渐消失。比如，我为什么还需要 MyFitnessPal 这种健身应用？我只要拍张食物的照片，我的智能体已经知道我正在麦当劳做一个糟糕的决定。结合这些信息，它能完美匹配出我吃了什么，甚至可能会反过来调整我的健身计划来确保我还能达标。所以，我不再需要那个 App 了。

一大批应用都会消失，因为你与事物的交互方式会变得完全不同，大多数应用会被简化为API。接下来的问题是，如果我可以把数据存在别的地方，我甚至还需要那个 API 吗？

Steinberger 在社交平台Mastodon 发布的帖子：

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

主持人：这个转变听起来很颠覆。但你觉得非技术背景的普通人，真的会为了这个去自己折腾部署这些东西吗？门槛会不会太高了？

Steinberger：我刚参加完一个线下聚会，碰到一个来自印第安纳州的设计机构的人，他没有写过一行代码。他说他去年 12 月初就发现了我的项目，然后开始使用 Clawdbot。

他说：「我们现在已经有了 25 个网络服务，我们可以为自己需要的任何东西构建内部工具。」他完全不懂代码，他只是通过 Telegram 和他的智能体交谈，然后智能体就为他构建东西。

所以，这里有一个巨大的转变：你不再需要订阅那些只提供通用功能的初创公司的服务。你拥有自己超个性化的软件，它能精确解决你的问题，而且还是免费的。非技术人员也在这样做，因为它非常自然。你只需要说出你的问题，然后这个东西就会为你构建解决方案。而且别忘了，现在的模型是它们有史以来最差的状态，未来只会变得越来越好，越来越简单，越来越快。

06Opus 是最好的模型，

Codex 编程是最靠谱的

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

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：相比于公司，我更倾向于成立一个基金会或者非营利组织。不过，我还没下定决心。

07Agent 的开发范式很简单：

Just Talk To It

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 只是意味着，我们对交付成果的期望值变高了。

转载原创文章请添加微信：founderparker