travel-guide-test（旅游导游考试）

Travel Guide Pages

Build a useful trip first, then build the webpage.

Core approach

Follow this sequence:

1. Discover the travellers, constraints, and vibe.
2. Decide the route logic before writing a day-by-day itinerary.
3. Build a realistic itinerary with energy management.
4. Add hotels, activities, transport legs, and booking urgency.
5. Turn the plan into a skimmable, image-led static webpage.
6. Deploy to Cloudflare Pages.

Do not jump straight to “top things to do”. Do not optimise for maximum attractions. Optimise for fit, flow, energy, and clarity.

Discovery checklist

Before proposing an itinerary, gather or confirm:

• destination(s)
• trip length
• who is going
• ages if relevant
• whether they have been before
• interests
• explicit dislikes / hard nos
• budget level
• pace preference: slow / packed / balanced
• style preference: practical / premium / adventurous / relaxing / design-led / traveller-friendly
• willingness to drive
• luggage or mobility constraints
• likely airports / rail / car usage

If details are missing, ask only the highest-value questions first.

Family / mixed-age optimisation branch

If the trip includes children, teens, mixed generations, or a group with clearly different energy levels, ask a more specific second layer:

• ages of each traveller
• interests by person, not just for the group overall
• any hard no's by person
• food pickiness / flexibility
• sleep, nap, jet lag, or bedtime constraints
• stamina / walking tolerance / motion sickness / transport tolerance
• rooming needs (e.g. one room vs two rooms, sofa bed vs separate beds, privacy needs)
• what the adults also want from the trip so the plan does not become child logistics only

Ask about gender only when it would materially affect rooming, privacy, safety, or comfort decisions. Do not ask for personal details that do not change the plan.

Route logic

Work out the structure before the days.

Always determine:

• number of bases
• best order of places
• whether the route should be rail, road, air, or mixed-mode
• where rental car pickup happens
• where rental car return happens
• where mixed-mode handoffs happen

For mixed-mode travel, label legs explicitly. Examples:

• Train + car pickup
• Scenic drive
• Drive to rail gateway + train into city

Do not collapse mixed-mode travel into vague one-line labels. If a leg uses two modes, show both.

Itinerary design rules

Design for humans, not robots.

Account for:

• arrival fatigue / jet lag
• group pacing / energy differences
• sensory overload
• realistic travel times
• recovery after big days
• flexibility for weather and mood
• rooming and sleep practicality when relevant

Use an energy curve:

• stimulating days
• slower reset days
• headline days
• transition days
• flexible buffer days

Common helpful pattern:

• arrival/reset day
• lighter recovery day after long travel if needed
• major highlight day once people are functioning well
• calmer or flexible day after a big one

Recommendations structure

For each base/segment, provide:

Why stay here

Explain what this base adds to the trip and why it suits the travellers.

What to do

Recommend only high-fit activities. For each one include:

• why it fits
• rough travel time
• whether it is essential / optional / weather-dependent
• whether it is half-day or full-day
• booking urgency if relevant

Where to stay

Provide a short practical shortlist, ideally:

• best practical option
• best stylish option
• best upgrade option (if relevant)

Explain the hotel logic:

• space / room fit
• location convenience
• scenery
• transport access
• vibe

Transport logic

Be explicit about:

• train start/end points
• car pickup location
• car return location
• rail handoff point
• what each leg is actually doing

Day-by-day output

Create a realistic day-by-day plan. For each day include:

• day title
• location/theme
• key plan
• travel mode/time if relevant
• effort/energy level when useful
• whether it is a highlight / reset / transition / flex day

Keep it concise and skimmable.

Traveller profiles and reusable preferences

Support reusable traveller profiles when helpful.

Default to a shared profile for the main travelling unit:

• individual
• couple
• family
• recurring friend group
• recurring multi-generational group

Use individual subprofiles only when useful or explicitly requested. A shared group profile should be the default; per-person profiles are optional layers, not mandatory dossiers.

The skill may:

