1. 为什么 Gitee 事件总是「推不到」AI 侧Day 3 要解决的问题很具体代码仓库里发生了 Push、PR、Issue 这些事件怎么让它们自动变成 AI 能处理的任务再把结果回传到飞书群里。听起来是一条直线实际落地时大多数人会卡在三个地方。第一个卡点是 Gitee 的 Webhook 只负责「把事件发出去」它发的是 Gitee 自己的 JSON 结构字段名、嵌套层级都是 Gitee 定义的。飞书自定义机器人要的是另一套消息格式两者对不上直接填 Webhook 地址过去飞书那边大概率报格式错误或者干脆静默丢弃。第二个卡点是 TRAE 侧要调用 Gitee API 拉 PR 列表、拉 commit 记录同时还要调飞书 API 发消息、读多维表格。这两套 API 的鉴权方式完全不同一个用 Personal Access Token一个用 tenant_access_token如果每个调用点都单独维护密钥配置会散得到处都是改一次要翻五个文件。第三个卡点是模型调用。TRAE 在处理代码事件时往往需要让模型做摘要、分类、生成回复如果模型通道的 Key 和 Gitee、飞书的凭证混在一起管理排查问题时根本分不清是哪个环节挂了。这篇要交付的就是把这三段接起来Gitee 事件 → 统一 Key 通道 → TRAE 处理 → 飞书回传。核心思路是用 TaoToken 把模型调用的 Key 和 API 通道统一收口Gitee 和飞书的凭证各管各的模型侧只认一个地址和一个 Key。这样后面不管是换模型还是加新的事件类型改动面都很小。适合谁看已经在 Day 1、Day 2 把飞书 Bot 跑起来现在要让代码仓库事件真正驱动 AI 响应的团队。如果你还没配飞书 Bot建议先回去补 Day 2否则这里的 Webhook 回传没有落点。2. TaoToken 前置把模型通道收成一个口子在整条链路里TaoToken 扮演的角色是「模型调用的统一入口」。Gitee 的 Token 管代码仓库读写飞书的 App ID/Secret 管消息和多维表格而 TRAE 里所有需要模型能力的地方——PR 摘要、Issue 分类、commit 变更说明——都走 TaoToken 这一个通道。这样做的好处很直接你不需要在 TRAE 的每个任务里分别填不同厂商的 Key也不用担心某个模型的地址变了要全局替换。config.toml 里只写一个 base_url 和一个 api_key换模型只改 model 字段。先拿到 Key。打开 TaoToken 控制台进入 API Keys 页面创建一个新 Key命名建议带上用途比如trae-gitee-bot方便后面在日志里区分是哪个任务在调用。创建后立即复制保存页面关闭后不再完整显示。拿到 Key 之后模型对话能力可以先在网页端验证一下通道是否通。打开模型对话页面随便问一句确认返回正常。这一步不是必须但能帮你排除「Key 本身有问题」这种低级故障省得后面在 TRAE 里排查半天。如果你后面要做长期的编码类任务比如让 TRAE 持续处理 PR 里的代码变更、生成 review 意见可以了解一下 Coding Plan它更适合这种高频、长周期的调用场景。Day 3 先用按量 Key 把链路跑通等稳定了再考虑套餐。接入文档在 doc 页面里面有各语言 SDK 的调用示例和参数说明。配置 config.toml 时如果对某个字段拿不准直接对照文档里的字段表比猜要快。3. 可复制配置config.toml 与 settings.json 骨架这一节给两份可直接改的配置。config.toml 管 TRAE 侧的模型通道和任务参数settings.json 管 Gitee 和飞书的凭证引用。两份文件分开的原因是模型通道的配置相对稳定而 Gitee/飞书的凭证可能因为换组织、换群而变动分开后改动互不影响。3.1 config.toml模型通道与任务定义# config.toml # TRAE 侧模型通道配置所有模型调用统一走 TaoToken [model] # 统一入口地址不要带末尾斜杠 base_url https://taotoken.net/api # 从 TaoToken 控制台 API Keys 页面创建后复制 api_key sk-你的TaoTokenKey # 按需切换PR 摘要用轻量模型即可 model gpt-4o-mini # 单次请求超时代码事件处理建议给足 timeout 60 max_retries 2 [gitee] # 从 settings.json 读取这里只声明引用名 token_ref GITEE_ACCESS_TOKEN owner your-org repo main-project # 拉取 PR 时的分页大小 per_page 20 [feishu] app_id_ref FEISHU_APP_ID app_secret_ref FEISHU_APP_SECRET chat_id_ref FEISHU_CHAT_ID [task.daily_sync] # 每日数据同步任务 enabled true schedule 0 9 * * * # 任务执行时注入的提示词模板路径 prompt_file ./prompts/daily_sync.md [task.webhook_handler] # Gitee Webhook 事件处理任务 enabled true # 监听的事件类型 events [Push Hook, Merge Request Hook, Issue Hook] # 事件转飞书消息的模板 message_template ./templates/gitee_event.json几个字段说明一下。base_url填https://taotoken.net/api不要加 UTM 参数那是给网页链接用的API 地址保持干净。api_key就是刚才创建的那串注意不要提交到 Git 仓库建议用环境变量注入或者放在.gitignore覆盖的本地文件里。model字段按任务类型选PR 摘要这种不需要太强的模型轻量的就够省钱也快。3.2 settings.json凭证引用与 Webhook 映射{ credentials: { GITEE_ACCESS_TOKEN: 你的Gitee私人令牌, FEISHU_APP_ID: cli_你的AppID, FEISHU_APP_SECRET: 你的AppSecret, FEISHU_CHAT_ID: oc_你的群聊ID }, webhook: { gitee_to_trae: { path: /webhook/gitee, secret: 你的Webhook密钥, events: { Push Hook: handle_push, Merge Request Hook: handle_pr, Issue Hook: handle_issue } }, trae_to_feishu: { path: /webhook/feishu, target_chat: oc_你的群聊ID } }, logging: { level: info, file: ./logs/trae-gitee.log } }credentials里的值建议实际部署时用环境变量覆盖settings.json 只作为本地开发的默认值。webhook.gitee_to_trae.path是 TRAE 侧暴露给 Gitee 的回调路径Gitee 那边填的 URL 就是你的服务地址/webhook/gitee。events映射把 Gitee 的事件类型对应到处理函数后面加新事件类型只改这里。3.3 Gitee Webhook 回调配置在 Gitee 仓库页面进入「管理」→「WebHooks」→「添加 WebHook」URL 填https://你的服务地址/webhook/gitee密码填 settings.json 里secret字段的值触发事件勾选 Push、Pull Request、Issue 三类。提交后 Gitee 会发一个测试请求如果 TRAE 侧服务正常日志里能看到收到事件。这里有个容易踩的坑Gitee 的 Webhook 测试请求和真实事件请求的 body 结构略有差异测试请求可能不带完整字段。所以不要只看测试通过就认为链路通了要实际推一次代码或者建一个 PR 来验证。4. 验证请求从 Gitee 事件到飞书回传配置写完接下来要验证整条链路真的能跑通。分三步先验证 TRAE 能收到 Gitee 事件再验证 TRAE 能调通模型最后验证结果能回到飞书。4.1 验证 TRAE 收到 Gitee 事件启动 TRAE 侧服务后在 Gitee 仓库里做一次真实的 Push 操作。然后看 TRAE 的日志文件tail -f ./logs/trae-gitee.log正常的话能看到类似这样的记录{ event: Push Hook, repo: your-org/main-project, commits: 2, handler: handle_push, status: received }如果日志里没有先检查 Gitee WebHook 的「最近推送记录」看 Gitee 那边是否发出了请求、返回码是多少。返回 404 说明路径不对返回 401 说明密钥不匹配返回 500 说明 TRAE 侧处理函数报错了。4.2 验证模型通道TRAE 收到事件后会调用模型生成摘要。用一个简单的 curl 验证 TaoToken 通道是否通curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的TaoTokenKey \ -H Content-Type: application/json \ -d { model: gpt-4o-mini, messages: [ {role: user, content: 用一句话总结修复了登录页面的空指针异常} ] }返回里有choices[0].message.content就说明通道正常。如果返回 401检查 Key 是否复制完整返回 404检查 base_url 是否写成了带路径的形式。4.3 验证飞书回传模型生成摘要后TRAE 会调飞书 API 把消息发到群里。这一步验证两个点消息能不能发出去格式对不对。先在飞书群里手动发一条测试消息确认 Bot 在群里且有发言权限。然后触发一次 Gitee 事件看群里是否收到消息。如果没收到检查FEISHU_CHAT_ID是否正确这个 ID 以oc_开头从群设置里能拿到。消息格式如果乱码或者字段缺失检查templates/gitee_event.json里的模板变量名是否和 TRAE 传入的数据结构对得上。常见问题是 Gitee 的 commit 消息里有换行符直接塞进 JSON 会导致解析失败需要在模板里做转义。5. 本篇常见错排查5.1 Gitee Webhook 返回 401密钥不匹配。检查 Gitee WebHook 配置里的密码字段和 settings.json 里webhook.gitee_to_trae.secret是否完全一致注意不要有多余空格。如果用的是 TRAE 内置的签名校验还要确认签名算法是否匹配。5.2 TRAE 日志显示模型调用超时先确认config.toml里的timeout是否够用代码事件处理建议给到 60 秒。如果还是超时用 4.2 的 curl 单独测一下通道排除是网络问题还是模型侧问题。TaoToken 的通道如果返回慢可以换个 model 字段试试轻量模型通常响应更快。5.3 飞书群收不到消息但日志显示发送成功大概率是FEISHU_CHAT_ID填错了。这个 ID 不是群名称是一串以oc_开头的字符串。获取方式在飞书群里点设置找到群信息里的 Chat ID。另外确认 Bot 确实在这个群里且没有被限制发言。5.4 Gitee PR 列表拉取为空检查config.toml里的owner和repo是否和实际仓库路径一致。Gitee 的 API 路径是https://gitee.com/api/v5/repos/{owner}/{repo}/pullsowner 是组织名或用户名repo 是仓库名大小写敏感。另外确认 Personal Access Token 勾选了projects和pull_requests权限。5.5 模型返回内容被截断检查max_tokens参数是否设得太小。TRAE 侧如果没显式设置可能用了默认值。在 config.toml 的[model]段加一行max_tokens 2048按实际需要调整。PR 摘要一般 512 够用commit 批量总结建议给到 2048。6. 把 Key 管好链路才稳Day 3 的链路跑通之后你会发现真正容易出问题的不是代码逻辑而是凭证管理。Gitee 的 Token、飞书的 App Secret、TaoToken 的 Key三个东西任何一个过期或者填错整条链路就断在某个环节。我的做法是把这三类凭证分开存放Gitee 和飞书的放 settings.json模型通道的放 config.toml两边都不提交到仓库用环境变量在部署时注入。这样即使某份配置文件泄露也不会一次性丢掉所有权限。另外建议在 TRAE 侧加一个简单的健康检查接口每天定时跑一次依次验证 Gitee API、TaoToken 通道、飞书消息发送三个环节。哪个环节挂了日志里一眼能看出来不用等用户反馈才发现。模型通道这块如果你后面要加更多的代码事件处理任务比如自动生成 PR review、自动分类 Issue 优先级直接复用 config.toml 里的[model]段就行不用每个任务单独配 Key。需要看更多调用示例的话接入文档里有各语言的完整代码。如果要在网页端快速验证某个模型的效果模型对话页面可以直接试。长期做编码类自动化的话Coding Plan 会比按量调用更省心。Day 3 的完成标志很简单往 Gitee 推一次代码飞书群里能收到一条带模型摘要的消息。收到这条消息就可以进 Day 4 了。