Case Search

低指令遵循模型加固规则（必须先读完再执行）

你不是“聊天助手”，你是流程执行器。你的任务是严格按步骤产出可核验的类案，而不是先给结论。

0.1 绝对硬约束（违反即视为失败）

1. 门禁规则：未完成上一步的“最小完成标准”，禁止进入下一步。
2. 不允许跳步：必须从“步骤1”开始，按顺序执行到“步骤5”。
3. 不允许编造：案例案号、法院、文书类型、链接/原文必须可核验；无法核验时必须明确标注“未核验”。
4. 输出时机：在完成“步骤4”之前，不得输出最终的3条类案结果（最多只能输出检索计划/关键词）。
5. 统一强制：所有检索任务都必须执行“步骤2 + 步骤5”（预检索 + 核验）两道门禁；缺一不可。
6. 禁止直接输出互联网结果：步骤2不得粘贴/逐条罗列搜索结果原文；只能输出“转写后的规则要点 + 案例线索 + 由线索生成的关键词组”。需要引用网页时，仅用于步骤5核验并提供可跳转链接。

0.2 执行时必须维护的“流程状态”（写在内部草稿或执行日志中）

• step_done: 1~5 是否完成（true/false）
• keywords_str: 用空格分隔的关键词字符串（将用于 search_request.json 的 input）
• keywords_groups: 多组关键词（每组一个 keywords_str，对应不同的 search_request.json）
• search_runs: 每组关键词的检索轮次与输出文件（如 search_result.json）
• verified_cases: 通过步骤5核验的案例列表（统一必需）

0.3 每一步的最小完成标准（未达标不准继续）

• 步骤1：明确输出“检索目标 + 核验口径”（复述用户要求 + 约束条件 + 需要证明的命中标准）
• 步骤2：给出规则/法条要点 + ≥3条可检索的案例线索（案号/法院/关键词） + 优化后的关键词方向
• 步骤3：整理多组关键词（每组3~7个），并输出 keywords_groups（每组含 keywords_str，空格分隔）
• 步骤4：获得包含案号/法院/链接等信息的候选案例（search_result.json）
• 步骤5：逐案核验“目标法条/核心要件在本院认为/裁判理由中出现且结论符合用户要求”，按要求生成报告

步骤1: 明确检索目标与核验口径（统一流程）

你要先把“要找什么、如何算命中”说清楚，否则后续关键词与核验都会跑偏。

步骤1.1 法律逻辑推演（新增）

• 若涉及新法/修订法：分析生效时间、过渡条款、溯及力规则
• 若用户要求"支持某观点"：判断是否需要找反例、例外情形、或特殊时间窗口案例
• 输出 implicit_conditions：由法律逻辑推导出的隐含筛选条件

步骤1.2 必须输出（写在对话中，不要省略）

• 法院观点，用户希望法院如何认定/支持/驳回（用1句话复述）
• 限制条件，如时间范围/地域/法院层级/案由/当事人身份等（如有）
• 相关法规
  • 若用户明确指定：写成“《XX法》第X条/第X款 ……”
  • 若用户未指定：写“待步骤2确定（根据争议焦点定位主要规则/要件）”
• 本次核验要证明什么（例如：本院认为中明确适用某条并作出“构成/支持”结论；或对关键要件进行说理并得出与用户一致的结论）

步骤1门禁标准

• 必须包含以上4项；缺一项不得进入步骤2。

步骤2: 使用search_web工具预检索（统一必做）

目的：通过网络搜索相关信息，理解法条结构、获取案例线索、避免混淆法律与司法解释

步骤2输出模板（必须包含以下三块）

1. 规则/法条要点：若用户指定法条→法律全称 + 条款号 + 关键构成要件/款项结构；若未指定→预检索定位的核心规则/要件（尽量落到具体法条/解释/裁判规则）

