全程可审计原生 GitHub 工作流现有检查仍掌握决定权每个任务的成本清晰可见
积压的 issue 不再无人处理
分流是最容易因无人处理而失去价值的工作:一个 issue 搁置一周,报告者不再回应,上下文随之丢失。developerz.ai 依据你 maintainer.yml 中的策略阅读每一个 issue,应用你的标签,关联可能重复的条目,向报告者索取缺失的复现步骤,然后交给你的 AI 开发者处理,或升级给你。任何决定都不会在无记录的情况下做出,每一步都是一条可查阅的审计记录。
提交即完成标记
按你自己的标签体系统一标记,在 issue 提交时即完成,而不必等到下一次分流会议。
报告者及时得到回应
缺少版本号、复现步骤或日志时,智能体会直接在讨论中索取。
只有需要你处理的才会交给你
安全、许可证与带有敌意的语气等信号会中止流程并升级给人工,而不是由机器人回复。
何时暂停并征询你
低于你设定的置信度时,由你决定
当它对某个 issue 的判断低于 triage.confidence_threshold(默认 0.6,可自行调整)时,会将其升级给你,而不是凭猜测行事;默认情况下,这类移交会出现在每周摘要中,而不是即时邮件。缺少信息的缺陷报告会收到一次询问,随后再询问一次并明确列出仍缺少的内容;此后该 issue 会以 not planned 关闭,补充信息的回复会重新打开它。答案已能解决的问题会被关闭;开启去重时,能关联到原始 issue 的重复项也会被关闭。安全、许可证和 CLA 相关问题始终交由你处理;带有敌意的讨论和直接提及维护者的情况同样如此,除非你将其从 escalate.always 中移除。只有当 issue 与你在 triage.non_goals 中写下的某一条相符时,它才会判定为超出范围,并且只发表评论,不会关闭 issue。
查看分流设置
developerz-bot 已定位到 session.ts 和两个集成测试。