AI 写代码这件事前三个月确实很爽。尤其当你用上带补全、自动生成和 Agent 类工具之后从“不会写、不想写”变成“写不完、写得很快”这个过程几乎不需要适应。但三个月后我身边不少人的状态开始明显分化有人继续用把生成代码逐步沉淀成自己的工作流有人开始返工因为代码库越来越难维护还有人重新翻回文档补架构、补测试、补注释。这篇文章想聊的不是 AI 写代码有多强而是三个月后真正会出现的那些问题以及怎么让自己不是只爽一阵子。下面按我自己的观察和实操经验拆一遍。1. 三个月的真实时间线从爽到慌再到冷静体验过 AI 写代码的人前三个月基本都会经历三个阶段兴奋、怀疑、冷静。这个顺序几乎不会变因为 AI 生成代码的方式决定了它前期效率高后期维护成本需要人来补。先把这三个阶段的形态说清楚你才能对号入座。1.1 第一个月单点任务效率确实翻倍第一个月最容易上瘾。写一个函数、补一段测试、生成正则、写 SQL、做数据清洗这些任务只要输入描述足够清楚AI 基本能在几十秒内给出能跑的代码。我见过同事把设计图直接丢给 AI 生成前端代码第一版确实能看布局结构也基本合理。这种速度带来的冲击感很强人会忍不住把所有能交给 AI 的任务都交给 AI。但要冷静看这些任务都有一个共同点就是“输入输出足够清晰”。一个函数接受什么参数返回什么结果边界条件是什么描述清楚之后AI 生成的就是一个可验证的单点实现。即便出问题影响范围也很小你只需要修这一处。所以第一个月真正提升的不是“写代码能力”而是“把重复劳动外包出去”的能力。这个时候最值得做的事不是继续扩功能而是把用 AI 生成代码的流程固定下来先描述需求再让 AI 给方案再生成代码最后自己跑一遍验证。1.2 第二个月代码变多以后维护问题开始出现第二个月开始问题会慢慢浮出水面。最典型的表现是代码库变大之后AI 生成的代码开始互相冲突。命名风格不统一有的人喜欢驼峰有的人喜欢下划线有的函数有注释有的函数完全不知道在干嘛同一个逻辑可能在三个文件里出现三遍。这时候你会频繁遇到“改 A 文件导致 B 文件崩掉”的情况。为什么因为 AI 生成代码时是按单次对话上下文来理解的它看不到你整个项目的完整结构。如果你没有主动给它项目背景它就会基于“最常见写法”生成一段看起来很标准的代码而不是基于你当前项目的实际约束。另一个很隐蔽的问题是 AI 幻觉。AI 可能编造一个不存在的函数名、对象字段或者 API 参数语法检查不报错但运行到那个位置就抛异常。尤其当你在长对话里持续让 AI 改同一个函数时它可能把之前假定的变量名或者字段名记串导致生成结果越来越偏离真实代码。这个阶段最需要的不是更会写提示词而是版本管理和测试意识。如果项目从一开始就没有 Git 提交记录、没有 lint 工具、没有基础测试AI 带来的上下文丢失会被无限放大。1.3 第三个月真正的分水岭是“能不能解释这些代码”三个月后决定你还能不能继续用 AI 写代码的不是 AI 本身而是你自己能不能承担代码维护的新增成本。一个很直接的标准现在给你一段两个月前让 AI 生成的代码你能不能准确说出每一段逻辑为什么存在如果不能那么一旦线上出问题你只能重新去问 AI“帮我查一下这段代码有什么问题”然后陷入“AI 猜现象、你再验证”的低效循环。我自己的经验是如果遇到 bug 后你需要在半小时以上才能定位问题大概率是因为你并不真正理解这段 AI 生成的代码。你只是把它当作一个黑盒粘贴进了项目。这种情况在个人项目里还勉强能扛在团队项目里就是事故隐患。到了这个阶段正确的做法是改变定位把 AI 当成一个快速生成初稿的助手而不是最终交付物。生成代码只是开始之后必须有人做审查、补测试、写注释、做边界验证。如果你不愿意做这些那三个月后 AI 写代码带来的红利会被技术债吃完。2. AI 写代码真正的边界什么能写什么不能信AI 写代码不是不能信而是要分清场景。它的能力边界不在“能不能写”而在“写完以后你能不能验证”。能验证的任务风险可控不能验证的任务AI 越自信越危险。2.1 适合用 AI 写的任务类型适合的任务通常有这些特征语义边界清晰、输入输出明确、错误影响范围小、验证成本低。常见几类一次性脚本数据清洗、文件批量改名、日志解析。基础 CRUD常规的表单提交、列表查询、数据保存。测试样例根据函数签名生成单元测试模板。正则表达式这类任务语法细节多AI 生成后跑几个用例就能验证。配置模板Dockerfile、CI 配置文件、IDE 配置。代码注释和文档草稿让 AI 先写你再修正。这些任务的共同点是你很快能判断“对不对”。只要跑一次、看几条结果就能确认是否可用。出了问题也能本地隔离不会直接影响到核心业务。2.2 不适合直接让 AI 写的任务类型不适合的任务要么是验证成本高要么是出错代价大。典型包括支付、权限、登录态校验安全边界敏感必须人工逐行 review。并发、锁、事务AI 生成的方案在简单场景下没问题但在特定时序下容易出错。嵌入式底层时序、中断、寄存器配置、内存布局AI 可能生成“编译通过但行为错误”的代码。不少做嵌入式的朋友会说“全靠 AI 写代码”但在这类场景里我建议不要全靠至少关键驱动部分要自己控制。复杂状态机或协议解析状态太多AI 容易漏边界条件。核心算法性能和安全要求高需要基准测试和大量边界样本来验证。任务类型AI 生成风险建议一次性脚本低影响范围小可用但要看输出结果基础 CRUD中需关注参数校验和异常处理可生成初稿人工补校验支付/权限高出错成本大必须人肉审查AI 只做辅助并发/事务高时序问题难发现需要设计评审和充分测试嵌入式/驱动高行为错误难定位只用来生成参考不直接落地2.3 识别 AI 幻觉代码看起来对但跑起来错AI 幻觉在代码场景里有两个典型表现第一推荐了不存在的依赖包或模块名第二使用了看似合法但实际不存在的 API 参数或方法。前者在 pip install 或 npm install 时就会暴露后者更隐蔽因为编译不报错只有运行时才炸。应对思路很简单生成代码后不要直接复制进项目先让它解释一遍它用了哪些 API然后对照官方文档验证。对关键依赖先把版本锁定不要默认“AI 推荐的就是最新稳定版”。我一般会这样做把 AI 生成的代码放到一个虚拟环境或者临时分支里跑最小样例再合入正式项目。只要测试足够小、足够快就能在几秒内暴露大部分幻觉问题。3. 三个月后真正要补的工程能力使用 AI 写代码一段时间后你会发现写代码这个动作本身变廉价了但想清楚要写什么、怎么维护、怎么保证质量这些能力变得更贵。如果你不想只是“爽三个月”就要补三类工程能力。3.1 需求拆解能力AI 生成代码前先知道自己要什么很多人给 AI 的提示词是“帮我写一个用户注册接口”然后 AI 生成一个基础版本但距离可用差很远。问题不在于 AI 能力不行而在于需求没有拆到“输入、处理、输出、异常、边界”的粒度。好的需求描述不是把界面截图丢给 AI而是要明确字段有哪些、哪些必填、格式要求、存储位置、成功返回结构、失败返回结构、超时时间、是否需要幂等。举例来说下面两种提示词的产出质量完全不同普通提示词 帮我写一个图片上传接口。 高信息量提示词 在 Python FastAPI 项目中新增一个图片上传接口字段名 file限制 jpg/png大小不超过 5MB保存到 uploads 目录文件名用日期随机串返回 JSON 格式 {url: string, size: number}。如果文件类型或大小不合法返回 400 和错误信息。第二种描述不只是给 AI 更清楚的信息也是在逼自己先想清楚需求。这个过程和产品经理沟通需求是一样的产品经理不需要指导程序员怎么写代码但应该把验收标准和异常场景写清楚。AI 时代这个能力变成了每个写代码的人的基本功。3.2 代码审查能力不要做无情的合并机器AI 生成的代码如果你想长期维护就一定要走 review。个人项目也要 review只是 review 的人只有你自己。我给自己定的检查清单比较简单但很有效导入的包是否都用到了来源能不能确认有没有异常处理失败路径是否清晰有没有硬编码的密钥、IP、路径输入校验是否太宽松有没有隐藏的全局状态这段代码改起来顺不顺还是说只能靠 AI 继续改后面这一点经常被忽略。如果 AI 生成的一段代码“只能跑、不能改”那它其实不是资产而是负债。因为你每次要调整功能都得重新让 AI 生成一遍然后再次面对“能不能改”的问题。对团队项目来说更严格一些AI 生成代码必须附带测试必须通过 lint 和编译关键模块必须有设计说明禁止 AI 生成代码直接 push 到主干。这些规则看起来严格但会省掉后续大量排错时间。3.3 安全与依赖意识AI 推荐包名和版本时别直接抄AI 写代码时会直接给出 pip install 或 npm install 的包名和版本甚至直接生成 import 或 require 语句。这里有一个很实际的风险AI 可能推荐一个名字很相似但来源不明的包或者推荐一个已经停止维护、存在已知漏洞的版本。在正规开发流程里依赖引入不能只看“能不能用”还要看“有没有必要、有没有维护、有没有已知漏洞”。具体做法是不直接用最新版本优先使用稳定版并锁定版本。使用 lock 文件固定依赖树。定期扫描依赖漏洞。移除不再使用的包。这不是要你怀疑 AI 推荐的所有包而是要在落地前多一道确认动作。AI 可以帮你写代码但它不会替你承担供应链风险。4. 单打独斗和团队协作是两种玩法AI 写代码在不同场景下的适用程度完全不同。个人项目可以更激进团队项目必须更保守。把这两者混在一起是最容易出问题的。4.1 个人项目可以放手让 AI 写个人项目、原型验证、学习 Demo这些场景可以放手让 AI 写。因为它的边界很明确不会影响线上用户也不会因为你改坏了某个模块导致他人阻塞。你可以用 AI 快速验证一个想法比如生成一个爬虫脚本、一个数据分析流程、一个基础后端服务。但即使这样我也建议个人项目至少做到三点项目放进 Git 仓库、写一个 README 说明运行方式、给关键函数补注释。原因是“三个月后的你”和另一个陌生人差不多没有文档支撑你自己也会看不懂自己当时让 AI 生成的代码。我比较推荐的处理方式是让 AI 生成初稿然后自己把每个关键函数的含义写一遍。这个过程不费太多时间但对理解项目结构帮助极大。4.2 团队项目必须建立准入标准团队项目引入 AI 写代码之后最大的风险不是 AI 写错而是连“谁对代码负责”都变得模糊。当一段代码是 AI 生成的review 的人容易降低警觉写代码的人也觉得“反正不是我写的尽力了”。这种责任稀释对工程质量是致命的。所以团队中要用制度把责任钉死AI 生成的代码也必须有人负责。具体准入标准可以是必须有对应测试不能只提交实现。必须通过编译、lint、现有测试集。关键模块必须补充设计说明说明这段代码为什么这么写。必须有指定 reviewer 审核AI 不能自动合入。提交信息要说明意图不能写“Generated by AI”就完事。这些规则不需要很复杂但要能落地。否则团队用 AI 写代码三个月后代码库会变成一座巨大的“AI 拼贴画”每个人都在改自己不完全理解的代码。4.3 产品经理和程序员的配合姿势“产品经理如何指导程序员写代码”这个问题的答案在 AI 时代反而更清晰了产品经理不需要指导程序员怎么写但应该把需求边界和验收标准写清楚。过去程序员写代码时遇到模糊的需求会停下来问因为写代码成本高返工成本也高。现在 AI 写代码成本很低程序员可能不再追问直接让 AI 生成一个“看起来符合描述”的版本。结果就是功能上线很快但用户真正遇到的异常场景几乎都没有处理。产品经理真正要做的是提前定义验收标准输入什么、输出什么、异常时提示什么、性能要求是什么。这些内容不但是程序员的开发依据也应该直接拿来作为 AI 写代码的提示词输入。程序员在让 AI 写代码之前先拿这些验收标准拆解任务而不是让 AI 猜需求。5. 让 AI 写代码能长期受益的三个习惯同样是用了三个月 AI 写代码有人越来越顺有人越来越累。差别不在工具而在使用习惯。下面三个习惯是我个人的亲测总结。5.1 每一步都留证据注释、提交信息、设计文档AI 生成代码有一个特点它不带业务上下文。它知道你在这个函数里做了什么但不知道你为什么要做。所以你必须通过注释、提交信息、设计文档把这些“为什么”补上。提交信息尤为重要。不要写“update code”这种没有信息量的话至少写成“修复订单状态异常时重复回调问题”或“增加图片上传格式校验”。下次你回溯问题时一眼就能知道这次改动的目的。我现在会让 AI 先帮我把提交说明的草稿写出来然后人工改一遍。这样做比从零写快而且比完全照抄更可控。5.2 先跑通最小样例再扩展批量场景用 AI 生成批量处理代码时最常见的翻车方式是一上来就让它处理全量数据。比如让 AI 写一个脚本然后直接对整个目录跑结果输出了几百个错误文件还不知道问题是出在数据本身还是代码逻辑。正确顺序是先跑通单条样例再跑小批量最后再跑全量。每一步都要检查输出是否符合预期记录失败次数和失败原因。如果 AI 生成的代码涉及并发处理不要把并发数直接拉满先跑 1、2、4 这样的小并发观察 CPU、内存和日志表现。判断标准不复杂单条是否成功输出是否正确失败是否可重试日志是否可读。这四个条件都满足再考虑扩大范围。5.3 把 AI 当成结对编程伙伴而不是代笔我见过最可惜的一种用法是把 AI 当成一个“自动写代码机器”自己什么都不想想直接说“给我写一个完整系统”。结果 AI 吐出一堆模块化很差的代码然后使用者再花几周去拆解、重构、理解。更好的方式是先让 AI 给方案再让它写实现最后一起 review。比如你可以先问“我要做一个定时任务系统有哪几种实现方式各自的优缺点是什么”等 AI 列出方案后你再选择适合当前项目的路径再让它生成具体代码。这样做的好处是你在这个过程中一直在做技术决策AI 只是执行者。三个月后你提升的是架构能力和判断力而不是只当了一个“AI 操作员”。6. 常见翻车现场和排查顺序AI 写代码大概率会遇到几类典型问题。提前知道这些现象和排查顺序能省掉很多试错时间。6.1 现象一代码没有报错但结果不对这是最有迷惑性的问题。接口返回 200但数据字段为空脚本执行完输出文件却少了部分内容。代码本身没有语法错误运行也不抛异常就是结果不对。优先检查这几类隐蔽问题输入边界、参数默认值、正则匹配范围、时区、编码、隐式类型转换。特别是 AI 生成代码时它默认你给的输入和它预想的输入一致一旦实际输入有差异结果就会悄悄出错。排查方式很简单先用最小输入复现打印中间变量确认每一步的实际值。不要盯着生成代码读十遍通常发现不了问题要看运行时的中间状态。6.2 现象二改一行别的地方全崩如果你改了一个工具函数结果多个模块报错说明代码存在大量重复逻辑或者不合理的耦合。这个问题在 AI 生成代码里很常见因为 AI 会基于当前对话复用之前的代码片段而不是优先抽取公共函数。这时候不要马上让 AI“修一下”单纯补丁只会让耦合更严重。正确做法是先用测试固定现有行为再把公共逻辑抽取出来减少重复。如果项目已经乱到不好改可以考虑先重构再继续加功能。6.3 现象三AI 生成的代码跑得慢AI 生成代码往往足够“能跑”但不一定足够“高效”。常见问题包括循环里查数据库、N1 查询、全表扫描、重复计算、大量不必要的日志输出。不要凭感觉改。先在代码里打点计时看看耗时集中在哪个环节再针对热点优化。你也可以直接问 AI“这段代码的时间复杂度是多少有没有更优方案”让 AI 给出候选方案你再根据实际场景选择。6.4 排查顺序输入、环境、依赖、参数、日志遇到问题后最忌讳一上来就怀疑 AI 能力不行或者直接把整段代码推倒重写。更靠谱的顺序是先按下面的表排查排查步骤检查内容可能结果1. 输入文件格式、编码、路径、参数类型输入格式不对导致逻辑分支没走到2. 环境系统版本、编译器、解释器、IDE 配置环境差异导致运行行为不同3. 依赖包版本、依赖冲突、lock 文件版本不一致导致 API 行为差异4. 参数默认值、超时时间、并发数、路径参数边界设置不合理5. 日志错误堆栈、运行耗时、资源占用定位到具体异常位置不少看起来像 AI 写错的问题最后查出来其实是项目配置、编译器版本或者依赖版本的问题。比如 IDE 里没有代码提示、编译不通过往往不是代码逻辑问题而是项目配置和环境变量没配对。把这一层先排掉再回头讨论 AI 生成的质量才有意义。写了三个月的 AI 辅助代码之后我最大的感受是AI 不能替你做工程决策。它能帮你快速生成代码但维护代码的是人架构设计是人上线出问题后要扛责任的也是人。如果只享受前三个月的速度后面大概率要花更多时间去填坑。反过来如果你从一开始就把 AI 当作一个需要验证、需要审查、需要对齐需求的协作工具它带给你的就不只是快而是可持续的快。