AI Coding 实践：PRD 到代码直出的探索

1. AI Coding 实践：PRD 到

2.

3. 录 01 AI Coding 发展史和现状 02 客户端 AI Coding 关键解法 03 典型业务场景与需求分析 04 总结和展望

4. 01 AI Coding 发展史和现状

5. AI模型的发展

6. AI Coding 发展历程基于机协作的视，结合交互形态、介与主程度，可将 Code Agent 划分为 L1—L5 五个阶段。 L1：类主导，Agent实时辅助：代码提示 L2：类布置任务，Agent 成代码：单 L3：类设定范围，Agent 推进多环节流程：成 L4：类输 task 实现案、代码 PRD，Agent 端到端交付：完成需求解析、架构设计、编码 L5：定义标，多Agent分协作：Agent 系统模拟完整软件团队，通过多 Agent 分协作完成全流程开发 · Ref：https://paradite.github.io/ai-coding/

7. 需求到交付——直出产品端到端“直出”型 AI coding 产品：然语直接产出可运、可访问的应放演示视频/图放演示视频/图（没有容量放不进来）（没有容量放不进来）步完成需求到交付，但是只出现在前端 Bolt.new Lovable ，

8. 需求到交付——直出产品（客户端领域）客户端领域的直出产品，但是很不幸暴雷了

9. 客户端 AI Coding 的困境 - 技术栈视前端构建与调试复杂度开发模式差异 UI 构建的抽象 2、框架分散：SwiftUI、UIKit、Jetpack Compose、Flutter、 2、框架相对集中：React/Vue/Angular 占据主流 React Native 构建具成熟，调试简单编译时间本质都是，真机调试必要 1、命周期复杂即时反馈：热重载、实时预览 2、依赖注和架构：MVVM、VIPER 等模式多样 UI 层种声明式UI 为主 SwiftUI、UIKit 和 Jetpack Compose 、Android View 同时存在，声明式和命令式混合化 1、平台碎化：iOS 16 的 API 和 iOS 17 的新 API 法不同标准碎 1、标准化程度：HTML/CSS/JavaScript 是统平台的标准化 vs 客户端

10. 客户端 AI Coding 的困境 - AI 模型视件，调链深

11. 客户端 AI Coding 的困境前端开发就像是在境中个标准化的、开放的、乐作，任务明确，材料（训练数据）充合 AI 统深度交互的环境中进个碎常适精密化的、半封闭的、需要与复杂系程，AI 在这个领域能提供帮助，但要做到像前端那样流畅和智能，还有很，展拳脚。客户端开发则像是在式的环的路要。

12. 02 客户端 AI Coding 关键解法

13. 客户端这么难，提效我们需要做什么？模型能边界是什么？能否直出交付？落到真实场景的提效，如何切？模型快速迭代，如何避免“ AI 如何更功”？期的融企业迭代？

14. 客户端这么难，提效我们需要做什么？需求评审技术评审交互评审模型快速迭代，如何避免“ 功”？ #1 科学评测体系 ….. 技术案 Coding 落到真实场景的提效，如何切 #2 需求 PRD 拆解 #3 UI 还原度出码 ….. ？联调& 测视觉 AI 如何更查期的融企业迭代？ #4 组件召回闭环迭代 ….. 缺陷修复回归发布

15. 02 AI Coding 端侧关键解法 #1 Mobile-swe-benchmark

16. 关键点：如何科学评测AI代码成效果 SWE-bench (Software Engineering Benchmark) https://www.swebench.com/original.html SWE-bench 是由普林斯顿学和芝加哥学于 2023 年推出的个规模软件程基准测试，通过从 12 个真实 Python 开源项中收集 2,294 个真实的 GitHub Issues 和对应的修复案，于评估型语模型解决实际软件问题的能

17. 关键点：如何科学评测AI代码成效果为什么SWE -bench成了代码能评测的事实基准？数据源基于真实的 GitHub 开源项（如 Django, Pytest），从数千个真实的 Issue (问题/Bug) 中提取需求描述，要求 AI Agent 动成个 Pull Request (代码补丁) 来解决这个 Issue。评测法通过原项带的单元测试（Unit Test）。如果 AI 成的代码能让测试例通过，就被认为是成功解决了问题。 Why it's popular? 痛点——如何在复杂、动态的代码库中下分。现在每个模型的发布、迭代都会默认跑程的核精准切中了现代软件效解决真实问题。

