人决定，AI 执行，证据说话：
一个人用三个 AI 工具七天做出产品的方法

这本书给谁看，看完能明白什么

如果你手里有一个想做的产品，身边有 Codex、Claude Code 这样的 AI 工具，但不确定该先说什么、什么时候该自己拍板、怎么判断它交回来的东西到底能不能用，这本书就是为你写的。

先说我是谁，以及这本书讲的是哪件事。我叫 Bin哥，平时同时用 ChatGPT、Codex 和 Claude Code 干活。2026 年 9 月 25 日上午十点，我在 ChatGPT 里开始聊一个想法：做一个叫 Tina 的 AI 陪伴女友，能聊天、能慢慢记住我、有自己的日常、按额度发和她当下状态一致的照片。到 10 月 2 日凌晨，这个项目的仓库里有 Java 后端、MySQL、React 前端、153 张任务卡、48 张缺陷卡、一份逐章对照过的 PRD 覆盖矩阵，本机上跑着能用测试邮箱登录、接真实 DeepSeek 聊天、自动提取记忆、知道上海天气、晚上十一点会窝在沙发上穿家居服的 Tina。

这本书不讲 Tina 这个产品本身，讲的是这七天里我和 AI 之间形成的一套工作方法：每一轮先说清要什么、人在哪些点上必须自己决定、AI 的产出怎么留下能查的证据、用户试用时暴露的问题怎么变成下一步。它一开始不是设计出来的，是从 9 月 25 日第一次纠正 AI "技术方面你先不考虑"开始，一条一条攒出来的。项目里有一个叫"编程方法论"的目录专门记这些，这本书是那个目录的整理版。

看完你能明白的五件事

1. 和 AI 做产品时，哪些决定必须由人来下，哪些事放手让 AI 做反而更快。
2. 从一句"我想做个 AI 女友"到一份能被另一个模型读懂的 PRD、交接包、计划，中间要固化哪几样东西。
3. "AI 说做完了""测试通过了""任务卡有 153 张"分别能证明什么、不能证明什么，验证要分哪五层。
4. 交给自己试用时为什么会卡在"怎么登录"，用户反馈怎么变成能复现的行为和能量化的验收标准。
5. 当项目能跑但不知道下一步改什么时，怎么用一次只读评审和一句话授权，让 AI 一天安全地做完十几个任务。

三条写作原则

• 只说验证过的事。书里每一句对话原话、每一个数字、每一次"通过"，都能在项目仓库里找到任务卡、日志、提交或对话快照。当时跑过的测试我写"当时记录"，这次只核对了文档的我写"本轮未复跑"。
• 不把一次经历说成普遍规律。这套方法只在一个项目、一个人身上验证过。哪些是案例观察、哪些尚无对照数据，我分开写；它是否省时间，我手里还没有数字。
• 每个工程词都翻译成人话。第一次出现时给一个生活里的类比，每章末尾有"人话翻译"框，书末有术语表。

没有方法的时候，我们在被三种"假完成"骗

AI 工具最擅长的事之一，是让一件没做完的事看起来做完了。不是它故意骗你，是它回复的语气、任务卡的数量、测试的绿色勾，都在替"完成"背书，而真正的完成只有一个标准：用户能用。

第一种：AI 说"已完成"

9 月 26 日晚上十点三十七分，Codex 已经连续跑了一天多，产出了一百多张任务卡，我问它："帮我看一下还有什么缺的，我要开始进行测试了，有没有全部跑通。"它回答得很体面，列了已完成的离线切片和工程检查。然后我问了第二句："怎么进行登录？目前邮箱没有打通。"

那一刻我才意识到，前面所有"通过"都是在合成账号、替身邮件、本地数据库上通过的，而我作为用户，连第一步登录都走不进去。工程证据是真的，只是它们证明的事和我要的事不是一件事。后来补了本机测试邮箱（TASK-134），我才第一次用自己的手走完"登录、发送、模型回复、状态落库"这条链。

第二种：任务数当进度

到 9 月 26 日下午，任务卡已经有 118 到 133 张，固定运行包的七项本地同包检查全部通过。但同一份报告里写着一行 candidateReady=false：Q02 的测试驱动证据不完整、Q05 整体门禁没过、Q09 跨会话记忆没验、最终用户验收没做。任务卡的数量说明的是拆分方式，不是完成度。我在方法论里专门留了一句："137 张历史任务卡包含实现、审计、补证和 Bug 修复，不代表 137 个业务功能。"

第三种：测试通过当验收

9 月 27 日凌晨，基本对话已经通了，我报告了一个 Bug："每次在发完消息的时候，焦点会从输入框消失，而且还需要我重新滚动右边的进度条。"这个问题在此前所有浏览器脚本里都没被检出，因为没有人写过"发送后输入框应该保持焦点"这条断言。测试通过只能证明写出来的断言满足，证明不了没写出来的体验。更早的一个例子是 TASK-105：浏览器脚本曾经通过，但大图遮罩只盖住了中间一栏，是人看了一眼才发现的。

方法从哪里来

这本书后面讲的每一条做法，几乎都是从这三种假完成的某一次翻车里长出来的。9 月 25 日那天还只有九条，都是"开发准备"阶段的：怎么讨论需求、怎么交接风格、怎么出计划。到 9 月 28 日补到十七条，多了连续实施、分层验证、真实试用、用户反馈。10 月 1 日换到 Claude Code 做了一天优化批次之后，又多了六条。它不是一开始就设计好的框架，是一本边做边记的账。

全流程一张图：二十个环节，人决定什么，AI 执行什么

先把七天压成一张图。从需求讨论到优化批次一共二十个环节，分四个阶段；每个环节都有一个"人必须决定"的点和一个"AI 负责交出"的东西。后面的章节就是沿着这张图一段一段讲。

