报价八千做了三个月，需求是在微信里一句句「顺便」加出来的，微信聊天记录导出留证攻略

接活的时候说得很清楚：一个小程序，商品展示、购物车、下单、后台看订单，报价八千，一个月交付。

第一周就开始了。

“购物车能不能顺便加个凑单提醒？就一句话的事。”

“这个页面改成那种可以左右滑的吧，应该差不多。”

“对了，我们还有个线下门店的需求，能不能也放进去，逻辑是一样的。”

每一句听起来都不大。你当时也没多想，能做就做了，想着做完整一点对方也满意。

三个月后，功能是你最初承诺的三倍，对方却说"怎么还在做"，尾款也没结。你翻遍微信，想找一句"我当时同意加这么多"——翻不到。因为从来没有一次是"加这么多"，只有三十几次"顺便"。

一、需求不是变大的，是长出来的

外包或者接私活，需求变更本身不奇怪，也不可怕。真正的问题是：这些变更从来没有一起被看见过。

它们是以"一句话"为单位发生的。对提出的人来说，一句话的成本几乎为零；落到做的人身上，可能是一个模块、一次数据结构的调整、两天的返工。这种不对称，就是矛盾的来源。

微信里的需求增长，大致有四种方式：

四种里最贵的是第二种。因为"看着差不多"和"实际差不多"之间，可能隔着一次重写。而提这句话的人是真的觉得差不多——他看到的是界面，你看到的是实现。

二、变更不可怕，不被计价的变更才可怕

这里要先把一件事说清楚：需求变更不是坏事。 很多项目做着做着，双方才真正想明白要什么，这是正常过程。

会出问题的是另一种情况——变更被默默吸收了。

每一次"顺便"你都做了，没有提工期，没有提费用，也没有提"那原来那个功能还做不做"。对方接收到的是：这些本来就在范围内。于是范围在一次次沉默里被重新定义了，而你手里连一个能拿出来对照的东西都没有。

所以这件事的正确做法不是"拒绝变更"，而是：让每一次变更都被计一次价。

计价有两种形式，二选一：

• 加工期或加费用：这个改动额外需要多少时间，或者多少
• 换掉别的东西：可以做，但要砍掉原来某个同等工作量的功能

第二种尤其重要，也尤其少人用。它把"加"变成了"换"，对方立刻就能感觉到这不是免费的——而这恰恰是它有效的原因。

三、当场估不准，就别当场答

上面这套方法有个前提：你要能在对方提出的时候，判断出这次改动有多大。而这件事恰恰是最难的——因为"顺便再加个"这种话，通常出现在你正忙的时候。

有一个判断方法很好用：看它动的是"表现"还是"假设"。

只动表现的改动，成本基本可控。 改文案、改颜色、换排序、调间距、加一个展示字段——这些改动停在外层，改动范围是你能直接看到的那一块。

动到假设的改动，成本会突然放大。 比如原来的下单流程里，一个订单默认只有一个收货地址；对方说"能不能支持多个地址"，这句话动的是一个底层假设。凡是建立在这个假设上的地方——结算、库存、发货、售后——都要重新过一遍，而且有些地方你可能已经不记得当初是怎么写的了。

判断的时候问自己一句就够了：“这个改动，会不会让之前某个’理所当然’不成立？” 会，就别当场给结论。

于是有了这条最实用的规则：当场估不准，就别当场答。

你可以说的是：「这个我看一下，半小时内给你一个影响评估，看它是加两天还是要动到别的地方。」

很多时候，吃亏不是因为答应了改动，是因为在你还没想清楚的时候说了一句"没问题"。那句话一出口，后面再谈成本，性质就变了。

而"我看一下再回你"这半句话，把被动变成了主动：你有了评估的时间，对方也有了心理预期。

四、三个锚点，把范围钉住

不需要写多正式的文档，只需要三个锚点。它们的作用不是约束对方，是让"当初说好的"这四个字有具体内容可指。

锚点一：范围——开工前的一版功能清单

不用长，列清楚有几块、每块是什么、不包含什么。"不包含什么"这一栏比前面所有内容都重要，因为绝大多数争议都发生在边界上，而不是核心功能上。

发过去，拿到一句明确的"对，就这些"。这一条消息就是后面所有对照的基准。

锚点二：变更——每次改动一条文字纪要

这是三个锚点里最关键的。每当对方提出新东西，用文字回一条，格式固定为三小段：

• 你提的是什么：复述一遍，确认理解一致
• 它带来什么影响：需要多长，或者会动到哪一块
• 怎么处理：加时间 / 加费用 / 换掉某个已有功能

举个例子：「你说的凑单提醒，需要在下单流程里加一层判断，比原计划多两天；如果不加时间，可以把后台的统计报表挪到二期，你看哪种？」

这条消息的作用不是推卸，是把成本当场摆出来。当场摆，对方可以选；事后再说，就变成了翻旧账。

