工作会从门户、Slack或Telegram中的用户,从您自己的系统和助手,以及从Coroid自身的自动化流程中进入Coroid。在门户中由人员提交的新任务就是其中的一种途径。所有这些途径最终都会汇聚到同一条执行路径上——需求说明、计划、构建、验证、审核、拉取请求。
| 途径 | 适用场景 |
|---|---|
| 新任务 | 有人有需求并希望描述清楚 |
| 导入工单 | 该请求已存在于Jira、Linear、Trello或GitHub Issues中 |
| 询问Coroid | 您更倾向于通过对话方式描述需求 |
| Slack或Telegram | 有人在聊天中提出相关需求 |
| 工作接收API | 其他系统会提交该请求,例如产品中的功能请求表单 |
| 事件自动化 | GitHub、Slack、Telegram或Jira中的某些内容需要转化为工作任务 |
| Coroid MCP | Hermes、Codex或Claude Code等助手或智能体负责管理工作任务 |
| 日程安排 | 触发条件是时间 |
| 钩子 | 触发条件是平台事件 |
| 报告与发现结果 | 报告或质量检查发现了需要修复的问题 |
请求
新任务
有人描述需求
导入工单
从追踪工具导入
通过 API 接收需求
您的产品或代理
事件自动化
一条 pull request、评论或消息
资格审核
系统会对请求进行筛选、去重并验证,随后确定处理路径。未经通过者不会生成任何内容。
转化形式
- 任务
- 计划
- 报告
- 日程
任选其一,或保持“创建”为自动模式,由 Qualification 自行决定。
任务与计划:规格说明、计划、构建、验证、评审、pull request
审核通过后即可路由
来自新任务的请求或导入的请求不会一收到就直接创建。它们会先经过资格审核环节。Coroid会筛查其中是否包含敏感信息,将其与当前发布版本对比,查找重复项,验证其可行性并确定最终形态。只有通过审核的内容才会被创建。详见描述您的需求。
来自工作接收API的请求也会经过该环节,事件自动化发送到资格审核的事件同样如此。
它最终会转化为以下四种途径之一:
| 途径 | 产出物 |
|---|---|
| 任务 | 单个任务,最终生成一个pull request |
| 计划 | 一份分阶段制定的计划,在编写代码前需经你审批。 |
| 报告 | 生成的报告 |
| 自动化 | 按预定时间或触发条件执行的工作。 |
在“新任务”表单中,你可以自行选择流程路径,也可保持默认设置。自动随后交由Qualification判定。若你选定的路径与Qualification推荐的路径不一致,你会看到相关建议并自行决策。
Ask Coroid的运行方式有所不同。在其Assistant模式下,聊天助手可直接创建任务和计划,无需经过Qualification环节。Prepare Work聊天模式属于引导式SDLC工作流,会在规划启动前将获批的规格说明发送至Qualification审核。详见聊天助手。
其他流程可直接创建工作,无需经过Qualification环节,具体启动规则由各自设置决定。对于MCP服务器而言,这些规则即为其审批和自动化策略。
工作启动时
无人会在门户中等待来自工作受理API的请求或事件自动化触发。Qualification审核通过后,Coroid会在几分钟内启动相关工作。任务是否会自动启动取决于请求来源:
| 来源 | 自动启动 |
|---|---|
| 设置为自动启动已获批工作的服务账号 | 是 |
| 具备代码库写入权限的GitHub pull request或议题创建者 | 是 |
| 提及Coroid的GitHub评论,仅限有写入权限的用户发布的内容 | 是 |
| 其他任何服务账号 | 否 |
| Slack、Telegram、Jira及其他任何来源 | 否 |
不会自动启动的任务需等待人工触发。Qualification会将此类请求标记为待启动状态,并附上任务链接。计划永远不会自动启动:它们始终需经审批。定时任务会在审核阶段等待相关人员确定运行时间。
Coroid会按照以下列表顺序指定工作负责人:提交请求或设置自动化的人员、服务账号创建者、项目创建者以及组织所有者。
未指定项目的请求会归入组织的唯一项目中。若存在多个项目,该请求会在Qualification环节等待审核,由审核人接收时选定对应项目。
任务是还是计划?
实用的判断标准是是否便于评审。如果最终成果是同事一次就能读完的一个 pull request,那就是任务。如果需要按明确顺序进行多次修改,或者你希望在开始构建之前先审批方案,那就是计划。
拿不准时,凡涉及重要工作优先选计划。计划在代码编写前就提供审批节点,此时修改成本最低。若任务规模超出预期,则会因空间不足无法继续。
已导入的工作
从追踪器导入的问题会经过相同的资格审核流程。重复问题、已修复的问题以及无法验证的请求会在该环节被拦截,其余则转化为任务或计划。待办事项列表本质上是一份愿望清单,因此这一筛选机制对导入内容而言比在其他场景下更为重要。详见导入工作。
来自您自身的系统
其他系统可通过工作受理API提交请求:例如您产品内的功能请求表单,或是用于传递客户需求的支持工具。
API需要配置服务账号,该功能包含在专业版和企业版套餐中。可在下方创建该账号:设置 → 服务账号。其API密钥需具备以下权限:intake:write。该密钥仅在创建时显示一次,禁用服务账号会导致其所有密钥失效。
将每条请求发送至API网关,并将密钥作为Bearer令牌传入:
curl -X POST https://api.coroid.ai/api/v1/organizations/work/intake \
-H "Authorization: Bearer ak_…" \
-H "Content-Type: application/json" \
-d '{"title": "Export invoices as CSV", "content": "Customers want to download their invoices as CSV from the billing page."}'| 字段 | 必填 | 描述 |
|---|---|---|
title | 是 | 简短名称,最多500个字符 |
content | 是 | 请求内容,最多20,000个字符 |
projectId | 否 | 该工作所属的项目 |
workType | 否 | task、plan、report或schedule |
signal | 否 | 请求来源的错误、警报或问题,具体描述如下 |
若未指定工作类型,资格审核流程将自动选择对应路径。资格审核会对每条API请求执行且无法跳过。
若请求来自监控或其他自动化源,需描述其信号特征。Coroid会据此识别不同项目中重复提交的同一事件,并起草任务的成果约定。
signal字段 | 必填 | 描述 |
|---|---|---|
fingerprint | 是 | 该事件的稳定标识,例如错误追踪器中的问题编号 |
source | 否 | 信号来源,例如glitchtip或sentry |
routes | 否 | 受该事件影响的路由数量,最多50条 |
minExposure | 否 | 在判定结果前,需处理这些路由上的多少请求? |
url | 否 | 该事件的链接 |
与routes和minExposure有了它们,合约才具备可衡量性:该事件必须保持静默。没有它们的话,合约会记录下无法衡量这一情况。强制要求可以拒绝启动无法衡量的工作。
来自服务账号的合格任务会等待有人启动它。所有者或管理员可以在「服务账号」板块下通过以下设置更改该账户的此项配置:自动启动合格任务仅当该账户提交的所有内容均来自你信任的人员时,才开启此功能。详见工作启动时间。
GitHub、Slack、Telegram和Jira中的事件也可转化为请求,无需人工重新输入。事件自动化会将它们发送至资格审核环节。详见触发器与目标。
来自你的助手
你运行的助手或智能体,比如Hermes、Codex或Claude Code,可通过其MCP服务器与Coroid协作。它能读取你的项目和工作内容,并在你授予的权限范围内创建、运行并交付工作。它创建的工作无需经过资格审核环节。详见Coroid作为MCP服务器。
自动录入
日程安排和钩子可在无人干预的情况下开启工作,二者的区别仅在于触发条件:时间或特定事件的发生。两者均属于自动化流程,它们列在工厂中,且在「新任务」板块创建。
质量检查也会催生修复类工作。当质量策略对报告进行审核时发现产品存在问题,Coroid会为其开启修复任务。Factory → 审核会列出无对应任务的测试失败项。修复可将其转为修复任务。
所有这些都会占用真实的智能体资源与模型算力。给自动化工作的优先级应低于他人正在等待的工作——详见容量与智能体资源。