工程师的诅咒

一、你解决的问题，可能不是问题

我有个朋友，技术很强，花了六个月写了一个"智能日程管理工具"。

他给我演示的时候眼睛放光：自动识别邮件里的时间信息、支持自然语言输入、能和 Google Calendar 双向同步、还做了一套冲突检测算法——当两个会议时间重叠时，会根据历史数据自动推荐最优调整方案。

我问他：你的目标用户是谁？

他说：所有需要管理日程的人。

我又问：你怎么知道他们需要冲突检测算法？

他愣了一下，说：这不是很明显吗？日程冲突是个很常见的痛点。

后来这个产品上线了，注册用户大概两百人，月活不到二十。不是因为技术不好——技术非常好。而是因为大多数人根本不管理日程。他们的日程就那么几件事，用脑子记就够了。真正日程复杂到需要冲突检测的人，已经有助理帮他们处理了。

这就是工程师的诅咒的第一层：你把"我能解决"当成了"有人需要"。

能力让你看到了可能性，可能性让你兴奋，兴奋让你动手，动手让你投入六个月。整个链条里，唯独缺了一个环节：有没有人在为这个问题真金白银地痛着？

二、诅咒的根源

工程师的训练，本质上是一种因果思维的训练。

给你一个问题，你找到原因，设计方案，实现解决。输入 → 处理 → 输出。干净、优雅、可验证。

这套思维方式在技术世界里无往不利。代码要么跑通，要么报错，没有模糊地带。系统要么能承受十万并发，要么不能，不存在"差不多行"。

但人的世界不是这样的。

人的决策是混沌的。一个用户选择你的产品，可能因为图标好看，可能因为朋友推荐，可能因为竞品的注册流程多了一步让他烦了，也可能纯粹因为刷到了你的一条短视频。这些原因无法被还原成一条清晰的因果链，也无法被写进需求文档。

工程师面对这种混沌会本能地不适。不适就会简化。简化的方式就是回到自己熟悉的领域——技术。

"我不知道用户为什么不来，但我知道我可以把加载速度从 1.2 秒优化到 0.3 秒。"

于是你花了两周优化性能，用户还是不来。但你的心理得到了安慰，因为你做了"有确定产出"的事。

这是诅咒的根源：确定性成瘾。 工程师太习惯在确定性的世界里获得反馈，以至于面对不确定性时，会不自觉地退回到确定性的壳里。

三、诅咒的七种表现

1. 过度构建

产品还没上线，你已经设计好了微服务架构、消息队列、缓存策略和自动扩缩容方案。

你的用户量：零。

这不叫远见，叫逃避。你不确定产品有没有人用，但你确定你能搭一套漂亮的架构。于是你选了后者。

2. 功能幻觉

"如果我再加一个功能，用户就会来了。"

不会的。用户不来，十有八九不是因为缺功能，是因为他根本不知道你的产品存在，或者他知道了但三秒内没看懂这东西跟他有什么关系。

功能是工程师最熟悉的武器，所以遇到任何问题都想用功能去解决。就像手里握着锤子，看什么都像钉子。

3. 技术选型洁癖

花三天调研用 Next.js 还是 Nuxt，用 PostgreSQL 还是 MongoDB，用 Tailwind 还是 Styled Components。

对于一个还没验证市场需求的产品，这些选择的差异为零。用你最熟的就行。你在选型上纠结的每一个小时，都是在回避真正的问题：有没有人愿意为你的想法买单。

4. 完美主义陷阱

"这个代码还不够干净，我不能让别人看到。" "这个交互有个边界情况没处理，不能上线。" "等我重构完这个模块再发布。"

工程师的审美标准是对的——在维护一个已经有用户的系统时。但在从零到一的阶段，完美主义是最昂贵的拖延症。

一个粗糙但有人用的产品，胜过一个精致但无人知的产品。前者有反馈，有迭代方向；后者只有你自己的自我感动。

5. 低估分发，高估产品

