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

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

先说最重要的一句话

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

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

你跟 AI 的对决，其实只有一个维度：谁掌握上下文。

如果上下文在 AI 的记忆里——你输了，因为它随时会忘、会编、会偷偷改主意。

如果上下文在文件里——你赢了，因为文件不会忘、不会编、你随时能查、AI 随时能读。

所以”规”的第一原则：把所有上下文写进文件，永远不依赖对话记忆。

tasks.md：你的上下文武器

我做 fh_java（加密策略平台）和 Orion（通知网关）的时候，总结出一个核心实践：每个功能开干之前，先生成 tasks.md。

不是那种”大纲”或”计划”，是一份可以随时中止、随时恢复的施工清单。

它长这样：

# 飞鸿 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 全流程走通

关键规则

[ ] 和 [x] — 未做和已做，一目了然
每完成一个任务就更新 tasks.md — 打勾 + 记录完成时间
每次更新后立刻原子化提交 — git commit -m "feat: complete Phase 1 auth"
决策记在任务下面 — 为什么选 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"

好处：

炸了能回滚 — git revert 精确到单个任务
code review 容易 — 每个 commit 只做一件事
中断不怕 — 关掉电脑、第二天打开，tasks.md 告诉你做到哪了

第一步：让 AI 生成 tasks.md

别自己写任务清单——让 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 add tasks.md
git commit -m "plan: add tasks.md for user management feature"

计划本身也是交付物。

第二步：同时出设计文档，互相关联

tasks.md 告诉你”做什么”，但不告诉你”为什么这么做”。

所以在生成 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 就行。

上下文在文件里，不在对话里。

第三步：按清单执行，看到成果——惊为天人

当你做完前面两步（tasks.md + design.md），真正开始让 AI 一个一个任务执行的时候，你会发现一件事：

AI 在约束下的产出质量，远超你的想象。

因为：

它知道只做这一个任务（不会越界）
它知道验收标准是什么（不会糊弄）
它知道前面做了什么（读 tasks.md 里已完成的部分）
它知道整体设计是什么（读 design.md）

没有约束的 AI 像一匹野马——跑得快，但方向不可控。有 tasks.md 的 AI 像一列火车——轨道限定了方向，速度反而能开到最大。

我在做 fh_java 的时候，14 个 controller 的重构，就是用 tasks.md 一个一个推的。每个 controller 一个 commit，总共 14 个原子提交。中间有两次 AI 改错了，git revert 回去重来，完全不慌。

这就是”规”的力量：约束产生质量，自由产生混乱。

执行时的对话方式

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

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

为什么每次都要让它先读 tasks.md？

因为你不相信它的上下文记忆。哪怕你刚才聊了 50 轮，新开一轮对话它可能就忘了一半。但 tasks.md 在那里——白纸黑字，它不可能编。

随时中止：关掉终端，tasks.md 不会消失。 随时恢复：新开一个对话，让它读 tasks.md，从上次打勾的地方继续。

三种项目规模的 tasks.md 实践

小项目（1-3 天）

tasks.md        # 一个文件搞定

中型项目（1-2 周）

docs/
  design.md
  tasks/
    01-database.md
    02-backend.md
    03-frontend.md
    04-deploy.md

大项目（1 个月+）

docs/
  milestones/
    v0.1-mvp/
      design.md
      tasks.md
    v0.2-auth/
      design.md
      tasks.md

常见翻车 & 对策

翻车 1：AI 出的计划太粗

症状：tasks.md 里一项就是”实现用户系统”

对策：

粒度太粗。请拆到文件级别：具体创建/修改哪个文件，大概多少行改动。
每项任务不超过 30 分钟工作量。

翻车 2：AI 偷偷加私活

症状：你让做 Phase 2，它把 Phase 3 也做了

对策：

严格只做 tasks.md 中 Phase 2 的内容。
不要修改 Phase 2 以外的任何文件。
需要额外改动请列出来但不要执行，等我确认。

翻车 3：做着做着计划对不上了

症状：Phase 3 发现依赖一个 Phase 1 没考虑到的东西

对策：这是正常的。更新 tasks.md：

Phase 3 发现需要额外处理 XXX。
请更新 tasks.md，在对应 Phase 加上这个任务，评估对后续的影响。
然后 commit 这次计划变更。

计划变更也是交付物，也要 commit。

总结：”规”的铁律

不信上下文，信文件 — tasks.md 是唯一的真相源
先出计划，再动手 — 不看到 tasks.md 不让 AI 写代码
每完成一个任务就原子提交 — 随时中止，随时恢复
计划和设计互相关联 — tasks.md 说做什么，design.md 说为什么
约束产生质量 — 给 AI 框架，它的产出惊为天人

人与 AI 的对决，本质上是上下文的对决。

AI 的上下文在记忆里——不可靠、会遗忘、会编造。你的上下文在文件里——可追踪、可恢复、可审计。

把上下文写在文件里，你就永远不会输。

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