不止写代码：我在技术、创作与真实项目中的一年复盘

不止写代码：我在技术、创作与真实项目中的一年复盘

说实话，回头看这一年，我做的事情并不新鲜。
写代码、做项目、赶进度、改方案、写博客——
如果只列清单，看起来和前几年差不多。

但真正不一样的，是我看待这些事情的方式变了。

以前我更关心：
👉 这个功能我能不能做出来？
👉 这个技术我会不会？

现在我更关心的是：
👉 这个系统能不能活得久？
👉 这个选择，半年后会不会变成坑？

这篇文章，不是炫成果，也不是年终总结模板，
只是一次很诚实的复盘——
关于我这一年在技术、创作，以及真实项目里的变化。

一、技术：我开始主动“少写点代码”

这一年，我明显不再迷恋“复杂度”了。

不是因为写不动，而是写得多了之后，越来越清楚一件事：
复杂，往往不是能力，而是负担。

在工程项目里，我慢慢稳定了一套自己用得顺、也兜得住的技术组合：

• Vue 3 + Pinia + Vite
• Three.js 只在“真的有必要”时才用

以前遇到需求，第一反应是：

这个能不能做得更炫一点？

现在更多是：

这个值不值得我引入新的复杂度？

我开始接受一个事实：
成熟的标志，不是你能写多复杂的代码，而是你知道哪些代码根本不该写。

二、写博客：从“记录我做了什么”，到“逼自己想清楚”

写博客这件事，对我来说变化也挺大。

一开始，更多是记录：

• 今天做了什么功能
• 遇到了什么坑
• 怎么解决的

但慢慢地我发现，
真正难的不是写出来，而是写清楚。

很多时候，文章写到一半我才意识到：

• 有些方案，其实只是“当时刚好能用”
• 有些结论，经不起多问一句“为什么”

于是我不得不停下来改方案、补逻辑，
甚至推翻之前的判断。

这也是我越来越偏向写系列文章的原因。
不是为了数量，而是逼自己把一件事想完整。

慢慢地，博客不再只是输出内容，
而成了一个长期帮我“校验认知”的工具。

三、一个真实项目的取舍案例

这一年，在一个偏智慧工地 / 数字孪生方向的项目里，我印象很深。

项目一开始，大家都很兴奋：

• 全三维
• 高精度模型
• 漫游、特效、动态展示

听起来很爽，对吧？
但真正摆到桌面上讨论时，现实开始出现了：

• 项目周期很紧
• 现场网络条件不稳定
• 后期维护人员并不是技术背景

最后我做了一个并不“酷”的决定：
主动收缩技术边界。

• 模型精度下调，先保证加载和稳定
• 用 2.5D + 关键三维节点，替代全三维漫游
• 把时间留给配置化、数据联动和稳定性

最终交付的系统，可能不是最炫的，
但在现场演示、使用理解、后期维护上，反而更顺。

那一刻我特别清楚地意识到：
工程里的好方案，往往是被现实“磨”出来的，而不是设计出来的。

四、我的角色，也在悄悄变化

这一年，我越来越少只盯着“怎么实现”，
而是更多参与到这些问题里：

• 这个功能到底该不该做？
• 这个复杂度我们能不能兜住？
• 半年后谁来维护？

我开始意识到，
真正值钱的能力，有时候是提前说“不”。

代码当然重要，
但在很多关键时刻，
避免一个错误决策，比写 1000 行漂亮代码更有价值。

结尾：我还在写，但不只是写代码了

回头看，这一年最大的变化，其实只有一句话：

技术、项目和写作，不再是三件分开的事，而是一个互相校正的整体。

我依然会写代码，
依然会做项目，
也会继续更新 CDSD 博客。

但比这些更重要的，是我开始接受：

• 不追求所有“看起来很厉害”的方案
• 不被技术潮流牵着跑
• 对长期可维护性负责

不止写代码，也不止总结成果，
而是在真实世界里，一点点把判断力磨出来。