client-revisions

客户修订

控制动画项目中的修订轮次和范围蔓延：明确修订的定义，在工作说明书（SOW）中限制轮次，以正确的方式收集反馈，将含糊的意见转化为可执行的修改，并通过礼貌地将超出范围的工作列为变更单来婉拒。

适用场景

当反馈不断增加、客户持续提出“微调”、需要在 SOW 中加入修订条款、需要在修改文件前解读含糊的意见（“让它更出彩”），或请求显然已超出工作范围、需要通过变更单回复时，使用此方法。

决策树——修改文件前先对每条意见进行分类

整个技能就是针对每条意见作出一个判断：这是修订、新请求，还是仅仅表述含糊？ 在打开项目之前，先逐条判断。

A note arrives.
├─ Is it vague ("make it pop", "feels off")?
│   └─ YES → translate to a decidable choice + ask for a timestamp.
│            Do NOT act yet. Re-classify once it's concrete.
└─ Is it concrete?
    ├─ Does it change something ALREADY approved in brief/board?
    │   (timing, palette colour, approved-copy edit, a fix)
    │   └─ YES → REVISION. Counts against the round cap. Do it.
    └─ Is it anything NOT in the approved brief/board?
        (new scene, +runtime, new concept, new ratio, new asset,
         reversing an approved decision, "let's also try…")
        └─ YES → NEW REQUEST. Send the change-order email. Quote it.
                 Do NOT silently absorb it.

Is feedback scattered across people/messages?
└─ YES → STOP. Send the consolidated-feedback request first; one
         document, all stakeholders, conflicts resolved by the client.

判断规则：如果不确定某条意见属于修订还是新请求，就问：“这件事之前是否已经确定并获批？”如果是 → 修订。如果新增、替换或推翻了原有内容 → 新请求。

核心区别：修订与新请求

这一句话可以避免大多数争议——把它写进 SOW 和反馈请求中：

• 修订 = 修改已包含在获批简报/分镜板中的内容（调整时长、从调色板中更换颜色、替换已获批的文字、修复故障）。
• 新请求 = 任何未包含在获批简报/分镜板中的内容（新场景、增加一秒时长、不同的概念、新画面比例、此前未提供的徽标、“我们再试试……”）。

修订包含在约定上限内。新请求则需单独报价并安排档期，作为变更单处理。应在第 1 轮之前说明这一点，而不是发生争议后才说。

SOW 修订上限条款

将以下内容加入合同/报价单：

REVISIONS
This project includes [2] rounds of revisions. A "round" is one
consolidated set of feedback, collected from all stakeholders and
delivered in a single document, then addressed in full.

Included (a revision): changes to elements already approved in the
brief and storyboard — timing, pacing, colours from the agreed
palette, approved copy edits, and fixes.

Not included (a new request / change order): new scenes, added
runtime, new concepts or directions, additional formats or aspect
ratios, new assets not previously supplied, or feedback that
reverses a previously approved decision.

New requests are quoted as a change order before work proceeds and
may affect the timeline. Additional revision rounds beyond those
included are billed at [day rate]. Feedback split across multiple
messages may be treated as separate rounds.

收到反馈后的工作流

1. 停下。 暂时不要打开项目文件。
2. 汇总。 如果反馈零散或来自多人，请发送下方的汇总反馈请求。将所有相关方的意见汇总到一份文档中，去重并消除冲突。
3. 逐条分类，根据上述区别判断是修订还是新请求。
4. 解读含糊的意见，先提出有针对性的问题，再开始执行（见下方的解读模板）。
5. 针对新请求，发送变更单邮件——不要默默将其纳入工作范围。
6. 记录轮次。 记录当前是第几轮，让双方都能清楚看到上限。

汇总反馈请求模板

Subject: Feedback on [project] — Round [N]

Hi [name],

Ready for your notes on V[n]. To turn these around fast and cleanly,
could you send everything in one go:

• Gather feedback from everyone who needs to weigh in and merge it
  into a single list (if two notes conflict, tell me which wins).
• Use timestamps where you can — "at 0:08 the logo feels slow."
• Tell me the problem, not the fix — "the intro drags" is more useful
  than "make it faster," because it lets me solve it properly.
• Flag any must-have vs nice-to-have.

Send it all together and I'll address the full set in this round.
Notes that arrive after, or in separate messages, may roll into the
next round. Thanks!

含糊反馈解读模板

不要根据含糊的意见直接采取行动。先将其转化为有针对性的问题：

客户说	你可以追问
“让它更出彩”	“是想要更鲜艳的颜色、更快的节奏、更大的缩放变化，还是更强的音效？请指出一个已经很出彩的片段。”
“感觉不太对”	“是节奏、颜色、字体还是信息传达不太对？哪 2 秒最让你觉得不对？”
“让它更显高端”	“你更倾向于更缓和的缓动、更多留白、更克制的调色板，还是更精致的字体？”
“能不能更有动感？”	“你想要更多镜头移动、更快的剪辑，还是更多元素运动？”
“我不太喜欢”	“具体哪里不喜欢？你觉得‘喜欢’的效果是什么样？提供参考会很有帮助。”
“做得更大/更有力”	“你想要更大的缩放、更粗的字体、更高的对比度，还是更长的展示时间？”
“好像少了点什么”	“是场景、信息、品牌元素，还是活力？具体在时间线的哪个位置？”
“能不能再加强一点？”	“是节奏、颜色还是音效？请给我看看一个已经具备你想要的那种活力的片段。”

