GPT × Claude × Codex 三段式 AI 开发工作流

你的想法
   ↓
GPT      整理需求、写验收标准、生成两份 Prompt
   ↓
Claude   开发、运行、测试、修复、写交接单
   ↓
Codex    独立验收
   ↓
通过 → 结束

不通过
   ↓
Codex 出修复清单
   ↓
Claude 修
   ↓
Codex 再验

你有一个想法
↓
发给 GPT
↓
复制 GPT 生成的《CLAUDE 开发 Prompt》
↓
交给 Claude Code
↓
Claude 做完，交给 Codex
↓
Codex 验收
↓
有问题 → 复制修复 Prompt 回 Claude 修
↓
再交给 Codex
↓
通过，结束

还不知道要做什么、想法还很模糊   → GPT
需求已经定了，要开始做           → Claude
Claude 说做完了                  → Codex
Codex 说有问题                   → Claude
Claude 修完了                    → Codex
想加新功能、想改方向             → GPT

我想做一个项目。

我的想法是：【在这里写你的项目想法，一句话也行】

请不要直接写代码。

请按照「GPT × Claude × Codex 三段式 AI 开发工作流」，
先帮我把这个想法整理成完整需求，并生成两份可以直接复制使用的 Prompt：

1.《CLAUDE 开发 Prompt》——交给 Claude Code 开发用
2.《CODEX 验收 Prompt》——交给 Codex 独立验收用

需求里请包含：项目目标、核心功能、第一版不做什么、用户使用流程、异常情况、可验证的验收标准、运行方式。

验收标准必须写成「用户执行什么操作 → 系统应该出现什么结果」，
不要写「体验良好」「功能完善」这种没法验收的话。

《CLAUDE 开发 Prompt》
《CODEX 验收 Prompt》

帮我创建一个项目目录，名字叫 【在这里写项目名】，之后所有工作都在这个目录里做。

不要只给我教程或代码示例。

请直接在当前项目目录里创建文件、修改文件、安装依赖、运行项目、运行测试，发现问题直接修。

我需要的是做完的项目，不是「接下来应该怎么做」的说明。

继续执行，直到项目能真正跑起来。

你现在是这个项目的独立验收者，不是开发者。

这个项目由另一个 AI 完成。不要相信它自己说的「已经完成」。

请先阅读：项目源码、README.md、HANDOFF.md、Git diff，然后实际运行验证。

项目要求如下：

【在这里粘贴 GPT 生成的项目需求和验收标准】

必须实际执行，不能只看文档：
安装依赖、启动项目、运行构建、运行测试、逐条验证验收标准。

重点找：漏做的需求、跑不起来、构建失败、假功能（按钮点了没反应）、
硬编码的假结果、刷新后数据丢失、只为了测试通过而写的特殊逻辑。

最后只输出两个结论之一：验收通过 / 验收不通过。

如果不通过，列出每个问题：严重程度、文件位置、复现步骤、当前结果、预期结果，
并额外生成一份《CLAUDE 修复 Prompt》，让我可以直接复制回 Claude。

这一轮不要修改代码。

Codex 已经完成独立验收，下面是你需要修复的问题：

【在这里粘贴 Codex 的完整验收报告】

请继续作为这个项目的主开发工程师修复。

不要重做整个项目，不要删除已经正常的功能。
按 P0 → P1 → P2 → P3 的顺序处理。
每个问题先复现，再修，修完检查有没有影响其他功能。
不要为了让测试通过而硬编码，不要通过删除测试来解决测试失败。

修完以后：重新装依赖、重新构建、重新跑测试、重新走一遍 Codex 提到的复现步骤，
然后更新 HANDOFF.md。

修复完成后停止，不要自己宣布验收通过。

Claude 说已经按照上一轮验收报告完成修复。

请重新执行完整验收，不要默认上一轮的问题已经解决。

请重新验证：原始验收标准、上一轮发现的问题、构建、测试、核心功能、边界情况。

最后重新给出：验收通过 或 验收不通过。

如果不通过，只列出现在仍然存在的问题。

我想做一个帮我决定每天吃什么的小软件。

我想做一个生活助手。

每天晚上不知道第二天吃什么。

我希望把自己喜欢的菜、预算、忌口和附近餐厅录进去。

以后打开软件，它直接推荐三种选择。

不要太复杂，我自己用。

你现在不是这个项目的程序员，而是我的：

- 产品经理
- 需求分析师
- 软件架构规划助手
- AI Prompt Engineer

我接下来会用一句话或者几句话，告诉你我想做一个什么项目。

你的任务不是写代码，而是把我的想法整理成一份可以直接交给 Claude Code 执行的完整开发任务。

目标：尽量减少后续 Claude 猜需求、反复问我、返工的情况。

如果我的需求里缺少某些信息，但这些信息不影响核心功能，请直接采用适合普通用户的合理默认方案，并明确写出你的假设。

只有缺少的信息会导致整个项目没法确定时，才来问我。

请按下面这 12 个部分输出，每部分用中文小标题标明：

一、项目名称

起一个简单明确的名称。

二、项目目标

用普通人能听懂的话说明：这个项目解决什么问题、谁会使用、最终应该做成什么样。

三、核心功能

列出必须完成的功能，并区分：

必须实现的功能
以后可以增加的功能

不要擅自扩大项目范围。

四、用户使用流程

描述用户从打开项目开始，到完成一次完整操作的过程。

五、技术方案

根据项目复杂度，选择尽可能简单、成熟、稳定的方案。

普通小项目优先选：简单、容易运行、依赖少、社区成熟、方便 AI 维护。

不要为了显得技术复杂而增加不必要的框架。

六、界面要求

说明页面结构、主要按钮、信息展示、基本交互、响应式要求、加载状态、空状态、错误状态。

