Idea 的萌生

先说说为什么要开发鸿蒙版 GitHub。

今年 8 月底的时候，网易云音乐宣布要上架纯血鸿蒙平台。对于这个动作，我当时有一个判断：鸿蒙应该是真的要做成了。如果说微信上架鸿蒙意味着鸿蒙迈过了生死线的话，那么网易云音乐上架鸿蒙意味着鸿蒙迈过了由弱转强的临界线。

网易云音乐作为一个大厂的拳头产品，并不是什么随便的阿猫阿狗小众 APP，它的动作具有极强的表态作用；但同时，它也不是微信、支付宝这种中国互联网的基础设施，需要讲政治出发。

众所周知，网易云音乐对鸿蒙的适配一开始并不积极，我们并不清楚一开始为什么那么不积极，可能是它打心眼里认为鸿蒙做不成，也可能是不想吃前期开发者工具链的摩擦税，也可能是网易内部在忙着反腐，没有招聘足够的人手，但无论如何，在 2026 年 8 月底，网易下定决心要上架鸿蒙了，这应该是一个大厂从纯粹的商业利益出发，最后发现不得不做的决定。

而且在这个时间当口，AI 编程也变得非常成熟，无论是国产模型 / Coding Agent 还是 AI 编程的方法论。这使得利用 AI 去解决跨平台适配，这种属于软件工程中的偶然复杂度问题成为了可能。于是我就在想，要不要自己开发一个鸿蒙版的 GitHub？ 不追求像素级的复刻，但追求体验级的复刻。这样就可以不用折腾出境易和卓易通了。

开发过程

搭好初始架子

我把 Android 平台的 GitHub 官方 APP 最常用的一些页面以及交互方式截图发给 Agent，让它使用多模态大模型进行识别，搭好基础架子，做成一个能启动的 APP。这个过程当中，截图了大概十几个页面吧，Home 页、Inbox 页、Explore 页、个人主页、仓库主页等等，相当于使用 BFS 的思路遍历了一下整个 APP 的主干功能。这一步写出来的 APP，在页面功能上做到了一定程度的复刻，但是 UI 极丑，icon 基本都是自绘的，而且很多页面，同样的组件并没有抽出为公共库，而是重复建设，样式并不统一。

确立设计规范

这一步最关键的是，你要主动去想，去思考有没有这么个东西？ GitHub 作为开源软件领域的基础设施，它的设计规范深刻影响了整个行业。如果你是 GitHub 移动端的重度用户，那么当你尝试复刻的时候，也一定会想这些图标都叫什么，会不会有原始的 SVG 素材？而一旦想到了这一步，接下来只要随便找一个 AI 问一句：

GitHub 有没有官方的设计规范，对图标、字号、颜色、交互进行了要求？

就能得到肯定的回答：GitHub 确实有这个东西，它叫 Primer Design System，并且提供了大量的 Octicons，这些东西都是开源的，基于 MIT 协议。

于是，我引入了官方的 Octicons，替换掉此前由多模态大模型根据截图逆向搞出来的组件和图标。

这一步搞定以后，在 UI 界面上就已经十分接近官方了。只不过痛苦的地方在于，很多 icon 不知道叫什么，需要去 Octicons 页面上肉眼挨个比对。不过常见的基本上都能很快找到。

到这儿，这个产品的最小 MVP 就已经成型了。但那个时候的我并不想做一个这么简陋的东西，而且这个时候投入的精力也不是很多，大概也就是跨度 10 天的下班以及周末时间而已。

App 命名和 Logo 设计

一开始命名是 StarRaft，Star 不说了，Raft 取自 Raft 协议，说白了纯粹为了逼格硬塞到一起。现在回头看起来，感觉十分晦涩难懂。后来更名为 ArkCat，首先，Ark 是很明显的鸿蒙元素，鸿蒙的 UI 叫 ArkUI，鸿蒙开发的语言叫 ArkTS。而 GitHub 平台的吉祥物是一只猫，猫在程序员群体中有着极高的接受度。于是就将其命名为 ArkCat 了。我自认为这是一个很好的命名，哪怕后面应用市场上架审核的时候比较狗血。

至于 Logo 设计，当名字确定了以后，Logo 的思路也很明显了：就是想办法将 ark 和 cat 这两个意象在一个 logo 里面体现出来。

一开始我的思路是搜索一些船的 logo，再搜索一些猫的 logo，然后将其进行拼接。对于一个没有什么设计经验的程序员而言，这个过程是极其痛苦的。

后来在尝试了 Figma 以及其他的设计软件以后，最终决定放弃，并选择了最土、最笨，但事实证明也是最好的手段：豆包抽卡。

告诉豆包，我要设计一个正方形的 App Logo，里面要有猫和船的元素。一只猫头在船的上面，尽可能多地去生成，找一些比较好的能看的进行保留，然后在这个基础之上进行微调。

