产品开发从入门到游戏废柴（项目失败复盘）

本文系用户投稿，不代表机核网观点
⚠️ 未经作者授权禁止转载
天才产品构思的诞生
两个月前，我在经历了各种账号风险验证的解决后，成功用上了谷歌 Antigravity 2.0 ，相较于先前使用 Claude Code + Kimi K 2.5，编程开发体验有了巨大提升，模型响应速度飞快的同时质量也有保证，本来已经熄灭的 Coding 兴趣被再一次点燃。
在高强度使用了一周后，出于对社区好评如潮的 Codex 的好奇，我又氪了一个月的 GPT plus 会员，感觉 GPT 5.5 模型的思考和推理能力比起 Antigravity 用的 Gemini 3.5 Flash 模型要好上不少，也因为手头各种想做的内容也都过了早期需要快速出功能验证效果的情况，我开始转头高强度使用 Codex。
使用几天后我开始意识到，不能让闲置的 Gemini 订阅浪费着，或许两个 Coding Agent 应用可以结合着使用。产生此想法主要有两个理由：
因为 Codex 的 plus 订阅额度给的不多，许多浏览器自动化测试在 Codex 上开发执行显得十分浪费，这些简单的验证测试工作可以用 Antigravity 来完成，让十分有限的 Codex 额度更多注重于代码逻辑上。
Gemini 3.5 Flash 虽不如各家旗舰模型，但拥有更快的响应速度，更少的 token 消耗，本身也更适合用于调用工具执行测试等使用场景，效率上比起只使用 GPT 5.5 模型来完成也有不错的提高。
所以我开始尝试将两个 Coding Agent 相互配合起来，我先在 Codex 对话讲清楚配合的逻辑，需要内容截图、浏览器自测等工具调用时，可以输出提示词，我再手动将提示词发给 Antigravity 让其执行。

图一：Antigravity 执行获取各页面截图任务

图二：Codex 根据测试结果分析并发布给 Antigravity 下一步的测试任务
这个过程里我充当着验证其协作沟通内容，确认无误后进行传话让对方验收或执行的角色，在这样执行验证发现该协作可持续后，很自然的意识到，应该尝试取削减我个人在两个 Coding Agent 中的传话作用。对此我采取了较为简单有效的方案，即先在双方对话里用提示词规定共同维护好某个协作文档，就像飞书用于团队协作的文档，当执行完任务时填写完成结果、产出内容、下一步指派给谁等内容，协作的对话只需明确自己在该项目里的定位，查看协作文档，即可自行验证或执行工作。（当然这里方法不唯一，我这里使用的是最直接简单的方法，肯定算不上是最优的协作方式，该协作方案在协作角色变多时会暴露各种问题，但当任务协作仅是几个对话角色线性执行的时候，该方法能够满足需求）
通过设定该协议后，我只需简单确认下工作执行的结果，对下个任务负责角色简单回一句“请查看协作文档并继续工作”即可，不需要我再手动复制传达各角色任务命令。而在这个工作流稳定循环执行了几次后，我正好出门吃饭，看着还有大半的 Codex 五小时额度，我设置了定时任务让 Codex 和 Antigravity 每隔十五分钟触发查看协作文档，至此一个很简单的 Multi Coding Agent Loop 便诞生了。
哇噢，感觉很棒不需要人类了，但是该协作方式仍存在很大的问题，最直接的是如下两点：
额外的不必要开销，定时器本身是通过定时给会话注入上下文执行的，这个定时器任务才不会管是否另一个会话工作完成，是否还需要再继续触发会话了，只是冷冰冰的到点注入提示词唤醒会话工作。
实时性上远不如由事件配置 hook 触发或者 CLI 触发，当某个会话完成后自行通知对应 Agent 会话是明显更合理的形式。
而这其实涉及到两个不同的 Coding Agent 的消息通信了，众所周知啊当你发现你有某个功能需求时，上 Github 找找总会有人做好可直接食用的产品的，因为这个大伙的需求都是一致的，不存在只有你有这个需求市面上别人并没有，除非你是什么小众变态爱好者，所以我快乐的上 Github 搜寻了一通.......
结果并没有找到相关产品应用！
我惊了，天才产品之魂在熊熊燃烧，我发现了一个别人未曾涉猎发现的！绝对有大需求！大应用场景的！做出来绝对够酷炫！必然包揽 Github Star 无数的天才设计！我重新找 GPT 老师确认了下，其也确定市面上并没有相关产品应用，同时我的产品想法是真实需求。

