基于 strix 1.3.1 源码（https://github.com/usestrix/strix）逐行核对 CLI 与运行逻辑编写。所有命令参数对应真实代码位置，可直接复制使用。

⚠️ 合规前提：Strix 是自动化渗透测试工具，仅可用于你拥有或已获书面授权的应用/资产。未经授权扫描他人系统属于违法行为。本指南所有示例目标均假设你拥有测试权限。

一、项目定位

Strix 是一个开源 AI 渗透测试工具，部署自主 AI agent 团队对应用进行漏洞发现与验证。核心区别于静态扫描器（SAST）：agent 像真实红队一样动态运行代码、构造 PoC、验证可利用性，产出可复现的漏洞报告而非误报堆积。面向开发与安全团队，支持 CI/CD 集成。

仓库：https://github.com/usestrix/strix ｜ 版本：1.3.1 ｜ License：Apache-2.0

二、技术栈

覆盖 8 款主流引擎，从开发语言、授权费用、2D/3D 能力、目标平台、学习曲线到生态资源全面对比。评分基于公开资料与社区共识，含主观判断，仅供选型参考。

• 游戏引擎对比分析

一、选型看哪些维度

• ① 开发语言：JS/TS 适合网页派；C# 门槛适中；C++ 性能强但陡峭；无代码更适合零基础。
• ② 授权与费用：开源免费（Godot / Phaser）最省心；Unity 订阅、Unreal 抽成，上线后都要算账。
• ③ 2D / 3D 能力：2D 多数引擎都强；3D 差距大，Unreal / Unity 领跑，Godot 4 进步明显。
• ④ 目标平台：纯网页 H5、微信小游戏、PC、手机 App、主机——覆盖度直接影响发行。
• ⑤ 学习曲线：无代码与 GDScript 上手快；C++ / 蓝图体系需要时间沉淀。
• ⑥ 生态与资源：教程、插件、素材商店的多寡，决定你卡壳时能不能自救。

二、综合对比表

多智能体深度调研成果

一句话结论：六家科技巨头已全部下场做 AI OS，2025–2026 年集中爆发；学界与产业界对其核心要素（记忆 / 决策 / 行动 / 安全四大系统原语）的定义高度收敛——AI OS 已从营销概念变成架构共识，竞争焦点转向「协议路线 vs GUI 路线」与「重构 vs 叠加」。

• 【Kimi】AI OS:智能体操作系统的范式革命 六巨头布局、核心本质与架构设计深度调研

Section 01 · 新闻背景

2026-07-13：阶跃星辰「四件套」发布，AI OS 之争进入白热化

上海「阶跃终端品牌暨新一代智能体战略发布会」上，大模型公司阶跃星辰一口气发布四件产品，宣称构建「模、软、硬」三位一体闭环，并提出智能体落地的「三堵墙」理论。[1][2]

• 品牌：STEPX —— 大模型原生 AI 终端品牌。阶跃公式：「Step 模型矩阵 × Step Agentic-native OS」。[3]
• 操作系统：Step AOS —— 「全球首个智能体原生操作系统」。官方口径为在 Android/Linux/RTOS 之上重构的智能体原生中间层，向下兼容。[4]
• 个人智能体：阶跃Amoo —— 拥有操作系统级身份：跨应用调度、端云协同、多设备任务接续，「越用越懂用户」。
• 硬件：STEPX Neo —— 大模型原生智能体手机，背部点阵 LED 像素副屏，华勤技术代工；WAIC 2026 首秀即获「镇馆之宝」。[5][6]

对象：iOfficeAI/OfficeCLI（https://github.com/iOfficeAI/OfficeCLI） 时间线：研究 → 安装到 WorkBuddy → 能力验证 → 三格式展示文档 文档性质：将「深度研究」与「本机实践」合并沉淀，既含结论也含可复现的操作记录

• 【WorkBuddy】AIOS_智能体操作系统范式革命.pptx

〇、一句话结论

