第一段有效对话：让 Codex 交出能验收的代码

工具都跑通了。现在到了整本教程最关键的技能：和 Codex 进行第一轮真正有效的对话。很多人在这一步翻车，不是因为 Codex 不行，而是因为下指令的方式从一开始就错了。这一章教你一个可复用的方法——任务卡——并且带你走完「下指令 → 它改代码 → 你验收 → 发现问题 → 纠正」的完整一圈。

3.1 别只说「帮我做个视频」

先说一个必然翻车的示范。如果你对 Codex 说：

帮我做个视频，要好看一点，现代一点。

会发生什么？它会基于想象开始写，产出几百行「看起来合理」的代码。你打开预览，发现配色不是你要的、文案是它编的、时长是它定的。然后你陷入最糟糕的循环：你一句句地纠正，它一句句地改，两个小时过去，你俩都在猜对方想要什么。

问题不在 Codex，而在你的需求没有变成它能执行、你能验收的形式。人类导演不会对剪辑师说「剪好看点」，他会说「这条片子 30 秒，前 5 秒放产品名，中间 20 秒每个卖点停 4 秒，结尾放 logo」。剪辑师需要这样，Codex 更需要——因为它连「好看」背后的行业默契都没有。

所以，给 Codex 的任何任务，都装进同一张任务卡里，四个部分：

任务卡的逻辑是：验收标准是你唯一的「完成的定义」。Codex 怎么实现是它的事；你只管它交回的东西是否满足验收标准。这和你第1章写下的「导演守则」完全一致。

3.2 给 Codex 的第一份任务卡

现在，让我们把第一份任务卡交给 Codex。先启动两个终端：

• 终端 A：在项目目录运行 npm run dev，保持 Studio 开着；
• 终端 B：同样在项目目录（cd my-video），运行 codex，进入对话。

之所以分两个终端，是因为 Remotion Studio 支持热更新：Codex 在终端 B 里改完代码保存，终端 A 的预览会立刻刷新，你马上就能看到结果。这让「改 → 看 → 再改」的循环变得非常快。

然后在终端 B 里，把下面这段话发出去（可以把标题文案换成你自己的）：

在这个 Remotion 项目里完成一个小任务，按任务卡执行：

目标：把默认示例画面改成「山雾乌龙」新品上新的开场标题卡。
位置：优先只修改 src/Video.tsx；如果确实需要看 src/Root.tsx 或 src/index.ts 才知道注册了哪个 composition，可以读，但不要改动它们；不要新建文件，不要安装任何新依赖。
验收标准：
1. 预览画面中央显示主标题「山雾乌龙」，下方一行小字「新品上市 · 本周四」；
2. 文案必须逐字使用我给的原文，不要自行改写或增删；
3. 画面尺寸保持 1920×1080，帧率 30fps，时长保持默认；
4. 文字完整可见，不溢出屏幕，不互相重叠；
5. 主标题配一个深色背景，文字用浅色，保证可读。
约束：先读 package.json 和现有代码，搞清楚项目用的是哪个版本的 Remotion 和什么组件结构，再动手；改完告诉我你改了哪些文件、每处改动的目的，以及如何在 Studio 里验证。

开始前请先说明你的实现计划，我确认后再动手。

注意这段话的结构：开场说了任务类型；目标/位置/验收标准/约束四项齐全；最后一句要求它先给计划再动手。第一次和某个项目里的 Codex 打交道时，「先计划后执行」能让你在它写错方向之前就纠正它——成本远低于它写完一坨代码再返工。

Codex 回复计划后，你看一眼：它打算改哪个文件？用的思路合理吗（比如是不是打算往现有组件里塞内容）？确认没问题，回复「按计划执行」。然后观察它工作：它会读文件、改代码，并在完成后汇报。如果它中途要跑命令（比如装包），会按你设置的授权模式征求同意——这正是第2章那套权限设计的用武之地。

3.3 它交回代码后：读 diff、跑起来、看画面

Codex 说「完成了」——这时，导演守则第2条生效：它说完成不等于完成。按顺序做三件事：

第一步，读改动。回到终端，在项目目录运行：

git diff

你会看到它到底改了什么。第一次看 diff 不必逐行理解，重点看三件事：改的文件是不是任务卡允许的？改动规模是否合理（任务小、改动却铺天盖地，往往有问题）？有没有偷偷加依赖或新建文件？

第二步，亲眼看。切到终端 A 的 Studio 预览，刷新并播放前几秒。对照验收标准逐条打勾：标题出现了吗？文案逐字一致吗？文字溢出或重叠了吗？

第三步，让它自证。如果某些验收点肉眼难判断（比如「文字是否真的没溢出边缘」），让 Codex 自己提供证据——它可以告诉你它在代码里怎么保证的，或帮你运行检查命令。你会慢慢发现，要求 Codex 给出验证方法，比它空口说「完成了」可靠得多。

这里强烈建议一个习惯：每次验收通过，立刻提交：

git add -A
git commit -m "feat: 标题卡初步可用"

如果验收不通过，不要急着让 Codex 继续改——先想清楚是哪里不满足哪一条验收标准，把话说具体，再进入下一轮。含糊的「感觉不太对」会让它退回猜谜模式。

3.4 Codex 猜错 API 时，教它读文档

新手最常见的挫折时刻：Codex 用了一个它「记忆里」的 API，结果预览里一片空白，或者终端报错。请记住：这不是它笨，而是大模型对快速迭代的框架（比如 Remotion）的记忆会过时。文档上周刚改的写法，它训练时根本没看过。

正确的应对不是换一种说法重问，而是让它去读当前文档。例如：

预览空白，终端报错：XXX（把完整报错贴上来）。
先不要猜。请按下面顺序排查：
1. 用官方文档核对这个 API 在当前 Remotion 版本（读 package.json 里的版本号）下的正确用法；
2. 如果项目还没装官方 Agent Skills，按 Remotion 官方文档的说明安装（它会把 Remotion 的最佳实践教给智能体）；
3. 找出报错里第一个真正的原因，只修那一处，不要顺手重构；
4. 改完先说明你依据的是哪份文档，再动手。

你可以把这个「读文档优先」的要求写进每个任务的约束里，一劳永逸。更进一步的做法是把它固化到项目里：在项目根目录放一个 AGENTS.md 文件，写清楚「本项目的规矩」——用什么版本、文档在哪、哪些文件不许动、验收标准怎么写。Codex 这类智能体通常会自动读取这类说明文件，等于给每次对话都装上同一个大脑。第9章我们会把 AGENTS.md 做成正式模板，现在你只要知道有这个机制即可。

3.5 行动：下达你的第一个可验收任务

到这里，你已经完成了一次完整的协作循环。但你心里可能还有一个疙瘩：Codex 写出来的那些代码，什么 Composition、什么帧，我其实没真正看懂，只是碰巧能跑。下一章就解决这个疙瘩——给你一套读 Remotion 代码的心智模型，让你从「看天书」变成「能判断它写得对不对」。