本周两个值得关注的 Agent 工程化项目设计规范文件与开源视频生产流水线摘要本周推荐两个和 Agent 落地很相关的 GitHub 热门项目google-labs-code/design.md让 coding agent 用结构化方式理解视觉设计系统减少“看起来差不多但总是不对”的前端还原问题calesthio/OpenMontage则把视频生产拆成研究、脚本、素材、剪辑、合成、质检等阶段让 AI 编程助手变成可审计的视频制作流水线。一个解决“Agent 怎么稳定理解设计规则”一个解决“Agent 怎么稳定完成复杂创作流程”。雷猴啊朋友们! 这周我挑的两个项目都不是单纯“又一个 AI 工具”。它们更像在回答同一个问题当 Agent 不只是聊天而是真的要参与生产哪些规则必须被写清楚、可检查、可复用一个是 Google Labs 开源的DESIGN.md它把品牌视觉、颜色、字体、圆角、间距、组件规则写成 Agent 能读懂的格式另一个是OpenMontage它把视频制作变成一套 Agent 可以执行、复盘、质检的工程流程。如果你做前端、做内容、做自动化或者正在尝试让 Codex、Claude Code、Cursor 这类工具真正参与日常工作这两个项目都值得看一眼。1. google-labs-code/design.md给 coding agent 一份稳定的设计系统说明书GitHub 地址google-labs-code/design.mdDESIGN.md是 Google Labs 开源的一个格式规范用来描述视觉身份和设计系统。它的目标很明确让 coding agent 不只是“凭感觉”写 UI而是能读取一份长期存在、结构清楚、可校验的设计说明。它的文件结构很有意思顶部是 YAML front matter写机器能精确读取的 design tokens下面是 Markdown 正文写给人和 Agent 都能理解的设计理由。也就是说颜色、字体、圆角、间距这些值有明确字段为什么用这个配色、什么场景该强调、组件应该有什么气质则用自然语言补充。它解决什么问题前端项目里Agent 最容易出问题的地方之一就是“风格漂移”。你可能已经遇到过这种情况第一次让 Agent 改页面还可以第二次它开始加大圆角第三次加渐变第四次又换了一套阴影。每次单看都不算错但放在同一个产品里就很割裂。传统设计系统一般写在 Figma、文档站、组件库或者团队脑子里。人可以看懂但 coding agent 往往只能从现有代码里猜。它不知道一个品牌为什么只用一个强调色也不知道按钮 hover 状态应该从哪个 token 派生更不知道某个产品到底是“企业后台的克制风格”还是“内容社区的活泼风格”。DESIGN.md的价值就在这里把这些规则变成一个 Agent 可以稳定读取的文件。它不是替代设计师也不是替代组件库而是给 Agent 一个明确上下文减少每次改 UI 时重新猜风格。核心工作流它的基本使用方式可以拆成四步在项目里写一份DESIGN.md。用 YAML front matter 定义颜色、字体、圆角、间距和组件 token。用 Markdown 正文解释视觉方向、使用原则、组件习惯和不要做什么。让 coding agent 在写前端代码前先读取这份文件并用 CLI 做校验、比较和导出。项目提供了一个 npm 包google/design.md可以做几件实用的事lint检查文件结构、token 引用、颜色对比度、章节顺序等问题。diff比较两份设计系统文件发现 token 变化和潜在回退。export把 token 导出成 Tailwind v3、Tailwind v4 CSS 变量或 DTCG tokens.json。spec输出规范内容方便塞进 Agent 提示词或工具上下文里。这些能力看起来不复杂但很适合放进真实工作流。比如你让 Agent 改一个落地页它先读DESIGN.md知道主色、辅助色、字体、按钮规则和设计气质改完之后再跑designmd lint DESIGN.md或对比新旧设计文件至少能发现 token 引用断了、组件颜色对比度不够、章节顺序乱了这类问题。适合哪些人我觉得它最适合三类场景。第一类是经常用 Agent 写前端的人。尤其是你已经不满足于“生成一个能跑的页面”而是希望页面和现有产品风格一致。DESIGN.md可以把“不要随便加渐变”“主操作只能用这个强调色”“卡片圆角不要超过 8px”这些偏审美又偏规范的东西写清楚。第二类是有多个前端项目的小团队。很多团队没有完整设计系统但其实有稳定偏好品牌色、字号层级、按钮样式、卡片密度、后台页面的克制程度。把这些写进DESIGN.md比每次在 prompt 里重复一遍更稳。第三类是维护组件库或设计规范的人。它可以作为 Figma、组件库文档之外的一层 Agent-friendly 规范让 AI 工具在读代码之前先读“设计意图”。不适合哪些人如果你的项目很小只是一次性活动页或者你根本不在乎多次迭代后的视觉一致性那它可能有点重。如果你的团队已经有非常成熟的 design token 管线、Figma Tokens、Style Dictionary、组件库文档和自动化检查也不一定要立刻迁移到DESIGN.md。更现实的用法是先把它当作 Agent 上下文文件而不是替换现有系统。另外它目前还是 alpha 状态。README 里也明确提到规范、schema 和 CLI 都还在发展。对于生产团队来说最好先在非核心项目里试一试不要一上来就把它当成不可变标准。上手条件与采用门槛采用难度中等偏低。如果你熟悉 Markdown 和 YAML写第一版并不难。真正需要思考的是哪些规则应该写成 token哪些规则应该写成说明。比如颜色、字体、圆角、间距适合写成 token“产品气质偏专业克制”“后台页面不要做营销式 hero”“主按钮只用于明确提交行为”这种判断就适合写在正文里。Windows 用户还要注意一个小坑README 里提到直接运行design.md这个 bin 名可能会和 Windows 的 Markdown 文件关联冲突所以 PowerShell 下建议用designmd这个别名。这个细节对跨平台团队挺实用说明项目作者确实考虑了真实开发环境。局限与取舍DESIGN.md解决的是“Agent 能不能读懂设计系统”不是“Agent 能不能自动变成优秀设计师”。如果你写进去的规则本身很含糊比如“高级一点”“好看一点”“科技感一点”Agent 还是会猜。它真正适合承载的是可复用、可解释、可检查的设计约束。还有一个取舍是维护成本。设计系统会变token 会改组件会演进。如果DESIGN.md不跟着更新它反而会给 Agent 错误上下文。所以更好的方式是把它和代码评审、组件库更新、设计规范变更放在一起维护。一句话判断如果你经常让 Agent 写前端而且在意长期视觉一致性DESIGN.md值得放进项目根目录如果只是一次性页面生成它可以先收藏不必马上引入。2. OpenMontage把 AI 视频制作变成 Agent 可执行的生产流水线GitHub 地址calesthio/OpenMontageOpenMontage的定位很直接开源的 agentic video production system。它不是只给你一个“文生视频”入口而是把视频生产拆成一套完整流程让 AI coding assistant 去编排研究、脚本、素材、配音、音乐、剪辑、合成和质量检查。这个项目吸引我的地方不是它声称能生成多炫的视频而是它把视频制作当成工程流程来处理。README 里反复强调 pipeline、provider selection、quality gates、decision audit trail、budget controls。这些词很工程化也很适合 Agent 时代。它解决什么问题现在很多 AI 视频工具的问题是入口很简单过程很黑盒。你输入一句 prompt平台吐出一个片段。能不能复现、素材怎么来的、脚本为什么这么写、成本多少、有没有字幕、画面是不是只是幻灯片动了动这些都不容易控制。OpenMontage的思路刚好相反让 Agent 像一个制作统筹一样做事。它先选 pipeline再读 stage skill再调用具体工具过程中做预算、做检查、做记录最后再渲染输出。它支持的方向比较多比如 animated explainer、cinematic、documentary montage、screen demo、podcast repurpose、localization、talking head 等。更关键的是它不只依赖付费视频模型。项目里提到零 API key 的情况下也能用 Piper TTS、Archive.org、NASA、Wikimedia Commons、Remotion、FFmpeg 等工具做出基于真实素材或图片动画的视频。核心工作流它的工作流大致可以理解成用户给 Agent 一个视频需求比如“做一个 60 秒神经网络科普视频”。Agent 读取 pipeline manifest确认要走哪个生产流程。Agent 读取对应 stage director skill知道每个阶段怎么做。系统做研究、脚本、场景计划、素材生成或素材检索。根据任务选择 Remotion、HyperFrames、FFmpeg 等渲染方式。渲染前做 pre-compose validation避免承诺和实际素材不匹配。渲染后用 ffprobe、抽帧、音频分析、字幕检查等方式自检。通过检查后才把最终视频交给用户。这套流程最有价值的地方是它把“AI 创作”拆成了可审查的中间步骤。比如 provider 为什么选这个成本大概是多少有没有替代方案某个视频是否真的用了 real footage这些都可以留下记录。适合哪些人我会优先推荐给三类人。第一类是技术型内容创作者。比如你想稳定做 AI、编程、产品教程、开源项目介绍不想每条视频都从剪辑软件里手搓。OpenMontage 的 screen demo、animated explainer、documentary montage 这些 pipeline 会很有参考价值。第二类是会用 Codex、Claude Code、Cursor 这类 coding assistant 的开发者。这个项目本身就是 agent-first 架构README 里也明确提到 Codex、Claude Code、Cursor、Windsurf 等工具。你需要的不是一个只会点按钮的 SaaS而是一个能在本地跑、能读文件、能执行脚本、能修改流程的 Agent 工作台。第三类是想研究“复杂 Agent 项目怎么组织”的人。它的目录结构里有tools/、pipeline_defs/、skills/、schemas/、styles/、remotion-composer/等模块。即使你暂时不做视频也可以学习它怎么把工具能力、流程定义、技能说明、质量标准分层。不适合哪些人如果你只是想快速做一个短视频不想装 Python、Node.js、FFmpeg也不想理解 pipeline那它不一定适合。成品 SaaS 可能更省事。如果你期待“一句 prompt 直接出片不要问我任何中间决策”它也不是最轻的选择。OpenMontage 强调人类批准、成本估算、质量检查和决策记录这会让流程更稳但也会比黑盒工具更重。还有一个现实点它是 AGPLv3 协议。个人学习和开源使用问题不大但如果公司要把它深度集成到商业系统里最好先认真看许可证和合规要求。上手条件与采用门槛采用难度中等偏高。基础依赖包括 Python 3.10、FFmpeg、Node.js 18还需要一个能读文件和执行命令的 AI coding assistant。项目提供make setup没有 make 的环境也给了手动安装命令。Windows 用户要注意如果npm install遇到ERR_INVALID_ARG_TYPEREADME 建议用npx --yes npm install。API key 是可选的。你有 FAL、ElevenLabs、OpenAI、Google、Runway 等 key能接更多生成能力没有 key也能走本地 TTS、开源素材、Remotion、FFmpeg 这些免费路径。真正的门槛不是安装而是工作方式。你需要接受这样一个流程先做需求和 pipeline 选择再产出计划再生成素材再渲染再质检。它更像“开源视频制作系统”不是“网页上点一下生成视频”。局限与取舍OpenMontage的优势是可控、可审计、可扩展代价是复杂。视频生产本来就是多阶段任务脚本、素材、声音、字幕、节奏、画面质量、版权、成本每一项都可能出问题。OpenMontage 把这些问题显式暴露出来是优点也是学习成本。另外README 里展示的成本和样例属于项目方示例。具体到你的机器、你的 API key、你的视频长度、你选择的 provider成本和效果都会变。实际采用前最好先从 30 秒以内的小 demo 开始不要一上来就做长视频。一句话判断如果你想研究或搭建“可控的 AI 视频生产流水线”OpenMontage很值得试如果你只想偶尔生成一个简单短片成品视频工具会更轻。两个项目放在一起怎么看维度DESIGN.mdOpenMontage主要目标让 Agent 稳定理解视觉设计系统让 Agent 编排完整视频生产流程典型输入设计 token、组件规则、视觉说明视频需求、pipeline、素材和 provider 配置输出结果可校验的设计规范、可导出的 token可渲染的视频项目、决策记录和质检结果更适合前端项目、设计系统、组件库、品牌一致性内容生产、视频自动化、复杂 Agent 流程研究上手门槛Markdown YAML npm CLIPython Node.js FFmpeg Agent 工作流最大优势把审美和规范变成 Agent 可读上下文把创作过程拆成可审查的工程流水线主要风险规范维护不及时会误导 Agent系统复杂安装和流程理解成本较高我的建议放到前端项目根目录试用先跑短 demo再评估是否接入内容生产这两个项目看起来方向不同但底层思路很像不要只相信 prompt要把生产规则沉淀成文件、schema、pipeline、检查器和可复盘记录。DESIGN.md更轻适合从一个项目文件开始。你可以先写一份设计规范让 Agent 下次改 UI 前必须读取。OpenMontage更重适合研究复杂 Agent 工作流。它提醒我们真正复杂的创作任务不能只靠一句 prompt而要拆成多个阶段每个阶段都有工具、约束、检查和记录。使用建议从“给 Agent 规则”开始如果你现在就在用 Codex、Claude Code 或 Cursor我建议这样试第一步先在一个前端项目里写DESIGN.md。不用追求完整把颜色、字体、圆角、按钮、页面密度和禁用风格写清楚即可。然后让 Agent 修改页面前先读它。第二步把designmd lint放进本地检查或 CI。哪怕只检查 token 引用和对比度也比完全靠肉眼稳。第三步如果你对内容自动化感兴趣再试 OpenMontage。先不要追求大片做一个 30 秒技术解释视频观察它的 pipeline、stage skill、provider selection 和质量检查是怎么组织的。第四步把这两个项目的思想迁移到自己的自动化里。比如写作自动化也可以有选题规则、历史去重、生成步骤、审稿评分、发布前检查和失败记录。Agent 工作流越长越需要这些显式状态。结论本期可以这样取舍做前端、设计系统、品牌页面的人优先看DESIGN.md。它小而实用能直接改善 Agent 改 UI 时的风格一致性。做视频、内容自动化、Agent 工作流研究的人收藏OpenMontage。它的工程组织方式比“能不能生成视频”本身更值得学习。如果你只想找一个轻量工具先从DESIGN.md开始如果你想研究复杂 Agent 系统OpenMontage会更有启发。我的总体判断是Agent 真正进入生产环境后最重要的不是“它会不会回答”而是“规则在哪里、状态在哪里、检查在哪里、失败后怎么恢复”。DESIGN.md和OpenMontage都在用自己的方式回答这个问题。记得点赞、收藏、关注。推荐标签GitHub、开源项目、AI工具、Coding Agent、前端设计、设计系统、视频生成、Agent工作流、自动化、Remotion