Cygnus Tech Blog

第01章 Agent 的 70 年简史 —— 从符号推理到深度学习

ruohuyang@163.com (Cygnus Yang) — Sat, 23 May 2026 00:00:00 +0800

你刚装好 Claude Code，输入一条命令，它就开始读代码、写文件、跑测试。一切都自动化了——感知代码库、推理目标、采取行动。这一切的背后是什么？是什么让一个模型变成了一个 agent？

什么是 Agent

Agent 的本质从 70 年前就没变过——一个在环境中感知、推理、行动的模型。

Agent = 模型 + 循环模型：推理引擎（感知 → 推理 → 决策）循环：observe → think → act → feedback

graph LR
 E[环境<br/>Environment] -->|感知<br/>Observation| M[模型<br/>Model]
 M -->|推理<br/>Inference| D[决策<br/>Decision]
 D -->|行动<br/>Action| E
 M --> MEM[记忆<br/>Memory]
 MEM --> M

核心定位：Agent 不是被编程出来的智能，而是被训练出来的智能。Agency——感知、推理、行动的能力——来自模型的训练，不是外部代码的编排。

符号 AI 时代（1956-1990）

Agent 的起点在 Dartmouth 会议（1956），那一年 “Artificial Intelligence” 这个词诞生了。

GOFAI：Good Old-Fashioned AI

符号 AI 的核心思想：智能来自符号操作和逻辑推理。通过手工编码规则、知识库、决策树来模拟智能行为。

维度	符号 AI Agent	弱点
定义	规则 + 推理引擎	❌ 无泛化能力
能力来源	人工编码知识库	❌ 规则脆弱
行动方式	硬编码分支	❌ 无法适应新场景
代表系统	专家系统、决策树	❌ 知识获取瓶颈

专家系统的兴衰：1980年代，专家系统（如 MYCIN、DENDRAL）在医疗诊断、化学分析等领域取得成功。但它们遭遇了"知识获取瓶颈"——每个领域的规则都需要专家手工编码，无法泛化，维护成本极高。

timeline
 title 符号 AI 时代（1956-1990）
 section 启蒙期
 1956 : Dartmouth会议<br/>AI 概念诞生
 1958 : LISP 语言诞生
 section 专家系统时代
 1972 : MYCIN 医疗诊断系统
 1980 : 专家系统商业化热潮
 section 认知转向
 1987 : 专家系统泡沫破裂
 1990 : 符号 AI 被质疑

机器学习时代（1990-2012）

符号 AI 的失败催生了新范式：从编码规则到训练模型。

从规则到学习

核心转变：不再人工编码决策逻辑，而是让模型从数据中学习模式。

维度	机器学习 Agent	符号 AI Agent
能力来源	从数据训练	人工编码规则
泛化能力	✅ 可以泛化到新数据	❌ 无法泛化
知识获取	自动从数据学习	需要专家编码
弱点	需要特征工程	规则脆弱

DeepBlue（1997）：IBM 的 DeepBlue 击败国际象棋世界冠军 Kasparov。但它本质上仍是搜索算法 + 评估函数，不是真正意义上的学习型 agent。

监督学习的局限：2000年代的机器学习以监督学习为主，需要大量标注数据。特征工程成为瓶颈——模型的表现很大程度上取决于人工设计的特征。

深度学习革命（2012-2022）

神经网络复兴：2012年，AlexNet 在 ImageNet 竞赛中大幅领先，开启深度学习时代。

端到端学习

核心突破：不再需要人工特征工程，模型可以直接从原始数据学习。

graph TB
 subgraph 传统机器学习
 A1[原始数据] --> A2[特征工程<br/>人工设计]
 A2 --> A3[模型训练]
 A3 --> A4[预测结果]
 end
 
 subgraph 挥度学习
 B1[原始数据] --> B2[神经网络<br/>自动学习特征]
 B2 --> B3[预测结果]
 end

Agent 的里程碑（2013-2019）

DeepMind DQN（2013）：一个神经网络，只接收原始像素和游戏分数，学会了 7 款 Atari 2600 游戏。没有游戏专属规则，没有决策树。一个模型，从经验中学习。到 2015年，同一架构扩展到 49 款游戏，达到职业人类测试员水平。

AlphaGo（2016）：击败李世石。围棋曾是 AI 研究者的噩梦——组合动作空间超过宇宙原子数量。AlphaGo 通过自我对弈学会了围棋，证明了深度学习 + 强化学习可以征服最复杂的游戏。

AlphaStar（2019）：DeepMind 的 AlphaStar 在星际争霸 II 中 10-1 击败职业选手，达到宗师段位（前 0.15%）。信息不完全、实时决策、组合动作空间远超围棋——agent 是什么？是模型。训练出来的。

OpenAI Five（2019）：五个神经网络，在 10 个月内与自己对战了 45,000 年的 Dota 2，击败 TI8 世界冠军 OG。没有脚本化的策略，没有团队协调逻辑。模型通过自我对弈学会了团队协作、战术和实时适应。

腾讯绝悟（2019）：在王者荣耀 5v5 模式下击败 KPL 职业选手。训练强度：一天等于人类 440 年。没有手工编写的英雄克制表，没有脚本化的阵容编排。

timeline
 title 深度学习 Agent 里程碑
 section 2013-2016
 2013 : DQN 玩 Atari<br/>从像素学习
 2016 : AlphaGo 击败李世石<br/>征服围棋
 section 2019
 2019 : AlphaStar 制霸星际<br/>宗师段位
 2019 : OpenAI Five 征服 Dota2<br/>击败世界冠军
 2019 : 腾讯绝悟统治王者荣耀<br/>超越职业选手

关键结论

每一个里程碑都指向同一个事实：Agency——感知、推理、行动的能力——是训练出来的，不是编出来的。

LLM Agent 时代（2022-2026）

大语言模型登场：GPT、Claude、Gemini——在人类全部文本和代码上训练的大模型，具备了前所未有的推理和泛化能力。

为什么是 LLM

维度	LLM Agent	传统 RL Agent
训练数据	人类全部文本/代码	特定领域数据
泛化能力	✅ 跨领域泛化	❌ 领域特化
推理深度	✅ 多步推理、规划	❌ 策略固定
知识广度	✅ 世界知识	❌ 游戏规则

LLM Agent 的核心：GPT/Claude 在人类全部文本上训练，推理能力来自数据而非架构。Agency 来自训练，不是来自提示词链或工作流编排。

Agent 产品爆发（2024-2025）

产品	定位	Harness 特点
Claude Code	编程 Agent	Bash/Read/Write/Edit + Skills + MCP
Cursor	IDE Agent	代码补全 + 重构 + 调试
OpenClaw	个人助手 Agent	多渠道通信 + 自动化
Codex CLI	命令行 Agent	Shell 执行 + 文件操作

提示词水管工陷阱

假 Agent 的本质：拖拽式工作流构建器、无代码 “AI Agent” 平台、提示词链编排库——它们共享同一个幻觉：把 LLM API 调用用 if-else 分支、节点图、硬编码路由逻辑串在一起。

flowchart TB
 subgraph FakeAgent["提示词水管工 (假Agent)"]
 A1[用户输入] --> A2{if-else 分支}
 A2 -->|分支1| A3[LLM调用1]
 A2 -->|分支2| A4[LLM调用2]
 A3 --> A5{再判断}
 A4 --> A5
 A5 --> A6[硬编码输出]
 end
 
 subgraph RealAgent["真Agent (Model + Harness)"]
 B1[用户消息] --> B2[Agent Loop<br/>observe→think→act]
 B2 --> B3[Model 推理]
 B3 -->|tool_use| B4[Harness 执行工具]
 B4 --> B2
 B3 -->|end_turn| B5[返回结果]
 end
 
 style FakeAgent fill:#FFE0E0
 style RealAgent fill:#E0FFE0

真相：它们做出来的东西是鲁布·戈德堡机械——过度工程化的、脆弱的过程式规则流水线。那不是 Agent。那是一个有着宏大妄想的 shell 脚本。

真正的 Agent 工程：Agency 来自模型，Harness 提供环境。Claude Code、OpenAI Five、AlphaStar——它们共享同一个架构：一个训练好的模型 + 一个让它能在特定环境中工作的基础设施（Harness）。

Agent 定义的演化

时代	Agent 定义	能力来源	弱点
符号AI（1956-1990）	规则 + 推理引擎	人工编码	无泛化、脆弱
机器学习（1990-2012）	特征 + 模型	训练数据	需特征工程
深度学习（2012-2022）	端到端网络	海量数据	计算昂贵、领域特化
LLM Agent（2022-2026）	大模型 + Harness	全量训练	需要 Harness

本章小结

Agent 的本质：一个在环境中感知、推理、行动的模型
Agency 的来源：来自模型训练，不是外部代码编排
70 年演变：符号AI → 机器学习 → 深度学习 → LLM Agent
永恒真理：最好的 Agent 出自信任模型、专注 Harness 的工程师之手

预告：下一篇我们深入看 LLM Agent 如何从游戏和实验室走向真实世界——2023-2026 的爆发期。

第01章 AI/深度学习增强控制

ruohuyang@163.com (Cygnus Yang) — Sat, 23 May 2026 00:00:00 +0800

概述

AI 增强控制是指利用人工智能技术（特别是深度学习和强化学习）来增强传统电机控制方法，实现更优性能。

传统控制 → AI 增强控制
│ │
│ │
│ PID 控制 │ PID + 神经网络补偿
│ 模型依赖 │ 模型自适应
│ 参数固定 │ 参数在线学习
│ 性能受限 │ 性能优化

AI 增强控制分类

┌───────────────────────────────────────────┐
│ AI 增强控制分类 │
└───────────────────────────────────────────┘
 ↓
┌─────────┴─────────┬──────────────┐
│ │ │
监督学习 强化学习 其他AI技术
│ │ │
└─────────┬─────────┴──────────────┘
 ↓
┌────────┬────────┬────────┬────────┐
│ │ │ │ │
神经网络补偿器 DRL 神经网络观测器 自适应控制

方法一：神经网络补偿器

原理

使用神经网络学习并补偿传统控制器的误差和未建模动态。

传统控制器 + 神经网络补偿器
 ↓
 输出 = u_traditional + u_NN
 ↓
 NN 学习并补偿误差

