你有没有遇到过这种情况------对着 AI 说"帮我做个参数化出图系统"，它回了一句"好的"，然后直接开始写代码，结果方向完全偏了？
这不是 AI 的问题，是流程的问题。
my-opencode-deepseek-config 是一套面向 DeepSeek 模型深度优化的 OpenCode 配置方案，它把 AI 编程从一个"聊天窗口"变成了一个受控的多人协作开发管线。本文通过一次真实的全流程执行，展示这套配置是如何工作的。
1. 从模糊需求到可执行计划------Brainstorming 门禁
任何实现动作之前，必须先通过设计审核。
当你说"帮我做个参数化出图系统"时，配置不会立刻写代码。它会强制走一遍结构化设计流程：
需求 → 项目上下文探索 → 关键技术验证 → 6个澄清问题 →
2种方案对比 → 逐节设计确认 → 设计文档 → 自查 → 用户审阅 → 实现计划它做了什么：
- 上下文探索：自动扫描了现有代码库（已有 SOLIDIMPORT/SOLIDEXPORT/SOLPROFEXPORT 三个命令），识别出现有基础设施
- 技术调研：研究了 GStarCAD API 的限制（COM 层不可靠、无 BREP API 等），这些约束直接决定了方案选择
- 逐项澄清：一次只问一个问题，用选择题方式引导你做出关键决策------CSG 粒度、参数输入方式、构件范围、3D 生命周期......
- 方案对比：提出两种代码复用策略（直接提取 vs. 接口抽象），给出推荐和理由
- 设计文档自检：写完后自己扫描一遍------有没有 TBD？有没有矛盾？有没有歧义？
关键设计理念：AI 不应该在理解需求之前就开始写代码。这套流程确保了"你想的"和"AI 理解的"是同一件事。
2. 多智能体执行引擎------把 10 个任务当 10 个"人"来管
设计确认后，配置自动生成了 10 个任务组成的实现计划。但执行方式不是单线程一条条做，而是子智能体驱动开发：
2.1 任务分解的艺术
每个任务是一个独立可测试的交付单元，有自己的：
- 任务简报：精确到每一行代码，没有 "TBD" 或 "implement later"
- 接口契约 ：明确声明
Consumes什么、Produces什么 - 审查包：自动生成的 diff + commit log
2.2 并行调度与模型分派
这是配置的核心能力------它知道什么时候并行、用什么模型：
| 任务类型 | 模型选择 | 调度策略 |
|---|---|---|
| 纯数据模型创建（ParamConfig.cs） | Flash（低成本） | 独立 → 并行 |
| 大型提取/重构（CsgBuilder） | Pro（强推理） | 文件冲突 → 串行 |
| 代码审查 | Pro（判断力） | 与实现并行 |
实际执行中，Task 2 和 Task 3（两个数据模型文件，完全独立）同时派发给两个子智能体，分别完成后各自提交，再由审查智能体并行审查。
2.3 上下文隔离
每个子智能体启动时只有任务简报 + 全局约束，不继承会话历史。这意味着：
- 智能体不会被之前的对话污染
- 每次派发的成本是可控的（不会随会话增长而膨胀）
- 出错时只需重新派发单个任务
3. 质量保障体系------四层审查门禁
这套配置最突出的特点不是"能写代码"，而是能审查代码。
3.1 审查等级
Task Review（每任务） → Fix Loop（最多 5 轮） → Final Review（全分支）Task Review 不是走过场------它输出两个明确的判决：Spec Compliance: YES/NO 和 Task Quality: APPROVED/APPROVED_WITH_SUGGESTIONS/BLOCKED。审查智能体会逐行对比 diff 和任务简报，检查：
- 规约符合性：代码是否实现了简报中要求的每一项？
- 代码质量：有无死代码、未使用导入、命名不一致？
- 架构一致性：是否违反了项目约定？
- 安全性：空 catch 块？未处理的 null 路径？
3.2 分级响应
审查结果按严重性分流：
| 严重性 | 处理方式 |
|---|---|
| Critical | 必须修复，进入修复循环 |
| Major | 必须修复，进入修复循环 |
| Minor | 记入账本，Final Review 时集中处理 |
| Nit | 同上 |
本次会话中，Task 级审查共发现 1 个 Critical （布尔运算缺少位置变换导致减法无效）和 2 个 Major（空值守卫缺失），全部在修复循环中解决。
3.3 Final Review------跨任务视角
所有任务完成后，还有一个全分支审查。它能发现单任务审查无法发现的问题------跨文件的接口不匹配、重复代码、架构漂移。
4. 自我审计------配置能审查自己
执行结束后，一个有趣的元操作发生了：用这套配置分析自己。
Oracle 智能体被派发去审计 opencode.jsonc、dcp.jsonc 和 AGENTS.md 三个核心文件，发现了 10 项问题，然后 deep-worker 自主应用了 12 项精准编辑：
- 3 个 agent 的 model 在 JSON 和 .md 两处定义了（双源冲突------改一处忘另一处时静默使用错误模型）
- 原生压缩和 DCP 插件同时开启导致双重压缩
- 用户消息保护关闭（你粘贴的错误日志可能被压缩掉）
- 压缩通知关闭（完全不知道上下文在什么时候被裁剪）
12 项编辑，3 个文件，一次提交，部署验证------配置修复了自己。
5. 上下文管理------让它能持续工作
AI 编程工具最大的短板是上下文窗口有限。这套配置用三层策略解决这个问题：
| 层级 | 策略 | 效果 |
|---|---|---|
| 派发隔离 | 子智能体只拿任务简报，不带历史 | 每个任务的上下文是干净的 |
| DCP 压缩 | 自动识别已完成阶段并浓缩为技术摘要 | 关闭的工作阶段不占窗口 |
| 账本机制 | 进度记录到 git-ignored 文件 | 会话断掉后，重连时可以恢复进度 |
实际效果：整个会话跨越了 200+ 条消息、10 个任务、13 次提交，但执行过程没有因为上下文膨胀而退化。
6. 修复纪律------不偷懒、不越权
有几条硬性规则定义了"负责任"的 AI 行为：
- 控制器不自己改代码。发现问题 → 派回实现者修复 → 再审查。自己改代码跳过审查是最大的质量风险。
- 审查不分级不看脸。Minor 发现和 Critical 发现一样走流程，只不过 Minor 可以延迟到 Final Review。
- 5 轮封顶。修复循环最多 5 轮，超过就停下来------要么是结构性问题需要重新设计，要么是审查方过度挑剔需要人工裁定。
- 每轮都有证据。任何"完成"声明都必须附带验证证据------构建输出、测试结果、diff 确认。
总结
my-opencode-deepseek-config 不是一套"提示词合集"------它是一个有纪律的 AI 开发流程：
- 不走捷径：从设计到计划到执行到审查，没有一步可以跳过
- 知道自己不知道什么：不确定的地方会提问，而不是猜测
- 可以被审计：配置本身暴露了所有决策点，而且可以自我诊断
- 成本可控：Flash 处理简单任务，Pro 处理复杂推理，充分利用模型分层
如果你对 AI 编程工具的期望不只是"快"，而是"可靠"，这套配置值得一试。