I. Business Scenario and Pain Points

A friend pulled together a three-person team to build a travel planning app: users enter a destination, number of days, budget, and preferences, and the app generates an itinerary that's editable, shareable, and bookable. Sounds simple, but once you start building, you realize it's a "full-stack buffet" of requirements:

• Itinerary generation must be fast, but must not fabricate. Attraction opening hours, transit times, restaurant operating status — any fabricated detail will directly destroy user trust.
• Budget estimation must be dynamic. The same itinerary costs vastly different amounts in peak vs. off-season, weekdays vs. weekends, so pricing data needs external services.
• Multi-model collaboration is unavoidable. Understanding long-form travel guides, generating structured itineraries, and handling conversational edits — using one model for all of them is both expensive and slow.

What a three-person team lacks most isn't ideas, but process and risk control. As the team's "half-manager," I drew three diagrams before the project kicked off: a data flow diagram, a collaboration/division-of-labor chart, and a risk checklist. This article explains the whole solution from a manager's perspective.

II. Three Core Concerns from a Manager's Perspective

1. Process: AI capabilities must be introduced in a "modular" way

We established one principle: AI is a station on the itinerary generation pipeline, not the entire pipeline. Itinerary generation is broken into five steps:

1. Intent parsing: Parse colloquial user input ("want to eat my way through Chengdu for five days, with a five-year-old in tow") into structured parameters.
2. Data retrieval: Call external APIs for attractions, weather, prices, etc., to get real data.
3. Itinerary orchestration: The LLM generates the first-draft itinerary based on real data — the model only does "orchestration," never acts as the "fact provider."
4. Validation and backfill: Use a rules engine to check for time conflicts and geographic reasonableness (e.g., in the east of the city in the morning, then 30 km away in the west at noon).
5. Conversational modification: When the user says "day two is too tiring," the AI partially rearranges rather than regenerating everything.

This decomposition lets each step be tested independently and have its model swapped independently, so when something goes wrong you can pinpoint the exact station.

2. Collaboration: How three people divide work without stepping on each other

• One person owns the data layer: external API integration, data cleaning, caching strategy.
• One person owns the AI orchestration layer: prompt management, model scheduling, output validation.
• I own the product layer and risk control: requirement reviews, cost monitoring, launch checklists.

The key collaboration agreement: all prompts and model calls must go through a unified orchestration service — direct SDK calls in business code are forbidden. This isn't bureaucracy; it's for the risk control discussed below.

3. Risk: Four questions that must be answered before launch

• What if the model output format is wrong? (structured output validation + degraded retry)
• What if the single model provider goes down? (hot-swappable backup model)
• What if costs spiral out of control? (call quotas tiered by user level)
• What about sensitive or non-compliant content? (output filtering layer)

III. Architecture Design

用户输入
   │
   ▼
意图解析服务（轻量模型）
   │
   ▼
数据聚合层（景点/天气/价格 API + 缓存）
   │
   ▼
行程编排服务（主力模型，结构化输出）
   │
   ▼
规则校验引擎（时间冲突/地理合理性/预算核对）
   │ 不通过 → 回到编排服务重试（最多2次）
   ▼
统一 AI API 网关（路由/重试/降级/计费日志）
   │
   ▼
前端行程编辑器 + 对话式修改（会话模型）

Why a unified AI API gateway significantly reduces maintenance costs — this is the decision I fought hardest for in this solution, for three reasons:

1. Integrate once, swap models freely. Business code only faces the gateway's standard interface. When we switched the itinerary orchestration model from A to B, not a single line of business code changed — only the gateway routing config. A three-person team doesn't have the bandwidth to maintain version upgrades, authentication methods, and error code systems for five different SDKs; the gateway consolidates these differences into one layer.
2. Retry, degradation, and rate limiting are implemented centrally, not scattered everywhere. If each station wrote its own retry logic, one provider hiccup would mean hunting through three codebases. With the gateway handling it uniformly, failure handling has a single entry point — the on-call person (usually me) can locate the issue from one log dashboard.
3. Costs are controllable only when they're observable. The gateway logs token consumption and cost for every call by function; the monthly bill is crystal clear. Which station is overspending, which user is making abnormal calls — it's all in the data. A small team has no dedicated finance person; without this observability, cost management is empty talk.

IV. Key Implementation Steps and Core Code

Landing checklist

1. Week 1: Define the itinerary data Schema (JSON Schema) and fix the input/output contracts for each station.
2. Week 2: Integrate the unified AI gateway; complete intent parsing and the data aggregation layer.
3. Week 3: Develop the itinerary orchestration prompt + rules validation engine; build an evaluation set (30 typical requirement samples with manually annotated expected itineraries).
4. Week 4: Conversational modification, gray release, cost alert configuration.

Core code: the orchestration service skeleton

async def generate_itinerary(user_input: dict) -> Itinerary:
    # 1. 意图解析（轻量模型，经网关路由）
    intent = await gateway.chat(
        model_group="light",          # 网关侧的模型分组，换模型不改代码
        messages=[parse_prompt(user_input)],
        response_format="json"
    )

    # 2. 拉取真实数据
    pois = await data_layer.fetch_pois(intent.city, intent.tags)
    weather = await data_layer.fetch_weather(intent.dates)

    # 3. 行程编排（主力模型）
    draft = await gateway.chat(
        model_group="planner",
        messages=[plan_prompt(intent, pois, weather)],
        response_format="json",
        timeout=15,
        fallback_group="planner_backup"  # 网关自动降级到备用模型
    )

    # 4. 规则校验，不通过则定向重试
    for attempt in range(2):
        issues = validator.check(draft)
        if not issues:
            return draft
        draft = await gateway.chat(
            model_group="planner",
            messages=[revise_prompt(draft, issues)]
        )
    return fallback_template(intent)  # 最终兜底：模板行程

Note two details from a manager's perspective: model_group rather than a specific model name, ensuring the decision to switch models is centralized in the gateway config layer without a team-wide code review; and fallback_group plus the fallback template, guaranteeing users always see a result even if the whole AI pipeline fails.

V. Post-Launch Management Essentials

• Evaluation set regression: Every prompt change runs the 30-sample evaluation, to prevent "fixing one case and breaking three."
• Weekly cost report: Auto-generated from gateway logs — per-user call cost, breakdown by station — readable in five minutes.
• User feedback loop: For cases users flag as "unreasonable itinerary," do a post-mortem within 48 hours on whether it was a data problem, orchestration problem, or validation gap, and attribute it to the responsible station owner.

VI. Final Thoughts

For a three-person team building an AI application, the game isn't about fancy model tuning — it's about whether the process is controllable, whether collaboration has contracts, and whether risks have fallbacks. Unified gateway + modular pipeline + centralized observability — these three things let us go from idea to launch in two months, and still sleep soundly when swapping models or adding features.

If you're preparing a similar project, I suggest starting by getting one stable multi-model calling entry point working — for example, try a unified AI API gateway service. Registration is here: https://api.thistoken.ai/register

---

Every example in this post runs with a single API key — get yours at https://api.thistoken.ai/register and start in minutes.