18. 如何科学评测AI代码成效果 —— SWE-bench 局限性

19. 移动端评测 —— mobile-swe-bench 测等评测、法动化

20. Bench核模型理解 UI 截图和代码，进 "像

21. Benchmark 评测流程

22. 热 Coding Agents表现如何根据实际需求的复杂度，将需求分层 Easy、Medium、Hard 3 种类别的测试集，能够看到即便市 Agent Easy Medium Hard All GPT-5-Codex (GPT-5 High) 38% 35% 26% 33.0% Claude Code (Sonnet 4.5) 35% 33% 26% 31.0% Gemini CLI (Gemini 2.5 pro) - - - 36% 34% 30% 般。 33.3% Cursor (Claude Sonnet 4.5) 产环境端到端的测试集中，表现也 Code Agent 在真实上热的

23. Where "top-tier coding agents" fail 其实就是prototyping ->

24. 02 AI Coding 端侧关键解法 #2 PRD 微调拆解

25. 低质量出码原因之 —— 上下代码定位错误企业组件缺乏需求实现不全技术规范层上下设计、构建并维护 Agent 执的上下企业组件库系统性学科，专注于 Context Engineering是任务的每 design token、布局规范、响应式要求效地完业务概念，业务逻辑、历史业务参考设计还原层上下步，为其智能地组装出最优组合，以确保任务能够被可靠、业务领域层上下个动态系统，该系统负责在成档、技术栈规范约束等 UI还原程度低代码库上下项架构、依赖关系、数据状态管理

26. 核核上下 - PRD 洞察 PRD 是核的上下载体，需求迭代的关键输，完整 PRD ≠ 好上下现状是：PRD 过于冗余或信息缺失, 内容不够结构化。这就导致AI 难以聚焦，成的代码质量低。标清晰，职责单任务，明确任务边界 - 理想状态：精准任务：复杂需求 → 可执

27. 需求理解 —— 精确上下 NER（Named Entity Recognition）命名实体识别（Named Entity Recognition，简称 NER）是然语项核任务，旨在从名、地名、组织机构名、时间、期等。本中识别并分类具有特定意义的实体，如中国市场政治实体产品/服务名称公司名称推动Apple Intelligence（苹果智能）进苹果公司正在努结构化处理（NLP）中的

28. 需求理解 —— 精确上下

29. 需求理解 —— 控件实体 • • • • • Components (组件) Inputs Navigation Containment Communication 浮层导航栏与板控件框架控件内容展示类控件 • Material Metaphor: 基于物理世界的隐喻进分类 • Intentional Hierarchy: 建明确的视觉层次 • Responsive Interaction: 响应式交互设计列表选择型控件附加逻辑控制条件。。。。

30. 需求理解 —— 基于控件实体的出码模型

31. 需求理解 —— 基于控件实体的优势 P 任务独任务精确性每个每个逻辑任务都有明确的UI控件主体避免"相似控件与逻辑的推理导致出码幻觉" 任务可以独 UI实体属性模型 D 边界清晰性可扩展性类似NER的精确边界识别分类体系可根据业务需要扩展避免逻辑归属模糊导致的重复或遗漏属性模型 C 和验证降低任务间的耦合度 A 执性持新的交互模式

32. PRD 拆解 —— 模型微调模型微调(Fine-tuning)：在预训练模型上通过在特定任务的数据集上进还能让模型学会解决特定问题的细微差别，从不是基础模型的权重，使基础模型适应某项任务集（称为低秩适配器）的权重，需更新模型参数前添加可训练的“前缀向量”，只优化这些前缀参数。 * LoRA 微调：通过在调整过程中改变模型参数的代表性成符合特定任务的输出，层的输本的提示来引导模型 * Prefix-tuning：在每预训练模型的泛化能在保持模型相对轻量化的同时，显著提升在特定任务上的准确度和效率。 * Prompt-tuning：通过修改输额外的训练，这样不仅可以利，

