我用 AI 做完整项目后，总结出一套把需求钉死的工作流

做了十几年开发，今年最大的变化是把 Codex、Claude Code 这类 Agent 真正用进项目里，而不是只在 demo 阶段玩玩。最近用它们做完一个本地 epub 阅读器，踩的坑和攒的经验，值得记一笔。

先说我的核心主张：用 AI 写代码不能只甩一条指令，必须建立一套"把预期逐步固化"的工作流，才能交付贴合需求、少 bug 的作品。下面把打法和背后的论据摊开，每步贴出当时真实配置。

最初我也走过弯路，把"听话的执行者"误当成"能替我想事的伙伴"。复盘下来，根子不在模型，在于指令越空泛，跑偏概率越高。

论据一：Agent（Codex、Claude Code 等）是"听话的执行者"，指令越模糊产物越易跑偏——这是机制，不是短板。它不会读心，你不写清预期，它就拿默认理解填坑。

论据二：完整流程分五步——环境搭建、产品设计、技术设计、产品实现、人工验证。

环境是第一步，也是地基。开 git 仓库，再补一份 AGENTS.md。这份文件是专门写给 AI 的项目说明书，约定"每功能一 commit + 跑通测试再交付"。先把提交习惯立住：

git init
git commit -m "chore: 初始化 Electron+React+TS 骨架"

git add src/features/reader
git commit -m "feat: 实现 epub 打开与基础渲染"

AGENTS.md 我只把最该卡的边界写死：

# AGENTS.md

## 提交规则
- 每完成一个独立功能单独 commit
- 禁止多件不相关改动混在一个 commit

## 质量门禁
- 改完跑通 `npm run test` 与 `npm run build`
- 本地能启动、核心流程走通才算完成

## 技术栈（禁止擅自更换）
- Electron + React + TypeScript
- 状态管理：Zustand

## 明确不做的范围
- 不做笔记 / 标注
- 不做云同步
- 不做账号系统

顺带把术语说人话：MVP 是最小可用产品，第一版只做核心；AGENTS.md 是给 AI 的项目说明书；Electron/React/TS 是桌面应用常用技术栈；computer use / Chrome 插件是让 AI 操作电脑、看页面的验证工具；前端是可见界面，后端是背后数据处理逻辑。

产品设计重点是做减法：MVP 之外，更要写清"不做什么"。阅读器第一版写死不做笔记、不做云同步、不做分享。技术设计把栈写进 AGENTS.md，AI 就不会乱换框架。

产品实现最关键的动作，是给 AI 一个能自测的闭环。借助 computer use 或 Chrome 插件，让 AI 真正打开页面、点击操作、观察反馈，自己验证"翻页按钮到底有没有生效"。
交互复杂的项目，我会先只做前端、数据全 mock，把交互先跑顺：

// 真实解析后置，先用 mock 把交互验证掉
const mockBooks = [
  { id: '1', title: '测试书A', content: '第一章内容……', progress: 0 },
]

function Reader() {
  const [books] = useState(mockBooks)
  const turnPage = (step: number) => { /* 先验翻页手势 / 按钮 */ }
  return <div>{books[0].content}</div>
}

这一步帮我在早期排掉不少方向性错误。简单小工具可以省。

论据三：复杂项目先做"仅前端、数据模拟"的 demo 验交互，简单项目可跳过——上面那段就是。

论据四：三条不可省原则：版本管理、给 AI 自测环境、人工验收。

论据五：参与越多掌控越强但越慢，按需求分量和复杂度权衡，别生搬硬套。

最后一步永远是人自己验收，这道关不能省。

我的立场是实用主义：当前阶段人必须把控预期和质量，反对把决策权全交 AI。也别把这流程当金科玉律——模型能力还在进化，它本就不是终极答案。

实践启示三件立刻可做：① 建 git 仓库 + 写 AGENTS.md 要求自测；② 复杂需求走满设计环节，简单需求裁剪；③ 务必亲自验收。

专业总结：核心价值是把"模糊需求 → 可信交付"的过程方法化。若只记一句：让 AI 能自己验证、你再验一遍，比写更长的提示词更重要。