Origin Blog

在信息之外，留一页空白

Origin Blog — Sun, 20 Sep 2026 00:00:00 GMT

如果计算资源能够持续转化为探索能力和判断能力，这也带来了一个令人不安的未来问题：拥有大量算力的人或组织，会不会获得远超普通人的智力资源？这是对未来可能性的追问，并非已经发生的终局。

‍

对于正在学习的我们，可以从眼前开始改变做事方式：让模糊愿望获得可检查的表达，把有效经验沉淀成可复用的方法，在需要探索时主动扩展方向，又用证据筛选结果。提示词的价值，最终要落在这些行动如何改变任务的结果上。

——Yanyan’s Wiki，《提示词与上下文工程》

‍

我很认同这段话。提示词的价值并不在于把句子写得多么漂亮，而在于能不能把一个模糊的愿望变成可以执行、检查和修正的行动。对我来说，博客也有类似的意义：它不只是保存结果，还保存一个人如何形成判断的过程。

‍

这一周我都在着手用AI重构我的个人博客，但是我不太想把这次博客的二次优化写成一份版本说明。页面换了什么颜色，按钮增加了什么效果，当然可以列出来，但那只是最容易被看见的部分。真正让我停下来想一想的，是一个更简单的问题：

在今天这个什么都被放进信息流的时代，我为什么还要做个人博客？

现在的社交平台让表达变得非常方便。注册一个账号，写几句话，配一张图，剩下的事情交给推荐、热搜和通知。内容被看见的机会更多了，但它也越来越像一种即时消费。昨天写下的东西很快沉下去，今天的情绪必须比昨天更响，才有可能得到一点回应。我们渐渐习惯用浏览量、点赞和转发来确认一段文字是否值得留下，甚至让平台替我们决定什么应该被记住。

‍

而个人博客的节奏要慢得多。这里没有热榜，也没有谁提醒我“再发一条”。页面打开以后，访客需要自己选择去哪里；一篇文章写完了，也不一定有人马上读到。可正因为它不负责替我制造注意力，我才可以在这里保存一些还没有想清楚的东西。

它不是展示一个已经完成的我，而是允许尚未完成的人留下修改的痕迹。

所以这次优化不只是审美变化。我希望页面更安静一些，让黑白墨色把视觉从装饰里收回来；圆角让交互不要像在操作一张冷冰冰的表格。原来的栏目、文章、音乐和相册已经构成了这个博客的记忆。如果为了追求“新”而把它们全部抹掉，得到的可能只是一个更漂亮、却不再属于我的页面。

‍

一个好的界面不需要不停提醒自己存在。借海德格尔关于“上手状态”的说法，工具在顺手工作时会退到背景，只有失灵或不合适时才会重新显形。对博客来说，界面大概也应该保持这样的分寸：让人感觉到它在工作，而不是一直要求被观看。对我而言，网页最重要的功能不是让别人觉得它完成得很好，而是让我

愿意下次再打开它。

‍

我想起司马迁在《报任安书》中写下的那句话：“藏之名山，传之其人。”这当然是史家的理想，和我的博客不能相提并论，但两者之间仍然有一点相似：记录从来不只是把内容放在那里，它还意味着对时间的抵抗。今天的想法如果不留下，明天很可能连自己都无法确认曾经这样想过。

博客也从来不是中性的仓库。什么被保存、什么被删去、用什么顺序保存，都会影响后来的人如何理解过去。公共平台上的记忆往往按照流量排列，而个人博客可以暂时采用另一套尺度：一篇没有得到回应的文章，和一篇被很多人读过的文章，都有资格留在同一份目录里；一次失败的尝试，也不必因为不够体面而立刻消失。

‍

正如开头那段话所说，知识最终要落在行动改变任务结果的地方。放在今天的 AI 浪潮里，思考也成了我最快捷的消遣之一。我可以在一个问题上不断追问，让模糊的念头慢慢变得具体；也可以和 Agent 讨论生活、哲学和人文历史。

‍

有时，我会在它的回答里找到一个暂时站得住的答案；有时，它只是让我意识到自己原本问错了问题。读到人类在历史长河中留下的思想，会让我开心很久。我会被一瞬间出现的灵感震撼，也会因为某个时代的命运不公而惋惜。那些已经离开的人，仍然可以通过文字和今天的我进行一场延迟很久的谈话。

‍

但这件事也有令人不安的一面。也许在不久的将来，AI 能够在某种意义上读懂人的思想和感情；也许有一天，它不仅在效率上远远超过人类，还能在策略和框架的精细程度上全面胜过人类。那或许才是社会真正被迫接受 AI 的时刻，因为人们接受的将不再是一件工具，而是一种无法绕开的基础能力。

‍

我也不因此觉得人类会走上“没有工作、没有钱途”的道路，世界的一切偶然都是必然。回看上世纪中叶以来计算机的发展，从最初的理论设想，到今天渗透进生活的各个角落，许多变化在当时都像偶然，后来却成为了新的必然。世界没有什么东西是一成不变的，人类也总能在变化中重新创造适合当下的工具、制度和生活方式。

‍

是的，世界会迎来巨变，这是无疑的。但我不认为接受变化就等于赞成变化，也不认为恐惧变化能够阻止变化。与其假装时代不会改变，不如尽量在变化发生时保留判断，找到属于自己的位置。这可能就是我对生命在当下的理解。

‍

上大学以来，我有过很多后悔的事情，生活整体也算不上特别充实。有时思考到一半的事情，因为没有记下来，转眼就忘得一干二净。我把太多事想得简单，又把太多事想得复杂；一方面过于功利，另一方面又想显得自己无欲无求，最后反而越来越不自在，越来越迷茫。

‍

更让我难受的是，很多想法总是在事情过去几天，甚至几年之后才突然出现。我会忍不住想：为什么我当时没有想到？如果那时候就明白，现在是不是会不一样？可一旦这样想下去，又会觉得现在才开始做，是不是已经太晚了，以后的路是不是只会越来越难走。

‍

小时候的我畏惧死亡，现在的我更畏惧时间。死亡至少有一个明确的终点，时间却没有声音，也不会提前通知你。等我意识到它已经过去时，青春可能早就只剩下回忆。

‍

后来我慢慢发现，我经常在用今天的自己审判过去的自己。现在的我拥有更多经验，所以当然比几年前看得远，但那时的我并没有今天的这些信息，也不可能提前知道答案。那个“如果早点开始就好了”的自己，只存在于想象里。他没有经历真实的迟疑、代价和迷茫，所以看起来永远比现实中的我更聪明。

‍

未来的路可能确实会更难走。责任会增加，机会成本会变高，有些选择也不会像以前那样轻易重新开始。但我也会拥有过去没有的东西：对风险的判断，对自己的了解，以及知道哪些事情不值得再重复的经验。路也许会变窄一些，却不一定只会变坏。

‍

我现在仍然会后悔，但我不想让后悔只证明自己来晚了。它至少说明某件事对我很重要，也说明我终于看见了以前看不见的部分。问题不应该一直停留在“为什么前几年没有想到”，而应该继续问下去：既然我现在已经想到了，接下来准备怎样处理它？

‍

时间当然无法追回，但我可以把现在的思考留下来。博客无法让我回到过去，却能让未来的我知道，自己曾经在什么时刻感到迷茫，又是怎样试着走出迷茫的。

‍

在大学里，生活大部分时候由课程、代码、实验、截止日期和一些没有整理好的念头组成。现在回头看，这种不稳定也许正是值得记录的地方。等以后真的走过一段路，再回来看这些页面，我未必会认同其中的每一句话，但至少能知道自己曾经怎样理解技术、时间和自己。

‍

这更像是一次我对生活的重新确认：我仍然愿意为一个不被算法催促的空间花时间，仍然愿意把界面、文章和那些并不重要却很具体的细节慢慢整理好。

‍

个人博客的意义，或许就在这种慢里。它没有替我保留一个固定的形象，只是给我一块可以反复修改的地方。页面会变，文章会增加，很多想法也会被后来的人推翻。但只要这块地方还在，我就还能从某个旧页面出发，继续认识自己正在成为谁。

‍

唯一重要的是，永恒的现在。

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://www.originblog.xyz/blog/chatter_1790012226310/

应用视角的操作系统

Origin Blog — Sat, 19 Sep 2026 00:00:00 GMT

1. 本讲要回答的问题

程序到底是什么？
函数调用、递归和程序运行状态如何精确描述？
编译器把程序转换成什么？什么叫“编译正确”？
一个最小的操作系统应用如何启动和退出？
浏览器、编译器、窗口管理器等复杂应用，是否都建立在同一组系统调用之上？
如何用工具观察程序和操作系统之间的交互？

2. 核心知识地图

1
flowchart TD
2
    S[源代码 C] --> T[简化为 SimpleC]
3
    T --> I[解释执行：逐条语句改变状态]
4
    T --> C[编译：转换为机器指令]
5
    C --> M[CPU 状态机：取指、译码、执行]
6
    M -->|syscall / ecall / svc| OS[操作系统]
7
    OS --> O[文件、进程、内存、设备等对象]
8
    OS -->|返回结果或改变状态| M
9
    M --> X[exit / exit_group]

3. 程序：一个状态机

3.1 什么是“状态”

程序的状态不是简单的“变量值”。在本讲的模型中，状态主要包括：

全局变量；
当前调用栈中的所有栈帧；
每个栈帧中的参数、局部变量和下一步执行位置（PC）。

执行一条语句，状态就发生一次迁移。程序运行，就是不断重复“读取当前状态 → 执行一步 → 得到新状态”。

1
初始状态 → 执行语句 → 新状态 → 执行语句 → 新状态 → …

3.2 函数调用与栈帧

调用函数时，程序会：

记录当前函数下一步应该返回的位置；
创建新的栈帧；
把参数放入新栈帧；
从被调用函数的入口开始执行。

函数返回时，新栈帧被弹出，程序回到保存的位置继续运行。

所以递归本质上不是“函数自己调用自己”这么一句话，而是调用栈不断压入新的函数实例。

3.3 为什么函数调用顺序很重要

数学函数通常只关心输入和输出；C/C++ 函数还可能产生副作用，例如打印、写文件、修改全局变量。存在副作用时，调用顺序可能改变最终结果。

例如：

1
printf("A");
2
printf("B");

交换两句，输出就从 AB 变成 BA。因此，程序的“语义”不仅是算出了什么，还包括对外部世界做了什么、按什么顺序做。

4. 解释执行、编译与编译正确性

4.1 SimpleC：把复杂语句拆小

C 语言包含循环、分支、函数调用和复杂表达式。为了更容易观察程序运行，可以把它改写成每行只做一件事的简化形式，例如把循环改写为条件跳转，把函数调用拆成明确的保存和跳转。

这样可以像模拟 CPU 一样单步执行源程序：

1
fetch_statement()
2
decode_and_execute(statement)

4.2 编译器做什么

编译器把高级语言程序转换成更低级的程序表示，最终得到 CPU 能执行的机器指令。

编译后的程序不需要保留源代码的结构。只要对于相同输入，它的可观察行为与原程序等价，就可以认为编译是正确的。

可观察行为包括：

输出结果；
是否终止；
系统调用和其他外部 API 的行为；
对文件、设备、网络等外部对象的影响。

4.3 优化与死代码消除

如果某段计算不会影响任何外部可观察结果，编译器可以删除它，这叫 DCE（Dead Code Elimination，死代码消除）。

因此，“编译正确”不等于“机器代码看起来像逐行翻译”；正确性关注的是外部行为，而不是内部写法。

5. 最小应用程序：从 `_start` 到 `exit`

5.1 `_start` 与 `main`

普通 C 程序通常从 main 开始，但操作系统加载可执行文件后，首先进入的往往是 _start。运行库会在 _start 中完成初始化，再调用 main。

1
操作系统加载 ELF
2
    ↓
3
进入 _start
4
    ↓
5
运行库初始化
6
    ↓
7
调用 main
8
    ↓
9
调用 exit / _exit

5.2 程序如何退出

CPU 的普通指令没有“把当前程序从系统中删除”这一能力。程序要退出，必须请求操作系统服务：

把系统调用编号放入规定的寄存器；
把参数放入规定的寄存器；
执行系统调用指令；
由操作系统终止进程并回收相关资源。

常见系统调用指令：

架构指令 x86-64 syscall RISC-V ecall AArch64 svc

6. 系统调用：应用与操作系统的边界

系统调用不是普通的库函数调用，而是一次控制权和权限的交接。

1
sequenceDiagram
2
    participant P as 应用程序
3
    participant CPU as CPU
4
    participant K as 操作系统
5
    P->>CPU: 执行 syscall / ecall / svc
6
    CPU->>K: 切换到操作系统入口
7
    K->>K: 检查参数、访问对象、执行服务
8
    K-->>CPU: 返回结果或改变进程状态
9
    CPU-->>P: 应用继续运行、阻塞或终止

系统调用可以用于：

fork、execve、exit：进程管理；
open、close、read、write：文件和设备访问；
mmap、brk：内存和地址空间管理；
send、recv：网络通信；
ptrace：观察或控制其他进程。

