0906 | 当 AI 代理走进生产环境：从调试到门禁

茉莉: 大家好，欢迎收听今天的节目，我是茉莉。

白桦: 我是白桦。今天我们还是从 Product Hunt 最近一天的上线里挑了几款有意思的产品来聊，但这期有一个很自然的线索：AI 代理现在真的很能干，能写代码、能干活，但问题也越来越明显——它们不太会刹车，也没有真正的记忆，出了事你怎么知道它干了什么。

茉莉: 对，所以今天前半段我们聊几款给代理"装约束"的工具，中间会过渡到在 push 之前怎么审查它们写的代码，后半段再转到几个完全不同方向的小工具——日记、家庭声音、通勤、片单，最后是两个创作类的产品。我们一条一条来。

白桦: 那就从 Ponytail 开始吧。这个名字挺逗的，官方形象是一个面无表情、扎马尾戴眼镜的资深开发者，写一行代码，能跑，不说话。它本质上是给编码代理装的一个插件，核心主张是：让代理写"能工作的最少代码"。

茉莉: 它的机制是一条阶梯，代理在写代码之前要逐级往下问：第一，这东西真的需要存在吗？如果是投机性的需求，直接跳过，就是 YAGNI 那套。第二，仓库里是不是已经有现成的 helper 或者模式可以复用？第三，标准库能不能干这个活？第四，原生平台特性行不行——他们举的例子是，用一个 date input 元素，而不是引一个日期选择器库。第五，已经装了的依赖能不能解决？如果能，用那个，不要再加新的。第六，能不能写成一行？走到最后一级，才允许写新代码，而且是最少能工作的量。

白桦: 他们给了一个基准数据，说是十二个功能任务，在一个 FastAPI 加 React 的仓库上跑的中位数：代码量少 54%，token 少 22%，成本降 20%，速度快 27%，而且声称安全性没有任何简化。当然，这些是开发者自己的说法，我们没有独立验证过，听众可以当作一个声称的结果来听。

茉莉: 而且有意思的是它的定位。作者自己在帖子里说，去年很多工具的思路是把模型包进更多的流程里，而这个插件反其道而行——一旦模型已经能交付功能了，更难的部分是让它"停下来别再建了"。他还开了个玩笑说，/ponytail ultra 是留给"你的代码库曾经伤害过你"的时刻，是个 YAGNI 极端主义模式，只交一行代码，同时还要质疑需求本身。

白桦: 评论区确实有不少真实的使用者反馈。有一位说在 Claude 上用了一段时间，感觉代理变得更专注、更精简、不那么容易过度设计了。也有人问了一个很尖锐的问题：如果标准库里那个"现成的函数"只是接近匹配，不是完全一致呢？比如边界情况的处理不一样、返回类型略有不同，插件会不会逼着代理强行套用错误的工具，只为少写几行代码？"复用"本身有时候反而会引入比新代码更隐蔽的 bug。这个问题我看了，帖子里没有正面回答，这算是一个真实的开放问题。

茉莉: 对，这也是它整个哲学的软肋所在——"最少代码"是个好目标，但什么时候复用是安全的，什么时候是偷懒，这个判断本身很难。社区里还有人问会不会省 token、会不会更快完成任务，作者的隐含假设是找到现成代码比从零生成快，但同样没有严格的对比数据。

白桦: Ponytail 管的是"少写"。那 Reflexio 管的是另一个维度：让代理从已经发生的事里学习。它的创始人是 Yi，之前在 Meta 做过技术负责人，也在华盛顿大学教过机器学习。他们的出发点是：人们每天都在用 AI 代理，但代理不会因为使用而变好。就算有记忆功能，昨天失败的任务，今天换个用户还是以同样的方式失败——因为没有任何东西把生产环境里发生的事，连接回代理下一次的行为。

茉莉: Reflexio 做的事情是：自主观察代理的实时 trace，从成功、失败和用户纠错中提取"学习"，然后持续优化代理的行为。关键是，每一个学习都是可见的、可测试的、可撤销的。他们给了案例数据：任务失败率降了 36%，token 用量省了 57%，47% 的交互里回复质量有提升，回归"可忽略"。同样，这些是他们自己报告的数字。

