从不受欢迎的 AI 产品看工程师的角色与影响力

我在多家大型公司参与过不少产品的研发，其中不少最终未能赢得用户的广泛认可。早期在 Zendesk，我负责构建应用市场的核心模块，功能实用却始终缺乏热度；随后加入 GitHub Copilot 团队，面对大量负面评价。期间我也有过几次正面案例：修复了热门 Gist 超过 30 条评论导致的超时问题；实现了在 GitHub Markdown 中直接编写 LaTeX 数学表达式的功能。总体来看，我的大部分工作都落在了用户不满意的产品上。

是否因为个人技术更强就能制造出更受欢迎的产品？答案并不确定。即便代码质量高，产品的成败仍受团队激励、业务目标和市场环境等多重因素左右。一个优秀的工程师可以在自己的职责范围内提升代码质量，但其代码必须与其他系统协同，并会被后续的改动所覆盖，个人贡献往往被大量变更淹没。正如我在《大型公司中的糟糕代码》一文中所阐述的，单个工程师对产品受欢迎程度的控制力极其有限。

回顾这些经历，我反而庆幸自己曾参与“不受欢迎”的项目。它们提醒我，产品的市场表现并非能力的直接映射；许多看似成功的功能内部隐藏技术债务，而一些失败的产品结构却相当健壮。工程师的职责是为公司长期利益服务，而非单纯追求用户满意度。公司当然希望用户满意，因为这直接关联收益，但有时业务需要收紧功能、下线亏损产品，这些决策并非技术层面可以左右。

面对负面反馈，常见的两种错误应对方式是：一是完全忽视用户声音，甚至把用户当作“愚蠢”；二是过度站在用户立场，强行要求管理层做出技术或政治上不可行的改变。两者都偏离了工程师的核心职责——在公司目标与用户需求之间寻找平衡点。

然而，开发不受欢迎的产品也有积极意义。用户之所以关注它们，说明它们在某种程度上提供了价值；最糟糕的产品往往只是被忽视，而不是毫无用处。只要具备足够的心理韧性，工程师仍能在此类项目中发挥作用，即便无法根本改变产品命运。

几乎每位工程师都曾参与过类似的项目。用户偏好随时间波动，未能快速失败的产品可能长期存在，甚至成为公司的“顽疾”。因此，指责开发不受欢迎产品的工程师既不公平，也会导致自我责备的恶性循环，错失对用户产生积极影响的机会。