How Qunar Implements AI‑Driven End‑to‑End Front‑End Delivery

Overview

Qunar has built an AI‑enabled end‑to‑end front‑end delivery system that lets autonomous agents continuously participate in the full software development lifecycle, aiming to reduce manual hand‑offs and improve overall delivery efficiency.

1. Differences Between Front‑End and Back‑End End‑to‑End Delivery

Requirement input is multi‑modal, including documents, design drafts, and interaction specifications.

Integration testing depends on real devices and must handle device compatibility.

Verification spans multiple dimensions: data accuracy, visual correctness, and interaction fidelity.

Deployment involves many engineering forms such as RN, H5, mini‑programs, iOS, and Android.

Front‑end delivery must resolve multi‑asset parsing, real‑device automated testing, multi‑platform implementation, and ensure data, visual, and interaction results meet expectations.

2. Accurate UI Design Restoration

Different platforms have distinct rendering characteristics, component capabilities, and layout rules. Feeding raw screenshots and design files to an agent often yields only a visual look‑alike, leading to style deviations, component misuse, or incorrect interaction handling.

Convert Design Files to Structured UI Information

Design drafts contain visual attributes, page structure, and interaction states, as well as redundant or hidden layers. To avoid overwhelming the agent's context, Qunar preprocesses only the boards and modules relevant to the current requirement, converting them into a compact, structured UI description.

After processing, the agent receives a reduced context containing only the pages, modules, and states directly related to the requirement, making it easier to locate nodes, component boundaries, and state differences.

Platform‑Specific Adaptation

The structured UI description captures design intent; code generation then aligns with the target project's technology stack, existing components, and style guidelines while preserving explicit dimensions, hierarchy, assets, and layout results. Unmappable attributes are recorded with reasons to avoid introducing non‑existent components or dependencies.

3. Real‑Device Automated Verification and Integration

Agent‑driven testing generates a checklist and integration interface information, then operates a connected Android or iOS device to execute the steps.

Each checklist item is transformed into an executable Case containing page entry, test data, operation steps, and acceptance assertions. Device scheduling discovers connected devices (Android via ADB, iOS via a local test engine) and runs cases in parallel when multiple devices are idle.

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

If results differ from expectations, the report retains failed steps, screenshots, and timestamps. Combined with request parameters, response data, and logs, developers can pinpoint whether the issue lies in front‑end rendering, back‑end response, test data, or the environment.

Automatic Issue Fixing

Beyond detection, the system drives the development workflow to fix problems, forming an automatic closed‑loop. After a failure, the system records the result, releases the device, and begins analysis. Even if the fix process is interrupted, failure artifacts remain for later review.

When all cases pass, the new results update the test report. Persistent failures, execution errors, timeouts, or completely skipped cases keep the testing phase open until addressed.

4. Ensuring Stable Execution of Long‑Running Tasks

End‑to‑end tasks can run for tens of minutes or hours, involving dozens to hundreds of tool calls. Prolonged execution leads to context bloating, causing workflow disorder, missed user decisions, or incomplete work.

Process State Recovery

Long tasks extract progress from chat context into a persisted state file containing only essential fields such as workflow ID, status, current step, completed steps, entry timestamp, and checkpoint directory.

{
  "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"
}

After each stage the agent records the actual output and updates step and completed. If a task is interrupted, a new agent reads the state and resume file, then continues from the last checkpoint without re‑executing completed stages.

User Decision Persistence

User confirmations (e.g., whether to retain a filter after switching) are stored in a separate decision record, not mixed with chat logs. Only confirmed decisions become part of the decision file; agent‑suggested options are excluded.

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

Subsequent spec generation, planning, and code generation read the current valid decisions, ensuring outdated proposals are never re‑introduced.

5. Multi‑Agent Flexible Scheduling

When task scale grows, a single agent becomes a bottleneck because each stage requires different information. Splitting the workload among specialized agents reduces context pressure.

Let different agents handle different task types under a unified scheduler.

Key scheduling rules:

Only pass the information truly needed for the current task.

Persist artifacts to disk; agents read artifacts on demand.

Retain critical decisions and task status, discard exploratory or obsolete context.

Re‑assemble context per task: requirements for development agents, acceptance criteria for testing agents, failure logs for integration agents.

6. Engineering Compounding

Each completed requirement leaves behind exploration data—entry points, involved components, data flows, instrumentation—that would otherwise be lost. By persisting this knowledge at the module level, the system builds a stable “project map”.

Knowledge updates become a by‑product of daily development tasks—reading, modifying, testing, and validating code—so the knowledge base evolves continuously without extra manual effort.

Repeated work on the same module benefits from accumulated knowledge, creating a positive feedback loop that distinguishes AI‑driven end‑to‑end delivery from one‑off AI coding.

7. Current Progress and Future Outlook

Qunar has piloted AI‑assisted end‑to‑end front‑end delivery covering requirement understanding, code implementation, automated testing, integration, and issue fixing. Three main shortcomings remain:

UI restoration accuracy still needs improvement for complex pages and fine‑grained styles.

Some task scenarios involve over‑processing, leading to longer pipelines and higher latency.

Cross‑project knowledge reuse is insufficient; existing experience is not yet shared across projects.

Future work will focus on improving UI accuracy, simplifying task execution chains, and strengthening cross‑project knowledge reuse, ultimately turning AI capabilities into a continuously evolving software delivery system that measures how many development stages a requirement can be autonomously completed.