悬赏经济：将闲置成员转化为有偿、可追踪的贡献者

1. 为什么悬赏比“谁想帮忙？”更有效

志愿者呼吁通常只会得到一次性响应。成员帮助一次，感觉良好，然后又回到潜水状态——因为没有记录、没有奖励、没有后续。悬赏将相同的请求转化为一个公开的、有价格的、有状态的合约：标题、奖励、所有者、状态和服务器中任何人都可以看到的历史记录。

定价是关键。一项文档任务的20欧元悬赏表明这项工作具有真正的价值。那些从不志愿帮忙的成员也会响应有价格的工作，因为有价格的工作消除了他们的努力是否会被认可的模糊性。

2. 生命周期：四个命令，五种状态

Sovereign 将悬赏实现为一个严格的状态机：OPEN → IN_PROGRESS → REVIEW → PAID，并为废弃的帖子提供明确的 CLOSED 路径。任何拥有关联身份的用户都可以使用 /bounty create <Title> | <Amount>（最低5 EUR，以分为单位存储）创建悬赏，使用 /bounty list 浏览开放的悬赏，使用 /bounty claim <ID> 领取悬赏，并使用 /bounty done <ID> 提交完成的工作。

状态机为您完成了审核工作。一个悬赏不能被领取两次，创建者不能领取自己的帖子，并且只有被分配的工作人员才能提交。每次状态转换都会通知正确的人：当悬赏被领取时，创建者会收到私信；当工作提交时，创建者会再次收到私信；提交的工作会进入 Dashboard Exchange 等待批准。

资金只有在 Dashboard 中明确批准后才会发放。这在关键环节——信任——保持了人工干预，而在其他所有环节都实现了自动化。

// Command routing and the guard clauses that make the state machine safe
switch (action) {
  case 'create': return await createBounty(tenantId, member.id, args);   // -> OPEN
  case 'list':   return { reply: await listBounties(tenantId) };         // 5 latest OPEN
  case 'claim':  return await claimBounty(tenantId, member.id, args);    // OPEN -> IN_PROGRESS
  case 'done':   return await completeBounty(tenantId, member.id, args); // IN_PROGRESS -> REVIEW
}

// Guards enforced inside the transition functions:
// - status must match the expected state or the command is rejected
// - creatorId !== workerId   (no self-claims)
// - only the assigned workerId may call /bounty done
// Funds are released after owner approval: Dashboard > Exchange (REVIEW -> PAID)

3. 调整悬赏以建立留存，而不仅仅是产出

有效的悬赏是小型的、具体的，并且可以在一个晚上完成。一个每周发布三个或更多新悬赏的社区，会给成员一个持续检查服务器的理由：开放的工作是一个定期更新的回归理由，这正是留存工程师试图制造的行为。

复合效应是为那些能让社区运行得更好的事情发布悬赏：入职脚本、文档、剪辑制作、审核覆盖、活动物流。每个完成的悬赏都是一项永久性资产，而不是一次性交付物。