在 AI 编码的真实项目里最常见的痛点是：需求不对齐导致频繁返工接口字段不稳定引发编译错误还有“UI 看起来好像没问题，却在细节上与 Figma 有偏差”。为了解决这些问题，我们把 PRD、接口文档和 Figma 转化为可验证的工程产物，并标准明确下来。

一、先把输入变成规格 —— 把业务拆解成可追溯的证据链

传统做法往往直接把 PRD、接口和 Figma 混进代码生成器，导致 AI 自动补全出现大量隐性假设： - 接口字段缺失时自己命名 - PRD 未描述异常状态时只实现成功方法 - Figma 未解析到资源时使用占位图

这一步先让 AI 输出RequirementSpec其中包含功能范围、页面结构、字段规则、接口依赖、状态流转、异常场景、埋点要求及 Figma 节点拆分。每个关键结论都标注来源，后续偏差能直接回到原始证据。怎么说呢，

二、两道人工门禁 —— 防止 AI 在错误基础上快速生成大量代码

• 需求审阅：Ai 对业务理解是否可靠？话说回来，主要方法完整吗？场景覆盖了吗，按理说，字段可信度是否标注？Figma 的组件状态和资源节点是否记录？如果有缺失，需要人决定是等待补充还是调整交互口径。
• 架构确认：Ai 按照ArchitectureDesign进行模块拆分与目录规划。针对 RN 项目，还需考虑网站差异、组件复用、路由注册及响应式布局等。

三、代码生成 —— 按架构和证据执行，实现可追溯的“按块实现”计划

code-generator 不是随意写 TSX。而是根据ArchitectureDesign和RequirementSpecArchitectureAlignmentReport 证明实现与架构一致。

生成前先读取所有产物：

• interface-field tables,
• Figma node summaries。
• resource mappings,
• project rules.

若某设计分块缺少落点，则标记为 blocked; 怎么说呢，不允许硬写代码。

# UI 前置直读审计 在编码前会自动生成。不过，每个视觉常量都可追溯到node_id + 属性名 + raw_value + RN mapping —确保颜色/字号/间距等来自原始设计值。而非仅凭截图直觉，

四、编译验证 —— 把“写完”变成“可运行”的质量闸口

Ai 自动执行 lint、TypeScript 编译还有 Web 建立检查；多网站场景还会额外验证 iOS/Android/Harmony 的 bundle。编译失败时AI 会自动定位并修复常见错误：导入方法错误、类型不匹配、接口字段变更等；若错误来自外部环境或需人工决策，则允许部分通过。

五、视觉审计 —— 确保页面还原与设计保持一致性并形成偏差清单回流修复流程

Ai 对照 Figma 检查布局间距文字颜色资源等细节，并输出偏差清单。话说回来，该清单直接回流给 精准修复。同时仍遵守直读审计规则，新增或调整的视觉常量必须可追溯到原始设计值。

六、经验沉淀 —— 将每一次迭代转化为 SOP 与模板。让流程越跑越稳健

Ai 会将有效提示词、不易解决的问题及其修复方式，Figma 直读规则，还有编译或视觉偏差记录沉淀为 SOP 或检查清单，由 自动归档，为下一个需求提供更成熟、更高效的起点。

——从工具到协作者的角色转移与闭环闭合机制

Ai 在这套流程中的角色是：信息整理 → 代码生成 → 错误修复 → 可视化审计；而人类则负责判断需求正确性与架构可靠性，还有最终取舍。只有当整个链路——从需求规格化到经验沉淀——均可追溯且可验证时AI 才能真正成为项目交付过程中的协作者，而不仅仅是“一句话生成代码”的工具。