OfficeCLI 是面向 AI Agent 的 Office 自动化套件：一个单文件二进制（内嵌 .NET 运行时，零安装、零外部依赖），提供对 Word / Excel / PowerPoint 的读、改、建能力，并用「高保真渲染 + 确定性 JSON 路径寻址」让 Agent 既能算、也能看见自己生成的排版（render → look → fix 闭环）。经本机实测，README 宣称的核心能力全部成立。它当前仅作为 WorkBuddy 用户级技能 安装在本机（~/.workbuddy/skills/officecli/），可被本 WorkBuddy 实例直接调用。

一、项目研究结论（深度）

1.1 定位与本质 类别：面向 AI Agent 的 Office 文档自动化工具 / AI 中间件（Agent 与 .docx/.xlsx/.pptx 之间的适配层，本身不是聊天机器人）。 技术本质： 单文件二进制：内嵌 .

面向 LLM · RAG · Agent 的高精度文档解析引擎 ｜ 实测版本 3.4.4 ｜ 含本地真实跑通经验与踩坑实录

• 【WorkBuddy】MinerU使用指南

一、介绍：MinerU 是什么

MinerU（opendatalab/MinerU）是一个面向 LLM · RAG · Agent 工作流 的高精度文档解析引擎。它把 PDF / 图片 / DOCX / PPTX / XLSX / 网页转换为机器可读的 Markdown / JSON，供下游检索、抽取与处理。它的起源是 InternLM 预训练过程中的科学文献符号（公式、表格）转换需求，因此对公式和表格的处理是强项。

一句话定位：把"人类看的文档"变成"模型能吃的干净结构化数据"——这是任何 RAG / 知识库 / 文档智能产品的第一道摄入层。

1.1 能力矩阵

基于本地实测（markitdown v0.1.6 · Python 3.13）编写，输出均为真实命令捕获，非示意。 项目：https://github.com/microsoft/markitdown ｜ 许可证：MIT（可商用）｜ 维护：Microsoft AutoGen 团队

验证进度：9 种格式中，Excel / Word / HTML / ZIP / Image(EXIF) / Audio(容器元数据) 已在本地用真实文件跑通；PPT / PDF 表现与直觉有出入（已标注）；YouTube 因本环境代理重置其 TLS 而未在本机跑通，命令与用法见第 5 节，可在能直连 YouTube 的机器上验证。

1. 它到底是什么

一句话：把任意文件（PDF / Office / 图片 / 音频 / 网页 / 压缩包…）转换成对 LLM 友好的 Markdown 的轻量 Python 工具。

本质定位：AI 应用链路里「模型前面的数据入口」——在喂给 RAG / 知识库 / 检索之前，先把杂乱格式洗干净。 设计哲学：不追求高保真排版还原，只保留对机器有用的结构（标题、列表、表格、链接），输出给文本分析工具消费。

⚠️ 它不是排版转换工具。如果你要的是「合同归档 / 视觉一致的 PDF 重排」，它不合适。

2. 30 秒上手

面向已部署 / 计划部署 AI 助手（如 WorkBuddy、ChatGPT Enterprise、Claude、内部 Copilot 等）的企业 覆盖：治理 · 部署架构 · 数据防护 · 访问控制 · 合规审计 · 落地路线图

• 原则：把发给 AI 的每句话当公开
• 分级 · 脱敏 · 最小权限 · 审计可追溯
• 贴合《个人信息保护法》《数据安全法》

1. 总体原则与定位

企业用 AI 不是"禁不禁"的问题，而是"在哪里用、用什么数据、谁能看"的问题。

核心结论（来自社区实践与一线技术文章共识）：企业用 AI 确实存在数据泄露风险，但风险主要源于架构选型与治理缺失，而非 AI 技术本身。通过私有化部署、RAG 权限隔离、严密的脱敏与审计，可构建"数据不出域"的安全闭环。

📌 四条铁律：

1. 假设公开：发给 AI 的内容视为可能公开，绝不粘贴凭证 / 完整 PII / 未脱敏商业机密。
2. 最小必要：只发送完成任务所需的最少数据，敏感字段在发送前脱敏或剔除。
3. 越敏感越本地：敏感度越高，处理越应留在内网 / 自托管模型。
4. 可审计：每一次 AI 调用、数据交互、工具执行都可溯源。

2. 组织治理框架

