AGENTS.md

本文件面向在 VLA-Handbook 仓库中工作的自动化/AI agent，说明写作与维护规范。

目标

维护结构化、可检索的 VLA 知识库，避免信息碎片化。
保持目录索引与内容同步，方便读者快速定位。
坚持可验证、可追溯的技术信息。

仓库快速导航

theory/: 理论与核心算法（主要入口）
deployment/: 真机与部署
question-bank/: 面试题库与实战
cheat-sheet/: 速查表
book/: 电子书（输出多为生成内容）
product/: 机器人产品
system-design/: 系统设计
companies/: 公司与求职
theory/code-notes/: 代码级分析速记（自动/半自动生成）
reports/biweekly/: 双周前沿报告

Moltbot 写入协议

Moltbot（自动化 AI agent）通过 GitHub Contents API 向本仓库写入内容。以下规则不可违反。

写入权限矩阵

文件/目录	允许的操作	禁止的操作
`theory/paper_index.md`	追加表格行	修改/删除已有行、改表头、改分类结构
`theory/benchmark_tracker.md`	追加表格行	修改/删除已有行、改表头、改 section 结构
`deployment/release_tracker.md`	追加表格行	修改/删除已有行、改表头、改表格结构
`theory/code-notes/{project}_analysis.md`	创建新文件	修改已存在的文件
`reports/biweekly/{YYYY-MM-DD}.md`	创建新文件；如同日重跑允许覆盖（仅限自动生成内容）	修改人工撰写报告、改报告结构
`reports/biweekly/README.md`	追加索引行；同日允许 upsert（替换同日行并清理重复）	修改其他日期索引行、改文件结构
`CHANGELOG.md`	在顶部追加条目	修改已有条目
`deployment/robot_hardware_selection_pricing.md` / `product/.md` / `companies/.md`（条件触发）	仅在文末“自动追踪区”追加（见下）	修改/删除既有正文、在非自动区写入
其他所有文件	❌ 默认不可触碰	包括 theory/ 主目录深度笔记、deployment/ 其他文件、README.md 等

核心原则：Moltbot 默认只做“追加行/创建新文件”。仅在权限矩阵明确允许时，才可对“自动生成文件”做同日 upsert（用于重跑修复）；永远不修改、不删除人工内容。

条件触发：Handbook 业务文档同步更新（严格）

当且仅当满足以下条件时，才允许更新 deployment/robot_hardware_selection_pricing.md / product/ / companies/ 下的指定文件：

信息量足够，且确认为正式发布（必须有一手来源链接）
这次更新能明确改善读者决策（例如硬件选型、仿真平台升级路径）
宁可不写也不写错；不确定就跳过

写入协议：

只允许在目标文件文末创建或使用固定 section：## 🤖 Moltbot Updates
只做追加（append-only），每条追加必须包含：日期 + 事件一句话 + 影响一句话 + 一手来源 URL
永远不修改/删除既有人工内容（包括标题、表格结构、排序）

paper_index.md 写入规则

去重：写入前检查论文是否已存在（依据：arXiv ID > DOI > 标题比对），已存在则跳过。

容量控制：单日超过 8 篇匹配时，只写入 🔧 和 ⚡ 级别，跳过 📖 级别。

分类判断：将论文匹配到已有分类的表格中追加。如果无法判断分类，放入「其他」。不要创建新分类。

格式：严格遵循现有表格的列结构，每行末尾的备注栏标记来源（见下方标注系统）。

Commit Message 规范

所有 Moltbot 提交使用 emoji 前缀，便于在 git log 中区分人工与自动提交：

来源任务	Commit Message 格式	示例
Task 2（每日论文）	`📄 daily papers: {日期} (+N papers)`	`📄 daily papers: 2026-02-10 (+5 papers)`
SOTA Tracker（榜单追踪）	`📈 benchmark: {model} on {benchmark}`	`📈 benchmark: pi0.5 on LIBERO`
Release Tracker（平台/硬件）	`🔧 release: {source} — {event}`	`🔧 release: MuJoCo — v3.3.0 released`
Task 4（双周报告）	`📊 biweekly report: {起始} to {结束}`	`📊 biweekly report: 2026-02-01 to 2026-02-14`
代码分析	`📝 code analysis: {项目名}`	`📝 code analysis: OpenVLA-2`
索引更新	`📋 update index: {文件名}`	`📋 update index: biweekly/README.md`

