把大语言模型当“编程书”用：从聊天到LLM Wiki知识库

如果你手里有一个大语言模型，却只把它当成“对话框里的万能助手”，问一句答一句，那大概率会陷入两种困惑：第一，它经常给一些听起来很专业、但仔细一推敲就不太对劲的答案；第二，每次解决完一个问题，下次遇到类似场景，你还是得重新组织一遍提问，知识完全没有沉淀下来。

一个更值得尝试的视角是：把 LLM 当作一本“编程书”来读。不是一张会回答问题的嘴，而是一套压缩了大量人类技术知识的参考书。你要学会怎么翻目录、怎么精读某一章、怎么把前面的示例代码复制下来跑一遍，以及怎么在书页边上写自己的批注。

这个类比不是文字游戏。它直接决定了你的使用姿势、工具链、提问策略和验证方法。本文会拆解“把大语言模型当编程书用”背后的逻辑，并给出一套可以从今天开始落地的个人知识库搭建方案。你会看到一个关键词：LLM Wiki 范式，也就是把模型、笔记、检索和提示词组合成一本随时可以增删改查的技术手册。

1. 为什么“聊天机器人”视角会让你事倍功半

先做一个思想实验。你翻一本 Redis 手册时，目标通常很明确：查某个命令的参数、确认某个数据结构的过期策略、对比两种做法的性能差异。你不会要求手册“用温暖鼓励的语气回答”，也不会问它“你觉得 Redis 和人生有什么关系”。你的动作是定位、阅读、对照、实践。

但现在大部分人用 LLM 的方式，仍然停留在“聊天”阶段。对话里塞满了不必要的上下文轮次，同一个问题换一种说法就要重讲一遍背景，而且很少有人把模型给出的优质回答固化下来。结果就是：模型的能力上限摆在那里，但使用者的“信息获取效率”非常低。

把 LLM 当编程书，本质上是换了一个心智模型：

• 聊天机器人的隐喻是“人有问，它有答”，答案质量完全依赖临场发挥。
• 编程书的隐喻是“知识被结构化地组织在固定位置”，你可以按目录检索、按章节精读、按示例验证，也能随时把书合上，在另一台设备上继续。

这个心智模型的变化，会直接改变三个层面的行为：

1. 提问方式：从“你觉得这个问题怎么解决”变成“请根据第 2 章关于正则回溯的描述，解释下面这段代码为什么会卡住”。
2. 知识管理：从“对话记录丢在历史列表里”变成“把答案提取出来，写进自己的知识库笔记，并挂上检索标签”。
3. 结果验证：从“它说得对我就信”变成“书上的示例代码必须先跑一遍，跑通才承认这段知识有效”。

这才是“LLM 应用为什么需要编排框架”这个问题的底层答案：不是模型本身不够强，而是你需要一套类似“书的结构”的编排方式，才能稳定地、可复用地从模型里获取知识。

2. “编程书”这个类比为什么成立

大语言模型的训练方式，本质上是让模型在超大规模文本上学习语言规律和知识分布。你可以把它理解成一本“超厚编程书”的成书过程：作者不是一个人，而是互联网上几乎所有公开的代码仓库、技术文档、博客文章和问答社区。

但这本书有两个非常重要的特点，和普通编程书完全不同。

第一，它没有一个“物理目录”。普通编程书会在前言列出章节结构，告诉你第几章讲什么。LLM 把这个目录隐式编码进了参数里。你知道它“大概知道”很多东西，但你不给提示，它不会自动展开给你看。这就像一本书的目录被藏起来了，你必须通过检索词（提示词）去定位。

第二，它的每一页都是“重新渲染”的。同样一句话，你换个语气提问，得到的文字可能不同。它不是逐字存储原文，而是以概率方式重建最合适的表达。这意味着：它给的不是原文照片，而是基于训练内容的“考题答案”。如果你没有验证机制，就会被这种流畅的表达误导。

不过，正因为如此，“编程书”这个类比反而有一个普通书没有的优势：它可以按需重排。

想象一本编程书里的内容可以从“章节模式”切换成“速查手册模式”再切换成“练习题模式”。比如你输入一段代码，它能在几秒钟内把“书里”所有相关知识重新组织成一份代码审查意见；你输入一个概念名，它能把几十页相关的背景浓缩成一段话。这种能力决定了它更适合作为“编程参考书”来用，而不是单纯的“问答机”。

