有一天我在想一个问题：能不能把产品需求文档直接丢给大模型，让它输出一整个可以跑起来的前端页面？
不是那种"帮我写个按钮"级别的问答，而是给它一份完整的 PRD，让它理解页面结构、数据模型、交互逻辑，然后按照项目已有的代码风格，输出可以直接放进仓库的代码。
听起来很激进，但我就是想试试。
整体设计：两个大流程
想清楚之后，我把这件事拆成两条线：
- 出码——从需求到代码
- 验证——确认生成的代码是否能用
当前阶段只追求"力大飞砖"——先把从 PRD 到页面这一步跑通，不考虑性能、token 成本这些优化问题。粗犷归粗犷，但整体流程是清晰的。
出码：从需求到代码的拆解
第一步：让 AI 理解需求
最朴素的想法是先把 PRD 结构化。不是给 AI 一份自由文本让它自由发挥，而是让它先做几件事：
- 数据建模：用 TypeScript 接口把需求里的数据结构抽出来
- 页面拆解：识别涉及哪些页面——是新增、修改还是删除？是列表、详情还是表单？
- 功能归类：按页面维度重新整理需求，每个页面要完成什么、涉及哪些组件
- 权限和埋点：单独列出，包括"可能遗漏的部分"
这一步的 prompt 大概长这样：
# 角色
你是一名前端产品经理，你需要将需求进行结构化，以方便开发将需求转变为页面。
# 任务
## 对需求内容进行数据建模
以 TypeScript 的方式对数据进行建模
## 拆解页面
分析需求涉及哪些页面，描述：
1. 页面是新增、删除还是修改
2. 页面属于列表、详情、表单还是其他类型
3. 页面包含哪些组件
4. 每个页面关联的数据模型
## 以页面维度重新整理需求
针对每个页面详细描述需要完成的功能点，
并对每个功能点需要开发的前端内容进行规划。
我故意让 AI 在结构化阶段就把权限和埋点列出来，包括"分析需求文档中可能遗漏的部分"。这不是为了让它当产品经理，而是为了在出码阶段减少遗漏。
第二步：任务拆解与代码输出
结构化之后，下一步是把页面级的需求拆成可执行的任务。规则也很简单：
- 有几个页面就有几个任务
- 每个任务先确认是否使用已有的页面模板
- 如果用，用哪一个；不用，从零开始
代码输出阶段，我尝试了两条路线。
两条实施路线
路线一：按文件依赖顺序逐个处理
整体思路是把需求信息按文件的依赖关系倒序处理——先处理基础文件，每个文件的输出会作为下一个文件的上下文输入。
优势：
- 极大控制了 AI 的创造性，输出结果（尤其是样式）更可预期
- 生成的代码一次性跑起来的概率比较高
- 实现相对简单
不足：
- 需要事先对模板文件做功能描述，不然 AI 不知道该文件是干什么的
- 输出的功能可能比较单薄，后续改动量仍然不小
- 输出的 token 多，冗余内容也多
路线二：全量代码 + 需求一起喂给大模型
把需求文档和项目所有代码打包喂进去，让大模型自己做任务拆分——列出要改哪些文件、每个文件具体怎么改。
优势：
- 输出内容更符合需求（大模型有完整上下文）
- 每个文件的任务更清晰
- 增量处理，单次输出的 token 少
- 可以根据需要做创造性的扩展
劣势：
- 每次都带全量上下文，输入 token 巨大，速度慢
- 创造性内容可能引入新的依赖问题，出现不可控的输出
两条路线不是互斥的。我后来的想法是让大模型根据需求类型自己选择执行哪条路线，甚至并行执行后比较结果。
模型选型：现实比理想骨感得多
因为是代码生成场景，输入的内容（完整 PRD + 项目代码）通常超出大多数模型的上下文窗口。当时（2024 年底）符合条件的选择不多：
| 模型 | 输入上限 | 输出上限 |
|---|---|---|
| qwen-long | 10M | 8K |
| qwen-plus | 128K | 8K |
| deepseek-r1 | 64K | 8K |
| deepseek-v3 | 64K | 8K |
8K token 的输出大约对应 800 行代码。也就是说，超过 800 行的文件可能输出不完整。以此推算，64K 的输入大约能容纳 8 个 800 行左右的文件。
这个限制直接决定了方案的天花板。
输入太长怎么拆？输出截断了怎么接？
这是我花了很多时间没有找到完美答案的问题。
输入拆分的难点：
- 不知道从哪里切割效果最好
- 还没有稳妥的方案把一次完整的问题拆成多轮提问，同时保证最终答案符合预期
我尝试的方案是按 token 上限做字符数切割，分次输入。每次输入结尾加一句"我还没问完，请先不要回答"，直到最后一段加上"以上是全部内容，请开始回答"。粗糙但能用。
输出拆分更难：
- 不知道 AI 会在哪个节点截断
- 不知道截断位置，就不知道怎么拼接
另一个思路是：让 AI 只输出代码的变更部分（diff），然后通过脚本把变更逐条应用到原文件上。这样单次输出的 token 少，也更可控。但实现复杂度不低。
跑通之后：诚实的阶段总结
第一个里程碑是 2025 年 2 月底跑通基本流程——命令行输入一个需求文档地址，输出一份基于模板的完整代码。
结果是任务规划有参考价值，但输出的代码效果不理想。
相对满意的部分：
- 生成的执行规划确实有参考价值
- 推荐的页面模板虽然不完全匹配需求，但也能用
- 部分代码改造是合理的
不满意的部分：
- 代码总体完成度不高，尝试约 10 次，符合需求的部分不足 20%
- 任务规划的输出不太稳定，切割失败时会导致整个流程中断
- 输出代码有冗余建议和意外内容，需要手动修改
已经解决的问题
- 任务切割不稳定 → 通过标签形式将返回结构化，降低了拆解难度
- 输出包含冗余内容 → 同样用标签形式结构化，排除掉建议文本
还没解决的问题
- 缺少把代码写回原项目原文件的流程（代码质量还不够好，暂时没想好怎么做）
- 缺少创建和删除文件的场景支持
- 缺少项目整体代码的统筹能力（当前更像是需求摘要）
- 需要让用户在每个环节可以介入和 debug
意外发现：一个有用的仓库序列化工具
在做这个项目的过程中，我发现了一个叫 yek 的工具——用 Rust 写的，专门把仓库代码序列化成 LLM 友好的格式。它的一些思路给了我启发：
- 用
.gitignore规则过滤不需要的文件 - 用 Git 历史推断哪些文件更重要（最近修改的排在后面，LLM 更关注末尾内容）
- 支持通配符模式和
yek.yaml配置文件
对"如何高效地把项目代码喂给大模型"这个问题，yek 提供了一个比我手动拼接优雅得多的解决方案。
下一步想做的事
- 尝试更多模型（随着上下文窗口越来越大，很多当时的限制可能已经不存在了）
- 探索：如果要操作的不是模板项目而是业务仓库，能否自动推荐要改造的目标文件
- 让用户可以对中间产物做 debug——不只是看最终输出，而是在任务规划、代码生成每个环节都能介入
- 把中间产物存档复用（比如项目的结构化分析，可以用在其他场景——做项目介绍、写技术文档等）
这个项目目前仍然处于"能跑但还不够好"的阶段。20% 的需求匹配率说明离实用还有距离。但换个角度看，它至少证明了一件事：让 AI 从需求到代码的全链路是可以跑通的，只是每个环节的质量都还需要打磨。
随着模型能力的提升——尤其是上下文窗口和代码理解能力的进步——我相信这条路最终会走通。当前的探索，更多是在为那个时刻做准备。