本讲的直观理解是：应用程序大部分时间在自己的状态机中计算；遇到系统调用时，暂时把控制权交给操作系统。

配图提示：小黑卡在“系统调用”的服务舱口，把请求递给操作系统，再接回返回结果。它表达的是权限和控制权的交接，不是普通函数调用。

7. 应用世界：程序看起来不同，本质相同

7.1 三类程序

Applications：浏览器、编辑器、播放器、IDE；
Utilities：Shell、gcc、vim、curl、ffmpeg、包管理器；
Daemons：后台服务，如网络服务、设备管理、安全组件和定时任务。

它们都可以抽象成：

1
计算 + 调用操作系统 API + 继续计算 + 退出

7.2 ELF：可执行文件是初始状态的描述

Linux 原生程序通常使用 ELF 格式。ELF 文件中包含：

程序入口地址；
机器指令；
初始数据；
加载信息；
各内存区域的权限等。

因此，ELF 不是“只有指令的二进制文件”，而是操作系统建立程序初始运行状态所需的信息集合。

7.3 复杂应用也只是 API 的组合

窗口管理器：管理屏幕和窗口对象，进行进程间通信；
任务管理器：读取进程相关信息；
杀毒软件：读取文件进行扫描，并观察或控制其他进程；
编译器：启动多个子进程，读取输入文件并生成输出文件。

它们的功能虽然复杂，但底层仍然由计算和操作系统 API 组合而成。

8. 用工具观察程序

8.1 `strace`

strace 用来观察程序执行过哪些系统调用，是理解“应用—操作系统边界”的重要工具。

1
strace ./a.out
2
strace -f gcc hello.c
3
strace ls |& grep -e read -e write

看到 openat、read、write、mmap、exit_group 等调用时，可以把它们理解成程序和操作系统之间的一次次对话。

8.2 工具分工

工具主要用途 gcc / clang 编译程序 gdb 单步执行、查看栈和变量 strace 查看系统调用 readelf 查看 ELF 文件结构 objdump 反汇编和查看二进制内容 profiler 分析时间和性能开销

9. 术语速查：用一句话理解

术语通俗解释状态机有明确状态和变化规则的运行模型状态迁移执行一步后从旧状态到新状态栈帧一次函数调用保存参数、局部变量和返回位置的区域调用栈当前还没有返回的函数调用层层叠加形成的结构 PC Program Counter，下一步执行位置形式语义用严格规则说明程序“到底是什么意思” 解释器直接读取并执行程序表示的软件编译器把程序转换成另一种等价表示的软件 Transpiler 在相近语言之间转换的程序，例如 C → SimpleC 副作用除了返回值，还改变了外部可观察状态指令集 CPU 支持的机器指令及其规则寄存器 CPU 内部少量但高速的存储单元系统调用应用请求操作系统提供服务的入口 API 应用可以使用的接口和约定进程一个正在运行的程序实例 ELF Linux 常见的可执行文件格式 _start 可执行文件通常实际开始执行的位置 main C 运行库通常交给程序员使用的入口 execve 用新程序替换当前进程的内容 daemon 在后台长期运行并提供服务的程序 Trace 记录程序从开始到结束的执行过程 DCE 删除不会影响结果的代码

10. 最容易混淆的地方

程序、可执行文件、进程

程序：抽象的代码和逻辑；
可执行文件：保存在磁盘上的程序初始状态描述；
进程：可执行文件被加载后的一次实际运行。

同一个可执行文件可以同时启动多个进程。

API、库函数、系统调用

API 是接口约定；库函数是对接口的某种封装；系统调用是进入操作系统的机制。一个库函数可能执行一次、多个或零个系统调用。

编译不是“逐行翻译”

编译器可以重排、合并或删除内部计算。只要外部可观察行为保持等价，内部结构不同也属于正确编译。

系统调用不是普通函数调用

普通函数调用仍在应用自己的权限和地址空间中进行；系统调用会切换到操作系统控制的执行路径，并可能改变进程状态。

11. 检查

为什么递归调用会自然地对应到栈帧？
为什么带有打印操作的两个函数不能随意交换调用顺序？
为什么程序退出必须依赖系统调用？
_start 和 main 分别处在启动流程的什么位置？
编译器为什么可以删除一段“看起来执行了计算”的代码？
strace 观察到的是程序的哪些行为？
浏览器、编译器、任务管理器为什么都可以被看成“计算 + 系统调用”？

12. 实验

1
# 1. 编译一个最小 C 程序
2
gcc hello.c -o hello
3

4
# 2. 观察它与操作系统的交互
5
strace ./hello
6

7
# 3. 查看可执行文件的 ELF 信息
8
readelf -h ./hello
9

10
# 4. 查看反汇编结果
11
objdump -d ./hello

建议重点观察：程序如何被加载、何时申请内存、怎样写出 Hello World，以及最后由哪个退出系统调用结束。

13. 资料来源

‍

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://www.originblog.xyz/blog/post_1789796421/

幻觉治理四机制（借鉴 J-Space）—— 分四阶段实施

Origin Blog — Sun, 16 Aug 2026 00:00:00 GMT

总原则（UX 安全）

全部改动落在离线质量脚本 + prompt 层 + 判定输出结构，不触碰交互路径延迟：

/submit、/feedback、/assess/stream 的耗时零增加（判定→再生只发生在离线脚本 run_quality_test.py）
工作流重试改造是同延迟更聪明（同样的 9 次 LLM 调用，但带上诊断 hint），不加调用

阶段一 ②：判定幻觉 → 携带诊断的定向再生（最高优先级）

1.1 `_generate_one` 支持修正 hint（`content_generator.py`）

_build_generation_prompt(node, theory_level, content_type, correction_hint="") 新增可选参数；非空时 system 消息追加”【上轮判定修正要求】{hint}。重点修正上述问题，其余保持原结构。”
_generate_one(node, theory_level, content_type, correction_hint="") 透传

1.2 新文件 `backend/app/agents/quality_regen.py`

🐍

python

1
def regenerate_flagged(resources, hallucination_result, kg) -> dict:

# verdict=="hallucinated" 的资源 → kg.get_node(target_node_id) 取节点

# → adaptation_profile 反映射 theory_level (beginner→2/intermediate→3/advanced→5)

# → _generate_one(node, level, content_type, correction_hint=verdict.reason)

# → 原位替换（保持顺序），节点缺失/生成失败保留原资源

# ThreadPoolExecutor 并行 (min(CONTENT_GEN_CONCURRENCY, n))

# 返回 {resources, regenerated_count, regen_indexes, failures}

1.3 工作流盲重试 → 定向重试（`content_generator.py`）

_node_body 开头：

🐍

python

1
retry_hint = ""

if state.get("content_phase_entered") and isinstance(state.get("review_results"), dict):

retry_hint = (state["review_results"].get("retry_hint") or "").strip()

tasks 元组带上 hint 传入 _generate_one（reviewer 产出的 retry_hint 首次被消费；首轮 content_phase_entered=False 不注入，语义安全）

1.4 离线脚本闭环（`scripts/run_quality_test.py`）

measure_one 里 judge 后：hallucinated > 0 → regenerate_flagged → 只对被替换资源重跑 judge → 汇总：

🐍

python

1
independent = {

"hallucination": <第一轮>,

"regen": {"regenerated": n, "reasons": [...], "after": {rate, hallucinated, total}} | None,

"adaptation": ...

}

--no-regen 开关（默认开）；artifacts 的 resources 更新为再生后（—judge-only 复跑看到的是修复后状态）
aggregate() 增加 independent 再生聚合（before_rate / after_rate）
write_markdown 增加”幻觉定向再生闭环”小节（before→after 对比表）

1.5 测试

新 backend/tests/test_quality_regen.py：只替换 flagged / hint 透传捕获 / 节点缺失保原 / 无幻觉 no-op / 非 dict 资源跳过
扩展 test_content_generator_unit.py：correction_hint 注入 prompt；retry_hint 状态流（state 带 content_phase_entered+retry_hint → _generate_one 收到 hint；首轮不注入）

阶段二 ①：生成时认识状态标记（unverified_claims）

_build_generation_prompt / _generate_feedback_one 的 JSON schema 增加： "unverified_claims": ["图谱事实之外的类比/背景性陈述, 每条一句; 完全锚定为空数组"] system 说明：自声明用于定向审计（类比允许，但要浮出水面），不是禁止
_generate_one / _generate_feedback_one：data.setdefault("unverified_claims", []) + 非 list 强转 []
judge_hallucination：_build_hallucination_prompt(content, facts_text, unverified=None) 追加”## 资源自声明待验证补充”块；从 r.get("unverified_claims") 读
run_quality_test.py：per_run + aggregate 统计 unverified_claims 总数（审计覆盖率证据）
测试：setdefault 兜底、prompt 含字段、judge prompt 含自声明块、空数组不追加

阶段三 ③：先锚定后展开（bridge-before-conclusion）

_build_generation_prompt system 增加： “【先锚定后展开】资源的第一小节必须先用 1-3 句复述节点 summary/key_points 已给事实（不加新信息），随后的展开只能阐释已锚定事实；结论不得先于其图谱依据出现。”
correction_hint 再生路径天然强化（修正要求 + 先锚定）
同步 data/prompts/04_content_generator_agent.txt 设计稿（新增同名小节）
测试：prompt 字符串含规则；04 spec 文件含小节

阶段四 ④：验证方式 + 覆盖双记录

data/prompts/judge_hallucination.txt 输出 JSON 增加 "coverage": "full|partial|none"（内容对节点 key_points 的锚定覆盖度）
quality_judge.py：verdict dict 读入 evidence_node_ids（现在被忽略）+ coverage（非法值兜底 “none”）

quality_metrics.py 新纯函数：

🐍

python

1
def compute_anchor_coverage(verdicts) -> {"full": n, "partial": n, "none": n, "rate_full": float}

run_quality_test.py：independent 聚合带 coverage 统计；markdown 判定表加”锚定覆盖”行；verdicts 留档 evidence_node_ids（验证依据可追溯）
测试：judge 读入两字段、非法兜底、compute_anchor_coverage 纯函数

‍

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://www.originblog.xyz/blog/post_1786883135/

项目图谱深度增强：实体丰富化 + 技术栈检测 + LLM 分析 + 联网搜索

Origin Blog — Sat, 15 Aug 2026 00:00:00 GMT

问题根因

数据断层：后端 parse_project 已提取 docstring/params/return_type/bases/decorators/external_calls/source_code 等丰富属性，但前端 normalizeGraphResponse 只保留 6 个字段（id/name/kind/qualified_name/line_start/line_end），其余全丢弃
无技术栈检测：external_calls 已捕获未解析外部调用名（requests.get/pandas.DataFrame），但从未聚合分类
无 LLM 分析：parse_project 纯 AST，无语义层面的架构解读
无联网搜索：search_web + learningResources store 已就绪，但 ProjectGraphView 完全未接入
Stats bug：后端返回 function_count，前端读 function，头部计数永远 0

设计：两段式（AST 自动 + LLM 按需）

AST 能做的（技术栈检测、实体属性展示）自动执行零成本；LLM 分析 + 联网搜索按需触发（按钮），不拖慢自动解析。

Phase 1：修复数据断层 + 实体详情丰富化（零 LLM, 自动）

1.1 api/project.js``normalizeGraphResponse 传递完整属性

entities 增加：docstring, params, return_type, bases, decorators, external_calls, module_name, source_code
stats key 映射：function_count->function, class_count->class, method_count->method, module_count->module（修复头部计数 bug）

1.2 `ProjectGraphView.vue` 实体详情面板丰富化

显示 docstring（如有，折叠展示）
显示参数列表 params（名称:类型）
显示外部依赖 external_calls（去重后的 top-level 模块名）
显示继承基类 bases、装饰器 decorators（如有）

Phase 2：技术栈自动检测（AST, 零 LLM, 自动）

2.1 新建 `frontend/src/utils/techStack.js`

detectTechStack(entities): 扫描所有实体的 external_calls，提取 top-level 模块名（. 前的部分），映射到技术分类
内置 ~30 个常见 Python 包映射表（flask->Web 框架, pandas->数据分析, requests->HTTP 客户端, pytest->测试等）
返回 [{name, category, count}]（按引用次数降序）

2.2 `ProjectGraphView.vue` 头部展示技术栈 badges

在 stats 行下方加一行技术栈 tag（el-tag per tech），点击可触发联网搜索该技术

Phase 3：LLM 深度分析 + 联网搜索（按需）

3.1 后端新建 `POST /api/project/analyze`

新文件 backend/app/agents/project_analyzer.py:
- analyze_project(project_id, kg, tavily_key): 从 Neo4j 取项目图谱 -> LLM 分析架构（模式/入口点/关键模块/复杂度/学习建议）-> 对检测到的技术栈逐个 search_web 搜教程/文档
- LLM prompt 包含：实体清单（名称/类型/调用关系摘要）+ 技术栈 + 要求输出 JSON {summary, architecture:{pattern, entry_points, key_modules}, recommendations:[...]}
- 复用 app/agents/llm.py 的 LLM 调用基础设施
- 复用 app/utils/web_search.py 的 search_web
路由 backend/app/api/project.py 加 POST /analyze:
- 入参 {project_id, tavily_key?}
- 503 if Neo4j 未就绪；404 if 项目图谱不存在
- 返回 {summary, architecture, tech_stack, web_resources:[{title,url,snippet,tech}]}

