组织重构来得突然。几周之内，我的团队规模翻倍，职责范围从几个AWS账户扩展到多条产品线，和兄弟团队一起管理多个云服务商，支撑分布在全球的数百名工程师。

变化不全是自己能选的。Jira换成Linear——这我倒欢迎。但继承下来的协作流程，明显撑不住这个体量了。

打开网易新闻 查看精彩图片

新架构下，云运维工程师不太想让产品团队的工程师直接在Linear里建工单。怕 backlog 被淹没，也怕工单派错队——AWS？GCP？Azure？于是默认做法变成：在共享Slack频道里发一条消息，平台域的人先人工分拣，再手动去Linear建单。

流程之前已经优化过一次：加了Slack Workflow，用表单结构化请求。至少信息是规整的，但人工分拣这一步还在。

我想再进一步：自动化到极致，消灭手工劳动和噪音。

目标是一条流水线：Slack继续当入口，工程师不用碰Linear，也不用知道该找哪个团队；自动化把请求转成结构化工单，AI补充上下文；AI辅助分拣确保工单完整、标签正确、可执行；最后，规范驱动的开发让描述清楚的工单变成任何人都能认领的需求和任务。

工具组合：Slack Workflows、Linear Slack Integration、Linear MCP server，以及Kiro配两个自定义技能：Ticket Triage和Platform Support。

第一步，守住Slack这个前门。为降低团队切换成本，保留了原来的MultiCloud频道。不想一夜之间颠覆流程，而是加了几条约定来简化分流。Slack Workflow本身很简单，触发类型、动作链、表单数据操作、频道转发都能自定义。

具体改了现有workflow：加上云服务商字段，能填就填，能推断就推断——比如仓库名叫aws-terraform-modules，那提供商大概是哪个也不难猜。又加了一个workflow：用对应云服务商的表情符号，就能自动@正确团队。这让最初的人工分拣快了不少。