四个阶段，二十个环节

这二十个环节连起来，就是方法论主文里那句很长的话：

讨论使用场景 → 人工收敛首版 → 固化 PRD → 选择视觉方向 → 文件交接与可点击原型 → 对照原型分析真实业务差距 → 按维护能力修订架构 → 分阶段计划与验收 → 补齐工程约束 → 形成目标模式执行提示词 → 固化人工决策与任务映射 → 持续实现可独立验证的切片 → 同版证据核对 → 提供实际测试入口 → 根据用户反馈修复与补证 → 记录新增需求 → 只读评审列优化点 → 一句话授权后的批次自治 → 覆盖矩阵与实测清单收口 → 试用反馈先查数据再量化。

它不是事先画好的路线图。前九个环节在 9 月 25 日自然发生，之后每一段都是上一段暴露了什么问题才长出来的。比如"提供实际测试入口"这一环，是因为我在 9 月 26 日晚上问"怎么进行登录"才被补上的。

人和 AI 各管什么

这张图最想说的一句话是：人持续决定产品重点、审美、维护方式、外部资源和验收口径；AI 把这些决定转成文档、原型、代码和检查；用户实际试用继续暴露遗漏。三者缺一个，就会退回第 1 章的某种假完成。

还有一个容易忽略的角色是"共同产物"。PRD、交接包、决策记录、任务卡、证据目录、覆盖矩阵，这些文件既不是人写的也不是 AI 写的，是两边对话之后固化下来的基线。换一个模型、换一台电脑、隔一个星期再来，接得上的靠的就是这些文件，不是靠谁的记忆。10 月 1 日我换到 Claude Code 时，它接手读的就是看板、任务卡、PRD 和方法论目录，没有读过 Codex 的任何会话。

这个项目用了哪些工具，各在哪一段

我要提醒一句：这张表能证明三个工具在不同阶段被实际使用过，证明不了哪个模型更擅长什么。同一个任务没有做过对照实验，本书不给模型排名。

需求阶段：限制讨论范围、缩小首版、用场景说话

9 月 25 日上午十点十八分到十一点二十分，一个小时，十二轮对话，从"做一个工作型陪伴女友"聊到一份 PRD。这一个小时里我做的四件事，后来成了方法论的前三条。

第一件事：按住技术，只谈需求

最初聊的是"工作型陪伴女友，能帮安排日程"。AI 展开功能的时候，很快就带进了数据模型和架构。我说了一句："技术方面你先不考虑，更多的是需求方面的。"过了几轮它又往技术上滑，我再说一次："技术是需求讨论完再进行。"

这两次纠正后来被我记成第一条做法：每轮开头说明目前要解决的问题与产物。AI 偏离时直接纠正当前阶段，再让它更新总结。一段详细的技术回答并不证明需求已经清楚，它只是让讨论看起来有进展。

第二件事：把首版缩到四样东西

脑暴里出现过日程、任务、提醒、多角色、会员档位、相册、主动发图。我把首版收敛成四样：聊天、用户人格设置、长期认识用户、固定角色 Tina。其他全部后置。

中间有一次表达冲突：我前面说"视频先预留"，后面又说"主要以视频为主"。AI 指出了矛盾，我明确："主要是图片，这才是最主要的，其他的没问题。"这句话保留在 PRD 里，没有被替换成更顺的说法。方法论里对应的做法是：把脑暴内容分成首版必做、后做、待确认；用明确纠正消除矛盾。还有一个边界要记住：我说"确认"只针对它上一轮的回答，不等于同意了它之前展开的所有建议。

第三件事：用具体场景定义功能

我没有写"支持图片互动"这种功能点，而是说了几个场景：我问"今天你在做什么"，她发一张咖啡店自拍；我说"再来一张全身照"，她发的还是同一身穿搭、同一个地方；每天免费三到五张，用完了她自己说。AI 据此展开了今日状态、场景连续性和计次规则。

这些场景后来直接变成了代码：今日状态快照、人物身份版本、"再来一张"沿用上一镜头、每天 5 张成功展示才扣次。方法论里的写法是把一项功能写成四段：用户说什么 → 系统做什么 → 用户看到什么 → 失败或超过限制怎么办。

第四件事：指定可交接的产物

讨论收敛后，我要求先输出 MVP PRD，然后说"生成 markdown 就好了"。这个 Markdown 文件就是后面所有工具读取的同一条基线。ChatGPT 那一轮的文件生成没有返回普通正文，我没有去补造它说了什么，只记录了最后落到本地的文件。

10:xx  "技术方面你先不考虑，更多的是需求方面的"
10:xx  "技术是需求讨论完再进行"
11:xx  "主要是图片，这才是最主要的，其他的没问题"
11:20  "生成markdown就好了"

需求阶段的过关检查

• 每轮开头说明本轮解决的问题与产物，AI 跑题时纠正阶段而不是跟着展开
• 脑暴结果分成首版必做、后做、待确认三栏
• 每个功能写成"用户说什么 → 系统做什么 → 用户看到什么 → 失败怎么办"
• 表述矛盾的地方由人明确结论并更新文档；AI 早期建议不视为已批准
• Markdown PRD 落盘，每个功能能追溯到一个具体场景

原型与交接：把审美变成另一个模型能读的文件

PRD 定了之后，我最想看的不是代码，是"它长什么样"。9 月 25 日中午到下午，视觉方案在 Codex 里选，原型在 Claude 里做，差距分析再回到 Codex。三个会话之间传递的不是记忆，是一个文件夹。

选一张图，然后把它存起来

我先说的是"美观、高大上"，Codex 追问之后我明确要主要几个页面的交互。它给了三种视觉方案，我选了 1，然后说："先把我选的这个风格存储起来，我需要用其它模型来绘制。"

