别再让AI重写你的整个代码库了, 快把主动权拿回来!

Mon, 20 Oct 2025 00:00:00 GMT

400美元的”灵魂拷问”

曾经, 为了追赶AI开发的潮流, 我豪掷200美元开通了Cursor的最高档订阅, 外加每月400刀的API额度。听上去很阔绰对吧?

结果呢?两周, 额度就光速见底。

后来我的写码时间, 得看API额度吃饭。你能想象吗?我本来是那种想写就写, 写到天荒地老的人, 结果每天像守着余额不足的银行卡一样, 反复刷新用量面板, 生怕哪天突然弹窗说”额度已用完, 请充值”。

可钱花了还不是最扎心的。最难受的是——原本设计得井井有条的代码, 被AI搅成了一锅大杂烩, 自己都快认不出来了。

你的好方案, AI一上手全乱了

想象下, 你精心设计了一套系统, 架构, 模式, 类型体系都规划清楚了。这不是随便玩玩, 而是要上线, 要扩展, 要真用户用的。

于是你把计划一五一十讲给LLM助手听, 信心满满地期待它来”锦上添花”。

结果, AI啪地甩你500行代码。

乍一看, 好像能跑?但细读下来:

Python类型注解都乱七八糟, 到处是裸dict, list, 你需要的是强类型啊兄弟!
数据传来传去全是原生JSON, 查个问题跟走迷宫似的
“关注点分离”是啥?AI直接一锅端, 所有逻辑全堆一个函数里
整个架构像被扔进搅拌机, 打成了”AI特调思慕雪”

你还不死心, 想着”没事, 我让它帮我修一下这些问题”。

然后——AI干脆全盘重写。

这回类型注解过于吹毛求疵, 17个helper函数你只用得上仨, 原本能跑的逻辑全没了, 换上了隐藏更深的bug。最可怕的是, 这20分钟内你已经经历了4次”推倒重来”, 连最初的代码长啥样都忘了。

你坐在电脑前, 内心OS: 我的方案呢?为什么我的方案没了?

相信我, 这种”心有余而力被AI毁”的感受, 绝对不是你一个人。很多开发者都因此差点把AI助手拉黑 (包括我) 。

真正的问题 (其实不是AI)

最后我想通了: LLM其实没啥写代码的毛病, 甚至很能干——前提是你给它画好范围, 说清楚规则。

问题在于, 我总让它”一上来就开工”。

你可以把AI想象成一个刚入职的新同事。你刚提个需求, 他转身就重写你整个认证系统, 连方案都不和你讨论一句。你会怎么做?当然是让他停下, 先聊聊思路, 评估下优劣, 看看和现有架构能不能兼容。

但用AI助手时, 我们常常跳过了这一步。问题一描述, AI立马coding, 连个设计讨论都省了。你们团队的约定?历史包袱?未来维护成本?AI统统不知道。

于是灾难开始:

A文件有个小小的架构瑕疵
B文件依赖A, 问题被放大
C文件又基于B, 表面能跑, 实际一碰就碎
你看着几千token生成的代码, 最后全得删了重写

拯救自己: 三步聊透, 最后才动手

折腾了几个月, API额度被榨干, 我终于琢磨出一条金科玉律, 简单得让人拍大腿:

先讨论, 后决策, 最后才动手。

简单说: 让LLM先跟你聊明白了解决方案, 没你点头, 谁也别乱改代码。

这其实就是三轮对话——三步走, 既能让你掌控全局, 又能让AI发挥长处。

第一步: “先认识一下我们家规矩”

第一轮对话, 重点不是解bug, 而是给LLM”入职培训”——让它搞清楚你项目的架构, 设计模式, 底层哲学。

我的惯用开场白:

需要你帮我优化代码, 关注类型注解和更优雅的实现方式。
我们采用迭代模式: 每个问题都先讨论, 敲定方案, 我说"可以上手了"你才能修改代码。
讨论期间禁止动代码, 必须明确允许才能操作。

下面是整个项目架构: @project_big_picture.md