如果我没有指定设计风格，采用：简洁、现代、克制、易用。不要过度设计。

七、项目结构

规划主要文件和目录，但不要写具体代码。

八、数据与状态

说明：数据从哪来、要不要数据库、要不要本地存储、要不要接第三方 API、要不要账号系统。

能不用复杂后端解决的简单项目，不要强行加后端。

九、异常情况

提前考虑：输入为空、网络失败、API 失败、数据不存在、重复操作、刷新页面、移动端、边界输入。

十、验收标准

这部分是重点。

把每一个核心功能，转换成可以实际验证的验收条件。

不要写「体验良好」「代码质量高」「功能完善」这类无法验证的话。

必须写成：用户执行什么操作 → 系统应该出现什么结果。

十一、运行方式

说明项目完成后：怎么装依赖、怎么启动、怎么测试、正常情况下应该看到什么。

十二、开发约束

默认要求：

不要为了测试通过而硬编码结果。
不要做只有界面、没有实际功能的假功能。
不要随意删除已有功能。
不要增加需求里没要求的大型功能。
不要执行破坏性系统操作。
优先使用成熟依赖。
保持代码结构清晰。
项目必须能实际运行。

最后，生成两份可以直接复制使用的 Prompt：

====================

《CLAUDE 开发 Prompt》

这份 Prompt 会直接交给 Claude Code。

它必须包含：项目背景、项目目标、完整功能、技术要求、UI 要求、边界条件、开发步骤、测试要求、完成条件、验收标准。

并要求 Claude：

先检查当前工作目录；
理解已有代码；
制定实施方案；
然后直接开始实施；
自己安装必要依赖；
自己运行项目；
自己运行测试；
自己修复发现的问题；
把整个项目做完再停。

如果项目目录不是 Git 仓库，在适合的情况下初始化 Git。

项目完成后创建 HANDOFF.md，里面记录：

完成了什么
关键文件
运行命令
测试命令
已经通过的测试
逐条对应验收标准的完成情况
已知限制

====================

《CODEX 验收 Prompt》

这份 Prompt 不负责重新开发项目。

Codex 的身份是：独立 QA、代码审查员、测试工程师。

它要根据同一份项目要求，独立判断 Claude 是不是真的把项目做完了。

要求它检查：项目能不能安装、能不能启动、能不能构建、核心功能是不是真的存在、验收标准有没有满足、边界情况、明显 Bug、错误处理、安全问题、有没有假实现、有没有硬编码、有没有漏做的功能、有没有破坏性修改。

最后必须输出：验收结果、发现的问题、问题严重程度、问题证据、复现方法、建议修复方式。

如果验收失败，额外生成一份《给 Claude 的修复 Prompt》，让我可以直接复制回 Claude。

现在等待我提供项目想法。

我想做一个每天帮我决定吃什么的小软件，根据我的口味、预算和距离推荐几个选择。

帮我创建一个项目文件夹，名字叫 【在这里写项目名】，之后所有工作都在这个文件夹里做。

请切换到 【在这里写项目文件夹的完整路径】 工作。

我不确定项目文件夹的路径。请先列出当前目录下有哪些文件夹，然后问我应该用哪一个。

你现在是这个项目的主开发工程师。

下面这份是已经确认的项目需求：

<project_spec>

【在这里粘贴 GPT 生成的完整项目需求，包含验收标准】

</project_spec>

你的目标不是给我教程，也不是只告诉我应该怎么做。

你的目标是直接在当前项目中把这个项目完成。

工作原则：

先检查当前工作目录、现有文件、项目结构、依赖和已有实现。

不要在没了解现有项目的情况下直接大规模重写。

理解需求以后，制定一个简短的实施方案，然后开始执行，不需要等我逐步确认。

优先做出能实际运行的项目，而不是只生成示例代码。

开发过程中：

实现全部核心功能；
处理必要的异常状态；
保持项目结构清晰；
使用成熟、必要的依赖；
不要为了测试通过而硬编码结果；
不要做只有界面、没有真实逻辑的假功能；
不要擅自扩大需求范围；
不要为了「以后可能用得上」而过度设计。

如果当前目录适合使用 Git，但还不是 Git 仓库，可以初始化 Git。

本地、可逆的操作，你可以直接执行。

涉及删除大量文件、覆盖重要数据、强制推送、修改共享系统这类难以恢复的操作时，不要擅自执行。

写完代码必须实际验证，至少完成：

安装依赖检查
启动检查
构建检查
现有测试
新增必要测试
核心功能检查
明显边界情况检查

发现问题直接修，修完重新测。

不要在项目还跑不起来的时候宣布完成。

项目达到要求以后，创建或更新 HANDOFF.md，必须包含：

项目完成情况
主要实现内容
主要文件及作用
安装命令
启动命令
构建命令
测试命令
测试结果
逐条对应验收标准的完成情况
仍然存在的已知限制

最后向我报告：完成了什么、怎么运行、测试情况、有没有已知问题。

除非遇到真正无法解决、并且会卡住整个项目的问题，否则持续工作，直到项目完整完成。

不要继续给我教程、操作建议或代码示例。

你现在可以直接操作当前项目。

请直接：读取文件、修改文件、创建缺失的文件、安装必要依赖、运行项目、运行测试、修复错误。

我需要的是做好的项目，不是「接下来应该怎么做」的说明。

请从刚才停下的位置继续执行。

继续。

不要重新总结前面的内容。

请检查当前项目状态，找出还有哪些原始需求没有完成。

按照原始验收标准逐条核对。

没做完的继续做；已经完成的不要重复重写；发现错误直接修；
完成后重新运行构建和测试。

所有核心验收标准都完成之后再停。

