• DSpark 论文

北京大学　DeepSeek-AI

摘要

推测解码（Speculative Decoding）通过将草稿生成与目标验证解耦来加速大语言模型（LLM）推理。尽管最近的并行 drafter 能够在单次前向传播中高效 Proposed 长令牌序列，但由于缺乏令牌间依赖关系，它们面临着接受率快速衰减的问题。此外，不加区分地验证这些扩展块会浪费关键的批次容量在具有高拒绝风险的令牌上，严重降低了高并发服务系统中的吞吐量。

我们提出了 DSpark，这是一个推测解码框架，统一了高吞吐量的并行生成与自适应的、负载感知的验证。为了保持草稿质量，DSpark 利用半自回归架构——将并行主干与轻量级顺序模块耦合——引入块内依赖建模并缓解后缀衰减。为了优化系统效率，DSpark 采用置信度调度验证，根据估计的前缀存活概率和引擎特定的吞吐量配置文件，动态地为每个请求定制验证长度。

在跨多个领域的离线基准测试中，DSpark 在已接受长度方面显著优于最先进的自回归和并行 drafter。当部署在 DeepSeek-V4 服务系统中并处理实时用户流量时，DSpark 成功缓解了验证浪费。与已确立的生产基线（MTP-1）相比，DSpark 在匹配的吞吐量水平上加速了每用户生成速度 60%–85%。

官网定位一句话：将文字、草图、截图、语音指令，一键生成 Web / 移动端高保真界面、可交互原型与可直接投入开发的前端代码，打通「灵感→设计→开发」完整工作流。 访问入口：stitch.withgoogle.com

🚀 Stitch：从想法到落地

Stitch 提倡“设计先行，边做边改”。告别面对空白页的焦虑，无需追求一步到位，通过不断迭代轻松产出优秀设计。

1. 极简起步：三步提示词公式

写下你的初始想法，无需死磕细节，给一个大概的“配方”即可生成：

• [想法] 是什么 + [主题] 风格氛围 + [内容] 核心板块。

2. 精准迭代：每次只改动一点

生成初稿后，构思才真正开始。

• 小步快跑： 每次锁定一个问题，用具体指令（配合 UI/UX 词汇）让 AI 修改。
• 全局调整： 善用“编辑主题”一键更换深浅模式、颜色和字体。

3. 验证与交付：从静态到上线

• 动效测试： 一键生成交互式“原型”，测试按钮悬停、文本输入等真实体验。
• 多端导出： 导出 HTML 和图片包。HTML 是万能资产，可借助大模型轻松转换为 React、Vue 或手机原生代码（Flutter/SwiftUI 等）。

💡 核心寄语： 别想太多，先生成，再优化。持续构思，直到满意！

• Everything you need to know

欢迎来到 Stitch。今天您将学习如何从设计切入并专注于概念构思。关键在于不要过度思考。

DESIGN.md是什么？

每个项目都有自己的视觉标识：颜色、字体、间距、组件样式。传统上，这些内容存储在 Figma 文件、品牌 PDF 或设计师的脑海中。AI 智能体无法读取这些格式。

DESIGN.md 改变了这一点。 它是一个纯文本设计系统文档，人类和智能体都可以阅读、编辑和执行。可以将其视为 AGENTS.md 的设计对应物：

文件	阅读者	定义内容
README.md	人类	项目是什么
AGENTS.md	编码智能体	如何构建项目
DESIGN.md	设计智能体	项目应该长什么样、什么感觉

它能给你带来什么

当像 Stitch 这样的设计智能体读取你的 DESIGN.md 时，它生成的每个屏幕都遵循相同的视觉规则：你的调色板、你的排版、你的组件模式。没有它，每个屏幕都是孤立的；有了它，它们看起来属于同一个产品。

DESIGN.md 是一个活的产物，而不是静态配置文件。它随着你的设计演变而演变。智能体生成它，你完善它，并在迭代过程中重新应用到屏幕上。

在底层，每个 DESIGN.md 都有两层：YAML 前置元数据包含机器可读的设计令牌（精确的十六进制值、字体属性、间距尺度）和Markdown 正文提供人类可读的设计原理说明。令牌为智能体提供精确值。散文告诉它们为什么这些值存在。完整的格式请参阅规范。

设计理念

DESIGN.md 规范是一个基础，而非规定。

• DESIGN.md

