对话笔记直发：2026年08月09日。分类：小程序接单。
- 1224 可以。昨晚这段聊天的核心其实不是某个具体模型，而是我们把你一直在摸索的 AI 软件开发工作流重新拆成了一条比较完整的流水线。
AI 项目开发工作流对话笔记
日期：2026-08-08 → 2026-08-09 主题：GPT-5.6 模型分工、OMO 子代理，以及从 0→1 项目的 AI 开发工作流
一、GPT-5.6 模型与不同推理强度
昨晚前半段主要讨论了 GPT-5.6 不同模型之间应该如何分工。
我们形成的核心理解是：
Luna：偏日常聊天、快速响应、简单任务。
Terra：偏日常开发、代码修改、一般性分析。
Sol：更适合复杂推理、架构设计、重大决策、复杂代码任务。
同一个模型还可以存在不同的推理强度，例如普通 / High / Max / Ultra 等。
模型本身的基础能力和推理强度是两个不同维度。
因此不能简单理解成：
Terra Ultra 一定比 Sol Medium 强。
更合理的理解是：
模型等级 × 推理投入
两者共同决定实际效果。
对软件开发的启发
对于 AI Coding：
工作 推荐思路
简单代码搜索 Luna 查找相关文件 / 上下文 Luna 普通 Bug 修复 Terra 普通功能开发 Terra 复杂业务分析 Sol 架构设计 Sol 大型重构 Sol 最终 Review Sol 极复杂任务 Sol + 高推理强度
二、OMO 的核心思路：不同 Agent 使用不同模型
我们又聊到了 OpenCode 的 OMO（Oh My OpenCode）。
OMO 的一个重要价值就是：
不同子代理可以承担不同职责，并且可以指定不同模型。
因此没有必要让整个任务从头到尾都使用最贵、最强的模型。
例如：
Explore / 搜索代码 ↓ Luna
Plan / 架构设计 ↓ Sol
Implementation / 写代码 ↓ Terra
Review / 最终审查 ↓ Sol
这实际上形成了一个很重要的思想：
让模型能力与任务的“判断密度”匹配。
简单的信息检索，不需要浪费顶级模型。
真正涉及架构、取舍、风险判断的地方，才值得使用顶级模型。
三、你之前的“顶级模型规划 → 普通模型执行 → 顶级模型 Review”思路
你提出了一个非常重要的工作流：
用 Sol / Fable 5 这种顶级模型先把 Plan 设计到足够细，然后交给 Terra 等普通模型执行，最后再让顶级模型 Review。
我们讨论后认为：
这个思路本身是成立的，而且实际上比“全程使用顶级模型”更合理。
原因是软件开发中的不同阶段，对模型能力的要求完全不同。
顶级模型最有价值的地方
不是“写代码”。
而是：
理解问题
发现隐藏需求
架构设计
技术选型
权衡方案
识别风险
拆分任务
Review
而大量实际编码工作往往具有较强确定性。
所以可以形成：
高能力模型 ↓ 思考 / 设计 / 决策 ↓ 中等模型 ↓ 执行 / 编码 ↓ 高能力模型 ↓ Review / 纠错
这是一种 “强模型负责决策，普通模型负责生产” 的思路。
四、真正关键的问题：Grill Me 到 Trellis 中间缺了什么？
这是昨晚最核心的一部分。
你原来的理解大概是：
Grill Me ↓ 梳理需求 ↓ Trellis ↓ 开始开发
但是我们发现：
这中间其实缺了一大块。
因为 Grill Me 解决的是：
“我到底想做什么？”
而 Trellis 更适合解决：
“已经明确要怎么做了，现在开始执行。”
所以两者之间需要一个完整的 设计层 / Engineering Design Layer。
五、我们最终拆成了 6 个阶段
整个流程变成：
① Goal ↓ ② Product Design ↓ ③ Architecture Design ↓ ④ Architecture Review ↓ ⑤ Implementation Plan ↓ ⑥ Trellis Execution
也就是：
目标 → 产品 → 架构 → 评审 → 实施计划 → 编码
六、第一阶段：Goal —— Grill Me
目的
回答：
“我到底想做什么？”
这个阶段不要急着考虑：
数据库
API
技术栈
文件结构
代码
怎么实现
而是把你脑子里的模糊想法变成一个明确目标。
例如：
“我要给微信小程序增加一个会员系统。”
经过 Grill Me 之后应该变成：
“用户可以注册 / 登录，通过会员等级获得不同折扣，后台可以管理会员等级，订单系统根据会员等级自动计算优惠。”
这时候才算真正从：
模糊想法 → 清晰目标
七、第二阶段：Product Design —— 产品设计
这一步解决：
“这个东西具体应该长什么样？”
主要包括：
- 用户角色
例如：
普通用户
VIP 用户
管理员
- 用户流程
例如：
用户进入小程序 ↓ 登录 ↓ 浏览商品 ↓ 加入购物车 ↓ 提交订单 ↓ 支付 ↓ 订单完成
- 功能模块
例如：
用户系统 商品系统 购物车 订单系统 支付系统 会员系统 后台管理
- MVP 范围
非常重要。
明确：
第一版到底做什么？
以及：
什么东西暂时不做？
八、第三阶段：Architecture Design —— 架构设计
这是从“产品”真正进入“工程”的阶段。
回答：
“这个产品应该怎么被实现？”
主要包括：
技术选型
例如：
前端技术
后端技术
数据库
缓存
文件存储
鉴权方案
部署方式
系统模块
例如：
Frontend │ ├── User ├── Product ├── Cart ├── Order └── Payment │ ↓ Backend │ ┌────┴────┐ ↓ ↓ Database Storage
数据模型
例如：
User Product Order OrderItem Payment
以及它们之间的关系。
API
例如：
POST /auth/login
GET /products
GET /products/:id
POST /orders
POST /payments
权限
例如：
用户 ↓ 只能访问自己的订单
管理员 ↓ 可以管理商品、订单、用户
九、第四阶段：Architecture Review —— 架构评审
这一步非常重要。
不要让设计模型自己设计完之后马上开始编码。
而应该专门再问一次：
“这个方案真的合理吗？”
重点检查：
是否过度设计？
比如一个小程序项目：
微服务 Kubernetes 消息队列 Service Mesh 分布式缓存
可能完全没有必要。
是否遗漏关键场景？
例如支付系统有没有考虑：
支付成功 支付失败 支付超时 用户取消 支付回调 重复回调 订单状态异常 退款
是否存在架构风险？
例如：
数据一致性
权限漏洞
并发问题
API 设计问题
数据库结构问题
后期扩展困难
是否有更简单的方案？
这一点尤其重要：
不是设计得越复杂越专业。
真正优秀的架构通常是：
在满足当前需求的前提下，尽可能简单。
十、第五阶段：Implementation Plan —— 实施计划
到了这里，才真正开始回答：
“代码应该按照什么顺序写？”
例如：
Phase 1 项目初始化
Phase 2 数据库设计
Phase 3 用户系统
Phase 4 商品系统
Phase 5 购物车
Phase 6 订单
Phase 7 支付
Phase 8 后台管理
Phase 9 测试
Phase 10 部署
然后继续往下拆。
例如：
订单系统 ├── Order Model ├── Order API ├── Create Order ├── Cancel Order ├── Pay Order ├── Complete Order ├── Refund Order └── Order Tests
最终应该达到：
Trellis 接到之后，不需要重新思考整个产品应该怎么做。
它主要负责：
按照已经确定的工程方案执行。
十一、第六阶段：Trellis —— 执行
到了这里才把项目正式交给 Trellis。
此时它拿到的应该已经不是：
“帮我做一个商城。”
而应该是：
Goal ↓ Product Design ↓ Architecture ↓ Architecture Review ↓ Implementation Plan ↓ Trellis
所以 Trellis 的任务变成：
执行工程计划，而不是重新设计产品。
十二、这五个阶段分别应该用什么？
昨晚最后一个问题就是这个。
结论是：
不建议全部使用 Grill Me。
Grill Me 最适合的是第一阶段：
① Goal
Grill Me
负责：
把模糊想法变成明确目标。
② Product Design
推荐：
Sol / 顶级模型
负责：
产品经理 + 产品架构师
输出：
用户角色
用户流程
功能列表
MVP
产品边界
异常场景
③ Architecture Design
推荐：
Sol / 顶级模型
负责：
首席架构师
输出：
技术选型
系统架构
模块划分
数据库
API
权限
部署
测试策略
④ Architecture Review
继续使用：
Sol / 顶级模型
但这时候角色发生变化：
不要让它继续当设计师，而是让它当“挑刺的人”。
可以让它专门寻找：
设计漏洞
过度设计
遗漏需求
安全问题
数据一致性问题
扩展性问题
更简单的替代方案
⑤ Implementation Plan
可以：
Sol → Terra
如果项目复杂：
Sol 负责最终拆解。
如果架构已经非常稳定：
Terra 也可以负责把设计拆成具体开发任务。
最终产物应该是：
Trellis 可以直接接管的执行计划。
⑥ Execution
Trellis
负责：
创建文件
修改代码
执行命令
测试
修复
收口
按计划推进
十三、最终形成的完整 AI 开发流水线
这是昨晚最值得保留下来的核心：
┌─────────────────────────────┐ │ ① Grill Me │ │ 澄清模糊需求 │ │ “我要做什么？” │ └───────────