OpenChain：第一次把工程思维完整用在项目里

这是我第一次把关于终身学习体系的思考里提到的工程思维，完整用在大学阶段的项目实践中。为了记录这个过程，写下这篇复盘：OpenChain ->。

What#

OpenChain 有双重属性：它既是我大一学年修读的一门大二专业基础课的期末大作业，也是参与 OpenRank -> 比赛的正式作品。比较幸运的是，我们最终拿到了全国三等奖。

简单来说，OpenChain 聚焦的是开源生态中的可持续发展问题。它希望通过构建“人 - 项目”的双向匹配机制，帮助开发者找到更适合自己的开源项目，也帮助项目找到更合适的贡献者。

客观来说，项目立意还不够深。在真正见过大项目、大场面的评委面前，它确实略显单薄，实际应用价值也还有待验证。

核心难点在于推荐算法的有效性验证与优化。个人认为，真正关键的推荐数据源应该包括浏览历史、页面停留时间、交互行为等更细粒度的数据。但 OpenChain 当前主要依赖有限的标签数据进行推荐，它能否精准理解并满足用户需求，还需要更多理论和实践验证。

主观来说，OpenChain 的完成对我意义很大。前端主要借助 v0.dev，后端以及前后端连接主要借助 Cursor。虽然代码主体很大程度上由 AI 工具辅助完成，但作为使用者，我仍然学到了很多：包括对前后端整体框架的理解、对项目推进节奏的把控，以及面对复杂问题时心态的稳定。

我越来越相信，用自然语言实现全栈开发是一个可以看见的未来。至少对有一定编程基础的初级开发者来说，全栈开发的门槛已经不像五年前，甚至一年前那么高。面对 AI 技术的快速发展，传统意义上对冗杂代码细节的深度钻研，是否仍然是开发者的唯一核心能力，值得重新思考。

所以我可以很坦然地说：这个项目是 coded by AI, but designed by Frank。

作为团队负责人，我主要负责项目全生命周期的管理与推进。

项目立意我放了很长一段时间。原因也很简单：我只愿意在自己真正感兴趣的事情上投入时间。

前期，推荐算法的实现迭代了好几版。从遍历共同作者，到优化相似度算法，再到最终的推荐池算法，中间有很多思维碰撞。这个过程其实很好玩。

当前后端基本完成后，我们有两个方向可以继续投入：

我始终认为，以推荐算法为核心的推荐流程才是这个项目真正有意义的部分。所以后期大量时间都花在调试和验证上：不断调整相似度指标各个维度的权重，让结果尽可能“看起来有意义”。

这个阶段很枯燥，但也最接近工程实践本身。

现在回头看，我怀疑这个阶段才是我们获奖的关键。

复赛进入 Top 16 只由两位评委决定，运气占了很大一部分。同时，评委不一定有足够时间完整运行和理解项目，所以他们对项目价值的判断，很大程度来自说明文件和展示材料。

因此我写了一份“过于详细”的 README，队友也做了一份“过于详细”的演示视频。事实证明，这些材料确实提高了项目被理解的概率。

由于时间冲突，很多学长学姐只能通过线上答疑和线下找人展示的方式完成最终路演。出于对更高奖金的追求，也经过权衡，我决定飞到武汉参加。

从体验上说，这段经历很宝贵；从效果上说，并不理想。

一方面，项目 PPT 还不够优秀；另一方面，项目本身也确实还不够强。我个人的展示能力也有限，对麦克风不熟悉，导致现场音量不够稳定。为了赶时间，我把 26 分钟的展示视频压缩到 3 分钟，代价是场馆音响几乎听不清。

不过最后 5 分钟的提问环节，我觉得自己还是比较有条理地正面回答了评委老师的问题。现在回想起来，当时好像也没有特别紧张。

这次项目最大的收获，是第一次真正体会到工程思维的魅力。

复杂项目并不是靠一口气冲完的，而是要拆解成一个个可操作的阶段：从项目立意、算法优化、方向取舍，到最终成果展示，每个阶段都有自己的重点和节奏。

后面要尽可能独立完成更高难度的项目。

简单的前后端项目当然有练手价值，但不能一直停留在这个层面。下一步更应该做的是：找到真正有挑战、有壁垒、也更值得长期投入的问题。