更新日期：2026 年 10 月 23 日
对比产品：Claude Duet、Grok Bot、ChatGPT dots、Meta Muse

随着 AI 助手从被动问答转向主动执行任务，Anthropic、xAI、OpenAI 和 Meta 相继推出了具备长期记忆、后台工作和应用操作能力的个人智能体。

它们不再只是回答问题的聊天机器人，而是能够接收长期目标、持续检查任务进度，并在必要时主动联系用户的 AI 助手。

不过，四款产品在定价、地区开放范围、自动化能力和订阅权益方面存在明显差异。

本文将从以下维度进行横向对比：

• 订阅价格与最低使用门槛
• 地区限制与开放资格
• 后台任务、自动化和记忆能力
• 浏览器、电脑与本地文件操作
• 编程、应用连接器与多智能体协作
• 各家公司完整的订阅套餐
• 使用额度和额外计费规则

一、价格与使用门槛

首先来看最直接的问题：使用这些 AI 助手需要多少钱？

注意：订阅门槛不等于购买后立即获得使用资格。

Claude Duet 和 ChatGPT dots 都采用分批开放方式，付费套餐只代表符合申请或使用条件。

1. Claude Duet

Claude Duet 是 Anthropic 推出的主动式个人 AI 助手。

最低使用门槛是 Claude Pro：

• 月付：$20
• 年付：$200
• 年付折合：约 $16.67/月

Duet 也向 Claude Max 用户开放，但目前有两个重要限制：

1. 仅面向美国用户。
2. 需要加入候补名单并获得邀请。

因此，即使已经支付 Claude Pro 的订阅费用，也不意味着立即能够使用 Duet。

官方资料：

• Claude Pricing
• Getting Started with Claude Duet

2. Grok Bot

Grok Bot 是 xAI 旗下的智能体产品。

2026 年 10 月，xAI 推出新的 The X Subscription，将 Grok、Grok Bot、Cursor 和 X 的部分权益整合到统一的订阅体系中。

最低完整使用门槛为 Premium：

• 月付：$30
• 年付：$300
• 年付折合：$25/月

需要区分：

这里的 Premium 是新版 The X Subscription Premium，而不是旧版 X Premium。

它也并非单独的 Grok Bot 套餐。

官方资料：

• The X Subscription Pricing
• Grok Bot Plans

3. ChatGPT dots

ChatGPT dots 是 OpenAI 推出的持续性个人智能体。

目前最低使用门槛为：

• ChatGPT Pro 100：$100/月

更高的 Pro 200、Pro 500 也包含 dots。

个人版要求用户年满 18 岁，目前不向欧洲经济区、英国和瑞士开放。

官方资料：

• About ChatGPT Pro Tiers
• ChatGPT dots Documentation

4. Meta Muse

Meta Muse 与其他三款产品最大的区别在于：

免费套餐已经包含基础智能体能力。

目前公布的订阅档位包括：

但 Muse 仍处于有限测试和逐步推出阶段。官方已提及美国、加拿大等市场，其他地区尚未确认正式开放日期。

官方资料：

• Muse
• Meta Muse Subscription

二、核心功能横向对比

四款产品都试图实现一个共同目标：

让 AI 不再只是等待用户提问，而是成为能够长期承担任务、主动推进工作的助手。

但它们的产品设计并不完全相同。

注：表中的「支持」表示官方公布过对应的产品能力，不代表所有地区、所有账户及全部套餐都已获得该功能。

三、Claude Duet：主动管理工作，而不是等待命令

Claude Duet 更接近一个专门面向知识工作者和小企业主的 AI 助理。

它最大的特点不是拥有浏览器，而是能够主动发现值得处理的事情。

主要功能

1. 主动生成每日简报

Duet 可以根据用户已经连接的日历、邮件和业务工具，整理当天的重要事项。

例如：

• 今天有哪些会议？
• 哪些客户需要回复？
• 是否有日程冲突？
• 哪些工作需要提前准备？
• 有哪些业务指标出现变化？

相比普通的聊天机器人，Duet 的目标是减少用户每天重新描述工作背景的时间。

2. 周期性检查任务

Duet 可以在后台持续检查已经连接的账户和任务。

当发现需要用户处理的事项时，可以主动提醒。

3. 处理专业工作

Duet 可以参与：

• 文档与报告制作
• 财务模型
• 幻灯片
• 仪表盘
• 商业数据分析
• 客户跟进
• 发票与经营事务
• 简单应用原型开发

4. 继承 Claude 生态

Duet 可以使用 Claude 已经建立的部分记忆、Skills 和连接器。

对于长期使用 Claude 的用户，这能够减少重复配置。

当前限制

Claude 官方目前明确指出：

• Duet 固定使用 Claude Opus 5.5。
• 用户不能手动切换 Duet 的模型。
• 当前无法查看或接管 Duet 的云浏览器。
• Microsoft 365 暂未在 Duet 中提供完整支持。
• 部分 Slack 功能存在限制。
• 支持录制语音消息，但不会代替用户拨打电话或发送短信。

这些限制尤其值得注意。

例如，Claude Pro 自身可能包含 Microsoft 365 相关能力，但不能据此推断 Duet 已经拥有相同的集成能力。

适合谁？

Claude Duet 更适合：

• 企业经营者
• 自由职业者
• 日常处理大量邮件和日历的用户
• 已经长期使用 Claude 的知识工作者

它的产品思路偏向于：

让 AI 主动告诉你今天应该处理什么。

官方介绍：

Introducing Claude Duet

四、Grok Bot：把 AI 组织成一个团队

Grok Bot 的设计更接近一个由多个 AI 同事构成的团队。

与单一助手不同，Grok Bot 强调多个具名 Bot 之间的分工与协作。

主要功能

1. 创建多个 AI Bot

用户可以创建不同职责的 Bot。

例如：

• Research Bot：负责信息收集
• Coding Bot：负责编程和修复问题
• Content Bot：负责文章和内容生产
• Operations Bot：负责监控和日常运营

不同 Bot 可以拥有各自的角色和工作上下文。

2. 多 Bot 协作

Grok Bot 支持群聊和任务交接。

例如：

Research Bot 完成资料收集后，可以把结果交给 Content Bot，由后者撰写文章。

这种产品设计更接近组织中的工作分工。

3. 云端电脑

Grok Bot 提供持久的云电脑环境，包括：

• 浏览器
• 文件系统
• 命令行
• 工作文件
• 登录状态

用户可以观看并接管云电脑。

但需要注意：

同一账户的多个 Bot 共用云电脑资源、文件、浏览器登录状态和终端凭据。

它们不是完全隔离的独立虚拟机。

4. Skills、Routines 与自动化

Grok Bot 可以把重复工作保存为 Skill，再通过 Routine 定时执行。

目前官方文档列出的限制包括：

• 每个 Bot 最多 50 个 Routine
• 运行间隔至少 5 分钟

此外，Grok Bot 还有通过操作示范学习任务的能力，但部分功能仍处于分批开放阶段。

Grok Bot 不只使用 Grok 模型

这是一个比较容易被忽略的细节。

Grok Bot 可以根据任务自动选择不同模型，包括 xAI 自家模型和第三方模型。

官方文档甚至提到了 Opus 5.5 路由。

不过：

• 用户不能指定具体模型。
• 用户也不能查看每个任务实际使用的模型。
• 自动模型路由不等于 Cursor 内第三方模型的免费使用权。

适合谁？

Grok Bot 特别适合：

• 希望创建多个专业 AI 助手的用户
• 有大量重复任务的开发者
• 同时使用 Grok、Cursor 和 X 的用户
• 希望通过 Skills 和 Routines 构建自动化流程的用户

它的产品思路可以概括为：

不是雇佣一个 AI 助理，而是组织一支 AI 团队。

官方文档：

• Grok Bot Overview
• Skills, Routines and Automations
• Computer and Apps

五、ChatGPT dots：让一个 AI 长期负责你的工作

ChatGPT dots 的核心理念是持续性。

用户不再需要为同一个项目每天创建新对话、重新交代上下文，而是可以将长期任务交给 dots。

它会持续推进任务，并在适当的时候主动跟进。

主要功能

1. 持续跟踪长期目标

例如：

• 持续研究特定技术领域
• 关注软件项目的开发进度
• 跟进工作中的待办事项
• 分析项目变化
• 定期准备工作简报

dots 可以将一个长期目标拆成多个任务。

2. 委派 Work 和 Codex

这是 dots 区别于普通聊天助手的重要能力之一。

当工作需要浏览器操作、文件处理或代码执行时，dots 可以委派给相应的工作环境。

对于编程任务，它还可以与 Codex 配合。

3. 云电脑和本地电脑

dots 可以使用云端电脑与浏览器。

用户也可以连接自己的电脑，让它访问本地工作环境。

需要注意：

云端任务可以在本地设备关机后继续，但依赖本地电脑的任务仍然需要电脑在线，并保持相应应用运行。

4. 长期记忆

dots 可以结合：

• ChatGPT 已有记忆
• 自身的笔记
• 用户偏好
• 长期目标
• 任务结果
• 已连接应用中的工作上下文

5. 主动研究与执行权限分离

dots 可以主动发现值得关注的信息，但主动研究中的部分工具采用只读权限。

需要对外部系统采取实际行动时，还需要遵循对应的授权和审批规则。

因此，主动发现问题与自动修改系统并不是一回事。

适合谁？

dots 更适合：

• 已经使用 ChatGPT 的专业用户
• 使用 Codex 的开发者
• 有长期研究任务的知识工作者
• 需要协调多个项目的用户
• 希望 AI 持续跟进工作而非只完成一次对话的用户

它的设计理念更像：

一个长期负责结果，并且能够协调其他工具的 AI 项目负责人。

官方文档：

• dots Tasks and Memory
• dots Computers and Apps
• dots Controls

六、Meta Muse：免费个人智能体，强调生活与目标管理

Muse 是 Meta 推出的个人智能体。

它的特点是：

免费版就可以使用基础智能体功能，而不是必须先购买昂贵的专业套餐。

主要功能

1. 长期目标管理

Muse 提供 Goals 功能，用于管理和持续推进个人目标。

例如：

• 旅行规划
• 学习安排
• 个人财务整理
• 家庭事务
• 购物与生活计划
• 小型企业经营

2. 云端电脑

Muse 可以使用自己的云端环境，包括：

• 浏览器
• 文件系统
• 命令行
• 安全虚拟机

它可以生成文档、网页、追踪工具及仪表盘。

3. Mac 本地操作

Meta 已经公布 Muse 的 Mac 本地操作能力。

获得相应权限后，Muse 可以处理部分本地文件以及：

• iMessage
• Notes
• Reminders
• Mail
• Calendar

这一能力对于深度使用 macOS 的用户具有吸引力。

4. 商业连接器

Muse 还扩展了小企业经营相关工具，包括：

• Shopify
• QuickBooks
• Stripe
• Slack
• Notion
• Facebook
• Instagram
• Meta 广告账户

5. 语音与电话功能

Muse 已经公布语音交互功能。

Meta 还展示了替用户联系商家的电话操作，但这仍属于实验性能力，不代表所有用户都已获得通用电话外呼功能。

模型方面

Muse 最初主要基于 Muse Spark。

2026 年 10 月，Meta 又宣布 Wonder 模型将优先向 Muse 订阅用户推出。

不过，目前不能据此认定所有 Muse Power 或 Maximum 用户已经全面切换到 Wonder。

适合谁？

Muse 更适合：

• 希望免费尝试个人智能体的用户
• Mac 用户
• 有较多日常事务的用户
• 希望 AI 管理长期个人目标的用户
• 使用 Meta 商业生态的小企业主

它的设计更接近：

一个长期了解你的生活、习惯和目标的私人助理。

官方资料：

• Introducing Muse
• Muse Business
• Meta Muse Subscription

七、完整订阅权益对比

仅比较 AI 助手的最低价格并不公平。

因为这些助手并不是独立售卖的产品，部分功能直接包含在母公司的 AI 订阅中。

下面分别整理四家的套餐。

7.1 Claude 套餐

Claude Max 的 API Credits

目前 Claude Max 还提供相应的月度 API Credits：

• Max 5x：$100/月
• Max 20x：$200/月

但是有重要限制：

1. 新订阅需要满 7 天并关联 Claude Console 组织后领取。
2. 每个计费周期刷新，不结转。
3. 可用于 Claude API、Managed Agents、Agent SDK 等。
4. 不能用于交互式 Claude Code。
5. 不能抵扣 Claude、Cowork 或 Claude Code 的超额使用费用。

因此不能把 API Credits 简单视为 Duet 可额外消耗的额度。

官方来源：

• Claude Pricing
• What Is the Max Plan?
• Monthly API Credits

7.2 Grok / The X Subscription 套餐

新版 The X Subscription 将多款产品整合到统一订阅中。

倍率均以 Plus 套餐为基准。

这不意味着不同套餐的 Bot 数量、执行任务数量或速度严格按照这些倍率增加。

各档权益

Plus：$8/月

主要包括：

• Grok Chat
• Grok Voice
• Grok Imagine
• Grok Build
• Cursor 基础代理
• 部分 X 认证和创作者权益

Premium：$30/月

在 Plus 的基础上，增加：

• Grok Bot
• Cursor 云端代理
• 自动化功能
• Origin 代码托管
• Bugbot 代码评审
• 视频生成
• 更多 X 权益

Super：$100/月

主要增加：

• 更多共享 AI 用量
• 高峰时期的模型优先访问

Ultra：$200/月

主要增加：

• 最高档共享 AI 用量
• 新产品与模型优先体验资格

Grok 套餐的两个重要限制

第一，Cursor 第三方模型单独计费。

如果用户在 Cursor 中手动选择 Claude、GPT 等第三方模型，从首次使用起就会按照对应的 API 标价额外收费。

不是包含在 30 美元订阅内。

第二，Grok API 不赠送 API 使用额度。

能够访问 Grok API，不等于订阅包含免费的 API Credits。

API 仍然按照相应的使用价格计费。

因此，如果购买 Premium 主要用于 Cursor 编程，应该将第三方模型的用量成本一起考虑。

官方来源：

• The X Subscription Pricing
• Cursor Pricing
• Grok Bot Plans

7.3 ChatGPT 套餐

dots 是否单独收费？

目前首个 dot 包含在符合条件的 Pro 或 Business Premium 套餐中。

无需额外支付一份独立的 dots 订阅费。

但是，必须区分两个概念：

• 与 dot 的对话
• dot 实际委派执行的工作

官方说明，与 dot 的对话不计入普通 ChatGPT 使用限制。

但 dot 创建或管理的 Work、Codex 等任务仍然会消耗对应工具的使用额度。

因此，不能把 dots 理解成一个每月支付 100 美元就能无限执行复杂任务的助手。

ChatGPT Business

Business 新建工作区至少需要两个付费席位。

所以，个人 Pro 100 的每月 $100 与 Business Premium 的年付折月 $100，不是同一种购买方式。

Enterprise 用户则需要满足对应资格，并由管理员启用相关功能。

官方来源：

• ChatGPT Pricing
• About ChatGPT Pro Tiers
• ChatGPT Business
• ChatGPT dots

7.4 Muse 套餐

根据 Meta 公布的数据：

• Power：每周 5 亿 Muse Tokens
• Maximum：每周 30 亿 Muse Tokens

Maximum 的价格是 Power 的 5 倍，而公布的周额度是 Power 的 6 倍。

不过，不能直接把 Muse Tokens 与 Claude、Grok 或 ChatGPT 的订阅额度进行数字比较。

因为不同平台的 Token 统计、工具执行成本与任务计费方式并不统一。

Muse 和 Muse Code 不是同一个订阅

需要特别注意：

Muse Code 是 Meta 的独立编程产品。

它拥有自己的订阅与使用规则。

因此不能将 Muse Code 的：

• 编程额度
• Wonder 模型权益
• API 使用规则

直接算作 Muse 助手 Power 或 Maximum 套餐的权益。

官方来源：

• Muse Subscription
• Muse Code Subscriptions

八、后台任务如何消耗额度？

对主动式 AI 助手来说，订阅价格不一定是最重要的成本。

因为这些助手可能在用户没有主动聊天时，依然继续运行任务。

Claude Duet 的问题

Claude Duet 与 Claude 主产品共用订阅限制。

例如，Duet 在后台进行日常检查、准备晨间简报时，也会计入相应额度。

因此，Claude Pro 的 20 美元并不代表能够获得一个无限工作的常驻秘书。

Grok Bot 的问题

Grok Bot、Grok 和 Cursor 的相关功能使用同一个共享 AI 额度体系。

因此，当 Bot 执行大量自动化任务时，可能减少其他 AI 功能的可用额度。

Premium 的 $30 不能理解为每个产品分别赠送一整份独立额度。

ChatGPT dots 的问题

与 dots 交流并不等于所有工作都免费。

当 dots 创建或委派 Work、Codex 等实际任务时，依然需要消耗相应工具的额度。

对于高频率执行代码修改、浏览器操作和文件处理的用户，这一点尤其重要。

Muse 的问题

Muse 公布了相对明确的周 Token 数字。

但目前缺少统一标准，无法将它转换为：

• 每周可以完成多少复杂任务
• 可以运行多少小时浏览器
• 可以执行多少次编程操作
• 可以同时管理多少长期目标

因此不能单纯根据数字大小认定 Muse 的性价比一定高于其他产品。

九、不同用户应该怎么选择？

将功能、套餐与实际使用方式综合考虑，可以得到以下建议。

十、总结：四种不同的 AI 助手路线

虽然 Claude Duet、Grok Bot、ChatGPT dots 和 Meta Muse 都被定位为下一代主动式 AI 助手，但它们并不是完全相同的产品。

Claude Duet：工作优先

更关注用户的日历、邮件、业务任务与每日工作安排。

它希望成为一个主动整理信息、发现问题的工作秘书。

Grok Bot：多智能体团队

强调 Bot 分工、协作、技能复用与自动化。

它希望让用户像管理团队一样管理多个 AI 助手。

ChatGPT dots：持续负责

强调长期任务、上下文延续、跨工具协调，以及 Work 和 Codex 的任务委派。

它希望成为一个持续推进目标的 AI 项目负责人。

Meta Muse：个人生活与目标

强调长期个人记忆、日常生活、Goals、商业连接器和本地设备操作。

它希望成为一个能够长期了解用户的私人助理。

最后的价格结论

从最低订阅门槛来看：

但月费最低并不意味着实际使用成本最低，月费最高也不意味着任务能力一定最强。

目前各家公司并没有提供可直接比较的统一 Agent 任务基准。

更合理的评估方式应该是使用同一批任务，比较：

1. 任务完成成功率
2. 单次任务实际消耗
3. 是否需要人工介入
4. 自动化执行稳定性
5. 工具连接与数据权限
6. 是否能持续跟进和修正任务
7. 每月真正完成的有效工作量

对于已经购买 Claude、ChatGPT 或 Cursor 订阅的用户，首先需要核对自己现有套餐是否已经包含对应的智能体权益，避免重复付费。

因此，购买前最好先确认账户是否已获得实际使用入口，而不是单凭订阅页面上的功能介绍进行升级。

参考资料

Anthropic / Claude

• Claude Pricing
• Introducing Claude Duet
• Getting Started with Claude Duet
• What Is the Max Plan?
• Monthly API Credits

xAI / Grok / Cursor

• The X Subscription Pricing
• Grok Bot Overview
• Grok Bot Plans
• Cursor Pricing
• Skills, Routines and Automations
• Computer and Apps

OpenAI / ChatGPT

• ChatGPT Pricing
• ChatGPT Pro Tiers
• ChatGPT Business
• ChatGPT dots
• dots Tasks and Memory
• dots Computers and Apps

Meta / Muse

• Introducing Muse
• Muse Business
• Muse Subscription
• Muse Code Subscriptions

即便账面额度翻倍，不同订阅档位折算成真实 API 额度后对比 Codex / Claude Pro 订阅依然差距悬殊。本文将结合最新实测数据，全面拆解 Gemini 4 Argon 的最新配额机制、Token 折算标准、四大渠道权限矩阵以及当下的订阅策略。

核心要点速览

• 配额大幅跃升：Pro（$20/月）升至 $15/周；Ultra（$100/月）翻倍至 $50/5小时、$200/周。
• Token 换算标准：在常规高缓存命中率下，**$1 约合 1.6M 至 2.0M Tokens**。
• 白嫖/特惠限制：通过学生优惠、印度 Jio 等渠道获取的“非付费 Pro”账号，无法在 Antigravity IDE 中调用该模型，但现已获准在 AI Studio 中免费体验。
• 订阅防坑指南：Ultra $100 档 为当前性价比最高的档位；鉴于官方策略调整频繁，强烈建议按月付费，切勿盲目锁定长期或年付订阅。

一、 新旧配额实测对比：主力档位近乎翻倍

在完成周配额重置后，各付费档位的账面可用额度（以等效 API 消耗美金计）迎来了显著提升：

二、 美金额度与 Token 数量直观换算

抛开单纯的账面美金数字，结合真实开发环境下的后台用量统计，可以更直观地评估各档位的实际生产力：

• 实测基准参考：单日 45 次调用产生 4.83M 总 Token（其中输入用量 696.5k，包含直接输入与 4.02M 缓存读取；输出用量 119.2k，包含内容生成 78.3k 与思考推理 40.9k），在 85.2% 缓存命中率下，预估费用为 $2.99。
• 折算比率：综合测算下来，每 $1 配额约可支撑 1.6M - 2.0M Tokens 的调用量。

按此基准比率折算，各档位的实际 Token 承载力如下：

• Pro（$20 档）：
  • 每周可用：24M - 30M Tokens
• Ultra 5x：
  • 每 5 小时可用：80M - 100M Tokens
  • 每周合计可用：320M - 400M Tokens（约为 Pro 档的 13 倍以上）
• Ultra 50x：
  • 每 5 小时可用：320M - 400M Tokens
  • 每周合计可用：1,280M - 1,600M Tokens

三、 四大渠道权限矩阵与“非付费 Pro”限制说明

很多用户关心通过学生教育优惠（Student Discount）、印度 Jio 联名赠送或试用活动获得的“非付费 Pro（Unpaid Pro）”账号，在此次更新后能否愉快玩耍。以下是四大官方渠道的最新权限划分：

四、 订阅决策与“防坑”建议

1. 首选档位推荐：
   如果你在 Antigravity IDE 中有高频编码、长上下文分析或重度 Agent 生产力需求，$20 的 Pro 档位（24M-30M Tokens/周）很容易触发周上限；建议直接选择 Ultra $100 档位，其每 5 小时 80M-100M Tokens、每周最高 400M Tokens 的容量足以应对绝大多数高强度开发场景，且单位 Token 成本远低于 Pro 档。
2. 切勿锁定长期订阅：
   虽然 Google 此次迅速响应社区呼声、将配额翻倍的操作值得肯定，但熟悉 Google 在 Antigravity 及 AI 订阅生态历史操作的老玩家都非常清楚其策略调整与模型更迭的频繁程度（如随时可能出现的动态限流、计费权重调整或新模型分流）。因此，当下强烈建议坚持“按月付费（Month-to-Month）”，保持随时升降级或退订的灵活性，切忌盲目锁死年付等长期订阅。
3. 非付费 Pro 用户的最优解：
   持有学生认证优惠或 Jio 权益的用户，无需在 Antigravity IDE 中耗费精力尝试突破权限限制，直接转向 Google AI Studio 或 Gemini Web/App 即可零成本体验 Gemini 4 Argon 的完整能力。

五、 延伸评估：Google AI Pro（$20/月）还值得订阅吗？

如果单看 Antigravity IDE 中的 AI 编程配额，$20/月的 Pro 档位（每周 $15，约合 24M - 30M Tokens）面对高强度 Vibe Coding 或大型代码库重构时确实略显局促，在纯编码性价比上不如 Codex / Claude 订阅。

但如果跳出“纯编码工具”的单一维度，从 Google 全家桶生态的视角来审视，这 $20/月的含金量依然极高 —— 甚至可以说属于“买全家桶送 AI 额度”：