3.2 `api/project.js` 加 `analyzeProject(projectId, tavilyKey)`

POST /api/project/analyze

3.3 `projectGraph store` 加 `analyze()` action

analyzing ref (bool) + analysis ref (null|{summary, architecture, tech_stack, web_resources})
调 analyzeProject -> set analysis -> web_resources 流入 learningResources store

3.4 `ProjectGraphView.vue` 加”深度分析”按钮 + 结果面板

工具栏加”深度分析”按钮（loading 状态）
侧栏新增”项目分析”卡片（analysis 非空时显示）：
- 架构摘要（summary）
- 架构模式 + 入口点 + 关键模块
- 学习建议
- 联网资源列表（web_resources，点击打开浏览器）
技术栈 badge 点击 -> 自动调 web_search 搜该技术 -> 结果流入 learningResources

Phase 4：测试 + 收尾

测试

utils/techStack.test.js: detectTechStack 映射 + 去重 + 空输入
api/project.test.js（或扩展 project-graph-store.test.js）: normalizeGraphResponse 传递丰富字段 + stats key 映射
后端 test_project_analyzer.py: mock LLM + search_web, 验证返回结构
全量 vitest + pytest 回归

‍

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://www.originblog.xyz/blog/post_1786808863/

修复"新领域动态建域后图谱无法生成"

Origin Blog — Sat, 15 Aug 2026 00:00:00 GMT

Kmatch项目中用户对于新领域的知识点答题后，无法生成知识图谱
已确认根因

动态域会话 submit 组装的 learning_path 含重复 node_id（实测 AI 域 12 节点中 AI-003/004/010 ×2）→ 前端 useGraphData.g6Nodes 直接喂 G6 → “Node already exists” 渲染崩溃。后端 BFS 结果循环是唯一无防重的口子（弱项补丁分支已有 path_ids 防重）。工作区已有的 seen_ids 修复方向正确，但从未验证（后端未重启过），且注释归因（“按 (start,n) 分组”）与 Cypher 语义矛盾，需实库取证修正——若库里真有同 id 双实体还需清库。

执行步骤

1. 起环境 + 实库取证

docker-compose up -d 起 Neo4j，等健康
cypher-shell 只读查询：
- MATCH (n:KnowledgeNode) WITH n.id AS id, count(*) AS c WHERE c>1 RETURN id, c — 同 id 双实体？
- SHOW CONSTRAINTS — kb_unique_id 唯一约束是否存在
- 直跑 BFS Cypher（known_ids=AI-001..007）数每个 id 的返回行数 — 实锤重复行来源
- 节点总数（期望 252）

2. 根因处置

若有双实体：清重复（保留 updated_at 最新）+ 确保 kb_unique_id 约束在
依据取证结果改写 engine.py 修复注释的归因描述（删掉未经证实的”按 (start,n) 分组”说法，写实测结论）

3. 验证后端修复

重启 uvicorn（加载含 seen_ids 的 engine.py）
POST /api/graph/path（known=AI-001..007, weak=AI-001..010, level=1, max_nodes=12，复现 20:44 场景）→ 断言返回路径 node_id 唯一、难度 ≤3

4. 前端防御（治本加固）

frontend/src/composables/useGraphData.js：g6Nodes 按 node_id 去重（保首个）——G6 对重复 id 直接抛错，前端单点兜底后任何后端回归都不再炸渲染
新增 frontend/src/__tests__/useGraphData.test.js（重复 node_id → g6Nodes 唯一）

5. 回归测试

后端：pytest tests/test_engine_learning_path.py -q → 全量 pytest -q
前端：npm run test（vitest 全量，281 个）

6. E2E 浏览器验证（browser-use）

浏览器打开学习会话，输入”人工智能”（已入库，秒级命中复用）→ 答题（全错模拟零基础）→ 提交 → 断言第 4 阶段”专属知识图谱”正常渲染（无 Node already exists，节点可点）
不再新建全新域：动态建域本身已 3 次 E2E 验证过（JV/CS/AI），本次坏的是路径组装+渲染

7. 文档 + 提交

devlog 追加到 docs/devlogs/A_后端/2026-08-14_动态建域.md：实锤根因 + 修复 + 前端防御 + E2E 结果
分 3 个 commit 推送：
1. fix(graph): assemble_learning_path BFS 重复节点 seen_ids 去重 - 修动态域 G6 "Node already exists" 渲染失败（engine.py + 测试 + devlog）
2. fix(ide): useGraphData g6Nodes 按节点 id 去重防御 - 后端任何回归不再炸图谱渲染（useGraphData.js + 测试）
3. chore(data): AI 动态域演示数据入库 (E2E 实测 10 节点 20 题, source=llm_generated 可识别)（_manual_nodes.json + AI 题目文件）

备注

若用户实际在安装包（sidecar exe）里复现：sidecar 是旧代码打的包，需重跑 PyInstaller 才含修复（本次不打包，验证以 dev 模式为准）

‍

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://www.originblog.xyz/blog/post_1786789626/

差点见不到我的博客

Origin Blog — Fri, 14 Aug 2026 00:00:00 GMT

原本是说想给博客的歌曲做个排序功能的，结果最后搞来搞去差点把后台搞崩了
因为我的后台跑的是”过期的快照”

my-blog-manager 后台不是用 npm run dev 在跑，而是被 launcher.py 用生产模式启动的：它检测到 .next/standalone/server.js 存在，就执行 node server.js。

而文章页面是（app/posts/[slug]/page.tsx、app/timeline/page.tsx）：

1
const postsDirectory = path.join(process.cwd(), 'posts');

生产模式下 process.cwd() = .next/standalone，所以后台读的是 .next/standalone/posts/——都没有更新这个 standalone 快照。TAT\

目前的解决办法就是：
删掉或改名 .next/standalone/server.js，让 launcher.py 自动回退到 npm run dev 模式。这样后台读的就是 my-blog-manager/posts/ 实时数据

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://www.originblog.xyz/blog/chatter_1786716136/

嵌入式图存储：打包版免 Docker/Neo4j

Origin Blog — Fri, 14 Aug 2026 00:00:00 GMT

背景与结论

现状：我的Kmatch 的知识库 JSON 真相源（222 节点 + 324 题）已经随安装包分发（electron-builder extraResources 带 data/），但运行时所有图查询/向量检索只走 Neo4j，用户必须自己 docker 起 Neo4j 再手动跑导入脚本。全部 Cypher 收口在 backend/app/graph/engine.py 一个类（932 行 ~30 方法），其余代码只依赖 KnowledgeGraph 方法签名 —— 替换点单一，是理想收口。

方案：新写 EmbeddedKnowledgeGraph（内存图 + SQLite 持久化动态数据 + 分层 embedding 缓存），KMATCH_GRAPH_STORE=embedded|neo4j env 切换；打包版默认 embedded，开发/Docker 链路保留 Neo4j 不动（488 存量测试均 mock driver，不受影响）。

实施步骤

1. embedding 预生成缓存 — `backend/scripts/build_embedding_cache.py`

复用 import_knowledge_base.py 的 embedding 逻辑，一次性算全部节点向量，输出 data/knowledge_base/embeddings.json（node_id → 1536 维向量，保留 4 位小数，~几 MB），提交仓库随 extraResources 分发。
构建期跑一次即可，装完即有完整离线语义检索。

2. 核心新模块 — `backend/app/graph/embedded.py`（~650 行，工作量主体）

与 Neo4j 版同方法面的 EmbeddedKnowledgeGraph：

加载：启动时经 kb_store 读 KB_DIR 全部节点/题目 JSON → 内存 nodes dict + REQUIRES 正反向邻接表 + questions_by_node。
图遍历：纯 Python BFS 实现 get_prerequisites / get_dependents / get_reachable（对应 REQUIRES*1..N 变长路径）。
学习路径：assemble_learning_path 的 Cypher 分层 BFS（MATCH path ... min(length(path))）重写为 Python 多目标 BFS；弱项补丁/配额逻辑（_WEAK_PATCH_LIMIT 等）已是纯 Python，原样复用，用小 fixture 与 Neo4j 版对拍。
向量检索：numpy（新增依赖）cosine 打分 top-k；embeddings 三层合并：shipped embeddings.json 为底 + state.db 覆盖层（见下）+ 内存新算。无向量节点跳过语义检索、保留图召回（沿用现有纯图降级语义）。
CRUD 同步：upsert/delete_knowledge_node、upsert/delete_question 只更新内存索引 + 触发增量 embedding（JSON 真相源写回已由 api/kb.py 完成，不重复）。
回答「题库会变」：增删改节点时若 embedding client 可用 → 单点补算写入覆盖层；不可用 → 该节点退出语义检索、仍在图检索里。内置 222 节点开箱即有向量。

3. 动态状态持久化 — SQLite（`KMATCH_STATE_DIR/state.db`）

node_status 表：update_node_status / get_node_status（掌握状态，比现在写在 Neo4j 全局覆盖式还更干净）。
project_entities / project_relations / project_meta 三表：write/get/delete_project_graph、annotate_risk、link_entity_to_knowledge（场景二项目图谱）。
embedding_overlays 表：CRUD 产生的向量变更（node_id, vec blob, text_hash；文本没变沿用缓存）。
数据量小、后端单进程，全内存 + 写穿 SQLite，无并发难题。

4. 工厂 + 启动接线

backend/app/config.py：新增 KMATCH_GRAPH_STORE（默认 neo4j）、KMATCH_STATE_DIR、KMATCH_SEED_KB_DIR 三个配置。
main.py lifespan：按 store 类型实例化 embedded 或 Neo4j 版（duck-typing 共用方法签名）；/api/health 改报 graph_store: "embedded" | "neo4j connected/unavailable"。
可写性：打包版 resources/data 在 Program Files 只读，KB CRUD 写 JSON 会失败。后端启动时若 KMATCH_SEED_KB_DIR 设置且 state 目录无 knowledge_base → 整体拷贝一份（~几 MB）到 <state>/knowledge_base 并把 KB_DIR 指过去；资源目录保持只读。开发模式无该变量，行为不变。

5. Electron 注入 — `electron/main/backend-sidecar.js`

生产分支 spawn 时注入 KMATCH_GRAPH_STORE=embedded、KMATCH_STATE_DIR=<userData>/state、KMATCH_SEED_KB_DIR=<resourcesPath>/data/knowledge_base；更新头注释（删「Neo4j 仍由用户 Docker 起」）。

6. 依赖与打包

backend/requirements.txt 加 numpy>=1.26（PyInstaller hook 自带，spec 预计无需手动 collect，打包时验证）。
README/AGENTS.md：安装包章节改为「开箱即用；Neo4j 为开发/服务端可选模式」。

7. 测试与验证

新增 backend/tests/test_embedded_engine.py：加载计数与 import 脚本一致 / BFS 手算小图正确性 / 学习路径与 Neo4j 版对拍 / 假向量（one-hot 1536 维）top-k 断言 / 项目图谱与掌握状态 SQLite roundtrip（tmp_path）/ embedding overlay 增删。
回归：全量 pytest（488 后端测试）。
手工：KMATCH_GRAPH_STORE=embedded 起后端跑学习会话阶段①②、图谱视图、KB 管理增改、场景二项目图谱，再打一次 NSIS 包验证 userData 拷贝与首启流程。

8. 文档

devlog 新阶段条目 + AGENTS.md 架构速览/打包节更新 + CONTEXT.md + ADR-0007（双后端存储决策）。

风险点

assemble_learning_path Cypher BFS 语义复刻是唯一有对拍风险的点，用小 fixture 双实现对照兜底。
embeddings.json 体积与 numpy 进 PyInstaller 产物，打包时实测确认。

‍

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://www.originblog.xyz/blog/post_1786708802/

龙芯嵌入式 Linux 开发实训第一阶段总结

Origin Blog — Mon, 13 Jul 2026 00:00:00 GMT

‍

实训平台：龙芯 2K0300 久久派开发板（LoongArch64 架构）
实训环境：Ubuntu 22.04 虚拟机 + VMware + MobaXterm + LoongOS
实训周期：2026年7月

一、实训背景与目标

本次计算机实训的主题是龙芯（LoongArch）嵌入式 Linux 系统开发。实训使用的硬件平台是龙芯 2K0300”久久派”开发板——这是一款搭载龙芯自主研发的 LoongArch64 架构处理器（LA264 核心）的嵌入式开发平台，运行 LoongOS 嵌入式 Linux 系统（内核版本 4.19.190+，含 PREEMPT_RT rt79 实时抢占补丁），固件层使用龙芯平台标准的 PMON 引导程序。

与常见的 x86 或 ARM 嵌入式开发不同，龙芯平台有自己独特的技术生态：专属的交叉编译工具链（loongarch64-linux-gnu-gcc 8.3.0）、定制化的板级支持包（BSP）、PMON 固件体系、以及尚在完善中的开源社区支持。这些特性使得本次实训不仅是一次技术学习，更是一次国产自主平台的实践探索。

