Fixy Code：多AI协作终端，让代码生成与审查更智能

1. 项目缘起从“复制粘贴中间人”到构建一个终端几个月前我的日常开发流程陷入了一个令人沮丧的循环。我会向Claude Code提出一个编程需求它总是信心满满地给出一个看起来完美的解决方案。我复制、粘贴、提交代码然后通常在三天后一个隐蔽的Bug会悄然浮现打乱整个开发节奏。问题的根源我逐渐意识到并不在于Claude Code本身不够聪明。问题在于它就像一个在真空中工作的天才工程师——它没有同行评审没有第二双眼睛来审视它的设计决策也没有一个持不同意见的声音来挑战它的假设。它给出的答案总是那么“自信”但这种自信背后缺乏了现实工程中至关重要的“辩证”过程。于是我决定结束这种“复制粘贴中间人”的低效状态。如果问题的核心是单一AI模型缺乏制衡与讨论那么解决方案就是创造一个让多个AI模型能够协同工作的环境。这就是Fixy Code诞生的初衷一个开源的终端它不是一个简单的AI聊天窗口而是一个专为代码生成与审查设计的“协作工作台”。它将Claude Code、Codex和Gemini置于同一个对话线程中让它们能够看到彼此的输出挑战对方的决定并在真正产生分歧时将最终的决定权交还给你——开发者。2. Fixy Code核心设计理念与工作流解析2.1 从单点咨询到多智能体协作传统使用AI编程助手的模式是点对点的你提问它回答。Fixy Code彻底改变了这一范式将其升级为一个多智能体协作系统。在这个系统里每个AI模型扮演着略有不同的角色基于它们各自的训练数据和设计倾向会从不同的角度审视同一个问题。你可以这样理解Claude Code像是一位注重代码整洁度、可维护性和架构优雅性的资深架构师Codex则更像一位经验丰富的实战派工程师追求快速、务实、能直接运行的解决方案而Gemini则提供了一个额外的、有时更具创造性的第三方视角。当你通过Fixy Code发起一个任务时你不是在询问一个模型而是在召集一个小型的技术评审会。2.2 核心交互命令与协作循环Fixy Code的交互是通过一系列直观的“”命令来驱动的这模拟了在一个团队频道中不同成员的感觉。这种设计极大地降低了使用门槛让协作变得自然。定向咨询你可以直接指定某个“专家”进行审查。例如claude review this function会请求Claude Code对当前函数进行代码审查指出潜在问题或改进建议。紧接着你可以问codex do you agree?让Codex对Claude的审查意见发表看法。这种交叉验证能迅速暴露单一模型可能忽略的盲点。综合讨论与执行all build the auth middleware这个命令会触发完整的协作循环。这是Fixy Code最强大的功能之一。它不是一个简单的“把任务丢给三个模型然后合并结果”的操作。其内部流程大致如下规划阶段所有“思考者”智能体Claude, Codex, Gemini会先就“如何构建这个认证中间件”进行讨论。它们会交换想法评估不同方案如JWT vs. Session 路由结构设计错误处理策略等并试图达成一个共识性的实施计划。执行与批处理一旦计划确定或由你在分歧时裁定worker这个角色会接手。它负责将大任务分解成可执行的小批次例如先创建基础文件结构再实现核心验证逻辑最后添加错误处理并依次执行代码生成。交叉评审在每一批代码生成后worker不会直接提交。相反它会将产出再次交给思考者智能体进行评审。Claude可能会检查代码风格和架构一致性Codex可能会测试逻辑的实用性Gemini可能会提出额外的边缘情况。只有通过这轮评审这批代码才会被标记为“就绪”。角色分离worker与思考者智能体的分离是一个关键设计。这模拟了现实中“规划”和“执行”的分离让每个部分更专注也避免了让同一个模型既当运动员又当裁判员的潜在偏见。注意all命令虽然强大但也会消耗更多的计算资源本地Token和时间。对于简单、明确的任务直接使用claude或codex进行快速生成可能更高效。将all留给那些架构复杂、容易出错或具有多种可能实现方案的核心模块。3. 技术架构与安全隐私实现细节3.1 本地优先与零信任设计在AI工具泛滥、数据隐私担忧日增的今天Fixy Code的架构选择了一条截然不同的道路一切都在本地运行。这是项目的基石也是赢得开发者信任的关键。无数据外泄你的代码、你的提示词、AI模型之间的讨论内容没有任何一部分会离开你的机器。Fixy Code本身不包含任何AI模型它只是一个“协调器”和“界面”。它通过适配器调用你已经安装在本地或通过官方API配置好的Claude、Codex和Gemini会话。零重复认证Fixy Code直接继承你现有的、已经通过官方渠道如OpenAI API、Anthropic API、Google AI Studio配置好的会话和环境变量。你不需要在Fixy Code里重新输入API密钥它利用系统已有的配置。这既简化了设置流程也避免了密钥在多个地方存储的安全风险。Git工作树隔离这是保障你主代码库安全的“金钟罩”。Fixy Code为每一个代理Agent在每一个对话线程中都创建了一个独立的Git工作树Worktree或分支。当worker执行代码生成或修改时所有操作都发生在这个隔离的分支里。你的主分支main/master永远不会被意外更改或污染。你可以在完全放心的情况下观察AI生成的所有代码进行仔细的审查和测试然后再手动合并或丢弃。3.2 数据持久化与可追溯性所有通过Fixy Code进行的对话、AI之间的辩论、生成的代码片段以及你的最终决策都会被记录在一个仅追加Append-only的对话日志中该日志存储在~/.fixy/目录下。这种设计带来了两个巨大好处完整的审计追踪三个月后当你回顾某个模块为什么采用了某种看似奇怪的设计时你可以回溯当时的完整讨论记录。你会发现那可能是Claude和Codex经过激烈辩论后由你拍板选择的一个权衡方案。这为项目决策提供了宝贵的上下文。上下文管理虽然当前版本提到了“上下文压缩”作为未来特性但完整的日志本身就是管理上下文的基础。你可以看到整个思维链而不只是最后一个答案。3.3 技术栈选择TypeScript与开源项目本身使用TypeScript构建这确保了代码的类型安全、良好的工具链支持以及庞大的NPM生态可用性。采用MIT开源许可证意味着任何人都可以自由地使用、修改和分发这个工具甚至将其集成到自己的商业产品中。这鼓励了社区审查、贡献和生态建设是项目长期健康发展的关键。4. 实战演练以构建用户认证中间件为例让我们通过一个具体的场景来感受Fixy Code如何改变你的开发流程。假设我们正在构建一个Node.js Express后端需要一个用户认证中间件。4.1 启动与任务分发在项目根目录一个Git仓库中打开终端运行fixy命令启动协作终端。首先我们创建一个清晰的上下文all 我们需要为一个Express.js API构建一个用户认证中间件。核心要求 1. 使用JWTJSON Web Tokens进行无状态认证。 2. Token通过HTTP Header的 Authorization: Bearer token 传递。 3. 中间件需要验证Token的有效性签名、过期时间。 4. 将解码后的用户信息如userId注入到 req.user 对象供后续路由使用。 5. 处理常见的错误情况Token缺失、格式错误、无效、过期并返回恰当的HTTP状态码401/403。 请讨论一个实现计划并生成高质量的代码。4.2 观察多智能体讨论过程发出命令后Fixy Code的界面会开始流式显示三个AI模型之间的讨论。你可能会看到类似下面的对话此为模拟Claude“我建议采用分层结构。首先一个纯粹的verifyToken工具函数只负责JWT的验证和解析不涉及任何HTTP上下文。然后authMiddleware包装它处理请求和响应。这样职责单一便于单元测试。我们应该使用jsonwebtoken库并考虑将密钥从环境变量读取。”Codex“同意使用jsonwebtoken。但我觉得可以更精简。authMiddleware可以直接内联验证逻辑减少一层函数调用。错误处理用try-catch包裹直接通过res.status(401).json(...)返回。这样对初学者更直观。另外我们是否需要区分401未认证和403Token有效但权限不足当前需求似乎只涉及401。”Gemini“除了基础验证我们可以考虑添加一个可选的‘权限守卫’扩展点。比如authMiddleware可以接受一个可选的回调函数(decodedUser) boolean用来进行更细粒度的权限检查这样中间件就更通用了。另外关于密钥是否要支持多密钥轮换的场景”Claude“Codex的内联方案虽然直接但牺牲了可测试性。将验证逻辑分离是行业最佳实践。Gemini的权限守卫想法很好但属于‘拓展需求’我们应该先完成核心需求YAGNI原则。我建议实现基础版但保留清晰的接口便于后续按Gemini的想法扩展。”你会看到它们不仅讨论实现还在讨论软件设计原则如单一职责、YAGNI。这种讨论本身对你就是一次极佳的学习。4.3 处理分歧与做出决策假设讨论在“错误处理返回格式”上卡住了。Claude主张返回结构化的错误对象{ error: UNAUTHORIZED, message: Invalid token, code: 401 }。Codex认为简单返回字符串信息更常用{ message: Invalid token }状态码由HTTP状态码体现即可。Gemini提出可以配置化。此时Fixy Code会暂停并提示你[!] 代理在‘错误响应格式’上存在分歧。 [1] 采用 claude 的结构化错误对象方案。 [2] 采用 codex 的简洁消息方案。 [3] 采用 gemini 的可配置方案。 [4] 要求它们寻找一个折中方案。 你的选择 (1/2/3/4):这才是“你”作为工程师掌控力的体现。你根据项目现有的API错误响应规范选择了选项1。这个决策会被记录在案。之后worker会基于达成共识或你裁定的方案开始生成代码。4.4 审查与迭代生成的代码worker生成代码后Fixy Code会自动触发一轮审查。你可能会看到Codex“生成的verifyToken函数没有处理jwt.verify可能抛出的多种错误类型如TokenExpiredError。建议用instanceof检查以提供更精确的错误信息。”Claude“同意Codex。另外中间件里把req.user decoded;这样赋值存在风险可能会覆盖已有的user属性。建议使用req.user { id: decoded.sub, ... };这样更安全的结构。”基于这些审查意见worker会进行迭代修改。最终呈现在你隔离分支中的代码已经过了一轮多角度的“同行评审”其健壮性和质量远高于直接向单一模型索取的初版代码。5. 开发心路教训、发现与未来方向5.1 最重要的发现分歧的价值在构建和使用Fixy Code的过程中最令我惊讶的发现是这些顶尖的AI模型之间的分歧频率和深度远超我的预期。而且这些分歧绝大多数不是“噪声”而是真正有价值的信号。它们揭示了那些在快速开发中容易被忽略的、需要慎重权衡的决策点。例如架构整洁 vs. 开发速度Claude倾向于前者Codex倾向于后者。当它们为此争论时其实是在帮你明确当前项目的优先级——这是一个需要长期维护的核心模块还是一个需要快速上线的概念验证过度工程 vs. 适度抽象Gemini有时会提出一些前瞻性很强的功能点而Claude和Codex会从必要性和复杂度角度提出质疑。这完美模拟了技术团队中关于“现在需要做多好”的经典辩论。这些冲突迫使你开发者从一个被动的代码接收者转变为一个主动的技术决策者。你不再是不假思索地接受一个“看似正确”的答案而是在理解了不同方案的利弊后做出清醒的、符合项目上下文的选择。这种“有意识的决策”是专业工程与随意编码的关键区别。5.2 踩过的坑功能蔓延与核心验证我犯了一个非常经典的产品错误在向任何外部用户展示之前我就构建了太多功能。我沉迷于添加各种“很酷”的特性红房间模式一个让智能体进行更激烈辩论的模式。分歧面板可视化展示分歧点的UI。上下文压缩算法为了节省Token而设计的复杂逻辑。多个适配器急于支持更多模型。结果呢我花了大量时间在可能根本没人需要的功能上而最核心的价值——“让两个AI一起讨论代码”——却迟迟没有得到真实用户的验证。如果重来一次我会采取完全不同的策略最小可行产品只实现claude和codex在同一个线程中对话的基本功能。甚至初始版本可以没有all和worker就只是让它们能互相看到对方的回答。立即发布将这个极其简陋的版本交给几个信任的开发者朋友使用。基于反馈迭代他们最常用的模式是什么他们最想要的分歧处理方式是什么他们需要Git隔离吗根据这些真实反馈来决定下一个优先开发的功能是什么。这个教训对任何工具建造者都至关重要先验证核心价值假设再添加装饰。一切在核心价值被证明之前添加的东西都可能是分散注意力的“杂音”。5.3 给使用者的实操建议与避坑指南从简单任务开始不要一开始就用all去构建一个完整的微服务。从一个工具函数、一个API路由、一个React组件开始。这能帮助你熟悉工作流并快速建立对工具的信任。精心设计初始提示你给all的初始提示就是项目的“需求文档”。写得越清晰、越具体包括技术栈、约束条件、代码风格偏好讨论的方向就越集中产出质量越高。模糊的提示会导致漫无目的的讨论。善用隔离分支充分利用Git工作树隔离。在合并AI生成的代码到主分支之前务必在隔离分支中进行运行测试和手动审查。AI是强大的助手但不是不会犯错的圣人。管理API成本与速率限制虽然Fixy Code在本地协调但它调用的后端API如OpenAI, Anthropic可能产生费用并有速率限制。长时间的、多轮次的all讨论会消耗大量Token。对于非关键性代码考虑使用定向的claude咨询或者先让一个模型生成再让另一个审查而不是一开始就开启全员讨论。将日志作为知识库定期回顾~/.fixy/下的日志。你不仅能看到代码的演变还能学到AI模型分析问题的思路和权衡点这对于提升你自己的系统设计能力大有裨益。Fixy Code不是一个“自动编程”的魔法黑箱。它是一个力放大器它将你从枯燥的代码搬运和初级调试中解放出来让你能将更多精力集中于更高层次的技术决策、架构设计和问题定义上。它引入的“多模型辩论”机制本质上是在你的开发流程中嵌入了一个永不疲倦、知识渊博的同行评审团。当你习惯了这种有制衡、有讨论的协作模式后再回头看过去那种从一个模型复制粘贴代码的日子会感觉那就像是在闭门造车。