最近Django创始人Willison的一句话在开发者圈子里讨论度很高AI让代码不值钱了。第一次看到这句话我先是心里一紧随即又觉得他说得克制而且准确——代码的生成成本正在被AI打到地板价但软件工程里真正重要的那部分能力正在以前所未有的速度升值。今天想结合我用AI辅助做Django项目的真实经历聊聊为什么我们更需要重建工作习惯以及我自己摸索出来的AI时代最佳实践。这篇文章不是转述更不是贩卖焦虑而是想给正在用AI写代码、又担心自己越来越像“只会复制粘贴的搬运工”的同学一个可以照着调整的参考。1. 先搞清楚为什么代码会“不值钱”1.1 生成一条代码的边际成本已经低到可以忽略早几年一个功能从需求到落地最花时间的环节就是把逻辑翻译成语法。举个例子在Django里写一个带权限校验的删除接口熟练的人也要折腾大半个小时建模型、写序列化器、定义视图、配路由、处理异常。现在把这些需求扔给AI它几秒钟就能生成一个能跑的初版甚至还会主动帮你加上注释、错误处理和简单的测试。这种变化是肉眼可见的也直接导致一个残酷的结果单纯“把需求写成代码”的工作市场定价正在快速下跌。我并不是说这类工作没有价值。能跑通的基础代码当然有价值但它正在从“定制服务”变成“标准商品”。用印刷术来类比可能更直观印刷术普及之前字写得又快又工整是一门值钱的手艺印刷术普及之后写得快、写得工整不再稀缺值钱的是内容质量、编排逻辑和审美判断。AI就是今天软件行业的印刷术它把“写字”这个环节变得极其便宜于是“字本身”就不值钱了。但注意代码生成成本降低不代表软件交付成本降低。AI生成的代码顶多算毛坯房你还是要验证业务逻辑、处理边界情况、做安全防护、跑测试、部署、监控线上。这些环节的复杂度没有消失反而因为代码量暴增而变得更不可忽视。很多团队发现引入AI之后功能开发速度确实快了但代码review时间变长了线上问题反而更难定位了。原因很简单AI可以一秒生产一千行代码但它没法一秒内告诉你这行代码在你们项目里为什么是错的。1.2 真正不值钱的是“只要给我需求就能写出来”的那部分如果我们诚实面对自己就会发现过去很多工作确实是套路化的。写一个增删改查接口查一张表映射到前端页面处理一下分页这类事情在垂直行业里重复了无数遍AI学得比人快、写得比人标准。如果一个开发者长期只做这些那么AI确实在让他贬值因为他的核心技能可以被模型低成本替代。但项目真正的难点从来不在这些表面动作。数据一致性怎么保证权限边界在哪里删除一个对象之后关联数据该级联还是该置空订单状态流转到一半失败怎么办这个字段加了索引之后写入性能会不会下降这些问题才是绝大部分软件项目里的“隐形工程量”而它们恰恰是AI很难从一两句提示词里替你判断的。所以“代码不值钱”不如理解成“搬运逻辑不值钱做决策更值钱”。以前你花一天写8个小时的代码其中6个小时在搬运2个小时在决策AI出现之后搬运的6个小时被压缩成5分钟但你仍然需要花至少2个小时做决策而且还多了一个新的任务审查AI搬运过来的逻辑是否符合你的决策。那些只会搬运、没有决策能力的人自然会焦虑而那些决策能力强的人相当于手里突然多了一堆免费劳动力效率被放大了数倍。2. AI时代正在疯狂升值的能力2.1 判断力敢不敢采纳敢不敢拒绝AI最擅长的是给你一个“看起来合理”的答案。它不会告诉你这个答案和你当前项目的技术栈、业务阶段、团队水平是否匹配。你问它“怎么写一个删除接口”它可能会推荐最主流的硬删除干净利落但如果你们业务要求保留操作痕迹需要软删除甚至需要状态机流转这时候最关键的动作就不是“写代码”而是“判断这个方案不能直接用”。我见过不少人拿到AI生成的代码后连看都不看就粘贴进项目理由是“它能跑就行”。但“能跑”和“该这么写”是两码事。比如AI生成Django的ORM删除逻辑时可能会直接调用Model.delete()这在没有外键约束、没有审计需求的小Demo里没问题一旦上了生产遇到开单、审核、对账这类流程硬删除几乎等于自毁后路。代码写错可以改数据删错了没法用代码找回。这种判断力就是上面说的“决策能力”它正在变成最稀缺的东西。判断力还可以再往下拆你要判断AI的建议在架构层面是否合理判断它的技术选型是否适合团队维护判断它给出的代码有没有引入不必要的复杂度判断什么时候该手写而不是用AI。这些判断没有快捷键只能靠你对自己项目的理解来支撑。AI能给你一百个答案但“哪一个答案配得上你当前的项目”只有你能回答。2.2 调试与推理从“写代码的人”变成“破案的人”代码生成越容易线上问题就越有迷惑性。因为你看到的代码未必是你自己写的它里面藏着AI自己的假设。举个例子在Django里执行查询后删除对象明明obj.delete()调用成功了数据库里记录却还在。这种问题怎么查先看模型有没有重写delete方法再看有没有软删除基类再查有没有信号拦截还要看事务有没有提交。AI可以秒答“ORM删除对象的语法”但它不知道你的模型里挂了哪些signal、用了什么自定义QuerySet、中间件有没有副作用。所以调试能力在升值而且升值得非常厉害。以前写代码的人天然更懂自己代码里每个分支的来历出错时能通过直觉快速定位现在AI生成的代码里你只是在审查一篇由陌生作者写的稿子出问题时你既没有完整上下文也没有作者的思维过程只能靠系统性的推理能力去还原现场。这个能力很像破案先收集线索报错信息、日志、SQL、数据快照再提出假设再逐步验证最后锁定根因。我现在的习惯是每次AI给我代码之后我都会刻意追问几个“为什么”为什么这里要这么写如果数据量翻十倍会怎样这个逻辑在什么情况下会失效有些问题AI会答得很好但有些问题需要我打开源码、翻历史提交、查数据库才能搞清楚。这个过程非常锻炼人也是最难被AI替代的部分。因为你要理解的对象不是一个孤立函数而是整个系统里所有模块之间的动态关系这种理解只能靠人脑慢慢建立。2.3 领域知识与业务建模AI对业务的理解来自互联网上海量的公开文本。但它训练数据里最多的内容是通用的、教科书式的场景而不是你们公司具体的业务规则。同样是“删除订单”电商系统的删除和财务系统的删除含义完全不同。电商可能允许用户取消订单然后从订单列表里消失财务系统里的订单删除必须留痕、必须走审批、必须有操作日志和审计字段。这些差别不是AI能从“删除订单”这四个字里猜出来的。因此能准确把模糊业务需求翻译成数据模型、状态流转、权限规则的人价值在急剧上升。这条路没法靠提示词外包。你得去和业务方聊天去翻历史代码看当时的约定去梳理异常流程用户删单了但支付回调已经进来了怎么办管理员恢复了已删除的评论原来的回复要不要一并恢复这些边界问题才是软件里真正的“代码”而表面的if else反而越来越便宜。对我来说Django项目里最典型的例子就是模型设计。AI能帮你生成一个看起来像模像样的模型但字段类型选得对不对、外键的on_delete行为合不合理、关联关系是OneToOne还是ForeignKey、是否需要unique_together约束所有这些都取决于你对业务场景的理解。业务建模能力本质上是一种翻译能力——把人的需求翻译成系统的约束。这个能力越强你越能驾驭AI而不是被AI带偏。2.4 复盘和沉淀习惯AI让写代码的门槛变低了但学习曲线没有消失。如果你每次都是“需求扔给AI代码复制进来”那你的技能增长会接近零。因为AI替你绕过了思考过程而思考过程恰恰是学习中最重要的部分。我自己有个强制性习惯每次让AI帮我解决一个问题后我会做一次简短的复盘。这次它为什么用这个方案它有没有给我挖坑如果换成我手写我会怎么设计这个坑要不要记进团队文档别小看这几分钟它决定了你是在“用AI”还是在“被AI用”。用AI是让AI干活你把成果吸收成能力被AI用是你负责复制粘贴AI负责思考最后除了代码量快速增长你什么都没留下。复盘沉淀下来的东西就是你的“最佳实践清单”。AI时代的最佳实践不可能是一成不变的教科书它更像每个人、每个团队动态更新的内部手册。今天我们一起踩到了N1查询的坑明天就把“AI生成ORM查询后必须检查SQL条数”写进清单今天发现AI默认用了最新版依赖导致老项目跑不起来明天就在对话一开始注明项目版本。这些事情不做了AI带来的效率红利很快就会被返工成本吃掉。3. 建立新习惯我如何在AI辅助开发Django项目里做最佳实践3.1 开始之前先写“验收清单”和“不做什么”我踩过最大的坑就是一开始太依赖AI“一步到位”。一句“帮我写个删除评论的接口”扔进去它确实能输出一整套代码但往往不是项目想要的。后来我改成在提问之前写一个简短的验收清单哪怕只是几句话效果也截然不同。举个例子我会这样描述需求用户删除自己的评论但管理员可以恢复不能物理删除要保留删除时间和删除人删除后这条评论在列表里不再出现但评论计数要同步减少这个版本不做管理员批量恢复。然后再让AI生成代码。这里最关键的是“不做什么”四个字它能帮AI避免很多脑补。AI很喜欢自作主张帮你加批量操作、加权限分组、加你不想要的字段先写清边界后面返工量会小很多。这份验收清单本质上就是工程里的需求边界。以前我们总觉得需求文档是项目经理的事但AI时代每个和AI协作的开发者都得具备把验收标准说清楚的能力。你说得越清楚AI的产出越能用审查成本越低。这不是AI带来的新负担而是以前被忽略的基本功现在被重新捡起来了。3.2 先要方案再要代码如果你直接跟AI说“给我代码”它大概率会给你最稳妥、最模板化的写法。但“最稳妥”不等于“最合适”。我现在会强制自己分两步走第一步让AI给出两到三种不同方案并说明取舍第二步自己根据项目情况选定方案后再让AI按选定方案写代码。比如在Django里实现软删除我会先问“有哪几种常见做法is_active字段、deleted_at字段、django-safedelete库各适合什么场景迁移成本和查询复杂度怎么样”拿到回答后我再结合项目是否已有历史数据、查询是否需要跨表过滤、团队是否愿意引入新依赖来做选择。这样AI写出来的代码是有决策依据的而不是随机生成。虽然这一步看起来多花了十分钟但能省掉后面几小时的返工。这一步背后有一个很重要的心态转变不要把自己当成AI的操作员而要当成AI的项目经理。你负责定方案、拆任务、验收成果AI负责实现具体细节。项目经理可以不懂每个API的底层源码但一定要懂为什么要选这个方案、不选那个方案。专业岗位里“做选择”永远比“执行”更有价值AI时代更是如此。3.3 把AI生成的代码当“同事的PR”来审很多人在看AI生成的代码时会自动放低标准觉得“AI写的应该没问题吧”。这个想法非常危险。AI生成的代码最好的情况是“看起来都对”但常常在权限、边界、异常处理等地方埋着雷。我把这类代码默认当成一个水平不错但不太熟悉项目上下文的同事提交的PR必须走一遍严格的代码审查。我的审查清单通常是这样的权限检查有没有做不能只依赖前端隐藏按钮后端必须做。输入校验有没有做Django有没有用Form或Serializer做字段校验查询有没有N1外键字段该select_related的地方有没有漏事务边界对不对多个写入操作是否包在transaction.atomic里了删除操作有没有考虑外键CASCADE、信号、审计日志异常有没有被静默吞掉有没有记录到日志里这个实现是否和项目已有代码风格、约定一致有时候我会直接在对话里把这份清单发给AI让它自查一遍效果也不错。但最终确认还得靠人。尤其像权限校验这种问题AI生成的代码里往往没有体现你对业务角色划分的理解。比如“用户只能删除自己的评论”AI可能只判断用户是否登录然后就把删除接口暴露出去。这种风险靠AI自己是意识不到的只能靠人审出来。3.4 小步提交快速验证以前我一个人改一个功能可能一口气改十几个文件本地跑通一次就算完事。现在和AI协作这个习惯必须改掉否则代码量一多出问题根本不知道该回滚到哪一步。我现在的节奏是把功能切成很小的块每完成一块就跑一次验证确认没问题再提交。比如用AI写一个Django的“删除评论”功能模块我会分这么几步先让AI生成模型迁移脚本跑makemigrations和migrate接着写最简视图手动带不同身份的token测一下权限再加入序列化器和业务逻辑跑几个单元测试最后补文档和注释合并进主分支。每一步都保持可回滚发现AI给的方案有坑直接回到上一个能通过的提交而不是在一大堆半成品里排除问题。这个习惯看起来降低效率实际是效率放大器。因为有了小步提交和测试用例后面再用AI做重构时会非常安心。比如让AI帮你把views.py重构成ViewSet只要测试覆盖率够高AI改完你直接跑一遍就知道有没有破坏原有逻辑。把工程里最耗时的“验证”环节自动化本质上就是在给AI这条高速路配好护栏跑得越快越需要护栏。4. 常见问题与排查技巧AI辅助Django开发实录4.1 查询“能跑”但页面慢到怀疑人生这是我在AI辅助开发中遇到最多的问题。现象很统一功能一切正常但列表页数据量只有几千条响应时间却超过5秒。用Django Debug Toolbar一看一个列表页发出了几十上百条SQL。原因基本就是经典的N1查询问题。AI生成的ORM查询往往只保证逻辑正确不关心真实数据量下的性能。它只知道用Comment.objects.filter(...)能查出来但不会主动帮你加select_related和prefetch_related。解决起来也不难。先用django-debug-toolbar或django-silk观察SQL条数再检查模型之间的外键、多对多关系是不是在循环里被一次次访问最后在查询中加上select_related处理外键prefetch_related处理多对多和反向关联并再次观察SQL条数是否降到常量级。还有一个小技巧用 print(queryset.query) 看生成的SQL能很快发现是不是多查了几张表。我的经验是凡是AI生成的查询类代码都要默认怀疑它有N1必须做一次“查询体检”再上线。4.2 删除对象时出现“幽灵数据”另一个高频问题调用obj.delete()后代码里也显示成功了但某些查询里这个对象依然存在。一开始我也很困惑后来排查才发现原因很杂。有可能是模型继承了某个软删除基类delete()被重写成了只标记deleted_at有可能是自定义Manager里只过滤了is_activeTrue但你的查询没走这个Manager还有可能是有个signal在delete过程中return了False把操作拦下来了。这种问题的排查思路是按证据倒推。先确认调用的是模型默认的delete还是被重写过的方法再查模型基类和Manager再查相关apps的signals最后看数据库里这条记录的deleted_at或is_active字段到底是什么值。Django里删除动作并不像表面看起来那么“直接”外键on_delete、信号、中间表、批量删除的query set行为都可能影响最终结果。避免这种“幽灵数据”的最好办法是给项目规定一个统一的删除入口比如封装一个service函数所有删除都走同一个函数函数内部显式处理软删、硬删、信号和审计日志。这样AI只能按你的入口来不会自己发挥出另一条野路子。4.3 AI生成的依赖与当前Django版本不兼容这是很多人忽略但非常烦人的问题。AI的训练数据里最新版本的Django、Python占的比例大所以在生成代码时它经常会默认你用的是Django 5.0甚至引用一些老项目里根本没装过的第三方包。如果你在一个Django 3.2 Python 3.9的项目里工作直接复制AI的依赖推荐很容易出现版本冲突。我的办法是在提问之前就把技术栈版本写死在上下文里例如“当前项目是Django 4.2 Python 3.11不要尝试升级依赖尽量用Django自带能力实现”。这样AI就不太会给出需要新增第三方包的方案。同时必须坚持依赖锁定无论用的是requirements.txt还是pyproject.tomlAI给出的pip install命令都要先经过审查确认兼容性再执行。这里还有一个暗坑AI可能会建议你升级某个包来解决问题但在老项目里升级一个包往往会牵动一堆间接依赖风险很大。除非有测试覆盖否则不要轻易尝试大版本升级。4.4 怎样避免“AI最佳实践”毁掉你项目的约定AI最喜欢的写法往往是GitHub上最常见、文档里最标准的写法。但每个项目都有自己内部的“气质”比如团队约定所有外键都要加related_name数据库时间统一存UTC所有删除逻辑必须走软删除所有对外接口必须由序列化器统一输出格式。如果这些约定没有让AI知道它大概率会给出一个规范但不合群的实现轻则增加review成本重则埋下维护隐患。解决这个问题的思路是给AI配一份“项目上下文”。我在团队里把约定摘要成一段很短的提示文本每次和AI对话时直接粘贴在最前面里面包括技术栈、目录结构、编码规范、常用模式。如果团队文档里有CONTRIBUTING.md或专门的架构决策记录也可以直接把关键条目复制给AI。这不是一劳永逸的配置而是像给新同事做入职介绍一样每次会话重来一遍。你也可以把这份上下文留在项目docs/ai-guidelines.md里随时更新方便所有人都能使用同一个“AI入职手册”。我自己的体会是代码不值钱不等于程序员不值钱而是“只写代码的程序员”正在快速贬值。你愿意花多少时间在判断、验证、复盘上决定了AI对你的作用是放大器还是替代者。我刚开始用AI辅助Django开发时也踩过不少坑后来慢慢养成先写验收清单、先要方案、审查PR、小步提交的习惯整体效率才真正提上来。如果你也正在摸索AI时代的最佳实践我的建议很简单每一次让AI写代码之前先问自己如果这段代码出问题我能不能在半小时内定位如果不能说明你对它的理解还不够不要急着让它跑起来。建立新的习惯比多写十段代码更重要。
