DeepMind 副总裁最近有句话被反复引用代码已经从稀缺变成免费人类的瓶颈只剩下想象力。很多人看到这句话第一反应是“程序员是不是要失业了”。我不想神化 AI也不想贩卖焦虑。结合最近大量使用 AI 编码工具、处理代码生成、排查 AI 幻觉问题的经验我更想把这句话拆成三件事来理解代码生产方式的改变、开发工作流的转移、以及写代码前后那些没有被替代的环节。先说结论代码生成确实变得越来越便宜但“把需求变成稳定可交付的系统”这件事依然需要大量判断力、技术深度和沟通能力。真正的分水岭不是会不会写代码而是能不能把模糊的想象压缩成清晰的问题、可验证的测试、可维护的架构。这句话的价值不在预言而在提醒过去靠会写代码就能形成壁垒的人现在必须重新找到新的壁垒。下面按我自己的理解把代码免费这件事的实操影响、工作流变化、能力重心和团队落地拆开说。1. 代码免费的本质是生产方式变了不是岗位消失1.1 “免费”的代码到底指什么先明确一点AI 生成的代码并不是物理意义上的不要钱。你用 ChatGPT、Copilot、Codex 这类工具要么付订阅费要么消耗 API 额度要么自己部署开源模型要承担显卡和运维成本。真正的“免费”指的是边际成本大幅下降。过去写一个读取 CSV 文件、做字段清洗、再输出统计结果的脚本从查文档到调通可能消耗半小时甚至更久。现在把需求描述清楚AI 几秒钟就能生成一个可运行版本。对于常见业务逻辑、标准算法、样板代码、接口封装、正则表达式这类“可以被标准化表达”的编码任务AI 的生成成本几乎为零。代码从稀缺变免费说的是这一类代码。我实测时的感受是越贴近教科书、越有标准答案的代码AI 表现越好。比如快速排序、文件读写操作、SQL 查询、多分类混淆矩阵计算、爱心代码、节日特效这类内容模型基本不会出错甚至能给出多种实现版本。现在网络搜索热词里有大量“示例代码”相关的需求这本身就说明获取示例代码的成本已经在肉眼可见地往下掉。1.2 免费不代表可以直接进生产环境代码生成便宜了但代码进入真实系统的成本还是很高。真实项目包含大量上下文既有系统的连接方式、数据库表结构、历史遗留逻辑、团队编码规范、异常处理要求、日志规范、性能指标、安全限制。这些上下文很多不在公共代码仓库里也不在模型训练语料里。AI 在你给出的简短提示词之外并不知道你的系统长什么样。所以“免费”代码更像一份高质量草稿而不是一份可以直接交付的成品。你还需要做代码审查、测试覆盖、边界条件补全、性能验证、依赖检查、安全审计。这些环节的时间和精力没有因为 AI 而消失反而可能因为生成数量增加而需要投入更多。我在实际项目里见过几次典型情况开发者让 AI 生成一段“完整”的批量处理脚本直接部署后发现文件命名冲突、失败重试机制缺失、超大文件内存溢出。不是代码写得不对而是需求描述里根本没有提到这些非功能要求。1.3 代码需求规格也在发生迁移过去人们写需求文档描述的是“我要一个什么功能”。现在和 AI 协作时需求描述本身变成了最关键的生产资料。同样一句话不同精度得到的结果完全不同“写一个 Python 脚本处理数据”“用 Python 读取指定目录下所有 CSV 文件按日期列去重重新排序后输出到新目录并保留原文件名前缀失败时写入错误日志”后者才是真正有效的需求描述。从“写代码”到“写出足够清晰的代码生成指令”这是整个生产方式变化中最重要的迁移。编程语言依旧是 Python、Java、C、JavaScript 这些老伙计但“第二语言”已经变成了精确表达输入、输出、约束、边界和验收标准。这正好对应了那句话瓶颈从代码生产转移到想象力和表达力。这里的想象力不是天马行空的创意而是能把一个模糊想法拆成清晰步骤、合理结构、明确边界的能力。2. AI 能稳定处理的代码类型和仍然依赖人的部分2.1 适合交给 AI 的任务清单先从我的使用场景和网络热词反映的需求出发整理一份 AI 已经比较稳的代码类型。第一类是标准算法和数据结构。快速排序、二分查找、链表操作、动态规划模板、二叉树遍历、图的最短路径等。这些题目在训练语料里出现次数极多模型给出的代码通常正确率很高。第二类是文件处理和格式转换。C 语言文件读写、Python 读取 Excel 或 CSV、JSON 和 XML 转换、批量重命名、目录遍历、plaintext 文本转图片内容提取这些任务规则明确AI 生成的边界情况虽然要补但整体可用。第三类是 SQL 和数据库操作。建表语句、常见查询、索引优化、分页查询、连表逻辑AI 能给出比较合理的初稿尤其在你不熟悉具体方言差异时模型能给出 PostgreSQL、MySQL、SQL Server 的对比写法。第四类是工具脚本和自动化。比如自动化测试脚本、定时任务、日志清理、监控指标上报、CI/CD 配置中的部分模板。这类代码通常短小、命名清晰、标准库成熟AI 生成后能快速验证。第五类是代码解释和转换。把旧语言改写为另一种语言把长函数拆成小函数把命令式写法改成函数式写法给一段代码补注释、写测试用例这些都是当前模型非常稳定的能力。2.2 AI 目前仍然容易翻车的场景再看另一侧。首先是业务规则复杂的代码。保险计费、税务计算、风控规则、供应链状态流转这些业务逻辑往往有几十条分支条件并且高度依赖行业经验和公司政策。AI 没有这些细节强行生成的结果从语法上没问题但业务上可能是错的。其次是历史系统和遗留代码改造。老系统的依赖关系、隐藏约定、异常数据、单点入口这些信息不在提示词里模型也无从学习。直接让 AI 重构一个大函数经常会把原本为了兼容旧接口而保留的判断逻辑“优化”掉导致事故。再次是安全敏感代码。权限校验、加密解密、支付回调、数据脱敏这类场景必须由懂安全的人逐行审查。AI 可能生成看似合理但存在设计缺陷的代码比如身份验证放过一个边界条件或者日志打印了不该打印的敏感字段。还有一类是性能瓶颈非常明显的代码。AI 生成的版本通常追求可读性和通用性不一定适合海量数据、高并发、低延迟场景。它不会主动告诉你某个版本在千万级数据下会内存溢出除非你在提示词里明确约束了数据规模。我的习惯是凡是和钱、权限、用户数据相关的代码不管 AI 生成得多完美都必须人工重点审查。凡是标准算法、工具脚本、格式转换类代码可以大胆使用 AI 初稿但也要跑测试。2.3 查错和验证仍然是硬技能网络搜索热词里有很多“代码诊断”“启动失败代码 2”“由于找不到 libcef.dll无法继续执行代码”“teamviewer 会话代码已过期”这类问题。这些背后都有一个共同点代码或配置已经存在但运行时报错需要人类去判断原因。这个环节 AI 能提供辅助但真正起作用的是你的排查链路。我一般会按这个顺序排查看报错信息本身提示的是哪个文件、哪一行、哪个阶段。看输入数据是否完整路径是否存在文件编码是否正确。看依赖版本和系统环境比如缺少 DLL、环境变量没配好、Python 版本过高或过低。看权限问题比如有没有写文件权限、有没有执行权限、端口是否被占用。看参数设计比如并发数是否过大、超时时间是否过短、批量任务中文件名是否冲突。最后才怀疑是工具自身缺陷考虑换版本或换方案。这套顺序不依赖 AI 也能完成但如果让 AI 辅助你一定要把自己看到的报错原封不动地贴进去同时告诉它你的操作系统、依赖版本、输入样例和已经尝试过的步骤。信息给得越完整AI 的定位越准确。3. 代码生成越来越便宜后开发工作流应该怎么改3.1 从“直接写代码”改为“先写验证方案”很多人都以为和 AI 协作编程就是“把需求发给 AI然后复制粘贴”。实际更稳妥的工作流是先定义验收标准再让 AI 生成代码。以前写代码是“逻辑在脑子里代码落在编辑器里”。现在写代码变成了“验收标准在脑子里代码由 AI 生成”。验收标准可以是测试用例是一组输入输出样例是关键指标的阈值。比如你想让 AI 写一个批量图片压缩脚本不要只写“请帮我写个图片压缩程序”。更好的方式指定输入目录格式指定输出目录和文件命名规则指定图片最大宽度或文件大小目标指定如何处理原始图片是否保留指定如何处理失败和异常指定使用的库和运行环境然后先跑一个包含 2 到 3 张图片的最小样本确认输出正常后再跑完整目录。这个过程看起来多花了几分钟但能避免 AI 生成一个“看起来完整、实际上和你的存储策略完全不一致”的脚本。3.2 AI 生成代码后至少要检查四层第一层是语法和运行层。能不能跑起来依赖是否齐全有没有报错。这一步交给测试环境验证。第二层是功能正确层。输入输出是否符合预期边界条件是否覆盖了空值、重复值、异常值。用写好的测试用例去验证。第三层是质量和维护层。命名是否清晰有没有大量重复代码是否遵循团队规范。可以直接用代码格式化工具、静态扫描工具跑一遍。第四层是安全和架构层。有没有敏感信息泄露有没有 SQL 注入风险是否符合当前架构的模块边界。这是人工审查的重点AI 只能辅助提醒。这四层检查不能省。网上热词里的“sonarqube 扫描本地代码”“sql 代码排版工具”“代码解耦”“优化代码重复删减脚本”其实都是在做这些事。工具是现成的关键是流程上有没有强制执行。3.3 单条顺利后再扩展到批量用 AI 处理单个任务顺手之后很多人会立刻想做批量。批量任务要考虑的问题完全不一样。首先是输入统一性。文件名是否规范是否有空格、中文名、特殊字符是否有嵌套目录。处理前先遍历一遍输入把异常文件单独标记出来。其次是输出命名。批量处理时很容易出现命名冲突、覆盖原文件、输出目录混乱。建议用规则化的命名方式比如“原文件名_结果 .csv”保留来源信息。然后是失败重试。单个任务失败不需要太关注批量任务如果遇到一个文件失败就中断整个队列后边全白跑。可以按“跳过失败继续处理最后汇总错误列表”的方式设计。最后是日志和断点。长时间跑批量任务中途卡住或断电没有断点续跑就要全部重来。哪怕不写断点也要把处理进度输出到日志方便定位卡在哪个文件。这些设计不是 AI 生成一个重要、需要开发者自己主动要求的。如果你只是跟 AI 说“批量处理一下”它通常不会主动处理失败重试和输出冲突。4. 代码免费之后真正稀缺的几种能力4.1 把抽象问题拆成具体步骤AI 不会替你解决“不知道自己要什么”的问题。比如“我想做一个更聪明的系统”这个描述没有任何模型能给出有效代码。但如果你拆成“我要做一个包含三个模块的轻量级流程引擎支持任务排队、失败重试和结果回调”AI 就能给出有价值的设计。这种拆分能力本质上是系统设计能力。你需要理解一个业务目标需要哪些子模块每个模块的输入输出是什么模块之间怎么协作异常情况下怎么处理。过去这个能力隐藏在写代码的过程中现在它变成了最重要的前置能力。很多开发者觉得自己“想象力不够”其实不是而是缺少把想象颗粒化、结构化的训练。4.2 分辨“看起来正确”和“实际正确”AI 生成代码的可怕之处在于它总是语法正确、结构清晰、注释完整看起来非常专业。但代码里可能有一个条件写反了有一个变量名用错了有一个异常被静默吞掉了。普通开发者容易在“看起来很专业”的代码面前降低警惕。这时候需要的能力是批判性审查。看到 AI 输出后先问几个问题这段代码用了哪些前置条件假设是否成立它在边界情况下的行为是什么有没有隐藏的副作用比如修改了全局状态、写入了不该写的文件它的性能是否满足数据规模要求我见过最典型的问题不是 AI 代码完全不能用而是 AI 代码在正常数据上表现完美在空数据、超大字段、格式错误的数据上直接崩溃。这些边界案例AI 不知道你必须主动测试。4.3 沟通和需求校准能力代码免费之后真正的工作时间会重新分配。过去花 60% 时间写代码现在可能花 30% 时间写提示词30% 时间做测试和代码审查30% 时间和业务方确认需求剩下 10% 写那些 AI 搞不定的核心逻辑。这意味着和业务方沟通需求的能力变得更重要。你不能只接一句“这个功能帮我做一下”就去写代码。你要追问几个问题这个功能给谁用预期输入是什么格式主要使用场景是什么哪些问题绝对不能出错这个功能的优先级有多高这些问题问得越清楚AI 生成的初稿质量越高。这部分能力不是“想象力”三个字能概括的而是把模糊想象变为精确需求的过程。4.4 领域知识的权重在上升AI 模型懂很多通用编程知识但深度领域知识仍然稀缺。金融、医疗、制造业、供应链、教育等领域里真正有价值的不是代码逻辑而是业务流程和行业规则。比如你写一个医疗数据脱敏工具代码层面并不复杂但你要知道哪些字段属于敏感字段、脱敏规则是什么、保留几位字符、是否需要关联主键一致。这些知识 AI 不知道你需要在提示词里输入或者自己写判断逻辑。这给开发者的建议是不要只盯着新技术多积累你所在行业的业务流程、合规要求、数据规范。未来代码生产是流水线领域知识才是你产出高价值输出的护城河。5. 开发者到底该怎么调整学习重点5.1 新手基础不能丢但要先学会用 AI 加速学习很多新手会用 AI 写作业代码、复现算法这是好事但要避免一个陷阱只知道结果不知道过程。比如你要写一个快速排序AI 直接给出代码。如果你只是复制粘贴那你什么也没学会。更好的做法是先让 AI 生成代码自己逐行解释每一行在做什么手动模拟一个短数组的排序过程再尝试不参考 AI 写一遍最后让 AI 对两版代码做对比分析这样 AI 变成了教练而不是代写。对于“c语言文件读写操作代码”“python 爱心代码”“快速排序代码”这类搜索需求更应该把重点放在理解原理而不只是拿到现成代码。基础数据结构和算法、编程语言核心语法、调试工具、版本管理这些该学还是要学。它们是判断 AI 输出正确性的地基。5.2 中级开发者转向架构、测试和代码评审对于已经能独立完成模块开发的开发者现在的重点应该从“怎么写”转向“怎么保证质量”。可以主动练习这些技能画模块交互图、数据流图训练系统设计能力写覆盖关键路径和边界情况的单元测试做代码评审重点看 AI 生成部分的逻辑缺陷熟练使用静态扫描工具、格式化工具、依赖检查工具学习重构技巧知道怎么把 AI 生成的大函数拆小这些技能才是中级开发者拉开差距的地方。过去你可能因为打字快、框架熟而显得厉害现在这些优势被 AI 抹平了。剩下的优势是你能不能把一个模块设计得稳定、可扩展、可测试。5.3 资深开发者和架构师多做决策少做实现资深开发者的价值应该进一步向上移。架构选型、技术标准制定、模块边界划分、技术债治理、团队规范建设这些工作 AI 很难替代。架构决策需要考虑的是长期成本、团队技术熟悉度、系统演进空间、运维复杂度。这些判断依赖丰富经验不是靠一次代码生成能解决的。另外资深开发者还应该承担一个角色把 AI 编程工具在团队里的用法标准化。比如定义统一的提示词模板建立 AI 生成代码的审查清单约定哪些模块不允许直接使用生成代码。这些规范直接影响团队效率和稳定性。5.4 非技术角色把代码当表达能力如果你是产品经理、运营、数据分析师看到“代码免费”这句话不应该无感。它意味着解决一些实际问题时你也多了一个工具。比如你经常要整理数据表格过去求着开发帮忙写脚本现在完全可以自己描述需求让 AI 生成脚本然后把脚本交给开发审查。再比如你要做一个数据报表可以让 AI 辅助 SQL 查询再让开发确认性能和权限。当然这里有个边界你不应该把 AI 生成的生产代码直接部署到正式环境除非有技术负责人审核。但用 AI 解决个人分析类、临时性、非关键任务已经是非常现实的选择。6. 团队落地 AI 编程时最该盯住的三件事6.1 建立 AI 协作规范而不是放任使用很多团队已经全员使用 AI 编码工具但没有规范。结果就是代码风格混乱、AI 生成代码无条件合入、错误率高、安全隐患多。我建议团队至少定义三件事哪些模块允许使用 AI 生成代码哪些模块必须人工编写AI 生成代码合入前必须经过哪些检查比如测试、静态扫描、安全扫描AI 提示词里涉及公司内部信息时要注意什么这个规范不用很长但要让每个人知道边界。比如“所有涉及支付、权限、数据导出的代码AI 初稿只能作为参考核心逻辑必须人工编写并评审”“所有生成代码合入前必须通过单测和代码评审两项门槛”。这样既能利用 AI 提升效率又能控制风险。6.2 不要只看生成速度要看全链路指标团队引入 AI 编程工具后很容易把“代码生成快”当成核心指标。但真正需要关注的指标是这些表格关注指标判断方式代码接受率AI 生成代码被直接使用或微调后使用的比例返工率生成代码上线前被发现问题的比例测试覆盖率AI 相关代码是否有对应测试覆盖平均交付周期从需求确认到合并或者上线的耗时线上故障数生成代码引入的生产事故数量代码审查耗时审查 AI 代码是否比人工代码花费更多时间如果只看生成速度团队可能陷入一种假象需求很多、代码很多但上线稳定性和可维护性都在下降。我见过一个团队让 AI 重构了一个核心模块一天完成三天后因为一个边界条件导致任务队列阻塞。原因就是只看了生成速度没有看边界条件和回归测试。6.3 给团队留“不借助 AI 写代码”的时间这一点可能看起来反直觉但很重要。如果开发人员长期只做“写提示词、复制粘贴、改报错”编程基本功会退化。特别是年轻开发者长期不手写代码对指针、递归、并发控制、内存管理的理解会变得非常脆弱。我的建议是日常开发可以用 AI 提效但每个迭代至少留一段时间让开发者手写核心算法、纯手写模块或做一轮无 AI 辅助的代码练习。这些时间不是浪费而是维持团队判断力底线的必要投入。也可以周期性组织代码审查会让重点审查 AI 生成代码中的技巧问题。团队在讨论中互相提高对 AI 输出质量的判断能力。7. 面对“代码免费”的现实我的个人建议先说几个实际建议都是我自己在项目里验证过、觉得可以复用的。第一从最小样例开始。不管提示词写得多么详细AI 第一次生成的代码很可能有偏差。先拿 2 到 3 组简单数据跑通再扩展到完整数据集或批量任务。这样可以避免一个文件就暴露问题后边全部返工。第二不要一上来就开最大并发。AI 可以生成高并发代码示例但你的机器、带宽、数据库连接数、第三方接口限流不一定支持。实际生产使用前先用并发 1、并发 5、并发 20 做阶梯测试确定安全边界。第三把每次有效的提示词沉淀下来。一个团队可以维护一个提示词库把需求描述、上下文背景、约束条件和验收标准写清楚。下次遇到类似需求直接复用能大幅提升一致性。第四学会向 AI 提问“还有什么我没考虑到”。生成代码后可以让 AI 列出可能遗漏的边界条件、失败场景、安全风险和性能隐患。这个提问往往会暴露不少有价值的信息。第五所有关键模块保留人工审查环节。AI 是一个放大器需求清晰时放大效率需求模糊时放大混乱。人工审查是问题的最后一道闸门无论如何不能省。最后再说回开头那句话。代码从稀缺变免费真正稀缺的确实不再是在编辑器里敲出语法正确的代码。但“想象力”在这个语境里不是一句鸡汤而是更具体的能力把模糊的业务问题定义成清晰的输入输出、约束条件和验收标准在 AI 生成的众多方案里做判断和取舍在系统边界处识别风险。这些能力没法一键生成需要长期在真实项目里磨。代码免费的时代对开发者来说不是终点而是能力模型重置的起点。早点把注意力从“怎么写代码”转移到“怎么定义问题、验证结果、控制风险”上可能是当下最值得做的一次转型。