最近 Andrej Karpathy 在技术社区里提到的“LLM Wiki”范式，方向也是类似的：把 LLM 当成一本可以对话、可以索引、可以不断往里写新条目的知识库。不是让模型扮演全知全能的神，而是让模型成为一本“活页式编程书”——你可以加页、删页、做批注，也可以按需检索。

3. 编程书的三种阅读方式：检索、精读、验证

如果你接受“LLM 是一本编程书”这个前提，接下来要掌握的就是怎么“正确地读”这本书。普通编程书一般有三种阅读方式，LLM 恰好也有对应操作。

3.1 检索：像翻目录一样写提问

普通编程书的目录是静态的，而 LLM 的目录需要通过提示词来激活。要激活到正确的“章节”，提问里最好带上三样东西：技术领域、具体问题、期望输出形式。

反例：

帮我看看这个报错

正例：

我在用 Python 的 asyncio 编写并发下载任务时，遇到 RuntimeError: Event loop is closed。请回答以下内容： 1. 这个异常产生的常见原因 2. 在 Jupyter Notebook 和独立脚本中分别如何解决 3. 给出一段最小可复现代码和修复后的代码

前一种提问就像对着整本书说“帮我找到 bug”，后一种提问则相当于直接翻到了“第 8 章 异步编程常见异常”这一节。模型不是更聪明了，而是你给了它更精确的“页码”。

3.2 精读：把一个主题问透

普通编程书里，精读意味着你不仅看正文，还会对照代码清单、图表和脚注。在 LLM 里，精读就是“多轮追问同一个知识点，但每一轮只问一个层面”。

例如，你要搞懂 Redis 的持久化机制，可以按如下顺序追问：

1. RDB 和 AOF 的核心区别是什么？
2. AOF 的三种写回策略分别有什么风险？
3. 如果服务器突然断电，最多可能丢失多少数据？
4. 用一张表格对比 RDB、AOF、混合持久化在恢复速度、文件大小、数据安全性三个维度上的优劣。

注意，每一轮都是在前一轮的基础上“深入一小层”，而不是让模型重新生成一篇泛泛而谈的科普。前者是精读，后者只是把书翻到第一页反复读。

3.3 验证：书上写的代码必须跑一遍

这是“编程书”类比里最重要的一环。普通编程书里的代码可能有勘误，也可能因为环境版本变化而过时。LLM 生成的代码同样如此，甚至更容易出错。因为模型的工作机制决定了它不一定真的“执行”过这本书里的每一段代码，它只是在概率上组织出了看起来合理的代码文本。

因此，强烈建议使用“先写代码，再让模型解释，最后放进测试环境运行”的流程：

1. 让 LLM 生成一段最小示例或解决方案。
2. 把代码复制到项目里，用 pytest 或简单的 assert 断言验证关键行为。
3. 如果失败，把错误信息原样贴回给模型，并要求它基于错误信息修正。

这个流程越早形成习惯，越能避免“听模型说得头头是道，上线后才发现完全不是那么回事”。

4. 从“提问-回答”到“查询-验证”的工作流转变

很多开发者的 LLM 使用方式还是“一次性消费”：提问、得到答案、用完即走。这种模式很难产生复利效应，因为答案没有被结构化地沉淀下来。把 LLM 当编程书之后，工作流应该变成下面这样的闭环：

提问（带上下文和格式约束） -> 获取模型输出 -> 提取关键信息，写进自己的笔记 -> 给这段笔记补上标签和索引 -> 下次遇到类似问题时，先检索自己的笔记 -> 检索不到时，再向模型发起新一轮提问

这个闭环里，模型负责“生成书页”，你负责“装订成册”。如果缺少后半部分，那你每次都在重复买一本新的书，但没有一本真正属于你自己的书。

具体到工具链上，就是当前社区里讨论度很高的“LLM Wiki + 片段检索 + 个人知识库”组合。思路很简单：你把模型给出的高质量回答，以及自己整理的学习笔记，按主题拆成一条条“知识卡片”，然后用向量检索把它们索引起来。此后每次启动一个开发任务，先在自己的知识库里做一次语义检索，把相关卡片作为上下文注入到模型里，再让模型基于这些资料继续推理。

这样的好处有三个：

