AI Coding 实践：PRD 到代码直出的探索
- 分享分为四个环节：
- AI Coding 在客户端领域的发展阶段与现状
- 客户端AI Coding的关键解法
- 实际业务场景与需求分析
- 总结与展望
AI Coding 发展史和现状
AI模型发展速览
自2017年Google提出Transformer后，AI在各领域实现突破。
2023年起，大语言模型商业化加速，年增速达30倍以上。
AICoding 领域是发展最快的学科之一，因为反馈机制明确（“对就是对，错就是错”）。
AI Coding 发展的五个阶段（人机协作视角）
| 阶段 | 描述 | 人机角色 | 典型能力 |
|---|---|---|---|
| L1 | 人类主导，Agent实时辅助 | 人主导，AI辅助 | 代码提示（如GitHub Copilot） |
| L2 | 人类布置任务，Agent生成代码 | 人布置单一任务 | 单一任务代码生成 |
| L3 | 人类设定范围，Agent推进多环节流程 | 人设定范围，AI推进流程 | 生成方案 + 生成代码 |
| L4 | 人类输入PRD，Agent端到端交付 | 人输入PRD，AI端到端交付 | 需求解析 + 架构设计 + 编码 |
| L5 | 人定义目标，多Agent分工协作 | 人定义目标，多AI协作 | 多Agent模拟完整软件团队 |
- L4阶段 前端领域已有产品（如“Lovable”），
“直出”型产品的现状与挑战
- 文字稿提到：
- 前端已有“直出”产品（如Lovable、Bolt.new），可用自然语言直接生成可运行应用。
- 客户端领域曾有一款叫 Builder.ai 的产品，但在2025年7月左右“爆雷”，据称背后有700多名工程师，被质疑是否真为AI驱动。公司估值从18亿跌至零，客户端直出仍存巨大挑战。
- 前端已有“直出”产品（如Lovable、Bolt.new），可用自然语言直接生成可运行应用。
客户端AI Coding的独特困境
从技术栈视角看客户端
- 技术栈碎片化：
- 前端：标准化高（HTML/CSS/JS）、框架集中（React/Vue）。
- 客户端：平台碎片化（iOS/Android API版本差异）、框架分散（SwiftUI、UIKit、Jetpack Compose等）。
- 构建与调试：
- 客户端编译耗时、真机调试必要，反馈循环慢。
- 开发模式：
- 前端热重载实时反馈；客户端生命周期复杂，架构模式多样（MVVM、VIPER等）。
从AI 模型视角看客户端
- 构建与调试复杂：编译时间长、真机调试必要，反馈循环缓慢。
- 训练数据稀缺：高质量客户端代码多在企业内部未开源，公开数据规模小。
- 代码模式多样：架构演进复杂（如Android从Activity到MVVM+Compose），上下文理解成本高。
结论
“前端开发像是在标准化、开放的乐高环境中工作；客户端则像是在碎片化、半封闭的复杂系统中进行精密工程。”
客户端AI Coding的关键解法
Mobile-SWE-bench
科学评测体系的建立：从SWE-bench到Mobile-SWE-bench
**SWE-bench**：由普林斯顿与芝加哥大学推出，基于真实GitHub Issue，要求AI生成PR来修复问题，以单元测试通过率为评测标准。
局限性：侧重于Bug修复而非功能实现，项目多集中后端，缺少移动端特有考量（如UI还原、多模态输入）。
移动端评测 Mobile-SWE-bench：
- 核心要素：高质量真实PRD、多模态输入（PRD+Figma）、详细测试用例、历史Commit基线、多维度评测方法。
- 评测方法：人工评测、自动化测试、渲染树约束检查、视觉语言模型评估。
- 核心要素：高质量真实PRD、多模态输入（PRD+Figma）、详细测试用例、历史Commit基线、多维度评测方法。
热门Coding Agents表现如何
把整个需求的测评级分成三类, 可以看到哪怕是业界比较火的一些模型放在测试集中表现也
一般, 30%已经算是很高了.
为什么这些 Code Agent 都表现不佳?
PRD的拆解与微调：将需求转化为结构化任务
PRD 是 “产品需求文档”(Product Requirements Document) 的缩写. 在传统的软件和产品开发流程中，PRD 是一个核心文档。它由产品经理（或业务分析师）撰写，详细描述了一个产品、功能或项目应该做什么、为谁而做以及要达到什么目标。
一个典型的 PRD 通常包含：
- 背景与目标： 为什么要做这个功能？要解决什么问题？业务目标是什么？
- 用户角色与画像： 为哪些用户设计？
- 功能需求： 详细的功能描述，包括用户场景、操作流程。
- 非功能需求： 性能、安全性、兼容性等要求。
- 成功指标： 如何衡量功能是否成功（如用户使用率、性能提升等）。
- 设计原型/线框图： 可视化地展示界面和交互。
这里探讨的是一种前沿的、由AI驱动的开发范式。在这个范式中，PRD 的角色发生了根本性的转变：
- 从“给人看”到“给AI看”：
- 传统PRD是写给开发、测试、设计等团队成员看的，需要人类的理解和解读。
- 在AI Coding实践中，PRD（或其结构化、AI友好的变体）是直接输入给AI智能体或大语言模型的“高级指令”。
- 成为AI的“蓝图”：
- AI（例如GPT-4、Claude 3、DeepSeek等）会分析、理解PRD中的需求。
- 基于对需求的理解，AI可以自动或半自动地执行后续开发任务，例如：
- 生成技术设计： 设计系统架构、数据库Schema、API接口。
- 直接生成代码： 产出前端、后端、测试代码的初稿。
- 生成测试用例： 根据需求描述编写测试场景和脚本。
- 对PRD质量的要求更高：
- 必须更加清晰、无歧义、结构化。 AI无法像人类一样通过模糊的上下文或沟通来“猜”出真实意图。
- 可能需要使用更标准化、机器可读的语言来描述需求，或者结合结构化数据（如流程图、状态图、清晰的验收标准列表）。
核心上下文 - PRD
- 核心上下文 - PRD：PRD是核心上下文，但当前PRD质量参差，AI难以聚焦。
- 问题本质：PRD拆解是一个领域特定的命名实体识别（NER）任务，即从PRD中识别“UI控件实体”。
- 控件实体分类：参考Apple HIG与Material Design，分为输入类、按钮类、浮层面板、导航栏、内容展示类等。
- 微调方法：采用LoRA（低秩适配） 对模型进行轻量微调，显著提升控件识别的准确率与召回率。
- 微调效果：带图评测的多模态模型F1分数达0.85，显著高于基线（0.57）。
UI高还原度出码：从设计稿到代码的准确转换
- 低还原度原因：
- Figma设计稿不规范（绝对布局、标记不清）
- 大模型存在幻觉（布局复杂时推理错误）
- 还原度低，人工审核成本高
- 还原度检测流程：
- 还原检测方案和挑战：
- 还原度检测方案对比：
- 静态代码分析：通过LLM推断约束关系，检测率**88.5%**，无需编译，易集成。
- 运行时渲染树检测：需编译运行，检测率仅55.4%，链路集成难度大。
- 优选静态方案：通过约束信息与样式Token比对，实现高效高精度检测。
UI组件召回：避免重复造轮子，提升代码采纳率
- 组件召回闭环迭代
- 问题：AI生成代码未使用企业内部组件，导致采纳率低。
- 解法：基于代码上下文与开发意图，智能召回组件库中的最佳匹配组件。
- 进化机制：通过UI自动化采集运行时属性与截图，自动构建训练数据集，实现组件的持续自学习与迭代。
- 问题：AI生成代码未使用企业内部组件，导致采纳率低。
典型业务场景与需求分析
一个实际的业务场景和需求分析, 用户登录页面，包含手机号输入框、密码框、登录按钮、忘记密码链接及成功/失败反馈。
流程:
- PRD
- 控件识别（手机号输入框、密码框、登录按钮、忘记密码链接）
- 逻辑聚合(登录成功Toast、失败弹窗）
- 结合企业组件库与设计规范生成代码
端到端提升：定制化Code Agent在Easy/Medium/Hard需求集上，比通用Agent（如GPT-5、Claude）提升约10%。
总结与展望
核心结论
客户端实现PRD到代码的完全直出目前尚不可能，但可通过“评测驱动子能力提升”路径逐步推进。
应关注四个关键课题：
1. 如何构建科学的端到端评测体系？
2. PRD该如何拆解、拆解到什么粒度？
3. 如何保证UI高还原度出码？
4. 如何实现组件的智能召回与闭环迭代？
未来方向
- 生产级评测集：积累真实PRD、Figma、Commit、测试用例等数据。
- 流动闭环的企业知识库：融入自动化流程，实现数据自收集与模型自进化。
- 全周期覆盖：从编码扩展至测试、CR、Bug修复、发布全流程。
- 跨平台垂类Agent融合：实现跨系统复杂任务的端到端闭环。
AICoding 核心价值
- AI Coding不是完全替代开发者，而是作为“副驾驶”提升效率、规范流程。
- 客户端AI落地的关键在于：高质量数据、领域适配、工程化闭环。
- 长期来看，AI将重新定义软件生产流程，推动研发模式向智能化、自动化演进。