技术实践日志

个人技术博客

Mon, 17 Aug 2026 21:00:00 +0800

背景

需要一个比 PDF 简历容纳更多过程信息的公开入口，用来持续记录技术实践、实验复盘和项目判断。网站既要便于写作，也要避免为了维护博客本身消耗过多时间。

关键约束

首期托管和平台地址免费；
所有文章以 Markdown 保存在 Git 仓库；
不依赖数据库和服务器运维；
桌面端和移动端都能清晰阅读；
更换托管平台时不重写内容；
站点需要体现个人判断，而不是直接套用通用博客主题。

方案

网站使用 Hugo 生成静态页面，Cloudflare Pages 负责构建和发布。视觉层使用自定义模板与原生 CSS，不引入前端框架和运行时依赖。搜索索引也由 Hugo 在构建时生成，浏览器只负责在本地过滤结果。

已实现

首页、文章列表、文章详情、项目、关于与搜索；
标签、RSS、Sitemap、Robots 与基础社交分享元数据；
代码高亮、目录、响应式排版和深色模式；
Git 推送触发的 Cloudflare Pages 自动部署配置。

后续迭代

真实内容稳定后再绑定独立域名，并补充访问统计。评论功能只有在确实出现讨论需求时才加入，避免为了一个暂时不存在的场景增加维护面。

关于

Mon, 17 Aug 2026 21:00:00 +0800

我关注智能系统、实验工程以及复杂技术问题的可复现解决过程。这个博客用于保存那些仅靠简历条目无法说明的部分：约束如何确定、方案为什么改变、失败证据排除了什么，以及最终结论能够支持到哪里。

这里会写什么

技术实践和故障排查；
实验设计、自动化与结果审计；
项目中的架构选择和权衡；
工具链、写作方法与工作流复盘。

内容原则

我会尽量区分设想、实现、运行、完成和验证，不用进程状态代替结果，也不把一次探索性观察包装成普遍结论。文章如果包含代码或实验，会给出必要环境、输入条件和最短复现路径。

使用这份模板

当前作者名称和联系方式集中在 hugo.toml。替换配置后，页头、页尾和关于页面会同步更新。项目与文章分别保存在 content/projects 和 content/posts，不需要修改页面模板。

搜索

Mon, 17 Aug 2026 21:00:00 +0800

为什么用 Hugo 与 Cloudflare Pages 搭建技术博客

Mon, 17 Aug 2026 20:00:00 +0800

搭建技术博客时，真正困难的不是把页面放到互联网上，而是找到一套几年后仍愿意继续使用的写作流程。我的核心需求有三个：文章归自己所有、维护成本足够低、网站本身能够成为技术能力的补充证明。

选择标准

我把需求拆成了四项可以检查的标准：

标准	具体要求
内容所有权	原稿保存在本地，并能完整进入 Git 版本管理
写作体验	使用 Markdown，不依赖在线编辑器
部署成本	不维护服务器，推送后自动发布
可迁移性	域名、托管平台或主题变化时，不必重写文章

这套标准排除了需要长期维护数据库的动态博客，也排除了文章只能保存在平台后台的封闭方案。

Hugo 负责什么

Hugo 把 Markdown、模板和配置编译成普通静态 HTML。文章的元数据集中在文件开头：

1+++
2title = '一次性能问题的完整排查记录'
3date = 2026-08-17T20:00:00+08:00
4tags = ['性能分析', '复盘']
5+++

这意味着每篇文章都是一个可以复制、搜索、比较和长期保存的文本文件。即使以后不再使用 Hugo，正文也仍然可以迁移到其他系统。

Cloudflare Pages 负责什么

Cloudflare Pages 连接 Git 仓库，在检测到新的提交后执行 Hugo 构建，然后把生成的静态文件发布到公开地址。日常流程因此只剩下四步：

怎样写一篇可复现的技术实践记录

Sun, 16 Aug 2026 20:00:00 +0800

很多技术文章描述了最终答案，却省略了答案成立的条件。读者可以照着复制代码，却无法判断自己的环境为什么得到不同结果。可复现记录需要把“做了什么”扩展成“在什么条件下做、如何知道它成功”。

从一个可验证的问题开始

避免从“最近学习了某工具”开始。更有价值的起点是一个能够判断成败的问题：

在固定数据和配置下，怎样确认一次训练任务真正完成，而不是进程仍然存活？

这个问题自然带出输入、约束、检查方法和完成标准。

记录最小环境

环境信息不需要罗列整台电脑上的所有软件，只保留会改变结果的部分：

操作系统和关键运行时版本；
直接依赖及其版本；
输入数据或配置的标识；
必要的硬件和资源约束；
随机种子或其他不确定性来源。

如果某个版本没有影响结果，就不必把它放进主要叙事，可以留在附录或锁文件中。

把失败尝试写成决策证据

失败记录不是流水账。每次尝试只回答四个问题：

当时基于什么假设？
做了哪一个最小改动？
观察到了什么证据？
这个证据排除了什么可能？

这样写可以保留真正的推理路径，也能防止同一个无效方案以后被重复尝试。

明确定义“完成”

“没有报错”通常不是完成标准。以一个自动化任务为例，可以分层验证：

1进程层：任务是否仍然运行
2日志层：是否存在未处理异常
3产物层：预期文件是否完整生成
4指标层：关键数值是否满足约束
5评估层：产物是否通过独立验证

只有最接近真实目标的那一层，才能支持最终结论。

给未来的自己留下入口

文章结尾应包含一段最短复现路径：从哪里取得代码、执行什么命令、预期看到什么，以及常见失败时先检查哪里。它不需要代替完整文档，但应该让几个月后的自己能够快速重新进入问题。

好的实践记录不是把过程写得更长，而是把关键判断写得更清楚。