“这里改一下就好了，怎么还要钱？”
对委托人来说，是看见成品以后才发现自己更喜欢另一种效果。对作者来说，可能是已确认的内容又要重新做。两边都觉得只是解释常识，争议就很容易从这一句开始。
判断是否属于额外工作，不能只看改动听起来大不大，要看它和最终确认的需求是什么关系。
配图：Mod 客栈公开定制页关于作者、赏金和阶段确认的说明。截图时间为 2026 年 10 月 2 日，不是实际交付案例。
约定没有做到，和后来想得更多，是两件事
假设需求写明某个按钮应关闭提示，但交付后点击没有反应，这是需要核对的交付问题。
如果按钮已经能关闭提示，你又希望它支持快捷键、记忆不同角色的设置，这就是新增内容。它很合理，也可能很有价值，但不能因为与原功能有关，就自动归入免费修正。
中间还会有一些不清楚的情况。例如原需求只说“颜色接近参考图”，双方却没有确认最终色稿。此时很难单凭一句“与想象不同”判定责任，需要回到参考材料和沟通记录具体讨论。
把具体请求放进这三类
| 情况 | 更适合怎样处理 |
|---|---|
| 没有达到已确认的要求 | 按约定提出修正，保留可复现证据 |
| 在已约定调整范围内细化 | 按范围、轮次和时间安排修改 |
| 增加功能、内容或适配环境 | 先评估额外费用与工期，再确认是否做 |
这张表是沟通方法，不替代双方协议。具体争议仍需要看原需求、确认记录和实际交付，不能只由一方贴个标签就算结束。
“包含两轮修改”也需要解释
一轮是指一条消息，还是一次集中反馈？改完发现原问题还在，算不算消耗新一轮？换了整体方向，与修正局部细节是不是同一类修改？这些都值得提前写清。
比较好执行的方式，是收到一个阶段成果后，先集中看完，把同一轮意见合并给作者。对方修改后，你再核对这些意见是否落实。
约定修改轮次不应被当成忽略交付缺陷的借口；委托人也不能用“还剩一轮”要求重做完全不同的方案。
反馈写具体，返工才不会来回转
“不够高级”“感觉不对”可以作为感受，但还需要补充可操作的部分。比如指出哪张截图里的哪块区域、在哪个动作下出现问题，希望保留什么、改变什么。
主观外观最好尽早确认。模型方向还没定就做完整材质，界面结构没确定就做完所有交互，后面的一次改动会牵连更多工作。阶段确认不是走形式，它决定哪些内容已经被双方接受。
确实想追加时，直接列成“新增需求”，问清费用、交付时间和是否影响当前版本。可以继续做，也可以先让原订单按约定完成，之后另谈。
在Mod 客栈发起定制前，把修改范围与验收标准一起写进去。这样真的到了“改一下”的时候，讨论的是一项具体工作，而不是谁更应该体谅谁。
