# 运营好一个活动


这页写给活动已经运行或即将发布的 Developer。它帮你做四件事：用小预算试出合适的奖励，把动态接到 Slack，读懂质量与速度的数字，判断什么时候调整价格。搭建工作流和通过发布检查是前一步，见[测试、发布与运行状态](/zh/tasks/launch)。

## 先用小预算试出合适的奖励

合适的奖励，是仍能吸引到目标 Contributor、交回的工作能通过、速度也够用的最低金额。找到它的办法是先跑一小批，读结果，每次只改一项设置。

四项设置决定一批试跑最多花多少钱：

| 设置 | 在哪里设 | 控制什么 |
| --- | --- | --- |
| **Budget cap (USD)**（预算上限（美元）） | 草稿 **Test & Launch**（试跑与上线）中的 **Pricing & Budget**（定价与预算）步骤 | 活动最多能花的钱。发布时预留整笔金额，发布后只能调高 |
| **Reward (per accepted submission)**（奖励（每条通过的提交）） | Builder 中人工步骤的 **Cost**（成本）部分 | 一条通过的提交的基础奖励 |
| **Items to collect**（采集条数） | 同一部分 | 这个步骤总共为多少条通过的提交付费，所有 Contributor 合计。它同时限制可以领取的工作量 |
| **Limit per contributor**（单个贡献者上限） | 同一步骤的 **Settings**（设置）部分 | 一位 Contributor 最多提交多少：**Per day**（每天）、**In total**（累计）或 **No limit**（不限） |

