夜雨聆风当所有人都在讨论 AI 能写多好的代码时
真正的问题其实是：你还要不要自己写代码？
01 / 一个反直觉的要求
上月内部架构分享会上，我跟团队提了一个要求： 一行手写代码都不要写。 不是为了偷懒。恰恰相反——是因为当你手写代码的时候，你会被惯性思维带着走。你用的Java，就按Java的范式来；你熟悉React，所有问题都长成组件的样子。
但AI不关心你用什么框架。它关心的是：你到底想做什么。
所以与其把精力花在写代码上，不如把时间花在想清楚逻辑上。AI是一个极其优秀的打手，但它没有判断力。方向对不对，只能靠人。否则他就只会乱打
02 / 代码写少了，但效率反而高了
团队用AI编程一个月后的真实反馈很一致：
"代码确实写少了很多" "效率提升特别大" "但有时候 AI 会进入死循环，还是需要人盯着"
有同事提到一个关键点：有些问题不是代码的问题，而是环境的问题。 比APP的开发，手机和电脑环境差异导致的bug，AI定位不准，还是得靠经验判断。
这恰恰说明了一件事——AI解决的是"怎么写"的问题，但"写什么"和"为什么写"始终是人的事。
解放出来的时间，不是用来摸鱼的，而是用来思考业务本身。以前一个开发者90%的时间在写代码，只有10%在想业务。现在反过来，你有了真正理解业务的时间。
03 / 整个团队没有一个"写代码的"
这是我跟团队说的原话： "我们这边没有写代码的，我们这边都是架构师。" 听起来像吹牛，但逻辑是这样的——当你背后有Claude Code、有Codex、有GLM 在 7×24 小时待命，你本质上就是带着一支千军万马在干活。你不是一个人在写代码，你是一个人在指挥很多个Agent在执行。 那你的角色就变了。你不再是「Python工程师」或者「前端开发」，你是项目的架构师和指挥官。
你要做的事情是：
梳理业务对象和实体关系 定义用户故事和验收标准 给 AI 下达任务书并 review 方案 在 AI 跑偏的时候把它拉回来
这些事情，过去是Tech Lead、架构师、产品经理三个人干的。现在，一个会用AI的开发者就能搞定。
04 / AI写代码最怕什么？不是bug，是跑偏
分享会上讲了一个真实的教训。
有同事拿到一个需求，直接让AI开干。结果上线之后发现——AI理解的目标跟业务实际需要的东西，根本不是一回事。代码写得没问题，功能也跑得通，但方向错了。
这就是我为什么反复强调：不要急于让AI写代码。
我的做法是给Agent定了一条契约：在我开口之前，你一行代码都不能写。 先把目标捋清楚，把方案过一轮，把风险列出来，确认没问题了，再动手。
这跟传统团队做方案评审是一样的流程——只是对手从"同事"变成了"AI"。
一轮一轮对齐目标、纠偏方案、确认边界。看起来慢，实际上是最快的。因为方向对了，执行只是时间问题。
05 / 最重要的事：把数据模型想清楚
如果整个分享只记住一句话，那就是：
数据模型是项目中最底层、最核心、最不变的东西。
为什么要先做数据架构设计？ 因为不管你用什么语言、什么框架、什么技术栈，业务实体和实体之间的关系是最稳定的。一个电商系统里，"用户""订单""商品"这三个对象不会因为技术选型而改变。变化的只是它们上面多了几个字段、多了一层关联关系。 反过来，如果数据模型没想清楚就开工，后果是什么？
前后端分别让 AI 开发，结果两边的业务抽象完全不同 数据库结构对不上，接口字段对不上 集成的时候发现两套完全不同的业务逻辑 回过头来洗数据，比从头做还痛苦
AI不理解你的业务目标。TA不是业务肚子里的蛔虫。 它会根据你给的设计稿去猜数据库结构——但猜出来的东西，大概率不是你想要的。
所以数据架构这件事，绝对不能交给AI做。它必须由理解业务的人来完成。你可以让AI辅助你梳理、帮你画图，但最终的抽象和判断，一定是人做的。
06 / 全栈 > 前后端分工？
分享会上讨论了一个很实际的问题：AI时代要不要分前后端？
我的答案：现阶段不分。
一个业务领域，就是一个开发组。一个人负责一个用户故事（User Story）的全栈交付。
为什么？因为如果前后端分给不同的人（或者不同的AI），最大的风险就是业务抽象不一致。前端按UI稿理解需求，后端按接口文档理解需求，两边各干各的，最后拼不上。
但如果一个人从头到尾负责一个用户故事，他就必须先把业务对象想清楚，再去做前后端——底层数据模型是统一的，怎么跑都不会偏太远。
当然，前端有统一的UI规范、后端有统一的技术栈约束，这些"基础架构"层面的事情需要有人统管。但业务开发层面，一个人一个故事，全栈交付。
07 / 和AI协作的真实工作流
不是"说一句话，代码就出来了"那么简单。一个完整的AI协作开发流程大概是：
第一步：需求梳理 跟业务方对齐需求，同时跟AI共创，让它帮你把碎片化的想法组织成结构化的用户故事。
第二步：架构设计 抽象业务实体、画实体关系图、设计数据模型。这一步人主导，AI辅助。
第三步：方案评审 把架构方案丢给另一个AI（相当于"蓝军"），让它从架构师视角帮你挑毛病、找盲点。
第四步：下达任务书 方案确认后，写清楚目标、边界、验收标准，把任务书下给AI执行。
第五步：开发执行 AI 写代码，人review。每个阶段写Handoff文件，确保上下文不丢失。
第六步：测试上线 AI 做冒烟测试、回归测试，人做最终验收。上线公告、使用说明书也由AI基于Handoff文件自动生成。
整个过程，人做的最多的事是：思考、判断、纠偏。 写代码这种事，真的可以交给AI。
08 / 几个踩坑经验
Handoff文件一定要写。 靠AI自己的记忆机制是不可靠的。每一步都让它写交接文档，后面复盘、发布、写说明书都省事。 给AI设纪律。 比如"不写代码除非我授权""不能自由发挥技术栈"。 用低能力模型做交叉检查。 你的方案做完之后，丢给一个能力稍弱的模型让它从架构师视角挑毛病，效果出奇的好——因为它不会被炫技迷惑，只关注逻辑漏洞。 前端组件加编码系统。 给每个UI元素打标签，这样跟AI说"改这里"的时候它不会改错地方。 AI容易掉进细节里炫技。 你要时不时把它拉回目标层面。
09 / 此处有总结
谋定而后动。
代码是工具，AI是工具，技术栈也是工具。真正决定项目成败的，从来不是你用什么工具，而是你对业务的理解深度。 进入AI时代，写代码的门槛越来越低，但做架构的门槛一点都没降。反而因为AI执行力太强，如果你方向没想清楚，它帮你跑得越快，偏得越远。
所以我的建议是：
别急着写代码。先想清楚你的业务对象是什么，它们之间的关系是什么，你要达成的目标是什么。 想清楚了，剩下的，AI 帮你干。
本文基于大唐架构分享会实录整理，内容经过脱敏和结构化处理。