白桦: 官网上有个挺直观的例子。用户问"我卡上有一笔 49.99 美元的 charge 我不认识"。没有 Reflexio 的代理回复"我已经退了 49.99"，结果十分钟后用户又回来："还有一笔 9.99 的。"两次对话才解决。有 Reflexio 的代理会先搜整个最近 charge 的窗口，把两笔不认识的 charge 一次列出来问要不要一起退，一次搞定。它从这个案例里学到的规则是两条：解决任何单笔争议之前，先搜全部最近的 charge；把所有不认识的一起呈现，一起问。

茉莉: 它的学习机制值得展开说说。第一条是自改进循环：每次对话都会喂回去，发现反复出问题的地方，把它变成一条学习，而且当新的对话和旧学习矛盾时，旧学习会被退役。他们举的例子是三月份学到"退款窗口 30 天，退款前确认订单"，六月份政策改成 14 天，三月的旧学习就不再使用了。第二条是自调优：每条学习会被它实际产生的证据持续修订——它帮助了哪些会话、在哪些会话里失效了，从这些真实案例里重写。

白桦: 还有验证和控制。每条学习在投入使用前会对照一个对照响应打分；开发者可以打开任何一条学习，看它包含什么、背后的证据是什么，可以重写、批准、拒绝或者删除，拒绝的那条立即停止被检索。想要代理只用你签过字的学习？那是一个设置。集成上，它提供了给 Codex、Claude Code、Cursor 用的 skill 链接，也有 Python、REST、CLI，号称不需要重写代理，用轻量 SDK 包住现有的 LLM 调用就行。

茉莉: 但评论区的问题很值得注意，因为好几个都没有得到回答。有人问：当一个用户的"纠正"其实是坏建议呢？比如用户自信满满地把代理推向了错误的答案，然后这个纠错被泛化成一条规则，应用到所有用户身上——有没有置信度阈值？是不是每条泛化规则都需要人工签字才能从"一个人的模式"变成"所有人的默认行为"？还有人问它怎么处理不同用户之间的冲突反馈、是按用户学还是全局学，以及"可忽略的回归"到底是怎么测量的、有没有 eval 机制。

白桦: 这些问题共同指向一件事：从人类反馈里自动泛化规则，本质上是在放大某一次交互的权重。机制设计得再透明，泛化错误的那条规则如果刚好通过验证，它的危害也是被系统化放大的。创始团队倒是交代了背景——他们之前在公司里做个性化服务和 AI 代理的记忆基础设施，亲眼看到这种学习基础设施需要多大的工程投入，只有少数公司养得起专门的平台团队，所以想把这件事产品化给普通团队用。这个动机是可信的，但上面那些治理问题确实还悬着。

茉莉: 从"让代理学习"再到第三个：dif.sh，管的是开关。创始人大卫讲了一个特别有共鸣的起点：他让 Claude Code 给项目加功能开关，结果代理走到了大多数开关工具都需要注册账号、拿 API key 的那一步，直接放弃了，最后自己写了个 process.env.SHOW_NEW_CHECKOUT 完事。这个故事本身说明了很多——代理没法替你穿越注册墙。

白桦: 所以 dif 的方案是：每个功能开关或 A/B 测试就是一个 markdown 文件，放在仓库里，跟它控制的代码待在一起。文件里写清楚这个开关做什么、为什么存在、你决定了什么，然后在 PR 里像任何其他改动一样被审查。一条命令安装，不需要账号，不需要 API key。dif init 还会在 agents.md 里加一些指令，并且每次构建时生成一个 context.json，让代理知道哪些 flag 存在、哪些被删了、哪些已经试过了。A/B 测试也住在同一套文件里，就算你还没准备好跑实验。

茉莉: 细节上它做得挺完整的。配置文件里可以声明受众属性，然后按国家、套餐、是否回访用户做 include 和 exclude，值在运行时到达，不会把任何客户数据提交进仓库。dif build 会解析排除图，当两个活跃测试会在同一个用户身上碰撞时直接拒绝编译——在 CI 里爆掉，而不是在生产里爆掉。还有 exclusion group 这一行 frontmatter，保证一个用户不会被同时分进两个实验。dif conclude 会把实验文件归档、起草决策块、往 surface 日志里追加一行，让下一个实验从你已学到的东西开始。想自己管数据的话，可以走 dif init --events custom，把事件转发到 Segment、Amplitude 或者你自己的数仓。