Codex 把选中的原图、风格说明、页面范围、交接提示词和来源清单保存到 doc/design/selected-style-01/，并记录了参考图副本的 SHA-256 与源图一致。这一步后来被总结成第四条做法：把审美偏好变成参考图、配色与布局说明、页面范围、交互清单和验收要求，再交给下一工具。

换一个模型，按包做原型

下午一点十七分，我在 Claude 本地会话里说：先扫一下项目结构，按已选风格实现静态网页原型，可以先不做数据处理，但需要有点击交互。三十多分钟后它交付了聊天、Tina、关于你、我的四个页面。

Claude 的公开回复里留下了一串排错：data: 预览导致资源丢失，改用静态服务器；端口冲突，换端口；保存栏超出视口，调样式。这些很适合拿来教"看见故障、定位原因、修复、复查"，但我要说明：本书没有复跑这些历史检查。

原型之后，马上做差距分析

原型能点了，我没有直接让它接后端，而是要求按静态页面和 PRD 生成技术分析，并顺便检查本机的"技术架构师"Agent 配置能不能用。分析指出了脚本聊天、内存记忆、固定图库与真实模型、持久化、额度一致性之间的差距，每个页面能力都列了"当前怎么实现、目标要达到什么、缺什么、用什么验证"。

这里有一个小教训：本机存在一个 Agent 配置文件，不等于当前会话已经能调用它。切换模型或角色之前先确认实际可用能力。

原型阶段的过关检查

• 审美偏好变成参考图、配色布局说明、页面范围、交互清单和验收要求
• 交接给另一个模型时，交接包有来源清单和文件校验值
• 原型允许不接数据，但关键流程必须可点击；人实际点过并记录问题
• 原型之后、写后端之前，对照 PRD 做一次差距分析

选型与计划：把维护者写进输入，把检查写进计划

9 月 25 日晚上七点五十五分到九点五十三分，两个小时里我做了三件事：改技术选型、要一份能验收的计划、把长期自主开发的要求写成一份执行提示词。这三样东西决定了后面两天 Codex 能不能一个人往前跑。

选型：我担心 hold 不住

技术分析初版给的数据层方案我没有直接接受。我问："使用 Java 后端行不行……我担心其它技术我这边 hold 不住。"接着追问能不能用 Spring AI。技术文档随即修订为 Java + Spring Boot + Spring AI，配套数据库等保留待评审。

这条做法是：在选型前告诉 AI 自己熟悉的语言、数据库、部署方式以及长期维护顾虑。变更选型时让它同步修改目录、数据访问、部署、测试和职责说明，并记录版本。维护者能不能理解和排错，是这个项目选 Java 的明确理由，不是性能，不是潮流。

计划：每阶段可演示，每阶段有人工检查

我要求按敏捷流程出实施计划，同时列出需要我提供的条件和最后的检查机制。第一版形成 S0 到 S5 六个阶段、34 个任务、11 项条件、16 条人工验收。

看完我追了一句："我没看到 API 的接口文档生成的步骤，我需要你在任务进行时有一定的文档输出，好让我做追溯和修改。"这一句让计划升到 v1.1：新增六项持续文档任务、开发同轮文档责任、版本快照和追溯规则，任务变成 40 个，人工验收 17 条。

两条做法从这里来。一是对每阶段要求输入条件、可演示结果、任务依赖、负责人、检查步骤和失败处理；资源按最晚需要的阶段准备，缺某个模型凭据只阻塞相关链路。二是用户的追问要进入计划和完成标准：发现遗漏时明确自己后续要做的动作，要求 AI 把反馈落实到任务、产物路径和验收条目。

再提醒一次：任务数说明的是拆分方式，不是工作量，也不是质量。

执行提示词：把"长期自主开发"写成能检查的要求

最后我要求目标模式的提示词引用项目文档并包含量化检查，又补充了 Docker、TDD、补充 PRD 与 Bug 记录、启停脚本、按日日志、可编辑的 Prompt 配置。它们被整理成七条工程要求 ENG-01 到 ENG-07 和十二条门禁 Q01 到 Q12。

关键在于"细化到能检查"：把"写好日志"细化为记录哪些输入输出、如何关联请求及验证；把"方便修改提示词"细化为独立配置文件、注释和修改生效检查。执行提示词写清参考材料、阶段顺序、约束、缺失条件的处理、检查证据和交付终点。

追溯链：从需求到人工验收

计划阶段的过关检查

• 把维护者熟悉的语言、数据库、部署方式与长期顾虑写进选型输入
• 每阶段写输入条件、可演示结果、依赖、检查步骤、失败处理
• 资源按最晚需要的阶段准备，缺一项只阻塞相关链路
• 执行提示词写清参考材料、阶段顺序、约束、缺条件处理、检查证据、交付终点
• 开发任务同轮产出文档（接口、决策、日志），追溯规则进计划

连续实施：决策留档、按依赖切片、验证分五层

9 月 25 日晚上十点零七分，目标模式启动。接下来一天多，Codex 在我偶尔回一句"继续"的情况下连续推进了一百多张任务卡。它能这样跑而不跑偏，靠的是三样东西：人的选择写成决策记录、每块工作独立可验证、每份验证说清自己能证明什么。

目标启动：人的选择写成可追溯决策

目标对话开始后，Codex 很快停下来问了两组问题。我回答"改用 MySQL"，并接受邮箱验证码登录、每天 5 张、上海业务日、封面不计次、成功展示后确认扣次这些默认规则。它把这些保存为 ADR-001，把 9 个用户故事和 7 项工程要求映射进 46 项 WBS，再用一个最小工程核对依赖、真实 MySQL 启停持久化和一条迁移的失败到通过。

