Vibe Coding Guide: Building Tongcheng Chengxin Travel Skill on Xiaoyi Platform

This guide details the complete development of the Tongcheng Chengxin travel skill on the Xiaoyi Open Platform using Vibe Coding, covering product design principles, intent routing, authentication flows, API specifications for seven travel domains, parameter standards, output formats, error handling, and the end-to-end development workflow from platform setup to deployment.

51CTO HarmonyOS Developer Community
51CTO HarmonyOS Developer Community
51CTO HarmonyOS Developer Community
Vibe Coding Guide: Building Tongcheng Chengxin Travel Skill on Xiaoyi Platform

Product Design

Core Design Principles

The Tongcheng Chengxin Skill adopts a minimalist architecture driven by four principles: Intent-driven routing extracts core business intent from natural language and maps it one-to-one to dedicated domain query interfaces, avoiding duplicate or chaotic multi-interface calls. Structured fields plus free-text passthrough precisely extracts fixed parameters (origin, destination, flight/train numbers) while placing all modifiers, personalized preferences, and weak constraints into an extra field passed unchanged to backend APIs. Original interface output returns the backend API raw response directly to the user; the large model does not summarize, rewrite, delete, or fabricate data, ensuring 100% authentic and authoritative information.

Capability Boundary

Tongcheng Chengxin is a full-category real-time travel search Skill powered by Tongcheng's self-developed Chengxin large model. All data originates from Tongcheng's official production systems, supporting real-time queries, structured display, and one-click booking across seven core travel domains:

Flights : inter-city flight search, flight-number precise query, low-price/special-fare recommendations, air-rail intermodal transfer compensation schemes.

Trains : inter-city train search, train-number precise query, station precise query, personalized filtering by train type/seat/time.

Hotels : city-wide hotel search, location preference filtering, star-rating/facility/price filtering, check-in date personalized matching.

Scenic Spots : city scenic spot search, theme/feature filtering, ticket price query, visit duration and ancillary service introduction.

Long-distance Buses : inter-city coach schedule search, bus station precise query, time-period preference filtering.

Vacation Packages : transport+hotel+scenic spot one-stop bundling, group tours/independent travel packages, multi-day itinerary planning, UGC real-guide queries.

Intelligent Traffic : parallel recommendation of train, flight, and bus options with intelligent comparison of optimal travel plans.

Intent Routing Decision Rules

The Skill routes strictly by semantic priority of user input. The decision tree maps keywords to specific query scripts with parameters:

User input
  ├─ Contains "low-price/cheap + flight" → flight-query --low-price
  ├─ Contains "flight/airplane"
  │   ├─ Has flight number → flight-query --flight-number "CA1234"
  │   └─ Has origin ± destination → flight-query --departure ... --destination ...
  ├─ Contains "train/high-speed/bullet/train-number"
  │   ├─ Has train number → train-query --train-number "G1234"
  │   ├─ Has station name → train-query --departure-station ... --arrival-station ...
  │   └─ Has city → train-query --departure ... --destination ...
  ├─ Contains "hotel/stay/check-in" → hotel-query --destination ... [--extra "..."]
  ├─ Contains "scenic/spot/ticket/fun" → scenery-query --destination ... [--extra "..."]
  ├─ Contains "bus/coach/long-distance-bus" → bus-query
  ├─ Contains "tour/group-tour/independent-travel/days/itinerary/vacation" → travel-query
  ├─ Contains "how-to-go/transport-mode" or only origin+destination without transport → traffic-query
  └─ Unclear intent → Guide user to specify: transport? hotel? scenic? vacation?

Account Credential Authentication Process (Mandatory)

Core Mandatory Rule

Before every skill execution, the credential status must be re-checked; historical session validation results cannot be reused. Even within the same conversation, each new query triggers a fresh credential validity verification to ensure security and compliance.

Credential Storage Path

/home/sandbox/.openclaw/.xiaoyienv

Global Authentication Method

Unified use of apikey request header for interface authentication.

Three-Level Authentication Flow

