cawplan-internal-qa-coding-humaninputs-test

CawPlan 内部 QA — 编码人工输入分类测试（批次）

初始化

cawplan skill check

工作流

1. 确定范围：人员、产品和日期范围

人员（可选）：

• 如果请求中提到了某人（例如“spx”或显示名称），运行 cawplan session members，并根据返回的列表进行大小写不敏感或子字符串匹配，以查找确切的 member 键——这是报告中用于 --member 的 git 身份字符串，不一定是其显示名称。
• 如果有多个成员可能匹配，不要猜测——将他们列成编号列表（使用响应中可用于区分的信息：显示名称、电子邮件、member 键），并在继续操作前请用户选择一人。
• 如果没有匹配项，说明这一点，并继续按整个工作区处理，不要猜测。
• 如果未提及人员，不要传入 --member——检查将在整个工作区范围内运行。

产品（可选——仅当请求中提到产品时）：

• 通过 cawplan products list --search "<name>" 解析。
• 如果有多个产品可能匹配，不要猜测——将它们列成编号列表（名称、产品线、unique_id），并在继续操作前请用户选择一个。
• 如果没有匹配项，说明这一点，并询问正确的产品名称，不要猜测最接近的产品。

日期范围（可选）：

• 如果请求中指定了日期范围，则使用该范围。
• 否则，默认使用最近 2 天：--from = 2 天前（含），--to = 今天。

比较模式（可选——默认 both）：

模式	用户意图（示例）	保留的行	评分内容
category	“分类准确率”、“仅看分类”、“只看分类”	云端 category 非空	仅 category
topic	“主题准确率”、“仅看主题”、“只看 topic”	云端 topic 非空	仅 topic
both	默认；“category 和 topic”、“两者”、“两项一起”	云端 category 和 topic 均非空	category、topic，以及组合项（同一行中两者都匹配）

如果用户明确指定了模式，则使用该模式。如果用户只询问 category 或 topic，则使用相应的单项模式。否则使用 both。

在最终报告标题中注明解析后的 compare_mode。

2. 获取人工输入行（内容 + assistant_message + 云端标签）

根据步骤 1 中解析出的范围选择端点——所有端点返回相同的行结构（content、assistant_message、category、topic，以及 .data 中的分页信息）：

已解析范围	命令
无（整个工作区）	cawplan session human-input-logs --from ... --to ...
仅人员	cawplan session human-input-logs --from ... --to ... --member "<exact_member>"
仅产品	cawplan session product-human-input-logs --product-id <id> --from ... --to ...
产品 + 人员	cawplan session product-human-input-logs --product-id <id> --user-id <id> --from ... --to ...（需要该人员的 PRM user_id，而不是 member 键——通过 cawplan users query --email <email> 或 --keyword <name> 解析；如果有多个用户匹配，也要按相同的编号列表消歧规则处理）

持续翻页，直到没有更多结果：

from="<resolved from>"; to="<resolved to>"
extra_flags=()
# extra_flags=(--member "<exact_member>")                       # person only
# extra_flags=(--product-id "<id>")                              # product only, use product-human-input-logs
# extra_flags=(--product-id "<id>" --user-id "<id>")             # product + person, use product-human-input-logs

page=1; page_size=100
: > /tmp/humaninput_rows.jsonl
while :; do
  resp=$(cawplan session human-input-logs --from "$from" --to "$to" "${extra_flags[@]}" --page-num "$page" --page-size "$page_size")
  # substitute "product-human-input-logs" for "human-input-logs" above if a product was resolved
  case "$compare_mode" in
    category)
      echo "$resp" | jq -c '.data.items[]? | select((.content // "") != "" and (.category // "") != "")' >> /tmp/humaninput_rows.jsonl
      ;;
    topic)
      echo "$resp" | jq -c '.data.items[]? | select((.content // "") != "" and (.topic // "") != "")' >> /tmp/humaninput_rows.jsonl
      ;;
    both)
      echo "$resp" | jq -c '.data.items[]? | select((.content // "") != "" and (.category // "") != "" and (.topic // "") != "")' >> /tmp/humaninput_rows.jsonl
      ;;
  esac
  total=$(echo "$resp" | jq '.data.total // 0')
  got=$(echo "$resp" | jq '.data.items | length')
  page=$((page + 1))
  if [ "$got" -lt "$page_size" ] || [ $(((page - 1) * page_size)) -ge "$total" ]; then break; fi