实训的目标非常明确——在龙芯 2K0300 平台上，从零开始完整走通嵌入式 Linux 开发的核心链路：从最上层的用户空间应用编程（Shell/Python），到交叉编译环境搭建和 C 语言程序部署，再到 Linux 内核模块驱动开发和设备树配置，最后触及系统固件构建（OpenWrt）。五个模块逐层深入，每一层都涉及不同的工具链、编程范式、和调试方法。

实训全程在 Ubuntu 22.04 虚拟机（VMware 运行于 Windows 11 宿主机）上进行代码编写和交叉编译，使用 MobaXterm 通过串口连接开发板进行操作，文件传输依赖 U 盘（因网络始终未调通）。整个过程中借助 Claude Code AI 进行实时错误诊断和原理讲解——这也是本次实训的一个特色：在 AI 辅助下，问题排查的效率得到了数量级的提升。

实训最大的特点是 “困难驱动学习”——五个实验模块下来，累计遇到了大大小小 20 余个实际问题，涵盖命令语法错误、编译工具缺失、内核版本不匹配、设备树语法错误、文件系统兼容性、USB 控制器驱动缺陷、内核启动 panic 等方方面面。每个问题都迫使我深入理解背后的机制，而这种”先踩坑、再理解”的方式，比顺利地走完一遍实验指导书要深刻得多。以下将按照实际实验顺序，以遇到的问题和解决过程为主线展开叙述。

二、实验环境详情

2.1 硬件配置

组件规格说明开发板龙芯 2K0300 久久派龙芯中科推出的嵌入式开发平台，面向 IoT 和工业控制场景处理器LoongArch64 LA264 核心龙芯自主设计的 64 位 RISC 指令集架构，区别于 x86/ARM/MIPS板载存储eMMC 8GB（/dev/mmcblk0）PMON 固件中识别为 emmc0，通过 ls2k_sdio 驱动访问，支持 HS200 高速模式板载内存DDR3/DDR4（约 512MB 可用）内核启动日志显示 Memory: 457496K/524288K available网络接口千兆以太网（Synopsys DWMAC1000 / stmmac 驱动）实训期间因网络配置问题未调通USB 接口dwc2 OTG 控制器用于 U 盘数据传输、USB 转串口串口UART，参数 115200/8/N/1，无流控通过 USB 转串口线连接 PC，是实验期间与开发板交互的主要通道扩展引脚GPIO 83（GPA80-3）等连接 LED，低电平有效（active-low）接线方式

2.2 软件环境

组件规格详细说明目标操作系统LoongOSYocto 项目构建的嵌入式 Linux，根文件系统高度精简内核版本Linux 4.19.190+含 rt79 PREEMPT_RT 实时抢占补丁，编译器为 GCC 8.3.0内核编译者zhangruijie@zhangruijie-virtual-machine说明该内核是由同一实验环境编译的固件PMON龙芯平台标准固件，相当于 x86 的 BIOS/UEFI主机 OSUbuntu 22.04 LTS（VMware 虚拟机）用户名 zhangruijie，NAT 网络模式宿主机 OSWindows 11 家庭中文版 10.0.26200运行 VMware 和 MobaXterm交叉编译器loongarch64-linux-gnu-gcc 8.3.0LoongArch GNU toolchain rc1.6 (20241115)工具链安装路径/usr/local/gcc-13.2.0-loongarch64-linux-gnu/虽然目录名写的是 13.2.0，实际装的是 8.3 版本串口终端MobaXterm同时支持 SSH、SFTP、串口三种连接方式AI 辅助工具Claude Code（deepseek-v4-pro 模型）运行在 Windows Git Bash 环境下

2.3 三机协作的物理拓扑

整个实训的物理连接关系如下：

1
 ┌─────────────────┐     USB 转串口     ┌──────────────────┐
2
 │  Windows 11 PC  │ ◄────────────────► │  龙芯 2K0300     │
3
 │  (宿主机)        │   115200/8/N/1     │  久久派开发板     │
4
 │                  │                    │  LoongOS 4.19    │
5
 │  运行:           │                    │  IP: 192.168.1.3 │
6
 │  - VMware        │                    └──────────────────┘
7
 │  - MobaXterm     │
8
 │  - Claude Code   │
9
 └──┬───────────────┘
10
    │
11
    │ VMware 虚拟网络 (NAT)
12
    │
13
 ┌──▼──────────────────┐
14
 │  Ubuntu 22.04 VM    │
15
 │  (编译环境)          │
16
 │                      │
17
 │  - 交叉工具链        │
18
 │  - 内核源码          │
19
 │  - 编译产物          │
20
 │  IP: 192.168.42.x   │
21
 └─────────────────────┘

需要注意的关键约束：Ubuntu 虚拟机使用 NAT 模式，IP 在 192.168.42.0/24 网段；宿主机连校园 Wi-Fi，IP 在 10.135.51.0/24 网段；开发板在 192.168.1.0/24 网段。三者之间两两不在同一子网，网络完全不通。因此文件传输只能通过 U 盘物理搬运——这是实训期间最大的工程约束之一。

三、实验过程 —— 以困难与解决为主线

模块一：GPIO 用户空间 LED 控制

实验目标

掌握 Linux sysfs 接口在用户空间操作 GPIO 的方法，先后使用 Shell 脚本和 Python 脚本控制 GPIO 83 号引脚驱动 LED 闪烁。这是嵌入式 Linux 开发的”Hello World”——从最熟悉的应用层入手，建立对 Linux 硬件抽象机制的第一印象。

实验原理

Linux 内核为用户空间提供了一套优雅的 GPIO 控制接口——sysfs。它的设计哲学是”一切皆文件”：把硬件引脚的操作抽象为对普通文件的读写。整个操作流程分为标准的四步：

第一步：导出 GPIO。 向 /sys/class/gpio/export 写入引脚编号（如 83），内核会为该 GPIO 分配资源并在 sysfs 中创建对应的控制目录 /sys/class/gpio/gpio83/。

第二步：设置方向。 向 gpio83/direction 写入 "out"（输出模式，用于控制 LED）或 "in"（输入模式，用于读取按键等）。

第三步：读写电平。 向 gpio83/value 写入 "1"（高电平，典型 3.3V）或 "0"（低电平，0V）。这里有一个容易混淆的点——LED 的实际亮灭取决于硬件接线方式：

高电平驱动（active-high）：LED 阳极接 GPIO，阴极接地，写 "1" = 亮，写 "0" = 灭
低电平驱动（active-low）：LED 阳极接 VCC，阴极经电阻接 GPIO，写 "0" = 亮，写 "1" = 灭

我们的开发板 GPIO 83 是低电平驱动方式，所以 Python 代码中 write("0") 才是”点亮”。如果搞反了这个逻辑，调试时会出现程序逻辑和别人代码对不上的困惑。

第四步：释放 GPIO。 程序退出前向 /sys/class/gpio/unexport 写入引脚编号，内核回收资源。这一步很重要——如果程序异常退出（如 Ctrl+C 中断）而没有 unexport，GPIO 会一直处于导出状态，下次运行时可能遇到”Device or resource busy”错误。

Python 脚本的模块化设计

Shell 脚本版本很简单，就是顺序执行四步操作。Python 版本做了更完善的设计：使用函数封装每个步骤（gpio_export()、gpio_write()、blink()、gpio_unexport()），支持两种运行模式——固定次数闪烁（默认 5 次，执行完自动退出并清理）和无限闪烁（Ctrl+C 中断后通过 try/finally 确保 GPIO 被正确释放）。Python 版本还用 time.sleep(1) 控制 1 秒的闪烁间隔，用 print() 输出当前运行状态方便观察。

遇到的困难

第一个实验就让我深刻体会到了嵌入式开发与桌面开发的一个关键区别：你以为理所当然存在的东西，在嵌入式系统里可能都没有。

困难一：权限错误 —— 但原因不是权限

我以 root 用户登录开发板后，自信地输入了第一条命令：

1
 echo 83 > /sys/class/gpio/gpio83

Shell 直接返回 Permission denied。我反复 whoami 确认自己是 root，一度怀疑是文件系统挂载成了只读。后来才知道这里有两个错误同时存在：

GPIO 83 根本没有被 export，/sys/class/gpio/gpio83/ 这个目录还不存在——我试图往一个不存在的路径写数据
就算目录存在，gpio83 是一个目录名，不能直接往里写数据，需要写到 gpio83/value 或 gpio83/direction

正确的第一步是 echo 83 > /sys/class/gpio/export。这个错误暴露了一个思维定式：我把 Linux 错误信息的字面意思当成了真实原因。Permission denied 在这里是”目标路径不存在且无法创建”的误导性表达——有时候错误信息只是表象，需要结合上下文深入分析。

困难二：vim 困境 —— Linux 新手的必经之路

通过 MobaXterm SSH 连接开发板后，我输入 vim led_blink.py 想编辑文件。屏幕上瞬间出现了满屏的波浪号（~ 表示空行）和底部一行看不清的模式提示。我尝试了 Esc、q、Ctrl+C、Ctrl+Z，甚至直接关闭 MobaXterm 窗口重新连接——终端里还残留着 vim 的界面。这是典型的”不知道自己在哪个模式”的 vim 新手困境。最终在 AI 指导下输入 :q!（冒号 q 感叹号回车）强制退出。

困难三：系统精简 —— nano 去哪了

逃离 vim 后我决定换个友好的编辑器：

1
 nano led_blink.py

-sh: nano: command not found。LoongOS 是 Yocto 构建的高度裁剪系统，只保留了最基础的 vi，nano、vim、gedit 等通通没有。解决方案是使用 shell 的 heredoc 语法直接在终端写文件：

1
 cat > led_blink.py << 'EOF'
2
 # 代码写在这里
3
 EOF

后来 MobaXterm 的 SFTP 侧边栏文件拖拽功能调通后，文件传输才变得轻松。

困难四：Python 环境阉割 —— pathlib 消失

脚本写好后执行 python3 led_blink.py：

1
 ModuleNotFoundError: No module named 'pathlib'

pathlib 是 Python 3.4 以后的标准库，桌面上从来不会缺。但 LoongOS 的 Python 显然是去掉了”不必要”模块的精简编译版本。我将所有 Path() 路径操作替换为 open() + 字符串拼接，去掉了 pathlib 依赖。

困难五：终端粘贴缩进毁坏

用 heredoc 方式粘贴多行 Python 代码时，终端经常出现缩进随机偏移——有的行多了两格，有的行少了两格，导致 IndentationError: unexpected indent。这是因为 MobaXterm 在传输大段文本时，对换行符和空格的处理偶尔不稳定。解决办法没有捷径，只能逐行用 vi 检查和修正缩进。

最终成果与反思

两个脚本最终都成功运行，LED 以 1 秒间隔规律闪烁。这次实验让我第一次感受到：嵌入式系统是一个”减法世界”——桌面 Linux 上理所当然的一切（nano、完整的 Python 标准库、tab 补全）在嵌入式环境里都是”可选配置”，有时候甚至被裁剪掉了。从”加法思维”（我需要装什么）转变为”减法思维”（系统有什么我就用什么），是嵌入式开发入门的第一个门槛。

模块二：交叉编译工具链搭建与 C 语言 LED 程序部署

实验目标

在 x86_64 Ubuntu 虚拟机上搭建 LoongArch64 交叉编译环境，用 C 语言重写 LED 闪烁程序（相比 Python/Shell 有更好的性能和更小的运行依赖），通过 Makefile 管理本地编译和交叉编译两种构建目标，最后将交叉编译产物通过 U 盘部署到开发板并成功运行。

实验原理 —— 交叉编译的本质

交叉编译（Cross Compilation） 是嵌入式开发最核心的概念之一。它的定义很简单：编译平台（Build Platform）和目标运行平台（Target Platform）是不同的 CPU 架构。在我们的实验中：

Build Platform：x86_64 Ubuntu（uname -m 输出 x86_64）
Target Platform：LoongArch64（龙芯 2K0300 处理器）

交叉编译器 loongarch64-linux-gnu-gcc 本身是一个运行在 x86_64 上的程序，但它输出的二进制文件是按照 LoongArch64 指令集编码的，只能在龙芯 CPU 上执行。这种”在 A 平台上编译给 B 平台用”的能力是嵌入式开发的基础设施——因为嵌入式设备通常性能有限、存储空间小，不适合直接在板子上跑编译器和链接器。

实验要求同时进行本地编译和交叉编译，通过对比来直观理解两者的区别：

led_blink_native：用 gcc 本地编译 → ELF 64-bit LSB executable, x86-64 → 能在 Ubuntu 上运行（但没有 GPIO 硬件，运行会失败）
led_blink_cross：用 loongarch64-linux-gnu-gcc 交叉编译 → ELF 64-bit LSB executable, LoongArch → 必须在龙芯开发板上运行

通过 file 命令查看 ELF 头中的架构标识，可以一目了然地验证交叉编译是否成功。这种”看一眼 ELF 头”的习惯在以后的嵌入式工作中会经常用到。