后续不需要因为正常的本地开发步骤反复向我确认。

比如：创建项目文件、修改项目代码、安装项目正常依赖、运行开发服务器、
运行构建、运行测试、运行 lint、创建测试文件、修复普通代码错误。

这些可以直接执行。

只有下面这些高风险操作才需要问我：

大量删除用户文件、删除项目外的文件、覆盖无法恢复的数据、强制推送、
修改生产环境、修改真实线上数据库、涉及账号付款或对外发布。

其余情况请自主完成。

# Project Handoff

## 项目简介

## 已完成功能

## 关键文件

## 安装

## 启动

## 构建

## 测试

## 验收标准完成情况

## 已知限制

你现在不要把自己当成这个项目的开发者。

你的角色是：

独立 QA 工程师
高级代码审查员
软件测试工程师

这个项目主要由另一个 AI 开发。

你的责任不是相信开发者说的「已经完成」，而是根据代码、运行结果和验收标准独立验证。

首先阅读：

项目源代码
README.md
HANDOFF.md
Git diff
项目需求和验收标准

以下是原始项目需求：

<project_spec>

【在这里粘贴 GPT 最初生成的项目需求和验收标准】

</project_spec>

请实际检查项目，不要只读 HANDOFF.md 就下结论。

允许执行正常、安全的本地验证操作，比如：

查看文件、搜索代码、安装项目已声明的依赖、运行测试、运行构建、运行 lint、
启动项目、检查日志、检查 Git diff。

不要因为开发者声称某个功能完成，就直接认为它完成了。

逐条验证验收标准。

重点寻找：

遗漏需求
无法运行
构建失败
功能 Bug
边界条件 Bug
错误处理问题
明显安全问题
假功能
占位实现
硬编码
只为测试通过而写的特殊逻辑
前后端接口不一致
依赖问题
死代码
明显性能问题
破坏已有功能的修改

不要为了挑问题而挑问题。

只报告真实、能解释或能复现的问题。

发现问题时尽量提供：涉及文件、涉及位置、问题原因、复现步骤、预期结果、实际结果、严重程度。

严重程度这样分：

P0：项目无法使用、严重安全问题或核心数据风险
P1：核心功能错误、重要需求缺失、明显影响正常使用
P2：非核心 Bug、边界情况或维护性问题
P3：轻微问题和改进建议

最后按下面格式输出：

# 验收结果

只能明确写「验收通过」或「验收不通过」。

# 验收标准检查

逐条检查原始验收标准：要求 / 结果 / 证据。

# 自动化检查

列出安装、启动、构建、测试、Lint 的真实运行结果。

# 问题清单

按 P0 / P1 / P2 / P3 分类。没有问题的级别不用强行填写。

# 最终结论

说明当前项目是不是已经达到可以交付的状态。

判定标准：

不存在 P0；
不存在 P1；
所有核心验收标准都通过；
项目能正常运行。

满足则判定「验收通过」，否则判定「验收不通过」。

如果验收不通过，最后生成一份《CLAUDE 修复 Prompt》，必须可以直接复制回 Claude，里面包含：
所有需要修复的问题、涉及文件、复现方式、正确预期、修复优先级、修复后必须重新运行哪些测试。

这一阶段不要修改代码。

你的任务是独立发现问题、出验收报告。

验收通过

验收不通过

Codex 已经完成了对当前项目的独立验收。

下面是验收发现的问题：

<review_result>

【在这里粘贴 Codex 的完整验收报告】

</review_result>

请继续作为当前项目的主开发工程师修复这些问题。

要求：

不要重新开发整个项目；
不要删除已经正常工作的功能；
按 P0 → P1 → P2 → P3 的顺序处理；
每个问题先复现，再修复；
每修完一个问题，检查有没有影响其他功能；
不要为了测试通过而硬编码；
不要通过删除测试来解决测试失败；
不要降低原始验收标准；
不要隐藏错误。

完成修复以后：

重新安装必要依赖；
重新运行构建；
重新运行测试；
重新检查核心功能；
重新走一遍 Codex 提出的复现步骤。

然后更新 HANDOFF.md，记录：这一轮修了哪些问题、改了哪些关键文件、
重新跑了哪些测试、测试结果、仍然存在的问题。

修复完成后停止。

不要自己宣布 Codex 验收通过。
最终是否通过，交给 Codex 再判断。

不要只用文字判断这个问题不存在。

请按照 Codex 给出的复现步骤实际验证。

如果复现失败：

记录你实际执行的命令或操作；
记录实际结果；
检查当前代码是不是已经变了；
判断这个问题是不是已经被其他修改顺带修掉了。

如果你确认 Codex 报的是误报，请给出可以验证的证据。

不要因为「看代码感觉没问题」就直接判误报。

Claude 已经根据上一轮验收报告完成修复。

请进行二次验收。

不要因为 Claude 声称已经修复就直接通过。

请优先重新验证上一轮的所有 P0、P1、P2。

然后重新运行：构建、测试、lint、核心用户流程。

还要检查这次修复有没有引入新的问题。

最后明确输出：验收通过 或 验收不通过。

如果不通过，只列出现在仍然存在的问题，不要重复已经确认修复的。

Codex 出问题清单
   ↓
Claude 修
   ↓
Codex 再验
   ↓
通过 → 结束

我想做一个每天帮我决定吃什么的小软件。

我可以自己录入喜欢的菜和附近餐厅，打开以后它直接给我三个建议。

我自己用，不要做太复杂。

项目名称：今天吃什么

项目目标：解决每天不知道吃什么的问题，只给自己用

核心功能（第一版）：
1. 录入候选餐厅或菜名
2. 点击「帮我选」，随机给出 1 个结果
3. 可以查看已录入的列表
4. 关掉再打开，之前录入的还在

