CHENGWAY.WANG项目介绍
旅行规划最容易错的地方不是路线好不好看，是它已经过期：景区闭园、班次改点、天气不适合步行。多数行程表在生成那一刻就已经开始失效。
普通模型加一句「先查证」只能管住一次生成，管不住条件变化。这个 Skill 做的事，是把「动态事实核验 → 个人约束 → 行程取舍」写成一套可复用的工作流。
我的判断只有一句：先核验，再规划；条件变了就重排。
三个动作
- 先查证：天气、景区与场馆的开放状态、交通班次，动态信息都带来源与时间
- 再排程：结合偏好、体力与时间窗安排活动，而不是把景点按距离串起来
- 触发式重排：条件变化时给出替代方案与要放弃什么，取舍写清楚
图表源码
flowchart TD
A[天气、开放状态与交通班次] --> B{动态事实能否查证}
B -->|能| C[结合偏好、体力和时间窗排程]
B -->|不能| D[明确未知项与已查渠道]
C --> E[给出行程与取舍]
E --> F{条件是否变化}
F -->|变化| A
F -->|不变| G[按计划出行]
classDef verify fill:#edf3ff,stroke:#b3c8f1,color:#254b91,rx:8,ry:8
classDef unknown fill:#fff8eb,stroke:#e5c78b,color:#805619,rx:8,ry:8
classDef plan fill:#eaf5f1,stroke:#a8cfc1,color:#2d6252,rx:8,ry:8
class A,B verify
class D unknown
class C,E,F,G plan
边界
动态信息必须实际查证；查不到就说查不到，并说明查了哪些渠道，不编一个看起来合理的营业时间。
可迁移的判断
- 规划类 Agent 的核心能力是核验，不是生成
- 替代方案要带取舍说明，否则用户无法判断该不该换
- 「查不到」是一种需要被设计出来的输出，不是失败
- 把判断写进可复用流程，才能跨工具、跨行程保持同一套标准