当前任务: 先整体了解项目, 全局观有了再聊具体问题。

这里的”project_big_picture.md”就是你的”新同事入门手册”, 既有架构图, 也有设计理念, 还带文件结构和重点原则。

文档里该写啥?

就当你新招个同事第一天上班, 你会让他:

明白架构全貌: 模块怎么分层 (我常画点ASCII图)
了解常用设计模式: 比如”数据库操作都用repository”, “强调不可变数据”等
熟悉文件/目录作用: 每个文件负责啥, 模块间怎么协作
知晓设计哲学: 为什么要这么做
划清红线: 比如”必须类型严格”, “错误处理要显式”等等

举个栗子 (假设你也是个猫片控😺) :

## 核心架构

CatRater采用分层架构:

- API层 (FastAPI) → 负责HTTP, 校验, 序列化
- 服务层 → 业务逻辑, 评分算法
- 仓储层 → 所有数据库操作
- 模型层 → Pydantic模型, 强类型, 杜绝裸dict!

## 设计原则

1. 显式优于隐式: 所有数据结构都用Pydantic建模, 拒绝裸JSON
2. 关注点分离: 评分逻辑只在服务层, 数据库操作只在仓储层
3. 类型安全: Python 3.11+全量类型注解, mypy必须strict通过

## 文件结构

- `api/routes/cats.py` - 猫片上传与获取接口
- `services/rating_service.py` - 核心评分算法 (萌值, 胡须对称等)
- `repositories/cat_repository.py` - 猫片数据库操作
- `models/cat_models.py` - CatPhoto, RatingScore等模型

是的, 维护这份文档确实要花点心思, 但它能省下你每次都手把手”再讲一遍”的功夫。

为啥这招灵?

前置了项目全貌, LLM能有的放矢地读代码, 理解模块关系, 把握你最在乎的原则。最妙的是, 这个prompt只用写一次, 只要架构没大改, 能一直复用。

第二步: “遇到问题, 先聊聊你咋看?”

LLM有了全局观, 接下来才能讨论具体问题。

核心原则: 要”聊方案”, 而不是”直接让它上手”。

好的第二轮提问:

我发现猫片评分逻辑和数据库仓储层耦合太紧, 不连数据库就没法测。你能提几点重构建议, 怎么用依赖注入模式解耦?

不好的提问:

让猫片评分代码变得易测。

差别巨大吧?前者引导LLM参与讨论, 后者直接让AI”自作主张”动手。

这时, 进入”头脑风暴模式”, 你和AI来回碰撞:

LLM: “建议为仓储层抽接口, 通过依赖注入传给评分服务…”

你: “可以, 但评分缓存现在在仓储层, 你怎么看?”

LLM: “确实, 那可以把缓存提到服务层, 或者单独建个缓存层…”

这阶段你甚至可以问三, 五, 十个”what if”, 方案越扎实越好。

重点: 这一步绝不让AI动代码!

LLM成了你的架构顾问, 而非”码农”。它帮你权衡利弊, 预判风险, 给出多种可选方案, 而你始终把控大方向。

这一招极大降低了焦虑。你不会再眼睁睁看着AI瞎改一通, 最后不得不推倒重来。所有决定都是你俩”面基”聊出来的, 等思路清楚了才动手。

第三步: “OK, 咱们正式开工!”

等你们就解决方案达成一致, 权衡了所有权衡的东西, 这时候才可以下令:

这个方案可以, 咱们现在把它实现到代码里吧。

此时, LLM才开始写代码。

因为前面沟通充分, 最终实现会:

完全贴合你的架构
遵循团队一贯风格
类型, 异常全都合乎规范
解决原有问题且不制造新坑

最美妙的是, 你不用事无巨细地盯着AI写代码。变量名, import, 文件拆分这些杂事, AI全包了。

你定了方向, LLM负责落地。

完整开发回路长啥样?

实际用起来, 大致流程如下:

会话1:
├─ 第一步: "了解我的架构" (@project_big_picture.md)
├─ 第二步: "猫片评分和数据库耦合, 怎么重构?"
├─ 讨论: 4-5轮打磨方案
├─ 第三步: "可以上手了"
└─ AI实现