白桦: 自托管版本免费，云版本是用于跨项目查看和让 dif 提议改动，但那些改动还是回到 PR 里来，git 始终是事实来源。评论区对它最常见的认可就是"一条命令、不要账号"这部分——有人说这是让编码代理真正能完成配置而不撞上注册墙的关键。也有人喜欢把开关和它背后的理由放在同一个文件里，因为这种上下文通常几周后就消失了。

茉莉: 但有一个批评非常实在，作者当时是主动请求"批评版本"的反馈，有人就真的给了：flags 进 git 意味着翻转一个开关需要一次提交、一次审查、一次部署。团队付钱给开关服务，买的就是凌晨两点不用走任何流程的紧急开关。对面向代理的 flags 来说这是个合理的取舍，对灰度发布或者事故响应来说就不是了。这位还指出，markdown 也解决不了死 flag 的问题——因为没人改文件就没人审查它，四个月没人碰的 flag 还在生产里分支着代码。

白桦: 这个批评我觉得站得住。它其实把 dif 的定位说清楚了：这是一个为"代理友好的、变更即代码"的场景设计的系统，而不是替代 LaunchDarkly 那类运营工具。另外社区里还有实际的工程问题：两个人同时编辑同一个 flag 文件怎么办、两个并行分支的代理都碰同一个 markdown 文件会不会冲突——看起来就是普通的 git merge 冲突，没有特殊处理。

茉莉: 好了，到这里你可能会发现一个共同的主题：Ponytail 是停下的规则，Reflexio 是从经验里学习的记忆，dif 是带着上下文的开关——它们都在回应同一个现状：代理很强，但缺约束，而且产出速度远超人类审查速度。那就自然引出下一个问题：在 push 之前，谁来审查代理写的东西？

白桦: GitWarren 就是回答这个问题的。它是一个本地运行的、类 PR 的代码审查应用，但工作对象是你的工作区，不是远程仓库。作者是个干了十五年的职业程序员，他说自己每天要在五到七个并行的 AI 会话之间跳，瓶颈就是审查流程——而且是在哪里审查。他的环境里不能把一坨一次成型的东西直接推到公司 GitHub 上，推过去的东西得差不多能接受同事审查才行。所以他一直在终端和 IDE 之间来回复制粘贴对代理改动的评论。

茉莉: 他想要的是"本地的 GitHub"——GitHub 的审查体验，但发生在提交之前、发生在自己电脑上。GitWarren 做到的就是：找到分支检出所在的工作区，不管它在磁盘哪个角落，把已提交、已暂存、未暂存、甚至未跟踪的文件全部折叠成一个你可以读、可以评论的 diff。那个被代理创建但从未 git add 的文件，也能在它成为一次提交之前被审查、被评论。

白桦: 代理不只是被审查的对象，也是参与者。GitWarren 带一个通过 stdio 的 MCP 服务器，把 Claude Code、Codex 或者任何 MCP 客户端接上之后，代理能拿到应用自己用的那十七个工具：开审查、读全部讨论、在话题里回复、在某一行留评论、解决某条评论。你可以让代理解释它自己的 diff，或者回答你留在第四十行的问题——答案就留在审查里。

茉莉: 有几个设计细节体现了作者的谨慎。第一，机器写的评论永远被标注为机器评论，工具的名字来自 MCP 握手，而不是模型自己给自己起的称呼。第二，每个 MCP 会话有自己的 id，两个代理同时工作也能在话题里被区分开，不需要它们互相配合。第三，权限是不对称的——你可以编辑或删除审查里的任何东西，但代理只能改它自己的消息，不能悄悄重写你的。

白桦: 架构上是彻底的本地派：没有账号、没有登录、没有任何服务器，所有分支名、提交和 diff 都是从 git 实时读取的，没有缓存就不会过期。你的评论和审查存在应用数据目录里的一个 SQLite 文件里，删掉它 GitWarren 就消失了，仓库不受任何影响。免费开源，GPL-3.0 协议，macOS 上 brew install 就能装，Windows 和 Linux 也有，Windows 的还没签名。

