「就改一个小地方」#

所有需求笑话的母题，其他段子都是它的变体。

它的杀伤力来自一个不对称：提需求的人只能看到界面，看不到界面后面。他看到的是一张表格多了一列；他没看到的是这张表被几个接口读、被几个任务 join、有没有缓存、有没有导出、有没有人在做报表。

所以「小地方」这个判断，在他掌握的信息范围内是完全正确的。错的不是判断力，是可见性。

「你照着淘宝做一个就行」#

这句话的完整版通常是：「功能不用那么多，照着淘宝做一个就行，先做个简单的。」

它的问题不在于「照着淘宝做」工作量有多大——而在于「不用那么多」是一句无法验收的话。验收标准在需求方脑子里，只有在成品面前才会显形。于是项目会精确地走到那个经典时刻：东西做完了，需求方说「我要的不是这个」。

把这句话翻译成工程语言，它其实是：「我没有需求文档，但我知道你做错了。」

「你先做，做完我就知道要什么了」#

这句话听起来像耍赖，但它描述了需求的真实形态。

需求不是一份躺在某处等着被收集的清单，它更像一个只能通过观察来测量的物理量——用户看到东西之后，才知道自己不要什么。原型法的整个理论基础就这一句。

真正的问题不是这句话，而是说完之后没有下一步：没有走查、没有反馈节点、没有「这一版不作为最终验收」的书面约定。那就变成了一次没有护栏的赌博。

「五彩斑斓的黑」#

设计圈的名场面，通常还会配上「logo 放大的同时缩小一点」「这个字要显得高端一点」。

它跟程序员的关系是：这就是另一种形态的「加个字段」。需求方描述的是一种感受，而实现方需要的是一组参数。感受无法直接编译，中间的翻译工作没人认领，就变成了来回拉锯。

「这个很简单吧，不就加个按钮」#

加按钮本身确实简单。不简单的是这个按钮按下去之后要发生的一切——尤其是当它按下去之后什么都不该发生的时候（权限不足、条件不满足），这部分通常没写进需求，但必须有人写出来。

「需求没变，只是补充说明了一下」#

这句是所有段子里最危险的一句。

前五句只是让工期变长，这一句让工期无法承诺。因为「补充说明」意味着需求的边界是开放的：任何一次口头补充都可以事后追认为「本来就是这个意思」。

它还有一种更隐蔽的形态：变更没有消失，只是从会上转移到了私聊里。三个月后回头看 git log，没有任何一条记录说这个功能为什么要长成现在这样。

1. 影响面三问#

不要直接回答「要多久」。先问三个问题，这时候的「不知道」是专业的：

• 改哪一个数据？ 找到那张表、那个字段，然后看它被谁读。
• 谁的行为会变？ 只有内部后台，还是外部用户能看到？
• 怎么验证它生效了？ 没有验收方式的变更，等于没有终点。

顺手做个习惯：每次口头变更之后，回到工单里补一行。一句话就够，比如「2026-09-26 追加：列表需按最后登录时间倒序」。这不是流程仪式，这是三个月后唯一的考古证据。

2. 让变更变便宜：expand-contract#

「重命名一个字段」在传统做法里是道送命题，因为它必须一次性完成——改代码、改数据库、同时上线。而 expand-contract（也叫 parallel change）把它拆成三步，每一步都可以单独上线、单独回滚：

1
-- 第 1 步 expand：只加，不改，不删。旧代码依然能跑
2
ALTER TABLE users ADD COLUMN full_name VARCHAR(100);  -- MySQL 8.0.12+ 可为 INSTANT
3

4
-- 应用层进入双写期：写 name 的同时也写 full_name，读仍然读 name

1
-- 第 2 步 migrate：分批回填历史数据
2
-- 关键是 LIMIT + 循环，别让一条 UPDATE 锁住整张表
3
UPDATE users SET full_name = name
4
WHERE full_name IS NULL
5
ORDER BY id
6
LIMIT 1000;

1
-- 第 3 步 contract：读切到 full_name，观察一到两个发布周期，确认没人在写旧列
2
-- 只有到这时才删
3
ALTER TABLE users DROP COLUMN name;

三步的价值不在于技术含量，而在于它把一次「大爆炸」变成三次可回滚的小操作。任何一步出事，退回去就好，不需要「全组通宵 + 祈祷」。

同样的思路适用于 API：先加新字段（expand），让所有调用方迁移（migrate），确认旧字段无人使用后再移除（contract）。这也是为什么「加字段容易、删字段难」——加字段在 expand 阶段，删字段在 contract 阶段，中间隔着一整个迁移期。

3. 用开关解耦「上线」和「发布」#

一个功能写到一半，需求方说「先上一半看看」。用分支硬扛，最后会得到一个活了三个月的 feature/new-list-v2 分支，和一个每次合并都像拆弹的下午。

用开关就简单得多：

1
if (flags.enabled('show-last-login', { userId })) {
2
  renderLastLogin(user);
3
}

代码可以先合进主干（部署了但不生效），再按白名单放量（灰度），最后全量——或者随时关掉。「上线」和「发布」变成两个独立动作，这是让变更便宜的最廉价手段之一。

代价是开关本身会积累。所以每条开关都该有一个删除日期，否则三年后你会拥有一套没人敢动的、由两百个 if 组成的考古现场。

4. 冻结窗口，和「大改小」#

发布前一天不接受新需求，这不是官僚主义，是风险管理——大改动的代价不是平均值，是尾部。一个改动如果非要赶在发布前上，那就把它拆成几次小改动，分开发布。

反过来说也成立：如果一个变更没法拆分，那它多半不是一个「小地方」。 这句话本身就是一句很好的需求评审用语。

5. 用能跑的东西代替文档#

需求歧义的解法不是写更长的文档（没人读），而是尽早给一个能点的东西。一个跑起来的丑原型，能在十分钟里暴露文档里三个月的歧义。

这其实也是在压那条变更成本曲线：把「发现要改」的时刻，从编码阶段提前到原型阶段。