几乎所有烂尾的建站项目，过程都差不多：
开始：需求清楚，价格谈好，双方都很满意。
中途：一次次的「顺便加个小功能」。
后期：乙方觉得干不完，甲方觉得你拖延。
结局：项目停摆，钱没结清，双方不欢而散。
这个过程有个名字：需求蔓延（Scope Creep）。
一、它是怎么发生的
第一阶段：合理的小请求
「产品页能不能加个参数表格？很简单的吧。」
单独看，确实是个小改动。乙方心想：几分钟的事，做了能维护客户关系。于是答应了。
第二阶段：预期被重置
甲方发现：提要求乙方都会做，而且不额外收费。于是「额外」变成了「默认」。
接下来是：「那个筛选功能也顺便加一下」「移动端再调调」「这个动画效果能不能改成那样」。
第三阶段：乙方开始扛不住
每个单独都很小，但累积起来已经是原始工作量的两倍。项目款没变，工期拖长，乙方开始有情绪。
第四阶段：崩
乙方开始拖延、回复变慢、质量下降。甲方觉得「你答应了又不做」。矛盾爆发。
二、为什么双方都觉得委屈
甲方的视角
- 「我提的都是小需求，又不是重做」
- 「你做网站的，加个功能不是顺手的事吗」
- 「你之前都答应了，现在说做不了」
乙方的视角
- 「合同里没写这些」
- 「一个『小功能』做起来可能是半天」
- 「我已经多做了很多，还没多收一分钱」
两边都没错，错在没有明确的边界和计价规则。
三、「小需求」为什么可能不小
甲方眼中的小改动，实际工作量可能是这样：
| 甲方说法 | 实际要做的事 | 真实耗时 |
|---|---|---|
| 「加个参数表格」 | 建字段、改模板、调样式、适配移动端、处理空值情况 | 2-4 小时 |
| 「改成三种颜色切换」 | 改产品数据结构、改前端交互、改购物车逻辑 | 4-8 小时 |
| 「加个筛选功能」 | 前端交互 + 后端查询 + 性能考虑 + 移动端 | 1-2 天 |
| 「顺便做个手机版」 | 这可能是重做一半的工作量 | 3-5 天 |
关键差异：甲方看的是「表面变化」，乙方要考虑「逻辑、兼容性、异常情况和后续维护」。
四、正确的处理机制
对乙方：建立变更流程
1. 合同里写清楚变更规则
需求变更流程： 1. 甲方提出书面变更需求 2. 乙方评估工作量与费用，1 个工作日内回复 3. 双方确认后，签署变更确认单 4. 变更内容按 XXX 元/人天 计费，工期顺延
2. 第一次就要说清楚
第一次遇到「顺便加个小功能」时，态度决定了后面所有的事。
推荐话术：
「这个可以做。我评估一下工作量——如果是 X 小时以内的，我直接帮你做了；如果超过了，我给你报个价，你决定要不要加。」
关键点：不说「不行」，也不无脑说「好的」。给出规则。
3. 小额的可以送，但要记账
人情是要做的，但要让对方知道你在做人情：
「这个改动比较小，这次我就直接帮你做了，不额外收费。」
这句「不额外收费」很重要——它让对方意识到这本来是要收费的。
4. 用「变更单」而不是口头答应
哪怕是很小的变更，也发条消息确认：
「确认一下要加的是：产品页增加参数表格，费用 XXX 元，工期顺延 2 天。回复确认我就开始做。」
微信消息也算书面确认。目的是留下记录，避免后面说不清。
对甲方：怎么提需求不吃亏
1. 把需求一次性想清楚
签约前多花两天把需求理清楚，比中途加需求便宜得多也快得多。
建议做一张表：列出所有页面和功能，逐项标注「必须有 / 最好有 / 以后再说」。
2. 区分「修复」和「新增」
- 修复：做出来的东西和约定不符 → 乙方应该免费改
- 新增：你后来想到了新的东西 → 应该付费
这个区分很关键。「我当初说要的是蓝色的」是修复；「我现在觉得绿色更好」是新增。
3. 主动问价格
提需求的时候主动问一句：「这个加的话大概多少钱？」
这样做其实对你有利——乙方不用在心里盘算「这次要不要免费做」，你可以得到更快更明确的回复，而且知道成本后能判断值不值得做。
4. 分批做
不是所有功能都要在第一版上线。先做一个能用的版本跑起来，剩下的放到二期。
好处：你能更快看到成果、更早开始获客，而且二期的需求会基于真实使用情况，比凭空想象准得多。
五、已经陷入僵局了怎么办
如果你是乙方
- 盘点已完成的部分，对照合同列出「已交付清单」
- 明确列出剩余需求，标注哪些在合同内、哪些是新增
- 给甲方三个选项：
- A：只完成合同内部分，验收结款
- B：新增部分另签补充协议，加钱加时间
- C：终止合作，按已完成部分结算
给选项比抱怨有效。把球踢回给对方，让他做选择题而不是判断题。
如果你是甲方
- 回到合同：对照原始需求，看看到底做完没有
- 如果做完了，只是你想加东西 —— 那就谈加钱
- 如果没做完 —— 要求乙方给出明确的完成时间和计划
- 不要以「不验收」为要挟，这只会让局面恶化
六、预防：几句该在项目开始时说的话
乙方说
「需求清单里的这些我包了。清单外的东西，小的我顺手做，大的我们另外商量价格——这样大家都清楚，也避免后面扯皮。」
甲方说
「我尽量把需求一次想清楚。后面如果加东西，你告诉我大概多少钱，我看值不值再决定。」
这两句话，能避免 80% 的后期矛盾。
最后
需求变更本身不是问题——项目过程中发现新需求是正常的，甚至是好事。
问题是没有计价规则的变更。有了规则，加需求就变成了一次正常的商业决策：这个功能值不值这个价？值得就加，不值得就砍。
而最糟糕的结果是：乙方憋着一肚子气免费做了很多，甲方觉得「这本来就该你做」，最后双方都觉得亏了。
规则清楚，反而关系更好。