Step 1: Read local credential file – Read .xiaoyienv, validate two fields: <clientId>_login_token and <clientId>_login_token_expire_time. If present and not expired (current time < expire time), credential ready; proceed to business query. If empty, missing, or expired, go to step 2.

Step 2: Call tool to refresh credential – On credential anomaly, must invoke huawei_id_tool with fixed parameters clientId and skillName. On success, re-read local file for latest token; on failure/no response/user refusal, go to step 3.

Step 3: Environment variable fallback – Only when step 2 fails, read system environment variable CHENGXIN_API_KEY as fallback credential, place in apikey header.

Skill Encapsulation Specification

General Invocation Paradigm

All domain query scripts follow a fixed invocation format, executed via Node.js, with unified gateway, timeout, and common parameters:

node scripts/<domain>-query.js [business params] --channel <channel> --surface <surface>

Request protocol: All HTTPS POST to business gateway.

Gateway base URL: https://tc-chengxin/cases/api/ (example).

Interface timeout: Fixed 15 seconds.

Common parameters: --channel and --surface are globally required, cannot be omitted.

Detailed API Specifications per Domain

Flight Query (flight-query)

Endpoint: POST /flightResource Parameters: --departure (string, conditional required) – origin city, e.g., "北京". --destination (string, conditional required) – destination city, e.g., "上海". --flight-number (string, conditional required) – exact flight number, e.g., "CA1234". --low-price (flag, optional) – triggers low-price query logic; presence activates. --extra (string, optional) – modifiers like date, cabin, airline, time preference, e.g., "明天 最早 直飞". --channel (string, required) – channel identifier, e.g., "webchat". --surface (string, required) – UI type, e.g., "webchat".

Valid parameter combinations (choose one): departure+destination; flight-number; departure+low-price (optionally with destination).

Low-price sub-mode: --low-price is an independent query switch for low-price dedicated logic; can coexist with extra carrying personalized needs.

Response example:

{
  "code": "0",
  "data": {
    "flightDataList": [{
      "desc": "北京 → 上海 2026-04-21",
      "flightList": [{
        "flightNo": "MF8561",
        "airlineName": "厦门航空",
        "depAirportName": "北京大兴国际机场",
        "arrAirportName": "上海浦东国际机场",
        "depDate": "2026-04-21",
        "depTime": "07:50",
        "arrDate": "2026-04-21",
        "arrTime": "09:45",
        "runTime": "1时55分",
        "price": "327",
        "superlinkRedirectUrl": "https://...",
        "redirectAppUrl": "tctclient://..."
      }]
    }]
  }
}

Air-rail intermodal fallback: When interface returns no flights (code=1), automatically recommend nearby hub airports, retry query, and supplement train/bus transfer solutions.

Mandatory constraint: All flight data, prices, links must come from script raw output; manual fabrication or modification prohibited.

Train Query (train-query)

Endpoint: POST /trainResource Parameters: --departure, --destination, --departure-station, --arrival-station, --train-number, --extra (date, train type, seat, time, price preferences), plus mandatory --channel and --surface.

Valid combinations: departure+destination; train-number; departure-station+arrival-station.

Response example:

{
  "code": "0",
  "data": {
    "trainDataList": [{
      "desc": "北京 → 上海 2026-04-21",
      "trainList": [{
        "trainNo": "G1234",
        "trainType": "GD",
        "depStationName": "北京南站",
        "arrStationName": "上海虹桥站",
        "depTime": "09:00",
        "arrTime": "13:28",
        "runTime": "4小时28分",
        "ticketList": [
          {"ticketType": "二等座", "ticketPrice": 553},
          {"ticketType": "一等座", "ticketPrice": 933}
        ],
        "superlinkRedirectUrl": "https://..."
      }]
    }]
  }
}

Hotel Query (hotel-query)

Endpoint: POST /hotelResource Parameters: --destination (required), --extra (optional: check-in date, location, star, facilities, services), plus mandatory --channel and --surface.

Special rule: Destination is mandatory; if missing, guide user to provide.

Response example:

