对庭律师背景画像卡

用户会反复提供律师姓名（有时带城市或律所），要求输出一份画像卡用于庭前准备。
这是长期复用的任务，本文件是其标准作业流程。

配套资源：
- references/retrieval-and-classification.md —— 检索通道参数、召回自检、角色/机构判定规则（做判定前必读）
- references/deliverable-spec.md —— 交付形态、合规红线、免责声明模板
- scripts/profile_pipeline.py —— 可复用的抽取+统计脚本（已用真实样本验证）
- CHANGELOG.md / VERSIONS/ —— 版本历史与回退方法

0. 适用边界

适用：中国内地执业律师的公开执业信息画像，用于己方庭前准备。

不适用 / 需拒绝：
- 要求评估律师"人品、能力、口碑" → 只描述可核查的行为模式与文书事实，不做人格评价
- 要求查询私人生活、家庭、住址、未公开案情 → 拒绝
- 要求获取对方当事人信息、在办案件内部信息 → 拒绝
- 非中国内地执业者（中国香港/中国澳门/中国台湾及境外）→ 数据库与执业登记体系不同，须先声明能力边界

1. 作业流水线

2. 身份唯一性确认（不可跳过）

四要素

同名排除

对姓名做 WebSearch + 律师页检索，逐个比对"律所/城市/执业证号"：
- 律所不同 → 直接排除，写入交付物的"同名排除记录"表
- 无法区分 → 列候选让用户确认，绝不默认选第一个

⚠️ 必须检索"执业初期律所"

律师实习期/执业初期常挂靠另一家所，只查当前律所会整段丢失早期数据。
- 查找途径：按年份分桶取最早几年的文书；司法厅许可决定书；律协执业机构变更公示
- 实战案例：马士成 2019 年入广东晟典，但 2018 年文书显示其在广东众诚律师事务所（记载为"实习律师"）。
只按"晟典"检索会漏掉 4 件早期案件。--firm 参数要把所有历史律所都传进去。

3. 检索与召回自检（决定样本质量）

通道优先级、参数含义、分桶策略详见 references/retrieval-and-classification.md。核心结论：

1. 主检通道只有一个：元典 yuandian_rh_ptal_search，qw="姓名 律所"（AND）
   - 企查查·法律不支持以代理律师为检索字段（实测 0 条），不要浪费时间
   - 威科先行可交叉验证，但配额易耗尽
2. "律师"不是检索字段 → 召回必然不完整，必须如实披露
3. 召回自检是硬闸门：每次检索后比对 total 与 len(lst)
   - len(lst) < total → 必须分桶重跑（按年 ja_start/ja_end、按文书种类 wszl、按案件类别 ajlb）
   - 多检索式结果按案号去重合并
   - 脚本会在 extract 阶段自动打印截断告警
4. 不重跑检索：返回超 token 时系统会自动落盘到
   ~/.workbuddy/projects/<proj>/<session>/tool-results/mcp-*.txt，用脚本读文件即可

4. 统计与判定

直接跑脚本，不要手写解析：

PY="C:/Users/MyPC/.workbuddy/binaries/python/versions/3.13.12/python.exe"
SK="$HOME/.workbuddy/skills/litigation-counterpart-profile"

# 第一步：抽取 / 去重合并 / 机构归属过滤
"$PY" "$SK/scripts/profile_pipeline.py" extract \
    --results-dir "<tool-results 目录>" \
    --name <姓名> \
    --firm <当前律所> --firm <执业初期律所> \
    --extra extra.json \
    --out cases.json

# 第二步：输出 Markdown 统计报告
"$PY" "$SK/scripts/profile_pipeline.py" stat --cases cases.json --out report.md

脚本会输出：案由分布、程序角色与实质身份两张立场表、攻守归类、法院层级、
程序/审级、常出庭法院、年份分布、执业机构，以及 ⚠️ 需人工复核清单。

口径必须与手工一致的三条铁律

1. 攻守看实质身份，不看程序位置——被上诉人（原审原告） 是攻方
2. 角色判定必须先把当事人首部与正文切开——否则同一律师会被判成两个角色
3. 回退判定项必须单列并标注浮动区间——不要用硬猜的数字填表

