以前做课程设计、建模比赛或者写小工具时，我总习惯把“写总结”当成项目彻底收尾后的附属品。结果往往是：做完的那一刻人已经筋疲力尽，那些中间踩过的坑、推翻过的假设、调通某个参数时的顿悟，全都留在了零散的草稿纸和终端历史里，过两个月连自己都想不起来当初为什么要那样设计。
后来我慢慢意识到，写作不是项目结束后的装饰，它本身就是工程思考的一部分。
从一个具体的摩擦开始
回想起来，真正能让我坚持做完的个人项目，几乎都不是从宏大的口号开始的，而是源于日常里一个非常具体的摩擦：比如学法语时总记混动词变位，于是干脆在博客里给自己写了一个练习页面；比如做传感器项目时发现光看温度曲线根本不知道节点是不是快没电了，于是开始琢磨怎么把设备自检也塞进数据流里。
遇到一个反复出现、一时又没有标准答案的小问题时，先把问题定义清楚、把第一个哪怕很粗糙的解法跑通，比花几个星期去寻找“终极架构”有用得多。
公开构建：把半成品和试错留在阳光下
“Building in public（公开构建）”这几年常被提起，但在我看来，它并不意味着每天都要去社交媒体上发进度打卡。对我来说，公开构建更像是一种诚实的工程习惯：不假装自己的方案完美无缺，而是把当时是怎么想的、做了哪些权衡、哪些地方还没验证坦坦荡荡地写出来。
就像写代码一样，与其在脑海里反复推演整套蓝图，不如先切出最核心的第一步，让想法变成屏幕上可被看见、可被讨论、也能被未来的自己复盘的东西：
const nextStep = (idea: string) => idea.trim().slice(0, 1);这也是我重新开始维护这个博客的初衷：无论是写透一个硬件项目、复盘一次建模比赛，还是随手记下一段界面设计的心得，只要真实地记录下思考的脉络，这些文字就会慢慢生长出属于自己的语境。