Compare

Issue 流程优化：可控关闭、按标签生成报告与分层任务

2026-01-29 14:30 · Zon · Issue → AI → Report

面向 GitHub Issues 的标签门控 + 评论指令 + 幂等更新落地方案

用标签与评论指令控制Issue报告/任务生成与关闭

TL;DR

  • 定义：本文将“主题”指代“报告/任务输出的模板样式（theme）”，不是 issue 话题分类。
  • 通过“标签 + 评论指令”三件套控制：是否生成报告、报告深度、是否允许自动关闭。
  • 采用“单条可更新的报告评论”模式：你每次回复触发重算并更新同一条评论，避免重复刷屏。
  • 任务按“Epic/Task/Subtask + Complexity(S/M/L)”分层；涉及厂商价的复杂需求走专门模板与信息缺口清单。

Key Insights

  • 自动关闭通常源于机器人把“已回复/已生成”误当“已完成”；应改为显式关闭（/close 或 ready-to-close 标签）。
  • 报告生成与任务拆分应解耦：用 report:none/report:lite/report:deep 标签决定输出，避免每个 issue 都产出长报告。
  • 评论驱动更新要幂等：用固定 marker 定位旧报告并更新（如配合 peter-evans/create-or-update-comment），并过滤 bot actor 防止循环触发。
  • 复杂度与层级最好结构化（labels 或 GitHub Projects 字段），否则“简单/复杂混在一起”无法排序与分派。

Playbook

  • 标签规范（最小可用）：report:none（只要任务）、report:lite（摘要+任务）、report:deep（调研+任务）；complexity:S/M/L；type:epic/task/subtask；state:hold/doing/done。默认给新 issue 自动加 report:lite。
  • 关闭策略：工作流/机器人不再自动 close；仅当检测到评论指令“/close”或新增标签 state:ready-to-close 时才执行关闭，否则仅更新状态标签为 state:done。
  • 评论触发更新：监听 issues、issue_comment(created/edited)；只对指定用户/作者触发；生成内容写入带 <!-- bot-report --> marker 的评论并持续覆盖更新，可用 actions/github-script + create-or-update-comment 实现。
  • 深度调研（厂商价）模板：当存在 report:deep + needs:vendor-quote 时，输出固定结构（需求约束、评估维度、候选厂商清单、待补充信息、更新时间）；对“无法在线核验”的价格信息强制标注口径与来源状态。

Diagrams

Decision Map ↑ Control / Consistency Speed / Convenience → 1 方案 A（推荐）：纯 GitH… B 把“主题”理解为“报告模板/皮… C 把“主题”理解为“话题分类”：… D 仅做任务拆分器：对带 repo…
Options · 速度 vs 可控性 的决策图（基于 Options 文本自动定位）
Execution Steps 1 标签规范（最小可用） 2 关闭策略 3 评论触发更新 4 深度调研（厂商价）…
Playbook · 执行步骤时间线（基于 Playbook 文本自动提取）

Options

  • 方案 A（推荐）：纯 GitHub 方案：labels 控制输出，Actions 在 issue/comment 事件中生成并更新同一条报告评论；必要时同步成仓库文件便于 Obsidian 索引。
  • 方案 B：把“主题”理解为“报告模板/皮肤”：机器人输出结构化数据（YAML/JSON），由 Obsidian Templater/Dataview 渲染成不同主题样式，满足你“换主题”的诉求。
  • 方案 C：把“主题”理解为“话题分类”：用 issue forms 收集 Topic/Complexity，报告按 Topic 定时汇总（每日/每周），而不是每条 issue 即时生成。
  • 方案 D：仅做任务拆分器：对带 report:none（或 mode:tasks）的 issue 只输出任务树与复杂度，不做调研；对 report:deep 才生成长报告与厂商价表格。

Expert Views

  • 产品经理（paraphrase）：把“输出类型”做成显式开关（标签/命令），默认轻量，先解决误关与刷屏，降低沟通成本。
  • 开源自动化工程师（paraphrase）：GitHub Actions + Octokit/gh API 足以做标签门控与幂等更新；关键工程点是防循环触发、权限最小化与失败可重试。
  • 交付/采购视角（paraphrase）：厂商价必须记录币种/税费/计费口径/有效期与时间戳；否则结论不可复用，宁可先产出“报价缺口清单”。
  • 知识管理教练（paraphrase）：层级任务要能被查询与汇总；建议把 complexity/type 变成可过滤字段，并把报告折叠在 <details> 中提高可读性。

Evidence & Confidence

  • GitHub Actions 可基于 issues/issue_comment 事件触发并调用 API 更新评论：confidence high；官方文档与成熟 action 支持（但此处无法在线核验）。
  • “固定 marker + 更新同一评论”能显著降低噪音并便于持续迭代：confidence high；工程上可实现且风险可控（过滤 bot actor、限制触发用户）。
  • “labels/Projects 字段化复杂度与层级”能提升排序、分派与统计：confidence medium；方法成熟但需要团队/个人习惯配合与字段治理。
  • “厂商价调研需要口径与证据链”是高质量报告前提：confidence medium；原则可靠，但取决于能否获取可核验信息与持续维护。

Next Steps

  • 澄清三件事：现在是谁在自动关闭（Actions/机器人/人工习惯）？“主题”指模板还是 UI 主题？报告最终要落到哪里（issue 评论/仓库文件/Obsidian 笔记）？
  • 先落地最小标签集并创建约定文档（例如 LABELS.md），同时把“report:none”作为你快速输入时的默认选择之一。
  • 做一个最小可用工作流：检测标签/命令→生成任务树→用 create-or-update-comment 覆盖更新；观察一周再加复杂度分层与厂商价模板。
  • 为 needs:vendor-quote 建立标准字段（厂商、方案、价格口径、链接/截图、更新时间、备注、可核验状态），并规定无法核验时的标注格式。

