课程项目什么时候才算工程资产

我回看自己的课程项目时，经常遇到一种尴尬状态：它比练习完整，所以我舍不得删；离真实产品又很远，所以我很少再打开。最后最容易做的，只是在 README 里增加更多功能描述，希望它看起来像作品。

重新检查 TaskFlow、Tradinghelper、carbon-admin 和 Configurate 后，我更愿意用一个严格标准：工程资产不是我完成过的代码，而是未来仍能降低成本、证明判断或支持新工作的材料。

四个仓库代表四种常见状态

TaskFlow：功能完整，但验证环境封闭

TaskFlow 是我明确标注的期末作业，包含任务增删改、优先级、截止时间、日历、主题、本地存储和导入导出。我没有为它加入后端，打开静态页面即可运行。

这类项目的优点是用户流程完整，缺点是需求由作业边界决定，缺少真实用户、跨设备数据和长期演进。它可以作为前端状态管理与本地数据设计的样本，但不必包装成成熟任务管理产品。

Tradinghelper：产品方向清楚，证据太少

我给 Tradinghelper 写下了实时行情、交互图表和技术指标的产品方向，但 README 只有一句简介。站在外部读者角度看，无法判断数据源、延迟、指标实现、风险提示、运行方式和当前完成度。

这类仓库不一定需要重写代码，第一步应该是补证据：截图、数据来源、可运行步骤、已实现功能与非目标。金融相关界面尤其不应把演示数据写成决策建议。

carbon-admin：只有题目，没有项目叙事

我当时只给 carbon-admin 留下“双碳管理系统”这个领域名称，却没有把它定义成可验证产品：用户是谁、管理什么数据、如何计算、哪些指标来自政策或业务规则，都没有说清楚。

如果要继续，这个项目首先需要领域重构，而不是视觉重构：定义组织边界、排放源、活动数据、因子版本、核算周期和审计记录。否则再完整的后台页面也只是 CRUD 外壳。

Configurate：代码谱系比功能更重要

我的 Configurate 仓库结构与 README 指向 SpongePowered Configurate 生态，但 GitHub 元数据没有把它标记为 Fork。无论当时是导入、镜像、课程分支还是历史迁移，我都应该在作品集中明确上游来源、基准版本、自己修改的模块和当前用途。

使用成熟开源代码学习没有问题。真正的问题是读者无法分辨继承内容与原创贡献。

五种处理方式，而不是全部重写

1. 保留原样

适合有历史意义、能运行、但不值得继续投入的项目。补一段状态说明，标记完成时间与限制即可。

2. 归档

适合依赖过时、无法运行、目标已失效的仓库。归档不是失败，而是停止制造维护预期。

3. 补证据

适合实现基本完整但文档太弱的项目。优先补运行步骤、截图、测试、数据来源和已知限制，不急于重做架构。

4. 提炼模块

适合项目中确实有第二次使用价值的部分，例如日期状态机、配置加载器、图表适配层或导入导出格式。只有当另一个项目需要它时，再抽成库。

5. 从问题重新开始

适合领域定义错误或作业假设太强的项目。保留旧仓库作为历史，新版本重新写规格，而不是在旧页面上继续叠功能。

一个仓库是否值得继续的评分表

每项 0—2 分：

维度	0 分	1 分	2 分
可运行性	已失效	需大量手工修复	有明确复现步骤
原创判断	无法区分来源	有少量说明	来源与贡献清晰
用户价值	只满足题目	有合理场景	有真实使用或反馈
证据	只有描述	有截图/输出	有测试、数据和限制
迁移价值	无可复用经验	可写复盘	可直接支持新项目
维护成本	依赖严重过时	可控升级	当前仍健康

总分不是绝对裁决，但可以阻止“因为写过很多代码，所以必须继续”的沉没成本。

作品集 README 应该写什么

课程项目最需要的不是更长功能列表，而是更诚实的上下文：

这是课程、练习、复现、团队项目还是个人产品。
需求来自哪里，自己负责哪些部分。
当前能运行到什么程度。
使用了哪些上游模板、库或已有代码。
最重要的技术判断与失败是什么。
如果重做，会改变什么。

一个清楚写着“期末作业，数据仅存在 LocalStorage，未做多用户同步”的仓库，比声称“现代化企业级任务平台”更可信。

从旧项目中提炼文章，而不是虚构升级

旧项目可以产生有价值的内容：

TaskFlow 可以写本地优先应用的数据边界。
Tradinghelper 可以写行情数据与技术指标的可信展示。
carbon-admin 可以写领域调研为什么先于后台开发。
Configurate 可以写代码来源与开源谱系如何标注。

文章的价值来自重新判断，不要求旧代码突然变成生产系统。

最后的选择

不是所有仓库都需要成为代表作。一个健康的 GitHub 主页应该允许四种状态同时存在：正在维护、完成留档、实验失败、明确归档。

真正值得重点维护的项目，应该能形成连续链路：有真实问题，有可检查实现，有验证证据，也有公开复盘。其余仓库保留历史即可，不必通过重写 README 假装它们从一开始就目标明确。