前文提到，我对 Qwen3.8-27B-TURBO-Fable-Cold-Fusion-735-882-Heretic-Uncensored-NEO-CODER-MAX-MTP-GGUF 的表现并不算满意，但我还是很馋它的生成速度，于是再次尝试使用详细提示词以及它的MTP版本进行测试。
运行命令
docker run --gpus all -v ./:/models -p 8000:8080 ghcr.io/ggml-org/llama.cpp:server-cuda -m /models/Qwen3.8-27B-TurboFCFusion-735-882-Here-Uncen-NEO-CODER-MAX-MTP-Q4_K_M.gguf --mmproj /models/mmproj-F32.gguf --port 8080 --host 0.0.0.0 -c 200000 -fa on --spec-type draft-mtp,ngram-mod,ngram-map-k4v --spec-draft-n-max 3 --cache-type-k q8_0 --cache-type-v q8_0 --fit off -ctkd q8_0 -ctvd q8_0 --ctx-checkpoints 32 --checkpoint-min-step 8192 --cache-reuse 256 --cache-idle-slots --no-kv-unified --no-context-shift -cram 20000由于MTP的加成，目前token生成速度提升到了60+tokens/s，随着上下文的增加，会降低到40+tokens/s。
测试项目：轻量级本地网盘系统
测试环境：opencode+superpowers
请严格遵循superpowers开发流程进行开发，所有文档除了代码外尽可能使用中文# 本地网盘系统 (Rust-MVP) 软件需求规格与系统架构说明书
本文档为基于 Rust 实现的高性能、轻量级本地网盘系统 MVP 阶段的正式软件需求规格说明书（SRS）与系统架构设计文档。
---
## 1. 需求规格清单
### 1.1 功能性需求 (Functional Requirements)
* **FR-01：双协议访问层（Web API & WebDAV）**
* **FR-01.1**：提供符合 RESTful 规范的 HTTP API，涵盖基础文件操作（浏览、上传、下载、删除、新建目录、重命名）。
* **FR-01.2**：原生集成 WebDAV 协议服务（监听 `/dav` 路径），支持标准 RFC 4918 动词（`PROPFIND`, `MKCOL`, `MOVE`, `COPY`, `DELETE`, `PUT`, `GET`），保证 Windows 资源管理器、macOS Finder 及主流播放器（Infuse、PotPlayer）能免客户端直接挂载。
* **FR-01.3**：提供开箱即用的轻量级单页面 Web 管理后台（Web UI），支持文件列表直观浏览与操作。
* **FR-02：直通存储与流式传输（Streaming I/O & Range）**
* **FR-02.1**：采用直通存储（Passthrough）机制，逻辑文件树与底层物理磁盘目录结构严格 1:1 映射，脱离服务后物理文件依旧完全可读。
* **FR-02.2**：全链路采用分块流式读写（Chunking Stream，默认块大小 64KB），严禁将大文件一次性加载至内存。
* **FR-02.3**：下载链路完整支持 `HTTP 206 Partial Content` 与 `Range` 请求头解析，满足视频在线播放的拖拽快进与断点续传需求。
* **FR-02.4**：预留在线预览路由扩展插槽（`/api/v1/files/:id/preview`），MVP 阶段默认返回原文件或重定向。
* **FR-03：嵌入式元数据管理与单写 Actor**
* **FR-03.1**：使用纯 Rust 嵌入式 KV 引擎 `redb` 构建元数据索引，隔离操作系统直接 `stat` 扫描的性能瓶颈。
* **FR-03.2**：实现专职单写者模型（Metadata Actor），独占 `redb` 写事务，外部请求通过异步通道（`mpsc`）排队提交，彻底避免多线程争抢写锁与 Tokio 阻塞。
* **FR-03.3**：提供前缀扫描支持，通过多表联合索引支持单目录下百万文件的毫秒级子项列举（$O(K)$ 复杂度）。
* **FR-04：物理文件监听与防抖入库（Notify & Anti-Echo）**
* **FR-04.1**：集成系统级文件变更监听，被动捕获外部第三方程序（如终端 `cp`/`mv`）向物理目录写入的文件。
* **FR-04.2**：提供 In-Flight 内存防回环注册表，网盘自身 API 发起的写入操作在落盘前后自动登记短效白名单，丢弃自身产生的 watcher 变更事件。
* **FR-04.3**：忽略监听到的 0 字节文件创建事件，规避客户端“先占坑、后写入”引发的状态抖动。
* **FR-04.4**：支持 1.5 秒防抖窗口及非阻塞读写锁探测（Probe Lock），确认大文件外部写入句柄完全关闭后再触发元数据入库。
* **FR-05：无阻塞软删除与后台异步 GC**
* **FR-05.1**：用户发起大目录删除时，元数据层即时标记 `is_deleted = true`（Tombstone），API 在毫秒级内返回成功，避免级联删除引发写锁长时间阻塞。
* **FR-05.2**：由独立的低优先级后台 Worker 分批次（单批次限制数量）推进物理文件删除与 redb 脏数据清理。
* **FR-06：冷启动全量静默对账（Reconciliation）**
* **FR-06.1**：系统冷启动时先以数据库现有快照秒级开放 Web/WebDAV 端口，不阻塞主服务监听。
* **FR-06.2**：后台异步启动全量对账引擎，遍历物理磁盘树与数据库 `PATH_INDEX_TABLE` 做双向 Diff，自动补齐离线期间产生的外部文件变更。
* **FR-07：单用户安全鉴权与系统过滤**
* **FR-07.1**：支持单用户认证模式，提供 HTTP Basic Auth 及静态 Bearer Token 验证机制。
* **FR-07.2**：提供系统级噪音文件黑名单过滤器（自动剔除 `.DS_Store`, `desktop.ini`, `Thumbs.db`, `~$*` 等垃圾文件）。
* **FR-07.3**：全链路强制 Unicode NFC 规范化，消除 macOS (NFD) 与 Linux/Windows (NFC) 之间的编码错乱问题。
---
### 1.2 非功能性需求 (Non-Functional Requirements)
* **NFR-01：内存硬上限管控**：在 16GB 物理机环境下，单节点服务运行时常驻基线内存 $\le$ 80MB；在大文件多路并发读写场景下，动态传输内存开销严格压制在 500MB 以内。
* **NFR-02：磁盘 I/O 背压保护**：引入并发信号量（Semaphore），强制限制全系统最大物理文件并发读写句柄数为 32，防止底层 NVMe/HDD 寻道抖动及 Tokio blocking 线程池耗尽。
* **NFR-03：跨平台稳定性**：除底层文件系统通知适配平台内核（Linux inotify, Windows ReadDirectoryChangesW, macOS FSEvents）外，核心逻辑全部采用跨平台标准 Rust 实现，不引入平台专属硬编码。
---
## 2. 系统整体架构图
```
+-----------------------------------------------------------------------------------------+
| 外部客户端接入层 |
| [ Web 浏览器 UI ] [ macOS Finder ] [ Windows 资源管理器 ] [ 移动端/播放器 ] |
+------------+----------------------+-----------------------+----------------------+------+
| | | |
| (HTTP REST / JSON) | (WebDAV / HTTP 1.1) | (WebDAV / HTTP 1.1) | (Range 播放)
v v v v
+-----------------------------------------------------------------------------------------+
| 【Component 1: Network & Protocol Ingress】 网络与协议接入层 |
| |
| +-------------------------------------+ +------------------------------------------+ |
| | Axum REST Router (/api/v1/*) | | dav-server-rs Handler (/dav/*) | |
| +-------------------------------------+ +------------------------------------------+ |
| +-----------------------------------------------------------------------------------+ |
| | Tower Middleware Stack: | |
| | - Auth Layer (Basic / Bearer) - Unicode Normalizer (NFC 归一化) | |
| | - Noise Filter (过滤 OS 碎片) - Trace & Cors Layer | |
| +-----------------------------------------------------------------------------------+ |
+-------------------------------------------+---------------------------------------------+
|
v
+-----------------------------------------------------------------------------------------+
| 【Component 2: Traffic Controller & Concurrency Limiter】 流量控制与背压调度层 |
| |
| * I/O 资源信号量管控器 (tokio::sync::Semaphore, Permit = 32) |
| * 慢客户端防御与单连接读写缓冲区配额 (64KB Fixed Buffer) |
+---------------------+---------------------------------------------+---------------------+
| |
(获取 I/O Permit 成功) (派发元数据写/读请求)
v v
+-----------------------------------------+ +-------------------------------------------+
| 【Component 3: Streaming Storage Engine】| | 【Component 4: Metadata Actor System】 |
| 存储与流式传输引擎 | | 元数据管理系统 |
| | | |
| - ReaderStream 流式读取 (HTTP 206) | | - 独立 std::thread 驱动单写事务循环 |
| - Stream-to-File 零拷贝落盘写入 | | - tokio::sync::mpsc 命令队列接收端 |
| - 文件排他锁探测器 (Lock Probe) | | - 微批处理提交 (Micro-Batching Commit) |
| | | |
| | | +-------------------------------------+ |
| | | | 嵌入式 redb 数据库引擎 | |
| | | | - METADATA_TABLE (file_id -> Meta) | |
| | | | - CHILDREN_TABLE (parent_id -> id) | |
| | | | - PATH_INDEX_TABLE (path -> id) | |
| | | +-------------------------------------+ |
+--------------------+--------------------+ +---------------------+---------------------+
| ^
| (落盘写操作) | (元数据提交)
v |
+-------------------------------------------------------------------+---------------------+
| 【Component 5: Watcher & Synchronization System】 外部监听与同步子系统 |
| |
| +------------------------------------+ +------------------------------------------+ |
| | In-Flight 防回环注册表 | | Watcher Debounce 引擎 | |
| | (DashMap<PathBuf, Instant>, TTL=3s)| | (notify-debouncer-mini, 1.5s 聚合窗口) | |
| +------------------------------------+ +------------------------------------------+ |
| +-----------------------------------------------------------------------------------+ |
| | 过滤策略管道: | |
| | 1. In-Flight 匹配过滤 -> 2. 大小 == 0 丢弃 -> 3. Lock Probe -> 4. 提交给 Actor | |
| +-----------------------------------------------------------------------------------+ |
+--------------------+--------------------------------------------------------------------+
| ^
| (系统级事件捕捉) | (比对同步写入)
v |
+-------------------------------------------------------------------+---------------------+
| 【Component 6: Background Maintenance System】 后台维护与对账子系统 |
| |
| - Cold-Start Reconciler: 启动后后台深度遍历物理目录树，与 redb 做双向 Diff 修复断档 |
| - Async Tombstone GC: 低优先级循环扫描软删除标记，分批次清理物理数据与 redb 悬挂条目 |
+--------------------+--------------------------------------------------------------------+
|
v
+-----------------------------------------------------------------------------------------+
| 底层硬件存储介质 (物理磁盘) |
| /data/storage/ (物理文件夹 1:1 Passthrough 直通存储，文件结构、权限完全透明) |
+-----------------------------------------------------------------------------------------+
```
---
## 3. 组件详细设计与技术栈对照表
| 组件模块 | 对应实现的需求清单 | 选用技术栈 / Crates | 内部核心职责与实现机制 |
| --- | --- | --- | --- |
| **Component 1: Ingress Gateway (接入层)** | **FR-01.1**<br>
<br>**FR-01.2**<br>
<br>**FR-01.3**<br>
<br>**FR-07.1**<br>
<br>**FR-07.2**<br>
<br>**FR-07.3** | • `axum` (0.8)<br>
<br>• `dav-server` (0.7)<br>
<br>• `tower`, `tower-http`<br>
<br>• `unicode-normalization`<br>
<br>• `mime_guess` | • **路由分发**：`/api` 走 REST，`/dav` 挂载 `dav-server`<br>
<br>• **路径清洗**：中间件统一将请求 URI 转为 NFC 编码<br>
<br>• **黑名单阻断**：直接拦截 `.DS_Store`、`Thumbs.db`，返回 204 或忽略<br>
<br>• **认证拦截**：校验 HTTP Authorization 头 (Basic/Bearer) |
| **Component 2: Traffic Controller (限流器)** | **NFR-01**<br>
<br>**NFR-02** | • `tokio::sync::Semaphore`<br>
<br>• `tokio::sync::OwnedSemaphorePermit` | • **背压保护**：全局配置容量为 32 的信号量，所有进出物理磁盘的 I/O 必须显式持有 Permit，离开作用域自动释放<br>
<br>• **内存配额**：杜绝无界并发导致的 Buffer 线性爆炸 |
| **Component 3: Storage Engine (流式引擎)** | **FR-02.1**<br>
<br>**FR-02.2**<br>
<br>**FR-02.3**<br>
<br>**FR-02.4** | • `tokio::fs`<br>
<br>• `tokio-util::io::ReaderStream`<br>
<br>• `http-range-header`<br>
<br>• `bytes` | • **分片直出**：基于 `ReaderStream` 以 64KB 块流式向 Socket 输出数据<br>
<br>• **Range 解析**：按字节区间 Seek 并组装 `206 Partial Content`<br>
<br>• **直通落盘**：上传流以 Stream 形式直接写物理文件，不经临时中转池 |
| **Component 4: Metadata Actor (元数据引擎)** | **FR-03.1**<br>
<br>**FR-03.2**<br>
<br>**FR-03.3** | • `redb` (2.x)<br>
<br>• `std::thread`<br>
<br>• `tokio::sync::mpsc`<br>
<br>• `tokio::sync::oneshot`<br>
<br>• `bincode`, `serde` | • **单写线程**：专职系统线程处理写事务，消灭写锁竞争<br>
<br>• **微批提交**：利用 `try_recv` 将排队消息合并在单次事务中 Commit<br>
<br>• **三表拓扑**：维护元数据表、前缀子节点表与绝对路径索引表 |
| **Component 5: Watcher & Sync (物理同步)** | **FR-04.1**<br>
<br>**FR-04.2**<br>
<br>**FR-04.3**<br>
<br>**FR-04.4** | • `notify` (6.x)<br>
<br>• `notify-debouncer-mini`<br>
<br>• `dashmap`<br>
<br>• `fs2` (文件独占锁探测) | • **防回环**：使用 `DashMap` 记录系统自身写入的路径，设定 3s TTL<br>
<br>• **0 字节丢弃**：新创建且 Size 为 0 的文件直接忽略，等待 Modify 事件<br>
<br>• **写锁探测**：使用 `fs2::FileExt::try_lock_exclusive` 探测拷贝是否完成 |
| **Component 6: Background Worker (对账与GC)** | **FR-05.1**<br>
<br>**FR-05.2**<br>
<br>**FR-06.1**<br>
<br>**FR-06.2** | • `tokio::task`<br>
<br>• `walkdir`<br>
<br>• `tracing` | • **无感冷启动**：后台轻量扫描物理目录，与 `PATH_INDEX_TABLE` 做 Diff<br>
<br>• **Tombstone GC**：每隔一定周期扫描标记为软删除的节点，每次最多物理清除 500 个文件，降低 I/O 尖峰 |
| **Component 7: Web Frontend Shell (管理后台)** | **FR-01.3** | • Vue 3 (SFC 编译为单静态 HTML)<br>
<br>• Tailwind CSS | • **极简集成**：单 HTML 文件通过 `rust-embed` 或 `include_str!` 内嵌编译进 Rust 二进制包，实现真正的零依赖单文件分发运行 |
---
## 4. 关键数据结构与协议定义
### 4.1 redb 表结构规划
系统在 `redb` 内部分配三个命名表：
```rust
// 1. 文件完整元数据表: file_id -> FileRecord
const METADATA_TABLE: TableDefinition<u64, &[u8]> = TableDefinition::new("metadata_v1");
// 2. 目录树层级索引表: (parent_id, file_name) -> file_id
// 利用 redb 的前缀范围扫描 (range)，快速提取目录下的所有子项
const CHILDREN_TABLE: TableDefinition<(u64, &str), u64> = TableDefinition::new("children_v1");
// 3. 物理路径索引表: absolute_path -> file_id
// 供 notify 捕获物理事件时做 O(1) 反查
const PATH_INDEX_TABLE: TableDefinition<&str, u64> = TableDefinition::new("path_index_v1");
```
**元数据结构载荷 (FileRecord)**：
```rust
#[derive(Serialize, Deserialize, Debug, Clone)]
pub struct FileRecord {
pub id: u64,
pub parent_id: u64,
pub name: String,
pub size: u64,
pub is_dir: bool,
pub mtime_ms: i64,
pub mime_type: String,
pub is_tombstone: bool, // 软删除标记
pub sha256: Option<[u8; 32]>, // 扩展字段：哈希校验预留
pub extra_metadata: Option<Vec<u8>>, // 扩展字段：预览图/视频时长等 JSON 扩展
}
```
### 4.2 Metadata Actor 交互协议定义
```rust
pub enum MetaCommand {
/// 插入或更新文件元数据
Upsert {
record: FileRecord,
abs_path: String,
responder: oneshot::Sender<Result<u64, StorageError>>,
},
/// 标记软删除
MarkTombstone {
file_id: u64,
responder: oneshot::Sender<Result<(), StorageError>>,
},
/// 批量同步对账事务
BatchReconcile {
inserts: Vec<(FileRecord, String)>,
deletes: Vec<u64>,
responder: oneshot::Sender<Result<(), StorageError>>,
},
/// 彻底物理清除 (由 GC 触发)
PhysicalPurge {
file_id: u64,
responder: oneshot::Sender<Result<(), StorageError>>,
},
}
```
---观察到的现象
本任务共计耗时2.5小时，其中，前面1.5个小时是使用TDD的开发时间，后面1小时是循环优化的时间，效果如下：
这次让我惊喜的是，在强调了要严格遵循TDD的开发流程后，模型的指令遵循能力大大提高，比起之前擅自跳过一些TDD流程，这次可以说是在大幅降低了思考时间的同时，依旧保持了良好的计划性。
不过，也许是由于思考时间的减少，superpowers中的review流程往往不到2分钟就会结束，基本上全是Pass，但很明显，很多代码质量问题并没有暴露出来，在完成初次MVP开发后，后续的循环检测又陆续出现了10多个优化点。
最后总体的交付质量基本达到了MVP要求，不过web端出现的CORS问题是在人工介入后才得到解决。
从结果上来看，该模型还是可以作为小规模的代码开发模型，尤其是不涉及到可视化的开发，像是命令行工具，后端接口等，皆有不俗的表现，期待D佬后面的新的模型。
Qwen3.8-27B测试（4）
https://556799.xyz/archives/qwen3.8-27bce-shi-4
Comments