技术只占三分之一，治理决定成败。建议建立三层治理结构：

2.1 组织

• AI 治理委员会：由 IT、安全、法务、业务负责人组成，制定并监督 AI 使用安全标准。
• 数据保护官（DPO）/ 合规负责人：对接《个人信息保护法》义务，处理违规与事件上报。
• 部门 AI 管理员：负责本部门知识库权限、账号开通与日常培训。

——基于国内外主流社交平台（Reddit / Hacker News / Product Hunt / X / 小红书 / B站 / 知乎 / 即刻 / 微博）的需求信号挖掘、机会评估与技术验证路线图

报告日期：2026 年 7 月 25 日

摘要

本报告通过系统扫描国内外主流社交平台上用户的真实抱怨、许愿帖（"I wish there was an app…"类内容）、趋势报告与创业社区讨论，提炼出十大高频未被满足的需求信号，并构建六维加权评估模型筛选出五个最值得优先进行技术验证的创业方向：

排名	方向	加权得分（满分5）	一句话逻辑
1	垂直行业 AI 工作流 Agent（法律/会计/医疗/跨境电商等文档与流程自动化）	4.05	B 端付费意愿最强，"窄而痛"是 2026 年最确定的变现路径
2	适老化数字助手 / 亲情远程协助	4.05	2.8 亿老年网民 vs "教不会"的子女，竞争极稀疏
3	内容真实性与"去 AI 味"工具（B2B 营销侧）	3.85	AI slop 反弹下，"证明你是真人做的"成为新预算项
4	情绪陪伴 / 心理健康轻应用	3.75	孤独经济高速增长，但需严控合规与伦理
5	垂直窄教育 AI（出海优先）	3.75	已被中国小团队反复验证的现金牛模式

项目：icon-tool/（Next.js 16 + React 19 + Tailwind v4） 面向设计师的公开图标工具：浏览 + 检索 + 一键导出（SVG / Sprite / 多尺寸 PNG）

一、项目背景与目标

一个给设计师用的图标工具，要解决的核心痛点是：跨库统一搜索 + 一键导出多格式。首版定位为「游客可用的公开原型」——聚合精选开源库、强搜索、一键导出，账号/云端与 AI 生成推迟到后续阶段。

首版交付范围（Phase 0–3）：

• 内置 Lucide、Tabler、Phosphor 三库共 10134 个图标（构建时抽成 public/icons.json，约 7MB）
• 关键词搜索 + 按图标集 / 风格筛选（客户端）
• 悬停快操作、多选、批量导出 SVG 压缩包与 SVG Sprite
• 图标详情页 + 多尺寸 PNG 导出与复制
• 上传 SVG、收藏（均存 localStorage）

二、开发过程时间线

timeline
    title 图标工具开发时间线
    需求沟通 : 4 轮结构化提问收敛方向<br/>核心=浏览+检索+导出，技术栈/库/视觉/范围敲定
    Phase 0-1 : 脚手架 + 三库索引脚本<br/>10134 图标入仓，网格渲染 + 悬停快操作
    Phase 2-3 : 客户端搜索筛选 + 上传 + 多选批量导出
    设计升级 : 用 /前端开发 技能重做 UI<br/>暖中性画廊色 + 玻璃态 + Framer Motion
    体验迭代 : 放大图标 + 操作条移底 + 详情页 + 多尺寸 PNG
    沉淀 : 流程固化为 icon-library-bundler 技能 + 本文档

三、系统架构

