为什么需要了解这四个阶段？ AI 工程领域的发展速度令人瞠目结舌。如果你只掌握了提示工程（Prompt Engineering），那么你已经落后了整整一个时代。从 2022 年到现在，短短四年时间里，AI 工程经历了四次深刻的范式跃迁，每一次都是对前一次的超越和包容。

写在前面：为什么要懂这四个阶段？ 很多人仍然认为"写好提示词就够了"——这已经过时了。这四个阶段不是孤立的知识点，而是一个完整的能力升级路径。 认知误区： 阶段一：提示工程 = AI 对话的精髓 阶段二：上下文工程 = 拉长对话 阶段三：驾驭工程 = 让 AI 更聪明 阶段四：循环工程 = 自动化提示 真相：

v0.6.0 把延时摄影管道搭起来之后，社区反馈很快就指出了几个硬伤：JPEG 序列要吃掉太多存储、H.265 摄像头生成的延时片段播放不了、双摄小米设备只能抓到主镜头、偶尔还会出现 H.265 HLS 直接 panic 的崩溃。这些都不是边缘场景——双摄 CW500 和室外摄像头 4 在国内出货量很大，H.265 已经是中高端摄像头的事实标准。v0.7.0 的主线就是围绕这些反馈展开的。

Zhi 主题 发布了 v0.2.0——这是从 4 月份 初次发布 后最重要的功能更新。这次发布的三个重头功能——多语言切换、文章系列（Series）分类法、Mermaid v11+ 升级——都是在自己使用过程中逐步积累的需求。

前几篇文章展示了如何使用 eBPF 追踪 OOM 事件。但这还不够——我们只是在"看"，不能"管"。内核的 OOM Killer 选谁杀谁，由 oom_badness() 算法决定，用户无法干预。

前两篇文章覆盖了 eBPF 基础概念和 OOM Killer 事件追踪。这篇文章进入更深的层次：容器级别的 OOM 定位、内存分配速率的实时追踪，以及用 Rust Aya 框架来实现同样的功能。 容器级 OOM 定位 在 Kubernetes 环境中，“某个 Pod OOM 了"实际上是一个模糊的描述。Pod 由多个容器组成，容器可能属于不同的 cgroup。eBPF 可以穿透这一层，精确地定位到"是哪个容器里的哪个进程"导致了 OOM。

bpftrace 适合快速探查和临时调试，但如果要构建持续运行的生产级监控工具，就需要完整的 eBPF 程序了。典型的架构分两层： 内核态：用 C 编写 eBPF 程序，挂载到 hook 点，采集事件数据 用户态：用 Go（或 Rust / libbpf C）编写 loader，加载 eBPF 程序并读取事件 这个模式在行业里已经非常成熟——Pixie、Parca、Cilium 等开源项目都遵循这个架构。

eBPF（Extended Berkeley Packet Filter）最初是网络包过滤工具，经过近十年发展，已经成为 Linux 内核最强大的可观测性框架。它允许你在不修改内核源码、不加载内核模块的前提下，安全地注入并执行自定义程序。

什么是循环工程？ 定义（Addy Osmani, 2026年6月）：循环工程就是取代你自己作为提示智能体的人。你设计系统来做这件事。循环是一个递归目标，你定义一个目的，AI 不断迭代直到完成。

MiBeeNvr 连续跑了几周录像后，存储最先告急。单路 1080p 摄像头每天要写几十 GB，30 天留存一件 1TB 硬盘就没了大半。社区里不少朋友反馈了同样的问题，讨论中延时摄影和转码保存的方案呼声最高——画面大部分时间静止，用 timelapse 压缩后同样时长只需要 5% 的空间。