结构

 ┌─────────────┐
 │ 目标轨迹 │
 └──────┬──────┘
 │
 ┌──────┴──────┐
 │ 传统控制器 │
 │ (PID/FOC) │
 └──────┬──────┘
 │
 ┌──────┴──────┐ ┌─────────────┐
 │ 系统对象 │ ───→ │ 神经网络 │
 └──────┬──────┘ │ 补偿器 │
 │ └──────┬──────┘
 ┌──────┴──────┐ │
 │ 误差分析 │ ──────────────┘
 └─────────────┘

应用场景

应用	描述
参数变化补偿	温度导致的 R、L 变化
扰动补偿	负载变化、外部扰动
非线性补偿	齿槽转矩、磁饱和
死区补偿	逆变器死区效应

网络结构

import torch
import torch.nn as nn

class NeuralCompensator(nn.Module):
 """神经网络补偿器"""
 def __init__(self, input_dim=10, hidden_dim=64, output_dim=3):
 super().__init__()
 self.net = nn.Sequential(
 nn.Linear(input_dim, hidden_dim),
 nn.ReLU(),
 nn.Linear(hidden_dim, hidden_dim),
 nn.ReLU(),
 nn.Linear(hidden_dim, hidden_dim),
 nn.ReLU(),
 nn.Linear(hidden_dim, output_dim)
 )

 def forward(self, x):
 return self.net(x)

# 输入特征
# [i_d, i_q, ω, θ, e_d, e_q, u_d, u_q, 电压, 温度]

方法二：深度强化学习（DRL）

原理

通过智能体与环境的交互，学习最优控制策略。

MDP（马尔可夫决策过程）

MDP = (S, A, P, R, γ)

S: 状态空间
 S = [i_d, i_q, ω, θ, u_d, u_q, ...]
A: 动作空间
 A = [Δu_d, Δu_q] 或 [u_d, u_q]
P: 状态转移概率
 s' = P(s|a)
R: 奖励函数
 R = -α·e_ω² - β·e_τ² - γ·u²
γ: 折扣因子
 γ ∈ [0, 1]

DRL 算法选择

算法	特点	适用场景
PPO	策略梯度，稳定	连续动作空间
DDPG	确定性策略	高维动作空间
TD3	DDPG 改进，更稳定	复杂动态
SAC	最大熵策略	探索能力强

AI 增强控制对比

方法	优点	缺点	计算量	适用场景
NN 补偿器	简单有效，可解释	需要训练数据	低	参数补偿
DRL	自学习最优策略	训练复杂，不稳定	高	复杂优化问题
NN 观测器	快速推理	需要标签数据	低-中	无传感器
元学习	快速适应	训练复杂	高	批量部署

前沿方向

2024-2025 研究热点

安全强化学习
- 硬约束下的学习
- 安全认证
小样本学习
- 少数据快速适应
- 元学习应用
可解释 AI
- 理解神经网络决策
- 可信 AI
在线学习
- 持续适应变化
- 遗忘问题
硬件协同设计
- AI 加速芯片
- 边缘 AI

参考资源

资源	链接
强化学习基础	https://spinningup.openai.com/
DRL 电机控制	“Deep RL for Motor Control” 论文
TFLite Micro	https://tensorflow.org/lite/micro

最后更新：2025-05-07

第01章 GBrain 是什么

ruohuyang@163.com (Cygnus Yang) — Sat, 23 May 2026 00:00:00 +0800

从问题说起

传统知识管理为什么失败

知识管理软件已经存在 30 年，但绝大多数人仍然无法有效维护自己的知识库。为什么？

flowchart TD
 A[用户维护知识] --> B[需要持续的人力投入]
 A --> C[需要记住更新交叉引用]
 A --> D[容易产生信息孤岛]
 
 B --> E[知识库很快过时]
 C --> F[重要信息被遗忘]
 D --> G[维护成本高于使用价值]
 
 style A fill:#f9f,stroke:#333,stroke-width:2px
 style E fill:#f66,stroke:#333,stroke-width:1px
 style F fill:#f66,stroke:#333,stroke-width:1px
 style G fill:#f66,stroke:#333,stroke-width:1px

flowchart TD
 A[AI 智能体处理知识] --> B[非常聪明，能处理复杂问题]
 A --> C[但没有长期记忆]
 A --> D[每次会话都是从零开始]
 
 B --> E[无法从过去经验中学习]
 C --> F[无法积累知识]
 D --> G[重复回答相同的问题]
 
 style A fill:#9f9,stroke:#333,stroke-width:2px
 style E fill:#f66,stroke:#333,stroke-width:1px
 style F fill:#f66,stroke:#333,stroke-width:1px
 style G fill:#f66,stroke:#333,stroke-width:1px

GBrain 的核心洞察

将知识管理的维护成本降至近乎零，让维护成为正常操作的副作用。

flowchart LR
 A[人力维护] -->|高成本，不可持续| B[知识腐烂]
 C[自动化维护] -->|零边际成本，可持续| D[知识生长]
 
 style A fill:#f66,stroke:#333,stroke-width:2px
 style C fill:#6f6,stroke:#333,stroke-width:2px
 style B fill:#999,stroke:#333,stroke-width:1px
 style D fill:#6f6,stroke:#333,stroke-width:1px

核心定位

GBrain 是为 AI 智能体提供个人知识大脑能力的模块化系统。它不只是一个存储系统，而是一个让知识能够自我生长的智能基础设施。

三层定位

graph TB
 subgraph GBrain[GBrain 定位层次]
 direction TB
 
 subgraph L1[第一层：存储引擎]
 L1A[Postgres + pgvector]
 L1B[向量检索<br/>语义理解]
 L1C[关系存储<br/>实体关联]
 L1D[全文搜索<br/>精确匹配]
 
 L1A --> L1B
 L1A --> L1C
 L1A --> L1D
 end
 
 subgraph L2[第二层：检索智能]
 L2A[混合搜索<br/>向量+关键词+RRF 融合]
 L2B[意图分类]
 L2C[多查询扩展]
 L2D[去重机制]
 
 L2A --> L2B
 L2A --> L2C
 L2A --> L2D
 end
 
 subgraph L3[第三层：工作流编排]
 L3A[25 个可组合技能]
 L3B[技能路由系统]
 L3C[自动触发机制]
 L3D[链式调用]
 
 L3A --> L3B
 L3A --> L3C
 L3A --> L3D
 end
 
 L1 --> L2 --> L3
 end
 
 style L1 fill:#e1f5fe,stroke:#0277bd,stroke-width:2px
 style L2 fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
 style L3 fill:#fff3e0,stroke:#ef6c00,stroke-width:2px

实际应用案例

生产环境规模

GBrain 不是一个概念产品，它正在为 Y Combinator CEO 的实际 AI 智能体提供生产级支持。

mindmap
 root((生产环境数据规模<br/>单实例))
 知识库规模
 17,888 个页面
 人物: 4,383 人
 公司: 723 家
 交易: 1,200+ 笔
 概念: 8,500+ 条
 运行状态
 21 个定时任务在自主运行
 会议同步
 邮件监控
 社交媒体追踪
 健康检查
 构建时间
 原版: 12 天构建完成
 部署: 约 30 分钟完成配置
 维护: 零人力成本，自动运行

实际工作流示例

sequenceDiagram
 participant U as 用户
 participant A as AI 智能体
 participant G as GBrain
 participant S as 技能系统
 
 U->>A: "准备一下我和 Alice 的会议"
 
 Note over A,S: Brain-ops 技能触发
 A->>G: 搜索 people/alice
 
 Note over G: 执行混合搜索
 G-->>A: 返回 Alice 的完整信息
 
 Note over A: 获得编译真理 + 时间线
 
 par signal-detector 并行运行
 A->>S: 捕获实体: DeepMind, Bob, RAG
 end
 
 Note over S: enrich 技能自动触发
 S->>G: 为 Bob 创建/更新人物页
 S->>G: 为 DeepMind 创建/更新公司页
 S->>G: 建立 Alice → Bob 关系
 S->>G: 建立 Alice → RAG 主题链接
 
 Note over U,A: 知识库被动增长

技术基础

引擎对比

GBrain 支持两种引擎，满足不同场景的需求。

特性	PGLite（默认）	Postgres（可选）
技术	嵌入式 PostgreSQL 17.5 WASM	PostgreSQL + pgvector 扩展
存储	~/.gbrain/brain.pglite	Supabase Pro 或自托管
配置	零配置，开箱即用	DATABASE_URL 环境变量
就绪时间	2 秒	需要数据库连接时间
适用规模	单设备，1000+ 文件前	多设备同步，无限规模
成本	免费	Supabase Pro $25/月

数据迁移：

PGLite → Postgres：gbrain migrate --to supabase
Postgres → PGLite：gbrain migrate --to pglite

混合检索技术栈

flowchart TD
 subgraph Vector[向量检索]
 V1[模型: OpenAI text-embedding-3-large]
 V2[索引: HNSW 分层可导航小世界]
 V3[相似度: 余弦相似度]
 V4[优势: 语义理解，能找到概念相似的内容]
 end
 
 subgraph Keyword[关键词检索]
 K1[技术: PostgreSQL tsvector]
 K2[索引: GIN 索引]
 K3[匹配: 全文搜索，支持 trigram]
 K4[优势: 精确匹配，能找到完全相同的短语]
 end
 
 subgraph RRF[RRF 融合]
 R1[Reciprocal Rank Fusion]
 R2[score = sum/1/60 + rank]
 R3[向量和关键词独立排名，然后融合]
 R4[兼顾语义理解和精确匹配]
 end
 
 Vector --> RRF
 Keyword --> RRF
 
 style Vector fill:#e1f5fe,stroke:#0277bd,stroke-width:2px
 style Keyword fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
 style RRF fill:#fff3e0,stroke:#ef6c00,stroke-width:2px

为什么需要混合检索？

纯向量搜索的问题：

查询 “Steve Jobs” → 可能找到 “科技企业家列表"但错过精确姓名
查询 “2024 年” → 可能找到 “财务报告"但错过具体数字

纯关键词搜索的问题：

