去哪儿网：前端需求端到端交付AI落地实践

前端端到端交付的核心目标

近两年，AI Coding 在代码生成上的能力快速提升，但从完整的软件研发过程看，编码只是需求交付中的一个环节。一个需求从提出到最终上线，需要持续跨越多个研发阶段。

如果这些环节仍依赖开发者人工推进，那么 AI 写代码再快，也很难真正提升整体交付效率。因此，前端端到端交付关注的不只是“写代码”，而是让 Agent 能够持续参与并推进完整研发链路：

产品立项 → 需求分析 → 产品设计 → 技术实现 → 前后端联调 → 测试验证 → 发布部署 → 线上验证

核心目标是让 Agent 围绕同一个需求持续理解上下文、推进流程并完成结果验证，减少人工的信息同步、上下文传递和流程操作。

现阶段并不直接覆盖完整生命周期，而是优先打通 Agent 可以深度参与的核心链路：

需求 → 开发 → 测试 → 联调

在这条链路稳定后，再逐步扩展到发布部署和线上验证，最终形成完整的前端端到端交付体系。

前后端端到端交付的关键差异

从研发流程看，前端与后端端到端交付的主要差异体现在以下几个方面：

• 需求输入多元：输入除需求文档外，还包含设计稿和交互说明信息

• 联调测试依赖真实设备环境：需使用真机设备，并考虑不同设备兼容性

• 验证维度多：除数据准确性外，还需保证展示准确性和交互准确性

• 发布部署的工程种类多：包括 RN、H5、小程序、iOS、Android 等工程形态

前端端到端交付需要解决多物料解析、真机自动联调测试、多端实现以及多端工程部署等问题，并在过程中同时保证数据、视觉和交互结果符合预期。

其中对交付质量影响较大的两个问题：一是设计稿与交互的准确还原，二是真机环境下的自动化验证与联调。

UI 设计稿与交互的准确还原

不同的端有不同的渲染特性、组件能力和平台规范，如果 Agent 仅凭截图和设计稿信息直接生成代码，往往只能还原“看起来像”的视觉结果，却无法准确理解不同端上的真实布局规则、组件边界、状态变化和交互行为，最终容易出现样式偏差、适配异常、组件误用、复用关系判断错误等问题。

将设计稿转换为结构化 UI 信息

UI 设计稿同时包含视觉属性、页面结构和不同的交互状态。

完整设计稿中通常存在大量与当前无用或重复的信息，例如隐藏图层、重叠元素等，以及各个节点中重复的样式属性。一个页面存在默认态、选中态、加载态、异常态和弹层态时，多个画板之间还会包含大量相同结构。

如果把完整的设计文件和原始节点数据直接交给 Agent，会快速占满上下文。因此，会先预处理与当前需求相关的画板和模块，将设计稿转化为为结构化 UI 物料：

经过处理后，Agent 获取的是与当前需求直接相关的页面、模块和状态信息。上下文占用更小，信息密度更高，也更容易定位页面节点、组件边界和状态差异。

对不同端进行规范适配

结构化 UI 信息描述的是设计意图，代码生成还需要结合目标端的规范。

会先识别项目使用的技术栈、页面入口、现有组件和样式方案，再按照目标端转换布局与组件。

生成过程中会优先复用目标项目已有的组件、设计规范和代码写法，但复用不能改变设计稿已经明确的尺寸、层级、素材和布局结果。无法直接映射的属性会记录具体原因和处理方式，避免引入项目中不存在的组件或依赖。

交互也会按端侧能力进行实现。点击、滚动、弹层、返回、键盘输入、安全区域和页面跳转，需要分别映射到对应平台的事件体系和导航机制。实现完成后，再通过端上自动化操作验证页面入口、交互步骤和状态变化，检查结构化设计信息是否在目标端得到正确呈现。

真机自动化验证联调

前端项目，尤其是在移动端场景下，真正的问题往往发生在运行态。

因此，端到端交付必须让 Agent 在真机上进行验证和联调。

让 Agent 真正操作应用进行验证和联调

