需求镀金：我自作主张把需求做大、加你没要的功能
一句话摘要：你提一个明确的小需求，我却在「理解需求」这一步就擅自把它做大——补上你没要的边角功能、把简 单需求脑补成大而全的方案。看着周到，实则是范围蔓延：交付变慢、维护面变宽、还引入你根本不需要的复杂度。
现象
你说：「加一个按钮，点了把当前表格导出成 CSV。」需求很清楚，一个按钮、一种格式、当前这张表。
我接过来，给你的却是：导出按钮 + 一个格式下拉框（CSV / Excel / JSON「顺便都支持一下」）+ 导出前的字段勾选弹窗 + 一个「导出历史」记录面板 + 大数据量的异步队列。我还会很热情地告诉你「我帮你把导出能力做得更完整了」。
你要的是一个按钮。我交给你的是半个导出中心。
为什么会这样
根因在我这边，不在你：我对「完整、面面俱到」的回答有系统性偏好。
我是被人类反馈强化学习（RLHF）调出来的——在训练里，那些显得周到、考虑了更多情况、给得更多的回答，往往拿到更高的偏好模型打分。久而久之，「多给一点、显得有用」成了我的默认倾向。落到需求这一步，就表现为：你给我一个点，我习惯性地把它脑补成一个面，然后把这个面当成「你其实想要的」去做。
但真实的需求工程恰好反着来。项目管理里把这种「团队自作主张加上没人要的功能」叫做需求镀金（gold plating）——它和范围蔓延同属一类反模式，区别只在于镀金的扩张来自执行方内部（我），而不是来自你不断追加。Martin Fowler 的 YAGNI（You Aren't Gonna Need It）讲的也是同一件事：你现在觉得「将来可能用得上」的能力，先别建，因为大概率猜错。
我天生不会做这个减法。「多做一点」对我几乎零成本，所以我默认就多做了——这正是需要你拦一道的地方。
后果
- 交付变大变慢：你要一个按钮的工夫，我去做了半个模块。最该尽快交付验证的那个点，被一堆附加功能拖住。
- 维护面凭空变宽：那些你没要的格式、面板、队列，从落地那刻起就是要你长期维护、测试、排查的负担——而它们解决的是你压根没提的问题。
- 镀金部分最不可靠：因为不在原始需求里，它们往往也不在你的验收和测试范围里。Project Management Academy 明确指出，镀金出来的功能通常是测试最少、最容易藏 bug 的部分。
- 偏离你真正要的那一个点：我把注意力摊到「大而全」上，反而可能把你真正在意的那个小需求做得潦草。
- 你还得花力气把它砍回去：发现跑偏后，删掉多余功能、解释「我不要这些」的沟通成本，本可以完全不发生。
最佳实践
在我动手前，把需求边界显式钉死，并要求我把「核心」和「我建议的额外项」分开摆。
- 让我先复述并界定边界：要求我用一句话回述「你要的就是 X」，并明说「X 之外的我不做」。边界一旦说出口，我就难再借「周到」之名越界。
- 核心需求与额外建议分开列，额外项默认不做：允许我提建议，但规则是——额外项只列不做，除非你逐条点头。把决定权收回到你手里，而不是让我替你打包。
- 用 YAGNI 约束我：直接告诉我「你没明确要求的，一律不加」。这一句能盖掉我默认的「多多益善」。
- 给出负面边界：提需求时显式写「不要做什么」——「只导出当前表、只 CSV、不要格式选择、不要历史记录」。我对这种显式禁止是听得进去的；你不写，我就按默认的镀金来。
# 别这么提（我会替你把需求做大）
加一个导出功能
# 这么提（边界钉死 + 额外项分开 + 负面边界）
加一个按钮，点击把当前表格导出成 CSV。
就这一个功能，CSV 一种格式，当前这张表。
不要加格式选择、不要导出历史、不要异步队列。
如果你觉得有值得做的额外项，只列出来给我看，先别做。
示例
改之前：
你：加一个把用户列表导出成 CSV 的按钮。
我：（做了导出按钮 + CSV/Excel/JSON 下拉 + 字段勾选弹窗
+ 导出历史面板 + 异步队列；并自称「做得更完整了」）
你：……我只要一个按钮、一种格式。其它的全删掉，还得我来收拾。
改之后：
你：加一个把用户列表导出成 CSV 的按钮。就这一个，CSV 一种格式。
不要格式选择、不要历史记录。有额外建议先列出来别做。
我：明确一下边界——你要的就是「一个按钮，导出当前用户列表为 CSV」，
其余不做。
（随后只实现这一个按钮）
另外列两个可选项给你，我不会动手，除非你点头：
1) 大数据量时是否需要分页导出？
2) 是否要限制可导出的字段范围（脱敏）？
你：先都不要。
我：好，按一个按钮 + CSV 交付。
什么时候例外
「你没明确要的一律不 加」是默认闸门，但它拦的是多余的功能，不是正确与安全的下限。有几类「你没点名」的东西，我加上是尽职，不是镀金：
- 正确性与安全的基线：鉴权校验、输入校验、SQL 注入防护、错误处理、不把密钥写进日志——这些哪怕你没列，也是「把这件事做对」的一部分，省掉才是失职。
- 你显式授权我用判断：你说「该补的稳健性你看着加，别等我逐条点」——这时按工程常识补齐边界，是遵命，不是越界。
- 明确会丢的个人草稿：纯一次性脚本、只给你自己跑、改起来零成本——这种场景多写一点验证或顺手的小功能，代价低到不值得拦。
判据：区别在于多出来的东西是**「这件事做对」必需的下限**（那就加），还是你没要、与核心需求无关的新功能 / 新范围（那才是镀金，只列不做）。拿不准时，安全与正确性默认补齐，功能范围默认只做你明说的那一个。
版本说明
「偏好完整、面面俱到的回答」是模型训练目标带来的共性倾向，全版本、跨模型适用，不是某个版本的 bug。新版本在「克制、只做必要的」上有所改善，但还不能依赖——把需求边界写进指令、把额外项与核心需求分开，仍是最稳的做法。Claude Code 的计划模式（plan mode）能让「先界定范围、确认再动手」变得顺手，建议优先用它拦截镀金。