数据来源：codebuddy-plugins-official 市场 manifest（共 207 个插件，2026-07-16） 整理口径：从 207 个插件中筛出 软件开发生命周期、安全、办公、设计 四个领域；一个插件只归入一个主领域，跨领域插件在说明中以「兼属 ××」标注；其余 32 个插件列入文末「未归入」。

一、软件开发生命周期（134）

1.1 需求、规划与项目管理（8）

插件名	来源	说明
requirements-driven-workflow	官方	需求驱动开发工作流，含 90% 质量门控的功能实现流程
interview	外部	访谈式命令，用于细化大型功能计划与规格
conductor	外部	上下文驱动开发：上下文 → 规格与计划 → 实施的结构化工作流
agent-team-agile-workflow	官方	BMAD 敏捷工作流，含 PO、架构师、SM、开发、QA 角色代理与交互式审批
taskmaster	外部	基于 AI 的任务管理系统，提供命令、代理和 MCP 集成
commands-project-setup	外部	项目初始化与搭建命令
commands-project-task-management	外部	任务管理与项目跟踪命令
feature-dev	官方	全面功能开发工作流，含代码库探索、架构设计与质量审查智能体

1.2 架构与设计（软件架构）（7）

本教程基于本工作区已实现的「坦克大战」源码（HTML5 Canvas 复刻红白机 Battle City）逐模块讲解。 读完后你将能独立从零搭建一个 60fps、数据驱动、可扩展 的俯视角坦克射击游戏，并理解其中每个模块的设计取舍。

配套源码入口：index.html，核心逻辑在 js/ 下 6 个文件，单元测试在 tests/tank.test.js。

GitHub 源代码：https://github.com/wang-junjian/tank-battle

1. 项目简介与技术栈

「坦克大战」是一款经典俯视角坦克射击游戏：玩家操控己方坦克在 13×13 的迷宫战场中移动、射击，摧毁敌方坦克并保护己方基地（老鹰）。

技术栈（零依赖、零构建步骤）：

技术	用途
HTML5 Canvas 2D	全部战场渲染
原生 JavaScript（ES6 class）	游戏逻辑，不依赖任何框架
Web Audio API	实时合成音效与 BGM（无音频素材文件）
localStorage	最高分与配置持久化
node:test	引擎逻辑的单元测试（无需浏览器）

为什么选这套栈： 无打包、无依赖，双击即可运行；逻辑与渲染分离后，核心玩法甚至能在 Node 里跑测试。这对"快速做出可玩原型"极其友好。

2. 运行、调试与测试

2.1 本地运行

直接用浏览器打开 index.

数据来源：codebuddy-plugins-official 市场 manifest（共 207 个插件）

分类方式：基于插件 name / description 关键词的中文功能聚类（官方 category 字段缺失较多，故采用描述推断）。

分类概览：腾讯安全实验室：7 | 语言服务器 LSP：11 | 文档与办公：11 | 前端与 UI 设计：37 | 游戏开发：5 | 腾讯生态与 MCP 集成：16 | 工作流与生产力：77 | 内容创作与写作：7 | 系统与脚本开发：5 | 外部领域合集：31

腾讯安全实验室（7）

研究对象是 WorkBuddy 桌面客户端的安装包——更准确地说，是它解包后的 resources/ 与 cli/ 两个目录。我们想知道两件事：

（1）对话时「我」到底由什么拼成？ （2）「我」能调用哪些模型、这些模型又从哪来？

答案出人意料地干净：它们分别落在两套声明式配置文件里——提示词模板库与产品配置文件。你此刻正在阅读的「我」，本质上就是这两套文件在运行时的一次实例化。

0. 为什么值得写

平时我们用 AI 助手，关注的是「它能不能帮我干活」。但如果你想知道「它是怎么被造出来的」，安装包本身就是最好的教材：没有编译混淆、没有黑盒，所有「性格」「能力边界」「可用武器」都白纸黑字写在那里。

这次我们顺着两条主线往下挖：

• 主线 A —— 大脑（提示词模板）：resources/templates/ 下的 19 个文件（约 2400 行），决定了「我是谁、能做什么、如何行动」。
• 主线 B —— 武器库（模型配置）：cli/product*.json 下的 5 个文件，声明了「我能调用哪些模型、怎么路由、怎么计费」。

