接着说一下我现在的开发方式
我不再是说每个AI出一个方案，我目前是用claude出文档（我觉得看起来最好），然后codex和Gemini3来审核，最终Gemini3来做开发（因为这部分Token消耗最大，Google大善人），codex做review，
就像文章里面说的一样，架构先行，然后用AI进行填空，架构图是技术方案第一要素，我是比较建议先讨论出来整个架构图和项目目录的，要复杂一点的甚至连流程图都可以一起讨论出来
架构好了，然后一个功能一个功能的进行开发，不要想着一蹴而就，把整个完整项目的PRD页面全部写出来，这样太容易出问题。
比如我就是想把落地页的语音生成和完整应用页的一起做到PRD里面，然后进行开发，AI并不能很胜任工作，开发了两个半成品，于是乎我改变方案，让AI只需要专注于落地页的工具开发，这样效果明显好很多
- 我统一了一下需求文档和技术文档的格式，我没有仔细用spec-kit这种框架，就纯自己总结的，不知道有没有他们好用
需求文档是：
需求文档: [功能名称]
1. 介绍
[此处填写对功能的1-2句话高级总结]
2. 需求与用户故事
需求 1: [具体需求点名称]
用户故事: As a [角色], I want [功能], so that [收益].
UI布局方案
使用ASCII编码的方式画出需要新创建的或需要更新的布局图
验收标准
*WHEN [某个事件或触发器], THEN the system SHALL [系统必须做出的响应].
- IF [某个前提条件为真], THEN the system SHALL [系统必须做出的响应].
技术文档是：
技术设计: [功能名称]
1. 架构概述
[简述新功能如何融入现有系统，使用 ASCII 画出架构图和时序图]
2. 数据模型/接口设计
- 数据库: [定义新的数据表或对现有表的修改]
- API 端点: [定义相关的 API 端点 (路径, 方法, 关键请求/响应)]
3. 关键组件与E2E测试用例
- 组件分解: [列出核心的前/后端模块或组件]
- E2E测试用例: [简述E2E测试的重点和case]
4.会发送变更的文件
- 会新增的文件
- 会更新的文件