vibe‑coding 九阳神功之规：不要相信任何模型的上下文，tasks.md 才是唯一真相

系列顺序：夯（Git） → 抄 → 学 → 喂 → 规 → 验 → 测 → 扩 → 收
人与 AI 的对决，唯一的优势是上下文。把上下文写在文件里，就永远不会输。

先说最重要的一句话

不要相信任何模型的上下文。

Claude 也好，GPT 也好，Codex 也好——它们都有上下文窗口限制，都会”忘事”，都会在长对话里越聊越飘。以为它记得前面说的约束？它不记得。以为它知道做到哪一步了？它不知道。

人跟 AI 的对决，其实只有一个维度：谁掌握上下文。 上下文在 AI 的记忆里——完蛋，它随时会忘、会编、会偷偷改主意。上下文在文件里——稳了，文件不会忘、不会编、随时能查、AI 随时能读。所以”规”的第一原则：把所有上下文写进文件，永远不依赖对话记忆。

tasks.md：上下文武器

我做 fh_java 和 Orion 的时候养成了一个习惯——开干之前先让 AI 出一份 tasks.md。说白了就是个 todo list，写清楚要干啥、干到哪了、下一步是啥。

它长这样：

# 飞鸿 iOS App - P0 MVP

## Phase 1: 认证模块
- [x] TokenManager actor 实现（Keychain 存储）
- [x] LoginView + LoginViewModel
- [x] 验收：登录→获取token→Keychain持久化 ✅ 2026-02-20
  - 决策：用 actor 而非 class，防并发竞争

## Phase 2: Dashboard
- [x] DashboardView + Swift Charts
- [x] API 对接 /api/dashboard/summary
- [ ] 空状态 / 错误状态 / Loading 状态
- [ ] 验收：真实数据渲染，3种异常状态覆盖

## Phase 3: 计划列表
- [ ] PlanListView + 分页加载
- [ ] PlanDetailView
- [ ] 创建/编辑计划表单
- [ ] 验收：CRUD 全流程走通

用起来就几个要求：做完一个任务就打勾，打完勾就 commit，别攒着。如果做的过程中有什么决策（比如为什么选 actor 不选 class），就写在任务下面。三个月后的你会感谢现在多写的这一行。

为什么要原子化提交？

AI 最擅长的事情就是”一口气改 20 个文件”。

让它自由发挥的话，它会像一个极度积极的实习生：说加个按钮，它把整个页面重写了，顺带重构了路由，换了状态管理方案，还把 CSS 全删了。

原子化提交，说白了就是每做一件事就存一次档。

# 做完 Phase 1 的第一个任务
git add .
git commit -m "feat(auth): implement TokenManager actor with Keychain"

# 做完 Phase 1 的第二个任务  
git add .
git commit -m "feat(auth): add LoginView and LoginViewModel"

为什么非要原子提交？因为 AI 一口气改 20 个文件是常态。我之前不拆提交，有一次 18 个文件改对了，2 个改错了。找那 2 个花的时间比全部重写还多。拆了之后就简单了——哪个 commit 炸了，git revert 回去，其他的不受影响。

让 AI 生成 tasks.md

别自己写任务清单——让 AI 写，自己来审。这是我踩了无数坑之后的结论：你写的计划，AI 不一定认；AI 写的计划，你审过之后，执行的时候它反而更听话。大概是因为”这是它自己说的”，上下文匹配度更高。

提问模板

我要实现【功能描述】。

请输出 tasks.md，要求：
1) 拆成 3-5 个 Phase，每 Phase 独立可验收
2) 每个任务精确到文件级别（创建/修改哪个文件）
3) 每个 Phase 有明确的验收标准
4) 用 [ ] checkbox 格式
5) 每个 Phase 改动不超过 5 个文件
6) 不确定的地方标注 [待确认]

约束：
- 不重构现有代码，只做增量
- 遵循项目现有风格

审什么？

拿到 AI 出的 tasks.md，检查 3 件事就够：粒度对不对——一个任务不应该超过 30 分钟，超过的就拆；顺序对不对——有没有依赖关系搞反的；验收标准清不清楚——”做完”不是验收标准，”curl 返回 200”才是。

确认完，commit 这个 tasks.md 本身。计划本身也是交付物，也要进 git 历史。我见过太多人把计划写在 Notion 里、写在飞书文档里，结果 AI 读不到，等于没有。

git add tasks.md
git commit -m "plan: add tasks.md for user management feature"

设计文档：tasks.md 的另一半

tasks.md 管”做什么”，不管”为什么这么做”。你一定会遇到这种情况：做到 Phase 3，忘了 Phase 1 为什么选的 bcrypt 而不是 argon2。翻聊天记录？聊天记录早就被上下文压缩吃掉了。