5. 战绩章节的写法

用户会要求"战绩"，但直接给胜率是错的（调解书不上网、撤诉上网率低、执行到位不公开、检索本身不完整）。

正确做法：
1. 明文警告"任何胜率结论在此样本上都不成立"
2. 列结果要素分布（撤回起诉 / 支持类判项 / 驳回上诉维持原判 / 终本 / 仲裁裁决相关）
3. 挑可确证的代表性案例，附案号 + 判决书原文引述 + 其代理方位置与胜负
4. 说明哪些指标不可测量（真实胜率、和解率、执行到位率）

6. 行为画像

• 律所官网"所内活动报道"是金矿——律师本人的专业分享/讲座常由律所官网或公众号发布，
  是唯一可逐字引用的公开观点来源。检索式："律所名" 姓名 分享 / 讲座 / 专业下午茶 / 沙龙
• "无自媒体"是有效结论，不是失败——须明文写出，并给出庭前启示：
  用公开言论预判其主张的路径失效，改走同类案由文书说理反推
• 同案搭档统计：统计本所搭档出现频次 → 提示实际出庭人可能是搭档，建议向法院确认出庭代理人
• 稳定客户/案源识别：同一当事人反复出现的系列案 = 其核心客户，可推断业务偏好

7. 交付前自查清单

• [ ] 身份四要素齐全，同名排除记录已写入，无"默认选第一个"
• [ ] 执业初期律所已检索并纳入
• [ ] 每项检索式的 total 与 lst 已比对，截断项已分桶补齐
• [ ] 有效样本量、统计区间、截至日期三处都标了
• [ ] 立场给了两张表（程序角色 + 实质身份），攻守按实质身份算
• [ ] 回退判定项已列出，并写明"人工复核后可能浮动 ±N"
• [ ] 战绩未给单一胜率，已列不可测量项
• [ ] 关键结论均有可溯源链接
• [ ] 未转载个人手机号/微信号/私人邮箱
• [ ] 免责声明完整（见 references/deliverable-spec.md §3）
• [ ] present_files 已调用
• [ ] 追问三件事已发出：①涉案件由/争议焦点/我方立场 ②承办法院与法官 ③统计区间偏好
• [ ] 已写入工作区 memory/YYYY-MM-DD.md

8. 成功经验（v1.0.0→v1.1.0 验证有效，请保持）

9. 失败教训（踩过的坑，务必规避）

9.1 本机环境类

9.2 数据通道类

9.3 方法学类（最昂贵的三条）

9.4 合规类

9.5 返工类

9.6 已知未解项（诚实登记）

• 无法评估召回率：裁判文书上网不完整，没有任何通道能给出"该律师真实案件总数"作为分母。
  因此不能声明样本覆盖率，只能声明样本量。
• 调解/撤诉案件大量缺失：导致战绩类指标系统性偏高或偏低，方向不可知。
• fallback 判定的准确性未验证：目前只能标记出来交人工复核，未找到自动化校验方案。
• 跨省执业经验：样本中异地案件极少时，无法判断是"不去外地"还是"外地文书未上网"，交付物中应避免下此结论。

10. 交付形态

默认产出自包含 HTML 画像卡（light 主题、单文件、可直接打印分享），命名
<姓名>律师-对庭背景画像卡.html 放工作区根目录。

固定章节顺序、版式规范、合规红线、免责声明模板 → 见 references/deliverable-spec.md。

11. 版本管理

• 版本号写入 frontmatter 的 version 字段
• 每次实质修改：先把当前 SKILL.md 复制到 VERSIONS/v<旧版本>-SKILL.md，再改主文件，
  然后在 CHANGELOG.md 记录
• 回退方法见 CHANGELOG.md

语义化约定：修 bug / 补规则 → 次版本号 +1（1.1.0 → 1.2.0）；
只改文案措辞 → 修订号 +1（1.1.0 → 1.1.1）；
流程结构性重构（阶段增减、交付形态变更）→ 主版本号 +1（1.x.x → 2.0.0）