graph TB
    subgraph 构建时["构建时 (CI / npm run build:icons)"]
        L["lucide-static"]
        T["@tabler/icons (outline)"]
        P["@phosphor-icons/core<br/>(regular + duotone)"]
        S["scripts/build-icons.mjs<br/>读 SVG→压缩→分类 style→索引"]
        L --> S
        T --> S
        P --> S
        S --> JSON[("public/icons.json<br/>10134 图标 · 7MB")]
    end

    subgraph 运行时["运行时 (Next.js App Router · 纯客户端)"]
        PG["app/page.tsx<br/>状态编排"]
        TB["TopBar<br/>批量操作条"]
        SB["Sidebar<br/>搜索/筛选/上传"]
        IG["IconGrid<br/>网格+骨架+空态"]
        IC["IconCard<br/>图标卡+底部操作条"]
        DP["app/icon/page.tsx<br/>详情页"]
        LD["lib/iconData.ts<br/>loadIcons / findIconById (缓存)"]
        EX["lib/export.ts<br/>SVG / Sprite / PNG"]
        LS[("localStorage<br/>收藏 / 上传")]
    end

    JSON -. "fetch 一次" .-> LD
    LD --> PG
    PG --> TB
    PG --> SB
    PG --> IG
    IG --> IC
    IC -. "双击 / 打开详情" .-> DP
    DP --> EX
    TB --> EX
    PG <--> LS

    style JSON fill:#faf9f5,stroke:#d97757,color:#141413
    style LS fill:#faf9f5,stroke:#a8a29e,color:#141413

关键架构决策：索引前置 + 纯客户端。

三库的 SVG 在构建时被抽成一份统一 JSON，前端加载后做客户端搜索与渲染，无需后端查询、无数据库、可静态部署。几千~上万个图标的规模下，fetch 一次 JSON + 内存过滤足够快。

四、关键技术流程

4.1 图标索引构建

flowchart LR
    A[扫描 node_modules<br/>各库 SVG 目录] --> B[读取每个 .svg 文本]
    B --> C[SVG 压缩<br/>去注释/多余空格/统一 currentColor]
    C --> D[归类 style<br/>line / filled / duotone]
    D --> E[组装统一记录<br/>id, set, name, style, tags, license, svg]
    E --> F[写入 public/icons.json]

统一记录结构（lib/types.ts）：

名称：officecli

描述：通过 officecli 命令行工具创建、分析、校对、修改 Office 文档（.docx、.xlsx、.pptx）。适用于用户需要新建文档、查看内容、检查格式、排查问题、插入图表或修改 Office 文件的场景。

officecli

适配AI使用的命令行工具，支持 .docx、.xlsx、.pptx。单二进制文件，无外部依赖，无需预先安装 Office。

安装

若未安装 officecli：

# macOS / Linux
curl -fsSL https://d.officecli.ai/install.sh | bash

# Windows（PowerShell）
irm https://d.officecli.ai/install.ps1 | iex

执行 officecli --version 验证安装。安装完成仍提示命令不存在时，请打开新终端重试。

使用层级策略

L1（读取操作） → L2（文档DOM编辑） → L3（原始XML） 优先使用更高层级接口。添加参数 --json 可输出结构化数据。

处理文档前，请查阅【专用技能模块】（文档底部） 融资演示文稿、学术论文、财务模型、数据看板、平滑切换（Morph）动画需要先加载对应专用技能——执行一次 load_skill 后再执行操作。

帮助系统（重要）

不清楚属性名称、取值格式、命令语法时，务必查看帮助文档，不

——写给完全不懂硬件的软件工程师的硬件设计入门读本

这份文档假设你从未接触过硬件设计。它一边讲这个项目做了什么、怎么做的， 一边把理解每个环节所需的硬件基础知识讲清楚。 读完后你应该能：看懂这套设计文件、知道每个文件是干什么的、 并能自己动手改一个尺寸、重新生成模型、拿去 3D 打印。

1. 这个项目是什么

我们团队做了一套「AI 智能会议系统」软件：开会时实时把语音转成文字、 区分是谁在说话（说话人分离）、会后自动生成会议纪要。这套软件完全离线 跑在一台 NVIDIA Jetson AGX Thor 开发套件上（一块带强大 AI 算力的卡片式电脑， 可以粗略理解为"一台浓缩到巴掌大、专门跑 AI 的小型工作站"）。

软件跑在芯片上，但芯片不能裸着摆在会议桌上。这个项目要做的， 就是给这套软件造一个 "身体"：一台放在公司会议室（20 人以内）桌上的 硬件终端——它有外壳、有麦克风阵列、有扬声器、有状态屏、有摄像头， 内部把 Thor 开发套件和这些器件安排得井井有条。

这台终端叫 智会 T1 (SmartMeet T1)，长这样：