最终得到的 Logo 是这样的：

对此我十分满意。

功能与 Spec 的规划

2026 年下半年，使用 AI 编程进行严谨的开发项目，是不可避免地要使用 SDD 的。那么问题来了，Spec 这些东西要怎么写？我虽然是一个重度的 GitHub 客户端用户，但是也不敢说对这个软件产品的功能了如指掌。我可以使用最土最笨的办法，将常见的交互页面进行截图，然后让多模态大模型进行逆向。但是更多更细的长尾功能肯定不能这样去搞。那这种情况下，思路是什么呢？

我们重新回顾一下目标：我们要做的是在鸿蒙平台最大程度复刻一个 GitHub 客户端，而不是自己从头设计整个产品。那么这种情况下，可以充分地借力：

让 AI 爬取 GitHub 这款 APP 在 Google Play 和 App Store 上从发布至今的全部 Release Notes。Release Notes 获取到以后，删除所有的 bug fix 记录，只保留功能的新增点。这样就得到了在时间轴上单向的整个 APP 的功能演化过程。在这个基础之上，让 AI 针对功能的演化过程，帮我设计规划所有的 Spec，并捋清楚不同功能之间的依赖关系，并确定好后面主干功能的开发顺序。

而在后面针对每一个具体的 spec 进行开发的时候，先让 AI 告诉我涉及到哪些页面、哪些交互点，然后我在 Android 版 App 上进入相应的页面截图，再把交互细节发送给 Agent。

这样做，虽然还是免不了针对截图进行逆向，但是整个功能开发的节奏却是明确的，总比自己像没头苍蝇一样一个页面一个页面去分析、去总结功能点要好。

这个环节当中，充分使用了LoopX这个框架，进行长程任务的执行，充分实现了睡后作业、睡醒检查验收。

妥协和审核

放弃 Copilot

GitHub APP 官方版第四个 Tab 是 Copilot，但是 Copilot 使用的 AI 要么是 OpenAI，要么是 Anthropic 提供的模型，而这两个无论如何在中国大陆是无法完成大模型算法备案的。于是我把第四个 Tab 改成了 Me，即我的主页。不过官方版自己的 App 也是在 2026 年 4 月（如果没记错的话）才推出 Copilot 页，这个功能上线的时间并不算长，所以这个战略放弃应该说还可以接受，相当于对齐的是一个较为落后的 GitHub 官方版本。

初次上架驳回

1.0.0 版本，向华为应用市场提审以后被驳回了，理由之一是 应用存在社区功能，具备舆论属性，需要提交安全评估报告以及相关的资质证明。

问题是，GitHub 在国内没有任何一个实体，黑名单关键词、先审后发、违法信息处置、用户实名认证，这些一个都做不到。个人申请这个安全评估报告相当于告诉网警：我做了一个 GitHub 直连、可向境外社区发内容的客户端，是舆论属性信息服务的参与入口，并且我个人完全没有能力对任何信息进行管控。显然，拿到这个安全评估报告审核通过的概率为 0。

安全评估那套法规的立法本质，不是“社区功能要审批”，而是属地管辖下的内容管控核验：国家要求任何一条“公众内容发布通道”背后，站着一个可追责、可配合处置的境内主体——能删帖、能交日志、能落实先审后发。评估表上的每一项，问的都是同一句话：“出了违法内容，找你，你管得住吗？”

我调研了一些已在鸿蒙平台上架的其他 GitHub 第三方客户端，几乎无一例外都是只保留了读功能，写功能极少，有的话，几乎也就只是一个 Merge Pull Request 而已。这对于整个 APP 的功能完整性而言，是大幅阉割的。

除此之外，还有一个巨他妈扯淡的理由，在这里我要好好讲讲：

这个 ARKcat 我在华为应用市场里面搜索了，压根没有。和华为应用市场的服务人员加了微信以后，做了进一步沟通，了解到大概意思是，GitHub 上有一个叫 ARKcat 的项目。

华为应用市场的审核团队认为：这个项目是一个知名的开源项目（对此我表示？？？），我的 APP 名字是 ArkCat，和人家这个项目的名字非常相近，虽然大小写不同，但是容易引起混淆。所以我需要人家的授权。

1. 我上架的是华为应用市场，而这个 ARKcat 在华为应用市场上完全没有存在，为什么要因为 GitHub 上的一个东西而卡我呢？言外之意，GitHub 成了一个注册平台，先行者可以抢注是吗？

2. 这个应用我大概看了一下，它是一个文本的分类器，而我的 App 是一个独立的 GitHub 第三方客户端，领域完全不相同，一点不相干。

3. 这个项目一共就 4 个 star，4 个 star 就有脸说是知名的开源项目了吗？

4. 这个项目我看 commit 记录已经差不多 9 年没有更新维护了，可以说它约等于已经死了，然而居然成了拒绝我的应用过审的理由之一。