二十分钟后它又问邮箱服务的事，我说："尚未准备，先做离线部分。"这一句决定了后面一天半的推进范围：账号、聊天、记忆、照片任务、额度这些能在本地 MySQL、HTTP 和浏览器上验证的切片先做，外部的模型、邮件、图片由替身或合成素材顶上。

两条做法：目标要说明输入材料、实施范围、终点和缺条件处理；人的选择落实到决策记录，再同步计划、配置与验证方式。以及：外部条件不齐时按依赖推进可验证的切片，每项检查注明真实组件、替代组件、已证明行为、还缺什么。比如"真实数据库下额度正确"是真的，但它不足以证明正式照片已经送到用户手上。

用失败案例推进实现，也老实记录证据缺口

工程里出现过典型的红转绿：缺表迁移先失败再通过；行为断言失败后做最小修复再定向回归。也出现过测试过了但人一看不对：TASK-105 的大图遮罩只盖住中栏，是看了实际页面才补上视口断言。

但我要如实写一个缺口。TASK-134 时点的 Q02 快照显示：66 项行为任务里，59 项"零跳过"记录、16 项重构决定，整体状态是 INCOMPLETE。这份快照里的红绿字段不能独立证明全部历史顺序，更不能用现在复跑去补造当时"先测试后编码"。所以方法论里写的是：对行为变更记录失败断言、最小修改、通过结果和是否需要重构；对资料整理类任务明确适用检查，不人为制造失败。做不到的部分就写做不到。

验证要分层，并绑定同一个版本

这张图里最容易被忽略的是中间那列。"MySQL 并发下额度正确"说明本地组件集成了，不说明外部供应商接通了；"DeepSeek 一条请求完成"说明指定请求实际完成，不说明所有失败恢复和产品闭环都通过。

还有一个"同版"问题。TASK-133 的固定运行包七项本地检查通过，但 TASK-134 到 137 又改了实现，旧包的结论不能自动覆盖新工作区。每份验证写清版本摘要、运行配置、数据和替身、执行命令、结果及边界；不能把不同版本的通过次数累加成完整验收。审计产物本身也要可解析：TASK-103 修过一个"脚本通过但输出重定向破坏了 JSON"的问题。

一张真实的任务卡

看一张 10 月 1 日深夜的卡，就能看到上面说的几件事是怎么落到一个文件里的：

# TASK-151：Tina 场景与穿搭按时间片变化（三餐、夜间居家、最短间隔）

- 状态：待验证
- 关联：用户反馈"地点一直是一个，需要按时间调整……"；TASK-143（状态池）；
  PRD §14/§16/§17；无公开接口变更，无数据库迁移

## 问题证据
用户账号 2927 在 companion_state_snapshots 中 09-26 至 10-01 的全部晚间快照
场景均为"家中"……原因：EVENING 覆盖 18:00—05:00 共 11 小时只选一条……

## 验收标准
- [x] 9 个时间片各至少 3 条场景，三餐片含餐馆与厨房/客厅，深夜片为床上/沙发居家
- [x] 日期变化必换；同日时间片变化且距上一条快照 ≥60 分钟才换
- [x] 定向测试通过：11 个测试类 40/40；全量 229 项，唯一失败为与本机运行中
      Worker 抢任务所致，停服后单独重跑 9/9 通过
- [x] 重新打包并重启；测试邮箱于 23:55 读到状态"沙发 / 浅灰色家居服套装"，
      真实 DeepSeek 回复"窝在沙发上呢，今天穿的是浅灰色的家居服"
- [ ] 用户自己的账号实测两个时间片（白天一次、晚上一次）

注意几处：问题先有数据证据再有原因；"全量 229 项 1 失败"没有写成"全量通过"，而是写明那一项为什么失败、怎么单独复跑；最后一项验收留给用户，所以状态是"待验证"而不是"已完成"。

实施阶段的过关检查

• 人的选择落为决策记录，再同步计划、配置与验证方式
• 外部条件不齐时按依赖推进可独立验证的切片，注明真实组件与替身
• 行为变更记录失败断言、最小修改、通过结果与是否重构；资料类任务不人为造失败
• 定向、本地组件、浏览器、真实供应商、用户验收五层分开写，每层写"不能说明什么"
• 每份验证绑定版本；不同版本的通过次数不累加

交付试用：先给一条能亲手走通的最小流程

9 月 26 日晚上十点三十七分到 27 日凌晨零点三十七分，两个小时，我作为用户第一次真正坐到 Tina 面前。前面一天半的工程证据，在这两个小时里暴露出三个洞：登不进去、模型不可用、记忆不知道怎么测。

第一个洞：怎么登录

我先问"有没有全部跑通"，接着问"怎么进行登录？目前邮箱没有打通"。AI 补了一个只在本机、显式开启的测试邮箱：验证码不发邮件，写进一个本地文件，手册告诉你去哪读。那是 TASK-134。

后来的 README 把这一步写成了三行命令，10 月 2 日我为了截本书的图又走了一遍：打开登录页，填一个 @example.invalid 邮箱，读文件里的六位数字，填回去。

第二个洞：聊天模型暂不可用

登录之后我报告"聊天模型暂不可用"，问密钥怎么填，然后确认"我已经写入到 .env 中"。AI 检查运行配置与进程，启用并验证了真实 DeepSeek 请求，顺手修了一个旧 Worker 进程没被识别导致重复运行的问题。那是 TASK-135：登录 → 聊天 API → 真实模型回复 → 消息与任务持久化，一次请求 166 个 token。

这里的做法是：按"凭据落盘 → 配置生效 → 进程正确 → 业务请求完成 → 数据读回"逐步核对，不能从"写入 .env"直接推定成功。

第三个洞：长期记忆不知道怎么测