Details (Optional)

Details

TL;DR

  • 定义：本文将“主题”指代“报告/任务输出的模板样式（theme）”，不是 issue 话题分类。
  • 通过“标签 + 评论指令”三件套控制：是否生成报告、报告深度、是否允许自动关闭。
  • 采用“单条可更新的报告评论”模式：你每次回复触发重算并更新同一条评论，避免重复刷屏。
  • 任务按“Epic/Task/Subtask + Complexity(S/M/L)”分层；涉及厂商价的复杂需求走专门模板与信息缺口清单。

Key Insights

  • 自动关闭通常源于机器人把“已回复/已生成”误当“已完成”；应改为显式关闭（/close 或 ready-to-close 标签）。
  • 报告生成与任务拆分应解耦：用 report:none/report:lite/report:deep 标签决定输出，避免每个 issue 都产出长报告。
  • 评论驱动更新要幂等：用固定 marker 定位旧报告并更新（如配合 peter-evans/create-or-update-comment），并过滤 bot actor 防止循环触发。
  • 复杂度与层级最好结构化（labels 或 GitHub Projects 字段），否则“简单/复杂混在一起”无法排序与分派。

Playbook

  • 标签规范（最小可用）：report:none（只要任务）、report:lite（摘要+任务）、report:deep（调研+任务）；complexity:S/M/L；type:epic/task/subtask；state:hold/doing/done。默认给新 issue 自动加 report:lite。
  • 关闭策略：工作流/机器人不再自动 close；仅当检测到评论指令“/close”或新增标签 state:ready-to-close 时才执行关闭，否则仅更新状态标签为 state:done。
  • 评论触发更新：监听 issues、issue_comment(created/edited)；只对指定用户/作者触发；生成内容写入带 <!-- bot-report --> marker 的评论并持续覆盖更新，可用 actions/github-script + create-or-update-comment 实现。
  • 深度调研（厂商价）模板：当存在 report:deep + needs:vendor-quote 时，输出固定结构（需求约束、评估维度、候选厂商清单、待补充信息、更新时间）；对“无法在线核验”的价格信息强制标注口径与来源状态。

Expert Views

  • 产品经理（paraphrase）：把“输出类型”做成显式开关（标签/命令），默认轻量，先解决误关与刷屏，降低沟通成本。
  • 开源自动化工程师（paraphrase）：GitHub Actions + Octokit/gh API 足以做标签门控与幂等更新；关键工程点是防循环触发、权限最小化与失败可重试。
  • 交付/采购视角（paraphrase）：厂商价必须记录币种/税费/计费口径/有效期与时间戳；否则结论不可复用，宁可先产出“报价缺口清单”。
  • 知识管理教练（paraphrase）：层级任务要能被查询与汇总；建议把 complexity/type 变成可过滤字段，并把报告折叠在 <details> 中提高可读性。

Options

  • 方案 A（推荐）：纯 GitHub 方案：labels 控制输出，Actions 在 issue/comment 事件中生成并更新同一条报告评论；必要时同步成仓库文件便于 Obsidian 索引。
  • 方案 B：把“主题”理解为“报告模板/皮肤”：机器人输出结构化数据（YAML/JSON），由 Obsidian Templater/Dataview 渲染成不同主题样式，满足你“换主题”的诉求。
  • 方案 C：把“主题”理解为“话题分类”：用 issue forms 收集 Topic/Complexity，报告按 Topic 定时汇总（每日/每周），而不是每条 issue 即时生成。
  • 方案 D：仅做任务拆分器：对带 report:none（或 mode:tasks）的 issue 只输出任务树与复杂度，不做调研；对 report:deep 才生成长报告与厂商价表格。

Evidence & Confidence

  • GitHub Actions 可基于 issues/issue_comment 事件触发并调用 API 更新评论：confidence high；官方文档与成熟 action 支持（但此处无法在线核验）。
  • “固定 marker + 更新同一评论”能显著降低噪音并便于持续迭代：confidence high；工程上可实现且风险可控（过滤 bot actor、限制触发用户）。
  • “labels/Projects 字段化复杂度与层级”能提升排序、分派与统计：confidence medium；方法成熟但需要团队/个人习惯配合与字段治理。
  • “厂商价调研需要口径与证据链”是高质量报告前提：confidence medium；原则可靠，但取决于能否获取可核验信息与持续维护。

Next Steps

  • 澄清三件事：现在是谁在自动关闭（Actions/机器人/人工习惯）？“主题”指模板还是 UI 主题？报告最终要落到哪里（issue 评论/仓库文件/Obsidian 笔记）？
  • 先落地最小标签集并创建约定文档（例如 LABELS.md），同时把“report:none”作为你快速输入时的默认选择之一。
  • 做一个最小可用工作流：检测标签/命令→生成任务树→用 create-or-update-comment 覆盖更新；观察一周再加复杂度分层与厂商价模板。
  • 为 needs:vendor-quote 建立标准字段（厂商、方案、价格口径、链接/截图、更新时间、备注、可核验状态），并规定无法核验时的标注格式。

Sources

Sources

Closing Summary

  • 结论：用标签与评论指令控制Issue报告/任务生成与关闭
  • 下一步：先确认“主题/自动关闭触发源/报告落点”，再按方案A落地最小标签门控与单评论更新

One next action

先确认“主题/自动关闭触发源/报告落点”，再按方案A落地最小标签门控与单评论更新

先闭环，再上强度。
— AI pipeline