我现在的编程工具箱并不单一。
本地侧，我使用 Ollama + Qwen3.5:9B；终端工作流里有 OpenCode、Claude Code 和 Codex，OpenCode 也会接入 Kimi K3；复杂的桌面任务，我会使用 GPT 的桌面版本。它们能力不同、成本不同、交互方式不同，但我越来越确定：真正决定产出的，不是选中了哪一个“最强模型”，而是怎样组织它们工作。
我不希望一个 Agent 从模糊需求出发，一口气完成设计、编码和验收。我的做法更接近一支小型工程团队：先建立项目上下文，让强模型提出架构方案，由我审核关键判断；再把工作拆成边界清晰的任务，交给不同工具执行和交叉 Review；最后以测试、类型检查、静态分析和实际行为作为验收证据。
这套方法的核心不是多开几个终端，而是建立一条可审计的工程流水线：
需求与约束
↓
项目上下文（AGENTS.md / CLAUDE.md / 文档）
↓
方案设计（架构、领域边界、风险、验收标准）
↓
人的评审与决策
↓
任务拆分 → 多工具执行 → 交叉 Review
↓
自动验证 + 场景验收
↓
把纠错沉淀回项目上下文
我使用的不是工具列表，而是分层工作台
不同模型适合占据不同位置。把所有任务都交给最昂贵的模型，会浪费成本；把高风险设计交给轻量本地模型，又可能在错误方向上快速前进。
| 层次 | 我的工具 | 更适合的工作 |
|---|---|---|
| 本地探索层 | Ollama + Qwen3.5:9B | 代码解释、局部检索、草稿、低风险修改、敏感上下文下的辅助分析 |
| 开放编排层 | OpenCode + Qwen / Kimi K3 | 多模型切换、快速试验、成本与能力对比、可替换的终端工作流 |
| 深度设计层 | Claude Code | 阅读大范围上下文、提出架构与领域模型、梳理复杂改造路径 |
| 工程执行层 | Codex / Claude Code / OpenCode | 仓库探索、实现、重构、测试、修复和代码 Review |
| 桌面协作层 | GPT 桌面版 | 跨文件与视觉材料理解、研究整理、长任务协作和成果打磨 |
这不是固定排名。模型会更新，工具也会变化；稳定的应该是分工原则：按任务的风险、上下文规模、可验证性和隐私要求选择执行者。
我的路由规则很简单：低风险且可逆的任务优先使用本地或低成本模型；需要跨模块推理的任务交给更强模型；涉及架构、数据迁移、安全、生产变更时，人必须进入决策环节；任何工具的输出都不能替代验收证据。
第一步不是写 Prompt，而是初始化项目上下文
进入一个新项目后，我会先建立 AGENTS.md、CLAUDE.md 等项目级说明，把技术栈、目录结构、运行方式和工程约束写进去。这一步看似只是准备文档，实际上决定了后续每个 Agent 的工作上限。
如果没有共同上下文，不同工具会反复扫描仓库、猜测约定，甚至各自发明一套实现风格。高质量的项目上下文至少应该回答：
项目目标：它解决什么问题，当前阶段是什么
技术栈：语言、框架、版本与关键依赖
架构边界：模块职责、依赖方向、禁止跨越的边界
领域语言：核心概念、术语与不变量
开发命令：安装、启动、测试、类型检查、构建
编码约定：命名、错误处理、日志、测试与提交规范
安全边界：敏感数据、密钥、外部调用和禁止操作
完成定义：一次改动必须通过哪些质量门禁
但上下文文件也不能变成几千行的知识垃圾场。AGENTS.md 更适合放跨工具、可执行、稳定的规则；CLAUDE.md 可以补充 Claude 特有的交互偏好。详细架构放进专门文档，再从入口文件链接过去。规则要短、明确、能验证，并随着代码一起更新。
一个重要原则是：不要在多个文件复制同一条规则。 重复内容迟早会不一致。公共事实应该只有一个来源，工具专属文件只记录差异。
先让强模型设计，但架构决定权仍然属于人
面对中大型需求，我通常先让 Claude 输出架构设计、领域边界、DDD 模型和实施路径。AI 很适合快速展开问题空间：发现受影响模块、列出候选方案、补齐异常流程、识别隐含依赖，并把模糊需求变成可以讨论的结构。
但我不会把一份结构完整的设计文档直接当作正确答案。我会重点审核五件事：
- 是否解决真实问题：方案有没有把需求想复杂，或者只展示架构技巧；
- 边界是否自然：领域划分是否来自业务变化，而不是为了套用 DDD 名词；
- 依赖是否可控：数据流、事务边界、失败恢复和兼容策略是否清楚；
- 是否可以渐进落地：能否分阶段交付，是否存在大爆炸式重写；
- 如何证明有效：测试、性能、迁移和业务验收标准是否在编码前就明确。
DDD 是组织复杂业务知识的方法，不是每个项目的默认装饰。CRUD 明确、生命周期短的模块，不需要为了“领域驱动”增加聚合、仓储和层层抽象；当业务规则复杂、术语混乱、边界长期演进时，DDD 才能真正降低认知成本。
因此我更愿意让模型同时提交“为什么这样设计”“替代方案是什么”“什么时候不该这样做”。好的架构输出不是一张看起来高级的图，而是一组可以被质疑、取舍和验证的决策。
拆分任务时，以边界和证据为单位
方案通过后，我不会把一句“请实现整个功能”扔给另一个 Agent，而是拆成可以独立理解、独立验证、尽量少共享写入范围的任务。
一个好的任务包应该包含：
目标：要改变的用户或系统行为
范围：允许修改的模块与明确不做的事项
上下文：相关设计决策、接口和现有约定
验收：测试、示例、性能或可观察行为
风险：兼容性、数据、安全与回滚要求
交付：代码、测试、文档和仍未解决的问题
任务可以按领域边界、模块、读写职责或验证类型拆分，而不是机械地按文件分配。多个 Agent 同时修改同一核心文件，往往会把节省的时间重新消耗在冲突和上下文同步上。只有边界足够清楚、写入范围互不干扰时，并行才真正有价值。
我也会控制每个任务的上下文。给 Agent 整个仓库并不总是更好；无关信息会稀释约束，增加错误联想。理想状态是：共享项目规则保持稳定，每个任务只补充完成当前目标所需的局部上下文。
交叉 Review：让不同工具发现不同类型的问题
我会让其他工具组对实现进行交叉 Review。这里的价值不是“两个模型投票”，而是引入独立视角。
实现者容易延续自己的假设，因此 Reviewer 不应该只收到一句“帮我看看代码”。更有效的 Review 会明确检查维度：
- 是否符合需求和验收标准；
- 是否破坏架构边界或引入隐藏耦合；
- 异常路径、并发、幂等和资源释放是否完整；
- 安全、隐私、权限和依赖风险是否可接受；
- 测试是否验证行为，而不是复述实现；
- 是否存在更简单、更易维护的方案。
Reviewer 应提交具体证据：文件与位置、触发条件、影响、复现方式和建议修复，而不是泛泛而谈。随后由实现工具处理问题，再运行验证。不同模型意见冲突时，不按模型名决定，而是回到需求、代码、测试和可复现事实。
还要警惕“模型互相背书”：如果几个工具共享了同一份错误假设，它们可能一致地给出错误结论。真正的独立验证应改变信息来源或验证方式，例如一个模型做静态 Review，另一个运行测试和场景检查，人再审查关键业务判断。
最终裁判不是模型，而是质量门禁
AI 生成的代码看起来正确，并不意味着系统行为正确。我的验收顺序通常是：
格式化 / Lint
↓
类型检查 / 编译
↓
单元测试 / 集成测试
↓
关键用户路径或 API 场景验证
↓
Diff 与架构一致性审查
能自动化的门禁应写入项目命令和 CI，而不是依赖 Agent 记住。Agent 必须报告它实际运行了什么、结果是什么、哪些验证因为环境限制没有执行。没有运行的测试不能写成“应该通过”，推测也不能伪装成证据。
高风险动作还要单独治理：生产部署、数据库迁移、删除数据、修改权限和对外发送都需要明确审批与回滚方案。本地模型保护了部分数据隐私，却不天然等于安全；模型下载来源、工具权限、Prompt 中的密钥、日志和外部插件同样需要管理。
把每次纠错变成下一次的默认能力
这套工作流最有价值的部分不是某一次把代码写快了，而是形成持续学习的闭环。
当我在 Review 中发现重复问题，会判断它应该进入哪一层：稳定的工程约束写回 AGENTS.md；架构取舍形成 ADR；领域事实进入领域文档；机械错误交给 Lint 或测试；高价值失败变成回归用例。这样下一次任务不需要依靠我再次提醒。
可以定期观察几项指标：从需求到合并的周期、首次验证通过率、Review 发现的问题数、人工返工时间、回滚次数，以及不同模型完成同类任务的成本。评价工具不能只看生成速度；一个写得快却带来大量复核工作的模型，未必更高效。
我的结论：人从编码者变成工作系统的设计者
Ollama、Qwen、OpenCode、Kimi、Claude Code、Codex 和 GPT 桌面版以后都会继续变化。今天最强的模型，明天可能只是工具箱里的普通一员。
真正可以积累的，是一套与模型无关的能力：把目标说清楚，把上下文写进项目，把架构变成可审核的决策，把任务拆成可验证的单元，让不同工具独立执行和 Review，再用自动化证据收口。
AI 降低了编码和探索的成本，但没有替我承担判断与责任。我的角色不是站在每一行代码前亲手输入，而是设计一套让正确上下文进入、让不同能力协同、让错误尽早暴露、让经验持续沉淀的工程系统。
这可能才是 AI 编程真正改变开发者的地方：我们不再只设计软件，也开始设计生产软件的方式。