需要说明的是：本项目交付的是结构设计与工程文档（外壳和内部布局怎么设计、 怎么装配、买什么零件），不包括电路设计和软件代码。

技能：image-text-desensitization（别名"智能自动脱敏工具"）v3.0.0 主类：SmartDesensitizer 能力：覆盖文本 / JSON / 图像三类对象的隐私脱敏，全程本地运行，不联网 安全背书：经腾讯云安全 cloudsec.tencent.com 与腾讯内部 tix.qq.com 扫描，状态均为"安全无风险（benign）"

颜色图例（贯穿全文）

颜色	类型
🟣 紫	手机号
🟠 橙	身份证
🩵 青	邮箱
🟢 绿	银行卡
🔴 红	IP 地址

① 能力总览

该技能是一个被动库——需要显式调用才生效，不会自动拦截对话。它提供三个入口方法：

入口	方法	说明
📝 文本脱敏	desensitize_text(text)	基于 5 条正则逐类替换。已验证可用，纯 Python 即可。
🧾 JSON 脱敏	desensitize_json(json_str)	按字段名命中 + 按值形态智能遮蔽。已验证可用。
🖼️ 图像脱敏	desensitize_image_base64(b64)	OCR 文字框 + 人脸检测后高斯模糊。需额外依赖（本地未装）。

② 文本脱敏规则 desensitize_text

源码写死 5 条正则，按固定顺序执行：手机 → 身份证 → 邮箱 → 银行卡 → IP。

基于一次真实落地经历整理：在 Apple M2 Max（64GB 统一内存）上部署 OpenMOSS/MOSS-Transcribe-Diarize（0.9B 端到端音频转写 + 说话人分离），并构建 Web 应用。过程中解决了长音频（30 分钟 / 1–2 小时）在 MPS 上 OOM / 静默卡死的问题。

本文不重复项目能力说明，只讲"怎么把它跑稳、跑长"。能力研究与部署步骤见 README.md，Web 后端实现见 webapp/app.py。

0. 一句话结论

不要在 Apple Silicon 上一次性推理超长音频。 端到端音频模型会把整段音频堆叠成一个巨型张量送编码器，自注意力矩阵大小 ∝ 音频长度²，几分钟可以、30 分钟必炸。正确做法是按 ≤300s 分块推理、块间重叠、时间戳偏移拼接、每块后释放 MPS 缓存。

1. 部署：把"能跑"变成"稳定跑"

1.1 固定依赖版本，杜绝解析回溯

torch>=2.8 + 未固定版本的 pip install -e . 会让 uv 陷入 version-resolution 回溯死循环（解析到 2.13、多个 transformers 版本，半小时不收敛）。

基于 OpenMOSS/MOSS-Transcribe-Diarize 的本地部署，并构建了一个 Web 应用：用户上传音频/视频，模型自动完成 转写 + 说话人分离（Diarization）+ 时间戳 + 声学事件感知，返回带说话人标签的结构化字幕。

mindmap
  root((MOSS-Transcribe-Diarize<br>本地部署与Web应用))
    模型与能力
      端到端音频理解（0.9B）
      联合ASR与说话人分离
      输出Sxx标签与时间戳
      声学事件感知
      支持50+语言
    部署环境
      Apple Silicon M2 Max
      Python 3.12 + venv
      PyTorch 2.11 + Transformers 5.10
      HF镜像下载
      FastAPI后端 + 静态前端
    长音频处理策略
      自动分块（默认300秒）
      块间重叠（15秒）
      绝对时间偏移与去重
      逐块释放MPS缓存
      跨块标签不对齐（需外部聚类）
    Web应用功能
      拖拽上传音视频
      异步任务轮询
      彩色说话人标签与时间轴
      点击段落定位播放
      导出SRT/JSON/TXT
      一键复制全文
    性能与边界
      RTF小于1（MPS加速）
      单块小于等于300秒稳定
      需注意MPS OOM风险
      支持环境变量调参

一、项目能力研究

定位

MOSS-Transcribe-Diarize 是 OpenMOSS 团队开源的 端到端（end-to-end）音频理解模型，当前版本 0.9B（2026-07-09 开源）。它一次性联合完成「语音识别 + 说话人分离」，而非传统 pipeline（ASR + 独立的 speaker diarization 再对齐）。