人工提交不使用以上 emoji 前缀，默认即人工。

失败处理

GitHub API 返回非 2xx：不重试，记录错误，不影响主任务（Telegram 推送）
返回 409 conflict：放弃本次写入，推送告警
返回 401/403：推送告警「GitHub Token 可能已过期」
格式异常（表格列数不匹配等）：跳过写入，推送告警

标注系统

本仓库使用以下 emoji 标注论文/内容的重要性和来源。AI agent 读取内容时应理解这些标记的含义。

重要性标注（用于日报和 paper_index.md）

三级分类：

标记	含义	入选条件
⚡	战略级	知名团队 + 明显方法论创新或 benchmark SOTA
🔧	可操作	有代码/数据/协议可复现
📖	值得了解	有参考价值但不需立即行动

研究方向标记（叠加在三级分类之上）

标记	含义	示例
🎯	primary 方向（主攻方向，当前为「触觉 + VLA」）	`🎯🔧 [TactileVLA]...`、`🎯📖 [SoftTouch]...`
`[方向名]`	team 方向（信号追踪，门槛较高）	`[RL] ⚡ Google 发布...`、`[世界模型] 📖 ...`
（无标记）	通用 VLA 论文	`📖 [SomeVLA]...`

🎯 与 ⚡/🔧/📖 组合使用，不单独出现。

paper_index.md 备注栏格式

情况	备注格式
primary 方向	`🎯 tactile \| 📖 daily 2026-02-11`
primary + 有代码	`🎯 tactile \| 🔧 daily 2026-02-11 \| repo: {url}`
team 方向	`[RL] 📖 daily 2026-02-11`
team + 战略级	`[世界模型] ⚡ daily 2026-02-11 — {理由}`
通用	`📖 daily 2026-02-11`
通用 + 有代码	`🔧 daily 2026-02-11 \| repo: {url}`
通用 + 战略级	`⚡ daily 2026-02-11 — {理由}`
人工添加	`✍️`（Moltbot 不触碰带 ✍️ 的行）

内容来源标注（用于文件开头）

标记	含义
⚙️ 本文由 Moltbot 自动生成 \| {日期}	纯自动生成
⚙️ 初稿由 Moltbot 自动生成 \| {日期} \| 经人工编辑	自动生成后经人工修改
（无标记）	人工撰写（默认）

自动生成内容的存放与任务对应

内容类型	存放路径	来源任务	操作类型
论文索引追加	`theory/paper_index.md`（追加行）	Moltbot Task 2（每日热点）	追加行
Benchmark SOTA 追踪	`theory/benchmark_tracker.md`（追加行）	VLA Benchmark SOTA Tracker	追加行
Release 追踪（平台/硬件）	`deployment/release_tracker.md`（追加行）	VLA Release Tracker	追加行
双周前沿报告	`reports/biweekly/{YYYY-MM-DD}.md`	Moltbot Task 4（双周推理）	创建新文件 / 同日重跑允许覆盖
双周索引更新	`reports/biweekly/README.md`（追加/同日 upsert）	Moltbot Task 4（双周推理）	追加行 / 同日 upsert
代码级分析速记	`theory/code-notes/{project}_analysis.md`	Moltbot 代码分析任务	创建新文件

内容与格式规范

语言：中文为主，保留英文术语与官方命名；模型/论文名保持原文拼写。
文件名：使用 snake_case.md，避免空格与大写。
公式与代码：用 Markdown 代码块或 LaTeX；示例可运行且简洁。
引用：必须给出来源链接（论文优先 arXiv/DOI/官网；代码/模型优先 GitHub/HuggingFace）。
部署类文档建议结构：环境/硬件 → 步骤 → 配置/参数 → 常见坑 → 参考。

