论文会越读越多，仿真会越跑越复杂，想法也会在几个月后被新的问题覆盖。如果没有一个稳定的记录系统，很多当时觉得重要的理解会慢慢变得模糊。于是有了这个博客。

为什么选择公开写作

公开写作有几个很实际的好处。

第一，它迫使我解释清楚。 一个概念如果只能模糊地说“我大概懂了”，往往说明还没有真正理解。把推导、假设和结论写成别人能读的句子，会暴露很多自己以为懂了、其实没想清楚的地方。

第二，它留下了时间线。 以后回看时，我不只想知道最后用了什么方法，还想知道当时为什么排除了另一条路。失败、犹豫和修改的过程，往往比最终结果更有信息量。

第三，它可以被搜索。 一个按主题分类、按关键词打标签的个人知识库，比散落在电脑各处的 Word 文档更容易复用。

这里会写什么

博客的内容大致分为几类：

• 论文阅读：重要论文的问题、方法、实验与局限；
• 实验记录：参数、环境、结果和异常现象，尽量让工作可复现；
• 工具方法：Zotero、LaTeX、Git、Python/MATLAB 等工作流；
• 科研随想：关于研究方向、学习节奏和读研生活的阶段记录。

分类负责较大的主题边界，标签负责更细的关键词。例如，一篇关于新能源并网的论文笔记，可以归入「论文阅读」，同时打上 新能源、并网、稳定性 等标签。

给自己定的三个原则

1. 记录过程，而不只展示结果。 不确定的地方、失败的尝试和被推翻的想法都应该保留。
2. 先完成，再完善。 不等到“完全读懂”才开始写，写作本身就是整理思路的过程。
3. 让未来的自己能找到。 标题具体、日期准确、分类克制、标签有用。

这个网站还很新，内容会随着研究生阶段的学习逐步生长。希望几年后回头看时，这里留下的是一条清晰可辨的成长轨迹。

下面是我准备长期使用的阅读模板。它不追求写得长，而是尽量让几个月后的自己能够快速想起来：为什么读它，它到底贡献了什么。

一、论文基本信息

不建议直接把出版社 PDF 上传到公开仓库。论文原文用 DOI 或官方链接记录，公开博客里放自己的笔记、图表重绘和引用即可。

二、它试图解决什么问题

用自己的话写清楚：

1. 这个问题在工程或理论中的具体表现是什么？
2. 为什么现有方法不够好？是精度、效率、可解释性、成本，还是适用场景受限？
3. 论文明确说明了哪些假设与边界条件？

这一部分尽量不要抄摘要。如果无法用自己的语言复述，说明还没有抓住论文的主线。

三、方法拆解

面对一个方法，我通常按下面的顺序拆：

• 输入与输出：模型或算法接收什么、输出什么；
• 核心假设：哪些条件成立时方法才有效；
• 关键步骤：用伪代码或流程图描述，而不是只写公式；
• 与已有工作的差异：它替换了哪个环节，为什么这样替换；
• 复杂度与代价：计算量、数据需求、参数敏感性。

如果论文里有重要推导，至少自己重推一遍关键一步，并记下卡在哪里。卡住的地方往往就是理解最薄弱的地方。

四、实验是否支撑结论

读实验部分时，我会问四个问题：

1. 对照是否公平？ 基线是否使用了同等的数据、预算和调参力度？
2. 指标是否回答了问题？ 指标提升是否真的对应工程意义上的改善？
3. 消融是否充分？ 哪个模块真正带来了收益？
4. 结果是否稳定？ 是否报告了多次实验、方差、极端情况和失败案例？

把“论文声称的贡献”和“实验直接支持的结论”分开记录，能避免把作者的解释当成事实。

五、局限与可借鉴之处

这一节可以写得更主观：

• 我认为最薄弱的假设是什么？
• 如果换一个数据集、工况或规模，结论还成立吗？
• 哪些方法可以迁移到我的方向？
• 是否有可以复现的小实验？需要哪些数据与工具？
• 它是否启发了新的问题，而不只是一个可引用的结果？

六、可直接复制的 Markdown 模板

---
title: 【论文笔记】论文标题
date: YYYY-MM-DD HH:mm:ss
categories:
  - 论文阅读
tags:
  - 论文笔记
description: 用一两句话写清楚这篇论文解决的核心问题。
---

## 基本信息

- 题目：
- 作者：
- 出处：
- DOI / 链接：

## 研究问题

## 方法与关键假设

## 实验设计

## 主要结论

## 局限与我的判断

## 可迁移的想法

写完之后再检查一遍

• 标题能让未来的我一眼想起主题；
• 分类和标签没有重复堆叠；
• 至少有一处是自己的判断，而不是复述；
• 公式、图号和引用能对应回原文；
• 记录了下一步可以做什么。

阅读笔记的价值不在于数量，而在于能不能成为下一次研究的起点。

实验记录的目的不是把终端日志复制一遍，而是让工作具备可复现性：换一台机器、换一个时间点，仍然能够解释结果是怎么来的。

一、实验基本信息

二、运行环境

• 操作系统与版本：
• 仿真软件 / 编程语言及版本：
• 关键依赖及版本：
• 硬件：CPU / GPU / 内存；
• 随机种子（如有随机过程）：

环境信息看似琐碎，但“在我电脑上能跑”不是可复现性。版本差异常常是结果不一致的第一来源。

三、变量与参数

先写清楚哪些是自变量、哪些是控制变量、哪些是要观测的指标。尤其要记录与默认值不同的参数，以及调整它们的原因。

有公式时，直接把定义写下来，避免不同脚本中的计算口径不一致。例如用均方根误差比较预测值与真实值：

四、执行步骤

写成一个可以照着重新执行的最小步骤列表：

1. 从哪个提交或压缩包开始；
2. 如何准备输入数据；
3. 运行哪个入口脚本；
4. 输出保存在哪里；
5. 后处理脚本是什么。

如果命令很长，至少记录入口文件和关键参数。不要只写“运行了主程序”。

五、结果与证据

除了最终指标，还要记录：

• 与基线相比的变化幅度；
• 重复运行时的波动；
• 出现了哪些异常点或不收敛情况；
• 哪张图、哪个文件是这次实验的有效证据。

六、解释与下一步

结果本身不会告诉我们原因。需要区分：

• 观察到的现象：例如误差下降，但某类样本明显变差；
• 暂时接受的解释：为什么会出现这个现象；
• 尚未排除的替代解释：还有哪些可能；
• 下一步实验：为了区分这些解释，应该改哪个变量。

七、可直接使用的日志骨架

## 实验目的
## 对应代码版本
## 运行环境
## 输入与参数
## 执行步骤
## 结果（指标 / 图 / 文件路径）
## 异常与失败记录
## 我的解释
## 下一步

一份好的实验日志，应该让未来的自己不必重新猜测，也让合作者能够在同一基础上继续工作。