• 2026-07-14 获 INTERSPEECH 2026 第二届 MLC-SLM 挑战赛第一名（覆盖 14 种语言）。
• 更强版本 MOSS-Transcribe-Diarize Pro 即将以 API 形式提供。

核心能力

能力	说明
长音频多说话人转写	面向会议、电话、播客、访谈、讲座、视频等杂乱多说话人录音
说话人分离（Diarization）	输出一致的说话人标签 [S01] [S02] …
时间戳	秒级对齐，格式 [start][Sxx]text[end]
声学事件感知	可选输出，标注非语音声学事件
多语言	支持 50+ 种语言

本文件研究了 /Applications/WorkBuddy.app/Contents/Resources/app.asar.unpacked/resources/templates 目录下的全部 *.tpl 模板（12个文件），每个文件作为独立章节，原文（含 Jinja 占位符与 XML 标签）原样保留在代码块中。 基于你提供的 WorkBuddy Prompt 模板文件，以下是其整体架构与各模板关系的思维导图（Mermaid 格式）：

mindmap
  root((WorkBuddy Prompt 模板))
    分类与概览
      共12个模板
      分类：模式提醒 / 系统提醒 / 身份上下文 / 主Prompt
      主Prompt分4个场景：Ask·编码 / Ask·通用 / Craft·编码 / Craft·设计 / 专家·编码 / 专家·通用 / 通用Craft
    模式提醒片段
      ask-mode-reminder
        Ask模式硬性规则：只读·不编辑·不运行命令
        建议切换至Craft
      craft-mode-reminder
        Craft模式能力激活：可自由编辑与创建文件
        直接执行任务
    系统提醒片段
      system-reminder
        占位标签
        运行时由系统注入提醒
    身份上下文模板
      user-context-expert-identity
        专家模式身份注入
        含BOOTSTRAP.md / USER.md
        聚焦产品身份与语气占位
      user-context-identity
        通用身份注入
        含SOUL.md / IDENTITY.md / USER.md
        用户自定义指令与语气风格覆盖
    主Prompt·Ask模式
      workbuddy-ask-prompt
        纯对话场景
        只读工具·不可编辑
        可视化工具（read_me / show_widget）
        MCP配置引导
      workbuddy-ask-coding-prompt
        Ask + 编码场景
        与ask-prompt同源
        强调代码库上下文与只读分析
    主Prompt·Craft模式
      workbuddy-prompt
        通用Craft默认主提示
        能力总览·Agent循环·结果呈现
        自动化任务与技能管理
      workbuddy-craft-coding-prompt
        Craft + 编码场景
        Agent循环·任务管理工具
        技能积累与反思（SkillManage）
        自动化（automation_update）
        可视化与多模态生成
      workbuddy-craft-design-prompt
        Craft + 设计场景
        智能设计助手角色
        画布三段式回复格式
        文生UI·截图验证
        目标节点优先原则
    主Prompt·专家模式
      workbuddy-expert-prompt
        专家模式通用（AGENTIC）
        角色覆盖·产物概览
        松弛自然沟通风格
        多模态生成与技能积累
      workbuddy-expert-coding-prompt
        专家 + 编码场景
        与expert-prompt同源
        聚焦编码任务与产物交付

该图清晰呈现了：

• 4 大类模板（模式提醒、系统提醒、身份上下文、主 Prompt）
• 7 种主 Prompt 场景（Ask 通用、Ask 编码、Craft 通用、Craft 编码、Craft 设计、专家通用、专家编码）
• 各模板的核心定位与关键约束（只读/可编辑、身份注入、可视化、自动化、技能管理等）

模板概览