基本对话通了之后我说："基本的对话是通了，但是我无法测试长期记忆是怎么做的额。"AI 去查，发现自动提取的开关是关的，14 条提取任务积压在队列里。启用、重启、处理积压之后，它用一个随机合成账号做了真实验证：第一轮说出一个事实，提取完成，API 里能看到；第二轮模型输入的"已确认的记忆"区里包含这个事实，回答准确。然后给了我一份手工步骤。那是 TASK-137。

做法：将"它会记住我"拆成可核查节点：任务入队 → 提取完成 → 有效记忆存储 → 上下文读取 → 模型输入 → 用户可见回答。检查开关和实际运行的进程，用合成事实留证据，告诉用户去哪看结果。

边界也要写：两轮仍在同一会话，近期消息也可能帮助作答。输入记忆区里有事实，证明接线生效，不能单独证明答案只来自长期记忆。跨会话的纯召回、真实纠错和遗忘，到本书发布时仍是待办。

第四件事：用户体验反馈要变成可复现行为

凌晨零点，我报告了那个失焦 Bug。AI 把发送、流式片段、窗口缩放和用户主动上滚分别检查：保留输入焦点，只在用户处于底部跟随状态时滚到底。三类失败断言之后，聊天定向 9/9、构建和本机浏览器通过。那是 TASK-136 和 BUG-048。

做法：反馈保留用户原话，再写触发步骤、实际结果和预期行为；补会失败的断言，做最小修改，然后在实际页面复查。修自动滚动的时候还要保护用户读历史的意图，否则修一个 Bug 制造另一个。

这两个小时教给我的事

这是方法论里标为"案例反思"的一条：应该更早提供一条用户能亲自完成的最小流程。它是根据这次阻碍提出的建议，还没有效率对照实验。

试用阶段的过关检查

• 一次可试用交付包含入口、测试账号取得方式、必要配置、生效步骤、预期现象、失败定位入口
• 按"凭据落盘 → 配置生效 → 进程正确 → 请求完成 → 数据读回"逐步核对
• 把抽象的 AI 能力拆成可观察的数据节点，并告诉用户去哪看
• 反馈保留原话，补会失败的断言，最小修改后在实际页面复查
• 说明本机已验的范围，用户设备、长历史、跨会话仍待验

优化批次：只读评审、一句话授权、基线先行、覆盖矩阵收口

10 月 1 日是这个项目里最特别的一天。我换到 Claude Code，全天只发了七条消息，它完成了十三个任务、十二次提交。能这样做，不是因为模型变聪明了，是因为前面六天把文件基线打好了，而这一天又加了四条新规矩。

第一条消息：只读评审

早上十点零三分，我说："这个是我 AI 女友的项目，帮我看一下，这个项目还有什么可以优化的点？"

它没有改任何代码。它读了后端核心类、前端页面、Prompt 模板、配置、脚本、PRD 和看板，跑了前端类型检查、37 个前端单测和后端离线编译，十分钟后给了一份 14 条的评审报告，分三类：产品体验（Prompt 结构与人设过薄、记忆提取缺上下文、今日状态写死、没有时间天气）、架构性能（Worker 串行、前端轮询与 SSE 双通道）、工程卫生（Git 只有一次提交、仓库 140MB、一次性脚本堆积、看板 441 行、没有 README、没有 CI）。每条都附文件路径或命令证据，已知外部阻塞单列一段不展开。

它的一句话结论我记得很清楚："工程底座扎实，差距不在稳，而在像不像一个人和别人能不能跑起来。"这个判断来自读代码，不是印象。

第二条消息：按你的建议来改

十点三十八分，我回了六个字。接下来三十二分钟，它按报告的推进顺序做了六个任务，每个任务一次带编号的提交：README 与按任务提交规范、聊天 Prompt 拆 system/user 并注入当前时间、Worker 线程池与前端停轮询、状态池与记忆提取语境、仓库瘦身、测试健康与 CI。

这里有一条新规矩：改动之前先跑一次全量测试记基线。改动前全量 196 项，4 失败 4 错误，原因是本机 .env 的开关泄漏进测试、迁移数写死 14 而实际 16、MySQL 连接耗尽。这些和功能无关，被登记为基线、归入单独的任务，批次末全量 208/208，基线 8 项清零。环境问题和功能问题分开算，每个功能任务的"定向通过"才有参照。

第三条消息：不用我确认了

十一点三十一分："查看 PRD，然后补全剩余的需求，按你的推荐来，不用我确认了，有问题我测试的时候再看。"我主动把确认点后移到了实测。

它通读 PRD 列缺口，做了四个任务：照片真正能发出来（人物参考图集、Gemini 生图、生成资产走原有"看到才扣次"流程）、说"发张自拍""换一套"就有反应、Tina 主页的今日动态与相册、以及一份 PRD 覆盖矩阵。覆盖矩阵对照 PRD §5 到 §30 逐章写"已实现 / 部分 / 未做"，未做的写原因（真实邮件、生产存储、上下文触发发图、会员积分、情绪照），最后给了一份 8 步实测清单。全量后端 222/222、前端 41/41。

这是收口的新规矩：批次结束不只汇报做了什么，还对照需求文档把每章状态标出来，"未做"必须带原因，再给用户一份按顺序执行的实测清单。

后四条消息：试用反馈

下午一点四十分，我在配 .env 时说："这几个配置是做什么的，你要给我注释清楚呢。"它重写了照片相关五项变量的注释，按"变量 / 作用 / 不配会怎样"列表。配置项的注释要能回答"不配会怎样"，这一条就是从这句追问来的。