遇到的困难

这个模块是整个实训中”工程琐事”最多的环节。C 代码本身不到 60 行，但从下载工具链到程序在开发板上跑起来，耗费了大量时间在与代码无关的事情上。这恰恰反映了嵌入式开发的真实面貌——很多时候瓶颈不在编程能力，而在工程环境的搭建和调试。

阶段一：工具链下载 —— 一场”找源”之旅

实验指导书给出的第一步是下载工具链，但没说从哪里下载。于是开始了漫长的尝试：

尝试 1：一键安装脚本。 指导书给了一个 gitcode.com 的脚本链接。下载后 cat install_gcc13.sh，发现内容竟然是 HTML 登录页面——gitcode.com 的 raw 文件需要认证才能访问。

尝试 2：GitHub。 搜索到龙芯官方的 GitHub 仓库有工具链发布。wget https://github.com/loongson/...，连接超时。在国内网络环境下访问 GitHub 极其不稳定，下载速度经常降到零。

尝试 3：apt 包管理器。 sudo apt install gcc-loongarch64-linux-gnu。返回 E: Unable to locate package。Ubuntu 22.04 官方仓库没有收录龙芯交叉编译器。

尝试 4：龙芯官方 FTP。 最终在 ftp.loongnix.cn（龙芯社区软件源）找到了工具链的直接下载链接：

1
 wget http://ftp.loongnix.cn/toolchain/loongson-gnu-toolchain-8.3-x86_64-loongarch64-linux-gnu-rc1.6.tar.xz

下载成功。这个经历让我认识到国产平台的软件分发现状——不像 ARM 的 gcc-arm-none-eabi 那样 apt install 就搞定，龙芯的工具链需要从官网或社区源手动获取。版本方面也做了妥协，指导书要求的是 GCC 13.2.0，而 FTP 上稳定版是 8.3.0，（涉及 BSP 版本兼容性问题——BSP 1.0 用 GCC 8.3 + Linux 5.10，BSP 2.0 用 GCC 13.3 + Linux 6.12，开发板跑的是 BSP 1.0 内核）。

阶段二：命令行操作的一连串小问题

下载完成后还有一系列操作上的坑：

目录双层嵌套：执行 mv toolchain /usr/local/gcc-13.2.0 时，目标目录已存在，mv 的行为是把源目录放入目标目录内部而非替换它，结果路径变成 /usr/local/gcc-13.2.0/toolchain/bin/...。PATH 环境变量配的路径完全找不到可执行文件。解决方法是 tar -xvf xxx.tar.xz --strip-components=1 -C /usr/local/gcc-13.2.0 直接解压到目标位置。
命令被终端换行截断：复制粘贴多行命令时，MobaXterm 有时会在不该换行的地方截断，导致命令参数不完整。这个问题的根源是 Windows 和 Linux 的换行符差异（\r\n vs \n），以及终端缓冲区对长命令的处理方式。

阶段三：Makefile 的 Tab 地狱 —— 不可见字符的陷阱

按照实验指导书编写好 Makefile 后，自信地敲下 make：

1
 Makefile:2: *** missing separator.  Stop.

我把第 2 行反复看了不下五遍，语法完全正确。搜索后才知道：Makefile 每个 target 下的命令行（recipe）必须以 Tab 字符开头，不能用空格缩进。 在编辑器里，Tab 和 4 个空格看起来一模一样，但 make 程序是通过 ASCII 码来区分的——Tab = \t = 0x09，空格 = 0x20。

为什么我会用空格？因为实验指导书的代码是通过网页浏览器复制粘贴的，浏览器渲染时把 Tab 替换成了空格显示，复制时 Tab 就永久丢失了。解决办法是在编辑器中开启”显示空白字符”（VS Code 中是 Editor: Render Whitespace），或者用命令修复：

1
 sed -i 's/^    /\t/' Makefile

这个坑几乎每个第一次写 Makefile 的人都会遇到。它还揭示了一个更普遍的规律：编程工具链对”不可见字符”的依赖是新手陷阱的重灾区。Python 的缩进（空格和 Tab 混用）、Makefile 的 recipe 行、Shell 脚本的换行符（\r\n vs \n），都是看起来一样但实际上不同的东西。学会区分和检测不可见字符是程序员的基本功。

阶段四：VMware USB 控制器兼容性 —— 硬件虚拟化也有坑

编译完成后，需要把可执行文件从 Ubuntu 虚拟机传输到开发板。网络不通（后面会讲到），只能用 U 盘。在 VMware 菜单中点击”连接 U330 USB 设备”后，Ubuntu 里执行 lsblk——空空如也。

查看内核日志 sudo dmesg | tail -20：

1
 usb 1-1: Invalid ep0 maxpacket: 9
2
 usb 1-1: unable to enumerate USB device

VMware 的 USB 2.0（EHCI）控制器和这个朗科 U 盘不兼容。这是 VMware 已知的 USB 直通（passthrough）兼容性问题。解决方法：关闭虚拟机 → 虚拟机设置 → USB 控制器 → 从 USB 2.0 改为 USB 3.0（xHCI）→ 启动虚拟机 → 重新连接 U 盘。lsblk 这次正确显示了 /dev/sdb（58.6GB）。

阶段五：文件系统兼容性 —— 开发板不认识 FAT32

U 盘在 Ubuntu 上挂载、复制文件、卸载，插到开发板上，执行：

1
 mount /dev/sda1 /mnt

返回 unknown filesystem type 'vfat'。尝试加载内核模块：

1
 modprobe vfat

返回 FATAL: Module vfat not found。这意味着开发板内核编译时完全没有包含 vfat/FAT32 支持——既没有编译进内核，也没有编译为模块。

大多数 U 盘出厂默认 FAT32 格式是为了跨平台兼容（Windows/Mac/Linux 都能读写），但嵌入式 Linux 为了精简内核体积，只保留了 ext4 等最必需的文件系统驱动。解决方案是将 U 盘重新格式化为 ext4：

1
 sudo mkfs.ext4 /dev/sdb1

风险提示：这会清空 U 盘上所有数据！格式化前务必确认 U 盘里没有需要保留的文件。格式化后还需重新拔插 U 盘让内核识别新的分区表和文件系统签名。

阶段六：U 盘设备名漂移 —— 没有持久化绑定

每次拔插 U 盘后，它的设备名都在变化：

1
 sda → sdb → sdc → sde → ...

这是因为 Linux 内核按照 USB 设备枚举的先后顺序动态分配块设备节点名（/dev/sd*），没有任何持久化绑定（不像 /dev/disk/by-uuid/ 或 /dev/disk/by-id/ 那样稳定）。开发板上连 lsblk 命令都没有（系统裁剪 again），只能用 ls /dev/sd* 和 fdisk -l 来确认当前设备名。

阶段七：ext4 超级块损坏

格式化 ext4 后挂载时又出错：

1
 EXT4-fs (sdb1): couldn't mount as ext3 due to feature incompatibilities

文件系统超级块（superblock）在格式化后出现了不一致。fsck.ext4 -y /dev/sdb1 修复后正常。

阶段八：网络困境 —— 为什么放弃 SCP

整个实训期间，Ubuntu 虚拟机和开发板的网络始终不通。经过详细排查：

Ubuntu 虚拟机：VMware NAT 模式，IP 为 192.168.42.x
Windows 宿主机：连校园 Wi-Fi，IP 为 10.135.51.x
开发板：静态度 192.168.1.3
三者之间两两不在同一子网，ping 全部返回 Network is unreachable
没有路由设备连接这三个网段

尝试将 VMware 网络模式改为桥接（Bridged），但桥接后虚拟机获取到的是校园网 DHCP 地址（10.135.51.x），仍然和开发板的 192.168.1.x 不在同一网段。想要打通需要额外配置路由规则或 NAT 转发，在实训时间有限的情况下不现实。最终决定全程使用 U 盘物理传输——每次多花几分钟拔插操作，但它不依赖任何网络配置，在隔离的嵌入式开发环境中反而最可靠。

阶段九：开发板目录结构差异

在开发板上执行 mkdir -p /root && cp /mnt/led_blink_cross /root/ 时报错 /root 目录不存在。标准 Linux 发行版中 root 用户的家目录是 /root，但 LoongOS 的根文件系统中省略了这个目录（root 直接使用 / 作为家目录）。改为 cp /mnt/led_blink_cross ~/ 后正常。

最终成果与反思

1
 # Ubuntu 上交叉编译
2
 $ make cross
3
 loongarch64-linux-gnu-gcc -o led_blink_cross led_blink.c
4
 $ file led_blink_cross
5
 led_blink_cross: ELF 64-bit LSB executable, LoongArch, version 1 (SYSV),
6
 dynamically linked, interpreter /lib64/ld.so.1, for GNU/Linux 4.15.0, not stripped
7
 
8
 # 开发板上运行
9
 # ./led_blink_cross
10
 LED blinking finished!   # LED 实际闪烁了 5 次，每次 1 秒亮、1 秒灭

C 语言 LED 程序在龙芯开发板上成功运行。这个模块耗费时间最长的部分不是编写 C 逻辑，而是九个”非代码”问题的逐一排查。它让我深刻体会到：嵌入式开发的瓶颈往往不在编程能力，而在工程环境——从哪里下载工具链、文件怎么过墙（物理的和网络的）、设备为什么不被识别、文件系统为什么挂不上。这些问题在 x86 桌面开发中几乎不存在（apt install + 本地运行搞定一切），但在嵌入式领域却是每天的日常。

模块三：PMON 固件基础操作

实验目标

了解龙芯平台 PMON 固件的基本功能、命令体系、启动流程、和自动启动配置方法。能够从 PMON 命令行手动加载 Linux 内核并引导系统启动。

实验原理 —— PMON 在系统启动中的位置

PMON 是龙芯平台的系统固件，在系统启动链中处于最底层的位置。它在系统中的角色完全等同于 x86 PC 的 BIOS 或 UEFI。当按下电源键后，SoC 首先执行固化在 ROM/Flash 中的 PMON 代码：

上电自检（POST）：初始化 CPU 核心、DDR 内存控制器、基础时钟树
外设枚举：扫描并初始化 eMMC、USB Host、以太网等外设，为它们分配 PMON 内部设备名（如 emmc0、usb0、syn0、syn1）
查找启动配置：按优先级顺序查找——先检查根目录是否有 boot.cfg 文件，没有则读取 autocmd 环境变量，再没有则使用 al/al1/rd/append 变量组合
加载内核：根据配置中的路径，从指定设备加载内核 ELF 文件（vmlinuz）到内存的指定地址
加载 initrd（可选）：如果配置了 ramdisk，将其加载到内存
传递设备树（DTB）：将 .dtb 二进制文件加载到内存并告知内核其位置
设置内核命令行参数：console=、root=、rdinit=、rootdelay= 等
跳转执行：CPU 程序计数器跳转到内核入口地址，此后由 Linux 内核接管一切

如果在启动过程中按了空格键，或者自动启动配置缺失/失败，就会进入 PMON 交互命令行，提示符为 PMON>。这时管理员可以手动执行 load、initrd、g（go）等命令来加载和启动系统。

PMON 核心命令速查

命令语法示例功能说明hh显示帮助信息和可用命令列表versvers查看 PMON 固件版本号devlsdevls列出所有检测到的设备及其 PMON 设备名loadload (usb0,0)/boot/vmlinuz从指定设备的指定路径加载 ELF 格式内核到内存initrdinitrd (usb0,0)/boot/initrd.img加载 ramdisk（initramfs）镜像gg console=ttyS0,115200 root=/dev/mmcblk0p1设置内核命令行参数并从入口地址开始执行setset autocmd "load (usb0,0)/boot/vmlinuz;g"设置环境变量（注意值中不能有空格）unsetunset autocmd删除环境变量floadfload (usb0,0)/pmon.bin烧录/更新 PMON 固件本身pingping 192.168.1.1测试网络连通性ifconfigifconfig syn0 192.168.1.100配置网络接口 IPfdtfdt (usb0,0)/boot/loongson_2k0300.dtb手动加载设备树文件blbl列出启动配置信息

PMON 与 Linux 的设备命名对照

一个关键认知是：PMON 的设备命名和 Linux 内核的设备命名是两套完全独立的体系。它们在同一个硬件上使用不同的名称：

硬件实体PMON 中的名称Linux 内核中的名称板载 eMMC 存储emmc0/dev/mmcblk0（块设备），mmc0（控制器）USB 大容量存储usb0/dev/sda（或 sdb/sdc，取决于枚举顺序）千兆以太网syn0, syn1eth0, eth1（或 stmmac）回环设备loopdev0/dev/loop0

理解这个对应关系在后续的内核启动调试中起到了关键作用——当内核 panic 报 Cannot open root device "mmcblk0p1" 时，我们可以回到 PMON 用 devls 确认 emmc0 硬件是否被检测到，从而判断问题是出在硬件层面还是内核的设备树配置层面。

遇到的困难与反思