会话2:  (同样架构, 另一个问题)
├─ 第一步: "了解我的架构" (同一份@project_big_picture.md, 复用!)
├─ 第二步: "图片上传校验不一致, 有啥优化建议?"
├─ 讨论: 6轮
├─ 第三步: "动手吧"
└─ AI实现

会话3:  (架构有大改动)
├─ 实现过程中发现需要加缓存层
├─ 更新@project_big_picture.md记录新架构
└─ 下次会话用新版架构重新"入职"AI

什么时候要更新 project_big_picture.md?

遇到以下情况要及时更新:

新增了架构层级 (比如加了缓存层)
换了核心模式 (比如REST转GraphQL)
重构了关键抽象层

这些情况不需要更新:

修bug
基于既有模式的新功能
不影响公开接口的小幅重构

更新方式也可以交给AI:

根据我们的讨论和改动, 帮我更新下project_big_picture.md。
保持风格一致, 既要有指导性, 也要能体现我们的设计决策, 重点描述架构演进, 具体实现细节不用写太细。

这样做, 究竟改变了什么?

自从用上这套”先聊后写”流程, 发生了这些变化:

花钱少了: 再也没月末刷爆400美元额度了。每次只聚焦一个问题, 讨论到位后才让AI动手, token用量直降70%。有时候甚至把AI的建议粘出来, 换个新对话再分析一遍, 听起来有点”抠”, 但真的省钱。

代码质量提升: 代码不再”自己长歪”了, 完全贴合我定下的架构。类型安全, 异常处理都很统一, 整个项目风格一致, 写起来有底气。

调试更轻松: 线上出bug, 我能一眼定位问题源头——因为关键决策都是我拍板的, AI只负责实现。代码结构我心里门清。

思维负担减轻: 这点最让我意外。原以为加了流程会累赘, 结果恰恰相反。我不用一边想”我到底想要啥”, 一边又猜”AI到底干了啥”。我专注设计, AI专注实现, 像和一个永远不累, 码速爆表的搭档并肩写代码。

开发速度反而更快了: 前期讨论花的时间, 远远少于后期debug和返工的时间。省事又高效。

给还在观望的你 (我也曾经是)

如果你试过AI助手, 最后只觉得”AI写的都是垃圾”, 其实你没错。我也深受其害, 见识过混乱类型, 架构乱套, 那种”能跑但不敢上线”的代码。

但说到底, LLM不是架构师, 你才是!

如果你让AI直接写代码, 就是把项目大权交给一个对你团队规则, 项目历史, 未来维护一无所知的”外包”。写出来的东西当然难以入眼。

但只要你把AI拉回”讨论区”, 用它做思想碰撞, 方案推演, 最后才让它执行, AI助手真的能变成得力帮手。

换个角度, 你招个新人, 也不会让他第一天就随便推main分支吧?肯定要让他先读架构文档, 参与讨论, 做code review。

LLM也要这样: 先了解项目, 讨论方案, 最后才动手。每次都要按这个顺序来。

终极法则

一定要: 先讨论, 再决策, 最后才让AI上手实现。

如果你发现AI在设计讨论阶段就开始”手痒”写代码, 立刻叫停, 拉回正轨。告诉它: 咱们先把思路聊明白。

你的职责: 把控架构, 定设计, 守质量。

AI的职责: 记住一切细节, 干琐碎活, 把你的想法高效落地。

界限划清, AI助力开发就不再是混乱, 而是真正的生产力提升。你可以放心写代码, 不怕余额见底, 不怕代码长歪, 不怕线上一出问题就手足无措。

而且, 写代码又变得有趣起来了。你不用和一个”永远比你多事”的助手斗智斗勇, 而是和一个能听懂你设计, 按你要求实现的靠谱搭档协作。这才是我一直想要的开发体验。

(本篇由人类原创, 部分内容参考AI建议优化。)

迭代开发 on 张欣耕的个人博客