图三：GPT对天才产品想法的热烈肯定
至此，我开始着手设计和思考该天才产品最终落地的样子。
我的天才 Multi Coding Agent 产品构思
我设想的产品一共分三个部分
多 Agent 协作通信协议规范
自定义团队角色模板
调用并配置各 Coding Agent 执行工作

 图四： figma 设计的产品原型图
我需要依次解释下我设想的产品长什么模样，首先最基础的是需要打通各 Coding Agent 的 CLI 调用，这样各 Coding Agent 本身就可以通过终端触发唤醒下一个执行任务的 Agent。其次仍保留协作文档，各 Agent 的工作结果要有输出留痕，便于复盘和查找问题。角色模板则方便用户在不同的使用场景使用不同的协作方式，例如开发、写作、调研等不同场景，角色配置不同，需要可统一管理的角色模板界面让用户可根据自己的不同需求进行自由调整修改。最主要也是我最期待能实现的效果是，能像 Claude Code 的 Agent Teams 一样，能看到其将页面拆分成多个窗口，能同时看到多个 Agent 在同时工作的样子。

图五：Claude Code Agent Teams 工作示例
工作时的效果大概长下图这个样子（简单把几个工具分屏显示，想象其各自工作的样子），脑补的效果也是感觉十分酷炫，还没开干我已经感觉到我能使用无上的热情投入进去了。

图六：脑补的 Coding Agent 协作工作的样子
开发过程中开始出现的各种问题
名为多 Agent 的地狱
整个过程可以说问题贯彻始终啊...首先既然是要做多 Coding Agent 的工具，那么我想着使用多 Agent 角色进行开发很合理吧（？）
GPT 老师可汗大点兵：整个 UI 设计、前端、后端、测试、PM、调研，先这几个吧，后续有需要再加！他们各自的提示词是.......整个产品开发流程是......
年少的我被 GPT 老师蒙蔽了双眼，事实上每次我被 AI 相关应用蒙蔽双眼时，都注定会被 AI 折磨，反而当我清楚 AI 并非神奇玩意，明白其能力边界进行合理使用，才能顺利应用其把某事做好。
总之当时的我真用多个 Coding Agent 创建多个角色进行配合完成任务，这里涉及一个大部分人可能都会有的误区，很多人可能下意识的会觉得“角色拆分越细、Agent 数量越多，任务处理执行就越专业”。
但实际的生产开发环境证明，开发流程中使用的 Agent 对话最好不超过 3 个。在工作上，团队配合似乎也是如此细致拆分，这拆分是在个人生产力有限的情况下，为了高效完成团队目标的结果，让负责不同部分的人可以并行同时开发，但也不可避免增加了沟通协调的成本。
这个成本在 Agent 协作上也同时存在，跨 Agent 交接任务信息也是有损的，在工作的一开始影响不大，但当任务多轮执行后，受限于大模型注意力和上下文的限制，其交接链路信息、一开始要求的约束、任务需求等细节规范会渐渐衰弱，导致偏离执行预期。
其次是协调的成本会远远覆盖过分工的收益，多 Agent 的收益是各自的上下文是干净的，是一致类似的任务内容，但成本为一套需要维护的角色系统提示词、工具调用权限、交接配合规则、避免冲突的方式等，最直接的影响是同样单个任务的执行，花费的时间、开销的 Token 都是巨大增长，随着角色细化甚至开销能达到原有单一 Agent 执行的数倍，但执行效果的提升嘛......感知很小的啦（谁还记得我一开始用多 Agent 协作是为了省 Codex 的额度）。
最恐怖的是，越拆分，运行稳定性就越不及单一 Agent，这个运行就越不能依赖自动化，要人工参与审查的情况就越多。当出现问题时你还要寻找是在哪部分执行的出错，你得在这堆角色一堆上下文里寻找答案，十分折磨。
我在这个过程看到最血压升高的情况是，后端干完了，写了个单元测试脚本，自测通过了，发给测试消息，测试一看干完了啊，噢还有单元测试脚本，看一下这个脚本写的咋样，嗯写的还行，运行测试下，好测试通过，发给 PM消息，PM 看嗷开发完了吗，嗯这几个文档和脚本我看看，嗯还有单元测试脚本，好的我运行下...通过了...好发下个活。
虽然说，上面血压高的情况可以通过提示词约束规定清楚，别你喵谁接手都跑遍无效单元测试脚本啊喂！但做好约束精细规范好提示词又会加剧上面说的更多开销，注意力有限偏离预期等问题。
所以我被折磨吐了，一气之下把所有相关角色会话删了，重新开始仅使用一两个对话来执行开发。
人类，你要产品推进流程把控在自个手里
在经历了上述折磨后，我重新向 GPT 老师讨论接下来怎么执行，GPT 老师重新给我输出了下产品执行路线，大抵是我前面被折磨的心力憔悴了，我不咋审查直接将方案发给我的 Agent 对话开始执行。