所以在生成 tasks.md 的时候，同时让 AI 出一份设计文档：

请在输出 tasks.md 的同时，生成 design.md，包含：
1) 技术方案概述（架构图/数据流）
2) 关键技术决策及理由
3) 接口定义（如果涉及 API）
4) 和 tasks.md 的映射关系（哪个 Phase 对应哪段设计）

目录结构：

docs/
  user-management/
    design.md      # 为什么这么做
    tasks.md       # 具体做什么

design.md 里引用 tasks.md：

## 数据层设计

用户表采用 UUID 主键，密码用 bcrypt 加盐。

> 对应任务：tasks.md Phase 1

tasks.md 里引用 design.md：

## Phase 1: 数据层
> 设计详见：design.md § 数据层设计

- [ ] 创建 users 表 migration

做到 Phase 3 的时候想回忆”当初为什么选 bcrypt”，不用翻聊天记录——看 design.md 就行。上下文在文件里，不在对话里。这句话我可能全篇说了三遍，但说三遍都不够。

按清单执行

做完前面的准备，真正开始让 AI 一个一个任务执行的时候，会发现一件事——AI 在约束下的产出质量，超出预期很多。它不会越界，因为 tasks.md 写了只做这一项；它不会糊弄，因为验收标准明摆着；它甚至知道前面做了什么，因为已完成的任务都打了勾。给 AI 越多自由，翻车越快。我现在深信这一点。

我在做 fh_java 的时候，14 个 controller 的重构，就是用 tasks.md 一个一个推的。每个 controller 一个 commit，总共 14 个原子提交。中间有两次 AI 改错了，git revert 回去重来，完全不慌。如果没有原子提交，这 14 个 controller 搅在一起，我大概率会选择删库重来。

对了说个题外话——我有次让 AI 自己写 tasks.md，结果它给自己安排了一项”优化 tasks.md 的格式”。递归了属于是。后来我加了条规则：tasks.md 的结构我定，AI 只管填内容。

执行时的对话方式

每次跟 AI 对话，第一句话永远是：

请先读 tasks.md，告诉我当前进度，然后执行下一个未完成的任务。
完成后：
1) 更新 tasks.md（打勾 + 记录完成时间）
2) 如果有设计决策，更新 design.md
3) 告诉我验收步骤

为什么每次都要让它先读 tasks.md？不信它的记忆就对了。哪怕刚才聊了 50 轮，新开一轮对话它可能就忘了一半。但 tasks.md 在那里——白纸黑字，它不可能编。随时中止，关掉终端，tasks.md 不会消失。随时恢复，新开一个对话，让它读 tasks.md，从上次打勾的地方继续。我有时候在公司写到一半，回家打开电脑，一句”读 tasks.md 继续”就能无缝衔接。

项目大了怎么办

小项目（一两天能搞定的）一个 tasks.md 就够了。项目大了就拆——中型项目按模块分文件（tasks/01-database.md、tasks/02-backend.md），大项目按里程碑分目录（milestones/v0.1-mvp/tasks.md）。原则是一样的，只是文件多了几个。别在这个问题上纠结太久，先写一个 tasks.md 跑起来，不够用了再拆。

翻过的车

计划太粗。 AI 出的 tasks.md 有时候一条就是”实现用户系统”——这等于没拆。碰到这种直接让它重来：”拆到文件级别，每项不超过 30 分钟”。

偷偷加私活。 让它做 Phase 2，它顺手把 Phase 3 也做了。这个特别烦。我后来在 prompt 里写死：”不要修改当前 Phase 以外的任何文件。需要额外改动请列出来但不要执行。”有用，但不是 100% 有效，隔几次还是会犯。

做着做着计划对不上了。 Phase 3 突然发现依赖一个 Phase 1 没考虑到的东西。这个其实不算翻车，软件开发就这样。正确的做法是更新 tasks.md，加上新发现的任务，然后把这次计划变更也 commit 掉。计划会变——关键是变更要有记录。

就这么点事

写到这里回头看，”规”讲的事情其实特别简单——别信 AI 的记忆，把上下文写文件里。tasks.md 管做什么，design.md 管为什么，每做完一步就 commit。

这套东西没有任何技术含量。不需要装插件，不需要配工具链，不需要学新框架。一个 markdown 文件，一个 git 命令。但就是这么朴素的东西，把我的 AI 编程翻车率从”经常”降到了”偶尔”。

你要问我最怕什么？最怕 AI 某天真的有了完美记忆力。那我这篇就白写了。

不过目前看，短期内不用担心。

下一式我们讲验：AI 写的代码看起来对，但真的对吗？用多模型交叉验证，专治幻觉。