一种用于向编码智能体描述视觉识别系统的格式规范。DESIGN.md 让智能体对设计系统拥有持久、结构化的理解。

格式

DESIGN.md 文件将机器可读的设计令牌（YAML 前置元数据）与人类可读的设计原理（Markdown 正文）相结合。令牌为智能体提供精确值，正文则解释这些值为何存在以及如何使用。

---
name: Heritage
colors:
  primary: "#1A1C1E"
  secondary: "#6C7278"
  tertiary: "#B8422E"
  neutral: "#F7F5F2"
typography:
  h1:
    fontFamily: Public Sans
    fontSize: 3rem
  body-md:
    fontFamily: Public Sans
    fontSize: 1rem
  label-caps:
// ...

读取此文件的智能体将生成一个 UI：Public Sans 字体的深墨标题、温暖石灰石背景，以及波士顿陶土色的行动号召按钮。

快速开始

对照规范验证 DESIGN.md，捕获损坏的令牌引用、检查 WCAG 对比度比率，并输出结构化发现——所有结果均以智能体可处理的 JSON 格式呈现。

结合 DSpark 论文与代码实现，全面剖析 DeepSpec 的工作原理与核心组件。

项目地址：https://github.com/deepseek-ai/DeepSpec DSpark 论文：https://github.com/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf

DSpark 是 DeepSeek 提出的一套无损加速大模型推理的“看人下菜碟”机制。 传统加速手段（推测解码）通常是让小模型一次性盲目盲猜一大串后续 Token，再让大模型统一验证。但这存在两个痛点：小模型猜得越往后越不准（多模态冲突导致“后缀衰减”）；高并发时，大模型花大力气去验证那些猜得不准的 Token，会严重压垮系统吞吐。

DSpark 的核心突破就在于两点：

1. 猜得更准（半自回归）： 它在原有的单次并行生成网络后，拼了一个极轻量的小尾巴（顺序头），在几乎不增加延迟的情况下，让后面的 Token 能根据前面猜出的 Token 进行自适应修正，大幅提升长序列的猜测准确度。
2. 动态裁剪（置信度调度）： 它能实时感知系统的硬件负载与并发压力。如果并发高、大模型很忙，或者发现后面小模型猜的置信度太低，它就会果断把不靠谱的后缀砍掉，只送靠谱的前缀给大模型验证。

通过这种“高质量猜测”与“负载感知动态裁剪”的结合，DSpark 在保障大模型输出质量完全无损的前提下，成功

本周主线：Google 一周内失去四位顶尖 AI 科学家，OpenAI 以 GPT-5.5-Cyber 正面回应 Anthropic 的网络安全布局，SpaceX 凭 63 亿美元算力协议巩固全球最大商业 AI 基础设施商地位，中美 AI 出口管制进入双向对抗阶段。

本周看点

1. Google 遭遇史上最严重 AI 人才流失潮：诺贝尔化学奖得主 John Jumper 与 Gemini 核心人物 Noam Shazeer 等四位科学家在一周内相继离开，分别加入 Anthropic 与 OpenAI，Alphabet 市值蒸发超 2700 亿美元，Gemini 3.5 Pro 发布计划受挫。
2. OpenAI 发布 GPT-5.5-Cyber 与 Patch the Planet：直接回应 Anthropic 的 Project Glasswing，将 AI 漏洞扫描嵌入 Codex，并承诺在 30 天内修复 cURL、Python、Linux 内核等 30 多个开源项目的安全漏洞。
3. SpaceX 与 Reflection AI 签下 63 亿美元算力大单：每月 1.5 亿美元、为期三年的 GB300 算力租赁协议，使 SpaceX 的 AI 算力合同承诺收入超过 800 亿美元，成为全球最大商业 AI 基础设施提供商。
4. Anthropic 把 Claude 智能体嵌入 Slack：Claude Tag 正式上线，企业用户可在任意频道 @Claude 调用智能体，Anthropic 内部称其已贡献产品团队 65% 的代码产出。
5. 中国反制美国 AI 出口管制：6 月 24 日，中国将 56 家美国企业列入制裁清单，禁止部分企业参与政府采购并实施出口管制，标志 AI 技术出口战从单向限制转向双向对抗。

最近先后在站点上线了两个纯前端的朗读工具：Read Aloud 和 智能朗读阅读器。两者都基于浏览器的 Web Speech API 实现，没有后端、没有上传、没有第三方语音服务。开发过程中踩了一些坑，也积累了一些可复用的经验，记录如下。

