第1989篇：工程师的创造力——用技术能力做出有意思的东西的故事
第1989篇：工程师的创造力——用技术能力做出有意思的东西的故事
去年我做了一个没什么实际用处的东西，但它是我过去几年做的最让我满意的东西之一。
事情的起因是一次发呆。我在跑步的时候想到一个问题：如果把我这几年写的所有代码按照时间顺序排列，能不能看出我的思维风格在哪些地方发生了变化？就像分析一个作家的写作风格演变一样，我能不能分析一个工程师的代码风格演变？
我把这个想法实现了出来：用词嵌入（Embedding）把代码片段向量化，把五年前的代码和最近的代码都向量化，然后在降维可视化后，看它们在空间里的分布。
结果让我有点吃惊：五年前的代码和现在的代码，在向量空间里确实有明显的聚类差异。五年前写的代码倾向于写很长的方法，现在写的倾向于更多地拆分。五年前喜欢在一个类里做很多事情，现在更倾向于单一职责。
这个分析本身没什么工程价值，但做这件事的过程让我非常开心。
我想聊聊这件事背后的话题：工程师的创造力，以及如何用技术能力做出有意思的东西。
工程师创造力的特殊性
"创造力"这个词通常和艺术家联系在一起，工程师谈到创造力，往往有点不好意思，好像这个词跟我们不太搭。
但我觉得工程师有一种非常独特的创造力，它的特点是：把世界上已经存在的工具和材料，组合成一个之前不存在的东西。
程序员写代码，本质上是在做一件创造性的工作——用已有的语言特性、库、框架、算法，构建一个新的系统，这个系统在你之前没有以这种形式存在过。就算是"重复造轮子"，你的轮子也不会和任何人的轮子完全一样，因为它来自你对问题的特定理解。
工程师创造力的问题，通常不是"有没有"的问题，而是"有没有机会表达"的问题。在大多数工作场景里，工程师的创造力被限制在"在给定的约束下寻找最优解"，而不是"自由地定义什么是值得解决的问题"。
当你可以自己定义问题的时候，创造力才有机会真正展开。
我见过的几种"有意思的东西"
在过去几年里，我见过或者自己做过一些让我觉得"这真的很有意思"的技术项目。分享几个：
第一个：工程师的个人仪表盘
一个朋友花了两个周末做了一个给自己用的仪表盘，把他的GitHub提交、读书记录、锻炼数据、学习笔记都整合到一个页面上，每天早上看一眼"我昨天做了什么"。
技术上没什么难度，但它解决了一个真实的问题：他感觉自己每天很忙但不知道做了什么，这个仪表盘让他的每天都有了记录。
半年后，他发现了一个自己之前没意识到的规律：他的GitHub提交量和他的跑步次数正相关。那段时间每周跑步多的时候，代码产出也更多。他把跑步坚持了下来，代码产出也更稳定了。
第二个：代码审美评估器
另一个朋友做了一个用LLM评估代码"审美质量"的工具——不是代码规范检查，不是功能正确性验证，而是评估代码的"优雅程度"：命名是否直观，抽象层次是否一致，结构是否让人一眼能看出意图。
他用了大量的优质开源代码来训练这个工具的"审美偏好"。
这个工具当然不完美，LLM对代码审美的判断有时候很奇怪，但它能找出"这段代码为什么让人看着不舒服"——通常是命名混乱或者层次不一致。
这个工具没有商业价值，但它引出了一个很有意思的问题：代码的美感是客观存在的吗？如果可以被量化，那量化的依据是什么？
第三个：对话式文档
我自己做过一个实验：把一个复杂系统的文档转化成"可对话"的形式。不只是RAG，而是让文档能够推理：如果你问"这两个API在什么情况下会产生冲突"，它能通过理解两个API的文档，推理出一个合理的回答，而不只是检索相关段落。
这在技术上挑战不小，最终效果也不完美，但这个过程让我对RAG系统的限制和可能性有了非常深的理解——比读十篇文章都更深刻。
技术创造的三种动机
回顾我做过的有意思的小项目，背后的动机大概可以分三类：
好奇心驱动： "这个技术用在这里会怎样？" 不知道结果，但想知道。
问题驱动： "我每次遇到这个问题都很烦，我能不能把它自动化掉？" 有一个真实的痛点。
表达驱动： "我想把这个想法变成现实，看看它能不能成真。" 有一个想象中的东西，想把它做出来。
这三种动机都有价值，但我个人感觉最有生命力的作品往往来自"好奇心驱动"——因为你不知道结果，所以探索的过程本身就充满惊喜；而且因为没有功利目的，你会更容易接受"做了但不实用"的结果，然后在这个过程中学到东西。
如何给自己创造做东西的空间
对于大多数有全职工作的工程师来说，做"有意思的东西"的最大障碍不是能力，而是时间和许可。
时间：工作本来就很忙，回到家也累了，哪来的时间做项目。
许可：做一个"没什么用"的东西，感觉不划算，有时候会有罪恶感，"我应该去刷题准备面试，而不是做这个"。
关于时间：我的经验是，"找整块时间"不可行，但"碎片时间累积"是可行的。很多有意思的小项目，不需要整块的时间，每天30分钟，两三周就能出来一个最小可用版本。关键是持续性，而不是单次投入多少时间。
关于许可：我想提供一个重新框架的视角——做有意思的东西，是工程师的自我保养。就像运动员需要充分的休息，工程师需要创造性的自由探索，才能保持长期的技术热情。你做的那个"没用的项目"，可能比任何培训课程都更能提升你的真实能力，因为你是在解决一个你自己真正在乎的问题。
我做过的一个代码实验：情绪感知的代码审查
我想分享一个更具体的例子，展示工程师创造力可以有多荒诞和有趣。
有一次我注意到：在一些特别繁重的项目冲刺阶段，代码提交的注释质量会明显下降。注释变少，或者变得语气很急——"fix this stupid bug"，"TODO: this is terrible but works"。
我好奇：能不能从代码注释里感知到团队的整体压力状态？
我做了一个小实验：收集了某个开源项目的所有commit message，然后用情绪分析模型对它们进行分类，最后和项目的发布节点、issue数量做交叉分析。
// 核心逻辑示意
@Service
public class CommitMoodAnalyzer {
private final SentimentAnalysisClient sentimentClient;
private final GitLogParser gitParser;
public ProjectMoodReport analyze(String repoPath, LocalDate startDate, LocalDate endDate) {
List<CommitInfo> commits = gitParser.parseCommits(repoPath, startDate, endDate);
Map<LocalDate, List<Double>> dailyScores = commits.stream()
.collect(Collectors.groupingBy(
c -> c.getTimestamp().toLocalDate(),
Collectors.mapping(
c -> sentimentClient.analyze(c.getMessage()).getScore(),
Collectors.toList()
)
));
// 计算每周平均情绪分数
Map<Integer, Double> weeklyAvgMood = dailyScores.entrySet().stream()
.collect(Collectors.groupingBy(
e -> e.getKey().get(WeekFields.ISO.weekOfYear()),
Collectors.averagingDouble(e ->
e.getValue().stream().mapToDouble(d -> d).average().orElse(0.5))
));
return new ProjectMoodReport(weeklyAvgMood, findAnomalies(weeklyAvgMood));
}
private List<MoodAnomaly> findAnomalies(Map<Integer, Double> weeklyMood) {
double avg = weeklyMood.values().stream()
.mapToDouble(d -> d).average().orElse(0.5);
double stdDev = calculateStdDev(weeklyMood.values(), avg);
return weeklyMood.entrySet().stream()
.filter(e -> Math.abs(e.getValue() - avg) > 1.5 * stdDev)
.map(e -> new MoodAnomaly(e.getKey(), e.getValue(), e.getValue() < avg ? "LOW" : "HIGH"))
.collect(Collectors.toList());
}
}结果发现：在这个项目里，发布前两周的commit message情绪分数会明显下降，而发布后一周会反弹。这和直觉相符，但用数据看到它还是很有意思。
更有意思的是：我发现了几个"低情绪周"和项目文档里显示的"重大决策被推翻"事件高度吻合。当技术方案被否定，团队的commit message情绪就会下降。
这个实验没有实际价值，但它让我更深入地思考了：代码是一种表达，不只是一种工具。工程师在写代码的时候，是有情绪的，这些情绪会渗透到代码的各个地方——注释、命名、提交信息、甚至代码结构本身。
技术创造的边界感
有一件事我觉得值得专门说一下：有意思的东西，不等于有用的东西，这没关系。
工程师的职业训练让我们习惯于为"有用"辩护——做一个东西，要说清楚它解决了什么问题，带来了什么价值，ROI是多少。
但有一类东西的价值，不在于它本身"有没有用"，而在于做这件事的过程让你变了什么——学到了什么新技能，看到了什么新视角，激发了什么新想法，或者只是让你度过了一段快乐的时光。
我做的"代码风格演变分析"没有实际用处，但做完之后，我对代码的词嵌入、降维可视化、相似度聚类都有了更深的理解，这些理解后来在一个真正的工程项目里用上了。
更重要的是：做完那个东西的那个晚上，我感觉非常好。不是因为它"有用"，而是因为我做了一个我想做的东西，而且它做出来了，它能运行，它给了我一个之前没有的视角。
这种满足感是纯粹的，没有附加条件的。
最后：给还没开始的人一个推荐
如果你还没做过"自己喜欢的技术项目"，我强烈建议你从一个特别小的想法开始。不需要宏大的计划，不需要完整的技术设计，只需要一个让你好奇的问题。
问你自己：有没有什么东西，如果能存在的话，我会觉得很酷？
然后试着把它做出来。哪怕做出来的东西很简陋，哪怕最后发现这个想法行不通，这个过程本身，已经是值得的了。