{
  "code": "0",
  "data": {
    "hotelDataList": [{
      "desc": "上海酒店推荐",
      "hotelList": [{
        "name": "上海虹桥新华联索菲特大酒店",
        "image": "https://xxx.jpg",
        "price": "1512",
        "star": "豪华型",
        "score": "4.8",
        "commentNum": "7493",
        "describe": "交通便利,设施齐全,服务优质。",
        "address": "泰虹路666号",
        "countyName": "闵行区",
        "brandName": "索菲特",
        "facilities": "停车场;免费wifi",
        "distance": "距虹桥火车站800m",
        "superlinkRedirectUrl": "https://..."
      }]
    }]
  }
}

Output rule: Hotel resources must display as cards; render top image when present; booking links use superlinkRedirectUrl preferentially.

Scenic Spot Query (scenery-query)

Endpoint: POST /sceneryResource Parameters: --destination (required), --extra (optional: theme, feature, level, crowd preference), plus mandatory --channel and --surface.

Response example:

{
  "code": "0",
  "data": {
    "sceneryDataList": [{
      "desc": "杭州景区推荐",
      "sceneryList": [{
        "name": "杭州宋城",
        "image": "https://xxx.jpg",
        "cityName": "杭州",
        "star": "4A",
        "score": "4.8",
        "commentNum": "14186",
        "price": "260",
        "openTime": "09:00-21:00",
        "playTime": "半天-1天",
        "describe": "世界三大名秀之一",
        "theme": "演出赛事",
        "superlinkRedirectUrl": "https://..."
      }],
      "needExtend": false
    }]
  }
}

Extend mode: When needExtend=true, automatically append traffic guidance, multi-ticket info, preferential policies, detailed intro, and tips.

Long-distance Bus Query (bus-query)

Endpoint: POST /busResource Parameters: --departure, --destination (both conditional required), --departure-station, --arrival-station (conditional required), --extra (optional: date, time period), plus mandatory --channel and --surface.

Routing synonyms: "汽车票", "大巴票", "客运", "长途汽车", "班车" all route to bus-query.

Vacation Package Query (travel-query)

Endpoint: POST /travelResource Parameters: --departure (optional, triggers full itinerary planning), --destination (required), --extra (optional: days, travel type, crowd, holiday needs), plus mandatory --channel and --surface.

One-stop return: Six modules – transport recommendations, hotel recommendations, scenic recommendations, bundled vacation products, daily itinerary plans, UGC user guides.

Intelligent compensation: If any core module missing, automatically output compensation query instruction to invoke corresponding domain script and complete the travel plan.

Intelligent Traffic Query (traffic-query)

Endpoint: POST /trafficResource Parameters: --departure (required), --destination (required), --extra (optional: date, transport priority), plus mandatory --channel and --surface.

Priority rule: When user specifies a single transport mode, call dedicated interface; only when user provides origin/destination without specifying transport, use intelligent traffic comprehensive query.

Common Parameter Design Specification

Channel and Surface Parameters

--channel

: values webchat, wechat, app, workbuddy – distinguishes client channel, adapts output format strategy. --surface: values webchat, mobile, desktop, table, card – forces table/card rendering strategy, unifies UI presentation.

Extra Free-text Parameter Design Philosophy

Core principle: Prioritize precise extraction of structured core parameters; all user modifiers, preferences, personalized needs are concatenated verbatim into extra field – no discarding, no simplification, no secondary processing.

Examples of need types and handling:

Time preference (earliest, latest, morning, afternoon, evening) → store in extra.

Price preference (cheapest, low-price, economy) → store in extra; flights can combine with low-price switch.

Service level (high-speed, bullet, first-class, business, five-star) → store in extra.

Itinerary preference (direct, transfer, fewer transfers, self-drive) → store in extra.

Crowd preference (family, couple, elderly, pet-friendly) → store in extra.

Feature filtering (free, night-view, night-tour, flower-viewing, sea-view) → store in extra.

Unified Output Format Specification

Resource-type-specific rendering rules:

