Slack里报bug，GitHub上出修复
在Slack里用大白话说清一个bug。Okou会写好GitHub issue并指派负责人；如果原因集中在某一个组件上，它还会提一个带修复和回归测试的pull request，交给你审阅。
Okou交付的成果：从一条Slack消息到一份待评审的修复
这是Okou团队#bug-report频道里的真实会话，按发生顺序原样记录。一位同事贴上客户的反馈，顺口要了个修复。4分钟后，Okou提交了带诊断结论的GitHub issue。从第一条消息算起14分钟，它开好了PR并发出预览链接。下面是两张截图：起点的那条会话，以及Okou写的PR。它们都是公开的，你可以自己去看issue、代码差异和评审记录。
会话里发生了什么
一位同事在#bug-report里反馈了客户遇到的PWA布局问题，并附上截图。Okou读完会话，定位到顶栏渲染时没有计入iOS安全区域内边距，随后提交了issue #11708，带上标签和判断依据。会话里提出要修复后，Okou只改了一个文件（给移动端顶栏加上最小高度和安全区域内边距），开出PR #11709并附上预览链接，然后就停在这里。评审和合并由人完成。
- 从消息到建单
- 4分钟issue #11708，标签为bug和PWA
- 从消息到PR
- 14分钟PR #11709，附预览链接
- 修复改动的文件数
- 1由人合并，不是Okou
在Slack里创建GitHub issue，到底是怎么回事？
在Slack里创建GitHub issue，意思是把有人在对话中描述的bug，直接变成仓库里一条结构清晰的issue，而不用任何人退出会话去重新敲一遍。难的从来不是调用API，而是写出一个说得清的标题、把复现步骤和预期行为分开、选标签、定优先级、找到对的负责人。这些事由Okou来做：它读你的Slack消息和前后的回复，写出issue正文，打上标签、给出讲得通的优先级，把Slack昵称对应到GitHub账号来确定负责人，最后把issue链接发回同一条会话，报告人扫一眼就能核对。
为什么bug反馈总是死在Slack会话里
有人在演示时发现了一个bug，或者客户周六来信反馈。老路子很长：打开GitHub，找到仓库，按格式写一条issue，指派给人，然后等这个人接手、读代码、写修复。一个十分钟的改动，变成三个人、好几天的来回，而且有一半的反馈根本没走出那条会话。换个做法：你在Slack里把问题说清楚。Okou建好issue，附上复现步骤、标签和负责人；如果原因范围有限，它会接着提一个带修复和测试的pull request。你审阅，然后发布。
Okou如何从Slack创建GitHub issue
第一步：连接你的工具
第二步：交给Okou
第三步：再往前一步
这套工作流背后的Slack与GitHub集成
这是一套中间放了智能体的Slack与GitHub集成：Okou在Slack里读对话，在GitHub里写记录。每个连接器都单独授权，权限范围只覆盖这套工作流真正用到的部分，所以读取一个频道，绝不等于拿到你仓库的写权限。
Slack集成：Okou读的那段对话
必需Okou会读你指给它的那条消息，以及前后的回复，所以晚三条才补上的信息同样会进到issue里。它会带上随消息附来的截图，读取报告人的昵称来确定负责人，并保留消息永久链接，让每条issue都能回到反馈的起点。它只写一件事：在同一条会话里回复issue编号和链接。Okou不会发到别的频道、不会发私信，也不会改动任何人的消息。
GitHub集成：Okou提交的那条issue
必需Okou在你指定的仓库里创建issue：标题是根据反馈重新写过的，而不是照抄原消息；正文包含描述、复现步骤和预期行为，会话里提到受影响范围时也会写上。它会用你指定的标签，或根据措辞推断标签，给出并解释优先级，再指派负责人。提交之前，它会先在未关闭的issue里搜同样的现象，找到匹配就改为在原issue下评论。当它还能顺手修掉这个bug时，会推一个分支，开一条关联关闭该issue并请求评审的PR。写权限只限于你授权的仓库，范围也仅此而已：issue、评论，以及提交评审的PR。Okou不会合并、不会强制推送，也不会碰仓库设置。
Okou、Slack里的GitHub应用、自动化搭建工具，三者的差别
把一个bug从Slack消息搬进GitHub，其实有三步：接住反馈、写出一条能用的issue、把它送到负责人手上。现有方案各自只解决其中一步。
Slack里的GitHub应用
输入/github会弹出一个表单，标题、正文、标签、负责人还是你自己填。它省下了切到浏览器的功夫，但写issue的人依然是你；而对话进行到一半冒出来的表单，正是让人说出「我待会儿再提」的那点阻力。
自动化搭建工具
无代码工具可以在触发器命中时，把一条Slack消息复制成一条新issue。它复制的是原始消息，所以报告人当时怎么打字，issue就长成什么样；而标签、优先级、指派和查重的规则，要你自己逐个频道定义并长期维护。
Okou的Slack到GitHub工作流
Okou读完会话再动手写issue：一个像样的标题，复现步骤与预期行为分开，标签和讲得通的优先级，以及根据报告人昵称匹配到的负责人。当原因收敛在单个组件里时，它会继续往下做，开出带修复和回归测试的PR，关联到issue，等你评审。提交前它会先查未关闭的issue，遇到重复就改成在原issue下评论，然后在会话里回复链接。
让效果更好的几个建议
常见问题
怎么从一条Slack消息创建GitHub issue？
把Slack和GitHub连到Okou，然后在频道里描述这个bug并Okou。它会读这条消息和周围的回复，写出带标题、复现步骤、预期行为、标签和优先级的issue，在你指定的仓库里创建，指派负责人，再在会话里回复issue编号和链接。你不用填任何表单。
这和Slack里的GitHub应用有什么区别？
GitHub应用给你的是一个待填的表单：标题、正文、标签、负责人还是你写。Okou直接从对话里写出这些内容，提交前会查有没有相同现象的issue，而且可以按计划扫描整个频道，而不是一次只处理一条消息。
Okou只是建单，还是能把bug直接修掉？
两者都可以，而且它会告诉你这次做了哪一种、为什么。issue一定会提交。当会话或代码都指向同一个组件、预期行为没有歧义、并且能先写出一个会失败的测试时，它还会开出带修复和该测试的PR，关联到issue并请求评审。涉及公共工具函数、设计token，或者需要产品决策的，它只建单不改动。Okou从不合并；每一个修复都以PR的形式交到你手上评审。
Okou能自动把issue指派给对的人吗？
可以。Okou会拿你提到的名字，或报告人的Slack昵称，去匹配仓库里的GitHub账号，然后指派。在消息里直接写出负责人是最稳的方式；没人被点名时，Okou会指派给会话所指向那块区域的负责人，并在issue里说明它是怎么判断的。
Okou怎么避免提交重复的GitHub issue？
动手之前，Okou会按相同的现象、受影响范围和措辞搜索未关闭的issue。找到匹配时，它会把这条新的Slack会话连同报告人和时间点作为评论追加到原issue上，并在Slack里回复已有issue的链接，而不是再开一条。
如果bug反馈里没写复现步骤，会怎么样？
Okou照样提交issue，避免这条反馈丢失，同时打上需要补复现步骤的标签，并在Slack会话里向报告人追问。补充上来的答案，就落在那条已经和issue互相关联的会话里。
Okou能定时扫描整个频道来建单吗？
可以。把一个或多个频道指给Okou，再给它一个时间安排，比如每周五下午4点。它会读这一周的消息，为每条描述缺陷的消息提交issue，在重复的issue下评论，跳过功能需求和提问，最后汇报它做了什么。
不用GitHub，换成Linear或Jira可以吗？
只要是Okou连上的跟踪工具，工作流的形态都一样；本页讲的是GitHub这条路径，用的是GitHub连接器。Linear的连接方式相同，你在指令里点名要用哪个工具就行。
下一个bug，不用离开Slack就能建单
连上Slack和GitHub，像跟同事说话那样把bug讲清楚，写issue和指派交给Okou。原因收敛的时候，PR也会一并等着你。
