企业官网建设流程全解析

• 人工智能
• AI Agent
• 代码智能体
• Agent 编排
• CLI
• AI 应用

导读

本文围绕 GSD-2 仓库中随附的 issue-triage 工作流模板 展开，讲解如何让 Agent 以一次性（oneshot）方式读取一个 GitHub Issue，完成分类、打标签、定级并输出下一条具体行动建议。读完本文，你将掌握该模板的完整协议（从gh拉取数据、六类主分类 + 七类辅助标签、p0–p3 优先级、结构化输出格式），以及它如何与 GSD-2 的工作流模板注册表、/gsd start命令和workflow-oneshot提示词机制协同工作，可直接用于你自己的开源仓库维护场景。

模板在 GSD-2 中的定位

issue-triage是 GSD-2 扩展内置的 25 个工作流模板之一（目录见 workflow-templates/），属于oneshot模式，其元数据在 registry.json 中登记如下：

"issue-triage": { "name": "Issue Triage", "description": "Categorize, label, prioritize a GitHub issue and suggest next action (oneshot)", "file": "issue-triage.md", "mode": "oneshot", "phases": [], "triggers": ["triage issue", "categorize issue", "label issue", "prioritize issue"], "artifact_dir": null, "estimated_complexity": "low", "requires_project": false }

几个关键语义：

• mode: oneshot：纯提示词驱动。正如 workflow-oneshot.md 所描述的——没有 STATE.json、没有阶段跟踪、没有产物目录、没有恢复机制，"执行完指令就返回"。这与bugfix、small-feature等markdown-phase模板形成鲜明对比：后者会创建.gsd/workflows/...产物目录、写 STATE.json、切gsd/<template>/<slug>分支并支持/gsd start resume恢复（见 commands-workflow-templates.ts 的writeWorkflowState与findInProgressWorkflows实现）。
• requires_project: false：不需要.gsd/项目目录，在任何仓库下都能直接对 GitHub 上的 Issue 进行分流。
• artifact_dir: null：不产生任何落盘产物，符合"只读、只思考、只回复"的定位。
• triggers：triage issue、categorize issue、label issue、prioritize issue。当你在对话中描述这类意图而没有显式指定模板名时，workflow-templates.ts 的autoDetect函数会做词法匹配（多词 trigger 得分翻倍，得分 ≥4 为 high 置信度），自动命中该模板。

启动方式：/gsd start issue-triage

模板通过 GSD-2 的斜杠命令派发，最直接的调用方式是：

/gsd start issue-triage #123 /gsd start issue-triage <issue-URL>

如果只给出自然语言描述，如 "帮我对 #123 做 issue triage"，系统会先尝试把第一个词解析为模板名（resolveByName，支持精确名、前缀模糊、别名映射），失败后再走autoDetect自动检测，命中即触发。相关命令还支持：

• /gsd start --list或/gsd templates——列出全部模板及各自的 phases、复杂度、触发词；
• /gsd templates info issue-triage——查看该模板的详细注册信息；
• /gsd start --dry-run issue-triage #123——只预览会执行的动作而不真正执行。

从源码看，handleStart在派发前还会做几件事：若 auto-mode 正在运行则拒绝启动（模板派发会切分支、发消息，与自动循环冲突，需先/gsd pause）；若是markdown-phase模板则创建分支与 STATE.json；而oneshot 模板全部跳过这些状态化步骤，直接把模板内容注入workflow-start提示词后通过pi.sendMessage触发一轮 Agent 回合（见 commands-workflow-templates.ts）。

模板执行协议详解

1. 拉取 Issue 数据

模板要求从用户参数中取得 Issue 编号（#123）或 URL；缺失则只询问一次。随后用ghCLI 一次性拉取结构化数据：

gh issue view <ref> --json number,title,body,labels,author,createdAt,updatedAt,reactions,comments

这一步取回了正文、标签、作者、创建/更新时间、reactions 和评论数，并顺带检查 linked PRs。判断依据全部来自这些字段：评论数反应社区讨论热度，reactions 反应关注度，createdAt/updatedAt计算年龄与新鲜度。若 Issue 已关闭，则直接说明并停止（除非用户明确要求复审）。这与仓库的 issue-tracker.md 约定的"用ghCLI 操作全部 issue 事务"保持一致；需要注意该文档提醒：在 fork 多 remote 场景下应始终显式传-R指向规范仓库。

2. 分类：一个主分类 + 辅助标签

