我的 AI 编程工作台：多模型编排而非单选

我的编程工具箱已经不再是单一产品了。

本地运行的是 Ollama + Qwen3.5:9B。终端里用 OpenCode、Claude Code 和 Codex，还通过 OpenCode 接入 Kimi K3。桌面端复杂工作时用桌面版 GPT。这些工具在能力、成本、隐私和交互方式上各有不同，但我逐渐相信：输出质量更多取决于多个模型的协同组织，而不是找到某个"最佳模型"。

我不想让一个 Agent 独立接收模糊需求、设计、实现并审批结果。我的工作流程更像一个小型工程团队：建立共享项目上下文，让强模型设计架构，我亲自审查关键决策，然后将工作分解为有限任务，分配给不同工具，再请其他工具审查实现，最后通过测试、类型检查、静态分析和实际行为观察来闭环。

关键不在于打开更多终端，而在于构建一个可审计的交付管道：

Requirements and constraints
          ↓
Project context (AGENTS.md / CLAUDE.md / documentation)
          ↓
Design (architecture, domain boundaries, risks, acceptance criteria)
          ↓
Human review and decision
          ↓
Task decomposition → execution → independent cross-review
          ↓
Automated checks + scenario validation
          ↓
Corrections become durable project context

分层工作台，而非工具列表

不同模型应处于工作流程的不同位置。把每个任务都发给最贵的模型是浪费。让小型本地模型处理高风险设计决策，可能让团队快速地走向错误方向。

这不是永久排名。模型和产品会不断演进。稳定的规则是根据风险、上下文规模、可验证性、成本和隐私需求来路由工作。

低风险、可逆的任务通常从本地或低成本模型开始。跨模块推理值得用更强的模型。架构、数据迁移、安全和生产变更需要人工决策。没有任何模型输出可以替代验收证据。

从项目上下文开始，而非精妙的 Prompt

初始化项目时，我会创建 AGENTS.md 和 CLAUDE.md 这样的项目级指令。它们描述技术栈、仓库结构、运行命令、架构和工程约束。这种准备看起来像文档，但它为后续的每个 Agent 设定了能力上限。

没有共享上下文，每个工具都要重新扫描仓库、猜测约定，可能发明出不同的实现风格。有效的项目上下文应该能回答：

Purpose: the problem, users, and current stage
Stack: languages, frameworks, versions, and major dependencies
Architecture: module responsibilities, dependency direction, hard boundaries
Domain language: core concepts, terms, and invariants
Commands: install, start, test, type-check, and build
Conventions: naming, errors, logging, tests, and commits
Safety: sensitive data, secrets, external calls, and prohibited actions
Definition of done: mandatory quality gates for every change

上下文文件不应变成千行倾倒场。AGENTS.md 是稳定、可执行、跨工具规则的合适归宿。CLAUDE.md 可以包含 Claude 特定的交互指导。详细架构应放在入口点链接的专门文档中。规则应简洁、可测试，并随代码更新。

有一条原则非常重要：不要在多个文件中重复相同的规则。重复最终会变成矛盾。共享事实需要一个规范来源；工具特定文件只应包含差异。

让强模型设计，但保持架构对人负责

对于中大型变更，我经常请 Claude 提出架构、领域边界、DDD 模型和实现路径。AI 擅长快速扩展问题空间：识别受影响的模块、提出替代方案、发现故障路径、暴露隐藏依赖、将模糊需求转化为可辩论的结构。

一份完善的设计文档不等于正确的设计。我审查五件事：

它解决的是真正的问题吗？还是为了展示架构 sophistication 而添加了复杂性？

边界自然吗？是跟随业务变更，还是仅仅应用了 DDD 术语？

依赖受控吗？数据流、事务、恢复和兼容性明确吗？

能增量发布吗？还是需要高风险的大爆炸重写？

如何知道它有效？测试、性能、迁移和业务验收标准在实现前定义了吗？

DDD 是组织复杂业务知识的方式，不是装饰性的默认选项。生命周期短、只有简单 CRUD 的模块不需要为自身而添加聚合、仓储和额外层。DDD 的价值在于规则复杂、语言有争议、边界需要随时间演变时。

因此我请模型解释为什么设计适合、存在什么替代方案、以及何时不应使用该建议。好的架构不是令人印象深刻的图表，而是一组可以被挑战、权衡和验证的决策。