而为了应对这个问题，我唯一可行的解决办法就是修改应用名字。

对我来说，因为这样的理由让我被迫修改应用名字，我不服气；而做一个只有读功能、写功能大幅阉割的 GitHub 客户端，毫无价值。

那既然到这地步了，这个项目后面就决定永久延迟上架计划，作为鸿蒙开发的习作开源。当然了，如果有需要 .hap 包的话，我也可以提供。

收获和感想

ArkCat 是我继 DAG-chat 和 Headroom 之后，第三个比较大的活。项目收获有这么几点吧：

1. 更进一步了解了做产品的生命周期。 首先 App 名字和 Logo 的设计就花了好大的精力，要知道程序员写代码的时候给变量命名都十分难受，更何况是搞 logo 设计。

   然后是备案，国内开发需要 ICP 备案，和公安部备案。当然在这里要给浙江的管局点个赞，速度很快，效率很高。

   至于应用市场的审核，虽然鸿蒙的审核确实有点狗，但是后来了解了一番，iOS 和 Google Play 也没好哪去，各有各的槽点。如果非要说对程序员而言，哪个体验更好的话，那还是 Android 开发：只要打个 .apk 的包丢到 GitHub Releases 上去，显然是最舒服的。

2. SDD 的落地实践。 在进行大任务开发的过程中，Spec 与实际代码出现漂移是一个难免的事情。在古法编程阶段，产品需求 PRD、技术文档和实际的代码实现存在不一致也是常见的事情，SDD 本身就是为了让 AI 更好地看产品需求 PRD 和技术文档，而演化出来的一种工程实践。所以，我认为 Spec 与实现产生漂移，并不是 AI 编程就可以解决的。只不过在古法编程阶段，代码和文档是分离的；而在 AI 编程中，Spec 已经被视为代码仓库的一部分，这个问题被拿到台面上，不可回避而已。那既然会产生漂移，那解决办法也很简单，治理就完了。我的经验是：AGENTS.md 的约束，以及 agent 本身的 memory，不足以完全在每次 session 结束以后，保证代码与 spec 能保持高度一致。所以我自己的实践思路是：按照 Commit 数量、开发时间跨度以及版本迭代规律，设三个复查触发条件——比如主干分支每 20 个 Commit、高强度编程时每两周左右、每一个大版本发布之前——到点就进行一次深度 code review，找出代码与 spec 偏移的位置，并确定以哪边为准、改哪一边。

3. 再说一个暴论：在 AI 编程时代，Coding、Code Review 这些工作占比在逐渐下降，因为都交给 AI 去做了。那么程序员要干嘛呢？我认为其中工作重点之一就是对 Spec 的漂移治理，这个观点在 X 上讨论得不多，但是我认为再有一两个季度可能会逐渐成为工程实践的显学。 实际上，当你把 Agent 代入为手速快、听话、世界知识丰富的应届生，把自己代入为指挥十几个乃至二十几个一线大头兵的小组长，你会发现，漂移治理实际上就是要搞清楚团队内部的人都在做什么，以及做出来的东西和实际想要的东西是否一致。这种对齐会，或者项目阶段性 review 会议，在公司里面，基本上每隔一阵子都会开。

几点感想：

1. 方法论比会写代码重要。用了 AI 以后，效率是 x2，还是 x5，还是 x10，还是 x+∞（考虑到我自己一行鸿蒙代码都不会写，鸿蒙开发能力为 0，能搓出来一个完成度不错的客户端，那显然是 x+∞），全看怎么用。以后大家就都是 Full-Stack 工程师了；

2. 独立开发产品之前，得先了解一下政策的边界。我是在看到网易云宣布上架鸿蒙当晚就开搞了，如果我很早就知道 GitHub 完全体功能在国内无法上架的话，可能压根也就不开这个坑了。这波啊，是吃了执行力过强的亏。

3. 纯血鸿蒙平台最好的 GitHub 客户端，还得是出境易的官方原版。

项目概况

项目及其地址：ArkCat 这个作品的工程纪律，以及 SDD 实践还是比较规范的，自认为可以作为一个 AI Native 驱动开发的样板间。一些项目数据（截至 2026-10-04）：

• 开发周期：2026-09-01 首次提交，2026-09-29 转公开仓库，主体开发 29 天，全部业余时间；
• Spec：specs/ 目录下 76 份编号 Spec（001–076），统一模板，全部过 check-spec.sh 结构合规检查；
• 代码规模：ArkTS 51,365 行（entry/src/main/ets）；
• CI 门禁：9 道 job——spec-lint、commit-lint、structure-check、hardcoded-colors、gitleaks、unit-tests、harmony-build、official-local-test、official-local-test-windows。

开发这个项目，日均 Token 消耗 5 亿上下，最猛的一天超过 10 亿。在这里将其开源，有兴趣进行鸿蒙开发的可以看一下，如果能给个 star 就更好了。