一、Web Speech API 基础

浏览器 TTS 的入口非常简洁：

const synth = window.speechSynthesis;
const utterance = new SpeechSynthesisUtterance(text);
synth.speak(utterance);

window.speechSynthesis 负责全局的语音队列，SpeechSynthesisUtterance 则是每一次发音的单元。在真正可用之前，建议先做兼容性判断：

if (!window.speechSynthesis) {
  alert('当前浏览器不支持 Web Speech API，无法使用朗读功能。');
  return;
}

目前 Safari、Chrome、Edge 等现代浏览器都支持该 API，但不同浏览器在语音质量、语音名、事件触发等方面差异明显，后面会详细说。

二、语音列表是异步加载的

第一次调用 speechSynthesis.getVoices() 时，返回的数组经常为空。这是因为浏览器需要异步加载系统语音包。

JiuwenSwarm 是什么？

JiuwenSwarm 是一个华为云开源的分布式 AI 多智能体协同与能力自进化系统。简单说，它是一个让 AI 智能体像团队一样协作、并且越用越聪明的系统。

核心特色

1. 三种执行模式，适配不同场景

模式	怎么工作	适合
Plan 模式	单 Agent 深度推理，自带任务规划 Rail，边思考边执行	复杂任务、多步骤分析
Performance 模式	卸掉规划护栏，直问直答，延迟最低	快速问答、简单查询
Swarm 模式	Leader 拆解任务，组建多 Agent 团队并行协作，可跨机器	大型复杂工作、多角色分工

flowchart LR
    M["用户输入"] --> P{模式选择}
    P -->|agent.plan| A1["单 agent 深度规划<br/>+ task planning rail"]
    P -->|agent.fast| A2["单 agent 快速响应<br/>- heavy rail"]
    P -->|team| A3["leader 拆解任务<br/>+ teammate 分布式执行"]
    A1 --> R["输出结果"]
    A2 --> R
    A3 --> R

本周主线：开源模型密集发布、SpaceX 600 亿美元吞下 Cursor、Anthropic Fable 5 遭美国商务部强制下线，智能体安全与监管同时升温。

本周看点

1. SpaceX 全股票收购 Cursor：这笔 600 亿美元的交易将 AI 编程工具市场进一步纳入马斯克生态，也标志着开发者工具成为巨头 AI 军备竞赛的制高点。
2. Anthropic Fable 5 / Mythos 5 遭美商务部下线：因一句 "Fix this code" 触发出口管制，Dario Amodei 本周赴华盛顿谈判，事件持续发酵。
3. 智谱 GLM-5.2 与月之暗面 Kimi K2.7-Code 相继开源：中国开源模型在 1M 上下文与编程专用模型上继续施压闭源 frontier。
4. DeepSeek 完成首轮融资：超过 500 亿元人民币（约 74 亿美元）、估值突破 500 亿美元，继续刷新中国大模型公司的融资纪录。
5. Agentjacking 攻击曝光：针对 Claude Code、Cursor、Codex 的假 Sentry 错误注入，85% 成功率，再次敲响智能体安全警钟。

一句话串起本周主线：模型开源、资本整合、监管收紧、安全反噬四条线同时加速，AI 行业正从能力竞赛进入治理与商业化并行的深水区。

一、大模型前沿动态

1. 智谱 GLM-5.2 以 MIT 许可证开源权重

版本 0.1 — 草案

OKF 是一种开放、对人类和智能体友好的格式，用于表示知识——即围绕数据和系统的元数据、上下文和精心整理的洞察。它旨在由人类编写、由智能体生成、跨组织交换，并由两者共同消费。

该格式有意保持极简：一个由 Markdown 文件和 YAML 前置元数据组成的目录。没有 Schema 注册中心，没有中央权威机构，也不需要任何特定工具。如果你能 cat 一个文件，你就能读取 OKF；如果你能 git clone 一个仓库，你就能分发它。

1. 动机

面向 AI 智能体的知识表示领域正在快速演进，许多互不兼容的约定正在涌现。OKF 的立场是，知识最好用常见、已建立的格式来表示，这些格式应具备以下特性：

• 无需工具即可被人类阅读。
• 无需定制 SDK 即可被智能体解析。
• 可在版本控制中进行差异比较。
• 可跨工具、组织和时间迁移。

该格式保持最低限度的主观性。它仅标准化一小套结构约定，使知识语料库能够自我描述——除此之外的一切留给生产者自行决定。

