工作就像机器学习中的强化学习：当奖励函数没有被明确定义时，智能体会学着利用环境来最大化奖励，而不是真正解决问题。最终，人们开始假装工作。

信息流

这个功能真的有必要吗？采用的方案是否正确？我们不太可能直接从产品团队拿到一份清晰的技术规格说明。通常，整个过程应该从一个痛点或增长机会出发。工程师理解了范围和上下文之后，才会给出符合需求的解决方案。更优秀的工程师——那些技术能力强、领域知识丰富的人——甚至能预判未来会发生什么，因此会为后续变化预留灵活性和扩展空间。如果工程师收到的任务是“使用 Y（一种模糊的技术方案）实现 X（一个功能），因为 Z（某个团队或管理层）想要它”，这些任务虽然已经被确认，却无法直接付诸实施，那么我认为有些沟通环节缺失了：我们应该把真正要实现这个功能的人带回讨论桌前。

只以 KPI 为驱动

KPI 是一种直观的员工评价方式，就像考试之于学生。如果老师过于强调分数，那么学习就不再是取得好成绩最有效的方式。比如，技术债从未被纳入 KPI 的考量，于是废弃代码和过时文档被留在原地。它们会误导后来的工程师和 AI 智能体，让他们在已有的垃圾之上继续制造更多垃圾。由于没有人掌握完整的上下文，也没有人愿意冒险处理技术债，系统逐渐变得脆弱，开发者不得不投入更多精力进行维护。最终，维护成本高得难以承受，团队也被折腾得筋疲力尽，大家才意识到问题所在。他们决定构建一个新系统来替换旧系统，甚至不考虑兼容性，因为他们根本不知道原来的系统是怎么运作的。这样的大动作必然需要管理层的支持，于是团队开始编故事、做空头承诺，确保自己不会被追责。是的，他们在装作自己正在工作。

随意的决策

这是一种常见现象：当没有人掌握完整的上下文（要解决什么问题、如何解决、以前做过哪些决策以及为什么这样决定），而团队又面临交付压力时，大家总是倾向于用快速修补的方式解决问题，把潜在的问题留到以后。所有决策都做得如此匆忙，以至于没有完整的记录可供追溯。也没有任何机制能阻止这种模式再次发生。每个人都忙于自己的工作，缺乏长远思考，于是团队陷入了恶性循环。

有时，一项决策太过重大，无法由一个人拍板，团队便会开会讨论并投票。这些选项都合理或可行吗？这个决策可以撤回吗？我们还是一如既往地选择工作量最小的那个，无论你有多不情愿（不同意，但仍全力执行）。接着，一个新功能需求出现，我们发现之前的决策不够好，于是又需要做出新的决策，如此循环往复。

结语

我大概是那个说“不”最多的人，这让我想起了我十分敬佩的已故技术专家陈皓的一句话：

做正确的事，等着被开除。