mindmap
  root((Hallmark))
    是什么
      反 AI 味的设计技能
      让 AI 生成的网页像人做的
      Together AI 出品 · MIT 开源
    给谁用
      Claude Code
      Cursor
      Codex
    核心功能 · 四个动词
      默认 · 新建设计
        预检扫描现有项目
        设计三问 · 受众/用途/基调
        先预览后写码
      audit · 体检
        给旧代码查 AI 味
        只出清单不改代码
      redesign · 重构
        留文案和品牌
        推翻视觉重做
      study · 提取 DNA
        从截图或 URL 学设计
        拒绝像素级抄袭
    凭什么不像 AI
      21 种页面结构
      20 个主题 · 4 流派
      58 道俗套检测门
      六维交付自评
    关键机制
      log.json 强制每次不重样
      tokens.css 设计系统可移植
      design.md 锁定整站风格
    怎么用
      npx skills add nutlope/hallmark

项目地址：https://github.com/Nutlope/hallmark 在线演示：https://www.usehallmark.com 许可证：MIT

一、这是什么

Hallmark 是一个面向 AI 编程助手（Claude Code、Cursor、Codex）的设计技能（Skill），由 Together AI 出品。它解决的问题很具体：大模型生成的网页 UI 总有股"一眼 AI"的味道——居中大标题、紫蓝渐变、三列等宽卡片、Inter 字体……Hallmark 用一套强制规则把这些"默认审美"全部禁掉。

它的核心理念是结构多样性优先于视觉多样性：两个不同需求（brief）生成的页面，不应该只是同一模板换了配色，而应该像两个真正不同的网站。为此它内置了：

• 21 种宏观结构（macrostructure）——页面的整体骨架，如 Bento Grid、Long Document、Manifesto、Marquee Hero、Stat-Led 等
• 20 个命名主题（theme）——分属四个流派（genre），外加一个"自定义主题"隐藏分支
• 50 个组件原型——9 种 Hero、14 种导航、8 种页脚、5 种节标题等
• 58 道"防俗套检测门"（slop test）+ 交付前六维自评——任何一项不达标就打回重做

本文记录 AI 生态工作台（open-ai-eco）通过 ACP（Agent Client Protocol） 接入本地 Agent 的完整实践：选型理由、架构设计、关键实现、踩坑经验与验证方法。

1. 背景与目标

工作台是组内的 Astro 站点，用于展示 AI 研究成果。日常工作中沉淀了一批 Agent 技能（Skill）：

• 研究 AI 项目：给一个 GitHub 地址，自动研究并把结构化信息写入项目 Excel；
• AI 周报：每周一生成结构化行业周报 Markdown；
• 后续还会有更多同类技能。

这些技能原本只能在终端里通过 Claude Code / Kimi CLI 使用。目标是：在工作台网页里加一个交互入口，直接在页面上对话、调用技能、审批文件操作，把"打开终端敲命令"变成"打开网页点一下"。

约束条件：主要自用、部署在内网 Node 常驻服务上、本地同时装有 Claude Code 与 Kimi CLI 两个 Agent。

2. 为什么选 ACP

一次「中国象棋 + 纯前端 + 自写搜索算法」的完整实践。零依赖、零构建，双击即玩。本文记录规则引擎、AI 搜索、Canvas 渲染的设计思路，以及布局调试中踩过的几个值得记住的坑。

WorkBuddy + GLM-5.2 开发的，花了 200 积分。开发出来第一个版本并没有花多少钱，问题是反复修改一些小问题，积分用量就上来了，感觉缓存并没有起作用。

一、需求与技术选型

需求很朴素：一款可以人机对弈的中国象棋 Web 应用。

权衡后定的方案：

维度	选择	理由
形态	单文件 index.html	双击即可运行，无需构建、无需服务器，便于分享
技术栈	原生 HTML5 + CSS3 + ES6	零依赖，引擎/AI/UI 全在一个文件里也能保持清晰
棋盘渲染	Canvas	棋盘线条、楚河汉界、九宫斜线用 Canvas 绘制最直接
AI 算法	Minimax + Alpha-Beta 剪枝	经典、可控、纯前端可跑，难度由搜索深度决定

架构上坚持一点：引擎层（棋盘状态 + 走子规则 + AI）与 UI 层（渲染 + 交互）彻底解耦。引擎函数只操作棋盘数组，不碰 DOM，方便单独测试和替换。

二、棋盘数据结构

中国象棋是 10 行 9 列的交叉点棋盘。用一个二维数组表示：

数据来源：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。

