大家好，我是程序员天天困。
前天想给自己做一份「今年上半年的编码总结」，我下意识打开了 GitHub 贡献图。绿格子挺好看，可突然想起来：我 Gitee 和 GitHub 都在用，还有几份代码只推在 Gitee，根本不在 GitHub 仓库里，这张贡献图自然也就缺了那边的记录。于是我打开 Gitee 页面，才发现更扎心——两个平台上既有各自独有的项目，也有两边都在推的同一个项目；平时我会在 Gitee 推一些小项目，开源则更爱放在 GitHub，再加上自己贡献过代码的仓库，两边名单根本对不上。
作为长期两边都推的开发者，这事已经烦人很久了。正常回顾链路大概是这样：先翻 GitHub 看公开贡献，再切 Gitee 看国内仓；想核对某次深夜提交，还得分别搜 commit；私有仓更麻烦，网页默认统计经常看不见，我还得自己点进仓库列表硬数。等到真正想问「今年到底写了多少、主要用什么语言、和谁协作多」，答案散在两个站点、多个页面里，靠脑子硬拼。每复盘一次，就要在两个官网、两套贡献视图之间来回切，口径不一致、思路被切碎，效率低得离谱。
我也试过把数据甩给云端统计服务，心里过不去：PAT、私有仓提交史，我不想交给陌生后端。缺的其实不是又一张好看图表，而是一本只存在自己浏览器里的「编码档案」——打开就能聚合双平台，热力图、语言分布、协作网络、年度报告都在本地算完。这念头盘了挺久，自己从零啃又觉得工程面偏大：双平台适配、限流续传、指标口径、看板交互，哪一块糊了都不像样。
正好打算用 AI 做这个项目时，碰上 Doubao-Seed-Evolving 二次升级。我查了下定位：Coding & Agent，上下文 1024k（约 1M），适合长程工程协作。于是立刻动手，从零做出开源项目 GitUnite：纯前端、隐私优先，数据存浏览器，支持私有仓统计和 JSON/CSV 导出——原来要开两个官网才能拼出来的编码画像，收进一个本地页面。
关键功能我会截图贴上，Token 用量也摊开给大家看。下面从 0 到 1 带你看我怎么做出来的。点个收藏，咱们开始。
一、先认识一下 Doubao-Seed-Evolving，以及这次花了多少 Token
Doubao-Seed-Evolving（豆包 Seed Evolving）：火山方舟面向 Coding & Agent 场景的快速迭代模型，统一 Model ID 为 doubao-seed-evolving，持续周级升级，接入方不用跟着改版本号。能力上覆盖多模态、深度思考、GUI Agent、视觉理解等；官方文档给出的上下文窗口可达 1024k（约 1M），输出上限可达 256k（见 火山方舟模型列表）。你可以把它理解成「能扛住长仓库上下文、愿意跟你一起把工程拆完」的好搭档。
先看官方模型页怎么写的——Coding / Agent 定位、统一 ID，以及更新时间线（2026/07/14 支持 1M 超长上下文、2026/08/01 通用能力与 Coding/Agent 再升级）：
再看 2026/08/01 这次更新亮点：Coding 能力、Agent 能力、幻觉改善，以及「一个 Model ID、持续跟上新版本」的接入方式：
这些能力和我要干的活刚好对上：GitUnite 是双平台适配 + 多文件 Vue 工程，仓库级、长程迭代。这次我用 Doubao-Seed-Evolving 从 0 到 1 做完：脚手架、双平台适配器、同步引擎，一路写到看板、年鉴和导出，前后大概 1.7 万行代码（含测试和中途改需求）。
长上下文对我这种「PRD + 多文件工程」很实在：适配器差异、限流策略、看板指标可以放在同一条对话里慢慢对齐，不用每轮把半本说明书重讲一遍。当然模型给方案，落地还得自己盯 API 和隐私边界——后面细说。
那到底花了多少？直接上两张真实用量图。先看订阅侧的 Agent 燃料值（AFP）：近一周大约 3 万 / 3.5 万（约 86%），近一月同为 3 万 / 10 万——这波 GitUnite 开发，基本把一周额度顶得挺满：
再看火山方舟「模型调用明细」里 doubao-seed-evolving：调用 122 次，累计耗时约 1.14 小时；输入 Token 约 5784 万，输出约 30 万，计费合计约 5814 万。柱状图更直观——用量几乎全压在 8 月 5 日一天（接近 5000 万），6 日还有一截收尾。输入远大于输出，很符合「长上下文工程协作」：大量时间在喂仓库上下文、PRD 和改文件，不是闲聊灌水。
对中小型前端工程来说，这个量级我能接受：换来的是不用每轮重喂背景，也能在一两天里从 M1 一路推到收尾。下面先把「为什么非做不可」说透，再看成品，以及怎么一步步啃下来的。
二、为什么我非做不可：双平台程序员的真实痛点
开篇那次「两套绿格子并排」的尴尬，其实只是日常缩影。再往下拆，真正烦人的是三件事叠在一起：
- 账本是两本的：GitHub 贡献图解释不了你在 Gitee 上的国内项目；反过来也一样。两边仓库集合经常是「交集 + 各自独有」，不是简单镜像。
- 私有仓经常被漏掉：不少在线统计默认只看公开贡献，而我在私有仓库上确实花了不少时间和功夫；统计一旦漏私有仓，上半年总结的数据就不对。
- 隐私边界过不去：把 Token 和完整提交史交给陌生 SaaS，风险不小。我想要的是「本地浏览器里的编码档案」，不是再注册一个云账号。
动手前我先做了一圈市场调研，原则很简单：能复用现成轮子就别从零造。搜下来大致三类：
- 平台自带贡献图：GitHub / Gitee 各自有绿格子，合不到一张表上。
- GitHub Wrapped 类年报：年终回顾好看，主战场仍是 GitHub，Gitee 那一半账本进不来。
- 开源世界大盘分析：适合看生态趋势，不是给我个人私有仓做本地编码档案用的。
结论也清楚：单平台回顾、云端年报、宏观统计都有人做；但我要的那套——个人向、GitHub + Gitee 双平台、含私有仓、纯前端数据不出浏览器——当时没找到能直接拿来用的。所以不是「为了用 AI 硬写个 Demo」，而是调研后确认缺口还在，才动手做 GitUnite。市场以后会变，真出现更合适的开源方案，我也愿意停下来去用、去贡献，犯不着死磕重复造轮子。
GitUnite：本地跑的 GitHub + Gitee 贡献统计与编码档案工具。浏览器里用 PAT 拉仓库和提交，聚合成看板、热力图、语言分布、协作网络、年度报告和成就徽章；纯前端、隐私优先，数据落 IndexedDB。你可以把它想成「自己的开发者年鉴本」，不是又一个要上传全量数据的云看板。
IndexedDB（浏览器本地数据库）：网页在本机持久化结构化数据的能力。刷新还在，但不经过你的后端——像浏览器里的轻量小仓库。
三、成品长什么样
跑起来之后，本地页面里就是统一视图：GitHub / Gitee / 聚合三档切换，数据看板、仓库列表、提交时间轴、热力图、协作网络、年度报告、徽章墙都能打开。
如果你也想做一份自己的 Wrapped，年度编程报告就是干这个的：活跃天数、深夜占比、新学语言、commit 词云——读起来像年终总结，但数据是你自己的提交史。
四、技术取舍：为什么坚持纯前端隐私优先
选型时我有一条硬规矩：Token 和贡献明细不出本机。所以 GitUnite 是纯前端 SPA，本地 pnpm dev 就能跑；业务数据进 IndexedDB（Dexie），Token/配置进 LocalStorage，请求只打 GitHub / Gitee 官方 API。
| 方案 | 数据落点 | 适不适合我 | 备注 |
|---|---|---|---|
| 只刷 GitHub / Gitee 官网 | 平台各自页面 | 不适合双平台合账 | 两套绿格子对不齐 |
| 云端聚合 SaaS | 对方服务器 | 隐私上我不放心 | 私有仓与 Token 敏感 |
| GitUnite 本地纯前端 | 浏览器 IndexedDB | 适合个人开发者自用 | PAT 手动录入，MIT 开源 |
技术栈：Vue 3 + TypeScript + Vite，路由 / 状态用 Vue Router、Pinia、VueUse，UI 用 Naive UI + Tailwind + lucide，图表用 ECharts（含词云），本地库 Dexie，HTTP 用 axios（Token、限流、重试、ETag），导出用 Papa Parse（CSV）和 html-to-image（分享 PNG），工程侧 pnpm + vue-i18n。双平台差异收进适配器，上层只认统一的 UnifiedRepo / UnifiedCommit——看板不管你是哪家的奇葩字段。
可能有人会问：纯前端没有 OAuth，安全吗？
v1 用 Personal Access Token 手动粘贴，是因为浏览器端拿不到
client_secret，搞不了传统授权码流程。Token 只放本机存储、只走请求头Authorization，并在设置页提示：不可信设备别登。权限尽量只读——GitHub Fine-grained 先给 Contents / Metadata 只读，需要 PR/Issue 时再开对应只读权限；Gitee 先勾projects、user_info，需要时再开pull_requests、issues。细则见仓库 README。
开源地址两份，方便不同网络环境克隆：
本地启动就两行：
pnpm install
pnpm dev
浏览器打开 http://localhost:5173，去设置页粘贴两边的 PAT，校验通过就能看到头像和剩余 API 配额。
五、从 0 到 1：M1～M6 我是怎么把 GitUnite 啃下来的
这一节是干货。顺序上我很固执：先写清产品需求文档，再开写代码。调研确认要做之后，我没有直接丢一句「帮我做一个贡献统计」给模型，而是先落了一份 PRD——产品定位、非目标、统一数据模型、功能边界、同步策略写清楚，技术栈也提前定死（Vue 3 + TypeScript + Vite、Pinia、Dexie、Naive UI、ECharts 等），再按可验收产出拆成 M1～M6。
后面和 Doubao-Seed-Evolving 协作时，这份 PRD 就像同一份「合同」：模型补接口差异和实现细节，我盯口径、限流和隐私。实操流程是——我先写一版初稿，让 AI 帮着补全；补全后再自己把功能理一遍。它刚补全时往往会甩出一批「待确认」问题，这些必须人拍板，别直接糊过去。
打开文档，把待确认项逐条处理掉，定稿成完整版 PRD。之后每做完一块功能，就在文档里把对应条目划掉，标记为已实现——进度一眼能看清，也不容易漏需求。
下面按里程碑讲：解决什么问题、落地时盯什么、产出长什么样。不画架构图，每一步都配上我和 AI 对话开发时的截图。
1）M1 基础骨架：先让登录与配额跑起来
PRD 和分期表写清之后，才进 M1。做法很直接：让模型先读 PRD 里 M1 那段，严格按文档做，别自己发挥花活。
M1 的验收就一句话：能登录、能看见头像、能看见剩余 API 配额。脚手架用 Vite + Vue 3 + 严格 TypeScript；路由、Pinia、Dexie、Tailwind、Naive UI 一次就位；设置页做 PAT 录入卡片；分别打 GitHub / Gitee 的 /user 做校验；AccountCards 接到 auth store；启动时恢复登录态。
开发完先本地跑起来看一眼。页面正常就好；有报错就把日志丢给 AI 继续改。跑通之后，再让它帮你把代码推到远程仓库。
GitHub 和 Gitee 两边都推上去，M1 就算收口，可以进 M2。
2）M2 双平台仓库同步：适配器 + 同步引擎才是硬仗
M2 产出一句话：能把仓库和提交拉到本地并浏览。这里有三块硬骨头：
- 适配器：GitHub / Gitee 各自封装，对外吐统一结构。
- 仓库列表：全部 / GitHub / Gitee 三 Tab，搜索、语言筛选、排序、贡献类型标签。
- 同步引擎：并发池、限流重试、ETag 条件请求、断点续传（
SyncCursor），IndexedDB 缓存 repos / commits / cursors / repoStats。
Gitee 没有像 GitHub 那样方便的代码行聚合接口，所以首次同步要弹窗说清楚：开代码明细会逐提交打详情，又慢又容易顶限流；设置里可以关。GitHub 侧则要处理 stats/contributors 偶尔返回 202 的「先等等再来」。
限流这事真不能马虎：并发开太猛，配额直线掉。得按平台收紧并发、读响应头做退避重试，再配合剩余配额阈值等待，同步才像能过夜的任务，而不是抽奖。
增量同步也在这一阶段接线：记 lastCommitSha / lastSyncedAt，首次全量、之后按游标增量，尽量吃 ETag 少耗配额。PR/Issue 更重，放到完整同步、由用户手动触发，体感会稳很多。
按 PRD 把 M2 主体做完后，增量同步若还有尾巴，先让 AI 收干净，再衔接到 M3，别两头糊。
3）M3 核心看板：开发者数据看板真正可用
有了本地提交缓存，M3 才谈得上「编码档案」。指标都要带口径，别让看板变成玄学：
- 基础统计：仓库数（Fork 单独计）、提交数（按 SHA 去重）、增删行、平均每次变更行数。
- 活跃度：活跃天数、streak、小时与星期分布、深夜与周末占比；时间按用户时区（设置里可覆盖）。
- 语言：有字节量时按字节加权，否则按仓库主语言估算；环形图 + Top N。
- 热力图：提交频次为主，可选代码量；可切换年份。
- 时间轴：按日浏览，单日详情抽屉；message 搜索高亮；可滤 merge。
日均提交我用「总提交 / 活跃天数」，不用「注册至今的日历天数」去除，否则早期空窗会把人算得特别惨。和模型讨论指标时，得先锁口径，再让它写聚合函数，不然图好看故事是错的。
4）M4 协作网络与年度编程报告：把数据做成可讲的故事
做到这儿，对话上下文已经挺沉了。我选择新开一条对话，明确告诉模型：M1～M3 已完成，现在只做 M4——少带历史噪声，长程任务更稳。
M4 负责「有点意思，但仍然基于真实提交」：
- 协作关系图：以仓库为节点的力导向图，支持平台 / 聚合切换。「显示协作者」是可选增强——同步默认主要拉当前用户自己的 author 提交（省配额），多数时候没有协作者节点，界面也会如实提示，免得读者以为缺功能。
- 年度报告：年份选择，年度提交、行数、活跃天数、streak、活跃节奏、语言与仓库摘要、commit message 词云。
- 成就徽章：夜猫子、早起鸟、全栈探索者等，并可持久化「首次达成」时间。
说真的，徽章图别指望对话里的 AI 随手画。我更愿意用豆包这类生图模型，写好提示词做出满意的徽章，再交给编码模型做尺寸裁剪和接入——出来的效果可控得多。
5）M5 PR/Issue 与导出分享：数据能带走、能发卡片
M5 把「自己看爽」升级成「必要时能带走 / 能分享」：
- PR / Issue 创建数、合并数、Closed 未合并数；已合并 PR 的合并耗时给中位数和平均值（中位数更抗极端值）。
- JSON 导出当前筛选范围内的仓库 / 提交 / Issue 与摘要统计；CSV 分
commits.csv/repos.csv，UTF-8 BOM，Excel 打开中文不乱码。 - PNG 分享卡片（约 1200×630）：头像、昵称、提交数、语言数、活跃天、streak 峰值、Top 3 语言、累计徽章；可隐藏身份；支持下载与复制到剪贴板。
可能有人会问：分享卡片会不会把私有仓细节泄露出去？
卡片默认是聚合后的摘要指标，不是仓库列表全文。但头像和昵称仍可能暴露身份，所以界面上要有风险提示和隐藏开关。真有保密要求，就只在本地看年鉴，别导出卡片。
6）M6 打磨开源：让别人 pnpm dev 也能用
M6 是「能给别人用」的那一层：vue-i18n（简体中文 / English）、外观主题（浅色 / 深色 / 跟随系统）、单测补齐、README 与贡献指南、MIT License。GitUnite 现在已经在 GitHub / Gitee 双端开源，文档里写清 Token 权限和快速开始——这比空喊「欢迎 Star」实在。
六、和 Doubao-Seed-Evolving 协作时，我真正省力的点
回看整条实战线，模型真正帮得上忙的，不是「替我决定产品」，而是这些：
- 把 PRD 分期拆成可提交的增量，每个里程碑都有可演示产出。
- 补齐双平台 API 差异的边角：202 重试、分页、作者过滤、Gitee 明细开关文案。
- 把统计口径落成可维护的聚合代码，提醒时区、去重、停用词这类容易漏的点。
- 长上下文里持续改同一工程，少重复粘贴背景；上下文太沉就新开对话接棒。
我仍然坚持人工把关三件事：隐私边界（本地存储、只读 Token）、限流策略（并发与配额）、指标诚实（看不懂的口径宁可不做「好看假图」）。
想跟做的同学，建议很具体：先写一页痛点与非目标 → 花半天市场调研 → 确认缺口还在之后，先写清 PRD（需求边界 + 技术栈 + 分期产出），再进 M1。同步引擎没稳之前别急着美化图表；每完成一个 M，就截一张产出图存档——写这篇文时，那些图就是证据链。
如果你也卡在「GitHub 一份数据、Gitee 一份数据」的分裂感里，可以直接克隆 GitUnite 本地跑起来试。仓库在 GitHub · Rangsh/GitUnite 与 Gitee · git-unite。这次 Doubao-Seed-Evolving 实战告诉我：适合拿真实职业痛点压测；对我而言，能每天打开的本地编码档案，比十个只会聊天的 Demo 都实在。
我是程序员天天困，持续分享编程干货。觉得有用的话记得点赞收藏和关注~也欢迎在评论区聊聊：你用 Doubao-Seed-Evolving 做过什么实战，平时 GitHub 和 Gitee 两边都推吗？