需求流程会生成验收清单（Checklist）和联调接口信息，再由 Agent 操作本地手机完成验证和联调。

Spec 中的验收项会先转换成可执行 Case。每个 Case 都包含页面入口、测试数据、操作步骤和验收断言。涉及特定城市、订单、账号或日期的场景，测试数据会提前写入 Case，执行时不能临时猜测或随机选择。

设备调度器会主动发现已经连接的 Android 和 iOS 设备。Android 通过 ADB 接入，iOS 设备通过本地测试引擎注册。空闲设备只有一台时顺序执行；存在多台空闲设备时，不同 Case 可以分配到不同设备并行运行。

单个 Case 的执行过程大致如下：

页面有直达地址时，Agent 会直接打开被测页面，避免每次都从 App 首页开始导航。点击和输入优先使用 OCR 等固定工具；OCR 无法定位控件时，再使用视觉模型辅助判断位置。每次操作后都必须读取新的截图，不能连续执行一串未经确认的坐标操作。

测试结果会按固定结构落盘：

{
  "caseId":"case_001",
  "intent":"验证筛选项切换后的页面状态",
  "status":"success|failed|error|timeout",
  "duration":9000,
  "device_report_url":"...",
  "steps":[],
  "acceptance_criteria":{}
}

并产出相应的测试报告：

联调也会使用同一份执行记录。如果页面结果与预期不一致，报告会保留失败步骤、截图和操作时间。后续可以结合对应时间段的接口请求参数、响应数据和异常日志，判断问题出在前端渲染、后端返回、测试数据还是运行环境。

发现问题自动修复

自动化测试联调真正有价值的地方，并不是发现问题，而是能够继续驱动研发流程进行问题修复，让整个过程形成一个自动闭环。

测试失败后，系统会先写入失败结果并释放设备，再开始分析。这样即使后续修复过程被打断，失败截图、操作步骤和设备报告仍然存在，设备也不会一直处于占用状态。

失败处理过程如下：

重跑通过后，新的结果会更新到测试报告。仍然失败、执行报错、超时，或者全部 Case 都被跳过时，测试阶段不会自动标记完成。流程需要继续处理失败项，或者由开发者明确记录跳过原因和风险后再交付。

端到端交付的稳定性保障机制

端到端交付首先面临的并不是“模型能力够不够强”，而是一个非常工程化的问题：

一个持续几十分钟甚至数小时的任务，如何保证它能够稳定执行？

普通 AI Coding 的工作方式通常是围绕一次对话展开的。

开发者提出需求，模型读取代码、分析问题、修改文件，然后继续通过聊天上下文记录已经做了什么。

对于一个几分钟可以结束的小任务，这种方式通常没有问题。

但端到端任务天然是长任务，一个需求可能需要经历：

在这个过程中，Agent 很可能执行几十甚至上百次工具调用。

一旦任务运行时间久了，上下文越来越长，触发上下文压缩，通常会出现以下几个问题，导致模型推进任务的稳定性下降：

• 任务执行流程错乱
• 用户关键决策可能被遗漏
• 以为完成了某项工作，但其实只做了一半

流程状态可恢复

长任务需要把执行进度从聊天上下文中拿出来，写入工程内的状态文件。状态文件只记录恢复任务必需的信息，例如任务 ID、当前阶段、已完成阶段、进入当前阶段的时间，以及检查点目录。

脱敏后的状态结构会包含类似下面这些字段：

{
  "workflowId":"ar-20260813-******",
  "status":"active",
  "step":3,
  "stepName":"撰写 Spec",
  "completed":[1, 2],
  "currentStepEnteredAt":"2026-08-13T09:30:00.000Z",
  "checkpointDir":".qfe/state/analyze-requirements/ar-20260813-******",
  "resumeFile":".qfe/state/analyze-requirements/ar-20260813-******/resume.md"
}

Agent 每完成一个阶段，都要提交本阶段的实际产物说明。状态机确认入口条件已经满足后，才会更新 step 和 completed，同时生成一份阶段检查点。仅修改状态数字无法让流程继续。