茉莉: 评论区有一个人问了个很实际的问题：他自己是一个代理任务开一个 git worktree，而不是多个代理共用一个工作区，GitWarren 能不能同时审查同一个仓库的多个 worktree，还是每个实例只能对应一个工作区？如果是后者，这是有意为之还是没顾上？帖子里没有看到回答。另一个人问的是，五个到七个并行会话里如果有两个碰了同一批文件，它会不会只是把工作区显示成一个平的 diff，分不清哪个改动是谁的，还是能在审查阶段之前就标出"这两个编辑要撞了"。从产品的描述看，会话 id 能区分讨论的归属，但编辑冲突的预警似乎不在范围内。

白桦: 不过这些问题不掩盖它填的那个缝隙。它跟前面三款是同一条逻辑链的最后一环：代理产出又多又快，人工把关必须发生在提交之前——Ponytail 让代理少写，dif 让变更带着上下文走，GitWarren 让你在本地、在 push 之前把住最后一道。

茉莉: 好，我们从开发工具切换一下频道，聊几个个人生活类的小工具。第一个是 at8pm，一个叫"你的诚实日记"的 iPhone 应用。核心机制一句话就能说清：你今天写的每一条日记，会在你设定的时间——默认晚上八点——锁定。锁了就是锁了，不能编辑，不能重写历史，不能悄悄润色你当时真实的感受。

白桦: 做这个的动机，创始人说得很直白：他想捕捉"我当时的真实感受"，而不是"我后来回忆起来的感受"。大多数日记应用允许你编辑、重写、删除任何东西，这有用，但同时也让人太容易在不知不觉中重写自己的历史。这就是 at8pm 要解决的问题。

茉莉: 隐私上它是这么做的：条目通过你自己的私人 iCloud 在设备间同步，从不经过第一方或第三方服务器。App Store 页面上开发者标的是"不收集任何数据"。除了打字，你还可以录语音笔记，或者拍一个"Square"——square video 的意思，就是方形的短视频笔记——还能加照片和位置。有一个锁环显示今天还剩多少时间，配合连续记录的 streak。想分享的话，可以把任意一条变成设计好的卡片发到 Instagram Stories。

白桦: 这里有个值得诚实指出的妥协：锁定条目可以花"解锁积分"重新变回可编辑状态 24 小时，积分可以在应用内购买。这一点官方自己也说"完全是可选的，不是使用核心应用的必需品"。但我觉得这本身就是产品哲学上的一个裂缝——如果解锁花钱就能买到，那"不可改写"就不是绝对的诚实，而是一种默认设置。当然，从产品角度看，给真需要改的人留一个出口，总比让他们删掉重写好。免费版每天最多两条，Pro 订阅解锁无限条，价格从 0.99 到 29.99 不等。评论区有人问了个实际的问题：跨时区旅行时，锁定时间是跟着手机本地时间走，还是锚定在你设置它时所在的时区？还有人问有没有 Android 计划。

茉莉: 从"自己的声音"再进一步，就是 Retold——把家人的声音变成手绘的故事影片。创始人 Karl 的故事是这款产品的起点：他的奶奶几年前去世了，他还留着奶奶给姐姐的一段语音留言，还有几段她学着用 Alexa 的搞笑片段。听到她真实的声音很重要，但那些文件躺在手机文件夹里，感觉不像一个家庭会自然回去看的东西。

白桦: Retold 的做法是：你可以录一段新故事，或者导入旧的语音留言，它会保留真实的声音，同时把故事里的人、地方、小细节画成一部手绘小电影，加上一本可读的故事，一起放进"家庭书架"。官网的文案写得很有画面感——"故事不在于词句，而在于讲述它的那个声音。讲到精彩处之前的停顿，他们憋不住的笑。"家人递过手机，一个大红按钮，不用填表不用打字，故事就按他们一贯的讲法被录下来。还有那些保留在书架上的例子："Nan 掉进运河的那天"，爷爷讲的，奶奶持不同意见；"我们怎么认识的，1963"——舞厅、坐错的公交、对的那个姑娘。