目标

1. 定义一种通用格式，增强型智能体可以写入其中。
2. 告知消费型智能体应如何读取和遍历它。
3. 促进知识跨系统和组织的交换。
4. 标准化少量必需字段，使内容能够被有意义地消费。

非目标

• 定义固定的概念类型分类体系。
• 规定存储、服务或查询基础设施。
• 取代领域特定 Schema（Avro、Protobuf、OpenAPI 等）——OKF 引用它们，而非包含它们。

范围：Kilo CLI (packages/opencode/) / VS Code Extension (packages/kilo-vscode/) / Kilo Cloud (后端归因引擎)

执行摘要

本方案解决的核心问题是：精确量化 AI 在最终代码库中的实际贡献比例。现有方案（包括行业通用的"行数计数法"）只能回答"AI 被接受了多少行"，但无法回答"这些被接受的代码有多少存活到了最终提交，以及被人类修改了多少"。

本方案在 Kilo Code 现有架构上，引入 AST-aware MinHash 指纹归因引擎（基于 k-Shingle + LSH），构建一条从 AI 代码生成瞬间到 Git 最终提交的全链路追踪能力。三套代码生成路径（Tab 补全、Chat 对话、Agent 子任务）统一采集代码指纹，服务端在 Git 提交阶段进行归因匹配，最终产出精确到行级的 AI 贡献占比。

基于 OpenAI Whisper 的命令行工具，将音频文件批量转写为 VTT / SRT 格式字幕。

环境要求

依赖	说明
Python	≥ 3.8
PyTorch	Whisper 的运行时依赖，自动安装
openai-whisper	语音识别引擎
ffmpeg	音频解码，系统级安装

安装步骤

1. 安装 ffmpeg

• macOS：

brew install ffmpeg

• Ubuntu / Debian：

sudo apt update && sudo apt install ffmpeg

2. 安装 openai-whisper

pip install openai-whisper

该命令会自动拉取 torch 等依赖。首次运行时 Whisper 模型文件会下载到 ~/.cache/whisper/。

⚠️ macOS 环境注意事项

使用系统 Python 或 miniconda 安装 whisper：

# miniconda（推荐，已预装 torch）
/opt/miniconda/bin/pip install openai-whisper

# 或系统 Python
/usr/bin/python3 -m pip install openai-whisper

脚本文件

编写文件：audio2sub.py

以下是完整的词汇表（共3100个单词，按字母顺序排列）：

这是一个非常实际的工业需求。MinHash 在这个场景中不是直接检测"是否 AI 生成"，而是作为代码指纹匹配引擎，追踪"AI 原始输出 → 人修改后最终代码"的相似度与存活比例。

下面给出完整的AI 生成代码占比统计系统设计方案。

一、问题定义：什么是"AI 生成代码占比"

在智能体编码助手（GitHub Copilot、Kilo Code、Cursor 等）的工作流中，代码的生命周期通常是：

AI 生成建议 → 人接受/修改 → 进入代码库 → 后续迭代中被修改

我们需要统计的是最终代码库中，可追溯至 AI 原始生成的代码比例。这不是简单的"谁按了 Tab 键"，而是：

统计维度	含义	计算方式
AI 原始贡献率	AI 生成的代码在最终代码中的存活比例	匹配上的代码行 / 总行数
人修改深度	人在 AI 代码基础上做了多大改动	1 - (AI 原始代码保留率)
人效提升系数	有 AI 辅助时人均产出 vs 无 AI 辅助	对比实验或历史基线

二、为什么 MinHash 适合这个场景

核心挑战

1. 人会修改：AI 生成的代码被人接受后，通常会修改变量名、加注释、调逻辑，文本相似度会下降
2. 代码重构：函数拆分、类提取等操作会让纯文本匹配失效
3. 规模问题：一个团队每天可能产生数千次 AI 交互，需要快速匹配

MinHash 的优势

在文本挖掘和信息检索领域，$k$-Shingle（通常也被称为 $k$-gram）是一种将连续的文本切分成固定长度碎片的技术。它是海量文本去重（如 MinHash + LSH 架构）中极其关键的数据预处理阶段。

简单来说，它的核心任务是：把一篇文章（一维的字符串）转化成一个集合（Set），并且在这个集合中锁死文本的局部语序。

一、 核心概念：滑动窗口（Sliding Window）

