README
Diary, 不过并不是日记的意思,应当是日志的作用
这个问题非常关键,特别是你已经有了像 Framework-App
、Environment
、Pitfalls
等专业分类后,**Diary
的定位就变得微妙**,它不能太宽泛也不能和其它重复,否则以后你自己也会难以归类。
✅ 一句话定义:
Diary
分类适合放“带有时间性、个人化、非结构化的技术日志或开发日常”,不像教程那样系统,也不像笔记那样整理好,只是“我做了什么 / 遇到了什么 / 有了什么想法”的记录。
🧩 一、适合放在 Diary
的内容类型
内容类型 | 示例 | 特点 |
---|---|---|
编程日志 | 今天搞了 MPV 播放器的交互、踩了一个 JS 的坑 | 记录“做了什么”,通常带时间性 |
开发过程记录 | 《Hello-World:边缘坐标建站记》 | 类似开发旅程,不是教程 |
日常技术碎碎念 | “最近在摸索 Rust 和 Tauri,感觉还挺清爽的” | 想法随写 |
未完成的实验/项目记录 | “计划做一个漫画发布系统,现在刚起草数据库结构……” | 草稿级别的写作内容 |
每日/每周技术总结 | “本周收获:学了 PostgreSQL 的索引优化” | 有时间感、有成长感 |
临时笔记,不确定归类 | “记一笔刚刚调通 Tailscale+RDP 的过程” | 可在日后转存到更专业分类 |
🧠 二、Diary
和其它分类怎么区分?
分类名 | 用来放…… | 和 Diary 的区别 |
---|---|---|
Environment |
专业的环境配置文档 | Diary 可放“配置过程记录或踩坑” |
Pitfalls |
归纳的坑点与警告 | Diary 是发现坑当下的日志 |
Framework-App |
框架的研究与使用笔记 | Diary 是我“尝试用框架”过程的记录 |
Language-Basic |
语法、结构、设计模式等基础知识 | Diary 是学某语言过程中的个人体会 |
Diary |
带有过程感、感受、时间记录的内容 | 更主观、更松散、允许未整理好 |
✍️ 三、Diary 适合的命名风格(文章标题)
- 《2025-03-27|Tailscale+RDP 初体验》
- 《Hello-MPV|第一次用 Tauri 控制播放器的记录》
- 《Rust 环境配置小记(Win+WSL 混搭)》
- 《边学边写:Vue Router 的动态路由试验》
- 《这个 Bug 我调了整整一天……》
这些都比教程更“人味”,哪怕内容技术含量高,也是从“我”的角度出发的。
📌 四、Diary 分类的意义和价值
- 是你“技术成长轨迹”的记录区
- 是未整理好但不想丢掉的想法池
- 是未来自己复盘、写系统文章的素材来源
- 是放“像 blog 又不像 blog 的内容”的好地方
✅ 总结
✔️ Diary
是一个非常适合用于:
- “我今天学了什么”
- “我这周做了什么”
- “我踩了什么坑”
- “我正在做的某个项目进展”
- “我发现了一个超好用的小工具”
的分类。
只要你写的是个人化 + 带时间感 + 偏技术过程的内容,放到 Diary
都是完全合理的。
需要的话我可以帮你梳理一份“这篇文章该放在哪个分类”的参考标准文档(分类策略指南)🧭,这样你以后不会纠结内容到底该归到哪。要吗?
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 世界尽头のWasteland!
评论