图七：被多Agent协作整吐后找 GPT 老师支招
经过几轮执行后，前面 figma 设计的产品图内容成功做了出来，功能上能够查看角色之间发送的消息，执行过的历史任务等，但任务一直徘徊在继续优化这个通信的规范上，这里可能是因为前面提示词的原因导致的，我在前面饱受多 Agent 的折磨后，对于多 Agent 协作已经失去信心了，所以在前面的提示词里强调需要等确定该流程稳定后再考虑往 Cli 发送控制另一 Coding Agent 执行，GPT 老师深表赞同，在给我输出的提示词里多次都强调了这一部分。
但这部分功能其实在产品的角度上看，是优先级较高的，我那时将整个流程管理，下一步功能实现的判断都交给了专门的 PM 角色对话，虽然我每次都会审查，感觉都是诶看上去很有道理，其提出的这部分内容确实是需要的，而对于 Coding Agent Cli 控制的实现一直表示还没到稳定时先不做，没多想便一直依照其建议执行。一天下来的结果便是，好像产品在诡异的部分不断前进，而最主要的部分却进度为 0 。
这事的复盘结果甚至怪不到大模型的头上，我的提示词建议其作为很重的权重去贯彻执行了，而我应该在前面部分执行到大致能用的情况下，就去推进别的优先级较高的功能了，产品开发这件事，说白了不好用有 bug 是一回事，这都是必经的后续优化调整，但核心功能至少得有先，当把基本的百分之 60 完成后，再重新罗列优化功能的优先级，这才是合理的推进目标和流程，我作为人类项目经理，这块属于是完全失职，惭愧惭愧。
压倒人的最后一根稻草
在上面花了较长时间的无效推进后，我的热情已经被磨灭的七七八八了，要说怎么还没彻底放弃，大致是枭🐻的一句“等你跑通了就是 github 万 star 扬名立万了。”但也已经处于被击败前的最后挣扎状态了，只需随便再来点问题我就将彻底击败，而做项目最不缺的就是难题。
前文提到，在产品构思时我希望能够如 Claude Code 的 Agent Teams 一样各 Agent 分屏同时工作，是否能使用 Cli 工具触发调用各 Coding Agent 应用达成该效果 is 决定权不在我，而在各 Agent 应用开放到何种程度，根据查找结果来看，各家 Agent 产品主要有两种形态，比如封装成应用软件有交互 UI 的 Antigravity 和可通过命令行调用的 Antigravity Cli，同理还有 Codex 和 Codex Cli，可以简单理解为 Agent IDE 和 Agent Cli 工具，经过我的尝试 Cli 工具本身数据不与 IDE 互通，即我使用 Codex Cli 创建了个会话发送了消息，其不会在 Codex 上有显示，而对于我想达成分屏同时工作的想法，我的第一反应是想借助“巨人的肩膀”，即本就有成熟交互设计的各家 Agent IDE 应用来实现，最直接的调用 Cli 却数据不互通这块对我颇有打击，实际上现在想想这是理所当然的事，做出有交互界面的 IDE 工具和终端 Cli 工具本身就是服务于不同场景人群的产品。
话虽如此，但经过几轮的尝试测试，终于能够使用 Cli 脚本控制 Codex 创建新会话、发送任务等，但这个过程给我的感觉不是研发的乐趣，而是不断测试的枯燥无聊，通过检索各家官网确实能够发现不少控制操作的方法，但哪些控制的结果是符合我期望的，需要靠人为接入测试才能得知，在 Codex 的测试过程中得先排除掉 Codex Cli 相关的操作方法，在 Codex 操作完还发现 Codex UI 并不会自动刷新界面会话内容（除非是已有会话），重启 Codex 后刚新建的会话才会加载出来，然后开始研究如何让 UI 刷新.......