按边界和证据分解工作

一旦设计通过审查，我不会给另一个 Agent 发一行指令说"实现整个功能"。我创建独立可理解、可验证的任务包，尽量减少重叠的写作用域。

有用的任务包包括：

Objective: the user or system behavior that must change
Scope: permitted modules and explicit non-goals
Context: relevant decisions, interfaces, and conventions
Acceptance: tests, examples, performance, or observable behavior
Risk: compatibility, data, security, and rollback requirements
Delivery: code, tests, documentation, and unresolved questions

任务应按领域边界、模块、读/写职责或验证关注点分解——而不是机械地按文件分解。当多个 Agent 编辑同一个核心文件时，生成时节省的时间往往在冲突解决和上下文同步中丢失。并行化只有在边界清晰、写作用域几乎不重叠时才有回报。

我还控制每个任务接收多少上下文。给 Agent 整个仓库并不总是有帮助的。无关信息会稀释约束并增加意外关联。稳定的项目规则应共享，而每个任务只接收其目标所需的本地上下文。

交叉审查：不同工具应搜索不同故障

我请其他工具交叉审查实现。价值不在于两个模型可以投票，而在于独立审查者可以挑战实施者的假设。

有效的审查比"看看这段代码"更具体。我请审查者检查：

是否符合需求和验收标准；

架构边界和隐藏耦合；

错误路径、并发、幂等性和资源清理；

安全、隐私、权限和依赖风险；

测试是否验证行为而非镜像实现；

是否存在更简单、更可维护的解决方案。

审查者应提供证据：文件和位置、触发条件、影响、重现路径和建议纠正。实施工具可以处理发现并重新运行验证。当模型意见不一致时，我不按品牌决定，而是回到需求、代码、测试和可重现的事实。

也存在 Agent 相互背书的风险。如果多个工具继承相同的错误假设，它们可能自信地同意错误结果。独立验证应改变信息源或验证方法：一个模型执行静态审查，另一个运行测试和场景，人审查关键业务判断。

最终裁判是质量门，而非模型

代码看起来合理不等于系统行为正确。我的验证阶梯通常是：

Formatting / linting
        ↓
Type checking / compilation
        ↓
Unit and integration tests
        ↓
Critical user journey or API scenario checks
        ↓
Diff and architecture consistency review

自动化检查属于项目命令和 CI，而非 Agent 的记忆。Agent 必须报告它实际运行了哪些命令、结果如何，以及哪些检查因环境限制无法运行。未执行的测试不是"可能通过"，预测也不是证据。

高风险操作需要单独治理。生产部署、数据库迁移、破坏性变更、权限更新和外部通信需要明确批准和恢复计划。本地推理可以提高隐私，但并非自动安全。模型溯源、工具权限、Prompt 中的 secrets、日志和外部插件仍需控制。

将每个纠正转化为默认能力

这个工作流的持久价值不在于一次变更更快发布，而在于学习循环。

当审查暴露反复出现的问题时，我决定哪一层应该吸收它。稳定的工程约束进入 AGENTS.md。架构权衡成为 ADR。领域事实进入领域文档。机械错误成为 lint 规则或测试。高价值失败成为回归用例。下一个任务不应依赖我再次记住同样的警告。

然后我可以追踪从请求到合并的周期时间、首次验证率、审查发现、人工返工、rollback 次数和跨模型可比任务成本。生成速度本身是糟糕的评估指标。快速模型若产生数小时的审查工作，可能是更慢的系统。

我的结论：开发者成为工作系统的设计者

Ollama、Qwen、OpenCode、Kimi、Claude Code、Codex 和桌面 GPT 都会继续演进。今天最强大的模型可能明天就变成普通组件。

真正重要的是模型无关的：明确目标、在项目中编码上下文、将架构转化为可审查的决策、将工作分解为可验证的单元、独立分配执行和审查、用自动化证据闭环。

AI 降低了编码和探索的成本，但没有承担判断或责任的所有权。我的角色不再局限于逐行输入代码。它是设计一个工程系统——正确的上下文进入，不同能力协作，错误尽早暴露，经验成为持久记忆。

这可能是 AI 编程带来的最深层变化：我们不再只是设计软件；我们还在设计软件生产的方式。