这是「与现实对账」选集的第三篇。上一篇讨论利润的边界；这一篇转向一个更私人的问题：为什么能力越强，有时越难接近事实？
我曾经以为，逃避一件事的样子应该是刷手机、拖延、什么也不做。
后来才发现，最难识别的逃避往往非常勤奋。它有完整的文档、漂亮的架构、连续的提交记录，甚至每晚都工作到很晚。
唯一缺少的，是那个可能说“不”的人。
能力会主动寻找适合自己的问题
锤子看什么都像钉子，并不只是因为锤子傲慢。更现实的原因是：敲钉子能给它确定反馈。
工程师看到混乱，会自然地想建系统；擅长写作的人遇到增长问题，会想到做内容；有销售经验的人更相信渠道；供应链出身的人往往认为货决定一切。
这些判断各有道理。麻烦在于，人会高估自己熟悉环节的重要性，低估那些无法凭现有能力处理的部分。
组织学习研究里有一个“能力陷阱”的说法：过去带来成功的做法，会因为持续获得资源和练习而越来越熟练；探索新办法反而显得低效。能力越成熟，调用它的成本越低；转向陌生能力则要重新忍受笨拙、低效率和他人的评价。
于是我们很容易得到一个令人舒服的结论：眼前最重要的问题，恰好是我最会解决的问题。
可控感是一种很强的奖励
写代码有一个相对的好处：许多错误会报错。性能不够，可以测量；接口失败，可以追踪。工程里当然也有偶发故障、错误需求和查不清的因果，只是与陌生人的沉默相比，我更熟悉怎样缩小这些不确定性。
市场通常不直接给出堆栈信息。
用户不回复，可能是需求不强，也可能是表达不清、时机不对、信任不足，甚至只是那天很忙。一个失败同时兼容许多解释。人既得不到明确答案，也无法保证更努力就会改善。
这种模糊会伤害可控感。大脑于是倾向于退回熟悉领域，找一些能够完成的任务。整理资料、重写代码、优化流程，都能带来即时而清晰的奖励。
问题不在于这些工作没有价值，而在于它们常常改变不了当前最关键的不确定性。
如果我不知道有没有人需要一个产品，把响应时间从两百毫秒优化到五十毫秒不会给出答案。系统变得更好，问题仍然原封不动。
复杂性还能保护自我评价
简单行动有时比复杂工作更难。
我在 DayPage 的夜间捕获界面上连续做过三轮调整：否掉中央的 orb，改成 canvas 画出的径向声纹，再反复删掉太大、太多的元素。每一轮都有明确问题，也都有完成感。与此同时，“什么时候算可以交给更多人使用”要模糊得多。删除是我的能力，交付却要求别人判断这些删除究竟有没有意义。
这个经历让我看见，给陌生人发出一份不完美的方案，技术上可能没有难度；等待他们是否回应，却会直接触碰自我评价。搭一套自动化系统可能需要两周，失败时还可以归因于技术、时间和资源。
复杂性给失败提供了更多解释空间。
只要项目足够大，我们就能说时机还没到、功能还没完成、团队配置不足。一个简单实验如果无人付钱，借口会少很多。
这也是为什么聪明人容易偏爱宏大问题。宏大问题听起来更重要，也更难被证伪。一个人可以在“改变行业”的路上努力很多年，却不用回答某个具体客户今天为什么不买。
能力在这里变成了盔甲。它帮我生产结果，也帮我避免接触那些不擅长、不可控、可能丢脸的环节。
沉没成本会替系统辩护
提前建设的另一个危险，是它会改变后面的判断。
如果只花一天做出原型，没有人使用时很容易停下。若已经投入三个月，承认方向不成立就等于承认大量工作没有产生预期价值。
人很难这样评价自己的过去。于是成功标准开始移动：没有付费，就看注册；没有注册，就看访问；访问也少，至少技术学到了很多。
学习当然有价值。只是当目标从商业验证悄悄变成个人成长，项目已经换了问题，我们却仍说它在前进。
系统越完整，继续维护它的理由越多。代码要升级，文档要更新，历史决策要兼容。原本为了服务需求而存在的东西，开始制造自己的需求。
这像养了一座还没有乘客的车站。后来大部分工作都在维护车站，于是我们更加需要相信列车终有一天会来。
反向思考：怎样确保自己一直见不到用户
与其问怎样成功，不如先问怎样保证失败。
如果我想确保一个产品永远接触不到真实需求，最可靠的做法大概是：
- 把首次交付推迟到系统完整以后；
- 只和认同我的朋友讨论；
- 用自己可控制的任务衡量进展；
- 每次没有结果时增加功能；
- 把不愿付费解释成用户还没理解价值。
这几件事组合起来，足以让一个聪明、勤奋的人工作很久，同时不获得多少新信息。
反过来，破解方法不需要多么宏大。它通常只是改变顺序：先让结果暴露在外部判断里，再决定哪些能力值得投入。
能力应该长在摩擦上
我现在给生产级系统建设设了一道很朴素的门槛：同一个动作有没有真实发生，重复是否已经造成明确损失？
如果流程尚未发生，自动化多半是在解决想象；如果只发生一两次，手工处理通常是更便宜的学习方式；如果重复已经拖慢反馈、增加错误或伤害交付，工程能力才找到了合适的位置。
这里有重要例外。数据一旦丢失无法补回，安全事故不能靠事后学习，合规错误可能直接让人出局，用户迁移成本也会随时间累积。这些地方值得提前设计。提前判断的任务是避免不可逆损失、保留选择；提前建设的问题，是为尚未发生的规模一次性建完所有选择。
好的系统像老茧，长在反复摩擦的地方。先有疼痛，身体才知道哪里需要保护。
能力圈也有背面
能力圈常被理解为“只做自己懂的事”。这条原则适合约束重大承诺，却不该禁止低成本学习。它还有一个不常被谈到的背面：知道什么时候自己的优势正在妨碍观察。
留在能力圈内下注是谨慎；为了获取新事实，短暂进入无能状态同样重要。舒适圈讨论的是感受，能力圈讨论的是认知边界，两者不能混为一谈。离开舒适并不会自动扩大能力，只有带着反馈回来，边界才真的移动。
朋友说“先成为用户”，并不是要求我抛弃工程背景。相反，它要求工程能力晚一点发言。先看看行业里的人如何笨拙地完成工作，哪些麻烦反复出现，哪些成本真的有人承担。
能力最大的浪费，不是没有使用，而是被精确地用在一个不重要的问题上。
读者回响