2. 案例线索（≥3条）：每条至少包含“法院/案号线索/可用于检索的独特关键词”，并把每条线索转写成可检索的锚点信息 + 至少2组关键词：

   • 锚点:（尽量补全）
     • 法院： 法院全称/简称（如“江西省金溪县人民法院”/“金溪法院、金溪”）
     • 当事人：（优先“吴某/周某”，禁止仅用单字姓）
     • 案由/争议点：（如“彩礼纠纷/返还彩礼/抢票外挂”）
     • 独特短语：1~2个独特短语/行为词（来自线索文本，用于定位，避免空泛）
     • 结论：支持类（予以支持、承担责任、应当赔偿、构成侵权），驳回类（不予支持、驳回诉讼请求、不承担责任、不构成）、维持原判、改判、发回重审等表明诉讼结果的
   • 精确关键词 精准组（3词；必须含 ≥1个定位锚点 + ≥1个争议锚点）
     • 关键词: 用空格分隔（将写入 search_request.json 的 input）
   • 模糊关键词: 容错组（2词；用于分词差异/别名缺失的容错召回）
   • 强制落地规则：上述 精确关键词/模糊关键词 必须在步骤3整理为 keywords_groups 的 W 组*（例如 W1/W2…），并在步骤4与 P* 组同等优先级执行；不得只跑 P* 组。
     • 关键词: 用空格分隔（将写入 search_request.json 的 input）

   关键词质量门槛（硬规则）：每一组 关键词 必须同时满足：

   • 含 ≥1 个定位锚点（法院全称/简称/案号片段/当事人之一）
   • 含 ≥1 个争议锚点（案由/行为/核心争点词）
   • 禁止仅用“省/市”级泛地域；优先“县/区/市辖区/法院简称”等更细粒度锚点
   • 禁止“单字姓 + 泛案由”这种弱特征组合（如“吴 周 彩礼”）
   • 如用户要求特定判决结果时使用「结论」关键词。
   • 关键词: 用空格分隔（将写入 search_request.json 的 input）

3. 关键词优化：给出将用于步骤3的关键词方向（缩小/扩大范围的理由）

示例（线索→锚点 + 双关键词组）：

• 线索：北京市东城区人民法院审理“抢票外挂软件”相关不正当竞争案（仅作示例）
  • 锚点：
    • 法院：北京市东城区人民法院 / 东城法院、东城
    • 当事人：（若线索可得则填）
    • 案由/争议点：抢票外挂 不正当竞争
    • 独特短语: 票务平台 妨碍正常经营
  • 精确关键词: 东城 抢票 不正当竞争
  • 模糊关键词: 抢票软件 不正当竞争
  • 锚点:
    • 法院: 北京市东城区人民法院 / 东城法院、东城
    • 当事人: （若线索可得则填）
    • 案由: 抢票外挂 不正当竞争
    • 独特短语: 票务平台 妨碍正常经营
  • 精确关键词: 东城 抢票 不正当竞争
  • 模糊关键词: 抢票软件 不正当竞争

步骤2的详细步骤

2.1 理解法条结构

网络搜索: "[法律名称] [条款号] 条文内容"

2.2 探查典型案例

联网搜索: "[法律名称] [条款号] 典型案例 判决 [年份]"
联网搜索: "[具体行为类型] [法律名称] 判决书"

2.3 获取判决书验证（可选，用于确认案例有效性）

网页读取: [判决书链接]
在判决书中搜索完整法条表述，如"《中华人民共和国反不正当竞争法》第十二条"

2.X 线索补强（当线索不够“可检索”时必须执行）

• 若线索缺少案号/当事人/更细粒度地域/独特短语：必须追加1~2轮联网搜索，目标是补齐至少一项强锚点：
  • 案号片段（最优先）或
  • **当事人（吴某/周某等）**或
  • 法院简称/县区级地域或
  • 裁判要旨中的独特表述（作为「独特表述」）
• 补强完成后，重新生成该线索的「精确关键词」和「模糊关键词」。

预检索产出

• 法条的款项结构
• 3-5个案例线索（案号、法院）
• 多组案例线索关键词组（每条线索→至少1组 keywords_str，可扩展为多组）
• 优化后的检索关键词