1. 减少模型“凭空发挥”的空间，因为你的资料已经提前垫进了上下文。
2. 你的历史经验和踩坑记录会持续参与后续推理，形成一个不断生长的知识库。
3. 即使某天换了一个模型，知识库仍在，不依赖于某个具体模型的口味。

下面我们从实操角度，把这个工作流完整搭建起来。

5. 实操：把 LLM 变成个人技术知识库（LLM Wiki 思路）

这一节的目标是搭建一个最小可用的“编程书阅读系统”，包含三部分：

• 本地模型服务（或任意可访问的模型 API）
• 一套按主题组织的笔记目录
• 一个简单的向量检索脚本，把笔记变成可检索的知识卡片

5.1 环境准备与工具选择

先明确一下整体技术栈。这里给你一套通用、可控的组合，也方便替换成你本来的习惯：

组件	作用	可选方案
模型服务	提供对话和生成能力	本地 Ollama / vLLM / 云厂商模型 API
笔记目录	存放格式化 Markdown 笔记	本地文件夹 / Obsidian 仓库
文本切分	把长笔记切成检索片段	LangChain 的 Text Splitter / 自写脚本
向量检索	按语义找相关笔记	Chroma / FAISS / sqlite-vec / 自建向量索引
提示词模板	规定检索后的回答方式	本地 Markdown 模板文件

如果你希望完全本地运行，推荐使用 Ollama 拉一个中尺寸的开源模型，比如 qwen2.5:7b。它有不错的编程能力，部署成本也比较低。安装好 Ollama 后，在终端执行：

ollama pull qwen2.5:7b ollama serve

Ollama 启动后，会监听本机的 11434 端口，你可以直接通过 HTTP 接口调用，这样后面写脚本时就不需要依赖特定厂商的 SDK。

5.2 最小调用函数：像翻书页一样请求模型

下面代码构造了 AskLLM 的最小封装。你传入一个系统提示词（相当于书的“使用说明”）和一个用户问题（相当于“检索的关键词”），模型返回回答。

# 文件路径：llm_book/llm_client.py import requests import json DEFAULT_MODEL = "qwen2.5:7b" OLLAMA_URL = "http://localhost:11434/api/generate" def ask_llm( prompt: str, system: str = "", model: str = DEFAULT_MODEL, temperature: float = 0.2 ) -> str: """向本地 Ollama 模型发起一次生成请求。""" payload = { "model": model, "prompt": prompt, "system": system, "stream": False, "options": { "temperature": temperature } } resp = requests.post(OLLAMA_URL, json=payload, timeout=120) resp.raise_for_status() return json.loads(resp.text)["response"] if __name__ == "__main__": system_msg = "你是一本 Python 异步编程参考书。请用结构化的方式回答问题。" question = "请解释 asyncio.create_task 和 asyncio.gather 的区别，并给出一段最小示例。" print(ask_llm(question, system=system_msg))

这个示例虽然是针对本地 Ollama 的，但换成任何兼容 OpenAI 格式的模型 API 也只需要改一处请求函数。关键在于：模型在这里扮演的是“编程书”，你通过 system 提示词规定这本书的种类和回答风格。

5.3 建立笔记目录：一本书的骨架

“书”不能只有模型，得有你自己沉淀的章节。我建议你的知识库目录按科目划分，文件名带序号，方便排序和定位。

personal-code-book/ ├── prompts/ │ ├── 01_retrieve.md # 检索式提问模板 │ ├── 02_deep_read.md # 精读式追问模板 │ ├── 03_code_review.md # 代码审查模板 │ └── 04_fix_bug.md # 根据报错修复模板 ├── notes/ │ ├── redis/ │ │ ├── 01_persistence.md │ │ ├── 02_cache_pattern.md │ │ └── 03_common_pitfalls.md │ ├── python-asyncio/ │ │ ├── 01_event_loop.md │ │ ├── 02_tasks_and_gather.md │ │ └── 03_debug_async.md │ └── llm-inference/ │ ├── 01_temperature.md │ ├── 02_context_window.md │ └── 03_hallucination.md ├── scripts/ │ ├── build_index.py # 切分笔记、生成向量索引 │ ├── search.py # 根据问题检索相关笔记片段 │ └── ask_with_context.py # 把检索结果注入提示词并询问模型 └── memory/ └── last_updated_model.md

这套目录的好处是：主题和文件一一对应，方便脚本读取；Markdown 格式也方便 Obsidian 等工具直接打开，配合本地知识库插件使用。

