用 AI 把核心功能做完：任务卡、进度接力和不心疼钱的模型分档
这一章要做什么
界面有了，这一章开始做核心功能。要学会两件事：怎么把一个需求讲清楚，让 AI 一次做对；怎么让 AI 在你关掉电脑、第二天重新打开对话时，还「记得」项目做到哪了。这两件事解决好，AI 才会真的帮你省时间，而不是来回返工浪费时间。
把需求拆成任务卡
直接跟 AI 说「帮我加个功能」，得到的东西经常文不对题，或者 AI 顺手改了不该改的地方。原因是一个需求里藏着三类信息，AI 猜不出来：这个功能为什么存在（背景）、它不该碰哪里（边界）、怎么算做对了（验收标准）。写成一张固定格式的「任务卡」，每次都补全这三块，AI 犯错的概率会明显降低。
【任务卡】
背景：
- 这个 App 是什么（一句话，参考第一章的产品定义）
- 现在做到哪一步了（比如：界面能跑，换算逻辑是写死的假数据）
- 这次要加的功能是什么、为什么需要它
边界：
- 只改哪些文件 / 哪个功能模块
- 明确不要碰的部分（比如：不要改界面布局，不要引入新的第三方库）
- 不要顺手"优化"没让你动的代码
验收标准（写成可以打勾的清单）：
- [ ] 输入 xxx，应该得到 xxx（具体例子，不要写"能正常换算"这种空话）
- [ ] 输入一个非法值（比如字母），不能让 App 崩溃
- [ ] 改完之后，原来能跑的功能还能跑（回归检查）
套在厨房换算器上举个例子：背景是「界面能跑，换算结果目前是写死的假数字，这次要让换算逻辑真的按比例计算」；边界是「只改换算函数那部分逻辑，界面代码不要动」；验收标准是「输入 100，从克换算到勺，得到符合换算比例的数字；输入 abc 这种非数字，App 提示请输入数字而不是崩溃」。把这三块填完发给 AI，比一句「帮我把换算逻辑做对」有效得多。
一个对比：模糊需求和任务卡的区别
同样是让 AI 改换算逻辑，两种问法的结果差别很大。模糊的问法：「帮我把换算功能做对一点。」 AI 拿到这句话，猜不到「做对」具体指什么，很可能顺手把界面布局也一起改了，或者引入一个新的换算库——因为它没有边界，只能靠猜。
用任务卡的问法，AI 拿到的是一份能直接执行的说明书：改哪个函数、不改哪里、输入什么应该得到什么。同样一次对话，任务卡版本返工的概率明显更低，因为大部分「猜错方向」的可能性已经被你在写任务卡的时候排除掉了。多花两分钟写任务卡，经常能省下十分钟的来回沟通。
用一份文件让 AI 跨会话接力
你不可能一次性把整个 App 做完，一定会分成好多次打开电脑、好多次跟 AI 开新对话。AI 每次开新对话都是「失忆」的，它不知道你上次做到哪、踩过什么坑、下一步该干嘛——除非你把这些写进一个文件，每次对话开始先让它读一遍。这份文件习惯上叫 STATUS.md，放在项目文件夹根目录：
# <App 名> 进度记录
## 现在做到哪了
（一段话说清楚：界面 / 核心功能，哪些做完了，哪些没做）
## 下一步要做什么
- [ ] ...
- [ ] ...
## 踩过的坑（别再犯第二次）
- 坑是什么，怎么解决的
## 关键决定
- 比如：换算比例暂时写死在代码里，等基本功能做完再考虑要不要做成可配置
最后更新：YYYY-MM-DD
用法很简单：每次跟 AI 开新对话，第一句话就是「先读一下 STATUS.md，了解一下这个项目现在做到哪了」；做完一次改动，让 AI 顺手帮你把 STATUS.md 更新一下。几周下来，这份文件比你自己的记忆更可靠。
举个填完的样子，还是拿厨房换算器做例子：
# 厨房换算器 进度记录
## 现在做到哪了
界面能在模拟器里跑起来，能输入数字、选单位、点按钮看到结果。
换算逻辑已经改成真实比例计算（不再是写死的假数字），
但只做了克、毫升、勺、杯之间的换算，还没做"份""个"这类非重量单位。
## 下一步要做什么
- [ ] 加一个"常用换算"的快捷入口（比如一键切换克转勺）
- [ ] 输入框加一个清空按钮
## 踩过的坑（别再犯第二次）
- 第一次生成代码时 AI 多写了一个 @main，编译报错，删掉多余的那个就好了
## 关键决定
- 换算比例暂时写死在代码里，等基本功能做完再考虑要不要做成可配置
最后更新：2026-09-07
下次开新对话，把这份文件甩给 AI，它三秒钟就能知道项目做到哪了，不用你从头再解释一遍。
怎么花钱不冤：三档模型的思路
不同 AI 模型的价格能差出好几倍，能力也有差别——不是越贵的模型什么活都干得更好，而是不同的活配不同档位的模型才划算。给一个小白也能用的三档判断法：
- 这件事需要「想清楚」——架构怎么搭、一个奇怪的 bug 到底出在哪——用能力最强的档位，哪怕贵一点，因为想错方向、返工的成本更高。
- 这件事已经想清楚了、只是「做出来」——比如按上面的任务卡模板实现一个明确的功能——用便宜、快的档位就够，贵的档位在这类活上不会更聪明，只会更贵。
- 这件事是查资料、机械重复的操作——比如批量改个命名、找一段代码在哪——优先用免费的额度或者最便宜的档位，很多时候一个搜索就能解决，不需要 AI。
还有一个常被忽略的省钱点：别把整个项目的大文件原封不动丢给 AI，先自己筛出跟这次任务相关的部分，只给 AI 看它需要看的。喂给 AI 的内容越大，同样一次对话花的钱越多，AI 也更容易被无关信息带偏，反而做错。
平时查资料、验证一个写法对不对，用一个免费的对话式 AI 就够，不用为每一句话都调用付费接口——国内可以直接用免费聊天工具（比如 DeepSeek 网页版），写脚本要批量调用模型的话，也有免费的 API 层可以先用起来（比如硅基流动的免费小模型、OpenRouter 的免费模型），等真的用到额度上限了再考虑要不要付费升级。这些入口的额度、门槛和核实日期，情报站里都有：https://lanmao.ai/zh/
真实做一个 App 的过程，往往是三档混着用：卡在「为什么这个界面死活跑不起来」这种奇怪问题上，切到最强档位的对话问一次；确认原因之后，具体的修改交给便宜档位去做；中途想确认一个 API 的用法这种纯查资料的事，用免费聊天工具顺手查一下就好，不用为了这一句话专门开一个贵的对话。分清楚「现在这一步到底属于哪一档」，比无脑用最贵的模型省钱得多，也比无脑用最便宜的模型省时间得多。
「AI 改坏了」的回退办法：三条 git 命令
AI 一次性改动的范围有时候比预期大，改完发现原来能跑的功能坏了。如果没有存档，只能一点点手动改回去，很折腾。Git 的作用就是给代码「存档」，改坏了直接读档，这一节只用得到几条最基础的命令，不需要提前系统学 git。
第一次用，在项目文件夹里执行一次（只做一次）：
git init
每次让 AI 做一个新功能之前，先确认现在的版本是能跑的，存一个档：
git add -A && git commit -m "能跑的版本：换算逻辑改完之前"
AI 改完之后，看看它到底改了哪些地方，是不是只改了让它改的部分：
git diff
如果改坏了，或者改的范围比预期大很多，直接退回上一次存档，重新描述一次更精确的任务卡再试：
git checkout -- .
如果连续几次都不满意，想直接跳回更早的某一次存档（不是最近一次，是再往前一次或几次）：先用 git log --oneline 看一眼存档列表，每行开头那串字母数字就是存档编号，找到你想回去的那一条，然后：
git reset --hard 存档编号
项目会整个退回那次存档当时的样子，之后的改动全部丢弃，执行前确认一下编号。
以上命令都是 git 的标准用法，在任何执行过 git init 的项目目录里都能直接用（实测）。这也是我自己做 App 时一直在用的存档习惯：改动大的功能之前先存一档，图个心安。
什么叫「做完」
回到第一章「做完的标准」清单，加上这一章任务卡里的验收标准一起检查一遍，再补两条专门针对「用 AI 做完」的检查：
【核心功能验收清单】
- [ ] 第一章"做完的标准"里的每一条都能打勾
- [ ] 每张任务卡的验收标准都能打勾
- [ ] STATUS.md 是最新的，下次打开新对话能靠它接上进度
- [ ] 有一段完整的 git 提交历史，能看到"从空壳到能用"的过程，不是一次性一个大提交
- [ ] 装到自己真机上，正常用一遍，没有崩溃
下一步：付费章节会讲什么
免费公开的部分到这里是三章：选题、环境、核心功能。走到这一步，你手上应该已经有一个能在自己手机上跑起来、核心功能是真的能用的 App——这是最难的一段，从零到一。
接下来的内容会讲怎么把这个 App 提交上架、被拒了怎么办、宣传图怎么做、发新版本怎么弄、要不要做成付费 App 怎么定价。这些内容需要真机测试、真实走一遍提交审核的流程，工作量和这三章加起来差不多，会放在完整版里。感兴趣的话，订阅可以拿到后续更新。