2万字复盘：我们用 AI 编程做出商业级视频 Agent 平台

2万字复盘：我们用 AI 编程做出商业级视频 Agent 平台 2万字复盘：我们用 AI 编程做出商业级视频 Agent 平台 Modified March 2 Code block Plain Text 任务 4：创建 useViduGeneration Hook 输入：参考 useSoraGeneration 的模式 输出：封装生成流程 + 轮询状态 + R2 持久化 约束：使用 TaskQueueService 控制并发 当任务拆到这个粒度，Codex 3.3 Ultra High 基本可以一次性搞定。 10.4 "收菜"的标准动作 "收菜"不是随便看看就完事了。我现在的标准动作是： Code block Plain Text 1. 查看 diff：AI 改了哪些文件？每个文件改了什么？ 2. 编译检查：npm run build 是否通过？ 3. 逻辑审查：核心业务逻辑是否符合预期？ 4. 边界检查：异常情况处理是否完善？ 5. 风格检查：代码风格是否符合项目规范？ 6. 测试跑通：被修改模块的全量功能测试 7. 关联检查：修改是否影响了其他模块？ 十一、架构设计中的关键决策 11.1 Agent + Pro 双驱动 这是整个平台最核心的交互设计： 两个模式共享分镜数据，Agent 操作的结果会自动同步到 Pro 的聊天历史（通过 metadata.source = 'agent sync' 标记）。 11.2 统一视频任务表 早期 Sora 任务用单独的表。后来引入 Vidu、即梦视频后，我们选择统一——在 sora tasks 表增加 provider 字段： Code block SQL provider: 'sora' | 'vidu' | 'jimeng' | 'volcano' | 'runway' 好处是巨大的： • 所有任务的状态轮询、R2 转存、失败重试逻辑可以复用 • 后续新增视频提供商只需要增加一个 provider 值 • 管理后台只需要维护一套界面 11.3 三级聊天历史 Code block Plain Text Project 级别 → Planning 阶段的对话 Scene 级别 → 场景级 Grid 生成历史 Shot 级别 → 单个分镜的 Pro 模式对话 11.4 积分系统的二次确认机制 AI Agent 最怕的就是一句话烧光积分。我们实现了前置拦截： Code block Plain Text 用户发指令 → Agent 预检意图 → 积分预估 → UI 弹窗确认 → 同意后才执行 当任务拆到这个粒度，Codex 3.3 Ultra High 基本可以一次性搞定。 10.4 "收菜"的标准动作 "收菜"不是随便看看就完事了。我现在的标准动作是： 十一、架构设计中的关键决策 11.1 Agent + Pro 双驱动 这是整个平台最核心的交互设计： 两个模式共享分镜数据，Agent 操作的结果会自动同步到 Pro 的聊天历史（通过 metadata.source = 'agent sync' 标记）。 11.2 统一视频任务表 早期 Sora 任务用单独的表。后来引入 Vidu、即梦视频后，我们选择统一——在 sora tasks 表增加 provider 字段： 好处是巨大的： • 所有任务的状态轮询、R2 转存、失败重试逻辑可以复用 • 后续新增视频提供商只需要增加一个 provider 值 • 管理后台只需要维护一套界面 11.3 三级聊天历史 11.4 积分系统的二次确认机制 AI Agent 最怕的就是一句话烧光积分。我们实现了前置拦截： 甚至考虑了模型抽风的情况——如果模型跳过 ToolCall 直接回复文本，中间件会自动检测并阻止虚假执行。 11.5 技术选型的"为什么" 十二、给 AI 视频创业者的建议 12.1 开发节奏 1. 第一周：不写代码。画架构图，写技术方案文档，定义数据模型 2. 第二周：搭骨架。核心服务接口、API 路由结构、数据库 Schema 3. 第三周起：按优先级填充功能 4. 始终保持：文档和代码同步更新，每次部署前全量回归测试 12.2 必须从 Day 1 就考虑的事 [ ] 临时 URL 持久化 → 底层拦截机制 [ ] 多提供商支持 → 统一任务表、统一状态管理 [ ] 认证与积分 → 从架构层保证，不是后面"加上去" [ ] 错误监控 → Sentry 或 LogRocket，主动发现问题而非被动等用户反馈 [ ] Git 分支策略 → main 只接受合并，永远不直接提交 [ ] 文档体系 → README + AGENTS + 开发规范，第一天就建立 [ ] 设计规范 → 颜色、字体、组件样式、间距、动效，统一定义 12.3 AI 编程工具选择 12.4 创业心态 1. 不要什么都自己做：你的时间是最稀缺的资源，核心创新自己做，标准化系统外包 2. 不要追求完美的 v1：先验证商业假设，再追求技术完美 3. 不要轻视规范：越复杂的项目，规范节省的时间越多 4. 不要忽视测试：生产环境的 bug 修复成本是开发环境的 10 倍 5. 不要独自苦熬：AI 编程模型在不断进步，彻夜 Vibe Coding 更可能是方式不对，而不是你不够努力 十三、不要自我感动：个人开发者最大的陷阱 13.1 技术思维 vs 用户视角 这是我要对所有个人开发者、技术型创业者说的最重要的话：不要自嗨，要有用户视角。 个人开发者最容易陷入"技术思维"——觉得某个功能在技术上很酷、某个架构很优雅、某个优化很精妙……但用户根本不在乎这些。用户只关心： 1. 这个工具能不能帮我更快地出片？ 2. 操作是不是足够简单？ 3. 生成的质量是不是够好？ 我有段时间就完全陷入了技术思维——花了大量时间在 Hook 架构重构、API 响应标准化、Cron 双阶段异步……这些在工程上确实很重要，但它们不是用户能感知到的价值。 真正应该做的是先评估好优先级，把自己累个半死做了一堆用户感知不到的基建，不如先把核心体验做到极致。 13.2 被代码困住的创业者 我有一段时间的状态是这样的：每天除了吃饭睡觉就是编程。 AI 编程确实让你"觉得"效率很高，但人反而被 AI 困住了——不断地对话、调试、修 bug、优化、又对话…… 问题在于你在用战术上的勤奋，掩盖战略上的懒惰。 我最多熬一两个夜，但这会严重影响后续的思维决策能力和身体状态。 凌晨 2 点做出的设计决策，质量远不如白天精力充沛时做的。 13.3 AI 是不眠不休的，但你不是 这是我最核心的反思：AI 是不眠不休的工作者，我们要做的是在更高层级把方法论、架构、规范设计好，然后让 AI 发挥自动化的能力。 特别值得一提的是，Claude 非常适合写文档。 我现在的做法是：用 Claude 来起草技术方案、架构文档、API 设计、甚至这篇复盘文章——它在结构化写作上非常全面和深入。 你告诉它你的想法和骨架，它能帮你扩展成一篇完整的、逻辑严密的文档。 你的精力应该花在三件事上： 1. 思考：想清楚做什么、不做什么、优先级是什么 2. 设计：架构、接口契约、数据模型、用户体验 3. 验收：审查 AI 的产出、做关键决策、处理边界情况 至于"把代码写出来"这件事——交给 AI。 13.4 保护好你自己 几条朴素但重要的建议： 1. 不要连续熬夜：一两个晚上的加班，需要三四天来恢复思维清晰度 2. 设定每日截止时间：到点就停，明天 AI 还在，你的身体不等你 3. 定期跳出代码看全局：每周花半天不写代码，只思考产品方向 4. 找人聊：个人开发者最怕的是自嗨，不妨找用户、找同行聊聊 5. 运动：没什么比健康的身体更重要的了 十四、写在最后 回顾这段旅程，我从一个知道 AI 编程是怎么回事的人，进化成了一个深度结合 AI 编程完成商业级项目的人。 核心感悟有以下七点： 1. AI 编程的效率瓶颈不在 AI，而在你的需求描述能力。 Codex 3.3 Ultra High 已经足够强了。但如果你给它一句"帮我做个视频生成功能"，它不可能做出你想要的东西。你需要把需求拆到"任何一个合格的程序员都能无歧义执行"的粒度。 2. 架构设计的时间投入，ROI 是最高的。 我花一两个月打补丁走的弯路，如果用两三周来做架构设计，可以完全避免。前期感觉"设计"比"写代码"慢，但长期看它是最快的路。 3. 文档是你递给 AI 的说明书，说明书越好，产出越好。 我的 AGENTS.md（750 行）和 CLAUDE.md（1600 行）不是废话堆砌，而是经过反复打磨的"开发哲学 + 技术约束 + 设计决策"的结晶。每次新功能开发，AI 读了这些文档后，产出的代码就像是项目原生的一样。 4. 测试不是可选项，是生命线。 改了什么就全量测试什么。我因为"觉得只是小改动"跳过测试而引入的生产环境 bug，远比我因为"功能没做完"而延迟发布造成的损失更大。 5. 专业的事交给专业的人。 别什么都自己做，别什么都 Vibe Coding。AI 编程让你能做更多事，但不意味着什么事都该你做。把非核心系统外包给专业团队，你的时间和精力应该放在核心竞争力上。 6. 不要自我感动，要有用户视角。 你觉得很酷的技术方案，用户可能完全无感。评估好优先级，先做用户能感知到价值的功能，再做工程基建。 7. AI 不眠不休，但你需要休息。 在更高层级做好设计，让 AI 去执行。你的精力应该花在思考、设计和验收上，而不是跟 AI 一起熬夜 Vibe Coding。保护好你的身体和决策能力，它们比任何代码都重要。 Video Agent Pro 仍在迭代中。从 v0.1 到 v4.0.6，它教会我的不仅是技术，更是：做产品的耐心、做架构的远见、测试的纪律、用户视角的坚持、以及驾驭 AI 工具的方法论。 AI 编程工具在变得更强大——OpenClaw、Codex、Antigravity……但工具的强大，终究需要使用者自身的成长来匹配。 而成长的前提是：你得保持清醒、保持健康、保持对用户价值的敏感。 希望这篇复盘能帮你加速这个过程 🤝 AI 编程工具在变得更强大——OpenClaw、Codex、Antigravity……但工具的强大，终究需要使用者自身的成长来匹配。 而成长的前提是：你得保持清醒、保持健康、保持对用户价值的敏感。 希望这篇复盘能帮你加速这个过程 🤝 西羊石团队 · 2026 年 3 月 作者：西羊石团队 日期：2026 年 3 月 项目：Video Agent Pro v4.0 关键词：AI 视频生成、Vibe Coding、Antigravity Tools、Codex、OpenClaw、创业复盘 写在前面 这是我创业以来真正意义上的第一个商业级别 AI 视频平台。 从 2025 年底的 v0.1，到 2026 年 3 月的 v4.0.6——28 个 Agent 工具、41 个 API 端点、6 个 AI 模型集成、一套完整的积分系统和认证体系…… 回头看这段旅程，我想把整个过程中踩过的坑、用过的工具、悟出的方法论，全部分享出来。 虽然这个平台目前主要是内部使用，帮助团队高效地调用 Google Gemini（纳米香蕉）、Sora、Vidu 等平台来生产 AI 视频内容，但一个创业者的第一个能跑的产品，以及真正帮助团队快速制作AI短剧，总是有特殊的意义。 这篇复盘不仅关于技术，更关于创业认知、团队协作、工程规范的全面反思。 希望能让后来的同行者少踩一些坑。 一、项目全貌：我们到底做了什么 1.1 产品定位 Video Agent Pro 是一个 AI 驱动的影视分镜生成与编辑工具。核心理念是：让视频创作者从剧本到成片，每一步都有 AI 辅助。 技术栈： 前端：Next.js 15.1 + React 19 + TypeScript 5.8 + Tailwind CSS 后端：Vercel Serverless + Next.js App Router（41 个 API 端点） 数据层：Supabase PostgreSQL + Cloudflare R2（媒体存储） AI 模型：Gemini 3.1 Pro/Flash Image、Sora 2、Vidu、火山引擎 SeeDream/SeeDance、即梦 1.2 核心功能矩阵 整个产品覆盖了影视创作的三个阶段，对应三个核心视图： 每个视图都支持 Agent（自然语言对话）+ 精细参数控制 双驱动模式，这是我们在架构上的一个核心设计决策。 功能上，从剧本 AI 分镜、角色三视图生成、Grid 多视图分镜图生成、Sora/Vidu 视频批量生成，到完整的积分计费系统、角色一致性追踪、R2 媒体持久化管道……可以说该有的都有了，就等着Seedance2.0的API接入。 1.3 规模感知——真实数据 服务层：22+ 独立服务文件，涵盖 Agent 推理、图片生成、视频编排、任务管理等 数据层： 一个文件封装了 97 个方法 Agent 工具：28 个 Function Calling 工具，支持并行执行 Hook 架构：22 个 Custom Hooks，仅 Chat 相关就有 12 个 Changelog：从 v0.1 到 v4.0.6，累计 30+ 个版本迭代记录 文档体系： 目录下 30+ 份架构文档 这些数字背后，是无数个深夜的 Vibe Coding。 二、竞品调研：站在巨人肩膀上做产品 2.1 不要闭门造车——深度使用竞品是第一步 在动手写一行代码之前，我花了大量时间深度调研市面上的 AI 视频垂类平台。 不是看看截图和功能列表，而是真正去用，用到每一个细节。 这个过程让我受益巨大——别人已经踩过的坑，你何必再踩一遍？ 2.2 我调研的主要平台及启发 其实我之前在公众号写了很多相关的AI视频 agent的深度调研文章，大家需要进一步了解这些不同平台的详情可以自己去深度使用，或者看西羊石AI视频公众号之前的文章。 2.3 从竞品中提炼的关键设计决策 1. TapNow 教会我：设计感不是锦上添花，而是产品基因 TapNow 的界面真的很漂亮。它让我意识到，AI 工具不应该看起来像一个"程序员做的工具"——它应该让创作者觉得自己在用一个专业级的创作平台。 这直接影响了我后来确立 Premium Glass 设计体系的决定，以及引入 Anthropic 的 Skill 来指导 AI 生成高质量 UI。 2. Mulan.pro 教会我：自动化是核心竞争力 Mulan.pro 的自动化工作流做得很好，一句话就能生成工作流节点，确认后会生成最终成片。 它让我笃定了 Agent + 手动操作 双模式的设计——Agent 模式让 AI 自动编排整个流程（分镜生成→图片生成→视频生成），手动操作模式让有经验的用户精细控制每一步。 3. 商汤 Seko2 教会我：用户要的是"一键出片" 很多用户其实不关心你底层用的是什么模型、什么 API、什么架构。 他们只想：输入一个剧本，输出一个视频。Seko2 的"一键成片"思路对我的 MVP 定义产生了很大影响。 4. Oiioii 教会我：增长策略和产品设计同样重要 Oiioii 的邀请码裂变机制非常聪明——每个用户都有专属邀请码，邀请新用户后双方都获得额度奖励。 这种零成本裂变式营销值得所有早期产品借鉴。它的可爱 UI 风格也说明了一点：产品有性格才有记忆点。 2.4 Skills 系统：让 AI 输出的 UI 不再有"AI 味" 竞品调研带来的最大冲击是设计差距——TapNow 那种精致高级的质感，我们的 UI 怎么生成都达不到。 即使用 AI 编程工具去美化，出来的还是千篇一律的 Inter 字体 + 紫色渐变 + 白色背景，一看就是AI 做的。 转折点来自 Skills 系统。 我们了解到 Anthropic 的 Claude 有一个 Skills 机制——你可以在项目目录下定义 .agent/skills/ 规范文件，AI 在工作时会自动加载这些规范并严格遵循。 于是我做了一件事：结合 ChatGPT 5.2 Thinking 模式和 Claude 等模型，深度分析我们对标的 TapNow、Mulan.pro 等项目的 UI 设计——拆解它们的色彩体系、字体选择、间距规律、动效策略、组件设计语言，然后把这些洞察提炼成一个结构化的 Skill 规范文件。 最终形成的 有 317 行，包含了： 效果是立竿见影的。 当 Gemini 读取了这份 Skill 后，它产出的 UI 代码不再是"AI 味"的千篇一律，而是真正有设计感、有品位的界面。 我们的 Premium Glass 设计体系（高斯模糊 + 极细内描边 + 克制的 hover 动效）就是在这个框架下一步步落地的。 这个方法论的本质是：用文档驯化 AI 的审美。 你不告诉 AI 什么是好的设计，它就会给你平均水平的设计。 你把你从竞品中学到的设计原则结构化地写下来，AI 就成了忠实执行你审美标准的设计师。 2.5 Agent 设计中的"手动确认"哲学 在调研过程中，我发现一个关键问题：很多 AI Agent 类产品失败在"太自动"了。 AI Agent 不是万能的，它会理解错误、会调用错误的工具、会在不该花钱的地方花钱。 如果让它完全自动化运行，用户会遭遇两个问题： 1. 操作门槛反而变高——用户不知道 AI 做了什么，出了问题没法排查 2. AI Agent 崩溃概率大增——复杂指令下 AI 容易"抽风"，直接跳过关键步骤 所以我们采用了"手动确认"设计： 特别是在消耗积分的操作上（比如批量生成视频），系统会先预估消耗，弹出确认弹窗，用户同意后才执行。这个设计同时解决了三个问题： • 降低了操作门槛（用户看到预览就知道 AI 要做什么） • 减少了 Agent 崩溃的影响（错误操作可以在执行前拦截） • 保护了用户的钱包（不会一句话烧光积分） 三、MVP 认知：你以为它能用就行了？ 3.1 MVP 不是最小可用，而是最小可验证 这是我在这个项目里学到的最重要的创业认知之一。 很多技术出身的创业者（包括我自己）对 MVP 的理解是：快速做出来，能用就行。 但这个理解是致命的——"能用"不等于"能验证商业假设"。 我的 MVP 年前才真正做出来供团队使用。但回头看，真正阻碍我的不是功能不够多，而是： 1. 没有想清楚 MVP 到底要验证什么：是验证"AI 视频生产效率提升"？还是验证"分镜→成片全流程可行"？ 2. 功能做得太多太杂：一开始就想做完整的 Planning→Canvas→Timeline 三视图，结果骨架没搭好就急着做功能 3. 没有设定明确的验证标准：怎么算"验证成功"？是用户用了还是用户效率真的提升了？ 3.2 一个好的骨架胜过十个新功能 AI 视频行业已经迭代了很多轮，Sora、Vidu、即梦、可灵等平台能力在不断升级。外部的变化越快，内部的骨架就越重要。 我的项目在 MVP 阶段犯的核心错误就是——在还没有清晰的架构蓝图时，就急着做功能。结果就是后来花了大量时间打补丁。 真正靠谱的 MVP 流程应该是： 如果能重来一次，我会把第二步至少延长到两周——磨刀不误砍柴工，在 AI 编程时代尤其如此。 3.3 MVP 阶段为什么骨架更重要？ 因为 AI 编程的本质是：你给 AI 的上下文越清晰、越结构化，它的输出质量就越高。 一个好的骨架意味着： • 清晰的目录结构 → AI 知道在哪里创建新文件 • 统一的编码规范 → AI 生成的代码风格一致 • 完善的类型定义 → AI 不会创造出冲突的类型 • 详细的文档体系 → AI 能理解设计决策的"为什么" 没有骨架，AI 编程就像在沙滩上建城堡——建得越高，塌得越快。 3.4 AI 迭代速度飞快——你的架构必须"模型无关" 这是做 AI 视频产品最深刻的教训之一。 当时我刚把 Sora 集成完，觉得 Sora 就是未来：角色一致性、15 秒/25 秒长视频、专业级画质…… 结果转眼就迭代了，SeeDance 2.0 来了，又有新的能力和参数以及玩法。 AI 视频模型的迭代速度远超你的工程化速度。 如果你的代码是"深度绑定某个模型"的，那每次模型更新你都要大改。 我的教训是：针对具体模型本身不要做太多定制化的工程化处理。 你的架构应该是——无论底层模型怎么变，系统都能很方便地适配。 我们项目的 sora tasks 表通过 provider 字段实现了模型无关。当 SeeDance 2.0 出来后，我只需要新增一个 Service 文件，前端和任务管理逻辑完全复用。 项目尽可能早一点做好这些基础的"模型无关"架构，不需要把业务弄得太复杂太定制化。 AI 时代要有自己的 MVP 和前期架构思维，无论模型怎么变，系统应该都能很方便地适配。 四、时间线：MVP 是怎么磨出来的 4.1 从零到 MVP（2025 年底 ～ 2026 年初） 版本 时间 里程碑 v0.1 2025 01 画布缩放、Gemini Grid 生成、AI 对话系统 v0.2 2025 01 角色三视图、Grid 切片预览、音频上传 v0.4 2025 12 用户认证、积分系统、云端存储、AbortController v0.6 2025 12 Sora视频生成全流程：角色注册— 场景拆分— Prompt组装— 任务提交— 状态轮询— R2持久化 版本 版本 时间 时间 里程碑 里程碑 v0.1 v0.1 2025 01 2025 01 画布缩放、Gemini Grid 生成、AI 对话系统 画布缩放、Gemini Grid 生成、AI 对话系统 v0.2 v0.2 2025 01 2025 01 角色三视图、Grid 切片预览、音频上传 角色三视图、Grid 切片预览、音频上传 v0.4 v0.4 2025 12 2025 12 用户认证、积分系统、云端存储、AbortController 用户认证、积分系统、云端存储、AbortController v0.6 v0.6 2025 12 2025 12 Sora视频生成全流程：角色注册— 场景拆分— Prompt组装— 任务提交— 状态轮询— R2持久化 Sora视频生成全流程：角色注册— 场景拆分— Prompt组装— 任务提交— 状态轮询— R2持久化 这个阶段是最痛苦的。节奏慢的原因很简单——没有一个好的骨架。 4.2 补丁式迭代的至暗时期（2026 年 1 月） 这是我打补丁打得最多的一个月。看 Changelog 就知道有多密集： 每一个小版本号背后，都是一个坑： v3.8.2：上传大图时 Vercel 报 413 错误，原来 4.5MB payload 限制卡住了 Grid 图片 → 不得不实现 R2 预签名直传 v3.8.5：生产环境 ，发现即梦 API 是同步阻塞的 → 紧急改为客户端轮询 v3.9.0：用户拖拽 Grid 切片到分镜后，刷新就丢了 → "所见即所得"的即时持久化重构 v3.9.3：Vidu/Sora 的参考图状态互相污染 → 彻底重构为隔离 Hook 架构 v3.9.6：Gemini 参考图在 VPN 下传不过去 → 实现 URL 优先+自动降级策略 这些坑，90% 是因为前期架构设计不够深入导致的。 4.3 架构收敛升级（2026 年 2 月） 经过一月份的"补丁地狱"，二月我下定决心做了几件大事： 1. ChatPanel Hook 大重构（v4.0.0）：把一个单体化的组件拆成 12 个独立 Hook 2. Cron 异步架构（v4.0.1）：将 Sora 状态检查和 R2 上传彻底解耦为两个独立定时任务 3. 事务原子性（v4.0.1）：核心删除操作迁移到 PostgreSQL 存储过程，零数据不一致 4. Hybrid Auth（v4.0.4）：解决了困扰已久的登录状态水合延迟问题 5. UI 设计体系（v4.0.4 v4.0.6）：确立 Premium Glass 美学规范，去掉所有"AI 味"的廉价设计 这时候项目才算进入了一个相对健康的状态。 五、AI 编程工具进化史：从 Claude Code 到 Antigravity + Codex 这是我最想分享的部分。在整个项目开发过程中，我彻底进化成了一个深度使用 AI 编程的人。 5.1 早期：Claude Code 阶段 项目早期我主要使用 Claude Code。那时候的体验是： 优点：理解上下文能力强，能直接操作文件，甚至操作系统，自动化能力强 痛点：生成的代码在复杂项目中经常出错，特别是跨文件引用和类型系统 那个阶段的 Vibe Coding 是真正的"彻夜"——经常凌晨 2 点还在跟 AI 反复调试一个参考图状态管理的 bug，有时候沉迷AI编程发现天就亮了，这是前段时间别人采访我，分享的一些内容，关于AI编程，大家感兴趣可以进一步了解。 5.2 转折点：发现 Antigravity Tools 后来我开始使用谷歌的 Antigravity Tools，这是一个真正的转折点。 为什么 Antigravity 这么好用？ 核心原因是它很便宜且能接入多个顶级模型： Claude Opus / Sonnet：目前最强的代码理解和生成模型 Gemini 最新模型：谷歌自家的大模型，对 Google 生态集成度最好 我的双模型工作流： 一个用来设计方案、写后端逻辑；另一个主要用于前端网页设计优化。这种分工让效率倍增。 5.3 终极武器：Codex（尤其是 3.3 Ultra High） Codex 的进化是肉眼可见的。 到了 3.3 版本的 Ultra High 思考维度，在项目业务逻辑已经非常复杂（700+ 行的 README、750 行的 AGENTS.md、1600+ 行的 CLAUDE.md、41 个 API 端点、22 个 Hook）的情况下，它依然能够： 1. 深度理解意图：告诉它"把 ChatPanel 的视频参考图状态解耦"，它能理解这涉及哪些文件、哪些 Hook、哪些状态流 2. 跨文件重构：一次性修改 5 8 个文件，类型定义、import 路径、接口签名全部自洽 3. 保持上下文一致性：在重构过程中不会丢失已有的业务逻辑 用客户端也会快很多，额度也基本够用（如果你适当使用的话）。 5.4 OpenClaw：强大但了解AI编程会更强 必须提一下 OpenClaw。它目前非常强大，几乎是 AI 个人助理领域的"六边形战士"。但它的强大，背后需要使用者对 AI 编程相关的内容更加熟练，才能发挥到最强。 OpenClaw 用好的前提条件： 1. 你得会写好的 Prompt：模糊的需求 = 模糊的代码。OpenClaw 放大你的能力，也放大你的弱点。 2. 你得有架构设计能力：如果你连数据模型和 API 契约都没想清楚，再强的工具也救不了你。 3. 你得有代码审查能力：AI 写的代码不是天然正确的。你至少要能判断它改了什么、影响了什么。 4. 你得有调试能力：当 AI 写的代码跑出 bug，你要能定位问题，而不是盲目地让 AI "帮我修一下"。 简单来说：AI 编程工具是放大器，不是替代品。 你的底层能力有 80 分，AI 可以帮你放大到 150 分。你的底层能力只有 30 分，AI 最多帮你到 50 分，而且 bug 会更隐蔽。 5.5 我的实战工具推荐 最佳实践组合： 省钱技巧——我的真实操作： 在闲鱼上多买几个 Google Pro 年会员账号，然后用 Antigravity Tools 接入使用。 额度不够就切换账号。改 bug、解决复杂问题时切到 Codex，效果足够好，非常省心。 在闲鱼上多买几个 Google Pro 年会员账号，然后用 Antigravity Tools 接入使用。 额度不够就切换账号。改 bug、解决复杂问题时切到 Codex，效果足够好，非常省心。 关于国产 AI 编程工具的看法： 老实说，一些国产模型在简单任务上速度确实快，效果也还不错。但是——一旦项目复杂度上去了，能力就直线下降。 当你的项目之间有复杂的状态依赖时，国产模型很容易"断片"——它能理解单个文件，但无法理解文件间的关系网。 在 MVP 阶段、简单项目中用国产模型无可厚非。 但如果你是做一个商业级别的完整平台，我不建议把核心逻辑交给国产模型。 六、血泪教训：测试是最不能省的环节 6.1 改了一行代码，崩了三个功能 我在这个项目里踩得最多的坑，不是架构设计的坑，而是测试不充分的坑。 真实案例： v4.0.4 优化了 组件的性能（解耦 上下文），结果把 里的用户头像搞丢了——因为 Props 传递链断了 v3.9.1 修复了即梦的 Pro Mode 显示问题，结果引入了一个登录死循环——因为路由守卫的逻辑被误改了 v3.8.5 统一了 API 超时时间为 120 秒，结果 SeeDream 的生成接口开始频繁 timeout——因为它实际需要更长的时间 每一次好心的优化引入的回归 bug，都比原来的问题更严重。 6.2 测试的核心原则：改了什么，就全量测试什么 这不是说你要写 100% 的单元测试（虽然理想情况下应该）。而是说： 我的惨痛经验总结成一句话：你改了什么，一定要尽可能全量测试。 不然新写的代码老是影响到系统原有正常的功能。 6.3 我现在的测试清单 每次部署前，我会强制自己或者AI过一遍： 这份清单看起来简单，但它阻止了我至少 10 次的生产环境事故。 5.4 给 AI 写测试的技巧 让 AI 帮你写测试时，有个关键技巧：不要让 AI 凭空写测试，要给它具体的边界条件。 AI 写测试的质量，取决于你对边界条件的定义能力。 七、核心反思：那些我应该更早想清楚的事 7.1 反思一：骨架先行，而非功能先行 我的 ChatPanel.tsx 最初是一个单体化组件，所有逻辑写在一起。随着 Vidu、Sora、即梦等视频提供商的加入，每个提供商都有不同的参考图管理逻辑： • Vidu 有 img2video、start end2video、reference2video 三种模式 • Sora 有角色注册、动态比例、智能拆分 • 每种模式下参考图的交互方式完全不同 结果就是这个组件代码膨胀到几千行，状态互相污染，动一处牵万处。 最后不得不花两周时间做大重构，拆出 12 个独立 Hook： 如果一开始就设计好这个分层结构，能省至少一半的时间。 6.2 反思二：临时 URL 的持久化必须是底层基础设施 浏览器中的 blob: 和 data: URL 是临时的，刷新就没了。但在早期开发中，我经常直接把这些临时 URL 存到数据库里，结果就是： • 用户生成了分镜图片，拖到分镜上看起来没问题，但一刷新页面就丢了 • 聊天历史里的图片在跨设备时全部变成空白 最终不得不实现一个透明持久化机制： 如果一开始就有这个意识，可以避免大量的"图片丢失"类 bug。 6.3 反思三：文档是你和 AI 协作的操作系统 到了项目中后期，我的核心文档体系长这样： 文档 行数 作用 README.md 700+ 行 项目全貌、功能列表、Changelog AGENTS.md 750 行 AI Agent 的完整行为指南 CLAUDE.md 1600+ 行 开发哲学、技术标准、设计模式 docs/ 目录 30+ 文件 各子系统详细架构 文档 文档 行数 行数 作用 作用 README.md README.md 700+ 行 700+ 行 项目全貌、功能列表、Changelog 项目全貌、功能列表、Changelog AGENTS.md AGENTS.md 750 行 750 行 AI Agent 的完整行为指南 AI Agent 的完整行为指南 CLAUDE.md CLAUDE.md 1600+ 行 1600+ 行 开发哲学、技术标准、设计模式 开发哲学、技术标准、设计模式 docs/ 目录 docs/ 目录 30+ 文件 30+ 文件 各子系统详细架构 各子系统详细架构 这些文档不仅是给人看的，更是给 AI 看的。 当你用 Codex 或 Antigravity 做复杂重构时，AI 需要理解： 1. 项目的整体架构是什么 2. 哪些设计决策是刻意做出的（不应该"优化"掉） 3. 各模块的依赖关系 文档越详细、越准确，越规范，AI 了解后的输出质量越高。 八、全方位规范体系：少走弯路的系统性保障 这是我最想给同行者强调的——规范不是形式主义，而是防止你在复杂项目中迷路的导航系统。 8.1 项目文档规范 关键原则：文档和代码同步更新，永远不要"先写代码，后补文档"。 因为后补的文档，90% 会遗漏关键的设计决策。 8.2 设计规范 经过反复迭代，我们确立了 "Film Grade Black & White" + Premium Glass 设计系统： 设计规范的好处：当 AI 帮你做 UI 时，它能严格按照规范输出，不会做出"AI 味"的廉价设计。 反面教材：早期没有设计规范时，不同功能模块的 UI 风格完全不统一——有的用 、有的用 、有的用 ，整个项目看起来像拼凑的。 8.3 代码编写规范 我们在 CLAUDE.md 中定义了明确的编码标准： 最重要的规范——我们列出了明确的"严禁行为"： 严禁 原因 ❌ 客户端暴露 API Key 安全风险 ❌ 跳过白名单检查 权限控制 ❌ 直接修改 project.chatHistory 已迁移至 chat messages 表 ❌ 轮询使用同步阻塞 Serverless 超时 ❌ 存储 Base64 到 Supabase 必须上传 R2 ❌ Planning 模式调用生成工具 消耗资源 严禁 严禁 原因 原因 ❌ 客户端暴露 API Key ❌ 客户端暴露 API Key 安全风险 安全风险 ❌ 跳过白名单检查 ❌ 跳过白名单检查 权限控制 权限控制 ❌ 直接修改 project.chatHistory ❌ 直接修改 project.chatHistory 已迁移至 chat messages 表 已迁移至 chat messages 表 ❌ 轮询使用同步阻塞 ❌ 轮询使用同步阻塞 Serverless 超时 Serverless 超时 ❌ 存储 Base64 到 Supabase ❌ 存储 Base64 到 Supabase 必须上传 R2 必须上传 R2 ❌ Planning 模式调用生成工具 ❌ Planning 模式调用生成工具 消耗资源 消耗资源 "严禁清单"是约束 AI 行为的最有效方式。 AI 处理大型项目时偶尔会走捷径，明确的禁止规则能大大减少这种情况。 8.4 软件开发流程规范 这套流程听起来像是教科书，但它是我用血泪换来的。 尤其是"3 次尝试失败后停止"——我曾经在一个 bug 上死磕 6 小时，如果在第 3 次尝试后停下来换个思路，可能 30 分钟就能解决。 8.5 Git 版本管理规范 真实教训：有一次我直接在 main 分支上改代码，auto deploy 把有 bug 的代码推到了生产环境。 从此以后，我严格遵循分支策略——main 分支只接受合并，永远不直接提交。 7.6 发布与部署规范 九、创业认知：专业的事交给专业的人 9.1 不是所有事情都适合 Vibe Coding 这是我在创业过程中最大的认知升级之一。 我的团队除了 Video Agent Pro 之外，还有另一个系统（类似Tapnow节点式工作流AI视频平台）。 那个系统的做法完全不同：直接外包给专业团队。 为什么？因为那个系统的核心不是 AI 创新，而是稳定的业务流程系统。它需要的是： • 成熟的技术选型 • 标准化的系统设计 • 稳定可靠的交付质量 • 可维护的长期架构 这些"无聊但重要"的事情，专业的外包团队或者合作的超级个体做得比你 Vibe Coding 好 10 倍。 8.2 外包的正确姿势 我们的外包合作模式是： 核心原则：前期让专业的人把架构做好，最多我们后续运维和结合 AI 编程解决一些紧急的 bug。 8.3 哪些适合