工程师相信"好产品会说话"。这是最浪漫也最危险的幻觉。

现实是：好产品如果没有分发渠道，它连自言自语的机会都没有。互联网上每天有无数好产品悄无声息地死去，不是因为它们不好，是因为没有人看到它们。

写代码和做分发需要完全不同的技能、心态和时间分配。大多数技术创始人把 90% 的时间花在构建上，10% 花在推广上。然后困惑为什么没人用。

比例应该反过来。至少在早期。

6. 用技术语言和世界对话

你的产品介绍写着"基于 RAG 架构的知识检索系统"。你的用户想知道的是"我把文档扔进去，能不能直接问它问题"。

你觉得前者精确，后者粗俗。但精确是说给同行听的，粗俗才是说给付钱的人听的。

7. 把困难等同于价值

这是最隐蔽的一种。

工程师有一种直觉：越难实现的东西越有价值。所以当你攻克了一个技术难题，你会天然地觉得这个难题的解决方案本身就很值钱。

但商业世界的定价逻辑不是"这有多难做"，而是"这能帮别人省多少钱或赚多少钱"。一个技术上极其简单的东西，如果解决了一个高频的真实痛点，可以卖得很贵。一个技术上巧夺天工的东西，如果没人需要，就一文不值。

难度和价值之间，没有因果关系。

四、诅咒的本质是身份固化

说到底，"工程师的诅咒"不是一个技术问题，而是一个身份问题。

当你的自我认同是"我是一个工程师"，你就会用工程师的方式看待一切、应对一切、评判一切。遇到商业问题，你会把它翻译成技术问题。遇到用户问题，你会把它翻译成功能问题。遇到增长问题，你会把它翻译成性能问题。

因为只有翻译成你熟悉的语言，你才知道怎么回应。

但世界不会迁就你的语言。

真正危险的不是你的技术思维本身——技术思维是极其宝贵的能力。危险的是你只有这一种思维，或者你在所有场景下都默认使用这一种思维。

一把手术刀在手术室里是救命的工具，在厨房里切菜就很荒谬。不是刀的问题，是你没切换场景。

五、怎么破

不讲大道理，只说几件具体的事。

第一，在写第一行代码之前，先卖出去。

把你的想法写成一页纸，发给十个可能是目标用户的人。不是你的工程师朋友，是真正会为这个问题付费的人。看他们的反应。如果十个里有三个说"我现在就想要"，你再动手。如果十个里有零个心动，你省下的不是六个月的时间，是六个月的人生。

第二，每周花一半时间在代码之外。

和用户聊天。写内容。做分发。录视频。发推文。这些事对工程师来说很不舒服，因为没有确定性产出。但这种不舒服恰恰说明你在拓展能力边界。

第三，找一个非技术合伙人，或者至少一个非技术的顾问。

不是因为你需要被管理，而是你需要一个能对你说"用户不关心这个"的人。你需要一面镜子，让你看到自己视野的盲区。

第四，给自己设一条铁律：上线时间不超过两周。

不管做什么，第一个版本两周内必须让真人用上。丑没关系，功能少没关系，有 bug 也没关系。你需要的是真实世界的反馈，不是自己脑子里的模拟。

第五，把"有人用"当作唯一的成功指标。

不是代码覆盖率，不是性能跑分，不是架构优雅度。就是一个数字：有多少人在用。这个数字在涨，你就是对的。这个数字是零，其他一切都是幻觉。

六、最后

工程师的诅咒不是贬义。恰恰因为你有深度思考的能力、系统性解决问题的能力、把抽象变成具体的能力，这个诅咒才存在——它是你的超能力的副作用。

蜘蛛侠的蛛丝如果控制不好会粘住自己。超人的力量如果控制不好会捏碎杯子。你的工程师思维如果控制不好，会让你花六个月造一个没人需要的精密机器。

觉察到诅咒的存在，就是破除它的开始。

不用消灭你的工程师本能。只需要在动手之前多问一句：

"这是用户的问题，还是我的痒？"