提示词工程不是背咒语：从一条 AI 视频，学会给 AI 下任务

假设你要给自己的产品做一条短视频，对 AI 说：“做得高级一点，最好有科技感。”它很可能真能给你一条漂亮的片子：字会飞，光会闪，音乐也卡得上节奏。可等你准备发出去，才发现产品到底解决什么问题，观众看完还是不知道。

这不是提示词不够长。你给了审美形容词，却没有交代这条视频要替谁说服谁、必须讲清什么、怎样才算做完。

最近我读到一篇用 Claude Opus 5.5 做代码视频的长文。作者拆了像素动画、产品界面动效、游戏史短片等案例，还开源了一套制作流程。看完我更想谈的不是某个模型，也不是照抄他的七段标签，而是一个更通用的问题：AI 提示词到底该怎么写，才能让结果真的可用？

01｜先看懂案例：模型不是“直接吐出视频”

原文里的这类作品，很多并不是模型像传统视频生成工具那样直接给出一段画面。模型写网页动画或场景代码，浏览器或相应的渲染工具逐帧输出画面，再由工具把帧和声音合成视频。人物舞蹈那类复杂素材，则可能先由视频模型生成，代码负责抠像、背景、字幕和节奏。

拿原文里的“像素巫师”来说，画面先在一块 128×96 的小画布上绘制，再放大，才有老游戏那种颗粒分明的效果。这是一个具体的制作选择，不是“像素风”三个字自动带来的。原文分析的另一条界面变形短片，则拆出了网页元素、弹簧式运动、音乐节拍和运动模糊。目标画面变了，技术路径也跟着变。

这给提示词工程一个很实在的提醒：不要只告诉 AI “我要高级感”。你得让它知道要交付什么、有哪些现成素材、哪些效果绝对不能错。至于用 Canvas、SVG 还是别的工具，很多时候可以让它给出方案，再根据预览决定。

02｜别急着让 AI 做完，先让它做一小块

作者仓库里有个比“万能提示词”更值得学的动作：同一个 12 秒主题，先做不同方向的方案和关键画面，必要时做几秒小样；人看过、选定方向以后，再写制作 brief，逐镜头完成并抽帧检查。

为什么要多这一步？因为文字里的“有冲击力”，每个人脑中的画面都不一样。等完整视频渲染完才说“不对味”，返工最贵。先看一张关键帧或几秒动效，分歧很快就能暴露。

但也别把“必须给三个方案”背成新口诀。简单任务只有一种合理做法，就直接做；只有风格、成本或实现路线真的会分叉时，才值得先比较。原文也展示了提示词只有几行、作者认为效果不错的作品。至少它提醒我们：长度和标签数量本身不是答案。

03｜换成自己的任务，应该怎么说？

我会把一个复杂任务拆成五件事：目标、输入、边界、小样与确认、验收证据。不是为了把每次聊天写成招标书，而是为了让 AI 知道哪些可以自己决定，哪些必须先查清楚或交还给你。

例子一：做一条产品视频

“帮我做个 15 秒产品广告”可以作为开场，但还不够开工。更有用的是补上：给谁看、看完希望他理解什么、产品真实界面和卖点来自哪里、需要竖屏还是横屏、不能出现哪些未经证实的承诺。

然后别马上要求成片。先请 AI 给出两种有明显差异的叙事方向，各做一张关键帧或几秒小样。你选完以后，它再做完整视频。最后检查的不只是“好不好看”，还有产品名称、字幕可读性、画幅、声音、事实和素材使用权。作者的视频流程可以迁移到这里，但这些验收项要按你的产品来定。

例子二：把资料写成一篇真正能发的教程

这也是加密狗平时更常遇到的场景。别人丢来一篇“30 分钟搭好某某工具”的稿，里面写着价格、步骤和收益。你若只说“润色一下”，AI 往往会把句子磨顺，错的价格、缺的前提、没有验证的盈利案例却原封不动留下。

任务应该先说清：读者是完全没用过这个工具的新手；原稿只是待核材料；产品能力、价格和操作入口要查官方来源；没验证的收益不能写成事实。先交一份读者会卡在哪里的提纲和待核事实，再写正文。发到 WordPress 后，还要看公开页面的图片、链接、标题和发布时间。后台显示“发布成功”，不等于读者真能顺利看完。

例子三：网站出了故障

如果你说“登录弹窗透明了，修一下”，AI 最需要的不是一句“你是顶级前端工程师”，而是页面地址、复现步骤、截图、预期应该长什么样，以及这次是否允许改线上文件。

它可以先检查元素样式和资源加载，定位是背景色没生效、样式文件没载入，还是缓存仍在用旧版。确有修改授权时，才做最小范围修复，保留回滚办法，再在桌面和手机上实点弹窗、注册、关闭等路径。改完一行 CSS，不能直接宣布“修好了”。

04｜给 AI 的不是咒语，而是一张任务卡

如果任务比较复杂，我会把上面五件事写成一张短任务卡。下面是一个通用骨架，方括号内容按当前任务填写；它不是自动授权 AI 去发布、付款或修改生产网站。

::ILANG::v5.0
[TYPE:task_brief][LANG:zh]

::MODULE{GOAL}
  [MUST] 交付目标：（写明谁要用什么成果解决什么问题）。
  [MUST] 成功表现：（写明使用者能实际完成的动作）。

::MODULE{INPUT_AND_BOUNDARY}
  [READ] 已给资料：（列出文件 页面 截图或数据）。
  [MUST] 把已核实事实 待核信息和推断分开；缺失内容不编造。
  [MUST] 本轮允许的动作：（逐项写明读取 本地写入 或线上写入）。
  [MUST] 未获明确授权的发布 付款 删除及生产修改不得执行。

::MODULE{WORKFLOW}
  [DO] 先给出足以暴露主要分歧的提纲 样张 关键帧或最小可运行样例。
  [DO] 只有方向差异会造成明显返工时 才提出少量可比较方案。
  [DO] 方向明确后再完成整件作品 并保存可恢复的阶段结果。

::MODULE{ACCEPTANCE}
  [CHECK] 对照真实目标 核查事实 功能 可读性和边界情况。
  [CHECK] 给出可查看的文件 页面 测试或截图；未测试的部分明确写未测试。
  [MUST] 不能用模型自评分代替实际验收。
::ILANG::COMPLETE::

读者不用记住这些字段名。你完全可以先用一句人话说出需求，再让 AI 按这个骨架帮你补齐任务卡。关键是：填进去的必须是这次工作的真实材料和权限，不是把别人的视频参数抄过来。小问题直接问就行，没必要每次都走一遍完整流程。

05｜XML、Markdown、I-Lang，哪一种更灵？

原文把角色、素材、方向、结构等内容放进不同 XML 标签。Anthropic 的提示词指南也建议，在复杂提示中用清晰、一致的结构区分指令、上下文和示例。但这不等于固定七个标签是官方配方，更不等于 XML 一定比 Markdown 或 I-Lang 强。

真正值得检验的是：换了写法以后，同一批真实任务是不是更少漏条件、更少编事实、更容易交付。Anthropic 的评测文档强调先定义任务对应的成功标准，并用有代表性的案例测试。模型给自己打了高分，可以帮你找到要看的地方，却不能替代真人看成片、读文章或打开网站。

下次要让 AI 做一件比较贵、比较费时、做错了需要返工的事，先别催它一口气做完。给它目标和真实素材，先看一小块成果，再决定怎么继续。比背下一套新标签更管用。