年初我信了那句"一句话让 AI 写完整个项目"的说法。真上手做那个本地阅读器时，翻车了。
我给 Claude Code 一句"做个能看 epub 的桌面软件"，它确实给了我一堆代码。跑起来才发现，界面不是我要的，翻页逻辑反了，搜索框点了没反应。问题不在模型笨，是我把"听话的执行者"当成了"懂我心思的同事"。
我想说的核心就一句：用 AI 写代码不能只甩一条指令，必须建立一套"把预期逐步固化"的工作流，才能交付贴合需求、少 bug 的作品。下面把这套打法和它背后的道理摊开讲。
为什么一条指令不够？因为 Agent（Codex、Claude Code 这类）本质是"听话的执行者"。你给的指令越模糊，它越按自己的理解自由发挥，产物就越容易跑偏。这不是能力短板，是机制使然------它不会读心，你的预期不写清楚，它就拿自己的默认理解来填。指望把提示词写得更长更完美来解决问题，方向就错了。
我后来沉淀出的流程是五步：环境搭建、产品设计、技术设计、产品实现、人工验证。
先把地基打牢。每个项目开 git 仓库，再写一份 AGENTS.md 当项目说明书------这个词得解释下，它是一份专门写给 AI 看的约定文件，核心就两条：每做一个功能提交一次 commit，跑通测试再交付。文件不用长，把硬规矩钉死就行，这是我为阅读器写的初版：
markdown
# AGENTS.md
你是本项目的开发助手，交付前必须遵守以下规则。
## 提交规则
- 每完成一个独立功能，单独提交一次 commit
- commit message 格式：feat: 实现某功能
- 禁止把多个不相关的改动混在一个 commit 里
## 质量门禁
- 改动后必须跑通 `npm run test` 与 `npm run build`
- 本地能正常启动、核心流程能走通，才允许说"完成"
## 技术栈（禁止擅自更换）
- Electron + React + TypeScript
- 状态管理用 Zustand，不要引入 Redux
- 样式用 CSS Modules
## 明确不做的范围
- 不做笔记 / 标注
- 不做云同步
- 不做账号系统这里顺带说几个术语。MVP 是最小可用产品，意思是第一版只做核心功能，别贪多。Electron / React / TS 是桌面应用的常用技术栈。前端是你看得见、能点的界面，后端是背后处理数据的逻辑------做 demo 时我们先碰前端、后端先不做处理。
接着做产品设计，只画 MVP，更要紧的是写清楚"不做什么"。阅读器第一版我就写死不做笔记、不做云同步、不做社交分享。边界划清了，AI 才不会自作主张给你堆用不上的东西。
技术设计这一步别省，把栈写进 AGENTS.md，AI 就不会今天一个框架明天一个库。
产品实现时，关键动作是给 AI 一个能自测的环境。借助 computer use 或 Chrome 插件------这两个是让 AI 真正操作电脑、打开页面去"看"效果的验证工具------让它点按钮、看反馈，自己确认"翻页按钮到底灵不灵"，比我对着 diff 猜高效太多。
复杂项目我还会多一道：先只做前端、数据全用 mock，捏个 demo 验交互。比如阅读器我先不接真实 epub 解析，用假数据把翻页、进度记忆跑顺：
javascript
// 先用 mock 数据把交互跑通，真实解析后面再接
const mockBooks = [
{ id: '1', title: '测试书A', content: '第一章内容......', progress: 0 },
{ id: '2', title: '测试书B', content: '示例正文......', progress: 30 },
]
function Reader() {
const [books, setBooks] = useState(mockBooks)
const [current, setCurrent] = useState(books[0])
const turnPage = (step: number) => {
const next = Math.min(books.length - 1, Math.max(0, 0 + step))
setCurrent(books[next])
}
return <div>{current.content}</div>
}这一步帮我在早期就发现一堆方向性错误。简单的小脚本，这道可以省。
最后一道关永远是人，亲自把功能走一遍。
说到底有三条原则谁都不能省：版本管理、给 AI 自测环境、人工验证。你参与得越多，掌控越强，但交付越慢。按需求的复杂度和重要性去权衡，别生搬硬套。
我的立场很明确：我是实用主义者，当前这个阶段，人还是得把控预期和质量，把决策权一股脑交给 AI 我不认同。也别把这流程当金科玉律------模型能力还在飞快进化，今天好用的方法明天未必，它本就不是终极答案。
AI编程落到行动上，三件事必须做：第一，建个 git 仓库，写份 AGENTS.md 要求它自测；第二，复杂需求走满设计环节，简单需求大胆裁剪；第三，无论多信 AI，务必亲自验收。
如果要给这套东西下一个总结：它的核心价值，是把"模糊需求 → 可信交付"这件事过程方法化了。利用AI编程只记一句，那就是：让 AI 能自己验证、你再验一遍，比写更长的提示词重要得多。