一、主线 A：提示词模板体系（"我"的大脑）

1.1 三层结构

resources/templates 不是一堆散落的提示词，而是一套以「角色」为主轴、以「模式」为运行时约束的模板工程体系，基于 Jinja2 风格语法（{{ var }} 占位符 + {% if

数据来源：cli/product.ioa.json（iOA 部署渠道覆盖层）
共 82 个模型条目，按路由代号（vendor）分组。

一、概览

• 模型总数：82
• 支持工具调用 (toolCall)：67 / 82
• 支持图像 (images)：67 / 82
• 支持推理 (reasoning)：50 / 82
• 仅推理 (onlyReasoning)：44 / 82
• 默认模型 (isDefault)：1

路由代号（vendor）分布

路由代号	数量	说明
e	33	外部聚合（多为国内厂商模型）
f	22	首方/海外聚合
tencent	7	TACO 代码补全/轻量子模型通道（非对话模型，能力字段为 None）
j	7	特定海外模型
i	2	iOA 专属条目
None	11	未标注（auto/default 等特殊聚合项）

注意：vendor 是后端路由代号，并非明文厂商名；同一逻辑模型在不同渠道 vendor 可能不同（例如 minimax-m2.5 在基座是 f、在 cloudhosted 是 e）。下表「推测来源」列按模型 id 名称推断，仅供参考，非配置字段。

推理档位（reasoning.effort）分布

effort 档位	数量
medium	25
(无effort字段)	17
high	8

计费倍率（credits）分布

空值 = 未显式声明（按渠道默认计费，多为 x1.00）。

研究对象：/Applications/WorkBuddy.app/Contents/Resources/app.asar.unpacked/（WorkBuddy 应用解包目录） 核心结论：可用模型不是硬编码在程序里，而是由 cli/ 目录下一组声明式产品配置文件（product*.json） 定义。机制为「一个基座 + 四个部署覆盖层」，运行时由环境变量选择渠道并合并生成最终模型清单。

一、模型定义的落点

模型定义全部集中在 cli/ 目录下的 5 个产品配置文件里，resources/ 目录中没有模型定义（那里是提示词模板、技能、插件）。

一、目录总览

resources/templates/ 共包含 15 个模板文件，组织为 4 个功能层级 + 1 个风格库：

一套面向 Agent 应用设计者的系统化设计原则、架构模式与实战指南。

基于对 WorkBuddy（CodeBuddy Code）工作空间源码、系统提示词、文档与架构的深度分析提炼而成。

目录

1. 概述：从 Chatbot 到 Agent 的范式跃迁
2. 原则一：闭环执行架构
3. 原则二：人格化身份体系
4. 原则三：分层记忆系统
5. 原则四：纵深防御安全模型
6. 原则五：渐进式能力扩展
7. 原则六：多模态工作模式
8. 原则七：上下文精细管理
9. 原则八：可组合的工具哲学
10. 系统架构全景图
11. 可复用的设计模式清单
12. 设计决策框架
13. 常见反模式

1. 概述：从 Chatbot 到 Agent 的范式跃迁

1.1 Chatbot 和 Agent 的本质区别

维度	Chatbot	Agent
核心能力	理解并回答	理解、计划、执行、验证
与环境的交互	被动接收文本	主动感知文件系统、网络、工具
输出的性质	文本回答	实际行动（文件变更、API 调用、部署）
正确性保障	依赖训练数据	通过执行测试、编译、对比等方式自我验证
会话生命周期	一问一答，无持续性	跨多轮持久化，可中断恢复
用户角色	提问者	协作者/监督者

设计 Agent 系统，首先要完成这个认知跃迁：Agent 不是"更强的 Chatbot"，而是一种全新的交互范式。

1.2 Agent 设计的核心张力

在设计 Agent 系统时，始终面临以下四对核心张力：

WorkBuddy 介绍

AI 专家团 全场景办公

WorkBuddy 是全能 AI 工作台，一人指挥，全行业专家执行，从策略到交付一站搞定

免部署·安装即用 ｜ 多专家·多模型协同 ｜ 全平台·桌面 / 主流 IM / 小程序

100+ 领域专家组成你的虚拟团队，运营、设计、数据、开发等全角色场景覆盖

一句话指令自主规划并交付完整结果

多专家并行协作，一个人顶一支团队

MCP 生态 + 自定义 Skills，能力无限扩展

设计系统（Design System）

• 场景：设计系统
• 模型：Deepseek-V4-Flash

输入（宫崎骏的太空之城风格设计系统）

帮我建立一套完整的 Design System，包含颜色体系、字体层级、间距规则和基础组件规范文档，风格为宫崎骏的太空之城

输出

基于 /Applications/WorkBuddy.app/Contents/Resources/app.asar.unpacked 逆向分析 WorkBuddy Desktop v5.2.5 + CodeBuddy CLI v2.106.4 | 腾讯出品

一、整体架构概览

graph TB
    subgraph "操作系统层"
        OS["macOS / Windows<br/>Darwin / Win32"]
        FSE["FSEvents API<br/>(macOS 文件监听)"]
        PTY["Pseudoterminal API<br/>(openpty / ConPTY)"]
        SQLITE["SQLite Engine<br/>(C++ 绑定)"]
    end

    subgraph "Electron 应用外壳 (WorkBuddy Desktop v5.2.5)"
        ELECTRON["Electron Main Process<br/>Node.js + Chromium"]
        RENDER["Renderer Process<br/>React/Vue UI + WebView"]
        DEVTOOLS["DevTools Panel<br/>Ghostty WASM Terminal"]
        PRELOAD["Preload Scripts<br/>IPC 安全桥接"]
    end

    subgraph "CLI 核心宿主 (CodeBuddy CLI v2.106.4)"
        CLI["cli/bin/codebuddy<br/>Node.js 启动器"]
        TUI["TUI Mode<br/>Ink + React 19<br/>~16MB Bundle"]
        DAEMON["Daemon Mode<br/>HTTP Server<br/>Port 51862+"]
        HEADLESS["Headless Mode<br/>-p / --print<br/>CI/CD 管道"]
        WEBUI["Web UI<br/>Workers / Logs / Metrics"]
    end

    subgraph "原生模块层 (app.asar.unpacked)"
        NATIVE_MOD["node_modules/"]
        BETTER_SQL["better-sqlite3<br/>v12.8.0 (MIT)"]
        NODE_PTY["node-pty<br/>v1.1.0 (Microsoft)"]
        LYDELL_PTY["@lydell/node-pty-darwin-arm64<br/>v1.2.0-beta.12"]
        DOCS_ENGINE["@tencent/docs-engine<br/>v0.0.1-beta.9"]
        FSE_MOD["fsevents<br/>(nunjucks 嵌套依赖)"]
    end

    subgraph "资源与扩展层 (resources/)"
        RES["resources/"]
        BUILT_PLUGINS["builtin-plugins/"]
        BUILT_SKILLS["builtin-skills/<br/>15 个内置技能"]
        BUILT_MCP["builtin-mcp-apps/"]
        TEMPLATES["templates/<br/>Nunjucks 提示词模板"]
        DEVTERM["devtools-terminal/<br/>Chrome Extension v3"]
        BRANDING["channel-branding/<br/>OEM 品牌资源"]
    end

    subgraph "AI 推理后端"
        BACKEND["copilot.tencent.com<br/>AI 推理集群"]
        MCP_PROXY["MCP Connector Proxy<br/>Port 61047"]
    end

    subgraph "用户数据层 (~/.workbuddy/)"
        USER_DATA["~/.workbuddy/"]
        DB["workbuddy.db<br/>(SQLite + WAL)"]
        SOUL["SOUL.md<br/>AI 灵魂"]
        IDENTITY["IDENTITY.md<br/>智能体身份"]
        MEMORY["memory/<br/>项目级记忆"]
        SESSIONS["sessions/<br/>会话 JSON"]
        TRACES["traces/<br/>运行追踪"]
    end

    OS --> ELECTRON
    ELECTRON --> RENDER
    ELECTRON --> PRELOAD
    RENDER --> DEVTOOLS

    ELECTRON -->|spawn| CLI
    CLI --> TUI
    CLI --> DAEMON
    CLI --> HEADLESS
    DAEMON --> WEBUI

    NATIVE_MOD --> BETTER_SQL
    NATIVE_MOD --> NODE_PTY
    NATIVE_MOD --> LYDELL_PTY
    NATIVE_MOD --> DOCS_ENGINE
    NATIVE_MOD --> FSE_MOD

    CLI --> NATIVE_MOD
    CLI --> RES

    RES --> BUILT_PLUGINS
    RES --> BUILT_SKILLS
    RES --> BUILT_MCP
    RES --> TEMPLATES
    RES --> DEVTERM
    RES --> BRANDING

    TUI -->|HTTP/WebSocket| BACKEND
    DAEMON -->|HTTP API| BACKEND
    HEADLESS -->|HTTP API| BACKEND
    BACKEND -->|MCP STDIO/SSE/HTTP| MCP_PROXY

    CLI -->|读写| USER_DATA
    DAEMON -->|读写| DB
    TUI -->|读取| SOUL
    TUI -->|读取| IDENTITY
    TUI -->|读取| MEMORY
    TUI -->|写入| SESSIONS
    TUI -->|写入| TRACES

    FSE -->|API 调用| FSE_MOD
    PTY -->|API 调用| NODE_PTY
    PTY -->|API 调用| LYDELL_PTY
    SQLITE -->|C++ 绑定| BETTER_SQL

    DOCS_ENGINE -->|"FFI 加载：libeditor_sdk_ffi.dylib (172 MB)"| EXT1
    DOCS_ENGINE -->|"HTTP Server：127.0.0.1:39099 本地文档预览"| EXT2
    DEVTERM -->|"WASM 执行：ghostty-vt.wasm 终端仿真"| EXT3
    EXT1 & EXT2 & EXT3:::dummy
    classDef dummy fill:none,stroke:none

    style ELECTRON fill:#e1f5fe
    style CLI fill:#fff3e0
    style BACKEND fill:#e8f5e9
    style USER_DATA fill:#fce4ec
    style NATIVE_MOD fill:#f3e5f5
    style RES fill:#e0f2f1

二、Electron 主进程与 CLI 双层架构

flowchart LR
    subgraph "Electron 主进程"
        direction TB
        EP1["app-instance.ts<br/>多实例检测"]
        EP2["auth.ts<br/>腾讯云 OAuth"]
        EP3["daemon-app-server-*.ts<br/>守护进程服务"]
        EP4["desktop-monitor-service.ts<br/>桌面监控"]
        EP5["helpers.ts<br/>工具函数集"]
        EP6["file-authentication-storage.ts<br/>文件认证存储"]
    end

    subgraph "CLI 进程 (Node.js 子进程)"
        direction TB
        C1["bin/codebuddy<br/>入口启动器"]
        C2["V8 Compile Cache<br/>~37% 启动加速"]
        C3["Node >= 18.20.8<br/>版本检查"]
        C4["Headless 路由<br/>--print / daemon / -p"]
        C5["TUI Bundle<br/>codebuddy.js<br/>Ink + React 19<br/>~16MB"]
        C6["Headless Bundle<br/>codebuddy-headless.js"]
    end

    subgraph "通信层"
        COM1["stdio<br/>标准输入输出"]
        COM2["HTTP<br/>Web UI / API"]
        COM3["WebSocket<br/>实时消息"]
        COM4["IPC<br/>Electron 内部"]
    end

    EP1 -->|"spawn('node', ['bin/codebuddy'])"| C1
    EP3 -->|HTTP 端口| COM2

    C1 --> C2
    C1 --> C3
    C1 --> C4
    C4 -->|TUI 模式| C5
    C4 -->|无头模式| C6

    C5 -->|stdio| COM1
    C5 -->|WebSocket| COM3
    C6 -->|HTTP| COM2
    EP1 -->|IPC| COM4
    RENDER["Renderer Process<br/>(UI 渲染)"] -->|IPC| COM4

    style EP1 fill:#e3f2fd
    style EP2 fill:#e3f2fd
    style EP3 fill:#e3f2fd
    style C1 fill:#fff8e1
    style C5 fill:#fff8e1
    style C6 fill:#fff8e1

关键设计决策：

• Desktop 与 CLI 版本分离：WorkBuddy Desktop v5.2.5 是 Electron 外壳，CodeBuddy CLI v2.106.4 是独立 Node.js 进程，两者版本独立演进
• 双 Bundle 策略：TUI 模式用 ink + React 19 提供交互终端，Headless 模式剔除 UI 依赖，显著减小启动开销
• V8 Compile Cache：通过 enableCompileCache() 将 ~16MB bundle 的加载时间从 ~400ms 降到 ~254ms
• --version 快速路径：直接返回版本号，跳过 DI 容器初始化和网络请求

三、原生模块与资源分层

graph LR
    subgraph "app.asar.unpacked 目录"
        direction TB
        subgraph "cli/ 目录"
            CLI_DIR["cli/"]
            CLI_BIN["bin/codebuddy<br/>入口脚本"]
            CLI_DIST["dist/<br/>codebuddy.js / codebuddy-headless.js"]
            CLI_WASM["dist/wasm/<br/>tree-sitter.wasm<br/>tree-sitter-bash.wasm"]
            CLI_WEBUI["dist/web-ui/<br/>docs/ (200+ 篇)"]
            CLI_VENDOR["vendor/<br/>sandbox / ripgrep / genie-trash"]
            CLI_PKG["package.json<br/>@genie/agent-cli"]
        end
        
        subgraph "node_modules/ 目录"
            NODE_DIR["node_modules/"]
            BETTER["better-sqlite3<br/>v12.8.0<br/>SQLite 数据库绑定"]
            NODE_PTY["node-pty<br/>v1.1.0<br/>Microsoft 伪终端"]
            LYDELL["@lydell/<br/>node-pty-darwin-arm64<br/>v1.2.0-beta.12"]
            TENCENT["@tencent/<br/>docs-engine<br/>v0.0.1-beta.9"]
            NJ["nunjucks<br/>+ fsevents<br/>模板引擎"]
        end
        
        subgraph "resources/ 目录"
            RES_DIR["resources/"]
            PLUGINS["builtin-plugins/<br/>weixinpay (MCP)"]
            SKILLS["builtin-skills/<br/>15 个技能"]
            MCP_APPS["builtin-mcp-apps/<br/>Ardot / Agently"]
            TEMPLATES["templates/<br/>8 模板 + 7 风格"]
            DEVT["devtools-terminal/<br/>Ghostty WASM"]
            BRAND["channel-branding/<br/>OEM 品牌"]
            PRELOADS["*-preload.js<br/>IPC 预加载脚本"]
        end
    end

    CLI_DIR --> CLI_BIN
    CLI_DIR --> CLI_DIST
    CLI_DIR --> CLI_WASM
    CLI_DIR --> CLI_WEBUI
    CLI_DIR --> CLI_VENDOR
    CLI_DIR --> CLI_PKG

    NODE_DIR --> BETTER
    NODE_DIR --> NODE_PTY
    NODE_DIR --> LYDELL
    NODE_DIR --> TENCENT
    NODE_DIR --> NJ

    RES_DIR --> PLUGINS
    RES_DIR --> SKILLS
    RES_DIR --> MCP_APPS
    RES_DIR --> TEMPLATES
    RES_DIR --> DEVT
    RES_DIR --> BRAND
    RES_DIR --> PRELOADS

    style BETTER fill:#ffebee
    style NODE_PTY fill:#ffebee
    style LYDELL fill:#ffebee
    style TENCENT fill:#ffebee
    style PLUGINS fill:#e8f5e9
    style SKILLS fill:#e8f5e9
    style MCP_APPS fill:#e8f5e9

为什么需要 app.asar.unpacked？

WorkBuddy 介绍

AI 专家团 全场景办公

WorkBuddy 是全能 AI 工作台，一人指挥，全行业专家执行，从策略到交付一站搞定

免部署·安装即用 ｜ 多专家·多模型协同 ｜ 全平台·桌面 / 主流 IM / 小程序

100+ 领域专家组成你的虚拟团队，运营、设计、数据、开发等全角色场景覆盖

一句话指令自主规划并交付完整结果

多专家并行协作，一个人顶一支团队

MCP 生态 + 自定义 Skills，能力无限扩展

绘制架构图和流程图

输入

@file:open-ai-eco 研究这个项目，绘制架构图和流程图。

输出

WorkBuddy 介绍

AI 专家团 全场景办公

WorkBuddy 是全能 AI 工作台，一人指挥，全行业专家执行，从策略到交付一站搞定

免部署·安装即用 ｜ 多专家·多模型协同 ｜ 全平台·桌面 / 主流 IM / 小程序

100+ 领域专家组成你的虚拟团队，运营、设计、数据、开发等全角色场景覆盖

一句话指令自主规划并交付完整结果

多专家并行协作，一个人顶一支团队

MCP 生态 + 自定义 Skills，能力无限扩展

截图重命名与分类

输入

把 截图 目录中的图像根据图像的内容进行重命名及文件夹分类。

输出

我先看看截图文件夹里有哪些图像，然后分析每张图的内容来重命名和分类。
截图文件夹有 11 张 PNG 图像。我需要逐一查看每张图的内容来判断如何命名和分类。我先读取这些图像。

我已经看完了全部 11 张截图，根据内容可以把它们分成三类。分类方案如下：

1. AI-概念图/

• Claude-Code-上下文工程.png（Claude Code 的上下文工程结构图）
• RAG-检索增强生成.png（ChatGPT / RAG 流程图）
• Multi-Agent-ChatDev工作流.png（ChatDev 多智能体开发流程）

2. Claude-Agent-SDK/ Claude-Agent-SDK-封面.

mindmap
  root((找到你的未知))
    【是什么】
      Anthropic 官方 agentic coding 指南
      核心观点：减少并管理未知 = 核心技能
      高手特征：未知少、懂代码库也懂模型
    【给谁用】
      用 Claude Code 的开发者
      面对陌生代码库/新领域的人
      想让 AI 协作更可控的人
    【核心框架：未知四象限】
      已知已知
        写进提示词的需求
      已知未知
        知道自己还没搞懂
      未知已知
        太显然没写 看到才认出
      未知未知
        完全没想到的坑 最危险
    【关键机制】
      告知起点上下文
        经验水平 思路进度 熟悉程度
      指令粒度要平衡
        太细→错过更优路径
        太粗→模型乱假设
      趁便宜先暴露未知
        原型期改成本远低于实施后
    【核心方法：按阶段】
      实施前
        盲点扫描：让 Claude 列出你的未知未知
        头脑风暴+原型：快速看到多种方向
        访谈：让 Claude 逐题问你澄清歧义
        参考引用：给源码当参照 比截图好
        实施计划：把易改决策放前面评审
      实施中
        实施笔记：记录偏离计划的决策
      实施后
        宣讲文档：加速评审者理解与批准
        测验：通过测验才算真懂 才合并
    【一句话精髓】
      让 Claude 帮你找未知
      在代价变大之前

原文：A field guide to Claude Fable 5: Finding your unknowns 作者：Thariq Shihipar（Anthropic 技术团队成员）

在使用 Claude Code 时，我常常想起地图与领土之间的区别。

地图，即待完成工作的表征，是我的提示词、技能和上下文——是我提供给 Claude 的东西。领土，则是工作需要实际发生的地方：代码库、现实世界、真实的约束条件。

地图与领土之间的差距，就是我所说的未知（unknowns）。当 Claude 遇到一个未知时，它需要根据对我意图的最佳猜测来做出决策。工作量越大，Claude 可能遇到的未知就越多。

Claude Fable 是我遇到的第一个模型，其工作质量的瓶颈在于我澄清未知的能力。

重要的是，仅仅提前规划并不总是足够的。你可能会在深入实现时发现未知，或者你的未知可能指向一个事实：你其实应该用完全不同的方式来解决问题。

我发现，使用 Fable 工作是一个迭代过程——在实现之前、之中和之后，不断发现自己的未知。

认识你的未知

你的未知是什么？当我带着问题来找 Claude 时，我倾向于将其分解为四种类型：

• 已知的已知（Known Knowns）：这本质上就是我的提示词中的内容。我告诉智能体我想要什么？
• 已知的未知（Known Unknowns）：我还有什么没搞清楚的，但我已经意识到我还没搞清楚？
• 未知的已知（Unknown Knowns）：有哪些事情如此显而易见，以至于我永远不会写下来，但看到时却能认出来？
• 未知的未知（Unknown Unknowns）：我完全没有考虑过什么？有哪些知识是我不知道自己不知道的？我知道某件事可以做得多好？

GitHub 仓库初始化

git init
git add .
git commit -m "first commit"

关联远程仓库并推送

git remote add origin https://github.com/wang-junjian/open-ai-eco.git
git branch -M main
git push -u origin main

视频没有使用 Git LFS

remote: warning: File public/videos/open-design-webprototype.mp4 is 84.20 MB; this is larger than GitHub's recommended maximum file size of 50.00 MB
remote: warning: GH001: Large files detected. You may want to try Git Large File Storage - https://git-lfs.github.com.
remote: warning: See https://gh.io/lfs for more information.

解决方案：

一、全局配置 public/videos/ 下所有文件走 Git LFS 1.

世界模型：预测下一个物理状态，理解世界演化。学习物理演绎的世界，编码物理规律，理解因果关系，推理未来状态。世界模型是智能体理解世界的基础。

• 智源对世界模型的思考（王仲远）

下面是 CLAUDE.md 文件的内容，用于改善 Claude Code 的行为，源自 Andrej Karpathy 的观察 关于 LLM 编码陷阱的总结。

CLAUDE.md

旨在减少大语言模型常见编码错误的行为准则。可根据项目特定说明按需合并。

权衡： 本准则偏向谨慎而非速度。对于琐碎任务，请自行判断。

1. 编码前先思考

不要假设。不要掩饰困惑。要呈现权衡。

实施之前：

• 明确陈述你的假设。如果不确定，就提问。
• 若存在多种解读，请呈现出来——不要默默选择一种。
• 若有更简单的做法，请说出来。在必要时坚持己见。
• 若某事不清楚，就停下来。指出困惑所在。提问。

2. 简单至上

用最少的代码解决问题。不添加任何推测性内容。

• 不添加需求以外的功能。
• 不为一次性代码创建抽象。
• 不提供未要求的“灵活性”或“可配置性”。
• 不对不可能发生的场景进行错误处理。
• 如果你写了 200 行，而本可以 50 行完成，那就重写。

问问自己：“一位资深工程师会认为这过于复杂吗？” 如果会，就简化它。

3. 外科手术式的修改

只碰你必须改的。只清理你自己弄乱的。

编辑现有代码时：

• 不要“改进”相邻的代码、注释或格式。
• 不要重构没有坏的东西。
• 即使你有不同做法，也要遵循现有风格。
• 若注意到无关的无效代码，提出来——但不要删除。

当你的修改造成孤立代码时： 删除由你的修改导致的未使用的导入/变量/函数。

递归自我改进（recursive self-improvement, RSI） 的概念可以追溯到 I. J. Good (1965)，他将"超智能机器"定义为一个能够在所有智力活动中超越人类、并设计出更好的机器来改进自身的系统。Yudkowsky (2008) 使用"递归自我改进"这一术语来描述一个特定的反馈循环：AI 利用其当前的智能来改进产生其智能的认知机制。

这种反馈循环在现代 AI 中可能意味着模型直接重写自身的权重，或者更广泛地说，模型改进了训练流水线和部署系统，从而催生出一个在经济价值任务上表现更优的继任模型。AI 研究发展的速度在前沿实验室中已被证明正在急剧加速（Anthropic；OpenAI）。

我特意提到 "部署系统"，因为原始模型与真实世界环境之间的这一层，似乎与模型原始智能（即预训练后的评估）同等重要。Harness 是 AI 部署的重要组成部分，Claude Code 和 Codex 等成功的编码智能体产品已证明了这一点。Harness 是围绕基础模型的系统，负责编排执行、决定模型如何思考和规划、调用工具和执行动作、感知和管理上下文、存储产物以及评估结果。

本文将聚焦于 harness 工程相关的研究，以及它如何促进 RSI。