$k$-Shingle 的工作原理就像一把长度为 $k$ 的滑动尺子。尺子从文本的开头开始，每次框住 $k$ 个单位的内容作为一个 Shingle，然后向右平移一个单位，重复这个过程，直到文本结束。

根据具体需求，这里的“单位”可以是字符（Character），也可以是单词（Word）：

• 基于字符的 $k$-Shingle：通常用于拼写检查、DNA 序列分析或中文字符处理。
• 基于单词的 $k$-Shingle：通常用于英文等有天然空格分隔的文本去重与防抄袭。

直观案例演练

我们以短语 abcde 为例，来看看在不同的 $k$ 值下，基于字符切分出来的 $k$-Shingle 集合是什么样的：

• 当 $k = 1$ 时（尺子长度为 1）：每次只框一个字母。
• 集合结果：{ "a", "b", "c", "d", "e" }

问题背景：为什么百亿级去重不可能暴力求解？

在互联网大数据场景中，如何从海量数据（如百亿网页、千万级商品描述、巨大的开源代码仓库）中快速找出重复或高度相似的内容？这是一个极其经典的工业界痛点。

最朴素的想法是：对文章进行分词，转成集合后两两比对。若有 $N$ 篇文档，需要比较 $\frac{N(N-1)}{2}$ 次。当 $N = 10^7$（一千万）时，比较次数约为 50 万亿次。即便单次比较仅需 1 微秒，也需要 1.6 年 才能跑完。这种 $O(N^2)$ 复杂度的算法会导致服务器直接卡死崩溃。

本文将结合数学原理、算法推导与工程实战，深入拆解 Jaccard 相似度 的直觉陷阱，以及 MinHash（最小哈希） 算法如何对高维稀疏数据完成降维打击，最终给出可直接落地的工业级实现方案。

一、Jaccard 相似度：精准度量及其直觉陷阱

Jaccard 相似度（Jaccard Similarity） 是衡量两个集合重合度的标准数学方法。其核心思想非常直观：看两个集合的交集（共同拥有的元素）占它们并集（总共拥有的元素）的比例。

数学公式定义为：

$$J(A, B) = \frac{|A \cap B|}{|A \cup B|}$$

1. 经典直觉陷阱：为什么你常常会算错？

Gemma 4 12B

• Introducing Gemma 4 12B: a unified, encoder-free multimodal model
• Gemma 4 12B: The Developer Guide
• Accelerating Gemma 4: faster inference with multi-token prediction drafters
• A Visual Guide to Gemma 4 12B
• Gemma 4: Byte for byte, the most capable open models
• Ollama Gemma 4

Gemma 4 12B 是谷歌最新推出的一款原生、无编码器（Encoder-free）的统一多模态大模型。它的核心定位是将高水平的“智能体（Agentic）”和多模态能力直接带到用户的笔记本电脑等日常消费级硬件上。

以下是对 Gemma 4 12B 大模型的详细介绍：

1. 创新的统一架构：无编码器设计（Encoder-free）

与传统的多模态模型（通常需要使用独立的、冻结的视觉或音频编码器将数据转化为文本格式）不同，Gemma 4 12B 采用了统一的、仅解码器（Decoder-only）的 Transformer 架构。

• 视觉嵌入器（Vision Embedder）：仅有 35M 参数，取代了传统复杂的视觉 Transformer 层。它将 48x48 像素的原始图像块（Patches）通过单次矩阵乘法直接投影到大语言模型（LLM）的隐藏维度中，并利用 X 和 Y 矩阵的坐标查找技术，直接将空间位置信息附带在输入中。
• 音频波形投影（Audio Wave Projection）：完全取消了独立的音频编码器。它直接将 16 kHz 的原始音频信号切片为 40ms 的帧（每帧包含 640 个浮点数），并通过线性投影无缝输入到 LLM 的空间中。

罗福莉 2026年4月6日

两天前，Anthropic 切断了第三方客户端（Harnesses）使用 Claude 订阅的通道——这并不令人意外。三天前，MiMo 推出了其 Token 计划（Token Plan）——这是一个我投入了大量精力去设计的方案，也是我认为在实现合理的算力分配和智能体客户端开发方面一次严肃的尝试。将这两件事结合起来，我有以下几点思考：