• create a primary group profile
• create optional traveller-specific subprofiles when they materially affect planning
• reuse an existing profile for future travel planning
• update the profile after a trip or after the user clarifies a preference

Only store durable travel-planning preferences, such as:

• trip pace
• budget style
• hotel preferences
• transport tolerance
• rooming preferences
• food preferences
• activity preferences
• hard no's
• destination preferences
• children’s ages/interests when relevant to future planning
• traveller-specific constraints only when they materially affect planning

Good pattern:

• primary family/couple/group profile for shared defaults
• optional subprofile for notable exceptions, e.g. motion sickness, food restrictions, very different activity tolerance, or strong preferences

Do not treat the profile as a dossier. Do not store unnecessary sensitive or irrelevant personal details. Store only information that improves future travel recommendations.

When saving or updating profile information, follow the environment’s consent and memory rules. If profile information is uncertain, summarise it as a tentative preference rather than a hard fact.

When a returning traveller or group is involved, check whether a profile already exists before re-asking basic planning questions. Reuse what is durable, then ask only for what has changed.

Planning extras

Always include:

Book in advance

Split into:

• must book early
• can book later
• flexible / low urgency

Weather / packing

Keep practical and brief.

Travel tips / hacks

Include only useful tips:

• booking strategy
• luggage strategy
• local transport logic
• timing / crowd avoidance
• family pacing

Avoid social-media fluff unless it is genuinely helpful.

Webpage requirements

Build a static HTML/CSS page suitable for Cloudflare Pages.

Style goals:

• premium travel editorial
• clean, skimmable, uncluttered
• image-led
• useful before clever

Suggested sections:

• cover / hero
• trip overview
• route summary
• route map + leg links
• day-by-day itinerary
• visual galleries by place
• hotel suggestions
• transport logic
• booking checklist
• final summary

Writing rules for the page

The page must be user-facing only. Do not include:

• “this version...”
• process commentary
• defensive caveats
• workshop notes
• tool chatter

Write like a polished guide, not a development log.

Image rules

Prefer correctness over generic mood shots.

Good order of preference:

1. exact place-matched images
2. source pages with usable og:image
3. official tourism / venue pages
4. Wikimedia Commons
5. stable generic mood imagery only when clearly labeled as general atmosphere

If the page names a specific place, do not use obviously unrelated visuals.

When image sourcing is messy:

• use fewer stronger images
• use source-page share images when available
• make gallery cards clickable to the source page
• host assets locally when reliability matters

Maps and leg links

Include a route summary visual where possible. Also include leg-by-leg links.

For each leg, ensure:

• the origin is correct
• the destination is correct
• the travel mode matches reality

Examples:

• transit for rail legs
• driving for car legs
• separate links for mixed-mode handoffs

Confidence gate before page build

Do not build or deploy the Cloudflare Pages site too early. Only move into page creation once the itinerary is stable enough that major structural changes are unlikely.

Minimum confidence before page build:

• route order is agreed or strongly recommended and accepted
• number of bases is settled
• core transport logic is settled
• major activity choices are reasonably locked
• hotel shortlist is directionally right
• the user is no longer still deciding the basic shape of the trip

If confidence is still low:

• stay in planning mode
• keep refining route, pacing, and activities
• summarise open decisions clearly
• avoid premature page production that will just cause churn

Once confidence is high enough:

• build the webpage
• treat the page as a packaging/output step, not as the discovery step itself

Cloudflare Pages deployment

After building the static page:

1. make sure assets are local or stable
2. create the Pages project if needed
3. deploy the static folder
4. return the live deploy URL and stable Pages URL

If Cloudflare auth is missing, ask for the minimum token/account/project info needed.

Quality bar

A good result should be:

• genuinely useful
• visually coherent
• easy to skim in under 5 minutes
• internally consistent about route and transport
• tailored to the travellers

If tradeoffs exist, prefer:

• correct route logic over pretty simplifications
• exact imagery over generic filler
• traveller fit over attraction maximisation
• group harmony and energy management over trying to “do everything”