语音提的需求要特别处理。 对方发语音说完，你要用文字复述一遍发出去，等一句确认。不是为了留证据，是因为语音里的需求最容易理解偏——复述一次，偏差当场就暴露了。

锚点三：阶段——做完一块确认一块

把项目拆成三到四个阶段，每阶段结束时发一条确认：这一段包含哪几项、目前完成到什么程度、下一步是什么。

分阶段确认的好处是：范围如果已经偏了，最多偏一个阶段就暴露，而不是三个月后一起爆。而且每个阶段的确认消息，天然就是进度的凭据。

五、导出这一步，按阶段做

导出不要等结束。按上面三个阶段各做一次，理由很实际：争议往往发生在项目后期，而那时候群里可能已经聊了几千条，靠翻找是不现实的。

三个导出时点：

• 范围确认之后：导出一次，覆盖从第一次沟通到范围定稿
• 每个阶段结束：导出一次，覆盖该阶段的沟通
• 出现分歧的当天：立刻导出，不要等事情解决完再补

导出时有两个讲究。一是时间范围要覆盖第一次报价，不能只导最近两周——因为"当初怎么说的"往往在项目最开始；二是格式要能保留图片，原型截图、界面标注、你发给对方的示意图，这些经常是解释"为什么这么做"的关键，只导出文字的话，这些位置会变成空白。

这类工具只要支持按时间范围和按对象筛选、并且能保留图片与文件的位置就可以（轻虾导出助手是其中一种，支持导出成 HTML、PDF、Excel、TXT 几种格式，按用途各存一份即可）。

导出之后顺手检查两件事：翻到发原型图那几天，确认图还在；拉到开头，看时间是不是连续的。

六、四件做了等于没做的事

第一件：默默做完，最后一起提。 这是最常见也最吃亏的一种。变更成本要在发生的时候说，攒到最后说，性质就变成了要钱。

第二件：只在聊天里口头答应"可以做"。 "可以做"和"现在这个范围内可以做"是两回事，聊天里少几个字，事后差很多。

第三件：只存关键截图。 单张截图说明不了上下文——同一句"没问题"，配上前因后果是确认，单独拿出来就可能被读成别的。要存的是连续的、带时间的记录。

第四件：不做阶段确认。 全程只在最后验收一次，等于把三个月的范围变化都压到一个节点上处理。

七、建议的归档结构

私活项目-2026/
├── 01-范围/
│ ├── 功能清单_v1（含不包含项）.txt
│ └── 范围确认记录.txt
├── 02-变更/
│ ├── 变更纪要_按序号.txt
│ └── 处理结论（加工期/加费用/换功能）.txt
├── 03-阶段确认/
│ ├── 阶段一_确认.txt
│ ├── 阶段二_确认.txt
│ └── 阶段三_确认.txt
├── 04-图片与原型/
│ └── 按变更序号命名/
└── 05-会话导出（只读）/
├── 阶段零_报价与范围.html
└── 各阶段.html

02 里每条变更一个序号，04 里的图片按同一个序号命名，这样图和变更能对上——事后最容易说不清的，往往就是"当时你发的是哪张图"。

八、几个常被问到的问题

对方不愿意确认，觉得太麻烦怎么办？

把动作做轻：不用文档，不用签字，就是微信里一条三小段的消息，对方回一个"可以"就够了。真正在消耗时间的是事后扯皮，不是这一分钟。

已经开始做了，前面什么都没留，还来得及吗？

来得及，从现在这一版开始。当前做到哪一步，就发一条阶段确认，把"目前包含这几项"写清楚。这一条之后的范围就清楚了，之前的损失到此为止。

对方的语音需求，要不要每句都复述？

涉及功能和工期的一定要。闲聊不用。判断标准很简单：这句话会不会影响你要做多少事。

对方说"这些之前都说好的，都包含在里面"，怎么回应？

不要争"说没说过"，把范围清单拿出来逐项对。清单上有的，不用争；清单上没有的，看它在哪一条变更纪要里被加进来、当时是怎么处理的。讨论一旦落到具体条目上，就很难再停留在"我说过你说过"上了。 这也是范围清单真正的用处——它不是用来约束谁的，是用来让讨论有地方落脚的。

项目已经结束很久了，这些记录还有用吗？

有用，而且用处往往在几个月后。二期续做、对方换了对接人、有人翻出来说某个功能当时答应过——这些情况都发生在项目结束之后。留一份完整的记录，成本是导出那几分钟，缺了它，很多事就只能靠印象。

要不要把导出的文件发给对方？

不必。这些是给自己用的，用来在需要的时候把事情说清楚。真要沟通，给的是那条三小段的变更纪要，不是几千条原始记录。

需求变多这件事，几乎每个项目都会发生。

它变成问题的时刻，不是对方说出"顺便再加个"的那一秒，而是你默默做完、什么都没说的那一次。那一次之后，范围就再也不清楚了。

一句复述、一条纪要、一段确认，成本加起来不到十分钟。而它们决定了三个月之后，你能不能把这件事说清楚。