5.4 切分与建索引：给书做一个“真正可查的索引”

普通编程书的索引在最后几页，而你的个人编程书需要一个语义索引。这里给一个最小实现思路，不依赖重量级框架。

基本流程：

1. 递归读取 notes 目录下的所有 Markdown 文件。
2. 按标题或固定长度切分成片段。
3. 为每个片段生成向量。
4. 把向量和原文一起保存为 JSON 文件。

代码示例：

# 文件路径：personal-code-book/scripts/build_index.py import os import hashlib import json import re NOTES_DIR = "../notes" INDEX_FILE = "../memory/vector_index.json" def split_markdown_by_heading(text: str, max_chars: int = 800): """按二级标题切分 Markdown，超长段落再按句号切分。""" sections = [] current_heading = "未分类" current_buffer = [] def flush(): if current_buffer: section_text = "\n".join(current_buffer).strip() if len(section_text) > max_chars: for i in range(0, len(section_text), max_chars): sections.append({"heading": current_heading, "text": section_text[i:i + max_chars]}) else: sections.append({"heading": current_heading, "text": section_text}) for line in text.splitlines(): if line.startswith("## "): flush() current_buffer = [] current_heading = line[3:].strip() else: current_buffer.append(line) flush() return sections def hash_text(text: str) -> str: return hashlib.md5(text.encode("utf-8")).hexdigest() def main(): all_sections = [] for root, _, files in os.walk(NOTES_DIR): for fname in files: if not fname.endswith(".md"): continue path = os.path.join(root, fname) with open(path, "r", encoding="utf-8") as f: text = f.read() sections = split_markdown_by_heading(text) for sec in sections: all_sections.append({ "id": hash_text(sec["text"]), "file": path, "heading": sec["heading"], "text": sec["text"] }) # 用本地 embedding 模型给每个片段生成向量 # 如果你的环境里有 sentence-transformers，可以替换为： # from sentence_transformers import SentenceTransformer # model = SentenceTransformer("all-MiniLM-L6-v2") # vectors = model.encode([s["text"] for s in all_sections]) # 这里只保存原文，向量部分留给你实际环境对应的 embedding 服务生成 compact = [{"id": s["id"], "file": s["file"], "heading": s["heading"], "text": s["text"]} for s in all_sections] with open(INDEX_FILE, "w", encoding="utf-8") as f: json.dump(compact, f, ensure_ascii=False, indent=2) print(f"[build_index] 已生成 {len(compact)} 个知识片段，索引文件：{INDEX_FILE}") if __name__ == "__main__": main()

这里的注释部分特意留出了选择空间：不同环境的 embedding 服务不一样，为了不让代码绑死在某个库上，索引脚本先去重、保存文本片段，embedding 只作为补充步骤。实际项目里，你可以把真实向量填充到每一条记录里，然后用余弦相似度做排序。

5.5 检索并注入上下文

检索脚本负责把用户问题变成“知识书页”。它先计算问题向量和每个片段向量的相似度，取出 Top-K 片段，再把片段原文拼进 prompt，让模型基于这些片段回答。

# 文件路径：personal-code-book/scripts/ask_with_context.py import requests import json # 请根据实际环境替换为你的 embedding 服务或函数 def get_embedding(text: str): """示例：调用本地 embedding 服务，如果没有就返回 None。""" # 这里仅作为占位，实际请接入你的 embedding 服务 # 例如 Ollama 的 /api/embeddings 接口： resp = requests.post( "http://localhost:11434/api/embeddings", json={"model": "qwen2.5:7b", "prompt": text} ) resp.raise_for_status() return resp.json()["embedding"] def cos_sim(a, b): dot = sum(x * y for x, y in zip(a, b)) norm_a = sum(x * x for x in a) ** 0.5 norm_b = sum(x * x for x in b) ** 0.5 if norm_a == 0 or norm_b == 0: return 0.0 return dot / (norm_a * norm_b) def search_notes(question: str, top_k: int = 3): with open("../memory/vector_index.json", "r", encoding="utf-8") as f: sections = json.load(f) q_vec = get_embedding(question) ranked = [] for sec in sections: sec_vec = get_embedding(sec["text"]) score = cos_sim(q_vec, sec_vec) ranked.append((score, sec)) ranked.sort(key=lambda x: x[0], reverse=True) return [sec for _, sec in ranked[:top_k]] def ask_with_context(question: str): hits = search_notes(question) context_blocks = [] for hit in hits: context_blocks.append( f"文件：{hit['file']}\n章节：{hit['heading']}\n内容：\n{hit['text']}" ) context = "\n\n---\n\n".join(context_blocks) prompt = f"""请根据下面的知识库片段回答技术问题。 【知识库片段】 {context} 【问题】 {question} 回答要求： 1. 优先使用知识库中的观点，不要编造知识库不存在的细节 2. 如果知识库不足以回答，请明确说明缺少哪部分信息 3. 格式使用 Markdown 列表或代码块 """ payload = { "model": "qwen2.5:7b", "prompt": prompt, "stream": False } resp = requests.post("http://localhost:11434/api/generate", json=payload, timeout=120) resp.raise_for_status() return resp.json()["response"] if __name__ == "__main__": question = "Redis 持久化时如果突然断电会丢失多少数据？" print(ask_with_context(question))