这个实验以理论学习为主，最大的困难不是技术操作，而是思维模式的切换。在前两个模块中，我们一直在 Linux 操作系统内部工作——有熟悉的 bash shell、ls / cd / cat 命令、tab 补全、命令历史、文件系统层级结构。但 PMON 是裸机固件：没有文件系统的概念（(usb0,0)/boot/vmlinuz 是 PMON 自己定义的一种设备路径语法，不是 Linux 路径），没有 tab 补全，输错参数就要全部重打，命令总数也就十几个。

这种切换的本质是从”操作系统提供的丰富抽象”降到”固件提供的极简抽象”。在操作系统里你习惯了 cd /boot && ls -la，在 PMON 里你得用完全不同的语法 devls 先看有哪些设备，然后凭记忆输入完整的内核路径。如果忘记设备名或路径，只能重启再看。

另外，设备树的传递过程值得特别理解：PMON 负责从存储设备读取 DTB 文件，将其加载到内存的指定位置，并在跳转到内核前把 DTB 的内存地址告知内核。如果 DTB 文件损坏（后面实验会遇到的 dtb chsum err!!!），或者 PMON 没有正确传递地址，内核就无法识别平台设备（GPIO 控制器、MMC 控制器等），导致启动失败。这个机制在后面实验四的内核 panic 排查中成为了分析问题的关键线索。

模块四：Linux 内核模块驱动开发 —— GPIO LED 驱动

实验目标

这是本次实训最核心、难度最高、耗时最长的实验。目标是：获取龙芯定制 Linux 4.19 内核源码，编写完整的 GPIO LED 驱动模块，通过交叉编译生成 .ko（Kernel Object）文件，在开发板上使用 insmod 加载驱动，驱动加载时自动点亮 LED 并通过 printk 内核日志输出学号。实验还涉及修改内核 Kconfig/Makefile 构建系统将自定义驱动集成进去，以及修改设备树（DTS）文件为 GPIO 引脚添加正确的 pinctrl 配置。

实验原理

内核模块 vs 用户空间程序的本质区别

前面模块一和模块二中，我们通过 sysfs 接口从用户空间控制 GPIO。调用链是：用户程序 → write() 系统调用 → VFS 虚拟文件系统 → sysfs 文件系统 → GPIO 子系统 → 硬件寄存器。每次 GPIO 操作都要穿越用户态到内核态的边界（系统调用开销），数据要经过多层抽象转换。

内核模块则完全不同——它直接运行在内核空间，享有最高的 CPU 特权级（Ring 0），调用的是内核内部 API（gpio_request()、gpio_direction_output()、gpio_set_value() 等），直接操作硬件寄存器，没有系统调用开销。内核模块没有 main() 函数，取而代之的是 module_init(fn) 和 module_exit(fn) 两个宏——前者指定模块加载时执行的初始化函数，后者指定模块卸载时执行的清理函数。

编译后的内核模块是 .ko（Kernel Object）文件，通过 insmod 命令加载、rmmod 卸载、lsmod 查看已加载模块列表、dmesg 查看内核日志（包括 printk 输出）。模块必须是 GPL 兼容许可证才能使用内核的 GPL-only 符号。

Kconfig/Makefile 构建系统

Linux 内核使用一套精密的配置和构建系统来管理数千个驱动和功能选项。要向内核添加一个自定义驱动，需要修改两个文件：

Kconfig：定义配置选项的元数据。它告诉 make menuconfig 界面应该显示什么选项、该选项的依赖关系、以及它对应什么编译行为（tristate 表示可以选 Y/M/N）：

1
 config LEDS_2K0300_GPIO
2
     tristate "LED Support for Loongson 2K0300 GPIO"
3
     depends on LEDS_CLASS && GPIOLIB
4
     help
5
       This option enables LED driver for Loongson 2K0300
6
       using GPIO 83.

Makefile：定义编译规则。它告诉内核构建系统当某个配置项被选中时应该编译哪些源文件：

1
 obj-$(CONFIG_LEDS_2K0300_GPIO) += leds-2k0300-gpio.o

这行代码的妙处在于 $(CONFIG_LEDS_2K0300_GPIO) 会根据 .config 中的配置值自动展开为 y、m、或空——分别对应编译进内核（obj-y）、编译为模块（obj-m）、或不编译。

设备树（Device Tree）机制详解

x86 PC 上的硬件很多是”可枚举”的——PCI 总线、USB 总线等都有标准的设备发现协议，内核启动时能自动扫描并识别外接设备。但嵌入式 SoC 平台不一样：大量的外设（GPIO 控制器、I²C、SPI、UART、MMC/SDIO 控制器等）是直接挂在芯片内部的内存映射总线上的，没有标准的自动发现机制。

设备树（Device Tree）就是为了解决这个问题。它是一种数据结构（源文件 .dts 编译为二进制 .dtb），在系统启动时由固件（PMON）传递给内核，告诉内核：

这个 SoC 上有哪些硬件（设备节点）
它们挂载在哪个总线上（compatible 属性用于匹配驱动）
它们的寄存器基地址、中断号、时钟源是什么（reg、interrupts、clocks）
GPIO 引脚的多功能复用如何配置（pinctrl 子系统）

在我们的实验中，设备树的样子大概是：

1
 &gpio {
2
     led_pin: led {
3
         gpios = <&gpio 83 GPIO_ACTIVE_HIGH>;
4
         label = "heartbeat";
5
     };
6
 };

&gpio 是引用（label reference）已定义的 GPIO 控制器节点，gpios = <&gpio 83 ...> 指定使用该控制器的第 83 号引脚。

内核模块加载的三道 ABI 校验机制

Linux 内核为模块加载设下了层层校验，确保模块与当前运行内核的二进制接口（ABI）完全兼容。理解这三道锁是成功加载模块的关键：

第一道：vermagic（版本魔术字符串）。编译模块时，构建系统会自动在 .ko 文件的 .modinfo 段中嵌入一个”版本魔术字符串”，包含：

1
 vermagic: 4.19.190+ SMP preempt mod_unload modversions LOONGARCH64

insmod 首先将模块中的 vermagic 与运行中内核的 vermagic 做字符串比对，任何差异都会直接导致加载失败。

第二道：module_layout 符号。这不是一个普通函数，而是一个数据结构校验和。它编码了内核核心数据结构 struct module 的大小和关键成员的内存偏移量。如果正在运行的内核和编译模块时使用的内核在抢占模型（PREEMPT vs PREEMPT_RT）、SMP 配置、内存管理选项等方面有差异，struct module 的布局就会不同，module_layout 的 CRC 值就会变化。

第三道：CONFIG_MODVERSIONS（符号级 CRC 校验）。启用后，内核为每个导出的符号（函数、变量）计算 CRC32 校验值。模块编译时会记录所有引用符号的 CRC 值，insmod 加载时将这些 CRC 与运行内核的实际情况逐一比对。即使内核版本号完全一样，只要某个内核配置项（尤其是影响函数签名的）不同，CRC 就会不匹配。

这三道锁层层递进：vermagic 是粗粒度的字符串匹配，module_layout 是数据结构级别的校验，modversions 是符号级别的校验。全部通过后才能成功加载。理解这些机制是后续调试 insmod 失败的基础。

遇到的困难

阶段一：编译困难

问题现象原因分析解决过程内核源码不在工作目录tar -xvf linux-4.19-0627.tar.gz 报文件不存在浏览器下载时使用了默认路径 ~/Downloads/，而我当时的工作目录是 ~/loongarch-dev/在 Downloads 目录找到后 mv 迁移过来缺少编译依赖make menuconfig 报 fatal error: openssl/opensslv.h: No such file or directory虚拟机是相对干净的 Ubuntu 22.04，缺少内核编译所需的大量开发库sudo apt install libssl-dev libelf-dev flex bison bc没有精确匹配的 defconfigmake loongson_2k0300_defconfig 报 No rule to make target2K0300 是较新的开发板，该版内核源码中并没有预置同名的默认配置以最接近的 loongson2_defconfig 为基础，再通过 make menuconfig 手动设置 CONFIG_LOCALVERSION="+" 等选项

阶段二：设备树困难 —— “看不到的依赖”

交叉编译走通了（make modules 成功生成 .ko），但设备树这边接连爆雷：

问题 1：dtbs 编译无任何输出。 执行 make dtbs 后静默结束，arch/loongarch/boot/dts/loongson/ 下空空如也。排查后发现 .config 中 CONFIG_BUILTIN_DTB_NAME=""——内核不知道要为哪个板子编译 DTB。通过 make menuconfig → “Boot options” → “Built-in DTB name” 设置为 loongson_2k0300_pai_99。

问题 2：DTC include 路径错误。 设置 DTB 名称后再次编译：

1
 fatal error: dt-bindings/gpio/gpio.h: No such file or directory

DTS 源文件顶部有 #include <dt-bindings/gpio/gpio.h>，这个 <> 的搜索路径中包含 arch/loongarch/boot/dts/include/，但这个目录不存在——它应该是一个符号链接，指向内核源码根目录的 include/。为什么它不存在？可能是在解压或迁移源码时符号链接丢失了（某些压缩格式不保留符号链接）。

1
 cd arch/loongarch/boot/dts
2
 ln -s ../../../../include include

创建符号链接后 include 问题解决。这件事让我学到一个经验：解压内核源码后，先检查符号链接是否完整。

问题 3：pinctrl 标签未定义。 引用了 .dtsi 头文件中不存在的 pinctrl 标签。需要仔细检查所 include 的 .dtsi 文件中实际定义了哪些标签，确保引用名称完全一致。

阶段三：模块加载困难 —— 内核设下的三道校验锁

编译终于全部通过，leds-2k0300-gpio.ko 成功生成。通过 U 盘拷到开发板上，敲下 insmod：

1
 insmod leds_2k0300_gpio.ko

第一道锁：module_layout 版本号后缀不匹配

1
 insmod: ERROR: could not insert module leds_2k0300_gpio.ko: Invalid module format

dmesg 查看内核日志：

1
 leds_2k0300_gpio: disagrees about version of symbol module_layout

我首先用 modinfo 查看模块信息：

1
 vermagic:       4.19.190 SMP preempt mod_unload modversions LOONGARCH64

而开发板 uname -r 输出：

1
 4.19.190+

就差了末尾的 + 号，这个 + 来自内核配置项 CONFIG_LOCALVERSION="+"（Yocto 构建系统默认加的后缀，表示代码树有未提交的修改）。我们在 Ubuntu 的内核 .config 中加上 CONFIG_LOCALVERSION="+" 重新编译模块，vermagic 对齐。

第二道锁：CONFIG_MODVERSIONS CRC 校验不匹配

版本对齐后再次 insmod，又报新的错误：

1
 leds_2k0300_gpio: disagrees about version of symbol gpio_request
2
 leds_2k0300_gpio: Unknown symbol gpio_request (err -22)

这表示开发板内核启用了 CONFIG_MODVERSIONS，每个导出符号都有 CRC 校验和。要让 CRC 完全匹配，需要获得开发板的精确内核配置。理想方案是从 /proc/config.gz 导出配置后完整重编译内核，但这有两个前置条件：

CONFIG_IKCONFIG_PROC 必须已在内核中启用（否则 /proc/config.gz 不存在）
完整重编译内核在我们环境中需要数十分钟

在我们的场景下，时间不允许完整重编译。经过分析后做出的决策是：使用 insmod -f（--force）强制加载，跳过 CRC 校验。 这不是盲目试错——我们的驱动只使用了标准 GPIO 子系统 API（gpio_request、gpio_direction_output、gpio_set_value、gpio_free），这些 API 的签名和实现在标准内核和 RT 内核中是完全一致的，不受 PREEMPT_RT 抢占模型差异的影响。强制加载不会导致内核崩溃或数据损坏。

1
 insmod -f leds_2k0300_gpio.ko

成功。

关于 insmod -f 的深入思考：在工程实践中，“强制”操作永远应该是最后的选择而非第一反应。如果一个新人遇到 insmod 失败就立刻 -f，那就是在蒙。但如果理解了 vermagic 的作用、module_layout 的编码内容、modversions 的 CRC 机制、以及 RT 补丁对内核数据结构的影响范围，然后做出”标准 GPIO API 不受影响、强制加载是安全的”这个判断，那就是真正的工程能力。“知其所以然”的变通，和”不知其所以然”的蛮干，表面上看起来做了同一件事，本质完全不同。 这是本次实训最重要的方法论收获。

阶段补充：内核启动 panic —— 设备树问题的连锁反应

在实验过程中，开发板还出现过一次严重的启动失败——内核 panic。这对理解设备树的作用是一次”反面教材”式的加深：

1
 [    5.734658] mmc0: new HS200 MMC card at address 0001
2
 [    5.750356] mmcblk0: mmc0:0001 8GTF4R 7.28 GiB
3
 ...
4
 [    9.947322] VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0): error -6
5
 [    9.955287] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

分析日志：

在 5.73 秒，MMC 控制器（ls2k_sdio 驱动）探测到了 eMMC 卡，显示了正确的容量（7.28 GiB）
但在 9.95 秒，内核报告找不到 mmcblk0p1 块设备，error -6 = ENXIO（No such device or address）
关键线索在 PMON 启动阶段的输出中：dtb chsum err!!!