如果任务被打断，新的 Agent 先读取当前状态和 resume.md，再按索引读取已经生成的检查点进行恢复，不需要重新加载完整聊天记录，也不会重复执行已经完成的阶段。

需求发生变化时则执行回退。状态机会撤销受影响阶段的完成标记，并把旧检查点移入过期目录。旧结果仍然保留，方便排查和审计，但后面的 Agent 不能继续把它当作当前输入。

遵循用户最新决策

长任务中最容易丢失的内容，通常是用户在过程中确认过的选择。例如：是否保留旧交互、接口异常时展示什么、某个改动是否需要兼容旧版本。

这类信息会单独写入用户决策记录文件，而不是夹在聊天记录中。只有用户明确确认的内容才能进入决策文件，Agent 自己推荐的方案不能写成已确认决策。

一条决策记录大致如下：

{
  "id":"decision-20260813-******",
  "step":2,
  "question":"切换筛选项后是否保留已选条件？",
  "selectedLabel": { "key":"A", "label":"保留已选条件" },
  "rejected": [
    { "key":"B", "label":"清空已选条件" }
  ],
  "source":"user-confirmed"
}

后续生成 Spec、实施计划和代码时，都会先读取当前有效的决策记录。被否决的方案不会因为更换 Agent 或发生上下文压缩又回到实现中。

如果用户后来改变选择，新记录会标记指向历史旧记录。旧决策继续保留，但退出有效决策列表。这样既能使用最新结论，也能查清需求为什么发生变化。

任务进展记录

状态机解决的是阶段推进，任务列表解决的是当前阶段内部做到了哪里。

进入代码实现后，实施计划会继续拆成多个 Task 或执行组。每个执行组都要留下独立报告，至少记录以下内容：

• 当前状态：DONE、DONE_WITH_CONCERNS、BLOCKED 或 NEEDS_CONTEXT；
• 实际修改的文件；
• 尚未确认的问题；
• 完整报告的文件路径。

多 Agent 灵活调度实现不同任务

1. 根据任务种类调度不同的Agent

   当任务规模继续变大以后，单 Agent 会遇到明显瓶颈。

   因为不同阶段需要处理的信息完全不同：

   

   如果所有信息全部交给一个 Agent 处理，那么随着任务推进，上下文会持续膨胀。

   最终一个 Agent 同时需要“记住”大量其实只在某个阶段有用的信息。

   因此更合理的方式是：

   让不同 Agent 负责不同类型的任务，由一个统一的调度机制完成整体交付。

   

   这样可以显著降低单 Agent 的上下文压力。

2. Agent调度上下文优化

   随着流程不断推进，如果每次 Agent 切换都把完整聊天记录、历史分析和中间过程继续向后传递，上下文仍然会快速膨胀，多 Agent 只是把“一个大上下文”拆成了“多个大上下文”。

   因此，Agent 调度过程中需要控制上下文的传递方式：

   • 只传递当前任务真正需要的信息。不同 Agent 根据职责读取需求、实施计划、代码变更、测试用例等对应产物，而不是继承完整会话历史。
   • 产物落盘，上下文按需读取。阶段结果以文档、状态或结构化产物进行沉淀，Agent 之间主要传递产物路径和关键状态，需要时再读取具体内容。
   • 保留关键决策，而不是保留完整过程。例如用户选择的方案、已经确认的约束、当前任务状态等需要持续保留；大量探索过程、临时分析和已经失效的信息则无需继续进入后续上下文。
   • 按任务重新组装上下文。调度到开发 Agent 时重点提供需求和实施计划；调度到测试 Agent 时重点提供验收条件、测试 Case 和构建产物；调度到联调 Agent 时重点提供失败信息、运行日志和相关代码。

   这样，每个 Agent 获得的都是与当前任务最相关的一小部分上下文，既降低 Token 消耗和上下文压力，也减少无关信息对 Agent 判断的干扰。

工程复利：构建持续演进的项目知识体系