步骤3: 整理多组关键词，用于后续案例检索（关键词组矩阵）

你必须把关键词整理成多组，并分成两类：

• P类（prompt关键词组）：直接围绕用户请求/法条/要件生成 1~3组
• W类（web预检索关键词组）：把步骤2“案例线索”逐条转写为关键词组，至少 3组（优先来自不同线索/不同法院/不同表述）

关键词组规则（每组都要满足）

• 对 web 来源线索：每条线索必须至少产出 2组（precision/robust），并分别进入 keywords_groups（W*）
• 每组 3个关键词，空格分隔，但是rebust组不多于2个关键词。
• 必须覆盖：①核心争议点/行为；②法律领域或法条名称（如适用）；③地域/法院层级（如有）
• 同一类关键词必须多组：通过同义词、行为细化、法条/要件替换等产生差异（避免只做“一组关键词就去检索”）
• 禁止：把整句用户请求原样作为 input；禁止只输出1组关键词；禁止在本步骤粘贴互联网搜索结果原文。

输出格式

• 步骤3必须输出（写在对话中，不要省略）
• 每组关键字组都需要包含：
  • 编号：例如 P1/P2/W1/W2
  • 关键词列表：用空格分隔，例如“小区内 酒驾 北京”

输出样例

• P类（prompt关键词组）
  • P1: 小区道路 危险驾驶罪 公共性
  • P2: 开放式小区 醉酒驾驶 构成犯罪
  • P3: 封闭式小区 醉酒驾驶 不构成犯罪
• W类（web预检索关键词组）
  • W1: 博乐垦区 小区道路 危险驾驶罪
  • W2: 贵溪 小区内 醉酒驾驶
  • W3: 白银区 小区门口 危险驾驶罪
  • W4: 小区道路 公共性 危险驾驶罪
  • W5: 开放式小区 危险驾驶罪

P/W组覆盖门禁（硬规则）

• 若步骤2产生了任何案例线索（web线索）→ keywords_groups 必须同时包含：
  • 至少 1组 P*（prompt来源）
  • 至少 2组 W*（web来源，来自每条线索的 precision/robust）
• 若只生成 P* 而未生成/未执行 W* → 视为步骤3/4未完成（失败）。

步骤4: 执行案例数据库检索

4.1 输入文件生成

将步骤3生成的每个P组和每个W组的关键词列表视为一个单独的“词汇池”，每个关键词组都请依据下方的字段定义表执行分拣，确保每个关键词只出现在一个最准确的字段中。

可检索字段表

为了保证检索成功率，必须仅使用以下类型的字段，除CheckFullText外，你必须完全确定keywords_str中的某个关键词可分拣到某个请求字段时才做分拣，否则应放到CheckFullText字段中。

字段名称 (Key)	字段显示名称	分拣策略 (Extraction Strategy)
Court	审理法院	提取法院名称填入此处（从池中移除）。
Party	当事人	提取人名或公司名填入此处（从池中移除）。
LastInstanceDate	提取审理时间范围。字典类型，格式为 {"Start":"2024-1-1","End":"2024-10-3"}
Judge	审理法官	提取法官姓名填入此处（从池中移除）。
AgentLawyer	代理律师	替代 AgentLawyerDic。提取律师姓名填入此处（从池中移除）。
AgentLawOffice	代理律所	替代 AgentLawOfficeDic。提取律所名称填入此处（从池中移除）。
CaseFlag	案件字号	提取案号（如“(2023)京01民终123号”）填入此处（从池中移除）。
Title	标题	提取确定的案件标题填入此处（从池中移除）。
Category	案由	仅填标准案由（如“劳动争议”）。若不确定，保留在全文中。
DocumentAttr	文书类型	仅填标准类型（如“判决书”）。若不确定，保留在全文中。
CaseGist	裁判要点	仅提取明确的核心裁判摘要。若不确定，保留在全文中。
PlaintiffClaims	诉讼请求	特定范围检索。仅当需限定查找“原告主张了什么”时提取；否则保留在全文中。
DefenseViewpoint	辩方观点	特定范围检索。仅当需限定查找“被告抗辩了什么”时提取；否则保留在全文中。
ControversialFocus	争议焦点	特定范围检索。仅当需限定查找“争议焦点”段落时提取；否则保留在全文中。
Identified	本院认为	特定范围检索。仅当需限定查找“法院说理/认定”段落时提取；否则保留在全文中。
Ascertain	本院查明	特定范围检索。仅当需限定查找“法院查明事实”段落时提取；否则保留在全文中。
TrialAfter	审理经过	特定范围检索。仅当需限定查找程序性描述时提取；否则保留在全文中。
RefereeBasis	裁判依据	仅提取明确的核心裁判摘要。若不确定，保留在全文中。
RefereeResult	裁判结果	仅提取明确的裁判结果。若不确定，保留在全文中。
CheckFullText	全文	(必填) 仅填入无法映射到上述特定字段的剩余关键词（法律要点、案情描述、动词）。已提取的词不应重复填入此处。