theory/ 写作风格（对齐 `theory/pi0_5_dissection.md`）

目标是把一篇文章写成**"可面试复述、可工程落地、可快速定位"**的结构化笔记，而不是流水摘要。

1) 开头固定结构（必须）

标题采用双语：# 中文标题 (English Title)
紧跟元信息块（blockquote）：
- 发布时间（或论文年份/版本）
- 论文题目/模型名（如适用）
- 核心定位（一句话回答：它解决什么痛点/相比谁提升了什么）
1-2 句导语：先写痛点与结论（避免铺垫太长）。

2) 强推荐的章节骨架（theory/ 默认模板）

按需删减，但尽量保持顺序与命名风格一致：

## 1. 核心架构/方法总览 (Overview / Architecture)
- ### 1.1 系统对比概览 (System Component Comparison)：用表格把模块、输入输出、频率/时序、训练/推理差异讲清楚。
- ### 1.2 关键机制 (Key Mechanism)：用要点解释"为什么这样设计"。
- ### 1.3 信息流/架构图 (Flow / Diagram)：优先用 ASCII 图或流程图代码块表达端到端路径。
## 2. 数学核心：X 如何实现 Y (Math Core)
- 先给目标，再给公式，再给变量说明（列表/小表格），最后给直觉。
- 若符号较多：加一段 > 符号与本文/相关文档保持一致：...。
## 3. 带数字走一遍：玩具例子 (Worked Example)
- 用 2D/低维例子把损失、推理/采样或更新过程走一遍，强调"可计算的闭环"。
## 4. 工程视角：快慢路径 / 训练-推理折中 (Engineering View)
- 写清楚：吞吐/延迟/步数/抖动/量化误差/内存等 trade-off。
- 用"工程含义"语言把公式落到控制频率、模块边界、部署约束。
## 5. 数据与评测 (Data & Eval)
- 数据组成、配比/标注类型、评测任务设置；避免只给结论不讲条件。
## 6. 能力与失败模式 (Capabilities & Failure Modes)
- 把"能做什么/不能做什么"讲具体（场景 + 原因）。
## 7. 与相关工作对比 (Comparison)
- 用表格对比同系列/基线：关注点、架构、训练方式、适用场景。
- 结尾放 1 条 面试 Tip：一句话告诉读者被问到时怎么答。
文章末尾统一：
- ---
- 返回链接：[← Back to Theory](./README.md)（或所在子目录的 README）。

3) 表达与排版习惯（建议遵守）

表格优先：遇到"对比/模块职责/优缺点/超参"先用表格。
分层标题：尽量用 ##/### 组织（避免大段无小标题正文）。
术语一致：同一概念的中英文/缩写在文内保持一致，首次出现给全称。
避免重复：0. 1 分钟版 写过的结论，正文不要再用同一句式复述；正文要新增信息（机制/变量/边界/数字/失败模式）来支撑，而不是把同一句扩写变长。
引用就近但不过载：关键结论附近放来源链接（至少 1 个可靠来源）；同一段/同一节若反复引用同一一手来源，不必每句话都挂链接，可保留 1 次或在章节末用 来源：... 集中列出。
不确定就标注：用 TODO/待证/待补 citation 明示，不要编造指标。

4) 最小质量门槛（theory/ 输出检查清单）

开头有元信息块（发布时间/定位/一句话 takeaway）
至少 1 张架构/信息流图（ASCII 也算）
至少 1 个"系统对比/组件对比"表格
"数学核心"包含：目标→公式→变量解释→直觉
至少 1 个玩具例子或具体数值推导（可很小）
有工程视角（延迟/步数/抖动/部署约束等）
有与基线/同系列对比 + 1 条面试 Tip
文末有返回索引链接 + 关键引用链接

5) theory/code-notes/ 轻量模板（代码分析速记）

theory/code-notes/ 存放自动或半自动的代码级分析，深度低于 theory/ 主目录的拆解笔记。