• 5TB Google Drive 云端存储：大容量云盘空间（支持家庭组共享），涵盖 Google Photos 原画质备份、Gmail 与 Google Drive，单买同级别云存储本身就价值不菲。
• YouTube Premium Lite 权益：附加轻量级免广告视频体验，大幅提升日常浏览与查阅技术教程的舒适度。
• Google Colab 算力与权益加成：提供更充裕的云端计算单元与更强的 GPU 分配优先级，对需要跑数据科学、模型微调或脚本测试的开发者极为实用。
• GCE 每月 10 美元额度：除了解锁 AI Studio 权限外，还能在 Google 云计算平台每月 10 美元的额度。

选购建议总结：

• 全生态综合型用户（强烈推荐 Pro $20 档）：如果你本身就有 Google Drive 扩容、YouTube 观看、Colab 算力或日常综合 AI 助手的需求，那么 $20 的 Pro 套餐综合回本率极高，附赠的每周 24M - 30M Tokens 足以应付日常轻中度代码补全与脚本编写。
• 重度沉浸式编码开发者（建议直上 Ultra 5x $100 档或专精工具）：如果你订阅的核心诉求是全天候在 Antigravity IDE 中进行高强度 Agent 编码，Pro 档的周限额很快就会见底，此时按月订阅 Ultra $100 档（每周最高 400M Tokens）才是更纯粹的生产力选择。

答案藏在浏览器地址栏旁边的安全认证机制里。最近爆发的 eMudhra（印度知名数字证书颁发机构，旗下品牌为 emSign）私钥缺陷事件，让 Google、苹果、微软、Mozilla 以及 Go 语言团队在同一天拉响了最高级别的紧急安全警报。

很多人的第一反应是：“我又没用过这家印度公司的产品，甚至都没听过它的名字，这关我什么事？”

在互联网的底层逻辑里，一家受信任的证书机构出事，全世界所有人的设备都会直接暴露在危险之中。 下面我们就用最通俗的语言，拆解这场让人啼笑皆非又细思极恐的安全大地震。

一、 什么是 CA？互联网的“护照管理局”

在现实生活中，你去银行办业务，银行看你的身份证或护照就能相信你是谁。为什么？因为身份证是由国家公安机关签发的，银行无条件信任公安机关的防伪印章。

在互联网上，这个“发证机关”就叫做 CA（Certificate Authority，证书颁发机构）。

• 当你访问 google.com 或 taobao.com 时，网站会向你的浏览器出示一张“数字身份证”（即 TLS/SSL 证书）。
• 你的手机和电脑（无论是 Windows、macOS、iOS 还是 Android）在出厂时，系统里就内置了一份“绝对信任的发证机关名单”（根证书库）。
• eMudhra 就是这份全球白名单里的正式成员之一。 只要盖有它家“数字印章”的网站，全世界的手机和浏览器都会默认放行，告诉用户：“这个网站是安全的、正牌的。”

二、 离谱的缺陷：把金库密码设成了“4”

CA 机构用来给网站“盖章”的核心工具，叫做私钥（Private Key）。

按照现代密码学（如椭圆曲线加密 ECC）的设计，一个合格的私钥应该是一个极其庞大、完全随机生成的数字。大到什么程度？就算把全地球所有的超级计算机加起来不眠不休地猜，也需要算到宇宙毁灭才能猜中。因此，即使全天下都能看到公开的证书（公钥），也绝对反推不出背后的私钥。

然而，在最近披露的漏洞中，安全研究人员发现 eMudhra 旗下有 8 张核心中级证书（Intermediate CA） 的私钥生成过程出现了灾难性的代码缺陷——随机数生成器（RNG）几乎完全失效了。

这导致了什么结果？

• 正常情况下，私钥应该是一个几百位的天文数字。
• 而 eMudhra 生成的这 8 把私钥，竟然全都是小于 256 的整数！
• 安全研究员 Scott Helme 测试后震惊地发现，其中一把核心私钥的数字竟然就是 4。

这就好比一家掌控着全球通行证的顶级印钞厂，花重金建造了厚达十米的钛合金金库大门，结果锁匠在装密码锁时偷懒，把密码设成了 0004。

为什么说它“不需要被黑客偷走就已经泄露了”？
因为证书本身是公开在互联网上的。任何人用一台普通家用笔记本电脑，写几行简单的代码，从 1 开始往上试，不到 1 秒钟（甚至用 AI 跑一句提示词），就能从公开的证书里把这 8 把绝密私钥全部算出来。

三、 为什么这会影响到“每一个人”？

对于普通网民和初级开发者来说，理解这件事的杀伤力，需要明白互联网信任链中的一个核心软肋：木桶效应（最弱一环决定整体安全）。

在浏览器的信任机制里，默认情况下，任何一家受信任的 CA，都可以为全世界任何一个域名签发证书。

哪怕 Google、苹果自己用的证书是由 DigiCert 或 Let’s Encrypt 签发的，跟印度的 eMudhra 半毛钱关系都没有，但只要你的电脑系统信任 eMudhra，攻击者算出那把等于 4 的私钥后，就能干出下面两件极其恐怖的事：

1. 完美的“中间人攻击”与网站伪造（针对 6 张 TLS 证书）

泄露的 8 把钥匙里，有 6 把是用来给网站签发 HTTPS 证书的。攻击者拿到钥匙后，可以自己开个假网站，然后用 eMudhra 的私钥给自己盖个章，签发一张写着 www.google.com 或你常用的某家银行域名的“真证书”。

当你连上咖啡馆、机场的公共 Wi-Fi，或者你的路由器、DNS 被劫持时：

• 黑客把你的流量引向他伪造的假银行网站。
• 你的浏览器上前检查身份证，一看：“哟，有 eMudhra 的亲笔签名，而且在我的出厂信任名单里！”
• 浏览器不会弹出任何红色的安全警告，地址栏依然显示安全锁标志。你输入的账号、密码、聊天记录，会在毫不知情的情况下被黑客全部截获解密。

2. 给木马病毒穿上“正版免死金牌”（针对 2 张代码签名证书）

更要命的是，这 8 把钥匙里还有 2 把是代码签名证书（Code Signing CA）。
平时我们在 Windows 或 Mac 上安装软件时，如果是个来历不明的病毒程序，系统会弹出大大的黄色或红色警告拦截它。但如果黑客用这把泄露的私钥给勒索病毒“签个名”，操作系统就会认为这是经过权威机构认证的合法企业软件，直接静音放行。

四、 全球紧急拆弹：科技巨头们做了什么？

正因为这把“万能钥匙”谁都能在 1 秒内算出来，整个互联网基础设施在短短几十小时内上演了一场生死时速的“拆弹行动”：

真正可怕的暗雷：无法更新的“僵尸设备”

看到科技巨头们光速打补丁，你可能会觉得危机已经解除了？恰恰相反，最恐怖的灾难才刚刚开始。

你的日常手机和电脑浏览器会自动联网更新黑名单，但互联网的庞大底座是由无数“从不更新”的设备与环境构成的：

• 出厂后固件就再也没升级过的智能电视、路由器、摄像头等物联网（IoT）设备；
• 企业内网里跑着老旧业务的 Docker 容器镜像（基础镜像里的 ca-certificates 停留在几年前）；
• 机房角落里被遗忘的 Linux 服务器；
• 开发者电脑上常年无人维护、静态编译的命令行工具（CLI）和自动化脚本。

这些设备在出厂或构建的那一刻，就已经把 eMudhra 的根证书写死在了信任列表里，而且它们没有自动拉取证书黑名单（CRL/OCSP）的能力。

这意味着，数百万台物联网设备、Docker 容器、被遗忘的 Linux 机器、无人维护的 CLI 工具等等，都将在未来几年甚至可能无限期地，被携带“合法安全签名”的恶意软件和中间人流量无情地入侵。 对黑客而言，这 8 把算出来的私钥不是一张限时体验卡，而是一把能长期打开无数老旧基础设施大门的永久万能钥匙。

五、 普通人与初级技术人员该做什么？

这次事件给我们上了一堂生动的网络安全课：数字世界的信任是极其脆弱的，密码学算法本身固若金汤，但写代码和做配置的人却可能犯下最低级的错误。

为了保护自己和公司的业务不受波及，建议立即采取以下行动：

1. 普通用户：立即重启并更新你的浏览器和系统。
   去检查一下你的 Chrome、Edge、Firefox 或 Safari 是否有待重启的更新。虽然现代浏览器大多有自动后台推送黑名单的功能，但保持最新版本能确保那 8 把“假钥匙”在你的设备上彻底作废。如果近期上网看到浏览器弹出“您的连接不是私密连接”的红色拦截警告，千万不要点击“继续前往”。
2. 初级开发者 / 运维人员：彻底排查后端环境与容器镜像。
   • 后端与依赖升级： 如果你的服务端或 CLI 工具使用了 Go 语言（Golang）编写并会主动发起外部 HTTPS 请求，或者在离线环境中使用了 Mozilla 的 NSS 库，请立刻升级到刚刚发布的紧急修复版本并重新编译部署。
   • 清理容器与老旧机器： 检查线上正在运行的 Docker 容器和 Linux 服务器，及时执行系统更新（如更新 ca-certificates 包）并重新构建基础镜像，避免它们成为上述永久暴露的“盲区”。
   • 排查自有域名： 检查公司业务是否采购过 emSign（eMudhra）签发的 SSL 证书。如果有，你的网站现在可能已经在用户的浏览器里报错瘫痪了，需立即更换为 Let’s Encrypt、DigiCert 或 Cloudflare 等其他机构的证书。

近期，围绕 p5.js + p5.brush + Claude Code 的动态手绘视频工作流（以开源项目 ClaudeAnimationBase 及其衍生 Skills 为代表）在开发者与创作者圈子里迅速走红。只需对 Claude 说一句“做一支 15 秒小角色抓蝴蝶的手绘短片”，它就能包揽分镜设计、逐镜头代码绘制、自我审片，最终直接渲染输出一支带有水彩晕染、纸张肌理和抖动墨线的 MP4 视频。

这套组合究竟有什么魔力？它又是如何把冷冰冰的几何代码变成充满呼吸感的手绘动画的？

一、 黄金铁三角：它们各自扮演什么角色？

这套工作流的惊艳效果，源于三个核心组件的天作之合：

• p5.js（创意编程的骨架）： 经典的 JavaScript 创意编程库，建立在 HTML5 Canvas 与 WebGL 之上。它负责管理画布、时间轴、物理运动、摄像机推拉以及每一帧的数学计算，让动画里的每一个元素都成为时间的纯函数（Pure function of time）。
• p5.brush（注入灵魂的手绘皮肤）： 由 Alejandro Campos Uribe（@acamposuribe）开发的 p5.js 扩展库。标准的 Canvas 绘图往往带着一股“矢量塑料感”，而 p5.brush 在 WebGL 底层模拟了真实物理笔触——水彩的多层晕染与出血（bleed）、炭笔的颗粒感、马克笔的叠加、钢笔的墨线以及画布本身的纸张纹理。
• Claude Code（懂视听语言的“总导演”）： 以 Claude（尤其是高推理能力的 Opus 模型）为核心的 Coding Agent。相比于让人头秃的 WebGL 坐标转换和参数调试，Claude 极其擅长理解结构化的 API 与空间几何关系。给它一套审美规范与动画法则，它就能直接用代码把分镜翻译成画面。

二、 为什么“代码生成手绘动画”能吊打传统 AI 抽卡？

传统文生视频模型在制作 2D 手绘风格时，常常面临线条闪烁失真、角色跨镜头崩坏、局部细节无法微调等痛点。而 p5.js + p5.brush 的代码渲染管线，精准命中了创作者的核心诉求：

三、 揭秘爆火背后的核心机制：如何让代码“有手绘的生命力”？

这股风潮的引爆点，很大程度上归功于开源项目 ClaudeAnimationBase（由 John Heibel 发起）以及社区随后衍生出的各类 painted-animation Claude Skills。拆解这套工作流的底层设计，会发现它之所以好看，是因为把传统手绘动画的“行业黑话”写进了代码规则里：

1. 灵魂抖动线（Boiling Linework）

传统手绘动画为什么看起来“活”？因为画师每一帧重描轮廓时，手部都会有细微的偏差。在这套引擎中，虽然主画面按高帧率流畅运行，但 p5.brush 的外轮廓墨线被设定为每秒重新随机采样绘制 12 次（利用受控的随机数种子 Seed）。这种微小的笔触抖动，瞬间抹去了计算机图形的冰冷感。

2. 把迪士尼动画法则写进 Prompt 指南

在项目的核心大脑 ANIMATION_GUIDE.md 中，并没有堆砌复杂的算法，而是给 Claude 制定了严格的动画师铁律：

• 角色会演戏： 任何动作不能是匀速平移，必须包含预备动作（Anticipation）、反应（Reaction）和回弹（Overshoot/Settle）。
• 拒绝空镜： 每个镜头都必须有事件发生，镜头切换采用极具手绘感的“画笔刷过（Brush-wipe）”转场。
• 情绪组件化： 比如内置的吉祥物角色 Clawd，提前封装了多角度视图与 31 种生动的戏剧化情绪（眼神、嘴型、肢体微动作），Claude 像搭积木一样调用即可完成细腻的表演。

3. “渲染-看片-自检”的闭环（Render-and-Look Loop）

以前让大模型写前端画图，最大的痛点是模型“看不见”自己画了什么，经常出现元素重叠或跑出画布。
现在的 Claude Code 动画工作流配备了基于无头浏览器（Headless Chrome）的渲染脚本 render.mjs。Claude 写完一个镜头的代码后，会先自动渲染出一张缩略图印样（Contact Sheet / Frame Strip），用自己的多模态视觉能力“看一眼”画面构图和动作连贯性，发现穿模或构图不佳就自己改代码，全部审核通过后，才调用 ffmpeg 合成最终的 MP4 视频。

四、 从零体验：如何用 Claude 跑通你的第一支手绘短片？

如果你想立刻上手体验这套丝滑的工作流，只需要准备好本地环境（Node.js、Google Chrome、ffmpeg 以及 Claude Code）。

第一步：拉取开源脚手架或安装 Skill
你可以直接克隆原版基础库：

1
2

git clone https://github.com/JohnHeibel/ClaudeAnimationBase.git
cd ClaudeAnimationBase

或者在支持插件生态的环境中，直接安装社区封装好的手绘动画 Skill（如 opus-video-skills 中的 painted-animation 或支持配乐对齐的 hiapi-hand-painted-animation-skill）。

第二步：用自然语言向 Claude 下达导演指令
在项目目录下启动 claude，直接输入你的创意：

“先阅读 ANIMATION_GUIDE.md，然后帮我制作一支 15 秒的手绘短片：Clawd 在开满野花的草地上试图抓一只蝴蝶，结果扑了个空摔倒，蝴蝶最后停在了它的鼻尖上。”

第三步：见证全自动片场运转
接下来你只需要喝杯咖啡，看着终端里的 Claude 自动完成以下流水线：

1. 编写分镜脚本（Storyboard）： 规划 3~4 个镜头的景别、时长与情绪转折。
2. 编写镜头代码： 调用 p5.brush 的水彩笔刷涂抹背景与天空，用墨线勾勒角色与草地。
3. 自检与微调： 生成分镜预览图，自我检查色彩层次与角色位置。
4. 渲染输出： 将序列帧编码输出为 out/video.mp4。

测试效果，使用 Claude Code 耗时 33 分钟，模型为 Claude Opus 5.5 xhigh，等价 API 费用 $6.78，成品：

1
2
3

Total cost:            $6.78
Total duration (API):  22m 47s
Total duration (wall): 33m 15s

硬件小贴士： p5.brush 的水彩晕染（Watercolour fills）在底层需要进行大量的多边形与混合计算。如果没有独立显卡（使用核显渲染），单帧渲染可能会需要几秒钟。你可以在 Prompt 里提醒 Claude：“在核显上运行，请尽量用平涂加排线（Hatching）替代大面积重度水彩晕染以加快渲染速度。”

五、 写在最后：程序化生成艺术的文艺复兴

p5.js 与 p5.brush 并不是今天才出现的新技术，但 Claude Code 的成熟，彻底抹平了创意编程那道陡峭的数学与 API 门槛。

它向我们展示了一种全新的 AI 创作范式：AI 不一定非要直接接管最终的像素生成；当 AI 成为连接人类审美意图与确定性图形引擎（Procedural Engine）的桥梁时，我们既拥有了大模型的无限创意，又夺回了作为创作者对每一根线条、每一帧节奏的绝对控制权。

无论你是想做独立音乐的卡点歌词 MV、科普视频的趣味手绘插画，还是单纯想把脑海里的小故事变成动画，现在，你的代码编辑器就是最棒的水彩画板。

提到 AI 生成视频，大多数人的第一反应是基于扩散模型（Diffusion）的像素级渲染——输入一段提示词，等待几分钟，然后祈祷生成的画面里人物手指数量正常、文字没有扭曲成乱码。在影视特效或实景空镜领域，像素生成确实惊艳；但在动态图形设计（Motion Graphics, MG）、技术科普动画以及叙事型绘本视频中，设计师和创作者真正需要的是精准的排版、丝滑的缓动曲线（Easing）、清晰的矢量线条，以及随时可微调的分镜结构。

近期在 GitHub 上走红的两个开源项目——mg-styles-15 与 hand-drawn-storybook-animation-skill——展示了一条截然不同的技术路线：可编程动态视频（Programmable Motion Video）。它们不再让大模型去“猜”每一帧的像素，而是通过封装完善的 Agent Skill 与提示词工程，让大模型直接编写前端与图形代码，在浏览器中实时渲染出达到商用和叙事水准的完整动画。

这些 Skill 除了 Opus 5.5 ，其他模型也可以使用，不过效果将因模型而产生差异，可以用于对比不同模型的能力。

一、 为什么“代码生成视频”正在成为新范式？

在传统的动画制作流程中，哪怕是一个 10 秒的片头或几分钟的科普绘本，也需要经历写脚本、画分镜、矢量绘图、AE 关键帧绑定、配音对齐和合成剪辑。而用传统文生视频大模型来做这类内容，往往会遇到三大痛点：

1. 文字与排版失控：无法精准渲染中英文标题、数据图表或 UI 界面。
2. 黑盒不可编辑：如果客户或自己觉得第 3 秒的某个元素颜色不对、节奏慢了半拍，只能重新抽卡，无法像改代码一样精准微调。
3. 音画脱节：生成的画面没有底层时间轴逻辑，配乐、音效与动效卡点全靠后期手动硬凑。

而 LLM + Agent Skill（技能包） 的思路，则是将专业动画师的审美规范、物理运动规律、分镜逻辑和音频合成 API 封装成标准化的上下文规则。大模型化身全栈动画工程师，直接调用 Canvas、SVG、WebGL 以及 Web Audio API，把“想法”编译成可交互、可录制、可二次修改的动态视频。

三、 两大标杆开源项目深度解析

这三个项目恰好代表了“代码生成视频”从高燃视觉片段到垂直绘本工作流，再到全能型微电影制片厂的完整生态演进：

1. mg-styles-15：15 种商用水准 MG 风格的“提示词与源码字典”

15 种 MG 动态设计风格，每种一支 10 秒成片，全部由 Claude Opus 5.5 写代码做出来。

Vincentwei1021/mg-styles-15 是一个极具视觉冲击力的展示与开源库（配套在线预览站：vincentwei1021.github.io/mg-styles-15）。作者盘点了 15 种达到准商用水准的 MG 动画风格，每支 10 秒的成片完完全全由 AI 根据一段提示词编写代码生成。

视频预览地址：https://vincentwei1021.github.io/mg-styles-15/

更硬核的是，这些片子不仅画面与动画由代码驱动，连背景配乐和卡点音效（SFX）也全部由代码合成，没有任何外部素材拼接。项目完整公开了每种风格的成片预览、风格设计说明、完整 Prompt 以及全部源码：

• 多元视觉美学全覆盖：项目中包含逐帧手绘（Frame-by-Frame）、等轴 2.5D（Isometric 2.5D）、扁平矢量（Flat Vector）、线条动画（Line Art）、3D 渲染（3D Render）、形变动画（Shape Morph）、贴纸风科普（Sticker Explainer）以及赛博朋克 HUD（Cyberpunk HUD）等 15 种截然不同的动态视觉语言。
• 提示词即生产力：以往我们让大模型写动画代码，出来的往往是生硬的 linear 位移和单调的色块。mg-styles-15 的核心贡献在于，它展示了如何用精准的设计语言（色彩系统、运动节奏、图层叠加关系、物理回弹约束）去编写 Prompt。你可以直接复制项目中的提示词模板，替换自己的主题文案，立刻复刻出同等质感的宣传片头或产品演示动画。

2. hand-drawn-storybook-animation-skill：在浏览器里“现场作画”的叙事动画工作流

如果说 mg-styles-15 解决了“10 秒高燃视觉怎么写”的问题，那么 lhlGitHub/hand-drawn-storybook-animation-skill 则解决了一个更宏大的命题：如何让一个不会画画、不会剪辑的普通创作者，把一篇故事或科普长文变成一部长达数分钟、有声有色的完整动画片？

这是一个专为 Claude Code 等智能体环境打造的开源 Skill。当你把它挂载到你的大模型工作流中时，AI 不再只是吐出一段静态代码，而是接管了从编剧、原画、分镜导演到后期录音合成的完整管线：

• 真正的“动”——笔触级实时绘制：它不是把一张静态图做简单的平移缩放（Ken Burns 效应），而是在浏览器里一笔一笔把画面实时画出来。结合水彩上色渲染，观众能看到线条生长、色彩浮现的真实手绘过程。
• 电影级分镜与物理翻页：Skill 内部定义了严谨的镜头调度逻辑（推拉摇移、局部特写）以及逼真的拟物翻页效果，转场就像在翻阅一本真正放在桌上的实体水彩绘本。
• 配音配乐一条龙合成：动画的灵魂在于声音。该 Skill 支持自动生成契合故事氛围的背景音乐，并集成了自然流畅的语音合成（如豆包 TTS 旁白）。系统会自动根据每一句台词的时长计算动画节拍，做到旁白念到哪里、画笔就画到哪里，实现严丝合缝的音画同步。
• 极简的集成方式：对于习惯使用 Claude Code 的开发者或创作者，只需将仓库克隆下来，把技能目录复制到本地的 .claude/skills/ 目录下即可一键激活。输入一段故事构想，剩下的分镜拆解、代码编写、音频对齐全部由 Agent 自动闭环。

3. lemo-opuscar：把大模型变成你的“私人微电影制片厂”

如果既想要 mg-styles-15 丰富的风格库，又想要 storybook-skill 的完整叙事与成片管线，那么 lemomo-ai/lemo-opuscar 就是将这两者推向极致的集大成者。

lemo-opuscar 是一个专为 Claude Code、Codex CLI 等编程智能体打造的开源微电影制作 Skill。它在完全不使用任何视频生成大模型的前提下，仅凭代码就构建了 43+ 种可直接复用的电影风格库（更包含扩展的 OPUSCAR 98 全景风格画廊）。“选一个风格，带上你自己的故事，让你的编程 Agent 来当导演”是它的核心设计哲学：

• 三层解耦的“制片厂”架构：为什么 lemo-opuscar 拍出来的代码短片没有“PPT 感”，反而充满电影质感？因为它让 Agent 在动手写代码前，先阅读三份核心指导手册：
  1. DIRECTOR.md（导演手册）：指导 Agent 如何讲故事、把控声音与画面节奏、设计摄影机运动（Camera）、调度角色表演（Performance）以及进行自我质量检查。
  2. TECHNIQUE.md（技术工程手册）：解决底层构建问题，涵盖逐帧渲染（Frame-by-frame rendering）、人声合成、配乐生成与多轨混音（Mixing），最终通过 Node.js、Python 与 FFmpeg 直接在本地输出 1920×1080、24fps 的标准电影级视频文件。
  3. styles/<style>/STYLE.md（美术与听觉设定集）：定义特定风格的视觉笔触与听觉氛围（涵盖油画厚涂 Impasto Oil Painting、手绘水彩、东亚传统美学等 2D/3D 风格），实现“视觉风格高度固定，故事内容完全自由”。
