从 80 个仓库看我的工程轨迹：2023—2026

如果只看自己的 GitHub 首页，我很容易把仓库数量、提交频率和绿色方格误认为成长本身。它们能说明我做过事情，却不能说明哪些工作已经形成了可复用的能力。

我用 GitHub CLI 重新检查了账号下的全部仓库，包括元数据、目录结构、依赖清单、README 和关键提交。审计时共有 80 个仓库：65 个非 Fork、15 个 Fork；35 个公开、45 个私有。这里的“非 Fork”只是 GitHub 的仓库关系字段，不自动等于从零原创，也不等于已经适合作为作品展示。

这篇文章不做项目陈列墙，而是回答三个更重要的问题：过去四年在反复解决什么问题，哪些仓库已经长成工程资产，下一步应该把时间放在哪里。

数量背后的时间线

年份	新建仓库	主要阶段
2023	2	建立账号身份与最初的代码存档
2024	18	Java、Minecraft、课程项目与 Web 基础扩张
2025	31	研究复现、桌面/浏览器工具、数据与前端项目快速增多
2026	29	开始重视边界、验证、发布、安全更新与方法沉淀

只统计 65 个非 Fork 仓库时，主语言最多的是 Java、Python、JavaScript、C# 和 Kotlin。这个分布比“全栈”更具体：早期重心在 Java 生态，之后 Python 承担研究和数据实验，JavaScript/TypeScript 承担界面与扩展，C# 则集中在 Windows 桌面工具。

真正明显的变化不是语言变多，而是仓库开始从“能运行”走向“能维护”。

2023：先有一个公开身份

2023 年的仓库很少，核心意义是建立公开身份和代码存档。这个阶段没有必要包装成宏大起点，它更像一条基线：账号存在，但尚未形成稳定的项目叙事。

作品集的第一个常见误区，是试图把每一次练习都解释成重要成果。更诚实的做法是保留它们，同时承认当时解决的问题很小。基线越真实，后面的变化越清楚。

2024：大量练习开始暴露工程问题

2024 年，我开始集中接触 Minecraft/Java 生态、配置库、静态站点和课程项目。我做的 TaskFlow 是这一阶段很典型的样本：我完整覆盖了任务、日历、主题和本地存储，但它也带着期末作业常见的边界，功能齐全，长期维护与真实用户验证不足。

我的 Configurate 仓库则提醒了我另一件事：GitHub 没有标记为 Fork，不代表代码谱系不需要说明。只要仓库来自上游项目、课程模板或迁移历史，我就应该在 README 中明确来源、修改范围和当前维护关系。作品集最怕的不是使用现成代码，而是让读者无法判断哪些判断属于我。

这一年最值得保留的能力，不是某个页面或某段 API，而是第一次接触多模块项目、依赖管理、构建失败和代码来源问题。

2025：广度快速增加，也开始出现证据焦虑

2025 年我新建了 31 个仓库，是数量增长最快的一年。公开项目覆盖股票辅助界面、双碳管理、图像复原、浏览器国际化和自动化实验；私有项目中则有更多研究复现、数据处理与交付型工程。

这一阶段，我开始处理真实复杂度。例如我在 Single-lens 中不只实现维纳滤波和 Lucy–Richardson，还加入 PSF 验证、指标比较、性能诊断与实验输出。我后来又对 Postman-Web-i18n 做了质量审计，修复 XSS、规则校验、语言切换原子性和动态页面兼容问题。

但仓库也暴露了一个共同风险：README 很容易写出“完整复现”“专业级”“性能提升”之类的结论，而证据可能仍停留在本机输出、合成数据或单次实验。研究项目越复杂，越需要把数据来源、基线、随机种子、运行环境和失败条件写清楚。

另外，我也保留了 AutoGreen 这个很适合作为反例的项目。自动提交能够改变活动图，却不会自动增加项目价值。绿色方格是副产品，不应该成为我的目标函数。

2026：从功能实现转向边界与交付

到 2026 年，我的代表项目开始呈现共同结构：先声明边界，再实现功能，然后补验证和发布链路。

我把 ACEOptimizer 的行为限制在 Windows 公开的优先级与 CPU 亲和性设置，并补上测试、版本校验和 Ed25519 更新签名。
我让 Emergency-Stop 保持键盘输入与外部覆盖层边界，不读进程、不注入、不自动操作。
我为 HybridFont 准备了默认禁用的保守包和恢复路径。
我没有在 Tau-gui 中重写 Agent 内核，而是围绕 Pi 的 RPC/SDK 做会话、上下文和包管理界面。
我在 agent-skills 中把反复出现的工作方法写成可触发、可评估的操作协议。
我用 vibe-coding-tutorial 把规格、拆解、上下文、验证和复盘组织成一套公开教程。

这些项目之间看似跨度很大，实际上共享一个判断：工具的价值不仅在于它能做什么，也在于它明确不做什么，以及失败后如何恢复。

哪些仓库值得写成文章

我用四个条件筛选本系列的主题：

仓库中有可核对的演进，而不只是一次性提交。
问题具有迁移价值，能帮助其他项目做判断。
可以公开讲清楚，不依赖私有代码或敏感数据。
文章能诚实写出限制，而不是把 README 再扩写一遍。

因此，本系列选择了 Agent Skills、Vibe Coding 工作流、Windows 工具边界、动态网页国际化、Android 系统修改、科研复现和 Agent 桌面工作台。课程项目也会写，但重点是如何判断它们是否已经成为资产，而不是替旧作业补一层包装。

下一阶段比新建仓库更重要的事

80 个仓库已经足够证明探索广度。下一阶段的增量更可能来自以下工作：

为公开项目补充最小可复现路径、测试证据和清晰许可证。
将一次性交付中的通用模块抽离，但只在确实有第二个使用者时抽离。
为导入或改造的仓库补全来源与修改说明。
把私有项目中的通用经验写成不泄露实现的文章。
让博客、教程和仓库互相引用，形成“判断—实现—证据”的闭环。

GitHub 主页保存的是结果，博客应该保存结果背后的判断。接下来的文章会沿着这条线展开。

系列导航

数据快照来自我的 GitHub 主页，统计日期为 2026 年 7 月 19 日。仓库可见性、数量和内容之后仍可能变化。