模板：

标题：# {项目名} — 代码级分析
元信息：repo URL、对应论文、团队、环境需求、复现难度（🟢🟡🔴）
## 架构概览：一段话 + 可选 ASCII 图
## 论文未提及的工程细节：逐条列出（这是最核心的部分）
## 与已知方法的对比：可选，如有已分析的相关项目
## 启发与可借鉴之处：1-3 句
文末：[← Back to Code Notes Index](./README.md) + [← Back to Theory](../README.md)

与 theory/ 主目录拆解的区别：

不要求：数学推导、玩具例子、面试 Tip
必须有：repo 链接、工程细节、复现难度判断
如果某个 code-note 值得升级为完整拆解，移入 theory/ 主目录并补齐质量门槛

reports/biweekly/ 写作规范

双周报告是索引层，不是分析层。目标是让读者 3 分钟掌握本期要点，再通过链接跳到深度内容。

固定结构

标题：# VLA 双周前沿报告 | {起始日期} – {结束日期}
元信息 blockquote：生成日期、覆盖范围
## 本期要点：3-5 条核心摘要，每条一句话
## VLA 模型与架构
## 开源项目与工具
## 硬件与部署
## 值得关注的论文：表格（论文 | 团队 | 关键词 | 链接）
## 趋势观察：2-3 段分析
文末返回链接：[← Back to Biweekly Index](./README.md)

与 theory/ 的区别

报告中不展开数学推导、玩具例子或工程细节
对值得深入的内容，用 → 深度笔记：[链接] 指向 theory/ 中的文档
每条摘要控制在 1-3 句话

质量门槛

有本期要点（≤5 条）
有论文表格（含链接）
有趋势观察（非流水账）
文末有返回索引链接

索引维护（必须同步）

theory/ 新增或改名：更新 theory/README.md（必要时 theory/README_FUN.md）。
新论文/综述：更新 theory/paper_index.md 与 theory/literature_review.md。
deployment/ 新增：更新 deployment/README.md。
question-bank/ 新增：更新 question-bank/README.md。
cheat-sheet/ 新增：更新 cheat-sheet/README.md。
需要新增入口时：更新根 README.md。
reports/biweekly/ 新增：更新 reports/biweekly/README.md（追加本期链接与摘要）。
theory/code-notes/ 新增：更新 theory/code-notes/README.md。

资产与图片

新增图片放 assets/，并使用相对路径引用。
避免提交大体积二进制文件，除非有明确需求。

避免事项

不要编造论文、实验结果或指标；不确定时标注 TODO/待证。
不要批量重写现有文档，优先小范围增量更新。
不要改动 book/output/ 等生成内容，除非明确要求。
Moltbot 不要修改或删除任何带 ✍️ 标记的人工内容。
Moltbot 不要创建新的分类/目录结构。

变更自检

索引可找到新增/修改文档
内部链接有效
术语与命名一致
有可靠来源链接
Moltbot 提交：commit message 使用正确的 emoji 前缀
Moltbot 提交：未修改权限矩阵以外的文件

AGENTS.md

本文件面向在 VLA-Handbook 仓库中工作的自动化/AI agent，说明写作与维护规范。

目标

维护结构化、可检索的 VLA 知识库，避免信息碎片化。
保持目录索引与内容同步，方便读者快速定位。
坚持可验证、可追溯的技术信息。

仓库快速导航

theory/: 理论与核心算法（主要入口）
deployment/: 真机与部署
question-bank/: 面试题库与实战
cheat-sheet/: 速查表
book/: 电子书（输出多为生成内容）
product/: 机器人产品
system-design/: 系统设计
companies/: 公司与求职
theory/code-notes/: 代码级分析速记（自动/半自动生成）
reports/biweekly/: 双周前沿报告

Moltbot 写入协议

Moltbot（自动化 AI agent）通过 GitHub Contents API 向本仓库写入内容。以下规则不可违反。

写入权限矩阵

