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