这段脚本的价值在于：它不是让模型凭空回答，而是先从你自己的知识库笔记里“翻到那一页”，再根据那一页内容组织回答。这正好对应“使用编程书”而不是“让模型编一本编程书”。

5.6 提示词模板：把常用阅读姿势固化

除了知识检索，提示词模板也应该像书签一样存下来。下面是一份“代码审查”模板，你可以放在 prompts/ 目录里：

# 03_code_review.md ## 角色 你是一名对代码质量和性能敏感的高级开发工程师。 ## 任务 审查下面这段代码，分别从以下维度输出意见： 1. 正确性：是否存在逻辑错误或边界问题 2. 性能：是否存在不必要的循环、频繁分配或阻塞调用 3. 可读性：命名和结构是否清晰 4. 安全隐患：是否存在注入、敏感信息泄露、权限绕过等风险 ## 代码 ```python # 把待审查代码粘贴到这里

输出格式

维度	问题	严重程度	修改建议

这个模板回答的是“怎么把书上的知识应用在真实代码上”。每次使用前，把代码粘贴进去，把模板内容连同代码一起作为 prompt 发给模型。模板本身也适合纳入 Git 管理，方便团队统一审查风格。 ## 6. 用测试来验证“书中内容”是否真实 前面反复提过一个观点：LLM 生成的代码必须验证。这里给一个可以落地的“验证工作流”，以 Python 为例。 假设你让模型生成了一个快速排序函数。建议这样做： ```python # 文件路径：scripts/test_code_snippet.py import pytest def quicksort(arr): """模型生成的示例代码：快速排序。""" if len(arr) <= 1: return arr pivot = arr[len(arr) // 2] left = [x for x in arr if x < pivot] middle = [x for x in arr if x == pivot] right = [x for x in arr if x > pivot] return quicksort(left) + middle + quicksort(right) def test_quicksort_basic(): assert quicksort([3, 6, 8, 10, 1, 2, 1]) == [1, 1, 2, 3, 6, 8, 10] def test_quicksort_empty(): assert quicksort([]) == [] def test_quicksort_duplicate(): assert quicksort([5, 5, 5]) == [5, 5, 5] if __name__ == "__main__": pytest.main([__file__, "-v"])

运行：

cd scripts python -m pytest test_code_snippet.py -v

如果所有测试通过，你才可以认为这段“书里的示例”在当前环境里是有效的。如果失败，就把报错信息发送给模型，要求基于测试输出修正代码。这个循环本质上就是在“勘误编程书”：每发现一个错误，你的知识库就多一条笔记，以后不会再踩同样的坑。

7. 常见问题与排查思路

在“把 LLM 当编程书”这条路上，你会遇到下面几个高频问题。

问题现象	可能原因	排查方式	解决方案
模型回答很空，像在泛泛而谈	提示词没有限定输出格式和知识范围	检查 prompt 是否给出章节、模板、例子	改用检索式提问，先注入笔记片段再提问
代码示例运行就报错	模型没有真正执行过代码，只是概率生成	复制代码到测试环境复现	建立“生成->测试->修正->沉淀”闭环
同一个问题两次回答不一致	采样温度过高，或缺少上下文	调低 temperature，增加固定 system 提示词	生产场景使用 temperature=0 或 0.2
知识库检索结果不相关	文本切分太粗糙，或 embedding 模型不合适	检查切分后的片段内容，检查向量相似度分数	按标题切分，必要时增大 top_k 数量
上下文太长，模型记不住前面的内容	上下文窗口被长文档占满	查看日志和 token 统计	改用 RAG，只注入相关片段，而不是整篇笔记
模型回答“看起来专业但结论错误”	幻觉问题	要求模型给出信息来源，或用测试用例验证	把关键结论与官方文档核对，沉淀进笔记
本地模型回答慢	模型参数量大，或 CPU 推理瓶颈	查看系统资源和推理日志	换更小量化模型，或部署 GPU 推理服务
检索脚本提示端口连接失败	本地模型服务未启动	执行ollama list或 curl 测试端口	先ollama serve，再运行脚本