• 交互式导演工作流（Storyboard First）：你只需用自然语言下达指令（例如：“用水彩风格拍一部 45 秒关于我家咖啡庄园的短片，温暖的女声旁白”）。Agent 会在开拍前主动向你确认一次细节与素材偏好，并询问是否需要先看分镜（Storyboard）。如果你选择“是”，它会先用真实的目标风格渲染出关键帧分镜供你审阅，确认无误后再自动耗时 30–60 分钟完成整部成片的逐帧渲染与混音合成。
• 一键插件化安装：支持直接通过 Claude 插件市场安装（claude plugin marketplace add lemomo-ai/lemo-opuscar），也可以直接将 plugin/skills/lemo-opuscar/ 复制到其他编程 Agent 的技能目录中即插即用。

视频风格预览： https://lemomo-ai.github.io/lemo-opuscar/

三、 解剖底层逻辑：一个优秀的“动态视频 Skill”是如何工作的？

把这两个项目放在一起看，我们会发现“大模型制作动态视频 Skill”背后有一套非常清晰的工程架构。如果你也想基于这些项目定制自己的视频生成 Skill，核心在于抓准以下四个层面：

1. 视觉与动效的原语抽象（Motion Primitives）

大模型直接写底层图形代码容易陷入细节泥潭。优秀的动画 Skill 会在指令或脚手架中规范好动效原语——比如强制规定使用特定的三次贝塞尔曲线（Cubic Bezier）而非默认线性过渡；定义好 SVG stroke-dashoffset 的路径生长计算公式；或者预设好噪点纹理滤镜（SVG Filter）来模拟纸张颗粒感与手绘抖动。

2. 时间轴与状态机驱动（Timeline & State Machine）

视频本质上是时间的艺术。在 hand-drawn-storybook-animation-skill 这类长视频技能中，核心架构往往围绕一个主时间轴（Master Timeline）展开。Skill 会指导大模型先将文本拆解为结构化的分镜脚本（Scene JSON），每个 Scene 包含台词、预计时长、镜头运动参数和绘制元素序列，再由前端渲染引擎按状态机顺序驱动播放。

3. 程序化音频合成（Procedural Audio & TTS Alignment）

为什么这两个项目都能摆脱外部剪辑软件？秘密在于将音频也纳入了代码控制：

• 音效与配乐：利用浏览器的 Web Audio API（或 Tone.js 等合成器库），大模型可以通过调节振荡器（Oscillator）、包络（ADSR）和滤波器，用纯代码写出转场嗖嗖声、按键音甚至环境极简旋律。
• 语音驱动时间轴：通过脚本调用 TTS 接口生成音频文件后，先读取音频的精确毫秒数，再反推当前分镜内 SVG 笔触绘制的持续时间（Duration），从而在代码层面彻底消灭“音画不同步”的顽疾。

4. 确定性录制与导出（Deterministic Rendering）

当浏览器里的画面和声音都准备就绪后，配合无头浏览器（如 Playwright / Puppeteer）或画布捕获工具，即可将实时运行的网页捕获并编码输出为高帧率的 MP4 视频文件，直接用于社交媒体发布。

四、 结语：知识传播与个人表达的“动画时代”

过去，把一个复杂的知识点、一段睡前童话或一个产品创意做成动画，是一支专业团队忙活好几周的专利；因此，绝大多数好内容最终只能停留在枯燥的文字里。

mg-styles-15 和 hand-drawn-storybook-animation-skill 的出现向我们证明了：当大模型的能力被结构化的 Skill 驯服后，代码就成了最强大的画笔和摄影机。 mg-styles-15 为我们提供了商业级动态设计的提示词美学标准，而 hand-drawn-storybook-animation-skill 则跑通了从文本到叙事成片的自动化工业管线。

无论你是想为自己的独立产品制作一段抓人眼球的 Promo 短片，还是想把深奥的技术博客转化为通俗易懂的手绘科普视频，都不妨把这两个仓库 Clone 下来，亲手体验一下用 Prompt 和 Skill “编译”出一部动画电影的乐趣。

相关链接：

• mg-styles-15 仓库：https://github.com/Vincentwei1021/mg-styles-15
• hand-drawn-storybook-animation-skill 仓库：https://github.com/lhlGitHub/hand-drawn-storybook-animation-skill

那么，Opus 5.5 生成的高水准动态设计（Motion Design）视频从何而来？答案是程序化生成（Procedural Generation）与无头渲染管线（Headless Rendering Pipeline）。

本文将系统拆解 Opus 5.5 制作视频的底层工程逻辑、7 大核心渲染技术栈、5 个代表性实战案例的架构与 Prompt，并提供一套可直接复用的工业级 XML 提示词框架与自动化工作流。

一、 底层原理：基于时间函数的确定性渲染

传统手翻书动画（Flipbook）的原理是在每一页绘制微小的姿态变化，通过快速翻动形成视觉暂留。代码生成视频在工程上遵循完全一致的逻辑，核心在于构建一个确定性的时间渲染函数（Deterministic Time-step Function）。

整个自动化生成管线分为三个阶段：

1. 状态函数构建：Opus 5.5 编写前端或图形代码，并在全局暴露一个基于时间的纯函数（如 window.render(t) 或 seek(t)）。向该函数传入任意时间戳 $t$（或帧序号），程序即可实时计算出该时刻所有视觉元素的精确状态（坐标、形变、色彩、光影）并完成单帧绘制。
2. 无头浏览器逐帧采样：使用 Playwright 等自动化测试工具在后台启动无头浏览器（Headless Browser），按照目标帧率（如 24 FPS 或 60 FPS）步进调用渲染函数，并将每一帧画面截取为无损图像序列。
3. 音画合成与编码：在音频侧，可通过 Python 的 NumPy 和 SciPy 直接进行数字信号处理（DSP），计算正弦波、方波及包络线来程序化合成鼓点、贝斯、合成器配乐与 UI 音效；最后调用 FFmpeg 将数千张图像序列与音频流混流编码，输出标准 MP4 文件。

二、 视觉渲染技术栈：7 类核心方案选型

无论是原生代码构建还是调用成熟框架，程序化视频的核心都在于渲染引擎的选择。根据目标视觉风格，可将主流方案划分为以下 7 类：

三、 架构拆解与实战：5 大代表性案例剖析

单一技术栈可以独立成片，多技术栈混合则能突破视觉上限。以下通过 5 个典型社区案例，拆解不同风格视频的技术组合与 Prompt 设计工程。

案例 1：16-bit 像素巫师（纯 Canvas 2D 渲染）

• 原作者：@majidmanzarpour
• 成片规格：11 秒无缝循环（单次循环约 5.5 秒），从 Claude 网页端对话生成，耗时约 30 分钟，零外部素材。
• 画面拆解：巫师处于待机呼吸状态 -> 举起法杖，杖头宝石聚拢蓝色螺旋火花 -> 挥杖释放光圈与飞弹（伴随屏幕震动） -> 收招复位。

核心技术实现

1. 低分辨率离屏渲染：所有元素先绘制在逻辑分辨率仅为 128×96 的离屏画布（Offscreen Canvas）上，随后按最大整数倍缩放至全屏，并强制关闭图像平滑（imageSmoothingEnabled = false），确保每个逻辑像素呈现出边缘锐利的方块感。
2. 帧率解耦与网格量化：将角色的法杖角度、手臂高度抽象为参数。主循环以 60Hz 运行，但角色姿态参数通过网格量化限制在每秒更新 8–12 次，还原复古游戏的抽帧动画感；与此同时，粒子与飞弹特效保持 60 FPS 更新，保证视觉流畅度。

复刻提示词（Prompt）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

创建一个独立的单 HTML 文件，用原生 JavaScript 和 Canvas 2D 渲染一个正在施法的像素风巫师动画。不使用任何外部素材、库或网络请求。

渲染
- 所有内容先画在一块逻辑分辨率固定为 128×96 的离屏画布上，再按能放进窗口的最大整数倍放大，画到全屏的显示画布上，居中，设置 imageSmoothingEnabled = false 和 CSS image-rendering: pixelated。
- 所有绘制都对齐到逻辑画布的整数坐标。不要亚像素位置、抗锯齿、渐变和 shadowBlur。
- 固定调色板，大约 24 个颜色：夜空用深蓝和深紫，长袍用暖色，再加 3–4 个明亮的魔法色。每一个像素都必须来自这个调色板。

角色
- 用填充矩形和一串串像素程序化地搭出巫师，大约 24×32 个逻辑像素：带弯折的尖顶帽、长胡子、双色长袍加深色描边、杖头有宝石的法杖。
- 把姿势做成参数（法杖角度、手臂抬起高度、头部倾斜、长袍摆动）。参数平滑变化，但每一帧都量化到像素网格上，这样虽然循环以 60fps 运行，动作看起来却像每秒 8–12 张的像素动画。

动画
- 循环状态机：待机（两帧上下晃动、胡子摆动）→ 蓄力（法杖举起、宝石闪烁、火花螺旋着向内聚拢）→ 施法（一道强光爆发，飞弹横穿画面，屏幕震动 1–2 像素）→ 收招（回到原位）。关键帧之间的姿势参数用缓动过渡。
- 粒子系统预先分配好、循环复用，不产生新对象。蓄力时火花围着宝石转，施法时向外炸开，每个粒子消失前从白色经过魔法色变成深色。画粒子时位置对齐到像素网格。
- 用固定的 60Hz 时间步长更新，用 requestAnimationFrame 渲染。循环里不产生任何新对象。

场景
- 极简背景：深色夜空、几颗闪烁的 1 像素星星、月亮、石头地面。角色的剪影必须清晰可辨。
- 宝石给巫师打一圈 1 像素的轮廓光，蓄力和施法时变亮。

质量标准
- 任何窗口大小下像素都清晰，无缝循环，稳定 60fps，剪影清楚。看起来要像一段精致的 16-bit 游戏角色动画，而不是缩小了的矢量图形。

案例 2：丝滑 UI 连续形变（HTML/CSS/SVG + 物理弹簧 + 节拍同步）

• 原作者：@twoclipping
• 成片特征：零 After Effects 介入，纯代码实现 Dribbble 级交互动效。全片一镜到底，单一黑白组件在鼠标光标的真实点击与拖拽下，连续变形为按钮、播放器、滑块、图表、命令面板等 10 余种状态。

核心技术实现

1. 解析式弹簧物理（Analytical Spring Physics）：摒弃生硬的线性过渡与 CSS transition，所有尺寸、圆角变化均由纯时间函数 seek(t) 结合弹簧动力学公式实时计算，甚至将组件的前沿与后沿绑定不同刚度的弹簧，实现移动时的拉伸形变（Stretch & Squash）。
2. 音频节拍网格对齐（Beat-Grid Synchronization）：预先通过 Python（NumPy）对音频进行节拍检测，提取精确的时间戳网格，确保每一次 UI 状态切换与交互音效严格卡在 120 BPM 的节拍点上。
3. 子帧采样运动模糊（Sub-frame Motion Blur）：使用 Playwright 渲染时，针对每一帧进行 4 次高密度子帧截图，再通过 FFmpeg 混合叠加，生成自然的动态模糊拖影。

复刻提示词（Prompt）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

<inputs>
开工前先问我：8–12 个界面状态（按钮、加载、播放器、滑块、开关、标签页、图表、命令面板、通知这些），纯黑白还是加一个强调色，以及一首 120 BPM 左右、可以商用的免版税音乐。
</inputs>

<direction>
Dribbble 级别的界面动效。从头到尾只有一个形状，永远不切镜头：每一个状态都是同一个元素改变尺寸、圆角和颜色变过去，里面的内容在一下短暂的模糊里切换。
一个鼠标光标用真实的点击和拖拽驱动每一次变化。浅暖灰背景，黑白组件，一种干净的界面字体（Geist）。所有动画都用弹簧，最多带一点点回弹。镜头跟着缩放，让每个状态都占满画面。最后一帧和第一帧一样，可以无缝循环。
禁止：弹跳缓动、粒子爆炸、发光、组件上的渐变、粗细不统一的图标、没有动作的空档、任何看起来像模板的东西。
</direction>

<structure>
120 BPM，7 个小节，每一拍都有事情发生。
按钮 → 加载 → 对勾 → 灵动岛 → 音乐播放器（播放和暂停图标互相变形）→ 拖动进度条 → 变成音量滑块，拖过最大值时被拉长 → 开关踩着节拍翻转 → 开关的圆点变成标签页的指示条 → 标签页展开成一张自己画出来的图表，悬停时出现提示 → 收成 ⌘K 命令面板 → 输入筛选 → 回车 → 通知 → 回到按钮。
</structure>

<build>
1. 一个 HTML 文件，1440×1440。所有样式都在 seek(t) 里由时间算出来：不用 CSS 过渡，不用计时器，帧和帧之间不保存状态。
2. 弹簧用公式直接算。一个值要多次改变目标时，把每一次变化的弹簧叠加起来，这样它始终只由时间决定。
3. 标签页指示条的左右两条边用两个不同的弹簧，前沿先走、后沿后跟，移动的时候会被拉长。开关的圆点也这样做。
4. 拖拽要像真的在拖：光标按住时，数值由光标的位置算出来；松手后从当前位置弹回去。
5. 用 numpy 分析音乐，找出节拍网格，从重拍开始。每一个界面音效都放在对应动作的那一拍上。
6. 用 Playwright 渲染，每帧截 4 张，用 ffmpeg 混合出运动模糊，输出 60 帧的视频。
7. 渲整片之前，每一拍先渲一帧检查，偏离节拍、太挤、看不清的地方先修掉。
</build>

<gotchas>
被镜头缩放的元素、会渲染文字的元素，都不要加 will-change，否则文字会糊。在变形容器里切换的文字，要有自己的进场和出场时间，不然新旧文字会叠在一起。最后一帧要和第一帧完全一样，包括光标的位置和速度，否则循环的时候会卡一下。
</gotchas>

<start>
先问我要输入的内容，写任何代码之前，先把状态列表排在节拍网格上给我看。
</start>

案例 3：电子游戏发展史（Canvas + WebGL 着色器 + Three.js 混合管线）

• 原作者：@prasenx（于 Cursor 中调用 Claude 完成）
• 成片特征：2 分钟史诗级短片，跨越多个游戏世代，全片零外部素材、零音频采样。

核心技术实现

该项目展示了多渲染管线分阶段协同与叠加的能力：

• Canvas 2D：负责绘制早期 8-bit / 16-bit 像素世代的游戏画面。
• WebGL 着色器（Shader）：作为后处理层叠加在 Canvas 之上，实现老式 CRT 电视的屏幕弧面畸变、扫描线（Scanlines）与荧光辉光（Bloom）。（注：实测对比 3 秒 90 帧的同一像素片段，纯 Canvas 渲染耗时 7 秒，叠加 WebGL 着色器后渲染耗时增至 48 秒，以算力换取了极高的物理质感。）
• Three.js（3D）：负责渲染 1993 年之后的 3D 游戏世代（如走廊射击、立体城堡、体素方块世界）。
• Python 音频合成：纯代码编写合成器配乐，并驱动画面剪辑节奏。

复刻提示词（Prompt）

该案例证明了在 Agent 编程环境（如 Cursor / Claude Code）中，极简的高层意图指令同样能激发 Opus 5.5 的自主工程规划能力：

1
2
3
4

做一条 2 分钟的电影感视频，讲电子游戏的历史，要史诗、要动人，像一部纪录片预告片，全力以赴。
配乐你自己写，完全用代码合成，不要采样，不要音频文件，不要虚拟乐器。画面要跟着音乐剪。

1920x1080，60 帧。不要下载任何图片或素材，每一帧都用代码生成。最后把画面和音乐混在一起，渲染成 MP4，保存到【你指定的位置】。

案例 4：甜酷舞蹈混剪（AI 视频模型生成主体 + 代码合成特效）

• 原作者：@Gorden_Sun
• 核心痛点与破局：纯代码擅长几何、排版与特效，但难以直接绘制写实人物与复杂舞蹈动作。最佳实践是采用混合管线（Hybrid Pipeline）——将写实人物交给生成式视频模型（如 Grok、Flova 等），将后期包装、场景搭建与卡点动效交给 Opus 5.5。

核心技术实现

以一段 15 秒的绿幕女孩跳舞视频（由 Grok 生成）为输入源，Opus 5.5 通过代码自动化完成了原本需要剪映或 After Effects 处理的三大后期工程：

1. 色度键控抠像（Chroma Keying）：通过像素级颜色阈值算法剥离绿色背景，提取纯净的人物前景图层。
2. 多维场景与包装合成：使用前端代码在人物底层与顶层绘制动态背景、巨型排版文字、警戒胶带装饰、多画面分屏以及 3D 环绕字幕。
3. 音乐节拍驱动剪辑：人物原片保持连贯播放，背景色彩切换、大字冲击与分屏动效严格对齐音乐节拍。

案例 5：从 Transformer 到 AGI（基于 Remotion 的 3 分钟叙事长片）

• 原作者：@kimmonismus
• 成片特征：在 Claude Code 中使用约 7400 行 React / TypeScript 代码（基于 Remotion 框架）构建的 3 分钟科普短片。融合了 SVG、Canvas、开源 TTS 语音模型与 Python 合成配乐，具备 Kurzgesagt 式的视觉叙事水准。

复刻提示词（Prompt）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

你是一位动态设计师兼创意总监，正在制作一部 3 分钟的动画短片，完全用代码搭建，最后渲染成 MP4。

这部片子
标题：「Attention Is All You Need → AGI」
讲的是 2017 年的一篇论文，怎样一步一步引出了大语言模型、推理、会用工具的 AI 智能体，以及 AGI 这个还没有答案的问题。它应该像一篇有电影感的影像随笔，而不是幻灯片或者时间线信息图。可以想象成 Kurzgesagt 遇上皮克斯电影的开场：有情绪、聪明、精准。

技术设置
用 Remotion（React）。新建一个项目，1920×1080，30fps，时长正好 180 秒（5400 帧）。
每个场景一个 composition，在一个主 composition 里按顺序排好。
不用任何外部图片素材或现成视频：所有东西都用 SVG、Canvas、CSS 和代码生成的粒子、形状来画。可以用 Google Fonts。
动手之前，先写一份 STORYBOARD.md，写清楚每个场景的时间、画面、屏幕上的文字和转场。然后一个场景一个场景地做。
每做完一个场景，渲染 3–4 张静帧（npx remotion still），用挑剔的眼光看一遍。先修好排版、重叠、可读性和节奏，再做下一个。
最后用 npx remotion render 输出到 out/film.mp4。给音乐留一个可选的 <Audio> 位置（public/music.mp3），我之后再加；如果文件不存在，就渲染无声版。

叙事主线 / 贯穿全片的母题
主角是一个会发光的词元，也就是单词「the」，它穿过每一个时代。2017 年，它是一个孤独的光点，突然通过注意力连线「看见」了所有其他单词。随着时间推移，它有了声音、感官（多模态）、推理能力、双手（工具），最后，有了一个问题。

场景（时间是大概的，你可以重新分配）
0:00–0:15 冷开场。一片黑暗。单词像星星一样散落，彼此不相连。RNN 式的逐个处理：单词一个接一个亮起，慢慢忘掉前面的。
0:15–0:35 2017 年 6 月，「Attention Is All You Need」（Vaswani 等人，Google）。每个单词同时连到其他所有单词。注意力连线绽放成一张网。论文标题像排版印刷一样出现。
0:35–0:55 2018–2020：大语言模型崛起，GPT-1、BERT、GPT-2、GPT-3。规模定律：这张网指数级增长，镜头往后拉。模型开始补全句子，流畅得有点诡异。
0:55–1:20 2022：指令微调和 RLHF，然后是 ChatGPT（2022 年 11 月 30 日）。词元有了一个聊天气泡。用户数计数器爆炸式增长。世界开始跟它对话。
1:20–1:40 2023：多模态。图像、音频和代码从四面八方流进同一张网，词元有了「感官」。每一种模态都变成词元，流过同一个注意力机制。
1:40–2:05 2024–2025：推理模型。一条看得见的思维链展开，分叉、剪枝、回溯。模型「先想再说」，时间变慢。
2:05–2:30 工具使用和智能体。词元长出了双手：它调用搜索、运行代码、打开文件，调度子智能体。很多条线程同时工作，屏幕变成一个忙碌又漂亮的工作室。
2:30–2:50 走向 AGI。所有母题汇合。2017 年的那张网重新出现，但现在是星球尺度。保持开放：不要乌托邦，也不要末日。屏幕上写：「Attention was all we needed. What comes next is up to us.」（如果你能写得更好，就改进这句话。）
2:50–3:00 回到黑暗中一个发光的词元。片名卡，结束。

制作规则
准确性很重要：年份、人名、论文标题都要正确。对某个具体事实没把握时，宁可不写也不要猜，并把所有不确定的说法列在 NOTES.md 里。
文字排版：屏幕上同时最多约 8 个单词，每段文字停留时间要够读完（至少 2.5 秒）。用一种展示字体，再用一种等宽字体表示「模型输出」。
动效：用弹簧和缓动曲线，不要线性运动。场景之间的转场要从内容里长出来（网络变形、镜头穿过一个节点），不用通用的淡入淡出。
颜色：深色背景，加一个暖色强调色，这个强调色随着时代慢慢变化。
细节和彩蛋留给认真看的人（比如真实的论文片段、小小的界面细节、看起来可信的模型输出），像高水准的动态设计作品那样。
节奏：密集和平静的时刻交替，给推理那一场和 AGI 那一拍留出呼吸的空间。

全程自主完成整条流程。做完以后，告诉我 MP4 的路径、一段简短的创作决策总结，以及 NOTES.md。

四、 提示词工程：如何用 XML 结构实现工业级稳定出片

在社交媒体上，常见一种“炫技式”的一句话提示词（例如：“做一条 15 秒的动态图形视频，展示你作为动效设计师的最高水平，全力以赴”）。这类提示词适合测试模型的创作上限，但缺乏可控性，无法直接应用于自媒体生产、产品商业广告或特定叙事短片。

对比社区内的高质量可控作品可以发现，最稳定的工程实践是遵循 Anthropic 官方推荐的 XML 标签结构化提示词。将角色设定、输入参数、艺术指导、分镜结构与构建规范封装在独立的 XML 标签中，能够彻底消除上下文混淆。

核心方法论：通过 <direction> 的“负面清单”打破模型默认惰性

在缺乏明确约束时，Opus 5.5 极易退化回其训练分布中最常见的“平庸默认风格”：深色渐变背景、居中大字标题、全局统一淡入淡出（Fade-in/out）、线性匀速运动。

要获得具备高级设计感的成片，必须在 <direction> 标签中明确列出负面约束（Negative Constraints），例如明确禁止：弹跳缓动、廉价粒子爆炸、组件发光（Glow）、渐变填充以及模板化的布局。

通用工业级视频生成 Prompt 模板

以下模板整合了分镜确认、静帧自检、纯函数渲染与波形防爆音检查，可直接复制用于商业或自媒体视频生产：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

<role>
你是一位动态设计师，也是一位创意程序员，擅长用代码做出有设计感的视频。
</role>

<inputs>
开工前先问我这几件事，我没给的不要自己编：
1. 主题，以及看完以后希望观众记住的一句话：【你的主题】
2. 时长和画幅：【30】秒，【1920×1080 / 1080×1920 / 1080×1080】，【30 / 60】帧
3. 风格：【像素 / 扁平插画 / 界面动效 / 彩铅手绘 / 复古电视 / 3D】，有参考视频或截图就发给你
4. 配色和字体：【主色 #颜色】，【字体】
5. 声音：【我提供的音乐文件 / 用代码合成配乐】，要不要配音：【要 / 不要】
</inputs>

<direction>
整片只用一套风格、一套配色，同一个角色或元素在每个镜头里的样子都要一致。
每个镜头只讲一件事，画面上的字少而大，每段文字至少停留 2.5 秒。
动画用缓动或弹簧，不用匀速运动。转场从画面内容里长出来，比如一条线变成下一个场景的地平线，不用默认的淡入淡出。
镜头要跟着内容动，推近、拉远、跟随，让主体在画面里足够大。
禁止：【居中大字加渐变背景的默认风格、所有元素同时淡入、满屏小字、任何看起来像模板的东西，按你的情况补充】
</direction>

