这个目录不是普通笔记目录，也不是问答记录归档。
它的目标是把每一次学习都沉淀成可以长期复用、持续扩展、直接服务于工作、项目、面试、考试、排障和复盘的高质量知识资产。
后续通过这个 README 生成的笔记，目标标准不是“看过了”，而是尽量帮助我达到下面这种状态：
- 能讲清原理
- 能写出代码
- 能看懂别人代码
- 能独立调试问题
- 能应对项目落地
- 能应对工作中的真实压力
- 能应对面试、考试、问答和突发故障
- 能把知识迁移到新场景，而不是只会做原题
一句话概括：
这个目录要服务的是“稳定能力的积累”，不是“信息的堆积”。
后续所有笔记，都要尽量朝下面这几个方向服务：
- 不只记结论，要尽量理解底层机制。
- 不只知道怎么写，还要知道为什么这样写。
- 不只知道正确写法，还要知道错误写法为什么错。
- 笔记最终应能帮助我在真实项目中写代码、改代码、查问题、做设计。
- 内容要尽量贴近实际开发，而不是只停留在课本定义。
- 学会一个点后，应该能迁移到相似问题、相似系统、相似项目中。
- 不允许把知识写成只能应付当前题目的“孤立答案”。
- 每篇笔记都应当能作为以后复习、速查、排障、讲解、面试准备的资料。
- 内容应当可独立阅读，不依赖当前聊天上下文。
- 目标不是“平时看懂”，而是“在工作、考试、面试、故障、赶进度时也能拿出来用”。
- 笔记必须包含排错、边界、易错点、验证方法，而不是只有理想路径。
- 所有学习内容都应尽量回答：它在 AI 大趋势下还能怎样提升我的工作效率、理解能力、交付能力或竞争力。
- 不只学“传统知识点本身”，还要思考它如何与 AI 工具、自动化流程、知识管理和工程协作结合。
- 即使是基础知识，也应尽量说明它为什么仍然重要，以及它在 AI 时代能作为什么底层能力支撑我。
- 所有新笔记默认全部用中文写。
- 标题、正文、解释、代码解读、排查思路、复盘内容，统一用中文表达。
- 命令、代码、配置名、函数名、接口名保持原样，不做生硬翻译。
- 文件名不带日期，不带编号。
- 旧的日期命名规则从现在开始废止。
- 笔记强调主题组织，不强调时间顺序。
- 文件名格式统一为：
主标题-副标题.md - 主标题表示大的知识域，副标题表示具体主题。
- 主标题和副标题之间用半角短横线
-连接。
例如：
Linux-Shell.mdLinux-文件系统.mdLinux-进程管理.mdC语言-指针.mdUART-中断接收.mdFreeRTOS-任务通信.mdBootloader-启动流程.md
- 每个问题默认整理成一篇独立笔记。
- 但这篇笔记必须写成“长期可复用”的知识节点，而不是一次性回答。
- 如果是已有主题的延伸，也单独成文，并在文末注明关联笔记。
- 不依赖“上一条聊天记录”才能理解。
- 不依赖“我自己知道上下文”才能看懂。
- 以后单独打开这篇文件，也应该知道它在讲什么、怎么用、适用于什么场景。
- 新笔记在保存时，要根据标题和内容判断它属于哪个知识域、哪个模块、哪个层级。
- 文件存放位置应服务于后续查找、复习、扩展和关联，不允许随意堆在根目录或错误目录。
- 如果一个主题明显属于已有目录，就必须放入对应目录；如果形成了新的稳定主题，再建立新目录。
- 外设相关主题如果后续会持续积累，应优先归入
外设目录；例如 GPIO、UART、I2C、SPI、CAN、PWM、ADC、DAC、RTC、Watchdog 等。 - 如果目标是服务嵌入式工作衔接，目录组织优先围绕稳定工作主线展开：
C_C++、硬件、外设、通信协议、RTOS、Linux、驱动开发、板级与启动、工具链与调试、项目与架构。 - 目录组织优先服从主题归类，而不是创建时间、记录顺序或临时来源。
- 后续新增要求时，必须先区分它属于“对笔记的要求”还是“对内容的要求”。
- 新需求产生后，应直接写入
README对应位置，但写入前必须查重；能合并到旧规则的，不重复新增。
后续所有笔记相关规则，默认按下面两类理解和维护。
- 约束“这篇笔记怎么组织、怎么命名、怎么存放、怎么检查”的要求，都属于对笔记的要求。
- 例如：文件名格式、目录归属、标题结构、模板模块、关联笔记、质量检查清单、保存流程。
- 约束“这篇笔记具体要讲什么、讲到多深、如何证明、如何迁移”的要求，都属于对内容的要求。
- 例如：是否讲清本质、是否给示例、是否解释代码、是否包含调试与边界、是否体现 AI 时代价值。
- 出现新需求时，先判断它属于哪一类，再写入对应章节。
- 写入前必须先检查
README是否已有同义、近义或可合并条目。 - 已有规则能覆盖的，不重复新增；需要强化的，直接补充到原规则。
- 只有当新需求无法被现有规则准确承载时，才新增独立条目。
- 不只解释表面概念，要尽量写清本质、机制、数据流、控制流、边界条件、常见误区。
- 避免空泛定义、模板化套话、无信息量重复。
- 每一段都要有真实知识增量。
- 不能只讲“是什么”，必须尽量讲“怎么做、怎么用、怎么验证、怎么排错、怎么迁移”。
- 能用代码、命令、配置、实验、日志、调试器解释的地方，优先不用纯口头描述。
- 优先保留项目中真的会用到的内容。
- 结构清晰，先结论，再展开。
- 标题命名直接，不写空标题。
- 内容分段要服务于理解，不要堆格式，也不要写成大段无重点长文。
- 读者应能快速抓到：核心结论、适用场景、关键风险、验证方法。
- 每篇笔记都应是可以继续追加、关联、深化的长期知识节点。
- 笔记之间应能建立主题网络，而不是孤立散点。
- 能和已有主题关联的，必须加“关联笔记”。
- 重要结论尽量通过代码、命令、运行结果、边界输入、日志、调试过程验证。
- 不允许大量依赖“想当然”“经验上大概是这样”。
- 能验证的知识尽量都要给验证方式。
- 每篇笔记都尽量回答：
- 这个知识在什么场景有用？
- 它能迁移到哪些项目？
- 它和相近概念的区别是什么？
- 什么时候不该用它？
- 强调真实开发中的接口设计、错误处理、日志、调试、性能、内存、并发、可维护性。
- 不只停留在“能跑起来”，还要关注“是否可靠、是否好查错、是否可扩展”。
- 学完一个主题后，要尽量能沉淀：
- 我以前哪里理解错了
- 现在真正理解了什么
- 下次再遇到类似问题应如何更快定位
- 每篇笔记都尽量服务于“我能清楚讲给别人听”。
- 不只帮助写代码，也帮助回答问题、解释原理、做技术沟通。
- 能够支持 30 秒、3 分钟、10 分钟三种不同深度的表达。
- 不堆历史背景，不堆百科式介绍，不堆空话。
- 不为了“显得全面”而写得冗长松散。
- 优先保留：原理、本质、示例、坑点、调试、边界、工程影响。
- 每篇笔记都尽量说明：这个知识在 AI 大趋势下为什么值得学。
- 要尽量体现它如何帮助我更好地使用 AI、配合 AI、校验 AI、超越只会调用 AI 的浅层能力。
- 如果某个主题暂时看起来和 AI 不直接相关，也应尽量指出它对应的底层工程能力、判断能力或问题拆解能力。
如果一篇笔记真正学懂并掌握，理想上应尽量让我达到下面六层能力：
- 知道这个概念是什么。
- 能解释它为什么存在、解决什么问题、与相似概念有什么区别。
- 能独立写出最小可运行示例。
- 遇到错误现象时，能提出合理怀疑、定位路径和验证方法。
- 能把这个知识迁移到相似模块、相似系统或相似项目中。
- 能把它讲给同事、面试官、同学或未来的自己听清楚。
如果一篇笔记只能做到“看懂”，做不到后面几层，就说明这篇笔记质量还不够。
默认建议每篇笔记都尽量包含以下模块：
- 先给结论
- 这个知识解决什么问题
- 核心概念和本质机制
- 数据流 / 控制流 / 时序关系
- 最小可运行示例
- 代码解读
- 正确写法 vs 常见错误写法
- 边界条件和适用范围
- 常见坑、常见报错、常见误区
- 调试方法和验证方法
- 工程场景如何落地
- 性能、稳定性、可维护性影响
- 问答时应该怎么讲
- 实战练习
- 关键要点
- 关联笔记
如果某类主题不适合所有项，可以裁剪，但至少要保留：
- 结论
- 本质
- 示例
- 解读
- 坑点
- 调试
- 迁移
- 代码类主题：尽量给最小代码。
- Linux 类主题：尽量给命令和命令结果解读。
- 配置类主题：尽量给最小配置片段。
- 驱动类主题：尽量给关键路径代码或伪代码。
每段关键代码都尽量解释：
- 这段代码解决什么问题
- 为什么要这样写
- 关键语句在做什么
- 如果改错会出什么问题
- 如何验证它确实生效
- 示例可以小，但不能假到脱离实际。
- 优先贴近真实开发中的写法、接口、错误处理和边界情况。
- 让笔记不仅告诉我“正确答案”，也告诉我“常见错误长什么样”。
- 这样更有利于排错和面试反问。
例如：
- 如何编译
- 如何运行
- 预期输出是什么
- 异常输出是什么
- 如何通过日志、断点、示波器、抓包、打印、寄存器或命令确认结果
后续所有笔记，默认都要尽量同时服务下面五种场景。
- 让我从不会到会。
- 让我以后快速回忆，不需要重新从零看资料。
- 让我在项目开发、代码阅读、接口设计、问题定位时直接能用。
- 让我能把问题讲清楚，而不是只会写代码不会表达。
- 让我在出问题时能快速建立怀疑链、验证链和修复链。
如果一篇笔记只适合“看一遍”，而不适合这五种场景，就不算合格。
- 先讲为什么，再讲是什么，再讲怎么做。
- 先让我把一个最小可运行流程跑通。
- 再往工程化、复杂场景、边界条件扩展。
- 先把主要逻辑讲清，再补充例外情况和复杂点。
尽量加入：
- 相近概念对比
- 正确写法 vs 错误写法
- 裸机 vs RTOS
- Linux 用户态 vs 内核态
- 同步 vs 异步
- 阻塞 vs 非阻塞
尽量回答：
- 它为什么存在？
- 不用它会怎样？
- 它解决了哪个具体问题？
- 它的代价是什么？
- 它的边界在哪里？
- 不允许只整理结论，不整理推理过程。
- 不允许只有结果，没有验证。
- 不允许只有 API，没有应用场景。
每篇笔记都尽量帮助我形成长期记忆，而不是短期印象。
- 用最短的话把最重要的原则提炼出来。
- 让我从“看懂”转成“自己能做”。
- 哪些地方最容易误解
- 哪些地方最容易在项目里出问题
- 哪些地方最容易在面试里被追问
- 学完这个主题，下一步该学什么
- 它和哪些主题强相关
如果主题和代码、系统、协议、驱动、工具链有关，默认尽量加入：
- 错误输出是什么
- 异常表现是什么
- 可能错在哪些地方
- 先看什么
- 再看什么
- 最后如何缩小范围
- 如何证明问题真的解决，而不是偶然消失
- 如何在以后避免类似问题再次出现
每篇笔记都尽量能支持三种表达深度：
- 用一句话说清核心作用和本质。
- 讲清原理、场景、优缺点、常见坑。
- 能结合代码、数据流、边界条件、调试经验展开讲解。
如果一个主题我自己看懂了，却讲不清，说明掌握还不够。
后续笔记应尽量体现下面这些真实开发能力：
- 模块边界怎么划分
- 接口应该怎么设计
- 错误处理怎么做
- 日志和断言怎么加
- 如何写得更可维护
- 如何避免未来改动把系统弄坏
- 如何做最小验证
- 如何做回归验证
- 如何权衡性能、复杂度、可靠性
- 使用：
主标题-副标题.md - 不带日期
- 不带编号
- 不使用无意义缩写
- 一级标题默认与文件主题一致。
- 推荐写法：
# Linux-Shell# Linux-文件系统# C语言-指针# FreeRTOS-任务通信
- 新笔记如与旧主题有关，必须增加“关联笔记”一节。
- 关联不是为了凑数，而是帮助形成知识网络。
- 保存笔记前，先根据文件标题和正文内容判断它最适合放在哪个主题目录。
- 如果内容跨多个主题，优先放到“主要问题所服务的知识域”下，而不是放到最宽泛的目录。
- 如果现有目录已经能准确承载该主题，不重复新建相近目录。
- 如果该主题会持续积累，且现有目录无法清晰容纳，再创建新的主题目录。
- 如果主题主线是外设本身的原理、初始化、时序、调试和迁移，优先放入
外设；如果主线是 Linux 框架或更底层硬件本质，则仍放在Linux或硬件。 - 如果主题主线是协议帧格式、校验、重传和状态机，优先放入
通信协议；如果主线是任务调度和同步，优先放入RTOS。 - 如果主题主线是驱动模型、资源申请和 probe 流程，优先放入
驱动开发；如果主线是启动链路和板级 bring-up，优先放入板级与启动。 - 如果主题主线是调试方法、观测手段和验证路径，优先放入
工具链与调试；如果主线是模块边界、接口和长期维护，优先放入项目与架构。
# 主标题-副标题
## 原始问题和可扩展的大主题
## 先给结论
## 这个知识解决什么问题
## 核心概念 / 本质机制
## 数据流 / 控制流 / 时序关系
## 最小可运行示例
## 代码解读
## 正确写法 vs 常见错误写法
## 边界条件与适用范围
## 常见坑与排查
## 工程落地建议
## 面试 / 问答怎么讲
## 实战练习
## 关键要点
## 关联笔记写完一篇笔记后，默认逐项检查：
- 是否全篇使用中文，且没有混入无意义时间信息？
- 文件名是否是“主标题-副标题”格式？
- 是否解释了这个知识解决什么问题？
- 是否讲清了本质，而不是只罗列表面现象？
- 是否有最小可运行示例、命令示例或配置示例？
- 是否对关键代码做了解读？
- 是否给出了正确写法和常见错误写法？
- 是否写了边界条件、适用范围和不适用场景？
- 是否写了常见坑、错误现象和排查路径？
- 是否说明了如何验证代码或结论正确？
- 是否说明了工程里如何落地，而不只是教材层面？
- 是否说明了这个知识如何迁移到相似问题？
- 是否提炼出了关键要点，方便以后快速复习？
- 是否能支撑我在学习、复习、工作、面试、排障五个场景中复用？
- 是否删掉了废话、空话、背景堆砌和无信息量重复？
- 是否放到了与标题和内容相匹配的主题目录下？
- 是否说明了这个知识在 AI 大趋势下的适应价值、协作价值或竞争力价值？
后续处理每个新问题，默认按这个流程执行：
- 识别主题和模块归属
- 根据标题和内容判断应存放的主题目录
- 提炼背后的核心知识点
- 判断这篇笔记未来主要服务哪些场景
- 判断该主题在 AI 大趋势下的适应价值或竞争力价值
- 先写结论和主线
- 补充本质机制和最小闭环
- 补充代码、命令、配置和解读
- 补充坑点、边界、调试、验证和迁移建议
- 加入练习、关键要点和关联笔记
- 检查是否符合质量清单
- 按
主标题-副标题.md保存到合适目录 - 如果出现新的长期规则，先判断它属于“对笔记的要求”还是“对内容的要求”
- 将新规则合并写入
README对应位置，并检查没有重复表达
- 只有概念，没有示例
- 只有示例，没有解释
- 只有正确写法，没有错误写法
- 只有 happy path，没有坑点和排错
- 只有 API 罗列，没有使用场景
- 只有当前问题答案，没有迁移能力
- 只有零碎知识点，没有结构
- 只有很长的背景介绍，没有可执行内容
- 只有“记住这个结论”，没有为什么
- 只有表面现象，没有本质机制
这个目录未来应该逐步变成我的：
- 个人技术知识库
- 项目实战参考库
- 面试与表达准备库
- 代码与调试经验库
- 长期成长复盘库
最终目标不是“我看过多少内容”，而是：
当我面对工作任务、项目压力、技术面试、考试追问、线上故障或陌生问题时，这套笔记能让我更快理解、更快定位、更快表达、更快落地，并且更不容易慌。