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最强大的功能之一。它不是一个简单的“把任务丢给三个模型然后合并结果”的操作。其内部流程大致如下：
  1. 规划阶段 ：所有“思考者”智能体（Claude, Codex, Gemini）会先就“如何构建这个认证中间件”进行讨论。它们会交换想法，评估不同方案（如JWT vs. Session， 路由结构设计，错误处理策略等），并试图达成一个共识性的实施计划。
  2. 执行与批处理 ：一旦计划确定（或由你在分歧时裁定）， @worker 这个角色会接手。它负责将大任务分解成可执行的小批次（例如，先创建基础文件结构，再实现核心验证逻辑，最后添加错误处理），并依次执行代码生成。
  3. 交叉评审 ：在每一批代码生成后， @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/ 目录下。

这种设计带来了两个巨大好处：

1. 完整的审计追踪 ：三个月后，当你回顾某个模块为什么采用了某种看似奇怪的设计时，你可以回溯当时的完整讨论记录。你会发现，那可能是Claude和Codex经过激烈辩论后，由你拍板选择的一个权衡方案。这为项目决策提供了宝贵的上下文。
2. 上下文管理 ：虽然当前版本提到了“上下文压缩”作为未来特性，但完整的日志本身就是管理上下文的基础。你可以看到整个思维链，而不只是最后一个答案。

3.3 技术栈选择：TypeScript与开源

项目本身使用TypeScript构建，这确保了代码的类型安全、良好的工具链支持以及庞大的NPM生态可用性。采用MIT开源许可证，意味着任何人都可以自由地使用、修改和分发这个工具，甚至将其集成到自己的商业产品中。这鼓励了社区审查、贡献和生态建设，是项目长期健康发展的关键。

4. 实战演练：以构建用户认证中间件为例

让我们通过一个具体的场景，来感受Fixy Code如何改变你的开发流程。假设我们正在构建一个Node.js Express后端，需要一个用户认证中间件。

4.1 启动与任务分发

在项目根目录（一个Git仓库中）打开终端，运行 fixy 命令启动协作终端。首先，我们创建一个清晰的上下文：

@all 我们需要为一个Express.js API构建一个用户认证中间件。核心要求：
1. 使用JWT（JSON 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（未认证）和403（Token有效但权限不足）？当前需求似乎只涉及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一起讨论代码”——却迟迟没有得到真实用户的验证。如果重来一次，我会采取完全不同的策略：

1. 最小可行产品 ：只实现 @claude 和 @codex 在同一个线程中对话的基本功能。甚至初始版本可以没有 @all 和 @worker ，就只是让它们能互相看到对方的回答。
2. 立即发布 ：将这个极其简陋的版本交给几个信任的开发者朋友使用。
3. 基于反馈迭代 ：他们最常用的模式是什么？他们最想要的分歧处理方式是什么？他们需要Git隔离吗？根据这些真实反馈，来决定下一个优先开发的功能是什么。

这个教训对任何工具建造者都至关重要： 先验证核心价值假设，再添加装饰 。一切在核心价值被证明之前添加的东西，都可能是分散注意力的“杂音”。

5.3 给使用者的实操建议与避坑指南

1. 从简单任务开始 ：不要一开始就用 @all 去构建一个完整的微服务。从一个工具函数、一个API路由、一个React组件开始。这能帮助你熟悉工作流，并快速建立对工具的信任。
2. 精心设计初始提示 ：你给 @all 的初始提示就是项目的“需求文档”。写得越清晰、越具体（包括技术栈、约束条件、代码风格偏好），讨论的方向就越集中，产出质量越高。模糊的提示会导致漫无目的的讨论。
3. 善用隔离分支 ：充分利用Git工作树隔离。在合并AI生成的代码到主分支之前， 务必在隔离分支中进行运行测试和手动审查 。AI是强大的助手，但不是不会犯错的圣人。
4. 管理API成本与速率限制 ：虽然Fixy Code在本地协调，但它调用的后端API（如OpenAI, Anthropic）可能产生费用并有速率限制。长时间的、多轮次的 @all 讨论会消耗大量Token。对于非关键性代码，考虑使用定向的 @claude 咨询，或者先让一个模型生成，再让另一个审查，而不是一开始就开启全员讨论。
5. 将日志作为知识库 ：定期回顾 ~/.fixy/ 下的日志。你不仅能看到代码的演变，还能学到AI模型分析问题的思路和权衡点，这对于提升你自己的系统设计能力大有裨益。

Fixy Code不是一个“自动编程”的魔法黑箱。它是一个 力放大器 ，它将你从枯燥的代码搬运和初级调试中解放出来，让你能将更多精力集中于更高层次的技术决策、架构设计和问题定义上。它引入的“多模型辩论”机制，本质上是在你的开发流程中嵌入了一个永不疲倦、知识渊博的同行评审团。当你习惯了这种有制衡、有讨论的协作模式后，再回头看过去那种从一个模型复制粘贴代码的日子，会感觉那就像是在闭门造车。