AI 编码（AI Coding）最容易被误解成"一句话生成代码"。真实项目里，这种方式前期很快，后期却常因需求没对齐、接口字段不稳、设计图还原偏差大而反复返工。问题不在于 AI 不会写代码，而在于缺少一套能约束 AI 工作边界、产物顺序和验证标准的工程框架。
这里的解决思路是引入流程框架（harness）：把提示词（prompts）、命令（commands）、子代理（subagents）、规则（rules）和门禁流程组织成一套开发约束。这个框架不负责替代工程判断，而是规定 AI 什么时候分析、什么时候等待审阅、什么时候生成代码、什么时候必须验证，从而把"一次性对话"变成"可追踪的开发流水线"。
这套流程面向 RN（React Native，跨端移动开发框架）需求开发，输入包括产品需求文档（PRD）、接口文档和设计稿（这里以 Figma 为例）。AI 负责分析、整理、生成、修复和审计；人负责判断、确认、取舍和兜底。核心原则是把不确定性前移，把代码生成后移，让实现能追溯到需求、接口、设计和架构证据。
先统一几个后文会反复出现的术语。它们在项目中通常也会以英文文件名、Agent 名称或自动化产物名出现，所以正文保留对应原文，方便和实际工程产物对照：
- 需求规格（RequirementSpec）：把 PRD、接口和设计稿整理成可审阅的实现依据。
- 架构设计（ArchitectureDesign）：说明模块拆分、数据流、文件落点和验证策略。
- Agent：承担某类固定职责的 AI 子流程，例如代码生成、编译验证、视觉审计。
- 代码生成（code-generator）：按架构设计实现代码，并说明实现是否对齐架构。
- 架构对齐报告（ArchitectureAlignmentReport）：代码生成后输出的检查结果，用来证明实现是否符合架构设计。
- 编译验证（build-verifier）：执行 lint、TypeScript 编译和构建检查。
- 视觉审计（visual-auditor）：对照 Figma 检查 UI 还原效果。
- 直读审计（direct-read-audit）：记录颜色、字号、间距等样式值来自哪个设计节点。
- 产物（artifact）：流程中生成的中间文件，例如接口字段表、Figma 节点信息、资源映射表。
一、先把输入变成规格
开发的第一步不是写页面，而是拆清输入源。PRD 提供业务目标、功能范围和验收口径；接口文档提供字段结构、错误码和前后端边界；Figma 提供页面结构、组件状态、资源节点和交互细节。
这些信息如果直接混进代码生成，AI 很容易做经验补全：接口没写字段就自己命名，PRD 没描述异常状态就只做成功态，Figma 没读到资源就用占位图。代码越早生成，这类隐性假设越难发现。
因此流程先要求 AI 产出需求规格 RequirementSpec，而不是直接实现。规格里要写清功能范围、页面结构、字段规则、接口依赖、状态流转、异常场景、埋点要求、Figma 节点拆分和验收标准。关键结论都要标注来源，后续偏差才能回到证据本身定位。
二、两道人工门禁：需求审阅和架构确认
需求规格产出后先进入人工审阅。审阅重点不是改文案，而是确认 AI 对业务和边界的理解是否可靠：核心路径是否完整，异常场景是否覆盖，字段可信度是否标注，Figma 组件状态和资源节点是否记录。AI 擅长整合信息，但字段缺失时是等待接口补充、做本地兜底，还是调整交互口径，需要人决策。
需求通过后，才进入架构设计 ArchitectureDesign。架构设计要明确模块拆分、目录结构、组件分工、状态管理、接口封装、数据流、异常处理和验证策略。对 RN 项目，还要覆盖平台差异、组件复用、路由注册、埋点 routeList（路由埋点清单）、响应式布局和资源处理。
Figma 在架构阶段不会直接变成最终样式值，而是形成"分块到实现映射"和"直读计划"：哪个设计分块落到哪个组件，绑定哪些字段，后续代码生成 Agent（code-generator）要直读哪些 nodeId（Figma 节点 ID）和属性。两道门禁的价值，是防止 AI 在错误需求或错误架构上快速生成大量代码。
三、代码生成：按架构和证据执行
代码生成 Agent（code-generator）的职责不是"看需求写 TSX"，而是按架构设计实施 RN / TypeScript（类型化 JavaScript）代码，并输出架构对齐报告 ArchitectureAlignmentReport，证明实现与架构一致。它会先识别实现类型，例如列表页 ListPage、详情页 DetailPage、表单页 FormPage、弹窗 Popup、纯接口 APIOnly、纯埋点 TrackingOnly、工具方法 Utility 或数据模型 Model；不同类型对应不同产物，新页面还可能涉及 native route（客户端路由）、web route（网页路由）和埋点 routeList。
实现前，代码生成 Agent 必须读取需求规格、架构设计、接口字段产物、Figma summary（设计稿摘要）、codeHints（代码生成提示）和项目规则。codeHints 会约束参考页面、Figma 样式、限定文件、Web 特殊处理和依赖变更；团队经验文档也会按 RN 页面开发、RN UI 组件库、lint（静态代码检查）、埋点等关键词检索后再应用。
真正写代码前，还要根据架构设计里的"分块到实现映射"生成执行计划。每个 block（设计分块）都必须有目标文件、目标组件、数据字段、交互和证据。缺少落点时，不能硬写代码，只能在架构对齐报告中标记 blocked（受阻）。
涉及 Figma 时，代码生成 Agent 会先验证磁盘产物是否真实存在，包括元数据 metadata、原始节点 raw node、参考代码 reference code、覆盖度审计 coverage audit、资源映射 asset mapping、单元契约 unit contract 和产物清单 artifact manifest。文档写着已验证 verified 不够，必须以文件事实为准；缺少关键产物时，回推需求分析子流程 requirement-analyzer 补齐，禁止凭截图手写 UI。
UI 编码前会生成 direct-read-audit.md。每个关键视觉常量都要能追溯到 node_id + 属性名 + raw_value + RN mapping，也就是"设计节点、样式属性、原始值、RN 写法"四者要对应起来。颜色、字号、圆角、间距、边框、阴影和图片资源不能只来自截图感觉；截图只用于最终校准，不作为首要编码来源。
设计稿参考代码 Figma reference code 是实现蓝本，但需要适配到 RN / ZRN UI（团队 RN 组件库）：div 转 View，text 转 Text，img 转 Image，按钮形态分组 button-like frame 转 ZRN Button 或 Pressable，CSS flex 转 RN flexbox，阴影 shadow 拆成平台策略。组件复用前核查 ZRN UI 的组件参数 props、默认状态、Web/Harmony 可用性和样式覆盖方式；资源节点按资源映射 asset mapping 分类处理。
最终实现顺序保持稳定：types.ts、api.ts、状态逻辑 hooks/state、子组件 leaf components、页面容器 page container、路由和 Web 注册 route/web registration、埋点和日志 tracking/logging。实现结束后生成架构对齐报告，覆盖文件、分块、接口字段、路由平台、ZRN UI 与样式、埋点、偏差和待验证项。只有关键项全部通过（pass），才能进入编译验证；如果发现缺失（missing），最多回流补全 5 轮，仍无法补齐则 blocked。
四、编译验证：把"写完"变成"可运行"
代码生成完成并不代表任务完成。编译验证 Agent（build-verifier）会执行 lint、TypeScript 编译和必要的网页构建 Web/build 检查；多平台场景下，还会追加 iOS、Android、Harmony 相关打包产物 bundle 验证。
编译失败时，AI 不只是贴出错误，而是自动定位并修复。常见问题包括模块引入 import 路径错误、类型不匹配、接口字段变更、平台后缀缺失、依赖误用和 lint 规则不满足。只有错误确实来自外部环境或缺少人工决策时，才允许部分通过 partial。
这一步把"语义上看起来对"的代码推进到"项目工具链可以接受"。很多 AI 生成代码的问题不是思路错，而是工程约束没满足，编译验证就是基础质量闸口。
五、视觉审计：UI 还原要回到证据链
编译通过只能说明代码能跑，不能说明页面还原正确。视觉审计 Agent（visual-auditor）会对照 Figma 检查布局、间距、字号、颜色、组件状态、资源、响应式表现和多端差异。
下面是一组视觉审计对比样例。左侧为 Figma 设计稿，右侧为 RN 实现效果。结论是：除标签和虚线因图层复杂未被完整识别外，其余页面结构、文本、图片、间距、按钮和刷新浮窗等核心元素都完成了还原。
| Figma 设计稿 | RN 实现效果 |
|---|---|
 |
 |
视觉审计不能只看整页截图，也不能发现问题后让人手动修。更稳定的做法是输出偏差清单，回流给代码生成 Agent 精准修复。修复时仍遵守直读审计 direct-read-audit：新增或调整的视觉常量必须能追溯到设计稿原始值 Figma raw value。
六、经验沉淀：让流程越跑越稳
需求交付后，经验沉淀 Agent（experience-depositor）会把有效提示词、常见失败、修复方式、组件复用经验、Figma 直读规则、构建问题和视觉偏差沉淀为 SOP（标准作业流程）、检查清单或模板。把经验写回流程后，下一个需求才能更早避开同类问题。
结语
高效的 AI 编码不是把人从流程里拿掉，而是重新分配职责。AI 负责信息整理、代码生成、错误修复和视觉审计；人负责判断需求是否正确、架构是否可靠、取舍是否符合业务目标。
这套流程的关键不是某一个提示词，而是稳定的人机协作闭环：需求规格化、人工审阅、架构确认、证据驱动编码、编译验证、视觉审计、经验沉淀。只有前后链路都可追溯、可验证、可回流，AI 才能从"生成代码的工具"变成"参与工程交付的协作者"。