- 人工智能
- AI Agent
- Agent 工作流
- CLI
- 研发协作
- AI 技能
- MCP 服务
【免费下载链接】loop-engineering
Practical patterns, starters & CLI tools for loop engineering with AI coding agents. Design systems that prompt and orchestrate agents (inspired by Addy Osmani and Boris Cherny). Includes loop-audit, loop-init, loop-cost.
导读
本文围绕 loop-engineering 仓库中的issue-triage技能（Skill）展开，讲解如何让 AI 编码代理以“报告优先、提案优先”的低风险方式持续扫描 GitHub Issue 与 Discussion，完成去重、分级（P0–P3）与标签建议，并把结果滚动写入issue-triage-state.md，让人类和 Daily Triage 循环始终知道 backlog 里“最该处理的 Top 5”。读完本文，你将掌握该 Skill 的输入输出契约、评分模型、L1/L2 分级权限边界，以及如何与 verifier、Daily Triage 配对形成一条可长期无人值守的队列健康流水线。
一、Skill 定位：Issue 队列健康代理
issue-triageSkill 的完整定义位于 starters/issue-triage/.codex/skills/issue-triage/SKILL.md，它在templates/SKILL.md.issue-triage中也有同名模板可供拷贝。SKILL.md 的 frontmatter 明确了它的身份与边界：
--- name: issue-triage description: > Scan open issues and discussions. Dedupe, prioritize, and propose labels. Updates issue-triage-state.md. L1 propose-only — never auto-label or close. user_invocable: true ---三个关键信息：
- 职责：扫描开放的 Issue 与 Discussion，做去重（dedupe）、分级（prioritize）、标签提案（propose labels）；
- 产物：更新
issue-triage-state.md状态文件； - 硬性约束：默认处于L1 提案模式，绝不自动打标签、绝不自动关单。
Skill 正文用一句话定义了它的角色：“You are an issue queue health agent”——保持 backlog 清晰可读，让人类和其他 loop 永远知道当前 Top 5 的可执行事项。这正是它在整个 loop-engineering 体系中的定位：一个低风险、高杠杆的“队列健康巡检员”，其完整模式文档见 patterns/issue-triage.md。
二、输入与信号源
SKILL.md 明确列出了 Skill 的三类输入：
- 开放的 GitHub Issue 与 Discussion（若配置了 MCP，也可读取 Linear / Jira）；
- 上一次运行产出的
issue-triage-state.md——它既是历史状态，也是本次运行的起点； - 信号（Signals）：
age（存活天数）、author（提交者）、labels（已有标签）、comments（评论数）、reactions（表情反应）、linked PRs（关联 PR）、milestone（里程碑）。
这些信号直接决定了后续的评分逻辑。需要特别说明的是信号采集方式：仓库在 examples/grok/issue-triage.md 中补充说明，可以启用GitHub MCP 只读模式做 Issue 发现与关联 PR 信号采集，在循环被信任之前，MCP 权限应限定为"读取 + 提案"（read + propose），这与 L1 只读原则保持一致。
三、输出契约：issue-triage-state.md的标准结构
SKILL.md 给出了输出状态文件的规范模板，这是整个循环的"记忆脊柱"，必须逐节继承：
# Issue Triage State Last run: <ISO timestamp> Open actionable: N (was M) New since last run: K Needs human: H ## Top 5 (by loop score) - #NNN (p1, 2d old) — "one-line summary" — suggested: label1, label2 ## Proposed Labels (not applied in L1) - #NNN: `label-a`, `label-b` ## Possible Duplicates (human confirm) - #NNN — possible duplicate of #MMM ## Noise / Ignored - brief list字段含义与使用要点：
Last run：ISO 时间戳，用于跨轮次对比增量；Open actionable：当前可执行事项总数，(was M)记录上一轮数值，形成趋势感知；New since last run：本轮新增数量；Needs human：需要人工介入的数量，这是"告警疲劳"的闸门——只有这个切片才通知人类；Top 5 (by loop score)：按循环评分排序的 Top 5，每行包含 issue 编号、优先级、存活天数、一句话摘要和建议标签；Proposed Labels：提案标签区，明确标注"L1 不应用"；Possible Duplicates：疑似重复，标注"human confirm"（人工确认）；Noise / Ignored：本轮忽略的噪音项，简短列出即可。
仓库提供了可直接落地的初始模板 starters/issue-triage/issue-triage-state.md.example，其内容在 SKILL 模板基础上额外补充了两个关键区块：
## Allowlisted labels (L2 only) `area:*`, `needs-repro`, `needs-info` ## Denylist (always human) auth, payments, security, public-api, breaking-change也就是说，状态文件不仅是输出，本身还承载了白名单/黑名单策略的持久化，让每次运行都能读到上轮确立的权限边界。
从 patterns/issue-triage.md 可以看到该文件的真实运行形态：
# Issue Triage State Last run: 2026-06-09 09:15 UTC Open actionable: 14 (was 17) New since last run: 3 Needs human: 2 (one potential duplicate of #412, one unclear spec) ## Top 5 (by loop score) - #487 (bug, p1, 2d old) — "Crash on export with large files" — suggested: bug + needs-repro + area:export模式文档还强调了一个维护原则：每次运行都要从状态文件中剪除已关闭/已合并的条目，只保留"需要关注"的事项，避免状态文件无限膨胀。
四、评分模型：P0–P3 分级表
SKILL.md 的核心分级逻辑是一张信号映射表，它把原始信号翻译成优先级：
| Priority | Signals |
|---|---|
| P0 | Security, prod breakage, data loss |
| P1 | High impact + clear repro or customer pain |
| P2 | Valid feature/bug, not urgent |
| P3 | Nice-to-have, docs, polish |
| needs-info | Unclear spec, missing repro |
| duplicate? | Title/body overlap with existing issue |
逐级解读：
- P0（最高）：安全漏洞、生产故障、数据丢失——这类条目在 L1 阶段也必须立即浮出水面，但分级动作本身仍只是提案，落到状态文件由人处理；
- P1：高影响且有清晰复现路径或明确客户痛点；
- P2：有效但非紧急的功能缺陷或需求；
- P3：锦上添花、文档、打磨类；
- needs-info：规格不清、缺少复现步骤——这是 Skill 对"信息不完整"的标准响应，避免把模糊请求误判为高优任务；
- duplicate?：标题/正文与既有 issue 高度重叠——注意这里带着问号，体现"保守去重"的立场。
patterns/issue-triage.md 给出了一个完整的典型循环周期，可以看作是评分模型的执行流程：
- 发现自上次运行以来新增/更新的 Issue 与 Discussion（首次运行则扫描全部开放项）；
- 对每条：总结意图、检测重复（标题 + 嵌入提示或简单文本匹配）、采集信号（age、author、linked PRs、reactions、现有标签）；
- 评分归类：P0 / P1 / P2 / P3 / needs-info / duplicate；
- 将干净的优先级列表 + 建议标签集 + 一句"为什么重要"写入状态文件；
- verifier（或人类）只审查 "needs human" 桶和敏感区域的标签变更提案；
- 记录本次运行、剪除已解决项、更新计数。
五、规则体系：L1 提案优先，分级放权
SKILL.md 的 Rules 节是整个 Skill 的安全内核，逐条继承并展开如下：
- L1（第一周）：只提案标签和优先级，绝不应用标签、绝不评论、绝不关闭。这是"零风险入场"的设计——即使 Skill 判断失误，也不会对仓库产生任何副作用；
- 升级到 "needs human" 的触发面：
auth（认证）、payments（支付）、security（安全）、public API、billing（计费）、infra（基础设施）——只要触及这些领域，一律进入人工桶； - 重复匹配保持保守：只输出 "possible duplicate of #NNN"，绝不自动关闭。这与
duplicate?分级中的问号一脉相承； - 每次运行剪除已关闭 issue，保持状态文件精简；
- 保持简洁：繁忙仓库可能每 2 小时运行一次，输出必须紧凑可读。
这些规则在 starters/issue-triage/LOOP.md 中被进一步落实为**人工闸门（Human Gates）**清单：
- P0 / P1 的指派——前几周仅限人工；
- 认证、支付、安全、公共 API——永远升级到人工；
- 重复 issue 的关闭——人工确认；
- 陈旧 issue 的关闭——人工确认。
同时 LOOP.md 给出了预算约束：每次运行最多派生 1 个子代理（仅用于 L2 带 verifier 的标签应用），相关预算细节见 loop-budget.md。
六、允许名单（Allowlist）：L2 的边界
SKILL.md 明确规定了 L2（第二周之后）可自动应用的标签白名单：
area:*,needs-repro,needs-info— never auto-applyP0,P1,breaking-change, orsecurity
即：即使升到 L2，也绝不自动应用P0、P1、breaking-change、security这类高敏感标签。L2 自动打标必须经过 verifier 通过之后才能执行。
verifier 的角色在 starters/issue-triage/.codex/agents/verifier.toml 中有完整定义，它采用maker/checker（实现者/检查者）分离的默认立场——"REJECT until proven otherwise"（除非被证明通过，否则一律拒绝）。其检查清单包括：
- Scope：只改相关文件，不触碰黑名单路径；
- Intent：是否对准既定目标；
- Tests：检查者亲自运行测试并报告 pass/fail 及输出；
- No cheating：不允许禁用测试或跳过断言；
- Risk：即使测试通过，中等以上风险也要建议人工复审。
输出裁决为APPROVE | REJECT | ESCALATE_HUMAN三者之一，推理强度设为high。对应地，仓库还提供了loop-verifier技能（skills/loop-verifier/SKILL.md）作为轻量检查手段。patterns/issue-triage.md 的验证策略与之呼应：L1 阶段循环从不自动打标或关单；L2 阶段在 verifier 通过后仅应用白名单标签；P0/P1 指派在前几周始终由人掌控，凡触及认证、支付、安全或公共 API 的事项一律人工负责。
七、与 Daily Triage 配对：队列喂食器
SKILL.md 末尾专门讲了配对方式：
Daily Triage reads this file and merges Top 5 into
STATE.mdHigh Priority. Do not duplicate full issue bodies in STATE.md — reference issue numbers only.
即：Issue Triage 是 Daily Triage 的喂食器（feeder）。Issue Triage 以更频繁的节奏（2h–1d）产出干净的队列，Daily Triage（1d）读取issue-triage-state.md并把 Top 5 合并进STATE.md的 High Priority 区。关键约定是：不要把 issue 完整正文复制进 STATE.md，只引用 issue 编号，避免状态文件冗余。
这一分工在 starters/issue-triage/README.md 中被描述为"低风险的 issue 队列喂食器"，而 Daily Triage 模式的完整定义见 patterns/daily-triage.md。多循环协调的整体视角可参考 docs/multi-loop.md。
八、落地运行：快速开始与提示词
starters/issue-triage/README.md 提供了三种工具的脚手架命令：
# Grok npx @cobusgreyling/loop-init . --pattern issue-triage --tool grok # Claude Code npx @cobusgreyling/loop-init . --pattern issue-triage --tool claude # Codex npx @cobusgreyling/loop-init . --pattern issue-triage --tool codex启动提示词（Grok，第一周）：
/loop 2h Run issue-triage. Read issue-triage-state.md first. Update Top 5 and proposed labels. No auto-apply. Escalate security and ambiguous items.其中--tool参数决定脚手架生成哪套工具适配层。以 Codex 为例，本文主体所在的技能文件即位于starters/issue-triage/.codex/skills/issue-triage/SKILL.md；同一 starter 还包含.claude/agents/loop-verifier.md（L2 标签应用检查器）等配套文件。
examples/grok/issue-triage.md 给出了更完整的周启动提示词：
/loop 2h Run the issue-triage skill. Read issue-triage-state.md first. Scan open issues and discussions since last run. Update issue-triage-state.md with: - Top 5 prioritized items (P0–P3) with one-sentence summaries - Suggested labels (proposed only — do not apply) - "needs human" bucket for ambiguous or security-sensitive items Do not auto-label, close, or comment on issues. Escalate duplicates as "possible duplicate of #NNN" for human confirmation.繁忙仓库可加速节奏：
/loop 1d Run issue-triage at start and end of day. Report mode only.也可以在examples/github-actions/找到基于issues/discussion事件触发 + 定时兜底的 GitHub Action 工作流示例。
九、进化路径与失败模式
进化路径（L1 → L2 → 永不无人值守）
examples/grok/issue-triage.md 给出了清晰的三阶段演进：
- L1（第 1–2 周）：只提案标签与优先级，人工手动应用；
- L2（第 3 周起）：verifier 通过后自动应用白名单标签（
area:*、needs-repro、needs-info）； - 永不无人值守：涉及认证、支付、安全或公共 API 的 P0/P1 事项——永远由人工处理。
失败模式与缓解
patterns/issue-triage.md 列出了三种典型失败模式及对策：
| 失败模式 | 缓解措施 |
|---|---|
| 过度优先高噪提交者 | 用团队真正关心的信号加权（reactions、linked PRs、内部 +1），人工覆盖记录在状态文件中 |
| 重复检测误报 | 保守匹配 + L1 阶段始终以 "possible duplicate of #NNN" 形式提交人工确认 |
| 每个新 issue 都触发告警疲劳 | 只对 "needs human" 切片通知人工，其余内容全部留在状态文件中供 Daily Triage 或工程师阅读 |
人工交接点
- 任何触及安全、认证、计费或基础设施的 issue；
- 不确定的重复检测（错误概率 > 30%）；
- 循环想以 "stale" 关闭的超过 N 天的旧 issue（须人工确认）；
- 单次运行出现过多新 issue（上下文过载信号）。
成功度量
- 从 issue 打开到首次有意义标签或 "needs info" 评论的时间缩短；
- 24 小时内获得明确优先级的 issue 占比；
- 工程师主观反馈的"我总是知道 Top 5 是什么"评分（从状态文件评审中获得）；
- 在两个人开始处理同一问题之前被拦截的重复数量。
十、安全边界总结
回到 starters/issue-triage/README.md 的 Safety 节，整个循环的安全设计可以浓缩为两条：
- L1 阶段无任何自动打标或关单动作——所有副作用都被人为延迟；
- 黑名单（denylist）：auth、payments、security——详见 docs/safety.md 中的安全约定。
结合 starters/issue-triage/issue-triage-state.md.example 中的 Denylist（auth, payments, security, public-api, breaking-change），可以得到完整的结论：这个循环通过"报告优先 + 分级放权 + 白名单/黑名单双闸门"的设计，用极低风险换取了持续、可复用的队列健康治理能力。任何团队都可以从 L1 提案模式起步，在确认 triage 质量稳定后再逐步开放 L2 的自动打标权限。
- 人工智能
- AI Agent
- Agent 工作流
- CLI
- 研发协作
- AI 技能
- MCP 服务
【免费下载链接】loop-engineering
Practical patterns, starters & CLI tools for loop engineering with AI coding agents. Design systems that prompt and orchestrate agents (inspired by Addy Osmani and Boris Cherny). Includes loop-audit, loop-init, loop-cost.
相关推荐
Issue Triage 循环实战：用 Codex Automation 构建低风险的 Issue 队列健康巡检（loop-engineering）
Issue Triage 循环实战：用 Codex Automation 构建低风险的 Issue 队列健康巡检（loop engineering） 导读 本文
人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务K线接下来会走成什么样：Kronos 股票预测完整指南
K线接下来会走成什么样：Kronos 股票预测完整指南 打开一张K线图，开盘、收盘、最高、最低、成交量五个维度叠在一起，还混着各种噪声，让通用模型一口气吞下，多
人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务Sunshine 游戏串流搭建指南：从硬件检查到 Moonlight 配对
Sunshine 游戏串流搭建指南：从硬件检查到 Moonlight 配对 Sunshine 游戏串流，简单说就是：一台跑在你 PC 上的自托管串流服务器，用显
人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