文件/目录	允许的操作	禁止的操作
`theory/paper_index.md`	追加表格行	修改/删除已有行、改表头、改分类结构
`theory/benchmark_tracker.md`	追加表格行	修改/删除已有行、改表头、改 section 结构
`deployment/release_tracker.md`	追加表格行	修改/删除已有行、改表头、改表格结构
`theory/code-notes/{project}_analysis.md`	创建新文件	修改已存在的文件
`reports/biweekly/{YYYY-MM-DD}.md`	创建新文件；如同日重跑允许覆盖（仅限自动生成内容）	修改人工撰写报告、改报告结构
`reports/biweekly/README.md`	追加索引行；同日允许 upsert（替换同日行并清理重复）	修改其他日期索引行、改文件结构
`CHANGELOG.md`	在顶部追加条目	修改已有条目
`deployment/robot_hardware_selection_pricing.md` / `product/.md` / `companies/.md`（条件触发）	仅在文末“自动追踪区”追加（见下）	修改/删除既有正文、在非自动区写入
其他所有文件	❌ 默认不可触碰	包括 theory/ 主目录深度笔记、deployment/ 其他文件、README.md 等

条件触发：Handbook 业务文档同步更新（严格）

当且仅当满足以下条件时，才允许更新 deployment/robot_hardware_selection_pricing.md / product/ / companies/ 下的指定文件：

信息量足够，且确认为正式发布（必须有一手来源链接）
这次更新能明确改善读者决策（例如硬件选型、仿真平台升级路径）
宁可不写也不写错；不确定就跳过

写入协议：

只允许在目标文件文末创建或使用固定 section：## 🤖 Moltbot Updates
只做追加（append-only），每条追加必须包含：日期 + 事件一句话 + 影响一句话 + 一手来源 URL
永远不修改/删除既有人工内容（包括标题、表格结构、排序）

paper_index.md 写入规则

去重：写入前检查论文是否已存在（依据：arXiv ID > DOI > 标题比对），已存在则跳过。

容量控制：单日超过 8 篇匹配时，只写入 🔧 和 ⚡ 级别，跳过 📖 级别。

分类判断：将论文匹配到已有分类的表格中追加。如果无法判断分类，放入「其他」。不要创建新分类。

格式：严格遵循现有表格的列结构，每行末尾的备注栏标记来源（见下方标注系统）。

Commit Message 规范

所有 Moltbot 提交使用 emoji 前缀，便于在 git log 中区分人工与自动提交：

来源任务	Commit Message 格式	示例
Task 2（每日论文）	`📄 daily papers: {日期} (+N papers)`	`📄 daily papers: 2026-02-10 (+5 papers)`
SOTA Tracker（榜单追踪）	`📈 benchmark: {model} on {benchmark}`	`📈 benchmark: pi0.5 on LIBERO`
Release Tracker（平台/硬件）	`🔧 release: {source} — {event}`	`🔧 release: MuJoCo — v3.3.0 released`
Task 4（双周报告）	`📊 biweekly report: {起始} to {结束}`	`📊 biweekly report: 2026-02-01 to 2026-02-14`
代码分析	`📝 code analysis: {项目名}`	`📝 code analysis: OpenVLA-2`
索引更新	`📋 update index: {文件名}`	`📋 update index: biweekly/README.md`

人工提交不使用以上 emoji 前缀，默认即人工。

失败处理

GitHub API 返回非 2xx：不重试，记录错误，不影响主任务（Telegram 推送）
返回 409 conflict：放弃本次写入，推送告警
返回 401/403：推送告警「GitHub Token 可能已过期」
格式异常（表格列数不匹配等）：跳过写入，推送告警

标注系统

本仓库使用以下 emoji 标注论文/内容的重要性和来源。AI agent 读取内容时应理解这些标记的含义。

重要性标注（用于日报和 paper_index.md）

三级分类：

标记	含义	入选条件
⚡	战略级	知名团队 + 明显方法论创新或 benchmark SOTA
🔧	可操作	有代码/数据/协议可复现
📖	值得了解	有参考价值但不需立即行动

研究方向标记（叠加在三级分类之上）

