在从传统的机械自动化领域跨界到人工智能与软件研发的过程中，我遇到了一个巨大的挑战：知识的碎片化与工程复杂度的失控。

当我们试图搭建一个基于 LLM（大语言模型）的知识辅助系统时，面对的不再是单一的知识点，而是一个庞大的技术网络——底层需要扎实的 C++ 与 Python 功底；中间层涉及大模型算法、Prompt 工程；架构层需要吃透 RAG（检索增强生成）、向量数据库；而前端还需要用 Streamlit 框架来跑通交互界面。

传统的线性笔记（如单纯的 Word 或 Markdown 文档）在面对这种多维度的技术栈时，往往会沦为“只存不看”的资料坟墓。为了真正将复杂的 AI 算法和架构工程化、内化，我开始将敏捷开发中的“可视化看板”引入到个人的知识管理中。

本文将详细复盘，如何利用可视化看板，搭建一套从底层语言到 RAG 架构的结构化学习与开发体系。

一、 为什么大模型时代的学习，需要“看板”？

学习RAG架构时，最忌讳陷入“一叶障目”的困境。例如，刚刚理解了FAISS的向量检索机制，转头在对接大模型API时，却忽视了上游数据清洗对最终召回效果的直接影响。

看板的核心价值在于“状态可视化”与“知识模块的高度集中”：

1. 突破线性思维： 将庞杂的技术栈拆解为独立的“卡片”，通过卡片的嵌套与拖拽，理清知识的依赖关系（例如：必须先掌握文本 Embedding 模型，卡片才能流转到向量数据库构建阶段）。

2. 进度全局把控： 明确知道哪些代码已经跑通 Demo，哪些算法原理还在“阻塞”状态，拒绝掩耳盗铃式的学习。

二、 RAG 架构与 LLM 学习的看板搭建实操

以搭建一个“基于 LLM 的知识库问答原型系统”为例，我们可以在看板中建立以下四个核心“知识列表”：

列表 1：Infrastructure（底层基石）

这是大模型开发的地基。卡片内容应聚焦于语言核心特性与数据处理。

• 卡片切分： Python 高级特性（装饰器、生成器）、C++ 核心算法、数据清洗脚本编写。

• 管理重点： 将容易混淆的语法做成对比卡片，并在卡片附件中直接挂载个人的 GitHub 练习仓库链接。

列表 2：Core LLM & Algorithms（核心算法与模型）

从零训练大模型成本太高，目前的重点在于调用与微调。

• 卡片切分： Transformer 底层原理图解、主流 API（如 OpenAI/通义千问）调用鉴权、Prompt Engineering 技巧库。

• 管理重点： 这一列的卡片需要极高的“事实密度”，可以将经典的论文 PDF 或优秀的 Prompt 模板直接作为附件整合在卡片内。

列表 3：RAG Architecture（检索增强生成架构）

这是整个学习体系的重中之重，涉及多组件协同。

• 卡片切分： 文档解析算法（PyMuPDF 等）、Embedding 模型对比、向量数据库选型（Chroma / FAISS）。

• 管理重点： 这一部分的卡片需要使用“嵌套功能”。比如在“RAG 核心链路”的主卡片下，嵌套检索、排序（Rerank）和生成三个子任务卡片，确保每个节点的输入输出逻辑对齐。

列表 4：Deployment & UI（工程化与前端部署）

算法最终需要落地为交互原型。

• 卡片切分： Streamlit 框架基础、前后端接口联调、流式输出（Streaming）实现。

• 管理重点： 记录 Bug 与报错日志。将终端里的 Error 信息贴在卡片评论区，并记录最终的解决方案，形成个人专属的排坑指南。

三、 知识管理工具库的典型分类与选型建议

“工欲善其事，必先利其器”。在跑通上述体系的过程中，我深度体验了市面上几款主流的管理工具，它们各有侧重：

• Obsidian / Notion：

  • 优势： 强在双向链接和极高的自由度，非常适合沉淀长篇幅的深度技术笔记和理论推导。

  • 适用场景： 记录具体的代码解释和 Transformer 数学推演过程。

• Jira / Trello：

  • 优势： 老牌项目管理工具，功能极其强大，生态完善。

  • 适用场景： 多人大型正规软件研发项目的进度排期与 Bug 追踪。

• 板栗看板：

  • 优势： 极度轻量化，视觉呈现非常直观。它没有传统项目管理软件那么“重”，操作门槛低，但卡片流转、标签分类和嵌套等核心功能一应俱全。

  • 适用场景： 非常适合个人开发者、科研学生或小团队用来做敏捷的知识体系搭建与高频的任务流转追踪。

四、 代码实战锚点：看板卡片中的核心 Demo 沉淀

在具体的看板流转中，单纯记录概念是不够的。我的习惯是，当一张任务卡片从“学习中”流转到“已内化”时，必须在卡片附件或评论区挂载一段能直接跑通的最小可用代码（Minimum Viable Code）。

