构建面向中国用户的循证旅行手册 是做什麼的？
把交付物当作可直接照着执行的现场手册，而不是景点清单。
中国市场默认设置
- 除非用户另有要求，否则使用简体中文沟通和交付。
- 把小红书作为中国游客体验的核心层，同时把官方、国外社区和目的地本地平台证据分层保留。
- 涉及价格决策时，同时给出当地货币、带汇率时间戳的人民币估算和中国常见渠道对比价。
- 按需要分别核验支付宝、微信支付、银联、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：未找到所需证据。
除非证据审计在声明的阈值上通过，否则绝不要写“所有项目都已通过负面帖子验证”。