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“入职培训”——让它搞清楚你项目的架构、设计模式、底层哲学。

我的惯用开场白：

1
2
3
4
5
6
7

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

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

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

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

文档里该写啥？

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

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

举个栗子（假设你也是个猫片控😺）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

## 核心架构

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有了全局观，接下来才能讨论具体问题。

核心原则：要“聊方案”，而不是“直接让它上手”。

好的第二轮提问：

1

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

不好的提问：

1

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

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

这时，进入“头脑风暴模式”，你和AI来回碰撞：

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

你：“可以，但评分缓存现在在仓储层，你怎么看？”

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

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

重点：这一步绝不让AI动代码！

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

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

第三步：“OK，咱们正式开工！”

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

1

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

此时，LLM才开始写代码。

因为前面沟通充分，最终实现会：

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

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

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

完整开发回路长啥样？

实际用起来，大致流程如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

会话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：

1
2

根据我们的讨论和改动，帮我更新下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建议优化。）