【学习工作赛道】GuiYi 归一：面向复杂成果交付的多模型智能编排 Demo
官网：https://guiyi.work/
1. 简介
1.1 是什么
大家好，我是一名AI产品经理，以前没有写过代码，今年2月份开始用Trae每天开发产品，所以我是Trae绝对的忠实粉丝。过去半年时间以来，我用AI开发了将近30个产品，而Trae则是我最大的助力，现在我一个月要订阅5个Trae Ultra会员，3个Trae.ai，2个 trae.cn，可见我对Trae是真爱
。
GuiYi 归一不是一个“再套一层聊天壳”的 AI 产品，而是一个面向复杂成果交付场景的多模型智能编排平台 Demo。
它的目标不是只回答问题，而是把用户目标编译成一条完整主链：
Requirement → Plan → Run → Artifact → Evidence → Delivery
换句话说，GuiYi 关注的不是“AI 说了什么”，而是“AI 能不能把一个复杂目标真正拆开、执行、验证，并交付一组可追踪、可回看、可审计的成果”。
1.2 面向谁
GuiYi 当前面向的是三类高频用户：
个人创作者和小团队：希望快速把想法变成结构化需求，再继续推进成正式任务
产品、运营、项目协作团队：需要把需求、规格、执行、证据、交付串成一条工作链
复杂任务交付场景：不满足于“AI 给一段答案”，而要求结果可验证、可复盘、可管理
1.3 GuiYi 的真正产品定位
GuiYi 的底层定位是“成果交付型多模型智能编排平台”。
这意味着它和普通大模型产品的区别，不是“用了更多模型”，而是它把不同任务形态统一到同一套交付逻辑中：
用户目标不是一次性 prompt
执行过程不是单轮回答
结果不是一段文本
最终交付是带有上下文、证据、版本和验证关系的成果包
- 创作思路
2.1 为什么会做 GuiYi
我在长期使用各类大模型产品时，感受到一个越来越明显的问题：
今天很多 AI 产品都能很好地“回答问题”，但很少有产品真正把“目标理解 → 任务拆解 → 协作执行 → 验证 → 交付”做成一条闭环。
现实里的复杂任务不是一句话就能结束的，它往往要经历：
目标澄清
结构化需求沉淀
多阶段执行
多产物汇总
证据与结果核验
最终交付与验收
而大部分 AI 产品只覆盖了最前面的“表达”和“回答”，没有覆盖后面的“执行”和“交付”。
GuiYi 想做的，就是把 AI 从“回答机器”往“编排机器”和“交付机器”推进一步。
2.2 想解决的真实问题
GuiYi 重点解决四个问题：
需求表达和正式执行之间有断层
用户会聊天，但聊天内容很难稳定沉淀为正式 Requirement、Spec 和后续执行对象
AI 输出常常不可审计
很多工具能产出内容，但过程、证据、验证状态、交付版本都不清晰
多模态、多任务、多产物之间没有统一控制面
文档、代码、视频、音乐、图片等不同任务通常散落在不同产品里，彼此不通
多模型调用更多停留在“接多个 API”，而不是“真正编排”
真正的多模型系统不应该只是切换模型，而应该能决定何时拆解、何时路由、何时校验、何时回滚
2.3 我希望 GuiYi 成为什么
我希望 GuiYi 最终不是一个“大模型聊天产品”，而是一个真正的 AI 成果交付平台：
入口像 ChatGPT：让用户低门槛表达需求
编排像 Dify：不是只停留在对话层
工作区像专业生产系统：对象之间有明确结构与版本关系
结果表达像交付工作台：不是“回复一段话”，而是“交付一组可验证成果”
- 为什么这个方向有创新价值：多模型智能编排与 Sakana 启发
3.1 当前大模型真正的创新热点，不只是更强单模型
我认为当下大模型最值得关注的方向之一，不是简单比较“哪个模型参数更大、榜单更高”，而是：
如何把多个模型组织成一个能完成复杂任务的系统。
这背后对应的是一个很重要的方向变化：
从单模型能力竞争，走向多模型协作与集体智能
从静态工作流，走向动态编排
从一次回答，走向 test-time scaling 和多轮执行
从“工具调用”，走向“执行组织能力”
GuiYi 正是在做这一层产品化尝试。
3.2 Sakana 的案例给了我什么启发
Sakana AI于2026年6月发布了旗舰模型系列Sakana Fugu，其核心并非传统的单一巨型模型，而是一个经过专门训练的“学习型协调器”——通过自身的小模型智能调度GPT、Claude、Gemini等多个外部大模型，将复杂任务拆解并分派给最擅长的专家模型。该技术基于Trinity和Conductor算法，采用监督微调结合进化策略的两阶段训练法，使模型的调度策略不断进化。在此技术路径下，Fugu Ultra在GPQA Diamond、SWE-Bench Pro等多项关键基准测试中超越了Google Gemini 3.1 Pro、OpenAI GPT-5.5等顶尖闭源模型，达到全球领先水平。2026年1月，谷歌按约25至26亿美元估值战略投资Sakana AI。
Sakana AI 的一系列工作，对我理解下一代 AI 产品非常有启发。
几个最典型的点包括：
Fugu
它强调的不是“训练一个万能模型”，而是把多模型编排本身做成一种能力
这说明未来系统的核心不只是单模型，而是“协调器”和“协作拓扑”
AB-MCTS
说明多模型协作并不是简单投票，而是结构化搜索和协同推理
也就是说，编排层本身可以创造超越单模型的表现
The AI Scientist
证明 AI 可以不只做单点辅助，而是跑通从想法、实验、实现到总结的一条完整流程
Darwin Gödel Machine
更进一步地展示了 Agent 系统未来甚至可以进入“自我优化”和“可进化”的状态
3.3 GuiYi 和这条路线的关系
GuiYi 不是直接复刻 Sakana，也不是把这些研究包装成营销概念。
GuiYi 真正借鉴的是它背后的方向判断：
复杂任务天然需要多阶段、多角色、多能力协作
多模型系统的核心价值，不是“模型列表更长”
而是让最适合的能力在最适合的环节工作
因此 GuiYi 的方向不是“接更多模型”，而是做一个面向真实任务交付的多模型智能编排中枢。
3.4 GuiYi 更进一步的目标：把编排训练成总控大模型的原生能力
我希望 GuiYi 最终不只是拥有一个“外置工作流引擎”，而是进一步把编排能力本身训练给总控大模型，变成它的原生能力。
这里的“总控大模型”不是只负责做一次高层规划，而是要逐步学习并吸收所有全自动无人值守工作流中的关键编排环节，包括但不限于：
编程开发工作流
文档撰写与专业文档生成工作流
视频生成工作流
音乐生成工作流
图片生成工作流
3D 生成 / CAD / 空间内容工作流
更重要的是，不只是把单一领域的工作流训练进去，还要把跨领域、跨模态、多领域协同工作流中的每一个关键智能编排环节也训练给总控大模型，例如：
如何拆分一个复杂目标，判断它需要文档、代码、视频、音乐、图片还是 3D 组合交付
如何在多个子工作流之间做任务切分、先后顺序安排、依赖管理和结果汇总
如何根据任务特点进行模型路由、Agent 选择、Provider fallback 和质量复核
如何把多个领域的 Artifact、Evidence 和 Delivery 合成为同一份最终成果包
也就是说，GuiYi 的长期方向不只是“有很多工作流”，而是让总控大模型逐步学会：
如何编排单领域无人值守工作流
如何编排跨领域复合工作流
如何把这些编排策略沉淀成自己的原生能力，而不是永远依赖人工手写流程
如果这条路线成立，那么 GuiYi 最终想实现的不是“一个能调用很多工具的模型”，而是“一个原生具备复杂任务编排、路由、协同、治理、交付能力的总控大模型”。
4.GuiYi 的完整产品蓝图
4.1 不是单页面 Demo，而是一条完整主链
GuiYi 的完整主链，不是“从聊天开始到聊天结束”，而是：
用户输入目标
系统沉淀 Requirement
Requirement 进入 Outcome / Project / Schedule 结构
任务交给对应 Adapter 执行
生成 Artifact 与 Evidence
进入 Delivery 进行版本化交付
这条主链背后的产品观非常明确：
Requirement 是入口，不是聊天记录本身
Run 是执行载体，不是一次性调用
Artifact 是交付物，不是临时输出
Evidence 是可验证依据，不是日志摆设
Delivery 是出口，不是最后导出一下文件
4.2 GuiYi 的核心对象
我在梳理完整规划文档后，GuiYi 最有辨识度的一点是：它不是把各种页面堆起来，而是围绕一组清晰对象工作：
Requirement
Spec
Run
Artifact
Evidence
Delivery
Project
Library
这也是为什么 GuiYi 最终会更像一个“任务和成果编排系统”，而不是“对话 App”。
4.3 四条核心能力主链
根据整个规划体系，GuiYi 最终不是只做软件开发，也不是只做内容生成，而是会走向四条主链：
文档生成主链
编码开发主链
视频生成主链
音乐创作主链
它们不是四个孤立产品，而是共享统一控制面、统一证据链、统一交付链。
4.4 当前 Demo 在整个蓝图中的位置
当前参赛 Demo 并没有把全部蓝图一次性铺开，而是选取了最关键也最能说明问题的一段切片：
让用户可以进入产品
让用户可以表达需求
让需求进入正式工作台
让产品结构开始呈现出统一控制面的形态
我认为这比做一个“看起来什么都能做、但哪条链都不真闭合”的 Demo 更真实，也更有产品价值。
5.GuiYi 不是四个项目的拼盘，而是四个项目能力被重新编译后的归一化平台
5.1 四个项目为什么重要
GuiYi 的路线不是凭空想象出来的，它站在四个已验证方向的基础之上，但目标不是把四个项目简单打包，而是把它们各自最强的能力抽取出来，重新统一进同一套控制面和交付链。
这四个项目分别是：
CodeMaster：
allinone：
AIVideo：
shengmian：
5.2 CodeMaster 提供了什么
CodeMaster 对 GuiYi 最大的启发，是“全自动无人值守编程开发工作流”和更长任务的运行控制面。
它带来的不是单个功能，而是一整套运行时思想：
长任务执行
恢复治理
证据链记录
Artifact 管理
更接近真实生产环境的无人值守流
GuiYi 会吸收其中最关键的部分，把它沉淀进编码主链和运行治理能力。
5.3 allinone 提供了什么
allinone 对 GuiYi 的价值，不只是 UI/UX/IA，更重要的是它成熟的专业文档工作流和五层 wiki 体系。
它代表的是：
复杂知识与文档工程如何被系统组织
规划、文档、结构化产物如何进入版本链
UI/UX/IA 如何形成稳定方法论
GuiYi 当前前端重构已经直接吸收了 allinone 的：
HSL token
多壳层结构
query key 纪律
state views
工作台骨架
但 GuiYi 的目标不是停留在“像 allinone 一样的文档产品”，而是把文档能力进一步接入任务执行和交付。
5.4 AIVideo 提供了什么
AIVideo 对 GuiYi 的价值，是视频生成工作流的系统化经验。
这包括：
pipeline manifest
checkpoint
provider router
媒体处理链
质量门和成本意识
GuiYi 会把这些经验吸收到未来的视频主链和通用媒体 Adapter 中，而不是重新从零设计一套视频工作流。
5.5 shengmian 提供了什么
shengmian 对 GuiYi 的价值，是音乐创作主链的领域经验。
它贡献的不是“能生成音乐”这么简单，而是更专业的音乐工作流概念：
Music Blueprint
provider fallback
audio QA
metadata 和交付结构
这些会成为 GuiYi 音乐主链的重要组成部分。
5.6 GuiYi 如何超越四个项目
四个项目各自在单条赛道都可以独立存在，但 GuiYi 的目标不是做“四项目合集”，而是做一个统一交付母系统。
它的超越点在于：
统一合同层
不让每个能力都长成独立平台
统一控制面
文档、代码、视频、音乐不是四个孤岛
统一证据链
所有成果最终都要能进入可审计的 Evidence / Delivery 体系
统一交付出口
不是“做完了一个内容”，而是“形成一组有版本、有验证关系的交付包”
这也是“归一”这个名字真正想表达的含义。
- 未来能力版图：不仅是文档、代码、视频、音乐，还包括图片生成与 3D
6.1 GuiYi 的未来不是只做四条流
虽然 GuiYi 当前吸收了四个项目的核心能力，但规划文档已经明确说明：它并不仅仅止步于这四种内容形态。
从更完整的能力版图看，GuiYi 的扩展方向包括：
文档生成
编码开发
视频生成
音乐创作
图片生成
3D 生成 / CAD / 空间内容
以及更广义的数据、知识和多模态任务
6.2 图片生成的规划
图片生成在 GuiYi 的规划里不是随口一提，而是有明确位置的。
它未来会作为统一 Adapter 体系中的一条重要能力链，目标不是做一个独立图片 App，而是让图片生成进入同样的：
brief / style
generate
select / edit / upscale
safety / quality
artifact pack
这样的结构化主链。
也就是说，图片生成最终也会进入 GuiYi 的统一 Artifact / Evidence / Delivery 体系，而不是变成一个平行控制面。
6.3 3D 生成的规划
3D 能力目前在 GuiYi 的产品冻结顺序中属于更后面的阶段，但它已经明确存在于规划体系里。
它代表的是 GuiYi 未来从“文本和媒体交付”继续走向“空间内容和工程内容交付”的可能性。
从产品视角看，这非常关键，因为一旦系统能统一承接文档、代码、图片、视频、音乐和 3D，那么 GuiYi 就更接近一个真正意义上的多模态成果编排平台。
6.4 为什么这些未来规划也值得写进 Demo 帖
因为我认为一个好的比赛 Demo，不只是告诉评审“我现在做了几个页面”，还要说明：
这个 Demo 背后到底指向什么产品
为什么这个方向成立
为什么现在做的这一步是真实而必要的第一步
当前 GuiYi 的 Demo 已经证明入口和主链开始跑通，而图片、3D 等能力则说明这不是一个局部小工具，而是一条有明确扩展路线的系统级产品。
6.5 总控大模型的训练方向
在长期规划里，GuiYi 最关键的技术目标之一，是把这些工作流能力不只是做成外部模块，而是进一步训练进总控大模型。
我希望未来的总控大模型具备两层原生能力：
单工作流原生编排能力
直接理解并调度编程开发、文档撰写、视频生成、音乐生成、图片生成、3D 生成等无人值守工作流
跨工作流原生编排能力
能够把多个领域的工作流组合成一条跨领域主链，自动处理依赖、上下文传递、质量门和最终交付
这意味着未来 GuiYi 的核心竞争力，不只是“接了多少模型和工具”，而是总控大模型会逐步把这些编排经验内化成自己的能力结构。
7.Demo 体验地址
7.1 在线体验地址
官网首页：https://guiyi.work/
7.2 产品截图
8.TRAE 实践过程
8.1 第一阶段：把健康页改造成可体验产品入口
最开始，https://guiyi.work/ 不是产品首页，而是后端健康页。
我先用 TRAE 完成了前台入口的整体重构：
/ Landing
/login
/register
/chat
/app/*
这一步非常关键，因为比赛要求的不是“概念原型”，而是一个真的能体验的 Demo。只有把首页、登录、需求入口先做出来，评审才能真正进入产品。
8.2 第二阶段：做三层壳与九域导航
接着我没有停留在“能打开几个页面”，而是继续用 TRAE 把整个前端升级成产品架构：
PublicShell
WorkbenchShell
OperatorShell
并把一级导航固定为：
Inbox
Projects
Specs
Runs
Artifacts
Evidence
Deliveries
Library
Ops
这样做的目的，是让 GuiYi 看起来不再像“临时活动 Demo”，而是一个真正有 IA 和系统边界的产品。
8.3 第三阶段：统一设计系统与基建
为了让产品体验更完整，我继续借助 TRAE 重构了前端设计系统和基建：
引入 shadcn/ui
引入 Radix UI
引入 TanStack Query
复用 allinone 的 HSL token 和暗色模式基线
建立 query keys 与 state views
这让 GuiYi 的 Demo 不只是“功能能跑”，而是开始具备更接近真实产品的设计一致性和交互秩序。
8.4 第四阶段：修复 Requirement Entry Chain
在前台与工作台打通过程中，我发现前端已经依赖 /api/v1/requirements，但后端没有这条路由，导致需求提交主链不闭合。
于是我继续借助 TRAE：
排查前后端断链原因
新增 requirements 路由模块
实现 GET / POST 能力
重新部署与公网验证
最终把：
ChatIntake → createRequirement → /app/requirements
这条链跑通。
这一步对整个产品 Demo 的意义非常大，因为它意味着 GuiYi 终于不只是“前台能看”，而是“主链能走”。
8.5 这次用到的 TRAE 能力
整个过程中，我主要借助 TRAE 完成了这些事情：
把复杂产品需求拆解成可执行批次
辅助阅读大规模代码和规划文档
快速定位阻断点和接口断链问题
重构前端信息架构与工作台壳层
协助补后端路由与验证链路
帮助我在规划、实现、验证之间反复闭环
我最深的感受是：TRAE 对我最大的帮助，不只是写代码，而是能把“产品规划 → 结构设计 → 实现 → 审计 → 复跑”串起来。
8.6 开发关键步骤截图与Session ID
7609398825753789460:27925b8aa3e07ff1bdc3fb88f7cfe8c7_6a5391508e9c0d11927558fa.6a5681993ba37e13003f725e.6a5681993ba37e13003f725c:TRAE Work.0.1.36.no_sid.no_ppe.T(2026/7/14 11:36:09)
7609398825753789460:75572e9248eefaa7106134fb904c7b8b_6a5391508e9c0d11927558fa.6a568f323ba37e13003f74c5.6a568f323ba37e13003f74c3:TRAE Work.0.1.36.no_sid.no_ppe.T(2026/7/14 12:34:11)
7609398825753789460:b198d8d8c4a29314bd09906ed7ef250d_6a5391508e9c0d11927558fa.6a56f82f3ba37e13003f843b.6a56f82f3ba37e13003f8439:TRAE Work.0.1.36.no_sid.no_ppe.T(2026/7/14 20:02:07)
3176967724610643:5750e802c1ab8db3829e529a53412b1c_6a50ba85b83786b67b82a083.6a5690d8aa910ba56ea29daf.6a5690d8aa910ba56ea29dad:TRAE Work CN.0.1.35.no_sid.no_ppe.T(2026/7/14 12:41:12)
3176967724610643:3946607f0af0809a232848ac88b7244c_6a50ba85b83786b67b82a083.6a56c8f9aa910ba56ea2a57f.6a56c8f9aa910ba56ea2a57d:TRAE Work CN.0.1.35.no_sid.no_ppe.T(2026/7/14 16:40:41)
9.我认为 GuiYi 这次 Demo 最重要的亮点
9.1 它不是概念，而是已经能体验
GuiYi 不是 PPT，也不是静态原型，而是已经可以访问、登录、体验、进入工作台的真实 Web Demo。
9.2 它不是单轮回答，而是开始走向任务主链
用户的自然语言输入，不再停留在聊天消息里，而是进入 Requirement。
这是从“聊天产品”走向“执行产品”的关键一步。
9.3 它不只是一个页面，而是一条更大的产品路线的第一阶段
这次参赛 Demo 虽然展示的是第一阶段切片，但它背后承接的是一个更大的产品蓝图：
文档
代码
视频
音乐
图片
3D
这些能力最终不是平铺罗列，而会被统一在一个成果交付系统里。
9.4 它体现的是 AI 产品下一阶段的重要方向
我最想表达的一点是：
AI 产品的下一阶段，不再只是“谁能更好地回答”，而是“谁能更稳定地组织多模型、多任务、多产物，完成真正复杂的成果交付”。
GuiYi 正是沿着这个方向往前走。
10.后续计划
GuiYi 当前已经完成前台入口、工作台骨架、Requirement 主链等关键基础，下一步会继续推进：
Media & Music Workspace
Design System & Component Governance
更完整的 Requirement → Spec → Run → Delivery 主链
图片生成 Adapter
视频与音乐主链进一步闭合
更长期的 3D / CAD / 空间内容能力
更真实的模型调用、执行调度与持久化能力
从更长期的技术演进看，我还希望继续推进一条更底层的方向：
将单领域无人值守工作流中的编排知识持续沉淀到总控大模型
将跨领域、多领域协同工作流中的编排知识持续沉淀到总控大模型
让“如何拆任务、如何路由模型、如何组织子流程、如何汇总交付”逐步从外置流程配置，升级为总控大模型的原生能力
最终形成一个真正具备复杂任务总控、跨领域编排与成果交付能力的总控大模型
我希望 GuiYi 最终能成为一个真正的多模型智能编排与成果交付平台，而不是一个短期活动里的“好看 Demo”。
11.报名帖链接