构建面向中国用户的循证旅行手册
把交付物当作可直接照着执行的现场手册，而不是景点清单。
中国市场默认设置
- 除非用户另有要求，否则使用简体中文沟通和交付。
- 把小红书作为中国游客体验的核心层，同时把官方、国外社区和目的地本地平台证据分层保留。
- 涉及价格决策时，同时给出当地货币、带汇率时间戳的人民币估算和中国常见渠道对比价。
- 按需要分别核验支付宝、微信支付、银联、Visa、Mastercard、境外交易费、动态货币转换、仅收现金例外和支付失败备选。
- 涉及执行时，检查中国护照、从中国大陆出发、漫游/实体 SIM/eSIM、插头、退税、海关、保修、地区型号、App/语言和售后限制。
- 国外平台名、官方产品名、车站名、型号和有用的当地语言检索词保持原文，避免因翻译损失操作精度。
不可协商规则
- 分离用户事实、用户偏好、模型假设、官方事实和社交体验。
- 不要从年龄或家庭角色推断身体限制。询问或使用明示的行动能力和耐热能力。
- 在交付前验证每一个不稳定的硬事实：天气、关闭、营业时间、价格、票务规则、交通覆盖、支付方式和入境要求。
- 为每个重要候选方案搜索正面和负面体验。
- 包含“避雷”的查询并非证据。打开结果并确认它讨论了确切的候选方案。
- 不要将与主题无关、复制、推广或仅标题的结果计为直接证据。
- 当任何重要候选方案仍未覆盖时，不要声称完成了负面验证。
- 保持社交访问为只读。永远不要自动登录、收集Cookie、发布、评论、点赞、收藏或绕过平台控制。
- 引用官方来源获取硬性规则，引用社交来源获取亲身经验。不要互相替换。
- 在交付前逐页渲染并检查最终PDF。
工作流程
1. 导入所有提供的材料
- 阅读 references/intake.md，收集最小需求，如果任何阻塞字段未知，则在广泛研究前停止。
- 阅读每个提供的PDF、文档、幻灯片、图片、预订和先前的对话。
- 在研究前将事实提取到需求台账中。
- 将每个项目标记为
USER_CONFIRMED、SOURCE_CONFIRMED、ASSUMPTION、UNKNOWN或CONFLICT。 - 保留确切的航班、酒店地址、日期、同行人数、支付限制、健康限制、期望地点、可选计划和禁止操作。
- 切勿将先前助手的猜测悄悄地作为用户事实延续。
使用 scripts/init_project.py DESTINATION_DIR 创建可重用的台账和文件夹。
2. 引导并诊断研究工具
当 Agent-Reach、OpenCLI、浏览器桥接或社交平台访问缺失或异常时，阅读 references/bootstrap.md。
- 优先使用 Agent-Reach 作为能力路由和健康检查工具。
- 运行
python scripts/doctor.py检查缺失的本地依赖，而不更改系统。 - 在平台工作前运行
agent-reach doctor --json。 - 使用报告为可用的后端；不要仅凭安装来判断访问权限。
- 对于 Chromium 浏览器（包括 Edge），使用用户控制的 OpenCLI 浏览器桥接会话。
- 如果无法获取登录后的会话，继续使用官方页面、公共网络索引和可访问的平台，同时标注差距。
- 不要仅仅因为某个社交后端不可用就阻止独立的官方验证。
3. 在收集帖子之前构建候选清单
列出每个与决策相关的对象：
- 景点、街区、商场、博物馆、餐厅或美食策略；
- 机场交通、交通通票、铁路旅行、出租车方案、车站换乘；
- 酒店运营、行李步骤、支付方式、SIM/eSIM；
- 商品、商店、退税流程、保修或海关问题；
- 依赖天气的分支和完整的备用日。
为每个候选分配：
- 稳定的
candidate_id； - 类别和确切的规范名称；
- 提议的日期和路线角色；
- 重要性：
critical、major或minor； - 证据目标；
- 包含状态：
candidate、included、optional或rejected。
不要只研究初始行程。包含合理的替代选项，以便负面证据可以改变计划。
4. 分两轮收集证据
在开始大规模收集前，阅读 references/research-protocol.md。
第一轮 - 广泛路线构建
- 搜索完整的行程、街区组合、季节约束和旅行者类型。
- 草拟地理上连贯的每日行程簇。
- 使用此轮发现候选，而非最终确定它们。
第二轮 - 候选级验证
对于每个关键或重大候选，分别搜索：
- 正面体验和实际停留时长；
- 直接负面体验、失望、排队、炎热、可访问性、支付、价格、卫生、关闭或物流失败；
- 当前的官方规则；
- 当地语言名称和当地平台讨论；
- 与下一站的确切连接。
打开完整帖子和相关评论。记录URL、日期、平台、作者（如果可用）、极性、相关性和所支持的主张。 对于每个直接的社交记录，还要保存摘录、评论者身份和明确的候选身份检查。
5. 强制执行证据覆盖
除非用户指定更严格的门槛，否则使用以下默认目标：
| 候选类型 | 正面 | 直接负面 | 官方/当前 | 运营失败 |
|---|---|---|---|---|
| 关键景点/路线 | 2 | 2 | 1 | 如适用 |
| 重大景点/商场 | 2 | 2 | 1（如有规则/价格） | 如适用 |
| 指定餐厅/商店 | 2 | 2 | 菜单/价格（如可用） | 1 |
| 交通通票/机场交通 | 1 | 2 | 2次主要检查 | 2 |
| 产品推荐 | 2 | 2个不利/限制条件 | 当前价格 | 保修/兼容性（如适用） |
| 次要连接点 | 1 | 1或明确 NOT_APPLICABLE | 地图/当前规则 | 可选 |
NOT_APPLICABLE 仅允许在有书面理由的情况下使用。“未找到负面帖子”是 UNCOVERED，而非 NOT_APPLICABLE。
计数仅使用唯一的规范URL。重复的帖子、重复的证据ID、孤立的证据行、无效的枚举、缺失的摘录或未检查的候选身份是验证错误，而非警告。
运行：
python scripts/audit_evidence.py PROJECT_DIR
在关键候选未通过关口时，不要进入最终写作。如果某个平台不可访问，公开不足之处并使用最佳可用替代方案，不要假装等价。
6. 从酒店出发构建每一天
对于每一天：
- 从确切的酒店地址开始。
- 按地理和开放日兼容性分组停留点。
- 说明每次步行、车站入口/出口、火车/巴士方向、换乘、出租车路段、预期等待时间和导航缓冲时间。
- 根据官方信息和社交报告添加实际停留时长。
- 添加餐食、卫生间、座位、行李、购物和天气恢复。
- 计算净景点时间、交通/搜索时间、用餐时间、缓冲时间、总耗时、步行范围、费用范围和最晚离开时间。
- 定义天气/可见度/门票关口和一个完整的备用路线。
- 移除或降级那些负面证据超过其路线价值的候选。
不要仅仅因为旅行者年龄较大就把一个完整的一天简化为一个景点。使用实际的行动能力、地形、温度、湿度、阴凉和声明的偏好。
7. 单独审计交通通票和支付
对于每个通票或支付建议：
- 对照实际行程计算盈亏平衡点；
- 区分卡价格、通票价格、押金、充值方式、激活规则、有效期、退款和服务费；
- 列出包含和排除的交通方式及地理范围；
- 验证每位旅行者是否需要单独一张卡；
- 区分机场购买、市内购买和返回机场的程序；
- 研究失败案例：外国卡被拒绝、仅收现金的机器、错误产品、漏刷卡、延迟激活、库存不足、不兼容路线和退款困难；
- 区分支付宝/微信支付的接受与商户展示的二维码兼容性，以及银联接受与通用的“接受卡”声明；
- 警告动态货币转换，并说明本地货币结算通常更优；
- 给出确切的备用方案并说明现金影响。
永远不要仅仅因为通票的有效期与行程长度匹配就推荐它。
8. 审计餐厅、购物和商品
- 优先选择决策规则而非脆弱的“必访”指定场所。
- 设定排队限制、价格透明度规则、点餐检查以及同区域内的替代选择。
- 对于商品，比较确切型号/尺寸和当天的净价，而非标价。
- 将目的地净价与注明日期的中国大陆参考价进行比较，并在可行时以人民币显示两者。
- 包括不良反应、不合适的用户、区域型号差异、保修、电压/频率、语言、海关和行李限制。
- 将促销视为过期的观察结果，而非保证的价格。
9. 撰写现场手册
在撰写前阅读 references/planning-and-pdf.md。
PDF 必须以以下内容开头：
- 旅行期间天气和更新时间；
- 出行前准备。
然后包括：
- 预订和硬性边界；
- 交通卡和机场交通操作；
- 概览日历；
- 每天一个完整章节；
- 每个停留点一张执行卡；
- 完整的替代方案；
- 餐饮、购物、商品、紧急处理、本地语言卡片；
- 证据覆盖和人类可读的源。
仅当图片能实质性地帮助识别、导航或非显而易见的决策时才使用图片。不要将社交截图用作固定导航，当实时标志或地图说明更可靠时。
10. 验证并交付
- 重新检查不稳定的官方事实。
- 运行证据审计并解决所有关键失败。
- 生成 PDF。
- 运行
scripts/validate_pdf.py FILE.pdf --require "term" ...。 - 运行
scripts/render_pdf.py FILE.pdf RENDER_DIR。 - 以全分辨率检查联系表和有代表性的页面。
- 修复裁切、溢出、稀疏的意外页面、不可读的URL、缺失的字形、损坏的图片和模糊的跨页卡片。
- 记录页数、文件大小、SHA-256、研究计数、未覆盖的候选和验证时间戳。
- 交付 PDF 以及（如果要求）源/证据包。
证据语言
使用精确的主张：
DIRECT：打开的来源讨论了确切的候选和问题。PARTIAL：同一区域/类别，但非确切候选或场景。MISMATCH：搜索结果关于另一个对象；将其从计数中排除。PROMOTIONAL：创作者激励或明显推广；仅作为发现保留。OFFICIAL：权威的硬性信息，非旅行者体验的证明。UNCOVERED：未找到所需证据。
除非证据审计以声明的阈值通过，否则永远不要写“所有项目均通过负面帖子验证”。