这个 dtb chsum err!!! 意味着 PMON 传递给内核的设备树二进制文件校验和错误——文件可能已经损坏。设备树中 MMC 控制器的描述信息可能不完整或错误，导致内核虽然在底层硬件枚举阶段探测到了卡（这也是 mmc0: new HS200 MMC card 能打出来的原因——硬件枚举是控制器驱动直接做的，不完全依赖设备树），但在上层的块设备注册阶段（block layer）失败了——因为没有正确的设备树节点，块设备层不知道要创建 /dev/mmcblk0 这个设备。

时序排查：将内核命令行参数 rootdelay 从 5 秒增大到 15 秒后依然 panic，排除了”设备还没就绪”的时序假说。

两套设备名验证：回到 PMON 用 devls 确认 emmc0 设备存在——硬件没问题，eMMC 卡是好的。问题出在 PMON → 内核的数据传递环节。这个排查链条完美体现了”理解 PMON 设备名和 Linux 设备名的对应关系”的实用价值。

最终成果

1
 # insmod -f leds_2k0300_gpio.ko
2
 # dmesg | tail -5
3
 [ 2988.090198] Simple LED driver loading
4
 [ 2988.097566] loongson pinctrl 16000490.pinctrl: request pin 83 (GPA80-3) for GPA80:83
5
 [ 2988.097591] LED on GPIO 83 turned ON
6
 [ 2988.097591] Student ID: 2024304788

两行关键日志：

loongson pinctrl ... request pin 83 ... for GPA80:83 — 引脚控制子系统成功为 GPIO 83 分配了引脚复用功能
LED on GPIO 83 turned ON — LED 亮了
Student ID: 2024304788 — 学号输出成功

两个多小时的鏖战，从编译到设备树到模块加载，终于在看到 LED 亮起的那一刻得到了回报。这是整个实训最具挑战也最有成就感的时刻。

四、实训收获 —— 技术、工程、方法论

4.1 技术知识体系

整个实训帮助我建立起了一个清晰的嵌入式 Linux 分层认知模型：

1
 ┌──────────────────────────────────────────┐
2
 │  系统构建层 │ OpenWrt / Yocto / Buildroot │ ← 固件镜像的自动化生产
3
 ├──────────────────────────────────────────┤
4
 │  内核驱动层 │ .ko 模块、设备树、pinctrl   │ ← 与硬件直接对话
5
 ├──────────────────────────────────────────┤
6
 │  编译部署层 │ 交叉编译、Makefile          │ ← 连接开发和运行的桥梁
7
 ├──────────────────────────────────────────┤
8
 │  应用编程层 │ C / Shell / Python           │ ← 用户空间的逻辑
9
 ├──────────────────────────────────────────┤
10
 │  固件引导层 │ PMON                        │ ← 硬件苏醒的第一段代码
11
 └──────────────────────────────────────────┘

具体的技术收获包括：

GPIO 子系统：从 sysfs 用户空间接口到内核 API（gpio_request/gpio_set_value/gpio_free），理解了”文件即硬件”的 Unix 哲学如何在 Linux 中不同层次体现
交叉编译：深刻理解 Build ≠ Target，掌握了 ARCH、CROSS_COMPILE、工具链安装、file 命令验证架构的完整流程
内核模块开发：module_init/module_exit 框架、Kconfig/Makefile 构建系统集成、printk 日志级别
设备树：DTS 语法（label reference &、pinctrl）、DTC 编译、include 路径依赖、dtb 在启动流程中的传递机制
模块加载校验：vermagic、module_layout、CONFIG_MODVERSIONS 三道锁的递进关系和破解方法
龙芯生态：LoongArch64 指令集、PMON 固件、Loongnix 软件源、2K0300 BSP 版本兼容性
内核启动调试：panic 日志分析、ENXIO 错误码含义、rootdelay 参数调优、设备树完整性验证

4.2 调试思维的建立 —— 最大的成长

回顾实训全程，最有长远价值的不是某一个技术点，而是一套面对未知错误的系统化分析思路。

以前遇到报错，我的反应是：看到错误信息 → 感到慌张 → 复制粘贴去搜索引擎 → 找到第一个看起来相关的结果 → 照做。这种方法的缺点是：不理解原因，下次遇到类似的变种错误还是不会。

经过这五个模块 20+ 个问题的训练，现在遇到报错会按这样的流程思考：

准确阅读错误信息：逐词理解报错文本，而不是扫一眼就下结论。Permission denied 不一定是权限问题，missing separator 指的是不可见字符 Tab 缺失。
区分症状和根因：module_layout 不匹配是症状，根因是内核配置中 CONFIG_LOCALVERSION 和 CONFIG_MODVERSIONS 与开发板不一致。只治症状（如随意 insmod -f）不是真正的解决问题。
逐层排除：文件在不在 → 命令对不对 → 版本匹不匹配 → 配置一不一致 → 硬件是否正常。每一层都排除了再到下一层。
理解后再做取舍：insmod -f 跳过了 CRC 校验，在确认 GPIO API 不受 RT 补丁影响的前提下是安全的工程权衡。理解了什么被跳过了、为什么跳过是安全的——这是”知其所以然”的工程判断。
善用工具但不依赖工具：dmesg 查看内核日志、modinfo 查看模块 vermagic、file 验证 ELF 架构、PMON devls 确认硬件——每个工具都有它最适合的诊断场景。

4.3 国产平台的实践认知

本次实训的特殊之处在于使用了龙芯 LoongArch 平台而非常见的 ARM（STM32/Raspberry Pi）。通过实训对国产自主平台有了直观认识：

技术成熟度：龙芯的 GNU 工具链已经很完善，GCC 8.3 对 LoongArch64 的支持稳定可靠。PMON 固件功能完整。Linux 内核主线从 5.19 开始逐步合入 LoongArch 支持。
生态现状：基础工具链成熟，但上层生态（包管理器覆盖、OpenWrt 支持、社区文档）与 ARM 相比还有差距。很多软件包需要从 FTP 或源码手动获取，不像 ARM 那样 apt install 就能搞定。
发展趋势：龙芯生态正在快速完善中（BSP 从 1.0 到 2.0，内核从 5.10 到 6.12，GCC 从 8.3 到 13.3），国产自主处理器的软件生态建设是一个长期但方向明确的工程。

4.4 AI 辅助学习的方法论

实训全程在 Claude Code 的辅助下完成。关于如何使用 AI 来辅助编程学习，我有几点体会：

AI 最适合的角色是”实时导师”：当终端报出一个错误时，AI 能够同时在几个维度给出反馈——错误的字面含义、可能的根因（通常给出 2-3 个假设）、每种假设的验证方法、以及背后的原理。这个”一条龙”式的诊断流程，比搜索引擎逐个页面翻阅的效率高出一个数量级。
AI 不能替代自己的判断：insmod -f 的方案是 AI 给出的（带着风险提示），但最终采不采用，取决于自己是否真的理解了 module_layout 和 modversions 的含义。如果无脑执行 AI 的每一条建议，学到的是零。
AI 辅助下，“不怕遇到问题”成为可能：以前遇到一个完全不懂的错误（如”module_layout 不匹配”），可能要花很长时间搜索、理解、尝试。现在 AI 能在几分钟内讲清楚来龙去脉，让”踩坑 → 学习”的循环极大加速。这也是为什么我能在一次实训中经历 20+ 个问题却依然能推进——每个问题都成为了一个高效的学习机会。

五、总结

本次实训以龙芯 2K0300 久久派开发板为硬件平台，围绕嵌入式 Linux 开发的核心技术链路，从应用层到底层固件，逐层深入，完成了五个模块的学习与实践：

模块内容概述层次核心困难关键收获GPIO 用户空间 LED 控制Shell/Python + sysfs GPIO 83 闪烁应用层裁剪系统缺工具、vim 困境、Python 标准库不全建立”嵌入式是减法世界”的认知交叉编译与 C 程序部署工具链安装、Makefile、C LED、U 盘传输编译层工具链下载源不稳定、Tab 缩进、USB 兼容性、文件系统不匹配、网络不通理解 Build ≠ Target，掌握工程环境搭建能力PMON 固件基础固件命令体系、启动流程、自动启动配置固件层裸机思维切换、设备命名体系差异理解固件在启动链中的角色内核模块驱动开发.ko 模块、Kconfig/Makefile、设备树、insmod 加载内核层编译依赖缺失、设备树 include 路径/语法、module_layout 版本不匹配、CRC 校验失败、内核 panic掌握驱动开发全流程和模块加载校验机制OpenWrt 系统构建初探构建系统架构、menuconfig 配置、软件包选择系统层依赖安装、源码获取理解从源码到固件的自动化构建流程

20 余个问题，从命令拼写到内核 ABI 校验，从 USB 控制器驱动到设备树传递机制——每一个问题的排查和解决，都迫使我深入理解背后的原理。

实训最大的价值不在于”点亮了一个 LED”，也不在于”写出了第一个内核模块”，而在于建立起了一套面对未知问题时的系统化分析框架——遇到报错不慌张，逐层定位根因，充分理解原理后再做工程决策。这种”调试思维”不是一个具体的技术栈，而是一种可以迁移到任何技术栈的底层能力。它会伴随我在计算机领域的每一步成长。

在国产自主处理器平台上完成这次实训，还多了一层特殊意义。从龙芯的指令集到 PMON 固件，从 Loongnix 的软件源到 LoongOS 的实时内核。在这个国际技术环境日趋复杂的时代，了解并掌握自主平台的技术体系，是我们这一代计算机专业学生的责任，也是机遇。

📅 实训时间：2026年7月

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://www.originblog.xyz/blog/post_1783926984/

Hello-Agent:构建一个能处理分步任务的智能旅行助手暨拓展

Origin Blog — Sat, 06 Jun 2026 00:00:00 GMT

为了能从 Python 程序中访问网络 API，我们需要一个requests 库。avily-python是一个强大的 AI 搜索 API 客户端，用于获取实时的网络搜索结果

openai是 OpenAI 官方提供的 Python SDK，用于调用 GPT 等大语言模型服务，通过指令安装：

1
pip install requests tavily-python openai

驱动真实 LLM 的关键在于**提示工程（Prompt Engineering），**将作为system_prompt传递给 LLM

当前，许多 LLM 服务提供商（包括 OpenAI、Azure、以及众多开源模型服务框架如 Ollama、vLLM 等）都遵循了与 OpenAI API 相似的接口规范。这种标准化为开发者带来了极大的便利。智能体的自主决策能力来源于 LLM。例如OpenAICompatibleClient，它可以连接到任何兼容 OpenAI 接口规范的 LLM 服务。

这个简单的旅行助手案例，集中演示了基于Thought-Action-Observation范式的智能体所具备的四项基本能力：任务分解、工具调用、上下文理解和结果合成。正是通过这个循环的不断迭代，智能体才得以将一个模糊的用户意图，转化为一系列具体、可执行的步骤，并最终达成目标。

但在运行过程中发现有以下问题：

‍

第 2-3 轮模型返回了空内容，导致解析失败浪费了 2 次循环。这是因为我的DeepSeek 模型在收到 Observation 后偶尔会输出空行。

所以我加一个重试机制——当输出为空时自动重新调用 LLM，让整个流程更稳定

1
if llm_output.startswith("错误:"):
2
        print(f"🚫 LLM 调用彻底失败: {llm_output}\n" + "="*40)
3
        break

核心问题：LLM（包括 DeepSeek）本质上是概率采样系统——每次根据概率分布随机选择下一个 token。这意味着同样的输入可能产生不同输出。偶尔采样路径会走进”死胡同”，模型输出空字符串——API 返回 200 但 content 为 None 或 ""。

1
正常采样路径:  "Thought" → ":" → " 查询" → "天气" → ... ✅
2
异常采样路径:  <EOS>  (模型直接选择结束)              ❌ → 空输出

拓展：

当前的架构：

1
┌──────────────┐     ┌──────────────────┐
2
│  prompt.py   │ ──▶ │ OpenAICompat...  │ ──▶  DeepSeek API
3
│  (主循环)     │ ◀── │ (generate方法)    │ ◀──
4
└──────┬───────┘     └──────────────────┘
5
       │
6
       ▼
7
┌──────────────┐
8
│  工具调度器    │ ──▶ │ get_weather()
9
│ (正则解析)     │     │ get_attraction()
10
└──────────────┘

1. 字符串解析工具调用 — 脆弱且不精确

1
模型输出字符串
2
     │
3
     ▼
4
re.search(r"Action: (.*)", llm_output)    ← 模型多写一个空格
5
     │
6
     ▼
7
re.search(r"(\w+)\(", action_str)          ← 模型写 get_weather (city="")
8
     │
9
     ▼
10
re.findall(r'(\w+)="([^"]*)"', args_str)  ← 参数是整数？嵌套引号？

问题：正则匹配容易出错，更适合用于判断。模型哪怕多一个换行、少一个引号都不行

解：因为DeepSeek 支持 原生 Function Calling，模型直接返回结构化的 JSON，由 SDK 自动解析。

‍