其中最容易忽略的是最后一个：很多人配置好了检索脚本，但忘了先启动本地模型服务，于是一转头就把整套方案判定为“不稳定”。实际上，工具链里的每个中间环节都要单独验证，这一步错了，后面所有结果都会受影响。

8. 工程化最佳实践与进阶方向

如果要在真实项目或团队里推广“LLM 当编程书”这套范式，下面几个实践建议值得认真对待。

8.1 提示词要版本管理

不要把提示词直接写在对话窗口里，更不要让每个成员各自攒一套“秘密提示词”。建议把提示词模板放入 Git 仓库，按用途分类。任何对模板的修改都要走代码审查流程。这样团队在同样一个模型版本下，才能产出风格相对统一的输出。

8.2 记录模型版本和参数

模型版本和 temperature 直接影响输出质量。建议在知识库的 memory 目录里记录当前使用的模型名称、版本、采样参数和评测结果。换模型时，可以先跑一份固定测试集，把新模型和旧模型的输出对比保存下来，再决定是否切换。这样也能避免“昨天模型能用，今天突然变笨了”这种无法追溯的问题。

8.3 把测试用例当作“书习题”

普通编程书每章后面都有习题，用来检验读者是否真的理解了。LLM 编程书里的“习题”就是测试用例。建议为每一个沉淀进知识库的技术方案准备至少一个冒烟测试。这样，当模型输出了一个新方案时，你可以直接复用历史测试集来验证它是否仍然正确。

8.4 安全边界：知识库不是泄密渠道

把企业内部代码、敏感配置、密钥作为笔记放入个人知识库时，要非常谨慎。如果检索脚本或模型服务部署在没有权限控制的网络环境里，这些敏感信息可能被其他调用方检索到。建议遵循最小权限原则：

• 知识库索引文件设置文件系统权限。
• 模型服务监听地址固定为 127.0.0.1，不要默认暴露到局域网。
• 提示词模板和笔记仓库里的密钥、token 必须用环境变量或密文管理，不能直接写进 Markdown。

8.5 从“个人笔记”走向“团队知识库”

个人笔记本的尽头是团队 Wiki。前期的沉淀工作做得越好，后期迁移到团队知识平台的成本越低。如果团队想共享这套 LLM Wiki，可以在中间加一层同步机制，比如使用私有 Git 仓库或内部文件服务，让所有成员的检索索引定期重建。这里的核心不是工具，而是“片段化、可检索、可验证”这三条纪律。

9. 总结与下一步建议

把 LLM 当作编程书，而不是当作聊天机器人，本质上是一次使用心智的升级。这背后是几个清晰的技术选择：

• 用结构化提示词代替随意的对话。
• 用个人知识库沉淀代替一次性回答。
• 用检索增强生成代替凭空让模型发挥。
• 用测试用例验证代替对输出无条件信任。
• 用 Git 版本管理代替零散截图和聊天记录。

这套思路不仅适合个人开发者，也适合团队协作场景。所谓 LLM Wiki 范式，并不是什么高深理论，而是把“书”的概念迁移到模型使用流程里：你有目录、有章节、有书签、有勘误表，也有习题集。

下一步，你可以从这三件事开始：

1. 安装 Ollama，拉一个本地模型，把文章里的 AskLLM 脚本跑通。
2. 把你自己过去三个月踩过的最有价值的 10 个技术坑，整理成 10 篇 Markdown 笔记，放进知识库目录。
3. 写一个检索脚本，让模型基于这些笔记回答，并写几个测试用例验证输出。

等这套最小闭环跑起来，你会明显感受到一个变化：模型不再是每次都从零开始“编答案”，而是越来越像一本被你翻旧了、写满了批注、并且越用越顺手的编程书。