done
wc -l /tmp/humaninput_rows.jsonl

不符合上述 compare_mode 筛选条件的行将被舍弃——例如，在 both 模式下，缺少任一云端标签的行都会被排除。content 为空的行始终排除。

如果行数较多（粗略参考：>100），在对所有行进行分类前告知用户数量并征求确认——每一行都需要单独进行一次分类，也就是你对每行自行推理，而不是脚本/API 调用，因此处理非常大的批次确实需要较多时间。

3. 使用基础技能对每一行进行分类

如果本次会话中尚未阅读过，请先阅读 cawplan-internal-qa-coding-humaninputs 的说明——你需要对每一行应用其中的任务／工作流步骤和分类体系参考文件（位于该技能自己的参考文件夹中），这样分类规则就只在一个地方定义，不会在此处重复。

对 /tmp/humaninput_rows.jsonl 中的每一行，将该行的 content 和 assistant_message 作为输入应用上述分类，并在处理过程中每行输出一条进度信息——这既是进度指示，也是每次原子技能调用的可见输入／输出，而不只是最终摘要：

[<n>/<total>] content: "<content excerpt, ~80 chars>" | assistant: <"<excerpt>" or "(none)"> -> category: <category>, categories: <categories>, topic: <topic>, topic_confidence: <0.00-1.00>

按顺序对每一行都执行此操作，每行输出一条信息，然后再进行比较——不要静默地批量处理多行，最后才报告结果。处理完最后一行后，输出一个纯文本列表，将每行的 unique_id 对应到其结果 category、topic 和 topic_confidence——这样下一步就可以直接进行差异比较，无需重新推导。

4. 与云端标签比较（依据 compare_mode）

对每个维度使用简单的字符串相等比较——不要比较 categories 数组字段，也不要编写或运行任何脚本。不比较 topic_confidence（云端可能存储了 LLM 置信度；此处仅检查标签准确性）。

category 模式——仅将你的 category 与该行云端的 category 比较。

topic 模式——仅将你的 topic 与该行云端的 topic 比较（应用下方的旧版规范化）。

both 模式——分别比较 category 和 topic，并报告综合准确率：经过旧版规范化后，两个标签都匹配的行所占比例。

旧版规范化（规范化后的值一致时，不要将其计为真正的错误）：

• **Category：**云端 v1 类别（decision／direction／requirement／correction／planning／ other）与 v2 叶节点类别——参见基础技能 CATEGORY_TAXONOMY.md 中的旧版对照表 → 分类体系版本不匹配
• **Topic：**云端 improvement → refactor，云端 ux → design_ui → 旧版主题不匹配

输出

第 3 步中的逐行进度信息已经展示了每条输入／输出——以下最终报告是摘要和重点展示，并非用于替代它们。

报告：

• 范围：compare_mode、人员和／或产品（或“整个工作区”）、解析后的日期范围、获取的总行数与该模式下可比较的行数。
• category 模式：category 匹配率；分类体系版本不匹配与真正的不一致；最多约 10 个真正的 category 不匹配项。
• topic 模式：topic 匹配率；旧版主题不匹配与真正的不一致；最多约 10 个真正的 topic 不匹配项。
• both 模式：category 匹配率、topic 匹配率、综合匹配率（同一行的两个标签都正确），并分别列出旧版／分类体系版本不匹配项；每个维度最多列出约 10 个真正的不匹配项（标明仅有一个标签不一致的行）。

说明

• 分类工作本身由 cawplan-internal-qa-coding-humaninputs 逐行完成——此技能只负责范围解析、数据获取和比较。如果该技能的规则发生变化，此技能会自动采用更新后的规则，因为此处没有重复定义这些规则。
• 只比较单值 category 和／或 topic 标签（依据 compare_mode）。categories 数组和 topic_confidence 不纳入评分——置信度仅在进度信息中显示，供人工查看。

参考资料

• references/CAWPLAN_OPEN_API.md