Hotels & Scenic Spots: Forced card display; render top large image when image non-empty; show only APP booking links ( superlinkRedirectUrl).

Flights, Trains, Buses, Vacation: Auto-adapt by channel strategy; no separate image rendering; show only APP booking links.

Request Header & Security Specification

Standardized Request Headers

Local credential valid: apikey: ${<clientId>_login_token} Fallback credential scenario: apikey: ${CHENGXIN_API_KEY} Global: Content-Type: application/json Global:

User-Agent: TC-Chengxin-NodeJS/1.0.0

Network Security

Production environment enforces HTTPS only; only localhost loopback may use HTTP.

Domain whitelist: credentials and request data sent only to official domains.

Request body: unified JSON format, fixed version field version: "1.0.0".

Data Privacy

Transmission contains only structured business parameters and extra passthrough text; no extra privacy data.

All requests connect solely to Tongcheng official APIs; no third-party data flow.

Skill does not store query logs, does not collect user telemetry.

All booking links point to Tongcheng official compliant domains.

Error Handling Specification

Credential anomaly: Force re-verify each query; expired/invalid triggers tool refresh; refresh failure activates fallback key; no valid credential returns auth failure prompt guiding re-authorization.

Missing parameters: Precisely guide user to supply missing core structured parameters; no blind interface calls.

No data from interface: Flights trigger air-rail fallback; other scenarios friendly inform no matching resources and suggest alternatives.

Interface timeout: 15-second timeout triggers failure callback, returns network error prompt; never return empty data or fabricated content.

Data anomaly: Strictly return original interface error info; do not tamper error codes or suppress exceptions, facilitating troubleshooting.

Complete Skill Development Process

Following Vibe Coding, the standardized closed-loop process: Platform creation → Requirement input → Clarification → Result verification → Real-device testing → Review & launch .

Step 1: Platform Creation & Requirement Input

Log into Xiaoyi Open Platform, enter Skill → Vibe Coding , initialize project and input requirements: upload this full specification document as core reference; enter development instruction, e.g., "Based on uploaded MD spec, fully develop Tongcheng Chengxin Skill, strictly follow all interface fields, invocation rules, auth flows, output specs; complete TS implementation files for all domain interfaces; deliver end-to-end Skill development."

Platform creation screenshot
Platform creation screenshot

Step 2: Development Interaction & Clarification (Core Selection)

Vibe Coding auto-generates core questions based on spec; confirm selections aligning with business scenarios and environment status to finalize technical standards.

Clarification screenshot
Clarification screenshot

Step 3: Generated Result Compliance Verification

After Vibe Coding generates full Skill code, TS interface implementations, and config files, verify against spec across dimensions:

Interface spec: cross-check seven domains' request params, API endpoints, param combination rules for consistency.

Auth logic: verify auth method, header config, env variable reading per simplified auth spec.

Output spec: validate card rendering, data return, booking link display, error handling match standards.

Code spec: confirm all interfaces implemented in TS, clear structure, complete param type definitions, no missing/mismatched issues.

Verification screenshot
Verification screenshot

Step 4: Real-device Testing

Deploy to test environment, test on Xiaoyi APP covering:

Routine queries, precise param queries, personalized preference passthrough scenarios.

Boundary cases: missing params, no data, network errors, credential anomalies.

Full validation of page rendering, booking link jumps, data authenticity; ensure online interaction meets expectations.

Real-device testing screenshot
Real-device testing screenshot

Step 5: Review & Launch

After all real-device tests pass with zero functional bugs or spec deviations, one-click submit for platform review; upon approval, Skill officially launches in skill marketplace, completing end-to-end deployment of Tongcheng Chengxin travel query Skill.

Reference: HarmonyOS official documentation.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Node.jsAuthenticationVibe CodingError HandlingSkill DevelopmentAPI SpecificationTravel APIXiaoyi Open Platform
51CTO HarmonyOS Developer Community
Written by

51CTO HarmonyOS Developer Community

The HarmonyOS Developer Community is a learning-oriented community for developers to learn, communicate, ask questions, and share.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.