查询 “创业公司应该做什么” → 找不到 “Do Things That Don’t Scale”
查询 “AI 安全” → 找不到 “LLM 对抗攻击”

核心价值主张

传统问题	GBrain 的解决方案
知识维护需要持续人力投入容易忘，需要手动提醒更新	AI 智能体自动维护，无需人力干预每个信号都触发丰富流水线
信息分散在不同地方难以建立关联，知识库成为信息孤岛	自动建立交叉引用和实体关系关系图支持图查询，“我认识谁也认识 X？”
知识检索效率低下关键词搜索错过概念匹配向量搜索错过精确匹配	混合检索兼顾语义理解和精确匹配向量搜索解决语义鸿沟 RRF 融合取两者优势
AI 无法从过去经验中学习每次会话都是从零开始重复回答相同的问题	持久化记忆让知识随时间积累编译真理预计算，直接获取综合结果时间线记录完整证据链
知识库很快过时维护成本高于使用价值	知识库在睡眠中自我增长维护成本为零，边际效益递增

关键差异化特性

编译真理预计算
- 传统 RAG：每次查询都从头合成知识
- GBrain：合成已预计算，直接返回
- 优势：响应更快，质量更一致
自动丰富而非手动维护
- 传统系统：需要记得去更新相关页面
- GBrain：触及实体时自动触发
- 优势：永远不会遗漏更新
MECE 目录结构
- 传统系统：同一知识可能存在多个地方
- GBrain：每个知识片段有一个主要归属
- 优势：无歧义，无重复
技能系统而非硬编码逻辑
- 传统系统：固定的工作流，难以扩展
- GBrain：25 个可组合技能，易于定制
- 优势：灵活，社区可贡献

第01章 MCP 开发者指南：从零构建你的第一个 MCP Server

ruohuyang@163.com (Cygnus Yang) — Sat, 23 May 2026 00:00:00 +0800

本文站在开发者视角，带你从"写一个最简单的 MCP Server"开始，逐步理解核心概念，最终掌握完整的开发实践。

快速上手：5 分钟写出第一个 MCP Server
理解 Tools：让 AI 调用你的函数
理解 Resources：为 AI 提供背景数据
理解 Prompts：为用户预设交互模板
深入核心：架构与协议
传输选择：stdio vs Streamable HTTP
进阶实践：认证、日志、进度追踪
配置与部署：在 Claude 中使用

1. 快速上手：5 分钟写出第一个 MCP Server

让我们直接开始——先写出一个能运行的 MCP Server，然后再理解它是怎么工作的。

1.1 选择你的语言

MCP 官方提供了多个语言的 SDK，我们先用 Python（最简单）：

pip install mcp
# 或使用 uv
uv add mcp

1.2 第一个 Server：天气查询

创建 weather_server.py：

from mcp.server.fastmcp import FastMCP

# 第一步：创建 Server 实例
mcp = FastMCP("天气助手")

# 第二步：定义一个 Tool（让 AI 可以调用的函数）
@mcp.tool()
def get_weather(city: str) -> dict:
 """获取指定城市的天气信息"""
 weather_db = {
 "北京": {"temperature": "22°C", "condition": "晴转多云"},
 "上海": {"temperature": "26°C", "condition": "多云"},
 "深圳": {"temperature": "28°C", "condition": "晴"},
 }
 return weather_db.get(city, {"error": f"暂不支持城市: {city}"})

# 第三步：运行 Server
if __name__ == "__main__":
 mcp.run()

1.3 测试你的 Server

使用 MCP Inspector 调试：

npx @modelcontextprotocol/inspector python weather_server.py

你会看到一个 Web 界面，可以：

查看 Server 提供了哪些 Tool
手动调用 Tool 测试
查看请求和响应的原始数据

1.4 发生了什么？

恭喜！你刚写了一个完整的 MCP Server。让我们拆解一下：

部分	作用
`FastMCP("天气助手")`	创建 Server，命名为"天气助手"
`@mcp.tool()`	装饰器：把函数注册为 MCP Tool
`def get_weather(...)`	实际的业务逻辑
`mcp.run()`	启动 Server，默认用 stdio 传输

关键概念：什么是 MCP？

MCP（Model Context Protocol）是一个标准协议，它让你的代码（Server）可以被 AI 应用（Host，如 Claude Desktop）以统一的方式调用。

┌─────────────────┐ 标准协议 ┌─────────────────┐
│ Claude Desktop │ ◄───────────────────────► │ 你的 Server │
│ (Host) │ JSON-RPC over stdio │ (weather.py) │
└─────────────────┘ └─────────────────┘

2. 理解 Tools：让 AI 调用你的函数

Tool 是 MCP 最常用的原语——它是AI 模型可以自主决定调用的函数。

2.1 Tool 的工作流程

用户提问："北京天气怎么样？"
 │
 ▼
Claude 分析问题 → "需要调用 get_weather 工具"
 │
 ▼
Claude 调用 Tool（通过 MCP 协议）
 │
 ▼
你的 Server 执行函数 → 返回结果
 │
 ▼
Claude 用结果回答用户

2.2 写好 Tool 的要点

要点 1：文档字符串很重要

@mcp.tool()
def get_weather(city: str) -> dict:
 """获取指定城市的天气信息

 Args:
 city: 城市中文名，如"北京"、"上海"、"深圳"
 """
 # AI 靠这个文档字符串理解：
 # 1. 这个工具是做什么的
 # 2. 参数应该传什么

要点 2：参数类型要明确

# FastMCP 会自动从类型注解生成 JSON Schema
@mcp.tool()
def search_products(
 keyword: str, # 必填字符串
 category: str = "all", # 可选，默认值
 limit: int = 10, # 可选整数
 in_stock: bool = True # 可选布尔值
) -> list:
 """搜索产品"""
 pass

要点 3：返回值要结构化

# 推荐返回 dict 或 list，方便 AI 理解
@mcp.tool()
def get_user(id: str) -> dict:
 return {
 "id": id,
 "name": "张三",
 "email": "zhangsan@example.com",
 "is_active": True
 }

2.3 更多 Tool 示例

示例 1：数据库查询

@mcp.tool()
def query_users(min_age: int = 0, max_age: int = 150) -> list:
 """查询指定年龄范围的用户"""
 sql = "SELECT * FROM users WHERE age BETWEEN ? AND ?"
 return db.execute(sql, [min_age, max_age]).fetchall()

示例 2：文件操作（带安全检查）

import os
from pathlib import Path

ALLOWED_ROOT = Path("/safe/directory")

@mcp.tool()
def read_file(path: str) -> str:
 """读取文件内容（仅限安全目录）"""
 file_path = (ALLOWED_ROOT / path).resolve()

 # 安全检查：防止路径遍历攻击
 if not str(file_path).startswith(str(ALLOWED_ROOT)):
 return "错误：禁止访问该路径"

 if not file_path.exists():
 return "错误：文件不存在"

 return file_path.read_text()

示例 3：调用外部 API

import httpx

@mcp.tool()
def search_github(keyword: str, limit: int = 5) -> list:
 """搜索 GitHub 仓库"""
 response = httpx.get(
 "https://api.github.com/search/repositories",
 params={"q": keyword, "per_page": limit}
 )
 items = response.json()["items"]
 return [
 {
 "name": item["full_name"],
 "description": item["description"],
 "url": item["html_url"],
 "stars": item["stargazers_count"]
 }
 for item in items
 ]

3. 理解 Resources：为 AI 提供背景数据

Resource 是提供给 AI 作为上下文的只读数据——就像给 AI 一份参考材料。

3.1 Resource vs Tool：什么时候用哪个？

场景	用 Tool	用 Resource
需要执行操作（写数据库、发邮件）	✅	❌
提供背景信息（配置、文档）	❌	✅
AI 决定何时调用	✅	通常由用户/应用决定
可能有副作用	✅	❌（只读）

3.2 定义 Resource

@mcp.resource("config://app-settings")
def get_app_config() -> str:
 """提供应用配置作为上下文"""
 return """
# 应用配置
- 数据库：PostgreSQL (localhost:5432)
- 缓存：Redis (localhost:6379)
- 环境：生产
"""

3.3 参数化 Resource（URI 模板）

Resource 支持 URI 模板，可以动态获取数据：

@mcp.resource("user://{user_id}/profile")
def get_user_profile(user_id: str) -> str:
 """获取指定用户的个人资料"""
 user = db.get_user(user_id)
 return f"""
用户 ID: {user_id}
姓名: {user.name}
邮箱: {user.email}
注册时间: {user.created_at}
"""

3.4 Resource 完整示例：项目文档助手

from mcp.server.fastmcp import FastMCP
from pathlib import Path

mcp = FastMCP("项目文档助手")
PROJECT_ROOT = Path("/my/project")

# ─── Resource：提供 README ───
@mcp.resource("doc://README")
def get_readme() -> str:
 """项目 README 文档"""
 readme = PROJECT_ROOT / "README.md"
 return readme.read_text() if readme.exists() else "无 README"

# ─── Resource：提供目录结构 ───
@mcp.resource("project://structure")
def get_project_structure() -> str:
 """项目目录结构"""
 tree = []
 for path in sorted(PROJECT_ROOT.rglob("*")):
 if ".git" in path.parts:
 continue
 rel = path.relative_to(PROJECT_ROOT)
 indent = " " * (len(rel.parts) - 1)
 prefix = "📁" if path.is_dir() else "📄"
 tree.append(f"{indent}{prefix} {rel.name}")
 return "\n".join(tree)

# ─── Tool：搜索代码 ───
@mcp.tool()
def search_code(keyword: str) -> list[str]:
 """在代码库中搜索"""
 results = []
 for path in PROJECT_ROOT.rglob("*.py"):
 if keyword in path.read_text():
 results.append(str(path.relative_to(PROJECT_ROOT)))
 return results

4. 理解 Prompts：为用户预设交互模板

Prompt 是可复用的交互模板——帮助用户快速触发常用的 AI 工作流。

4.1 什么时候用 Prompt？

代码审查
翻译
文档生成
数据总结
任何标准化的交互流程

4.2 定义 Prompt

