最近我的一个 Django 项目在做订单状态机重构我把需求丢给 AI三分钟不到它就把模型、序列化器、视图和迁移文件全部生成出来了甚至附带了一整套测试目录。代码整整齐齐注释也像模像样。可我盯着这段输出脑子里突然冒出 Django 创始人 Simon Willison 最近说的那句话AI 让代码不值钱了。这句话在社区里被疯转刺痛感来自两个方向。还没学会 AI 工具的人觉得自己要失业已经把 AI 用得很熟的人也开始心虚——如果人人都能用 AI 产出这段 Django 代码那我过去十年靠写 ORM、写视图、配路由建立起来的本事还剩下什么Willison 在里面还补了一句更扎心的话整个行业都还在摸索新的最佳实践他自己也在摸索。但他给了一个非常明确的方向我觉得那个方向才是这篇文章真正值钱的地方。结合我自己在 Django 项目里大量使用 AI 的实战经验今天把这些思考完整整理出来。这篇东西不聊工具参数也不聊华丽架构只聊一个核心问题代码开始不值钱之后到底什么东西正在疯狂升值以及我们该怎么建立新习惯接住这波变化。1. 代码贬值是个事实但要先搞清楚贬值的到底是什么1.1 从 Django 的世界里看“代码不值钱”在 Django 生态里最先被 AI 击穿的就是过去最基础的“攒代码”工作。写 Models、配 URL、套模板、生成 Serializer这些活儿对于大语言模型来说毫无难度。你只要给出足够清晰的字段描述它甚至能把class Order(models.Model)写到比你预期还完整自动加好__str__、Meta、外键关联和索引建议。这件事在五年前是需要专门雇一个初级开发做一整天的。现在呢用聊天窗口搞定平均五分钟。如果你把代码定义成“把需求变成能跑的程序”那代码确实在飞速贬值而且贬的不只是 Django 的代码是所有常见框架的样板代码。但这个贬值和大多数人的直觉不一样。我做了一个很有意思的实验同一个订单模块我让 AI 单独写和让一个三年经验的开发写两个方案放一起对比。AI 的版本完成速度是人的五十倍代码规范程度甚至略高。但当我追问一个场景——“用户下单后支付超时订单要自动取消但如果取消那一刻用户刚好在付款页点了支付怎么办”——AI 给出的答案开始含糊那个三年经验的开发却能根据业务日志、既有状态位和公司的容错策略直接给出机器人能落地的判断路径。问题根本不是出在 AI 身上问题出在“代码”这个词被定义得太窄了。代码不只是save()和filter()代码是一整套决策的凝固产物。决策值钱凝固这个动作正在变得非常便宜。1.2 代码贬值其实是技术民主化的必经之路如果你了解 Django 诞生之初的思想你就会发现“让代码不值钱”这件事Django 自己早就干了十几年。Django 的核心哲学之一是 DRY是“约定优于配置”。为什么要有这种东西因为模板代码、配置代码、重复代码本身就是一种浪费框架的设计者想要消灭它们。当年 Django 帮我们消灭的配置样板和今天 AI 帮我们消灭的代码样板本质上是同一股力量。高级语言让汇编代码贬值编译器让手写机器码贬值全栈框架让重复造轮子贬值现在 AI 让“把熟悉需求写成熟悉代码”这件事贬值。技术演进的方向从来都是让“执行”更便宜让“决策”更值钱。谁要是觉得应用框架就是为了让程序员显得更厉害那他就理解错了框架存在的意义。所以我的第一个建议是不要用愤怒对抗趋势也不要用神秘感守护自己的工作。代码贬值是产业进化的必然结果。真正的开发者应当欢迎代码贬值——因为只有当没人稀罕“写代码”这件事本身时大家才会被迫去思考代码背后的系统和业务那才是真正拉开差距的战场。1.3 别把“代码不值钱”误读成“程序员不值钱”在 Django 项目里最经典的问题是 N1 查询。AI 能给你写出select_related和prefetch_related它甚至知道哪张表该用哪一种。可它不知道的是你们的数据库是 PostgreSQL 还是 MySQL当前流量峰值在哪个时间段查询结果集到底有多大这条路径是不是会在循环里被调用几十次。AI 能写出“语法正确”的代码但它很难判断“在当前运行环境下这样做到底对不对”。程序员真正的价值恰恰在这个“对不对”里。需求方一句“把用户等级接口暴露出去推广要用”你需要判断这不只是一个is_vip字段的事情它涉及权限边界、缓存失效、数据一致性、运营取数口径。AI 会照着字面意思执行程序员会对着真实世界执行。代码生成得越快这种“对着真实世界执行”的判断力就越稀缺。代码不值钱值钱的是那个知道“这代码不能在当前场景里那么写”的人。2. 正在升值的东西判断力、领域知识和验收意识2.1 问题定义能力取代“出活能力”AI 时代最稀缺的能力不是把活干完而是把活定义清楚。我给你举一个我在实际项目中遇到的例子。运营提了个需求“给用户加个 VIP 标签方便筛选。”这句话丢给 AI它大概率会给你生成一个is_vip models.BooleanField(defaultFalse)然后完事。但你稍微多想几步问题全出来了。VIP 是全局生效还是店铺级生效免费用户和付费用户的 VIP 状态是不是同一套VIP 到期之后历史订单里的快照还要不要保留这个标签如果人工客服给用户标记了 VIP 权限这个标签和支付系统的 VIP 逻辑冲突时听谁的这些需求细节AI 不会主动问你你问它它不一定能给全。能问出这些问题能把模糊的运营语言翻译成机器能验证的规则这才是 AI 时代工程项目里的核心能力。我以前管这种能力叫“需求分析”现在我更愿意叫它“问题定义”——因为它的本质是在给 AI 划边界是在替系统做取舍。你越会定义问题AI 输出的东西就越能直接用。你的问题定义能力越差AI 就只能在细枝末节上给你变魔术看似什么都会实际什么都不敢交付。2.2 领域知识是 AI 提示词的“长期记忆”关于 AI 生成 Django 代码这件事很多人有个误区觉得只要提示词写得好代码质量就高。提示词确实重要但再好的提示词也只是短期记忆真正决定输出质量的是你喂给它的领域知识。举例子。你告诉 AI “请实现一个订单取消接口”它能写一个中庸的cancel_order方法。但如果你在提示词里补充“订单具有状态幂等性已完成的订单不能取消取消后需要释放库存如果支付已经成功需要生成退款单退款单创建与订单取消必须处于同一数据库事务库存释放和退款单创建失败时要能整体回滚。” 你看这个时候 AI 输出的代码水平完全不一样了。这些约束从哪里来从你对 Django 事务机制的理解来从你对公司业务规则的理解来从你踩过的坑里来。领域知识不会自动进入 AI 的上下文但只要你系统性地组织它、灌输它AI 就能把这些知识转化成合格的代码。反过来那些不愿意积累领域知识的人就只能写点泛泛而谈的 CRUD然后抱怨 AI 也不过如此。我把这个习惯叫做“写领域规则卡”。每次面对一个复杂模块我先不急着让 AI 写代码而是花时间整理一页规则卡什么状态允许什么操作什么操作会对哪些数据产生副作用哪些边界情况已经明确不处理。把这些内容贴在对话开头再让 AI 动手。这套流程跑顺之后我的 AI 协作效率提升了至少两倍。2.3 验证和验收意识从“能跑”到“做对了”AI 生成代码之后最大的坑不是代码跑不起来而是代码看起来全对实际上逻辑漏洞百出。Django 项目里最常见的一种假象是测试全绿但测试本身就是错的。AI 很擅长生成自我安慰式的测试。它会根据你给的需求生成test_order_cancel_success测试路径也覆盖到了“取消成功”和“重复取消抛错”。但如果你仔细看它可能没测“支付成功后取消时退款单是否创建”也可能没测“库存释放失败时整个事务是否会回滚”。因为这些问题来源于领域知识而领域知识在提示词里缺失了AI 自然会觉得“测过成功和失败两种情况”就是完整覆盖。这就引出一个关键词验收意识。AI 时代每个人都必须成为代码的验收方。你不能看到 AI 写了测试就觉得万事大吉你必须问自己三个问题测试断言的是我的真实目标吗它覆盖了我最担心的边界条件吗如果这个测试全绿我真的敢让它上线吗我也不是说非要把 AI 写的测试推翻重来。我的做法是把 AI 生成的测试当作“第一版草稿”然后我会刻意补充三个领域相关的边界测试比如“用户权限不足时是否被拒绝”“极端并发下状态是否错乱”“外部接口超时时业务是否回滚”。经历过几次线上事故你就明白这三个追问比代码本身值钱得多。3. 建立新习惯比更新工具更迫切我践行的六个习惯3.1 每次 AI 会话都必须先写“验收头”受 Willison 那篇文章的启发我现在给所有 AI 对话立了一条规矩正式开始之前先写一段“验收头”。验收头包含三件事我要解决什么问题、成功的标准是什么、失败的表现是什么。比如我在处理一个 Django 线上 Bug 时会这样写要解决后台导出订单报表时超时。成功标准100 万订单量级的导出控制在 30 秒内内存占用不超 500MB。失败表现导出期间数据库主库 CPU 跑满或者导出文件用户打开时报格式错。这段验收头不是为了讨好 AI是为了逼我自己把问题想清楚。很多时候你写着写着自己就发现刚才想丢给 AI 的那个问题根本不是真问题。真问题是缓存策略而不是 SQL 写得不够快。这个习惯我连续用了三个月最大的收益不是 AI 回答变准了而是我自己的提问变精了。3.2 拆解习惯给 AI 分层不要让它一口气吃成胖子新手用 AI 最容易犯的错误是发一个笼统的大需求“帮我把这个系统的订单模块优化一遍。”AI 通常会给你一份看起来全面、实际全是空话的方案。我现在习惯把任务拆成三层。第一层是约束层把领域规则、参数边界、性能指标说清楚第二层是结构层让 AI 设计模型关系、接口定义、数据流走向第三层才是实现层让它填充具体的方法逻辑。每一层单独对话每一层都做验收。这个习惯的本质是把一个庞大系统分解成 AI 能理解的上下文块。Django 一个模块涉及 Models、Views、Serializers、URLs、Tasks、Signals如果全部塞进一个提示词里AI 的输出必然顾此失彼。拆开之后每一层的输入输出都是明确的我反而能控制整个过程。3.3 双重模型互查让 AI 扮演自己的代码评审AI 生成的代码存在一个系统性问题它对自己的输出有路径依赖哪怕这路径是错的它也会顺着圆回来。所以我养成了“双模型互查”的习惯。让两个不同模型分别开一个会话回答同一个技术问题然后把两份答案放在一起对比。如果两份答案在关键逻辑上一致那说明大概率没问题如果不一致我就仔细研究差异点反向挖掘自己可能遗漏的约束。这个技巧尤其适合高风险模块。我在做订单状态迁移、支付回调、权限升级这类功能时几乎一定会用双模型互查。成本是多花几分钟对话时间收益是提前发现 AI 在某个边界条件上“编造了一个看似合理的判断”。3.4 让 AI 解释代码而不是让它表演写代码这个习惯我推荐所有人立刻开始练。每次 AI 给出一段 Django 代码后我都会逼它逐行解释关键部分。不是让它说“这段代码执行了什么”而是让它回答“如果这里抛异常事务是回滚还是部分提交”“如果用户并发点击两次这段代码会触发什么状态变化”。如果 AI 回答得清楚这段代码大概率可以合并如果 AI 开始含糊其辞说“这是一种常见的防御性写法”那就要警觉了。它并不真正理解这段代码在当前场景下的行为。这个时候代码写得再漂亮也不是资产而是隐患。3.5 建立个人提示词库像管理代码一样管理提示词我在本地维护了一个提示词大全按场景分类Bug 复现模板、Django 安全审查模板、模型设计模板、迁移脚本生成模板、数据修复模板。每一个模板后面附一段说明记录这个提示词适合什么场景、在我们项目里踩过什么坑。这个习惯的启发来自 Django 的迁移系统——代码必须可追踪、可回滚。提示词也一样如果你每次都是从零开始跟 AI 对话那你的人机协作永远停留在新手村。把提示词版本化、标签化固定出一套你自己常用且顺手的工作模式才是真正的工程化做法。我甚至会把线上事故复盘写进提示词库的注释里下次遇到相似问题我直接把复盘内容发给 AI提醒它避开上次的坑。3.6 刻意保留不依赖 AI 的时间最后一个习惯可能有点反直觉我已经坚持每周安排半天时间完全关闭 AI 工具纯手写代码。目的不是为了证明自己还能写而是为了防止过度依赖。当 AI 把所有答案都变得唾手可得时人的判断力反而容易退化。定期关闭 AI 写一点新东西你会立刻感受到哪里已经生疏、哪些基础能力正在悄悄流失。这种“痛感”是好事它提醒你不是在掌握 AI而是被 AI 反向掌握。手写代码的那几个小时我的作用不是产出而是校准自己的判断力免得未来连 AI 给的代码对不对都看不出来。4. 最佳实践还处于混沌期但几个关键原则已经反复被验证4.1 别迷信万能 SOP用“人机交互轮数”量化效率Willison 说得非常诚实整个行业都在摸索新的最佳实践他自己也在摸索没有任何一套标准答案能适配所有团队。我是认同这个判断的。AI 编程工具进化得太快三个月前的 prompt 技巧可能已经过时去年总结出的工作流可能被新模型彻底颠覆。但我们不能因为没有标准答案就不做量化。我自己现在最常跟踪的指标是“人机交互轮数”从提出问题到最终达成验收标准的来回对话次数。三到五轮内能达到目标说明提示词叙事清晰、拆解合理如果超过十轮还在来回拉锯那大概率不是 AI 笨是我自己没有把问题定义好。这个指标帮我把模糊的感觉变成了可追踪的数据。以前我只觉得“这次用得不顺畅”现在我会去复盘到底哪个环节描述得不够把问题真正具象化。AI 时代的效率不取决于你写了多少行代码而取决于你在“和 AI 沟通”这件事上消耗了多少轮次。4.2 原则一护栏不是限制而是解放我在 AI 协作中最常做的事情不是让 AI 多干活而是给它划不许干活的边界。我在每一个 Django 项目的提示词库里都维护了一份“绝对禁止操作”清单。比如我会告诉 AI禁止在订单事务里混入第三方 HTTP 调用禁止为一时方便给用户模型加通用字段禁止在没明确要求的情况下使用bulk_create禁止通过disable_for_loaddata绕过信号机制。这些护栏不是限制 AI 的能力恰恰相反它们是在释放 AI 的能力。边界越清楚AI 在你给出的合法范围内越敢大胆发挥。有一次我忘了在提示词里加“禁止直接改用户表结构”AI 为了完成“新增用户标签”需求直接往User模型上加了五个字段导致全站数据库迁移计划变得极其复杂。从那以后我彻底明白了AI 时代给模型写“边界条件”就像开车前系安全带不是束缚是基本保护。4.3 原则二可撤销性永远优先于精致优雅AI 生成的代码往往看起来很完整但这种“完整”是虚假安全感。真正让我睡得着觉的不是 AI 代码写得有多优雅而是万一出问题我能不能迅速回滚到安全状态。所以我在使用 AI 做重构前有一套固定操作先把当前状态打一个干净的 git tag把数据库做一次 dump然后才开始让 AI 动手。Django migrations 有个很好的习惯就是每一步都是可记录的。我要求 AI 生成迁移后再拆成小粒度的多次提交而不是一次 commit 塞入十几文件。出了问题我就git revert数据出问题我就恢复备份重放迁移。你会发现所谓可撤销性其实就是工程里的“后悔药”。在 AI 时代这个后悔药比任何新潮技巧都重要因为 AI 犯错的方式往往不是运行时报错而是静默产生错误的结果。如果你没有可撤销的兜底等发现的时候往往已经太晚了。4.4 原则三人工代码评审不能省略但可以前置到“动手前”很多人觉得 AI 时代代码评审可以完全托管给 AI让它自己审自己。我试过结论是AI 确实能当第一道检查岗指出明显的代码风格问题、缺少类型标注、索引缺失。但它看不出“这个 Redis Key 的失效策略和缓存业务冲突”也看不出“这个视图函数被那个旧接口复用改了之后会影响运营报表”。所以我提出一个概念叫“前置评审”。在让 AI 动手之前我先写一段“上下文评审卡”包含这段代码会在什么环境运行、依赖哪些外部系统、有没有历史包袱、哪几个调用方会被影响。然后把这张卡发给 AI让它评审自己的实现方案。对比效果很明显。有上下文评审卡的 AI输出的代码明显避开了一些已知雷区没有上下文评审卡的 AI就像第一次入职的新人一样热情满满但总是撞上不该撞的坑。人在这个过程中不是变成了旁观者反而成了永远绕不开的最终责任人。 AI 可以帮你写代码但 AI 没法替你背锅。4.5 原则四把编码外包给 AI但把业务判断留给自己如果把这篇文章浓缩成一句话我会说在代码生产变成廉价商品的时代业务判断能力才是最稀缺的硬通货。AI 越会写代码你就越要把精力投向代码之外。它写代码你定义业务规则它实现接口你判断该不该开放它生成测试你补上边界的边界它把一切做得又快又好你负责回答最关键的那个问题“这项功能真的应该这么做吗”我经常在群里看到有人炫耀一段 AI 写出来的优雅代码说“整个模块我一个人全包了”。我觉得挺好但真正值得记录的成长应该是另一种叙述“我今天把一个模糊的业务诉求定义成一套 AI 能执行、测试能覆盖、线上可观测的规则。” 那才是代码价值转移之后新工程师能力的核心定义。我自己目前也在不断迭代这套工作流。千万别把任何一篇讲 AI 编程的文章当成终局答案包括这篇。但我建议你从今天开始做一个小改变下次用 AI 处理 Django 项目时不要直接说“帮我写一个订单模块”改成“帮我定义一个订单模块的成功验收标准然后我们再来动手”。你会发现当“写”这一步变得便宜之后前面那个“想清楚”的动作才是决定最终价值的关键。这件事现在做的人还不多所以它正在疯狂升值。