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建议优化。)