图八：激情（并非）测试功能中
一想到想要打通其他 Coding Agent，大概也要经历类似步骤，我的热情便瞬间耗尽了，现在回过头复盘也可以说，我是在错误的方向上狂奔，而我醒悟到这一点，是在我放弃该项目投入干其他项目的一周后，在 Github 上看到一个与我同方向的产品 https://github.com/stablyai/orca ，截止至今斩获 39.2 K 的 Star。
三体降临，天才沦为游戏废材
如标题所言，当我看到 orca 项目时，有种人类科学全方面被三体人碾压的既视感，又像是刘慈欣的短篇小说《朝闻道》那样，高等文明来到地球，告知如果想要答案可以前来，我带着对该项目的疑问前去，而上头的人甩给了我个 Github 链接，说：“这就是你要的。”

图九：orca Github链接上的图图
为了不让下文变成 orca 的安利，我只挑出点核心差异讲。该项目协同使用的不是 Agent IDE，而是 Agent Cli。前文我提到我在错误的方向狂奔，主要也是这点上的差异，使用 Agent Cli 能在终端中运行有足够的运行上下文信息，更方便于统一的放进一个工作台里管理，同时也能做到如 Claude Code 的 Agent Teams 那样切分多个窗口同时在一个页面显示运行。
当时的我瞬间完全意识到，这样的方向才是对的，这样才能更好的维护管理多个 Coding Agent 而不失优雅，满脑子只想着酷炫且想站在巨人的肩膀上的我是做不出这样的东西的，从产品设计到项目规模，我的个人在这个项目面前就像一粒尘埃。
我没有力量！我不是天才产品人！...吗？
orca 这个项目虽看着与我设想是类似，但实际初心和产品最终形态仍与我有巨大差异，其是个多 Coding Agent 协作工作没错，但其并不主打替你省钱，他的 README 页面里介绍的功能里有一项是让多个 Coding Agent 独立执行同一工作这样的 Agent 大乱斗功能，让用户从中选择跑的最好的，如此奢侈！岂有此理！大家的 token 额度都是大风刮来的吗！
我只能说我深刻认识到个人的能力是有限的，所以才会想用站在巨人的肩膀上来实现，会有这个产品的想法也始于想要节约 Codex 的额度，吾之财力也是有限的。财力有限所以是个人开发，个人开发所以因为能力不足碰到了各种问题，若要复盘项目失败的原因，可以说是这个目标对于个人来说是宏大的，这是个从一开始就注定失败的项目。但过程中的破防折磨和留下来的反思甚是有趣，故一点点记录下来，很大程度我后续逐渐对 AI Coding 去魅，开始脱离 Coding 拥抱快乐游戏人生，也是拜该项目所赐。
逸剑风云决真你喵好玩~