标记	含义	示例
🎯	primary 方向（主攻方向，当前为「触觉 + VLA」）	`🎯🔧 [TactileVLA]...`、`🎯📖 [SoftTouch]...`
`[方向名]`	team 方向（信号追踪，门槛较高）	`[RL] ⚡ Google 发布...`、`[世界模型] 📖 ...`
（无标记）	通用 VLA 论文	`📖 [SomeVLA]...`

🎯 与 ⚡/🔧/📖 组合使用，不单独出现。

paper_index.md 备注栏格式

情况	备注格式
primary 方向	`🎯 tactile \| 📖 daily 2026-02-11`
primary + 有代码	`🎯 tactile \| 🔧 daily 2026-02-11 \| repo: {url}`
team 方向	`[RL] 📖 daily 2026-02-11`
team + 战略级	`[世界模型] ⚡ daily 2026-02-11 — {理由}`
通用	`📖 daily 2026-02-11`
通用 + 有代码	`🔧 daily 2026-02-11 \| repo: {url}`
通用 + 战略级	`⚡ daily 2026-02-11 — {理由}`
人工添加	`✍️`（Moltbot 不触碰带 ✍️ 的行）

内容来源标注（用于文件开头）

标记	含义
⚙️ 本文由 Moltbot 自动生成 \| {日期}	纯自动生成
⚙️ 初稿由 Moltbot 自动生成 \| {日期} \| 经人工编辑	自动生成后经人工修改
（无标记）	人工撰写（默认）

自动生成内容的存放与任务对应

内容类型	存放路径	来源任务	操作类型
论文索引追加	`theory/paper_index.md`（追加行）	Moltbot Task 2（每日热点）	追加行
Benchmark SOTA 追踪	`theory/benchmark_tracker.md`（追加行）	VLA Benchmark SOTA Tracker	追加行
Release 追踪（平台/硬件）	`deployment/release_tracker.md`（追加行）	VLA Release Tracker	追加行
双周前沿报告	`reports/biweekly/{YYYY-MM-DD}.md`	Moltbot Task 4（双周推理）	创建新文件 / 同日重跑允许覆盖
双周索引更新	`reports/biweekly/README.md`（追加/同日 upsert）	Moltbot Task 4（双周推理）	追加行 / 同日 upsert
代码级分析速记	`theory/code-notes/{project}_analysis.md`	Moltbot 代码分析任务	创建新文件

内容与格式规范

语言：中文为主，保留英文术语与官方命名；模型/论文名保持原文拼写。
文件名：使用 snake_case.md，避免空格与大写。
公式与代码：用 Markdown 代码块或 LaTeX；示例可运行且简洁。
引用：必须给出来源链接（论文优先 arXiv/DOI/官网；代码/模型优先 GitHub/HuggingFace）。
部署类文档建议结构：环境/硬件 → 步骤 → 配置/参数 → 常见坑 → 参考。

theory/ 写作风格（对齐 `theory/pi0_5_dissection.md`）

目标是把一篇文章写成**"可面试复述、可工程落地、可快速定位"**的结构化笔记，而不是流水摘要。

1) 开头固定结构（必须）

标题采用双语：# 中文标题 (English Title)
紧跟元信息块（blockquote）：
- 发布时间（或论文年份/版本）
- 论文题目/模型名（如适用）
- 核心定位（一句话回答：它解决什么痛点/相比谁提升了什么）
1-2 句导语：先写痛点与结论（避免铺垫太长）。

2) 强推荐的章节骨架（theory/ 默认模板）

按需删减，但尽量保持顺序与命名风格一致：