2. 没有区分”系统提示”和”工具定义”

当前做法是把工具描述写死在 AGENT_SYSTEM_PROMPT 字符串里：

1
# 硬编码在字符串里
2
- `get_weather(city: str)`: 查询指定城市的实时天气。
3
- `get_attraction(city: str, weather: str)`: 根据城市和天气搜索...

3. 主循环没有终止条件

1
for i in range(5):  # 写死 5 轮

如果任务不需要五轮或者需要五轮以上呢？我认为没有动态判断！

改动后架构层：

1
┌─────────────────────────────────────────────────┐
2
│  第 6 层: 交互入口                                │
3
│  while True → input() → run_agent()             │
4
├─────────────────────────────────────────────────┤
5
│  第 5 层: Agent 主循环                            │
6
│  while turn ≤ 10: chat() → 检查 tool_calls       │
7
│  → 有 → 执行工具 → 追加 tool 消息 → 继续            │
8
│  → 无 → 输出 content → 结束                       │
9
├─────────────────────────────────────────────────┤
10
│  第 4 层: 配置 (API Key / URL / Model)           │
11
├─────────────────────────────────────────────────┤
12
│  第 3 层: DeepSeekClient.chat()                  │
13
│  发送 messages + tools → 返回 Message 对象        │
14
│  内置重试: 网络异常 / 空响应                        │
15
├─────────────────────────────────────────────────┤
16
│  第 2 层: 工具实现 (get_weather / get_attraction) │
17
│  纯函数，与框架完全解耦                             │
18
├─────────────────────────────────────────────────┤
19
│  第 1 层: 工具 Schema (JSON 定义)                 │
20
│  同时用于: API tools 参数 + 自动生成提示词          │
21
└─────────────────────────────────────────────────┘

数据流Before：

1
LLM 输出字符串
2
    │  "Thought: xxx\nAction: get_weather(city=\"\")"
3
    ▼
4
re.search(r"Action: (.*)")     ← 匹配失败，一轮浪费
5
    │  "get_weather(city=\"北京\")"
6
    ▼
7
re.search(r"(\w+)\(")          ← 工具名提取
8
re.findall(r'(\w+)="([^"]*)"') ← 参数提取
9
    │
10
    ▼
11
available_tools["get_weather"](**kwargs)

数据流After：

1
LLM 返回 Message 对象
2
    │  .tool_calls = [{
3
    │    function: { name: "get_weather", arguments: '{"city":""}' }
4
    │  }]
5
    ▼
6
json.loads(tool_call.function.arguments)
7
    │  {"city": ""}    ← 已经是 Python dict，零解析
8
    ▼
9
TOOL_MAP["get_weather"](**{"city": "北京"})   ← 直接执行

1
添加新工具
2
# 1. 在 TOOLS 列表中加 Schema
3
{
4
    "type": "function",
5
    "function": {
6
        "name": "get_restaurant",
7
        "description": "搜索指定城市的美食餐厅",
8
        "parameters": {
9
            "type": "object",
10
            "properties": {
11
                "city": {"type": "string", "description": "城市名称"},
12
                "cuisine": {"type": "string", "description": "菜系，如'川菜'、'日料'"}
13
            },
14
            "required": ["city"]
15
        }
16
    }
17
}
18

19
# 2. 实现函数 + 注册到 TOOL_MAP
20
def get_restaurant(city: str, cuisine: str | None = None) -> str:
21
    ...
22

23
TOOL_MAP["get_restaurant"] = get_restaurant
24

25
# 这样提示词自动更新，主循环自动调度。

关键点：

content: null — Function Calling 模式下，模型决定调用工具时不输出文本，content 就是 null。这也是为什么重试检测要区分”有 tool_calls（正常）“和”没 tool_calls 且没 content（异常）”
arguments 是一个 JSON 字符串，不是对象。所以代码里必须 json.loads() 才能拿到 {"city": "城市"}
id: "call_abc123" — 这个就是 tool_call_id，后面回传时必须带上。

‍

`_build_tool_description()` 做了什么

1
# 遍历同一个 TOOLS 列表，自动拼出:
2
# - `get_weather(city: str)`: 查询指定城市的实时天气。返回天气描述和气温。
3
# - `get_attraction(city: str, weather: str)`: 根据城市和天气搜索推荐的旅游景点...

为什么存在：Function Calling 的 tools 参数是发给 API 的（模型据此决策），系统提示词是给我们调试看的。而两份信息来自同一份 Schema，改了 TOOLS 就不用担心提示词忘记更新QWQ。

‍

1
continue ：执行完工具后重新进入循环，把带有工具结果的新 messages 再次发给 LLM。这是 ReAct 模式的核心——模型看到工具返回后，可能再调下一个工具，也可能直接给最终答案。

‍

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://www.originblog.xyz/blog/post_1780708366/

一个拍纪录片的人，正在被时代淘汰

Origin Blog — Tue, 02 Jun 2026 00:00:00 GMT

这两天看到了一个视频，讲的是一位田野就是乡工作者，也就是我们所说的纪录片导演，对当今世界的思考，受益良多：

在如今信息洪流的快节奏时代，一切都如同流星一样划过。短视频时代使得人们的耐心变得越来越少，但是这些纪录片记录者，放慢姿态，用时间来弥补，用热爱来守护。越是瞬息万变的节奏，越要定下心去守护内心的宁静，正如作者说的：

这几年越来越意识到：
很多人并不是不痛苦，
只是已经学会了快速地活着。

但纪录片这门手艺，
偏偏反着来。

谨以此片献给时代洪流下，
仍认真用力活着的平凡人。

我们不是时代的注脚，
我们就是时代本身。

一个拍纪录片的人，正在被时代淘汰_哔哩哔哩_bilibili↗

‍

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://www.originblog.xyz/blog/chatter_1780412512/

🐱煤球接入Deepseek

Origin Blog — Mon, 01 Jun 2026 00:00:00 GMT

在此之前，煤球的模型是Gemini：

1. API 路由（核心请求入口）

my-blog-manager/app/api/chat/route.ts

这是小猫 AI 的后端路由，直接对接 Google Gemini API：

第 13 行：从环境变量 GEMINI_API_KEY 或 OPENAI_API_KEY 读取密钥

第 21-22 行：从 siteConfig.geminiConfig 读取模型 ID，构建请求 URL：

1
https://generativelanguage.googleapis.com/v1beta/models/{modelId}:generateContent?key={apiKey}

第 29-42 行：发送请求体，包含 system_instruction（猫设 prompt）、用户消息、generationConfig（token 上限、temperature）

2. API 配置（模型参数 + 猫设 Prompt）

1
geminiConfig: {
2
  modelId: "",
3
  systemPrompt: "",
4
  maxOutputTokens: ,
5
  temperature: ,
6
},

3. 前端调用方

my-blog-manager/components/CyberCat.tsx — 页面右下角的赛博小猫组件，handleFeed()和 handleChatSubmit()都向 /api/chat 发 POST 请求
my-blog-manager/components/settings/AICatSection.tsx — 后台设置页面，可修改 modelId、systemPrompt、temperature、maxOutputTokens，点”暂存至队列”写入 geminiConfig

‍

而接入Deepseek有两个需要注意的点：

‍

DeepSeek 用的是 OpenAI 兼容接口，跟 Gemini 的请求体结构完全不同：
端点，鉴别权限都不相同

‍

此外：CMS 管理后台（Settings 页面 → AI 小猫配置）点「暂存至队列」并应用，会丢失 apiKey 和 baseUrl。

原因是 cms_core/api/config.py:178-185 的写入逻辑——前端只传 4 个字段：

1
{ modelId, systemPrompt, maxOutputTokens, temperature }

后端用正则直接把整个 geminiConfig 块替换掉，新增的 apiKey 和 baseUrl 不在前端传的字段里

‍

解决问题：在 config.py 的 update_site_config 里加一个合并逻辑 —— 更新 dict 之前先保留已有字段，缺少的 key 不被丢弃。不影响现有任何功能。

1
 existing = {}
2
                m = re.search(rf"{key}\s*:\s*\{{([\s\S]*?)\}}", content)
3
                if m:
4
                    existing = parse_ts_dict(m.group(1))
5
                merged = {**existing, **value}

不过！！！把 key 明文写在代码里相当于把房门钥匙贴在门上。🐖

所以我在在 Vercel Dashboard → Settings → Environment Variables 加入环境变量，这样就不用把API放在仓库里面

搞定！

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://www.originblog.xyz/blog/chatter_1780305190/

Origin Blog

在信息之外，留一页空白

应用视角的操作系统

1. 本讲要回答的问题

2. 核心知识地图

3. 程序：一个状态机

3.1 什么是“状态”

3.2 函数调用与栈帧

3.3 为什么函数调用顺序很重要

4. 解释执行、编译与编译正确性

4.1 SimpleC：把复杂语句拆小

4.2 编译器做什么

4.3 优化与死代码消除

5. 最小应用程序：从 _start 到 exit

5.1 _start 与 main

5.2 程序如何退出

6. 系统调用：应用与操作系统的边界

7. 应用世界：程序看起来不同，本质相同

7.1 三类程序

7.2 ELF：可执行文件是初始状态的描述

7.3 复杂应用也只是 API 的组合

8. 用工具观察程序

8.1 strace

8.2 工具分工

9. 术语速查：用一句话理解

10. 最容易混淆的地方

程序、可执行文件、进程

API、库函数、系统调用

编译不是“逐行翻译”

系统调用不是普通函数调用

11. 检查

12. 实验

13. 资料来源

幻觉治理四机制（借鉴 J-Space）—— 分四阶段实施

总原则（UX 安全）

阶段一 ②：判定幻觉 → 携带诊断的定向再生（最高优先级）

1.1 _generate_one 支持修正 hint（content_generator.py）

1.2 新文件 backend/app/agents/quality_regen.py

1.3 工作流盲重试 → 定向重试（content_generator.py）

1.4 离线脚本闭环（scripts/run_quality_test.py）

1.5 测试

阶段二 ①：生成时认识状态标记（unverified_claims）

阶段三 ③：先锚定后展开（bridge-before-conclusion）

阶段四 ④：验证方式 + 覆盖双记录

项目图谱深度增强：实体丰富化 + 技术栈检测 + LLM 分析 + 联网搜索

问题根因

设计：两段式（AST 自动 + LLM 按需）

Phase 1：修复数据断层 + 实体详情丰富化（零 LLM, 自动）

1.1 api/project.js``normalizeGraphResponse 传递完整属性

1.2 ProjectGraphView.vue 实体详情面板丰富化

Phase 2：技术栈自动检测（AST, 零 LLM, 自动）

2.1 新建 frontend/src/utils/techStack.js

2.2 ProjectGraphView.vue 头部展示技术栈 badges

Phase 3：LLM 深度分析 + 联网搜索（按需）

3.1 后端新建 POST /api/project/analyze

3.2 api/project.js 加 analyzeProject(projectId, tavilyKey)

3.3 projectGraph store 加 analyze() action

3.4 ProjectGraphView.vue 加”深度分析”按钮 + 结果面板

Phase 4：测试 + 收尾

测试

修复"新领域动态建域后图谱无法生成"

执行步骤

1. 起环境 + 实库取证

2. 根因处置

3. 验证后端修复

4. 前端防御（治本加固）

5. 回归测试

6. E2E 浏览器验证（browser-use）

7. 文档 + 提交

备注

差点见不到我的博客

嵌入式图存储：打包版免 Docker/Neo4j

背景与结论

实施步骤

1. embedding 预生成缓存 — backend/scripts/build_embedding_cache.py

2. 核心新模块 — backend/app/graph/embedded.py（~650 行，工作量主体）

3. 动态状态持久化 — SQLite（KMATCH_STATE_DIR/state.db）

4. 工厂 + 启动接线

5. Electron 注入 — electron/main/backend-sidecar.js

6. 依赖与打包

5. 最小应用程序：从 `_start` 到 `exit`

5.1 `_start` 与 `main`

8.1 `strace`

1.1 `_generate_one` 支持修正 hint（`content_generator.py`）

1.2 新文件 `backend/app/agents/quality_regen.py`

1.3 工作流盲重试 → 定向重试（`content_generator.py`）

1.4 离线脚本闭环（`scripts/run_quality_test.py`）

1.2 `ProjectGraphView.vue` 实体详情面板丰富化

2.1 新建 `frontend/src/utils/techStack.js`

2.2 `ProjectGraphView.vue` 头部展示技术栈 badges

3.1 后端新建 `POST /api/project/analyze`

3.2 `api/project.js` 加 `analyzeProject(projectId, tavilyKey)`

3.3 `projectGraph store` 加 `analyze()` action

3.4 `ProjectGraphView.vue` 加”深度分析”按钮 + 结果面板

1. embedding 预生成缓存 — `backend/scripts/build_embedding_cache.py`

2. 核心新模块 — `backend/app/graph/embedded.py`（~650 行，工作量主体）

3. 动态状态持久化 — SQLite（`KMATCH_STATE_DIR/state.db`）

5. Electron 注入 — `electron/main/backend-sidecar.js`

`_build_tool_description()` 做了什么