Step 1.5 模式判定细则

读完 Issue 后立即判定走 PR 路径还是 Comment 路径。判定逻辑分两层：关键词显式优先 → 内容信号。

1.5.1 显式优先

用户原始消息里若有以下关键词，直接锁定模式，跳过内容分析：

关键词（用户消息中出现）	锁定模式
"修复"/"修一下"/"提 PR"/"开 PR"/"端到端"/"改一下"	PR
"回答"/"答疑"/"只评论"/"只回复"/"评论回复"/"不改代码"/"先回复"	Comment

两类同时出现，以含"只 / 不"的一方为准——"只 / 不"是明确缩小意图。

1.5.2 内容判定（无显式关键词时）

读 Issue title + body + labels，做一句话判断"这条 Issue 是否需要改代码？"。

典型 PR 信号（→ 推荐 PR）：

• bug-report / bug / regression 标签 + 复现步骤 + 期望 vs 实际
• feature-request / enhancement 标签 + 明确诉求
• 正文带报错栈、测试失败输出、断言不符、崩溃日志
• 正文显式提出修改某段代码（"应改成"/"建议改为"/"少了 nullptr 检查"等）

典型 Comment 信号（→ 推荐 Comment）：

• question / help-wanted / 咨询 / discussion 标签
• 标题或正文带"如何"/"为什么"/"是否支持"/"请教"/"咨询"/"求助"/"想了解"
• 正文是疑问性陈述、问设计意图、问用法、问适配范围
• 没有任何"应该如何修改"的诉求

信号矛盾或都缺：默认推荐 PR（更主动）；但确认弹窗里把分析摆出来让用户复核。

1.5.3 推荐 + 确认

先把判定结论以普通文本打印到对话主流（不要塞进 AskUserQuestion 的 preview）：

Issue #${issue_number} 模式判定
- Issue 摘要：<一句话>
- 关键信号：<labels + 标题/正文中触发判定的关键词，写明哪条>
- 推荐路径：<PR | Comment>
- 推荐理由：<一句话>

再 AskUserQuestion 三选一：

• 走推荐路径
• 改走另一条
• 取消

用户改路径时，吸收选择继续；不要嘴硬辩护。

1.5.4 路径确定后

• 选 PR：若 Step 0 时跳过了 git author 检查（因为模式未明），现在补做。然后进入 Step 1.6（处理 fork_url 缺失）→ Step 2。详见 pr-path.md。
• 选 Comment：直接跳到 comment-path.md 的 Step C-2。