<structure>
先写分镜表，每个镜头写清楚：
镜头 [N]｜[开始–结束秒]
画面：构图、元素、文字
动作：进场、主要动作、出场
镜头：推、拉、跟随还是固定
声音：这一段的音乐和音效
转场：怎么过渡到下一个镜头
如果有音乐，先分析节拍，镜头切换和关键动作都落在拍子上。
</structure>

<build>
1. 画面用【Canvas 2D / HTML+CSS+SVG / WebGL 着色器 / Three.js / Remotion / HyperFrames】来做，不用外部图片和素材。
2. 页面暴露 window.render(t)，画出第 t 秒。所有画面只由 t 算出来，随机数带固定种子，不用计时器，帧和帧之间不保存状态。
3. 用 Playwright 逐帧调用 render(t) 并截图，再用 ffmpeg 合成 MP4。
4. 配乐和音效用 Python（numpy、scipy）从零合成，每个音效放在画面动作发生的那一帧上；有配音的话，整段合成，不要一句一句拼。
5. 每做完一个镜头，先渲 3 张静帧自己检查：文字有没有溢出、元素有没有重叠、画面够不够满，修好了再做下一个。
</build>

<gotchas>
- 字体加载完再开始截图，不然前几帧会用默认字体。
- 用了 WebGL 的话，先渲一帧确认着色器真的生效了，再渲整片。
- 你听不到声音，所以要把音频的波形画成图自己检查，确认没有爆音。
</gotchas>

<start>
先问我 inputs 里的问题，然后给我分镜表，等我确认。再渲 3 张关键帧让我看风格，确认后再渲整片。
</start>

五、 工程化进阶：Agent Skill 自动化与质量控制（QA）

在高频生产场景中，手动维护长提示词依然存在效率瓶颈。通过引入 Claude Code 的 Skill 机制、全局规范文件（CLAUDE.md）与多模态视觉自检闭环，可将工作流升级为全自动管线。

1. 部署开源自动化工作流：xilo-opus-video

社区已将上述完整的制作规范封装为开源 Agent Skill。在支持 Skill 的终端或客户端中，直接向 AI 发送以下指令即可完成部署：

1

