我现在的团队是 default to AI。多数 ticket 一开始就有模型在 loop 里，而不是一个空白光标。启动一项工作的速度比以往任何时候都快。AI 做了很多 heavy lifting，我每天花在 review 和打磨上的时间比敲键盘的时间还多。
这是大家挂在嘴上的部分。被低估的是后半截：工作的形态变了。敲键盘的时间下降，review 的负担上升，整个工作从「做」转向「查」。如果你没准备好接这个迁移，AI 并不会真的帮你省时间，它只是把时间从一个地方挪到另一个地方。
我看到很多人会陷进两个误区。
误区一：「AI 做 90%，你只要检查结果」
听起来很美：把 context 全部喂给模型，让它端到端把分析做完，扫一眼结果就 ship。
直到有人提问。
你没写过的步骤，你不拥有它的细节。你可以读懂结果，但你 defend 不了它。当 stakeholder 第一次反问 为什么这个 filter、为什么这样定义 cohort、pre-launch 用户怎么办，你站在那里解释一份你根本没做过的工作。如果你想先验证结果对不对，你得自己重做一遍，重做到一定程度，等于你一开始就该自己写。「省下的时间」在 review 阶段蒸发一次，在 readout 上当着大家的面再蒸发一次。
还有更深一层的坑。大部分公司的内部文档本身就一般，湾区科技行业固有的 high turnover 把这个问题放大：当年知道一张表究竟意思的那批人早走了，wiki 里留下的东西半数过时、半数错误。如果你把 AI 怼到这堆资料上，依赖它的总结，得到的不是干净的概要，而是被自信地复述一遍的错误信息。如果你对 business 的理解还不到能识别错误的程度，AI 只是帮你在错误的方向上走得更快、更远。
解法不性感：在 reasoning 这一层留在 loop 里。你不需要敲每一行，但你必须知道每一行为什么在那。
误区二：「AI 全权处理 ETL」
我以前的一天里有大量 SQL：拉数据、validate、整理好、交给下游。这些活儿现在大部分由 AI 起稿，简单数据源上效果很好。
数据 model 一复杂就开始翻车。
当你面对几十张表、重叠的 key、半重复的数据、十种「active user」的合理定义，模型会从这些表里挑某一条路径走。这条路是不是对的，没有任何保证。看起来合理的 join 经常是从错的表上 join 出来的，数字回来一切正常，但其实是错的。
修这个问题不靠更好的 prompt，而要往上游修。你必须先给 AI 一份 join map：哪些 fact 表是某个粒度下的 canonical 选择，哪些 dim 表已经废弃，哪些列看起来像但其实不是默认安全选项。我个人摸索出来最干净的做法是：和 data engineer 一起花一小时，把常用表和它们的典型 use case 写下来，再 pin 几条已经 validate 过的 query 给模型做 pattern-match。做完这一步之后，AI 出的 SQL 质量直接上一个台阶，因为它不再是在猜结构。
这一步没有捷径。在你把 ETL 委派给 AI 之前，你得先了解仓库本身。AI 不会取代你对 warehouse 的理解，反而让这种理解更有杠杆。
一个让我省下不少时间的小习惯
当 AI 给我的回答密度太大的时候，比如一篇 paper、一段推导、或者一坨纠缠在一起的统计推理，我会让它再用 simple and plain 的语言重写一遍解释。
不是降智，只是把学术腔扒掉。
我们这行一半的认知负担来自解码语言，不是想清楚思想。语言一旦平实，思路通常就显形了，你几秒钟就能判断这是不是你要的东西。pain point 或 key insight 浮出来更快，学一个新方法的曲线明显变缓。
听起来很简单，但确实管用。
一年下来，工作的形态
AI 没把活从我盘子里拿走，它只是把活重新分配了。我写得更少，review 更多，debug 更小心，更多时间花在搭脚手架（join map、prompt、validated example）上，让 AI 能去做有用的事，而不是自信地犯错。
从 default to AI 里收益最多的，不是把活外包得最干净的人，而是那些虽然把活交出去、但仍然清楚自己交了什么出去的人。