Hive 集成赏金计划「Game Master 运营手册」维护者从受理、审核、晋升到反作弊的全流程实战指南【免费下载链接】hiveMulti-Agent Harness for Production AI项目地址: https://gitcode.com/gh_mirrors/hive48/hive本文是 HiveMulti-Agent Harness for Production AI开源仓库中 docs/bounty-program/game-master-manual.md 的深度解读版面向运行集成赏金计划Integration Bounty Program的维护者Maintainer / Game Master。手册定位为“运营操作手册”覆盖维护者的完整职责闭环发布赏金并定价、受理领取Claim、审核合并 PR、把关质量门禁、拒绝低质量提交、晋升 Core Contributor、执行反作弊处罚以及维持赏金池活跃。读完本文你将掌握这套赏金体系在 Hive 仓库中的具体运营动作、每个bounty:*标签对应的质量验收标准以及 PR 合并后 XP 自动发放背后的 GitHub Actions Lurkr 自动化链路源码。一、Game Master 的角色定位维护者 赏金计划的运营者在 Hive 的赏金体系里维护者扮演的是“Game Master”游戏主持人角色。与普通贡献者不同Game Master 不负责完成赏金而是负责让整张赏金棋盘正常运转。手册明确了以下五项核心职责发布赏金 Issue 并为 Core Contributor 设定美元金额Post bounty issues and set dollar values把被认领的赏金分配给贡献者Assign claimed bounties to contributors审核并合并赏金 PR合并会触发 GitHub Action 自动授予 XP 并推送 Discord 通知管理 Core Contributor 角色晋升与移除都由维护者手动执行因为该角色涉及金钱监控刷量Gaming与低质量提交保证赏金池不被滥用。这套体系在整个赏金计划中的位置可以参照 docs/bounty-program/README.md赏金计划由三份文档共同定义——Setup Guide从零搭建面向管理员、Contributor Guide面向贡献者与本文解读的Game Master Manual面向维护者运营。三者分工清晰Setup Guide 回答“系统怎么建起来”Contributor Guide 回答“贡献者怎么参与”Game Master Manual 回答“维护者怎么运营好它”。二、受理赏金领取Bounty Claims三种难度三种处置当贡献者在 Issue 下评论“Id like to work on this”时维护者按下述规则处置difficulty:easy直接分配assign immediately。这类赏金定位为“Good First Contribution”风险低、门槛低无需额外考察。difficulty:medium/difficulty:hard先核查该贡献者是否已完成过更简单的赏金check if theyve done easier bounties first避免新手直接扑向高难度任务导致烂尾。分配动作在 GitHub 上完成若分配后7 天内未提交 PR维护者应取消分配并重新开放该赏金unassign and re-open。难度标签体系由 scripts/setup-bounty-labels.sh 一次性创建共 3 个难度标签标签颜色含义difficulty:easy#BFD4F2适合首次贡献difficulty:medium#D4C5F9需要一定熟悉度difficulty:hard#F9D0C4需要显著投入或专业技能7 天窗口并非孤例贡献者侧规则docs/bounty-program/contributor-guide.md同样写明“no PR within 7 days bounty gets re-opened”并且限制每位贡献者最多同时持有 3 个活跃认领Max 3 active claims防止囤积。维护者在受理时应同步核对这两条规则。三、PR 审核主流程六步闭环收到赏金 PR 后维护者按以下顺序执行这是手册给出的标准动作序列验证 PR 与赏金 Issue 匹配Verify the PR matches the bounty issue——防止“挂羊头卖狗肉”用其他改动冒领赏金检查质量门禁Check quality gates——详见下文第四、五节的两套清单交叉审核批准者必须是创建该赏金之外的另一位维护者A different maintainer must approve than the one who created the bounty杜绝自我背书合并前为 PR 打上正确的bounty:*标签Apply the correct label before merging——这一步是 XP 自动发放的触发开关见第十一节源码剖析合并 PR——GitHub Action 自动授予 XP 并推送 Discord 通知Merge — the GitHub Action auto-awards XP and posts to Discord关闭关联的赏金 IssueClose the linked bounty issue。需要特别强调第 4 步的时序标签必须在合并之前打在 PR 上。从 .github/workflows/bounty-completed.yml 的触发条件可以看出工作流监听的是pull_request_target的closed事件并要求github.event.pull_request.merged true且 PR 标签列表中包含bounty:前缀。也就是说如果合并时 PR 上没有bounty:*标签整条 XP 链路根本不会触发。四、质量门禁一Integration Bounties 验收清单集成类赏金围绕工具生态展开手册为四类标签分别定义了可勾选的验收清单。bounty:docs写文档20 XP遵循 tool README 模板Tool README Template配置说明准确API key 的获取 URL 真实可用函数名与实际代码一致未经核验的 AI 生成内容不予通过。bounty:test用真实 API Key 测试工具20 XP测试报告遵循 Agent Test Report 模板包含日志、Session ID 或截图等证据必须使用真实 API Key 完成不得 mock如实报告失败项Reports failures honestly。bounty:code健康检查器 / Bug 修复 / 集成改进30 XPCI 通过健康检查相关使用uv run pytest tools/tests/test_credential_registry.py修复针对根因而非表象Fix addresses root cause, not symptomBug 修复必须附带新增测试New test added for bug fixes。bounty:new-tool从零构建完整集成75 XP完整实现工具 凭据规格Credential Spec 测试 READMEmake check make test全部通过注册在_register_unverified()未验证区而非直接进已验证区。后两条与仓库源码直接对应bounty:code提到的uv run pytest tools/tests/test_credential_registry.py对应仓库中的 tools/tests/test_credential_registry.pybounty:new-tool提到的_register_unverified()位于工具注册入口 tools/src/aden_tools/tools/init.py参见 docs/bounty-program/promotion-checklist.md 的定位说明。从源码结构可以推断工具注册表按“未验证 / 已验证”分区存放bounty:new-tool交付物默认进入未验证区待通过 Promotion Checklist 后再由维护者移动到_register_verified()。五、质量门禁二Standard Bounties 验收清单标准类赏金按工作量与影响力分级docs/bounty-program/README.md 中定义的四种尺寸手册为每一级给出了验收标准。bounty:small小修10 XP改动正确且不引入回归CI 通过范围符合“small”——不得把更大的改动塞进小赏金里not padded into a bigger change。bounty:medium中等30 XPCI 通过Bug 修复附带回归测试regression test文档/指南准确且遵循现有风格未经核验的 AI 生成内容不予通过。bounty:large大型75 XP实现前已在 Issue 中讨论过设计Design was discussed in the issue before implementationCI 通过新增测试覆盖改动性能类工作必须附带基准测试benchmarksbefore/after架构文档须经第二位维护者审阅。bounty:extreme极限150 XP动手前维护者已预先批准设计提案Maintainer pre-approved the design proposalCI 通过测试覆盖全面文档已同步更新以反映改动至少两位维护者审阅Reviewed by at least two maintainers。可以观察到一条递进规律从medium开始强制要求回归测试从large开始要求“先讨论设计再动手”与基准数据到extreme则升级为“双维护者审阅 预批准”质量门槛随金额与 XP 呈阶梯式上升。六、拒绝提交Rejecting Submissions的规范拒绝不是终点而是协作的延续。手册给出的标准动作给出具体、有建设性的反馈Leave specific, constructive feedback——指出问题而非笼统否定请求修改而非关闭 PRRequest changes, dont close the PR——给贡献者修复机会留出 7 天修改窗口超时无响应 → 关闭 PR、解除赏金分配。最后一条原则被手册单独强调并加粗“Never merge low-quality work just to be nice.”永远不要因为人情而合并低质量工作。这既是对贡献者时间的尊重有建设性反馈也是对项目质量的守护。结合 docs/bounty-program/contributor-guide.md 的规则可知贡献者侧同步约束了“no self-review”禁止自我审核与“no AI-only submissions without verification”维护者在拒绝时也应据此说明理由。七、Core Contributor 晋升机制高门槛、高回报Core Contributor 是唯一解锁金钱奖励的层级因此手册明确“The bar must be high”门槛必须高。满足以下条件才可晋升Promote when活跃4 周以上贡献覆盖3 种以上赏金类型contributions across 3 bounty typesPR 一贯干净整洁PRs are consistently clean至少一位维护者为其背书At least one maintainer vouches for them。晋升动作How与维护者团队讨论 → 在 Discord 分配角色 → 在#integrations-announcements频道公告 → 将其加入#bounty-payouts频道该频道仅 Core Contributor 可见用于金额发布与支付记录。不要晋升Dont promote的情况只做 easy 赏金、活跃不足 4 周、或表现出刷量迹象。失活处理Core Contributor 若8 周以上不活跃先私聊联系无回应再移除角色reach out privately first, then remove the role if no response。对照 docs/bounty-program/README.md 的三级体系可见完整晋升路径Agent Builder约 500 XP / Lurkr 5 级与 Open Source Contributor约 2000 XP / Lurkr 15 级由 Lurkr 机器人自动分配唯独 Core Contributor 是纯人工决策——因为它直接绑定真金白银自动化在这里被刻意排除。八、美元价值体系Dollar Values金额表与支付流程金额只在 Discord 的#bounty-payouts频道发布仅限 Core Contributor 可见。集成类赏金Integration bounties赏金类型美元区间bounty:test$10–30bounty:docs$10–20bounty:code$20–50bounty:new-tool$50–150标准类赏金Standard bounties赏金类型美元区间bounty:small$5–15bounty:medium$20–50bounty:large$50–150bounty:extreme$150–500支付流程PayoutPR 合并 → 核验质量verify quality→ 在#bounty-payouts记录 → 处理付款。手册特别强调一条设计原则“XP is always awarded regardless of budget. Money is a bonus layer.”——XP 不受预算限制、始终发放由 scripts/bounty-tracker.ts 中的点数映射自动计算见第十一节金钱只是叠加在 XP 之上的奖励层。这保证了赏金体系在预算紧张时依然能持续运转并积累积分数据。九、反作弊Anti-Gaming模式识别与三级处罚手册用一张“模式 → 应对”表定义了最常见的作弊形态作弊模式应对措施把一个改动拆成多个 PRSplitting one change across multiple PRs拒绝多余 PR发出警告Reject extras, warn未经核验的 AI 生成提交AI-generated without verification拒绝并说明原因Reject, explain why认领大量赏金却很少完成Claiming many, completing few7 天后解除分配Unassign after 7 days处罚采用阶梯制初犯警告 → 再犯停权 2 周2-week cooldown→ 三次永久移除permanent removal。这条规则与前面“拒绝低质量提交”形成组合拳拒绝环节解决单次质量问题反作弊机制解决系统性的刷量行为。维护者在审核时可结合贡献者的认领历史活跃认领数、完成率来判断是否属于“Claiming many, completing few”模式。十、保持赏金池新鲜Keeping It Fresh运营的持续目标是让赏金池保持吸引力与流动性手册给出四条操作性建议随时保持 10 个无人认领的赏金Aim for 10 unclaimed bounties at all times定期解除过期认领超过 7 天无 PR 的认领Unassign stale claims在公告频道为杰出贡献点名致谢Shoutout exceptional contributions in announcements发布里程碑例如“第 10 个工具晋升为 verified”——Post milestones。其中“10 无人认领”与“55-Tool Blitz”启动计划见 docs/bounty-program/README.md 与 docs/bounty-program/setup-guide.md直接呼应仓库中 55 个未验证工具面临“缺 README约 41 个、缺健康检查端点约 40 个、缺社区测试报告55 个”三类缺口正是靠批量发布赏金来填充的。维护者日常职责就是维持这类供给侧的“货架陈列”。十一、自动化引擎源码剖析XP 是如何“自动到账”的手册中反复提到“Merge — the GitHub Action auto-awards XP and posts to Discord”这条自动化链路在仓库源码中可以被完整还原维护者理解它有助于排障与设计新赏金类型。触发端.github/workflows/bounty-completed.yml 监听pull_request_target的closed事件合并条件为merged true且 PR 标签包含bounty:前缀同时支持workflow_dispatch手动补发为“漏发”的赏金提供pr_number输入对应手册里“自动处理漏发”的运营场景。工作流注入的环境变量包括GITHUB_TOKEN、DISCORD_BOUNTY_WEBHOOK_URL、BOT_API_URL、BOT_API_KEY、LURKR_API_KEY、LURKR_GUILD_ID等这些 Secret 的配置方式见 docs/bounty-program/setup-guide.md 第 6 步。计算端scripts/bounty-tracker.ts 内置与文档完全一致的POINTS映射表第 69–80 行可作为核对各标签点数的权威来源标签点数bounty:test20bounty:docs20bounty:code30bounty:new-tool75bounty:small10bounty:medium30bounty:large75bounty:extreme150脚本提供两种运行模式与两个工作流一一对应notify由bounty-completed.yml调用处理单个已完成赏金并推送 Discord 通知与leaderboard由 .github/workflows/weekly-leaderboard.yml 调用生成每周排行榜。从源码可以推断脚本通过 GitHub API 读取 PR 的labels与user结合 MongoDB 中hive.contributors集合完成 GitHub ↔ Discord 身份映射再调用 Lurkr API 推送 XP——这与 docs/bounty-program/README.md 描述的“bounty-tracker.ts → 计算点数 → 解析身份 → 推送 XP → 发通知”流水线一致。身份前提贡献者必须在 Discord 执行/link-github完成 GitHub ↔ Discord 绑定通过公共 gist 验证所有权否则赏金仍会被记录但 Lurkr 无法向其 Discord 账户推送 XP——这也是维护者在排查“合并后没有 XP 到账”时的首要检查项docs/bounty-program/setup-guide.md 的 Troubleshooting 章节给出了同样的排查顺序检查 Webhook Secret → 检查 API Key 是否为 Read/Write → 检查贡献者是否已/link-github→ 检查 Action 日志中的Lurkr XP push failed。标签底座整个体系依赖 scripts/setup-bounty-labels.sh 一次性创建的全部 11 个标签4 个集成赏金 4 个标准赏金 3 个难度标签脚本使用gh label create --force幂等创建可安全重复执行。十二、进一步阅读运营相关的仓库文档地图docs/bounty-program/game-master-manual.md — 本文解读的原始运营手册docs/bounty-program/README.md — 赏金计划总览三级体系、标签颜色、自动化架构与 55-Tool Blitz 启动计划docs/bounty-program/setup-guide.md — 管理员从零搭建标签、频道、角色、Lurkr、Secrets、流水线测试docs/bounty-program/contributor-guide.md — 贡献者参与规则认领、7 天窗口、3 个活跃认领上限docs/bounty-program/promotion-checklist.md — 工具从 unverified 晋升 verified 的完整核验清单docs/bounty-program/templates/tool-readme-template.md 与 docs/bounty-program/templates/agent-test-report-template.md —bounty:docs与bounty:test的交付物模板.github/workflows/bounty-completed.yml、.github/workflows/weekly-leaderboard.yml、scripts/bounty-tracker.ts、scripts/setup-bounty-labels.sh — 自动化链路的四份关键源码/配置tools/tests/test_credential_registry.py —bounty:code健康检查验收所依赖的回归测试。适用范围说明本文所有流程、点数、金额区间与自动化行为均以当前仓库内容为准。其中美元金额发布在 Discord 私密频道#bounty-payouts、由维护者人工执行XP 计算与排行榜则由 GitHub Actions 自动化完成。若你的仓库结构或标签体系与 Hive 不同需要相应调整标签命名与工作流配置。【免费下载链接】hiveMulti-Agent Harness for Production AI项目地址: https://gitcode.com/gh_mirrors/hive48/hive创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考