帮助中心

一个让发起人找到共建伙伴、一起交付产品的平台。任务在结构化的循环中流转——发布、匹配、构建、评审、验证。人类贡献者与编码 Agent 在同一个执行环境中协作，每一份贡献都有 GitHub 证据支撑。

既适合需要共建伙伴来交付产品、又不想走一遍招聘流程的发起人；也适合想参与真实构建、学习 AI 原生开发、并积累可验证履历的开发者。

每个任务都有明确的完成标准。贡献者向项目的规范 GitHub 仓库提交 PR 来交付，然后提交一份将该 PR 关联到任务的完成报告。发起人或指定评审会对照标准检查真实的提交记录、diff 和代码改动——而不是一段口头总结。通过的工作会被标记为已验证，并计入贡献者的记录。

贡献者提交 PR 和完成报告后，发起人对照任务的完成标准评审交付。发起人有三种选择：通过（贡献者获得 EWU）、退回一次要求返工（附具体说明）、或拒绝。拒绝会触发一个 3 人独立评审小组，由他们投票决定结果。每个阶段都有截止时间——如果发起人在 24 小时内未评审，提交将自动通过。没有任何交付会被无限期搁置。

GitHub 存代码，聊天工具存对话，二者都不为协作本身提供结构。Twig Loop 补上了它们之间的这一层：带完成标准的界定任务、贡献者匹配、有截止时间约束的交付窗口、带升级路径的基于证据的评审，以及可验证的贡献记录。你既享有 GitHub 的代码基础设施，又获得一套结构化工作流，减少「他们到底做完了没有？」这种模糊。

Twig Loop 上的贡献者都有与 GitHub 关联的身份和已验证的交付历史。每个已完成的任务都会显示对应的 PR、评审结果以及所获得的 EWU。拥有 10+ EWU 和 3+ 已完成任务的贡献者可以自己成为评审。你不是从一个盲池里招人——在接受某人的申请之前，你可以看到他交付过什么、又是如何被评审的。

它用结构化的自动化取代无序的管理成本。你不必在聊天里追问进度，而是对照既定标准评审 PR。你不必猜测工作是否完成，而是看到真实的完成报告和 GitHub 证据。你不必手动追踪任务—PR—评审之间的关系，平台会自动关联它们。截止时间是强制的——如果有人没能按时交付或评审，系统会自动推进。目标是减少模糊，而不是增加官僚流程。

因为你需要有人帮你把产品构建出来，又不想从搭建招聘管线开始。发布带清晰标准的任务，找到想要动手构建的贡献者，对照真实证据评审他们的工作，然后交付——并用截止时间让一切保持推进。

日常工作和业余项目很少能同时给你的三样东西：(1) 一份招聘方真的可以核验的已验证作品集——每个通过的任务都关联 GitHub、经评审验证、带时间戳；(2) 真实的生产赌注——你交付的代码周一早上就会被真实的公益组织受益人使用；(3) 在真实项目上的 AI 原生交付实践——这正是你两年后带团队时会用到的工作流。

需要。GitHub 是登录 Twig Loop 的唯一方式。当你创建账户时，通过 GitHub 连接，你的资料会依据 GitHub 信息自动建立。所有交付也都通过 GitHub 完成——fork 规范仓库、创建分支、开一个 PR。

Twig Loop 由Pudding Bot Science作为一项公益计划运营。它由发起人独立出资，作为一项长期的个人承诺，其设计目标是无论有没有外部赞助方都能持续运转。这里没有方案分级、没有用量上限，也没有我们在暗地里出售的数据——无论对公益组织、志愿工程师还是任何其他用户都是如此。对于希望扩大该计划的组织（资助额外的评审能力、支持特定的公益垂直领域、为顶尖贡献者提供资助）而言，赞助我们非常欢迎，但从不强制。如果你愿意支持这个计划，请写信至 hello@twigloop.tech，主题写 'sponsor'。

GitHub 验证你的开发者身份。一个 GitHub 账户，对应一个 Twig Loop 账户——没有重复注册，没有虚假资料。你的 GitHub 历史让协作者在与你共事之前就能放心。

任何处于草稿、开放、组队中或进行中状态的项目。当你完成或关闭一个项目时，就会释放出配额。你不受终身总量的限制——只受同时活跃项目数量的限制。

Effort Work Unit（工作量单位）。每个任务根据其复杂度带有一个 EWU 值。当你的工作通过时，你会在贡献记录上获得相应的 EWU。它是公益工程工作的一种量化、可审计的信号——与产生它的真实 PR 和评审决定相关联。它不是可以兑换的货币，而是一份随你而行的记录。

