从 59 个仓库到 3 条主线：我的项目复盘、取舍与重启计划

为什么重新梳理这些项目

截至 2026 年 8 月 20 日，我的 GitHub 账号共有 59 个公开仓库。按照 GitHub API 的公开仓库数据统计，其中 47 个不是 Fork，12 个是 Fork；14 个仓库在 2026 年仍有推送记录，另有 44 个仓库的最后推送早于 2025 年。

数据说明：仓库数量、时间、语言、Fork 属性和已实现功能来自 GitHub API、仓库代码及 README；项目之间的延续关系和保留价值是基于这些证据做出的复盘判断；“接下来的取舍”是未来计划，不代表已经完成。

这些数字能说明项目数量和时间分布，却不能直接说明哪些项目真正有价值。Stars、提交次数和技术栈也不是唯一标准。这次复盘更关心五件事：

项目是否对应一个具体问题，而不只是框架练习。
项目是否代表一次明显的能力跃迁。
项目中的思路是否延续到了后来的作品。
项目是否形成了可以复用、安装或继续维护的成果。
如果今天重新投入，它是否仍有明确的用户和差异化。

因此，这不是一份按热度排列的仓库榜单，也不是要把所有旧项目重新维护起来。它更像是一张技术路径图：哪些探索已经完成了历史任务，哪些线索值得被保留，哪些项目应该成为下一阶段的重点。

第一阶段：从网页练习走向真实场景

2020 年的项目大多使用 JavaScript 或 Vue，但其中已经出现了比页面临摹更具体的产品场景。

信息、工具与社区

infomation_website 是一个疫情科普网站。它依赖外部数据接口，把网页开发放进了当时真实的信息需求中。它不适合在今天重启，但保留了“用软件组织公共信息”的历史意义。
chrome_extends 包含强制暗色模式和滚动截屏两个浏览器扩展实验。README 不仅记录功能，也明确记录了视频变黑、动态页面和截图尺寸不一致等问题。与普通页面练习相比，它开始面对浏览器 API、页面注入和兼容性约束；这条技术线后来在 FormilyAutofill 中再次出现。
campus_cat_book 试图收集校园流浪猫信息，并设计了查猫、社区、知识科普和个人收藏等模块。仓库还拆出了 Node、Express、MongoDB 后端。它的意义不只在小程序技术，而在于项目开始围绕具体人群、真实对象和持续内容来设计。
community_node 在 README 中被标记为“第一个 Node 项目”，包括帖子搜索、头像上传等能力。它代表了从单页界面走向服务端、数据和用户功能的早期尝试。

这一阶段最值得保留的不是旧框架本身，而是三个变化：开始使用外部数据，开始处理浏览器能力边界，也开始把前端页面放进完整的用户场景。

第二阶段：搭建完整系统，并尝试抽象

2021 到 2022 年，仓库重心从单个页面转向多端系统、算法工具和低代码方向。

从博客全栈到算法可视化

reactBlog 是博客项目的总入口，连接 Next.js 博客首页、Node/Express/MySQL 后端和 React 管理端。今天再维护这套旧技术组合的收益有限，但它证明了当时已经开始按“内容端、服务端、管理端”拆分完整系统。现在的 GitHub Blog 继承了内容发布目标，却改用静态内容、自动同步和边缘函数减少维护面。
Compilation_principle_compiler 使用 Electron、React 和 TypeScript 展示编译原理课程设计，README 列出了词法分析、预测分析、LR、算符优先、语义分析、中间代码、目标代码和 DAG 优化等模块，同时明确标注目标代码生成尚未验证正确性。它最有价值的部分，是把抽象算法转化为可交互工具的尝试。
portal 将自己定位为面向门户网站的低代码平台。当前公开 README 对完成度描述很少，因此不能把它当作已经成熟的低代码产品；但“通过配置和抽象降低页面搭建成本”这条方向，与后来持续投入的 Formily 工具存在清晰联系。

这个阶段也暴露了一个问题：完整系统和平台型项目很容易扩大边界。项目可以覆盖越来越多模块，却未必同步建立部署、分发、文档和真实用户验证。这个问题成为后续取舍时最需要控制的成本。

第三阶段：从通用项目收敛到 Formily 工具

2025 年之后，项目开始出现更明确的垂直领域。

