一份可以照着做的实操清单 · 全部条目附官方依据 A checklist you can actually follow · every item backed by primary sources
这里没有「AI 很好用」这种口号，只有可以照着执行的动作：给模型什么上下文、按什么顺序提问、用什么方式验收、在什么条件下会失效。所有结论都指向各家官方文档或公开研究，遇到版本差异以官方文档为准。 No slogans about AI being great — just actions you can execute: what context to hand the model, in what order to ask, how to verify the result, and when the technique stops working. Every claim points back to official documentation or public research, and where tools differ by version, the official docs win.
每个技巧都写清了：怎么做、为什么有效、什么时候会失效、以及提效点在哪。 Every technique states the steps, the mechanism, the failure mode, and where the time actually goes back.
方法论Method
文件、日志、截图、验收标准——你喂给模型的东西，直接决定输出上限。多数场景下，把上下文写清楚的收益大于换一个更强的模型。Files, logs, screenshots, acceptance criteria: what you hand over sets the ceiling on the output. In most cases, writing the context down beats switching to a stronger model.
每一次生成都要能回答「怎么判断它是对的」。有了可判定的验收方式，才敢真的把活交出去，而不是自己重写一遍。Every generation needs an answer to "how do we know it is right?". With a checkable definition of done, you can actually delegate instead of rewriting the output yourself.
同时改三个变量，你既不知道是哪一个起了作用，也没法回退。原子粒度同时换来可回滚和可归因，这是整套方法里回报最高的一条。Change three variables at once and you neither learn which one mattered nor can you undo it. Atomic steps buy rollback and attribution at the same time — the highest-return rule in this book.
图片类工作先把静帧定下来，视频类工作先把分镜定下来。一个能被检查的静帧，永远比一段正在运动的画面便宜。Lock the still before animating it, and lock the shot list before generating footage. A frame you can inspect is always cheaper to fix than a shot that is already moving.
技巧库Library
让模型产出可合并、可回滚、能被测试验证的代码，而不是一次性大段生成。Make the model produce reviewable, revertible, test-verified code instead of one giant generated blob.
构建、测试、风格、目录职责写进 CLAUDE.md / AGENTS.md，一次编写、每次自动生效。Build, test, style and directory ownership belong in a CLAUDE.md / AGENTS.md file that is read every session — not in prompts you retype.
请扫描本仓库，生成一份 CLAUDE.md 草稿，只包含四类内容：构建/测试/格式化命令；不可协商的代码风格约束；各目录的职责边界；提交前检查清单。每条写成祈使句，全文不超过 200 行。凡是你无法从仓库中确认的内容，标注为 TODO 等我确认，不要自行假设。Scan this repository and draft a CLAUDE.md containing only four kinds of content: build, test and formatting commands; non-negotiable style constraints; what each directory owns; and a pre-commit checklist. Write every line as an imperative, keep it under 200 lines, and mark anything you cannot confirm from the repo as TODO for me to check instead of assuming it.把生成草稿当成初稿，你只做删改，通常十几分钟就能定稿。Treat the draft as a draft: your job is deletion and correction, not authorship. Most teams finalise it in under fifteen minutes.
每次会话都从一个全新的上下文窗口开始，规则文件是唯一能把上下文跨会话带过去的载体；写得越具体，被遵守的概率越高。Every session begins with a fresh context window, so a rules file is the one artifact that carries context across sessions. The more specific it is, the more reliably it is followed.
不要把目录结构、依赖清单这类它自己读得出来的东西写进去，只会稀释真正重要的指令；也不要指望它记住你没写下来的约定。Do not paste in directory trees or dependency lists it can already read — that only dilutes the rules that matter. And it will not honour conventions you never wrote down.
省掉每次开工重复交代背景的沟通成本，也让不同会话、不同同事产出的代码遵循同一套约定。Removes the per-session briefing ritual and keeps output consistent across sessions and across teammates.
用检索和子代理建立上下文地图，比一句「实现这个功能」少得多返工。Mapping the code with search and subagents first removes far more rework than a one-line "implement this".
只读，不要写代码。先在仓库里找出实现〈目标〉需要修改或新增的文件，逐个说明该文件的职责、关键函数、相关的现有测试以及调用关系；然后列出你还无法确认的地方（每条一行，并说明你需要我提供什么）。不要输出实现代码。Read only — do not write code. Find the files that would need to change to implement <goal>. For each one, state its responsibility, the key functions, the existing tests that cover it, and who calls it. Then list what you could not determine, one per line, with what you would need from me. Do not output an implementation.把目标换成具体名词（接口名、模块名），而不是笼统的功能描述。Put concrete nouns in the goal — an interface name, a module name — not a vague feature description.
官方最佳实践强调要把文件、日志这类富上下文直接交给模型，而不是靠描述；上下文越具体，模型需要猜测的部分越少。Official guidance stresses handing over files and logs directly instead of describing them. The more concrete the context, the less the model has to guess.
别让它全量通读整个仓库：既烧上下文也拖慢速度。把探索范围限定在这次改动真正涉及的那几个模块。Do not let it read the whole repository — that burns context and time. Scope the exploration to the modules this change actually touches.
少掉「生成完才发现用错模块」的整轮返工，而这通常是代理式编程最贵的一类错误。Removes the expensive class of error where the code lands in the wrong module and only shows up after generation.
先要一份写明边界、依赖与验证方式的方案，再让模型执行；返工发生在理解不一致的时候。Ask for a plan with explicit boundaries, dependencies and verification before any code is written. Rework starts where understanding diverges.
先不要写代码。给出实现方案：1) 要修改或新增的文件清单；2) 每个文件的改动要点，每条不超过两行；3) 边界条件与异常路径；4) 你打算用什么方式验证（具体命令或具体检查）。凡是你假设的前提，请单独列为「我的假设」，等我确认后再开始写代码。Do not write code yet. Give me an implementation plan with: 1) the files to modify or add; 2) what changes in each, no more than two lines per file; 3) edge cases and failure paths; 4) how you will verify it, naming the exact command or check. List every assumption you are relying on under "My assumptions". Wait for my confirmation before writing any code.「我的假设」这一栏是整份方案里最值钱的部分，务必让它写出来。The "My assumptions" section is the most valuable line in the whole plan — make sure it appears.
计划阶段把隐含假设逼到台面上，人机分歧在这一刻被发现，代价只是一段文字；等到代码写完，同样的分歧代价就是一次重构。The planning stage surfaces hidden assumptions while disagreement still costs a paragraph. The same disagreement discovered after coding costs a rewrite.
计划不等于承诺。看起来合理的方案可能建立在错误前提上，所以「怎么验证」这一段不能省。A plan is not a guarantee. A well-written plan can rest on a wrong premise, which is why the verification section cannot be dropped.
把返工的形态从「改代码」降级成「改方案」，两者成本差一个数量级。Downgrades rework from "rewrite the code" to "revise the plan" — an order of magnitude apart in cost.
写清「完成长什么样、怎么验证、哪些不能动」，输出才会可判定，而不是只能凭感觉验收。State what done looks like, how it gets checked, and what must not move. Only then is the output judgeable rather than a matter of taste.
任务契约——
目标：〈一句可验证的目标〉
必须满足：1) … 2) … 3) …
禁止：修改 〈文件/目录〉；引入新的运行时依赖；改变现有对外接口。
验收：运行 〈具体命令〉，并贴出真实输出；若失败请贴出失败信息。
开始前先用你自己的话复述这份契约，等我确认后再动手。Task contract —
Goal: <one verifiable outcome>
Must hold: 1) … 2) … 3) …
Forbidden: editing <files/directories>; adding a new runtime dependency; changing any existing public interface.
Verification: run <exact command> and paste the real output; if it fails, paste the failure text.
Begin by restating this contract in your own words and wait for my confirmation.契约一旦定稿，存成模板复用，是投入产出比最高的一步。Once a contract works, store it as a template — this is the highest-leverage step in the whole workflow.
契约把「看起来对」变成「可判定对错」，模型因此有了明确的目标函数，你也有了明确的检查方式，双方不再靠感觉对话。A contract turns "looks right" into "can be judged right or wrong". The model gets an explicit target, and you get an explicit check — no more negotiating by feel.
契约里出现无法执行的检查（「代码要优雅」「体验要顺畅」）等于没写，这类条目只会制造分歧。Checks that cannot be executed ("the code should be elegant", "the experience should feel smooth") are not checks. They only create disagreement.
验收从主观讨论变成跑一次命令，沟通轮次明显减少，也更容易把工作交给别人并行做。Turns acceptance from an opinion into one command, cutting discussion rounds and making the work easy to hand to someone else in parallel.
把改动切成一次提交装得下的粒度，每一步都能单独验证、单独回滚。Cut changes down to the size of one commit. Every step stays independently verifiable and independently revertible.
这次只做一件事：〈一个具体改动〉。不要顺手重构，不要修改这个改动之外的文件，不要升级或新增依赖。完成后：1) 列出改动的文件；2) 运行 〈测试命令〉 并贴出真实输出；3) 如果与预期不符，先停下来问我，不要自行扩大改动范围。Do exactly one thing this time: <one specific change>. No opportunistic refactors, no edits to files outside that change, no dependency upgrades or additions. When done: 1) list the files you touched; 2) run <test command> and paste the real output; 3) if anything differs from expectations, stop and ask me instead of widening the change.同一类任务重复出现时，把这段限制固化到规则文件里。Once this pattern repeats, move the constraint into the rules file so it applies by default.
模型在一次改动里同时引入行为变更和结构变更时，你很难判断是哪一处引入了问题；原子粒度让因果关系始终可判定。When behaviour and structure change in the same step, cause becomes untraceable. Atomic steps keep cause and effect intact.
拆得过细会把一个小任务变成一长串对话，得不偿失。粒度的目标是「一步一个概念」，不是「一步一个文件」。Over-splitting turns a small task into a long conversation. The goal is one concept per step, not one file per step.
出错时回滚一步而不是半天的工作，定位问题也只需要看一个 diff。When something breaks you roll back one step instead of half a day, and diagnosing it means reading a single diff.
先让它按规格写测试，再让它写实现去满足测试；对不对由测试回答，不由信心回答。Have it write tests from the spec first, then write the implementation to satisfy them. Correctness gets answered by a test run, not by confidence.
先写测试，不要写实现。规格如下：〈规格〉。要求：1) 覆盖正常路径、边界值和至少一条失败路径；2) 测试必须能独立运行，不依赖执行顺序；3) 断言要检查具体值，不要只检查不抛异常；4) 每条测试名要能读出它在验证什么。写完贴出测试文件内容，等我确认后再写实现。Write tests first, no implementation. Spec: <spec>. Requirements: 1) cover the normal path, boundary values and at least one failure path; 2) each test must run independently, with no order dependency; 3) assert concrete values, not merely that nothing threw; 4) each test name should read as the thing it verifies. Paste the test file when done and wait for my confirmation before writing the implementation.如果规格本身含糊，模型会立刻在测试里暴露出来——这正是先写测试的价值。If the spec is vague, the tests expose it immediately. That is exactly the value of writing tests first.
模型擅长穷举边界情况，写测试比写实现更容易把规格里的模糊点逼出来；实现只是把已经明确的规则翻译成代码。Models are good at enumerating edge cases, so writing tests surfaces ambiguity in a spec more readily than writing the implementation does. Implementation merely translates rules that are already clear.
未经审阅的测试可能断言过弱，甚至被悄悄改松。所以顺序必须是：写测试 → 你审 → 再写实现。Unreviewed tests can assert too weakly, or be quietly loosened. The order matters: write tests, you review, then implement.
把「读代码判断对不对」换成一条可重复运行的命令，评审和交接都变轻。Replaces "read the code and judge" with one repeatable command, which makes review and handover lighter.
把角色从作者换成审查者，它会去看你没让它看的地方——前提是要求它给出证据。Switch its role from author to reviewer and it will look at things you never pointed at — provided you demand evidence.
以严格代码审查者的身份审这次改动。只输出问题，不要修改代码。要求：1) 按严重程度从高到低排序；2) 每条给出文件与行号、什么输入或状态下会触发、建议怎么改；3) 只写你能从代码中确认的问题，不要写猜测；4) 最后单列一节「我无法确认的部分」，并说明需要我提供什么信息才能判断。Review this change as a strict code reviewer. Report findings only — do not modify code. Requirements: 1) order by severity, highest first; 2) for each finding give file and line, the input or state that triggers it, and a suggested fix; 3) report only issues you can confirm from the code, no speculation; 4) finish with a separate section listing what you could not verify, and what you would need from me to judge it.让模型直接输出「我无法确认的部分」，比让它闭嘴更能暴露信息缺口。The "what I could not verify" section is more useful than silence — it shows you exactly which information is missing.
同一个模型在「我写的东西对吗」这个任务上会切换到找错的模式；要求行号和触发条件，把泛泛而谈变成可核对的具体条目。The same model switches into error-finding mode when the task is "is my work wrong?". Demanding line numbers and trigger conditions converts generalities into checkable items.
审查会漏掉架构级问题，也可能对风格过度敏感。它是第二双眼睛，不是最后一道防线。A review misses architecture-level problems and can be over-sensitive about style. It is a second pair of eyes, not the last line of defence.
相当于多了一次随时可用的同行评审，而且不用约人、也不用等排期。Adds a peer review you can run on demand — no scheduling, no waiting for someone's calendar.
会话上下文是一次性资源，真正该被记住的东西应该写进仓库，而不是留在聊天记录里。A conversation is a one-shot resource. Anything worth remembering belongs in the repository, not in the chat log.
这次任务收尾，请输出三段，不要修改任何代码：1) 本次改动的文件清单，每项一行说明改动原因；2) 尚未解决、留给后续的 TODO，每条给出建议的下一步；3) 本次任务中你发现的、值得写进项目规则文件的约定（每条一行，祈使句）。Wrapping up this task, output three sections and do not modify any code: 1) the files changed, one line each explaining why; 2) open TODOs left behind, each with a suggested next step; 3) conventions you noticed during this task that belong in the project's rules file, one per line, written as imperatives.第三段是长期收益最大的一段：它把一次会话的经验变成之后每次都会加载的规则。The third section pays off longest: it turns one session's experience into rules that load every time after.
每个会话都从全新的上下文窗口开始，跨会话的记忆只能靠文件和规则文件承载；官方也把「自动记忆」建立在文件之上。Every session starts with a fresh context window, so cross-session memory can only live in files. Official memory mechanisms are built on files too.
同一个会话里塞太多任务会让上下文越来越噪，出现重复读文件、反复确认时就该换会话了。Piling many tasks into one session makes the context noisier and noisier. The tell is repeated re-reading and repeated confirmations — switch sessions then.
避免上下文漂移带来的来回摇摆，也让下一次开工不是从零开始。Avoids the back-and-forth caused by context drift, and stops the next session from starting from zero.
把一致性、画幅、文字这些难题，从提示词里拿出来交给参考图和参数。Move consistency, framing and typography out of the prompt and into references and parameters.
想让同一张脸或同一个产品在多张图里保持一致，参考图比再详细的一段文字可靠得多。If the same face or product must stay consistent across images, a reference image beats any amount of descriptive text.
参考图 1 是人物身份锚点：保持面部特征、发型与服装完全一致。把该人物放进〈新场景〉，〈具体动作〉，〈光线〉。不要改变身份特征，不要文字，不要 logo。Reference image 1 is the identity anchor: keep the face, hair and wardrobe exactly as shown. Place the subject in <new scene>, <specific action>, <lighting>. Do not alter identity features. No text, no logo.参考图的质量决定一致性上限：背景杂乱、多人合照、强表情、低清都会让身份漂移。Reference quality caps how consistent you can be. Busy backgrounds, group shots, extreme expressions and low resolution all cause identity drift.
参考图是强约束，文字描述是弱提示；官方文档把「保持角色外观一致」明确列为模型的核心能力，Midjourney 也用 --cref 专门做这件事。A reference image is a hard constraint; prose is a soft hint. Official documentation lists maintaining character appearance as a core model capability, and Midjourney ships --cref specifically for it.
参考图不是三维角色绑定，不能保证每一帧都像同一个演员；商业级连续性仍要留出人工筛选和修图的时间。A reference is not a 3D character rig. It cannot guarantee every frame reads as the same actor, so commercial continuity still needs human selection and retouching time.
一致性问题从「反复重抽碰运气」变成「可控编辑」，系列内容的产出速度会有量级差别。Turns consistency from lucky retries into controlled editing — the difference is an order of magnitude across a series.
多图合成时写清「图 1 管身份、图 2 管场景、图 3 管色调」，模型才不会在冲突的线索之间折中。When combining references, say which image owns identity, which owns setting and which owns palette — otherwise the model averages conflicting cues.
参考图 1 = 人物身份，参考图 2 = 场景布局，参考图 3 = 色调与质感。合成一张〈画幅〉的〈场景〉图：人物做〈动作〉。统一〈光线方向与色温〉、真实比例与接触阴影；保留〈身份与服装特征〉。不要文字，不要 logo。Reference 1 = identity. Reference 2 = scene layout. Reference 3 = palette and texture only. Compose one <aspect ratio> image of <scene>, with the subject performing <action>. Unify <light direction and colour temperature>, realistic scale and contact shadows, and preserve <identity and wardrobe features>. No text, no logo.角色分工要在提示词里显式写出来，光靠上传顺序指望模型自己猜是不现实的。Write the division of labour out explicitly. Upload order alone will not make the model infer it.
多图输入本质是把不同语义的约束拼接起来；角色越清晰，模型越少在互相矛盾的线索之间取折中，结果越接近你的意图。Multi-image input stitches together constraints of different kinds. Clear roles mean fewer compromises between conflicting cues, so the result lands closer to your intent.
身份参考与风格参考指向矛盾时（比如强光人物配暗调风格），画面会被拉扯；此时应该降低风格参考的权重，而不是反复重抽。When an identity reference and a style reference pull in opposite directions (brightly lit subject, dark palette), the image gets stretched. Lower the style influence rather than retrying blindly.
一次合成到位，减少「再换一张参考图试试」的随机循环，这是批量产出最省时间的环节。One pass instead of a loop of swapping references — the biggest time sink in batch production goes away.
局部修改时明确「改什么 + 不改什么」，比让它重画整张图可控得多。When editing part of an image, state what changes and what must not. Far more controllable than asking for a redraw.
只做这一处修改：〈唯一目标，例如把季节改成初冬午后〉。
保持不变：人物身份与面部特征、服装与配饰、姿势、镜头角度、裁切、光线方向、所有物体位置。
除上述修改外，其余像素级细节尽量保持原样。Make exactly one change: <the single target, e.g. change the season to a cold early-winter afternoon>.
Keep unchanged: the subject's identity and facial features, wardrobe and accessories, pose, camera angle, crop, light direction, and the position of every object.
Apart from that change, keep everything else as close to the original as possible.把「保持不变」写成清单而不是一句话，逐条列出来能显著降低漏改。Write the keep-list as a list rather than a sentence. Itemising it noticeably reduces accidental edits.
自然语言编辑是按指令做局部更新，逐条点名不变量能阻止模型顺手「重新想象」其它部分，这是定向编辑与整图重生成的根本差别。Natural-language editing updates only the instructed region. Naming the invariants explicitly is what stops the model from quietly reimagining everything else — the real difference between surgical editing and regeneration.
指令越长越容易漏检不变量。如果连续两轮都改错了不相关的地方，把不变量拆成多轮小改。Longer instructions mean more invariants get dropped. If two rounds in a row touch something they should not, split the keep-list across several smaller rounds.
从「整张重抽、碰运气」变成可预期的局部修补，返修轮次和重抽成本同时下降。Turns "redraw and hope" into predictable patching, cutting both revision rounds and generation spend.
主体、动作、环境、构图、风格、光线、画幅各占一个位置，缺哪项补哪项，出图更可预期。Subject, action, environment, composition, style, lighting and aspect ratio each get a slot. Fill the gaps deliberately and results become predictable.
主体：〈蓬松的灰色长毛猫〉
动作：〈在窗台上打盹〉
环境：〈老式公寓的窗边〉
构图：〈中景平视，主体偏右〉
风格：〈温暖写实摄影〉
光线：〈清晨侧逆光〉
画幅：3:2Subject: <a fluffy long-haired grey cat>
Action: <dozing on a windowsill>
Environment: <the window of an old apartment>
Composition: <medium shot, eye level, subject to the right>
Style: <warm realistic photography>
Lighting: <early morning backlight from the side>
Aspect ratio: 3:2官方指南把构图、风格、画质、画幅列为独立维度，逐项说明比笼统形容有效得多。Official guidance treats composition, style, image quality and aspect ratio as separate dimensions — stating each beats one vague adjective.
官方提示指南明确建议在提示词里说明构图、风格、画质与画幅；模型按维度理解这些槽位，比把期望揉进一段散文更可执行。Official prompting guidance asks you to state composition, style, quality and aspect ratio. Models slot these dimensions; they are far more actionable than a paragraph of prose.
别把质感词堆在开头当咒语。形容词的优先级低于名词和动作：先修好主体与动作，再谈风格。Do not treat quality words as incantations at the top. Adjectives rank below nouns and actions: fix the subject and the action first, then style.
出图命中率提高，减少「再抽一次看看」的次数，也让提示词变得可复用、可交给别人。Raises the hit rate, cuts the retry loop, and makes prompts reusable — handable to another person as-is.
文字排版已经是新一代图像模型的明确能力，让它排字比自己拼图更快也更整齐。Text rendering is an explicit capability of current image models. Let them set the type instead of compositing it yourself.
生成一张 3:4 竖版海报。主标题「〈标题文字〉」置于画面上方居中，占据约三分之一宽度，字形清晰锐利；副标题「〈副标题〉」在主标题正下方，字号约为主标题的三分之一；底部留出 〈主题〉 信息区；〈配色〉 背景，标题文字为 〈对比色〉；整体版式干净、对齐精确、无多余装饰。Create a 3:4 vertical poster. The headline "<headline text>" sits centred near the top, about a third of the width, crisp and sharply rendered. The subhead "<subhead text>" sits directly beneath it at roughly a third of the headline size. Reserve a <topic> information area at the bottom. Background in <palette>, headline type in <contrast colour>. Clean layout, precise alignment, no decorative clutter.正文段落和需要严格遵循品牌规范的排版不适合交给模型排，仍然需要专业工具。Body paragraphs and strict brand-compliant typography still belong in a design tool. This is for display type, not for documents.
新一代图像模型把文字渲染列为主要改进方向之一，产品页也把「文字渲染更清晰准确」单独列为一项能力，版式理解同步提升。Text rendering is listed as a headline improvement in current image models, and the product documentation calls out clearer, more accurate text plus better layout understanding as distinct capabilities.
仍然需要人工逐字校对；长文案、多语种混排和带精确尺寸要求的版面仍要后期修字。Proofreading is still mandatory. Long copy, mixed scripts and layouts with precise typographic requirements still need manual correction.
省掉「设计稿 + 排版工具 + 导出」的一整套往返，拿到可用的初稿只要几分钟。Removes an entire design-and-export round trip; a usable first draft lands in minutes.
先决定这张图用在哪、要多宽，再开始生成；画幅定错就得重抽，这是返工的主要来源。Decide where the image will be used and how wide it must be before generating. A wrong aspect ratio means regenerating — the top cause of rework.
〈Midjourney 写法〉〈画面描述〉 --ar 9:16 --stylize 150 --no text, watermark --seed 20261102
〈Gemini 系写法〉〈画面描述〉，aspect_ratio 9:16，image_size 2K，保留〈不变量〉。<Midjourney form> <description> --ar 9:16 --stylize 150 --no text, watermark --seed 20261102
<Gemini family form> <description>, aspect_ratio 9:16, image_size 2K, preserving <invariants>.拿到满意的种子就把它记下来，那是这张图唯一能精确复现的入口。Save the seed of any result you like. It is the only exact reproduction handle you get.
Midjourney 把画幅、负面元素、种子、风格化强度做成独立参数，Gemini 系模型把 aspect_ratio 与 image_size 做成独立旋钮；这些旋钮先定好，画面才不会在后期被裁。Midjourney exposes aspect ratio, exclusions, seed and stylisation as separate flags; the Gemini family exposes aspect_ratio and image_size as their own dials. Set them first and nothing has to be cropped away later.
把尺寸留到「之后再说」是返工的头号来源：构图按方图设计，最后要塞进竖版，人物就被切掉了。Deferring size decisions is the number one source of rework: compose for a square, then force it into a vertical and the subject gets cropped out.
同一套参数可以复用，同风格的多张图批量产出时不再每次重新试，也不再返工裁剪。One parameter set serves many images, so batch production in a single style stops being a fresh experiment every time — and nothing gets cropped later.
用分镜、参考图和短镜头把不可控的生成过程切成可预测的流水线。Break an uncontrollable generation process into a predictable pipeline of shots, references and short clips.
有参考图时不要再去描述人物长相，用简单代词指代主体，把提示词全部留给运动。With a reference frame in hand, stop describing the face. Point at the subject with a pronoun and give the prompt entirely to movement.
The subject turns slowly toward the window, a faint smile forming. The camera slowly pushes in. Warm afternoon light catches her face.The subject turns slowly toward the window, a faint smile forming. The camera slowly pushes in. Warm afternoon light catches her face.如果结果没动起来，通常是提示词在描述画面长什么样，而不是发生了什么。If nothing moves, the prompt is almost certainly describing what the frame looks like instead of what happens in it.
Runway 官方指南指出：图生视频时输入图已经决定了构图、光线与外观，提示词应聚焦随时间变化的部分；官方示例也用「the subject」「she」这样简单的指代。重复描述外观反而让模型在图与文字之间折中。Runway's official guide states that in image-to-video the input already fixes composition, lighting and appearance, so the prompt should concentrate on what changes. Their examples refer to the subject simply — "the subject", "she". Repeating the appearance makes the model negotiate between the image and the text.
不要在提示词里改图里已有的细节（衣服颜色、发型、光线方向）；图文冲突时结果会闪烁和漂移。Do not contradict what is already in the frame — wardrobe colour, hairstyle, light direction. When text and image disagree, the result flickers and drifts.
一个动作一条提示词就能出可用片段，不再需要反复重抽整段。One action per prompt yields usable clips, instead of re-rolling an entire segment over and over.
短视频模型在短时长里最稳，长片靠剪辑拼接，而不是靠一条更长的提示词。Short-video models are stable at short durations. Long pieces come from editing, not from a longer prompt.
5 seconds, one action only: she opens the envelope and looks inside. Static camera, soft window light from the left, no camera movement.5 seconds, one action only: she opens the envelope and looks inside. Static camera, soft window light from the left, no camera movement.动作确实需要更长时，先加长时长再重抽，而不是让它自己加速把动作做完。If the action genuinely needs more time, extend the duration and re-roll — do not let the model rush through it instead.
片段越长，脸、衣着和光线越容易中途漂移；把每个片段控制在几秒内，漂移就被限制在可接受的范围内，剪辑再把它们接起来。The longer the clip, the more the face, wardrobe and light drift midway. Keeping each clip to a few seconds bounds the drift, and the edit stitches the pieces together.
一条提示词塞进多个动作，模型通常会压缩时间或干脆忽略其中一个——结果往往是三个半成品动作。Several actions in one prompt get time-compressed or dropped, usually leaving three half-finished actions.
用五个稳定片段拼出二十五秒，比抽一段二十五秒的成功率高得多，成本也更好控制。Five stable clips assembled into twenty-five seconds beats chasing one twenty-five-second take — and the cost stays predictable.
固定顺序的五段式覆盖了绝大多数镜头需求，也让你能逐段替换调试。A fixed five-part order covers almost every shot and lets you debug one segment at a time.
[摄影] 中景，手持轻微晃动
[主体] 二十多岁女性，棕色波浪发，脸上有浅雀斑
[动作] 推开爵士俱乐部的木门并回头
[环境] 午夜的爵士俱乐部，烟雾缭绕，舞台灯在远处
[风格] 35mm 电影感，暖调霓虹，浅景深[Cinematography] medium shot, slight handheld drift
[Subject] a woman in her twenties, wavy brown hair, light freckles
[Action] pushes open the jazz club door and looks back
[Context] a jazz club at midnight, hazy with smoke, stage lights in the distance
[Style] 35mm cinematic, warm neon, shallow depth of field对白要单独成句、逐字写清楚，交给支持音频生成的模型处理。Keep dialogue in its own line, written out word for word, and use a model that generates audio.
Google DeepMind 的 Veo 指南把可用要素列为镜头构图与运动、风格、光线、角色描述、地点、动作与对白；五段式正是这些要素的一个不重不漏的排列，官方 Veo 3.1 指南也给出同样的五段公式。Google DeepMind's Veo guide lists the usable elements as framing and camera motion, style, lighting, character description, location, action and dialogue. The five-part order is exactly those elements without duplication — and Google's Veo 3.1 guide gives the same five-part formula.
「震撼」「大片」「史诗」这类形容词几乎不携带信息。把它们换成镜头、景别和光线描述，模型才知道往哪儿使力。Words like "stunning", "epic" or "blockbuster" carry almost no information. Replace them with camera, framing and light — that is where the model can act.
提示词不再靠感觉写，出问题时能精确定位到是哪一段写得不对。Prompt writing stops being guesswork; when output is off, you know which segment to change.
把每个镜头写成「观众看到什么、多长、为什么存在」，再决定哪些镜头真的需要生成。Write each shot as what the audience sees, how long it runs and why it exists — then decide which shots actually need generating.
把下面的脚本拆成分镜表，列为：镜头号 / 时长 / 景别 / 画面内容 / 声音 / 素材类型（生成视频 / 生成静帧 / 实拍）。然后单列一节，指出哪几个镜头用「静帧 + 缓慢推进」就足够、不必生成视频，并说明理由。Break the script below into a shot list with columns: shot number / duration / framing / content / sound / asset type (generated video, generated still, live). Then add a short section naming which shots would work as a still with a slow push instead of generated video, with your reasoning.分镜表别一开始就写太细：先排结构，只在关键镜头上加细节。Do not over-detail it at first. Structure first, detail only on the shots that carry the piece.
生成便宜，决策昂贵。先把镜头结构定下来，就避免了「生成完再凑故事」这种最贵的返工。Generation is cheap; decisions are not. Locking the shot structure first avoids the most expensive kind of rework — building a story after the footage exists.
分镜表太细会拖慢启动。判断标准是：它是否已经决定了「哪些镜头要生成」和「各镜头多长」。An over-detailed shot list slows the start. The bar is simple: it should already settle which shots get generated and how long each runs.
无效生成大幅减少，算力花在真正需要的镜头上，整体成本下降一大截。Wasteful generations drop sharply and the budget lands on the shots that matter.
跨镜头的一致性来自素材库和统一后期，而不是来自更长的提示词。Consistency across shots comes from the asset library and a unified post pass, not from longer prompts.
参考图 1 = 同一人物定妆图（正面 / 四分之三 / 侧面），参考图 2 = 同一场景。请按分镜表第 〈N〉 镜生成：〈动作〉，镜头〈运动〉，光线方向与参考图一致，不要改变人物身份、服装与场景结构。Reference 1 = the same character sheet (front / three-quarter / profile), reference 2 = the same location. Generate shot <N> from the shot list: <action>, camera <move>, light direction matching the references. Do not change the character's identity, wardrobe, or the structure of the location.不要拿上一段视频里截出来的模糊帧当参考图——模糊会被继承，清晰才有用。Never use a blurry frame lifted from a previous clip as a reference. Blur gets inherited; sharpness does.
参考图是硬锚点、文字是软描述；统一的调色与声音再把不同批次生成的片段缝合成一部作品——这一步对成片质感的提升，往往超过换一个更强的模型。References are hard anchors and text is a soft description. A single grade and a single sound bed then stitch separately generated clips into one piece — and this step typically lifts perceived quality more than any model upgrade.
参考图不是三维绑定，不能保证每一帧都像同一个演员；商业广告和连续剧角色必须保留人工筛选、重生成和修面的时间。A reference is not a 3D rig and cannot guarantee every frame reads as the same actor. Commercial work and recurring characters still need time for human selection, re-generation and face retouching.
多镜头素材从「各自好看但不像一部」变成「可以剪在一起」，这是系列内容能否成立的分水岭。Turns "each shot looks good but they do not belong together" into footage that can actually be cut together — the dividing line for series work.
同一个提示词先在低成本档位验证动作是否成立，再上高成本档位做最终版本。Validate the action on a low-cost tier with the same prompt, then pay for the final pass only when the shot is proven.
（批处理脚本思路）遍历 refs/ 下的参考图，每张配 prompts.json 中同名文件的动作提示词：先以低成本档位生成 5 秒草稿；成功后下载并把文件名记入 results.csv，失败写入 errors.log；为每次运行设置任务数量上限；开始前先打印预计消耗，等我确认再提交。<Batch script outline> Walk the references in refs/, pairing each with the motion prompt of the same name in prompts.json: generate a 5-second draft on the low-cost tier first; on success, download it and record it in results.csv, and write failures to errors.log; cap the number of tasks per run; print the estimated spend first and wait for my confirmation before submitting.让 coding agent 写批处理脚本时，记得要求它先读官方文档确认参数名，不要凭记忆写。When you let a coding agent write that script, make it read the official docs for parameter names instead of relying on memory.
Runway 的文档明确区分标准档与 Turbo 档的成本差异，并建议先用低成本档探索、确认后再升级；把成本分层用在迭代流程里，是可控预算的基本做法。Runway's documentation separates standard and Turbo tiers by cost and recommends exploring on the cheaper tier before upgrading. Layering your budget that way is the basic move for predictable spend.
草稿档位会掩盖画质和细节问题，所以最终版本仍要留一次高质量重跑的预算，不能只靠草稿交付。Cheap tiers hide quality and detail problems, so keep budget for one final high-quality pass. Drafts are never the deliverable.
大部分镜头只跑草稿就定稿，重抽次数受控，预算从「看运气」变成「可预测」。Most shots get finalised from a draft, retries stay bounded, and the budget becomes predictable rather than a matter of luck.
跨领域通用的底层方法：把指令写成规格，把验收写成清单。The layer underneath every craft: write instructions as specifications and acceptance as checklists.
「帮我写个好看的」是愿望；「生成 X，约束 Y，验收 Z」才是能被执行的指令。"Make something nice" is a wish. "Produce X, under constraints Y, judged by Z" is an instruction that can be executed.
目标：〈一句可验证的目标〉。
约束：只使用〈数据来源〉；不出现〈禁止元素〉；输出为〈形式与画幅〉。
验收：〈逐条可检查的标准，每条一行〉。
若任何一条验收标准无法判断，请先问我，不要自行解释。Goal: <one verifiable outcome>.
Constraints: use only <data source>; no <prohibited elements>; output as <format and aspect ratio>.
Acceptance: <one checkable criterion per line>.
If any acceptance criterion cannot be judged, ask me before proceeding — do not interpret it yourself.最后那句「无法判断就问我」能挡住模型最常见的一类错误：自己把模糊需求补成一个看似合理的解释。That last line blocks the most common failure: the model quietly turning an ambiguous brief into a confident guess.
官方提示策略的核心就是让指令清晰具体，因为模型无法猜测意图。可判定性把「沟通质量」变成「工程问题」，也让双方有共同的完成定义。Official prompting guidance is built on making instructions clear, because models cannot guess intent. Judgeability turns a communication problem into an engineering one with a shared definition of done.
约束不是越多越好，十条约束难以全部满足。先给最关键的三条，其余按问题出现再加。More constraints are not better — ten of them will not all hold. Start with the three that matter and add the rest when problems show up.
返工从「再改改」变成「核对清单」，双方都知道还差什么，沟通轮次显著减少。Rework becomes "check the list" instead of "tweak it again", and both sides know exactly what is missing.
同时改三个要素，出了结果你也不知道是哪一个起了作用。Change three elements at once and you still do not know which one did the work.
这是当前的提示词和结果：〈内容〉。
请只改一个要素来改善〈具体问题〉，并说明你改了哪一个、为什么这么改会有效。
先只给出修改后的提示词，不要重新生成，也不要同时改其他部分。Here is the current prompt and result: <content>.
Change exactly one element to improve <specific problem>, and tell me which element you changed and why that change should help.
Give me the revised prompt only — do not regenerate yet, and do not touch anything else.先让它解释改动理由，再让它生成——理由说不通的那次改动，本来就不该执行。Have it justify the change before it generates. A change whose rationale does not hold was never worth running.
单变量对照让每次尝试都携带信息；多变量齐调会破坏因果，你既学不到东西，也无法把问题归因到具体某处。Single-variable comparisons make every attempt informative. Changing several at once destroys the causal link, so nothing is learned and nothing can be attributed.
单变量迭代在完全没方向时起步会显得慢，但快的方式是随机乱调——那种调法通常要多花好几倍次数才收敛。One-at-a-time feels slow when you have no direction, but the fast alternative is random tweaking, which usually takes several times as many attempts to converge.
从随机试错变成可学习的迭代，几次就能逼近目标，而且下一件事会更快。Turns blind trial into a learnable loop: a few rounds reach the target, and the next task starts faster because you brought the evidence with you.
事先写好评判标准，产出才有对照物；没有对照物时，所有讨论都会滑向审美偏好。Write the criteria in advance so the output has something to be measured against. Without them every discussion drifts into taste.
请按下面的验收清单自检这份产出，逐条给出「通过 / 不通过」与依据，并引用原文位置，最后给出每条不通过项的最小修改建议：
1) 〈可判定标准〉
2) 〈可判定标准〉
3) 〈可判定标准〉
4) 〈可判定标准〉
不要改写产出内容，只做评估。Self-check this output against the acceptance list below. For each item give pass or fail with the evidence and the location in the text, then give the smallest possible fix for each failure:
1) <judgeable criterion>
2) <judgeable criterion>
3) <judgeable criterion>
4) <judgeable criterion>
Do not rewrite the output — assess it only.清单本身也接受检查：凡是读起来还需要争论的条目，就说明它还不够可判定。The checklist deserves the same scrutiny: any item that still sparks debate is not judgeable enough yet.
把隐式的质量标准外显成可核对项之后，模型更容易定位问题并做小幅修正，而不是笼统地道歉或整段重写。Once implicit standards are made explicit and checkable, the model can locate a problem and patch it, instead of apologising generically or rewriting wholesale.
写「看起来专业」「读起来舒服」这种没法判定的条目等于没写；把主观词换成数量、位置、可对比的事实。Criteria like "looks professional" or "reads well" are not criteria. Replace subjective words with counts, positions and comparable facts.
质量检查从「凭感觉来回讨论」变成一次带出处的检查，评审和返修都有据可依。Turns quality review from an argument about taste into one check with receipts — review and revision both become evidence-based.
人对 AI 速度的主观感受并不可靠；METR 的随机对照试验给出了一个明确且反直觉的结论。Your sense of your own speed is not a reliable instrument. METR's randomized controlled trial produced an explicit and counter-intuitive result.
这是我最近 10 个任务的记录（任务类型、纯手工耗时、AI 辅助耗时、审查耗时）：〈数据〉。请按任务类型算出净节省，指出哪些类型实际上变慢了，并给出下个月的三条调整建议。不要安慰我，只要结论。Here are my last 10 tasks (type, manual time, AI-assisted time, review time): <data>. Compute the net saving per task type, name the categories where AI actually made things slower, and give me three adjustments for next month. No reassurance — conclusions only.最后那句「不要安慰我」很重要：模型默认会倾向于给出正面的总结。That last instruction matters — models default to a positive summary unless told otherwise.
METR 的随机对照试验让 16 位资深开源开发者处理自己仓库里 246 个真实 issue（平均每个约两小时）：允许使用 AI 时，他们平均多花了 19% 的时间；开发者原本预期会快 24%，体验过变慢之后仍相信自己快了 20%。METR 明确说明这是 2025 年初模型能力在特定场景下的快照，并不代表 AI 不会提升效率。结论是：体感不能作为依据，记录才可以。METR's randomized controlled trial had 16 experienced open-source developers work on 246 real issues from their own repositories, averaging about two hours each. With AI allowed they took 19% longer. Developers had expected a 24% speedup and, even after experiencing the slowdown, still believed they were 20% faster. METR is explicit that this is a snapshot of early-2025 model capability in one specific setting, not a claim that AI never helps. The takeaway: impressions are not evidence, records are.
单个样本、单一场景的结论不能外推到所有工作；你自己的数据同样需要按任务类型分层看，整体平均会掩盖掉关键差异。One sample in one setting does not generalise to all work — and your own numbers need the same stratification, because an overall average hides the differences that matter.
把「感觉快了」变成一张能复盘的表，也让你清楚地知道哪些环节值得继续用 AI、哪些该收手。Turns "it felt faster" into a table you can review, and tells you which parts of the work deserve more AI and which need less.
没有匹配的技巧，换个关键词试试。No match. Try a different keyword.
诚实的部分The honest part
METR 做了一项随机对照试验：让 16 位资深开源开发者处理自己仓库里 246 个真实 issue，平均每个任务约两小时。允许使用 AI 工具时，他们平均多花了 19% 的时间。开发者原本预期会快 24%，真正体验过变慢之后，仍然相信自己快了 20%。METR 明确说明，这是 2025 年初模型能力在特定场景下的一张快照，并不代表 AI 永远不会提升效率。但它足以说明一件事：靠体感判断 AI 带来的提效并不可靠。 METR ran a randomized controlled trial: 16 experienced open-source developers worked on 246 real issues from their own repositories, averaging about two hours per task. With AI tools allowed, they took 19% longer. Developers had expected a 24% speedup and, even after experiencing the slowdown, still believed they were 20% faster. METR is explicit that this is a snapshot of early-2025 model capability in one specific setting, not a claim that AI never speeds up developers. What it does establish is that your feeling about your own speed is not a reliable instrument.
索引Index
下面这些是本文引用的官方文档与产品页面。技巧本身会过期，文档不会——遇到分歧时以文档为准。 These are the official documentation and product pages cited in this playbook. Techniques expire; documentation does not. When they disagree, the docs win.