合并的PR，直接变成发布文案
Okou读完你这周合并的pull request，挑出面向用户的那些，写成更新日志文章，等你确认草稿之后，在同一次运行里发到你的博客、Resend邮件列表和X。
Okou交付什么：文章、邮件和长推
这是一份真实的Okou产品更新，2026年7月20日发布在okou.ai上，这里原样呈现当时发出的样子：博客文章、同一份更新做成的邮件通讯，以及X上的长推。三者都来自同一次运行，素材是这一周合并的pull request。
什么是更新日志自动化？
更新日志自动化，是用团队真正合并的工作来生成产品更新，而不是到周末凭印象去写。Okou就是中间那个智能体：它读取GitHub里已合并的pull request，留下面向用户的部分，归成主题，写出更新日志文章，并在一次运行里发布到你的博客、Resend邮件通讯和X长推。结果是一份按时发出的每周产品更新，而且每个渠道说的都是同一件事。
每周更新日志为什么会吃掉一个周五
周五下午。这一周合并了三十多个pull request，总得有人把它们变成一篇别人真愿意读的更新。你扫一遍合并列表，猜哪些改动是面向用户的，写成文章，为邮件砍一版，再为X砍一版，然后把每个版本分别粘到不同的工具里。同样的内容读了三遍，而最后发到X上的那一版，和进了收件箱的那一版，说法往往还对不上。
Okou如何把一周的合并变成一篇发布出去的更新日志
第一步：连接你的工具
第二步：交给Okou
第三步：再往前一步
更新日志自动化用到的GitHub、Resend、X和Slack集成
这条工作流从一个工具读，往三个地方写。上线了什么，只以GitHub为准；Resend和X是发布目的地；Slack是草稿等人确认的地方。每个连接器都单独授权，权限范围只覆盖工作流真正用到的部分，所以读取你仓库的权限，不会顺带变成用你的账号发帖的权限。
GitHub集成：Okou读什么来写更新日志
必需Okou会查询你设定的窗口内合并进你指定仓库的pull request，并逐个读取标题、正文、标签、合并时间、作者和改动的文件路径。区分面向用户的改动和内部重构，靠的就是这五个信号：release-note标签最有说服力，改动路径能捞出没人打标签的那些，正文则补上标题没说清的细节。这条工作流里的GitHub集成是只读的。Okou不建issue、不推送提交、也不改动pull request。指给它多个仓库，它会在同一轮里全部读完，前后端分仓也照样只出一篇更新日志。
Resend集成：Okou发出的邮件通讯
必需Okou会读取你的Resend受众，这样你用名字而不是ID指定其中一个就行，然后创建并发送这封邮件：标题、预览文字、HTML正文和纯文本版本。发完之后它会把结果读回来，报告有多少封送达、延迟和退信，所以报告和实际发送不会对不上。发送权限和受众读取权限是分开授权的，Okou不会添加、删除或导出任何联系人。
X集成：Okou发出的长推
必需长推是专门为X写的，不是把博客文章截短：每个主题一帖，开头一帖交代改了什么，结尾一帖链回完整文章。Okou会把每一帖作为上一帖的回复发出，长推才连得起来；发之前它先检查长度，不会让某一帖被截断。写入权限只限于你连接的那个账号，它也只做发长推这一件事。Okou不会读你的时间线、提及和私信。
Slack集成：草稿等待确认的地方
可选Slack是可选的，它的价值体现在确认这一步。Okou会把完整草稿发到你指定的频道，包括博客正文、邮件标题和长推里的每一帖，然后停下来。没人回复确认，就什么都不会发布；你也可以在同一条会话里要求重写，当场拿到更新后的草稿。不用Slack，这条工作流照样能跑完，草稿会回到你发起这次运行的地方。
Okou、手写更新日志与更新日志生成器的对比
更新日志自动化其实是两个问题：决定什么值得公告，以及把公告送到每一个渠道。大多数工具只解决其中一个。
手写
有人读完合并列表，判断哪些重要，写成文章，再为邮件和X各改写一遍。判断到位，文案也贴合品牌，但每周都要搭进同样的90分钟，一忙起来第一个被砍掉的就是它。
更新日志生成器
它会自动把提交或pull request的标题汇总成一页发布说明。一个合并都不会漏，但它发出来的是标题而不是主题，分不清重构和新功能，而且只能发到一个地方。
Okou的更新日志工作流
Okou读的是同一批合并，套用你定义的「面向用户」规则，把留下的归成主题，再按渠道写文案。博客、Resend和X在一次运行里从同一份已确认的草稿发出，运行结束还会说明它押后了什么、为什么。
让效果更好的几个建议
常见问题
怎么用GitHub的pull request自动生成更新日志？
把GitHub连到Okou，再给它一个定时任务或者一个发版触发器。Okou会读取窗口内合并的pull request，用你定义的「面向用户」规则筛一遍，把留下的归成主题，写出更新日志文章。再接上Resend和X，同一次运行就会把它发到这些渠道。
Okou怎么判断哪些合并是面向用户的？
按你给它的规则，作用在四个信号上：release-note标签、改动的文件路径、pull request标题和正文。标签是最强的信号，也是多数团队统一采用的做法。被Okou排除掉的内容都会带着理由列在运行报告里，判断错了你看得见，而不是悄无声息。
同一份草稿能同时发到邮件通讯和X吗？
可以。Okou先把主题写一遍，再按渠道改写：博客发完整版，邮件按收件箱长度写，带标题和预览文字，长推则一个主题一帖。三者在同一次运行里从同一份已确认的草稿发出，各渠道的事实不会跑偏。
会有内容不经我确认就发出去吗？
除非你主动要求，否则不会。默认流程是把草稿发到频道里等着。你可以确认、在同一条会话里要求重写，也可以直接放弃。如果你希望它无人值守地发布，在提示词里说明，Okou就会跳过确认这一步。
这套更新日志自动化需要哪些工具？
GitHub是必需的，它是「上线了什么」的来源。Resend和X是两个发布目的地，也必须接上。Slack可选，只用在确认这一步；不接的话，草稿会回到你发起这次运行的地方。
这条工作流需要哪些权限？
GitHub需要你要发布内容的那些仓库的读取权限。Resend需要发送权限和受众读取权限。X需要发长推那个账号的写入权限。如果你用Slack，它需要能在确认频道里发消息。每个连接器都在Okou里单独授权，撤销其中一个不影响其他。
Okou能把多个仓库合成一篇更新日志吗？
可以。在提示词里写上每一个仓库，Okou会在同一轮里全部读完，再按改动带来的行为变化归类，而不是按它们来自哪个仓库。前后端分仓，照样只出一篇文章。
能不能按发版标签触发，而不是每周定时跑？
可以。建一个自动化，在GitHub上打出发版标签时启动这条工作流。Okou会按这次发版包含的pull request来生成更新日志，而不是按时间区间，其余步骤完全一样。
发布本周更新日志
连接GitHub、Resend和X，用每周那条提示词跑一遍完整流程：扫描、归类、起草、审批、发布。