晚上七点三十五分："能不能接一些外部的工具，我发现有一些天气和时间的问题，答不出来。"它先把两件事拆开：时间在上午的批次里已经注入系统提示，我测的时候跑的是旧包，重启就好；天气确实没有数据源，接 Open-Meteo，直接注入系统提示而不走模型工具调用，理由是流式回复里嵌工具调用链路复杂、不好测。然后重新打包、重启、用测试邮箱真实提问，七点四十一分 Tina 回"现在快七点四十二啦，我这边上海是多云，22 度左右"，再从诊断日志里核对模型确实收到了那行天气。

深夜十一点三十九分："我觉得需要根据时间段调整地点。不能一直是一个。"它没有直接改，先查数据库，列出我的账号从 9 月 26 日起晚间场景一律"家中"的六条快照，归纳三个原因，复述方案等我补充。我补了三条口语规则：晚上在家床上沙发、白天女生喜欢去的地方随机、三餐配餐馆或厨房客厅、短时间内不能换至少一两个小时。它把这些翻成数字写进验收标准：9 个时间片各不短于 2 小时、深夜片只有床上或沙发、三餐片含餐馆与厨房客厅、地点最短间隔 60 分钟、穿搭按外出 / 居家 / 睡衣三类每日一套，对外 4 个时段与接口不动。

这一天的六条新规矩

1. 只读评审先行。项目能跑但不知道改什么时，先要一份带证据、分三类、排优先级的评审，评审期间不改代码。
2. 一句话授权后的批次自治。前提是评审已经把范围、顺序、证据写清；AI 按序拆独立任务，每任务一次提交、一张任务卡，最后一项验收留给用户。
3. 基线先行。批次前跑一次全量记失败清单，既有失败单独立任务，不和功能改动混在同一次提交。
4. 真实链路四步。改了模板、配置或打包资源，定向测试之后固定补：打包、重启、测试账号真实请求、读诊断日志核对模型实际输入。
5. 反馈先查数据再量化。体感反馈先用数据或日志证实，分辨是旧包、配置、Bug 还是能力缺失；口语规则翻成数字写进验收标准。
6. 覆盖矩阵收口。批次结束逐章标"已实现 / 部分 / 未做与原因"，再给实测清单；配置注释能回答"不配会怎样"。

账本与追溯：任务卡、看板、日志、证据，以及方法论本身的两层

这本书里每一个数字都能指回一个文件，不是因为我记性好，是因为项目从第一天就在记账。这一章讲账记在哪、怎么分层，以及方法论自己为什么也要分成"案例"和"手册"两层。

项目里的账长什么样

ai-girlfriend/
├── STATUS.md                 看板：未完成任务 + 最近 10 条验证（49 行）
├── tasks/
│   ├── TASK-001.md … TASK-153.md   一件事一张卡
│   └── ARCHIVE.md            已完成任务、历史验证、9 月工作记录
├── logs/2026-10-01.md        按日工作日志：几点、哪个任务、跑了什么、结果
├── doc/
│   ├── prd/                  PRD v0.1 与工程补充需求
│   ├── planning/             WBS 计划、验收手册、文档规则、执行提示词
│   ├── traceability.md       每行任务对回需求与接口
│   ├── process/              对话快照与原话索引（TASK-006 / 138 / 152）
│   ├── evidence/             每份验证的 JSON：版本、组件、命令、结果
│   ├── reports/              评审报告、PRD 覆盖矩阵
│   └── bugs/                 BUG-001 … BUG-048
└── 编程方法论/
    ├── 方法论手册.md          跨项目检查清单 v0.1
    ├── 方法论提炼.md          本项目案例，23 项做法
    ├── 阶段时间线.md          20 节
    ├── AI交互记录/            按日记录
    └── whitepaper/           本书

五层，每层只引用下一层

这个分层是 10 月 2 日才明确的。之前方法论只有一个文件，到第 23 项已经两万多字，事实记录、方法提炼、教学素材三层写在一起，按项目线性增长，新项目很难直接套用。所以拆成两层：案例继续按阶段追加，保留每一项"真实发生的事"和边界；手册只放可复用的检查项，带版本记录，每轮只改变化的条目。手册在新项目里好不好用，到本书发布时还没有验证过。

为什么 10 月 1 日之前只有一次提交

这是这个项目最大的账务漏洞，我要老实写。到 9 月 30 日，138 张任务卡的全部产出都在同一个初始提交里，任务卡上"关联提交"写的是"无"。这意味着无法按任务回滚、无法按任务看 diff，"任务 → 提交"这条追溯链是断的，和 Q11 追溯门禁的目标矛盾。10 月 1 日的评审把它列为工程卫生第一条，从 TASK-140 起每个任务一次带编号提交。

手册第三节由此定了四条：提交信息以任务编号开头，一任务至少一次提交，文档任务也提交；"关联提交"在提交后立刻回填，不留"待补充"过夜；看板只放未完成任务与最近验证，已完成移入归档；过程证据放 doc/process/ 与 doc/evidence/，方法论文档只引用不复制。

方法论自己怎么更新

方法论到本书为止更新过三轮：9 月 25 日建目录（TASK-006，Codex），9 月 28 日补目标实施与真实试用（TASK-138，Codex），10 月 2 日补优化批次并拆出手册（TASK-152，Claude Code）。三轮走的是同一套流程：

1. 读真实对话。不是凭印象写"当时我说了……"，而是从 ChatGPT、Codex、Claude Code 的会话记录里取用户原话与助手公开文本，排除工具回传、系统提醒和自动续跑包装，保存文件、行号、消息 ID。
2. 与工程证据交叉核对。每句原话对到任务卡、提交号、日志；助手回复里说的"通过"要在任务卡里找到对应记录。
3. 区分四种口径。用户原话、AI 公开回复、当时的验证记录、本轮的提炼，分别标注；没有原始记录的只写"用户回顾"，不补造提示词或回复。
4. 定向文档校验。范围内文档存在、本地链接不失效、快照与源文件逐条一致、业务源码摘要未变、密钥模式零命中。10 月 2 日这一轮是 12 项检查全过，48 条消息与源文件一致，270 个业务文件未动。
5. 不复跑业务。方法论是文档任务，不改业务代码、不重跑历史测试，历史结论原样引用并注明"本轮未复跑"。