模板规定恰好选择一个主分类：

在此基础上按需叠加辅助标签：needs-repro、needs-info、good-first-issue、regression、security（发现安全问题要强烈标记）、breaking、external-dep。

这套标签词汇与本仓库的 triage-labels.md 描述的跟踪器标签体系（needs-triage、needs-info、ready-for-agent、ready-for-human、wontfix）互补：前者是模板运行时按内容打的语义标签，后者是仓库级维护流程的角色标签，二者都用gh label/gh issue edit --add-label落地。

3. 优先级评估：p0–p3

评估维度明确给出：影响面（blast radius）、复现频率、reactions 数、是否存在 workaround、是否被既有 issue 引用。这五个维度共同决定级别，避免只看单点证据。

4. 推荐下一步行动（四选一）

模板要求输出一条具体行动，而不是空泛建议：

• Ask for info：列出缺失的 1–3 项具体信息（复现步骤、版本、日志），并起草评论文本；
• Accept and schedule：建议接下来运行的工作流，例如/gsd start bugfix --issue #123或/gsd workflow small-feature——这里与 bugfix 模板的--issue标志打通，把 triage 结论直接喂给后续开发流程；
• Close：起草礼貌的关闭评论并给出理由；
• Escalate：标记人工复核并给出具体原因。

5. 固定输出格式

模板强制要求以下结构化输出，便于人工或下游脚本消费：

Issue: #<n> — <title> Author: <user> Age: <d>d Comments: <n> Reactions: <n> Classification: <primary>, <secondary labels> Priority: <p0/p1/p2/p3> Why: <2–3 sentence rationale> Next action: <recommendation> Comment draft: > <text to post — or "n/a" if no comment needed>

首行浓缩 Issue 身份与热度，中间给出分类/定级与理由，末尾给出行动与可粘贴的评论草稿——一次调用即可产出可直接执行的维护决策。

6. 只建议、不落盘

模板最后一条是硬性红线：评论草稿与标签变更都只是"建议"，绝不在未获用户明确确认时执行gh issue comment或gh issue edit。这与仓库src/web、扩展工具层的只读/写入门控思路一致（例如 GSD-2 的write-gate.ts等工具拦截机制），保证 Agent 的自动化和"人类在环"审批之间的边界清晰。

与 GSD-2 运行机制的印证

从源码层面可以交叉验证模板的设计：

1. oneshot 语义有专门的提示词包装：workflow-oneshot.md 明确写出四条执行规则——不建脚手架、不切分支、一次回合内输出单一产物（报告/总结/评论）、仅在真正被阻塞时才提问。issue-triage正是典型的"报告型" oneshot。
2. 模板加载与匹配链路完整：workflow-templates.ts 提供loadRegistry（带缓存）、resolveByName（精确名 → 大小写不敏感名 → 前缀模糊 → 别名表）、autoDetect（按 triggers 词法打分排序）、loadWorkflowTemplate（按注册表 file 字段读取 .md 原文）。issue-triage.md即通过file: "issue-triage.md"被定位加载。
3. 无状态设计可反复调用：由于artifact_dir: null、mode: oneshot，同一条命令可以对任意数量的 Issue 重复执行而不会互相污染，非常适合配合脚本批量分流。

使用建议与限制

• 适用前提：需在本机安装并认证ghCLI，且对目标仓库有读取权限；Issue 引用必须能从参数中解析出编号或 URL。
• 批量场景：可对一批gh issue list结果循环调用本模板，但要注意模板输出为单 Issue 报告，更适合逐个消费。
• 与后续流程衔接：Accept and schedule分支推荐/gsd start bugfix --issue #123等命令，将分流结论无缝转交 GSD-2 的 bugfix 工作流执行修复。
• 不越权：模板的输出永远是建议与草稿；真正的gh issue edit/gh issue comment需人工确认后手动执行。

结语

issue-triage模板把仓库维护者日常最机械、最耗时的环节——看 Issue、定性、定级、想下一步——压缩成一条 oneshot 命令。它依靠固定的六步协议（拉取 → 分类 → 定级 → 建议行动 → 格式化输出 → 不落盘）保证了输出的可复现性与可消费性，同时通过"只建议不执行"保留了人类的最终决定权。配合 GSD-2 的模板注册表与/gsd start命令，它可以直接嵌入到任何以gh为后端的开源仓库维护流程中。

• 人工智能
• AI Agent
• 代码智能体
• Agent 编排
• CLI
• AI 应用