## 1. 核心架构/方法总览 (Overview / Architecture)
- ### 1.1 系统对比概览 (System Component Comparison)：用表格把模块、输入输出、频率/时序、训练/推理差异讲清楚。
- ### 1.2 关键机制 (Key Mechanism)：用要点解释"为什么这样设计"。
- ### 1.3 信息流/架构图 (Flow / Diagram)：优先用 ASCII 图或流程图代码块表达端到端路径。
## 2. 数学核心：X 如何实现 Y (Math Core)
- 先给目标，再给公式，再给变量说明（列表/小表格），最后给直觉。
- 若符号较多：加一段 > 符号与本文/相关文档保持一致：...。
## 3. 带数字走一遍：玩具例子 (Worked Example)
- 用 2D/低维例子把损失、推理/采样或更新过程走一遍，强调"可计算的闭环"。
## 4. 工程视角：快慢路径 / 训练-推理折中 (Engineering View)
- 写清楚：吞吐/延迟/步数/抖动/量化误差/内存等 trade-off。
- 用"工程含义"语言把公式落到控制频率、模块边界、部署约束。
## 5. 数据与评测 (Data & Eval)
- 数据组成、配比/标注类型、评测任务设置；避免只给结论不讲条件。
## 6. 能力与失败模式 (Capabilities & Failure Modes)
- 把"能做什么/不能做什么"讲具体（场景 + 原因）。
## 7. 与相关工作对比 (Comparison)
- 用表格对比同系列/基线：关注点、架构、训练方式、适用场景。
- 结尾放 1 条 面试 Tip：一句话告诉读者被问到时怎么答。
文章末尾统一：
- ---
- 返回链接：[← Back to Theory](./README.md)（或所在子目录的 README）。

3) 表达与排版习惯（建议遵守）

表格优先：遇到"对比/模块职责/优缺点/超参"先用表格。
分层标题：尽量用 ##/### 组织（避免大段无小标题正文）。
术语一致：同一概念的中英文/缩写在文内保持一致，首次出现给全称。
避免重复：0. 1 分钟版 写过的结论，正文不要再用同一句式复述；正文要新增信息（机制/变量/边界/数字/失败模式）来支撑，而不是把同一句扩写变长。
引用就近但不过载：关键结论附近放来源链接（至少 1 个可靠来源）；同一段/同一节若反复引用同一一手来源，不必每句话都挂链接，可保留 1 次或在章节末用 来源：... 集中列出。
不确定就标注：用 TODO/待证/待补 citation 明示，不要编造指标。

4) 最小质量门槛（theory/ 输出检查清单）

开头有元信息块（发布时间/定位/一句话 takeaway）
至少 1 张架构/信息流图（ASCII 也算）
至少 1 个"系统对比/组件对比"表格
"数学核心"包含：目标→公式→变量解释→直觉
至少 1 个玩具例子或具体数值推导（可很小）
有工程视角（延迟/步数/抖动/部署约束等）
有与基线/同系列对比 + 1 条面试 Tip
文末有返回索引链接 + 关键引用链接

5) theory/code-notes/ 轻量模板（代码分析速记）

theory/code-notes/ 存放自动或半自动的代码级分析，深度低于 theory/ 主目录的拆解笔记。

模板：

标题：# {项目名} — 代码级分析
元信息：repo URL、对应论文、团队、环境需求、复现难度（🟢🟡🔴）
## 架构概览：一段话 + 可选 ASCII 图
## 论文未提及的工程细节：逐条列出（这是最核心的部分）
## 与已知方法的对比：可选，如有已分析的相关项目
## 启发与可借鉴之处：1-3 句
文末：[← Back to Code Notes Index](./README.md) + [← Back to Theory](../README.md)

与 theory/ 主目录拆解的区别：

不要求：数学推导、玩具例子、面试 Tip
必须有：repo 链接、工程细节、复现难度判断
如果某个 code-note 值得升级为完整拆解，移入 theory/ 主目录并补齐质量门槛

reports/biweekly/ 写作规范

双周报告是索引层，不是分析层。目标是让读者 3 分钟掌握本期要点，再通过链接跳到深度内容。

固定结构

标题：# VLA 双周前沿报告 | {起始日期} – {结束日期}
元信息 blockquote：生成日期、覆盖范围
## 本期要点：3-5 条核心摘要，每条一句话
## VLA 模型与架构
## 开源项目与工具
## 硬件与部署
## 值得关注的论文：表格（论文 | 团队 | 关键词 | 链接）
## 趋势观察：2-3 段分析
文末返回链接：[← Back to Biweekly Index](./README.md)

