字段值与页面正文对不上时，先不要改映射规则。多数情况是字段取自页面的哪一层没有先定清楚：标题、正文首段、列表项摘要，还是嵌套在某个容器里的组合文本。处理顺序建议是先把原始返回体存下来，再逐个争议字段标注来源层，然后用同页不同查询把问题压到抽取层或映射层，最后才动配置并做回归对照。这个顺序的价值在于：每一步都能通过配置、日志或页面行为复现，不依赖对抽取算法内部实现的猜测。
遇到 AnySearch 返回字段与页面正文不一致，建议先把原始返回体落盘，按页面段落逐段对齐，再给每个争议字段标注它应该来自标题层、正文层还是列表项层。随后用同一页面、不同查询条件的两次请求对比字段差异：若变化只出现在某些字段的粒度上，问题多半在抽取层；若字段值稳定但被放错位置或截断，问题多半在映射层。修改后必须做修改前后取值对照，确认其他字段未被连带改动。边界是：不要假设抽取算法内部如何切分，只以可观察的返回体和页面结构为依据。
存下原始返回体并与正文逐段对照
边看边改是最容易把证据弄丢的做法。建议先固定一次请求的完整返回体，后续所有判断都以这份副本为准。落盘时保留请求参数、响应原文和抓取时间，便于复现同一查询。
# 通用骨架，按实际 SDK 或命令行替换占位符
your-search-cli query "目标查询词" \
`--url` "页面地址" \
`--out` raw_response.json \
`--log` request.log拿到 raw_response.json 后，不要整篇通读，而是把网页正文按视觉段落切开，逐段与返回体中的字段值做对照。建议用一张临时对照记录，字段一侧写返回体里的路径或键名，页面一侧写段落序号和开头若干字。对照时重点看三类偏差：字段值比页面文字短（可能只取到标题或摘要）、字段值比页面文字长（可能把相邻段落拼接进来）、字段值出现在页面其他位置（可能取错了容器）。
- 返回体落盘：保存原始 JSON 或原始响应文本，不做二次格式化后再存。
- 段落对齐：按页面视觉段落编号，不要按返回体顺序编号。
- 偏差标注：只记录“短、长、错位”三种情况，先不解释原因。
这一步的验证方式很直接：同一份 raw_response.json 反复对照，结论应当稳定；如果换一次请求结论就变，说明页面本身存在多条同名字段或动态内容，需要先把查询条件固定住。
确认字段取自页面哪一层
AnySearch 这类检索返回通常同时包含标题、正文片段、列表项摘要等不同粒度的内容。字段对不上，常见原因是把列表项摘要当成了正文，或者把正文首段当成了整篇摘要。判断依据建议写具体，不要只写“看起来像”。
| 字段名 | 疑似来源层 | 判断依据 |
|---|---|---|
| title | 标题层 | 与页面 H1 或列表标题逐字一致，长度明显短于正文 |
| content | 正文层 | 包含页面多个段落，且段落顺序与页面一致 |
| summary | 列表项层或正文首段 | 以句号截断，且能在页面列表卡片中同样找到 |
| author / date | 元信息层 | 位于正文之外，属于页面头部或侧栏区域 |
每个争议字段都要落到上表的一行，并写出判断依据。判断依据优先使用可复核的特征：字数范围、是否包含列表卡片中的固定文案、是否与页面某一段落完全重合。只有来源层定下来了，才能判断“字段值不对”是抽取粒度问题还是映射写错。
用同页不同查询区分抽取层与映射层
把问题范围缩到一个环节，最省事的办法是在同一页面上发起两次查询，只改变一个条件，比如查询词更具体或更宽泛，然后对比返回字段。两次请求使用同一个页面地址，避免页面差异混进结论。
# 同一页面，两次查询，只改查询词
your-search-cli query "较宽的查询词" `--url` "页面地址" `--out` run_a.json
your-search-cli query "更具体的查询词" `--url` "页面地址" `--out` run_b.json对比时看字段差异落在哪里：
- 若两次返回中，content 字段的起止位置明显不同，但都还能对应到页面真实段落，问题偏向抽取层，即粒度或切分范围选得不合适。
- 若两次返回中，title 和 content 的原值都稳定，但 summary 始终等于 title 或始终缺少尾段，问题偏向映射层，即字段被指到了错误的来源。
- 若两次返回中某些字段为空且页面同样位置为空，先记录为页面侧因素，不要急着改配置。
差异指向哪一层，写清楚再动手。判断标准可以保守一些：能用“字段取值随查询变化”解释的，归到抽取层；能用“取值不随查询变化但位置固定错”解释的，归到映射层。需要结合环境确认的是，不同页面的模板结构不同，同一条结论不一定能直接搬到另一类页面。
修正映射并做回归对比
确认问题在映射层后，修改应尽量小：只改目标字段的来源指向，不同时调整多个字段，便于归因。改完立刻用同一份查询条件重跑，并保留修改前的返回体作为对照。
| 字段名 | 修改前取值特征 | 修改后取值特征 | 是否被连带改动 |
|---|---|---|---|
| content | 只包含首段 | 覆盖正文多段 | 否 |
| summary | 与 title 相同 | 与列表卡片一致 | 否 |
| title | 正常 | 正常 | 否 |
回归对比的重点不是“看起来变好了”，而是确认修改只影响目标字段。建议至少重跑两类页面：一类是本次出问题的页面，一类是此前正常的同类页面。若正常页面的字段取值发生偏移，说明映射改动影响面超出了预期，应先回退再缩小改动范围。
留下字段与页面位置的对应记录
同类问题下次还会出现，把对照结果沉淀成表比写排查心得有用。建议每个页面模板维护一张对应表，字段名用返回体里的实际键名，页面位置写到可以定位的粒度。
| 字段名 | 页面位置 | 样例值 | 最近验证时间 |
|---|---|---|---|
| title | 页面主标题 | 示例标题文本 | 填写实际验证日期 |
| content | 正文区第一至第三段 | 示例正文片段 | 填写实际验证日期 |
| summary | 列表卡片描述 | 示例摘要文本 | 填写实际验证日期 |
| author | 正文上方元信息行 | 示例作者名 | 填写实际验证日期 |
最近验证时间只写真正跑过对照的日期，没有验证就留空，不要把填写日期当成例行公事。有了这张表，下次再遇到字段与正文对不上，先查字段对应哪一层，再决定是调抽取范围还是改映射，不必从头对照一遍。