最近我在用 Orca 做开发。它的任务页接入了 Linear，查看自己的待办很方便。
但团队的需求、开发子任务和缺陷，都在飞书项目里。
于是，一件很普通的事开始占用注意力：飞书里创建一个任务，我要去 Linear 再建一次；标题改了，要记得改另一边；任务做完了，还要补一次状态。两边都能找到这件事，却需要我一直帮它们保持一致。
我想把这段重复劳动省掉。团队继续在飞书协作，我在 Orca 里看到自己的任务，开始工作前少复制一遍标题、来源和需求链接。
最后跑通的链路是：飞书项目 → 飞书多维表格 → Linear → Orca。
没有额外部署中转服务，接收事件和调用接口都放在飞书多维表格的原生工作流里。
文中的图片均为解释性示意图，根据这次实际配置和验证结果绘制，不是产品截图。
为什么我还需要这几个工具
要减少重复维护，还需要先处理好团队工具和个人工具之间的分工。
飞书项目承载着团队现有的需求流程、人员分工和缺陷管理。我只是想让自己的开发入口更顺手，并不需要让其他人一起换工具。
Linear 已经能接到 Orca 的任务页。我希望在这里查看自己的开发事项，但团队的信息来源仍然保留在飞书。
所以我先确定了一条规则：任务的标题和完成状态，以飞书项目为准，单向同步到 Linear。
这条规则确定之后，许多问题就变得具体了：什么事件需要同步，哪些字段可以覆盖，出了问题应该回到哪里查看。
这里的 Orca，承担的是查看 Linear 任务的开发入口。当前链路没有配置任务出现后自动执行开发，也没有把 Linear 的修改反向写回飞书。
多维表格，刚好可以接住中间这一段
我先尝试从飞书项目的缺陷开始。
飞书项目创建缺陷后，可以发送 Webhook；多维表格可以接收这个事件，再通过 HTTP 节点调用 Linear 的 GraphQL API。这两段能力接起来，新建的缺陷就有机会出现在 Linear 里。
多维表格还需要把两边的对应关系存下来。
假设飞书里的一条任务，第一次同步后对应 Linear 中的 POP-13。之后标题变化或者任务完成，我需要找到这同一个 Issue，而不是每次都创建新的。
表格里因此保存了来源任务 ID、所属需求、节点名称、Linear ID、来源链接，以及同步状态和最近事件时间。它也成了一个可以检查的中间台账：已经同步、请求失败、等待核对，都能落在具体的一行上。
我给任务的来源标识加上了类型，例如 空间:task:任务ID。缺陷和需求子任务各自使用独立的表与工作流，避免后续扩展混在原来的链路里。
对读者来说，这里最值得记住的是：同步要保存两边的对应关系。只把一次请求发送出去，还不足以支持后续更新。
缺陷跑通之后，我又接了需求里的开发任务
缺陷同步能工作之后，我想把平时在需求节点下面创建的开发任务也接进来。
这里需要分清楚两个层级。一个需求可能包含多个研发任务，分别由不同的人负责。我需要同步的是自己要执行的那些子任务。
因此，创建任务的事件到达之后，工作流会先校验来源，再遍历负责人名单。只有创建时负责人包含我的任务，才允许入表。
后续调用 Linear 时，Issue 也会分配给我的账号。团队里其他人的任务不会因为这条规则一起出现在我的开发待办里。
除了任务标题，我还保留了所属需求名称、节点名称和飞书链接。打开 Linear Issue 时，可以知道它从哪个需求、哪个节点过来，再回飞书查看完整上下文。
当前链接跳到所属需求详情，具体子任务可以在对应节点里找到。以后如果有稳定的子任务直达链接，再继续补这一层定位。
能创建出来之后，还要处理后续变化
创建成功之后，还需要继续验证日常修改能否同步。
同一个事件再次收到，会不会多建一条？飞书任务改名了，Linear 的标题会不会还是旧的？已经完成的任务撤销完成后，应该怎么更新？
我把这些变化分开处理。
创建时，先按来源任务 ID 查找映射，已经入表就跳过。改名时，更新已有记录的标题；状态变化时，只更新任务状态。名称和状态各自记录最近事件时间，旧事件不会再覆盖对应的新值。
出表工作流根据 Linear ID 判断下一步：没有 ID 时走创建分支，有 ID 时调用更新接口，继续修改同一个 Issue。
完成状态也做了明确映射：飞书子任务未完成对应 Todo，完成对应 Done，撤销完成后回到 Todo。删除事件则把 Linear Issue 置为 Canceled，并保留来源映射。
这次真实页面验证里，我创建了一个带 TEST 标记的子任务，它自动生成了 POP-13。随后在飞书改名，标题里还特意放了引号；点击完成任务，Linear 变为 Done；再撤销完成，它回到 Todo。
整个过程中，更新的都是同一个 Issue。
重复创建事件、非本人事件和过期状态事件，另外用合成事件做了验证。删除到 Canceled 的处理也验证过，不过使用的是合成删除事件，没有执行真实飞书任务删除。
最容易漏掉的情况：创建成功了，回写却没成功
还有一种情况，比请求直接失败更麻烦。
多维表格已经把请求发给 Linear，Linear 也可能创建了 Issue，但响应没有顺利回来，或者后续的 ID 回写失败了。
此时表格里仍然没有 Linear ID。下一次收到改名或状态事件，如果继续根据"没有 ID"决定新建，就可能再创建一条。
所以我增加了一个创建请求标记：请求发送前，先记录这条任务已经尝试创建。如果已经尝试过，却没有拿到 Linear ID，后续事件进入待核对，不再自动新建。
恢复时，先在 Linear 查找。如果已经创建，就回填对应的 ID；确认没有创建，才清除创建标记并重新触发。
联调中，我还遇到过工作流显示运行成功，HTTP 节点却返回 400 的情况。定位时先验证只读查询，再看静态请求体和节点的实际配置，最后才重新尝试建单。这次配置中，移除手动添加的 Content-Type、使用节点原生 Raw JSON 发送方式后，请求成功了。
验证时，我分别检查工作流有没有运行、接口有没有成功、Issue 有没有创建，以及 ID 有没有回写。
现在能用到哪一步
现在，我可以在飞书项目里创建自己的缺陷和需求子任务，在 Linear 和 Orca 查看对应的开发待办。需求子任务的改名、完成和回滚，也能继续更新同一个 Issue。
这套方案还保留了几个边界。
只同步创建时已经由我负责的任务。已有任务后来才分配给我，目前不会自动补建，历史任务也没有批量导入。
负责人发生变化后，已经入表的任务会暂停同步。当前平台对嵌套的负责人增删名单读取有限制，我先采用了保守处理，即使变更后仍然包含我，也需要核对后人工恢复。
排期、估分和优先级暂时没有加入，Linear 修改也不会反向覆盖飞书。跨平台请求和回写无法放进一个事务，当前的查重与创建保护也不等于并发事务锁；大量并行重放历史事件，还需要更完整的处理。
这些边界明确之后，日常使用反而更容易判断：在飞书维护任务，在 Orca 查看自己的工作，异常时回到中间表格核对。
对我来说，最实际的收益就是少维护了一份重复的任务列表。
团队沿用现有的协作方式，我也能继续使用顺手的开发入口。连接工具这件事，最后落在了每天少复制一次、少补改一次状态的具体动作上。