跨工具交接的最小上下文

10 月 1 日 Claude Code 接手时读的是：STATUS.md、相关任务卡、PRD、编程方法论/ 和核心代码。它没有读过 Codex 的任何会话，也没有人口头交代。能接上，说明只要看板、任务卡和方法论保持最新，换工具的最小上下文就是这几份文件。反过来，两种工具的任务卡格式应该统一，这一条也进了手册。

踩过的坑、还不能证明的事，与十问十答

七天里翻过的车，有的修好了，有的只是记下来了。这一章先列坑，再列到本书发布时还没有证据的事，最后是我自己最常被问到的十个问题。

七天里的十个坑

还有三个小坑写在手册里：两张任务卡的提交号没及时回填；TASK-151 跨日没提交；每次冒烟留下的测试账号没集中登记。

到本书发布时还不能证明的事

• 效率是否提升。只有日志时间戳，没有每任务耗时、人工介入点、返工轮次和费用的系统记录。"七条消息十三个任务"是事实，"省了多少时间"没有数字。
• 长期记忆的纯召回。验证时两轮仍在同一会话，跨会话、隔离近期历史的召回和真实纠错 / 遗忘还没做。
• 真实图片链路。Gemini 生图代码与假服务测试在，真实调用没发起过，人物一致性要人看图。
• 完整用户验收。真实邮件、CI 远端运行、17 条 UAT、用户按 8 步清单实测，都还是待办。
• 手册的可迁移性。它只从一个项目抽取，还没在第二个项目里用过。
• 模型分工。三个工具在不同阶段被实际使用过，但没有同题对照，不能给能力排名。

十问十答

方法论手册 v0.1、术语对照表、配图来源与版本记录

附录一是从全书抽出来的检查清单，可以单独打印；附录二是书里出现过的词；附录三是每张真实配图从哪来；附录四是这本书和方法论文档的版本关系。

一、方法论手册 v0.1：十个阶段的过关检查

使用方式：新项目按阶段顺序过一遍，没过的项不进入下一阶段；每条检查都应能回答"看哪个文件、跑哪条命令能证明"，证明不了就写"待补充"。人负责决定重点、审美、维护方式、外部资源和验收口径；AI 负责把决定变成文档、代码和检查。

1. 需求讨论

• 每轮开头说明本轮解决的问题与产物，AI 跑题时纠正阶段
• 脑暴结果分成首版必做、后做、待确认三栏
• 每个功能写成"用户说什么 → 系统做什么 → 用户看到什么 → 失败怎么办"
• 表述矛盾由人明确结论并更新文档；AI 早期建议不视为已批准
• 过关：Markdown PRD 落盘，每个功能能追溯到一个具体场景

2. 视觉选择与原型

• 审美偏好变成参考图、配色布局说明、页面范围、交互清单和验收要求
• 交接给另一个模型时，交接包有来源清单和文件校验值
• 原型允许不接数据，但关键流程必须可点击
• 过关：下一工具只读交接包就能完成原型；人实际点过关键流程并记录问题

3. 技术分析与选型

• 把维护者熟悉的语言、数据库、部署方式与长期顾虑写进输入
• 每个页面能力列"当前实现 / 目标 / 缺口 / 验证方式"
• 选型变更时同步目录、数据访问、部署、测试与职责说明
• 过关：差距表与未决项分开，静态演示与真实链路分别说明

4. 计划与执行提示词

• 每阶段写输入条件、可演示结果、依赖、检查步骤、失败处理
• 资源按最晚需要的阶段准备，缺一项只阻塞相关链路
• 执行提示词写清参考材料、阶段顺序、约束、缺条件处理、检查证据、交付终点
• 开发任务同轮产出文档（接口、决策、日志），追溯规则进计划
• 过关：任务数只表示拆分方式，不作为工作量或质量指标

5. 连续实施

• 人的选择落为决策记录，再同步计划、配置与验证方式
• 外部条件不齐时按依赖推进可独立验证的切片，每项检查注明真实组件与替身
• 行为变更记录失败断言、最小修改、通过结果与是否重构；资料整理类任务不人为造失败
• 每任务至少一次带编号提交，任务卡填提交号
• 过关：每条结论注明版本与真实 / 替代组件

6. 验证分层

• 定向行为检查、真实本地组件、实际浏览器、真实供应商、用户验收五层分开写
• 每份验证写版本、运行配置、数据与替身、命令、结果、边界
• 改动前先跑一次全量测试记基线，既有失败单列为环境任务，再开始功能改动
• 审计产物本身可解析，脚本输出不要写坏自己的 JSON
• 过关：不同版本的通过次数不累加成完整验收

7. 交付试用

• 一次可试用交付包含入口、测试账号取得方式、必要配置、生效步骤、预期现象、失败定位入口
• 配置项注释能回答"作用是什么、不配会怎样"
• 真实链路固定四步：打包 → 重启 → 测试账号真实请求 → 读诊断日志核对模型实际输入
• 改了模板或配置后提醒用户重启，避免把"旧包未生效"当成功能缺失
• 过关：用户能自己完成一条最小流程

8. 反馈修复

• 保留用户原话，先用数据或日志证实现象，再找根因
• 分辨是 Bug、未生效配置、能力缺失还是旧版本未重启
• 用户的口语规则翻成数字写进验收标准
• 补会失败的断言，做最小修改，在实际页面或真实链路复查，说明仍未验的范围
• 过关：行为恢复，剩余限制明确，用户能重复检查步骤

9. 优化评审与批次推进