与 theory/ 的区别

报告中不展开数学推导、玩具例子或工程细节
对值得深入的内容，用 → 深度笔记：[链接] 指向 theory/ 中的文档
每条摘要控制在 1-3 句话

质量门槛

有本期要点（≤5 条）
有论文表格（含链接）
有趋势观察（非流水账）
文末有返回索引链接

索引维护（必须同步）

theory/ 新增或改名：更新 theory/README.md（必要时 theory/README_FUN.md）。
新论文/综述：更新 theory/paper_index.md 与 theory/literature_review.md。
deployment/ 新增：更新 deployment/README.md。
question-bank/ 新增：更新 question-bank/README.md。
cheat-sheet/ 新增：更新 cheat-sheet/README.md。
需要新增入口时：更新根 README.md。
reports/biweekly/ 新增：更新 reports/biweekly/README.md（追加本期链接与摘要）。
theory/code-notes/ 新增：更新 theory/code-notes/README.md。

资产与图片

新增图片放 assets/，并使用相对路径引用。
避免提交大体积二进制文件，除非有明确需求。

避免事项

不要编造论文、实验结果或指标；不确定时标注 TODO/待证。
不要批量重写现有文档，优先小范围增量更新。
不要改动 book/output/ 等生成内容，除非明确要求。
Moltbot 不要修改或删除任何带 ✍️ 标记的人工内容。
Moltbot 不要创建新的分类/目录结构。

变更自检

索引可找到新增/修改文档
内部链接有效
术语与命名一致
有可靠来源链接
Moltbot 提交：commit message 使用正确的 emoji 前缀
Moltbot 提交：未修改权限矩阵以外的文件

AGENTS.md

AGENTS.md

目标

仓库快速导航

Moltbot 写入协议

写入权限矩阵

条件触发：Handbook 业务文档同步更新（严格）

paper_index.md 写入规则

Commit Message 规范

失败处理

标注系统

重要性标注（用于日报和 paper_index.md）

研究方向标记（叠加在三级分类之上）

paper_index.md 备注栏格式

内容来源标注（用于文件开头）

自动生成内容的存放与任务对应

内容与格式规范

theory/ 写作风格（对齐 theory/pi0_5_dissection.md）

1) 开头固定结构（必须）

2) 强推荐的章节骨架（theory/ 默认模板）

3) 表达与排版习惯（建议遵守）

4) 最小质量门槛（theory/ 输出检查清单）

5) theory/code-notes/ 轻量模板（代码分析速记）

reports/biweekly/ 写作规范

固定结构

与 theory/ 的区别

质量门槛

索引维护（必须同步）

资产与图片

避免事项

变更自检

Related Skills

Markdown Converter

Nano Banana Pro

1password

AGENTS.md

目标

仓库快速导航

Moltbot 写入协议

写入权限矩阵

条件触发：Handbook 业务文档同步更新（严格）

paper_index.md 写入规则

Commit Message 规范

失败处理

标注系统

重要性标注（用于日报和 paper_index.md）

研究方向标记（叠加在三级分类之上）

paper_index.md 备注栏格式

内容来源标注（用于文件开头）

自动生成内容的存放与任务对应

内容与格式规范

theory/ 写作风格（对齐 theory/pi0_5_dissection.md）

1) 开头固定结构（必须）

2) 强推荐的章节骨架（theory/ 默认模板）

3) 表达与排版习惯（建议遵守）

4) 最小质量门槛（theory/ 输出检查清单）

5) theory/code-notes/ 轻量模板（代码分析速记）

reports/biweekly/ 写作规范

固定结构

与 theory/ 的区别

质量门槛

索引维护（必须同步）

资产与图片

避免事项

变更自检

theory/ 写作风格（对齐 `theory/pi0_5_dissection.md`）

theory/ 写作风格（对齐 `theory/pi0_5_dissection.md`）