预算可以很小。门户对金额没有下限，有奖励的活动只需要预算大于零。**Pricing & Budget** 也接受低于预计支出的上限。这时页面会提示：这笔预算能覆盖的条数可能少于预估，预算用完后活动自动暂停。上限怎样预留和调高，见[预算、费用与对账](/zh/collaboration/billing#活动预算设置与增加)；**Items to collect** 的名额怎样计算，见[配置工作流](/zh/tasks/workflow#supply人工工作)。

你填写的奖励，是声誉等级的奖励系数为 1.0× 时的金额。Contributor 看到的报价可以按其所在等级的系数缩放，范围是 0.5× 到 1.4×。所以 **Pricing & Budget** 显示的是一个预估范围。举例说明：奖励为 0.50 USDC、**Items to collect** 为 100 时，奖励支出在 25 到 70 美元之间。适用平台服务费时，费用另加在奖励之上。各等级的系数见[等级如何影响任务报价](/zh/learning/reputation#等级如何影响任务报价)。

一轮试跑这样做：

1. 用较小的 **Budget cap (USD)** 和较小的 **Items to collect** 发布。
2. 等这一批至少产生十条审核决定。少于十条时，门户只显示条数，暂无通过率。
3. 按[读懂质量与速度](#读懂质量与速度)读结果。
4. 只改一项设置。改哪一项，参考[什么时候调整价格](#什么时候调整价格)。
5. 跑下一批，和上一批对比。

某一批的质量和速度都达标后再放量。在 Builder 调高 **Items to collect**，在 **Setup**（配置）的 **Budget & costs**（预算与成本）中调高预算。

> **计划中：分成产品。** Humanbased 计划在 2027 年第一季度推出分成产品，目的是给 Contributor 更强的激励，并降低 Developer 前期的数据成本。目前尚未提供。

## 运行中调整奖励

奖励属于人工步骤，所以要在 Builder 里改。打开活动，选择 **Open builder**（打开构建器）。打开人工步骤，修改 **Reward (per accepted submission)**。先保存步骤，再保存画布。

活动运行中或已暂停时，你在确认框选择 **Save and apply**（保存并应用），这次修改就立即发布。从确认到 Contributor 看到新奖励之间没有测试环节，保存前先读[确认弹窗会改变什么](/zh/tasks/define#保存)。

对报价来说，分界线是任务被领取的那一刻：

| 任务 | 报价 |
| --- | --- |
| 保存之后才领取 | 按新奖励报价 |
| 保存时已经被领取 | 保持领取时的报价。那次报价已经固定了当时的奖励和 Contributor 的等级系数 |

所以无论奖励调高还是调低，已经在手的工作仍按原报价结算。

**Items to collect** 和 **Limit per contributor** 是同一步骤的设置。在运行中的活动上修改它们，走的是同一次画布保存。

## 把动态接到 Slack

连接频道后，这个活动的事件会在发生时发到频道里。暂停、预算用完或有提交等待审核时，团队无需打开门户就能知道。

### 连接频道

活动所属组织的任何成员都可以连接频道。

1. 打开活动，选择 **Setup**，进入 **Notifications**（通知）。这里有 **Slack**（Slack 连接面板）。
2. 选择 **Add to Slack**（添加到 Slack）。Slack 会打开授权页面。
3. 选择接收动态的频道，并同意授权。
4. Slack 把你带回这个活动。再次打开 **Setup** 的 **Notifications**，**Slack** 面板会列出这个频道。

组织已经连接过频道时，面板还会显示 **Connect an existing channel**（连接已有频道）。它把这个活动挂到已有频道上，无需重新授权。要停止推送，在频道那一行选择 **Disconnect**（断开连接）。

### 选择推送内容

事件分为两组：

| 分组 | 事件 |
| --- | --- |
| **Alerts**（告警） | 活动发布、发布被撤回、暂停、被系统暂停。预算消耗达到 50%、80%、95%，消耗回到阈值以下，以及预算用完。提交等待审核超过 24 小时。Contributor 提出申诉 |
| **Activity**（动态） | 收到新提交、提交通过、提交被驳回。活动恢复运行、结束、归档 |

新连接默认包含两组事件，并在事件发生时逐条发送。要调整，在频道那一行选择 **Edit**（编辑）。顶部的两个勾选框 `alert` 和 `activity` 用来开关整组事件。**Event types**（事件类型）用来开关单个事件。**Frequency**（频率）为每组选择 **As it happens**（实时）、**Hourly summary**（每小时汇总）或 **Daily summary**（每日汇总）。提交量大的活动，让 **Alerts** 保持实时，把 **Activity** 改为汇总。

### 在 Slack 里通过或驳回

需要人来决定的提交会以卡片形式出现。卡片带有 **Approve**（通过）和 **Reject**（驳回）按钮，以及 **View submission**（查看提交）链接。使用按钮前，先把你自己的 Slack 用户和门户账户关联一次：

1. 在 Developer 门户左下角的菜单打开 **Account**（账户）。
2. 在 **Slack** 一行选择 **Connect Slack**（连接 Slack）。门户显示 **Your Slack link code**（你的 Slack 绑定码）。
3. 10 分钟内，在 Slack 中执行 `/link-account`，后面跟上这串绑定码。

**Approve** 记录决定。**Reject** 会打开一个填写理由的对话框，Contributor 能看到你写的理由。决定记在你的门户账户名下。如果 Slack 用户尚未关联，或你的账户无权决定这条提交，Slack 会私下提示你，提交保持原样。

### Slack 没有消息时

| 你看到什么 | 这说明什么 | 现在做什么 |
| --- | --- | --- |
| 频道那一行出现 **Unreachable**（无法送达） | 最近一次推送失败，连接可能已在 Slack 中被撤销 | 选择 **Disconnect**，再用 **Add to Slack** 重新连接 |
| 选择 **Add to Slack** 后，面板显示 “Slack authorization did not open, so nothing was connected. Allow popups for this site and try again.” | 门户没能发起授权 | 再试一次。仍然出现时，带上 Campaign ID 写信到 [hello@humanbased.ai](mailto:hello@humanbased.ai) |
| 在 Slack 同意授权后，**Slack** 面板仍显示 “No channel connected. This campaign's updates stay in the portal.” | 授权没有完成：被拒绝、没有选定频道，或超过 10 分钟才同意 | 重新选择 **Add to Slack**，选好频道并同意授权 |
| **Account** 的 **Slack** 一行显示 “Locked — create or join an organization to connect a Slack workspace.” | 你的账户还没有加入任何组织 | 创建或加入一个组织，再回到 **Account** |
| Slack 回复 “Link your Slack account in the developer portal, then try again.” | 你的 Slack 用户还没有关联门户账户 | 按上面的三步完成关联 |

## 读懂质量与速度

活动有四个视图：**Overview**（概览）、**Reviews**（审核）、**People**（成员）和 **Setup**。每跑完一批，值得看的是这些数字：

| 数字 | 在哪里 | 告诉你什么 |
| --- | --- | --- |
| **Submission acceptance · All decisions**（提交通过率 · 全部裁定） | **Overview** 的 **Output**（产出）面板 | 已有审核决定的提交中，通过的占多少 |
| 已通过的记录数，显示为 “of N records accepted” | **Overview** 的 **Output** 面板 | 活动已经产出多少完成的记录 |
| 最近几小时通过的条数，以及按此速度做完剩余部分所需的时间 | **Overview** 上方的状态行 | 当前的速度 |
| 排队中的任务分配、已领取的任务、待审核的提交 | **Overview** 的 **Workflow**（工作流）面板 | 工作是在等 Contributor 领取、正在进行，还是在等你审核 |
| 等待审核的提交数，以及最久的等待时间 | **Overview** 的 **Needs your attention**（需要你处理）面板 | 你自己的审核是否拖慢了活动 |
| 每个步骤的提交总数，以及其中待审核、已通过、已驳回、重复各多少 | **Reviews** 的 **Task submissions**（任务提交记录）区块 | 哪个步骤在流失工作 |
| 单个 Contributor 的 **Campaign acceptance**（本活动通过率） | **Reviews** 的 **Acceptance history**（通过率历史）列，以及 **People** 的 **Success**（通过率）列 | 驳回是分散的，还是集中在少数人 |
| 常见耗时，显示为 “Typical … · Median” | **Reviews** 的 **Volume & time**（提交量与耗时）列 | 该步骤从领取到提交的中位时间，其中包含休息和等待 |
| 名单上的 Contributor 数，以及其中多少人已经提交 | **People** 名单上方的一行 | 加入的人有没有开始工作 |
| **Available for new work**（可用于新工作） | **Overview** 的 **Budget & obligations**（预算与义务）面板 | 扣除已经承诺的款项后还剩多少预算。预算消耗达到 80% 起，活动顶部的提示条会写明剩余金额 |

### 跟踪通过率

通过率的算法是：通过 ÷（通过 + 驳回 + 重复）。重复也算一次审核决定，等待审核的提交未计入。审核决定少于十条时，门户显示 **Too few to rate**（样本过少），暂无百分比。活动列表的每张卡片也会显示这个比率，取整数百分比。

这个数字覆盖发布以来的全部审核决定，所以新的一批只会让它缓慢变化。想看清某次修改的效果，要按批对比：

1. 修改设置前，打开 **Reviews**，记下 **Task submissions** 中已通过、已驳回和重复的条数。
2. 下一批结束后，再读一次这三个数。
3. 用后一次减去前一次。新增的通过数除以新增的审核决定数，就是这一批自己的通过率。

**计划提供**。计划提供活动运行状况视图，用图表显示提交量、工作流健康状况和通过率随时间的变化。在它可用之前，请使用上面的比较办法。

### 驳回偏高时

调价之前，先找原因：

1. 在 **Reviews** 的 **Task submissions** 中，找出驳回或重复最多的步骤。
2. 用 **Review**（审核）打开几条被驳回的提交。**Review outcome**（审核结果）显示结论和记录的理由。
3. 在 **People** 中，对比各 Contributor 的 **Rejected**（已驳回）和 **Success** 两列。

| 你发现什么 | 通常说明什么 | 改什么 |
| --- | --- | --- |
| 驳回分散在很多 Contributor 身上 | 说明或表单写得不清楚 | 在 **Setup** 的 **Campaign details**（活动详情）中重写说明，或在 Builder 修改表单。见[定义工作与参与要求](/zh/tasks/define) |
| 驳回集中在少数 Contributor 身上 | 问题出在这些账户，任务本身没有问题 | 活动 owner 可以在该 Contributor 那一行选择 **Blacklist**（封禁）。被封禁的人会被移出这个活动，之后无法再参加、领取或提交；已经领取的工作仍可以交回，之后可以用 **Lift ban**（解除封禁）撤销。也可以用 **Limit per contributor** 限制每个人的提交量 |
| 理由指向技能或知识不足 | 活动放进了准备不足的人 | 收紧参与条件，见[调整谁可以参加](#调整谁可以参加) |
| 理由指向赶工或敷衍，而说明是清楚的 | 奖励不足以支持认真完成 | 见[什么时候调整价格](#什么时候调整价格) |

## 调整谁可以参加

由谁来做这份工作，取决于参与条件。它们在 Builder 的 **Entry Gate**（准入门）步骤里：

| 条件 | 作用 |
| --- | --- |
| 必签协议、必修课程和资料条件 | 只放进已签署、已通过或资料匹配的 Contributor。资料条件也可以在 **Setup** 的 **Requirements**（参与要求）中修改 |
| **Require an invite code to join**（参加须凭邀请码） | 只有出示这个活动邀请码的人才能参加。邀请码由你生成并分发 |
| **Only members of selected teams can join**（仅所选团队的成员可加入） | 只有你选定的 Contributor 团队的成员才能参加。Contributor 团队尚未在正式环境的 Contributor 门户开放，在那里打开这个开关后没有人能加入；见[功能开放情况](/zh/help/updates) |

想扩大人群，就去掉或放宽一项条件；想收窄，就加上一项。活动运行中修改 Entry Gate，同样是一次画布保存，立即生效；邀请码的生成、更换和撤销无需保存就立即生效。各项条件怎样配置，见[配置工作流](/zh/tasks/workflow#entry-gate参与条件)；Contributor 一侧看到什么，见[任务准入条件](/zh/learning/eligibility)。

## 什么时候调整价格

先排除说明和参与条件的问题，再动奖励。每次只调一小步，这样每一批都能给你一个明确的信号。

### 奖励偏低的信号

| 你观察到什么 | 通常说明什么 | 改什么 |
| --- | --- | --- |
| **People** 里的 Contributor 很少，**Overview** 的 **Workflow** 面板中排队的任务分配一直很多 | 符合条件的人里，愿意为这个奖励参加的很少 | 把 **Reward (per accepted submission)** 调高一档。参与条件比工作需要的更严时，放宽条件 |
| 已有 Contributor 加入，但 **People** 名单上方显示提交过的人很少 | 奖励抵不上完成一个任务所花的时间 | 对照 **Reviews** 里的常见耗时。调高奖励，或缩短表单 |
| 做事的人并非你想要的人群。在 **People** 打开 **Submitted**（已提交）最多的几位，**Standing**（信誉状况）显示各自的等级和奖励系数 | 按这个价格，目标人群选择放弃，接手的是其他人 | 调高奖励，或用课程、资料条件或邀请码限制参与 |
| **Overview** 中的提交通过率下降，**Task submissions** 中已驳回的条数上升，而说明没有改动 | 认真的 Contributor 在离开，或者大家为了凑够收入而赶工 | 先读被驳回提交的 **Review outcome**。确认是赶工后，调高奖励 |

### 奖励高于所需的信号

| 你观察到什么 | 通常说明什么 | 改什么 |
| --- | --- | --- |
| 任务分配一出现就被领走，状态行显示剩余部分的完成时间早于你的需要，提交通过率保持稳定 | 你付的钱超过了这份工作所需 | 把奖励调低一档。新金额用于保存之后领取的任务 |
| 预算消耗比计划快：预算告警来得早，**Available for new work** 的下降快于通过数的增长 | 做事的是等级较高的 Contributor，每条通过的提交最高按奖励的 1.4× 支付 | 质量值得这个价格时，保留奖励并调高预算。否则调低奖励 |
| **People** 中少数几位 Contributor 占了大部分 **Submitted**，**Task submissions** 中重复的条数上升 | 奖励高到足以吸引只求数量的提交 | 把 **Limit per contributor** 设为 **Per day** 或 **In total**，再调低奖励 |

这些数字背后的单条记录，见[查看提交结果并处理反馈](/zh/tasks/results#developer-查看审核结果)。活动已经花了多少，见[预算、费用与对账](/zh/collaboration/billing#核对一项活动的资金)。