1. 先想清楚为什么“代码执行者”这个定位正在失效1.1 当AI能写代码纯执行不再是护城河最近圈子里聊GPT-6聊得很凶很多朋友跑来问我同一个问题如果模型都能自己写代码了那程序员还剩下什么我做了十来年技术近一年带团队的方式几乎每个月都在变最大的感受是——不是程序员没用了而是“只会执行”的程序员价值被迅速摊薄了。我这里说的“代码执行者”指的是接到一个明确到不能再明确的任务把它翻译成代码、跑通、提交。比如把一张表的数据导出成Excel写个分页接口或者把旧系统的某个函数拆成两个。这类工作一个熟悉业务但技术一般的人学两天也能干GPT-6这类模型学两秒就能干。现在团队里一个后端新人可能一天也就能写三四个接口但模型可以按任务卡批量产出甚至在产出前自己补几组单元测试。纯执行层面的产出效率已经不在一个量级。有人会反驳模型生成的代码有bug啊不能直接上线。对确实有关系但那是“验证”和“兜底”的问题不是“生成”的问题。生成这件事的成本趋近于零之后护城河就不再是“你能写出来”而是“你知道什么该让它写、写完之后如何去判断”。我在团队里做过一个很小的对照实验同一个内部运营后台的MVP模块用传统方式人写需要两天把需求拆成任务卡交给模型生成再人工修大概两个上午就进入了联调。这中间的差距不是手速而是任务拆解的质量。拆得越清楚AI的产出就越接近可用的交付物。1.2 真正稀缺的是决策权与责任既然执行被工具替代那“责任”就从“把代码写出来”转移到了“这段代码该不该以这个方案存在”。代码执行者过去只需要对语法负责但现在AI可能同时给你三个方案一种性能最好但改动大一种改动小但有隐藏边界风险还有一种实现简单但后续维护困难。谁来做这个取舍还是程序员。这就是为什么我说团队里真正值钱的身份不是“写代码的人”而是“能够对系统状态做决策、并愿意为此承担责任的人”。更直接一点Tech Lead这个角色在这个时代像是被放大了。以前Tech Lead要掌控大方向但仍需要花大量时间在代码实现细节上现在因为AI能承担更多执行细节Tech Lead反而要把更多精力放在需求验证、架构边界、风险排查和协作流程上。你不再是一个写得最快的人而是一个在人与AI之间搭桥让整个系统永远朝向业务价值运转的人。这种责任是模型无法替你承担的——模型不会为线上事故坐立不安也不会在凌晨三点接到告警后去决定是回滚还是热修。如果你愿意扛住这份责任你就能从“执行者”名单里走出来。2. 重新定义岗位AI团队Tech Lead的核心动作2.1 从写代码到编排代码好如果已经意识到角色要变下一步是搞清楚AI团队Tech Lead到底在做什么。很多朋友以为“Tech Lead”还是那个“技术最强、能解决别人搞不定的bug”的人。在GPT-6时代这个定义至少删掉一半。我越来越觉得Tech Lead更像一个系统编排者而不是代码超人。打个比方。以前你是个厨子所有切配、翻炒、调味都得自己上手。现在你有了一个手脚麻利但偶尔会忘放盐的帮厨AI。你站在灶台前真正要做的是确定今晚的菜单告诉帮厨切什么菜、配什么料、起锅顺序是什么然后在他把菜端出来的时候尝一口判断哪里不对哪里该重来。写代码本身的动作变轻了但“编排工作”变重了——这个菜谱怎么设计哪些环节能分出去哪些必须自己盯这就是Tech Lead的活。落到日常我会在做项目拆解时不只拆成“前端、后端、数据库”而是拆成“可直接交给AI生成的任务”和“必须人来做判断的任务”两类。前者通常是结构清晰、输入输出明确、有现成规范的任务后者通常是需要权衡业务策略、需要理解历史包袱、需要承担风险的任务。把这些边界划清楚再去编排AI的产出顺序比单纯让AI生成二十段代码要有价值得多。2.2 需求翻译与验收标准设计当AI成为团队里的“正式成员”后需求翻译这件事的难度反而变高了。以前你面对的是一个听得懂弦外之音的人类你说“这个列表要支持搜索”他会默认做一些边界处理。但模型不会它只会按字面意思执行。如果你没有说清楚“搜索是前缀匹配还是模糊匹配、空关键词返回什么、结果超过100条怎么分页”它很可能会给你一个看似正常实际上处处都是坑的实现。所以我现在非常强调“验收标准前置”。每个交给AI的任务我至少会写清楚三件事输入是什么、输出格式是什么、哪些情况算失败。把这三条写清楚之后AI生成的代码明显更靠近可用状态。有一次让AI写一个文件上传接口我只说了“支持大文件上传”结果它没有处理分片也没有限制文件类型。后来我在任务卡上补了“超过50MB需要分片、只允许PDF和图片、存储路径按日期归档”整个接口基本一遍通过。这就是需求翻译的颗粒度对人说到意图对AI说到边界和约束。2.3 多Agent协作的秩序设计再说一个更贴近GPT-6趋势的点多Agent协作。以前一个任务由一个程序员从头做到尾现在我们可以让一个Agent负责代码生成、另一个Agent负责代码审查、第三个Agent负责测试用例补全。听起来很美但如果你没有设计好协作秩序它们会在同一个上下文里互相覆盖甚至把前一个Agent的结论推翻重来最后产出一堆自相矛盾的内容。我习惯的秩序是“流水线加制衡”先由生成Agent产出再由审查Agent挑刺最后把两份结果交给同一个主持Agent汇总。关键是在每个Agent之间设定信息边界——谁只能读哪种摘要谁的输出是最终版本。比如生成Agent不能直接修改数据库连接配置审查Agent不能绕过测试结果下结论。这些规则听起来很像传统团队里的“职责分离”但到了AI协作里也需要明确写出来。否则多个Agent的能力不构成合力只会构成噪音。3. 能力重构的三条主路如何刻意训练自己3.1 用“预判-对比-复盘”训练判断力能力重构不是喊口号是需要刻意训练的。我总结了三件每天都在做的小事按重要性排在第一位的是判断力。判断力怎么训练我的方法是“预判—对比—复盘”。拿到一个需求先不急着让AI动手自己花十五分钟写一版设计我会怎么实现、有哪些边界条件、性能瓶颈大概在哪。然后把这种预判作为任务卡的一部分发给AI让它在约束下生成。等代码出来后我会逐段对比它哪些地方比我的预判好哪些地方是我想到了但它漏掉的。这个方法看起来简单但连续做两周你会发现自己对系统设计的敏感度明显提升因为你不再只是旁观AI输出而是提前动脑建立了一个“正确性基准”。我还发现判断力最容易被废掉的操作是“看都不看直接复制”。很多刚转过来的同事以为AI生成的代码能跑就是对的。但能跑和正确的距离非常大——可能隐藏着密钥泄漏、无限重试、极端输入下的数组越界。我建议团队里执行一条规矩AI产出的核心代码必须先看一遍再做自动测试。这是给人保留思考空间的最低成本方式。3.2 把AI协作沉淀成工程规范第二件要刻意训练的事情是把AI协作从“个人经验”变成“团队规范”。我们常说文档化但很少有人给AI写文档。我理解的工程规范不只是prompt模板而是一个完整的“AI任务交互约定”上下文里放什么、禁止让AI调用哪些工具、输出要求是什么、哪些关键路径必须人工确认。举个例子我们团队拥有一套“AI产出检查表”不是什么复杂东西就是把常见风险点列成勾选项输入校验是否齐全、是否处理超时和重试、有没有硬编码密钥、数据库索引是否匹配查询条件、日志是否脱敏。每次审查AI生成的代码时拿着这张表过一遍。这样一来无论哪个同事跟AI协作都能保持同一个质量基线不会因为个人习惯差异导致生产质量忽高忽低。这类规范还可以包括模型选择、上下文长度策略、工具调用开关。比如默认只给AI开放只读数据库权限修改表结构的命令必须二次确认。把这一整套沉淀成文档之后“AI团队”才不是一句空话而是一个可复制的交付模式。3.3 业务理解与向上沟通不可外包的软技能第三条主路是很多技术人会忽略的业务理解和向上沟通。当AI把交付速度提上来后业务方对你的期望也会变高——他们会觉得“这东西不是AI一下就能搞出来吗”然后一个简单的需求也要你当天上线。这时候你需要具备一种能力把技术上的不确定性和成本说清楚同时又不打击业务方的信心。我现在的做法是每次接需求先和业务方拉一个“验收口径”对齐会明确哪些是核心场景哪些是异常容忍范围。然后用AI快速做一个带边界的原型让业务方直观看到结果。这和以前“闷头开发最后演示翻车”完全不一样。说白了Tech Lead不是一个人写代码最厉害而是能在复杂的人和系统之间持续把期望管理到可落地的范围。这一块模型再强也替不了你。4. 我在项目中切换协作模式的实操记录4.1 第一步盘点哪些任务真正适合交给AI讲完理念我拿自己最近一个项目做实例拆解。这是一个内部数据平台的重构最初团队有六个人前端两个、后端两个、测试一个、我作为tech lead兼架构。因为历史代码比较乱一开始大家对引入AI持怀疑态度后来我提议先跑一周“AI结对”实验才慢慢改过来。实验的第一步是把所有任务列成一张表然后给每个任务打标能不能在十五分钟内把输入输出说清楚有没有现成的基础库可用是不是需要频繁的跨模块判断凡是满足前两个条件、第三个条件为否的全部采用“AI生成人工审查”模式。当时列表里大概有四十多个任务其中二十多个属于“AI友好型”比如数据导出脚本、接口返回结构整理、单元测试骨架、日志告警规则。剩下十几个涉及服务拆分、权限模型、数据迁移回退策略等仍然由人来主导。这一步最大的收获是团队终于不再凭感觉讨论“AI能不能干”而是用统一标准做分类。普通人容易站在两头吵架一边说AI神一边说AI垃圾真正做过的人会发现AI的能力边界比你想象得清楚关键是愿不愿意先花一个小时把任务说明书拆出来。4.2 第二步为AI定义任务卡与角色协议分类完成后我要求所有交给AI的任务都必须附带一张任务卡。任务卡的格式是任务目标、输入数据、输出格式、约束条件、验收标准、禁用行为。刚开始同事嫌麻烦觉得有这个功夫自己都写完了。但事实上前三次确实慢到第五次开始AI生成结果基本能一次过总体时间明显下降。这就是“先慢后快”的投资。我还给Agent设了角色协议。比如“生成Agent”只负责根据任务卡输出代码不允许修改测试用例“审查Agent”只负责挑错不允许直接改业务逻辑“补充Agent”只负责根据审查意见补测试。听起来像多人协作的分工文档但我们是把它写到Agent配置里去的。这个设计让多Agent的上下文冲突大幅减少因为每个Agent视角单一、职责清晰。在实际使用中有一个细节很重要上下文越界是最大的坑。如果一股脑把整个项目历史都塞进任务卡AI很容易被无关信息干扰甚至在改A模块时把B模块的代码也重写了。所以我规定每张任务卡只携带与本任务相关的模块摘要、接口签名和上游依赖不携带全量代码。实测下来出错率至少降了一半。4.3 第三步搭建“AI写人审自动校验”的闭环最后是整个交付闭环。现在我们的标准流程是需求拆解 → 编写任务卡 → 生成Agent产出代码 → 审查Agent给出问题列表 → 人工review关键路径 → 自动测试与静态检查 → 代码合并。人工review不是全面重新读而是带着审查Agent的问题列表重点看边界、安全和可维护性。这个过程代码V3速度很快因为AI已经帮我们把重复性的校对做掉了。我这边还专门维护了一份“AI代码Review清单”已经在前面提过这里再展开讲讲第一输入验证别让传进来的数据直接拼接SQL或HTML第二异常路径超时、重试、并发冲突有没有兜底第三幂等设计接口重复提交会不会产生脏数据第四可观测性日志里有没有足够的上下文第五残留代码AI经常因为上下文发散生成一堆看似在解决问题、实际上根本用不到的变量和函数。五条过完没有大问题就可以进测试环境。实话说这个流程不是一开始就顺的。第一次跑全流程的时候生成Agent给出一个看起来很漂亮的文件上传模块结果审查Agent抓到路径穿越漏洞人工又发现它没处理文件重名。那一版被打回三次才通过。但正是这种“AI写、AI审、人拍板”的三层结构把一个原本需要三四天的模块压缩到了一天半而且质量比我们自己赶工的还好。5. 避坑清单从执行者转向Tech Lead最容易翻车的五个点5.1 会写提示词不等于理解AI模型边界才是关键前面说了很多方法论这条路走下来也踩过不少坑。第一条是很多人把“会写提示词”当成“懂AI”。提示词只是表面真正要懂的是模型的“能力边界”。比如模型对数值计算并不那么可靠容易一本正经地给错误结果对超大上下文理解会退化对工具调用的状态维护有时候会断。如果你意识不到这些边界就可能在关键业务里被它的“自信”坑到。我的经验是凡是涉及强计算、强实时、强一致性的地方不要让AI直接算而是让AI生成调用成熟库的代码由程序自己计算结果。宁可让它去写一个稳定的SQL查询也不要让它心算最后的金额。这里的原则很简单AI负责智力密集的逻辑表达但不负责需要精确结果的中间状态最终结果必须由代码本身验证。5.2 过度自动化会让团队失去手感第二个坑是我自己踩过的过度自动化导致团队失去手感。有一段时间我们把所有任务都优先交给AI连核心算法的实现也走了“AI生成人工review”。结果上线后遇到一个性能问题团队成员花了两天才定位到问题是算法里一个排序策略写错了。如果这个模块是亲手写的可能半天就能意识到。当时我们不得不立下一个规矩核心模块的首次实现必须由人主导AI只能辅助生成单元测试和文档。这个“手感”实际上是你对系统复杂度的直觉它需要经常用纸笔推演和亲手调试来维持。如果连续几个月只做review你会发现自己在线上问题时反应变慢。所以我会刻意保留一些“无AI任务”比如每周五下午做手工调优或者重构一个旧函数让大家的手指不离开代码保持对真实执行逻辑的敏感。5.3 敏感信息与安全规范比代码风格更重要第三安全规范。AI的便利太容易让人放松警惕。我曾经看到同事直接把生产环境导出的脱敏前的数据贴给模型让“它帮忙分析一下”那是在打安全合规的擦边球。后来我在团队里明确生产数据、用户隐私、密钥文件绝对不进入外部模型上下文任何涉及数据的处理必须脱敏后再交给AI。代码生成的时候还要在任务卡里写明“禁止生成包含真实凭证的示例代码”防止模型把某个测试秘钥带出来。这不是小题大做。当AI能自动调用内部系统的时候权限边界就变成了“最后一公里”。Tech Lead要有意识地给Agent设置最小权限能用只读绝不给写能限制IP绝不开放全网。工具调用权限和人工审批流比代码风格重要得多。5.4 只“用”不“建”永远无法形成团队能力第四只“用”不“建”。很多团队把AI当成一个即时工具用的时候写一段prompt用完就关什么也没留下。这会导致AI使用能力停留在个人手感和即时运气上换个人就完全没法复制。我们后来规定每次项目结束必须输出一份AI协作复盘沉淀三类东西哪些任务类型表现稳定哪些任务类型失败率偏高一张好用的任务卡长什么样一份更新后的AI产出检查表。这样建过三轮之后新人在第一天就能拿着模板上手不用重新摸索。沉淀下来的不是“prompt大全”而是“知识地图”——什么场景用AI、什么场景不用、用的话怎么约束。这才是团队级别的AI能力而不是某个人的灵光一现。5.5 软技能不是“锦上添花”而是Tech Lead的门槛第五很多技术人觉得软技能是“会说话而已”但在这个转型期它变成了一道硬门槛。当你带着AI团队去和业务方对齐需求如果一句话没说清楚对方会拿着一个AI生成的漂亮页面对你说“这不就出来了嘛”。你如果只会讲“这里技术上有复杂度”对方很难理解。你需要用业务的例子解释比如“这个功能能做但异常场景需要约定比如网络中断时用户看到什么这里需要人工决策”。还要学会向上管理预期AI让交付变快但也会让需求变更更快。你需要主动设置节奏告诉老板“这个版本我们先切核心链路边缘场景下迭代”。这种沟通能力不是哪个prompt模板能替你完成的。这也是我判断一个开发者能不能成为Tech Lead的重要标准——当系统越来越复杂沟通的带宽要求只会越来越高。6. 给你的落地路线图三个月从执行者走向AI团队Tech Lead6.1 第一个月重新盘点日常工作挑选“AI友好型任务”最后给一份我私底下的三个月路线图适合正在转型中的普通开发者。第一个月先别急着学各种高级技巧。拿一张纸把过去两周的工作内容全部列出来按三个维度打分重复度、清晰度、风险等级。重复度高、清晰度高、风险等级低的任务不管你现在会不会让AI做都先标记出来。然后挑两个最典型的任务用简单的任务卡方式让AI生成记录你的感受。这里的目的不是追求一次成功而是建立手感——你需要在真实场景里感知什么是“能说清楚的任务”什么不是。6.2 第二个月用任务卡驱动一个完整模块训练系统视角第二个月你要完成一个完整的中型模块别再用零散prompt来对话。从设计任务卡开始把模块拆成五到十张卡片每张卡片都带上输入输出和验收标准。然后把生成的代码组合起来自己手动完成集成和调试。这个过程会逼你思考模块边界、依赖顺序、失败回退路径。你会发现原来写代码时关注的“语法细节”现在变成了“接口契约”和“数据流方向”这就是系统视角在悄悄生长。另外推荐每周做一次“预判-对比-复盘”拿到需求先写方案再看AI怎么写对比差异。这比看十篇技术文章都有效因为它是针对你手头项目的定制训练。6.3 第三到四个月在团队内建立标准并推动协作升级第三到四个月把个人能力外化成团队标准。找一个愿意尝试的同事组成双人组把你沉淀的任务卡模板和检查表共享出去。负责一个内部小项目的交付从任务拆解到多Agent分工全部按统一流程走。不要一开始就追求完美先让标准跑起来再根据反馈迭代。走到这一步你的身份实际上已经从“代码执行者”切到了“AI团队Tech Lead”。哪怕职位名字没变你在团队里的作用也会完全不一样。你已经不是在跟AI抢活干而是在决定活儿怎么分、标准怎么定、风险怎么扛。我把这套思路分享过好几个团队最后能聊得来的人都有一个共同特征他们不会急着说“AI真强”或者“AI不行”而是会先问“这个任务的前置条件是什么”。如果你也想转型别急着去研究最新提示词框架从明天早上的第一个接口开始先花十分钟把任务卡写出来再给AI试试。跑上两周你再回来看这篇文章会发现很多困惑已经有了答案。