# Humanbased 如何运作


Humanbased 将需要数据的人与能够采集、标注或核查数据的人连接起来。Developer（开发者）定义工作和质量要求，Contributor（贡献者）运用自己的知识完成工作，再由各自的记录跟踪验收、交付与收入。

Developer 是业务身份，不要求每个人都编写程序。任务负责人、课程作者、组织协作者和数据使用者都可能使用 Developer 端。

## 把活动理解为共同工作的项目

如果你熟悉 GitHub，可以把活动理解为一个协作项目：它把说明、参与者、工作和结果放在一起。这个比喻帮助解释协作；具体权限、参与条件和验收仍按 Humanbased 的规则执行。

你不需要了解 GitHub 才能参与。先分清三个对象：

| 对象 | 它表示什么 | 你要核对什么 |
| --- | --- | --- |
| 活动 | 围绕同一数据需求组织的工作与规则 | 要做什么、谁能参与、怎样验收 |
| Task | 这次实际领取或进入的具体工作 | 输入材料、操作要求和当前领取状态 |
| Submission | 交出工作后形成的记录 | 保存了什么、审核到哪一步 |

完整关系见[核心概念](/zh/start/concepts)。

## 从需求到结果

以一项虚构的图片分类工作，说明两端怎样围绕统一标准协作：

1. **说明需要什么。** Developer 准备图片、分类标准与边界情况，明确预期答案。
2. **准备工作方式。** 配置人工步骤、回答字段、参与要求和质量检查，让完成工作的人与审核的人使用同一套标准。
3. **完成工作。** 符合条件的 Contributor 领取 Task，按说明提交类别与所需材料。
4. **查看审核结果。** 根据活动配置的检查和验收方式处理 Submission，参与者查看记录与反馈。
5. **核对数据与收入。** Developer 检查交付及访问权限；Contributor 在 Earnings 查看实际收入。

每一步都有自己的记录。任务被接受、数据可以读取和奖励已经付款，需要分别确认。

## 用数据结果改进下一次工作

Developer 取回有权使用的数据后，按原来的需求检查准确性与覆盖范围。例如，图片已按任务标准验收，却发现“包装反光”缺少清楚的分类规则。下一轮可以修改说明、例子、表单或验收标准，再单独测试和发布。验收通过说明这次配置的检查已经完成，不证明模型效果自然提高；已有数据满足需求时，先按访问授权和实际记录继续使用。

## 选择你的起点

- **希望参与工作：** [参与第一项工作](/zh/start/contributor-start)，从选择活动到确认提交记录。
- **需要组织新的数据工作：** [从数据需求开始](/zh/start/developer-start)，了解组织、任务配置与发布。
- **只需要已有数据：** [获取已有数据](/zh/start/data-start)，先确认内容、来源与访问条件，无需为了取数先创建活动。
- **需要程序接入：** [API 参考](/zh/api)，核对凭证、订阅、请求与返回内容。

课程、资格与声誉帮助解释准备情况和参与条件。只处理目标工作要求的项目，在相应页面核对具体结果。声誉反映已记录的工作表现；要求的课程结果和身份验证需要分别完成。验收、交付和付款各有自己的状态与记录。