1. 数据统计
数据统计这块使用了飞书多维表格的工作流功能，实现的功能主要有用户 Issue、PR 实时在飞书群内通知、发版消息通知等。 工作流的触发器会给一个 webhook 触发的地址
这里直接在项目中配置了不同的 webhook 来监听对应的事件触发。
当记录生成后，可以通过配置 bot 自动化来做群消息发送提示。
消息卡片效果展示：
2. llmstxt
最初看到尤大大的一条 X 推文在分享这个技术：llmstxt
其主要作用就是生成协助 ai 理解的文本，ai 可以通过文本更快的理解网页内容，使用的优势主要有：
| 优势 | 描述解释 |
|---|---|
| 去除噪声，聚焦核心内容 | HTML 里包含大量标签、脚本、样式、广告代码等，直接用 AI 理解这些会干扰内容提取。纯文本把这些都剔除，只留下真正的文字内容，AI 更容易专注理解。 |
| 输入更简洁，降低复杂度 | 纯文本数据相比 HTML 结构更轻量，模型处理时计算成本更低，响应更快，尤其在有限上下文长度的情况下，能让模型利用更多实际内容。 |
| 跨平台和跨格式兼容 | 纯文本格式统一，不用考虑不同网页的标签差异，方便把多源网页内容合并或做统一处理。 |
| 便于下游自然语言处理任务 | 纯文本适合做摘要、问答、情感分析等 NLP 任务，减少了对复杂 HTML 结构的额外解析需求。 |
| 简单且稳定的预处理 | 提取文本的流程相对成熟、简单，避免了 HTML 解析时可能遇到的结构异常或标签错乱问题。 |
| 提升模型理解效 | 纯文本形式更接近模型训练时见过的自然语言数据分布，有助模型更准确地理解语义。 |
而 FlowGramAI 的文档在年中调研结果和平日里 oncall 反馈中一直不断有用户反映文档学习成本较高。
之前也接入了Cognition Labs 推出的 AI 工具 DeepWiki deepwiki.com/bytedance/f… llmstxt 是有助于协助用户理解文档的。
由于我们的官网是基于 rspress 构建的，因此最终我们决定采用 @rspress/plugin-llms 插件来实现这个效果。并且最终在 rspress 同学的帮助下合入了改动：github.com/bytedance/f…
最终效果：
体验官网：FlowDocument - FlowGram.AI 在每个静态页面顶部，都会有一个对应的跳转链接，我们默认内置了 gpt 和 claude 的跳转，通过内置的 md 文件输出协助 ai 理解。
由于存在一定的延迟，gpt 偶尔可能会获取不到 md 文件，这时候点击「复制 Markdown」即可直接复制内容，贴给 gpt 也可以直接理解。
3. 自动翻译机器人
目前 FlowGramAI 的国际使用量并不高。
目前我们的 README 和 PR 都由内部同学控制 default in English，但是 issue 都是由外部同学提的，所以很难去规范化，如果手动更改为英文，一方面工作量比较大，另一方面也不利于提出 issue 的同学回看问题。
3.1 社区方案
其实社区已经有一个现成的方案，github.com/dromara/iss… Github Action 来实现
name: 'issue-translator'
on:
issue_comment:
types: [created]
issues:
types: [opened]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: usthe/issues-translate-action@v2.7
with:
BOT_GITHUB_TOKEN: ${{ secrets.BOT_GITHUB_TOKEN }}
# Required, input your bot github token
BOT_LOGIN_NAME: Issues-translate-bot
# Not required, suggest not input, action will get name from BOT_GITHUB_TOKEN
# If input, BOT name must match github token
通过评论的形式来引用原文，并且翻译，如果目标语言已经是英文，则不翻译。
效果如下图：
但是使用社区方案会存在一些问题
- 标题翻译
在 issue-translator 中，更改标题的属性IS_MODIFY_TITLE如果被设置成 true，需要将 @Issue-translate-bot 拉到对应的项目中，并且赋予 admin 权限。
a. 赋予 admin 权限会需要花时间等待对方接受（现在这个项目就还有好几个很久以前的 open 的 issue 在等待官方同学审批）
b. 给第三方 bot 账号添加 admin 权限也不安全。bytedance 组织本身为了安全起见，也不允许有其他的账号作为 admin。
- 功能限制
社区方案中的 translator 功能上有一些限制。它只能满足翻译标题和通过评论的方式来翻译。 并且它只监听了 issues.opened 和 issue_comment.created 两个事件，当用户的 issue 在创建后再手动编辑更新，评论内的机器人的回复依旧是老的回复信息，并不会同步更新。
这里就打算自己动手写一个 Github App，来实现这个自动翻译的功能。
3.2 Github App 开发
smee.io/ 官方教程 sample 仓库：github.com/github/gith…
跟着官方教程一步步开发配置，可以得到一个 Github App，效果是提交一个 PR 后，添加一段指定内容的评论。 主要就是通过 smee.io 建立一个 webhook，打到本地进行代码调试。 smee.io 是 GitHub 官方提供的一个 Webhook 代理服务，通过执行如下命令： npx smee -u 「这里放 smee.io 的 webhook 链接」 -t http://localhost:3000/api/webhook 这样 GitHub webhook 的请求就能安全地从公网转发到你本地。
这里贴一下我这边自己实现的项目地址：github.com/dragooncjw/…
本地配置需要着重关注三个属性：
APP_ID - 创建 Github App 的时候需要携带的应用 ID
WEBHOOK_SECRET - Github App 创建 secrets 的时候会让你手动输入一个 webhook secret，如果忘记可以重新生成。
PRIVATE_KEY_PATH - Github App 对应生成的私有密钥
在本地 .env 下设置完成后，可以运行 npm run server 来运行本地测试脚本。
本地测试脚本监听了 issue 被打开和 issue 被创建的时机，并且会变更标题以及更新内容。正式版本的代码在 api/webhook.js 路径下，可以监听内容更新并且实时翻译。详细可见项目 README：GitHub - dragooncjw/translator-bot
3.3 线上部署
如果要投入正式使用，那就需要有一个线上环境部署 App。线上部署工具我挑选了 vercel，使用默认的 serverless function 可以很方便的部署 webhook。同时每个月有 100G 的 cdn 加速额度。调用 google translator api 的速度会相比较于本地调用大大提升。 整个配置过程比较简单，不过相比较于本地调试的代码需要做一些变更。
自动翻译 bot 邀请链接：github.com/apps/flowgr… 通过邀请链接可以直接接入目前我已经部署的 Github App（flowgram-translator-bot[bot]），如果想要 bot 自定义命名可以自行部署。
当然，由于 google 翻译效果比较一般，所以还是会存在一些 bad case，这种场景就需要手动调整一下中文，使回复的内容稍微官方正式一些。
此外， 基于 Github App 还有很多不同的功能可以持续探索，比如基于大模型搜索，集成 context7 mcp Context7 - Up-to-date documentation for LLMs and AI code editors 或者 deepwiki mcp deepwiki.com/bytedance/f… 来进行 issue 的第一步 ai 自动回复等。我们也将持续优化 flowgram.ai 基建，力求获得更好的社区体验。
