---
name: recording
description: 用户明确要求整理学习过程、撰写学习日记或保存相关内容时使用。没有记录需求时，不要自动生成日记。
---

# Recording

帮助用户把一次学习中值得留下的过程整理成记录，让以后重新阅读时，还能理解当时为什么这样想、遇到了什么问题，以及后来是怎么想明白的。

## 从学习对话中选择要记录的内容

先回顾本次实际发生的讨论，找出对理解有影响的部分。通常包括用户最初的想法、遇到的疑问或矛盾、推动理解变化的讨论，以及最后形成的认识。具体保留哪些内容，要看这次学习实际发生了什么，不需要每篇记录都包含相同的环节。

把这些内容之间的联系写清楚。不要逐条复述聊天，也不要只列出知识点和技术名词。与理解无关的闲聊、重复解释和旁支内容可以省略；如果某个分支解释了主线中的关键问题，就保留它与主线的关系。

如果用户在原来的学习对话中调用 Recording，就直接利用当前对话整理，不需要 Learning 先生成一份额外交接报告。如果用户在另一个对话中调用，而原来的学习过程并不在当前上下文里，就不要假设自己能看到完整记录；先利用实际可访问的资料，缺少关键内容时再请用户提供原对话或相关片段。

## 把过程写成连贯的个人笔记

记录应当像用户自己的学习笔记，不要写成 AI 对用户的学习评估，也不要重新写成一篇面向读者的知识教程。

参考用户真实的日记样本，了解其书面表达、叙述节奏和段落组织。当前对话用于确认本次实际发生的事情；历史日记用于参考文风，不能把旧日记中的经历或结论混入本次记录。

用户习惯自然、直接、平铺直叙的表达。通常先讲自己怎么想，再讲遇到的问题和后来的理解。保留真实的疑惑和转折，不刻意拔高或说教，也不要机械套用 AI 常见的总结句式。不要把「不是……而是……」「最值得记住」当作用户惯用的表达。

## 如实呈现认识是怎样形成的

区分用户最初的想法、AI 后来提供的解释，以及双方经过讨论后形成的结论，并按照实际发生的过程组织内容。

用户最初的猜测应保留为猜测；AI 后来补充的解释不能写成用户一开始就知道的内容；用户表示某个地方理解了，也只代表对话能够支持的具体范围。代码是否完成、运行或提交，同样要以实际情况为准。不要补写没有依据的心理活动、感受或学习成果。

## 根据需要保留代码和其他资料

正文以思考过程为主。代码、公式、图表和参考资料可以作为补充内容保留，是否需要取决于本次记录的用途。正文说明它们与学习过程的关系即可，不必把整份代码或资料重复写进叙述。

算法题日记可以沿用现有的日期、题目链接、简短题意、正文和代码折叠区域；源码分析、论文阅读或其他主题则根据内容选择合适的形式，不必套用算法日记的格式。「口诀」只在确实出现了能跨多个题目复用的经验时考虑，不为每篇记录强行添加。

用户只想保存一个结论或一段代码时，就按要求的范围整理，不扩展成完整日记。用户只要求草稿时，先提供草稿；用户明确要求写入 Notion 或其他位置时，再按现有页面结构保存，并确认是否成功。

## 写作样本

具体的个人日记样本放在 [references/examples.md](references/examples.md)。撰写记录时参考样本的表达方式，但不要复制原句，也不要把每篇日记写成相同的模板。