茉莉: 它目前在 iPhone 上是 beta，Android 在封闭测试中。免费保留五个故事，订阅制，年费 39.99 英镑，约等于每周 77 便士，月付 5.99 英镑可以随时取消，订阅用户可以无限故事、全家人都能看，而且就算停止付费，故事也永远归你。这是创始人亲述的动机，情感上是很有说服力的。

白桦: 但评论区有一条批评我必须提，因为它问的正是这一类产品最脆弱的地方：这类应用的源素材往往是已经无法对后续用途表示同意的人的录音——特别是逝者的旧语音留言。实际的数据政策是什么？音频是被处理后删除，还是无限期存在服务器上，或者会被用在为这一个家庭生成影片之外的任何地方？这条评论写得很有分量，而且目前在源材料里没有看到回应。对于要把自己家最私密的声音交进去的用户来说，这不该是一个悬而未决的问题。

茉莉: 从家里的声音，转到门口的那辆车。CommuteBar 是一个 Mac 菜单栏应用，把实时通勤时间直接放在你随时能看到的地方。创始人的起源故事很生活化：有一天他准备开车出门，看了一眼路况觉得挺通畅，心想今天肯定能早到家。结果十五分钟后堵上了——那时他人已经在路上了。他意识到自己缺的是"视线之内的一个快速指示"，就放在他总是看的时钟旁边。

白桦: 具体功能上：实时通勤时间始终可见，路况变化时自动更新，不用打开地图应用。可以保存多个目的地，比如办公室、学校、健身房，按重复通勤自动切换，有"快出发了""现在出发"的指示和可选的通知。还有路线对比、拥堵提醒、不同出行方式。隐私上，位置数据留在你的 Mac 上，不需要账号或登录。macOS 14 以上，一次性买断，不是订阅。

茉莉: 评论区对它最大的认可就是"住在菜单栏里"这个选择——有人说，这把"我现在该不该出发"从一个需要打开应用的决定，变成了一眼扫过的事。还有人说"终身授权、不订阅"对这种小工具来说是件令人耳目一新的事。一个挺实际的问题没人回答：自动切换目的地的那天，如果中途有一站——比如先送孩子再去上班——它是按顺序显示下一个保存的目的地，还是得手动切换？另外还有人说自己现在的做法是人在电脑前、手机上开着 Waze，这款正好补上了那个空档。

白桦: 从出门，到回家以后看什么。Queuebrick 是一款观影记录应用，自述是"the Letterboxd alternative"——一个没有广告的 Letterboxd 替代品。搜索一部电影，评分，加入队列，排列接下来看什么。创始人 Zachary 说这是个热情项目，帮他记录电影，重点是没有广告和"真正用心的用户体验"，而且已经包含了电视剧，还有一个通用的导入功能，让你从几乎所有其他平台把看过的片子和剧带过来。

茉莉: 社区里最有意思的一条反馈是建议加一个"情侣或朋友的共享队列"：大家都可以往里加电影，然后投票决定下一部看什么，这样就不用花三十分钟争论选哪部了。另一位用户说，比起一个巨大但从没用过的 watchlist，一个聚焦的"接下来看什么"队列实用得多。还有一个很技术的问题：不同平台的评分体系不一样——Letterboxd 是五星半星制，IMDb 是十分制，有些就是竖大拇指——导入多年的评分时，是按比例换算保持相对排序不变，还是大致映射然后你得重新评一遍？这个也没看到答案。

白桦: 这几款放在一起，共同点其实挺清楚的：都是小而克制的个人工具，每款只为一件事做到位——锁定一段诚实，保存一个声音，告诉你什么时候出门，帮你决定今晚看什么。没有一款试图变成平台。

茉莉: 最后一组，回到创作，而且是两个"把繁琐的多平台流程压成一次操作"的例子。第一个是 BrickForgerAI，一句话描述：输入一段提示词，得到一个你真的可以拼搭的积木模型。注意"真的可以拼搭"这几个字，这是它和市面上大多数"AI 乐高生成器"的分水岭。

