Codex 额度烧完了，DeepSeek 4.1 能不能接手写代码

一位非开发背景的用户用 AI 从零搭了一个题库系统，日常靠 Codex 完成需求讨论、功能上线和小细节修补，体感非常顺。问题出在额度：高档位订阅用不起，低档位的额度又在两天内被几个功能烧光，连重置卡也用完了。而系统里有一部分能力本身就是调用模型做分析，额度一旦见底，等于整站停机。于是他开始考虑：把活交给 DeepSeek 4.1 这类更便宜的模型，能不能顶住？

这类问题在 AI 编程里越来越常见。答案不是简单的「能」或「不能」，而要拆成两件事分别看：它能不能把活写对，以及用它的总成本是否真的更低。讨论里对这两点的结论其实并不冲突，冲突的是大家拿它干的活不一样。

先分清两种「能干活」

一种是把已有的小功能改对：加个字段、修个报错、补一段接口、写个脚本。另一种是设计和演进系统：划分模块、改数据模型、处理并发和性能、跨文件重构。前者是执行，后者是决策。

多数使用者的反馈是：前一类任务它基本够用，速度快、不挑活；后一类任务上它容易「看起来做完了，其实埋了坑」，需要人反复纠正。有人形容得像手动挡，得随时握着方向盘；也有人直接说，把它当许愿机不行，但你有一定指挥能力时很好用。这两句话说的是同一件事。

为什么有人说便宜，有人说贵

价格分歧在讨论里最激烈，原因是大家比的不是同一个东西：

• 按 token 计费时，账单取决于用法而不是单价。 上下文越长、返工越多、每轮都把整个仓库塞进去，消耗就越快。同一个模型，有人半小时跑掉几块钱，有人一天用不了多少。
• 同一系列里不同档位的模型差别很大。 便宜的说法往往对应小尺寸、主打速度的版本；贵的说法往往对应更大参数或长上下文版本。名字里带 pro、max 之类后缀的也不一定更强，有些是上一代产品，编程能力反而不如新一代的小模型——具体型号能力请以官方最新文档和榜单为准。
• 不同渠道的价格不能横向比。 市面上有些第三方转发服务的价格低到不合常理，你无法确认请求最终路由到哪个模型、代码是否被留存、服务何时消失。为了省几块钱把整个项目的源码交出去，风险和收益不成比例。要长期用，走官方 API、官方订阅或正规云厂商的托管服务更稳。

务实的做法是：先用小额充值跑两三个真实任务，记录每个任务大概花多少、用多久、返工几次，再决定要不要把它设成主力。别人的「半小时五块」对你的项目没有参考意义。

稳妥的用法：计划、实现、审查分成三段

讨论里最一致的共识，是不要让一个模型从头包到尾，而是按角色分工。

1. 计划阶段用最强的那个

把需求讲清楚，让能力最强的模型产出一份 Markdown 计划文件，落盘到仓库里，而不是留在对话里。模板可以是这样：

## 目标
一句话说明这次要做什么，验收后用户能看到什么

## 涉及文件（只允许改这些）
- src/api/question.ts
- src/pages/bank/list.tsx

## 步骤（每步独立可验证）
1. 加字段 xxx，跑通迁移
2. 接口返回新字段，用 curl 验证
3. 前端展示，手动点一遍

## 验收标准
- npm run build 通过
- 新增 1 条题目后列表正确显示

## 禁止事项
- 不改表结构以外的东西，不删数据，不升级依赖

2. 实现阶段交给便宜的模型

让它读这份文件，一次只做一个步骤，做完就停下。每完成一步，跑一次构建或测试，然后提交一次。这样即使某一步做错了，回滚成本也只有一步。

3. 审查阶段再回到强模型

把 diff 而不是整个仓库丢给强模型看，让它只挑问题：边界条件、错误处理、有没有偷偷改动范围外的文件。有使用者给出的经验是，弱模型写、强模型查，能抓出不少「大大小小」的毛病，但完全由弱模型自己收尾就容易漏。

这一套跑顺之后，强模型的额度基本只花在计划和审查上，消耗会明显下降——而这两步恰恰是最不该省的地方。

防改坏：先做好止损，再谈效率

对不熟悉代码的人来说，最怕的不是写得慢，而是数据库被改坏了自己修不回来。这件事有标准解法，和模型强弱无关：

# 1. 开新分支，别在主分支上折腾
git switch -c feat/ai-$(date +%m%d)

# 2. 记录一个可回退的基线
git add -A && git commit -m "baseline before AI changes"

# 3. 动手前备份数据库
mysqldump -u root -p your_db > backup_$(date +%m%d%H%M).sql

再补几条习惯：

• 让模型写迁移脚本，由你执行，而不是让它直连生产库改表；
• 先在本地或测试环境跑通，再考虑部署；
• 给 AI 用的数据库账号只开必要权限，最好是只读加写入测试库；
• 每次让它改完，自己点一遍关键路径，别只看它说「已完成」。

几个容易踩的坑

• 长会话容易崩。 对话拉得很长之后再让它读图片或大文件，可能直接报错。把上下文写成文件、拆成新会话，比硬撑更省事。
• 慢可能不是模型的问题。 同一个模型在不同客户端、不同 agent 工具里体感差别很大，有的工具本身就慢。换工具再评测，别急着给模型下结论。
• 免费额度和套餐要看清楚。 有些渠道确实提供免费额度或大额度套餐，但稳定性和合规性需要自己确认，别把关键业务压在上面。
• 非开发者慎用弱模型。 你无法判断代码对错时，省下的调用费往往要用返工、数据和排查时间来偿还。判断力不足的场景下，用最好的模型反而是最省钱的选择。
• 长时间跑的任务要有人看着。 如果任务本身要跑几十分钟甚至几小时，而你的本子会休眠、网络会断，中途掉线就得从头再来。这种情况下，把 agent 放到一台能长期在线、网络稳定的远程机器上跑，是一种可选的处理方式，适合长任务和批量任务，日常小修小改则没必要。

小结

结论可以压缩成三句话：中小任务、有明确验证标准、有 git 兜底时，DeepSeek 4.1 这类模型完全能接手，速度往往是它的优势；涉及架构、不可逆操作、你不熟悉的领域时，别省这一步的强模型额度；成本要按「完成一个任务的总花费」算，而不是按每百万 token 的单价算。

先小额试两三个真实任务，把计划和审查留给强模型，把执行交给便宜的模型，再用 git 和数据库备份把下限兜住——这套组合比纠结「谁更强」更能解决问题。