Notes

复杂性体现在细节之中。当库存被其他订单临时占用时该如何处理？如何应对部分付款？若邮件服务暂时不可用该怎么办？是否需要重试？重试次数应设为多少？若客户在结账过程中会话超时又该如何处理？如何防止订单重复提交？每个答案都会引发更多疑问。累积的决策、边界情况和交互形成了真实的复杂性，没有任何工具或语言能消除这种复杂性。必须有人思考这些场景。这种思考就是软件开发，无论它是以 COBOL、CASE 工具图、Visual Basic 还是 AI 提示的形式呈现。

人工智能改变的是开发者的工作方式，而非消除他们判断力的必要性。复杂性依然存在。必须有人理解业务问题，评估生成的代码是否正确解决问题，考量安全影响，确保其与现有系统无缝集成，并在需求演变时持续维护代码。

人工智能能增强开发者的能力，但它无法取代那些既通晓问题领域又精通技术环境的人。

当 “A/B Test” 成了拍板的主要方式，清晰的产品愿景就变成了可有可无的东西。久而久之，产品团队的角色就变了：判断力慢慢让位于迭代，品味慢慢让位于数据表现。产品还在演进，但已经没有了明确的方向感……只剩下一种惯性往前冲的动量。

你没法轻易量化用户心里的那股怨气。也没法量化他们带着火气狂点按钮、只为关掉又一个"你知道吗"弹窗时的那种暴躁。你没法轻易画出一张图表，标注用户心里冒出这个念头的那一刻：“我以前挺喜欢这产品的，现在怎么这么烦人。“你没法轻易量化信任是怎么一点一点被消磨掉的。

传统教育的一个大问题是过早地"关闭"知识——把东西教成"就是这样"，而不是"在某些条件下是这样"。结果学生学到的是僵化的事实，而不是活的、可以灵活运用的理解。

“这时，我才开始体会到金钱的最大优势：考虑金钱以外事情的能力。”

反直觉洞见：获得"是"并不意味着谈判成功，获得"怎么执行"才是。

很多时候你得到"是"的那个人根本没有执行权，或者没有认同感，“是"只是会议室里的礼貌。

检验方法：问对方"这要怎么实现？““谁来负责下一步？“如果对方无法回答，这个"是"是空的。

真正的成交需要两个东西同时到位：公平感和执行路径。缺少任何一个，协议都会在事后崩溃。

习得的乐观主义与解释风格：

永久性：乐观者将负面事件归因于特定的暂时性因素；悲观者则将其归因于永久性因素。

普遍性：乐观者将无助感进行隔离处理，而悲观者则认为生活中的某个领域失败就意味着整个人生失败。

个性化：乐观者将坏事归咎于自身之外的原因，而悲观者则将发生的事情归咎于自己。

任何思想都必然源自另一思想或你的感官（视觉、听觉等）。举例说明：你无法想象一种颜色，它不是你曾经见过某种颜色的组合。

追溯任何想法的源头，你就会发现所有想法都建立在你已经看到、听到等事物之上。

你的现实受限于你能感知和记忆的事物。

“我的语言的边界即我的世界的边界”

人们经常在对话中“文不对题”：一方需要的是情感支持(被理解、被陪伴)，另一方却提供的是实用建议（解决方案）,结果双方都感觉不被满足。识别对方此刻究竟是想“被听见” 还是想“被解决"”，是一项被严重低估的技能。 - 布鲁克斯

1. 最直接的动作是不要自动假设对方需要什么，而是直接问：“你现在是想让我帮你想办法，还是只是想找个人说说?”
2. 先把对方的情绪说出来—“你现在一定很害怕/很愤怒/很无助”
3. 把问题延伸对方的叙述，而不是用问题引向解决方案。比如"当时具体发生了什么" “你那一刻是什么感觉”
4. 持续在场，而不是一次性的戏剧化姿态。

在对话中,人们倾向于用“转移式回应”(shift response,把话题转回自己)而不是“支持式回应”(support response,继续深挖对方)。举例说，朋友说“我今天很累”，转移式回应是“我更累，我昨晚只睡了三小时”；支持式回应是“发生什么了”？

我们必须犯错误，这样我们才学会同情别人。

一起什么都不做的美好：一种围绕着“无所事事”而展开的生活。也许你正坐在沙发上，看着朋友回复邮件；也许你正和正在收拾行李准备旅行的朋友闲聊；也许你正在帮忙准备晚餐。 你们在做什么其实并不重要。重要的是邀请对方走进你生活的平凡片段，而不是等待一个“值得”发出邀请的特殊场合。