• 评审只读进行，每条优化点附文件路径或命令证据，分产品体验、架构性能、工程卫生三类并排优先级
• 已知外部阻塞单列，不在评审里重复展开
• 人一句话决定采纳范围后，AI 按顺序拆任务、逐任务提交、任务卡记录首轮失败与修复
• 批次结束汇报表：任务、提交、做了什么、待用户验证什么
• 过关：工作区干净，每任务一次提交，全量测试结果附在收口任务

10. 收口与复盘

• 对照需求文档逐章写"已实现 / 部分 / 未做与原因"，附实现位置
• 给用户一份按顺序执行的实测清单
• 方法论更新时读取真实对话原话，区分用户原话、AI 公开回复、工程证据与本轮提炼
• 记录每任务开始与结束时间、返工轮次、费用（本项目尚未系统记录，属待补）
• 过关：建议与已发生结果分别标注；进度先回答"可用什么、卡在哪、下一步谁做什么"

任务卡最小字段

状态（待开始 / 进行中 / 待验证 / 已完成 / 阻塞）、负责人、创建时间、关联（需求条目、评审项、上游任务、是否改接口或迁移）、关联提交、目标、验收标准（勾选项，最后一项通常是用户实测）、当前记录、交付物与验证入口、下一步与阻塞、完成记录与验证（命令、结果、首轮失败、未做什么）。Codex 与 Claude 两种工具的任务卡使用同一套字段。

提交与追溯

• 提交信息以任务编号开头，一任务至少一次提交；文档任务也提交
• 任务卡"关联提交"在提交后立刻回填，不留"待补充"过夜
• 状态看板只放未完成任务与最近验证，已完成移入归档文件
• 过程证据放 doc/process/ 与 doc/evidence/，方法论文档只引用不复制

五条常用提示词

以下为本项目重写的示例，不是历史原话，也未在新项目实测：

二、术语对照表

PRD

产品需求文档。本项目是一个 Markdown 文件，写谁用、什么场景、首版做什么不做什么。

首版 / MVP

最小的能用的版本，砍到再砍就不成立。

场景化定义

不写"支持 X"，写"用户说什么、系统做什么、用户看到什么、失败怎么办"。

基线

所有人和模型共同出发的那份文件；测试基线则是改动前的失败清单。

交接包

把一个决定打包成另一个模型能直接读的一组文件：参考图、说明、范围、提示词、来源清单。

SHA-256

文件的指纹，用来确认交接的是选中的那一版。

静态原型

只有页面和点击、没有真实数据的网页，用来看长什么样。

差距分析

每行一个能力，四列：现在怎么做、目标、差什么、怎么验。

WBS

工作分解结构，把阶段拆成可独立领走、有依赖和验收的任务。

UAT

用户验收测试，人亲手按清单试一遍，本项目 17 条。

ENG / Q 编号

七条工程要求与十二条检查门禁的编号，让任务卡能写"本任务满足 ENG-06、Q06"。

目标模式

Codex 里给一个目标文件让它连续自主推进，只在需要人决定时停下来问。

ADR

架构决策记录：决定了什么、为什么、还有什么没定。

切片

一块能独立验证的功能，不等整个产品做完就能证明它对。

替身

外部服务没接通时顶替它的假组件，比如本机测试邮箱。

红转绿 / TDD

先写会失败的测试，再写最少的代码让它过；失败那一步是证据。

同版证据

验证结果和被验证的代码是同一个版本；代码改了，旧的"通过"只是历史。

门禁

阶段放行前必须通过的检查清单。

读回

做完之后从数据库或接口把结果再读出来，而不是相信"写入成功"。

Worker

后台干活的进程：调模型、写回复、提取记忆、做照片。

测试邮箱

只在本机生效的假邮件服务，验证码写进文件。

system / user 消息

给模型的两种话：system 说你是谁和规则，user 说用户刚说了什么。

诊断日志

Worker 记下的每次模型完整输入与回复，确认"模型真的知道"要看这里。

真实链路四步

打包、重启、测试账号真实请求、读诊断日志核对模型输入。

覆盖矩阵

需求文档每章一行，已实现 / 部分 / 未做三种状态，未做写原因。

只读评审

不改代码，只读代码与文档，输出带证据和优先级的优化清单。

批次自治

人一句话决定范围后，AI 按顺序拆任务、逐任务提交、最后一项验收留给用户。

任务卡

一件事一张 Markdown 文件，写目标、验收、做了什么、怎么验的。

看板

STATUS.md，未完成任务加最近验证，一屏能看懂。

追溯表

每行一个任务，对应需求、接口、证据与边界。

对话快照

会话记录里的用户原话与 AI 公开回复按原样存成 JSON，带行号和消息 ID。

手册 / 案例

方法论的两层：手册是可复用检查清单，案例是本项目每条做法的出处与边界。

三、真实配图来源

真实截图取自 2026 年 10 月 2 日凌晨本机：静态原型经本机静态服务器（8877 端口）打开；Tina 应用由 10 月 1 日 23:54 重启的实例提供（前端 15173 端口），账号为本机测试邮箱账号。任务卡、看板、日志、覆盖矩阵的文字按原文抄录。

示意插画 10 张由 AI 生成（gpt-image-2.5，经 Grsai 接口，10/10 成功），统一暖陶风，仅用于辅助理解；提示词与结果记录在本机 ~/grsai_temp_log/2026-10-02/，对应关系见 src/images/gen/rename_map.json。流程与结构图 8 张为内嵌 SVG，由 src/diagrams/gen_diagrams.py 生成，颜色跟随页面主题。

四、版本记录

方法论的 Markdown 原文继续保留在项目仓库 编程方法论/ 下，本书不替代它们；下一版白皮书应在用户完成实测、手册在第二个项目使用之后再写。