1. Claude Code 的订阅制是一个专为平衡算力分配而设计的精美系统。 我的猜测是——它并不赚钱，甚至可能在亏本，除非他们的 API 利润率高达 10-20 倍，但我对此深表怀疑。虽然我无法严密地计算出第三方客户端接入所带来的损失，但我近距离观察过 OpenClaw 的上下文管理——它真的很糟糕。在单个用户查询中，它会把一轮轮低价值的工具调用作为独立的 API 请求发送出去，每个请求都携带长达 100K 以上 Token 的长上下文窗口——即便有缓存命中，这也是极大的浪费，在极端情况下还会推高其他查询的缓存未命中率。其单次查询的实际请求次数最终比 Claude Code 自身框架高出数倍。折算成 API 定价的话，真实成本恐怕是订阅价格的几十倍。这不仅是一个差距，而是一个巨大的黑洞。
2. 像 OpenClaw/OpenCode 这样的第三方客户端依然可以通过 API 调用 Claude——它们只是不能再薅订阅制的羊毛了。 短期内，这些智能体用户会感到阵痛，成本极有可能飙升几十倍。但这种压力恰恰会倒逼这些客户端去优化上下文管理、最大化提升提示词缓存（Prompt Cache）的命中率以复用已处理的上下文，并减少无谓的 Token 消耗。痛苦最终会转化为工程上的严谨与克制。
3. 我强烈呼吁大模型公司不要在搞清楚如何为编程套餐定价且不亏本之前，就盲目地进行价格战、卷到行业底层。 廉价销售 Token 却对第三方客户端敞开大门，看似对用户友好，实则是一个陷阱——正是 Anthropic 刚刚踩进去又退出来的那个陷阱。更深层次的问题在于：如果用户把精力浪费在低质的智能体客户端、极度不稳定且缓慢的推理服务，以及为了削减成本而降级的大模型上，结果却发现依然什么事也做不成——这对于用户体验或留存率来说，绝不是一个健康的循环。
4. 关于 MiMo Token 计划——它支持第三方客户端，按 Token 配额计费，这与 Claude 最新推出的额外用量包逻辑一致。 因为我们追求的是长期、稳定地交付高质量的模型与服务——而不是吸引你冲动消费后便任由你弃船而去。

AGPL v3.0 许可证的开源豁免仅限于公司内部直签员工自用。由于公司混编了第三方外包人员，在法律主体上已被视作向外部第三方提供服务；一旦我们修改了该项目的核心代码，将直接触发强制开源机制，导致公司相关的商业源代码面临被迫向全社会彻底公开的重大合规风险。

AGPL-3.0

GNU AFFERO通用公共许可证 第三版，2007年11月19日

版权所有 (C) 2007 Free Software Foundation, Inc. https://fsf.org/ 允许每个人复制和分发本许可证文档的完整副本，但不得修改它。

序言

GNU Affero通用公共许可证是一份自由的、著佐权性质的许可证，适用于软件及其他类型的作品，它专门设计用于确保在网络服务器软件的情况下与社区合作。

大多数软件的许可证旨在剥夺您分享和修改软件的自由。相反，我们的通用公共许可证旨在保证您分享和修改程序所有版本的自由——确保它对所有用户来说都是自由软件。

当我们谈论自由软件时，我们指的是自由，而非价格。我们的通用公共许可证旨在确保您拥有分发自由软件副本的自由（如果您愿意，也可以对此服务收费），确保您能够收到源代码或在需要时获取它，确保您可以更改软件或在新的自由程序中使用其部分内容，并且确保您知道您可以做这些事情。

使用我们的通用公共许可证的开发者通过两个步骤来保护您的权利：(1) 声明软件的版权，以及 (2) 向您提供本许

构建/测试 (Build/Test)

• 运行 (Run): bun run --conditions=browser ./src/index.ts
• 测试 (Test): bun test（运行所有测试）或 bun test test/tool/tool.test.ts（运行单个测试）
• 类型检查 (Typecheck): bun run typecheck（运行 tsgo --noEmit）

导入别名 (Import Aliases)

• @/* 映射到 ./src/*
• @tui/* 映射到 ./src/cli/cmd/tui/*

核心模式 (Key Patterns)

命名空间模块 (Namespace modules) —— 代码以 TypeScript 命名空间（Namespace）的形式组织，而不是类（Class）。每个模块导出一个包含其 Zod schema、类型和函数的命名空间：

export namespace Session {
  export const Info = z.object({ ... })
  export type Info = z.infer<typeof Info>
  export const create = fn(z.object({ ... }), async (input) => { ... })
}

Instance.