最近我的一个 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 项目里，最经典的问题是 N+1 查询。AI 能给你写出select_related和prefetch_related，它甚至知道哪张表该用哪一种。可它不知道的是：你们的数据库是 PostgreSQL 还是 MySQL，当前流量峰值在哪个时间段，查询结果集到底有多大，这条路径是不是会在循环里被调用几十次。
AI 能写出“语法正确”的代码，但它很难判断“在当前运行环境下，这样做到底对不对”。程序员真正的价值恰恰在这个“对不对”里。
需求方一句“把用户等级接口暴露出去，推广要用”，你需要判断这不只是一个is_vip字段的事情，它涉及权限边界、缓存失效、数据一致性、运营取数口径。AI 会照着字面意思执行，程序员会对着真实世界执行。代码生成得越快，这种“对着真实世界执行”的判断力就越稀缺。代码不值钱，值钱的是那个知道“这代码不能在当前场景里那么写”的人。
2. 正在升值的东西：判断力、领域知识和验收意识
2.1 问题定义能力取代“出活能力”
AI 时代最稀缺的能力不是把活干完，而是把活定义清楚。我给你举一个我在实际项目中遇到的例子。运营提了个需求：“给用户加个 VIP 标签，方便筛选。”这句话丢给 AI，它大概率会给你生成一个is_vip = models.BooleanField(default=False)，然后完事。
但你稍微多想几步，问题全出来了。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 项目时，不要直接说“帮我写一个订单模块”，改成“帮我定义一个订单模块的成功验收标准，然后我们再来动手”。
你会发现，当“写”这一步变得便宜之后，前面那个“想清楚”的动作，才是决定最终价值的关键。这件事现在做的人还不多，所以它正在疯狂升值。