帮我安装这个 Skill：[https://github.com/Kianzzz/xilo-opus-video](https://github.com/Kianzzz/xilo-opus-video)

该 Skill 激活后将自动接管以下标准作业程序（SOP）：

1. 多源需求解析：支持输入文本创意、文章链接、产品 URL 或参考视频。若提供参考视频，Agent 会自动抽帧分析其分镜与剪辑节奏；若提供背景音乐，则先行运行节拍检测算法。
2. 差异化提案生成：输出 3 套在视觉风格、底层代码技术栈、分镜设计与预估渲染耗时上显著区分的方案。
3. 关键帧/小样预览：为每个方案渲染静态关键帧（或数秒的动效小样），实现“所见即所得”的方案决策。
4. 分步实施与自检交付：方案确认后自动生成包含 7 大 XML 模块的 brief.md，逐镜头编码并抽帧自检，最终完成多维度打分迭代（全项达 8 分以上）后交付成片。

2. 提升出片质量的 3 个工程技巧

技巧一：拉满推理思考强度（Thinking Effort）

程序化动画涉及复杂的空间坐标计算、缓动函数推导与时间轴对齐。在生成效果不理想时，优先在配置中将模型的推理预算（Thinking Budget / Effort）调至最高档位。

技巧二：配置项目级持久化规范（CLAUDE.md）

在工作区根目录下创建 CLAUDE.md 文件。Claude Code 每次启动会话时会自动加载该文件作为全局系统上下文，无需在单次对话中重复强调基础规范：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# 视频制作规矩
## 渲染
- 每一条视频都只由时间决定：window.render(t) 画出第 t 秒。
- 不用 CSS 动画、不用计时器，帧和帧之间不保存状态，随机数带固定种子。

## 画面
- 禁用的默认风格：居中大字加渐变背景、所有元素一起淡入、角落里的标签和边框、界面上的发光。
- 一种标题字体、一种正文字体，除非我另外说明，只用一个强调色。
- 每 2–4 秒画面上要有新东西出现。

## 声音
- 没有给音乐的话，配乐和音效都用代码合成，放在节拍上，响度 -14 LUFS。

## 给我看之前
- 先出抽帧图，自己打分，把最严重的 3 个问题改掉，每一项都到 8 分以上再给我看。

技巧三：建立多模态抽帧自查闭环（Self-Correction Loop）

利用 Opus 5.5 强大的视觉理解能力，让其在完成初步渲染后，将视频拆解为网格静帧图并切换至“严苛的动效导演”视角进行自我审查。可直接复用以下自检 Prompt：

1
2
3
4
5
6
7
8

检查视频，先完成抽帧处理，然后站在严格的动效导演视角，专门挑毛病，别替自己说好话。
按下面几项各打 1–10 分：前 2 秒抓不抓人、缩到手机屏幕大小还看不看得清、动作是否自然（有没有匀速滑动、有没有卡住不动的空拍）、画面变化是否足够（每 2–4 秒要有新东西）、构图、声音和画面是否对得上。

列出最严重的 3 个问题，标上时间点。重点找这几类：切换时文字叠在一起、居中大字加渐变背景的默认画面、角落里多余的标签和边框、缩放以后变糊的字、循环接缝处的卡顿。

列出以后重新渲染有问题的部分，再出一张新的抽帧图和新的分数。

重复这个过程，直到每一项都在 8 分以上。

六、 延伸阅读与开源生态参考

Opus 5.5 并非视频生成模型，但其顶尖的代码架构能力与视觉审美先验，使其成为了极具潜力的“程序化动态设计引擎”。如需进一步探索底层源码与提示词范式，推荐参考以下开源仓库：

• **athemeroy/awesome-opus-5-5-videos**：收录了 1000+ 条由 Opus 5.5 生成的视频案例，并详细标注了每条作品对应的渲染技术栈与实现路径。
• **guanmo-ai/awesome-ai-motion**：中文 AI 动效案例精选集，附带原作者完整 Prompt 与原始出处链接。
• **JohnHeibel/ClaudeAnimationBase**：基于 p5.js 与 p5.brush 构建手绘卡通动画的标准化工程脚手架。
• **JohnHeibel/PDoomVideo**：一支完整音乐 MV 的全量工程源码，适合深入研究长视频的代码目录组织与状态管理模式。

X 博主 Seeco 花了一整周时间把这些爆款视频逐一拆解。其中确实有几个是从 30 个词的简单提示词开始的；但真正惊艳的作品，背后往往是一份 9,500 字符的详尽需求文档（Brief）、一个 Skills 文件夹、两个 API 密钥，以及在作者睡觉时连续跑了 12 个小时的自动化流水线。

这篇文章将把这套工业级工程底座拆解开来，一步步带你搭建完整工作流，让你做出的第一个作品就摆脱“满大街同款 Demo”的廉价感。

核心速览 (At a Glance)

1. 帧函数（Frame Function）：Opus 只写代码，由无头浏览器将其转化为视频帧。
2. 工程底座（The Rig）：10 分钟搭好 Claude Code + FFmpeg + 无头浏览器。
3. 需求文档（The Brief）：用严谨的制片规范代替模糊的“感觉（Vibe）”。
4. 视觉参考（The Reference）：借用成熟的视觉语法，跳出模型的默认审美。
5. 状态列表（State Lists）：用单一容器的连续丝滑形变，干掉生硬的十几个特效转场。
6. 弹簧与音效（Springs & Sound）：赋予运动物理质量感，让音频与画面共享同一个时钟。
7. 视觉质检（The Critic）：让 Opus 审视自己生成的分镜缩略图（Contact Sheet），打分并修复最差的 3 处。
8. 封装技能（The Skill）：将整套管线打包，让下一支视频真正变成“一行命令”。

1. 帧函数：为什么 Opus 写的是程序而不是直接输出视频？

Opus 5.5 本身并不能直接输出 .mp4 文件。你在信息流里看到的每一段视频，本质上都是它写出的一个前端程序，再由外部工具把程序运行画面截成图片序列、最后合成视频。

整个体系的核心机密，在于一个只回答单一问题的纯函数：

1

seek(t) -> 精确绘制屏幕在第 t 秒时应该呈现的画面

对于一段 15 秒、60 fps 的视频，无头浏览器会调用这个函数 900 次，逐帧截图，最后交给 FFmpeg 拼接成视频文件。

• 无定时器驱动（Nothing runs on a timer）：正因为不依赖实时定时器，第 240 帧可以直接独立绘制，而无需从第 0 帧回放到第 239 帧。如果某个标题入场太早，只需改一个数字并局部重渲染即可。
• 默认技术栈倾向：如果不加干预，Opus 默认会走“零依赖路线”——单个 index.html + Playwright 逐帧截屏 + FFmpeg 编码。Tommy Rossi 发现，即便环境里安装了 Remotion 或 HyperFrames，Opus 默认也会跳过它们。因此，如果你想用特定框架，必须在提示词中明确点名。
• 代码渲染的边界：
  • 劣势领域：真实感摄影场景、复杂角色动画、自然的有机运动（这些依然需要实拍素材或传统视频生成模型）。
  • 统治级优势：产品宣传片、UI 动态交互、数据可视化故事、动态排版（Kinetic Typography）以及发布解读视频。

2. 工程底座：为什么只用网页版聊天窗口只能做出“平庸之作”？

网页版聊天应用能写出动画代码，但只有具备 Shell 权限的 Agent（如 Claude Code），才能真正把视频渲染出来、“听”到音频，并亲眼“看”到自己渲染出的画面帧。

有没有这个自我反馈闭环（Feedback Loop），就是全网爆款视频与普通玩家口中“感觉也就那样（a bit mid）”之间的根本分水岭。

10 分钟环境搭建

1
2
3
4
5
6
7
8
9
10
11
12
13

# macOS 使用 brew，Linux 请使用 apt
brew install node ffmpeg python
pip install numpy librosa soundfile

mkdir motion-studio && cd motion-studio && npm init -y
npm i -D playwright && npx playwright install chromium

# 可选：引入专业框架 Skills
npx skills add remotion-dev/skills
npx skills add heygen-com/hyperframes

# 启动 Claude Code
claude --model claude-opus-5-5

接着，在项目根目录下放一个 CLAUDE.md。Claude Code 每次运行时都会自动读取它，你的“制片厂铁律”就无需在每次对话中重复：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

## Render contract (渲染契约)
- window.seek(t) 唯一负责绘制第 t 帧画面，严禁任何其他机制驱动画面变化
- 渲染模式下严禁使用 CSS transitions、setTimeout 或 requestAnimationFrame
- 只能使用带种子（seeded）的噪声函数，严禁使用 Math.random()

## Look (视觉规范)
- 严禁出现：渐变背景上的居中大标题、所有元素无脑淡入（fade in）、角落小标签、UI 泛光特效（glow）
- 字体限制：严格限制一种展示字体（Display Face）、一种界面字体（UI Face）、一种强调色（Accent）
- 节奏要求：每 2 到 4 秒屏幕上必须出现新的视觉信息

## Sound (音频规范)
- 除非提供了外部音轨，否则配乐与音效（SFX）必须通过代码合成，响度统一标准化为 -14 LUFS

## Before you show me anything (交付前自检)
- 每个节拍（beat）抽一帧拼成缩略图样片（Contact Sheet），自我打分，并自动修复得分最低的 3 处问题

算力档位（Effort Settings）：Opus 5.5 默认运行在 medium 档。所有出圈的“一镜到底”神作，跑的都是 xhigh 或 max 档。 经验法则是：局部小修小补用 medium，制作新片用 xhigh，而当视频前 3 秒直接决定产品发布生死时，果断拉满到 max。

3. 需求文档（The Brief）：为什么“凭感觉写提示词”等于把决定权交给平庸？

如果你只告诉模型：“帮我做一个炸裂的产品视频”，模型就会用它所知道的最安全、最平庸的默认选项填满每一个未知的空白——那个让人审美疲劳的“渐变背景居中大标题”就是这么来的。

当然，那句著名的“一句话提示词”依然有它的测试价值：

1
2

make a dynamic 15-second motion graphics video that shows what an incredible motion designer you are, like it's your showreel for a résumé. go all out.
(制作一段充满活力的 15 秒动态图形视频，展示你作为一名顶尖动态设计师的实力，就像你简历里的个人作品集一样。全力以赴。)

• 为什么这句话有效？ “Showreel（作品集）”直接给 Opus 限定了一个规则成熟的影片类型；让模型展示“它自己”，意味着不存在理解错产品业务逻辑的风险；15 秒刚好容纳 6 到 8 个镜头；而“go all out”则在 xhigh 之上进一步压榨了模型的表现欲。
• 但仅限于跑通测试：跑一次验证完你的环境就够了。成百上千人发送了这句一模一样的话，结果得到了几百个高度雷同的视频——athemeroy 数据集将这种现象称为“需求传染（Brief Contagion）”。

当你真正要推广一款产品时，在执行任何渲染任务前，Opus 需要一份真正的制片文档（Production Document）。Claude Code 团队的 Thariq 说得很直接：推文上写着“One-shot”，背后的提示词足足有 10,000 字符，还挂载了 Skills、参考示例和 API 密钥。

标准制片文档结构

1
2
3
4
5

FILM      观众看完后记住的一句话核心信息、目标受众、时长、输出画幅格式
ASSETS    真实 Logo、真实 UI 截图、品牌标准字体与色值、音频文件
VISUAL    从参考片中汲取什么元素、绝对要避开哪些陈词滥调（Clichés）
HARD LINE 底线红线：严禁捏造虚假的产品界面或业务数据指标
DELIVER   交付物清单：故事板、分镜缩略图（Contact Sheet）、最终成片、封面帧、完整源码

• Tony Dinh 的 TypingMind 宣传片：他只多加了三行关键信息——产品网址、要求使用真实截图/Logo/品牌资产、以及“必须有配乐”。Opus 自己访问了网站，自动抓取了所有素材，不到 30 分钟就完成了整支视频。而在一年前，找外包机构做一支类似的发布视频花了他大约 1,200 美元。
• Rob Hallam 的连续创作经验：在做完第一支作品集后，他在同一个会话窗口里要求制作一支产品广告，结果生成速度快得多——因为渲染器、音频合成器和导出管线都已经存在于上下文中了。建议：每个品牌固定维护一个专属会话（Session）。
• 密钥安全：把 API Keys 放在 .env 文件中，在提示词里只通过变量名引用（achxvi 在公开他的 Pocketsflow 提示词时，就专门用了一个搞笑占位符来隐藏真实密钥）。

4. 视觉参考（The Reference）：如何打破“千篇一律”的模型味？

如果不提供视觉语法（Visual Grammar），Opus 就会套用它自带的默认语法，导致完全不相干的产品视频看起来像失散多年的亲兄弟。

Rexan Wong 在研究了数十个爆款切片后发现了一个规律：直接点名某种风格，远比用形容词描述一种风格有效；而直接给出一张参考帧或一段参考视频，则能瞬间把节奏、字体排版和转场逻辑全盘托出。

最管用的三种参考素材：

1. 你钟爱的某支视频里的单张静帧；
2. 一段由 Opus 调用 FFmpeg 自动抽帧分析的短视频切片；
3. 你自己过往作品的本地文件夹（例如 Pleometric 的 TikTok 风格短片就是从另一个爆款动画的单帧衍生出来的；而他的 Donald 风格短片则直接指向了他私人的 PC-98 艺术画廊——这是一个别人绝对无法复刻的独门素材库）。

视觉参考提取工作流提示词

1
2
3
4
5
6

Reference: ./refs/launch.mp4
1. 使用 ffmpeg 每 0.5 秒提取一帧画面，并仔细研究它们
2. 编写 docs/style_guide.md：包含十六进制色板（Hex）、字体排版、镜头时长分布、转场方式、运镜逻辑、颗粒感（Grain）
3. 编写 docs/shotlist.md：按照上述风格，为关于 [SUBJECT] 的 [DURATION] 秒视频编写分镜表
4. 只提取视觉语法，严禁照搬参考片中的具体主体、Logo 或文案
5. 将这两个文件展示给我，在我确认 OK 之前，不要编写任何代码

• 真实资产核验：制作产品视频时，可以让 Opus 直接从线上网站抓取真实界面，但你必须亲自审核这份资产清单。如果缺少某张关键截图，Agent 应该停下来向你索要，而不是自己画一个看着很像的假界面。
• 把技术选型留给模型：Pleometric 曾建议模型使用 p5.js，结果 Opus 自己手写了一个专属的纸张质感渲染器，效果反而更好。你只需明确视觉效果和边界限制，具体的技术实现让模型自己决定。
• 去哪里找优质参考片？：whatships.com（专门收集优质产品发布视频）、Dribbble Motion 板块、以及你竞争对手的发布会视频。

5. 状态列表（State Lists）：为什么“一镜到底的连续形变”秒杀十个花哨特效？

“放大、变形、加粒子特效”——这叫动作清单（List of Activity），不叫故事。真正的故事板（Storyboard）定义的是观众在每一秒建立的认知：

1
2
3
4
5

00-02s  HOOK (钩子)     一个瞬间抓人眼球的画面，赢得注意力
02-05s  PROBLEM (痛点)  把用户遇到的阻碍与摩擦直观呈现在屏幕上
05-09s  REVEAL (揭晓)   通过一次真实的交互操作，自然引出产品
09-13s  PROOF (证实)    用一个真实界面或核心数据支撑你的主张
13-16s  CLOSE (收尾)    干净利落的定格状态 + 清晰可读的行动号召（CTA）

发布周被收藏次数最多的提示词，是一份 XML 规范文档。@twoclipping 的 UI 连续形变视频借此斩获了 90.7 万播放和 1.9 万收藏，而 @verbove 的 MakerMap 产品片也复用了完全相同的结构。

这两支神作背后的核心思想高度一致：全片只有一个主容器，通过不断改变尺寸、圆角半径和颜色，从一个状态丝滑演进到下一个状态；一个鼠标光标通过真实的点击驱动每一次变化；且最后一帧与第一帧完美重合，实现无缝循环播放（Loop）。

1

Logo → CTA 按钮 → 邮箱输入框（伴随打字动画） → 加载动画（Loader） → 成功对勾 → 数据看板（Dashboard） → 图表自动绘制 → 悬浮提示框（Tooltip） → ⌘K 命令面板 → 弹窗提示（Toast） → 回到 Logo

• 每个节拍（Beat）都必须具备三要素：起始状态（Entry State）、结束状态（Exit State）以及它存在的理由。如果 Agent 说不出第 4 个镜头为什么存在，那就直接砍掉第 4 个镜头。
• 剧中剧模式（The Story Version）：NFT_Chen 让 Opus 先用代码写了一个带时间轴、音频波形和导出按钮的“卡通版视频剪辑软件界面”，然后把整支宣传片放在这个虚拟剪辑软件的预览窗里演绎。一个虚拟的 UI 外壳就像一个天然的摄影棚，里面每个元素的状态都清晰可控。

6. 弹簧与音效：为什么廉价的动画一眼就能看出来？

固定缓动曲线（Easing Curve，如简单的 ease-in-out）只是机械地从 A 点滑到 B 点；而具备物理质量感（Mass）的运动，会先加速、越过终点产生微妙的回弹（Overshoot），最后稳稳落定。

解析解弹簧函数（Closed-form Springs）既能提供这种真实的物理质感，又能保持作为时间 $t$ 的纯函数特性，从而确保 seek(t) 的绝对确定性。当一个属性（比如光标位置或容器宽度）需要连续多次改变目标值时，不要重置弹簧，而是为每一次变化叠加一个独立的弹簧脉冲：

$$\text{track}(t) = v_0 + \sum (v_i - v_{i-1}) \times \text{spring}(t - t_i)$$

1

track(t) = v0 + Σ (v_i − v_(i−1)) × spring(t − t_i)

靠这个公式，哪怕直接跳到第 812 帧，也能瞬间算出精确位置，完全不需要从第 0 帧一路物理模拟到第 811 帧。

• 分级赋予物理规则：
  • 小型 UI 控件：干脆利落地吸附，几乎不留回弹；
  • 大面板（Panels）：沉稳落定；
  • 摄像机运镜：极度平滑，让人几乎察觉不到镜头在动；
  • 核心大标题：重重砸下，并保持足够长的静止时间供人阅读；
  • 品牌吉祥物（Mascots）：故意设计明显的Q弹跳跃感。
  • 记住：如果画面里所有东西都在回弹，那就没有任何东西显得精准。

音画同源（Sound on the Same Clock）

声音与画面运行在同一个时间轴时钟上。Rob Hallam 起初以为他视频里的音效是后期加的，结果发现那是直接由代码生成的；@oozn 的乔布斯传记短片更是直接用 Node.js 合成了整条配乐，23 个转场严丝合缝地卡在 120 BPM 的节拍上。

如果你使用的是外部现成音乐，在写动画代码前，先用脚本测量音轨数据：

1
2

# 使用 librosa 提取 BPM、节拍点、重拍（Downbeats）和打击点（Hits）
python beats.py song.wav > beats.json

• 卡点铁律：常规状态切换卡在普通节拍（Beats）上；重磅画面揭示卡在强拍/小节首拍（Downbeats）上；鼠标点击和呼啸转场声（Whooshes）卡在打击音效点（Hits）上。
• 盲听测试（The Blindfold Test）：闭上眼睛只听视频的声音。如果脱离了画面，声音听起来毫无起伏与结构感，说明你的声音设计还没做完。

7. 视觉质检（The Critic）：为什么必须逼 Opus 亲眼检查它渲染的每一帧？

Opus 5.5 具备强大的多模态视觉阅读能力，这意味着它可以亲自检查自己刚刚渲染出来的画面。 几乎所有引爆社交网络的短片，背后都有这个关键动作。

@mablesjoseph 曾坦诚公开过他那支水彩风格短片的幕后数据：总共调用了 163 次模型，耗时近 7 个小时。 Drew 在发布日当天斩获 170 万播放的作品，在成片前也经历了多轮肉眼可见的修正清洗。

不要傻傻地把完整视频导出十遍、从头到尾看十遍。让 FFmpeg 自动生成质检证据包：

1
2
3
4
5

contact sheet (分镜缩略图)  每秒抽 2 帧，每行排 6 张拼成大图
strip (高速运动切片)        在运动最剧烈的片段前后，连续截取 12 帧
phone test (移动端可读性)   将画面缩放到 360px 宽度，检查小屏阅读体验
loop check (循环衔接检查)   将视频首尾相连播放两遍，检查接缝是否顺畅
determinism (确定性校验)    将第 300 帧独立渲染两次，校验文件 Hash 必须完全一致

接着，给 Opus 下达一份带牙齿的严厉质检任务（Critique Task）：

1
2
3
4

只根据实际渲染出的画面帧进行评判，完全忽略你原本“打算”做出什么效果。
按 1-10 分对以下维度打分：前 2 秒吸引力（Hook）、手机端可读性、运动质感、视觉丰富度、音画同步率、品牌还原度。
列出最严重的 3 处缺陷，必须附带精确时间戳、画面证据以及局部修复方案。
仅针对有问题的这几秒打补丁、局部重渲染，循环往复，直到所有维度的得分都达到 8 分以上。

重点抓捕的典型 Bug：文字重叠、该用缓动的地方变成了生硬平移、残留的角落小标签、缩放后模糊发虚的字体、画面毫无动静的“死拍（Dead Beat）”，以及循环衔接处的卡顿跳帧。

8. 封装技能（The Skill）：让你的下一支视频真正只需“一句话”

如果整支视频的决策过程只留在聊天记录里，那你只是撞大运打出了一次好局。把所有工程决策沉淀为本地文件，让下一次运行可以直接读取复用：

1
2
3
4
5
6
7
8

motion-studio/
├── brief.md         # 核心目标与产品事实信息
├── style_guide.md   # 色板、字体、运动规范、严禁使用的默认套路
├── shotlist.md      # 节拍点、状态演进、时间戳、镜头目的
├── assets/          # 经审核确认的 Logo、真实界面截图、音频文件
├── src/             # 支持 seek(t) 的动画组合与核心渲染代码
├── reviews/         # 历次生成的 Contact Sheets 缩略图与缺陷修复记录
└── out/             # 按不同画幅比例导出的最终成片

通宵挂机必备：质量门禁（Gates）

Donald 只口述了五分钟需求就去睡觉了，一觉醒来得到了一支 142 秒的音乐 MV，随后狂揽 210 万播放（他的完整提示词长达约 9,500 字符；而 @pradeepXkapoor 的“Pip”机器人短片更是用了 19,000 字符的巨型 Brief）。

想要放心让 Agent 长时间自主运行，必须设置阶段门禁（Gates）：

1
2
3
4
5
6

GATE 1  参考片与产品真实资产审核通过
GATE 2  视觉规范（style_guide.md）与分镜表（shotlist.md）审核通过
GATE 3  每个镜头的静态关键帧渲染完成，并通过视觉质检
GATE 4  输出 960x540 分辨率的动态分镜预览（Animatic），带上占位音频
GATE 5  全尺寸完整渲染、细节打磨、正式合成音效与配乐
GATE 6  多画幅版本导出、无缝循环检查、提取封面帧、生成 README 文档

在两个门禁之间，Agent 可以连续自主工作数小时。遇到缺失的界面截图会自动作为阻塞项停下提问；遇到不明确的参考风格，会先询问或渲染单张测试帧，而不是闷头渲染出 900 帧精美但方向全错的废片。

• 生成后描摹（Generate-then-trace）：这是 Donald 的核心杀招——先用 Seedance 2.5 生成带有复杂角色和物理规律的基础视频片段，然后让 Opus 用 JavaScript 在其之上逐帧重绘整部影片，最终观众看到的完全是由代码绘制的风格化图层。John Heibel 在 GitHub 上斩获 1.1K Star 的 PDoom 仓库则展示了多子智能体（Subagent）版本：由主 Opus 编写 ANIMATION_GUIDE.md，然后同时指挥多个并行 Worker 分头制作九个章节。
• 多画幅原生适配：每一个宽高比（横屏、竖屏、方屏）都应该从同一条时间轴代码中原生计算得出，绝不能靠简单粗暴的画面裁剪（Crop）。竖屏版自动放大字号、减少同屏元素；方屏版收紧停顿节奏；宽屏版则展示更多空间上下文。

当你把以上所有流程打包封装成一个 Claude Skill 后，制作下一支视频的整个过程就会真正浓缩为一行命令：

1

/motion-reel for [URL], 20s, vertical, reference ./refs/frame.png

• 商业变现潜力：achxvi 现在已经把这套流水线直接包装成商业服务对外接单——包含配乐、任意风格的定制吉祥物、产品功能展示、片尾促销信息、支持任意语言并包含最多 3 次修改。他制作一支 38 秒的竖屏产品宣传片，全程仅需 45 分钟。
• 推荐直接 Clone 的开源仓库：
  • PDoomVideo（学习大型音乐 MV 的多智能体协作管线）
  • ClaudeAnimationBase（最适合作为你自己的工程脚手架起点）

全景对照表：一套完整的动态设计工作室

为什么这件事真正值得关注？

一年前需要花 1,200 美元找外包机构制作的产品发布宣传片，如今借助一个封装好的 Skill 和自动质检闭环，一个下午就能在本地跑完。

第一个“一句话生成”的结果出得极快，这也是为什么它能瞬间引爆社交网络的时间线。但真正具有颠覆意义的在于：你的第 10 支视频会比第 1 支好得多——因为你的制片规范、确定性渲染引擎以及严苛的审片清单，会在每一次运行中不断复利积累。

等到下一次新产品发布时，你只需要替换掉产品 Brief 和界面截图资产，剩下的整座“动画制片厂”都可以原封不动地为你全速运转。

写在最后：真正的核心机密

1. 提示词本身只占最终效果的 10% 左右，真正决定上限的，是包裹在提示词外面的那套工程脚手架（Harness）。
2. 可寻址性（Seekability）是唯一绝对不能妥协的铁律：任何一帧都必须能够随时独立渲染，且每次渲染的结果必须分毫不差。
3. 坚持只用真实的产品资产：Opus 可以极具创意地发明一个运镜轨迹，但它绝不应该去“发明”你的产品数据看板。
4. 自我审片闭环（Critique Loop）是大多数人最容易跳过的一步——因为第一遍渲染成功往往会给人一种“大功告成”的错觉；但恰恰是这一步，构成了所有百万播放爆款视频的共同基因。

那么，如果现在对你的工作流做一次分镜缩略图测试（Contact Sheet Test），你觉得哪一个环节会第一个暴露问题？

(原文作者：@seeconvm | 整理与编译优化版)

将 Hexo 博客部署到自己的 VPS 上，核心原理是在服务器上创建一个Git 裸仓库（Bare Repository），并通过 Git 的 post-receive 钩子（Hook），在每次本地执行 hexo d 推送静态文件时，自动将最新代码检出（Checkout）到 Web 服务器的网站根目录下。

以下是完整的手动配置流程，文末附带一键自动化部署脚本。

一、 手动配置步骤

假设你的服务器系统为 Debian / Ubuntu，目标是将博客源码推送到 /var/repo/hexo.git，并将生成的静态网页自动同步到 /var/www/hexo。

1. 安装 Git 并创建专用用户

在 VPS 上执行，出于安全考虑，限制 git 用户通过 SSH 登录交互式 Shell。

首先确保服务器已安装 Git，然后创建一个名为 git 的系统用户，并将其默认 Shell 修改为 git-shell（仅允许执行 Git 推送/拉取操作，禁止常规命令行登录）。

1
2
3
4
5
6
7
8

# 1. 安装 Git
sudo apt update && sudo apt install -y git

# 2. 将 git-shell 加入系统合法 shell 列表
which git-shell | sudo tee -a /etc/shells

# 3. 创建 git 用户并指定 shell 为 git-shell
sudo adduser --disabled-password --gecos "" --shell "$(which git-shell)" git

2. 配置 SSH 公钥免密登录

避免每次 hexo d 都需要输入服务器密码

在本地电脑上获取你的 SSH 公钥（如果还没有，先在本地运行 ssh-keygen 生成）：

1

cat ~/.ssh/id_ed25519.pub

1

ssh-keygen -t ed25519 -C "hexo-deploy"

回到 VPS 服务器，将复制的公钥写入 git 用户的授权列表中，并严格设置目录权限（权限不对会导致 SSH 验证失败）：

1
2
3
4
5
6

sudo -u git mkdir -p /home/git/.ssh
echo "粘贴你本地的公钥内容" | sudo -u git tee -a /home/git/.ssh/authorized_keys

# 严格限制权限
sudo chmod 700 /home/git/.ssh
sudo chmod 600 /home/git/.ssh/authorized_keys

3. 初始化 Git 裸仓库与网站目录

裸仓库只保存 Git 版本历史，不保存工作区源文件

创建用于存放 Git 仓库的目录 /var/repo 和存放网页文件的目录 /var/www/hexo，并将所有权交给 git 用户， 钩子脚本有权限写入文件。

1
2
3
4
5
6
7
8

# 1. 创建并初始化裸仓库
sudo mkdir -p /var/repo
sudo chown git:git /var/repo
sudo -u git git init --bare /var/repo/hexo.git

# 2. 创建静态网页部署目录
sudo mkdir -p /var/www/hexo
sudo chown git:git /var/www/hexo

4. 编写 post-receive 自动同步钩子

实现推送即部署的核心步骤

当本地向裸仓库推送代码完成后，Git 会自动触发 hooks/post-receive 脚本。我们利用它将文件强制部署到 /var/www/hexo。

1
2
3
4
5
6
7
8

# 创建并写入钩子内容
sudo -u git tee /var/repo/hexo.git/hooks/post-receive >/dev/null << 'EOF'
#!/bin/sh
git --work-tree=/var/www/hexo --git-dir=/var/repo/hexo.git checkout -f
EOF

# 赋予可执行权限（极其重要，否则钩子不会生效）
sudo chmod +x /var/repo/hexo.git/hooks/post-receive

5. 配置本地 Hexo 并推送测试

在你的本地电脑博客根目录下操作

首先确保本地安装了 Git 部署插件：

1

npm install hexo-deployer-git --save

打开本地 Hexo 根目录下的 _config.yml 文件，修改文末的 deploy 配置项：

1
2
3
4

deploy:
  type: git
  repo: git@你的服务器IP或域名:/var/repo/hexo.git
  branch: master

保存后，在本地终端执行三连命令即可完成发布：

1

hexo clean && hexo g && hexo d

推送成功后，去服务器的 /var/www/hexo 目录下查看，你会发现静态网页文件已经全部自动生成好了。随后只需用 Nginx 或 Caddy 将网站根目录指向 /var/www/hexo 即可访问。

进阶：一键自动化部署脚本

如果你觉得上述手动步骤太繁琐，或者后续还想在同一台 VPS 上快速部署其他静态站点（如 VitePress、Hugo、纯静态主页等），可以直接在服务器上使用下面整理好的自动化脚本。

脚本亮点

• 幂等性设计：可重复执行，已存在的用户、公钥或目录会自动跳过，方便随时新增第二个、第三个静态站点仓库。
• 安全隔离：自动配置 git-shell 与严格的 .ssh 权限，无需手动切换用户调整 chown / chmod。
• 灵活传参：既支持命令行直接传参（如 ./git-deploy-repo.sh hexo /var/www/hexo），也支持不带参数交互式运行。

使用方法

1. 登录 VPS，创建脚本文件 git-deploy-repo.sh：

   1	vim git-deploy-repo.sh

2. 将下方完整代码粘贴进去（注意将第 12 行的 PUBKEY 替换为你本地电脑的真实 SSH 公钥）：

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123

   #!/bin/bash # 用 git + post-receive hook 部署静态站点（如 Hexo） # 用法：git-deploy-repo.sh [repo 名] [部署目录] # 例：git-deploy-repo.sh hexo /var/www/hexo # 不带参数时交互输入。可重复执行，用于快速新增不同的 repo。 set -u GIT_USER="git" REPO_ROOT="/var/repo" PUBKEY="PUBKEY" # ── sudo 包装：非 root 自动加 sudo ──────────────────────────────── if [ "$(id -u)" -eq 0 ]; then SUDO="" else if command -v sudo >/dev/null 2>&1; then SUDO="sudo" else echo "需要 root 权限，但未找到 sudo。请以 root 身份执行。" >&2 exit 1 fi fi # 以 git 用户身份执行命令（root 下用 runuser，否则用 sudo -u） as_git() { if [ "$(id -u)" -eq 0 ]; then runuser -u "$GIT_USER" -- "$@" else sudo -u "$GIT_USER" "$@" fi } if ! command -v git >/dev/null 2>&1; then echo "未找到 git，正在安装..." $SUDO apt update && $SUDO apt install -y git || exit 1 fi # ── 参数 ────────────────────────────────────────────────────────── REPO_NAME="${1:-}" if [ -z "$REPO_NAME" ]; then read -r -p "repo 名称（如 hexo）: " REPO_NAME </dev/tty fi REPO_NAME="${REPO_NAME%.git}" if [ -z "$REPO_NAME" ]; then echo "repo 名称不能为空。" >&2 exit 1 fi WORK_TREE="${2:-}" if [ -z "$WORK_TREE" ]; then read -r -p "部署目录 [默认 /var/www/$REPO_NAME]: " WORK_TREE </dev/tty WORK_TREE="${WORK_TREE:-/var/www/$REPO_NAME}" fi REPO_DIR="$REPO_ROOT/$REPO_NAME.git" # ── 1. git 用户 ─────────────────────────────────────────────────── GIT_SHELL="$(command -v git-shell)" if [ -z "$GIT_SHELL" ]; then echo "未找到 git-shell。" >&2 exit 1 fi if ! grep -qx "$GIT_SHELL" /etc/shells; then echo "$GIT_SHELL" | $SUDO tee -a /etc/shells >/dev/null fi if id "$GIT_USER" >/dev/null 2>&1; then echo "用户 $GIT_USER 已存在，跳过创建。" else $SUDO adduser --disabled-password --gecos "" --shell "$GIT_SHELL" "$GIT_USER" || exit 1 echo "已创建用户 $GIT_USER。" fi if [ "$(getent passwd "$GIT_USER" | cut -d: -f7)" != "$GIT_SHELL" ]; then $SUDO usermod -s "$GIT_SHELL" "$GIT_USER" echo "已将 $GIT_USER 的 shell 设为 $GIT_SHELL。" fi # ── 2. SSH 公钥 ─────────────────────────────────────────────────── GIT_HOME="$(getent passwd "$GIT_USER" | cut -d: -f6)" AUTH_KEYS="$GIT_HOME/.ssh/authorized_keys" as_git mkdir -p "$GIT_HOME/.ssh" as_git touch "$AUTH_KEYS" if $SUDO grep -qF "$PUBKEY" "$AUTH_KEYS"; then echo "公钥已存在，跳过。" else echo "$PUBKEY" | as_git tee -a "$AUTH_KEYS" >/dev/null || exit 1 echo "已添加公钥。" fi $SUDO chmod 700 "$GIT_HOME/.ssh" $SUDO chmod 600 "$AUTH_KEYS" # ── 3. 裸仓库 ───────────────────────────────────────────────────── $SUDO mkdir -p "$REPO_ROOT" $SUDO chown "$GIT_USER:$GIT_USER" "$REPO_ROOT" if [ -d "$REPO_DIR" ]; then echo "仓库 $REPO_DIR 已存在，跳过 init。" else as_git git init --bare "$REPO_DIR" || exit 1 fi # ── 4. 部署目录 ─────────────────────────────────────────────────── $SUDO mkdir -p "$WORK_TREE" $SUDO chown "$GIT_USER:$GIT_USER" "$WORK_TREE" # ── 5. post-receive hook ────────────────────────────────────────── HOOK="$REPO_DIR/hooks/post-receive" as_git tee "$HOOK" >/dev/null << EOF #!/bin/sh git --work-tree="$WORK_TREE" --git-dir="$REPO_DIR" checkout -f EOF $SUDO chmod +x "$HOOK" echo echo "完成：" echo " 仓库：$REPO_DIR" echo " 部署：$WORK_TREE" echo " 远程地址：$GIT_USER@$(hostname -f 2>/dev/null || hostname):$REPO_DIR" echo " Hexo _config.yml 中 deploy.repo 填上面的远程地址即可。"

3. 赋予执行权限并运行：

   1 2	chmod +x git-deploy-repo.sh ./git-deploy-repo.sh hexo /var/www/hexo

原作者：X 博主 @Sac
演示作品：点击查看《小王子》3D 可探索星球演示
核心看点：结合 Tripo + Blender + Unity，利用 Opus 5.5 将《小王子》故事中的每一个星球变成可探索的 3D 场景。从场景搭建、人物制作，到代码开发与调试，核心工作流全部交由 AI 完成。

本文将完整公开这套 AI 3D 游戏制作的工作流，结合《小王子》实际案例与可复用的提示词（Prompts），手把手带你入门 AI 3D 游戏开发，搭建属于你想象中的世界。

全文主要分为三个部分：

1. 游戏开发流程与工具配置
2. 3D 场景构建全流程
3. 3D 角色建模与动作交互

一、 游戏开发流程与工具配置

1. 核心 AI 协同工作流

整个游戏的开发由多个 AI 模型各司其职、串联完成：

• 需求与策划（Fable 5.1）：负责制作 PRD（产品需求文档），梳理游戏核心场景、人物设定以及剧情故事线。
• 视觉概念设定（GPT Image 2.5）：生成高一致性的场景参考图与人物多视角设定图。
• 核心 3D 资产生成（Tripo）：将 2D 概念图转化为高精度 3D 模型资产。
• 场景搭建与核心代码（Opus 5.5）：通过 CLI 与 MCP 工具操控 Blender 与 Unity，完成场景组装与核心代码搭建。
• 迭代优化与 Debug（Astra）：负责后期的细节打磨、性能优化以及 Bug 修复。

2. 基础工具与环境配置

在开始制作前，需在本地配置好以下软件与插件接口，以便 AI 能够直接接管操作：

• Blender 配置：
  • 下载并配置 Blender CLI，用于让 AI 优化 Tripo 生成的 3D 模型，并完成游戏整体的 3D 建模组装。
  • 安装付费插件 Auto-Rig Pro，用于人物的自动绑骨与蒙皮，为后续动作交互打下基础。
• Unity 配置：
  • 安装 Unity 客户端，作为游戏引擎将场景、人物与交互动效打包成完整游戏。
  • 安装 Unity CLI，并在项目中安装 Pipeline 包，使 Claude（Opus 5.5）能够通过官方 Unity MCP 直接操作 Unity 项目。

二、 3D 场景构建全流程

核心链路：Image 2.5 生成场景参考图 ➔ AI 拆解 3D 资产并在 Tripo 中生成 ➔ Opus 5.5 操控 Blender + Unity 完成场景建模与还原

步骤 1：使用 GPT Image 2.5 生成多视角场景参考图

根据前期整理好的游戏需求，使用 Image 2.5 生成场景参考图，以此确定整体画风、配色方案以及核心物体的空间位置。

• 实操建议：先确定一张满意的主场景效果图，再围绕它补充其他角度（尤其是包含室内外结构的复杂场景）：

  • 俯视图：用于明确场景的整体平面布局。
  • 斜侧视图：用于补充物体的高度、造型特征和前后层次关系。
  • 全景多视图：也可以直接通过提示词一次性生成包含多视角与局部细节的综合参考图。
    

• 💡 可复用提示词（生成多视角场景图）：

  基于上传的场景参考图，帮我生成一张该场景的全面貌参考图片，包括整体环境的多视角视图以及局部细节的展示。

步骤 2：利用 AI 拆解场景资产，并在 Tripo 中生成独立道具

拿到参考图后，不要急于建模。先让 AI 分析画面，判断哪些复杂资产需要在 Tripo 中单独生成，哪些基础几何结构可以直接交给 Opus 5.5 在 Blender/Unity 中用代码搭建。

• 💡 可复用提示词（资产拆解与标注）：

  我现在要进行游戏开发，我的技术栈是 Tripo + Blender + Unity。请你根据上述生成的场景参考图，帮我深入分析哪些资产适合用 Tripo 生成，哪些资产适合用 Blender 直接进行搭建。并将需要用 Tripo 生成的资产在图片中标注出来，方便我确认。
  

• Tripo 模型选择技巧：在 Tripo 中制作场景道具类 3D 资产时，建议使用 H3.1 模型，该模型能最大程度保证静态资产的高精度细节。
  

步骤 3：让 Opus 5.5 操控 Blender 与 Unity 进行组装与多机位迭代

在 Tripo 中生成并导出独立 3D 道具后，将这些资产连同第一步的场景参考图一起交给 Opus 5.5。让它操控 Blender 和 Unity 搭建整体环境，并严格按照参考图摆放道具、调整比例与空间位置。

• 关键核心：提供详尽的参考图，并引入独立审查 Agent 进行多机位截图盲审，通过视觉反馈闭环不断调整布局与细节。

• 💡 可复用提示词（场景复刻与自动盲审迭代）：

  根据上传的场景内外景多视角参考图以及生成好的 Tripo 3D 资产，请你对照参考图进行完美级的复刻，要求实现和参考图一致的惊艳质感与细节还原。

  在实现完成后，请派一个独立的审查 Agent 进行多机位的场景盲审。如果发现有和参考图存在差异的地方，就不断地进行迭代完善。

三、 3D 角色建模与动作交互

核心链路：Image 2.5 生成人物四视图 ➔ Tripo 生成 3D 角色模型 ➔ Blender (Auto-Rig Pro) 绑骨蒙皮 ➔ 接入 Mixamo 动作库 ➔ Blender 复杂交互二次精调（可选）

以下我们以《小王子》主角的设计为例，拆解具体步骤：

步骤 1：使用 Image 2.5 生成人物 T-pose 四视图

根据人物形象设定，首先使用 Image 2.5 生成小王子的标准 T-pose 四视图（正视、背视、左视、右视），务必确保各个视角下的人物服装、比例等细节高度统一。

步骤 2：使用 Tripo 的 Smart Mesh P2.0 生成可编辑 3D 角色

• 为什么选 Smart Mesh P2.0？ 这是一个专门面向游戏和交互内容的 3D 生成模型，其核心优势是生成的布线面数可控、拓扑结构规整，非常便于后期的骨骼绑定和动画制作。
• 实操流程：
  1. 在 Tripo 中选择「多视图生成 3D」，依次上传生成的四视图。
  2. 参数设置：拓扑默认选择「四边形」，精度拉到最高，模型选择 P2.0 并开始生成。
     
  3. 网格检查与贴图：先观察初步生成的白模。若网格整齐无误，直接点击「Texture（纹理）」生成模型贴图；若发现局部网格形状不合理，可使用「Edit Mesh」功能进行局部重绘再生成。
     

步骤 3：在 Blender 中利用 Auto-Rig Pro 自动绑骨与蒙皮

配置好 Auto-Rig Pro 插件后，直接在 Claude 中上传人物模型，通过提示词驱动 Blender 完成自动化骨骼绑定与权重测试。

• 💡 可复用提示词（自动绑骨、蒙皮与动作测试）：

  使用 Auto-Rig Pro 为人物完成绑骨和蒙皮，确保骨骼位置与人物关节精准对齐。完成后测试抬手、弯腿、转身等基础动作，检查并修正明显的变形、拉扯和穿模问题。

步骤 4：从 Mixamo 获取动作文件并由 Opus 5.5 完成重定向

1. 根据游戏的交互设定，前往 Mixamo 官网 按关键词搜索小王子所需的动作（如行走、跳跃、挥手等），并下载对应的 .fbx 动作文件。
2. 将动作文件交给 Opus 5.5，让其自动检查动作数据是否匹配小王子的真实骨骼结构，并在引擎/Blender 中完成动作接入与重定向。
   

步骤 5：在 Blender 中精调特殊动作与道具接触细节（进阶可选）

对于诸如「小王子提水壶」这类涉及人物与道具发生物理接触的复杂交互，Mixamo 的通用动作库往往无法完美适配。

• 解决方案：先在 Mixamo 中挑选一个姿势最接近的基础动作，再让 Opus 5.5 在 Blender 里利用控制器进行局部细节的迭代修正。
  

• 💡 可复用提示词（复杂交互与 IK 手部精调）：

  请参考提供的 Mixamo 基础动作，保留其中适用的部分，并使用 Auto-Rig Pro 的手臂 IK 控制器调整手臂姿势，配合手指握持姿态和水壶空间位置的细节修正，补全「提水壶」的完整动作。确保手掌与水壶把手接触稳定、提起过程自然流畅，避免出现穿模、握持脱离或水壶悬空等问题。

Tripo 3D 的注册地址： https://studio.tripo3d.ai/

它提供 .co.fo、.com.fo、.wz.io、.wz.org 等比较少见、但看起来相当简洁的域名后缀。

比如：

• hello.co.fo
• blog.com.fo
• dev.wz.io
• home.wz.org

这些域名不仅适合搭建个人博客、项目主页，也很适合拿来做短链接、个人导航站或者各种小工具。

一、doma.in：一个专注于特色域名的平台

网站地址：https://doma.in/zh-CN/

与传统域名注册商不同，doma.in 主要提供特定二级域名下的注册服务。

例如 example.co.fo，从 DNS 层级来看属于三级域名，但注册和管理体验更接近普通域名。

目前平台开放以下四种后缀：

另外，还有一批后缀计划陆续开放：

.cc.ag、.cc.je、.cc.sk、.cc.td、.co.ki、.co.lu、.co.sk、.co.td、.edu.ax

相比一些已经被大量注册的传统域名，这些新开放的后缀意味着你有机会找到自己喜欢的单词、缩写甚至超短前缀。

如果你一直想拥有一个简洁、好记的域名，现在倒是值得去搜索一下。

域名价格：最低每年 $5

以 .co.fo 为例，平台根据域名前缀的长度区分首次注册价格：

最吸引我的地方是，短域名虽然首次注册需要溢价，但后续续费统一为 $5/年。

例如：

假设你成功注册了 ab.co.fo：

• 第一年：$25
• 第二年：$5
• 第三年：$5
• 第四年：$5

四年合计只需要 $40。

对于喜欢短域名的人来说，这样的续费价格还是挺有吸引力的。

需要注意，部分特殊名称还可能有额外溢价，具体以平台查询结果为准。域名支持一次注册 1～10 年，也支持设置第三方 DNS 服务商的 NS 记录和 DNSSEC 的 DS 记录。

二、重点来了：如何免费注册这些域名？

正常情况下，注册一个四字符以上的普通域名需要支付 $5。

不过，最近烧饼论坛的商城上线了 doma.in 域名代金券，可以直接使用论坛积分购买。

也就是说：

每天去论坛签到，攒够积分后兑换一张 $5 代金券，就可以用来注册一个普通的域名。

论坛公告：【烧饼商城更新】doma.in 域名代金券

目前商城提供三种面额：

这里需要解释一下论坛的两种积分：

• 烧饼：通过签到、发帖、回复、活动等方式获取。
• 大米：烧饼商城使用的积分，100 大米相当于 1 个烧饼。

购买时如果大米不足，商城还会自动使用账户中的烧饼补足，不需要手动兑换。

因此，只要积攒 500 个烧饼，就能兑换价值 $5 的域名代金券。

兑换码可以在 doma.in 登录后兑换为账户余额，再用于域名注册。

这里的免费是指不需要额外支付现金，而不是域名本身永久免费。

三、每天签到，一年究竟能攒多少烧饼？

这是我觉得最有意思的地方。

烧饼论坛的签到奖励不只是每天随机送几个积分，还提供连续签到奖励、整月全勤奖励，以及签到暴击机制。

先看看目前的签到规则：

其中，连续 7 天与连续 30 天的奖励分别计算，可以同时领取，并且支持使用暴击卡 100% 暴击双倍（道具售价 5 烧饼），烧饼论坛每月可以补签 4 次，因此不需要太担心断签。

那么，如果坚持连续签到整整 365 天，会获得多少烧饼？

先计算固定奖励

假设每天都完成签到，中途没有断签，并在连续签到 7 天、30 天时使用暴击卡：

也就是说，仅计算连续签到奖励、全勤奖励，并扣除暴击卡成本，一年就能获得约 2,280 个烧饼。

与不使用暴击卡的 1,480 个烧饼相比，净收益增加了 800 个烧饼。

再加上每日随机奖励

每日签到可以随机获得 1～10 个烧饼，假设平均为 5 个，实际分布可以在签到记录查看。

那么一年的预期收益就是：

365 × 5 = 1,825 个烧饼

再加上前面计算的固定奖励：

2,280 + 1,825 = 4,105 个烧饼

换句话说，只要每天坚持签到，并合理使用暴击卡，一年就能获得约 4,105 个烧饼。

一年能免费兑换多少域名？

烧饼商城中的 $5 域名代金券需要 500 个烧饼。

4,105 ÷ 500 = 8.21

也就是说，一年签到获得的烧饼，就足够兑换 8 张 $5 域名代金券，总价值 $40。

如果用于注册普通四字符以上、每年 $5 的域名，相当于可以免费注册 8 个域名，或者覆盖一个域名长达 8 年的注册与续费成本。

这还没有计算新用户注册奖励、论坛发帖回复、签到随机暴击，以及不定期发放的红包。

对于喜欢折腾个人网站的人来说，每天花几秒钟签到，就有机会长期免费持有自己喜欢的域名，还是相当划算的。

五、不只是签到，日常逛论坛也能赚烧饼

如果平时就喜欢逛技术社区，那么攒积分的速度还会更快。

烧饼论坛日常参与奖励包括：

另外，论坛也会不定期发放红包，平时看看自己感兴趣的技术讨论，顺手参与一下，就有机会获得额外奖励。

比如，假设每天除了签到，还正常参与讨论，发表 3 条有效回复：

一年可以额外获得：

3 × 365 = 1,095 个烧饼

加上前面计算的平均签到收益：

3,487.5 + 1,095 = 4,582.5 个烧饼

这已经足够兑换 9 张 $5 代金券。

当然，没必要为了积分刻意灌水。论坛对无效回复、重复内容和违规行为都有限制。正常交流、分享经验才是更适合长期积累积分的方式。

六、实际兑换流程

如果想体验一下，可以按照下面的流程操作。

第一步：注册烧饼论坛

进入 烧饼论坛 注册账号，并完成邮箱验证。若论坛采用邀请注册，需要先取得邀请码。

第二步：每天签到积攒积分

坚持每日签到，争取获得连续 7 天、30 天与整月全勤奖励。

空闲时也可以参与论坛讨论，积攒额外积分。

第三步：兑换域名代金券

积攒到 500 个烧饼后，打开：

烧饼商城 → 域名

选择 $5 面额的 doma.in 域名代金券，完成兑换。

购买成功后，可以在「我的兑换码」中查看对应兑换码。

第四步：兑换到 doma.in 账户

进入 doma.in 登录账户，使用兑换码将 $5 充值到账户余额。

第五步：注册喜欢的域名

搜索自己喜欢的域名前缀，确认尚未被注册后，直接使用账户余额支付即可。

如果注册的是普通四字符以上、首年价格 $5 的域名，那么一张 $5 代金券就能覆盖一年的注册费用。

七、注册前需要注意的事情

虽然价格便宜，而且有免费获取的方式，但在正式注册之前，还有几个地方值得留意。

首先，这些并不是传统意义上独立的二级域名。

例如 example.co.fo，它依赖于上级域名 co.fo 的持续运营和管理。相比直接注册 .com、.net 等顶级域名下的名称，上级运营方的稳定性也是需要考虑的因素。

其次，平台目前不提供 DNS 托管。

注册后需要自行选择第三方 DNS 服务商并设置 NS。根据平台公告，目前能否直接接入 Cloudflare 还需要视公共后缀列表收录情况和 Cloudflare 的实际支持而定。

另外，建站需要正确配置 HTTPS。

平台目前开放的这些域名后缀已加入 HSTS Preload List。浏览器会强制使用 HTTPS 访问，如果没有正确部署 TLS 证书，网站可能无法正常打开。

最后，论坛积分、优惠券和域名价格都有可能发生变化。代金券还可能存在有效期，购买后也不支持退款，所以建议有实际注册需求时再兑换。

总结：一个值得顺手收藏的域名羊毛

对于喜欢折腾个人网站、博客和小项目的人来说，我觉得 doma.in 还是挺值得关注的。

一方面，.co.fo、.com.fo、.wz.io、.wz.org 这些域名后缀看起来比较简洁，有机会注册到不错的短名称。

另一方面，最低 $5/年的价格并不算高，短域名后续统一 $5/年的续费机制也挺有吸引力。

最重要的是，现在还能通过烧饼论坛签到获取代金券。

每天签到几秒钟，按当前规则计算，一年平均能够积攒约 3,488 个烧饼，相当于接近 $35 的域名代金券面额。

平时参与讨论、领取红包或者获得其他活动奖励，还能进一步加快积累速度。

虽然不能说是无条件永久免费，但如果愿意每天顺手签到，确实有机会长期不花现金地持有几个喜欢的域名。

如果你最近正好想给博客、开发项目或者个人主页找个新域名，不妨去看看。

相关地址：

• 域名注册平台：doma.in
• 烧饼论坛：sb.sb
• 域名代金券：烧饼商城
• 兑换说明：官方公告
• 签到和积分规则：论坛规则

针对这一工程痛点，由前 OpenAI 研究员 Diogo Almeida 创立的 TypeSafe AI 带来了一种截然不同的解法——推出面向结构化决策的 System One 模型 Jev：让 AI 深度理解语义，但不让它自由发挥，直接返回预定义的选项、评分与概率分布，供后端业务系统直接执行。

2026 年 9 月 15 日，TypeSafe AI 宣布完成由 DCVC 领投的 4000 万美元种子轮融资，并正式开放 Jev 的早期访问（同时已集成至 Vercel AI Gateway）。与面向普通用户的对话助手不同，Jev 的首要目标客户是软件本身：它不负责聊天，也不负责写代码，而是旨在成为开发者可以嵌入业务流程中的一个高频“语义判断组件”。

理解 Jev 的关键，不是把它看作“更便宜、缩水的聊天模型”，而是理解它为什么从底层架构上主动放弃了自由对话与文本生成。

软件需要的，往往不是一段回答

设想一套客服自动化系统收到这样一条用户消息：

“昨天同一笔订单被扣了两次钱，到现在也没有退回来，麻烦尽快处理。”

在业务逻辑层面，系统接下来需要确定的其实只有几个核心问题：

1. 分类归属：这属于账单问题还是技术故障？
2. 意图判断：客户是否在明确申请退款？
3. 紧急程度：是否需要提高处理优先级？

处理这些问题确实需要理解自然语言，但答案本身并不开放。软件往往不需要一封措辞得体的客套回信，也不需要长篇大论的因果剖析；它真正需要的是能直接用于业务分流、分支跳转和数据库更新的结构化数据。

Jev 正是为这种场景量身定制。开发者向模型传入当前状态（如客户消息、订单记录和业务规则），并严格限定允许的问题与备选答案。模型直接返回受约束的结构化结果，而不是发散生成的自然语言。

一个直观的类比是：通用聊天模型就像一个可以交流的顾问助手，而 Jev 更像一个嵌入在代码内部、能够读懂语义的判断函数。

三种输出，覆盖三类核心判断

Jev 的 API 接口围绕三种基础类型展开：Choice、Score 与 Noul。开发者无需写冗长的 Prompt 笼统要求“帮我分析一下”，而是以强类型的方式明确告诉模型程序需要哪一种数据结构：

1. Choice（单项选择）

Choice 适用于分类与路由。它会返回被选中的选项、各个选项的完整概率分布以及一个整体置信度（Confidence）指标。目前单个 Choice 最多支持 255 个选项。由于所有选项必须由开发者事先严格枚举，模型无法凭空创造一个不存在的部门名称或工具标识。

2. Score（基准评分）

Score 适用于带有评价标准的等级打分。开发者需要预先定义有序档位（例如将故障划分为“仅影响外观”、“功能受损但有替代方案”、“关键功能完全不可用”三个等级），而不仅是告诉模型模糊的“打个分”。最终返回的分数通常是小数，因为它是各档位编号按预测概率加权后的数学期望值，并不局限于某个离散的整数档位。

3. Noul（概率判断）

Noul 本质上是带概率输出的布尔判断题。对于“客户是否要求退款”，模型可能直接返回 0.98。数值越接近 1.0 表示断言为真的概率越高，接近 0.0 表示更倾向于“否”，而在 0.5 附近则说明处于模棱两可的不确定区间。由于自身已是直接的概率值，Noul 不再额外返回独立的 confidence 字段。

这三个类型的核心价值在于：让调用方软件在发起请求前就确切掌握返回数据的形状（Data Shape）。后续程序可以直截了当地比较概率、设置阈值、排序或分支跳转，彻底告别了对非结构化文本的脆弱解析与正则匹配。

为什么它能这么快？

Jev 的速度与吞吐优势，并不仅是因为“返回的内容变短了”。

在底层推理机制上，通用大语言模型普遍采用自回归（Autoregressive）机制，必须逐个 Token 串行生成字符，即便输出简单的 JSON 也要耗费多次前向传播。而据 TypeSafe 官方介绍，Jev 放弃了逐 Token 文本生成，转而采用面向结构化决策的并行输出机制。

在单次请求中，开发者可以同时声明多个独立的判断问题（例如同时评估部门分类、退款意图与紧急程度），Jev 能够在单次推理中并行完成评估并返回结果。Vercel 在官方接入 Jev 的说明中，也将这一并行评估能力列为它与传统语言模型的重要区别。

与传统 LLM 的“结构化输出”有何不同？

这里需要厘清一个常见的认知误区：传统的生成式模型并非只能输出杂乱的自由文本。

现有前沿模型（如 OpenAI GPT-4o、Anthropic Claude）已经支持 Structured Outputs（结构化输出），通过强制约束 JSON Schema 来保证输出符合指定格式。

然而，传统模型的本质依然是在语法掩码约束下逐个 Token 串行生成文本，计算开销与延迟依然受制于自回归机制。同时官方也明确提醒：格式合规（Syntactically Valid）并不等于内容真实正确（Semantically Accurate）。

因此，Jev 的差异化不在于“终于让 AI 学会了返回 JSON”，而是从底层架构彻底剥离了自由文本生成的包袱，用更聚焦的有限答案空间，换取极限的吞吐效率、极低的时延与原生的校准概率。

比“选什么”更重要的，是“不确定时怎么办”

假设系统在两次工单分类判断中，最终都将最高概率给到了“账单部门”，但其详细的概率分布如下：

• 工单 A：账单 98%，技术 1%，销售 1%
• 工单 B：账单 40%，技术 35%，销售 25%

两次判断的最高概率选项虽然相同，但任何健壮的软件系统都绝不应该对它们采取完全一样的处理方式：工单 A 可以直接由自动化流水线秒级派单，而工单 B 显然处于高争议状态，更适合打上待确认标记或转交人工介入。

这就是 Jev 将概率分布与不确定性置于核心地位的原因。

RLCD：面向校准决策的强化学习

传统聊天模型的 RLHF（基于人类反馈的强化学习）更侧重优化回复的顺畅度与人类偏好，这有时容易导致模型在不确定时表现出盲目的过度自信。

针对这一痛点，TypeSafe 采用了专门的训练方法 RLCD（Reinforcement Learning for Calibrated Decisions，面向校准决策的强化学习）。其核心目标不仅是选出高概率答案，更在于让输出的概率分布与真实世界的统计分布相校准（Calibrated）。

所谓校准，可以用一个统计场景来说明：

如果模型对 1000 条客服消息给出的“退款意图”概率均为 80%，那么在事后人工复核中，这 1000 条消息里实际属于退款请求的比例也应该非常接近 80%。

对自动化系统来说，真正有用的不是一个永远表现得无比自信的模型，而是一个能够准确量化自身不确定性、方便程序妥善兜底的模型。

“快 193 倍、便宜 444 倍”，应该怎样理解？

在 TypeSafe 官网的宣传中，一组对比数据格外吸睛：在其 System One 工作流基准测试中，Jev 相比对照前沿模型实现了约 193.6 倍的速度提升 和 444.6 倍的成本优势。

这些数字来自特定工作流比较，我们需要结合具体工程条件客观审视：

1. 延迟与响应时间

官方公开介绍给出的端到端响应时间通常在 70 ~ 500 毫秒 之间。官方也坦承，上百倍的极端改善倍数往往处于特定长文本、高推理对比场景的较高端。测试网络节点、输入文本长度、对照模型的推理配置以及是否要求对照模型输出完整 Logprobs 等，都会显著影响实际对比倍率。

2. 准确率评估方法

在 TypeSafe 的工作流评测中，基准参考并非全量来自于独立专家的人工标注，而是采用其他多款前沿强模型的共识汇总。因此，它能够有力展示在特定流程中的相对表现，但不能简单等同于在所有未知垂直场景下都具备普适的准确率。

科技媒体 Every 的一项独立初测提供了直观的侧面参考：在针对 12 段合成文本进行写作问题检查时：

• 耗时对比：Jev 每段的中位耗时为 0.35 秒，对照的 Claude Fable 5.1 在高推理设置下为 8.83 秒，相差约 25 倍；
• 检出效果：在预设的 7 处问题中，Jev 找到了 6 处，对照模型找到了全部 7 处。

这一样本虽小，但清晰体现了实际工程中的核心取舍：是用极低延迟和成本换取高并发吞吐，还是用漫长的深度推理等待换取边际精度的极致提升。

3. 定价与推理成本

在计费方面，截至 2026 年 9 月，官方文档公布的标准费用极低：

• 输入费用：**$0.042 / 百万 Token**
• 输出费用：完全免费

1
2
3
4

[成本估算示例]
假设每次业务请求消耗 1,000 个输入 Token：
调用 100 万次 = 10 亿输入 Token
纯模型调用费用仅为： 1,000 × $0.042 = $42 美元

对于日均数百万次的高频小判断任务，这种成本结构极具吸引力。但在生产环境中，更全面的考量还应包括网络通信、数据清洗、重试逻辑以及异常情况的人工介入成本。

“没有幻觉”，不等于“不会犯错”

这是理解与落地 Jev 时必须守住的一道边界。

TypeSafe 所强调的“类型安全”与“零幻觉”，其严谨含义是：输出被严格限定在预先定义的答案空间与数据结构中。
比如，在候选项仅有 billing、tech 与 sales 时，Jev 在机制上绝不会凭空捏造一个诸如“量子事务部”的不存在字段。

它保证了绝不跳出答题卡，但并不保证每道题都答对。

它依然可能误将技术故障判定为账单问题，也可能低估一张紧急工单的严重程度。

更进一步，在系统工程设计上：即便模型准确识别出“客户希望退款”，程序也绝不能据此直接触发支付网关退款。
后续操作依然必须由严谨的业务规则把关：订单是否存在？交易是否重复？是否在退款时限内？操作人员是否有授权？

一种合理的系统架构设计是：

• 模型负责语义识别：处理非结构化自然语言中的主观性与模糊性；
• 代码负责规则与执行：核验记录、执行状态机、调用业务 API；
• 异常机制负责兜底：低置信度结果自动进入人工复核或交由高推理模型二审。

它适合放在哪里？

Jev 更适合成为现有软件流水线中的一个高频节点，而不是独自包揽全流程任务：

• 智能请求路由（Router）：客服系统的工单分派、社区发帖的违规预审、多 Agent 架构中决定下一步调度哪个专用工具或 Subagent。
• Agent 执行控制（Controller）：判断当前工具执行结果是“成功”、“需要重试”还是“陷入死循环需人工接入”，驱动决策状态机。
• 内容与合规质检（Evaluator）：作为低成本的裁判模型（LLM-as-a-Judge），批量检查生成式模型的输出是否符合既定规范。

相反，如果任务目标是写一封邮件、生成一段业务代码或向用户详细推导判断依据，这些场景依然属于生成式模型的绝对领域。同时，Jev 当前仅接收文本形态的输入（如字符串、JSON 对象或文本数组），无法直接输入图像、音频等多模态数据，多模态内容需先经过转换。

从聊天窗口，走向软件内部

“Jev” 这个名字取自英国经济学家威廉·斯坦利·杰文斯（William Stanley Jevons）以及著名的杰文斯悖论（Jevons Paradox）：

当某种资源的使用效率大幅提升、成本显著下降时，该资源的总消耗量往往不仅不会减少，反而会因为应用边界的指数级扩张而大幅激增。

TypeSafe 借此表达了对 AI 普及路径的深刻预期：当可靠的语义判断变得足够轻巧、响应时间进入几十毫秒量级、调用成本低至几乎可以忽略不计，开发者会毫不犹豫地把它嵌入到成千上万个以往根本不舍得用 AI 的日常代码分支中。

通用对话助手能否让人满意，往往取决于它能否把长篇大论写得生动可信；而软件底层的判断组件，衡量标准则完全不同：延迟是否够低、成本是否可控、接口是否足够强类型安全，以及系统能否在其产生疑虑时平稳降级。

Jev 不需要证明自己“比会聊天的模型更高级”。它只需要在那些数以亿计、候选项明确、却必须读懂人话的后台分支里，证明自己是那个比通用模型更轻巧、更可靠的“语义判断函数”。

它真正具有启发性的地方，正是让 AI 走出人机对话的窗口，静默地沉淀为现代软件系统内部随处可调用的基础设施。

整场 AMA 的评论区一半用户认真提问 Codex、GPT-5.6 和 ChatGPT Work 的使用方法，另一半用户则集中吐槽额度消耗、桌面应用体验以及不同平台之间长期存在的功能差距。

虽然官方没有正面回答所有尖锐问题，但在模型选择、推理强度、长任务设计、MCP 工具接入和权限管理方面，还是给出了不少具有实际参考价值的信息。

其中最核心的结论可以概括为一句话：

官方介绍了如何节省 Token 的使用 Codex，却没有解释为什么 GPT-5.6 宣称效率更高却用起来消耗更快。

不同模型与 Effort 应该怎么选

这次 AMA 中最实用的部分，是 Codex 团队成员分享了不同模型和 Effort 推理强度的选择经验。

官方给出的日常默认组合是：

Sol + Medium Effort

这一配置适合大多数普通开发任务，在速度、质量和额度消耗之间相对均衡。

对于不同场景，则可以进一步调整。

Sol：日常开发和前端任务的首选

Sol 适合作为 Codex 中的默认主力模型，尤其适合：

• 常规代码编写
• Bug 修复
• 跨文件修改
• UI 与前端开发
• 根据参考图还原界面

官方特别提到，UI 和前端能力 本身就是 GPT-5.6 的重点训练方向之一。

如果任务中能够提供截图、设计稿或参考页面，Sol 的表现通常会明显优于只给出文字描述。

Terra：额度敏感任务的性价比选择

如果任务相对轻量，同时比较在意额度消耗，可以优先尝试 Terra。

按照官方成员的说法，Terra 在部分任务上的表现可以接近 GPT-5.5，但资源消耗更低，比较适合：

• 小范围代码修改
• 简单脚本生成
• 格式调整
• 重复性开发工作
• 已经明确实现路径的任务

也就是说，并不是所有任务都需要直接交给最强模型。

当需求本身足够清晰时，使用更轻量的模型反而可能获得更高的整体效率。

Luna：适合低成本探索

对于一些不确定是否值得深入的探索性任务，可以先交给 Luna。

例如：

• 快速浏览项目结构
• 初步寻找相关文件
• 调查某个功能的实现位置
• 尝试生成几个可行方向
• 判断问题是否值得升级到更强模型

Luna 更适合作为一个低成本的“侦察兵”，而不是最终负责复杂修改的主力模型。

High：模糊 Bug 和跨模块修改

当问题描述比较模糊，或者修改涉及多个模块时，可以将 Effort 调整到 High。

常见场景包括：

• 无法稳定复现的 Bug
• 多个模块之间的状态异常
• 大范围重构
• 跨前后端联调
• 涉及复杂调用链的问题

这类任务往往不仅需要生成代码，还需要模型建立完整的问题假设，并逐步排除错误方向。

Ultra：只用于真正不能出错的任务

官方并不建议将 Ultra 作为常规配置。

更适合使用 Ultra 的场景包括：

• 数据库迁移
• 安全相关修改
• 生产事故修复
• 权限系统调整
• 大规模基础设施变更
• 一旦出错就可能造成严重损失的任务

Ultra 的意义不是让所有任务都“更聪明”，而是在高风险任务中换取更多检查、推理和验证。

xhigh 的收益已经开始递减

对于最高级别的 xhigh，官方也明确表示，在评测中已经出现明显的收益递减。

它更适合以下情况：

• 任务执行时间很长
• 修改范围非常大
• 错误成本极高
• 需要多轮验证
• 用户特别担心模型遗漏边缘情况

对于普通任务，直接提高到 xhigh 并不一定划算，反而可能带来更慢的速度和更高的额度消耗。

觉得 GPT-5.6 慢，可能是 Effort 设得太高

不少从 GPT-5.5 升级到 GPT-5.6 的用户，仍然沿用了之前较高的推理强度设置。

Codex 团队建议，如果觉得 GPT-5.6 运行速度过慢，可以先检查当前 Effort 是否仍然保持在 GPT-5.5 时期的配置。

GPT-5.6 在更低 Effort 下，往往已经能够完成过去需要更高推理强度才能完成的任务。

换句话说，升级模型后，不应机械地保留原有配置。

更合理的方法是从 Medium 开始，根据任务难度逐步增加，而不是一开始就使用 High、Ultra 或 xhigh。

官方还提到，Fast mode 可以进一步提升大约 1.5 倍的速度。

因此，一套比较实用的选择顺序是：

1. 先尝试 Sol Medium
2. 简单任务切换到 Terra
3. 模糊问题再提高到 High
4. 高风险任务才使用 Ultra
5. 只有极少数长任务需要 xhigh

长任务不要只给目标，还要给停止条件

在长时间运行的 Agent 任务方面，官方推荐使用 /goal 来描述任务目标。

但仅仅给出目标还不够。

如果没有清晰的边界和停止条件，Agent 很容易持续探索、反复修改，最终消耗大量 token，却未必能够产生更好的结果。

官方建议在长任务中明确加入限制条件，例如：

• 只允许修改指定目录
• 不允许改变公开 API
• 最多验证三个假设
• 每个假设完成后必须运行测试
• 如果所有假设都失败，则停止修改并输出总结
• 不允许添加新的依赖
• 不允许修改数据库结构
• 达到指定时间或尝试次数后结束

例如，一个比“修复登录 Bug”更合适的任务描述可以写成：

1
2
3
4
5
6
7
8

修复用户偶尔无法登录的问题。

限制条件：
- 只修改 auth 和 session 目录
- 不改变现有公开 API
- 最多验证三个可能原因
- 每验证一个原因后运行相关测试
- 如果三个方向都失败，停止修改并总结调查结果

这类停止条件能够避免 Agent 陷入无限尝试，也可以降低模型在长任务中不断扩大修改范围的风险。

MCP 工具不一定要全部常驻上下文

MCP 为 Codex 提供了调用外部工具和服务的能力，但如果直接挂载大量 MCP 服务，也会带来明显的上下文开销。

几十个工具定义长期驻留在上下文中，会占用 token，并增加模型选择错误工具的可能性。

Codex 团队提出了两个更节省上下文的思路。

把常用操作封装成 CLI

第一种方式，是将外部服务操作封装成命令行工具，再通过 Skill 教会 Codex 如何使用。

例如，不直接加载一整套部署平台的 MCP 工具，而是提供：

1
2
3

deployctl status
deployctl logs
deployctl release

然后在 Skill 中描述这些命令的用途和参数。

这样做的优势是：

• 工具定义更短
• 上下文占用更低
• 调用方式更稳定
• 更容易进行权限控制
• 可以直接复用现有 Shell 工作流

对于原本就支持命令行操作的服务，这通常比长期挂载完整 MCP 更高效。

将专业 MCP 放到专用子 Agent

第二种方式，是创建一个专用子 Agent，并只为它配置特定 MCP。

例如可以创建：

• Unreal Engine 专用 Agent
• 数据库运维 Agent
• Kubernetes Agent
• 浏览器自动化 Agent
• 内部文档检索 Agent

主 Agent 平时不需要加载这些工具，只有遇到对应任务时，才将工作委托给专用 Agent。

这种模式既可以减少主上下文中的工具数量，也能降低不同工具之间的干扰。

权限优先使用 Auto Review

在 Codex 权限设置上，官方建议多数情况下使用 Auto review，而不是直接开启 Full access。

Full access 虽然能够减少执行过程中的确认步骤，但也意味着 Agent 可以更自由地执行命令、修改文件和访问环境。

对于日常开发任务，Auto review 通常已经能够在效率与安全之间取得较好的平衡。

官方尤其提醒 Windows 用户，应更加谨慎地使用 Full access。

Windows 环境中的 Shell、权限系统、路径处理和脚本行为更加复杂，一些看似普通的命令可能产生超出预期的影响。

因此，更稳妥的做法是：

• 默认使用 Auto review
• 仅在可信项目中临时开启更高权限
• 限制 Agent 可修改的目录
• 对删除、安装和系统级命令进行人工确认
• 不要在包含重要个人文件的目录中直接运行高权限 Agent

Codex、ChatGPT Work 和普通聊天的额度如何计算

这次 AMA 也对不同功能的额度分类做出了解释。

按照官方的划分：

• Codex 计入 Agentic 额度
• ChatGPT Work 计入 Agentic 额度
• 普通 ChatGPT 对话不计入 Agentic 额度
• 图像生成有独立额度
• 文件上传与处理有独立额度
• 语音功能也有独立额度

这意味着，不能简单地将 ChatGPT 中的所有功能都视为共享同一个额度池。

用户看到某一类功能额度下降，并不一定代表其他功能也会同步受到影响。

不过具体到单个 Codex 任务，其消耗并不是固定值。

任务长度、上下文规模、模型、Effort、工具调用次数、测试次数以及是否发生重试，都会影响最终消耗。

为什么 Pro mode 没有进入 Codex

不少用户询问，既然 ChatGPT 中提供了 Pro mode，为什么 Codex 中没有同样的选项。

官方给出的解释是，Pro mode 的运行机制对于 Agentic 编程任务的提升相对有限。

它通常具有以下特点：

• 响应速度更慢
• 消耗额度更多
• 更偏向一次性深度推理
• 对连续工具调用和代码执行的帮助没有想象中明显

因此，Pro mode 更适合：

• 搜索
• 数学推理
• 长文写作
• 文档分析
• 复杂研究任务

而 Codex 的核心场景是读取代码、执行命令、修改文件、运行测试并根据结果继续行动。

在这种 Agentic 工作流中，模型本身的单次推理强度并不是唯一决定因素，工具使用和反馈循环同样重要。

AMA 没有回答的几个关键问题

虽然官方分享了许多使用技巧，但用户最关心的一些问题仍然没有获得明确答案。

GPT-5.6 为什么比 GPT-5.5 更耗额度

整个 AMA 中呼声最高的问题，仍然是 GPT-5.6 的额度消耗。

大量用户反馈，GPT-5.6 在实际使用中的额度下降速度明显快于 GPT-5.5。

这与官方此前强调的“更高 token 效率”形成了明显反差。

官方对此只解释称：

每个任务的消耗并不是固定的。

这句话本身并没有错。

复杂任务、更多工具调用、更长输出以及更高 Effort，确实都会增加消耗。

但它没有正面回答用户真正关心的问题：

• 相同任务下，GPT-5.6 是否平均消耗更多额度？
• 是否因为内部推理 token 增加？
• 是否因为工具调用和验证次数更多？
• Agentic 额度是否采用了不同于文本 token 的权重换算？
• Fast mode 与普通模式的额度计算是否相同？
• 官方宣传中的 token 效率，是否不等于用户看到的额度效率？

这些问题在 AMA 后依然没有答案。

1M 上下文窗口仍然没有明确计划

用户同样频繁询问 Codex 是否会提供 1M 上下文窗口。

官方对此仅表示会认真查看用户反馈，没有给出明确的产品计划或上线时间。

对于大型代码仓库来说，更大的上下文窗口确实具有吸引力。

但在实际 Agentic 工作流中，上下文越大，也可能意味着：

• 更高的处理成本；
• 更慢的首次响应；
• 更多无关代码进入上下文；
• 更复杂的信息筛选；
• 更快的额度消耗。

因此，1M 上下文是否能够真正改善 Codex 体验，仍然取决于检索、压缩和上下文管理能力，而不只是数字本身。

在价格方面，官方也明确表示无法承诺长期稳定。

新版 ChatGPT 桌面应用遭到集中吐槽

新版 ChatGPT 桌面应用是 AMA 中另一个争议集中的话题。

不少用户认为，新应用更偏向 ChatGPT Work 和 Agent 操作，而传统 Chat 功能则被压缩成了一个附属面板。

用户集中反馈缺失或体验退步的功能包括：

• Projects
• 完整历史记录
• 常用快捷键
• 录音功能
• 原有聊天工作流
• Classic 应用中的部分导航体验

官方承认新版应用仍在改进。

但目前给出的短期方案，基本上仍然是同时保留并使用两个应用：

• 需要传统聊天功能时使用 Classic；
• 需要 Agent 和 Work 功能时使用新版应用。

这显然称不上理想的解决方案。

Linux 没有时间表，Windows 仍是二等公民

对于 Linux 桌面版，官方确认相关工作正在进行，但没有提供具体时间线。

而 Windows 用户长期存在的体验差距，也在 AMA 中再次被提及。

官方事实上承认，Windows 版本在过去长期处于相对次要的位置。

这种差距不仅体现在桌面应用，也体现在 Agent 开发环境中：

• Shell 行为与 macOS、Linux 不一致；
• 路径和权限处理更复杂；
• 部分开发工具优先适配 Unix 环境；
• 沙箱能力存在差异；
• 自动化脚本的兼容性更差；
• 部分功能在 Windows 上更晚推出。

对于将 Codex 作为主要开发工具的 Windows 用户来说，这仍然是一个现实问题。

Reward Hacking 问题被礼貌绕开

还有用户追问了 METR 报告中提到的 reward hacking 问题。

问题主要集中在：

• 基准成绩提升中有多少来自 reward hacking
• 模型是否学会针对评测环境优化行为
• GPT-5.6 的训练中做了哪些针对性修改
• 官方如何区分真实能力提升和评测策略优化

Codex 团队没有给出具体数据，也没有详细解释训练层面的改动。

这类问题涉及模型训练、内部评估方法和安全研究，官方选择谨慎回应并不意外。

但从用户角度看，这也意味着外界仍然难以判断：

模型在基准上的提升，有多少能够稳定转化为真实开发环境中的可靠性。

怎么用更省已经讲清楚，为什么更费仍然悬而未决

总体来看，这次 Codex 团队 AMA 的价值主要集中在实际使用方法上。

官方给出的建议相当明确：

• 日常默认使用 Sol Medium
• 轻量任务优先尝试 Terra
• 探索性工作可以委托给 Luna
• 模糊 Bug 和跨模块任务使用 High
• Ultra 只留给高风险任务
• xhigh 不应成为日常默认
• 长任务必须设置停止条件
• 不要让大量 MCP 工具长期常驻上下文
• 优先使用 Auto review，而不是 Full access
• GPT-5.6 不一定需要沿用 GPT-5.5 的高 Effort 设置

这些建议的共同目标都是降低不必要的模型调用、上下文占用和推理消耗。

但另一方面，用户最关心的问题依然没有获得正面回应：

为什么 GPT-5.6 明明宣传 token 效率更高，实际使用时却更快消耗 Codex 额度？

如果 Agentic 额度并不直接等于输入输出 token，那么官方就需要更清晰地解释其计算方式。

如果 GPT-5.6 由于更频繁的工具调用、更长的内部推理或更主动的验证而消耗更高，也应该让用户能够看到这些差异。

否则，用户最终只能通过反复试验来猜测每种模型和 Effort 的真实成本。

这场 AMA 讲清楚了 Codex 应该“怎么用更省”。

至于它为什么“变得更费”，仍然是一个没有被回答的问题。

GPT-5.6：性能全面跃升

GPT-5.6 已于今日开始在 ChatGPT、Codex 和 OpenAI API 全球逐步推出。

PRO 用户已全面完成更新，Plus 用户可能看不到 GPT-5.6 SOL 模型的选项，预计在 24 小时内全面可用。

• ChatGPT 用户：Plus、Pro、Business 和 Enterprise 用户可通过中等及以上思考等级设置访问 GPT-5.6 Sol；Pro 和 Enterprise 用户还可选择 GPT-5.6 Pro 以获得复杂任务的最高质量输出。
• 核心能力提升：在推理复杂任务、遵循模板、参考文件和偏好风格生成材料方面达到业界领先。只需描述期望结果，无需一步步指导。
• 工件质量：显著提升演示文稿、文档和电子表格的质量，支持导出到专业工具并融入企业工作流。
• 设计判断力：增强的计算机使用能力让模型能“查看并优化”渲染结果，而非仅生成代码或内容，从而自动捕捉视觉和功能问题并进行润色。
• Ultra 模式：最高性能设置，通过并行协调多个智能体加速最复杂工作（以更高 token 消耗换取更强更快的结果）。
• 基准表现： OpenAI 提供的基准测试得分情况
  • Artificial Analysis Coding Agent Index：80.0（领先 Claude Fable 5 达 2.8 分），使用更少 token、更短时间且成本约三分之一。
  • Agents Last Exam：53.6（领先 Claude Fable 5 达 13.1 分）；中等推理下以约四分之一成本领先 11.4 分。

ChatGPT Work：AI 自主完成整个工作流

ChatGPT Work 是基于 Codex 和 GPT-5.6 驱动的新智能体，能跨应用和文件采取行动，可长时间持续项目，将单一目标转化为完成的工作。

主要特性：

• 理解用户目标，利用选定应用和文件上下文；
• 自主创建精美文档、幻灯片、分析、网站和报告；
• 支持整个工作流单次请求完成，用户始终保持控制权；
• 反映 AI 使用从“提问”向“真正完成工作”的转变。

可用性：

• Web 和移动端：今日起向 Pro、Enterprise 和 Edu 计划推出；Plus 和 Business 计划未来几天内跟进。
• 桌面应用：Chat、Work 和 Codex 在所有计划（含 Free）可用，已全球支持 Windows 和 Mac 下载。原有 Codex 应用用户更新即可切换为新 ChatGPT 桌面应用。

OpenAI 表示，这一发布体现了 AI 正在成为生产力核心工具，用户只需提出目标，AI 即可自主推进并交付成果。更多细节和演示可通过 OpenAI 官方账号 查看。

此更新进一步巩固 OpenAI 在前沿 AI 模型和实用智能体领域的领先地位。

本教程适用于使用 Docker 部署的 Vaultwarden

1. 临时开启 debug 日志

Docker Compose 里给 vaultwarden 加上：

1
2
3

environment:
  LOG_LEVEL: debug
  EXTENDED_LOGGING: "true"

然后重启：

1

docker compose up -d

如果你是 docker run ，加：

1
2

-e LOG_LEVEL=debug \
-e EXTENDED_LOGGING=true \

2. 重新触发一次“更改邮箱”

在网页端再次提交更改邮箱，让 Vaultwarden 重新生成验证码。

3. 查看 Docker 日志

容器名如果叫 vaultwarden ：

1

docker logs vaultwarden 2>&1 | grep -i "email"

输出的日志大概会是类似：

1

...[vaultwarden::api::core::accounts][DEBUG] Email change ... email (...) with token (123456)

日志末尾括号中的六位数字，就是需要填写的验证码。

4. 完成后改回正常日志级别

查到验证码并完成更改后，建议改回：

1

LOG_LEVEL: info

或：

1

LOG_LEVEL: warn

然后重启。 debug 日志可能暴露敏感信息，不建议长期打开。

5. 长期建议：配置 SMTP

如果以后还会用邮箱验证、邀请、2FA 邮件等功能，最好配置 SMTP。 Vaultwarden 常用的 SMTP 配置项包括：

1
2
3
4
5
6

SMTP_HOST: smtp.example.com
SMTP_FROM: vaultwarden@example.com
SMTP_PORT: 587
SMTP_SECURITY: starttls
SMTP_USERNAME: vaultwarden@example.com
SMTP_PASSWORD: your_password

过去，我们不得不编写各种一次性服务并用复杂的 depends_on 串联。而现在，随着 Docker Compose 新特性的发布，我们终于迎来了官方的 Init Containers 支持。本文将带你一探究竟，看看它如何帮我们精简 compose.yaml！

在使用 Docker Compose 部署应用时，我们经常会遇到一种很常见的需求：在应用启动之前，先执行一些初始化任务。

例如：

• 启动 Web 服务之前，先执行数据库迁移
• 容器以非 root 用户运行前，先修复挂载目录权限
• 应用正式启动前，先生成配置文件
• 先导入初始化数据，再启动主服务

过去我们通常会单独定义一个 migrate、init、setup 之类的一次性服务，然后通过 depends_on 和 condition: service_completed_successfully 控制启动顺序。

现在，Docker Compose 正式提供了更自然的写法：Init Containers。

Init Containers 本质上是 short-lived（短生命周期）容器，会在主服务容器启动之前依次执行；如果其中任何一步返回非 0 退出码，主服务就不会启动。

什么是 Init Containers？

Init Containers 可以理解为：

绑定在某个服务启动前执行的一组初始化步骤。

它们不是长期运行的服务，也不是后台任务，而是“跑完就退出”的临时容器。

Docker Compose 中这个能力通过 pre_start 生命周期钩子实现。根据官方文档说明，pre_start 中的每个步骤都会在独立的临时容器中运行，这些容器会在服务容器创建之后、真正启动之前执行。

一个最简单的例子：

1
2
3
4
5

services:
  app:
    image: myapp:latest
    pre_start:
      - command: ["./manage.py", "migrate"]

这段配置表示：

1. Docker Compose 先创建 app 服务容器；
2. 在 app 真正启动之前，先运行 ./manage.py migrate；
3. 如果迁移命令成功退出（即返回状态码 0），app 才会启动；
4. 如果迁移失败，app 不会启动。

这比过去单独写一个 migrate 服务清晰很多。

以前我们是怎么做的？

在 pre_start 出现之前，如果想表达“先执行迁移，再启动应用”，通常会这样写：

1
2
3
4
5
6
7
8
9
10
11

services:
  migrate:
    image: myapp:latest
    command: ["./manage.py", "migrate"]
    restart: "no"

  app:
    image: myapp:latest
    depends_on:
      migrate:
        condition: service_completed_successfully

这种写法虽然可以工作，但存在以下几个明显的问题：

• 概念混淆：migrate 本质上并不是一个真正的长期运行服务，它只是 app 启动前的一个初始化步骤。把它放在 services 顶层，会让整个 Compose 配置文件显得臃肿。
• 状态残留：任务执行完成后，它会作为已退出的服务留在 docker compose ps 列表中，使得容器服务列表不够清爽。
• 编排繁琐：如果初始化步骤较多（比如先迁移数据库、再导入默认数据、最后生成配置文件），就需要定义多个一次性服务，并用一堆复杂的 depends_on 串联起来。

使用新的 pre_start 特性后，我们可以直接把它们收纳进服务内部：

1
2
3
4
5
6

services:
  app:
    image: myapp:latest
    pre_start:
      - command: ["./manage.py", "migrate"]
      - command: ["./manage.py", "loaddata", "fixtures.json"]

Docker 官方也明确指出，pre_start 的优势在于：

1. 初始化逻辑作为服务的从属步骤表达，不再伪装成并列的独立服务；
2. 已完成的临时步骤不会出现在 docker compose ps 中，保持环境整洁；
3. 多个步骤按顺序执行，无需再通过复杂的 depends_on 逻辑进行链式串联。

示例一：启动前执行数据库迁移

这是最典型的使用场景。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

services:
  app:
    image: myapp:latest
    depends_on:
      db:
        condition: service_healthy
    pre_start:
      - command: ["./manage.py", "migrate"]

  db:
    image: postgres:18
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: password
      POSTGRES_DB: app
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
      interval: 10s
      retries: 5
      start_period: 30s
      timeout: 10s

这里有两个关键点：

1. 依赖关系：app 通过 depends_on 等待 db 容器进入 service_healthy（健康）状态。
2. 初始化时机：在 app 真正启动前，会先在临时容器中执行 ./manage.py migrate。

若数据库迁移成功，app 主服务会继续启动；若失败，app 不会启动，且相关错误日志会直接输出在 docker compose up 中。

这种设计非常适合 Django、Rails、Laravel、Prisma、Drizzle、Alembic 等需要在服务运行前进行表结构迁移的项目。

示例二：修复 Volume 权限

另一个痛点是权限问题：当服务本身以非 root 用户运行，但挂载的 Docker named volume 默认归属于 root 权限时，容器可能会因为没有写入权限而崩溃。

过去，我们可能需要在 Dockerfile 里大动干戈，或者单独拉起一个辅助服务。现在，使用 pre_start 可以非常轻量地搞定：

1
2
3
4
5
6
7
8
9
10
11
12
13

services:
  app:
    image: myapp:latest
    user: "1000:1000"
    volumes:
      - data:/data
    pre_start:
      - image: busybox
        user: root
        command: sh -c 'chown -R 1000:1000 /data'

volumes:
  data:

在这个例子中：

• app 容器以 1000:1000 非 root 用户运行。
• pre_start 步骤指定了覆盖镜像为 busybox，并以 root 权限执行 chown，从而在主服务运行前顺利修正挂载目录所有权。

该场景在自托管/开源应用部署中极度实用，例如：

• 修复上传/缓存目录权限；
• 自动初始化数据目录结构；
• 在挂载路径中提前生成默认配置文件。

示例三：串联多个初始化步骤

pre_start 支持定义一个步骤列表，并会按照声明顺序串行执行。只有当前一个步骤成功退出（返回 0）时，才会继续运行下一个步骤；若中间某一步失败，后续步骤和主服务都将终止。

例如：

1
2
3
4
5
6
7
8
9
10
11
12
13

services:
  app:
    image: myapp:latest
    depends_on:
      db:
        condition: service_healthy
    pre_start:
      - command: ["./manage.py", "migrate"]
      - command: ["./manage.py", "loaddata", "fixtures.json"]
      - command: ["./scripts/generate-config.sh"]

  db:
    image: postgres:18

整个启动流为：

1. 等待数据库容器进入健康状态；
2. 执行数据库表结构迁移；
3. 导入系统初始数据；
4. 生成动态配置文件；
5. 拉起主应用容器。

例如在导入数据时：

1
2
3
4
5
6

-- 不推荐：每次无脑插入，可能会导致主键冲突或数据重复
INSERT INTO users (id, name) VALUES (1, 'admin');

-- 推荐：检测到冲突时跳过，保证幂等性
INSERT INTO users (id, name) VALUES (1, 'admin')
ON CONFLICT (id) DO NOTHING;

pre_start 容器的运行规则

根据官方文档说明，pre_start 步骤拉起的临时容器具有以下行为特征：

• 独立容器：每个步骤都在自己专属的临时容器中运行。
• 默认继承：默认继承当前宿主服务的 image 定义，无需重复指定镜像。
• 允许覆盖：可以通过 image 字段指定其他的轻量工具镜像（如 busybox）。
• 同网共用：会自动加入当前宿主服务所在的网络，因此可以直接访问通过 depends_on 声明的其他依赖服务。
• 共享卷挂载：会自动共享当前服务定义的所有 volumes 挂载。
• 强状态约束：必须返回退出码 0，下一个步骤及主服务才会继续运行。

这些特性为我们编写配置带来了很大便利。例如，若迁移命令就存放在应用镜像内，你只需直接声明命令，无需重复书写镜像名称：

1
2

pre_start:
  - command: ["pnpm", "db:migrate"]

如果需要使用辅助镜像（如 busybox）来做文件操作，直接在步骤内声明 image 即可进行覆盖：

1
2
3
4

pre_start:
  - image: busybox
    user: root
    command: sh -c 'chown -R 1000:1000 /data'

因为共享了同一网络与 volumes，初始化容器在挂载目录中写入的动态配置文件、修正的权限或是写入的数据，在主容器拉起后会立刻生效。

它会每次 docker compose up 都执行吗？

答案是：不会。这是一个非常关键的细节。

根据 Docker 官方文档：

• 如果某个 pre_start 步骤在上一次部署中已经成功执行过，且其定义没有发生任何变化，那么后续执行 docker compose up 时，Compose 会自动跳过该步骤。
• 当服务因 restart 策略发生重启时，不会重新触发 pre_start。
• 只有在以下情况下，初始化步骤才会再次执行：
  1. 步骤的配置定义发生变更；
  2. 上一次执行失败（退出码非 0）；
  3. 执行 docker compose up --force-recreate 强制重建服务。

由此可见，pre_start 偏向于“宿主服务生命周期中的一次性部署初始化”，而不是“每次容器进程启动前的强制拦截”。

什么时候不适合使用 Init Containers？

Init Containers 虽然方便，但并非银弹。根据官方文档的建议，如果你的需求仅是注入静态配置文件或密钥，应当优先使用 Docker Compose 原生的 configs 和 secrets，因为它们支持直接挂载，并允许精细化配置权限和所属用户。

以下场景不建议使用 pre_start：

1. 静态配置文件挂载

对于不需要动态生成的固定配置文件，直接挂载即可，无需启动一个额外的初始化容器去写文件。

推荐方案：

1
2
3
4
5
6
7
8
9
10

configs:
  app_config:
    file: ./config/app.yml

services:
  app:
    image: myapp:latest
    configs:
      - source: app_config
        target: /app/config.yml

2. 敏感凭证 (Secret) 注入

数据库密码、API 密钥等敏感数据切忌通过初始化脚本写入 volume 或文件系统，以防泄露。

推荐方案：

1
2
3
4
5
6
7
8
9

secrets:
  db_password:
    file: ./secrets/db_password.txt

services:
  app:
    image: myapp:latest
    secrets:
      - db_password

3. 定时任务与后台运维任务

例如：

• 定期数据备份
• 定期清理缓存与临时文件
• 容器销毁后的退出清理工作

这些任务并不属于“主应用启动前必须阻塞完成的必要依赖”，因此不适合放进 pre_start。

当前的设计限制

由于该特性还相对较新，在使用时需要注意以下局限性：

• 非副本级执行：pre_start 是针对服务整体执行一次，而非针对每个容器副本单独运行（目前尚不支持 per_replica: true 配置）。
• 部分挂载类型不兼容：多副本共享的命名卷（Named Volume）和绑定挂载（Bind Mount）能够完美适配；但对于每个实例完全独立的匿名卷或 tmpfs 挂载，pre_start 临时容器写入的数据是无法同步到主容器的。
• 扩容时不触发：当你执行扩容命令时（例如 docker compose up --scale app=3），新创建的副本容器不会再次触发 pre_start 执行。它依然只遵循“配置变更/强制重建”的触发逻辑。

因此，如果你的某些初始化逻辑（如本地缓存预热）必须在每一个容器副本里运行，目前请不要依赖 pre_start。

与 Kubernetes Init Containers 的区别

从概念上看，两者的目的非常一致：都在主业务容器拉起前执行前置准备。

但实现和能力上有所差异：

• Kubernetes (K8s) 的 Init Containers 是 Pod 级别的核心一等公民，高度契合云原生分布式调度，且天然对多副本容器进行各自初始化。
• Docker Compose 的 Init Containers 则是通过 pre_start 生命周期钩子实现的一种轻量级解决方案。它更契合单机部署、本地开发、小规模自托管（Self-Hosted）场景。

简单来说，Docker Compose 的 Init Containers 是为 Compose 场景量身定制的精简版初始化机制，小巧但十分够用。

最佳实践建议

在实际生产或开发环境使用 pre_start 时，建议遵循以下原则：

1. 绝对的幂等性：初始化脚本一定要做到“多次执行，结果一致”，随时准备应对重试和重建场景。
2. 严禁包含长驻进程：pre_start 的步骤必须是能在短时间内主动退出并返回 0 的任务，否则将无限期阻塞主服务的启动。
3. 区分生产与开发环境的迁移策略：虽然在 pre_start 中自动运行 migrate 很爽，但在生产环境中自动执行数据库迁移依然存在一定风险。建议重要线上项目通过独立的 CI/CD Pipeline 触发迁移。
4. 封装复杂逻辑为脚本：如果初始化流程复杂（包含多步判断和环境准备），建议封装为独立脚本（如 ./scripts/init.sh）放入容器，而在 compose.yaml 中只调用该脚本，避免配置文件过长。

1
2

pre_start:
  - command: ["./scripts/init.sh"]

总结

Docker Compose 的 Init Containers 终于解决了容器编排中长久以来的一个痛点：如何优雅地表达“启动前的必要前置步骤”。

我们可以将它的应用场景简单归纳为：

最后，让我们用一张直观的对比来看看引入这一新特性后的变化：

1
2
3
4
5
6
7
8
9
10
11

services:
  migrate:
    image: myapp:latest
    command: ["./manage.py", "migrate"]
    restart: "no"

  app:
    image: myapp:latest
    depends_on:
      migrate:
        condition: service_completed_successfully

1
2
3
4
5

services:
  app:
    image: myapp:latest
    pre_start:
      - command: ["./manage.py", "migrate"]

这就是 Docker Compose Init Containers 的终极奥义 —— 让初始化步骤，优雅地回到它真正属于的地方。

而 Paper Shaders 想解决的正是这个问题。

它是 Paper Design 团队开源的一组 零依赖 Canvas / WebGL Shader 组件，可以直接通过 npm 安装使用，也可以在 Paper 设计工具中可视化调整后导出代码。项目目前托管在 GitHub，采用 Apache 2.0 协议开源，官方定位是 “ultra fast zero-dependency shaders for your designs”。

Paper Shaders 是什么？

简单来说，Paper Shaders 是一套可以直接放进网页里的视觉特效组件库。

它把原本需要手写 GLSL、配置 WebGL 上下文、处理 Canvas 渲染循环的复杂过程，封装成了更接近普通前端组件的使用方式。对于 React 项目，你可以直接安装：

1

npm i @paper-design/shaders-react

如果不使用 React，也可以安装 vanilla 版本：

1

npm i @paper-design/shaders

官方 README 中也特别提醒，目前项目仍处在 0.0.x 版本阶段，可能会有破坏性更新，因此建议固定依赖版本。

它能做哪些效果？

Paper Shaders 内置了不少适合现代网站设计的视觉效果。官方示例站把它们大致分成几类：

图片滤镜类：
比如 paper texture、fluted glass、water、image dithering、halftone dots、halftone cmyk。

Logo 动画类：
比如 heatmap、liquid metal、gem smoke。

背景与动态效果类：
比如 mesh gradient、static mesh gradient、grain gradient、dot orbit、warp、spiral、swirl、waves、neuro noise、perlin、simplex noise、voronoi、metaballs、god rays 等。

这些效果很适合用在：

• Landing Page 首屏背景
• 产品官网 Hero 区域
• Logo 动效
• 文章封面图生成
• 开发者工具官网
• 设计感较强的 SaaS 页面
• 作品集网站
• 音乐、游戏、创意类项目页面

相比直接使用静态图片，Shader 的优势是可以实时渲染、动态变化，并且通常能保持更好的响应式适配能力。

所有效果都可以在项目官网：https://shaders.paper.design/ 预览并进行调整。

React 中如何使用？

Paper Shaders 的 React 用法非常接近普通组件。

例如官方 README 中给出的 MeshGradient 示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

import { MeshGradient, DotOrbit } from '@paper-design/shaders-react';

export default function App() {
  return (
    <>
      <MeshGradient
        colors={['#5100ff', '#00ff80', '#ffcc00', '#ea00ff']}
        distortion={1}
        swirl={0.8}
        speed={0.2}
        style={{ width: 200, height: 200 }}
      />

      <DotOrbit
        colors={['#d2822d', '#0c3b7e', '#b31a57', '#37a066']}
        colorBack="#000000"
        scale={0.3}
        style={{ width: 200, height: 200 }}
      />
    </>
  );
}

从这个例子可以看出，它并不要求开发者先理解完整的 WebGL 渲染流程，而是通过 colors、distortion、swirl、speed、scale 这类参数来调节视觉表现。对于设计师或前端开发者来说，这种抽象会更容易试错。

设计师友好的 Shader 工作流

Paper Shaders 最有意思的一点，不只是“提供了一堆 Shader 组件”，而是它试图打通 设计工具 → 前端代码 的流程。

项目 README 中提到，它的目标之一是让设计师可以用视觉化方式使用常见 Shader，并且最终产物可以直接导出为轻量代码，放进任意代码库中使用。

这点其实很重要。

很多网页视觉效果在设计稿里看起来很漂亮，但真正落地时会遇到几个问题：

设计师不知道如何描述 Shader 参数；
开发者不想从零写 WebGL；
设计稿里的动态效果很难准确还原；
最后只能用视频、GIF 或静态图片代替。

Paper Shaders 的思路是把 Shader 变成一种更“产品化”的设计资产：
设计阶段可以调，开发阶段可以直接用，最终上线时又不需要引入庞大的运行时依赖。

零依赖的意义

Paper Shaders 官方强调自己是 zero-dependency HTML canvas shaders。

这对前端项目来说很有吸引力。很多视觉动效库虽然效果强大，但往往会带来明显的 bundle 体积、依赖链和运行时复杂度。对于只想在首页加一个动态背景、给 Logo 增加一点高级感、或者做一个轻量交互效果的项目来说，引入完整 3D 引擎有时候显得太重。

Paper Shaders 的定位更轻：
它不是要取代 Three.js、R3F 或专业图形引擎，而是提供一组可以快速嵌入网页的高质量 Shader 效果。

开源协议与商业使用

Paper Shaders 使用 Apache 2.0 License。官方说明中提到，可以在商业网站、应用、游戏、视频、原型、内部工具和其他最终产品中使用，不要求可见署名。若将 Paper Shaders 代码作为另一个 Shader 库、插件或工具的一部分重新分发，则需要保留 LICENSE 和 NOTICE 文件。

这意味着它对个人项目、商业官网、SaaS 产品、内部工具都比较友好。

适合哪些项目？

我觉得 Paper Shaders 特别适合以下几类场景。

第一类是 想快速提升视觉质感的官网。
比如一个 AI 工具、设计工具、开发者平台或者 SaaS 产品首页，使用 Mesh Gradient、Grain Gradient、God Rays 这类效果，很容易让页面从“普通模板感”变得更有记忆点。

第二类是 需要动态 Logo 或品牌动效的项目。
Liquid Metal、Heatmap、Gem Smoke 这类效果非常适合做品牌展示，尤其适合科技、创意、设计类产品。

第三类是 不想写底层 WebGL 的前端项目。
如果你只是想要一个漂亮的 Shader 背景，而不是开发一套图形引擎，Paper Shaders 的组件化封装会比从零写 WebGL 轻松很多。

第四类是 设计师与开发者协作密集的团队。
如果设计师希望动态视觉效果不是“截图给开发者猜”，而是能直接变成可用代码，那么 Paper Shaders 的方向就很值得关注。

需要注意的问题

当然，它也不是万能的。

首先，Paper Shaders 目前版本号仍然处于 0.0.x，官方也明确建议固定依赖版本，因为这个阶段仍可能出现破坏性更新。

其次，Shader 本质上仍然是实时渲染效果。虽然官方强调轻量和高性能，但在实际项目中，仍然建议注意移动端性能、低端设备表现、电池消耗，以及是否会影响页面可读性。

最后，视觉效果不要滥用。Shader 很适合做氛围和品牌感，但如果整页都是动态纹理、噪声和闪动渐变，反而会影响内容阅读。

总结

Paper Shaders 是一个很有意思的开源项目。

它把原本偏图形编程领域的 Shader，封装成了更接近现代前端组件的形态：可以 npm 安装，可以 React 使用，可以调参数，也可以与设计工具结合。对于想给网站增加动态背景、纹理、Logo 动画和高级视觉效果的开发者来说，它提供了一条比手写 WebGL 更轻量的路径。

它并不是一个庞大的 3D 框架，而更像是一盒彩色墨水：
你不需要重新造画布，只需要把它滴进页面里，就能让原本平面的界面多一点流动感、颗粒感和生命力。

项目地址

• 官网：https://shaders.paper.design/
• GitHub：https://github.com/paper-design/shaders

无论输入还是输出，Sonnet 5 的单价都只有 Opus 的六成。但单价更低不代表实际更省——后面会提到，按实际任务成本衡量，Sonnet 5 完成同一任务反而可能花更多钱，这也是后面争议的根源。

Sonnet 5 相比 Opus 单价全面更低，又完成了一次大版本号的跃迁，你可能会有疑问，Sonnet 5 到底值得使用吗？

结论

这里直接上结论：

Sonnet 5 不适合直接作为默认模型使用，其性能不如 Opus 4.8，但是在写作方面获得了表现出色的评价。

因此对于大型、大规模代码编辑，直接使用 Opus 4.8 系列即可，如果预算充足则使用 Fable 5（7 月 7 日后 Claude Code Pro 订阅中将无法直接使用 Fable，需要按照 API 定价收费）。

当需要考虑费用成本、需要较新的知识库（已更新至 2026 年 1 月）时，以及在小型任务、写作任务中，可以切换为 Sonnet 5。

对于更简单的任务，使用其他更经济的模型即可覆盖。

Sonnet 5 是什么？

按照 Anthropic 官方新闻页的说法，Claude Sonnet 5 是 Sonnet 系列的新一代模型，定位是「面向编码、Agent 和专业工作的前沿性能模型」。Anthropic 将其放在 Sonnet 产品线上，而不是 Opus 或 Fable 这种更高阶、更昂贵的旗舰线，这本身就是一个信号：Sonnet 5 不是用来刷榜的模型，而是用来「天天用」的模型。

外媒报道也提到，Sonnet 5 被设计为一个更适合日常高频使用的模型，重点加强了浏览、编码、规划、知识工作和自主任务执行能力，并已同步面向 Claude Free、Pro、Max、Team、Enterprise 等所有订阅层级开放。这种「首发即全量」的铺开方式，也印证了它的定位：主力机型，不是尝鲜彩蛋。

简单说，Sonnet 5 不是「最高规格炫技模型」，而是 Anthropic 想推给大多数 Claude 用户的主力工作模型。

这和过去 Anthropic 对 Sonnet 系列的定位一致： 比 Haiku 强，比 Opus 便宜，适合作为日常主力。

社交媒体评价：完全不值

一张来自 Artificial Analysis 的「Cost per Intelligence Index Task」图表显示，Claude Sonnet 5 在 Max 思考等级 下的单任务成本明显高于 GPT-5.5、GLM-5.2、Kimi-K2.6、DeepSeek-V4-Pro 等模型，甚至高于 Opus 系列。于是有人直接总结：

Sonnet 5 直接扔进垃圾桶
比 Opus 4.8 Max 贵 1.2 倍
比 GPT-5.5-xhigh 贵 2 倍
比 GLM-5.2 贵 5 倍
比 Kimi-K2.6 贵 7 倍
比 DeepSeek-V4-Pro 贵 57 倍

对此 OpenClaw 的作者 Peter Steinberger 直接 评价： 每 Token 价格 != 实际任务成本 != 最终生产力成本。

由于 Sonnet 5 的智能没有实现很大进步，需要消耗更多的 Token 来完成任务，导致总消耗反而比 Opus 系列更多。

因此对于大型、大规模的代码编辑项目直接使用更高智能的 Opus 系列即可。

争议点：Sonnet 5 贵不贵？

贵。

尤其是放在 2026 年这个时间点看，Sonnet 5 的成本压力会比过去更明显。

Artificial Analysis 的成本图并不是单纯比较输入 / 输出 Token 单价，而是按 Intelligence Index 任务加权计算，包括 Input、Answer、Reasoning、Cache Write、Cache Hit 等不同 Token 类型。它试图回答的是：完成一个标准化智能任务，平均要花多少钱。

这就解释了为什么「看起来 API 单价差不多」的模型，实际任务成本可能完全不同。举个例子：如果一个模型平均需要 3 轮工具调用、每轮都要重新读一遍上下文才能完成任务，而另一个模型 1 轮就能给出可用结果，那么即使两者单价一致，前者的实际账单也会是后者的数倍——差距不是来自定价表，而是来自「模型解决问题需要绕多少路」。

一个模型如果：

• 输出更长
• 推理 Token 更多
• 工具调用链路更重
• 不擅长一次完成，需要反复修正
• Cache 利用率不高

那么它的实际成本就会被拉高。

这也是很多人吐槽 Sonnet 5 的原因：
Anthropic 的模型越来越像豪华燃油车，性能强，但开起来不便宜。

但只看单任务成本，也容易误判

问题在于，开发者真正关心的往往不是「跑一次 Benchmark 花多少钱」，而是：

它能不能少折腾我？

对写代码、重构项目、分析仓库、修 Bug、跑 Agent 来说，模型成本只是总成本的一部分。更重要的是：

• 第一次方案是否靠谱
• 是否理解大型项目上下文
• 是否会乱改无关文件
• 是否能保持长期任务稳定
• 是否能自己发现问题并修正
• 是否减少人工 review 和返工

如果 Sonnet 5 在这些方面明显强于便宜模型，那么它即使「每次任务更贵」，最终仍然可能更划算。

打个比方：假设一个中型重构任务，便宜模型单价是 Sonnet 5 的五分之一，但因为理解不了项目边界，需要反复试错 6 轮才能勉强跑通，且中途还改坏了两个无关文件，需要你手动回滚；而 Sonnet 5 单价更高，但 2 轮就能给出可用方案，且不会牵连其他文件。算上你自己排查、回滚、二次确认的时间成本，便宜模型的「总成本」未必比 Sonnet 5 低——只是这部分成本没有出现在账单上，而是变成了你的时间。

这就像云服务器：

便宜的很便宜，但如果一天炸三次、IO 抽风、网络绕路，最后浪费的是人的时间。

AI 模型也是一样。

Sonnet 5 真正的价值：Agent 和代码工作流

从 Anthropic 的宣传重点看，Sonnet 5 最核心的卖点不是普通聊天，而是 Agentic Workflows。

也就是让模型不只是回答问题，而是能连续执行任务：

• 阅读项目文件
• 理解现有架构
• 制定修改计划
• 调用终端
• 修改代码
• 跑测试
• 根据报错继续修
• 最后总结变更

这正是 Claude Code、Cursor、Windsurf、OpenClaw 这类工具最依赖的能力。

对这类场景来说，模型的「听话程度」「上下文稳定性」「工具调用判断」往往比单纯的知识问答更重要。Anthropic 过去几代 Sonnet 在代码 Agent 场景中口碑一直不错，Sonnet 5 如果继续强化这条路线，那它仍然会是开发者绕不开的模型。

尤其是复杂项目里，很多模型不是不会写代码，而是：

• 看不懂项目边界
• 喜欢重写整个文件
• 改 A 坏 B
• 测试失败后开始胡猜
• 上下文一长就开始失忆
• 看到报错只会重复同一个错误修法

如果 Sonnet 5 能减少这些问题，那么它就不是单纯的「贵」，而是「贵但省心」。

那它适合所有人吗？

不适合。

如果你的需求只是：

• 翻译
• 摘要
• 写普通文章
• 生成短代码片段
• 问一些常识问题
• 做轻量客服 QA
• 批量处理低价值文本

那 Sonnet 5 很可能不是性价比最高的选择。

这类任务已经进入「模型过剩」阶段。GLM、Kimi、DeepSeek、GPT 的中低价模型都能做得不错。尤其是批量任务，成本差距会被无限放大。

比如一篇博客摘要、一个 JSON 转换、一个普通 SQL 生成任务，Sonnet 5 的优势可能并不能抵消它的成本。

这时候更合理的策略是：

便宜模型跑基础任务，Opus / Fable 系列处理大型复杂的任务，当有成本考虑是，将一些中阶的小规模任务交给 Sonnet 5 处理。

我的建议：不要把 Sonnet 5 当默认模型无脑用

Sonnet 5 最适合的使用方式，不是「所有请求都丢给它」，而是把它当成一个经济型的工作模型。

可以这样分层：

1. 普通文本任务：不用 Sonnet 5

翻译、润色、改标题、写摘要、生成普通 Markdown，用便宜模型就够了。

这些任务对推理深度、工具调用、项目理解要求不高，用 Sonnet 5 属于杀鸡用牛刀。

2. 一般代码片段：看情况

写一个简单函数、改一个 CSS、生成一个 Docker Compose，便宜模型也能胜任。

但如果它开始反复出错，或者你已经花了 10 分钟纠错，那就应该可以尝试切换 Sonnet 5。

便宜模型最贵的地方，是让你以为它快好了。

3. 中小型代码任务：可以用 Sonnet 5

例如：

• 修改单个页面
• 补一个组件
• 写一个脚本
• 修一个明确报错
• 添加一个简单 API
• 生成测试用例
• 对已有代码做小范围重构

这类任务的特点是边界清晰、上下文较短、失败成本较低。Sonnet 5 在这里可以发挥 Claude 系列一贯的代码理解和指令遵循能力，同时比 Opus 4.8 单价更低。

如果任务本身不复杂，用 Opus 4.8 反而有些浪费；但如果用更便宜的模型反复出错，Sonnet 5 就是一个不错的折中选择。

它适合处理「需要一点智能，但还不值得动用最高智能模型」的代码任务。

4. 大型项目的开发与重构：直接使用更高智能的模型

如果你的目标不是修一个小 Bug、改一个组件、写一段脚本，而是让 AI 参与实现一个完整项目，那么 Sonnet 5 反而不一定是最优选择。

这类任务通常包括：

• 从零搭建一个完整应用
• 设计项目架构
• 实现多模块功能
• 连续修改几十个文件
• 处理数据库、鉴权、状态管理、路由、部署配置
• 长时间运行 Claude Code / Codex / OpenClaw 这类 Agent 工具

在这种场景里，模型最重要的不是「单价低」，而是「一次做对的概率高」。

大型项目的成本并不只是 Token 成本，而是由多部分组成：

• 模型理解需求的成本
• 模型维护上下文的成本
• 多轮修改产生的返工成本
• 改错文件带来的回滚成本
• 测试失败后的排查成本
• 人工 review 和补救的时间成本

如果一个模型智能略低，它可能每一步看起来都能做，但组合起来就会出现问题：前面设计的架构后面忘了，刚写好的接口下一轮又被改坏，A 页面修好了 B 页面挂了，最后整个项目进入「能跑但不敢碰」的状态。

这也是为什么在大型项目里，应该优先使用 Opus 4.8、Fable 5 这类更高智能模型。

它们的单价更高，但在复杂任务中更容易保持全局一致性，能减少无效尝试和重复修复。尤其是当任务涉及架构设计、跨文件重构、测试修复和长期上下文时，更高智能模型带来的稳定性往往比价格差异更重要。

Sonnet 5 更适合做局部任务：
比如写一个页面、改一个模块、生成一段文案、补一个测试、修一个明确的报错。

但如果你要让 AI 从头到尾实现一个大型项目，尤其是需要连续运行 Agent 多小时，那么更合理的策略是：

直接使用 Opus 4.8 或 Fable 5，不要为了省一点单价把项目交给 Sonnet 5 硬跑。

因为大型项目里最贵的不是模型，而是模型犯错之后你还要继续相信它。

Sonnet 5 的问题：Anthropic 还是那个 Anthropic

Sonnet 5 的发布，也再次暴露了 Anthropic 的老问题：

模型很好，但生态和价格让人焦虑。

Claude 的体验一直很强，尤其是代码和长上下文任务。但 Anthropic 在可用性、额度、区域、订阅限制、API 成本和第三方工具支持上，始终不像 OpenAI 那样稳定。

更重要的是，随着 AI Agent 消耗越来越大，「订阅制无限用」这件事本身就越来越难持续。此前已有分析指出，重度 AI 用户实际消耗的 API 等价成本可能远超订阅价格——一个长期跑 Agent 任务的开发者，一天消耗的 Token 换算成 API 价格可能就超过月费本身。这意味着 AI 公司未来很可能继续向更细粒度、更接近成本的计费方式调整，比如更严格的用量上限、分层限速，或者像 Sonnet 5 这样在输出端悄悄提价。

所以 Sonnet 5 的问题不是单个模型贵，而是代表了一种趋势：

好模型会越来越强，但真正便宜随便用的时代正在结束。

一句话总结

Sonnet 5 不是便宜模型，也不是最强模型，而是一个适合写作和中小型任务的 Claude 日常模型。 它在代码编辑领域没有找到一个足够舒服的位置：便宜任务轮不到它，复杂任务又不如直接上 Opus / Fable。

如果你把它当成 Opus 的廉价替代品，可能会失望；
如果你把它当成一个更适合日常文本和轻量工作的 Sonnet，它依然值得放进工具箱。

过去，这类项目往往需要拆成多个 Vercel Project，或者把部分服务放到其他平台上运行。项目一多，域名、环境变量、Preview URL、跨服务调用、CORS、路由转发都会变复杂。

Vercel 最近推出的 Vercel Services，就是为了解决这个问题：它允许开发者在一个 Vercel Project 中部署多个独立构建的服务，并通过统一的路由规则把请求分发到不同服务中。

换句话说，一个项目里可以同时放：

• Next.js 前端
• FastAPI 后端
• Go API 服务
• Astro 文档站
• Vite / React 管理后台
• 其他独立构建单元