这不是bug，这是功能 — 本质、起源与区别

「这不是bug，这是功能」是什么意思

「这不是bug，这是功能」 — 开发者或经理用来表示程序的意外行为是故意的而非错误的一句话。在经典情况下这是一个玩笑：所有人都明白行为是错误的，但称之为「功能」来缓解紧张。然而在实际项目中，这句话也用于严肃的场合 — 当行为确实符合规格说明但不符合用户期望时。

bug和功能之间的区别往往是主观的。对于编写代码的开发者来说，某种行为可能看起来是合理的。对于用户来说 — 则是意想不到和错误的。感知的主观性 — 这句话如此长久不衰的主要原因。它允许将对话从「谁有错」的层面转移到「就是这样设计的」层面。根据UX Collective的数据，用户报告的bug中有40%实际上是用户体验问题，而不是代码错误。

在敏捷团队中，这句话经常在演示中被用作防御机制。开发者展示意外行为，产品负责人皱起眉头，然后听到神圣的「这不是bug，这是功能」。团队中的信任决定了这句话会被视为玩笑还是隐藏问题的企图。在健康的团队中，这样的玩笑可以缓和气氛，而在有毒的团队中则会引发冲突。

标志性语句的起源历史

这句话的第一个已知使用记录是在1976年的DECUS（数字设备公司用户协会）的一份简报中。用户抱怨文本处理器RUNOFF不正确处理空行。开发者的回答：「这不是bug，这是功能 — 段落就是这样处理的」。从那时起，这句话就成为「原样」编写代码的辩护象征，无论其实际质量如何。

这句话的流行得益于行话文件 — 黑客俚语词典，它在20世纪90年代构成了《新黑客词典》的基础。在行话文件中，「feature」词条直接指向那些由于无法或不愿修复而变成功能的bug。例如：早期终端上的Caps Lock键没有指示灯 — 这是一个变成了「盲打」功能的bug。

在21世纪初，这句话通过网络梗进入了大众文化。一张配有「It's not a bug, it's a feature」文字的猫图在论坛和社交媒体上传播。在游戏行业中，这句话尤其常用：那些不影响游戏性的故障被宣布为「功能」以营造氛围。文化现象远远超出了IT的范围 — 在任何为错误辩护的背景下都可以听到这句话。

借口的心理学：为什么他们这么说

这句话的心理基础是认知失调。开发者花费了数小时编写代码，承认结果是错误的意味着贬低自己的工作。这句话「这不是bug，这是功能」减少了失调：错误变成故意的决定，开发者从犯错者变成创意的作者。这是心理的防御机制，可以保护自尊心。

第二个原因 — 害怕返工。如果承认是bug，就必须重新经历代码审查、测试和部署。而「功能」不需要修正 — 任务关闭，负担减轻。根据微软研究院的数据，开发者在23%的情况下有意识地降低bug的严重程度以避免返工。这句话是这种降低的一种温和形式。

第三个原因 — 企业文化。在一些公司中，bug会计入开发者的关键绩效指标中，而在代码审查中发现bug被认为是作者的错误。在这样的环境中，这句话「这不是bug，这是功能」是一种避免对职业产生负面影响的方式。健康的错误文化（无指责文化）消除了这个原因：如果bug不受惩罚，就更容易承认它们。

bug和功能之间的界限在哪里

明确的界限只有在存在验收标准时才会出现。如果行为不符合验收标准的任何一点 — 这就是bug。如果行为符合验收标准但用户不喜欢 — 这是用户体验问题，不是bug。如果没有验收标准 — 任何行为都可以被宣布为功能，这也是这句话长久不衰的主要原因。

实用规则：bug — 当程序做了不应该做的事或没做应该做的事时，根据规格说明。功能 — 当程序做了设计要做的事时，即使结果让用户感到惊讶。有争议的情况：未定义行为（语言未定义结果）、竞态条件（不稳定地表现）、极端值（对99%的数据有效）。

为了区分，使用决策矩阵：

• 行为在规格说明中有描述并正确实现 — 功能，即使你不喜欢
• 行为有描述但实现不正确 — bug，需要修正
• 行为没有描述但逻辑上源自需求 — 未记录的功能，应添加到规格说明中
• 行为没有描述且不合逻辑 — bug，需要明确需求

最危险的情况 — 当没有规格说明且开发者自己决定什么是功能时。在这样的项目中，任何错误都可以被宣布为「功能」，这使得代码对整个团队来说都不可预测。每个任务都有明确的验收标准 — 这是客观划定界限的唯一方法。

团队中概念偷换的危险

第一个危险 — 质量模糊。如果每个bug都可以被宣布为功能，团队就没有动力编写高质量的代码。错误不再被修复，技术债务增长，用户习惯了「奇怪的行为」。迟早竞争对手会推出可预测的产品，用户就会流失。

第二个危险 — 团队冲突。QA工程师发现一个bug，开发者说「这是功能」。如果没有客观标准（验收标准），争论就会转向个人层面：「你测试得不好」vs「你编程得不好」。根据PractiTest《2023年测试状况》报告，「bug vs 功能」的争论是QA和开发者之间摩擦的三个主要原因之一。

第三个危险 — 法律风险。在受监管的行业（医疗、金融、航空）中，「bug」和「功能」这些概念具有法律分量。如果在医疗软件中某种行为被宣布为功能但导致剂量计算错误 — 这不是玩笑，而是违反监管要求。安全关键系统不容忍概念偷换，因此它们总是应用形式化验证。

如何防止混淆bug和功能

主要工具 — 每个任务中的明确验收标准。验收标准在开发开始之前编写：「在输入X时，系统应输出Y」。如果行为没有描述 — 默认情况下就是bug，即使开发者有不同想法。验收标准必须是可衡量和可验证的：「按钮是绿色的」 — 不好，「HEX #00FF00」 — 好。

第二个工具 — 团队中的完成的定义。明确描述「任务完成」意味着什么：代码已写、测试已写、测试通过、代码审查已完成、已部署到暂存环境、已由QA测试。如果完成的定义的所有点都已满足但用户投诉 — 这不是bug，而是遗漏的需求，以新功能的形式进入待办列表。

第三个工具 — 无指责事后分析文化。如果bug被宣布为功能并进入了生产环境 — 我们分析原因，而不是寻找责任人。为什么开发者认为这是功能？为什么QA放过了它？为什么验收标准不完整？这些问题的答案改进流程，而不是惩罚人。系统性改进比禁止「这不是bug，这是功能」这句话更有效。