这些事情，一个有经验的工程师做起来，甚至算不上挑战。但对一个只会用 AI 写代码、从来没有经历过真实工程协作的人来说，这些东西是盲区。而盲区，往往是最贵的东西。
他找了一个工程师来看。工程师看了两个小时，出来说了一句话："你们的数据库查询没有索引。"这不是复杂的问题。这是工程基础课第一节课的内容。AI 在生成代码的时候，没有提醒他。他不知道该问。产品停摆了三天，紧急修复，用户投诉，口碑受损。我不是在说 AI 不好用。我用 AI 写代码，每天都在用。它确实让我的工作速度快了很多。
我想说的是另一件事——速度快了，但速度本身不会告诉你方向是不是对的。
这些认知，不是从 AI 那里能学到的。AI 会帮他修每一个具体的 bug，但不会告诉他，他的整个测试方式是有问题的。
AI 帮我想怎么实现，这个它很擅长。但它不会主动告诉我这个功能放进真实世界里会遇到什么。这个要我自己去想。
AI 生成的代码有一个特点：它能工作，但它没有记忆。
他说：Code Review 从来不只是找 bug 的。找 bug 只是顺带的事。它真正在做的事情，是让两个人对同一段代码建立共同的理解。这段代码在做什么，为什么这样做，有没有更好的方式。这个过程，是知识在团队里流动的方式。
那用了 AI 之后，Code Review 是不是更重要了？至少不应该更不重要。
我以前以为技术决策是技术问题，应该有一个标准答案。现在发现不是，它是一个业务问题，答案取决于你现在在什么处境里。
我知道重构有风险，但我低估了风险的程度。如果当时想得更清楚，我可能会选择分阶段来做，而不是一次性全部推倒重来。
故障是礼物：故障是系统在告诉你，它在哪里是脆弱的。你不出故障，你不会知道这些脆弱的地方在哪里。你知道了，你才能加固它。
故障是礼物，但这句话有一个前提——你得有能力从故障里学到东西。如果每次出了故障，修好了就过去了。没有复盘，没有改进，下次同样的问题还会发生。这种故障不是礼物，只是损失。
你们开复盘会，不追责吗？追责解决不了问题。同样的漏洞，换一个人来写，可能还是会写出同样的问题。我们要改的是流程，不是换人。
但如果真的是有人不负责任呢？技术负责人说：不负责任的人，平时就能看出来，不需要等到出了故障才处理。故障复盘不是评价人的场合，是改进系统的场合。
用 AI 做架构设计，要反着用。它给你一个复杂方案，你要问它：如果去掉这个部分，会有什么后果？如果去掉那个部分，最坏的情况是什么？一个一个剥，把真正不能去掉的留下来，把现在用不上的先放一边。
技术负责人问了他一个问题：你觉得你现在最大的能力缺口在哪里？
陈默想了一下，说：我不太确定我做的东西，放到更复杂的环境里还能不能用。
技术负责人说：这个回答挺好的。知道自己不确定，比以为自己确定要好。
他说：成熟的工程师，接到需求的时候，问的第一个问题不是"怎么实现"，而是"为什么要做这个"。
我问：这两个问题有什么区别？
他说：问怎么实现，你得到的是一个技术任务。问为什么要做，你得到的是这个需求背后的业务逻辑、历史背景、真实的用户是谁、他们真正在意的是什么。有了这些，你才能判断什么方案是合适的，什么方案看起来对但其实不对。
他说：AI 非常擅长回答怎么实现。它不擅长告诉你为什么要做，因为它不在你的公司，不了解你的用户，不知道你的历史。这个问题，只能你自己去问，去挖，去积累。
这些东西不在任何文档里，在公司里待久了才会知道。有些上下文，是时间给的。没有捷径。
他停了一下，说：现在想起来，那段时间做的很多决定，都是 AI 的决定，不是我的决定。我只是按下了回车键。
你写代码的速度提升三倍，但如果你写的东西方向错了，你只是更快地走错了路。效率是工具，判断力是方向。方向没有，效率越高，偏得越远。
工程里有大量的决策，是在信息不完整的情况下做的。你不知道用户量会涨多快，不知道需求会往哪个方向变，不知道这个方案三个月后会不会成为包袱。要在这种不确定里，做出一个能为之负责的判断。
猎头说：这个怎么证明给别人看？
张晨说：没办法证明，只能靠记录。你做过什么决定，结果怎样，你从中学到了什么。时间长了，这些记录会说话。
他不确定怎么用一两句话解释清楚。他在做的事情，不是一个具体的项目，不是一个具体的功能。是他在带着一群人，慢慢建立起一种做事的方式——在 AI 能做很多事情的今天，仍然知道哪些判断必须是自己做的，哪些经验必须是自己趟过的，哪些问题必须是自己想清楚的。
这本书想说的只有一件事：工具变强了，不等于使用工具的人变强了。变强，还是要靠自己。
见过足够多的问题。复盘足够多的失败。在不确定里做过足够多的决定。在系统崩掉的凌晨两点坐在电脑前排查过足够多的故障。在会议室里把一个复杂的技术问题解释给不懂技术的人听，直到他们真的理解。这些事情，AI 可以陪你，但不能替你。
📔Content