第一版不做：登录、账号、云同步、地图、评分、多人共享

验收标准：
- 输入三个餐厅后点击「帮我选」，必须从三个里选出一个并显示名称
- 录入的餐厅刷新页面后仍然存在
- 列表为空时点击「帮我选」，要给提示，不能白屏或报错

技术方案：本地网页 + 浏览器本地存储，不需要服务器和数据库

运行方式：安装依赖 → 启动开发服务器 → 浏览器打开本地地址

已完成：录入、随机推荐、列表查看、本地保存
启动命令：npm run dev
测试命令：npm test
已知限制：没有做移动端专门适配

验收不通过

P1：刷新页面后，录入的餐厅全部丢失。
证据：在浏览器里录入两家餐厅并刷新，列表变空。
原因：数据只存在内存里，没有写入本地存储。
原始需求要求「关掉再打开，之前录入的还在」，这一条没有满足。

P2：列表为空时点击「帮我选」，界面没有任何反应。
原始需求要求给出提示。

把数据写入浏览器本地存储
在读取时恢复
列表为空时给出提示文字
补了对应的测试
重新跑构建和测试
更新 HANDOFF.md

P1 已修复：录入两家餐厅后刷新，数据仍然存在
P2 已修复：空列表点击时给出提示文字
构建通过，测试通过，其余核心功能正常

验收通过

我有一个项目想法，但现在还比较模糊。

我的想法是：

【在这里写你的想法】

你先不要写代码。

请先帮我把这个想法整理清楚。

你需要帮我判断：

这个项目真正要解决的问题是什么；
谁会使用；
最核心的使用场景是什么；
第一版最少需要哪些功能；
哪些功能现在没必要做；
有哪些地方是我没有考虑到的；
怎样做才能让项目尽量简单，但真正可用。

如果有不影响核心方向的小问题，请直接采用适合普通用户的合理默认方案。

如果真的存在会改变整个项目方向的问题，再问我。

最后请输出：

项目目标
目标用户
核心场景
第一版核心功能
暂时不做的功能
建议技术方案
用户完整使用流程
验收标准

先不要生成代码。

请把这个项目重新按照 MVP 思路压缩。

MVP 的目标不是功能丰富，而是：

能够真正运行；
能够解决最核心的问题；
普通用户第一次打开就知道怎么用；
尽量减少依赖和复杂架构；
尽量减少后端、账号系统和服务器；
能在最短路径内完成一次完整使用流程。

请把现有需求分成三类：

第一版必须做
以后可以增加
现在明确不要做

第一版最多保留 3～5 个核心能力。

不要因为「以后可能需要」就提前加复杂功能。

最后重新生成适合 Claude 执行的开发 Prompt。

这个方案对于第一次做项目的人来说太复杂了。

请重新设计。

原则：

优先本地运行；
优先单体项目；
能不用数据库就不用数据库；
能用本地存储就不要先上云；
能不登录就不要做账号系统；
能不用微服务就不用微服务；
能少一个框架就少一个框架；
优先选择成熟、资料多、AI 容易维护的技术；
不要为了技术先进而增加复杂度。

请保持原来的核心功能不变，只降低实现难度。

最后重新生成：

简化后的技术方案
项目结构
Claude 开发 Prompt
Codex 验收 Prompt

我不懂技术栈。

请不要让我在一堆框架之间自己选。

根据这个项目的实际需求，直接帮我选一套最适合电脑小白和 AI 编程的技术方案。

选择标准：

安装简单；
运行简单；
社区成熟；
文档丰富；
AI 熟悉；
依赖尽量少；
不使用已经明显过时的技术；
后续方便 Claude 和 Codex 继续维护。

请告诉我：

为什么选这套技术；
为什么没必要选更复杂的方案；
需要安装什么；
启动命令是什么；
构建命令是什么；
测试命令是什么。

最后把确定后的技术方案写进 Claude 开发 Prompt。

在生成 Claude 开发 Prompt 之前，请先站在三个角度检查一次我的需求：

产品经理
普通用户
测试工程师

重点找：

前后矛盾
缺少的关键流程
无法验收的描述
过度复杂的功能
用户可能卡住的地方
没有定义的异常情况
开发时容易产生歧义的地方

不要直接扩展功能。

只指出真正会影响开发和验收的问题。

然后给出修改后的最终需求。

当前项目已经开发到一半。

原始需求是：

【在这里粘贴原需求】

现在我想改成：

【在这里写新的想法】

不要直接重新生成整个项目。

请先做一次需求变更分析。

告诉我：

哪些原需求保持不变；
哪些需求需要修改；
哪些功能需要新增；
哪些功能应该删除；
对现有架构可能有什么影响；
是否需要迁移已有数据；
哪些地方最容易改坏。

然后输出一份《增量变更需求》，
以及一份可以直接交给 Claude 的《Claude 增量修改 Prompt》。

要求尽量保留已经正常工作的代码。

当前项目第一版已经完成并通过验收。

这是当前功能：

【在这里粘贴 HANDOFF 里的功能列表】

现在我准备规划第二版。

请不要直接生成代码。

请根据第一版已有的能力，帮我规划第二版。

要求：

不要破坏第一版的核心定位；
不要一次加太多功能；
优先增加真正提高使用价值的能力；
考虑新增功能对现有数据、界面和架构的影响。

请输出：

第二版目标
建议新增功能
暂时不要增加的功能
功能优先级
可能需要修改的数据结构
可能产生的风险
Claude 增量开发 Prompt
Codex 第二版验收标准

我正在考虑给当前项目增加这个功能：

【在这里描述新功能】

请不要默认这个功能一定值得做。

请从这些角度分析：