33. PRD 拆解 —— LoRA 微调（如 80GB）低（如 16GB）训练时间长短（提速 3-5 倍）存储空间完整模型副本仅 LoRA 权重部署灵活性低

34. 微调结果对评估控件归类是否精确 ● 准确率：是否误检微调后的多模态模型 ● 召回率：是否漏检（带图评测）微调后的多模态模型 ● F1分数：两者的调和平均数微调后的纯纯本Baseline 型 ● 准确率：0.83 ● 准确率：0.51 ● 召回率：0.72 ● 召回率：0.69 ● F1分数：0.74 本模（图评测） ● 准确率：0.81 ● 准确率：0.88 ● 召回率：0.87 ● F1分数：0.85 ● 召回率：0.73 ● F1分数：0.75 ● F1分数：0.57 *数据来源于每份测试PRD的指标平均值

35. PRD 拆解后的效果

36. 02 AI Coding 端侧关键解法 #3 UI 还原度出码

37. 低精度 UI 出码原因模型存在幻觉还原度低 Figma设计稿布局复杂，存在推理瓶颈任务复杂，上下多成、漏遗忘成view 相设计稿还原度低代码审核成本

38. 还原度检测流程节点1-2 节点2-1 节点2-2 还原度检测

39. 还原检测法直时的案

40. 还原度检测、字体等和Figma json中次完整的还原度检测需要 N 分钟环节，法很好的集成到AI出码环节

41. 静态还原度检测模型推理约束关系来确定View布局，当静态代码约束正确时，运平静态约束关系的还原度检测准确率可以达到 88%+的通过案时即可准确还原UI结构。基于

42. 02 AI Coding 端侧关键解法 #4 UI 组件召回

43. UI 组件召回问题：功能实现 OK，但是代码采纳率低。，降低和开发意图，智能召回组件库中的最佳匹配组件，避免重复造轮解法：基于代码上下期维护成本。

44. UI 组件召回 —— 时属性，动态成

45. 03 典型业务场景与需求分析

46. 典型业务场景与需求分析

47. 典型业务场景与需求分析

48. 典型业务场景与需求分析评估需求出码质量 ● 例通过率：评估代码逻辑准确性 PRD 拆解微调模型 ● 代码采纳率：是否按企业内部规范出码 UI还原度检测 UI 组件召回 ● 代码采纳率： 78.6 % ● 还原度检测 ● 代码采纳率： 55.6 % ● BaseLine 例通过率： 85.7 % 例通过率： 67.3 % ● 代码采纳率： 44.5 % ● 例通过率： 64.1 % ● 代码采纳率： 36.6 % ● 例通过率： 52.3 % *数据来源于每份测试PRD的指标平均值

49. 典型业务场景与需求分析根据实际需求的复杂度，将需求分层 Easy、Medium、Hard 3 种类别的测试集，能够看到适配完的 CodeAgent 有不错的表现，整体端到端提升 10% 左右，在某些垂类测评中效果显著。 Agent Easy Medium Hard GPT-5-Codex (GPT-5 High) 38% 35% 26% Claude Code (Sonnet 4.5) 35% 33% 26% Cursor (Claude Sonnet 4.5) 36% 34% 30% Custom Code Agent 40% 38% 34%

50. 04 总结与展望

51. 总结与展望技术评审交互评审技术案 Coding 联调& 测视觉缺陷修复查 Topic 1：如何构建科学的端到端评测 Topic 3：如何保证客户端UI 的体系，期指导和度量 Agent 动作？度出码？对需求理解这个环节， Topic 4： Topic 2： PRD 如何拆解，拆解到什么粒度？代，如何更效的做组件识别召回？ Agent能缝切换到代码直出的新范式跃，我们可以的随着模型能还原对期 UI 组件的新增和迭客户端实现 PRD 到代码的直出，当下是做不到的，不影响我们的发展路径选择：以评测驱动也许后回归发布需求评审提升。

52. 总结与展望

53. 05 Q & A

54.

55. THANKS 模型正在重新定义软件 Large Language Model Is Redefining The Software