一、早上九点半，我的工位上坐了五个人
早上九点半，我打开编辑器。
屏幕左边是我，右边是五个"同事"：一个写测试，一个重构老代码，一个翻文档查资料，一个给我的改动做预审，还有一个专门写注释和 Changelog。
他们不领工资，不请假，不开周会，全年无休。发版前夜让他们加班，没有一个人有情绪。
但他们的水平，说实话------大概相当于我十几年前带过的那批应届生：手脚极快，知识极杂，但判断力约等于零，而且偶尔非常自信地胡说八道。
写到这儿我自己笑了。
十几年前，我确实带过这样一个团队。公司扩张，一口气招了大批初中级研发，我每天最主要的工作不是写代码，而是：告诉他们要做什么、不能怎么做、检查做得对不对、做错了把原因讲清楚。
这两件事，是同一件事。
现在坐在你工位右边的那群 AI，就是当年坐在你工位右边的那群新人。
折腾到最后我发现，自己只是把十几年前带团队的那套东西重新捡了起来，换了个对象。
下面是我这一年多的真实复盘。
二、第一重转变：敢用、多用、用心了解------先学会「御马」
从"偶尔问一句"到"全流程嵌入"
最早我把 AI 当搜索引擎用：不熟的 API 问一句，报错看不懂贴一段，写完就关，跟关掉一个 Stack Overflow 标签页没区别。
这个阶段，它对我的效率提升大概只有 5%。
真正的分水岭，是我把它从"问答框"挪进了"工作流"：
- 写代码前：先让它把 test case 列出来------边界条件、异常输入、并发场景------我确认 case 没问题，再让它写实现。
- 重构时：先让它讲清楚"原来的实现为什么这么写"，再给方案，且必须回答"你为什么这么改"。讲不清理由的，一律打回。
- 联调时：把接口文档和真实返回一起丢给它，生成 mock 与类型定义，字段对不齐的地方它会自己标出来。
- 排查 bug：给它完整报错栈、复现路径和上下文，让它先给三个可能的原因加对应的验证方法，我去验证------而不是让它直接给答案。
- Review：让它先跑一遍预审，但最终的判断我做。
- 写文档：README、接口说明、Changelog------最耗耐心又最不产生活力感的活，交给它，我只负责审。
这一步的区别，是 5% 和 50% 的区别。
不了解，就没有驾驭权
但在大规模用它之前，你得先花时间了解它。
了解它的边界。 样板代码、模式迁移、信息整合，它强得离谱；但"这个需求该不该做""这两个方案哪个更适合我们团队"这类需要上下文和价值判断的问题，它基本是废柴。
了解它的成本。 上下文窗口有多大？什么时候它开始"忘事"？什么任务适合一次给全、什么必须拆开喂？不了解这些，长任务里你会被它莫名其妙带偏。
了解它的性格。 它会讨好你。你给它一个明显有问题的方案，它大概率先夸一句"这个思路很好"，再委婉提一点意见。这个讨好倾向，是你用它做技术决策时最大的隐形陷阱。
我见过太多人，用 AI 用得越多，决策质量反而越差------因为他把"AI 说可以"当成了"可以"。
骑手不了解马性，上马那一刻就已经输了。
先学会御马，再谈策马狂奔。
三、第二重转变：接受它的缺点，用规范兜底
AI 遍布全程，人只在关卡
它的缺点，短期不会消失
带过那么多新人，我早就接受了一件事：新人一定会犯错，而且会反复犯同一类错。 你不会因为应届生写了个 N+1 查询就开除他，你会做的是在 Review 里指出来、在规范里写下来、下次分配任务时提前提醒。
AI 也一样。它有三类问题，短期不会消失：
不稳定性。 同一个需求问三次，得到三个不同质量的实现。它对上下文极度敏感，你多说一句少说一句，结果可能差很远。
幻觉。 它会编造不存在的 API、不存在的配置项、不存在的库版本。最要命的是------它编造时的语气，和它说真话时一模一样。
过度自信。 它很少说"我不知道"。它更常见的做法，是在你问了一个它根本没答案的问题时，给你一个看起来非常完整、非常专业的错误答案。
所以我给自己定了一条铁律：
AI 的产出，本质上是一份永远需要 Review 的 PR。
你不会让应届生直接把代码合进主干，那就别让 AI 直接把代码合进主干。
给它写一份《新人上手指南》
把团队做事的方式显式写下来，而不是指望它每次都猜对
当年带新人，我第一件事是写文档：《新人上手指南》《代码规范》《常见坑清单》。
现在我做的是一模一样的事，只是对象换成了 AI。
在 Cursor、Claude Code 这类工具里，这些约束的载体就是 rules / skill / command------名字不重要，重要的是你要把"我们团队做事的方式"显式写下来，而不是指望它每次都猜对。
我的清单大概长这样（前端向，供你裁剪）：
① 项目上下文（rules）
- 技术栈与版本锁定：框架、语言、包管理器、Node 版本
- 目录结构与命名约定；状态管理只用一种范式；样式方案只用一种
- 明确禁区：不许引入的依赖，不许出现的写法
② 可复用能力（skill）
- "生成组件"：必须含类型定义、单测、无障碍属性
- "重构"：先输出改动理由，再输出 diff，且 diff 必须可逐块回滚
- "修 bug"：先复现、再定位，最后才允许改代码
③ 高频动作（command）
/test：为当前改动补测试，优先边界 case/review：按「阻塞 / 建议 / 吹毛求疵」三档审我的 diff/explain：解释这段代码在做什么，不许出现"显然""很简单"/commit：生成 commit message，但必须附上它理解的改动摘要
④ 审核流程
- AI 生成的 diff，人必须逐块看过才能提交
- 涉及数据流、权限、支付、埋点、性能的改动，不看 diff 不许合
- AI 生成的测试，至少有一条是"我故意写错实现也能挂掉"的验证
- 它给出的外部依赖版本号，必须人工核对一次
规范不是给 AI 立的规矩，是给你自己的判断力留的座位。
而且当你把约束写清楚，它的产出质量会稳上一个台阶。更重要的是------你被迫把"我认为什么是对的"从脑子里掏出来，变成了文字。 这个过程本身，就在提升你。
四、第三重转变：承认它比你强，敢放手
这一关最难。因为要承认它比你强，真的很伤人。
它的知识体量比你大。 你熟悉的那几个框架和库，它全熟悉；你不熟的领域------渲染管线、编译原理、协议细节、某个冷门语言的生态------它也熟悉。你花十年攒下的"我知道有这个东西"，在它面前几乎是免费的。
它的学习速度比你快。 一个新框架发布，你还在看文档，它已经能用它写项目了。
我拧巴过一阵。明明它写得又快又好，我还是要自己先写一遍，好像不这样，就证明不了"这活是我干的"。
后来我想通了：放手不是躺平，是把精力挪到杠杆更高的地方。
当年带团队也经历过这个转变。开始我什么都自己写，觉得"教他的功夫我自己都写完了"；后来被迫放手，把时间挪到需求拆解、架构设计、技术选型、跨部门沟通上------团队产出反而翻了几倍。
一个 Leader 的价值，从来不是自己写了多少行代码，而是他能撬动多少产能。
现在这句话依然成立，只不过你撬动的，是一群不睡觉的数字初中级研发。
我现在的手感：
- 样板代码、CRUD、类型定义、数据转换 → 全给它，我看 diff
- 重复性批量修改（比如 200 个文件的 API 迁移）→ 全给它，我用测试兜底
- 我不熟的领域里的一次性脚本 → 全给它，我只验证结果
- 架构决策、边界划分、性能权衡、体验判断 → 我自己来，让它当反方
把"写"的成本降为零之后，你才有资格把时间花在"想"上。
五、第四重转变：互相学习，重建自己的知识体系
把 AI 当陪练：你教它说清楚，它逼你想明白
让它当陪练，而不是当老师
带团队那几年，我有个很强烈的感受：我以为我懂的东西，讲给新人听的时候，才会暴露出我其实没懂。
"这里为什么要用 useMemo？""避免重复计算。""那这个函数为什么不用？""......"
讲不下去的那一刻，就是你知识体系里那个洞被照亮的那一刻。
用 AI 也一样。
带人最好的学习方式是讲清楚，用 AI 也是。
我现在常做两件事。
第一，让它当反方辩友。我给出一个方案，然后明确要求："请站在反对者立场，找出这个方案最可能失败的三个地方，给出具体的技术理由，不要说套话。" 十次里有六七次，它真能指出我没想周全的地方。
第二，让它追问我。"请扮演一个不了解业务背景的资深工程师，向我提出十个你应该问、但我没说清楚的问题。" 那些我答不上来的，就是我的盲区。
你教 AI 的过程，其实是在教自己把话说清楚。
把隐性经验，逼成显性结构
我们这代人身上有大量"只可意会"的东西：看到一段代码你会说"这写法不太对劲"，但说不出为什么；review 时你会说"这样改以后会踩坑"，但举不出具体的坑。
这叫直觉，也叫肌肉记忆。它有用，但它不可传授------不可传授的东西，也就不可迭代。
AI 逼我做了一件事：把直觉变成语言。你想让它产出好东西，就必须把"什么叫好"讲成它能理解的规则。而一旦讲出来你会发现：原以为自己懂的，有三成其实是含糊的；而讲清楚之后，自己的判断速度反而更快了。
这一年我用 AI 做的最有价值的事，不是让它帮我写代码，而是借它的手，把自己的知识体系重新整理了一遍。
从"我知道这个东西"，到"我能说清楚它为什么是这样"------这是两个层级。
六、建立你的 AI4SE 日常：磨合、反馈、试错、突破边界
AI4SE（AI for Software Engineering，用 AI 做软件工程）说到底不是一个工具问题，是一个协作关系问题。而任何协作关系，都是磨合出来的。
我的节奏不一定适合你，但你可以拿去改：
晨间（15 分钟）：把今天的任务拆成 3-5 个可独立验证的小块，给每块写清验收标准（这是给它的，也是给自己的）；挑出"我最没把握"的那块，留给自己做。
开发中：先给约束再给任务------不说"帮我写个组件"，而说"按规范写个 X 组件，要求 A/B/C，不要做 D"。每轮产出后给具体反馈，不是"不对"，而是"这里不对，因为我们的状态是全局共享的，你应该......"。它反复犯的错，立刻写进 rules。
收尾（10 分钟）：逐块 review diff，重点看数据流和边界；让它生成 commit message，但自己复核一遍；复盘哪一环帮了大忙、哪一环帮了倒忙，倒忙的原因写进规范。
反馈的复利是惊人的。 同一个任务，第一次你可能要来回七八轮；磨合三个月后，两轮就能拿到可用的结果。这个差距不来自 AI 变强了，来自你把话说得更准了。
鼓励它试错，但要求它解释；允许自己突破边界，但不允许自己放弃判断。
七、AI 时代的新 SWOT：重新审视你自己
盾牌＝优势 · 警示＝劣势 · 上升箭头＝机会 · 靶心＝威胁
最后，给还在观望的同行一套我用来做年终复盘的框架。
S｜拿不走的：业务理解（为什么这个需求现在做、那个可以拖）；架构判断力（什么该拆、什么现在别动）；工程品味；跨部门推动力；以及兜底能力------它写不出来的时候，你还能自己写出来。
W｜正在被稀释的 ：手写代码的肌肉记忆------离开补全还能不能流畅写一个完整模块；调试直觉；底层原理；以及把控全局的信心------当系统里有一半代码你没真正读过，你还敢不敢说"这个系统我负责"。
O｜正在打开的 ：一人成军；从执行者到编排者（产出不再取决于手速，而取决于拆解能力）；能力边界扩张（以前说"这个我不会"，现在可以说"给我两天"）；成长为超级个人智能体------一个懂业务、懂架构、并且带着一支数字团队的你。
T｜正在逼近的 ：同质化（同一批模型、同一套 prompt，产出越来越像）；能力空心化------看起来什么都能做，实际上什么都不深；被会用 AI 的人替代；路径依赖------习惯了"有问题就问它"，你就失去了独立推演的耐心。
画完这张表，结论其实很简单：
AI 不会让强者更强，它只会放大你原本的样子。你混乱，它帮你混乱得更快；你清晰，它帮你清晰得更远。
你越懂，AI 越强；AI 越强，你越贵。
这就是我说的"双赢"。
八、写给还在观望的你
御马：不是让它跑得更快，是让它跑在对的方向
我知道很多同行还站在岸上。有人是忙，有人是不屑，有人其实是怕------怕自己练了十年的手艺，一夜之间不值钱了。
我不打算说服你，只想说三件我确定的事。
第一，抗拒没有意义，但盲从更危险。 你可以不用它，但不能不了解它。不了解就下判断，和你当年没看过一个新框架就说它垃圾，是同一种懒惰。
第二，你的价值从来不在"写代码"这三个字上。 如果你的核心竞争力是"我打字比别人快、我记的 API 比别人多"，那确实该焦虑。但如果你的价值是判断、拆解、权衡、推动------那 AI 不是来抢你饭碗的，是来给你配团队的。
第三，别把工作做成了 AI 的样子。
这句话送给我自己，也送给你。
AI 的产出是平均值------它给你的是"大多数情况下大多数人会怎么写"。而你的价值恰恰在"大多数"之外：那个别人想不到的边界条件、那个只有你知道的历史包袱、那个基于业务判断做出的反直觉取舍。
如果你只是把 AI 的产出原封不动地交出去，那你就在亲手把自己变成 AI。
回到开头那个画面。早上九点半，我打开编辑器，屏幕右边坐着五个不领工资的初中级研发。
十几年前，我就是这样带着一群年轻人，一边写代码，一边教他们怎么写，一边被他们逼着把话说清楚。
十几年后，场景几乎没变。
变的只是：这一次我要带的人，速度快了一万倍，记性好了一万倍，而且永远不会累。
不变的还是那句老话：带团队这件事，最终考验的不是你能写多少，而是你能让多少人写对。
现在，去给你的新同事们，写一份《新人上手指南》吧。
它们已经在等你了。
如果这篇对你有点用，转发给你团队里那个还在观望的同事。他可能需要的不是工具推荐，而是一个敢开始用的理由。