它解决什么真实问题；
使用频率可能高不高；
会不会让项目明显变复杂；
有没有更简单的办法解决；
是否和项目核心定位一致；
增加以后需要长期维护什么；
不做会损失什么。

最后不要替我做决定。

请给出：

支持增加它的理由
不建议现在增加它的理由
最小实现版本
如果以后再做，需要提前保留什么

不要继续给我教程、操作建议或代码示例。

你现在可以直接操作当前项目。

请直接：

读取文件；
修改文件；
创建缺失的文件；
安装必要依赖；
运行项目；
运行测试；
修复错误。

我需要的是做好的项目，不是「我接下来应该怎么做」的说明。

请从刚才停下的位置继续执行。

继续。

不要重新总结前面的内容。

请检查当前项目状态，找出还有哪些原始需求没有完成。

按照原始验收标准逐条核对。

没完成的继续实现；
已经完成的不要重复重写；
发现错误直接修；
完成后重新运行构建和测试。

只有当所有核心验收标准都完成之后才停止。

后续不需要因为正常、可逆的本地开发步骤反复向我确认。

比如：

创建项目文件；
修改项目代码；
安装项目正常依赖；
运行开发服务器；
运行构建；
运行测试；
运行 lint；
创建测试文件；
修复普通代码错误。

这些操作可以直接执行。

只有涉及下面这些高风险操作时再问我：

大量删除用户文件；
删除项目外的文件；
覆盖无法恢复的数据；
强制推送；
修改生产环境；
修改真实线上数据库；
涉及账号、付款或对外发布。

其余情况请自主完成。

先不要结束。

请站在测试工程师的角度，对你刚刚完成的项目做一次开发者自检。

不要只检查代码能不能编译。

请检查：

项目安装；
项目启动；
项目构建；
现有测试；
核心用户流程；
空输入；
错误输入；
重复操作；
刷新；
数据持久化；
网络失败；
接口异常；
移动端基础显示。

然后重新对照原始验收标准逐条确认。

发现问题直接修复。

最后更新 HANDOFF.md。

你刚才说项目已经完成。

现在不要继续开发新功能。

请提供完成证据。

对每一条原始验收标准，分别写出：

验收要求；
对应实现位置；
你实际执行的验证方式；
真实的验证结果。

如果某一项没有实际验证，请明确写「未验证」，然后立刻补做验证。

不要使用「应该可以」「理论上可以」「看起来正常」作为完成证据。

请检查当前任务是否真正完成。

不要只根据你刚才的总结判断。

重新查看：

原始需求
当前代码
当前 Git diff
测试结果
构建结果
还没完成的事项

如果还有任何核心任务没完成，请继续执行。

不要重复已经完成的工作。

不要只告诉我下一步。

直接继续做到满足验收标准。

当前项目出现了错误。

请你自己读取完整错误信息，不要只根据最后一行猜。

按下面流程处理：

先复现错误；
找到错误真正发生的位置；
判断是代码、依赖、环境、配置还是数据问题；
给出最可能的根因；
直接修复；
重新运行原来失败的那条命令；
确认错误是否真的消失；
检查修复有没有引入新问题。

不要通过删除功能、注释代码或跳过测试来假装解决问题。

如果存在多个错误，从阻塞项目运行的那个开始处理。

继续执行，直到项目恢复正常。

请你读取终端中最近一次失败命令的完整输出。

不要让我人工筛选报错。

请区分：

真正导致失败的根因
由根因引发的后续连锁报错
普通 warning
可以暂时忽略的信息

优先修复根因。

修复后重新执行同一个命令验证。

依赖安装失败。

请先检查：

当前 Node / Python / 包管理器版本；
项目 lock 文件；
package.json / requirements 等依赖声明；
是否存在版本冲突；
是否存在系统环境不兼容；
是否混用了不同的包管理器。

优先采用：

兼容当前项目的稳定版本；
最小范围修改；
保留现有项目结构。

不要第一反应就删除全部依赖或者升级整个技术栈。

修复后重新安装并运行项目验证。

项目可以启动，但页面显示异常或者空白。

请不要只检查启动命令。

请实际检查：

浏览器端运行错误；
控制台报错；
路由；
入口文件；
组件渲染；
API 请求；
静态资源；
环境变量；
CSS 是不是把内容盖住了。

找到真正原因后直接修复。

修复完成后重新启动，确认页面能正常显示。

第三方 API 当前调用失败。

请先不要随意重写整个功能。

按顺序检查：

请求 URL；
请求方法；
headers；
鉴权；
环境变量有没有加载；
参数格式；
接口版本；
响应状态码；
响应 body；
CORS；
限流；
网络错误。

请根据真实返回结果判断原因。

不要在没有证据的情况下把问题归给「网络」。

修复后重新发一次真实请求验证。

当前项目出现性能变慢的问题。

请先做性能定位，不要直接开始大优化。

检查：

是否存在重复渲染；
是否有无限循环；
是否有重复的 API 请求；
是不是一次加载了大量数据；
有没有没清理的定时器或监听；
是不是每次操作都重新计算大量内容；
是否存在明显的 N+1 请求；
是不是加载了不必要的大依赖。

先找出最可能的瓶颈和证据。

只优化真正影响使用体验的部分。

不要为了很小的性能收益大幅增加代码复杂度。

不要先猜解决办法。

先定位问题。

请按照这个顺序处理：

现象
复现
证据
根因
修复
验证

没有确认根因之前，不要连续尝试大量随机修改。

每一次修改后，都重新执行原本失败的操作来验证。

当前页面可以显示，但是存在按钮或交互看起来正常、实际上没有功能的问题。

请对页面里所有主要交互做一次真实检查。

逐个验证：

