当天记录问题#

遇到问题时先记下原始现象：报错信息、命令、输入文件、系统环境。不要等问题解决后只写结论，因为最有价值的往往是中间定位过程。

草稿只解决一个主题#

一篇日更文章不需要覆盖整个知识体系。比如今天只讲 pip 下载超时处理，就不要顺手扩展到完整 Python 环境管理。

主题越小，越容易写具体，也更适合作为以后检索的入口。

发布前做三次确认#

• 标题是否能独立表达问题。

• 正文是否有可执行步骤，而不是只有感想。

• 结尾是否写清楚这次经验下次如何复用。

每周回看栏目#

每天写会产生很多单点文章，每周应该回看一次分类结构，把相关主题串起来。这样博客不是流水账，而是逐步形成知识地图。

实战复盘#

复盘《每日写作节奏整理》时，我会把它当成一个站点维护动作，而不是单篇文章。凡是影响首页、分类、RSS、Sitemap、搜索索引或旧链接的改动，都要在发布后做一次线上验证。

如果只在源码里看起来正确，但线上接口或页面没有变化，就说明构建或发布链路还有问题。博客维护类内容必须把“怎么确认已经生效”写清楚。

以后继续扩展这类文章时，可以补充真实命令输出、截图前后的差异，以及回滚路径。这样文章会更接近操作手册，而不是零散备忘。

最小验收样例#

验收《每日写作节奏整理》时，我会选一篇真实文章或一个真实页面作为样例，而不是只看源码。先确认页面能打开，再确认列表、分类、归档、搜索这些入口都能找到它。

如果文章讲的是站点维护，还要记录修改前后差异：改了哪个文件、构建产物是否更新、线上 HTTP 状态码是多少。这样后面出问题时，可以直接回到这次验收记录。

小结#

每日写作的核心是把真实问题及时沉淀。少写空泛总结，多保留场景和步骤，长期看才会变成有用的技术资料。