大家好，我是 AI 超元域。
\n\n这段时间，我在 Claude 官方桌面版中体验了内测中的 Fable 5.5，做了不少动画项目。这篇文章选出最新一期视频里的 8 个代表性案例：有上传图片制作宣传短片，也有只输入提示词完成艺术史、生活记录和地质年代动画的尝试。
\n\n这次我最关注的是交付结果：能不能拿到可播放的文件，能不能补齐素材，以及画面运动、音效和结尾构图能否服务于同一个目标。下面按视频顺序展开，大家可以直接跳到对应片段查看效果。
\n\n本文根据 10 月 21 日的公开视频与讲解整理，记录的是内测体验，并非统一 benchmark。文中的 Fable 5.5 指本次测试环境中的模型名称，不将拍摄时的发布预期视为已经确认的官方公告。
\n\n如果嵌入播放器无法加载，可以前往 YouTube 观看完整视频。
\n\n| 项目 | \n本次可确认的信息 | \n
|---|---|
| 测试环境 | \nClaude 官方桌面版 | \n
| 输入方式 | \n图片加文字要求，或仅提供文字提示词 | \n
| 输出交付 | \n视频中展示了可播放的 MP4 文件 | \n
| 声音 | \n宣传动画、弹球案例的讲解明确包含合成音效 | \n
| 公开规格 | \nFable 5.5 的正式发布信息、模型参数及官方输出规格未获确证 | \n
| 未统一记录 | \n生成耗时、费用、失败率、重试次数及输出分辨率、帧率 | \n
这组案例适合观察动画制作能力，但不能据此计算每分钟视频成本，或推导模型的原生视频、音频架构。桌面环境交付了视频，具体使用什么工具链完成，是另一个问题。
\n\n第一个案例是宣传动画复刻。我上传了两张 Dots 图片、OpenAI 的 logo，以及一张用 AI 生成的毛茸茸球体图片，再输入完整提示词，让 Fable 5.5 根据这些素材制作动画。
\n\n它交付的是可以直接播放的 MP4。视频讲解中也提到，成片里的音效由 Fable 5.5 完成合成。
\n\n这个案例值得关注的地方，是多个素材被放进了同一个短片任务里。图片、标识和声音需要共同完成宣传表达，这比让一张图里的局部动起来更接近实际内容制作。对已有品牌素材的创作者来说，这是一条值得尝试的输入路径。
\n\n不过，这次没有公布声音的生成方式、独立音轨结构或后期编辑流程，因此先把结论落在可播放成片上，不延伸到未展示的技术细节。
\n\n第二个案例展示艺术发展史。我没有提供图像素材，直接通过文字描述，让它制作不同年代采用不同画风的动画，最后同样得到 MP4 文件。
\n\n在视频里，我特别提到了梵高风格的段落，以及猫的光影、地板反光这些细节。它的看点在于，同一个主题可以通过不同视觉语言展开，不必先由用户逐张准备好所有素材。
\n\n对于风格探索，这种方式很有吸引力：先把主题与画风变化表达清楚，再检查各段结果是否符合预期。但画面有相应风格，不代表艺术史分期和流派归类已经准确，这部分仍需单独核对。
\n\n第三个动画围绕从早到晚的一天展开，也只使用了提示词，没有上传任何图像资源。
\n\n这个案例里，我印象比较深的是手表拆解的动效。另一个值得注意的地方，是原本需要配图的部分没有因为缺少上传素材而停下来：成片中补出了建筑场景和跑步照片。
\n\n这对制作初稿很有帮助。一个内容想法还没有配齐图片时，可以先观察整体表达是否成立，再决定哪些画面需要换成自己的真实素材。
\n\n这里能确认的是素材补全的结果，不能仅凭成片判断这些图片来自生成、检索还是其他制作路径。它们也不应被当成用户本人的真实生活记录。
\n\n这一段的提示词非常短，要求制作一个 15 秒的弹球动画。这里的 15 秒是任务要求，并非本文独立测量的输出时长。
\n\n我最喜欢它的收尾：小球最终变成了“5.5”中间的小数点。前面的运动有了明确落点，动画主体也成为文字的一部分。视频讲解同时说明，这一段的音效也是由 Fable 5.5 合成的。
\n\n这个设计给我的启发是，短动画未必需要塞入很多场景。只要动作和最终信息之间有联系，一个小球也能完成清楚的视觉表达。评估这类作品时，结尾是否成立，往往比中间堆了多少特效更值得看。
\n\n第五个案例复刻了一段文字动画。视频里重点展示了高亮文字出现时的效果，以及背景类似木质桌面的纹理。
\n\n它没有地质年代那样丰富的场景，却适合观察局部完成度：文字动效是否突出重点，背景材质是否给画面提供了可信的质感。对教程标题、产品说明和信息展示来说，这些小细节同样影响成片观感。
\n\n本期没有完整列出这个案例的提示词，也没有核实输出分辨率与帧率，因此这里不附上所谓的“原版复现参数”。
\n\n这一段我提供了一张蝴蝶图片，要求蝴蝶产生动态效果，并在结尾出现 Claude Fable 5.5 字样与 logo。
\n\n视频里的过程是：第一只蝴蝶飞入，其他蝴蝶陆续进入，最后重新组成输入图片中的图案，再出现文字和标识。蝴蝶保留了原图的柔糊感，没有被强行转换成写实风格。
\n\n我在讲解中认为，最后一帧的蝴蝶构图与输入图保持了一致。这里说的是视觉观感，没有做像素级或几何误差测量。
\n\n这个案例比单纯要求“蝴蝶飞起来”多了一个重要约束：结束时回到哪里。对标识演绎和片尾动画来说，保留画风、组织入场动作、落到指定构图，是可以分开检查的三个目标。
\n\n这是本期展开最充分的案例。我只输入完整提示词，没有上传图片等素材，要求制作从埃迪卡拉纪到第四纪的地质年代变迁动画。
\n\n演示包含海底生命、陆地环境、恐龙、火山、撞击、哺乳动物和冰河时期等场景。对我来说，值得注意的是环境之间的差异：石炭纪段落的巨型植物与雾气、二叠纪段落的干旱感，以及第四纪段落的冰川，都承担了区分时期的作用。
\n\n动态细节也参与了表达。奔跑时的画面震动、小行星撞击后的爆炸和烟尘，让场景变化更有力度。这些效果说明，较长主题可以通过环境、动作和事件一起推进。
\n\n我也用同样的提示词测试了 Claude Opus 5.5 和 GPT-6 Astra，个人更喜欢这次 Fable 5.5 的结果。但这个比较只针对该案例，没有统一预算、多轮重复或盲测，不能扩展成所有视频任务的模型排名。
\n\n还有一点必须单独强调：科普动画需要事实审校。 生物名称、生活习性、出现年代和演化关系，都不能因为画面有说服力就直接采信。这个案例展示了长主题的视觉组织能力，离可直接用于教学的成品，还需要科学内容审核。
\n\n最后一个案例把方向转向大模型推理相关概念。演示从输入一个问题并按下 Enter 开始，再通过动画展开《一个 Token 的旅程》。
\n\n我选择展示这个案例，是因为动画还能帮助观众进入比较抽象的技术话题。相比一次给出大量术语，让过程沿着一个明确入口逐步展开，更容易形成整体印象。
\n\n不过，这类内容应当作为解释性可视化来理解，不能视为模型真实内部状态或实际思维轨迹的逐帧记录。教学表达是否直观、技术描述是否准确，仍然是两项需要分别检查的事情。
\n\n这次体验让我更看重三个方向：
\n\n如果大家想尝试类似任务，可以先明确输入素材、主要动作和结尾目标，再逐项检查结果。需要用于正式发布的内容，还要补上素材授权与事实核验；涉及生产效率的判断，则需要另外记录耗时、成本和修改过程。
\n\n以上就是本期 8 个动画案例的整理。大家可以结合原视频，重点看看自己更关心的是画风、动态细节、构图控制，还是复杂主题的表达。欢迎交流你最想尝试的动画方向。
\n", "date_published": "2026-10-23T22:00:00+08:00", "authors": [{"name": "AI超元域"}], "tags": ["Claude","Fable5.5","AI视频","动画"] }, { "id": "https://www.aivi.fyi/llms/minimax-m31-flash-long-task-review", "url": "https://www.aivi.fyi/llms/minimax-m31-flash-long-task-review", "title": "MiniMax M3.1 Flash 长程编程实测：音乐播放器、极光号飞船与圣家堂", "summary": "在 OpenCode 中完成音乐播放器、极光号飞船与圣家堂，记录长任务耗时和运行体验。基础功能可用，但复杂三维场景发热、建筑还原与动画细节仍需改进。", "content_html": "大家好，我是 AI 超元域。
\n\nMiniMax M3.1 Flash 发布之后，我把它接入 OpenCode，做了三个比较耗时的开发任务：macOS 原生音乐播放器、科幻小说《极光》中的极光号飞船，以及巴塞罗那圣家堂。三个任务分别记录了 2 小时 40 分钟、3 小时 32 分钟和 5 小时 51 分钟的开发耗时。
\n\n这次我想看的，是它能把实际项目做到什么程度：功能能否运行，复杂场景的细节是否到位，运行时会不会出现明显的性能问题。另外，我也在官方网页版与 Hermes 中做了几组房屋和动画测试。
\n\n本文整理自 2026 年 10 月 20 日发布的本期视频讲解与公开章节。耗时、用量和运行感受沿用当时的记录；这些案例没有统一预算、多轮重复或硬件性能采样，不作为严格的模型排名。
\n\n如果嵌入播放器无法加载，可以前往 YouTube 观看完整视频。下文的跳转时间采用原视频公开章节。
\n\n| 环境 | \n本期任务 | \n主要观察点 | \n
|---|---|---|
| MiniMax 官方网页版 | \n平面图生成双层 3D 房屋、艺术发展史动画 | \n空间组织、交互与画面细节 | \n
| OpenCode | \n原生音乐播放器、极光号飞船、圣家堂 | \n长程开发、功能完成度与运行表现 | \n
| Hermes | \n黑洞骑行动画、从早到晚的动画 | \n动作细节、主题表达与场景变化 | \n
MiniMax 的官方发布文章标注的发布日期是 2026 年 10 月 19 日。官方报告 M3.1 Flash 在 DeepSWE v1.1 上取得 73.7%，并公布了每百万 Token 的美元价格：普通输入 0.15 美元、输出 0.60 美元、缓存输入 0.015 美元。这里引用的是截至 10 月 24 日核对到的官方发布信息，不是我在这期视频里测出的分数或实际账单。
\n\n官方还给出了较高的输出速度数据。但模型每秒输出多少 Token，与一个项目需要多少小时完成，是不同层面的指标。项目耗时会受到任务复杂度、工具调用和开发过程影响，下面仍以本次记录为准。
\n\n第一个测试在 MiniMax 官方网页版完成。我提供了一张室内平面图，要求根据图纸构建真实、可自由探索的 3D 室内空间，使用 Three.js 或更合适的 Web3D 技术栈，并支持第一人称进入房间。
\n\n它完成的空间包含客厅、卧室、餐厅、厨房和书房。客厅中能看到不同颜色的沙发、茶几、电视与电视柜、绿植；卧室有床和衣柜，餐厅放置了桌椅，厨房也有对应的地板和设施设计。
\n\n交互部分不只是转动一个模型。我可以进入第二层，也可以切换到俯视视角，再点击指定房间进入；右上角还能切回第一层的俯视图。对一张平面图输入来说，空间和交互的组织效果是本次比较满意的地方。
\n\n不过，探索了两三分钟之后，我的电脑开始发烫，风扇转得明显。这也是这期几个复杂 3D 案例反复出现的问题。画面能跑起来之后，还需要继续检查运行负担。 这里记录的是当时的体感与风扇现象，没有 CPU、GPU、帧率或温度曲线，不能据此确定具体瓶颈，也不能推断所有设备都会出现相同情况。
\n\n我还在官方网页版测试了艺术发展史动画。整体效果有可取之处，尤其是后方的壁画，以及窗外景色带来的真实感。
\n\n但局部细节并不稳定。画面中的猫不太像猫，人物喝水时的胳膊也不够协调，有些地方看起来像是胳膊与身体分离，或动作角度不对。
\n\n当时我的评价是，它基本遵循了提示词，画面中也有不错的部分，但需要逐个检查具体对象和动作。对于这种内容，整体氛围容易先吸引注意，真正审片时还要回到角色形态、肢体连接和运动是否合理。
\n\n本期展示的是环境中完成的动画作品，没有完整披露生成和渲染工具链。不能因为看到了动画，就把它解释为模型原生输出视频。MiniMax 当前官方说明区分了文本输出与结合代码、工具完成的图像和视频处理。
\n\n接下来进入 OpenCode。第一个任务是开发一款 Apple Music 风格的 macOS 原生音乐播放器，记录的开发耗时为 2 小时 40 分钟。
\n\n运行之后，我导入了几首音乐，检查了播放和音量调节，也切换播放了其他曲目。演示中还展示了这些界面与功能：
\n\n这一项和几个 3D 场景的运行感受不同：使用播放器时，我没有遇到明显发烫的情况。至少在本次展示的操作范围内，功能与运行表现都比较顺利。
\n\n我不太满意的是开发耗时，接近三个小时。当时我认为，这个速度不如之前体验的 DeepSeek V4.1 Flash。不过，这只是我在这些项目中的体验比较，不能直接转成统一条件下的速度结论。视频也没有覆盖全部音频格式、超大曲库、异常文件或长期运行稳定性，因此还不能把这款播放器当成已经完成全面验收的产品。
\n\n第二个 OpenCode 任务，要求先研究科幻小说《极光》中的极光号宇宙飞船，再用前端技术复刻。这道题需要理解飞船构造，并把它转成可以交互探索的场景，本次记录的开发耗时为 3 小时 32 分钟。
\n\n进入作品后能听到类似飞船引擎的声音，右上角可以调小音量。放大后可以查看中心轴、载人舱和背景星空，也能通过导航进入不同区域。
\n\n我在演示里切换到计算核心和居住区。居住区有亮着灯的建筑、绿色草地和上方的穹顶，还能用方向键继续探索。除了内部区域，也可以切换整体、主轴和推进装置等视角。
\n\n这些内容让飞船不只是一个远处的外形展示。不过，进入内部探索后，我的电脑又出现了发烫、风扇明显加速的情况。前端场景的性能仍然需要进一步优化。
\n\n这道题此前也用于测试过其他模型。在本次讲解中，我认为上一期 DeepSeek V4.1 Flash 的实现效果更好一些。这是对具体作品的观感评价，没有统一评分标准，也没有在本文中新增一轮同条件对照测试。
\n\n第三个 OpenCode 任务是用前端技术复刻巴塞罗那圣家堂。它的外部与内部构造都比较复杂，本次记录的开发耗时达到 5 小时 51 分钟。
\n\n在浏览器中运行后，我把画质选择为高，先看远处的整体效果，再切换不同角度查看细节。与实拍照片相比，作品没有完整还原建筑的外部结构，这一点需要保留下来，不能只展示漂亮的画面。
\n\n进入内部之后，彩色玻璃和光影效果是比较好的部分。移动视角时，可以看到光影发生变化，空间有一定的表现力。
\n\n但运行负担也很明显：电脑再次发烫，风扇快速转动。最终我的评价是，这个复杂题目对 M3.1 Flash 确实有挑战，整体还原有可取之处，但建筑外观的准确性和前端性能都还有改进空间。
\n\n这一项也提醒我，建筑复刻至少要分开检查两件事：是否形成有观感的空间，以及是否忠实于参考建筑。内部光影不错，不能抵消外部结构的偏差；能够进入内部，也不代表几何比例和建筑细节已经准确。
\n\n除了 OpenCode，我还在 Hermes 中调用 M3.1 Flash 完成动画任务。
\n\n第一个要求是让鹈鹕、渡渡鸟和几维鸟在黑洞吸积盘上骑自行车。我比较满意的是鸟骑车时的动作细节，以及吸积盘也被呈现出来，场景整体有一定完成度。这是一组创意动画要求，不应当作黑洞物理过程的科学模拟。
\n\n另一个动画围绕从早晨到晚上展开。视频展示了 8:30 骑自行车、中午的画面，以及后来变成手表的特效。这里能确认的是演示中的场景和变化，没有统一记录这两项动画各自的生成时长、输出规格或重试次数，所以不额外补充效率结论。
\n\n三个 OpenCode 项目的记录耗时相加是 12 小时 03 分钟。这是三项任务的耗时合计，不代表一次连续运行的总墙钟时间，也不能解释为模型在这段时间内始终只进行推理。
\n\n本期讲解记录的后台用量约为 8.95 亿 Token，缓存命中率约为 97.2%。视频同时说明，官方网页版生成可探索 3D 房间的任务没有消耗我的 API Token；不能把这个总量简单平均给三个 OpenCode 项目，因为本期还有其他任务。
\n\n这些数字按当时后台读数与图表估算口径理解，没有在本文中重新完成逐项目、逐模型的账单核算。它们适合说明本轮测试的使用规模，但不等于三个项目分别消耗多少，也不能直接换算成实际支付金额。
\n\n官方价格将普通输入、缓存输入和输出分别计费。缺少这三类 Token 的明确拆分时，只拿总 Token 数乘某个单价，或者把 97.2% 直接套到全部 Token 上，都不足以得出准确费用。
\n\n我在视频中还提到，之前 DeepSeek V4.1 Flash 那轮测试的用量达到 30 多亿 Token，但那一轮测试题更多。这一回顾数字与前一期记录的 6.19 亿不同，现有材料不足以确认两者统计范围，本文不将它们直接合并比较。任务数量与内容不同，所以不能仅凭总量说哪款模型更省。比较单个任务成本，还需要相同输入、相近验收标准和更完整的过程记录。
\n\n这次 M3.1 Flash 在多个环境里交付了可以运行或展示的结果。音乐播放器的基础操作比较顺利，复杂 3D 场景也完成了空间、视角和内部探索，动画中有一些不错的动作与背景细节。
\n\n不足同样具体：音乐播放器开发耗时较长；房屋、飞船和圣家堂的演示都出现了电脑发烫与风扇明显加速；圣家堂外部结构没有完整还原；艺术史动画的猫与人物胳膊仍有问题。
\n\n如果大家要用它做类似项目，我建议验收时保留三个步骤：
\n\n本期的结果说明，它能推进这些复杂任务，但不同任务的完成度并不一致。大家可以结合原视频，分别看看自己更关心的是原生应用、复杂 3D 场景，还是动画制作，再判断这些结果是否符合自己的需求。
\n\n大家好，我是 AI 超元域。
\n\n这期我在 DeepSeek Harness 中测试了 DeepSeek-V4.1-Flash-1017，连续做了 7 个项目：艺术史动画、圣家堂、海战游戏、《清明上河图》虹桥、极光号飞船、Godot 坦克游戏，以及原生 iOS 背单词应用。
\n\n先说这轮最直观的感受：它已经能把复杂需求推进到可打开、可运行的作品，飞船内部和建筑空间也有相当完整的结构。但真正上手以后，反向转弯、穿模、运行报错和平板导航失灵都出现了。评价这类编程模型，画面效果、功能正确性和运行性能需要分开看。
\n\n本文依据本期公开简介、章节和匹配的已保存校正字幕整理。未取得 YouTube 直接导出的完整字幕，因此细节与耗时按本期讲解记录，未进行独立复跑。公开视频在美西显示为 2026 年 10 月 17 日，精确发布时间换算为本站 +0800 时区是 10 月 18 日 01:04:25。官方资料补充核验于 2026 年 10 月 24 日。
\n\n如果嵌入播放器无法加载，可以前往 YouTube 观看完整视频。
\n\n本轮在 DeepSeek Harness 中选择 DeepSeek-V4.1-Flash，推理级别设为 high。多组提示词沿用了我此前测试其他模型时的任务，重点看同类需求交到这个模型手里，最终能做出什么。
\n\nDeepSeek 的 1017 官方发布说明将改进重点放在端到端项目开发，提到通过带自反馈的强化学习提升游戏与三维建模等任务的完成能力，并建议使用 DeepSeek Harness v0.2.1-rc.1 或更高版本。这里是官方的兼容建议，不能据此倒推我录制时实际使用的 Harness 版本。
\n\n官方页面也展示了 DeepSWE v1.1 的 Pass@1 与单任务成本对比，注明使用 mini-swe-v2 harness。它是厂商公布的评测，不是本次 7 项案例的结果。我的这些体验也不是统一 benchmark：没有对所有模型统一运行环境、重试次数和验收标准，不能将某一项画面更好直接写成整体能力排名。
\n\n第一个任务沿用此前艺术发展史动画的提示词。按本期讲解，等待接近 49 分钟后，Harness 交付了 MP4 文件，可以在播放器中直接打开，成片还带有背景音乐。
\n\n这项的成果很明确：交付物已经从文字或代码推进到了可播放的视频。但放到局部检查，猫只画出了前腿、没有后腿，人物比例也不够协调。整体观感可用，不等于每一帧都经得起细看。
\n\n这里记录的是模型与 Harness 工具环境共同交付的成片，不能由此推出 DeepSeek 原生具备视频或音乐生成能力，也不能补写未记录的分辨率、帧率和配乐来源。用于正式发布前，仍应逐段检查身体结构、人物比例和素材权利。
\n\n圣家堂任务耗时约 1 小时 17 分钟。成品能查看建筑外观、放大局部，也能进入内部空间切换视角探索。与真实照片对照时，我认为整体还原效果尚可，但具体细节仍有差距。
\n\n更值得注意的是运行体验：继续探索时，电脑开始发烫，风扇转了起来。这反映出该次成品存在性能方面的担忧，但视频没有提供 CPU/GPU 占用、帧时间或温度曲线，不能仅凭发热就断言是哪一段代码造成了瓶颈。
\n\n如果继续完善这类项目，下一步应补做性能采样，检查几何体数量、材质、光照和渲染循环，再决定优化方案。建筑看起来像，和能长时间流畅地逛，是两个验收目标。
\n\n这项使用此前海战游戏的提示词，开发等待约一个多小时。成品可以进入游戏，船体和海面画面有一定完成度，也可以开炮。
\n\n真正操作时，问题非常具体：按右转，船往左；刷新以后再按左方向键，又往右转。船体还出现类似倾覆的姿态，鼠标也无法拖动切换观察角度。运行过程中再次出现风扇高速转动和发热。
\n\n因此，这项不能因为“有画面、能开炮”就算全部通过。输入方向、船体运动、摄像机控制和射击反馈，都要逐项验收。截图无法发现这些问题，亲手按一次方向键才会暴露。
\n\n《清明上河图》虹桥部分耗时约两小时。浏览器可以加载场景，用户能拖动视角，观察桥的结构，也能沿河道探索，观看船只过桥。
\n\n这项的短板是几何与遮挡关系。讲解中指出，船上能够直接看到水面，多艘船都有类似的穿模现象；从下方观察，也能发现不合理的交叠。运行不到三分钟，电脑又开始发烫。
\n\n场景搭建能力值得肯定，但真实的三维体验还要求物体之间关系成立。后续验收应同时检查桥上、桥下、船内以及运动过程中的视角，而不能只保留一个最好看的镜头。至于具体是几何交叉、材质还是渲染设置导致，需要检查项目后才能确认。
\n\n这次沿用极光号飞船任务，等待约 1 小时 21 分钟后完成。外部可以缩放观察星空背景、引擎尾焰、燃料罐和头部结构，还能进入载人舱，查看房屋、植物、穹顶以及远处类似玻璃的视觉效果。
\n\n我在本期中特别肯定了载人舱的连接方式：不同舱段连接起来组成轮状结构，而不是各自独立。这是一个比“细节多”更具体的优点，说明这次成品抓住了任务中重要的结构关系。
\n\n不过，对小说还原程度的评价仍属于本期体验，没有做逐项原文考证；与此前 Kimi K3 结果的比较也只是对应项目的观察，不是跨模型综合排名。进入载人舱探索时，发热和风扇噪声仍然存在，结构做得好并没有自动解决性能问题。
\n\n这次要求使用 Godot 4 创建可玩的 3D 侏罗纪坦克射击游戏。按讲解记录，约 30 分钟便完成了开发，是这组任务中等待时间相对短的一项。
\n\n进入以后可以控制坦克、转动炮塔，并尝试攻击空中的飞碟。但运行画面不流畅，瞄准也有问题，之后还出现了报错。报错原文没有完整记录在现有文字材料中，因此这里不推测异常类型或修复方法。
\n\n我认为本次效果比此前用早期 DeepSeek V4 做同样任务有所进步，但仍不能称为可交付的完整游戏。对于射击游戏，稳定帧率、可用的瞄准和持续运行不报错，都是基本要求，不能用“已经生成项目”代替。
\n\n最后一项是原生 iOS 背单词应用，开发等待约 50 分钟。首页包含今日进度、连续学习天数、词汇和每日一词等内容，并分别展示了 iPad 与 iPhone 上的效果。
\n\n在 iPad 上，单词卡片能发音、翻转、查看详情，也能选择认识或不认识。随机听力测试可以选择题数，回答后显示正确或错误，结束时显示正确率。这些功能构成了能够实际操作的学习流程。
\n\n但词书、进度和设置导航点击没有反应。切换到 iPhone 检查，对应入口却可以打开。这说明同一个应用在手机上可用，并不能证明平板适配已经完成；需要把每个设备尺寸下的导航、返回、状态切换分别验证。
\n\n此外，本期只展示了部分交互，没有验证长期学习记录持久化、离线使用、无障碍或上架要求，不能将其描述为已经完成生产验收。
\n\n本期讲解记录的开始余额为 21.44 元，开发过程中又充值 20 元，最后报告本轮总花费为 30.04 元人民币，Token 用量为 6.19 亿。公开简介也采用了这两个数字。
\n\n这两个数按创作者本次记录保留，并不代表“任何人花 30 元都能完成同样的 7 个项目”。现有材料没有完整的输入、输出、缓存命中与未命中分项账单，也没有逐项费用拆分。不能擅自把 6.19 亿改成另一个数量级，同样不能仅用总金额除以总 Token，推导通用 API 单价。
\n\nDeepSeek 官方定价页在补充核验时将缓存命中输入、未命中输入和输出分别计价，还区分高峰与非高峰时段。费用与用量的对应关系需要结合这些明细理解，实际调用前应检查当时价格。
\n\n另一个容易忽略的成本是等待和修复。艺术史动画接近 49 分钟，虹桥约两小时；即使 API 账单不高，交互错误、性能优化和设备适配仍然需要时间。本轮没有记录统一的人工修复工时，所以无法计算最终可交付项目的完整成本。
\n\n这 7 项测试最有价值的地方，是把优点和问题放在同一轮实际使用中展示。DeepSeek-V4.1-Flash-1017 能做出带配乐的动画文件、可探索的建筑和飞船，以及具有学习流程的原生应用。极光号的载人舱连接、iOS 的卡片和听力交互，都是具体可辨认的成果。
\n\n同时，海战转向反了、虹桥穿模、坦克游戏报错、iPad 导航失灵，也都是影响使用的真实问题。多项三维项目出现发热，需要继续用性能工具检查，而不能只凭肉眼判断优化是否充分。
\n\n如果要复用这组任务，我建议保留三个独立的验收清单：
\n\n模型交付了第一版之后，测试才真正开始。低成本让我们更愿意尝试复杂项目，但只有把这些问题修完，原型才能进一步成为可持续使用的作品。
\n\n大家好，我是 AI 超元域。
\n\n这期我把 Muse 用在了几种不同的视频场景里：手绘水彩动画、雨夜便利店的生活抓拍、飞碟坠海的科幻片段，还有麦田雷雨和仙侠场景。除了看画面，我也关注对白、环境音和动作能不能一起成立。后半段再把人物、服装和场景分开准备，用三张参考图尝试控制雪地人像视频。
\n\n本文整理自 2026 年 10 月 5 日发布的视频，以及与本期案例和时间顺序匹配的校正讲稿。本次未重新取得 YouTube 字幕导出，也没有对所有成片做逐帧测量；下面的体验结论保留为当时的案例观察，不当作统一评测或长期稳定性承诺。
\n\n如果播放器无法加载，可以前往 YouTube 观看完整视频。
\n\nMuse 是个人智能体产品，Muse Video 是视频生成模型。本文讨论的是我在 Muse 中调用视频生成能力的体验，并不是把智能体与视频模型当成同一个概念。
\n\nMeta 在 2026 年 7 月的官方介绍中将 Muse Video 定位为预览中的视频模型，并明确提到原生音频支持。这能支持“视频和声音一起生成”的能力描述，但不能据此断言所有账号、所有地区在任何时间都具有相同入口。
\n\n9 月的Muse 产品介绍说明了个人智能体和免费使用、付费扩展的产品定位。本文在 10 月 24 日整理时核对了上述页面；文中免费额度、生成速度和界面步骤仍以拍摄当时的实际体验为准。
\n\n01:06 的额度说明中，我记录了当时生成一段视频大约消耗免费额度的 2%–3%，并给出每周约 30 段的保守估算。
\n\n这组数字值得分开理解：
\n\n视频随后展示了注册和邀请码入口。活动奖励、重置周期和可用区域都可能调整，本文不把当时的奖励条件写成长期有效的领取教程。准备正式做项目时，先看自己账号当下显示的额度，再用一两个短片确认消耗，会比直接按历史估算安排整部短剧更稳妥。
\n\n01:51 的动画案例采用了吉卜力式手绘水彩氛围。提示词不只有风格词，还明确写出了短发女孩、白衬衫、蓝裙、赤脚提草鞋，以及水稻田埂的场景。
\n\n动作被拆成三个阶段：先沿田埂走，再停下看火车，最后让汽笛白烟在远山边散开。声音也有独立要求，包括风声、远处汽笛和稻叶摩擦，并且不要对白、不要字幕。
\n\n我在播放时注意到，女孩行走、火车靠近和蒸汽散开的主要动作都得到了呈现。这里可以借鉴的写法是：把人物、场景、动作先后和声音分层说明，让它们服务于同一个镜头。
\n\n讲稿中的 0–3 秒、3–7 秒、7–10 秒是提示词对节奏的要求，不应把这些时间段直接当作逐帧核验过的成片时间线。
\n\n02:46 的生活片段把镜头设定为第一人称，男友不入镜，只允许手或前臂偶尔出现。
\n\n故事发生在雨夜便利店门口：黑色长发、灰色卫衣的女性拿着汽水走出自动门，把瓶子贴在脸上，说“有点冰”；画面边缘的手接过她的包，她靠近半步，说“回家吧”。自动门、瓶盖和远处车声也写进了要求。
\n\n这组动作的重点是连贯性。递包、空出手、靠近镜头之间存在前后关系，镜头视角也限制了第二个人如何出现。我的当时观感是，动作、对白、微表情，以及湿地反光等细节表现不错。
\n\n这些是对片中选定样例的评价。便利店文字和人物口型没有在本文中重新做独立逐帧核验，因此不能推广成“任何中文都不会出错”或“所有对白都完全同步”。
\n\n04:03 的科幻段落展示了两个方向。
\n\n第一段是沙漠飞碟：狂风刚停，镜头从沙丘推进裂谷，探险者发现谷底飞行器，走下斜坡并拂开壳体积沙。提示词里提出了 15 秒和 16:9 的目标。讲稿记录了沙尘、发现飞碟、走近和拂沙等主要事件的呈现。
\n\n第二段要求几艘飞碟离开火星、进入大气层，再分别发生坠落。播放讲解中特别提到了进入地球大气层、飞碟落海和峡谷降落，坠海画面是我当时觉得比较震撼的部分。
\n\n第二段提示词提出了 20 秒需求，但这不等于已经证明模型原生支持单次 20 秒输出。本文没有取得原始文件元数据，也不据此推断底层是否经过延长、拼接或其他处理。读者可以把这部分当作复杂场景编排案例，不把提示词时长当成产品规格。
\n\n05:54 的麦田雷雨关注乌云、风、雷声和暴雨如何组合起来。它没有复杂的人物互动，但声音对天气变化的感受很重要。
\n\n06:18 的仙侠案例则有两种气质：一段把御剑飞行和现代生活结合，古装女子失去法力后落入纸箱，形成反转；另一段更接近常规仙侠氛围，重点是发带、云雾、风声、脚步声与配乐。
\n\n我在片中评价过纸箱文字的清晰程度，也注意了发带飘动和云雾的效果。这些都属于具体样例的观看感受。相比只写“电影感”，描述风如何影响衣物、人物如何进入场景、声音从哪里来，更容易让评估有明确对象。
\n\n07:17 的现场生成又回到了水彩动画：戴草帽的少女提着旧皮箱站在屋檐下，雨滴落下，远处火车的烟先出现，再配合轨道声和环境声音。
\n\n我在当时讲解中说，这次生成不到一分钟。这个说法仅对应该次体验，本文没有独立运行计时实验，也没有统计平均耗时或排队波动。不能把它写成固定响应时间，更不能据此计算批量生产吞吐量。
\n\n08:25 开始的人物一致性流程是本期最值得复用的部分。做法是先准备图，再生成视频，让每张参考图只承担明确的职责。
\n\n上传人物图片后，让 Muse 生成正面微侧、浅灰背景的定妆照。要求保留脸型、眼距、眉形、鼻梁、嘴唇、下颌线、肤色和发际线，不要瘦脸、不要放大眼睛，也不要改变年龄。
\n\n背景简单、光线平整的目的，是减少环境和造型对身份判断的干扰。这里提供的是本期采用的约束方式，并非保证人物永远不变脸的公式。
\n\n下一张图关注长袖红裙：裙摆到小腿，布料与剪裁要看清，采用全身正面和浅灰背景，并继续要求不要换脸、不要增加场景。
\n\n如果人物和服装在一张图里已经发生明显偏移，直接进入视频环节会让问题更难定位。先检查静态参考图，是这套流程中很实际的一步。
\n\n场景是白天的初雪公园，雪还在落，一条步行道延伸向远处树木。要求空镜、不要人物、不要游客、不要文字和水印，按 16:9 作为背景参考。
\n\n将背景单独生成后，就能单独判断天气、空间和构图是否合适，而不用同时处理人物身份问题。
\n\n09:49 的三图合成将职责写得很具体：
\n\n本期讲稿记录了最后生成一段 10 秒视频。我在观看时关注了红裙是否延续参考款式、落雪和脚印是否自然，以及脸部与鼻尖在寒冷场景中的细节。这里的“效果不错”仍然是单个样例的主观评价，没有跨镜头身份保持率或批量成功率数据。
\n\n我的主要收获是，Muse 的视频创作流程可以同时处理画面和声音，而人物视频更适合先拆分参考资料，再组合生成。对想做动画或短片的朋友，先做一个动作简单、角色明确、声音要求清晰的短镜头，比一开始塞入大量转场更容易判断效果。
\n\n三图流程展示了一条可尝试的方向，但本期没有制作并验证完整连续短剧，也没有证明多个镜头之间的人物身份始终稳定。正式项目仍要逐镜头验收，尤其检查脸、手、文字、对白和物体交接。
\n\n至于“超越某个模型”的结论，本期没有统一提示词、统一样本数量和盲评，因此本文不据此排出模型名次。大家可以直接回到视频，对自己最关心的场景做判断。
\n\n官方资料核对日期：2026 年 10 月 24 日。案例体验以视频拍摄时的账号、界面和成片为准。
\n\n", "date_published": "2026-10-05T23:02:42+08:00", "authors": [{"name": "AI超元域"}], "tags": ["Meta","Muse","MuseVideo","AI视频","人物一致性"] }, { "id": "https://www.aivi.fyi/aiagents/openai-dots-cloud-agent-review", "url": "https://www.aivi.fyi/aiagents/openai-dots-cloud-agent-review", "title": "OpenAI dots 实测：语音操作 Notion，云端并行开发 Godot 游戏与 Blender 模型", "summary": "通过语音完成 Notion 查找与笔记写回，并行交付 Godot 贪吃蛇和 Blender 巨石阵文件。区分亲手试玩、助手报告与仅完成设置的长期任务，保留验收边界。", "content_html": "大家好，我是 AI 超元域。
\n\n把任务交给一个有自己电脑的 AI，会得到怎样的结果？这期我用 OpenAI dots 做了几类具体工作：通过语音找 Notion 旧笔记、检索论文并写回笔记；在云端同时推进 Godot 贪吃蛇和 Blender 巨石阵模型；再安装并调用 Grok CLI，做一个简单的登录页 Demo。
\n\n我更关心的是任务有没有落到实际软件里，最后能不能拿到文件、自己打开验证。下面按这条线整理体验，区分助手报告的进度、实际交付物，以及我亲自检查过的部分。
\n\n本文整理自 2026 年 9 月 30 日发布的视频、公开章节和与案例匹配的校正讲稿。本次没有重新取得 YouTube 字幕导出，也没有重新运行片中的工程。它记录的是当时的产品体验，不是当前每个账号都能复现的功能保证。
\n\n如果播放器无法加载，可以前往 YouTube 观看完整视频。
\n\nOpenAI 的产品介绍将 dots 描述为由 GPT-6 Astra 驱动、可以在对话之间持续推进工作的智能体。它有自己的云端电脑，也能使用用户选择连接的工具。本文于 2026 年 10 月 24 日核对该页面，模型名和产品定位均有官方依据。
\n\n这里容易混淆的是“它有一台云端电脑”和“它已经获得我的电脑权限”。二者并不等价。云端开发、连接 Notion 和访问本地文件，是不同的工作路径，所需权限也不同。
\n\n本期主要围绕已经连接的应用和它自己的云端环境展开。视频介绍中涉及的机器配置、应用数量和入口位置，不在本文中作为长期固定规格。账号资格、地区和工作区设置，请以当前官方入门文档为准，不要把历史体验直接当成购买订阅后的功能承诺。
\n\n01:24 的创建环节中，我给助手起名后，让它根据青铜机器人的概念设计形象，再转换为带动态效果的头像。
\n\n这个步骤本身并不能证明生产力，但让长期使用的助手有一个容易辨认的入口，确实更方便。随后我问它对我的技术栈有什么了解，再把它接入 Slack，查看能怎样协助内容整理、开发和资料查找。
\n\n02:07 的演示体现的是：在当前可用上下文和已连接应用的范围内，它可以带着背景继续工作。不能因此推断它默认能读取所有历史对话、所有工作区，或不经授权访问任意文件。
\n\n第一次连接时，我建议先给一个范围小、结果可核对的任务，比如找出指定主题的几条笔记。确认读到的是正确账号和资料后，再增加写入或更复杂的工作。
\n\n02:55 开始的语音测试不是只问一个知识问题。我先让它从 Notion 查找大模型微调相关笔记，接着根据查找结果继续调整任务。
\n\n这段流程可以拆成三个环节。
\n\n我通过通话要求它查找微调笔记。助手返回了方法梳理和实操记录，并提醒其中一些资料来自 2024–2025 年，真正照着运行前要确认依赖版本。
\n\n这类提醒的价值在于，找到笔记和判断笔记是否适合今天使用，是两件事。旧文章可能仍有概念价值，但命令、依赖和模型接口不一定还能原样使用。
\n\n发现资料偏旧后，我继续让它搜索 QLoRA 相关论文，并进一步明确要求查找当年的论文。
\n\n这样做比只说“找最新论文”更清楚：需要区分首次发表时间、修订日期，以及旧方法在新任务上的应用。片中的助手也谈到了实验环境和结论适用范围。
\n\n本文重点记录语音任务如何衔接，没有独立复现所提论文的实验，也不将助手口头归纳的性能结论作为本文的技术评测结果。
\n\n之后我选定其中一个方向，要求整理成笔记、保存到 Notion 并提供页面链接。助手报告完成后，我在通话中确认看到了笔记，并给出了正面反馈。
\n\n这一步使整个流程有了可检查的终点：从口头指令出发，找到已有资料，补充研究，再生成落在工作应用里的文档。语音的价值在于可以连续补充条件，而不是把每条指令重新打成文字。
\n\n当然，写入外部应用需要正确连接和相应授权。遇到重要资料，仍应该打开页面检查内容、引用和保存位置，而不只听到“完成”就结束。
\n\n06:46 的桌面演示中，我查看了网页与桌面端的对话同步，以及输出区域中的图片和 Blender 文件。
\n\n这里我关注的是文件交付：结果有没有明确入口，能不能下载，在自己的环境里能否继续使用。对图片来说，预览通常足以做初步检查；对工程文件来说，最好还要打开源文件，而不是只看截图。
\n\n本期后面的贪吃蛇就继续做了本地试玩。截图、源代码和可运行项目对应不同程度的验证，不能混成一句“整个项目都已测试完成”。
\n\n07:20 的定时任务展示了检查项目仓库 Issues，以及定时检查 OpenAI 是否发布新文章的设置方式。
\n\n创建后，任务出现在界面中，这是本期能够支持的观察。视频没有记录连续多天执行情况，也没有统计漏报、误报或失败恢复，因此不能把它写成已经验证了长期无人值守稳定性。
\n\n如果要把类似任务真正用于日常工作，创建时应说明检查对象、运行时间、发现什么才通知，以及没有新内容时怎么处理。设置完成后，再核对一次实际运行结果，才能知道它是否按预期执行。
\n\n08:01 的插件部分展示了安装 Supabase 插件、进入授权流程，然后回到 dots 请求列出已有数据库信息。
\n\n本期看到的是它在连接后返回了相关列表。这可以说明应用连接进入了可读的工作环节，但没有覆盖数据库写入、迁移、权限修改或生产环境运维。
\n\n这样的顺序很值得保留：连接后先做小范围只读验证，确认账号和对象正确，再考虑更有影响的操作。不要把一次列出资源的结果理解为它已经有权处理所有数据。
\n\n08:37 的云端电脑展示中，我查看了浏览器、终端和开发工具。随后进入这期最直接的交付测试。
\n\n09:05 的开发环节中，我让 dots 使用 Godot 开发最简单的贪吃蛇游戏。
\n\n选择简单游戏有一个好处：规则容易理解，结果也容易检查。能否移动、吃到食物、在触碰边界后结束，比复杂游戏里大量无法立即验证的设定更适合作为初次测试。
\n\n游戏开发进行中，我又让它使用 Blender 创建英国巨石阵模型。助手提示模型正在制作，贪吃蛇任务也继续推进。
\n\n本期可以确认的是，这两个任务在同一次使用过程中并行推进并分别交付。不能据此推导任意数量任务都不会相互影响，也没有测量并行前后的资源竞争或性能收益。
\n\n视频讲解记录了它打开 Godot 项目并运行游戏窗口：贪吃蛇走出边界后结束。随后助手报告逻辑测试和窗口检查通过，开始保存工程与截图。
\n\n这里需要分清两层证据：测试通过是助手的报告，游戏窗口运行和结束是演示中的可观察行为。它们都比只有代码文本更进一步，但不能代替完整测试报告。
\n\n10:27 的试玩部分，我下载源代码后运行游戏，实际控制贪吃蛇吃到食物，并对这个简单游戏的效果给出了正面评价。它至少说明交付物可以进入我自己的验证环节，不只停留在云端的一张截图。
\n\n同一段演示里，我继续要求输出巨石阵文件，拿到了模型效果渲染图和 Blender 文件。
\n\n渲染图方便看整体造型，工程文件则便于后续打开、编辑和检查。本文没有进一步声称完成了模型拓扑、尺寸精度、物理真实性或商业生产质量验收。它是一个三维建模任务的初步交付案例。
\n\n11:06 的最后一个案例中，我让 dots 安装 Grok CLI。登录时，它给出了官方授权页面和设备授权流程，随后我让它调用这个工具开发一个简单登录页 Demo。
\n\n讲稿记录了等待后成功得到页面的过程。这个案例说明，在本期授权完成的环境中，dots 能把外部命令行工具接入开发流程。
\n\n这里的登录页是界面 Demo，不能据此推断已经实现真实用户认证、密码存储、会话管理或安全部署。视频提到其他命令行工具可以作为后续方向，但本文不把尚未在本期演示的工具逐一算作已经验证成功。
\n\n账号授权也应和普通任务区分开：只在对应服务的正规登录流程中操作，不把登录凭据写进提示词或公开文档。
\n\n这次最让我有感受的是三件事：
\n\n这些观察来自一次有限范围的体验：一个简单游戏、一个模型、一个页面 Demo，以及应用和任务设置流程。它们没有证明 dots 能独立完成所有生产级项目，也没有构成与 Muse 或其他智能体的统一对照评测。
\n\n如果你准备尝试，我更建议从一个验收条件清楚的小任务开始。提前说明要拿到什么文件、在哪里运行、怎样判断完成；拿到结果后亲自打开检查。等一个流程稳定了，再把更多任务交给它。
\n\n官方资料核对日期：2026 年 10 月 24 日。文中的具体案例、操作顺序和主观体验以拍摄当时为准。
\n\n", "date_published": "2026-09-30T19:34:43+08:00", "authors": [{"name": "AI超元域"}], "tags": ["OpenAI","dots","GPT6Astra","Godot","Blender","Notion"] }, { "id": "https://www.aivi.fyi/llms/claude-sonnet-55-development-review", "url": "https://www.aivi.fyi/llms/claude-sonnet-55-development-review", "title": "Claude Sonnet 5.5 实测：81 分钟音乐播放器、原生 App、Godot 游戏与桌面操作", "summary": "记录 Sonnet 5.5 的 81 分钟播放器、iOS 学习流程、Godot 飞行游戏和桌面下棋。核心交互可操作，但原型运行、完整对局与生产验收不能混为一谈。", "content_html": "大家好，我是 AI 超元域。
\n\n这次测试 Sonnet 5.5，我把任务从网页动画一路推进到原生应用和桌面操作：让它为频道制作短片、开发背单词 App 和音乐播放器，再用 Godot 做攻击机游戏，最后直接操控 macOS 自带的国际象棋。
\n\n最值得关注的结果，是这些作品已经有了能实际体验的功能。音乐播放器可以播放歌曲，背单词应用能完成学习与听力测试，桌面下棋也能连续走出多步。不过，一款 MVP 跑起来与正式产品通过验收，仍然是两个阶段。
\n\n本文根据本期公开简介、章节与匹配的已保存校正字幕整理。未取得 YouTube 直接导出的完整字幕，以下操作结果和耗时按本期记录说明，未独立复跑。官方资料补充核验于 2026 年 10 月 24 日。
\n\n如果播放器无法加载，可以前往 YouTube 观看完整视频。
\n\n本期在 Claude 网页版将推理级别设为 medium，在 Claude Code 中处理较复杂的开发任务时设为 xhigh；最后的桌面国际象棋测试又使用 medium。这些任务并非完全相同配置下的统一基准。
\n\nAnthropic 官方发布页给出的标准价格是每百万输入 tokens 2 美元、输出 tokens 10 美元。官方 Terminal-Bench 4.0 表格中，Sonnet 5.5 为 70.6%，Opus 5.5 为 66.4%；但官方也明确指出，Opus 5.5 在复杂、开放式、需要持续判断的工作中仍然更强。单项分数不能推导成全任务排名，token 单价也不等于完成一个项目的总成本。
\n\n所以，下面重点看我这轮具体做出了什么，不把视频中的主观比较扩写成“全面超越”或“史上最便宜”的结论。
\n\n第一个任务要求模拟超大质量黑洞吞噬恒星。播放后，能看到恒星被拉伸、物质进入吸积盘以及黑洞逐渐显现的过程。它完成了具有阶段变化的演示动画，而不是只生成一张静态示意图。
\n\n这里评价的是视觉表达和流程呈现，没有对物理方程、尺度或模拟精度做验证，不能当作科研仿真。
\n\n\n\n接下来的要求是根据我的频道制作一段 15 秒介绍视频。工具环境交付了 MP4 文件，播放时能同时体验动画和声音效果。15 秒是任务要求，本次整理没有对文件时长、分辨率和帧率重新测量。
\n\n这类成果说明编程模型能够在工具环境中组织并交付视频作品，不意味着 Sonnet 5.5 本身是原生视频生成模型。实际制作链路和每个素材的来源，也不应从最终 MP4 反向猜测。
\n\n\n\n破茧成蝶案例进一步考察连续叙事。按本期展示，毛毛虫的体型与颜色会变化，画面和音效一起呈现完整过程。我对细节和整体观感的评价较好，但这仍是动画作品的体验，不是对生物学准确性的系统审查。
\n\n这个任务在 Claude Code 中完成，提示词沿用了此前 Opus 5.5 的同类测试。启动模拟器后，我依次体验了引导页、每日目标设置和正式学习流程。
\n\n这一项有几处比“界面好看”更重要的结果：
\n\n这些步骤说明学习、练习和结果反馈之间已经衔接起来。视频里的 59 秒、36 秒是局部学习或测试界面的计时，并非模型开发耗时。正式产品还需要检查数据持久化、词库质量、无障碍和异常路径，本期没有覆盖这些完整验收项目。
\n\n我要求 Sonnet 5.5 开发一款 Apple Music 风格的音乐播放器。按当期记录，Claude Code 用了 1 小时 21 分钟完成开发。
\n\n运行后可以看到侧边栏、主页、歌单、专辑和歌手入口。实际点击歌曲可以播放，右下角可以调节音量，也能进入歌曲列表与专辑。测试音乐由 Claude Code 合成，这是当期讲解记录的素材来源，不应进一步推断成模型原生音乐生成能力。
\n\n我把它称为可用的 MVP，原因很具体：它不只是播放器外观，确实能发出声音并完成基本浏览。不过，这不能证明它已经接入 Apple Music 服务、获得音乐授权，或实现完整商业播放器的所有功能。
\n\n这一项明确采用 Godot 游戏引擎，而不是 Three.js 网页场景。任务是制作 A-10 攻击机对地打击游戏。
\n\n试玩时可以选择不同地图、加载导弹、控制飞机并发射导弹，过程中也出现被命中的反馈；随后切换另一种地形继续测试。这个案例的意义是，模型把需求落实到了游戏引擎中的交互流程。
\n\n本期没有长时间压力测试、帧率统计或跨设备比较。因此可以说这段试玩流程能够运行，不能据此补写“性能稳定”“没有 bug”或“已达到商业游戏标准”。
\n\n摩艾石像动画依次展示雕刻、竖立、绳索牵引、缓坡运输和安放头饰等过程，还允许切换角度、缩放查看细节。我关注的是这些步骤能否连贯呈现，以及空间关系是否容易理解。动画中的方案不等于已经得到考古验证的唯一历史过程。
\n\n\n\n飞船案例要求用适合的前端技术还原小说中的场景。除了外部结构、尾焰和音效，还可以进入内部舱室探索；房门会自动打开，场景中有打印零件的设备、舷窗和参数显示器。
\n\n这种从外观进入内部空间的体验，比单一模型展示更有层次。至于和小说设定是否完全一致，本次没有逐段对照原著，因此保留为我的场景体验评价。
\n\n\n\n宇宙探索应用原型展示了标签切换、天体详情和收藏等界面。这里交付的是手机应用原型，不能与前面已经在模拟器运行的原生 iOS 应用混为一谈。
\n\n最后我打开 macOS 自带的国际象棋应用，让 Claude Code 直接操作桌面界面，推理级别设为 medium。按本期记录，约 2 分 30 秒时已经走了 11 步，随后主动结束测试。
\n\n这个结果支持的是：在本次环境中，模型能够连续识别和操作桌面棋盘，操作节奏给我的感觉更快。它没有完整对局结果，不能写成赢棋，也不能据此评价棋力或通用桌面自动化成功率。
\n\n这轮 Sonnet 5.5 的表现让我印象较深：视频和动画能交付，原生应用有实际功能，Godot 游戏能试玩，桌面任务也能连续执行。尤其是背单词应用和音乐播放器，已经能通过一系列真实点击检查功能之间的联系。
\n\n如果把这些能力用于自己的项目，我会把验收拆成三个层次：先确认文件能打开、程序能运行，再逐项检查关键交互，最后补齐数据、性能与长时间使用的测试。模型完成第一版的能力值得关注，但省下来的开发时间，不应该变成省略验收的理由。
\n\n大家好，我是 AI 超元域。
\n\n这次测试 Claude Opus 5.5，我更关心代码运行之后的体验：播放器能否导入歌曲，背单词 App 能否完成学习和测试，一张平面图能否变成真正可以走进去的房屋，复杂动画能否把过程讲清楚。
\n\n这轮让我印象比较深的是作品的细节和交互完整度。约 35 分钟做出的音乐播放器具备导入与播放功能，约 63 分钟完成的原生 iOS 应用可以发音、练习和查看结果；三维房屋还支持自动开门与上下楼。但这些是本轮案例结果，不是统一条件下的模型排名。
\n\n本文依据本期公开简介、章节与匹配的已保存校正字幕整理。未取得 YouTube 直接导出的完整字幕，操作结果和耗时按本期记录说明，未独立复跑。官方资料补充核验于 2026 年 10 月 24 日。
\n\n如果播放器无法加载，可以前往 YouTube 观看完整视频。
\n\n本期在 Claude 网页版与 Claude Code 中均选择 medium 推理级别。官方基准并不全部使用相同设置，因此不应把厂商跑分直接当作这轮项目的预期结果。
\n\nAnthropic 官方发布页给出的标准价格是每百万输入 tokens 4 美元、输出 tokens 20 美元。官方表格显示 Opus 5.5 在 Terminal-Bench 4.0 为 66.4%，但其中采用 xhigh；其他多数公布结果使用 max。页面同样指出，在这一能力水平上，基准的微小差距未必可靠反映真实工作体验。
\n\n因此，本文不重复“全面超越”的宣传式判断，也不拿 API 单价推算本期未记录的总账单。下面直接看作品和操作结果。
\n\n第一个动画从虫卵开始，毛毛虫钻出、吃树叶、长大，再爬上树枝形成蛹。蝴蝶出来时翅膀尚未展开，随后逐渐舒展并开始飞行。
\n\n让我印象深的地方，是它没有只给“毛毛虫”和“蝴蝶”两张结果图，而是把中间阶段也做成可观看的过程。这里记录的是动画表现，不是对生命周期知识或模拟精度的专业验证。
\n\n我在 Claude Code 中让 Opus 5.5 开发 Apple Music 风格的原生 macOS 音乐播放器，耗时约 35 分钟。随后在 Xcode 中打开并运行项目。
\n\n实际体验里，我导入了一首之前下载的 AI 生成音乐，成功播放并调节音量。应用还提供合成测试音乐，可以创建播放列表、浏览歌曲与专辑，调出迷你播放器及列表视图。
\n\n这几项操作比只看截图更有意义：本地文件导入、音频播放和界面控制已经连起来了。它仍是仿照视觉风格开发的独立应用，不能把它说成 Apple Music 官方客户端，也不能假定已接入订阅曲库。
\n\n这个任务沿用此前测试其他模型的题目：上传室内平面图，生成可以探索的三维房屋。结果支持一层、二层俯视图，并能进入室内以第一人称移动。
\n\n本期展示了客厅、餐厅、卧室、厨房、卫生间、书房与阳台。走近房门时会自动开门，离开后会关门；沿楼梯可以上二楼，再进入不同房间。家具、绿植、地板纹理和灯光让空间更完整，阳台也有桌椅和可眺望的外部景观。
\n\n我对这轮的空间观感评价很高，但“看起来真实”不等于尺寸和结构准确。若用于装修沟通，仍需要逐项核对原始平面图的墙体、开口、尺度和动线，不能将这次演示当成施工或建筑设计依据。
\n\n按当期记录，背单词应用的开发耗时约 1 小时 3 分钟。模拟器启动后，单词卡片能够显示解释、播放单词与例句发音；详情页包含更多解释、例句和同义词，并支持笔记和收藏。
\n\n学习后可以标记掌握状态，完成时有动画与音效。快速测试中，我故意输入错误答案，界面给出了错误提示；结束后显示得分、正确率和待复习单词。练习页还包含错题本、测试记录、收藏以及进度和成就展示。
\n\n设置页支持调整每日学习数量、选择英音或美音、切换深色外观。本轮由此确认了一批实际可操作功能，但没有系统检查词库质量、数据同步、长期复习算法和异常恢复。演示流程顺畅，并不意味着所有功能都已通过生产级测试。
\n\n这一项从简单提示词开始。运行后，可以切换手枪和步枪、射击、换弹、投掷手雷，进入建筑躲避并移动到二层。敌人会攻击，玩家被击中后也有死亡反馈。
\n\n本期我提到运行时电脑没有明显发烫，这是当时的主观体感，不是温度或性能测量，不能扩写成跨设备性能结论。
\n\n\n\nGodot 案例中，玩家驾驶 A-10 攻击机对地面目标发动攻击，地面火力会还击，试玩时能发射导弹并出现被命中提示。南宋街头游戏则展示近战、不同招式和武器切换，建筑外墙有剥落墙皮和青砖等细节。
\n\n这几段证明了相关玩法片段可以运行。它们没有覆盖完整关卡通关、碰撞边界和长时间运行，因此结论仍应停留在本轮试玩范围内。
\n\n键盘产品详情页给出了多种风格，其中包含深色方案。我比较喜欢它的简洁程度和产品呈现，没有依靠大量蓝紫渐变堆出视觉效果。
\n\n宇宙探索应用提供了多种主题，可以切换标签、查看天体详情、拖动星空，还能比较不同天体的大小。这是可交互 UI 原型，不能与前面原生 iOS 项目混为一谈；页面上显示的数据也没有在本期逐项科学核验。
\n\n\n\n水墨动画从宣纸上的墨色晕染开始，逐步描绘群山、太阳、飞鸟、水面与小船，再转向荷叶、荷花、树干和梅花，最后以不同墨色交织收束。让我印象深的是渗染、勾勒和转场之间的连续感。
\n\n当期的想法是，可以在此基础上继续配音乐、配语音并录制发布。这里不能写成已经交付了完整配音成片，也不能从动画成果推断 Opus 5.5 具有原生视频模型架构。
\n\n机械计算器中，我输入 8 加 9，齿轮转动后显示 17，放大后能看到指针指向结果。另一项古希腊机械演示支持切换视角、查看背面和内部齿轮，点击部件后显示名称或解释，还展示手摇传动以及太阳、月亮相关功能。
\n\n这些结果说明模型能做出具有结构说明和交互的机械展示。单次 8 加 9 正确，并不足以证明完整运算范围无误；齿轮会转，也不等于传动比、历法计算和历史复原已经得到专业验证。
\n\n\n\n结尾还有中子星动画，但这一段保存字幕出现“Opus 5”与整期“Opus 5.5”不一致的名称。本文保留这个不确定性，不把它纳入 Opus 5.5 的确定成果清单。
\n\n这期最值得留下的，不是一个抽象排名，而是一组可核对的成果：本地歌曲能够导入并播放，单词学习可以进入测试和结果反馈，房屋可以从俯视切换到内部探索，游戏有操作和受击反馈，动画也能组织完整过程。
\n\n我的整体体验偏正面，尤其是界面、空间和动态细节。但正式使用仍然需要补齐验收：软件检查数据与异常路径，游戏检查碰撞和性能，机械与科学演示检查原理。模型交出越完整的第一版，人越应该把注意力从“有没有生成”转向“生成的东西是否正确”。
\n\n大家好，我是 AI 超元域。
\n\n这次测试 GPT-6 Astra，我在 ChatGPT 和 Codex 中都选择 medium 推理级别，把任务从原生 App 开发一路延伸到 3D 游戏、看图构建场景、浏览器自动化与桌面下棋。
\n\n这轮有几个具体结果值得关注：macOS 音乐播放器约 15 分钟完成，iOS 背单词应用约 82 分钟完成，而且开发过程中会调用模拟器做自动化测试。与此同时，水墨动画里的鱼群形态、游动方向，以及房屋中的床铺朝向，也说明作品仍有需要人工检查的细节。
\n\n本文依据本期公开简介、章节与匹配的已保存校正字幕整理。未取得 YouTube 直接导出的完整字幕，耗时和操作结果按本期记录说明，未独立复跑。官方资料补充核验于 2026 年 10 月 24 日。
\n\n如果播放器无法加载，可以前往 YouTube 观看完整视频。
\n\n本期 ChatGPT 和 Codex 均使用 medium。前半部分介绍了科学工作流、商业工作流、数学、终端、CAD 和交互推理等基准，但实际案例主要集中在开发、视觉场景和电脑操作，并没有复现这些正式评测。
\n\nOpenAI 官方发布页把电脑操作、浏览器与软件工程列为 Astra 的重点能力，也提到 Codex harness 的速度改进。由此可以看出，用户体验来自模型与工具环境的共同作用，不能把一次任务的速度全部归因于模型本身。
\n\n下面记录具体交付和不足，不把个人案例扩大成“所有任务都优于其他模型”或“已经证明 AGI”的结论。
\n\n第一个案例生成了可互动的黑洞场景。界面支持调节参数，切换自由飞行、电影与科学观测模式，还能选择不同类型的黑洞并显示结构标注。
\n\n这一项让我比较满意的是，视觉展示和操作入口结合起来了：看完一个角度，还能主动切换模式观察变化。不过，本期没有验证物理方程、参数单位或数值精度，它应当被理解为交互式视觉演示，而非已经通过校验的科学模拟器。
\n\n背单词应用在 Codex 中开发，按当期记录耗时 1 小时 22 分钟。值得注意的是，开发过程中不仅生成代码，还会打开模拟器、滚动页面、切换标签、输入单词搜索，并点击练习选项。
\n\n这些操作展示了模型能够通过界面检查一部分流程。但自动点击完成不等于测试覆盖完整，也不能仅凭操作速度就判断所有断言都正确。
\n\n\n\n随后我手动运行了应用。从引导页进入后，可以选择词汇范围并设置学习数量。学习页面支持发音、翻转卡片、查看中文解释和标记认识状态；完成后显示认识与不认识的单词。
\n\n其他实际体验过的功能包括单词查询与收藏、听力练习、正确率、错误单词详情、学习进度和成就徽章。设置页还能选择英音或美音。我故意在听力练习中选错，界面给出错误反馈，结束后也显示了对应单词。
\n\n这个案例已经有较完整的学习链路，但本期没有核验长期复习效果、词库准确性、同步能力和数据恢复，不能据此写成正式教育产品已经完成。
\n\n任务要求开发原生 macOS 音乐播放器，视觉风格参考 Apple Music，同时明确不使用 Apple 的 logo、图标、字体等受保护内容。按当期记录，Codex 用约 15 分钟完成开发。
\n\n运行后可以进入推荐专辑、播放测试音乐、打开迷你播放器、切换下一首、收藏歌曲，并查看接下来要播放的内容，也能隐藏侧边栏。
\n\n这是一个具备基本播放控制的应用成果。这里的“参考 Apple Music 风格”不意味着它已获得 Apple 授权、接入官方服务或具备完整曲库；测试音乐的播放也不能反向证明模型原生具备音乐生成能力。
\n\n这一项明确指定 Godot 4，引擎中的游戏背景设为侏罗纪：玩家驾驶坦克，场景里有恐龙、翼龙、UFO、树木和神秘物体。
\n\n首次开发约 19 分钟完成。之后我追加要求，将恐龙转圈改成随机漫步，又用了约 2 分多钟。这个修改过程很重要，它说明最终展示的版本包含一次后续调整，不能写成第一稿已经完全符合要求。
\n\n试玩时可以移动坦克、瞄准并射击恐龙，UFO 会攻击玩家，击中 UFO 后可以看到它的血量减少；击中神秘物体还会触发天空变色。这里确认的是这些玩法片段能够运行，没有进行完整性能或长时间稳定性测试。
\n\n\n\n第二款游戏没有指定技术栈。要求是制作一个 3D 动作冒险场景，主角像小狐狸，有尖耳朵、大眼睛并提着灯笼。按本期记录，开发约 20 分钟完成。
\n\n运行后可以操控角色旋转、踢飞箱子和连续跳跃，整体具有童话场景的观感。由于本期没有明确记录所选技术栈，不能因为前一个案例用了 Godot，就把这一项也归为 Godot 游戏。
\n\n我上传室内平面图，让模型构建可探索建筑。结果可以切换楼层、俯视和第一人称视角，进入餐厅、客厅、阳台、书房与卧室，看到电视、沙发、绿植和家具。
\n\n整体观感不错，但第三个卧室中，床头朝着门口的摆放让我觉得不太合理。这是具体的布局问题，也提醒我们：生成出来的空间即使漂亮，仍要核对原图、家具朝向和使用动线。
\n\n\n\n飞船案例要求用前端技术复刻参考图。结果展示了外部结构、尾焰、载人舱和天线，还能放大看细节、切换内部不同舱室。
\n\n这一项支持的是模型能从图像出发构建三维视觉体验，不代表每个结构都有工程可行性，也不意味着内部布局能由一张外观图唯一推导出来。
\n\n《山河醒》的提示词给出了七段结构：落墨、群山、江河、人间、风暴、云上与归一。实际播放中，墨滴形成群山，随后出现江河、建筑、船只、烟花、闪电与白鹤，最后各种元素收回一点墨。
\n\n山峦的层次、颜色变化，以及建筑与船只的呈现给我的印象较好。但江河里的鱼不太像真实鱼类，游动方向也不理想。这些缺陷在完整动画里很容易被一带而过，逐段检查才能发现。
\n\n这轮成果是模型与工具环境完成的动画体验，不能据此定义模型的原生视频生成架构。本期也没有记录后续修复是否完成，因此应当保留这些不足，而不是写成“经过修复已完美”。
\n\n我在浏览器中打开 Tinkercad，要求制作英国巨石阵。操作过程里，Codex 创建了 3D 设计、使用导入功能选择文件，再调整场景颜色。
\n\n之后我追问具体方法，得到的说明是：先在本地生成 STL 三维模型，再导入 Tinkercad。因此，正确的描述是“本地建模文件加浏览器导入与调整”，不能写成模型在网页里逐块拖拽石头完成了全部建模。
\n\n这个路径很实用，展示了代码生成与界面操作可以配合完成任务。保存字幕未能明确浏览器名称，所以这里只写浏览器，不擅自补成 Chrome 或其他产品。
\n\n最后，我打开 Mac 自带 Chess，明确要求不要考虑胜负，以最快速度下棋。按本期记录，完成了 20 回合，用时 5 分 12 秒。
\n\n这项测试的目标就是操作速度，而不是棋力。视频没有提供足以核验获胜的结果，因此不能写成战胜电脑；也不能将它与其他模型在不同指令和环境下的对局，直接换算成通用 Computer Use 性能排名。
\n\n这轮 Astra 的进步感，主要来自任务能够连续推进：写 App、打开模拟器检查，再到浏览器导入文件和桌面操作，多个步骤已经可以连接起来。
\n\n但具体问题也必须留下：恐龙行为需要追加修改，卧室家具朝向不合理，鱼群形态和运动需要修正。真正有用的结论是，这些工作已经能较快得到可操作的第一版，而人仍需定义验收标准、逐项检查并确认修改是否生效。
\n\n大家好，我是 AI 超元域。
\n\nClaude Fable 5.1 发布后，我把编程测试的难度继续往上提。这次从可交互的 3D 黑洞、平面图转住宅，一路做到 Unity 3D 侏罗纪生存沙盒。最有参考价值的地方，是模型能否把复杂要求组合成可运行的作品，以及长任务最后还会留下哪些问题。
\n\n本文整理自 2026 年 9 月 2 日这期视频的公开简介、章节，以及与七项案例逐一匹配的已保存校正字幕。此次未取得 YouTube 在线字幕导出，以下记录原视频中的体验，不代表重新跑过全部任务，也不是统一条件下的模型排行榜。
\n\n如果播放器无法加载，可以前往 YouTube 观看完整视频。
\n\n本期在 Claude 网页端和 Claude Code 中都使用 medium 推理级别。前六项主要是网页端生成的单页作品；最后一项则进入 Claude Code，通过 Ultracode 工作流组织多智能体开发，使用 Unity 3D 和 C#。
\n\n这些条件必须放在结果前面。网页端生成一个可以打开的文件，与 Agent 在游戏工程中持续修改、构建和运行，是不同层次的测试。最后的成果也应归于模型、工作流和工具共同组成的开发环境，不能简单说成模型一次回答就生成了一款完整商业游戏。
\n\nAnthropic 的官方发布说明确认了 Fable 5.1 这一模型名称及其面向编程、知识工作和复杂任务的定位。本文不照搬发布材料中的领先幅度，而是回到自己的案例。官方资料补充核对日期为 2026 年 10 月 24 日。
\n\n01:52，3D 黑洞这一题关注的是交互式呈现。生成的作品可以用鼠标旋转、缩放，查看吸积盘与整体形态，右侧还有参数控制。我的观感是画面很震撼，但视觉上接近电影镜头，不等于已经通过广义相对论数值计算的准确性验证。
\n\n02:58，平面图转住宅则加入了图像输入。我提供室内平面图，要求生成可自由探索的 3D 空间，涵盖布局、墙体、门窗、家具和光照。
\n\n实际演示中，可以用方向键移动、鼠标转向，进入卧室、客厅、餐厅、厨房、卫生间和储物空间，也可以沿楼梯上到二层。沙发、电视、桌椅、灶台等细节都出现在场景里。这说明作品不只是一个外观模型，而是具备室内游走体验。不过，本期没有逐一测量墙体尺寸与原图误差，因此不能据此把它当作建筑建模精度测试。
\n\n05:12 的武侠游戏以南宋临安为背景，玩家扮演白衣侠客，在古巷中活动并与黑衣刀客交战。
\n\n演示涉及攻击、切换招式、切换武器、飞行和进入建筑。场景里还有荷花池、室内人物、墙面字画，以及入夜后亮起的灯笼。这类任务比静态页面更考验系统之间的连接：人物控制、敌人、场景、时间变化需要同时工作。
\n\n本次短时间试玩可以支持“这些玩法已经出现在可运行版本中”，还不足以支持长时间稳定性、完整关卡设计或游戏平衡性的判断。
\n\n07:01 的 F-35 数字风洞能够切换高速平飞、大攻角、接近失速等情景，并展示流线、速度云图、压力云图和粒子效果。视角可以旋转，面板参数随操作变化。
\n\n这是一项前端交互与科学可视化题。视频没有展示网格收敛、边界条件校验或与真实实验的对照，所以这里的“数字风洞”应理解为演示作品，而非可用于工程决策的 CFD 求解结果。
\n\n08:36 的 SVG 动画要求几维鸟、渡渡鸟和鹈鹕在土星环上骑自行车比赛。它体现的是角色辨识度、骑行动作、星环构图和背景层次。相比只看画面是否精致，更值得观察的是多个指定对象有没有被遗漏，以及运动是否围绕同一个场景组织。
\n\n09:28 的案例要求研究石像的开采、雕刻、运输与竖立，再用前端技术复现。
\n\n生成作品按阶段推进：从岩体上开采和雕刻，到利用绳索移动石像，再到安放于底座、处理帽状构件。演示还能切换视角，观察人物动作与环境光影。
\n\n这个例子说明模型能够把长流程组织为连续动画。至于每一步是否符合考古证据和物理约束，需要另行核对文献、工程参数与假设。动画完整、观感生动，与科研结论已经得到验证，是两件需要分别验收的事。
\n\n12:25 开始的最后一项，我把此前使用 Godot 4 的沙盒游戏题改成 Unity 3D 与 C#，背景设为侏罗纪世界，并通过 Claude Code 配合 Ultracode 启动开发。
\n\n大约三小时后得到可运行版本。随后试玩中展示了恐龙、加特林射击、手雷、飞行、方块挖掘和放置，以及雨天、昼夜变化和闪电。可以创建世界、探索地形，再把这些机制串起来使用。
\n\n同时，视频保留了一个具体问题：进入水中后仍然显示雨效。因此不能把这次演示概括为“全部完美通过”。它提醒我们，生成可运行原型之后，还要继续检查场景状态、边界条件和视觉效果之间的关系。
\n\n本轮测试合计用尽了两个 Claude Max 20× 账号当时可用的额度，这是原视频记录的使用经历。它不等于本期所有任务的精确 Token 数，也不能直接推出单个案例的美元成本，或者模型 API 单价一定高于另一款模型。
\n\n没有统一的输入输出统计、缓存信息和计费口径，就不应给出看似精确的成本结论。对准备复现的朋友来说，先选一个最相关的任务、保留工程检查点，再观察自己的额度与运行时间，更有实际意义。
\n\n这次最值得关注的提升，是复杂要求最终能变成可操作的作品；最需要保留的判断，是作品能运行之后，仍然需要验收。尤其涉及科学模拟、空间精度和长时间游戏运行时，不能只凭一段漂亮演示做结论。
\n\n", "date_published": "2026-09-02T17:05:47+08:00", "authors": [{"name": "AI超元域"}], "tags": ["Claude","Fable5.1","ClaudeCode","Unity3D"] }, { "id": "https://www.aivi.fyi/aiagents/webmcp-codex-browser-review", "url": "https://www.aivi.fyi/aiagents/webmcp-codex-browser-review", "title": "WebMCP 与 Codex 浏览器实测：从论文笔记到网站工具调用", "summary": "用 Codex 侧边栏分析论文、翻译摘要并写入 Notion，再通过 WebMCP Demo 创建笔记与贺卡。区分插件连接和网站工具，说明已完成的操作及尚未验证的支持范围。", "content_html": "大家好，我是 AI 超元域。
\n\n这期我把 Codex 放进浏览器侧边栏，连续测试了论文分析、图片理解、选中文本翻译、Notion 笔记，以及多个标签页共同参与的问答。随后切换到 Codex 内置浏览器，测试网站直接提供工具的 WebMCP Demo。
\n\n这两段体验容易被混在一起。侧边栏解决的是浏览网页时怎样使用 AI；WebMCP 则进一步涉及网站怎样把自己的操作能力交给 Agent。下面分别看它们实际完成了什么。
\n\n本文回顾 2026 年 8 月 26 日的视频，依据公开视频简介、章节和与本期内容匹配的保存版校正字幕整理。该字幕不是此次直接从 YouTube 导出的逐字稿。界面与模型选项按拍摄时记录；文末官方资料于 2026 年 10 月 24 日补核，不将后来变化倒写成当时功能。
\n\n播放器无法加载时，可以在 YouTube 观看完整视频。
\n\n02:01 的安装演示从桌面应用的 Computer Use 设置进入，开启 Chrome 支持，再通过浏览器扩展图标打开侧边栏。这是拍摄时的界面路径，今天安装时应以应用当前设置和官方说明为准。
\n\n侧边栏里可以直接和 Codex 交互，也可以使用已经连接的插件。本期界面选择的是 GPT-5.6，展示了 Medium 推理级别和标准、Fast 速度选项。视频没有记录同一任务在两档速度下的完整计时，因此不能把界面的速度选项当成本期测出的性能提升。
\n\n实际使用中，最直接的好处是上下文不必来回搬运。正在读的论文、选中的摘要、需要解释的图片，都可以沿着当前问题继续讨论。
\n\n03:19开始，我打开一篇 arXiv 论文，要求分析它的核心概念、试图解决的问题和实验结果。接着又取论文中的图片继续追问。保存的讲解记录表明，它输出了较详细的文本分析。
\n\n这里能确认的是分析流程打通了，不能据此断言论文中的全部结论都被正确复核。要用于正式研究，仍需回看原文、图注与实验设置，而不能只看总结是否流畅。
\n\n04:13之后，我先选取摘要并翻译成中文，再选择 Notion 插件，让它把前面的分析整理成中文笔记。工具提示保存并验证成功后，我实际打开了 Notion，看到新建的笔记。
\n\n这个验证动作很重要：任务成功不只看对话中的“已完成”，还要检查目的地是否真的出现内容。与此同时，这次 Notion 写入属于连接插件的调用，不应该拿来证明 Notion 网站已经支持 WebMCP。
\n\n05:15的测试又加入了论文对应的 GitHub 页面。我打开新的标签页，在原来的侧边栏会话里选中该页，再让它给出项目的安装方式。
\n\n它随后输出了安装说明。本例说明可以把论文与项目页面放进同一轮上下文来分析，但视频并没有继续在干净环境里安装并运行该项目。所以这里的结果是“生成安装说明”，不是“安装验证通过”。
\n\n这一区别适用于很多浏览器任务：读取页面、归纳步骤、实际执行步骤，是三个不同的完成层级。
\n\n06:08开始切换到站点工具测试。我在 Codex 内置浏览器打开笔记 Demo，先询问当前站点有哪些可调用工具。
\n\n它列出了 10 个，包括列出或搜索文档、读取文档、在编辑器中打开文档，以及创建、重命名、更新等操作。记录里明确区分了其中的只读工具与写入工具。
\n\n随后我要求写一篇 WebMCP 使用笔记，并存到当前网站中。笔记创建后，我继续询问使用了什么工具，它返回了创建文档的工具及参数说明。接着要求为笔记加入更多 emoji，它使用更新文档工具修改了内容。这一段可以从07:14直接观看。
\n\n这里的重点是任务与站点能力之间的对应关系更清楚：创建文档对应创建工具，修改文档对应更新工具。不必每次都让 Agent 从界面位置推断应该点哪里。不过，工具是否可靠、参数是否正确、修改是否符合要求，仍需检查结果。
\n\n08:52的另一个 Demo 用来设计贺卡。我让它制作 WebMCP 宣传主题的作品。完成后再追问调用过程，返回的动作包括重置空白卡片、设置尺寸、调整背景色和强调色。
\n\n本次讲解对生成速度和视觉效果评价较好，但没有录制一套与普通点击自动化严格配对的耗时实验。因此，更稳妥的结论是：在这个 Demo 中，Agent 可以通过明确的编辑工具完成作品；“普遍快多少、准确率高多少”仍需要额外测量。
\n\n先澄清一个容易从视频标题产生的误解：WebMCP 不宜概括为 OpenAI 独创的封闭协议。补核的官方 Site tools 文档将它描述为对 WebMCP 提议标准的实现。网站工具与传统 MCP 连接也有区别，前者依附当前网页，后者可以连接独立服务。
\n\n拍摄时，本期 WebMCP 演示使用的是 Codex 内置浏览器，不是已经装好侧边栏扩展的 Chrome。不能因为扩展能处理网页，就推定该浏览器已经支持所有 WebMCP 接口。
\n\n截至补核时，官方文档仍明确存在支持范围限制，例如不支持 HTML 表单属性声明的工具，以及 iframe 内注册的工具。站点提供的名称、描述和结果也不是天然可信，调用仍要经过安全审查。以上是补核日期的文档状态，后续可能变化。
\n\n对网站开发者而言，我更看重的方向是先为少量明确动作提供工具，同时保留正常的人类界面。对用户而言，最实用的顺序是先问清楚当前页面提供什么，再完成任务，最后回到页面核对结果。
\n\n这次侧边栏体验完成了论文理解、摘要翻译、Notion 笔记和多标签页分析；WebMCP Demo 则完成了笔记创建、更新与贺卡设计。二者组合起来，让浏览器中的 AI 工作流更连贯，但并不意味着所有网站都已经拥有工具接口，也不意味着复杂任务从此无需人工验收。
\n\n大家好，我是 AI 超元域。
\n\n上一期介绍了 DeepSeek Harness 的 Web UI、模型接入和基础开发流程。这次继续往下走，重点测试三件事：用 Workflow 拆分代码审计，用 Agent Teams 组织多角色评审，以及通过 Skill 开发自己的插件。
\n\n最具体的结果是：Workflow 一轮派生了 4 个子任务，汇总 25 条原始问题；Agent Teams 的另一轮代码评审共有 9 个 Agent 参与。这些数字反映本次任务规模，不代表 25 个问题都已独立确认，也不意味着 Agent 数量越多，效率就按比例提升。
\n\n本文依据 2026 年 8 月 24 日公开视频简介、章节及与本期案例匹配的保存版校正字幕整理。未取得此次直接导出的 YouTube 字幕；下文记录拍摄时的体验，并非重新运行测试。官方仓库于 2026 年 10 月 24 日补核，当前文档不能替代历史版本说明。
\n\n播放器无法加载时，可以在 YouTube 观看完整视频。
\n\n00:33展示了手写笔记 OCR 和房屋平面图转 3D 可探索页面。保存的讲解把所用模型称为 DeepSeek V4 Flash Vision，演示包括按原有格式提取笔记，以及用前端技术制作可探索空间。
\n\n这里要区分输入理解与最终交付：平面图经过代码开发形成了一个前端项目，不应直接理解成模型原生输出了专业建筑模型。视频也没有提供尺寸精度、OCR 字符错误率或完整图纸一致性检测，因此这部分是应用展示，不是定量评测。
\n\n本期 Workflow 的用法很直接：在当时的标准模式中，选定代码仓库，让 Harness 对当前项目进行并行、只读的发布前审计。
\n\n02:30 的任务明确分成 4 个方向：模块边界与依赖方向、错误处理、测试覆盖、输入验证。要求中还指定必须使用 Workflow、禁止修改文件，每个 SubAgent 返回结构化结果。
\n\n这几项约束值得保留。任务如果只写“帮我检查代码”，最终报告很容易散落成一批重复观点。先指定检查方向与统一返回格式，主 Agent 才更容易把不同角度的结果合在一起。
\n\n执行时，我可以点进子任务，查看读取了什么文件、执行了什么命令、当前是否完成。完成的任务返回 JSON，主 Agent 再汇总。最终记录显示 4 个 SubAgent 全部成功结束，共收集 25 条原始问题，并按严重程度列出代码位置、证据要点和修复建议。
\n\n这个结果的价值在于可继续核查。原始问题还需要去重、确认影响范围与复现条件，不能直接当作已验证漏洞数量。视频没有逐条验证全部 25 项，也没有展示全部修复后的回归测试。
\n\n在05:20之后，我让 Harness 展示刚才构建的工作流代码。讲解记录中可以确认，它使用 JavaScript，包含工作流标识、阶段声明、跳过文件的约定、返回格式、项目路径参数和四个子任务的职责。
\n\n对于这种动态编排，我建议先检查三个地方：
\n\n这是根据本期流程给出的使用建议，并非额外完成的一轮测试。尤其是“只读”不能只靠一句提示词保证；在重要项目里，还应配合实际权限和最终 diff 检查。
\n\n06:55开始，视频转向 Agent Teams。与前面的独立子任务汇总相比，这次演示强调成员之间可以发送消息，围绕任务看板持续推进，最后由主审统一输出报告。
\n\n07:43，我直接用自然语言要求对当前代码库进行 code review。它没有立刻机械地凑出一组成员，而是先阅读项目结构。讲解中识别到的组成包括 iOS 应用、Chrome 扩展、Supabase 后端和脚本。
\n\n随后团队方案分成一个侦查 Agent、7 个专业评审 Agent，以及一个主审 Agent。界面中看到的“7 个成员”指并行专业评审成员；10:10 的总结所说“共 9 个 Agent”，则包含侦查和主审。这两个数字并不矛盾。
\n\n专业成员接收上下文简报并读取代码，完成后返回各自报告。最终主审给出统一文档，包含团队构成、核心结论和问题优先级。本期没有逐项展开该报告，也没有公开一套与单 Agent 同题同预算的对照，所以不能把这次体验写成严格的效率倍增证明。
\n\n结合这次演示，我会把选择依据放在任务依赖上：
\n\n无论哪一种，重要的都是最终证据能否汇总到一个可读、可验证的结果中。多一个 Agent 就可能多一份上下文、重复阅读和协调开销。本期没有记录完整成本，因此不提供未经测量的节省比例。
\n\n10:45之后，我介绍自己制作的 DeepSeek Harness Plugin Creator。本期做法是让 Agent 阅读项目说明并安装 Skill，再用自然语言描述要创建的插件。
\n\n第一个例子是定时任务插件。讲解展示了生成完成及其说明文档，但没有记录长时间运行、进程重启或错过执行时刻后的行为。因此，这个案例能证明生成流程，不足以证明长期调度的可靠性。
\n\n第二个例子是调用 Pi Agent 做 code review 的插件。我将前面平面图生成的 3D 项目交给它审查，记录中出现“Pi 审查通过”，并给出结论与验证方式。不过，单次审查通过也不能等同于项目不存在缺陷。
\n\n2026 年 10 月 24 日补核时，Skill 仓库已强调对目标 Harness 契约和版本进行核对，再生成、验证插件。现在使用时应阅读当前说明，不要把拍摄时的安装状态和后来更新后的实现混用。
\n\nDeepSeek 官方仓库将 Harness 定位为插件化的开源 Agent Harness，并提示仍处于快速迭代的 developer preview，可能发生兼容性变化。因此本文不凭记忆补写安装命令、配置键或实验功能开关。
\n\n本期最值得复用的顺序是：先做有范围的只读任务，观察执行过程，要求结构化证据，再决定是否扩大协作规模或封装插件。已经明确展示的成功结果值得记录，但没有测过的失败恢复、成本和安全边界，也应该留在结论里。
\n\n大家好，我是 AI 超元域。
\n\n这期我从零体验 DeepSeek Harness：启动 Web UI、配置模型与工作目录，查看 Agent 的执行轨迹，再用会话分支同时探索同一个 Issue 的两种处理方向。最直观的开发测试，是继续使用 DeepSeek V4 Pro 和相同提示词，重做前一期在 Claude Code 中测试过的游戏。
\n\nHarness 的插件化设计很有吸引力，但是否适合自己的工作流，还得看任务完成度、过程可见性和操作成本。这篇文章围绕本期实际跑过的流程展开，不把一轮游戏演示扩大成对所有编程助手的排名。
\n\n本文依据 2026 年 8 月 14 日公开视频简介、章节，以及与本期示例和时间线一致的保存版校正字幕整理。未取得此次直接导出的 YouTube 字幕，也未重新执行开发任务。官方仓库于 2026 年 10 月 24 日补核，当前启动方式与拍摄时界面可能存在差异。
\n\n播放器无法加载时，可以在 YouTube 观看完整视频。
\n\n01:40的演示从官方仓库开始：在终端运行启动流程，打开浏览器里的 Web UI，填入 DeepSeek API Key，设置工作路径，再发一条简单消息确认模型连通。
\n\n这里先做连通测试，比一上来就提交大型开发需求更容易定位问题。如果模型没有响应，应先检查提供商配置；如果模型能聊天却无法操作项目，再检查工作目录与权限。不要把所有失败都归因于模型能力。
\n\n补核时，官方仓库给出的 npm 启动命令如下。这是 2026 年 10 月 24 日所见的说明，不冒充视频中未完整呈现的历史命令：
\n\nnpx @deepseek-ai/dsh web\n当前 README 说明默认地址为 http://127.0.0.1:3080，并提示项目仍处于 developer preview，可能发生破坏兼容性的变更。开始前应阅读当前版本说明与安全提示，不要混用旧教程的配置片段。
API Key 应保留在对应提供商的本地配置或安全输入界面中。下面的案例只讨论操作流程，不展示任何密钥、令牌或个人公网访问地址。
\n\n02:40中，我通过 ngrok 做了远程访问演示，并在另一台 Mac mini 的浏览器中成功打开 Web UI，修改界面主题。由于时间原因，没有继续深入测试远程开发。
\n\n所以这部分的结果应限定为“远程页面打开并可交互”，不能写成已经验证了移动端长任务、网络中断恢复或长期稳定运行。
\n\n还需要补充一个安全提醒：能够访问 Web UI，可能意味着能够驱动本机 Agent 操作代码和运行命令。公网可访问并不等于安全。不要照着演示直接把没有可靠身份验证和访问控制的界面暴露出去，也不要把隧道令牌贴进普通对话或公开文章。
\n\n实际部署时，应先明确谁能访问、能操作哪些目录、怎样收回访问权限。这里不提供未经核对的公网配置命令。
\n\n03:38展示了当时界面的标准模式、代码模式、最小模式和创作者模式。讲解中的标准模式包含文件编辑、命令执行、搜索、Skill、计划、目标和子 Agent 等能力；代码模式则用于本期后续开发测试。
\n\n这些是拍摄时的模式划分，不能保证后来每个版本仍保持同名入口或相同能力组合。选择时应看当前配置实际挂载了哪些工具，并从任务必需的权限开始。
\n\n本期游戏测试采用 DeepSeek V4 Pro、high 推理级别，并给予了较宽的操作权限。这样的设置属于当时演示条件，不是对所有读者都推荐的安全默认值。尤其在包含重要资料的目录中，应先备份或使用隔离副本。
\n\n05:01的重点是轨迹界面。它用不同颜色区分内容类型，可以点开系统提示、用户输入、工具调用与结果，查看调用时间和耗时。
\n\n我可以沿着这条记录追踪：它先读了什么，接着执行了什么命令，最后得到了什么返回。这对排查失败特别实用。比如最终页面没达到预期，可以回到相关工具结果，而不是只能根据最后一段自然语言猜测发生了什么。
\n\n不过，过程可见并不自动保证过程正确。日志中出现命令调用，与命令成功完成是两回事；生成了代码，与游戏可玩也是两回事。轨迹的价值，是让这些区别有机会被检查。
\n\n在06:58，我通过界面添加 OpenRouter，填入对应配置后，在新会话中选择其提供的模型并测试响应。
\n\n这说明本期环境能够接入另一家模型提供商，但“可以连接”不等于所有模型都具有同样的工具调用可靠性、上下文能力或开发效果。切换模型后仍应重新做小任务验证。
\n\n07:38又查看了插件列表与斜杠命令。演示涉及上下文压缩、导出 Session、目标、计划和模型选择等入口。插件化让工作流更容易扩展，同时也要求认真检查插件来源与实际权限。搜索到一个插件，不代表已经安装，更不代表它完成了安全审核。
\n\n08:06，我给出一个开源项目的 Issue 链接，要求分析成因。它返回了相关代码位置与修复建议。
\n\n接着在08:40使用会话分支：新分支继续制定完善的修复方案，原会话则查找项目现有 PR 是否已经处理这个问题。
\n\n最终，两个方向都有输出：一个找到对应 PR 并给出分析，另一个形成了详细修复方案。对于实际开发，这种分支方式可以帮助比较“沿用上游已有方案”和“自行设计修改”的差别。
\n\n但本例到这里仍然是分析与方案阶段，没有演示合并 PR，也没有展示应用补丁后的完整回归测试。会话分支同样不应该被理解成代码仓库自动获得了文件隔离或冲突解决能力。
\n\n09:46，游戏开发完成后，我实际进入场景，测试人物移动、持剑动作、攻击敌人、恢复气血与飞行，也查看了商贩和店铺等环境内容。
\n\n这次讲解中，我对 Harness 版本的可操控性、动作和打击效果评价更好。比较对象是前一天使用相同模型与提示词在 Claude Code 中生成的游戏。
\n\n这个结果说明运行框架和执行流程值得单独观察，但它仍是一轮具体项目的体验。没有多次独立运行、统一预算或客观评分，就不能据此推出 Harness 在所有任务上都优于 Claude Code，更不能据此排除提示词之外的上下文和运行差异。
\n\n保存的材料没有记录这一轮明确的崩溃或控制失效，所以这里不补写不存在的失败案例。可确认的不足主要在验证覆盖：没有完整兼容性测试、长期运行测试或性能测量。
\n\n10:48，我又尝试让 Codex 通过内置浏览器打开 Harness Web UI，输入一个分析项目架构的任务。
\n\n记录显示 Codex 打开了页面，填入较完整的提示词并发送，Harness 随后开始执行。这里验证的是浏览器驱动的任务派发，不应自动等同于原生 Agent 通信协议，也不能把“已经开始执行”写成“架构分析全部完成并通过验收”。
\n\n如果把这种方式放进实际工作流，还需要考虑重复提交、任务身份、执行状态和最终结果怎样回收。本期没有完整测试这些环节，因此保留为后续探索方向。
\n\nDeepSeek Harness 给我最直接的印象，是 Web UI、执行轨迹和插件组合让开发过程更容易观察与定制。本期跑通了模型连接、会话分支、具体游戏开发，以及从另一个助手发起任务的入口。
\n\n对准备上手的读者，我建议先完成一个小而可验收的任务：确认模型和目录正确，观察工具结果，打开产物实际操作，再逐步加入更多插件与协作方式。把这些基础环节跑稳，比一开始就追求全权限、远程公开访问和多工具叠加更有价值。
\n\n大家好，我是 AI 超元域。
\n\n这期我把 DeepSeek V4 Pro 0813 接入 Claude Code，继续用动画、3D 场景、游戏和原生应用测试它的开发能力。最值得关注的结果是，整轮测试记录的 API 消耗为 5.36 元，而且几个复杂项目已经能实际操作。不过，SVG 的空间关系仍然出错，各个任务的表现也并不一致。
\n\n本文整理自 2026 年 8 月 13 日的视频与匹配本期模型、案例和时间顺序的校正讲稿。本次未重新取得 YouTube 字幕导出，也没有重新运行项目。文中的耗时、效果和费用都是当时的测试记录，不代表统一基准或今天的服务报价。
\n\n如果播放器无法加载，可以前往 YouTube 观看完整视频。
\n\nDeepSeek 的8 月 13 日官方公告确认 V4 Pro 正式版上线，并介绍了 Agent 能力、推理强度和 Responses API 支持。公告还说明，新的峰谷价格要到 8 月 16 日 16:00 UTC 才生效。因此，本期 8 月 13 日记录的费用，不能直接套用后来公布或当前显示的价格重新解释。官方资料于 2026 年 10 月 24 日整理本文时核对。
\n\n原视频标题写的是“5 元、5 个复杂项目”，简介写的是“5.36 元、6 个复杂编程项目”，而章节与讲稿实际包含七项开发测试：SVG、古戈尔齿轮、飞船、临安小游戏、Manim、Godot 和 macOS 播放器。本文按七项测试逐一整理，不把不同宣传口径强行合并成一个项目数；费用则采用结尾明确记录的 5.36 元。
\n\n01:18 的接入环节是在 Claude Code 中配置 DeepSeek API。本期实际执行工具、打开文件和运行项目的是这套编程环境，不能把它们全部理解为模型独立自带的能力。讲稿记录使用 1M 上下文配置，但没有给出一套可以复现所有结果的完整参数、提示词和调用日志。
\n\n01:53 的任务要求三种鸟骑自行车，在土星星环上比赛。模型用 Python 生成 SVG，并自动打开结果。
\n\n这一轮的优点比较具体：鹈鹕、渡渡鸟和几维鸟具有可辨识的外形，骑车动作也能看出来，背景中还出现了不同的行星。但赛道没有贴合土星，星环与主体之间的空间关系没有正确建立。
\n\n与此前 Kimi K3 的同题作品相比，我当时更认可 Kimi 的星环关系和蹬踏动作。这个案例说明，生成了完整动画文件并不等于完成了所有约束。检查这类任务时，除了“有没有动”，还要看主体之间的位置和动作关系。
\n\n03:32 的 Three.js 测试耗时约 20 分钟。相比此前 Flash 作品中彼此分离的齿轮，Pro 这次生成的齿轮在视觉上紧密啮合，并增加电机、转速控制和可旋转查看的视角。
\n\n我当时认为这一项比 Flash 明显进步，也展示了 Kimi K3 的作品作为比较。但这里验证的是画面与交互，没有逐齿核算真实机械传动。因此，文章把“啮合更像真实机构”保留为视觉观察，不把它升级成机械工程精度认证。
\n\n05:03 的飞船任务要求先搜索并阅读小说信息，再选择前端技术复现飞船，并支持进入内部探索。
\n\n这轮比较有价值的过程是：模型发现搜索结果中的飞船描述互相矛盾，继续调整关键词，尝试寻找更可靠的原文描述。约 27 分钟后，它交付了可旋转、可放大查看的外部模型，也提供了内部舱室入口。
\n\n演示中可以查看前方防护结构、载人舱、尾焰，以及带有天空、地面和草地的内部环境。我当时更认可这一版的轮状舱室排列，认为它比所展示的 Kimi K3 作品更符合小说描述。这仍然是本期作品的局部比较，没有对原著所有结构做独立逐项考证，更不能推广成模型整体排名。
\n\n08:03 的小游戏以南宋临安为背景，玩家可以飞行、挥剑，与追击的黑衣人战斗。约 26 分钟后，演示中能够击中敌人，并看到击败敌人后气血增加。
\n\n场景中还有路人、小贩和商铺招牌。我当时认为，它在玩法和街巷细节上比对照作品更完整，已达到可以操作的 MVP。这里的 MVP 指视频里这些核心动作形成了可玩的原型，不代表关卡平衡、存档、性能和长期运行都通过验收。
\n\n09:35 的测试要求显示函数表达式、绘制曲线、标注顶点和零点，并用动画展示绘制过程。
\n\n讲稿记录约四分钟完成，随后打开输出视频检查，能够看到表达式、顶点、零点和连续绘制过程。我当时认为它比此前 Flash 的结果更好。这个案例是模型编写并调用 Manim 生成动画，不是 DeepSeek 原生生成视频；本文也不补写未保留下来的具体函数、帧率或渲染设置。
\n\n10:29 的任务要求在侏罗纪场景中驾驶坦克射击，加入恐龙、UFO 和音效。约 32 分钟后，项目在 Godot 中打开并运行。
\n\n测试中能移动坦克、攻击恐龙、击落 UFO；UFO 也会反击，玩家会被消灭。场景还包括火山、树木、石头和飞行的翼龙。这些动作让原型有了基本的战斗循环。
\n\n需要保留一个跨期口径差异：本期回顾 Flash 时用了“不能运行”的说法，但 Flash 那期的直接演示记录是游戏可以运行，只是操控和需求完成度很差。因此，更准确的比较是 Pro 在本次游戏的可玩性和细节上明显改善，而不是把前一期改写成完全无法启动。
\n\n12:32 的最后一项是用 SwiftUI 开发原生 macOS 音乐播放器，视觉参考 Apple Music。
\n\n项目在 Xcode 中运行后，可以查看首页、音乐库、专辑、歌手和歌单，并操作迷你播放器与收藏。演示中的音乐可以正常播放，但我也指出合成音乐本身不好听。这里为了避免使用现成歌曲，测试使用了合成音乐；它验证的是播放器功能，不是商业音乐服务接入，也没有证明具备 Apple Music 的曲库授权或完整功能。
\n\n14:21 的费用环节记录整轮 API 消耗为 5.36 元。它说明这轮原型开发的模型调用成本很低，但不包含人工验收、开发设备、返工、部署和长期维护成本，也没有按项目公开缓存命中和输入输出 Token 明细。
\n\n我的结论是：这次 Pro 的价值主要体现在复杂任务的完成度，尤其是飞船、游戏和原生播放器。SVG 仍有明确错误，视觉满意也不等于工程正确。拿它开发自己的项目时，可以沿用这期的检查方式：先让核心流程运行，再逐项核对需求，最后单独检查错误处理、稳定性和性能，而不要只看生成速度与 API 总价。
\n", "date_published": "2026-08-13T16:37:02+08:00", "authors": [{"name": "AI超元域"}], "tags": ["DeepSeek","ClaudeCode","Godot","SwiftUI","AI编程"] }, { "id": "https://www.aivi.fyi/aiagents/prime-agent-workflow-review", "url": "https://www.aivi.fyi/aiagents/prime-agent-workflow-review", "title": "Prime Agent 实测：动态分工、四个 SubAgent 与长期任务", "summary": "记录 Prime Agent 调用外部编程工具、四个 SubAgent 审查和 REST 到 tRPC 迁移，并验证心跳任务的设置与停止。动态编排可用，长期稳定性与节省比例尚未测量。", "content_html": "大家好，我是 AI 超元域。
\n\n这期测试 Prime Agent，我最意外的经历是：原本只是让它并行分析一个项目，它却打开了电脑上的 Orca，在多个终端中启动 Codex，把任务继续分发出去。为了避免额度快速消耗，我随后要求它停止，并关闭这些终端。
\n\n这个过程很适合用来理解 Prime Agent 的特点，也提醒我们：当 Agent 能动态组织工具和其他 Agent 时，任务范围、预算和停止方式需要提前说清楚。
\n\n本文根据 2026 年 8 月 12 日的视频简介、章节和匹配到的已保存校正字幕整理。此次未取得 YouTube 在线字幕导出，没有重新执行视频中的任务。以下区分当时的演示、项目机制和后续文档核对，避免把“自我改进”写成模型权重被训练更新。
\n\n如果播放器无法加载，可以前往 YouTube 观看完整视频。
\n\n本期介绍的核心包括 Persistent IPython、RLM、Continual Harness、SubAgent、Goal 和 Heartbeat。
\n\n用更直观的方式理解：长期任务不必把所有中间材料反复塞进聊天窗口，可以在持久运行环境中保留状态，用代码访问资料、组织工具调用与子任务；重复使用的提示、技能说明、记忆和子 Agent 配置，也可以成为可调整的工作资料。
\n\n官方仓库在 2026 年 10 月 24 日核对时，仍明确说明了持久 Python 环境、子 Agent、可回顾轨迹的 refine，以及后台会话与长期目标。这是对机制的补充核对，不代表文档当前每个细节都与 8 月拍摄版本完全一致。
\n\n尤其要注意，“自我改进”在这里主要指 Harness 的补充状态和工作方式，而非在线修改模型参数。视频讲解也区分了可调整内容与不可变的基础系统提示，不宜将它概括为“Agent 可以无限制改写一切规则”。
\n\n02:58 开始展示安装与启动。之后在项目目录中打开终端界面，通过登录入口选择模型提供方。
\n\n03:33 的演示使用 ChatGPT/Codex Plus 或 Pro 订阅登录：选择对应提供方后打开浏览器，完成授权，再回到终端使用。这里记录的是当时可用的入口，不应推导为所有套餐、所有地区、未来所有版本都永久兼容。
\n\n实际使用前应确认当前版本支持的提供方、授权范围和额度规则。本文也不复制一条未来可能失效的安装命令，最新步骤以项目 README 为准。
\n\n05:11的任务是深入分析代码库。我没有在提示中要求它调用外部编程工具，但随后发现，它打开 Orca，并在多个终端内启动 Codex，分发并行分析任务。
\n\n这一幕能够证明本次环境中发生了工具编排行为，却不能证明每台电脑上都会自动复现。可用工具、已有安装、权限和任务内容都会影响结果。
\n\n我担心多个 Codex 同时运行会用尽额度，因此输入停止要求。演示中 Prime Agent 报告停止任务并关闭终端，返回 Orca 后也看到相应终端被关闭。这里既有执行过程，也有停止后的界面核对，比仅看一句“已停止”更有参考价值。
\n\n对于类似工作，建议预先明确：是否允许启动其他编程助手、最多并发多少个任务、哪些目录可以修改，以及什么时候停止。这些是从本次经历得出的使用建议，不是额外完成过的一组测试。
\n\n07:32 的测试把分工写得更清楚，分别检查后端框架、前端、测试覆盖和安全问题。
\n\n执行中可以看到动态构建的 Python 代码与子任务提示。通过 BTW 询问进度时，系统返回四个 Agent 的执行状态，并在部分报告完成后说明还有哪些工作在继续。最终输出按严重程度组织的项目审查结果。
\n\n本期展示了拆分、并行、进度查看和结果汇总这条链路。报告提到的漏洞没有在本文中逐一复现，所以这里不会把 Agent 的审查发现直接写成已经独立确认的安全漏洞。
\n\n它与 Dynamic Workflow 的相似之处，是能够围绕任务动态组织子工作。不能因为操作体验相近，就断言两个项目内部实现完全一样。
\n\n09:34测试 Goal，要求把项目从 REST API 迁移到 tRPC，并确保测试通过。演示中的代码库较简单，任务完成后给出了验收结果，界面记录的消耗约为 34K Token。
\n\n这个数字只属于当时那次任务。它不是大型迁移项目的成本预测，也不能与别的工具随意比较。原视频结尾还明确把与 Codex CLI、Claude Code 执行相同任务的对比留给后续，因此本文不宣称已经完成同题、同条件的 Token 节省评测。
\n\nGoal 的实用价值，是让目标和验收条件保持在任务中。真正使用时，仍应自己检查代码差异和测试证据，而不是只接受总结中的“已经完成”。
\n\n10:21演示设置心跳任务，每 12 小时检查仓库 Issues 并输出分析报告。界面显示下一次运行时间，随后又查看状态并停止任务，停止后显示没有激活的心跳。
\n\n因此，这一段能支持配置、状态查看和停止流程已经演示，不能支持“连续多天稳定运行”或“定时报表已经准时发送”。如果复现长期任务，应继续检查真正触发后的运行记录与输出，而不只看下一次计划时间。
\n\nPrime Agent 的吸引力在于把状态、任务分工与长期执行组合起来。对持续维护代码库、分工审查、重复性研究任务，这种形式值得尝试。
\n\n但官方 README也提醒，模型生成的 Python 和项目命令以用户权限执行，内部 worker 与 kernel 的进程隔离不等于安全沙箱。建议从可恢复的副本或干净工作区开始，对不可信代码使用外部隔离环境。
\n\n这期留给我的重点，是看清 Agent 如何组织工作、如何汇报、如何停下来。至于节省多少 Token、长任务稳定多久、相比其他工具能提高多少效率，还需要更严格的同条件测试。
\n\n", "date_published": "2026-08-12T23:32:56+08:00", "authors": [{"name": "AI超元域"}], "tags": ["PrimeAgent","RLM","Harness","MultiAgent"] }, { "id": "https://www.aivi.fyi/aiagents/qm-team-agent-review", "url": "https://www.aivi.fyi/aiagents/qm-team-agent-review", "title": "qm 团队 Agent 实测：记忆管理、共享项目与私人空间", "summary": "本地部署 qm，用两个账号检查记忆管理、共享项目中的接续问答和文件可见性。普通界面的私人空间有区分，但未进行越权安全审计，PDF 分析也未展示最终结果。", "content_html": "大家好，我是 AI 超元域。
\n\n把一个 AI 助手交给自己使用，与让整个团队共同使用，遇到的问题很不一样。多人登录后，谁能看到对话和文件？私人记忆会不会进入公共项目？工具调用和凭据应该由谁管理？这期我在本地部署 qm，重点检查这些基础协作流程。
\n\n本文整理自 2026 年 8 月 3 日的视频简介、章节和对应的已保存校正字幕。此次未取得 YouTube 在线字幕导出，文章记录当时的实测，不代表重新部署或完成了一轮安全审计。文中“隔离”首先指演示中的作用域和可见性表现，不承诺任何部署都绝对安全。
\n\n如果播放器无法加载，可以前往 YouTube 观看完整视频。
\n\n01:15 的介绍将 qm 放在团队使用场景中：大家可以共享 AI 能力，同时保留各自的私人空间。
\n\n官方仓库在 2026 年 10 月 24 日核对时，将项目描述为面向工作的多人 Agent Harness，并明确区分个人与共享作用域。记忆、文件、权限、Keychain 视图以及持久化沙箱等资源，都围绕作用域组织。
\n\n这里的 Keychain 视图不能简单理解为“每个人都能读取所有原始密钥”，共享项目也不意味着自动共享所有个人资料。部署时需要理解具体授权和配置，而不能只看界面上有没有一个“私有”标签。
\n\n本期没有进行对抗攻击、越权访问测试或基础设施审计。因此，“适合团队协作”是功能定位，“已经达到某项企业安全认证”则是本文没有验证的另一类结论。
\n\n04:08从管理员控制台开始，随后进入普通用户的 Web UI。管理界面用于查看和管理用户等内容，日常对话则在用户界面中进行。
\n\n这样的分工很重要：聊天体验只是整个系统的一部分，团队还需要身份、配置和权限的管理入口。本期后续新增第二个账号时，就回到管理员面板确认用户已出现，再进入项目完成邀请。
\n\n视频讨论了 Pi Agent、Codex、OpenCode 和 Claude Code 等接入方向；实际对话演示使用的是 Pi Agent。不能把讲解中的兼容选项写成四种后端都逐一完成过实测。当前支持方式和配置细节应以对应版本文档为准。
\n\n06:05 的记忆演示，我告诉 Agent 自己通常使用 Claude Code 写代码，再用 Codex 做 review。
\n\n运行过程显示它读取并更新记忆，随后在记忆界面中可以找到这条开发工作流。还可以查看历史记录、直接修改内容、切换视图或删除条目。
\n\n这个过程的价值在于记忆是可以检查的。用户能看到系统记下了什么，也能纠正它。对于团队工具，记忆不仅要“记得住”，还要有合适的归属和维护方式。
\n\n本期说明了记忆写入与管理界面，并没有验证所有记忆在任意版本、任何异常重启后都保持一致。长期运行和数据恢复仍需单独测试。
\n\n07:15创建名为“AI 研究”的项目，并邀请另一个账号加入。
\n\n测试先注册第二个用户，通过邮箱登录。随后在原账号的项目中添加该用户并保存。第二个账号刷新后，可以看到这个共享项目。
\n\n接着，第二个用户在项目中提问“大模型微调时如何防止过拟合”。切回原账号，可以看到这段对话，并接着要求讲解第一条内容。再次切换到第二个用户，刷新后也能看到后续问答。
\n\n这一段把团队协作最基础的闭环跑通了：同一个项目、不同账号、共享对话、接续提问。它适合团队共同研究问题，而不需要每个人把回答复制到别处再转发。
\n\n08:38继续比较私人内容和项目内容的可见性。通过普通界面切换账号时，没有看到对方的个人私有对话；加入共同项目后，则可以看到项目中的交流。
\n\n需要准确限定这个结果：它验证的是当时两个账号在应用界面中的访问表现，不代表系统管理员、数据库管理员或服务器所有者在所有层面都无法接触数据，也不等于证明不存在越权漏洞。
\n\n如果准备投入团队使用，应该为自己的配置补充验收：移出项目后是否失去访问权限，文件链接是否遵循项目权限，日志和备份有哪些人能读，以及模型服务会收到哪些内容。这些是建议检查的项目，不是本期已经跑过的测试。
\n\n10:10 的演示向共享项目上传文件，并让 Agent 分析内容。切换账号后，另一位成员可以看到相关对话，界面显示工具调用和运行过程，文件侧栏也能找到上传的文件。
\n\n当时演示中 PDF 分析尚在进行，没有立即输出结果。因此，这一段支持文件与任务过程在项目内可见，不能写成“PDF 已完整分析且结论准确”。
\n\n这是协作工具验收时容易忽略的区别：文件能共享、任务能启动、结果能产出、结果正确，分别需要证据。不要因为前两步顺利，就把后两步也一并视为通过。
\n\n11:47解释了整体流程：消息由 Web UI 或 Slack 进入核心，根据身份和来源识别作用域，再由配置的 Harness 与模型处理；需要工具时，经过相应策略与执行环境，结果返回后继续判断，最后回复并保存有关记录。
\n\n本文不会由“有记录、有审计”进一步推导出模型自动训练更新，或者所有操作都经过独立安全验证。持久化与审计能帮助追踪过程，其覆盖范围和保护效果仍依赖具体实现和部署。
\n\n想复现本期环境，可以参考我的从零安装笔记。笔记明确区分本地测试环境与生产部署，不能把本地 HTTP 配置直接暴露到公网。正式部署前还应核对最新官方项目文档，并处理身份验证、访问范围、备份、凭据和网络入口。
\n\n这期最明确的收获，是 qm 把私人工作与团队协作放进了同一个使用流程：记忆可以管理，共享项目可以连续讨论，文件和执行过程可以被成员看到。下一步真正值得投入的工作，是围绕团队自己的权限边界做验收，而不只是把一个聊天界面部署起来。
\n\n", "date_published": "2026-08-03T23:42:08+08:00", "authors": [{"name": "AI超元域"}], "tags": ["qm","YCombinator","Agent","团队协作"] }, { "id": "https://www.aivi.fyi/llms/deepseek-v4-flash-0731-coding-review", "url": "https://www.aivi.fyi/llms/deepseek-v4-flash-0731-coding-review", "title": "DeepSeek V4 Flash 0731 实测：七项编程任务、约 1.42 元成本，以及复杂游戏的短板", "summary": "约 1.42 元调用消耗测试七项任务，得到动画与可运行的 iOS 学习原型，也暴露齿轮分离、Godot 操控不足和深色主题失效。低单价不等于低验收与返工成本。", "content_html": "大家好，我是 AI 超元域。
\n\nDeepSeek V4 Flash 0731 的吸引力很直接：调用便宜，Agent 能力也值得测试。这期我把它接入 Claude Code，连续尝试飞船、骑马游戏、齿轮、SVG、Manim、Godot 和 iOS 应用。结果既有能运行的背单词 App，也有完成度明显不足的恐龙坦克游戏。
\n\n本文整理自 2026 年 7 月 31 日发布的视频及匹配本期案例的校正讲稿。本次没有重新取得 YouTube 字幕导出，也没有重跑这些项目。耗时、界面状态与使用体验均为当时的演示记录；下面会把官方发布信息、实际案例和使用建议分开。
\n\n如果播放器无法加载，可以前往 YouTube 观看完整视频。
\n\nDeepSeek 官方更新日志的 2026 年 7 月 31 日条目说明，这次更新针对 V4 Flash API，保持此前 Preview 的架构和规模，主要重新进行了后训练；当时 App、网页和 V4 Pro 并未同步升级。官方代码 Agent 基准采用了 DeepSeek Harness minimal 模式等特定设置，本期则使用 Claude Code，二者不能直接当成同一套评测。
\n\n还有一个对今天复现很重要的变化：同一日志在 9 月 10 日记录了 V4.1 Flash 上线，旧的 V4 Flash 模型名临时路由到新模型。因此，本文是 0731 版本的历史实测，不应拿相同的旧模型名调用今天的 API，再认为测到的还是当时版本。上述官方信息在 2026 年 10 月 24 日整理时核对。
\n\n01:24 的接入环节展示环境变量和模型选择。文章不提供未经重新验证的旧版配置教程，也不把模型的自我介绍当作可靠规格。视频曾询问知识截止日期，但一次问答和一道时事题不足以独立验证训练截止时间。
\n\n02:19 的第一个开发案例要求先搜索小说《极光》，再用合适的前端技术还原飞船。这不只是写一段绘图代码，还包含联网搜索、整理结构信息和实现动态场景。
\n\n约 20 分钟后，项目可以打开并用鼠标拖动查看。演示中包含尾焰、分成两部分的载人舱、前方结构和背景星空。我当时认为整体效果不错，但 Kimi K3 对照作品的光影和可辨识度更好。
\n\n这能证明本轮搜索到代码生成的链路完成了，不能据此认定小说全部细节都被正确还原，也不能把一次主观视觉比较写成通用能力排名。
\n\n04:08 的任务参考《荒野大镖客》的骑马场景，要求移动、转弯和探索。约半小时完成后，可以听到风声和马蹄声，看到落叶、云和昼夜变化，天黑后房屋也会亮灯。
\n\n但马的头和身体有分离感，造型没有很好地连接起来。与展示的 Kimi K3 版本相比，马的细节和可操控性也有差距。这个例子很能体现 Flash 的特点：它能把多个环境元素组合起来，但角色结构和输入反馈仍需要继续验收。
\n\n05:30 的古戈尔齿轮约 14 分钟完成。不同齿轮呈现出明显不同的转速，也有光影效果；问题是齿轮没有连接在一起。
\n\n因此，不能只因为“第一个转得快、后面的转得慢”就说机械传动完全正确。本期的判断是转速表现看起来符合要求，但结构仍然粗糙，没有独立测量齿数、接触关系或精确速比。
\n\n06:36 的 SVG 灯泡完成得较快，具备逐步绘制的过程。但与 Kimi K3 的同题结果相比，线条和绘制风格不够接近手绘。这里的问题不是“没有实现动画”，而是动画风格与需求还有距离。
\n\n07:31 的二次函数可视化要求用 Manim 显示表达式、绘制曲线并标注关键点。播放生成的视频时，可以看到公式、顶点、零点和绘制过程，我当时评价动画比较流畅。
\n\n这是编写代码后通过 Manim 渲染视频的工作流，不是模型直接输出视频。本期没有保留足以复算的完整函数与渲染参数，所以本文只记录实际展示的组成部分，不增加数学精度或画质参数的结论。
\n\n08:30 的复杂任务是在已经初始化的 Godot 4 项目中制作侏罗纪坦克射击游戏。
\n\n讲稿前面用“大约 40 分钟”描述等待，随后记录为 39 分钟，Claude Code 界面上下文占用达到 96%。打开后能够看到坦克、发射炮弹和 UFO，但坦克方向不好控制，恐龙造型和数量也不符合预期。
\n\n这一轮必须准确描述为：游戏能启动，有部分交互，但要求的大量效果没有实现。不能把它改写成完全不能运行，也不能因为成功打开就认定开发成功。
\n\n96% 是当时客户端显示的上下文状态，并不直接证明模型真实输入已经达到一百万 Token；缺少调用日志和客户端配置，无法把这个百分比精确换算成模型上下文使用量。它至少提示我们，长任务接近这套工具当时的会话边界时，应该关注剩余空间和任务完成情况。
\n\n10:00 的原生 iOS 任务约 24 分钟完成，当时界面上下文显示 100%。项目在 Xcode 中编译成功，并在模拟器里打开。
\n\n演示检查了这些功能：
\n\n其中一个明确的问题是，切换为深色主题后，页面仍然保持浅色。我当时把它评价为可以正常运行的简单 MVP，而不是已经没有缺陷的成品。提醒设置有界面，也不意味着通知在所有权限和后台状态下都经过了测试。
\n\n这个结果与 Godot 的失败形成了很好的对照：同一个模型面对不同技术栈和任务复杂度，完成度可能相差很大，不能用某一个项目代表全部开发场景。
\n\n12:20 的费用与总结中，开始时记录余额约 20 元，结束后为 18.58 元；公开视频简介把整轮消耗记为约 1.42 元。这里采用这个近似口径，不将起始余额的“大概”改成精确审计账单。
\n\n低调用成本确实使它适合尝试范围清晰的子任务。我当时提出一种用法：由更强模型负责规划，再让 Flash 执行拆分后的工作。但本期没有做“主模型加 Flash 子智能体”的成本和成功率对照，不能把这个建议写成已验证的最优方案。
\n\n对我来说，这期最有价值的结论是把便宜和交付质量一起看。飞船、动画和背单词 App 有可用成果；复杂 Godot 游戏则暴露了操控和需求覆盖问题。实际采用时，把验收标准拆到能够操作和检查的粒度，保留错误与返工成本，才知道低 API 价格是否真的转化成了更低的完成成本。
\n", "date_published": "2026-07-31T20:45:17+08:00", "authors": [{"name": "AI超元域"}], "tags": ["DeepSeek","ClaudeCode","Godot","iOS","AI编程"] }, { "id": "https://www.aivi.fyi/llms/claude-opus-5-coding-review", "url": "https://www.aivi.fyi/llms/claude-opus-5-coding-review", "title": "Claude Opus 5 编程实测：可探索住宅、Godot 沙盒与 26 分钟 Android 应用", "summary": "测试可进入的双层住宅、飞船、Godot 沙盒与约 26 分钟的 Android 开发和模拟器测试。交互原型较完整，发音音量、本地化和长期运行仍需补充验收。", "content_html": "大家好，我是 AI 超元域。
\n\n这期测试 Claude Opus 5，我没有停留在简单网页，而是直接给它安排了更复杂的任务：根据平面图做可探索住宅、还原科幻飞船、制作多种 SVG 动画，再进入 Claude Code 开发 Godot 沙盒游戏和原生 Android 背单词应用。
\n\n最让我关注的是两个方面：一是空间结构能不能真正走进去探索，二是模型能不能在写完代码之后继续运行和测试。下面按具体案例拆开看，哪些效果确实出现了，哪些结论还不能只靠演示成立。
\n\n本文整理自 2026 年 7 月 25 日的视频及与本期案例、顺序和耗时匹配的校正讲稿。本次未重新取得 YouTube 字幕导出，也未重新运行这些项目。文中的体验是当时的观察，不是独立复测报告。
\n\n如果播放器无法加载，可以前往 YouTube 观看完整视频。
\n\nAnthropic 的Opus 5 发布公告日期为 2026 年 7 月 24 日。官方将它描述为接近 Fable 5 前沿能力、成本更低的日常模型，并说明其定价与 Opus 4.8 持平。官方在不同评测里给出了不同结果，并不是宣布它在所有任务上都超过 Fable 5。
\n\n因此，视频中“能否替代 Fable 5”的问题，在本文里限定为这些编程场景和当时的个人使用判断，而不是全领域排名。上述公告在 2026 年 10 月 24 日整理时核对；历史定价关系也不等于今天所有平台、套餐和调用方式都适用相同价格。
\n\n本期前半段在 Claude 中查看生成的前端作品，后半段通过 Claude Code 操作本地项目。代码生成、工具调用、模拟器与引擎共同构成了交付流程，不能把一切结果都归结为模型单独完成。
\n\n01:06 的第一个任务提供包含两层结构的房屋平面图，要求用 Three.js 重建，并支持第一人称和俯视视角。
\n\n运行后，我先切换俯视图查看房间布局与标注，再进入室内逐个探索。演示中可以查看客厅、餐厅、厨房、洗手间、储物空间，通过楼梯到达第二层，再进入书房、卧室和阳台。厨房里能看到灶台、抽油烟机和冰箱，卧室和阳台之间也有连通关系。
\n\n这轮真正有价值的是空间连接：房间不是只摆在一张静态图片里，而是能在视角切换和行走过程中被检查。家具、地板和光影让场景更完整，但它仍然是根据图像生成的互动重建，没有进行尺寸、结构安全或施工精度验证，不能当作建筑设计成果。
\n\n04:08 的黑洞案例通过较复杂的提示词生成可交互场景，可以用鼠标拖动视角，也能调整右侧参数。演示中的吸积盘和整体氛围让我联想到《星际穿越》。
\n\n我当时对它的视觉完成度评价很高，但“像电影里的黑洞”是审美观察。没有方程、数值误差或物理模型的验证记录，就不应该把这段前端效果称为可靠的天体物理模拟。类似边界也适用于后面的风洞案例。
\n\n05:06 的《极光》飞船根据小说描述生成。演示中可以放大查看喷口、燃料罐、前方结构和轮状舱室，再进入不同内部空间，看到草地、树木和控制中心等元素。
\n\n这个任务同时考察外部构造和内部探索。我的当时评价是细节还原很出色，但这里没有把原著逐句对照校验，所以“符合小说”应理解为创作者在本期中的判断，不是独立的文学设定考据。
\n\n06:57 的第二种任务则先准备一张 AI 生成的旋转重力飞船图，让 Opus 5 依据图片重建。结果包含转动的飞船、尾焰、可进入的舱室，以及从舷窗看到的旋转星空。演示还看到了舱门自动打开、屏幕显示数据和底部透明区域。
\n\n这说明本轮结果不仅复现外形，也补充了互动细节。但旋转带来的视觉效果并不能证明人工重力参数符合真实工程设计；屏幕上存在数据，也不等于接入了真实飞船系统。
\n\n08:04 的动画与推理测试集中展示了几种常用题目。
\n\n手绘灯泡案例中，笔画边缘保留不完全规则的效果，文字也更接近手写。我当时认为它比此前的 Kimi K3 作品更符合手绘风格。三只鸟在土星星环上骑车的案例，则能看到角色编号和蹬踏细节。
\n\n复合弓动画展示了拉弓、滑轮转动和箭释放时的形变；农夫过河案例同时呈现动作与步骤。我当时对这些作品的评价很高，但视觉上合理的弓箭动作不等于经过力学计算，步骤被展示出来也不等于本文重新证明了推理过程。它们更适合作为“细节是否跟随任务要求”的具体观察。
\n\n09:49 的 F-35 风洞还提供了可调参数。这里展示的是前端可视化，未提供网格、求解器、边界条件或实验对照，不能据此用于真实气动性能判断。
\n\n10:08 开始的项目进入 Claude Code，要求使用 Godot 开发类似 Minecraft 风格的第一人称侏罗纪沙盒。需求包括恐龙、翼龙、手持武器、手雷和探索。
\n\n约一小时完成开发后，我在演示中测试了射击、飞行和投掷手雷，也进入水下查看鱼类。继续向前飞行时，地图持续生成新的区域，还出现了昼夜、雨雪、荒原与冰原。爆炸能够破坏部分地形，并允许玩家穿过破坏后的空间。
\n\n这一轮相比只生成一个静态场景更进一步：移动、战斗、环境变化和地形交互形成了完整得多的原型。我当时特别强调了它能持续探索，而此前展示的 Kimi K3 版本没有达到同样效果。
\n\n不过，视频里“无限探索”的意思是演示期间前进会继续加载地图，不是通过数学或长期运行测试证明无限。文章没有内存、帧率、区块回收和存档测试数据，因此把这一点准确写成“演示中持续生成”，而不是对大型开放世界稳定性的保证。
\n\n13:43 的原生应用任务沿用此前背单词应用的功能需求，但把技术栈改为 Android。这里最值得看的过程出现在14:20 的测试环节：Claude Code 打开模拟器，运行应用，并对单词卡片进行滑动和点击。
\n\n讲稿记录开发与测试共耗时约 26 分 10 秒。随后，我在 Android Studio 中打开项目，检查了发音、翻转卡片、滑动、收藏、练习题、错误反馈、进度、成就徽章，以及亮色和暗色主题。
\n\n它也有值得保留的小问题：发音声音偏小；因为测试使用英文提示词，生成的界面也是英文，若要面向中文用户还需要本地化。自动运行并操作模拟器，确实比写完代码就停止更接近可用的开发流程，但点击几张卡片不等于完整覆盖所有功能、设备和异常路径。
\n\n这里的“26 分钟”是这一轮特定环境中的记录，并非对任意 Android 应用的交付时限承诺。项目还没有在本文中经过上架审查、隐私检查、不同屏幕适配和长期稳定性测试。
\n\n本期让我最满意的，是 Opus 5 能把空间与交互结合起来：住宅可以走进去，飞船可以内外探索，Godot 项目有持续生成的地图，Android 应用能够运行并接受模拟器操作。
\n\n对于这类快速原型，我当时认为它已经值得作为日常主力尝试，也能在部分原先依赖 Fable 5 的工作中替代使用。但这不是一个严格控制变量的横向排名：提示词、环境、等待时间和人工检查并没有全部统一公开。
\n\n如果把这些成果继续用于真实项目，我会先验收核心流程，再补充准确性、性能、异常处理和平台适配。尤其是黑洞、风洞、建筑和机械动画，视觉说服力越强，越需要明确它展示了什么、没有证明什么。这样的区分，比单纯看“代码写了多少”更能反映一次 AI 开发是否真正完成。
\n", "date_published": "2026-07-25T16:39:05+08:00", "authors": [{"name": "AI超元域"}], "tags": ["Claude","Opus5","ClaudeCode","Godot","Android","Threejs"] }, { "id": "https://www.aivi.fyi/llms/codex-multi-agent-v2", "url": "https://www.aivi.fyi/llms/codex-multi-agent-v2", "title": "🚀Graph Engineering范式：Codex Multi-agent V2支持Kimi、MiniMax、GPT多模型混用+动态派生subagent，并行执行、Pi Agent工具调用，效率倍增", "summary": "我把 Codex 变成了一个多模型代码审查团队", "content_html": "过去使用 Codex 进行代码审查，通常是把代码、分支或 Pull Request 交给同一个模型。
\n\n它负责理解改动、发现问题、判断严重程度，最后再生成审查报告。
\n\n这种方式足够简单，也很容易使用，但它存在一个明显的问题：
\n\n\n\n\n从发现问题到验证问题，所有判断都可能来自同一个模型。
\n
如果模型第一次阅读代码时忽略了某个风险，它在第二次检查自己的结论时，也可能继续忽略同一个风险。
\n\n随着 Codex 对自定义 Subagent 的支持逐渐完善，我们可以采用一种更接近真实软件团队的工作方式：
\n\nCodex 主 Agent\n负责理解任务、拆解范围和调度流程\n\nKimi Code Reviewer\n负责独立代码审查\n\nMiniMax Code Reviewer\n负责从另一个模型视角检查缺陷\n\nPi Code Reviewer\n调用独立审查器提出候选问题，再逐条验证\n最终形成的已经不再是一个模型独自完成全部工作，而是一套由主 Agent 统一调度的多模型代码审查系统。
\n\n\n\n\n\n\n🚀 本篇笔记所对应的视频：
\n\n
\n- 👉👉👉 通过YouTube观看
\n
多模型系统的意义，并不是简单地让三个模型重复检查同一份代码。
\n\n如果只是把同一个 Prompt 同时交给多个模型，再把结果拼接起来，通常只会产生大量重复内容。
\n\n更有效的做法，是先为每个 Agent 设定清晰的职责边界。
\n\n例如：
\n\n| Agent | \n主要职责 | \n
|---|---|
| 主 Agent | \n确定审查范围、创建子 Agent、汇总与验证结果 | \n
| Kimi Reviewer | \n独立检查正确性、安全性、并发和兼容性问题 | \n
| MiniMax Reviewer | \n从另一个模型视角补充代码缺陷和测试风险 | \n
| Pi Reviewer | \n调用独立审查流程，并验证候选问题是否真实存在 | \n
这样的设计有两个直接价值。
\n\n不同模型的训练数据、推理方式和代码偏好并不完全相同。
\n\n同一个问题可能被 GPT 忽略，却被 Kimi 或 MiniMax 发现。
\n\n多模型不能保证一定正确，但可以扩大审查覆盖面。
\n\n一个模型提出问题，并不意味着这个问题可以直接写进最终报告。
\n\n更可靠的流程应该是：
\n\n第三方模型提出候选问题\n ↓\n主 Agent 重新打开对应代码\n ↓\n检查触发路径与实际影响\n ↓\n必要时运行测试或静态检查\n ↓\n确认后才进入最终报告\n也就是说，其他模型负责提供新的观察角度，主 Agent 负责最终证据校验。
\n\n这套系统中最重要的设计原则，是把主 Agent 和第三方 Subagent 的模型配置彻底分开。
\n\n整体结构如下：
\n\n用户任务\n ↓\nCodex 主 Agent\n ├→ Kimi Code Reviewer\n ├→ MiniMax Code Reviewer\n └→ Pi Code Reviewer\n ↓\n 汇总、去重与验证\n ↓\n 最终报告\n主 Agent 继续使用默认的 OpenAI 模型，负责：
\n\n第三方模型则只绑定到指定的自定义 Agent。
\n\n例如，只有显式调用 Kimi Reviewer 时，任务才会被路由到 Kimi。
\n\n普通 Subagent 不会因为系统中注册了 Kimi，就自动切换到 Kimi 模型。没有明确指定 Agent 类型时，它仍可能继承主 Agent 的模型配置。
\n\n这可以避免一个非常危险的问题：
\n\n\n\n\n为了增加一个第三方 Reviewer，却意外把整个 Codex 主 Agent 都切换到了第三方模型。
\n
因此，第三方模型的连接信息、模型目录和认证逻辑，都应该被限制在独立的 Provider 和 Agent 配置中，而不是放入主配置的全局层级。
\n\n代码审查和代码实现是两种不同的职责。
\n\n如果 Reviewer 在发现问题后立即开始修改代码，就容易出现以下情况：
\n\n因此，我为所有 Code Review Subagent 设置了相同的基本原则：
\n\n默认只读\n不主动编辑文件\n不创建提交\n不扩大任务范围\n不把风格偏好当成缺陷\nReviewer 应重点检查：
\n\n每一条问题还必须回答三个问题：
\n\n问题发生在哪里？\n什么场景会触发？\n会造成什么实际影响？\n如果没有足够证据，就不应该为了让报告显得“有内容”而编造 Finding。
\n\n没有发现可执行问题时，直接说明没有验证到明确缺陷，反而更加可靠。
\n\n主 Agent 和第三方 Subagent 使用不同模型和 Provider 时，最大的难点往往不是模型路由，而是任务上下文如何传递。
\n\n在实测中，常见的上下文交接方式存在三种情况。
\n\n看起来最保险，但完整历史可能同时携带父 Agent 的模型类型、角色状态和内部上下文。
\n\n对于自定义第三方 Agent，这可能导致：
\n\n这种方式看似最干净，但第三方 Subagent 可能根本收不到当前用户的实际任务。
\n\n结果通常是：
\n\n在这次配置中，更可靠的方式是只让子 Agent 继承当前一轮任务。
\n\n这样既可以保留当前用户的明文要求，又不会把父 Agent 的完整历史、角色和模型状态全部带入子线程。
\n\n它解决的是一个非常实际的问题：
\n\n\n\n\n第三方模型必须知道“现在要做什么”，但不一定需要知道主 Agent 之前所有的思考过程。
\n
这也是跨 Provider Subagent 能否稳定工作的关键。
\n\n当父任务中包含“创建 Reviewer 并执行审查”之类的描述时，第三方 Subagent 有可能把这条父级指令也当成自己的任务。
\n\n于是可能出现：
\n\n主 Agent 创建 Kimi Reviewer\n ↓\nKimi Reviewer 又尝试创建 Kimi Reviewer\n ↓\n新的 Reviewer 继续创建 Reviewer\n这会造成无意义的递归调用。
\n\n因此，每个专用 Subagent 的角色指令都应该明确：
\n\n\n\n\n直接执行被委派的任务，不要再次创建或委派给其他 Codex Agent。
\n
在联调过程中，还应当让不同角色清楚自己的身份：
\n\n主 Agent：\n负责创建子 Agent 并等待结果\n\nReviewer：\n直接执行 Code Review，不再继续委派\n在多 Agent 系统里，“你是谁”与“你应该做什么”同样重要。
\n\nKimi Reviewer 是一个独立的只读代码审查 Agent。
\n\n它适合检查：
\n\n它的价值在于，为主 Agent 提供一个不同模型的独立审查视角。
\n\nMiniMax Reviewer 的职责与 Kimi Reviewer 类似，但使用不同模型。
\n\n同时保留两个 Reviewer，并不是为了证明哪个模型一定更强，而是为了观察：
\n\n如果两个 Reviewer 返回同一个问题，主 Agent 仍需要重新验证。
\n\n多个模型意见一致，只能提高关注优先级，不能直接代替证据。
\n\nPi Reviewer 的设计更特殊。
\n\n它本身仍然由主模型运行，但会调用一个受限、只读的 Pi 审查器，让 Pi 使用另一个模型进行第二轮独立审查。
\n\n其工作流程是：
\n\nCodex Reviewer 确定审查范围\n ↓\n调用只读 Pi Reviewer\n ↓\nPi 返回候选问题\n ↓\nCodex 逐条重新检查代码\n ↓\n确认或否决每一条候选问题\n ↓\n只报告通过验证的问题\n这里最关键的原则是：
\n\n\n\n\nPi 的输出只是审查证据，不是最终答案。
\n
Pi 返回的问题必须被重新打开、重新定位和重新验证。
\n\n需要删除：
\n\n这种结构比直接转发 Pi 的回答更加可靠，因为它形成了“外部发现—本地验证”的两阶段流程。
\n\n自定义模型接入 Codex 时，终端可能出现模型元数据相关的 Warning。
\n\n很多人看到 Warning 后，会立刻认为第三方模型没有真正运行。
\n\n但模型目录警告和模型路由失败是两件不同的事情。
\n\n判断 Subagent 是否真的使用了指定模型，应同时检查：
\n\n也就是说，不要只看终端里的一行提示。
\n\n真正可靠的判断来自完整的运行链路：
\n\nAgent 角色正确\n+\n模型正确\n+\nProvider 正确\n+\n工具调用真实发生\n+\n请求日志匹配\n当第三方模型通过本地代理接入 Codex 时，还需要注意系统网络环境。
\n\n如果系统启用了全局 HTTP 代理，本来发往本机服务的请求，也可能被错误转发到外部代理。
\n\n表现通常是：
\n\n解决思路不是不断修改模型参数，而是先确认：
\n\n这是本地 Agent Harness 中非常典型的一类问题：
\n\n\n\n\n看起来像模型错误，实际是网络路径错误。
\n
另一类常见问题是：配置最初完全正确，但代理工具重启、切换 Provider 或重新接管后，主配置被自动重写。
\n\n结果可能是：
\n\n原本：\n主 Agent 使用 OpenAI\nKimi 只用于指定 Reviewer\n\n重启后：\n主 Agent 也被改成 Kimi\n这种错误非常隐蔽，因为用户可能仍然看到 Codex 正常运行，却不知道模型路由已经变化。
\n\n更可靠的做法是：
\n\n如果确实需要自动修复配置，脚本应当具备幂等性：
\n\n\n\n\n无论执行一次还是执行多次，最终配置都保持相同。
\n
仅仅看到主 Agent 输出一句“Kimi 已完成审查”，并不能证明 Kimi 真的运行过。
\n\n父 Agent 有可能根据已有上下文模拟一个看似合理的子任务结果。
\n\n因此，完整验证应至少覆盖以下几层。
\n\n确认主配置和自定义 Agent 配置可以被真实解析器读取，而不是仅凭肉眼判断格式正确。
\n\n发起一次真实任务，确认主 Agent 仍然使用预期的默认模型和 Provider。
\n\n绕过 Subagent 交接，直接测试第三方模型路由，确认本地代理能够收到请求并成功返回。
\n\n由主 Agent 创建指定 Reviewer，并确认子线程中的：
\n\n要求子 Agent 返回一个只有实际执行后才能获得的标记或证据。
\n\n例如：
\n\n重启代理工具和 Codex 后，再次确认：
\n\n只有这些步骤全部通过，才能说明系统不是“配置看起来正确”，而是真的完成了端到端路由。
\n\n说明模型连接和 Provider 大概率正常。
\n\n问题更可能出现在：
\n\n通常说明它没有收到清晰的当前任务。
\n\n应优先检查上下文继承方式，而不是立刻修改模型参数。
\n\n这通常属于上游容量问题。
\n\n不应直接把它判断为协议或本地代理配置错误。
\n\n说明全局配置被代理工具重新接管。
\n\n应检查配置事实来源和重启后的覆盖逻辑。
\n\n在接入第三方模型时，最容易被忽略的是凭据传播范围。
\n\n建议始终遵守以下原则：
\n\n尤其在使用 Pi 等外部审查器时，传递内容应严格限制在当前代码审查范围内。
\n\n对于大型 diff，可以只传递：
\n\n不要为了让模型拥有“完整上下文”，把整个用户目录、配置目录或凭据文件一起交给它。
\n\n这套多模型代码审查系统，真正有价值的地方，不是 Codex 可以同时调用 Kimi、MiniMax 和 Pi。
\n\n而是我们开始把代码审查拆成不同责任：
\n\n主 Agent 负责调度\n第三方模型负责独立发现\n确定性工具负责验证\n主 Agent 负责最终判断\n这已经不再是简单的“换一个模型”。
\n\n它更接近一套小型的 Graph Engineering 工作流：
\n\n任务进入\n→ 选择 Reviewer\n→ 多模型独立审查\n→ 汇总候选问题\n→ 逐条验证\n→ 删除重复和误报\n→ 输出最终报告\n但多 Agent 并不会自动带来更高质量。
\n\n真正决定系统可靠性的，仍然是：
\n\n当这些基础工作真正做好之后，Codex 才不再只是一个独自工作的超级 Agent。
\n\n它开始变成一个能够调度不同模型、不同工具和不同审查路径的 AI 工程团队。
\n", "date_published": "2026-07-23T00:00:00+08:00", "authors": [{"name": "AI超元域"}], "tags": ["Codex","Kimi","MiniMax","Pi Agent","Subagents","多Agent","Graph Engineering","AI智能体","AI编程","OpenAI","AGI","AIGC"] }, { "id": "https://www.aivi.fyi/llms/introduce-orca-ade", "url": "https://www.aivi.fyi/llms/introduce-orca-ade", "title": "🚀Orca不是另一个AI IDE，而是一个人的AI工程团队作战室！Claude Code、Codex、OpenCode多Agent并行编排、Git Worktree隔离、Diff Review与手机远程控制完整实测", "summary": "Orca 不是另一个 AI IDE：它想解决的是“一个人如何管理一支 AI 工程团队”", "content_html": "当 Claude Code、Codex、Grok、Gemini、OpenCode 等 AI 编程工具越来越强，开发者面临的问题也在发生变化。
\n\n过去，我们关心的是：
\n\n\n\n\n哪个模型写代码更强？
\n
现在，一个新的问题逐渐浮现：
\n\n\n\n\n当我同时使用多个 AI Agent 时，应该怎样管理它们？
\n
如果让 Claude Code 负责分析，让 Codex 负责实现，让 Grok 负责 Review，再让另一个 Agent 补测试，你很快就会遇到一系列现实问题：
\n\n多个 Agent 会不会互相覆盖文件？
\n\n不同任务应该使用哪个分支？
\n\n谁正在执行，谁已经完成，谁在等待输入？
\n\n多个 Agent 给出不同实现后，应该怎样比较？
\n\n离开电脑之后，如何继续查看和控制任务？
\n\n多个 Claude、Codex 账号以及额度，又该如何管理？
\n\n最近我体验了一段时间 Orca。它给我的最大感受是：Orca 并不是想成为一个更强的 AI 编程 Agent，而是在尝试成为多个 AI Agent 之上的管理层。
\n\n\n\n\n\n\n🚀 本篇笔记所对应的视频：
\n\n
\n- 👉👉👉 通过YouTube观看
\n
传统 IDE，例如 VS Code，主要围绕人类开发者设计：
\n\n但在 AI Agent 逐渐承担大量编码工作的情况下，开发界面的核心对象正在变化。
\n\n开发者不再只是自己编辑代码，还需要同时观察多个 Agent、给它们派发任务、检查执行状态、比较不同结果，并决定最终合并哪个方案。
\n\nOrca 将自己定位为一个面向 AI Agent 工作流的开发环境。官方对它的描述是：在同一个桌面 IDE 中并排运行多个 AI 编程 Agent，每项任务拥有自己的 Git worktree、Agent 终端和浏览器环境。它并不是模型，也不会替代 Git，而是运行开发者原本就在使用的 Claude Code、Codex、OpenCode 等 CLI Agent。
\n\n换句话说：
\n\n\n\n\nVS Code 更像一张给人类使用的办公桌，而 Orca 更像一间用于管理多个 AI 工程师的项目作战室。
\n
假设我们在同一个项目目录中同时运行三个 Agent：
\n\nClaude Code：分析认证模块并修改接口\n\nCodex：重构登录流程\n\nGrok：检查安全问题并补充修复\n它们很可能同时读取和修改相同文件。
\n\n第一个 Agent 读取代码后，第二个 Agent 改写了文件；第一个 Agent 再继续操作时，它所理解的代码状态可能已经过时。
\n\n接下来就会出现：
\n\nOrca 的核心设计之一，就是让每项任务运行在独立的 Git worktree 中。
\n\n每个 worktree 都有自己的：
\n\n多个 Agent 即使修改相同路径的文件，也不会直接覆盖彼此的工作。开发者可以让它们从同一个基础版本出发，分别尝试不同方案，最后查看各自的 Diff，选择更好的实现。
\n\n这解决的并不只是“分支切换麻烦”，而是多 Agent 并行开发最基础的隔离问题。
\n\n只有一个 Agent 时，我们可以盯着终端看它在做什么。
\n\n但当 Agent 数量变成五个、十个甚至更多时，情况就完全不同了。
\n\n你需要知道：
\n\n在我的视频测试中，Orca 左侧侧边栏能够显示不同 worktree 和 Agent 的运行状态；不同 Agent 还可以通过标签页或横向、纵向分屏同时显示。关闭 Orca 中的任务视图后，之前的 worktree、终端内容和任务记录也可以重新恢复。
\n\nOrca 还提供了更结构化的 Orchestration 能力。它可以通过消息、Task、Dispatch 和 Decision Gate 等机制协调多个 Agent，而不只是向多个终端随便发送几段 Prompt。官方将 Orchestration 定义为结构化的多 Agent 协调层，用于任务派发、完成状态跟踪、Agent 间消息以及需要人工决策的流程。
\n\n可以简单理解为：
\n\nWorktree\n解决“在哪里工作”\n\nAgent Terminal\n解决“由谁执行”\n\nOrchestration\n解决“谁做什么、依赖谁、怎样确认完成”\n这使多 Agent 工作流从“同时打开几个终端”，逐渐变成一套可管理的执行流程。
\n\n不过也需要注意：Orchestration 是协调基础设施，不是一个自动替你完成所有任务拆解、技术判断和代码合并的“AI 主管”。任务边界、验收标准和最终决策，仍然需要开发者负责。
\n\nAI 编程发展到现在，代码生成速度已经不是唯一瓶颈。
\n\n真正困难的部分越来越像是：
\n\n\n\n\nAI 一次生成了几百行甚至几千行修改，我怎样确认它真的做对了？
\n
如果同时运行多个 Agent，这个问题会更加严重。
\n\n三个 Agent 分别给出三个实现，并不意味着开发效率自动提升。假如所有修改都混在一个目录里，或者你必须手动来回寻找文件、复制行号、整理反馈，那么并行带来的收益很快会被 Review 成本抵消。
\n\nOrca 为每个 worktree 提供独立 Diff，并支持查看暂存、未暂存和新增文件，还提供合并冲突界面以及按行、按代码块暂存等能力。
\n\n它的 Annotate AI Diff 功能还允许开发者直接在 Diff 行上留下评论，再把一批评论统一发送给 Agent，让 Agent 根据带有明确代码位置的反馈进行修改。这样就不需要手动复制文件名、行号和代码片段。
\n\n这让一种非常有价值的工作流成为可能：
\n\n让多个 Agent 从同一版本出发\n\n分别尝试不同方案\n\n查看各自 Diff\n\n选择最好的方向\n\n在 Diff 上批量标注意见\n\n让获胜 Agent 继续修改\n\n最终由人类审查和合并\nOrca 官方甚至专门提供了“三个 Agent 竞争同一项任务”的使用方式：同一个 Prompt、三个 worktree、三个 Agent，完成后比较结果并选择获胜方案。
\n\n所以 Orca 的价值并不是减少人工 Review，而是让人工 Review 更有组织。
\n\nAI Agent 经常需要长时间运行。
\n\n它可能在：
\n\n如果这时需要开会、出门或换一台设备，传统终端工作流就很不方便。
\n\n在这次视频测试中，我将 Orca 桌面端与手机配对后，可以直接在手机上查看不同任务和 Agent 的终端输出，了解它们当前的执行状态。
\n\nOrca 官方提供了 iOS 和 Android Mobile Companion。目前移动端仍处于 Beta 阶段，定位也不是完整代码编辑器，而是桌面端的远程控制器。它可以查看 worktree 和 Agent 状态、读取近期终端输出、回复等待输入的 Agent、查看 Source Control、切换账号和创建 workspace。
\n\n这意味着，一个比较现实的使用场景是：
\n\n在电脑上启动多个 Agent\n\n离开工位去开会\n\n手机收到 Agent 完成或等待输入的通知\n\n查看终端内容\n\n回复“继续”或补充一个要求\n\n回到电脑后集中 Review\n它并不是让开发者在手机上完成复杂编码，而是避免长时间 Agent 因为一个简单确认停在那里。
\n\n很多重度 AI 编程用户并不只使用一个工具。
\n\n常见组合可能是：
\n\nClaude Code 负责分析和复杂推理\n\nCodex 负责代码实现\n\nGrok 或 Gemini 负责补充 Review\n\nOpenCode 负责其他模型调用\n与此同时，开发者还可能拥有个人账号、公司账号、不同工作区账号，以及 Host、WSL、远程服务器等不同运行环境。
\n\n传统做法经常是不断执行：
\n\nlogout\nlogin\n重新选择账号\n检查额度\n重启 Agent\nOrca 可以在状态栏中显示 Claude、Codex 等 Provider 的用量和重置窗口，并提供 Claude、Codex 的账号切换能力。官方说明中，当前用量会跟随活动账户显示，其他已配置账户也可以在账号选择器中查看。
\n\n对于 Codex 和 Claude，Orca 可以在不手动修改配置文件的情况下切换活动账号。但已经运行的 Agent 进程通常仍会保留启动时的账号身份，需要重启相应 Session，新的 Session 才会使用切换后的账号。
\n\n这项功能看起来不像 worktree 那么醒目，但对于每天高频使用多个 AI Provider 的开发者来说，非常实用。
\n\n视频中我还演示了 Orca 的 Tasks 功能。
\n\n在 Tasks 页面中，可以选择项目仓库，查看 GitHub Issues 和 Pull Requests。打开一个 Issue 后，可以直接基于它创建 workspace，Orca 会启动对应 Agent，并把 Issue 上下文放入任务输入中。
\n\n这样，传统流程：
\n\n打开 GitHub\n\n找到 Issue\n\n复制标题和描述\n\n回到终端\n\n创建分支\n\n启动 Agent\n\n粘贴上下文\n就可以简化为：
\n\n打开 Issue\n\n创建 Worktree\n\n启动 Agent\n官方文档也说明，从 GitHub Issue 创建 worktree 时，Orca 会预填任务名称，并把 Issue 与 worktree 关联起来；Tasks 页面还可以浏览 GitHub Projects 中的卡片并从卡片直接创建 worktree。
\n\n除了 GitHub，Orca 还支持 Linear、Jira 和 GitLab 等工作项来源，把“任务从哪里来”和“Agent 在哪里执行”连接在一起。
\n\n在视频中，我还测试了语音输入。
\n\n设置好语音识别模型后，通过快捷键即可直接说出：
\n\n\n\n\n对这个项目的代码进行 Review。
\n
识别结果会进入 Codex 的输入框，然后可以直接提交任务。
\n\n对于复杂代码需求，键盘输入依然更精确；但对于“继续执行”“检查测试”“总结当前修改”“对这个模块做 Review”一类指令，语音输入确实能够减少操作成本。
\n\n视频还演示了自动化功能。例如，可以选择一个仓库、指定 Codex 等 Agent，再设置为每个工作日上午 9 点自动运行 Repo Review。
\n\n这意味着 Orca 不只是在管理当前打开的终端，也开始把部分重复性工作转变为可计划的 Agent 任务。Orca CLI 同样提供对 worktree、终端、浏览器和定时自动化的控制能力。
\n\n在多 Agent 工作流中，最怕的事情之一是：
\n\n\n\n\n我昨天到底在哪个分支、哪个终端里，让哪个 Agent 做到了哪一步？
\n
Orca 会恢复打开的 worktree、终端分屏、滚动记录和聚焦标签页。在宿主机没有重启、后台 PTY 进程仍然存活的情况下，关闭并重新打开 Orca，Agent 进程还可以继续运行并重新连接。
\n\n在视频中，我恢复了之前关闭的 oh-my-pi 和 Claude Code 任务。之前的输出内容没有丢失，恢复后还可以继续查看或接着执行。
\n\n当你只有一个终端时，这可能只是一个便利功能；但当你同时维护多个 worktree 和多个 Agent 时，它实际上是在保存整个“AI 团队的工作现场”。
\n\n虽然 Orca 的功能非常丰富，但它并不是“输入一句需求，就自动完成整个项目”的工具。
\n\n官方也明确强调：
\n\n它真正擅长的是：
\n\n把不同 Agent 放进合适的隔离环境\n\n让多个任务可以并行推进\n\n让状态、上下文和结果更容易被管理\n\n把最终判断权留给开发者\nWorktree 隔离也不等于完整安全沙箱。
\n\n即使每个 Agent 使用独立目录，Agent 仍然可能执行命令、访问网络、读取凭据或修改 worktree 之外的资源。特别是在启用类似 YOLO 或跳过权限确认的模式时，仍然需要理解相应风险。
\n\n此外，更多 worktree、文件监视器、浏览器标签和终端进程也会消耗更多磁盘与内存。官方的故障排查建议同样提到，不再使用的 worktree 和浏览器标签应及时关闭。
\n\n我认为，Orca 特别适合下面几类开发者。
\n\n第一类，是已经同时使用 Claude Code、Codex、OpenCode 等多个 CLI Agent 的人。
\n\n第二类，是经常需要让多个 Agent 并行尝试同一个问题，并对不同结果进行比较的人。
\n\n第三类，是在多个功能分支、多个 Issue 和多个 PR 之间频繁切换的人。
\n\n第四类，是需要通过 SSH 或远程开发机运行长时间 Agent 任务的人。Orca 可以在远程主机创建 worktree 和运行 Agent，同时在本地继续使用编辑器与 Diff 界面。
\n\n第五类，是认为“生成代码已经很快，但管理、Review 和合并 AI 代码越来越累”的人。
\n\n相反，如果你平时只运行一个 Agent、一次只处理一个小任务，并且不需要多分支并行，那么 Orca 带来的收益可能没有那么明显。
\n\n过去两年，AI 编程工具之间的竞争主要围绕：
\n\n但随着模型能力逐渐提高，另一个竞争维度也会越来越重要：
\n\n\n\n\n谁能更好地组织多个 Agent 工作？
\n
未来的开发方式可能不再只是：
\n\n一个开发者\n+\n一个 AI 助手\n而是：
\n\n一个开发者\n\n管理多个拥有不同能力的 AI Agent\n\n让它们在隔离环境中并行工作\n\n通过结构化流程交付结果\n\n最终由人类 Review 和决策\n从这个角度来看，Orca 真正想解决的，并不是“怎样让一个 AI 写代码更快”。
\n\n而是：
\n\n\n\n\n当一个人开始管理一支 AI 工程团队时，需要怎样的开发基础设施？
\n
这也正是我认为 Orca 最值得关注的地方。
\n", "date_published": "2026-07-20T00:00:00+08:00", "authors": [{"name": "AI超元域"}], "tags": ["Orca","Claude Code","Codex","OpenCode","AI智能体","多Agent","AI编程","Vibe Coding","Git Worktree","Agent Teams","AGI","AIGC"] }, { "id": "https://www.aivi.fyi/llms/introduce-GPT-5.6-Sol", "url": "https://www.aivi.fyi/llms/introduce-GPT-5.6-Sol", "title": "🚀GPT-5.6 Sol真正可怕的，不是更聪明，而是更能把活干完！九轮极限实测：SVG、Three.js、Godot、iOS、Chrome扩展与浏览器自动化", "summary": "GPT-5.6 Sol 真正可怕的，不是更聪明，而是更能把活干完", "content_html": "GPT-5.6 系列终于正式发布了。
\n\n这次 OpenAI 一共推出了三个型号：面向复杂任务的 Sol、主打平衡的 Terra，以及追求速度和成本的 Luna。
\n\n从官方公布的数据来看，GPT-5.6 Sol 在终端操作、浏览器自动化、长上下文和 Agent 任务上的表现都非常突出，部分成绩甚至超过了 Claude Fable 5 和 Claude Mythos 5。
\n\n但跑分表只能告诉我们模型在标准化测试中拿了多少分，无法回答一个更实际的问题：
\n\n把一个真正复杂的任务交给它，它到底能不能做出来？
\n\n为了弄清楚这一点，我没有只让它写几个函数或者生成一个简单网页，而是连续安排了九组难度完全不同的任务：
\n\n测试完成以后，我对 GPT-5.6 Sol 最大的感受，不是它突然变得无所不能了。
\n\n而是它越来越像一个能够接手完整项目的人。
\n\n它仍然会犯错，也会误解指令，甚至会为了尽快完成任务主动寻找捷径。但只要任务目标足够清楚，它确实比过去的大多数模型更愿意继续追踪问题，把代码、测试、功能和最终交付一起做完。
\n\n\n\n\n\n\n🚀 本篇笔记所对应的视频：
\n\n
\n- 👉👉👉 通过YouTube观看
\n
GPT-5.6 Sol 发布后，OpenAI 同时推出了 Max、Pro、Ultra 等不同名称，很容易让人误以为它们是不同模型。
\n\n其实不是。
\n\nGPT-5.6 Sol 支持多档推理强度：
\n\nnone、low、medium、high、xhigh、max
推理强度越高，模型能够用于分析问题的时间和计算量越多，但延迟和 Token 消耗也会随之增加。
\n\n我在这次测试中，大部分复杂任务使用的都是 Extra High。
\n\n它适合大型代码开发、复杂逻辑推理、跨文件修改和需要反复验证的任务，但完全没有必要用来修改按钮颜色或者调整一段文案。
\n\nPro 更重视最终答案的质量，而不是速度和成本。
\n\n它更适合架构设计、安全审查、复杂研究，以及做错一次就会造成很大损失的任务。
\n\nUltra 默认由多个 Agent 并行处理任务，再由主 Agent 汇总结果。
\n\n它和 Max 的区别非常明显：
\n\n如果任务可以拆成前端、后端、数据库和测试四个独立方向，Ultra 会很有价值。
\n\n但如果只是修改同一个文件，让四个 Agent 同时工作，往往只会产生重复劳动、上下文膨胀和修改冲突。
\n\nOpenAI 没有公布 GPT-5.6 Sol 的参数量、训练规模和具体架构。
\n\n目前能够确认的主要参数包括：
\n\n上下文窗口：1,050,000 Tokens
\n\n最大输出：128,000 Tokens
\n\n官方模型资料标注的知识截止日期：2026 年 2 月 16 日
\n\n输入类型：文本、图片
\n\n输出类型：文本
\n\n暂不支持：音频输入、视频输入和微调
\n\nAPI 模型名称：gpt-5.6-sol
它还支持网页搜索、文件搜索、代码解释器、Hosted Shell、Computer Use、MCP、Skills、图像生成、Apply Patch 和 Tool Search 等工具。
\n\nGPT-5.6 Sol 的标准 API 价格为：
\n\n这里还有一个容易被忽略的细节。
\n\n当单次请求的输入超过 272K Tokens 后，整个请求都会进入长上下文计价区间，输入和输出价格都会进一步上涨。
\n\n所以百万上下文并不意味着应该把整个代码仓库、几十份 PDF、所有日志和历史对话一次性全部塞进去。
\n\n它解决的是“放不下”的问题，却无法自动解决“内容太乱”和“重点不突出”的问题。
\n\n我首先在 ChatGPT 网页版中询问了两个问题：
\n\n第一，它的知识截止日期是什么时候？
\n\n第二，它知道的日本最新首相是谁？
\n\n网页端给出的回答是，知识截止日期为 2025 年 12 月，同时也正确回答了当时的日本首相。
\n\n至少从这个简单测试看，它对近期政治信息的覆盖没有出现明显断层。
\n\n但这里也暴露出一个值得注意的问题：
\n\n模型自己回答的知识截止日期，和官方模型资料中的日期并不完全一致。
\n\n这说明我们不能单纯依赖模型自报身份、版本和知识截止日期。真正需要确认模型参数时，仍然应该以官方模型卡和 API 文档为准。
\n\n模型可以回答自己是谁，但它对自身运行环境的描述不一定永远准确。
\n\n第一道真正的能力测试，是让 GPT-5.6 Sol 使用 SVG 制作一段动画：
\n\n一只几维鸟、一只渡渡鸟和一只鹈鹕，分别骑着自行车在土星环上比赛。
\n\n我还要求：
\n\n最终生成的结果总体不错。
\n\n土星、土星环和背景中的几颗行星都被画了出来，鹈鹕和渡渡鸟的外形也比较容易辨认。自行车车轮会持续转动，而且不同车辆还表现出了不同的运动速度。
\n\n不过，它犯了一个非常明显的错误：
\n\n几维鸟是倒着骑自行车的。
\n\n几维鸟最长、最明显的嘴部应该朝向前进方向，但它生成的身体朝向刚好相反。
\n\n这次测试说明，GPT-5.6 Sol 已经能够同时处理：
\n\n但它对角色朝向和生物结构的理解还不够稳定。
\n\n单从最终视觉效果来看，这次生成结果已经可以使用，不过和我之前测试 Claude Fable 5 时得到的版本相比，细节和整体完成度仍然略逊一筹。
\n\n第二道 SVG 测试更加困难。
\n\n我要求它制作一段男性使用复合弓射箭的动画，并且必须表现出：
\n\n结果一开始就出现了问题。
\n\n尽管提示词里明确要求使用 SVG，它第一次仍然直接调用了图像生成工具，给我生成了一张静态图片。
\n\n我再次强调：
\n\n用 SVG，不是用图像生成。
\n\n第二次它才真正生成了可运行的 SVG 动画。
\n\n修正后的结果包含了拉弓特写、滑轮转动、放箭、箭矢飞行和命中靶心等完整过程，还加入了动画进度显示。
\n\n从功能完整性来看，它确实理解了我想要的整个过程。
\n\n但在物理结构上仍然有一个严重问题：
\n\n它把复合弓拿反了，弓片弯曲的方向也是反的。
\n\n这次测试暴露了 GPT-5.6 Sol 的两个短板。
\n\n第一，它有时会根据任务内容自行选择工具，即使这个选择和提示词里的明确要求冲突。
\n\n第二，它可以生成“看起来像那么回事”的物理动画，却不一定真正理解机械结构中的受力方向。
\n\n箭能够飞出去，滑轮也会转，靶心也能命中。
\n\n但这些元素组合在一起，不代表物理关系一定正确。
\n\n接下来，我把逻辑推理和动画生成结合在了一起。
\n\n题目是一个经过扩展的农夫过河问题。
\n\n农夫需要把老虎、羊、蛇、鸡和一筐苹果安全送到对岸，但船每次只能搭载农夫和一样东西。
\n\n同时存在三组特殊关系：
\n\n普通的大模型测试，通常只需要输出一段文字步骤。
\n\n这次我要求 GPT-5.6 Sol 不仅要推导出正确方案，还要使用 SVG 动画完整演示整个过河过程。
\n\n最终，它给出的主要顺序是：
\n\n这套顺序是成立的。
\n\n更重要的是，它没有只输出几个移动的小圆点，而是做出了一个完整场景：
\n\n这次结果让我比较意外。
\n\n因为模型必须先完成逻辑推理，再把推理结果转换成时间轴，最后还要把每一步对应到 SVG 动画状态。
\n\n它唯一比较明显的 Bug，是农夫独自划船返回时，整个人会变成倒立状态。
\n\n原因很可能是模型为了复用同一个角色元素，直接使用了整体翻转，而没有单独处理人物朝向。
\n\n但除了这个问题，整段动画的推理顺序、场景元素和播放流程都比较完整。
\n\n在我看来，这个案例比单纯让模型回答一道逻辑题更有价值。
\n\n因为它不只证明了模型“知道答案”，还证明了它能够把答案转换成一个真正可运行、可观察的产品。
\n\n完成 SVG 测试后，我继续加大难度，让它使用 Three.js 创建波音 747-8 洲际客机的三维模型。
\n\n要求包括：
\n\n等待几分钟后，它生成了一个可以直接运行的版本。
\n\n外部视角下，可以对飞机进行 360 度旋转和缩放。机身、机翼、尾翼和四台发动机都已经具备，整体轮廓也能看出波音 747-8 的特征。
\n\n点击“进入机舱”后，视角会切换到飞机内部。
\n\n用户可以在机舱中转动视角和前后移动，内部也确实包含座椅、窗户和过道。
\n\n不过它实现的过道明显过于狭窄，部分座椅和机舱空间比例也不够合理。
\n\n这说明它已经能搭建完整的三维交互体验，但距离精准的工业建模还有很大差距。
\n\n如果目标是展示概念、制作网页 Demo 或快速验证交互方式，这个结果已经足够。
\n\n如果要还原真实飞机尺寸、空气动力学结构或者舱内布局，就必须提供更严格的尺寸数据和参考模型。
\n\n网页端的测试主要集中在 SVG 和 Three.js。
\n\n进入 Codex 后，我决定把难度再提高一个等级。
\n\n过去测试大模型的游戏开发能力时，我经常使用 Three.js。但对现在的模型来说，使用 Three.js 制作一个网页小游戏已经不算特别困难。
\n\n所以这一次，我改用 Godot 4。
\n\n第一个任务，是开发一款可以直接运行的 3D 侏罗纪坦克射击游戏。
\n\n游戏设定是：
\n\n玩家驾驶一辆现代坦克进入侏罗纪时代，通过鼠标控制炮塔和准星，可以射击恐龙、翼龙、树木、石头以及突然出现的 UFO。
\n\n我只提前创建了一个空的 Godot 3D 项目，然后把需求完整交给 Codex。
\n\n大约半小时后，游戏已经能够直接运行。
\n\n进入场景以后，可以看到一辆完整的 3D 坦克。键盘可以控制前进、后退和转向，鼠标能够控制炮塔方向，点击后会发射炮弹。
\n\n炮弹击中树木后，树会倒下。
\n\n场景里还出现了多种不同外形的恐龙和天空中的翼龙。玩家可以驾驶坦克在地图中寻找并攻击这些目标。
\n\n更出乎意料的是，它还实现了随机出现的 UFO。
\n\nUFO 不只是一个装饰模型，而是会主动攻击玩家。坦克可以转动炮塔进行还击，命中后 UFO 会坠落并发生爆炸。
\n\n它还加入了环境音效、射击音效、爆炸效果，以及不同类型的恐龙模型。
\n\n这个项目当然还称不上完整商业游戏。
\n\n画面精细度、敌人 AI、碰撞反馈和关卡设计都有提升空间。
\n\n但它已经不是一段用来演示语法的代码，而是一款具备基本循环的游戏原型：
\n\n移动、瞄准、射击、敌人攻击、目标被摧毁、爆炸反馈。
\n\n从一个空的 Godot 项目到能够运行的三维射击原型，大约用了半小时。
\n\n这已经足以说明，GPT-5.6 Sol 的优势不是只会生成某一段代码，而是能够在一个真实工程里持续创建场景、脚本、节点和交互逻辑，最后把它们拼成一个完整结果。
\n\n完成侏罗纪坦克游戏后，我又测试了一个相反的方向。
\n\n前一个任务的提示词非常详细，几乎把玩法、操作方式和场景元素都规定好了。
\n\n这一次，我故意只给它一个很短的任务：
\n\n使用 Godot 4 开发一款可以直接运行的 3D 空战原型。玩家驾驶 A-10 攻击机，可以攻击地面的坦克和装甲车，需要模拟导弹发射和机炮射击，其余部分由模型自行发挥。
\n\n大约 20 分钟后，项目完成。
\n\n游戏支持第三人称和第一人称视角切换。
\n\n飞机可以：
\n\n画面中还会实时显示飞机速度。
\n\n第一人称座舱视角的效果尤其不错，导弹发射、飞行和爆炸也已经形成完整反馈。
\n\n测试过程中，我还因为操作失误直接撞到了地面。这从另一个侧面说明，它确实实现了飞机和地形之间的碰撞，而不只是播放一段预设动画。
\n\n这个案例说明，GPT-5.6 Sol 不仅能够根据详细规格执行，也能够在提示词非常简短的情况下自行补全大量设计。
\n\n但这并不意味着提示词越短越好。
\n\n提示词越短，模型发挥空间越大，结果也越不可控。
\n\n如果只是做创意原型，这种自主发挥非常有价值。
\n\n如果开发的是正式产品，仍然应该明确规定控制方式、核心玩法、性能要求、代码结构和验收标准。
\n\n整个测试中，最复杂、也最有代表性的案例，是一套原生 iOS 背单词产品。
\n\n这次我没有让它开发一个只有几个页面的小型 MVP，而是明确告诉它：
\n\n除非遇到无法解决的技术障碍，否则不要主动缩小范围，尽可能实现接近最终产品的体验。
\n\n整个产品包含三个部分：
\n\nChrome 扩展负责用户阅读英文网页时的取词。
\n\n用户双击不认识的单词后，扩展需要显示：
\n\n用户可以把这些单词保存到 Supabase。
\n\niOS App 再从 Supabase 中读取词库，并根据用户保存的单词生成学习计划。
\n\n更复杂的是，我还要求它把用户学过的单词随机组合起来，通过 OpenRouter 调用大模型生成一篇英文短文，让这些单词自然地出现在文章中，帮助用户在语境中强化记忆。
\n\nApp 使用 Swift 和 SwiftUI 开发。
\n\n整个开发过程持续了一个多小时，中间也不是完全一次成功。我让 Codex 继续修复了多轮 Bug，才最终得到能够完整运行的版本。
\n\n这一点必须说清楚：
\n\n它不是一句提示词下去，几分钟后就凭空变出一个完全无 Bug 的商业产品。
\n\n但真正重要的是，它在遇到问题后没有停在一个残缺版本，而是继续修改，最终把整条产品链路跑通了。
\n\nApp 首先实现了注册和登录。
\n\n用户创建账号后，首页会显示当前词库、学习进度和学习状态。
\n\nChrome 扩展也可以登录同一个账号，并提供：
\n\n我在一篇英文文章中连续双击了多个单词。
\n\n扩展能够弹出翻译卡片，显示单词在当前句子中的具体意思，而不只是给出脱离语境的词典解释。
\n\n随后，我把八个单词保存到了词库。
\n\n回到 iOS App 后，这八个单词已经同步出现。
\n\n点击开始学习后，App 会自动创建一轮学习计划。
\n\n每个单词不仅包含中文解释，还会显示用户当时在网页中看到它的原始句子。
\n\n这点非常重要。
\n\n很多背单词软件只保存单词本身，过几天后用户已经忘记当时为什么查这个词。
\n\n保留原始网页语境，可以让记忆重新和具体阅读场景建立联系。
\n\n完成单词学习后，用户可以选择文章主题，再点击“生成专属短文”。
\n\n我选择了四个刚刚学习的单词。
\n\n生成完成后，这四个单词都自然出现在短文中，并且被高亮显示。
\n\n页面还支持：
\n\n其中朗读功能的声音比较机械，明显使用的是系统级语音合成。
\n\n这也是整个产品中比较明显的不足。
\n\n后续可以将它替换成质量更高的大模型语音 API，让长文章朗读听起来更自然。
\n\n读完短文后，App 会自动进入巩固练习。
\n\n它实现了：
\n\n我实际录入了一句英文，App 成功识别出了说话内容。
\n\n完成整轮学习后，它还会生成学习总结，显示：
\n\n词库页面中，每个通过 Chrome 扩展保存的单词也可以单独打开，查看解释和原始语境。
\n\n这个项目最有价值的地方，不是某一个页面设计得多漂亮。
\n\n而是 GPT-5.6 Sol 打通了完整的数据链路：
\n\n网页取词 → Chrome 扩展 → Supabase → iOS App → 学习计划 → 大模型生成短文 → 练习 → 学习总结。
\n\n它同时处理了：
\n\n从最终完成度来看，这一次 GPT-5.6 Sol 开发的版本，甚至比我之前使用 Claude Fable 5 开发的版本更完整。
\n\n提示词中要求的大部分功能都实现了，其中一些学习流程和交互细节还超出了我原本的预期。
\n\n当然，这仍然是原型，而不是可以直接上架的正式产品。
\n\n真正发布前，还需要继续处理：
\n\n但它已经证明了一件事：
\n\n复杂 Agent 模型正在从“帮你写代码”，走向“帮你搭建产品”。
\n\n最后，我测试了 GPT-5.6 Sol 的浏览器自动化能力。
\n\n我让 Codex 接管浏览器，进入 Tinkercad，创建一个简单的房屋三维模型。
\n\n它首先进入 3D 设计工作区，然后开始寻找可以使用的元素。
\n\n原本我以为它会使用立方体、屋顶、门窗等基本几何体，从零搭建一座房子。
\n\n但它很快清空了当前内容，在搜索框中直接搜索“房子”，找到一个现成房屋模型，拖到工作区，再对尺寸和参数进行调整。
\n\n最后，它保存了这个房屋模型，并告诉我任务已经完成。
\n\n这个结果非常有意思。
\n\n从任务目标来看，我只要求它“创建一个简单的房子模型”，并没有明确规定必须从几何体开始搭建。
\n\n所以它并没有违反指令。
\n\n它只是发现了一条更快完成目标的路径。
\n\n这说明 GPT-5.6 Sol 已经不再机械地把每一个动作都从头执行，而是会观察环境、寻找现有资源，再选择成本更低的方案。
\n\n但这个案例也带来了一个非常重要的提醒：
\n\n模型完成了任务，不代表它使用的是你预期的方法。
\n\n如果我的真实目的不是得到一座房子，而是测试它能否使用基本几何体完成建模，那么提示词中就必须明确写出：
\n\n否则，模型会优先优化最终结果，而不是遵循你脑海中没有写出来的过程。
\n\n把 SVG、Three.js、Godot、iOS 和浏览器自动化放在一起看，GPT-5.6 Sol 的特点已经非常明显。
\n\n过去使用代码 Agent，经常会遇到一种情况：
\n\n模型完成了表面修改，测试还没跑完，边界条件没有处理，文档也没有同步，然后就告诉你任务已经完成。
\n\nGPT-5.6 Sol 更愿意继续追踪问题。
\n\n尤其是在 iOS App 开发中，它经历了一个多小时和多轮 Bug 修复，最终仍然把 Chrome 扩展、Supabase、SwiftUI 和大模型接口连接了起来。
\n\n它不是不会失败。
\n\n它的提升在于，失败后更愿意继续做。
\n\n很多模型可以单独写一个 SwiftUI 页面，也可以单独写一个 Chrome 扩展。
\n\n真正困难的是把这些部分连接起来。
\n\nSol 在这次测试中表现最突出的能力，正是把不同技术栈组合成一个完整工作流。
\n\n它不是只生成一堆互不相关的文件，而是尝试让数据真正从一个系统流向另一个系统。
\n\nA-10 游戏的提示词非常短，但它主动补充了：
\n\n这种自主性在创意原型中非常有价值。
\n\n但在正式项目中，也意味着必须提前写清楚边界。
\n\n几维鸟倒着骑车、复合弓方向错误、弓片弯曲方向错误、农夫返回时倒立、飞机机舱过道过窄。
\n\n这些错误有一个共同特点：
\n\n模型实现了主要功能，却没有完全理解现实世界中的结构、比例和方向。
\n\n所以在涉及机械、建筑、医学、工程和真实物理结构时，不能因为动画“能动起来”，就默认它是正确的。
\n\nTinkercad 房屋模型是最直观的例子。
\n\n它没有从零搭建，而是直接搜索现成模型。
\n\n这和 METR 测试中发现的某些行为虽然性质不同，但背后有一个相似点：
\n\n模型会主动寻找最快满足完成条件的路径。
\n\n这不一定是坏事。
\n\n在人类工作中，复用现成资源本来就是一种效率。
\n\n问题在于，如果某些路径不能使用，就必须提前写进约束，而不能指望模型自行理解。
\n\nGPT-5.6 Sol 在 Terminal-Bench 2.1 中获得 88.8 分，Ultra 模式达到 91.9。
\n\n它在 DeepSWE、BrowseComp 和 OSWorld 等涉及终端、网页和计算机操作的测试中也表现突出。
\n\n这些结果和我的实际体验基本一致。
\n\nSol 最强的并不是单次代码补全，而是：
\n\n但在 SWE-Bench Pro 中，Sol 的成绩仍然明显落后于 Fable 5。
\n\nArtificial Analysis 的综合测试中，Sol Max 也没有全面超过 Fable 5。
\n\n这说明它并不是在所有任务中都更聪明。
\n\n我的判断是：
\n\nSol 更擅长把东西做出来，而且做得完整、可运行；Fable 5 在部分需要细腻理解、代码可读性和严密分析的任务中，仍然可能更强。
\n\n这两个模型并不是简单的上下级关系，而是工作风格不同。
\n\nSol 的自主性很强。
\n\n如果不给出验收标准，它会自己判断什么叫完成，而这个判断不一定和你相同。
\n\n一个完整任务至少应该写清楚：
\n\nTinkercad 案例里，我只规定了结果，没有规定过程，所以它直接复用了现成模型。
\n\n以后可以把约束分成两类。
\n\n结果约束：
\n\n过程约束：
\n\n只写结果，模型会寻找最快路径。
\n\n结果和过程都写清楚，才能得到真正符合预期的交付。
\n\n不要让模型只说“已经完成”。
\n\n应该要求它：
\n\n在 iOS App 项目中，真正有价值的并不是它生成了多少代码，而是最后确实完成了注册、取词、同步、文章生成和练习流程。
\n\n普通代码修改和文档整理，Medium 或 High 通常已经足够。
\n\nMax 更适合复杂架构、疑难故障和高风险决策。
\n\nUltra 则只适合能够真正并行拆分的任务。
\n\n模型越强，越要学会控制计算量，而不是无脑把所有选项开到最高。
\n\n目前更务实的方式，不是寻找一个包打天下的模型，而是按照任务路由：
\n\n可以先让 Fable 5 设计架构，再让 Sol 实现。
\n\n也可以先让 Sol 完成产品，再让 Fable 5 进行代码审查。
\n\n模型之间的竞争，正在逐渐变成不同工序之间的分工。
\n\n你是本项目的交付负责人，不是只提供建议的顾问。\n\n目标：\n[写清楚最终需要解决的问题]\n\n最终交付物：\n[代码、文件、报告、应用或可运行项目]\n\n技术要求：\n[技术栈、平台、依赖和版本]\n\n必须实现：\n1. [核心功能]\n2. [核心功能]\n3. [核心功能]\n\n禁止事项：\n1. [不能使用的捷径]\n2. [不能修改的内容]\n3. [未经批准不能执行的操作]\n\n验收标准：\n1. 项目可以实际运行或构建。\n2. 必须执行相关测试。\n3. 必须验证主要用户流程。\n4. 不得只根据代码推测功能可用。\n5. 必须列出仍然存在的问题。\n\n工作规则：\n1. 先检查现有项目和环境。\n2. 制定实现计划，再开始修改。\n3. 遇到错误后继续定位和修复。\n4. 涉及删除数据、发布、付款或生产环境时，必须暂停。\n5. 最终只交付完成结果、验证记录、已知问题和后续建议。\n这套模板最重要的不是让提示词变长。
\n\n它真正解决的是四个问题：
\n\n什么才算完成，哪些捷径不能走，什么时候必须停下来，以及最后拿什么证明结果可信。
\n\n完成这九轮测试后，我认为 GPT-5.6 Sol 并不是一个在所有方面都碾压其他模型的“全能模型”。
\n\n它会把几维鸟画反，会把复合弓拿反，会让农夫倒立，也会在 Tinkercad 里直接找一个现成房子交差。
\n\n但与此同时，它也能在半小时内做出一款可玩的 Godot 三维射击游戏，在简短提示词下自行补全空战玩法，还能持续一个多小时，把 Chrome 扩展、Supabase、SwiftUI 和大模型 API 连接成一套真正能够运行的学习产品。
\n\n这就是 GPT-5.6 Sol 最值得关注的地方。
\n\n过去，我们判断一个模型好不好，主要看它能不能给出正确答案。
\n\n现在，更值得问的问题变成了：
\n\n它能不能在长时间工作后仍然记得最初目标？
\n\n能不能自己发现缺失的功能？
\n\n能不能在遇到 Bug 后继续修复？
\n\n能不能把代码、界面、数据库、测试和最终交付连在一起？
\n\n能不能真正运行项目，而不只是生成几段看起来合理的代码？
\n\n从这次测试来看，GPT-5.6 Sol 已经越来越接近一个能够负责完整交付的 Agent。
\n\n它不一定是每一道题里最聪明的学生。
\n\n但在真实工作中，它可能是那个最愿意把项目做完、把现场收拾干净，最后还回来检查一遍的人。
\n\n而这，往往比跑分多拿几分更重要。
\n\n本文基于截至 2026 年 7 月 10 日的公开资料和实际测试结果整理。不同账户、运行环境、推理级别和工具权限可能导致结果存在差异。
\n", "date_published": "2026-07-11T00:00:00+08:00", "authors": [{"name": "AI超元域"}], "tags": ["GPT-5.6 Sol","GPT-5.6","OpenAI","Codex","AI智能体","AI编程","Vibe Coding","Godot 4","SwiftUI","AGI","AIGC"] } ] }