本周主线：Anthropic 双弹齐发 Sonnet 5 与 Claude Science，美团 LongCat-2.0 万亿参数模型亮剑国产算力，AI 独角兽 IPO 密集冲刺，优必选人形机器人订单破万——产业从实验室走向市场成为本周最强音。

本周看点

1. Anthropic 双弹齐发：Sonnet 5 性能逼近 Opus 4.8：价格仅为前者的三分之一，Agent 能力大幅跃升，同时推出 Claude Science 科研工作台，将多智能体编排推向科学计算场景。
2. 美团 LongCat-2.0 万亿参数模型亮剑：业界首个在五万卡国产算力集群上完成全流程训练的万亿参数大模型，OpenRouter 全球调用量排名前三。
3. 优必选 U1 人形机器人订单破万：消费级全尺寸人形机器人首发即获 13,361 台订单，标志着具身智能从实验室走向家庭的第一步。
4. AI 独角兽 IPO 密集窗口：Momenta、宇树科技、珞石机器人等 5 家 AI 企业冲刺上市，Anthropic 以 9,650 亿美元估值抢跑 OpenAI。
5. Meta 为防模型蒸馏划红线：内部限制使用 Claude Code 和 Codex，引发行业对 AI 时代「谁教会了谁」的深层讨论。

本周的六条主线——模型平权、智能体科研落地、编程工具体系化、机器人消费破冰、资本密集兑现、监管松绑——共同指向一个判断：AI 正从「能做什么」向「谁来做

本文系统梳理了「AI 生态实验室 · 技术雷达」的完整工作流程，从信息输入、项目筛选、研究落地到成果分享，形成一套可执行、可度量的常态化研究机制。

一、为什么需要一套固化流程

开源技术每天都在产生新变量。如果研究工作是"想到哪做到哪"，很容易陷入两个极端：要么因为信息过载而疲于奔命，要么因为缺乏目标感而长期停滞。我们需要的是一条从信息输入到技术落地的清晰链路，让每一天、每一周、每一个研究周期的产出都有明确的归属和节奏。

整个机制围绕三个核心问题展开：

1. 节奏问题：每天、每周、每月到底该干什么？
2. 方向问题：研究什么才能真正提升研发效率，而不是做无效功？
3. 价值问题：研究成果怎么让团队看见、让业务用上？

下面这张图，就是我们对这三个问题的系统化回答。

二、全景架构：一张图看懂技术雷达

整个技术雷达的运转可以分为 三个层面 和 一条核心闭环。

三个层面

层面	角色	说明
信息输入层	外部信息源 + 内部需求	决定"看什么"
核心引擎层	AI 生态实验室 · 技术雷达	决定"怎么研"
成果输出层	项目 PPT + 技术期刊 + 镜像库 + Skill	决定"产出什么"

一条核心闭环

项目开展工作流程：趋势洞察 → 深度研究 → 构建项目 → 测试验证 → 内网部署 → 镜像库。

这条链路从"每天的信息扫描"开始，到&q

一、技术方案

1.1 总体架构

采用 “公众号前端 + 智能客服中台 + 知识库底座” 三层架构：

层级	功能	技术选型建议
接入层	公众号对话入口，支持文字、图片、视频等多模态输入	微信公众号开发接口
智能客服中台	意图识别、知识检索、问答生成、智能路由（AI/人工分流）	RAG架构 + 大模型API（通义千问/Qwen、文心一言等）
知识库底座	产品手册、FAQ、历史工单、维修案例的结构化存储与向量检索	向量数据库 + 结构化知识库

1.2 核心功能模块

1. 智能问答：基于RAG（检索增强生成）架构，系统从知识库中检索相关文档，再由大模型生成精准答案。方案匹配准确率可达92%以上。

2. 多模态故障识别：支持客户上传故障图片/视频，利用多模态大模型进行图像识别与故障推理，自动推送处理建议。

3. 智能路由与转人工：AI首轮处理常规问题，疑难问题自动转接人工客服，实现“AI首轮服务＋人工兜底”的协同模式。

4. 知识自进化：系统在问答过程中持续学习，客户采纳的答案自动整理为问答对，不断优化知识库。

1.3 实施路径（建议分三期）