formily_baker_script 是 Formily 知识库生成脚本。它的独立产品空间有限，但可以作为文档整理和知识生产能力，被更完整的 Formily 工具链吸收。
agent-skills 将 Formily 初始化、挂载、联动、校验和布局知识整理成 Agent Skill。它说明同一领域的经验正在从零散笔记变成可以被工具调用的结构化知识。
formily-autofill 则进一步把这些经验变成浏览器开发者工具：发现页面中的 Formily 实例、展示 FormGraph、生成填充操作、预览并执行真实回填。它已经具备测试、构建和 AI 辅助填充的基础闭环，也明确记录了 ArrayTable、富文本、上传、自定义组件和真实浏览器 E2E 等尚未完成的边界。

这三个仓库不应该继续作为彼此孤立的项目扩张。更合理的关系是：FormilyAutofill 成为产品主体，知识库脚本和 Agent Skill 分别补充知识生成与开发指导能力。

第四阶段：从 Rust 练习到可分发作品

2026 年的另一条明显变化，是 Rust 项目从练习进入完整作品阶段。

rust_practice 集中保存 Rust 练习项目，是语言和工具链学习的承接点。它适合继续作为学习记录，而不是包装成独立产品。
skystrike 是终端竖版射击游戏，已经包含固定时间步游戏循环、双缓冲差异渲染、对象池、难度、得分、道具和本地记录，并发布了 crates.io 0.1.0。这使它从练习仓库跨过了“可安装、可运行、可发布”的门槛。
github-blog 使用 Astro、Cloudflare Pages、GitHub 数据同步和 D1 访问统计来承载项目与文章。它不需要发展成另一个大型内容管理系统；它更适合作为其他项目的展示、解释和分发中枢。

从仓库状态看，这一阶段最重要的变化不是换了一门语言，而是开始补齐 README、测试、CI、安装方式、发布流程和展示素材。项目价值不再只由代码是否完成决定，也取决于别人能否理解、获得并实际运行它。

哪些历史项目仍然有意义

“有意义”和“值得重启”不是同一件事。历史项目可以分成四类：

类型	代表项目	当前处理方式
仍有产品生命力	FormilyAutofill、SkyStrike	继续作为旗舰项目投入
题材仍有价值，但需要重新验证	校园猫猫图鉴、编译器	先验证用户、数据和展示方式，再决定是否重启
能力已经被后续项目继承	Chrome 扩展、React Blog、Portal	保留为技术路径节点，不直接重写
主要承担学习记录	商城、后台、模板、课程 Demo、Rust Practice	标记历史状态并归档整理

其中，校园猫猫图鉴和编译器最值得保留“重新定义”的可能：

校园猫猫图鉴有具体人群和内容对象，但真正重启的前提是存在持续的数据来源、校园合作、内容审核和隐私方案。没有这些条件，单纯升级前端框架不会让项目获得新生命。
编译器项目可以弱化桌面应用外壳，转成纯 Web 的交互式编译原理实验室，让 Token、语法树、中间代码和优化过程可逐步观察。它适合作为技术作品，而不是追求通用编译器产品。

收敛为三条主线

复盘之后，未来投入可以收敛为三条相互支持的主线。

1. Formily 开发者工具

以 FormilyAutofill 为主体，优先完成真实页面 E2E、复杂组件适配、测试场景保存与重复执行，再考虑扩展分发和更完整的 AI Gateway。Formily Baker Script 与 Agent Skills 不再独立扩张，而是作为这条主线的知识资产。

2. Rust 与终端作品

以 SkyStrike 为当前代表作，下一阶段优先提供 macOS、Linux 预编译包和更直观的动态演示，再增加 Boss、波次、敌方弹幕和可复现随机种子。目标不是无限叠加功能，而是缩短从看到项目到实际游玩的路径。

3. 内容与项目中枢

GitHub Blog 负责说明项目解决了什么问题、记录关键迭代并链接安装或演示入口。它本身保持轻量，避免再次走向需要长期维护的大型博客后台。

接下来的取舍

第一步不是马上重写旧项目，而是治理现有仓库：

给仓库标记 Active、Experiment、Learning 或 Archived。
归档重复的商城、博客、模板和课程项目，保留 README 作为历史记录。
重写 GitHub Profile README，只突出少数代表项目和当前方向。
将主要开发时间集中到 FormilyAutofill 和 SkyStrike。
每次完成可验证的迭代，再通过 GitHub Blog 记录过程和结果。

这次复盘的结论不是“旧项目都应该复活”。相反，真正有意义的整理，是承认不同项目承担过不同任务：有些验证了技术，有些第一次面对真实用户场景，有些形成了今天仍可延续的产品方向。历史可以被保留，但维护资源必须集中。

59 个仓库最终不需要变成 59 个长期项目。更合理的结果，是让少数作品继续成长，让能够复用的经验被合并，让其余项目以清晰的历史身份留下。