如果把时间拨回到一年前我使用 AI 的方式非常简单打开一个聊天窗口把问题发进去等待答案不满意就补一句“再详细一点”“再专业一点”或者“换一种表达”。这种用法刚开始很惊艳但任务变多以后我越来越频繁地遇到同一个问题聊天记录越来越长模型扮演的角色越来越混乱内容创作、技术分析、会议整理和代码排错全部堆在一个上下文里最后看似什么都能做却没有哪件事真正形成稳定流程。真正让我改变思路的不是某个更长的提示词而是“不要再把 AI 当成一个无所不能的员工而要把它组织成一支分工明确的团队”。最近我看到产品更新页加入 GPT 5.6 Luna、Terra、Sol 三种模型这种想法一下变得具体起来Luna 负责创意洞察Terra 负责旗舰推理Sol 负责高效日常再配合 AI 聊天、多模型协作、无限画布和角色对话一个人也能搭建出小型虚拟项目组。这篇文章不再讨论“哪一个模型最强”而是从项目管理的角度完整复盘怎样让三种模型共同完成一个真实任务从模糊需求出发做用户研究、产品方案、技术设计、内容发布和知识沉淀。文中也会讲到如何通过 API 将这种协作嵌入业务以及向量检索和 RAG 为什么是虚拟团队的长期记忆层。需要先说明本文关于 Luna、Terra、Sol 的定位来自产品更新页所展示的信息。文中涉及的团队组织、路由、RAG 和工程流程属于通用实践不代表产品已经提供所有示例能力也不对价格、额度、延迟、并发、数据保留或 SLA 作出推断。真正接入前仍应以当前页面、接口资料和实际测试为准。一、很多人缺的不是更强模型而是一张组织结构图使用单一聊天窗口时我们常常把四类工作混在一起。第一类是探索。我们还不知道目标是什么只能通过发散、类比和连续追问寻找方向。第二类是判断。方向出现以后需要根据事实、限制和风险筛掉不可行方案。第三类是执行。决定已经做出需要整理、改写、转换格式、生成清单。第四类是记忆。任务结束以后需要把结论、证据和失败经验保存下来供下一次检索。这四类工作对 AI 的要求完全不同。探索阶段太保守会迅速收敛到平庸答案判断阶段过度发散会让决策一直悬而不决执行阶段反复深度推演会浪费注意力记忆阶段没有结构下一次仍要从头解释背景。传统提示词的问题是试图让一个模型在同一轮中完成所有身份切换。我们会写“你既是一名有创意的策划又是一名严谨的架构师同时还是擅长落地的执行专家。”这句话听起来很完整实际包含了互相冲突的评价标准。模型不知道此刻应该优先追求新颖、正确还是快速只能给出一份折中的答案。组织虚拟团队的第一步就是承认这些工作不该挤在同一个工位。我的分法很直观让 Luna 负责探索让 Terra 负责判断让 Sol 负责执行再用无限画布保存项目状态用向量检索保存长期知识。这样每次对话不再问“AI 能不能做”而是先问“这项工作应该流向哪个角色”。这张组织结构图的价值甚至高于某个提示词模板。提示词只能优化一次交互结构却能约束整个项目。即使模型以后更新只要探索、判断、执行、记忆四层仍然存在工作流就可以继续复用。二、先给三位“虚拟同事”写岗位说明书组建团队时最怕的是岗位名称很酷职责却高度重叠。三种模型如果都被要求“给出最佳答案”最后仍是三份相似回复。为了让协作真正发生我给 Luna、Terra、Sol 分别写了一份简短岗位说明书。Luna 的职责不是交付最终结论而是扩大候选空间。它需要发现隐藏需求、提出反常识问题、连接不同领域、生成多个叙事方向并主动指出每个创意可能落入的俗套。Luna 的产物应该是“可以继续研究的可能性”而不是“已经确定的方案”。Terra 的职责不是让文字显得更复杂而是缩小不确定性。它需要保存约束、区分事实与假设、建立因果链、寻找反例、设计验证步骤并在证据不足时明确停止。Terra 的产物应该是“为什么选择或放弃某个方案”而不只是一个结论。Sol 的职责不是替前两个角色重新思考一遍而是把已经明确的任务快速转成可用交付。它负责摘要、改写、表格、清单、会议纪要、格式转换、常规问答和边界清楚的代码辅助。Sol 的产物应该是“可以直接进入下一环节的标准件”。岗位说明书还要写清楚禁止事项。Luna 不得把创意猜测写成产品事实Terra 不得因为推理完整就假装拥有外部证据Sol 不得为了补齐格式而编造缺失字段。三者遇到未知信息时都必须保留“待确认”而不是用流畅语言把空白填满。有了这份说明书多模型协作才从模型对比变成流程协作。一个模型的输出不再是终点而是另一个角色的输入。团队是否有效也不看谁写得最长而看信息经过交接后是否变得更清楚、更可信、更容易执行。三、用一个真实项目测试为开发者做一套AI知识助手为了避免只讲抽象方法我给这支虚拟团队设定了一个完整任务为一个开发团队设计内部 AI 知识助手。它需要回答接口接入、部署配置、故障排查和项目规范问题还要能把复杂资料整理成新人看得懂的操作步骤。项目刚开始时需求非常模糊。有人希望它像搜索引擎有人希望它直接解决报错有人希望它能自动写代码还有人要求它“什么问题都能回答”。如果直接让模型写技术方案它很可能会顺着所有愿望列出一长串功能最后得到一个范围失控的系统。我先把原始材料放进无限画布用户访谈记录、现有文档目录、常见工单、错误日志样本、权限限制和上线时间。每份材料只标记来源不急着得出结论。然后建立四种节点颜色已确认事实、未经验证的假设、已经做出的决定、需要继续调查的问题。这一步很重要。聊天窗口中的信息是按时间排列的而项目决策需要按关系排列。某条权限限制可能同时影响检索、日志和回答展示某个接口版本变化可能同时影响十几篇文档。放在画布中以后这些关系更容易被看见模型也不必每次从几十轮对话里寻找上下文。随后项目进入第一个正式阶段不是设计功能而是重新定义问题。这个任务由 Luna 开始。四、Luna的第一项工作把“做个知识助手”改写成可研究的问题我没有让 Luna 直接写需求文档而是给它三类输入开发者最近一个月最常见的提问、团队当前的文档结构、项目明确不能做的事情。然后要求它从新人、资深开发者、值班工程师和技术负责人四个角色出发分别描述他们在什么时刻需要帮助。Luna 给出的价值不在于某一条需求多么惊艳而在于它帮助团队跳出了“做一个聊天框”的默认想象。新人需要的可能不是自由问答而是按环境生成接入清单值班工程师需要的不是长篇解释而是根据状态码快速定位证据技术负责人关心的不是某次回答而是哪些知识长期缺失、哪些故障反复发生。接下来我让 Luna 提出一组反向问题如果不做聊天界面还有哪些方式能解决同样问题如果助手不能访问任何生产数据它还能提供什么价值如果回答必须给出证据界面应该怎样变化如果文档存在多个版本用户如何知道当前答案适用于哪一版这些问题把项目从“增加一个 AI 功能”转向“减少开发者寻找和验证信息的成本”。看起来只是措辞变化实际决定了后续架构。前者容易追求功能数量后者会关注检索命中率、证据版本、回答边界和问题解决时间。Luna 还生成了多种产品形态对话助手、工单侧边栏、错误码导航器、部署清单生成器、文档差异解释器。团队不需要全部实现但可以比较哪种形态最接近真实工作。探索阶段的目标不是立刻选中一个而是避免因为第一个想法听起来合理就错过更合适的入口。这个过程让我意识到创意模型最适合处理的不是“帮我写一句更漂亮的话”而是“帮我发现我们其实在解决另一个问题”。当 Luna 被放在需求前端它产生的价值会影响整个项目而不仅是发布时的宣传文案。五、Terra接手把好点子送进约束条件里碰撞有了候选方向以后团队最容易犯的错误是凭喜好投票。对话助手看起来熟悉错误码导航器看起来专业文档差异解释器看起来新颖但它们是否值得做必须回到约束和证据。我把 Luna 的候选方案交给 Terra同时提供五项硬条件首期只能使用现有技术文档不能读取生产环境敏感数据答案必须显示来源用户需要区分不同软件版本失败时不能伪造完整结论然后要求 Terra 不做文案润色只建立决策矩阵。矩阵包含用户价值、资料准备成本、技术依赖、错误风险、可评估性和首期范围六列。每个判断都必须说明依据来自哪一条输入如果没有依据就标记为未知。这样可以避免模型用听起来专业的形容词替代证据。Terra 发现“什么都能问”的通用聊天入口虽然容易演示却最难建立清晰评估。相比之下以接口接入和常见故障为首期范围更容易准备标准问题、期望证据和正确步骤。于是项目没有把通用助手当作第一目标而是先做“有证据的技术问题导航”。接下来是风险分析。Terra 把失败拆成四层检索不到正确材料检索到过期资料材料正确但生成误读答案正确却展示给了无权限用户四层问题不能靠同一个“回答准确率”指标解决需要分别设计测试和保护措施。它还提出一个非常关键的停止条件当召回材料没有覆盖结论时系统必须返回资料不足并展示已经检索到的范围不能让模型依靠通用知识补全内部配置。这个规则牺牲了一部分回答的流畅感却保护了知识助手最重要的可信度。这就是 Terra 在虚拟团队中的作用。它不是负责否定创意而是让创意接受现实检验。经过这一步团队得到的不只是“做哪个功能”还知道为什么这样选、什么情况下结论需要重审。六、Sol把决策变成交付没有它方案永远停在讨论里经过 Luna 发散和 Terra 评估画布上已经有大量信息但这些材料还不能直接交给开发团队。会议中的判断散落在不同节点术语写法不一致一些结论是段落一些结论是表格还有一些只是评论。此时最适合让 Sol 进入。它的第一个任务是把已经确认的内容整理成一页项目说明目标用户、首期范围、不做事项、核心流程、成功标准和待确认问题。要求非常明确只能压缩和重组不能新增功能。第二个任务是生成验收清单。例如每个回答是否包含来源、版本和更新时间没有足够证据时是否明确停止同一问题在不同文档版本下是否能显示差异敏感内容是否在进入模型前完成过滤错误日志是否避免保存 API Key 和用户正文。第三个任务是把讨论转成开发任务。Sol 按“输入、处理、输出、异常、验收”五段模板为文档导入、切分、索引、检索、回答生成和引用展示分别生成任务卡。Terra 已经决定了系统边界Sol 负责让边界进入每个执行项。第四个任务是会议管理。每次评审结束后Sol 从记录中提取新决定、负责人、截止时间、被推翻的旧决定以及仍未解决的问题。它不会重新判断方案只确保团队知道下一步做什么。很多人容易低估这类工作觉得摘要和清单没有复杂推理那么高级。但项目失败往往不是因为没人提出好点子而是决定没有进入文档文档没有进入任务任务没有进入验收。Sol 承担的是组织中的“传动系统”它让 Luna 和 Terra 的价值真正落地。七、无限画布为什么比超长聊天记录更适合项目协作项目进行两周以后单一聊天记录通常会出现三个问题。第一早期假设和最终决定混在一起新成员不知道哪一句仍然有效。第二相同概念被不同人用不同名称表达模型也会把它们当成多个对象。第三重要限制被大量生成内容淹没后续对话容易重新提出已经否决的方案。无限画布可以把项目状态从时间线中解放出来。我会在中央放当前架构左侧放输入材料和事实右侧放方案与决定下方放测试结果和失败案例。每个决定都连回支持它的证据每个待办都连到受影响的模块。三种模型围绕画布的使用方式也不同。Luna 主要在问题区域增加分支寻找遗漏场景Terra 沿连接关系检查依赖和冲突Sol 定期将已完成分支压缩成摘要归档不再使用的节点。这样既保留探索过程又不会让画布无限膨胀。角色对话则可以模拟评审会议。我会设置产品负责人、开发者、安全审查者和新人用户四个角色。产品负责人关心范围开发者关心接口和异常安全审查者关心敏感数据新人用户负责指出术语障碍。让不同模型承担角色时重点不是表演语气而是坚持各自的评价标准。例如当团队提出“记录所有问答用于持续优化”时产品角色可能觉得有价值安全角色会追问是否包含密钥、日志和内部代码开发角色会追问存储结构和删除机制新人角色会关心是否能够查看或撤回自己的内容。一个看似简单的功能由此暴露出多条必须确认的条件。画布最终应该是一份活的项目地图而不是漂亮的思维导图。每个节点要么代表事实要么代表决定要么代表动作。无法归类的生成内容应及时删除。只有这样多模型产生的大量信息才不会变成新的管理负担。八、虚拟团队也需要“交接协议”否则上下文会在途中丢失人与人协作需要交接模型之间同样需要。最常见的低效方式是把 Luna 的全部长回答原样复制给 Terra再把两份回答全部发给 Sol。上下文越来越长真正重要的约束反而不容易被识别。我为三种交接设计了固定格式。Luna 交给 Terra 的内容只包含候选方向、目标用户、可能价值、依赖假设和已知风险不包含大量修辞。Terra 交给 Sol 的内容只包含已确认决定、决定依据、硬性限制、待办和禁止新增项不包含完整推理草稿。Sol 回传项目画布的内容则包括完成状态、格式化交付、发现的缺失字段和需要升级的问题。每份交接单顶部都有一个版本号和时间。因为模型配置、产品资料和项目决定都可能变化没有版本的摘要很快会被误认为当前事实。涉及接口时还要记录测试环境、请求路径、模型标识来源和响应结构版本。交接协议还要限制信息损失。摘要不能只写“方案可行”而要保留“在什么条件下可行”不能只写“接口失败”而要保留状态码、错误阶段和已经排除的原因不能只写“用户喜欢”而要说明样本来自谁、使用了什么任务。一套好的交接格式会让模型替换变得容易。今天用 Luna 做探索未来换成另一个创意模型只要它输出相同字段后面的 Terra 和 Sol 流程仍能继续。组织能力因此不再绑定某一次对话而是沉淀为可复用的协议。九、给虚拟团队增加长期记忆为什么需要向量检索与RAG聊天上下文适合保存当前任务但不适合承担团队全部历史。项目文档、接口说明、故障记录、评审决定不断增加以后不可能每次都完整塞进提示词。内容太长不仅增加处理负担还会让真正相关的证据被无关材料淹没。RAG 的基本思路是先从资料库中找到与问题相关的片段再把这些片段交给模型生成回答。向量检索可以根据语义相似度寻找材料即使用户的表达与文档标题不完全相同也有机会命中相关内容。需要强调本节描述的是通用工程方法不表示某个产品已经具备全部向量数据库、Embedding、重排或评测功能。具体能力仍需根据实际资料确认。对于这支虚拟团队长期记忆至少分为四类。第一类是产品事实例如功能说明和当前接口文档。第二类是项目决定例如为什么首期只做某些场景。第三类是操作经验例如某类 401、404 或超时如何排查。第四类是失败样本例如哪些问题曾经召回错误文档、哪些回答缺少证据。入库前不能简单把所有文件切成相同长度。接口文档应尽量保持参数、示例和错误说明的局部完整故障复盘应保留现象、证据、原因和修复的关联项目决定应同时保存背景、适用范围和失效条件。切分方式决定模型以后能看到什么上下文。检索回来以后也不能立刻生成最终答案。首先过滤权限和版本再检查来源时间然后判断不同片段是否冲突。Terra 适合承担证据审查Luna 可以在召回不足时做查询改写但不能把改写词当成事实Sol 适合把已经确认的证据压缩为易读回答。长期记忆真正有价值的标志不是“存了多少文档”而是新成员提出真实问题时系统能否找到正确版本、显示证据、承认未知并把新发现重新沉淀进知识库。只有形成检索、使用、纠错、再入库的闭环向量引擎才不是一个展示性组件而是虚拟团队持续成长的基础设施。十、从界面走向API怎样把三种角色接进业务系统在 AI 聊天和多模型协作界面中验证流程以后开发团队通常会希望把它接进自己的工单、内容后台或知识助手。这时最重要的不是立刻写大量业务代码而是先把任务标签与具体模型配置分开。例如业务系统只提交idea_discovery、evidence_reasoning、routine_delivery三类任务。路由层根据当前实际可用模型把探索类任务映射到创意模型把判断类任务映射到推理模型把执行类任务映射到日常模型。以后模型 ID 变化时只更新配置不修改每个业务模块。还要特别注意产品界面展示的 Luna、Terra、Sol 名称不一定等于 API 请求中的模型标识。开发者不能只根据截图猜测model字段应以当前控制台、接口文档或模型列表返回的真实 ID 为准。向量引擎已经确认的调用信息包括Base URLhttps://api.vectorengine.cnOpenAI 兼容接口前缀https://api.vectorengine.cn/v1Chat Completionshttps://api.vectorengine.cn/v1/chat/completions下面的示例只展示通用请求结构模型 ID 需要替换为实际环境中确认的值curlhttps://api.vectorengine.cn/v1/chat/completions\-HAuthorization: Bearer${VECTORENGINE_API_KEY}\-HContent-Type: application/json\-d{ model: MODEL_ID_FROM_CURRENT_CONSOLE, messages: [ { role: system, content: 只依据提供的项目证据回答证据不足时明确说明待确认。 }, { role: user, content: 请把这份评审记录整理成已决定、待验证和下一步。 } ] }这个示例不意味着截图中的全部模型一定通过该路径提供也不代表具体速率、上下文长度、工具调用或流式能力。兼容接口降低的是调用结构迁移成本不能替代逐项测试。API Key 不应写在浏览器前端、移动端安装包、公开代码仓库或文章截图中。通用做法是从受控服务端调用通过环境变量或密钥管理系统注入并让日志只记录请求 ID、任务标签、配置版本、状态码和脱敏错误摘要。服务端路由还要有升级机制。日常任务如果连续无法满足约束可以升级到推理链路推理任务发现目标本身不明确可以返回探索链路任何链路遇到资料不足都应进入人工确认而不是自动增加生成次数。自动化的重点不是让模型无限尝试而是让失败落到正确队列。十一、不要用“感觉不错”评估模型团队一个回答读起来顺畅并不代表整个工作流有效。虚拟团队需要像真实项目一样建立指标而且不同岗位不能共用一个模糊分数。评估 Luna 时我关注的是候选覆盖度、方向差异、有效新意和事实越界率。它是否提出了原团队没想到的方向不同方案是不是只换了标题创意是否能够被现有材料支撑有没有把假设写成产品能力评估 Terra 时我关注约束保持、证据引用、反例发现和停止能力。它能否在长任务中记住硬性限制结论是否能追溯到输入能否发现方案在极端条件下失败证据不足时是否愿意说不知道评估 Sol 时我关注信息保真、格式合规、处理效率和升级准确性。摘要有没有漏掉决定表格字段是否完整改写有没有改变原意遇到复杂问题时它是否知道应该交给 Terra而不是继续生成看似完整的答案评估 RAG 时则需要把检索与生成分开。先看期望证据是否进入召回结果再看模型是否正确使用证据。没有召回时问题可能在切分、Embedding、过滤条件或查询表达已经召回却回答错误问题才更可能出在证据整合和生成。测试集必须包含失败案例、相似版本、冲突文档、无答案问题和权限边界。如果只用十个最容易成功的问题做演示任何系统都会看起来聪明。真正决定能否上线的是它遇到不完整、过时和互相矛盾的信息时如何表现。十二、三个最容易被忽略的管理风险第一个风险是自动化放大错误。一份错误事实被 Luna 用来创作被 Terra 当作约束被 Sol 写进文档再进入向量库后可能在多个流程中反复出现。解决方法不是要求模型永不出错而是让事实节点拥有来源、版本和负责人未经确认的内容不得自动进入长期知识库。第二个风险是模型之间形成“共识幻觉”。后一个模型看到前一个模型的完整分析后容易沿用其框架最终三种模型给出一致结论看起来像交叉验证实际只是重复同一假设。关键评审应给反方模型独立材料只提供结论和证据不提供全部思考路径。第三个风险是责任消失。团队可能说“这是 AI 给出的建议”却没人对采用建议负责。虚拟团队可以生成、比较和审查但产品范围、安全策略、商业承诺和上线决定必须由明确的人确认。每个决定节点都要记录负责人而不是只记录使用了哪个模型。此外还要防止把模型定位误读成固定能力排名。某项真实任务是否适合 Luna、Terra 或 Sol最终仍要通过样本测试。页面定位帮助我们建立初始路由但不能替代自己的评估数据。十三、内容创作者如何复制这套虚拟团队虽然前面的案例是知识助手但这套方法迁移到内容创作几乎不需要改动。选题阶段把读者问题、产品事实、竞品常见表达和禁用承诺放进画布让 Luna 提出多个不重复角度。不要直接要八千字成稿先选择真正能持续展开的主线。论证阶段把选中的提纲交给 Terra要求检查每个章节回答什么问题、使用什么证据、可能遭遇什么反对意见。凡是涉及价格、速度、排名、客户数量或绝对承诺的表达都必须有当前可追溯资料否则删除或改为待确认。写作阶段让 Sol 按确定结构扩写统一术语、段落长度和 Markdown 格式。它可以把同一事实改写成开发者、产品经理和普通用户能理解的版本但不能新增事实。审校阶段再让 Terra 只做反方检查标题是否夸大案例是否真的支持结论代码是否能运行API Key 是否泄露界面名称是否被误当成接口模型 ID。最后由 Sol 根据明确修改单整理发布稿。发布后把评论区真实问题、读者误解和高频搜索意图加入知识库。下一篇文章不再从空白页开始而是从已经验证的读者问题出发。时间久了这支虚拟团队会拥有自己的选题记忆、事实白名单和失败案例集。十四、程序员如何复制这套虚拟团队开发任务同样可以拆成探索、判断和执行。遇到新需求时让 Luna 探索不同实现路径、用户操作方式和可能被忽略的边界场景。它的输出只是候选不直接进入代码。设计评审时让 Terra 比较数据流、状态变化、失败恢复、安全边界和维护成本。要求每个结论关联具体约束对未知依赖生成验证任务。复杂故障也先由 Terra 建立假设树再设计一次只改变一个变量的探针。任务明确以后让 Sol 完成小范围代码模板、测试数据、注释、接口字段整理、变更说明和发布清单。涉及核心算法、鉴权、支付、数据迁移和并发状态时必须回到 Terra 或人工评审不把日常执行模型当作自动合并机器人。代码仓库中的文档、架构决定和故障复盘可以进入受控知识库。提问时先检索当前版本材料再让模型回答。代码本身是否适合进入外部服务、是否包含敏感信息需要团队单独评估不能因为 RAG 方便就默认全部上传。十五、我最终得到的不是三种模型而是一套工作操作系统经过完整项目测试以后我对 GPT 5.6 Luna、Terra、Sol 的兴趣已经不只是“多了三个模型”。真正有吸引力的是它们提供了三种清楚的工作节奏。Luna 允许项目在早期不急着正确先找到值得研究的问题Terra 让团队在决定前不急着顺滑先把事实、假设和风险分开Sol 让已经明确的事情不再占用大量脑力快速变成文档、清单和行动。多模型协作让三个角色形成接力无限画布让项目状态不再埋在聊天历史里角色对话让不同评价标准进入同一次评审API 则让这套流程可以嵌入现有业务。再加上向量检索和 RAG项目还能够拥有跨对话的长期记忆。这种组合更像一套个人或小团队的 AI 工作操作系统。输入不是一句孤立问题而是带着来源、版本和权限的任务输出也不是一段看完即丢的文字而是候选方案、决策依据、执行交付和可检索经验。结语AI真正替你省下的应该是组织成本很多人衡量 AI 时只计算生成一篇文章或一段代码节省了多少分钟。但在真实项目里更昂贵的是组织成本需求没有说清导致返工决定没有记录导致重复讨论证据没有版本导致使用过期方案失败经验没有沉淀导致下一位同事重新踩坑。GPT 5.6 Luna、Terra、Sol 的三模型定位为解决这些问题提供了一套很容易理解的入口。Luna 负责寻找可能性Terra 负责验证可行性Sol 负责推动执行。它们不是彼此竞争的三个答案而是位于同一条工作链路上的三个岗位。如果你正在做内容项目、软件产品、内部知识库或任何需要多人角色协作的复杂任务不妨先选一个小项目进行实验建立事实画布让 Luna 发散让 Terra 评审让 Sol 交付再把有效经验沉淀到可检索的知识层。不要一开始追求全自动先确认每次交接都比上一阶段更清楚。想了解产品中的 GPT 5.6 Luna、Terra、Sol、多模型协作与相关入口可以查看https://178.nz/dn当模型开始拥有明确岗位AI 才真正从聊天工具变成生产系统。一个人并不会因为同时打开三个窗口就自动变成一支团队但当探索、判断、执行和记忆形成稳定闭环时一个人确实可以用更小的组织规模完成过去需要多人反复协调的工作。这才是这次三模型更新最值得体验的地方。