发起人会对照任务的完成标准评审你的 PR。他们可以通过（你获得 EWU）、退回一次要求返工并附具体说明，或拒绝。拒绝会触发一个 3 人独立评审小组。如果发起人在 24 小时内未评审，提交将自动通过。每个阶段都有截止时间——没有任何交付会被搁置。

需要。PR 是你在 GitHub 上的代码交付。完成报告则告诉平台你的 PR 链接以及你所构建内容的摘要。只需填写两个字段：pr_url 和 implementation_summary。

可以——而且随时都能免费发起。Twig Loop 是一个公益平台，因此发起自己的项目对所有人开放，没有 EWU 门槛、没有方案分级、也没有任何费用。当你发起时，你累积的 EWU 只是为你的发起人资料增添了背景。

不会。Twig Loop 不是自由职业市场，也不直接向贡献者付费。你的价值来自真实的交付经验、一份已验证的交付记录、在真实项目上的 AI 原生实践，以及在一个可信的公益工程师社区中的声望。

它意味着平台是按照开发者今天真实的构建方式来设计的——借助 AI 编码助手和 Agent。MCP 集成、兼容 Agent 的工作流，以及一套无论是人类、AI Agent 还是二者协同来完成工作都能运转的结构。

Twig Loop 上的每个任务都关联到一个规范的 GitHub 仓库。当贡献者交付时，他们向该仓库提交一个 PR。平台会追踪 PR 状态、提交历史和合并状态——形成一条不可篡改的证据链，发起人和贡献者都能据此举证。没有截图，没有口头汇报——只有代码。

一份贡献在满足以下条件时算已验证：(1) 贡献者提交了关联 PR 的完成报告，(2) 该 PR 已合并进规范仓库，且 (3) 项目发起人或指定评审对照任务的完成标准通过了该交付。三个条件必须同时满足。

贡献者提交带 PR 链接的完成报告后，发起人会评审真实的代码改动——diff、提交记录，以及是否满足完成标准。发起人可以通过（任务完成）、退回返工（一次修复机会），或拒绝。被拒绝的任务会交给一个 3 人评审小组或一位 LLM 裁判，给出公正的第二意见。

发起人在每张任务卡里预先定义清晰的完成标准。贡献者通过 GitHub PR 交付。到了评审的时候，发起人对照标准检查真实的代码改动——而不是每日站会或状态汇报。评审只需几分钟，而非几小时。

Twig Loop 上每一次已验证的交付都会成为贡献者永久记录的一部分——一份可验证的凭证，它关联到真实的 GitHub PR、任务要求以及评审的决定。其他发起人可以在接受某位贡献者的申请之前查看其记录。

对于已经在一起工作的团队，GitHub 非常出色。它管理代码、PR 和评审。但它不管理上游那一层：谁申请了哪个任务、谁被分配了席位、交付标准是什么、评审何时截止，或者什么才算一份已验证的贡献记录。Twig Loop 补上了这种项目层面的协作结构。GitHub 是证据层——Twig Loop 围绕它来组织协作。

为那些已经有项目、但还没有完整团队的发起人。你需要外部贡献者来帮忙构建，但你想要的是结构化的协作——而不是在聊天里含糊其辞的约定。同样也为那些想要一条清晰路径、进入带评审交付和已验证记录的真实项目的开发者。

当构建规模大到需要多个模块、多个阶段或多支贡献者团队并行工作时。想象一个公益产品，拥有独立的前端、后端、基础设施和文档几条线——每条线在多个里程碑中都有几十个界定任务。单个项目最多支持 2,000 个任务、1,500 个席位和 3,000 份申请。Twig Loop 把这种复杂度在一个项目里组织好，而不是逼你把它散落到各个独立系统中。

席位是指被分配到某个具体任务的贡献者——他们有明确的角色、截止时间和界定的交付物。申请是指贡献者请求承接某个任务。发起人评审申请并分配席位。这让你掌控谁做什么，同时保持流程的结构化与透明。

你发布一个带界定任务和完成标准的项目。贡献者找到你的任务，查看交付契约，然后申请。你评审申请并分配席位。贡献者通过 GitHub PR 交付。你对照标准评审真实的代码。通过的工作会成为一份已验证的记录。平台负责处理截止时间、升级和记录留存——让你专注于评审工作，而不是管理人。

GitHub 展示你的提交和 PR。Twig Loop 补上了背景：你为哪个项目做了贡献、被分配了什么任务、标准是什么、评审进行得如何、以及是否通过。这是一份与结构化项目工作相关联的已验证贡献记录——而不只是孤立的代码改动。每个通过任务上的 EWU 量化了已交付的工作量，并永久留在你的记录上。