上周五在公司的技术例会上我顺手做了一件事把团队最近一个月合并到主干的提交记录拉出来逐个看了一眼里面有没有AI生成的代码痕迹包括注释风格异常、结构过于规整、以及那种“看起来没问题但总感觉不像人写的”片段。统计结果让我自己都愣了一下——超过四成的提交里能明显看到AI参与的影子如果算上“人工改过AI初稿”的情况这个比例还要更高。但就在同一个会议室里一位干了十几年后端的老工程师跟我非常认真地说“AI写的代码我不敢兜底我宁愿自己多花半天重新写一遍。”这就是今天想聊的话题AI编程已经铺到我们每天的工作流里几乎无处不在但并非所有人都信服。信的人已经把AI Agent当同事使唤不信的人依然坚持每一行都要自己敲。这篇东西不打算急着站队我会把两边的理由、我自己实测下来的能力边界、以及团队用了大半年后沉淀下来的几条实用规则全都摊开来讲。1. 先承认一个事实AI编程的扩散速度已经不需要争辩很多人一聊AI编程就喜欢争论“能不能用”但现实是这个问题已经过时了。我身边真实的开发者生态里AI早就不是一个“要不要用”的可选项而是一个默认存在的工作背景。你打开编辑器Tab补全背后是模型你搜报错信息第一条结果长什么样已经不重要了因为你会直接把报错粘给AI你接一个新需求第一件事是让AI帮你列接口设计和边界条件。这种渗透不是某一家公司的特例而是整个行业的默认走向。1.1 从“玩具”到“默认选项”我观察到的三个变化我自己的感受里有三个特别明显的变化节点。第一个变化是环节前置。以前写代码是整个流程的核心现在写代码反而变成了“验证AI方案”的过程。需求评审一结束团队里最熟练的那几个人会先把需求文档丢给AI让AI生成一个初步的技术方案和数据模型。人是来做判断题和决策题的AI负责生成候选答案。第二个变化是错误处理的方式变了。以前遇到一个诡异的线上Bug我的习惯是打日志、加断点、追堆栈一步步缩小范围。现在我的第一反应是先把堆栈和上下文丢给AI让它给我一个嫌疑列表。说实话有一半的情况下AI的猜测并不准但它给出的排查思路里经常藏着我自己容易忽略的角落比如并发条件下的状态覆盖、异常被吞掉之后的连锁反应。这种“先问AI再动手”的习惯一旦养成很难退回去。第三个变化是团队结构在悄悄调整。我认识好几个创业团队现在招人策略已经从“我要十个开发”变成“我要三个厉害的人加一堆AI工具”。有个做SaaS的朋友团队从八个人精简到三个人加一个AI Agent流水线迭代速度反而还快了一点。这不是什么遥远的科幻故事而是发生在我朋友圈里的事实。1.2 不服气的人群并不是同一批人有意思的是对AI编程“不服气”的人其实分成完全不同的两大类他们之间的诉求甚至是对立的。第一类是经验非常丰富的老工程师。他们不服气的点在于“责任边界”。代码出问题了你要对线上的事故负责要面对业务方的质问AI能替你背这个锅吗不能。在这种人眼里AI生成的代码就像一个态度很好但经验为零的实习生什么都敢写什么都敢说“应该没问题”但出了问题你还是要自己扛。他们的不信任本质上是对“兜底责任”的清醒认知。第二类反而是刚入行不久的新人。他们不服气的点在于“路径依赖被破坏了”。以前学习编程的路径非常清晰看书、写demo、刷题、做项目、踩坑、总结一步步把经验攒起来。现在AI直接把最终答案摆在面前看似走了一条捷径但绕过了所有该踩的坑。很多新人有一种隐约的焦虑我现在确实能用AI把需求做出来可如果哪一天没有AI了我是不是连一个增删改查都要想半天这种不信任不是觉得AI不行而是担心自己不行。把这两拨人放在一起看你会发现“信服”和“不信服”根本不是同一个维度上的话题。老手担心的是“AI搞砸了怎么办”新人担心的是“以后没有AI了怎么办”。这两种担心都是真实的也都不能被一句“你要拥抱AI”打发掉。2. 把“不服气”拆开看有人输在体验有人担心真问题既然有人不服咱们就得弄清楚他们到底在不服什么。我发现网上很多讨论AI编程的文章都喜欢把质疑者描述成“思想保守、拒绝变化”的顽固派但以我接触到的人的实际情况来看这个归类太粗暴了。质疑的声音里有一部分确实是体验不好带来的情绪但还有相当一部分指向的是真实的工程风险。2.1 最容易翻车的场景越是“你觉得AI懂了”的时候我自己用AI编程踩过最大的坑不是需求复杂、上下文很长那种反而是那种“我觉得AI已经懂了”的场景。有一次让AI帮我重构一个订单状态流转的模块我给了它很详细的需求描述它第一次生成的代码结构漂亮得惊人状态机的设计模式用得相当标准我当时都快感动了。但往深了看才发现它对业务里几个特殊状态的约束理解错了——比如“已退款”的订单在某些条件下还允许“用户主动取消”这种边界情况它完全没有处理。这种问题是最难防的。因为AI写的代码不是完全不能用而是大部分能用、小部分致命。它不会像刚毕业的新人那样一下给你整段全部报错它会把错误藏在优雅的抽象和漂亮的命名背后。等你发现的时候通常是线上出了一个非常诡异的Bug你顺着代码一查才发现一个前提条件从一开始就是错的。这种“高完成度低正确性”的输出比“直接写不出来”要危险得多。2.2 真正让人紧张的是“没人兜底”的系统风险除了单点上的代码质量问题另一个让人不服气的理由是系统性的AI编程在放大“无人负责”的风险。以前一段代码合并进主干写的人要对它负责。代码写得烂Code Review的时候会被同事喷出了事故邮件列表里会挂着你的名字。现在呢AI生成的代码是谁的责任你让AI写了一个模块它写错了你能去骂模型吗不能。你说你只是“参考了AI的方案”可代码是你提交的责任依然是你的。AI的存在让每个人可以用更少的时间产出更多的代码但产出的责任没有变少反而因为代码量变大而更难盯得住。我还观察到一种更隐性的风险团队里如果缺少足够强的技术骨干来兜底AI会把团队的平均水平快速推向“看起来能跑但没人真正理解”的状态。代码提交越来越频繁模块之间的依赖越来越绕但能讲清楚系统全貌的人寥寥无几。以前写代码是一种“慢工出细活”的手艺现在变成了“AI出量产人出质检”的流水线。而流水线上如果质检员本身也不懂工艺产出的东西就很可怕。2.3 此外还有几笔“算不清的账”安全、合规与知识产权除了代码质量还有几笔账是团队必须算清楚的。第一是安全问题你让AI生成的代码有没有可能把密钥硬编码进去有没有可能调用了不安全的依赖库版本有没有可能在正则、编码转换、权限校验这种环节留下漏洞这些都不是AI的“锅”但用AI的人得承担后果。第二是合规问题。有些客户的合同里明确写了代码的出处和知识产权归属AI模型训练数据里包含的代码来自大量开源仓库这些代码的许可证兼容性你根本没法完全追溯。如果你的产品要过合规审查这是个非常头疼的事。第三是数据隐私问题你把公司核心代码贴给一个第三方的AI工具就等于把家底交给了别人。我见过不止一家公司因为担心代码泄密严格要求内部仓库的代码绝不能进公网AI工具。这些约束叠加起来就让“AI编程无处不在”这句话在公司层面打了不少折扣。3. 我自己实测的边界什么任务AI能扛什么任务必翻车聊了这么多态度层面的事总得落到实际操作上。我在自己的项目里做了一件挺费时间的事把日常遇到的开发任务按类型分了一下每一类都让AI去试了试然后记录它的表现。折腾了两三个月之后我得出一张特别实用的“能力边界表”今天直接分享给你。任务类型AI表现我的结论写一个独立的小工具脚本非常好基本上十几秒就能给出可用代码少量修改就能跑实现一个定义清楚的数据模型转换很好只要字段映射说得明白它很少犯错根据已有代码风格补全一个模块中上需要喂足上下文但产出风格一致性很好重构一个有历史包袱的模块非常差它会对旧逻辑做“美化式重写”然后破坏隐含行为排查一个表现诡异的线上Bug时好时坏它能给思路但最终定位必须靠人做设计一套有复杂业务规则的状态机较差表面设计漂亮边界规则大概率漏大范围跨文件改动不建议改着改着就“局部正确、全局失联”3.1 一次中型模块重构AI的高光与翻车清单挑一个印象最深的例子来说吧。我最近接手了一个老模块的重构任务模块不大不小大概两千多行负责一个积分系统的核心计算逻辑。这个模块最大的问题是历史逻辑复杂里面塞了各种营销活动叠加的规则而且没有测试。我一开始是抱了很大期望的——直接把整个模块丢给AI让它做“提炼拆分”因为按道理这种机械性的重构工作机器应该比人擅长。结果就是本节开头讲的那个翻车现场AI给我的第一版重构代码结构确实漂亮用了很现代的PHP语法还用上了我不太常用但很标准的模式。但当我对照旧逻辑去验证一些很偏门的历史规则时发现它“好心”地把很多看似重复实则有关键语义差异的分支合并掉了。这个经历让我明白了一件事AI特别擅长把“看起来重复”的代码简化掉但它没有能力判断那些重复背后是不是藏着不同的业务语义。从那以后我再也不让AI做“在没有测试保护下的重构”。它适合做的事是“在测试保护之下的重构”——先把关键路径的测试用例全部用代码固化下来然后再让AI动手。测试是安全网没有安全网就上高空作业人和AI都得完蛋。3.2 AI的“自信度”与代码风险往往成反比还有一点我必须强烈提醒所有人AI的表达方式有极强的迷惑性。它生成代码的时候如果遇到拿不准的地方不会像人那样犹豫或者留个TODO它会把一种“看起来最合理的方案”直接当作答案写进去而且解释得头头是道。你问它“这段代码有没有问题”它大概率会说“根据我的分析目前逻辑是完整的但建议你用更多用例进行验证”——等于没说。所以我把AI当成一个“过度自信但能力波动很大的同事”。跟这个同事合作你要随时保持一种有礼貌的怀疑。它说“这个功能实现了”你要自己去读它生成的测试才能确认它说“这个方案可行”你要自己画图验证一下依赖关系才能信任。不要被它写出来的专业口吻和漂亮结构带跑这一点在AI编程里比什么都重要。4. 比“信不信”更值得讨论的是怎么用才不会变成两头都不讨好在“AI到底行不行”这个口水仗打了无数回合之后我更愿意把问题换一个角度不管你是怎么想的AI进入工作流这件事已经不可逆了。那怎么用才能让既不会变成无脑吹的“工具依赖患者”也不会变成坚决不碰、然后看着别人效率翻倍的“抵抗分子”我的体会是关键不在于“用不用”而在于“怎么用”。同样的AI工具有的人用起来是如虎添翼有的人用起来是自找麻烦——差别不在工具在使用方法。4.1 提示词工程并没有消失而是变得更加关键很多人觉得“AI编程提示词”这个词已经过时了因为现在的模型理解能力越来越强随便说一句“帮我写个登录功能”它也能给你生成。但如果你追求的是稳定可靠的产出提示词的质量直接决定代码的质量。这不是玄学它有非常现实的逻辑AI生成代码的质量上限基本取决于两个因素一个是你给它喂的上下文有多准另一个是它对目标的理解有多清晰。我自己现在写提示词的固定套路是“上下文充分、验收标准前置、约束显式化”。上下文充分就是把相关代码片段、数据表结构、接口文档全部粘进去而不是只丢一句自然语言需求验收标准前置就是先告诉AI“什么样的输出算通过”比如处理哪些边界条件、遵循什么代码规范、要不要写单元测试约束显式化就是把禁止事项直接说清楚——“不要修改已有的接口签名”“不要引入新的依赖库”“不要改变旧逻辑的行为”。这套模板看起来朴实但能大幅减少AI“自由发挥”的空间。AI就像一个有主见的下属你交代任务越模糊它越会按自己默认的思路来而那个默认思路通常和你的业务需求是有偏差的。4.2 用“结对编程”思维替代“代写代码”思维还有一点心得我觉得特别值得分享把AI当成“结对编程的同伴”而不是“代写代码的工具”使用体验会有本质区别。代写模式是什么样的你给它一个需求它给你一大段代码你拿过来看看好像没问题就提交了。这种模式下AI生成代码的正确性压力全压在你这边而且你很容易产生“反正它是AI写的应该比我靠谱”的错觉。结对模式是什么样的你把自己当成主导者让AI来当那个“不断给你提方案、供你批评”的辅助角色。你不用它替你写整个功能而是让它帮你做几件事列出几种潜在实现方案的优缺点、给出一个你要亲手实现的基础骨架、帮你写一版参数化的测试用例、在你卡住的时候提供一种“第三种思路”。在这种模式下产出的代码每一行你都是理解的它的正确性是你把关的AI只是让你的手更快、让你的视野更宽。坦白讲这才是AI编程让我个人效率提升最明显的方式。5. 落到团队落地层面我更新过的四条实操军规最后这部分跟大家分享一下我们团队在使用AI编程大半年之后通过无数教训和讨论总结出来的四条实操军规。这些规则不一定适用于所有团队但它们解决的是真实工作中的冲突和责任问题所以我把它们原原本本写出来你们可以根据自己的情况裁剪。5.1 强约束这几类代码必须人来写我们规定有几类代码是“禁止AI直接生成并提交”的。第一类是涉及支付、权限、数据删除等敏感操作的代码。不是说AI一定不行而是一旦出了问题影响面不可控必须让人一点一点地审清楚。第二类是项目里最核心的领域模型和状态机。前面的实践告诉我们AI在这些地方因为缺乏真正的业务判断力非常容易生产“逻辑正确但语义错误”的代码。第三类是跨多个服务、牵一发而动全身的接口变更。这种代码交给AI后果就是它改了一处、裂了三处而且每一处都是“合理”的裂。这并不意味着这类代码完全不碰AI而是说AI可以参与讨论、给出草案但最终落地的版本必须由人重写一遍。我们内部管这个叫“AI只能当副驾主干道必须人握着方向盘”。5.2 把Code Review升级成“对抗式验收”以前我们做Code Review是看代码风格、看逻辑漏洞、看潜在风险。现在加了AI之后Review的强度必须上一个台阶因为AI生成的代码太容易“看起来没问题”了。我的做法是在Review的时候特意带一个新问题“这段代码如果是AI写的它会在什么地方犯错”对抗式验收的核心有三点第一必须把AI生成代码涉及的关键业务规则找出来逐条对照尤其关注那些“AI可能会因为觉得没必要而合并掉”的重复分支。第二要求代码提交者说明每一段关键逻辑“为什么这样写”回答不上来的一律打回。第三必须有能跑起来的测试用例作为证据不允许出现“我测过了应该没问题”这种无凭据的话。说句实在话在引入AI之后我们团队Code Review花费的时间不是变少了反而是变多了。但这笔时间花得值。它把“信任AI”转化成了“审查AI产出”而不是让AI悄悄进入我们的生产系统然后等着它出其不意地出Bug。5.3 保护新人的成长路径AI不能让“不理解代码的人”毕业这一条是我作为团队技术负责人特别坚持的AI可以当新人的老师但不能当新人的替身。具体落实到管理上我们有两条规定。第一条新人入职前几周不让他们用AI直接生成业务代码只允许用AI查文档、解释概念、生成练习题和做题。目的很朴素——必须先把编程基础打扎实知道每一步在干什么才能在上面盖AI的楼。第二条新人用AI完成的任务必须在小组内做一次完整的技术讲解讲清楚每段代码的逻辑和取舍。讲解不清楚的说明他没有真正理解那这活就不能算他干完。我见过太多新人被AI“喂”成了巨婴——需求丢给AI、代码复制粘贴、能跑就交差。短期看效率挺高但三个月之后他连自己写的系统是怎么串起来的都说不清楚。这种成长是不可持续的。AI理应让人的起点更高但绝不能让人丢掉理解代码的能力。真正的高手是那个“能比AI更早看出AI方案有问题”的人。5.4 关于“多AI协作”和“AI Agent”的未来形态先放平预期最后聊聊“AI Agent”和“多AI协作”这种更进阶的话题。现在很多团队开始尝试让多个AI Agent分工协作比如一个负责生成代码、一个负责写测试、一个负责Code Review。我们也在小范围试了试感受比较复杂。它确实能跑通一些上下游明确、规范清晰的流程比如从接口定义生成代码、再从代码生成测试、再拿测试结果反推代码修改。这种流程化的事AI Agent之间的协作效率远超单个人工指定。但它的问题也很明显环节越多错误被传递并放大的概率越大。第一个Agent生成的代码有缺陷第二个Agent基于这个缺陷去写测试它的测试会努力去覆盖那个错误的行为然后第三个Agent看了测试说“逻辑正确”。整条链路看起来严谨实际是在为同一个错误层层背书。所以我对AI Agent的态度是可以试但先放平预期。它现在更适合处理那种“边界清楚、反馈快速”的任务离“全自主地把一个复杂业务系统维护好”还有很长的路。如果你正在规划类似的事我建议从风险最低、最容易验证的环节切入先让它帮你在局部维度跑通不要一上来就指望它接管整个研发流程。说到AI编程的未来我现在反而不太关心“AI到底能不能替代程序员”这种话题了。好用的工具从来都不会让真正有能力的工匠失业它只会淘汰那些本来就不打算把手艺练好的人。我自己最深的体会是信服也罢怀疑也罢AI都已经在改写着我们写代码的方式。与其站在两边互相说服不如认真想想怎么让自己成为那个“能驾驭AI、也能为它的产出兜底”的人。最后分享一个实战小技巧吧。如果你刚开始在团队里推行AI编程可以先做一件很小的事定一条规则让AI生成的每一个函数必须带至少一个可以证明它的行为符合预期的测试用例。有了这个规则兜底AI的能力和风险都变得可控你的团队也会更快地找到舒服的协作节奏。