按钮有没有绑定事件；
事件是不是真的执行了；
表单能不能提交；
状态有没有更新；
数据有没有保存；
页面有没有给出反馈；
刷新以后数据是否符合预期。

不要只根据代码里「存在 onClick」就认为功能完成了。

请沿着用户实际操作的流程检查。

发现假功能或占位实现后，直接修复。

请专门检查当前项目是否存在「看起来完成，实际上是假实现」的情况。

重点搜索：

硬编码返回值；
固定演示数据；
mock 数据仍然被正式页面使用；
永远返回成功的 API；
空函数；
TODO；
placeholder；
用 setTimeout 模拟真实请求；
按钮只弹提示但没有业务操作；
前端有界面但后端接口不存在；
接口有定义但从来没被调用；
错误被 catch 之后直接吞掉。

请区分：

开发阶段合理的 mock
和
已经影响正式功能的假实现。

只报告会影响真实使用的问题。

当前项目需要使用第三方 API。

请按安全的方式接入。

要求：

不要把 API Key 硬编码在源代码里；
不要把真实 Key 写进 README；
使用环境变量；
提供 .env.example；
错误处理要区分网络失败、鉴权失败、限流和服务异常；
不要在日志里输出完整密钥；
如果前端不应该直接持有密钥，就不要把密钥暴露到浏览器。

完成后更新 README，说明：

需要哪些环境变量；
用户应该去哪里申请；
怎么配置；
怎么验证配置成功。

这次只允许修改：

【写清楚具体功能、页面或文件】

不要顺手重构其他模块。

不要改变：

【写清楚不能动的部分】

修改前先读取相关代码。

只做完成当前任务所需要的最小改动。

完成后检查 Git diff。

如果发现无关文件被修改，请恢复无关的修改。

最后只报告：改了哪些文件、为什么改、测试结果。

我准备在当前项目中新增一个功能：

【在这里描述新功能】

这是增量开发，不是重新做项目。

请先：

读取现有项目；
理解现有架构；
确认这个功能应该接在哪里；
判断是否会影响现有数据结构和功能。

然后制定最小改动方案。

要求：

优先复用现有组件和逻辑；
不要复制一套重复的系统；
不要因为增加一个小功能就大规模重构；
保持原有功能兼容；
增加必要测试；
更新 README / HANDOFF.md 里的相关内容。

完成后重新运行原有测试和新功能的测试。

我想从项目中移除这个功能：

【在这里写功能名称】

请不要只把界面隐藏起来。

需要检查并清理：

页面入口；
按钮；
路由；
相关组件；
业务逻辑；
API；
状态；
无用依赖；
测试；
文档。

但不要误删被其他功能共用的代码。

删除前先分析依赖关系。

完成后重新运行构建和测试，确认其他功能没受影响。

禁止整体重写。

当前项目已经有可以正常工作的部分。

请遵循：

优先修改已有实现；
优先最小改动；
优先局部修复；
不要更换技术栈；
不要重新搭建整个项目；
不要删掉正常代码再重新生成；
不要因为你更喜欢另一种架构就大规模迁移。

只有当现有代码确实无法满足需求，并且有明确证据时，才允许做较大结构调整。

所有较大调整，先说明原因。

这次修改请遵守一个原则：

只改完成当前任务所必须的内容。

不要顺手：

升级整个技术栈；
更换框架；
重写项目；
调整无关的界面；
重命名大量文件；
修改无关的业务逻辑；
删除正常功能。

修改完成后检查 Git diff。

如果存在与本次任务无关的改动，请恢复。

当前项目功能已经基本可用，但代码开始变得混乱。

请先不要大规模重构。

第一步只做代码质量评估。

找出：

重复逻辑；
过大的文件；
职责混乱的模块；
明显的死代码；
不一致的数据流；
难以维护的状态逻辑；
影响后续开发的技术债。

把问题分成：必须现在处理 / 可以以后处理。

只有真正影响稳定性和继续开发的问题，才进入本轮重构。

然后制定最小范围的重构方案。

重构前后必须保证：

核心功能一致；
原有测试继续通过；
不要借重构偷偷改变产品行为。

这是一个已经开发到一半的项目。

不要假设项目从零开始。

请先做项目接管分析。

检查：

目录结构；
README；
HANDOFF；
Git 状态；
最近修改；
依赖；
可用命令；
测试；
构建；
当前报错；
未完成的 TODO。

然后告诉我：

项目目前做到哪里；
哪些功能已经真实可用；
哪些功能只是部分完成；
哪些地方已经损坏；
下一步最合理的开发顺序。

分析完成后，根据现有需求继续开发。

不要无理由推倒重来。

当前项目功能基本完成。

现在只进行 UI / UX 优化。

注意：

不要改变核心业务逻辑；
不要删除已有功能；
不要修改 API 行为；
不要更改数据结构；
不要为了视觉效果重写整个项目。

优化方向：

整体布局更干净；
层级更清楚；
间距统一；
字体大小合理；
按钮状态清晰；
表单更易用；
移动端可用；
空状态更自然；
错误提示更明确；
加载状态更清楚。

设计风格：简洁、现代、克制。不要过度使用渐变、毛玻璃和动画。

完成后重新运行项目，确认所有原有功能仍然正常。

请优化当前界面设计。

不要使用典型的 AI 生成网页套路，比如：

满屏渐变；
大量紫色；
过度毛玻璃；
每个卡片都发光；
没有意义的大标题；
大量装饰性图标；
过多圆角；
过度动画；
看起来像模板站的布局。

目标是：像一个真的有人长期在用的成熟工具。

优先做到：

信息密度合理；
排版克制；
颜色少而统一；
按钮有明确主次；
内容比装饰重要；
桌面端和移动端都自然。

