Source: 07-life-information/SRC-LIFE-001.md

关键实体

• 桑的記事本（creator）：方格子 vocus 个人创作者，本文作者；中心角色，提供 30 天欧洲旅行 AI 辅助的真实实践。Wiki 中不存在，需要新建创作者页。
• ChatGPT（tool）：贯穿全篇的对话式 AI 工具，用于行程规划、交通票券对比、现场识图问答与翻译。Wiki 中ChatGPT已存在，无需重复创建实体，但可补强其在旅行场景下的连接。
• 方格子 vocus（platform/出版平台）：本文发布平台，属于来源元数据，非独立 page 候选。

关键概念

• 先给固定条件再追问（method）：作者不再让 AI 从零决定全程，而是先确认住宿位置和少量必去景点，再让模型按地理顺序排路线；变化时继续对话修订。来源直接支持。Wiki 中无独立方法页，应新建。
• 现场拍照提问式随身信息层（method）：用拍照+对话代替翻译、设备操作说明、展品背景查询；核心是把视觉问答当作"先整理、再追问"的旅行助手。来源直接支持，Wiki 中无此方法页，应新建。
• 票券多条件比较由人决策（method）：把停留天数、预计搭乘次数、景点交给模型对比日票与单程票，最终购买由人判断。这是把 AI 当"决策辅助"而非"决策者"的典型做法。来源直接支持，应新建方法页或并入既有"AI 辅助决策"族。
• 适用对象与时效性提醒：作者以成功体验为主，未系统记录错误率与误识别案例，因此不构成对该方案鲁棒性的证据。

主要论点与发现

• 主张：把住宿和少量必去景点作为锚点，ChatGPT 能输出按地理顺序串联的一日路线，临时改计划可继续对话调整。证据：作者自述实践。强度：单一作者自我报告，无错误统计；仅支持"可行"，不证明"普遍准确"。
• 主张：把停留天数和预计搭乘次数交给 ChatGPT 做日票 vs 单程票比较，可形成初步成本参考。证据：作者自述。强度：同上，且交通票价、班次、营业时间具有强时效性，作者发表于 2026-01-06，不可直接移植到其它日期。
• 主张：在车站、公寓、超市、展馆现场拍下标识、设备、食材、艺术品并提问，可用于翻译、操作解释、料理方式与作品背景查询。证据：作者自述。强度：单一来源成功体验，未提供视觉误识别案例与失败复盘；不支持"始终可靠"的强结论。
• 以上主张全部以桑的記事本此次旅行实践为限定，不应外推至"任何 ChatGPT 用户在任何旅行场景下都能得到同质结果"。

与现有 Wiki 的关联

• 与 ChatGPT 强关联：本文提供 ChatGPT 在长程旅行场景下的使用样例，可作为该工具页的"生活助手与信息核验"方向补充案例。
• 与 生活与信息处理 方向一致：本文是该方向在"旅行"细分场景下的中文个人实践来源。
• 与现有"求职/AI 简历"等页所用提示词模式不同；与"AI 客服"、"跨境广告素材"等页也无主题重叠，扩展而非冲突。
• 既有 Wiki 中无旅行规划、票券比较、现场识图相关任务/方法/案例页，本文将填补这一空白。

矛盾与张力

• 内部张力：作者未系统记录误识别与错误行程，强调以"由人决策"和"回到官方来源确认"做兜底。这意味着来源不能支持"ChatGPT 旅行助手可靠"这一强结论，只能支持"作者个人实践中的可用做法"。
• 与通用期待的张力：读者可能期待"AI 一站式搞定旅行"，但来源只展示"AI 做初步整理、关键信息回到运营方确认"，应在页面中明确这一边界。

建议

• 新建 wiki/creators/桑的記事本.md，类型 creator，来源 SRC-LIFE-001，标签：旅行、生活助手、ChatGPT。
• 新建 wiki/cases/桑的記事本-ChatGPT30天欧洲旅行.md，类型 case：输入（住宿、景点清单、停留天数、搭乘次数、现场照片）、过程（先锚定→路线→票券→现场识图）、产物（顺路行程框架、票券成本参考、翻译与背景说明）、限制（作者未给出错误统计、信息时效性强）。
• 新建 wiki/tasks/task-plan-route-from-stay-and-must-see-with-ai.md，类型 task：用 AI 把住宿地与必去景点整理成按地理顺序串联的一日行程。
• 新建 wiki/tasks/task-on-site-photo-qa-for-travel-with-ai.md，类型 task：在现场用拍照+对话完成翻译、设备说明、票务与展品背景查询。
• 新建 wiki/methods/method-anchor-then-iterate-route.md，类型 method：先给固定条件再生成路线，临时改计划时继续追问修订。
• 新建 wiki/methods/method-photo-qa-as-on-site-info-layer.md，类型 method：把视觉问答作为旅行中的"先整理、再追问"随身信息层。
• 新建 wiki/methods/method-ai-ticket-comparison-human-decides.md，类型 method：由 AI 做日票 vs 单程票多条件对比，最终购买判断留给人。
• 新建 wiki/risks/risk-ai-travel-info-staleness-and-no-failure-stats.md，类型 risk：交通票价、班次、营业时间、预约规则的强时效性，以及作者未系统记录错误率带来的可推广性边界。
• 新建 wiki/risks/risk-uploading-travel-photos-pii.md，类型 risk：上传票据、车站、住宿照片前应遮挡姓名、订单号、二维码、精确住址、房号、定位与同行者面孔。
• 在 wiki/topics/生活助手与信息核验 索引中加入上述任务、案例与方法的双链。
• 强调：作者个人实测、关键信息需回到官方运营方确认。淡化：不要把成功个例宣传为"通用可靠的旅行 AI 方案"。
• 待用户确认的开放问题：是否单独立一个 topics/旅行规划与现场辅助 子方向，还是并入既有 生活助手与信息核验。