先给结论AI 写代码的能力确实在快速提升但手写代码没有过时也不该被轻视。最近“AI 时代手写代码是不是没必要了”的讨论很多最流行的一种说法是只要提示词写得好AI 生成代码的效率比人高几十倍为什么还要手动敲键盘这个说法对了一半。对的部分是AI 确实大幅压缩了样板代码、重复实现和基础 API 补全的时间被忽略的部分是在真实项目里AI 生成的代码只是初稿后续的阅读、审查、修正、测试、上线和维护仍然需要人来亲手完成。这篇文章想聊的不是“AI 能不能写代码”而是“手写代码的价值到底在哪里”。我会围绕几个问题展开AI 编程解决了什么、没解决什么手写代码为什么在架构设计、遗留系统、性能关键路径、安全合规和线上排障这些场景里依然不可替代以及在实际开发中怎么搭建一套“AI 生成初稿 人工掌控关键路径”的工作流既保住效率又控制质量。下面先把核心判断放在前面。1. 核心判断速览维度判断AI 编程的定位辅助生成工具不是独立工程师AI 擅长的事情样板代码、单函数实现、测试样例、成熟场景的 API 示例AI 不擅长的事情全局架构设计、跨模块上下文、遗留系统改造、安全敏感逻辑手写代码的不可替代部分需求理解、系统设计、调试排障、代码评审、长期维护推荐工作模式AI 生成初稿 人工审查修正 手写核心关键路径适合人群所有开发者新手更需要先打牢手写基础再依赖 AI最大风险把 AI 初稿当最终产出进入上线后才发现维护成本远高于手写这个表格不是唱衰 AI 编程工具而是给“手写代码”重新定位它从“生产方式”逐渐变成“质量保障方式”。下面逐条展开。2. AI 编程解决了什么又没解决什么2.1 AI 真正解决了什么AI 编程工具目前最能打的场景是“已知方案的快速代码化”。比如你要写一个 JSON 解析函数、一个文件读写封装、一个常见算法的 Python 实现或者一个前端组件的布局这些场景有大量公开代码和标准写法AI 能在几秒内给出可运行版本。这类工作的共性特征非常明显范围小、上下文清晰、评价标准明确、不需要和大量既有系统交互。传统开发里这类工作占掉的时间比例不低尤其是写单元测试模板、补注释、生成 DTO 和查请求库的用法。AI 把这些时间压缩之后开发者确实可以把精力放到更重要的模块设计上。2.1 里还需要注意一点AI 在 IDE 里的补全能力对“写过代码的人”加成最大。一个人如果完全不知道某个库的正确用法AI 给出的代码其实很难判断对不对但如果你知道大概流程AI 帮你把模板补完再快速核对几个关键参数效率提升就非常明显。2.2 AI 没有解决的问题第一需求理解。AI 不会替你做产品分析。一段代码应该是“同步处理还是异步队列”“失败重试还是快速失败”“强一致性还是最终一致性”这些问题必须在提示词或需求文档里说清楚。而能把这些约束说清楚的人往往已经有了很强的工程判断力。换句话说AI 把“翻译成代码”这件事变简单了但“定义翻译目标”这件事依然完全依赖人。第二架构设计。单个函数 AI 可以写得很漂亮但一个模块怎么拆、接口怎么定、数据流怎么走、如何保证幂等、如何降级AI 很难通过一次对话给出全局可落地的方案。它更擅长的是在既定设计下填充代码片段而不是替你做系统设计。第三运行时排障。线上出了问题你要看日志、查调用链、分析慢 SQL、做流量对比甚至临时加日志再重新发布。这些工作需要侵入真实运行环境AI 只能给你排查思路参考不能帮你完成定位过程。第四团队协作。代码规范、评审意见、模块接口约定、技术方案文档这些是开发者和开发者之间的事情AI 目前也没有办法参与到一个团队的长期协作上下文里。3. 手写代码依然不可替代的 5 类场景3.1 跨模块、跨状态的全局上下文大型业务系统里一个功能往往要牵动多个模块。以订单取消为例它要处理订单状态流转、库存回滚、退款、消息通知和幂等控制。AI 单看“取消订单”这个需求很容易生成一个顺序执行的函数但真实场景中状态机的边界条件、并发下的重复请求、支付回调的时序问题都需要人来梳理。这里可以看一个简化的订单状态迁移设计from enum import Enum, auto class OrderStatus(Enum): CREATED auto() PAID auto() SHIPPED auto() CANCELLED auto() REFUNDED auto() def can_transit_to(self, target: OrderStatus) - bool: transitions { OrderStatus.CREATED: {OrderStatus.PAID, OrderStatus.CANCELLED}, OrderStatus.PAID: {OrderStatus.SHIPPED, OrderStatus.REFUNDED, OrderStatus.CANCELLED}, OrderStatus.SHIPPED: {OrderStatus.REFUNDED}, OrderStatus.CANCELLED: set(), OrderStatus.REFUNDED: set(), } return target in transitions[self]这种状态迁移关系必须对照业务文档、产品需求和历史事故来确认AI 无法帮你从“用户应该可以取消已支付订单吗”这种问题里推导出唯一正确答案。手写代码的价值就在于你亲手把约束写进代码里而不是交给了概率模型。3.2 遗留系统与老旧技术栈改造很多企业的核心系统不是新项目而是跑了七八年甚至更久的老系统。它们可能是 PHP、Java、C# 混用可能没有自动化测试可能文档早就和代码脱节。AI 的训练数据对这类“脏”项目覆盖很弱因为公开仓库里很难找到同等复杂度、同等混乱度的私有业务代码。在这种项目里改动一个接口前要先读调用方脚本、查历史提交、理解数据表设计。这个过程很依赖“人肉上下文”而手写代码能让你在改代码的同时积累对这个系统的真实感知。直接让 AI 生成一段“干净”的代码反而容易和现实系统脱节尤其是当它忽略了某个老配置、某个特殊字符或某个隐式状态时。3.3 性能关键路径高并发接口、实时数据处理、底层算法库里代码质量直接决定成本和稳定性。AI 能给你一个大方向但真正决定性能的往往是细节循环里有没有重复创建对象、锁粒度是否过大、缓存有没有穿透问题、SQL 有没有走索引、内存分配有没有可以避免的拷贝。这些细节需要在 profiling 结果和具体数据下反复调整。没有哪个 AI 能在不看真实压测报告时精准告诉你“这段代码应该改成批量写入”。手写代码的核心作用不是“打出来”而是帮助你理解每一行的开销最终形成性能敏感意识。3.4 安全、权限与合规逻辑涉及支付金额计算、权限校验、用户隐私数据、审计日志和外部接口鉴权的代码手写和人工审查是最低要求。AI 生成的代码里常见问题包括缺少输入校验、路径拼接没有做安全处理、把敏感参数落到日志、没有考虑数据脱敏、直接信任前端传过来的状态。AI 可以当辅助但最终责任人一定是开发者和团队。一个高效的做法是用 AI 生成初稿然后人工逐行审查关键安全点再补上测试用例。安全逻辑不能只是“看起来能跑”。3.5 调试与线上问题定位这类工作的代码量不大但非常依赖推理能力。比如一个偶发的连接池耗尽问题你需要同时看慢查询、线程池状态、上游超时配置还要对比发布前后流量变化。这些信息分散在系统各处AI 无法直接感知你线上服务的运行状态只能提供排查建议。而人工手写排查脚本、临时打点、复现用例的过程往往就是定位根因的过程。代码不只是输出它也是你思考系统行为的工具。4. 别忽视 AI 生成代码的维护成本4.1 幻觉 API 与错误假设AI 生成代码最常见的坑是编造出不存在的库函数或参数。这个问题在冷门库、私有框架里更明显。你在 IDE 里看到它自动补全了一个方法以为标准库真的支持结果编译不过或者运行到那一步才报错。处理这类问题需要人去查文档、读源码反而比直接手写更耗时。4.2 没有测试或测试是“假绿”AI 可以生成单元测试但这些测试不一定真的覆盖了逻辑。常见情况是写了一个用例但没有断言或者断言写得很宽任何输出都能通过或者只覆盖了 happy path异常路径完全没有检查。“测试通过”给开发者造成虚假的安全感这是比没有测试更危险的事情。4.3 过度抽象与风格不一致AI 的代码生成偏好是“看起来优雅”会引入多层封装、工厂模式、装饰器、泛型。单个文件看可能很工整但放进整个项目后和其他模块的写法不一致团队维护时会产生大量“理解成本”。代码首先是给人读的其次才是给机器执行的。如果 AI 生成的高抽象代码没人能快速读懂它反而变成技术债。4.4 依赖与许可证合规风险AI 生成代码时可能会引用带有特定开源协议的第三方库也可能直接输出与某段开源代码高度相似的实现。企业内部使用时要考虑许可证合规问题如果公司有代码保密要求还要注意不要把私有代码直接发给外部 AI 服务。合规审查必须由人来把关AI 不会自动帮你规避这些风险。5. 手写代码真正锻炼的工程能力5.1 代码阅读与快速理解能力阅读代码也是一种“手写”。你在阅读过程中大脑会模拟执行路径、推断设计意图、定位异常分支。经常手写代码的人读别人代码的速度和准确度都会更高。反过来如果只依赖 AI 生成你面对一个不熟悉的模块时可能连从哪儿开始读都不知道。5.2 抽象与边界划分能力手写代码的过程本质上是在做“边界决策”哪些逻辑放函数内、哪些逻辑拆到类里、哪些放在业务层控制、哪些放到基础设施层。AI 能按提示词写函数但“为什么这个逻辑应该放这一层”是人的思考。边界划分能力越强系统越容易被扩展和替换。5.3 调试与根因分析能力写代码时你会有“自己埋过坑”的经验记忆你曾经因为忘记处理空指针而踩到线上异常下一次就会主动加判断你曾经因为把状态字段直接暴露给前端而吃了安全漏洞的亏下一次就会在服务端做校验。这种对错误模式的敏感度只能靠一次次手写、报错、修复来积累。5.4 代码评审与批判思维代码评审的本质是判断一段实现是否满足约束、是否足够简单、是否隐藏了未来维护的坑。一个没有手写经验的人很难评出深度问题——因为他不理解“这段代码在真实运行时可能会遇到什么”。当 AI 变成主要代码产出者之后代码评审能力反而变得更加重要因为它是对 AI 输出的唯一质量闸门。6. AI 辅助编程的落地工作流6.1 推荐的工作流以下流程可以作为一个通用参考适合大多数业务项目需求澄清与拆解由人完成输出明确的任务边界。模块设计与接口定义由人完成确定模块边界、入参出参、异常约定。AI 生成片段把大任务拆成 100 到 300 行以内的小任务让 AI 逐段生成。人工审查与改写逐行阅读补齐安全校验、异常处理、日志记录。测试补充AI 生成初版单测人工补关键分支断言。提交评审把 AI 输出当成“实习生初稿”来评审而不是默认接受。这个流程的要点是AI 承担重复劳动人承担决策责任。6.2 一个可复用的提示词模板下面这个模板比较适合生成业务代码可以根据实际项目调整请帮我实现一个{功能}语言为{语言}框架为{框架}。 业务约束 1. 输入参数{字段说明} 2. 输出格式{返回结构} 3. 需要处理的异常{异常场景} 4. 不允许绕过权限校验 5. 数据访问方式{数据库或接口} 6. 输出代码风格{项目现有风格} 请先列出关键实现步骤再给出完整代码最后标注出你需要人工确认的不确定点。其中“最后标注需要人工确认的不确定点”很重要它能让 AI 把潜在风险显式列出来而不是隐藏在一整段看起来正常的代码里。6.3 示例文件上传接口的 AI 初稿与人工修正假设要写一个文件上传接口AI 可能给出一个直接保存文件的版本。人工审查时至少要补上扩展名校验、大小限制、随机文件名和路径安全性。import uuid from pathlib import Path from fastapi import FastAPI, UploadFile, HTTPException ALLOWED_SUFFIX {.png, .jpg, .jpeg} MAX_SIZE 5 * 1024 * 1024 UPLOAD_DIR Path(./uploads) UPLOAD_DIR.mkdir(exist_okTrue) app FastAPI() app.post(/upload) async def upload_file(file: UploadFile): suffix Path(file.filename).suffix.lower() if suffix not in ALLOWED_SUFFIX: raise HTTPException(status_code400, detail文件类型不允许) content await file.read() if len(content) MAX_SIZE: raise HTTPException(status_code400, detail文件超过大小限制) new_name f{uuid.uuid4().hex}{suffix} save_path UPLOAD_DIR / new_name save_path.write_bytes(content) return {file_id: new_name, size: len(content)}这个版本仍然可以继续优化比如改成流式写入避免内存占用过高、增加文件内容头校验而不是只靠后缀但重点是这些“业务细节”是 AI 无法替你决定的。哪些校验必须加、加多严格取决于业务场景和合规要求需要人来拍板。更完善的做法是分块读取这里之所以先完整读入是为了展示“大小校验 随机文件名 类型白名单”这些人工审查时需要补齐的点实际生产代码请按框架和场景进一步调整。7. 判断“该手写还是该粘贴”的标准一个比较实用的判断方式是在接受 AI 代码前先问自己四个问题。第一你是否理解这段代码每一行在做什么如果答案是“不完全理解”说明你还没有能力维护它这种代码要当成学习材料而不是产出物。第二这段代码会进入核心业务路径吗它会频繁被修改吗一次性的数据迁移脚本、原型演示代码可以放心让 AI 生成但订单、支付、权限、用户数据这类核心链路值得人工逐行控制。第三这段代码有没有涉及安全边界文件上传、SQL 拼接、命令执行、鉴权逻辑、支付回调只要涉及这些关键词都不能跳过人工审查。第四这段代码的测试是否真的覆盖了关键分支如果 AI 给出的单测只覆盖正常路径就要人工补齐异常路径测试。用这个标准去判断你会发现自己会更自然地接受“AI 写临时脚本人写核心业务逻辑”的分工方式。8. 常见误区与心态调整8.1 误区会用 AI 提示词就等于会编程提示词写得好说明你表达能力不错但不代表你有系统工程能力。真正决定项目成败的是模块划分、依赖管理、异常兜底和上线运维这些能力都需要代码实践来积累。8.2 误区代码生成越快项目推进越快短期看AI 能把第一版代码快速堆出来。但如果没有评审和重构后续 Debug、改需求、加字段、排查线上问题时每一处“模糊的代码”都会加倍消耗团队时间。长期效率不是看你第一版写得有多快而是看代码在两年内被改了多少次、每次改动的成本有多低。8.3 误区新人不需要练手写代码恰恰相反新手更需要先手写。因为手写的过程是建立“代码直觉”的过程什么样的缩进和命名容易读异常应该在哪一层捕获一个函数拆到多细才算合理。这些手感没办法通过阅读 AI 生成结果来建立。建议新人在学习阶段先用 AI 生成参考答案再自己手写一遍最后对比差异理解为什么 AI 的版本更好或者为什么 AI 版本在某些细节上是错的。8.4 心态把 AI 当“结对同事”不是“最终输出方”如果你把 AI 当作一个水平中等、速度快到离谱的结对同事你会自然地审查它的代码、纠正它的问题、补充它遗漏的测试。如果你把它当作“答案生成器”很容易在效率幻觉里埋下技术债。这个心态转过来之后AI 编程的体验会健康很多。9. AI 编程时代的能力建设建议如果 AI 编程工具会继续迭代那么开发者应该把精力放在 AI 替代不了的能力上。第一基础功不能丢。数据结构、算法、操作系统、网络、数据库原理这些知识仍然是排查问题和设计系统的底层工具。AI 可以帮你写出排序代码但它不能替你判断在百万级数据的分布式场景下应该用哪种一致性策略。第二多读高质量源码。阅读优秀项目的源码是在积累“好代码长什么样”的判断标准。当你脑子里有足够多高质量范式才能快速识别 AI 输出里的平庸方案和隐患。第三练好提示词表达。提示词的本质是“需求文档压缩版”。能把约束写清楚的人往往也是能把任务拆细的人。这个能力和写代码能力互补但不替代。第四掌握重构能力。AI 生成的代码通常能跑但未必符合你项目的结构。重构能力决定了你能不能把 AI 初稿改造成可维护的资产。常用手段包括抽函数、去掉过度封装、统一异常处理、补充类型标注、把魔法数字提取成常量。第五建立一个“手写代码区”。即使工作里大量使用 AI也可以每天保留一点手写时间比如写一些算法题、写一个小工具脚本、或者重写一个刚被 AI 生成出来的函数。这个习惯的价值不在于练习题量而在于保持对代码细节的敏感度。10. 总结与下一步无论你是否认同“Dreams of Code”这类创作者对写代码的浪漫化表达有一点已经越来越清楚在 AI 编程时代手写代码并没有过时它只是从“最耗时的生产方式”变成了“质量保障方式”。你现在可以立刻做三件事第一选一个小项目关闭 AI 补全全手写一遍。重新体验从设计到实现的完整流程找到自己在 AI 辅助下容易忽略的薄弱环节。第二把 AI 当初稿生成器但提交代码前用审查清单过一遍异常分支是否完整、是否包含安全校验、测试是否覆盖关键路径、代码风格是否和现有项目一致。第三对核心业务、资金链路、安全逻辑和用户数据相关代码保持人工掌控。AI 可以提高产出速度但它不应该替你承担工程责任。如果你在实践 AI 辅助编程时遇到过特别离谱的幻觉代码或某段 AI 生成的代码在评审时被团队打了回来欢迎在评论区聊聊。那些看起来“AI 什么都能写”的帖子不会告诉你的事往往才是真实项目里最值得分享的经验。