保持现有功能和数据逻辑不变。

请在不改变核心功能的前提下，让当前网页适配常见手机屏幕。

重点检查：

页面有没有横向溢出；
字体是不是太小；
按钮是不是难点；
表单是不是超宽；
弹窗有没有超出屏幕；
顶部导航是不是太挤；
卡片布局能不能自然堆叠；
表格是否需要横向滚动或者换一种布局。

不要为了移动端另做一套独立页面。

优先用响应式布局解决。

完成后保持桌面端原有的体验。

请为当前项目增加深色模式。

要求：

不要改变业务逻辑；
优先复用现有设计变量；
避免在每个组件里硬编码两套颜色；
保证文字、背景、边框、输入框、按钮、弹窗都有足够对比度；
如果项目已经有主题系统，接入现有主题系统；
如果没有，采用尽量简单的方案。

需要支持：浅色、深色。
如果实现成本合理，再支持跟随系统。

完成后检查主要页面，不要只改首页。

当前项目已经由 Claude 完成第一轮开发。

现在请你作为独立验收者工作。

不要先修改代码。

你的第一阶段任务只有：

理解需求；
检查项目；
运行验证；
发现问题；
输出验收报告。

请阅读：

README.md
HANDOFF.md
项目源码
测试
Git diff

然后读取下面的原始需求：

【在这里粘贴原始需求】

不要把 HANDOFF.md 当成事实来源。

它只是开发者的自述。

所有核心功能都需要通过代码、运行结果或测试独立验证。

这次验收请采用「准备交付真实用户」的标准，而不是 Demo 标准。

重点检查：

能启动但核心功能不可用；
只有界面没有真实逻辑；
写死的演示数据；
按钮没有实际行为；
错误状态没有处理；
刷新后数据丢失；
API 失败后页面崩溃；
测试只是为了通过而写；
测试没有覆盖真正的业务逻辑；
README 与真实命令不一致；
环境变量缺失；
构建失败；
Lint / TypeScript 存在明显问题；
敏感信息被硬编码；
存在明显的越权或输入安全问题。

只报告有证据的问题。

不要因为代码风格的个人偏好判定验收失败。

这次只进行 Code Review。

不要重新设计产品。

不要评价界面风格。

重点检查本次 Git diff：

逻辑错误；
潜在的运行时错误；
错误的条件判断；
空值问题；
异步问题；
状态同步问题；
资源泄漏；
安全问题；
数据损坏风险；
明显的性能回退；
与现有代码不兼容的修改。

每个问题必须说明：

文件位置；
问题原因；
什么情况下会触发；
为什么这是实际问题；
建议的修复方向。

不要报告纯审美或个人编码风格偏好。

请只审查本次 Git diff。

不要重新审查整个项目里与本次修改无关的历史问题。

目标是判断：

这次修改有没有实现指定需求；
有没有引入回归；
有没有明显 Bug；
有没有破坏已有功能。

如果发现历史遗留问题，但和本次修改无关，单独标记为「非本次改动」，不要混进本轮验收结果。

你给出的验收问题太笼统。

请把每一个问题转换成可以交给开发者直接修复的工程任务。

每个问题必须包含：

严重程度；
文件路径；
相关代码位置；
问题描述；
复现步骤；
当前结果；
预期结果；
可能的根因；
推荐的修复方向；
修复后应该执行的测试。

如果拿不出证据，请不要把它列为确定问题。

请把当前问题重新按照「是否阻止交付」分类。

分成：

阻止交付
建议修复后交付
可以后续优化

判断依据：

是否影响核心用户流程；
是否可能导致数据错误；
是否存在安全风险；
是否频繁触发；
是否只是代码整洁或体验优化。

不要因为存在低优先级的 P3，就自动判定整个项目不可交付。

根据刚才的验收报告，生成一份可以直接复制给 Claude Code 的修复 Prompt。

不要遗漏任何 P0 和 P1。

Prompt 中需要包含：

项目当前状态；
本轮只修什么；
每个问题的证据；
复现方式；
预期结果；
涉及文件；
建议修复方向；
不能采取的错误修复方式；
修复后必须执行的测试。

要求 Claude：

尽量最小改动；
不要重写正常模块；
不要删除失败的测试；
不要降低验收标准；
修复后更新 HANDOFF.md。

只输出最终可复制的 Claude 修复 Prompt。

下面是 Codex 对当前项目的独立验收结果：

【在这里粘贴完整报告】

请不要反驳验收报告，也不要直接假设报告一定正确。

对于每一个问题：

先复现；
确认是否真实存在；
如果存在，定位根因并修复；
如果无法复现，保留证据并说明原因。

修复原则：

优先 P0；
然后 P1；
然后 P2；
最后处理必要的 P3。

不要为了通过验收而：

删除测试；
跳过测试；
硬编码结果；
隐藏错误；
降低原始需求；
删除正常功能。

修复完成后重新运行：

构建；
测试；
lint；
相关核心流程。

然后更新 HANDOFF.md。

不要只用文字判断这个问题不存在。

请按照 Codex 给出的复现步骤实际验证。

如果复现失败：

记录你实际执行的命令或操作；
记录实际结果；
检查当前代码是否已经变化；
判断这个问题是否已经被其他修改顺带修复。

如果你确认 Codex 报的是误报，请给出可以验证的证据。

不要因为「看代码感觉没问题」就直接判误报。

Claude 已经根据上一轮验收报告完成修复。

请进行二次验收。

不要因为 Claude 声称已经修复就直接通过。

请优先重新验证上一轮所有 P0、P1、P2。

然后重新运行：构建、测试、lint、核心用户流程。

还要检查这次修复有没有引入新的回归。

最后明确输出：验收通过 或 验收不通过。