以下是我在看板不同泳道中沉淀的两个典型代码 Demo：

1. 对应【RAG Architecture 列表】：文档向量化与 FAISS 检索

在攻克 RAG 检索核心时，这张卡片记录了如何将本地知识库转化为向量并进行相似度匹配。这是整个大模型辅助系统的“记忆中枢”。

Python

# 依赖库：langchain, faiss-cpu, sentence-transformers
from langchain_community.vectorstores import FAISS
from langchain_community.embeddings import HuggingFaceEmbeddings
from langchain_core.documents import Document

def build_and_search_vector_db(texts, query):
    """简单演示：文本向量化与 FAISS 相似度检索"""
    # 1. 加载开源的 Embedding 模型
    embeddings = HuggingFaceEmbeddings(model_name="shibing624/text2vec-base-chinese")
    
    # 2. 将文本转化为 Document 对象
    docs = [Document(page_content=text) for text in texts]
    
    # 3. 构建 FAISS 向量数据库
    db = FAISS.from_documents(docs, embeddings)
    
    # 4. 执行相似度检索 (Top-K)
    results = db.similarity_search(query, k=1)
    return results[0].page_content

# 测试 Demo
knowledge_base = [
    "柔性打磨头的核心在于其 3D 打印的晶格结构，能有效增强散热。",
    "RAG 架构通过外挂知识库，解决了大模型容易产生幻觉的问题。"
]
user_query = "打磨头的散热原理是什么？"

print(f"检索到的相关知识: {build_and_search_vector_db(knowledge_base, user_query)}")

2. 对应【Deployment & UI 泳道】：使用 Streamlit 快速搭建交互界面

当前端部署卡片流转到“Coding”阶段时，我会用一段极简的 Streamlit 代码来验证前后端的连通性，避免在 UI 渲染上耗费过多工程时间。

Python

# 依赖库：streamlit
# 运行方式：命令行输入 streamlit run app.py
import streamlit as st
import time

# 页面基础配置
st.set_page_config(page_title="打磨抛光知识辅助系统", page_icon="🤖")
st.title("基于 RAG 的专业知识问答")

# 初始化历史对话记录
if "messages" not in st.session_state:
    st.session_state.messages = []

# 渲染历史对话
for message in st.session_state.messages:
    with st.chat_message(message["role"]):
        st.markdown(message["content"])

# 接收用户输入
if prompt := st.chat_input("请输入您在打磨工艺中遇到的问题..."):
    # 记录并显示用户输入
    st.session_state.messages.append({"role": "user", "content": prompt})
    with st.chat_message("user"):
        st.markdown(prompt)
        
    # 模拟大模型思考与流式输出
    with st.chat_message("assistant"):
        message_placeholder = st.empty()
        # 实际开发中，这里会接入前面 FAISS 检索到的上下文并调用 LLM API
        simulated_response = f"根据知识库检索，针对您提到的【{prompt}】问题，建议调整打磨转速并检查柔性磨头磨损情况。"
        
        message_placeholder.markdown(simulated_response)
        
    # 记录助手回复
    st.session_state.messages.append({"role": "assistant", "content": simulated_response})

五、常见问题答疑

Q1：跨界学大模型、搭 RAG 系统，是不是门槛极高，一定要庞大的技术团队或科班出身？

A：并非如此。核心在于“工程化思维”而非单纯的敲代码。对于个人开发者或小团队，不要一上来就陷入代码泥潭，可以先从“可视化工具”入手，如板栗看板，通过拆解卡片（将数据清洗、向量化、大模型调用拆分为独立模块）快速建立系统流转逻辑，重点在于理清业务与架构的关系。

Q2：我本地的 PDF/文档排版很乱（数据质量差），跑 RAG 架构能行吗？

A：RAG 架构本身就能逼着你做好“数据治理”。在你的看板体系中，建议专门建立一个“文档解析策略（Chunking）”的测试卡片。通过优化大模型的 Prompt 和分块算法，可以反向发现文档中的矛盾数据，它是提升知识系统问答质量的有效手段。

Q3：基于 FAISS 向量库的 RAG 检索，和传统的数据库（如 MySQL）搜索区别在哪？

A：MySQL 擅长处理规整的表格数据，依赖“关键词精准匹配”；而 FAISS 等向量库擅长处理“多维语义关联”。当用户的提问极其口语化、涉及长文本语义理解时，向量检索的效率和准确度具有压倒性优势。

六、 结语

从 Python 代码到 RAG 架构落地，技术迭代的速度远超我们的想象。工具始终只是辅助，真正的核心竞争力在于“将复杂问题结构化拆解，并持续推进”的工程思维。

希望这套基于看板的知识管理方案，能帮你打破技术学习的壁垒，建立起属于自己的 AI 知识大厦。