白桦: 创始人说得明白：他调研之后发现，大多数同类产品就是渲染一张好看的图片然后完事——那些你根本买不到零件、也拼不出来。所以他把真正的功夫放在了后端的积木放置引擎上：先把形状体素化，然后用真实的、可购买的零件去铺排，错开接缝让它不会像松散的堆叠一样裂开，再跑结构分析——连接图、重力负载——找出任何会散架的地方，自动修复之后才交给你。AI 图像和 3D 生成是"简单的、买来的部分"，真正的难题一直是积木摆放。

茉莉: 目前用的是 55 个零件的库，包括各种坡度和弧面，还在持续扩充，官方说在加侧向搭建（SNOT）之类的新技巧。输出的东西很实在：一个 .ldr 文件、完整的零件清单、一份分步 PDF 拼搭指南。官网声称大部分生成的模型能达到 100% 的连接率，在 BrickLink Studio 的稳定性检查器上只有少量标记问题。定价上免费计划每月 3 个积分，生成预览免费，只有下载 .ldr 文件才付费，还有小、中、大三种尺寸，15、22、30 studs。当然要说明，它和乐高集团没有任何关联，乐高是对方的商标。

白桦: 有一条社区反馈说得很到位：拿到 .ldr 文件、零件清单和分步 PDF，把结果从"你能看的东西"变成了"你能坐下来真的拼的东西"。另一位用户提了一个特别好的方向：零件成本估算，或者一个"用我已有的零件来拼"的模式——能对着自己的收藏说"用我的积木搭这个"，那这个想法就上了一个台阶。这两个目前都还只是用户的愿望，不是产品的功能。

茉莉: 最后一个是 PostBox，解决的是设计师发作品的问题。创始人 Jason 说自己喜欢在 Figma 里设计、为每个像素纠结，但讨厌的是把设计排版得对社交平台有吸引力这件事——为了曝光度不得不做。所以 PostBox 是一个设计暂存和发布工具：把 MacBook 的刘海变成一个拖放台，把导出的图拖上去，写一次文案，一键发布到 X、Bluesky、LinkedIn、Dribbble、Behance、Cosmos 这些平台——Threads、Instagram、Pinterest 还在开发中，现在登录账号的话，等它们上线当天就能开始发布。

白桦: 它的工作流是三步：拖进来，截图原封不动落进草稿；选一个外观——布局、设备、地面、内边距，所有改动实时反映在图上，相当于不用重新打开 Figma 就能"艺术指导"这条帖子；最后直接发布，构图本身就是附件，没有导出这一步。账号安全上它是这么处理的：你在各平台的页面上登录，PostBox 保存的是会话，永远不碰你的密码。免费版永久可用，每 30 天 5 条帖子，两张 Mac 共用一个授权；Pro 每月 9.99 美元或年付 119.88，无限帖子和账号，带 14 天试用。

茉莉: 有用户已经下载试过，说应用包括引导流程都很流畅，希望未来加定时发送和"视频加文字"的组合帖。还有一个很实际的技术疑问：X、Instagram、Pinterest、LinkedIn 对长宽比和字数限制的要求都不一样，PostBox 会不会按平台自动裁剪和裁短文案，还是所有平台用同一张图和同一段文字，接受某些平台被裁得有点别扭？这个问题在源材料里没有答案。另外有人问能不能为作品集或公告这类不同内容定制工作流，也没看到回应。

白桦: 不过这个产品跟 BrickForgerAI 放在一起看确实像一对：一个是把"从想法到真的能拼的模型"压成一次输入，一个是把"从导出到九个平台"压成一次拖放。都不是在 AI 上做文章，而是在 AI 之后的那段繁琐流程上做文章。

茉莉: 好了，今天从给代理装刹车、装记忆、装开关，聊到 push 之前的人工审查，再到四个小而克制的日常工具，最后是两个创作类的效率产品。有几条共同的开放问题值得我们带走：AI 生成的结果越自动化，"谁来为它把关"这个问题就越往前移——移到生成之前，移到提交之前，甚至移到一条学习规则被泛化之前。

白桦: 而所有这些工具，无论面向开发者还是普通人，评论区里最尖锐的问题几乎都是同一类：数据去哪了、错了怎么办、出了事能不能撤。能回答好这三个问题的，大概才是真正能留下来的产品。谢谢大家收听，我们下次见。

茉莉: 下次见！