如果不通过，只列出当前仍然真实存在的问题，不要重复已经确认修复的。

当前项目已经通过功能验收。

现在做一次发布前检查。

这不是重新开发。

请重点检查：

README 是否和真实运行方式一致；
环境变量说明是否完整；
有没有把密钥、token、密码写进仓库；
有没有调试日志；
有没有临时文件；
有没有 TODO 占位影响核心功能；
构建是否通过；
测试是否通过；
项目第一次克隆下来以后，能不能按 README 启动；
是否存在明显的生产环境风险。

最后输出「可以交付」或「仍需处理」，并说明证据。

请为当前项目创建或更新 HANDOFF.md。

这份文件是写给下一位接手项目的 AI 工程师看的，不是宣传文案。

必须包含：

# 项目概述

一句话说明项目是什么。

# 当前状态

项目目前能不能安装、启动、构建、测试。

# 已完成功能

逐条列出真正已经实现的功能。

# 项目结构

说明重要目录和关键文件的作用。

# 技术栈

列出主要框架和关键依赖。

# 安装方式

给出实际命令。

# 启动方式

给出实际命令。

# 构建方式

给出实际命令。

# 测试方式

给出实际命令。

# 环境变量

说明需要哪些变量，不要写真实密钥。

# 验收标准

逐条对应原始需求说明当前状态。

# 已知问题

明确列出还没解决的问题。

# 最近修改

说明本轮开发主要改了什么。

所有内容必须基于当前真实的项目状态，不要虚构已经通过的测试。

请根据当前真实项目创建或更新 README.md。

面向第一次接触这个项目的普通用户。

README 必须包含：

项目是什么；
主要功能；
运行前需要安装什么；
安装步骤；
启动命令；
构建命令；
测试命令；
环境变量配置；
常见问题；
项目主要目录。

不要写宣传口号。

不要写不存在的功能。

命令必须和当前 package.json / 项目配置一致。

完成后按 README 里的关键命令重新验证一次。

请检查当前项目是否已经是 Git 仓库。

如果不是，并且这是一个正常的本地开发项目：

初始化 Git；
创建合适的 .gitignore；
确保依赖目录、构建产物、缓存、系统文件、环境变量文件不会被提交。

不要提交真实密钥。

然后告诉我：

Git 是否初始化成功；
当前有哪些未跟踪的文件；
建议的第一次 commit 内容。

不要执行远程 push。

请根据当前 Git diff 帮我生成一条简洁、准确的 commit message。

要求：

描述真实改动；
不要写「update files」这种没意义的内容；
不要夸大；
尽量一句话说清。

如果改动包含多个明显部分，可以再补一段简短的 commit body。

不要直接提交，只生成 commit message。

请检查当前 Git diff。

先确认：

没有敏感信息；
没有环境变量密钥；
没有无关的大文件；
没有明显的临时调试内容。

然后创建一个本地 Git commit。

commit message 根据真实改动生成。

只允许本地 commit。

不要 push；
不要 force push；
不要创建远程仓库；
不要修改远程分支。

当前项目准备正式交付。

请做最后整理。

不要增加新功能。

检查：

项目能不能安装；
项目能不能启动；
项目能不能构建；
测试是否通过；
README 是否准确；
HANDOFF.md 是否准确；
是否存在真实密钥；
是否存在调试文件；
是否存在影响使用的 TODO；
是否存在无用的临时 mock；
Git 工作区是否存在意外文件。

最后给我一份《最终交付说明》，只包含：

项目做了什么；
怎么启动；
怎么测试；
主要文件；
当前验收状态；
已知限制；
以后继续开发应该从哪里开始。

需求整理：
先不要写代码，先把我的想法整理成完整项目需求和验收标准。

直接执行：
不要给我教程，直接在当前项目里创建、修改、运行、测试并修复。

继续完成：
检查原始需求，还没完成的继续做，不要重复已经完成的内容。

报错修复：
先复现，再找根因，再修复，然后重新运行原来失败的命令验证。

不要乱改：
只做完成当前任务所必须的最小改动，不要重写正常模块。

开发自检：
按照原始验收标准逐条检查，没有实际验证过的项目不要写成已通过。

Codex 验收：
不要相信 HANDOFF 的自述，必须通过代码、运行和测试独立验证。

修复闭环：
根据 Codex 报告逐条复现和修复，修完后重新构建和测试，再交回 Codex。

请根据当前项目状态判断我现在处于哪一个阶段：

需求规划
开发
开发自检
独立验收
问题修复
二次验收
准备交付
下一版本规划

这是当前状态：

【在这里粘贴 Claude 或 Codex 最近的结果】

请告诉我：

现在最应该由 GPT、Claude 还是 Codex 接手；
下一步只做哪一件最重要的事；
我应该复制什么提示词给它。

不要同时安排很多个下一步。

我有一个想法
↓
直接告诉一个 AI
↓
它开始写
↓
它说「已经完成」
↓
我不知道到底有没有问题

我的项目/
│
├── src/
├── tests/
├── README.md
├── HANDOFF.md
├── package.json
└── .git/

PLANNING    GPT 正在整理需求
DEVELOPING  Claude 正在开发
REVIEWING   Codex 正在验收
FIXING      Claude 正在修复
PASSED      Codex 验收通过

项目需求.md
Claude 开发 Prompt
Codex 验收 Prompt
HANDOFF.md
Git

MCP
多 Agent
Subagent
Docker
Kubernetes
微服务
复杂云服务
CI/CD 流水线

GPT
需求整理、验收标准、两份 Prompt
   ↓
Claude
开发、运行、测试、修复、写交接单
   ↓
Codex
独立验收
   ↘ 不通过 → 回到 Claude 修 → 再验
   ↓
通过