@mcp.prompt()
def code_review(code: str, language: str = "python") -> str:
 """代码审查模板"""
 return f"""请审查以下 {language} 代码，从以下方面给出建议：

1. 🔒 安全性：有没有安全漏洞？
2. ⚡ 性能：有没有性能问题？
3. 📝 代码风格：是否符合最佳实践？
4. 🐛 潜在 Bug：有没有逻辑错误？

代码：
```{language}
{code}

"""


### 4.3 Prompt 的使用方式

在 Claude Desktop 中，用户会看到 Prompt 作为菜单选项：
1. 用户选择"代码审查"
2. 界面弹出表单让用户填写 `code` 和 `language`
3. 提交后，Prompt 生成的消息自动发送给 Claude

### 4.4 多轮对话 Prompt

Prompt 可以返回多轮对话消息：

```python
from mcp.types import TextContent, Message

@mcp.prompt()
def pair_programming(task: str) -> list[Message]:
 """结对编程助手（多轮对话）"""
 return [
 Message(
 role="user",
 content=TextContent(
 type="text",
 text=f"我们一起完成这个任务：{task}"
 )
 ),
 Message(
 role="assistant",
 content=TextContent(
 type="text",
 text="好的！让我先了解一下项目结构..."
 )
 )
 ]

5. 深入核心：架构与协议

现在我们已经会写代码了，让我们深入理解 MCP 的工作原理。

5.1 核心架构

┌─────────────────────────────────────────────────────────┐
│ Host (Claude Desktop / Claude Code) │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Client 1 │ │ Client 2 │ │ Client 3 │ │
│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
└─────────┼─────────────────┼─────────────────┼───────────┘
 │ │ │
 │ 1:1 连接 │ 1:1 连接 │ 1:1 连接
 ▼ ▼ ▼
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ Weather Server │ │ GitHub Server │ │ File Server │
└──────────────────┘ └──────────────────┘ └──────────────────┘

角色	作用
Host	AI 应用（Claude Desktop），管理整个生态
Client	Host 创建，每个 Client 只连一个 Server
Server	你的代码，提供 Tools/Resources/Prompts

关键点：1:1 隔离

每个 Client-Server 对是独立的——这是安全设计，防止 Server 之间互相访问数据。

5.2 协议基础：JSON-RPC 2.0

MCP 使用 JSON-RPC 2.0 作为通信格式。

你不需要手写 JSON，但理解它会帮助你调试：

// Client → Server：列出所有 Tool
{
 "jsonrpc": "2.0",
 "id": 1,
 "method": "tools/list",
 "params": {}
}

// Server → Client：返回 Tool 列表
{
 "jsonrpc": "2.0",
 "id": 1,
 "result": {
 "tools": [
 {
 "name": "get_weather",
 "description": "获取指定城市的天气信息",
 "inputSchema": {
 "type": "object",
 "properties": {
 "city": { "type": "string" }
 },
 "required": ["city"]
 }
 }
 ]
 }
}

5.3 生命周期

MCP 会话有明确的三个阶段：

┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 初始化 │ ─────→ │ 运行中 │ ─────→ │ 关闭 │
│ Initialize │ │ Operation │ │ Shutdown │
└─────────────┘ └─────────────┘ └─────────────┘

初始化阶段：能力协商

这是最重要的一步——Client 和 Server 互相告诉对方：“我支持什么功能”。

# 你不需要手写这段代码，SDK 会处理
# 但理解它很有帮助

# Client → Server
{
 "method": "initialize",
 "params": {
 "protocolVersion": "2025-03-26",
 "capabilities": {
 "sampling": {}, // Client 支持让 AI 生成内容
 "roots": {} // Client 支持根目录管理
 },
 "clientInfo": { "name": "Claude Desktop", "version": "1.0" }
 }
}

# Server → Client
{
 "result": {
 "protocolVersion": "2025-03-26",
 "capabilities": {
 "tools": {}, // Server 提供 Tool
 "resources": {}, // Server 提供 Resource
 "prompts": {} // Server 提供 Prompt
 },
 "serverInfo": { "name": "天气助手", "version": "1.0" }
 }
}

6. 传输选择：stdio vs Streamable HTTP

MCP 支持多种传输方式，选择合适的取决于你的部署场景。

6.1 stdio：本地工具首选

# 默认就是 stdio
mcp.run()
# 或显式指定
mcp.run(transport="stdio")

工作原理：

Host 启动你的 Server 作为子进程
通过 stdin/stdout 交换 JSON-RPC 消息

适用场景：

本地工具（CLI、桌面应用集成）
个人使用的 Server
开发调试

优点：

简单，零配置
安全（本地信任）
不需要网络

6.2 Streamable HTTP：生产环境推荐

mcp.run(
 transport="streamable-http",
 host="0.0.0.0",
 port=8000,
 stateless_http=True, # 无状态，支持水平扩展
 json_response=True # 简化客户端
)

工作原理：

所有通信通过单个 HTTP 端点
响应可以是 JSON 或 SSE 流

适用场景：

远程部署的 Server
团队共享的 Server
生产环境

优点：

支持水平扩展
支持 OAuth 认证
可远程访问

6.3 选择指南

 你的场景？
 │
 ┌──────────────┼──────────────┐
 │ │ │
 ▼ ▼ ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ 个人工具 │ │ 团队共享 │ │ 生产服务 │
│ 本地开发 │ │ 远程 Server │ │ 高可用部署 │
│ │ │ │ │ │
│ ┌───────┐ │ │ ┌─────────┐ │ │ ┌─────────┐ │
│ │ stdio │ │ │ │ HTTP │ │ │ │ HTTP │ │
│ └───────┘ │ │ └─────────┘ │ │ └─────────┘ │
│ │ │ │ │ │
│ • 简单可靠 │ │ • 可远程访问 │ │ • 支持 OAuth │
│ • 零配置 │ │ • 团队共享 │ │ • 水平扩展 │
└───────────────┘ └───────────────┘ └───────────────┘

7. 进阶实践：认证、日志、进度追踪

7.1 日志：让 Server 告诉 Host 发生了什么

from mcp.server.fastmcp import Context

@mcp.tool()
async def process_large_data(ctx: Context, data: list) -> str:
 """处理大量数据"""
 await ctx.info("开始处理数据...")

 for i, item in enumerate(data):
 await ctx.debug(f"处理第 {i+1} 项: {item}")
 # ... 处理逻辑

 await ctx.warning("注意：有 3 项数据格式异常")
 await ctx.info("处理完成！")
 return "success"

7.2 进度追踪：长时间操作的用户体验

@mcp.tool()
async def batch_import(ctx: Context, items: list[str]) -> str:
 """批量导入数据"""
 total = len(items)
 success_count = 0

 for i, item in enumerate(items):
 # ... 导入逻辑
 success_count += 1

 # 报告进度
 await ctx.report_progress(
 progress=i + 1,
 total=total,
 message=f"已导入 {success_count}/{total}"
 )

 return f"成功导入 {success_count} 项"

7.3 OAuth 2.1 认证（HTTP 传输）

对于远程 Server，你可能需要认证：

from mcp.server.fastmcp import FastMCP
from mcp.server.auth.provider import AccessToken, TokenVerifier
from mcp.server.auth.settings import AuthSettings
from pydantic import AnyHttpUrl

class MyTokenVerifier(TokenVerifier):
 async def verify_token(self, token: str) -> AccessToken | None:
 # 验证 JWT token
 # 调用你的认证服务
 # 返回有效的 token 信息
 pass

mcp = FastMCP(
 "安全服务",
 token_verifier=MyTokenVerifier(),
 auth=AuthSettings(
 issuer_url=AnyHttpUrl("https://auth.your-company.com"),
 resource_server_url=AnyHttpUrl("https://mcp.your-company.com"),
 required_scopes=["read", "write"],
 ),
)

注意：stdio 传输不需要 OAuth——它依赖本地信任，可以从环境变量获取凭据。

8. 配置与部署：在 Claude 中使用

8.1 Claude Desktop 配置

编辑配置文件：

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json

{
 "mcpServers": {
 "天气助手": {
 "command": "python",
 "args": ["/path/to/weather_server.py"]
 },
 "GitHub": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-github"],
 "env": { "GITHUB_TOKEN": "ghp_你的token" }
 },
 "远程服务": {
 "url": "https://mcp.your-company.com"
 }
 }
}

8.2 Claude Code 配置

编辑 ~/.claude/settings.json：

{
 "mcpServers": {
 "weather": {
 "command": "python",
 "args": ["/path/to/weather_server.py"]
 }
 }
}

8.3 完整示例：项目全栈 Server

让我们写一个综合的 Server，用于项目开发：

from mcp.server.fastmcp import FastMCP, Context
from pathlib import Path
import subprocess
import json

mcp = FastMCP("项目开发助手")
PROJECT_ROOT = Path("/my/project")

# ─── Resource：项目结构 ───
@mcp.resource("project://structure")
def get_project_structure() -> str:
 """项目目录结构"""
 tree = []
 for path in sorted(PROJECT_ROOT.rglob("*")):
 if ".git" in path.parts:
 continue
 rel = path.relative_to(PROJECT_ROOT)
 indent = " " * (len(rel.parts) - 1)
 prefix = "📁" if path.is_dir() else "📄"
 tree.append(f"{indent}{prefix} {rel.name}")
 return "\n".join(tree)

# ─── Resource：README ───
@mcp.resource("doc://README")
def get_readme() -> str:
 """项目 README"""
 readme = PROJECT_ROOT / "README.md"
 return readme.read_text() if readme.exists() else "无 README"

# ─── Tool：运行测试 ───
@mcp.tool()
async def run_tests(ctx: Context, file: str | None = None) -> str:
 """运行项目测试

 Args:
 file: 指定测试文件，留空则运行全部测试
 """
 await ctx.info("开始运行测试...")

 cmd = ["python", "-m", "pytest"]
 if file:
 cmd.append(str(PROJECT_ROOT / file))

 result = subprocess.run(cmd, capture_output=True, text=True)

 if result.returncode == 0:
 await ctx.info("✅ 测试通过！")
 else:
 await ctx.warning("❌ 测试失败")

 return f"""
退出码: {result.returncode}

标准输出:
{result.stdout}

标准错误:
{result.stderr}
"""

# ─── Tool：搜索代码 ───
@mcp.tool()
def search_code(keyword: str) -> list[str]:
 """在代码库中搜索"""
 results = []
 for path in PROJECT_ROOT.rglob("*.py"):
 if keyword in path.read_text():
 results.append(str(path.relative_to(PROJECT_ROOT)))
 return results

# ─── Prompt：代码审查 ───
@mcp.prompt()
def review_file(path: str) -> str:
 """审查指定文件的代码"""
 file = PROJECT_ROOT / path
 code = file.read_text() if file.exists() else f"文件不存在: {path}"

 return f'''请审查以下代码文件：{path}

\``` {file.suffix.lstrip('.')}
{code}
\```

请从以下方面审查：
1. 安全性问题
2. 代码质量
3. 可维护性
4. 性能建议
'''

# ─── 运行 ───
if __name__ == "__main__":
 mcp.run()

总结

核心概念回顾

概念	作用	谁控制
Tool	AI 可调用的函数	模型
Resource	背景数据	应用/用户
Prompt	交互模板	用户

开发流程

从简单开始：先写一个 Tool，用 Inspector 测试
逐步添加：根据需要添加 Resource 和 Prompt
测试验证：用 Inspector 和 Claude Desktop 测试
部署配置：配置到 Host 中使用

下一步

查看官方示例：https://github.com/modelcontextprotocol/servers
阅读协议规范：https://modelcontextprotocol.io
加入社区讨论！

开始动手：用 @mcp.tool() 写你的第一个函数，运行 npx @modelcontextprotocol/inspector python your_server.py 调试。5 分钟就能跑通！

第01章 OpenClaw 是什么 —— 自托管个人 AI 助手的终极形态

ruohuyang@163.com (Cygnus Yang) — Sat, 23 May 2026 00:00:00 +0800

你有没有想过：拥有一个完全属于你自己的 AI 助手，它可以：

在你所有常用的聊天平台（WhatsApp/Telegram/Discord/iMessage）上工作
本地运行，你的数据不会离开你的设备
支持多个 AI 模型，你可以自由切换 Anthropic/OpenAI/Google 等等
内置浏览器自动化，可以帮你自动浏览网页
支持定时任务，定期帮你收集信息
多智能体协作，让多个专家 AI 一起帮你解决复杂问题
开放技能市场，你可以随时安装新技能

这就是 OpenClaw。

OpenClaw 定义

OpenClaw 是一个开源自托管个人 AI 助手网关，它帮你把 AI 能力接入到你日常使用的聊天平台，让 AI 随时随地陪伴你。

“Multi-channel AI gateway with extensible messaging integrations” —— GitHub 官方定义

简单说：

网关：中心服务，连接 AI 模型和聊天渠道
自托管：你自己部署，数据完全在你控制之下
多渠道：同一个 AI 助手，在 WhatsApp/Telegram/Discord/iMessage 都能用
可扩展：通过技能和插件，随时增加新能力

核心架构

OpenClaw 采用中心网关架构：

%%{init: {'theme':'base','themeVariables': {'primaryColor':'#f1f5f9','primaryBorderColor':'#0f4c81','primaryTextColor':'#0f172a','secondaryColor':'#f1f5f9','secondaryBorderColor':'#0f4c81','secondaryTextColor':'#0f172a','tertiaryColor':'#fbbf24','tertiaryBorderColor':'#fbbf24','tertiaryTextColor':'#0f172a','background':'#f8fafc','fontFamily':'Inter, system-ui, sans-serif','fontSize':'14px','textColor':'#0f172a','lineColor':'#334155','edgeLabelBackground':'#ffffff','actorBorderColor':'#0f4c81','actorTextColor':'#0f172a','actorFill':'#f1f5f9'}}}%%
graph TD
 G[Gateway<br/>中心控制平面 ws://127.0.0.1:18789]
 G --> C1[Chat Channel<br/>WhatsApp/Telegram/Discord]
 G --> C2[CLI<br/>命令行工具]
 G --> C3[WebChat UI<br/>网页界面]
 G --> C4[Native Clients<br/>macOS/iOS/Android]
 G --> C5[Pi Agent Runtime<br/>树莓派运行时]

所有组件都连接到中心 Gateway，Gateway 负责：

接收来自各个渠道的用户消息
路由给对应的 AI 会话处理
调用 AI 模型
把结果返回给用户

关键特性

让我们来看 OpenClaw 最重要的特性：

1. 25+ 消息平台支持

OpenClaw 开箱即用支持 25+ 聊天平台：

大平台：WhatsApp, Telegram, Discord, Slack, iMessage, Signal
其他：Matrix, Mastodon, Twitch, Line, 飞书等等

你不用换聊天软件，继续用你每天都用的那个，OpenClaw 直接接进去。

2. 本地优先，远程可访问

Gateway 运行在你自己的服务器或者电脑上
默认本地访问，数据不出去
需要远程访问的时候，可以通过 Tailscale 或者 SSH 隧道暴露
完全你掌控

3. 多智能体协作原生支持

这是 OpenClaw 最核心的能力之一：

sessions_spawn 核心原语，一键生成隔离子智能体
支持多种协作架构：Master-Worker, Hub-and-Spoke, Pipeline
深度限制防止上下文漂移
自动结果回传，不用你管

我们这个系列后面会专门讲这个。

4. 语音唤醒与语音交互

macOS 支持语音唤醒，说一声"Open Claw"就能唤醒
语音输入语音输出
完全本地，不用云

5. Live Canvas A2UI

实时可视化协作工作区，AI 可以直接在画布上画图、排版，你可以实时看到进度。

6. 内置工具开箱即用

浏览器控制：AI 可以帮你自动浏览网页、抓取内容
Cron 自动化：定时任务，比如每天早上给你汇总新闻
文件读写：读写本地文件
技能市场 ClawHub：分享和获取社区技能

7. 安全模型

配对白名单：只有允许的发送者才能访问你的 AI
DM 安全策略：阻止未认证发送者
所有数据你自己掌控，不会上传到第三方云

8. 模型故障转移

配置多个模型，一个失败了自动切到下一个，可用性更高。

谁适合用 OpenClaw

✅ 适合你如果：

你想要一个完全属于自己的 AI 助手，不想把数据给大厂
你经常在聊天平台，想要 AI 就在聊天窗口里面
你需要处理复杂任务，想要多个 AI 专家分工协作
你想要自定义扩展，开发自己的技能

❌ 可能不适合：

你想要开箱即用的 SaaS 服务，不想自己部署
你只需要简单的聊天，不需要多智能体协作

OpenClaw 和其他 AI 助手有什么不一样

维度	OpenClaw	ChatGPT APP	Claude.ai	其他 self-hosted 框架
自托管	✅	❌	❌	⚠️ 部分支持
多渠道接入	✅ 25+	❌ 单 APP	❌ 单 APP	❌ 一般只支持单渠道
原生多智能体	✅	⚠️ 有限	⚠️ 有限	❌ 很少原生支持
技能扩展	✅ 市场	❌	❌	⚠️ 需要自己写
语音唤醒	✅	✅	✅	❌

文档导航

OpenClaw 官方文档结构：

文档	内容
入门导航	`onboarding` 引导你完成设置
平台指南	Windows (WSL2), Linux, macOS, iOS, Android 各平台安装
架构	Gateway + 协议模型架构概述
配置参考	完整配置键参考
操作手册	Gateway 运行维护
远程访问	SSH 隧道 / Tailscale 配置
故障排查	常见问题调试
安全指南	暴露服务前必读

你看完这个系列，就能对照官方文档，部署一个自己用的 OpenClaw，并且理解背后的设计原理。

本章小结

OpenClaw 是自托管个人 AI 助手网关，让 AI 能力接入你日常聊天平台
中心 Gateway 连接各个渠道和 AI 运行时
核心特性：25+ 渠道支持、原生多智能体协作、本地优先、可扩展技能
接下来我们讲解核心架构，Gateway 为什么是中心控制平面

第01章 Workshop 分享稿：用 Claude Code 探索机器人与智能制造行业

ruohuyang@163.com (Cygnus Yang) — Sat, 23 May 2026 00:00:00 +0800

Workshop 分享稿：用 Claude Code 探索机器人与智能制造行业

分享背景

大家好，今天我想分享一个工具和方法，帮助我们快速了解一个新领域。

工具：Claude Code - 一个 AI 编程助手，但我觉得它更适合做知识探索

目标：15 分钟内，从零开始建立一个领域的认知框架，并逐步深入分析

今天的主题：机器人与智能制造（刚好和我们的课程相关）

时间安排

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#4FC3F7', 'primaryTextColor': '#1a1a2e', 'primaryBorderColor': '#0288D1', 'lineColor': '#0288D1', 'secondaryColor': '#B3E5FC', 'tertiaryColor': '#E1F5FE', 'nodeTextColor': '#1a1a2e'}}}%%
flowchart LR
 A["Part 1\n快速配置\n2min"] --> B["Part 2\n实战演示\n10min"] --> C["Part 3\n数据校验\n5min"] --> D["Part 4\n总结\n3min"]

Part 1：Claude Code 快速配置（2分钟）

为什么需要配置？

国内直接用 Claude Code 会遇到两个问题：

需要 Anthropic 官方登录（国内不方便）
API 调用需要稳定的国内代理

我的配置方案

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#81C784', 'primaryTextColor': '#1a1a2e', 'primaryBorderColor': '#388E3C', 'lineColor': '#388E3C', 'secondaryColor': '#C8E6C9', 'tertiaryColor': '#E8F5E9'}}}%%
flowchart LR
 A["① 跳过登录"] --> B["② 订阅 Coding Plan"] --> C["③ 配置 API"] --> D["④ 启动测试"]

① 跳过官方登录 — 创建 ~/.claude.json：

{
 "hasCompletedOnboarding": true
}

② 订阅国内 Coding Plan（推荐顺序）：

平台	体验
阿里云百炼	最稳定，服务省心，每天 9:30 抢 Pro
火山方舟	抢购难度低，入门首选

③ 配置 API — 在 ~/.claude/settings.json 填入：

{
 "env": {
 "ANTHROPIC_AUTH_TOKEN": "你申请到的API密钥",
 "ANTHROPIC_BASE_URL": "https://coding.dashscope.aliyuncs.com/apps/anthropic",
 "ANTHROPIC_MODEL": "qwen3.5-plus",
 "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1"
 }
}

④ 启动测试：

claude
# 简单测试一下
写一个 hello world 程序

Part 2：实战演示 - 机器人与智能制造分析（10分钟）

整体流程

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#4FC3F7', 'primaryTextColor': '#1a1a2e', 'primaryBorderColor': '#0288D1', 'lineColor': '#0288D1', 'secondaryColor': '#B3E5FC', 'tertiaryColor': '#E1F5FE'}}}%%
flowchart LR
 A["Step 1：建立框架"] -->|保存到文件| B["Step 2：追问深入"]
 B -->|选一个方向演示| C["Step 3：整理报告"]
 C --> D["Part 3：校验数据"]

目标说明

今天的演示，我想用 Claude Code 帮我们系统化地了解「机器人与智能制造」这个行业。

我们希望搞清楚的问题：

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#FFB74D', 'primaryTextColor': '#1a1a2e', 'primaryBorderColor': '#F57C00', 'lineColor': '#F57C00', 'secondaryColor': '#FFE0B2', 'tertiaryColor': '#FFF3E0'}}}%%
mindmap
 root((机器人与智能制造))
 行业现状
 市场规模
 主要玩家
 竞争格局
 技术发展路径
 各方向成熟度
 瓶颈与趋势
 商业闭环
 技术到产品路径
 盈利模式
 商业逻辑
 核心逻辑
 利润来源
 战略选择
 技术路线
 市场定位
 出海决策
 落地机会
 可投资方向
 可创业方向

这些信息如果用传统方式查，可能要花几天时间。今天我们用 Claude Code 在 10 分钟内建立一个初步框架。

Step 1：先建立框架（约3分钟）

我用的第一个 Prompt：

我想快速了解机器人与智能制造行业，请帮我：

1. 建立一个知识框架（分层级，方便后续深入）
2. 列出关键技术方向和它们的成熟度
3. 分析主要的商业模式和代表性企业
4. 找出未来有商业价值的方向

输出要求：
- 先保存到 Markdown 文件（方便后续在文件中多轮修改）
- 用表格对比关键要素
- 每个结论注明数据来源建议
- 结构适合我们课堂讨论

这个 Prompt 的预期输出：

Claude Code 通常会给出一个结构化的框架，可能包含：

技术层级表：列出各技术方向（工业机器人、协作机器人、AGV、人形机器人等），标注成熟度（成熟/成长/探索），给出代表企业
商业模式分类：对比不同模式（设备销售、解决方案、RaaS），分析各自的利润来源
商业机会清单：识别几个值得深入的方向，比如柔性制造、人形机器人、智能物流等

关键点：这个框架只是一个起点。输出内容的准确性、数据的来源、观点的深度，都需要我们在后续步骤中验证和补充。框架的作用是帮我们「知道要问什么」，而不是「知道答案」。

Step 2：针对重点问题追问（约5分钟）

基于刚才生成的框架文件，有几个点值得深入：

追问 1 - 人形机器人与具身智能：

读取刚才生成的文件，深入分析"人形机器人"和"具身智能"部分：

1. 现阶段的技术瓶颈在哪？（驱动、控制、感知）
2. Tesla Optimus 和国内玩家（优必选、傅利叶等）的技术路线对比
3. 各场景的商业化时间线预测（2025-2030）

给出对比表格

追问 2 - 商业模式变化：

读取刚才生成的文件，深入分析"商业模式"部分：

1. 传统"卖设备"模式的利润空间为什么在压缩？
2. RaaS（机器人即服务）模式的盈利逻辑是什么？
3. 国内企业在这个变化中如何找到机会？

补充具体案例分析

追问 3 - 战略选择：

读取刚才生成的文件，基于技术方向和商业模式的分析：

如果一家机器人企业要做战略决策，需要考虑哪些因素？

1. 技术路线：自研核心部件 vs 外采集成
2. 市场选择：全场景覆盖 vs 垂直深耕
3. 出海：欧美 vs 东南亚，风险和机会各是什么

给出决策框架

追问 4 - 具身智能融资：

读取刚才生成的文件，深入分析"融资情况"：

1. 2024-2025 年具身智能领域的融资事件汇总
2. 主要获投企业、融资金额、投资方
3. 资本看好哪些方向？投资逻辑是什么？
4. 和上一轮机器人热潮（2015-2018）相比，这次有什么不同？

给出融资数据表格和趋势分析

现场演示建议：从以上四个追问中选一个现场演示，完成后直接进入 Step 3 整理输出。

追问经验：

每次追问聚焦一个具体问题，别太散
要求输出表格或对比，方便讨论
如果输出太泛，就说「聚焦 XX 方向，更具体一点」

Step 3：整理成完整报告（约2分钟）

最后一个 Prompt：

把以上内容整理成一份完整的分析报告：

格式要求：
- 标题：机器人与智能制造行业分析
- 开头加一个执行摘要（200字左右）
- 结构：技术 → 商业模式 → 战略建议
- 最后加几个讨论问题（适合我们课堂）

保存成 Markdown 格式，方便后续修改

最终输出结构大概是：

# 机器人与智能制造行业分析

## 执行摘要
（核心发现：技术成熟度分层、商业模式转型、投资机会识别）

## 一、技术发展现状
（各方向成熟度 + 人形机器人专题）

## 二、商业模式分析
（传统 vs 新兴 + 成功案例）

## 三、战略建议
（技术路线 / 市场定位 / 出海）

## 四、讨论问题
1. 人形机器人商业化时间线是否乐观？
2. 国内企业如何突破"四大家族"？
3. RaaS 在中国市场可行吗？

Part 3：如何校验生成内容的数据准确性

这部分很重要。Claude Code 生成的框架和内容，数据不一定都对，我们需要一套校验方法。

为什么要校验？

常见问题：

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#EF9A9A', 'primaryTextColor': '#1a1a2e', 'primaryBorderColor': '#D32F2F', 'lineColor': '#D32F2F', 'secondaryColor': '#FFCDD2', 'tertiaryColor': '#FFEBEE'}}}%%
flowchart LR
 A["数据过时\n2024年数据实为2022年"] --> B["来源虚构\n引用不存在的报告"]
 B --> C["概念混淆\n协作机器人≠工业机器人"]
 C --> D["主观判断\n预测缺乏客观依据"]

校验的三个层面

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#4FC3F7', 'primaryTextColor': '#1a1a2e', 'primaryBorderColor': '#0288D1', 'lineColor': '#0288D1', 'secondaryColor': '#B3E5FC', 'tertiaryColor': '#E1F5FE'}}}%%
flowchart TD
 A["数据准确性"] --> A1["数字是否正确？"]
 A --> A2["来源是否真实？"]
 B["逻辑合理性"] --> B1["框架是否自洽？"]
 B --> B2["推论是否有支撑？"]
 C["观点时效性"] --> C1["结论现在还成立？"]
 C --> C2["有没有更新信息推翻？"]

使用 Skills 进行校验

Claude Code 有一些内置 Skills，可以帮助我们校验数据。以下是每个 Skill 的调用提示词：

Skill 1：WebSearch - 搜索最新数据

直接在对话中输入搜索请求，Claude Code 会自动调用 WebSearch。

请搜索"2024 年中国工业机器人市场规模"，找出 IFR、中国机器人产业联盟等权威来源的数据，对比我们文章中给出的数字是否一致

适用场景：验证市场数据、查找最新行业报告、对比多个来源

Skill 2：docs-lookup - 查官方文档

在提示词中明确说「使用 docs-lookup skill」。

使用 docs-lookup skill 查询 IFR（国际机器人联合会）的统计方法，确认文章中"工业机器人销量"的定义和口径是否正确

适用场景：确认技术术语定义、查询行业标准、验证官方数据口径

Skill 3：sequential-thinking - 深度推理验证

在提示词中明确说「用 sequential-thinking skill」。

用 sequential-thinking skill 验证："人形机器人 2025 年能实现大规模商业化"这个结论是否合理？

请从以下角度逐步推理：
1. 当前技术瓶颈（驱动、控制、感知各自的成熟度）
2. 成本下降曲线（关键部件价格走势）
3. 应用场景优先级（哪些场景最先落地）
4. 竞争格局演变（头部玩家进展）

给出每一步的判断依据和最终结论

适用场景：验证复杂推理、分析预测合理性、多因素综合判断

Skill 4：Context7 - 查库/框架文档

在提示词中说「使用 Context7」或「查询 [库名] 文档」。

使用 Context7 查询 ROS2（机器人操作系统）的官方文档，确认文章中提到的 ROS2 技术架构描述是否正确

适用场景：验证技术细节、确认 API/架构描述、查开源项目文档

Skill 5：Exa - 网页深度搜索

在提示词中说「用 Exa 搜索」。

用 Exa 搜索"比亚迪机器人业务"的相关报道，找出官方公告和媒体报道，对比文章中的信息是否准确

适用场景：企业信息核实、新闻报道验证、多来源深度对比

实战校验流程

假设 Claude Code 输出了：「2024 年中国工业机器人市场规模约 600 亿元」

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#81C784', 'primaryTextColor': '#1a1a2e', 'primaryBorderColor': '#388E3C', 'lineColor': '#388E3C', 'secondaryColor': '#C8E6C9', 'tertiaryColor': '#E8F5E9'}}}%%
flowchart LR
 A["① 搜索验证"] --> B["② 来源追溯"] --> C["③ 交叉验证"] --> D["④ 逻辑验证"]

① 搜索验证

请搜索"2024 中国工业机器人市场规模"，找出 IFR、中国机器人产业联盟、国家统计局的数据，对比差异

② 来源追溯

文章中提到"市场规模约 600 亿元"，这个数据来自哪个报告？请给出报告名称、发布机构、发布时间、原文链接

③ 交叉验证

请搜索三个来源验证"600 亿元"这个数据：
1. 行业协会（中国机器人产业联盟）
2. 企业财报（汇川技术、埃斯顿）
3. 第三方研究（麦肯锡、BCG）
对比数据，标注哪个最可信

④ 逻辑验证

用 sequential-thinking skill 验证：600 亿元这个数字是否合理？请从增长率、出口占比、内销占比逐步推理计算

校验结果的处理

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#CE93D8', 'primaryTextColor': '#1a1a2e', 'primaryBorderColor': '#7B1FA2', 'lineColor': '#7B1FA2', 'secondaryColor': '#E1BEE7', 'tertiaryColor': '#F3E5F5'}}}%%
flowchart TD
 A{"校验结果"} -->|"数据正确"| B["标注来源，保留使用"]
 A -->|"数据有偏差"| C["标注偏差范围，注明实际范围"]
 A -->|"数据无法验证"| D["标注「待验证」，不建议直接引用"]
 A -->|"来源不存在"| E["删除该数据，重新搜索真实来源"]
 A -->|"逻辑有问题"| F["指出逻辑漏洞，要求补充论证"]

校验习惯建议

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#4FC3F7', 'primaryTextColor': '#1a1a2e', 'primaryBorderColor': '#0288D1', 'lineColor': '#0288D1', 'secondaryColor': '#B3E5FC', 'tertiaryColor': '#E1F5FE'}}}%%
flowchart LR
 A["关键数据\n必验证"] --> B["来源\n必追溯"] --> C["多来源\n对比"] --> D["时效\n必确认"] --> E["存疑\n必标注"]

Part 4：总结一下

今天分享的核心：

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#81C784', 'primaryTextColor': '#1a1a2e', 'primaryBorderColor': '#388E3C', 'lineColor': '#388E3C', 'secondaryColor': '#C8E6C9', 'tertiaryColor': '#E8F5E9'}}}%%
flowchart LR
 A["配置\n两个文件\n跳过登录"] --> B["框架\n一个好 Prompt\n快速建立认知"] --> C["追问\n聚焦重点\n逐个深入"] --> D["整理\nClaude Code\n做格式化"] --> E["校验\n用 Skills\n验证数据"]

特别强调：生成的框架只是起点，关键数据必须用 Skills 校验后再使用。

如果大家有兴趣继续

可以试试这些主题：

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#FFB74D', 'primaryTextColor': '#1a1a2e', 'primaryBorderColor': '#F57C00', 'lineColor': '#F57C00', 'secondaryColor': '#FFE0B2', 'tertiaryColor': '#FFF3E0'}}}%%
flowchart TD
 A["人形机器人商业化\n分析人形机器人的商业化路径和时间线"] --> B["柔性制造转型\n分析中小工厂自动化改造的机会和挑战"]
 B --> C["机器人投资价值\n分析机器人赛道的投资逻辑和风险"]
 C --> D["AI+机器人融合\n分析AI如何提升机器人智能化水平"]

一些 Prompt 参考

行业快速了解模板

我想快速了解 [XX行业]，请帮我：

1. 建立知识框架（层级清晰）
2. 列关键技术方向和成熟度
3. 分析主要商业模式
4. 找出未来有价值的机会

输出：表格对比 + 数据来源建议

深入分析模板

请深入分析 [具体问题]：

1. 现状和瓶颈
2. 不同路线对比
3. 未来发展趋势
4. 给出决策建议

输出：对比表格 + 具体案例

报告整理模板

请整理成报告：

- 执行摘要（200字）
- 分章节展开
- 添加讨论问题（3-5个）
- Markdown 格式保存

如果大家有问题，或者想一起试试，欢迎讨论。谢谢大家！

第01章为什么是人机协作，而非全自动？

ruohuyang@163.com (Cygnus Yang) — Sat, 23 May 2026 00:00:00 +0800

2025 年 3 月，Lu 等人在 Nature 上发表了一篇引发广泛讨论的论文：The AI Scientist——第一个通过同行盲审的端到端全自动 AI 研究系统。它独立完成了从研究构思、实验设计、代码编写、结果分析到论文撰写的全过程，其生成的论文在 ICLR 2025 workshop 的盲审中获得了 6.33/10 的评分（workshop 平均分 4.87）。

这听起来像是 AI 取代研究者的序幕。但 Lu 等人自己写了这篇论文的 Limitations（局限性） 章节，其中列出的一系列结构性失败模式，恰恰为"为什么我们仍然需要人在回路中"提供了最有力的论据。

全自动的诱惑与陷阱

全自动 AI 研究系统解决了一个真实痛点：学术写作中大量重复性劳动——文献检索、格式排版、引用管理、数据验证——消耗了研究者本应用于思考的时间。如果能把这些交给 AI，研究者就能专注于定义问题、选择方法、解释数据的意义。

但 Lu 等人的实验暴露了一类更隐蔽的失败：看起来像好研究的坏研究。

一个包含幻觉实验结果的论文，读起来和真实论文一模一样。一个利用了取巧特征（而非真正学会泛化）的模型，在数值指标上可能表现优异。一个描述从未实际运行的实验的 Method 段落，措辞上与忠实记录无从区分。

传统学术质量控制的两个支柱——同行评审和可复现性——在面对这类失败时都显得力不从心。同行评审者看不到底层代码和实验日志，无法区分"声称的实验"和"实际运行的实验"。可复现性依赖于作者诚实发布数据和代码，但一个看似合理的假结果可能在被质疑之前已经进入了文献。

ARS 的答案：在每一步设置人类确认点

Academic Research Skills (ARS) 的设计前提是：人类研究者 + AI 的组合，比纯自动或纯人工都更能避开这些失败模式。

这不仅仅是"AI 干活，人类检查"的流水线。ARS 的 pipeline 设计将人类确认嵌入到了每一个关键决策点：

Stage 1（研究）：AI 提出研究问题和方法论蓝图，你确认方向
Stage 2（写作）：AI 撰写大纲和初稿，你批准大纲后才开始动笔
Stage 2.5（诚信审查）：AI 对论文执行 7 类失败模式检查，你审阅诚信报告并决定是否通过
Stage 3（同行评审）：AI 模拟多视角评审，你做出编辑决定（接受/小修/大修/退稿）
Stage 4.5（最终诚信审查）：AI 以零容忍标准重新验证，你做最终确认

关键设计在于：AI 不能跳过任何人机交互检查点。Stage 2.5 和 Stage 4.5 的诚信闸门在代码层面是不可绕过的——即使你说了"我相信 AI 的判断"，系统仍然要求你逐条审阅检查结果。

不是遮掩，而是把关

市面上有一些"AI humanizer"工具，专门用于改写 AI 生成的文本，使其看起来像是人类写的。这类工具的隐含前提是：使用 AI 辅助写作是需要隐藏的事情。

ARS 的立场完全不同。它不仅不帮你隐藏 AI 参与的事实，还提供了针对特定期刊（Nature、Science、ICLR、NeurIPS、ACL、EMNLP）的 AI 使用揭露声明生成器（/ars-disclosure），让研究者合规、诚实地报告 AI 在论文创作中的角色。

ARS v3.1 的灵感来自 aspi6246/Claude-Code-Skills-for-Academics 的三个设计原则：唯读约束（reviewer 不能修改论文原稿）、Anti-Pattern 作为一等公民设计（明确列出"不要做什么"而非仅说"要做什么"）、以及认知框架方法（教 Agent “如何思考"而非只是步骤清单）。

在风格校准（Style Calibration）方面，ARS 走了另一个方向：它从你过去的论文中学习你的写作风格——句子节奏、词汇偏好、引用整合方式——然后在写作时作为软性指引使用。但优先级系统是：学科规范（硬性）> 期刊惯例（强）> 个人风格（软性）。风格校准的目的是让 AI 的协助更贴合你的声音，而非让你隐藏 AI 的参与。

PaperOrchestra 的启发

ARS v3.3 的多个技术强化来自 PaperOrchestra（Song, Song, Pfister & Yoon, 2026, Google）：

Semantic Scholar API 验证：用程序化方式批量验证引用的存在性（标题 Levenshtein 匹配 ≥0.70、DOI 一致性检查），而非依赖 LLM 的"记忆”
反泄漏协议：知识隔离——优先使用 session 内材料，缺失内容标记为 [MATERIAL GAP] 而非让 LLM 用训练数据填补
VLM 图表验证：用视觉模型对生成的图表做 10 项闭环保真检查

这些技术的共同特征：用外部验证取代内部信任。程序化检查不相信 AI 的判断，API 调用不相信 AI 的记忆，视觉模型不相信 AI 生成的图表——每一个 AI 产出都由另一个独立的系统交叉验证。

人机协作的边界在哪里？

ARS 的设计并不回避一个重要问题：人机协作的质量取决于人类的学术判断力。如果你跳过了诚信闸门中的每一条警告，如果你在魔鬼代言人指出方法论缺陷时一律选择"忽略"，如果你在所有 checkpoint 都机械地点击"继续"——那么 ARS 最终输出的论文质量，不会比全自动系统更好。

这也是为什么 ARS 在 v3.5.0 中加入了 协作深度观察员（Collaboration Depth Observer）：一个纯咨询性的 Agent，在每次 checkpoint 时评估你与 AI 的协作模式——你是真正在思考（Zone 1）、部分依赖（Zone 2）、还是完全将认知责任外包给了 AI（Zone 3）。它从不阻止 pipeline 推进，但会将评估写入最终的 Stage 6 过程记录中。

换言之，ARS 不会阻止你做出糟糕的学术决策。但它会记录这些决策，让你在最后面对一份诚实的协作评估报告。

下一步

理解了"为什么是人机协作"之后，下一篇我们将深入剖析 Lu 等人识别的 7 类 AI 研究失败模式，看 ARS 如何在 Stage 2.5 和 Stage 4.5 的诚信闸门中逐一设防。

下一节：AI 研究的七类失败模式

参考来源：

Lu et al. (2026). Towards end-to-end automation of AI research. Nature 651, 914-919
Song, Song, Pfister & Yoon (2026). PaperOrchestra. arXiv:2604.05018
source/academic-research-skills/academic-pipeline/references/ai_research_failure_modes.md
source/academic-research-skills/shared/style_calibration_protocol.md
source/academic-research-skills/shared/anti_leakage_protocol.md

第01章研发创新与交付的动态平衡：科技团队领导者的决策框架

ruohuyang@163.com (Cygnus Yang) — Sat, 23 May 2026 00:00:00 +0800

论文配置记录

项目	内容
论文类型	管理类深度分析（HBR风格）
目标读者	技术Leader/管理者（CTO、VP Engineering、技术总监）
核心论点	创新与交付不是零和博弈，领导者需要根据团队/产品/组织所处阶段，动态调整创新投入与交付节奏，并设计相应的绩效考核机制
案例类型	公开知名案例（Google、Amazon、Netflix等）
预估字数	8000-12000字
实际字数	~20,600字符（约10,000-12,000中文字）
发布渠道	博客/微信公众号
状态	已完成

章节结构

第一章：引子 — “我们要么在交付，要么在创新"的错觉

典型技术团队困境场景开场
提出问题：为什么领导者总觉得两者只能选一个？
引出核心论点：这不是取舍，而是动态平衡

第二章：创新与交付的本质 — 不是对立，是不同阶段的侧重

定义"交付”（可预测、可衡量、短期价值）
定义"创新"（探索性、不确定性、长期价值）
四象限模型：高交付×高创新、高交付×低创新、低交付×高创新、低交付×低创新

第三章：动态平衡模型 — 三个阶段的决策框架

探索期：创新70%，交付30% — 快速试错，验证假设
成长期：创新40%，交付60% — 在交付中创新
成熟期：创新20%，交付80% — 流程优化驱动创新
每个阶段的领导者关键决策点

第四章：绩效考核的动态设计 — 让考核成为平衡的杠杆

探索期考核：学习速度 + 创新实验数量
成长期考核：交付质量 + 创新贡献双轨制
成熟期考核：交付效率为主 + 创新"安全空间"
可落地的KPI/OKR设计模板

第五章：知名案例拆解

Google 20%时间制度的成败
Amazon “Two-Pizza Teams” 的交付-创新平衡
Netflix “自由与责任"文化

第六章：常见陷阱与避坑指南

陷阱1：用成熟期KPI考核探索期团队
陷阱2：创新变成KPI后失去灵魂
陷阱3：交付压力下的"创新疲劳”

第七章：行动清单

团队阶段自测表
调整考核节奏的3步法
与上级/团队沟通的对话模板

第01章研发绩效的底层逻辑

ruohuyang@163.com (Cygnus Yang) — Sat, 23 May 2026 00:00:00 +0800

如果说研发的本质是把不确定性问题，通过探索、验证和工程实现，逐步转化为可靠能力，那么研发绩效要回答的是另一个更根本的问题：

什么样的研发工作，应该被认为是高绩效？

这件事不能简单等同于“交付多”“上线快”“没有延期”。这些当然重要，但它们只是表层结果。研发绩效真正难评价，是因为研发工作经常处在不确定性里：问题不确定、路径不确定、依赖不确定、结果滞后、风险隐藏。

所以，研发绩效的本质不是单纯评价结果，而是评价团队在不确定性中管理方向、节奏、风险和长期能力的能力。

一句话总纲

研发绩效 = 方向正确性 × 推进节奏 × 风险控制能力 × 长期能力。

这四个维度缺一不可。

方向对但没有节奏，事情会停在研究和讨论里；节奏快但方向错，越努力偏差越大；方向和节奏都有，但风险失控，短期交付会变成长期负债；当期项目成功但没有沉淀，组织下一次还会从头再来。

维度一：方向

方向关注的是：我们做的事情是不是对的。

研发团队经常会陷入一种局面：大家很忙，任务很多，迭代很满，但做完之后发现没有解决关键问题。这说明团队有执行，但方向没有被管理好。

方向管理不是一句“战略对齐”就够了，它至少包含三层判断。

1. 问题是否真实

研发开始前，要先确认问题是否真实存在，是否值得投入资源。

很多研发浪费不是发生在写代码阶段，而是发生在问题定义阶段。需求看起来明确，但背后的用户问题、业务约束、技术假设并没有说清楚。研发团队如果直接进入执行，就可能高效率地完成一个低价值甚至错误的目标。

2. 假设是否被验证

研发尤其是创新型研发，本质上是在验证假设。

这些假设可能包括：

假设类型	示例
用户假设	用户是否真的需要这个能力
技术假设	当前技术路径是否可行
成本假设	性能、成本、资源是否可接受
集成假设	是否能和现有系统稳定协同
规模假设	放大后是否仍然可靠

高绩效研发不是保证每个假设都成功，而是能快速、低成本、清晰地验证关键假设。

3. 路线是否持续校准

研发路径很少一开始就是最优解。

好的团队会在推进过程中不断用数据、实验、用户反馈和工程事实校准路线。差的团队则会把最初方案当成承诺，即使发现问题也继续硬做，直到最后集中爆雷。

因此，方向维度的绩效不是“有没有坚持原计划”，而是“有没有基于证据持续逼近正确路径”。

维度二：节奏

节奏关注的是：研发是否在合理推进。

研发管理不能只问“最后什么时候交付”，还要看中间过程是否持续收敛。因为研发风险如果只在最后暴露，代价通常最大。

节奏不是催进度。节奏管理的核心是让不确定性被阶段性消化。

1. 里程碑要表达收敛

好的里程碑不是简单写几个日期，而是定义每个阶段应该收敛什么问题。

例如：

里程碑	不好的定义	更好的定义
M1	完成 Demo	验证核心链路可跑通
M2	完成开发	关键性能指标达到目标区间
M3	准备上线	严重缺陷关闭，回滚方案验证

里程碑的价值不在于制造进度感，而在于让团队知道每个阶段必须消除哪些不确定性。

2. 推进要有反馈频率

研发工作不能长时间处在黑箱里。

如果一个项目连续几周只有“还在开发”“基本正常”“快好了”这类反馈，管理上其实是失控的。合理的节奏应该有稳定的反馈频率，包括阶段结论、风险变化、阻塞事项、下一步验证计划。

反馈不是汇报工作量，而是暴露真实状态。

3. 节奏要允许调整

研发节奏不是把最初计划机械执行到底。

如果关键假设被证伪，继续按原计划推进不是高绩效，而是浪费。真正好的节奏管理应该允许团队根据阶段结论调整范围、路线、投入和优先级。

所以，节奏维度评价的不是“是否从不延期”，而是“是否持续推进、持续收敛、及时调整”。

维度三：风险

风险关注的是：现在的交付是否在透支未来。

研发风险通常不只表现为项目失败，还会表现为系统越来越难维护、质量越来越不稳定、团队越来越依赖少数人、架构越来越难演进。

风险管理是研发绩效中最容易被低估的部分，因为它的收益往往不如交付数量直观。

1. 质量风险

质量不是测试团队最后兜底的问题，而是研发过程中的绩效问题。

如果一个团队交付很快，但严重缺陷多、线上事故多、回归成本高、问题闭环慢，那么这个团队不能被简单评价为高绩效。

高绩效研发应该能在速度和质量之间保持基本平衡。

2. 技术债风险

技术债不是完全不能有。为了验证方向、抢窗口、降低初期成本，团队可以有意识地接受一些技术债。

问题在于，技术债必须被看见、被记录、被评估、被偿还。

不可接受的是“无意识负债”：为了短期交付不断绕路，却没有任何后续治理计划。这样的绩效评价如果只奖励交付，就等于鼓励团队把成本留给未来。

3. 组织风险

研发绩效还要关注组织能力。

如果一个系统只有一个人懂，一个模块没有文档，一个流程全靠口头经验，一个平台无法被其他团队复用，这些都是组织风险。它们短期不一定影响项目结果，但会降低组织长期研发效率。

因此，沉淀、复用、文档、自动化、知识扩散，也应该进入研发绩效视野。

研发绩效不是结果主义

结果很重要，但研发绩效不能是简单结果主义。

一个项目失败，不一定说明团队低绩效；一个项目成功，也不一定说明团队高绩效。

更关键的是看过程质量：

情况	绩效判断
假设清晰、验证充分、及时止损，但结论失败	不应低绩效，甚至可能是高质量探索
结果完成，但靠堆人、绕路、隐瞒风险、透支质量	不应简单高绩效
路线不清、过程黑箱、问题最后爆发	应视为低质量研发管理
能持续发现问题、收敛路径、控制风险	应视为高绩效能力

研发管理要惩罚的不是失败，而是低质量的行为：拍脑袋、无验证、无闭环、风险不透明、重复犯错。

不同阶段的绩效逻辑不同

研发绩效不能一套规则打到底。

不同阶段的确定性不同，绩效评价的重点也应该不同。

阶段	核心矛盾	绩效重点
0->1 探索	不知道能不能做、值不值得做	验证质量、学习速度、止损能力
1->10 验证	已有方向，但还不稳定	里程碑收敛、质量控制、方案迭代
1->100 规模化	路径基本确定，要效率和稳定	交付效率、成本优化、稳定性、可复制性

0->1 阶段如果强行用规模化 KPI 管理，会压制探索；1->100 阶段如果还只讲探索，会缺少效率和纪律。

一个更完整的研发绩效公式

可以把研发绩效理解成：

研发绩效 = 有价值的问题选择
 × 有证据的方向验证
 × 可收敛的推进节奏
 × 可控的质量和技术风险
 × 可沉淀的长期能力

这个公式强调的是一套系统能力，而不是某个孤立数字。

小结

研发绩效的逻辑，不是简单问“有没有完成”，而是问：

做的事情是否真的重要；
技术和业务假设是否被验证；
推进过程是否持续收敛；
质量和长期风险是否可控；
组织能力是否因此变强。

只有把这些问题放在一起，研发绩效才不会沦为数字游戏。

第01章 Claude Code 是什么

ruohuyang@163.com (Cygnus Yang) — Fri, 22 May 2026 00:00:00 +0800

Claude Code 是 Anthropic 官方推出的 agentic coding tool，可以在终端、IDE、桌面和 Web 中读取代码库、编辑文件、运行命令，并连接开发工具完成端到端任务。

如果你想系统学习，建议直接阅读新版系列：

系列目录

学习顺序

先掌握“目标 + 范围 + 权限边界 + 验证方式”的任务写法，再学习 /code-review、/run、/verify 等 bundled skills。等日常闭环稳定后，再引入 LSP、GitHub、Figma、Linear、Sentry 等插件，把 Claude Code 接入真实工程系统。

不要一开始就堆满插件。先让 Claude Code 理解项目，再让它稳定完成小任务，最后再把重复流程沉淀成 skills 和插件配置。

参考资料：