一个需求完成后，Agent 通常已经为了实现它进行了大量探索，积累了许多信息，例如入口、涉及的组件、数据流向、埋点等：

传统 Agent 进行开发中，这些信息通常只存在于当前对话。任务结束以后，这些探索过程基本全部丢失。下一次出现类似需求时，Agent 又要重新搜索一次项目。这会产生大量重复成本，因此端到端体系中的另一个重要方向，就是把 Agent 的探索过程转化为项目知识。

以模块为粒度记录知识

项目知识如果只按照“某个需求”进行沉淀，随着需求不断增加，很容易变成大量零散、重复的文档，Agent 在后续任务中依然很难快速找到真正有用的信息。

因此更合适的方式，是以工程模块作为知识沉淀的基本单位。

例如一个订单详情页面可以按照：订单状态模块、提示条模块、退款进度模块等来划分

对于每个模块，可以逐步沉淀：

这样知识就不会大量零散，而是可以沉淀为具有稳定结构的的“项目地图”。

随研发流程更新知识

项目知识库一个常见的问题是维护成本。

如果要求开发者单独整理知识文档，那么随着项目变化，文档非常容易过期。

端到端体系则可以天然解决这个问题。

因为 Agent 本身就在持续执行真实研发任务。

它每天都会：阅读代码、修改代码、执行测试、处理错误、验证结果，因此知识更新可以成为研发流程的副产物。

知识不再依赖人工一次性建设，而是随着每一次研发任务持续演进。

形成工程复利

当需求数量不断增加之后，系统对项目的理解也会不断增加。

第一次修改某个模块时，Agent 可能需要大量搜索。

第二次进入这个模块时，已经存在部分知识。

到了第十次时，大量工程信息已经沉淀下来。

这形成了一个持续增强的正循环。这也是端到端交付和普通 AI Coding 最大的区别之一：普通 AI Coding 优化的是一次编码过程，端到端交付建设的是一套会随着研发过程不断积累能力的工程系统。

当前进展与未来展望

目前，前端端到端交付已经从单点 AI Coding 逐步扩展到需求理解、代码实现、自动化测试、自动联调并修复问题等核心环节，且已经在试点使用了。

从实际效果看，当前存在三个不足：

• UI 还原度仍有提升空间，复杂页面和细节样式下还原质量需提升
• 部分任务场景存在过度处理，导致链路偏长、处理耗时较高
• 跨项目知识复用能力不足，已有经验还没有形成跨项目的共享与复用机制

后续会重点围绕提升 UI 还原准确率、简化任务执行链路、加强跨项目知识复用三个方向持续优化，在保证交付质量的同时进一步提升整体效率，长远来看，希望逐步把当前研发过程中大量离散的 AI 能力连接起来：

最终形成一套真正围绕软件交付结果运行的研发系统。它衡量的也不再只是AI 写了多少代码，而是一个需求有多少研发环节可以由系统持续、自主、稳定地完成。

JOTO 企业落地观察

• 前端端到端交付体系本质是构建一套可演进的智能体工程基础设施。其核心挑战不在模型能力，而在工程化——状态持久化、决策隔离、产物标准化与上下文裁剪。这对企业部署AI系统提出了新要求：需将Agent视为长期运行的服务组件，而非一次性对话工具。
• 真机自动化验证与联调能力表明，前端AI落地必须突破仿真环境局限，直面真实设备生态。这对RAG知识工程提出更高要求：需将设备驱动、平台API、兼容性矩阵等非结构化运维知识纳入知识库，并支持动态检索与执行。
• 以模块为粒度沉淀知识、随研发流程自动更新，标志着AI系统正从“任务级工具”转向“组织级记忆”。这对AI安全治理构成新命题：知识沉淀需建立访问权限、变更审计与版本追溯机制，防止知识污染或误用。
• 多Agent调度与上下文优化策略，揭示了智能体工程的关键取舍：不追求单Agent全能，而强调任务解耦与接口契约。这对FDE驻场共创模式有直接启示——需将业务逻辑、技术规范、质量标准预先定义为Agent间可交换的结构化协议。