规则：将每种感受都转化为具体、可判断的选项，并询问对应的时间戳。

超出范围/变更单邮件模板

Subject: [project] — quick note on the new request

Hi [name],

Happy to help with [the new request] — flagging that it sits outside
the approved brief/storyboard, so it's a change rather than a revision
under our current scope.

Here's what it takes:
  • Work: [what's involved]
  • Cost: [amount / day estimate]
  • Timeline impact: [+X days / new delivery date]

If you'd like to go ahead, reply "approved" and I'll add it and update
the schedule. If you'd rather keep to the original scope and budget,
no problem — we'll proceed as planned and can revisit this later.

Either way works for me; just let me know which you prefer.

语气提示：保持协作态度，绝不指责。提供选择（继续还是暂缓）、给出费用，并说明对时间线的影响。目标是让取舍清晰可见，而不是直接说“不”。

实例

正确做法——先弄清模糊意见，再顺利执行：

客户：“开场感觉不太对。” → 你：“是节奏、颜色还是信息表达不太对？哪 2 秒最让你觉得不舒服？” → 客户：“Logo 出现前的 3 秒有点拖。” → 你重新调整入场时机（属于范围内的修改），并将其记为第 1 轮。一个问题就把一种感觉转化成了明确且在范围内的修改。

反面模式——默默把新增工作揽下来：

客户：“太喜欢了！我们还能不能再做一个方形版本，并加一个简短的片尾场景？” → 你悄悄把两项都做了，多花 2 天，导致项目延期且无利可图。

问题所在：新的宽高比和新场景都是新需求，不是修改——但如果不通过变更单就把它们揽下来，客户会觉得范围内工作不收费，形成先例，也会侵蚀你的利润空间。解决办法：回复变更单邮件，说明价格和对时间表的影响，让客户选择。说“很乐意——这是所需的工作”，并不等于拒绝。

常见错误

症状	原因	解决办法
修改轮次没完没了，永远没有“最终版”	没有定义上限，或没有引用上限	在第 1 轮开始前于 SOW 中注明上限；从第 N+1 轮起引用该上限
意见相互矛盾，反复重做	按每个人的反馈分别执行	要求提供一份汇总文档；由客户解决冲突
利润被“微调”蚕食殆尽	把新需求当作修改揽下来	对每条意见进行分类；新工作 → 通过变更单报价
按“让它更出彩”执行后，效果仍不对	照字面执行了模糊意见	修改文件前，先将意见转化为可判断的选项，并标注时间戳
重新修改已获批准的场景	未锁定审批关卡	将每个阶段的审批结果书面锁定；重开已锁定阶段 = 新需求
反馈断断续续地持续好几天	没有统一的提交截止时间	一轮 = 一份文档；之后提交的意见转入下一轮
客户觉得被斤斤计较	把变更单说成“拒绝”	将其表述为明确的取舍（继续或暂缓），而不是拒绝

交付成果规范——妥善处理修改应产出什么

产出物是邮件和合同措辞，而非文件。妥善处理意味着：

• SOW 在工作开始前定义“轮次”、设定轮次上限，并区分修改与新需求。
• 每轮反馈均汇总为一份文档，并按轮次编号记录。
• 执行前，将模糊意见转化为可判断的问题，并标注时间戳。
• 对新需求发送变更单邮件，说明工作内容、费用和对时间表的影响——绝不默默揽下。
• 始终保持协作语气：每封邮件都提供选择，并说明取舍。

完成前——检查清单

• SOW 说明轮次数量、“轮次”的定义，以及修改与新需求的区别。
• 反馈已汇总（所有相关方均在一份文档中，且冲突已解决）。
• 每条意见都已分类：修改 / 新需求 / 模糊且需要转化。
• 模糊意见已转化为有限选项，并请求提供时间戳。
• 新需求已作为变更单发送，并注明费用和对时间表的影响。
• 当前轮次编号已记录，且双方均可查看。
• 审批关卡已书面锁定；重开时标记为新工作。
• 每封客户邮件都提供选择，并避免指责语气。

速查

情况	做法
反馈由不同人员零散提交	发送反馈汇总请求；重新开始该轮
“让它更出彩”	转化为具体选项 + 请求提供时间戳
客户要求第 4 轮修改	引用 SOW 上限；按日费率报价额外一轮
“只加一个小场景就好”	发送变更单邮件；这是新工作
推翻已批准的决定	属于新需求，不是修改
后期新增宽高比	提交变更单——不同格式 = 不同交付成果
两位相关方意见冲突	开始工作前，要求客户选定要采纳的意见

参考文件

• references/sow-clauses.md — 完整的 SOW 修订章节、审批关卡措辞和“轮次”定义变体。
• references/email-templates.md — 汇总反馈、变更单、额外轮次和审批停滞邮件模板。
• references/feedback-translator.md — 扩展版模糊反馈到具体反馈的对照表，以及面向客户的“指出问题而非提供解决方案”指导说明。