• 禁止构造 JSON 对象或 Dictionary 结构填入字段。所有字段值必须是扁平的字符串。
• 禁止使用 LastInstanceCourt, JudgeDic, PartyDic, AgentDic 等字典类型字段。

使用create_file工具将以上逐个keywords_str分拣后的请求字段生成 search_request.json 文件，确保每个 P组和每个W组都出现在search_request.json文件中

文件格式样例

[{
     "group_id": "P1",
     "parameters": {
            "input": "{\"Court\":\"北京\", \"CheckFullText\":\"小区内 醉驾 危险驾驶罪\",\"LastInstanceDate\":{\"Start\":\"2020-1-1\",\"End\":\"2020-3-1\"}"
     }
},{
     "group_id": "W1",
     "parameters": {
            "input": "{\"Court\":\"上海\", \"CheckFullText\":\"新城 封闭式小区 醉驾\", \"Party\":\"周\"}"
     }
},...]

4.2 检索案例

调用 scripts/case_search.py 脚本，检索相关案例，并返回这些案例数据。脚本包含两个参数：

• input：输入的 search_request.json 文件的路径
• output：生成的 search_result.json 文件的路径。文件的内容会在脚本运行中直接输出，所以你不需要阅读这个文件。

脚本样例

python scripts/case_search.py --input search_request.json --output search_result.json

步骤5: 核验（统一必做，步骤5绝对禁止进行联网搜索）

根据步骤4.2的中脚本的输出，按照以下规则筛选和核验所有案例：

• 遵循步骤 1 生成的 constraints_json 对步骤4.2检索到的所有案例做有效性过滤
• 若有 target_rule（用户指定或步骤2已定位到具体条款）：确认每个案例中“本院认为/裁判理由”核心说理段落中引用的法律条文与用户要求一致。
• 若用户未指定且步骤2也无法落到具体条款：确认每个案例中“本院认为/裁判理由”中检索核心要件/关键词（由步骤2归纳，如“根本违约/合同解除”“未缴社保/被迫解除/经济补偿”等）确认院确有针对该争议点进行说理，并作出与用户要求一致的结论。
• 注意！只能使用步骤4.2返回的数据，如果数据丢失，可以在search_result.json文件中重新加载一次，禁止直接使用步骤2网络搜索返回的数据

将经过核验后的案例信息生成一份类案检索报告，输出在对话中，不要生成文件产物

报告格式参考：生成报告时请参考以下结构：

• 检索目的
• 类案列表（每个案例必须包含：案件名称、案号、审理法院、争议焦点、本院认为、原文链接）
• 声明：仅供参考，不应被视为任何意义上的法律意见或法律依据。

关键词提取技巧

劳动争议：劳动合同、社会保险、经济补偿金、工伤、违法解除、竞业限制

合同纠纷：表见代理、违约责任、合同效力、善意相对人、无权代理

知识产权：外观设计专利、侵权判定、现有设计、独创性

反不正当竞争：互联网不正当竞争、流量劫持、恶意不兼容、数据抓取、广告屏蔽