项目开源地址：GitHub - FerryCat · 真实三模型互审轨迹存档：real-mesh-trajectory.json
前篇回顾：📖 做东西变快了，钱却更难挣了：AI 正在抽空组织的腰部骨干
这几天我新开了一个叫 FerryCat 的开源项目。
很多朋友看到名字里的 Cat，以为我又在给之前的端侧 AI 工作流编排 工具加新画布。其实完全不是一回事。FerryCat 没有炫酷的图形界面，它甚至只干一件听起来极其朴素的事：在我的同一台电脑上，帮两个互不相通的 AI 编程窗口“递纸条、审代码”。
这篇文章我们少聊甚至不聊底层代码细节，只聊聊一个真实的日常开发痛点：为什么我已经有了现成的 AI 编程工具，却还是被逼着自己动手做了一条“工单摆渡船”？
一、 起因：不要让同一个 AI 批改自己的作业
在推进日常开发时，我一直依赖 AI 辅助编程和“边写边学”的工作流。但只要你用 AI 写过稍微复杂一点的项目，一定踩过同一个坑：让刚写完代码的模型去审查它自己写的代码，基本等于白审。
这就像让学生自己批改自己的考卷。模型在写下那段代码的时候，它的上下文和思维惯性已经滑进了特定的轨道里。它漏掉的边界条件，你在同一个对话框里问它十遍“有没有问题”，它依然会满口答应“逻辑严密、没有遗漏”。
怎么破除这种同源盲区？最管用的土办法，就是“换个人审”。
于是在我的电脑桌面上，日常变成了双开甚至多开模式：左边开着最擅长全局推理的主力模型负责写代码、搭骨架；右边开着 Codex、Antigravity 或者 WorkBuddy，里面挂载着 DeepSeek、Step-5、Hy3 等不同厂商的模型，专门当“挑刺的独立审计员”。
思路很丰满，但真正这么干了两天之后，我发现自己沦为了一个全职的“人肉剪贴板搬运工”。
二、 痛点：当你在两个窗口之间来回切换时，灾难发生了
没有工具协助的时候，想让左边的窗口 A 写完代码、交给右边的窗口 B 审查，你只能靠双手硬扛三个极其折磨人的问题：
1. 复制粘贴到手软，两边都在白烧额度
改完三个文件，我得在左边窗口把背景说明、修改意图、几百行源码全选复制，切到右边窗口粘贴进去；等右边审完了，再把那一大坨审查意见复制回来，粘给左边去改。几百行代码在两个窗口的聊天框里来回塞，不仅经常因为超长被截断，两边的对话额度更是哗哗地重复消耗。
2. 最隐蔽的坑：在旧文件上“一本正经地胡说八道”
为了省掉复制代码的麻烦，我试过直接对右边窗口说：“代码就在电脑硬盘的某某目录里，你自己去读那个文件并审查。”
结果灾难来了。
有好几次，左边窗口刚改完代码，编辑器的缓存还没来得及存盘；或者左边窗口正在顺手改另外两行；又或者我刚切了一下分支。右边的审查模型根本不知道外面的变化，它读着硬盘里五分钟前的旧文件，一本正经地挑了半天毛病，给出了一份看起来专业无比、实际上完全驴唇不对马嘴的审查报告。
这种旧文件静默盲审比直接报错可怕得多——它不弹窗、不告警，却直接把你和主力模型带进沟里。
3. 写两千字小作文，就是不给准话
你让右边的模型审代码，它往往极其热情地给你输出一篇两千字的长篇散文：先夸奖一番代码结构清晰，再列举七八条不痛不痒的风格建议。把它粘回左边窗口，开发模型看懵了：到底算通过还是不通过？哪几条是必须改的硬伤，哪几条只是顺嘴一提？两边经常在咬文嚼字里陷入无休止的拉锯。
三、 关键节点共创：向物理限制低头，做一个诚实的工具
被折磨了无数次之后，我和 AI 搭档坐下来盘需求：能不能利用现有的本地工具协议，在电脑上搭一座桥，让两个窗口直接交接审查工单？
在项目实施的关键节点上，我们经历了一次非常彻底的“去幻想化”碰撞：
我从日常使用的痛点出发，提了三个产品硬要求：
- 不准再让我贴代码：派单只传文件路径和行号，让审查窗口自己去硬盘读，省心省额度；
- 绝不允许审错版本：如果硬盘上的文件和派单那一刻对不上，或者编辑器刚改完还没存盘，宁可当场报错废掉工单，也绝不准在旧代码上瞎审；
- 交卷必须填标准表格：不看两千字散文，交单时必须按规定格式给出明确的“通过/不通过”和逐条修改清单，格式不对直接打回重写，连续两次写不对就强制终止，别在那儿死循环烧钱。
而 AI 搭档则给我泼了一盆关键的冷水，指出了桌面软件的物理铁律： 当时我原本幻想做一套“全自动流水线”——左边窗口一派单，右边窗口自动从后台惊醒、自动审完、自动把结果推回左边。AI 直接帮我证伪了这个设想：你电脑上开的这几个 AI 编程软件，彼此是完全隔离的独立程序，而且它们全都是被动触发的。你不敲回车跟它说话，没有任何后台服务能强行把一个闲置的聊天窗口叫醒；如果强行让插件在后台卡着等 60 秒，只会直接触发客户端的超时报错。
这次碰撞彻底定下了 FerryCat 的产品性格：人做窗口触发，工单总线兜底契约。
| 协同方式 | 跨窗口上下文传递 | 代码版本一致性保障 | 审查结果交付形态 | 真实操作体验与代价 |
|---|---|---|---|---|
| 纯手工复制粘贴 | 全文塞进剪贴板，极易截断且双倍耗费额度 | 靠人眼盯，经常漏拷文件或粘错版本 | 自由散文，需要人工提炼重点 | 切十几次窗口，人沦为纯体力搬运工 |
| 口头让对方直接读硬盘 | 省去复制代码 | 零保障：极易读到未保存旧文件或被中途篡改的文件 | 自由散文，优缺点混杂 | 表面省事，一旦发生“旧代码盲审”排查代价极高 |
| FerryCat 契约工单摆渡 | 仅传文件路径与行号引用 | 双重快照锁死：派单、领单、交单全程核对文件指纹 | 强制按表格交卷（明确过/不过 + 整改项） | 需人工切 3 次窗口触发，换取 100% 确定性交付 |
在 FerryCat 的 Demo 里，日常工作流变成了清爽的三步：
- 我在左边的主力编码 Agent 里说一句：“发张审查工单。” FerryCat 自动给硬盘上的目标文件拍下快照，并把文件第一行和最后一行亮出来确认没有忘存盘；
- 我按一下快捷键切到右边的独立审查 Agent，说一句：“领单审代码。” 它自动抢下工单，核对硬盘文件一字未改后，就地读文件、按规定表格交卷；如果在它审代码的这几分钟里我手欠改了原文件，交卷那一刻工单会直接作废，绝不让脏结论蒙混过关；
- 我切回左边窗口：“看下审查结果。” 一份结构清晰、逐条对齐的体检报告直接摆在眼前。
四、 证明它真实存在：用 FerryCat 审 FerryCat 自己
市面上很多开源项目停留在概念图和演示文稿里。为了证明 FerryCat 解决的是真问题，最好的办法就是吃自己的狗粮：在 FerryCat 第一个版本刚跑通的那天晚上，我立刻用它做了一次真实的跨窗口实战。
我在左边的主力开发窗口里，针对 FerryCat 自己的核心代码连发了 3 张真实审查工单；然后切到右边的独立审查窗口，分别让挂载在里面的三个不同模型（Deepseek-V4.1-Flash、Step-5-Preview、Hy3）各自领走一张工单进行独立盲审。
这批真实的工单轨迹完整保存在代码库的 docs/real-mesh-trajectory.json 里。几分钟后，三个外部模型通过 FerryCat 交回了三份结构化工单，实打实地抓出了我们在编写时漏掉的 9 项边界漏洞：
- 一号审查员（
Deepseek-V4.1-Flash，耗时 241.5 秒）一针见血地指出：你们只在“领单”那一刻检查了文件有没有被改过，万一审查员读了四分钟代码，这期间主窗口把文件改了，最后交上去的结论不还是错的吗？必须加上“交单前二次验明正身”；同时它还抓出了命令行参数行号可能超出文件总行数的漏洞。 - 二号审查员（
Step-5-Preview，耗时 354.1 秒）盯上了我们的交卷核验逻辑：如果模型交上来的不是标准表格而是一个数组列表，原有的类型检查会被绕过去；而且每次交卷都重新编译一遍规则太慢，应该把规则缓存起来。 - 三号审查员（
Hy3，耗时 463.6 秒）则从外围入口找出了防守缺口：我们的插件接口做了严格的参数限制，但配套的命令行小工具却忘了套上同一层限制；如果有人一次性塞进几百个文件路径，或者漏填了身份参数，系统就会静默出错。
看着这三张带着真实时间戳、文件指纹快照和整改清单的工单稳稳落进本地记录里，然后由主窗口逐条修复合入，那种踏实感是单开一个窗口自嗨完全给不了的。如果没有这套跨宿主互审机制，这 9 个隐蔽的坑大概率就会原封不动地留在代码库里。
五、 诚实交代代价：什么情况下你绝对不该用 FerryCat？
作为一个在真实桌面环境里长出来的工具，把它的短板和代价摆在明面上，比吹嘘功能更重要。FerryCat 把跨窗口工单交接做成了一套强约束的 确定性工作流，但它绝非万能药，以下三种情况请直接绕道：
- 三句话就能聊完的简单问题，别用它： 因为桌面软件不能被后台自动唤醒，用 FerryCat 每完成一次跨窗口互审，你必须手动切换 3 次窗口、敲 3 次指令，这会带来大约 15 到 25 秒 的人工操作开销。如果是改个变量名、写个简单函数，直接在一个窗口里搞定就行，上工单纯属折腾自己。
- 两个工具不在同一台电脑、看不到同一个硬盘文件夹，用不了： FerryCat 省掉复制粘贴的前提，是左边的窗口和右边的窗口能读到你电脑硬盘上的同一个项目目录。如果有一方跑在完全隔离的云端网页里、摸不到本地文件，这条摆渡船就开不通。
- 想要半夜睡大觉、让几十个任务全自动跑完，别用它： FerryCat 服务的是“人在电脑前盯盘，让两个桌面编程软件一替一换严密配合”的场景。如果你需要的是无人值守、成百上千个节点按拓扑顺序自动流转，那应该去用专门的 DAG 状态机 编排引擎（比如我之前开源的 PatchCat），而不是在两个桌面聊天框之间硬搭积木。
结语：从当下的 Demo 走向免人工介入的双边自主对话
做软件这么多年，我越来越觉得：好用的工具很少靠一上来画大饼取胜，往往都始于老老实实先把地基打牢。
目前的 FerryCat（v0.1）本质上还是一个验证底层契约的早期 Demo。在这个阶段，面对桌面软件不能被后台隔空唤醒的客观限制，我们选择让人先来充当那三次窗口切换的触发器，集中精力先把“不丢单、不审旧文件、强制按规矩交卷”这条最难啃的契约底座跑通。
但人工切窗口绝不是 FerryCat 的终点。在后续的产品演进里，FerryCat 最终要长成的形态是：把人从中间的传话触发里彻底解放出来，让两边的 Agent 能够通过底层守护通道直接互相对话、自动派单、自动挑刺、自动返工对线——整个多轮博弈与验证过程完全不需要人为介入，直到两边达成一致、任务彻底完成，再统一弹出通知请人类做最终签字验收。
FerryCat 的第一块契约基石已经跑通并开源，每一条防呆规则都是被真实的日常痛点逼出来的。如果你平时写代码也习惯在电脑上同时开着多个 AI 窗口互相挑刺，欢迎拉下代码试试这条正在进化的“摆渡船”，更欢迎随时提 Issue 拍砖指教。
关于作者
郭强 (GuoBug)，Product Engineer，做平台工程也做业务增长。目前主要在折腾 AI 工作流编排、DAG 状态机与确定性系统架构。
开源项目与主页：https://github.com/GuoBug · https://guobug.github.io
欢迎就工作流引擎架构、拓扑调度和低门槛开发体验交流指教。