QQs'Note

具身智能 Embodied Artificial Intelligence 不仅仅是人工智能+机器人， 而是人工智能通过物理本体与环境交互实现知行合一

智能闭环核心要素：

• 具身本体:协作机械臂 四足/轮臂复合/人形机器人 无人驾驶汽车/无人机
• 智能内核 依托大模型 世界模型 多模态技术
• 环境交互 以第一人称视角与现实物理世界进行动态交互和自适应学习

挑战

• sim-to-real gap 如硬件公差 环境误差 引起的累积误差
• 数据的稀疏性 和 昂贵的试错 如自动驾驶的意外情况
• 泛化能力
• 安全性和不可解释性

现阶段人形机器人从业公司运营路径：

• 软硬件全栈 从AI大脑到硬件躯体全自主研发 通过技术闭环提升软硬协同能力 代表：Figure AI、智元机器人
• 重硬件 核心优势在本体设计 运动控制算法 代表：宇树
• 重软件 Physical Intelligence、Field AI、银河通用

基于真实情况的路线判断

当前事实：

• 已经参与工业机器人项目
• 有机会接触真实机器人、PLC、相机
• 项目有关联 RL / VLA 库，但现阶段还没有真正落地
• 自研运动控制库包含 FK、IK、碰撞检测、RRT、SafeTrajectoryBuilder
• C++、Python、Linux 有接触，但实际熟练度较低
• 没有开发过产品级机器人/工业软件
• 当前职责还不清晰，个人更想广泛接触整个系统
• 可以接受 title 或薪资阶段性下降

结论：

当前项目不是传统上位机项目，而是有“上层智能库 + 自研运动规划/控制底座 + 硬件执行接口”的机器人系统。最短路径不是直接冲“VLA/强化学习算法工程师”，而是先把这条系统链路看懂，并把中层运动规划与落地层硬件执行转化为可证明的工程能力。

推荐定位：

Web/应用软件工程师 -> 机器人系统软件工程师 -> 具身智能落地 / 机器人平台 / 运动规划可视化工程师

学习原则：

• 每个知识点都要绑定真实对象：机器人、PLC点位、相机帧、坐标系、状态机、报警、日志
• 不只写学习笔记，要沉淀现场图、数据流图、接口表、状态转移图、最小可运行Demo
• C++、Python、Linux 不需要先追求算法竞赛式熟练，而要先达到能读SDK、写调用示例、调接口、看日志、部署Demo
• 机器视觉应提前进入主线，因为光学背景是差异化优势
• 当前项目主线是自研运动控制库和硬件封装接口，ROS2 作为开源生态参考和求职加分项，不作为现场项目主线
• RL / VLA 是上层智能能力，现阶段作为系统分层认知和后续接入方向，不作为近期主要产出
• 个人职责不清晰时，先做系统地图和调试工具，争取成为“看得懂全链路、能把问题定位清楚”的系统型工程师

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155

mindmap
  root((机器人系统软件 / 具身智能落地工程师))
    近期目标(0-3个月)
      系统分层地图
        RL VLA库位置
        任务规划入口
        运动规划链路
        硬件执行接口
      现场系统建模
        机器人品牌与控制器
        PLC点位表
        相机数据输出
        工艺状态流
        安全与报警
      工程基础补底
        Linux常用命令
        Python脚本与OpenCV
        C++基础与CMake
        调试与日志
      自研运动控制库
        自研运动控制库API
        FK IK
        碰撞检测
        RRT
        SafeTrajectoryBuilder
      硬件封装与通信
        硬件封装接口
        机器人状态与命令
        Modbus OPCUA MQTT基础
      Web优势迁移
        WebSocket实时通信
        设备状态面板
        运动规划日志回放
        ThreeJS轨迹可视化
    
    中期目标(3-6个月)
      运动规划调试工具
        IK结果展示
        碰撞检测结果
        RRT路径显示
        SafeTrajectory结果
        失败原因记录
      视觉-机器人链路
        相机标定
        手眼标定
        OpenCV检测
        图像坐标到机器人坐标
      机器人数字孪生调试台
        URDF模型加载
        FK基础
        TCP与工具坐标系
        轨迹播放
      现场Demo
        PLC状态采集
        相机帧展示
        机器人状态可视化
        报警与事件日志
    
    长期目标(6-12个月)
      产品级意识
        设备抽象
        多状态机协同
        异常恢复
        权限与安全边界
      上层智能接入
        LLM任务描述
        VLA输出理解
        结构化动作意图
        人工确认闭环
        安全门控
      系统集成能力
        Linux部署
        Docker容器化
        数据库与时序日志
        README与演示视频
      进阶方向选择
        机器人应用软件
        工业数字孪生
        机器视觉集成
        AI辅助运维
    
    核心技能层(必学)
      现场理解
        设备边界
        工艺流程
        安全停机
        异常处理
      通讯协议
        PLC点位读写
        协议转换
        实时数据流处理
      Web技术栈
        前端3D可视化
        后端API开发
        实时状态同步
      机器人理论
        自研控制接口
        FK IK
        碰撞检测
        RRT
        安全轨迹生成
        坐标变换
        运动学基础
    
    扩展技能层(选学)
      机器视觉
        标定
        检测
        视觉-控制闭环
      运动控制
        控制卡编程
        MoveIt
        轨迹规划概念
      具身智能
        RL VLA库阅读
        数据采集链路
        任务规划
        模型输出安全约束
      数据工程
        时序数据库
        数据可视化
        运行回放
      AI应用
        RAG说明书问答
        工具调用
        人工确认闭环
    
    工具链
      开发工具
        VS Code/Visual Studio
        Git版本控制
        Postman调试
      调试工具
        Wireshark抓包
        串口调试助手
        机器人仿真软件
      部署工具
        Docker/K8s
        CI/CD流水线
        云端部署
    
    学习路径
      项目驱动
        现场问题复现
        完整Demo整合
        可展示作品
      车间实践
        观察真实机器人
        记录接口和状态
        理解工艺痛点
        与电气/机械/工艺工程师交流
      开源参考
        ROS2框架
        MoveIt运动规划
        工业软件源码

机器人系统软件 / 具身智能落地学习路线

目标角色：懂机器人系统分层、能读运动规划链路、会做调试工具和可视化、能把上层智能接到安全执行链路的复合型工程师。

推荐定位：机器人系统软件 / 具身智能落地 / 运动规划可视化工程师。

本路线的主线是：

看懂 RL/VLA 上层库、自研运动规划库、硬件封装接口、PLC、相机、工作流状态之间的关系，并能把运动规划、轨迹、安全约束和现场状态用 3D 和实时 UI 表达出来。

1
2
3
4
5
6
7
8
9
10
11

阶段 1：看懂系统
RL/VLA库位置 / 自研运动控制库 / 硬件接口 / PLC点位 / 相机输出

阶段 2：做出可视化
FK/IK / 碰撞检测 / RRT路径 / SafeTrajectory / WebSocket / 事件日志

阶段 3：接近现场
机器人动作 / PLC信号 / 相机帧 / workflow编排 / 异常恢复 / 安全门控

阶段 4：形成作品
运动规划调试台 / 机器人数字孪生 / 视觉引导Demo / LLM辅助运维

应用软件工程师 -> 机器人系统软件工程师 -> 具身智能落地/机器人平台/运动规划可视化工程师

工艺流程（本质是finite state machine）数据流 应用开发
↓
运动规划 安全轨迹 硬件执行 可视化
↓
上层智能接入 系统整合 复杂系统表达

这些title尽量不要作为长期目标：

❌ 纯WPF工程师
❌ 传统MIS/后台系统开发
❌ 只写流程脚本的“工具人”
❌ 短期直接包装成VLA/强化学习/人形机器人控制算法工程师

工业软件的本质： 数据采集 状态控制 实时性是与互联网软件的最大区别

工业系统知识自测

重要欠缺

1 工业通信

可能出现：

读写竞争
UI阻塞
状态撕裂

所以真实系统里会有：

缓冲区
消息队列
Dispatcher
事件总线

学习产物：

• 一份真实或脱敏的PLC点位表
• 一个Modbus/OPC UA/MQTT模拟采集Demo
• 一个设备状态面板
• 一份异常与报警状态表

2 设备抽象

工业设备的本质是状态机, 多设备协调本质是多状态机协同

1
2
3
4
5

Idle
Running
Waiting
Error
EmergencyStop

状态之间是转移、事件、异常恢复

3 数据流思维

1
2
3
4
5
6

PLC
→ 通信层
→ 设备模型
→ 状态机
→ UI
→ 3D场景

4 工程语言和Linux

当前不是缺少“会不会刷题”，而是缺少能在工业现场稳定调试的工程熟练度。

优先补：

• Linux文件、进程、服务、日志、网络排查
• Python脚本、OpenCV、接口测试、数据处理
• C++基础、CMake、动态库、SDK调用、硬件接口封装
• Git分支、README、构建脚本、部署说明

5 自研运动规划库

这是当前项目中最有含金量的中层能力，不应只把它当作黑盒 SDK。

需要拆清楚：

• FK：关节角如何变成 TCP 位姿
• IK：目标位姿如何变成关节解，失败原因是什么
• 碰撞检测：障碍物、机器人模型、工作空间如何表示
• RRT：在哪些场景触发，路径如何采样和筛选
• SafeTrajectoryBuilder：如何把候选路径变成可执行安全轨迹
• 硬件接口：轨迹如何下发，状态如何反馈，异常如何回滚

学习产物：

• 运动控制库 API 输入输出表
• 规划失败原因表
• 轨迹生成流程图
• 一版运动规划调试/可视化工具

6 视觉和坐标系

光学背景要转化成机器人项目价值，需要补齐：

• 相机内参、畸变、外参
• 手眼标定 AX=XB
• 图像坐标、相机坐标、机器人基坐标、TCP坐标
• 检测结果如何进入机器人动作流程

7 上层智能库

RL / VLA 库目前有关联但未落地，所以近期不要把它当成主要产出。

正确读法：

• 它在系统里属于上层智能或策略层
• 需要看它输出的是自然语言、动作意图、目标位姿、轨迹片段还是策略参数
• 它的输出必须经过结构化、约束检查、安全门控和人工确认
• 真正执行仍要进入运动规划库和硬件接口

近期目标不是训练 VLA，而是理解：

1
2
3
4
5
6

LLM/VLA输出
→ 结构化任务
→ 安全检查
→ 运动规划
→ 轨迹执行
→ 状态反馈

T 型能力路线

横向广度：

1
2
3
4
5
6
7
8

RL/VLA
→ 任务规划
→ 运动规划
→ 碰撞检测
→ 安全轨迹
→ 硬件接口
→ PLC/相机
→ UI/日志/回放

纵向深度：

运动规划调试台 / SafeTrajectoryBuilder Inspector

这个纵向作品最适合当前背景：既能承接 Web3D 和工程化经验，又能深入 FK/IK、碰撞、RRT、安全轨迹和硬件状态。

12个月作品路线

0-3个月：系统链路地图与运动库接口表

目标：看懂 RL/VLA 库、自研运动控制库、硬件接口、PLC、相机之间的边界。

产物：

• 设备拓扑图
• 系统分层图
• 自研运动控制库 API 输入输出表
• PLC点位表
• 机器人状态字段表
• 相机数据输出表
• 运动规划失败原因表

面试价值：

证明自己不是只会前端页面，而是能读懂机器人系统链路和运动规划接口。

3-6个月：运动规划调试台

目标：把 FK/IK、碰撞检测、RRT、SafeTrajectoryBuilder 的结果放进一个可交互工具。

产物：

• URDF/简化模型加载
• FK/IK结果展示
• 碰撞检测结果显示
• RRT路径展示
• SafeTrajectory生成结果
• TCP和坐标系显示
• 轨迹播放和失败日志

面试价值：

证明Web3D能力能迁移到机器人运动规划和调试工具，而不是普通后台系统。

6-12个月：视觉与上层智能接入Demo

目标：完成从相机或上层智能任务到机器人安全执行的最小闭环。

产物：

• 相机标定记录
• 手眼标定流程说明
• OpenCV检测或识别
• 坐标转换
• LLM/VLA输出到结构化任务的接口说明
• 安全检查和人工确认流程
• PLC/机器人/相机/任务状态机
• Demo视频和README

面试价值：

证明光学背景、视觉算法、上层智能、运动规划和软件工程能组合成一个完整系统。

团队的生态位

系统层工程师，把整个系统串起来的人

机器人是： 机械 + 电气 + 控制 + AI + 软件 + 空间系统 的综合体。

系统设计解决的问题

• 各部分边界和状态
• 数据的生产、流经、消费、同步
• 状态机：状态 变化 异常恢复

Object3D

Object3D是three.js场景物体的基类

父子随动

物体之间的随动 如机械臂关节的逐级带动 是Object3D之间通过children嵌套完成的 父物体的任何变换（移动、旋转、缩放）都会自动、完整地传递给所有子物体。子物体会跟随父物体一起运动，同时保持自己在父物体坐标系中的相对位置和姿态

注意 子物体的所有变换属性（position, rotation, scale）都变成了相对于其父物体的局部坐标 于是会出现万向锁

四元数

万向锁是欧拉角的数学特性，解决万向锁需要使用四元数描述物体运动。每个 Object3D 都有一个 .quaternion 属性

1
2
3
4
5
6

// 1. 创建一个四元数，表示“绕 Y 轴旋转 90 度”
const q = new THREE.Quaternion();
q.setFromAxisAngle(new THREE.Vector3(0, 1, 0), Math.PI / 2);

// 2. 将这个旋转应用到物体的当前四元数上
mesh.quaternion.multiply(q);

webview 与 native 组件的通信

通信方式

• 进程间通信 postMessage 双向异步通信
• URL scheme 自定义协议的 URL（如 myapp://action?param=value）js触发 -> 由Native拦截
• JavaScript注入 Qwebchannel js代码通过 qwebchannel.js 提供的 API，连接到 QWebChannel，并根据注册时的名字 “context” 获取到 C++ 对象的代理

统一登陆

SSO / OAuth2.0 + PKCE （存目）

React Native 从bridge到fiber

AABB vs BVH

AABB（Axis-Aligned Bounding Box）是轴对齐包围盒。
BVH（Bounding Volume Hierarchy）是包围体层次结构。

可以先用 Three.js 中熟悉的概念理解：

• Box3：一个物体或一组三角面的 AABB
• Mesh：场景里的可渲染对象
• BufferGeometry：顶点、索引、法线、UV 等几何数据
• Raycaster：从鼠标、相机或控制器发出一条射线，寻找命中的对象或三角面

如果一个模型只有几十个三角面，射线或者碰撞检测可以直接逐个三角形测试。但当模型来自 CAD、glTF、机器人 URDF mesh，或者场景里有很多设备、障碍物、工件时，逐三角面遍历会很快变成性能问题。

BVH 的核心价值就是：先用便宜的包围盒测试排除大部分不可能命中的区域，只在少量候选区域里做昂贵的精确测试。

从 Three.js 的 Raycaster 理解

Three.js 的 Raycaster 常用于鼠标拾取：

1
2
3
4
5
6
7
8

const raycaster = new THREE.Raycaster();
const mouse = new THREE.Vector2();

mouse.x = (event.clientX / window.innerWidth) * 2 - 1;
mouse.y = -(event.clientY / window.innerHeight) * 2 + 1;

raycaster.setFromCamera(mouse, camera);
const intersects = raycaster.intersectObject(mesh);

这个过程可以拆成三步：

1. 屏幕坐标转成 NDC 坐标。
2. 从相机位置向场景里打一条 ray。
3. 判断 ray 和对象、三角面是否相交。

Three.js 默认的 Mesh.raycast 已经会做一些早期排除，例如先用 boundingSphere，再用 boundingBox 判断射线是否可能碰到 mesh。通过这些粗测试之后，才进入三角面级别的相交测试。

问题在于：一个复杂 mesh 通过了包围盒测试以后，内部仍然可能有成千上万个三角形。如果每次鼠标移动、点击、路径采样、光线追踪都要遍历这些三角形，开销会非常高。

BVH 就是在 mesh 内部继续建立一棵树：

1
2
3
4
5
6
7

root AABB
├── left child AABB
│   ├── leaf: triangles 0-127
│   └── leaf: triangles 128-255
└── right child AABB
    ├── leaf: triangles 256-383
    └── leaf: triangles 384-511

查询时，如果 ray 连 left child AABB 都没有碰到，那么这个节点下面所有三角形都不用再测。

BVH 的基本构建方式

BVH 不是一种渲染效果，而是一种空间加速结构。

构建过程可以粗略理解为：

1. 给每个 primitive 建立包围盒。primitive 可以是三角面、点、线段、mesh 或机器人 link。
2. 把一组 primitive 的包围盒合并成父级包围盒。
3. 按某个策略拆分成左右子集，例如最长轴中位数切分，或 SAH（Surface Area Heuristic）启发式切分。
4. 递归构建，直到叶子节点里的 primitive 数量足够少。

BVH 的查询性能不保证严格是 O(log n)，因为模型分布、树质量、射线路径都会影响遍历量。但在实际图形学和物理查询里，它通常能把“每次都扫所有三角形”的 O(n)，变成“只检查少量候选节点和叶子”的过程。

在光线追踪中的应用

光线追踪的计算量大，是因为每个像素可能不止一条光线：

• primary ray：从相机打到场景，找第一个命中点
• shadow ray：从命中点打向光源，判断是否被遮挡
• reflection ray：反射方向继续追踪
• refraction ray：折射方向继续追踪
• GI / AO sample：为了间接光照和环境遮蔽继续采样

如果场景有 100 万个三角形，一条 ray 逐个测试三角形就几乎不可用。BVH 在这里通常是光线追踪渲染器的核心数据结构：

1
2
3
4
5
6
7
8
9

for each ray:
  traverse BVH from root
  if ray misses node AABB:
    skip subtree
  if ray hits node AABB:
    visit children
  if leaf:
    test ray-triangle
  return nearest hit

不同 ray 的需求也不一样：

• 找最近表面：需要维护当前最近的 t，越近的命中越优先。
• 阴影判断：只要找到任意遮挡物就可以提前结束，称为 any-hit。
• 透明材质：可能不能简单 early-out，需要继续追踪或累计透射。

BVH 不负责材质、BRDF、采样降噪这些渲染问题，它只回答一个底层问题：这条 ray 最可能和哪些几何体相交？

在碰撞检测中的应用

碰撞检测一般分两层：

• broad phase：快速找出可能碰撞的对象对。
• narrow phase：对候选对象做更精确的几何检测。

BVH 可以同时参与这两层。

在 broad phase 中，可以把整个场景、设备、障碍物、机器人 link 都看成带包围盒的对象。先判断对象级 AABB 是否相交，不相交就直接排除。

在 narrow phase 中，如果两个复杂 mesh 的包围盒相交，可以继续进入 mesh 内部 BVH，做 triangle-triangle、sphere-triangle、capsule-triangle、ray-triangle 等更精确的检测。

对机器人可视化和数字孪生来说，这个点很重要。一个六轴机械臂的模型通常由多个 link 组成，每个 link 可以有自己的碰撞几何：

1
2
3
4
5
6
7

robot base
├── link1 BVH
├── link2 BVH
├── link3 BVH
├── link4 BVH
├── link5 BVH
└── link6 BVH

关节角变化时，link 的刚体变换会变化，但 link 自身 mesh 的局部几何没有变。工程上可以把 BVH 建在 link 的局部坐标系中，查询时把 ray、sphere、capsule 或障碍物变换到对应 link 的局部坐标系，再做 BVH 查询。这样通常不需要每帧重建 BVH。

这和你后续做机器人轨迹可视化、RRT、SafeTrajectory、碰撞提示是同一类能力：

• 轨迹上的每个采样点是否碰到障碍物
• TCP 或夹爪路径是否穿过禁入区
• link 是否和工作台、相机支架、安全围栏相交
• 鼠标点击模型时是否需要快速拿到命中的三角面、法线、UV

Three.js 中的工程用法

Three.js 自身提供了 Raycaster、Box3、Sphere、Triangle 等基础能力。复杂 mesh 的 BVH 加速通常会使用第三方库，例如 three-mesh-bvh。

典型用法是给 BufferGeometry 建立 bounds tree，并让 Mesh.raycast 使用加速版本：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

import * as THREE from 'three';
import {
  computeBoundsTree,
  disposeBoundsTree,
  acceleratedRaycast,
} from 'three-mesh-bvh';

THREE.BufferGeometry.prototype.computeBoundsTree = computeBoundsTree;
THREE.BufferGeometry.prototype.disposeBoundsTree = disposeBoundsTree;
THREE.Mesh.prototype.raycast = acceleratedRaycast;

const geometry = new THREE.TorusKnotGeometry(10, 3, 400, 100);
const mesh = new THREE.Mesh(geometry, material);

geometry.computeBoundsTree();

const raycaster = new THREE.Raycaster();
raycaster.firstHitOnly = true;
const hit = raycaster.intersectObject(mesh);

对普通交互来说，firstHitOnly = true 很实用。因为很多场景只关心最近命中的对象或面，不关心射线穿过模型后面的所有命中点。

如果直接操作 BVH，要注意坐标系。geometry 的 BVH 通常在 mesh 的 local space 中，raycaster 的 ray 通常在 world space 中。因此查询前要做坐标变换：

1
2
3
4
5
6
7
8

const inverse = new THREE.Matrix4().copy(mesh.matrixWorld).invert();
const localRay = raycaster.ray.clone().applyMatrix4(inverse);

const hit = geometry.boundsTree.raycastFirst(localRay);

if (hit) {
  hit.point.applyMatrix4(mesh.matrixWorld);
}

这和机器人里的 frame 思维是一致的：world、base、link、TCP、camera frame 之间必须说清楚，否则碰撞检测和拾取结果会看起来“差一点”，实际是坐标系错了。

静态、动态和变形模型

BVH 不是免费午餐。

适合 BVH 的情况：

• 大型静态 mesh
• CAD、建筑、工厂、机器人 link 这类几何稳定的模型
• 高频 raycast、hover、选择、刷选、测距
• 需要大量路径采样的碰撞检测
• 光线追踪或光照烘焙

需要谨慎的情况：

• 顶点每帧都变化的布料、软体、水面
• SkinnedMesh 骨骼动画导致表面持续变形
• 场景对象极少，构建 BVH 的成本大于查询收益
• 只做对象级碰撞，不需要三角面精度

刚体运动一般比较友好，因为可以保留局部 BVH，只更新对象的 world matrix。真正麻烦的是 geometry 顶点发生变化，这时要么 refit BVH，要么重建 BVH，要么降低碰撞精度。

和 Octree、KD-Tree 的区别

几种空间结构经常一起出现：

BVH 的优势是工程适应性强。它不要求空间均匀，也不要求对象固定在规则格子里。对三角网格、机器人 link、CAD 模型这类“不规则但几何稳定”的对象很自然。

学习价值

BVH 对 Web3D 和机器人软件的连接意义很强。

从 Three.js 角度，它解释了为什么复杂模型的拾取、喷涂、测距、框选不能永远依赖朴素遍历。

从图形学角度，它是光线追踪能跑起来的底层结构之一。没有 BVH 这类加速结构，ray tracing 很容易停留在公式层面。

从机器人角度，它是碰撞检测、轨迹安全检查、数字孪生交互的重要基础。真正有面试价值的不是只知道 BVH 的定义，而是能讲清楚：

• BVH 建在什么坐标系里
• 查询对象是什么，ray、sphere、capsule 还是 mesh
• 静态模型如何复用 BVH
• 运动 link 如何通过矩阵变换参与查询
• broad phase 和 narrow phase 如何分层
• 什么时候该用 BVH，什么时候用简单 AABB 已经足够

References

• Three.js Raycaster
• Three.js Box3
• three-mesh-bvh

1

irm https://claude.ai/install.ps1 | iex

或需手动添加路径C:\Users\qqqst.local\bin到PATH

当您给 Claude 一个任务时，它会经历三个阶段：收集上下文、采取行动和验证结果。这些阶段相互融合。Claude 始终使用工具，无论是搜索文件以了解您的代码、编辑以进行更改，还是运行测试以检查其工作。

1
2
3

claude
claude --plan "Refactor the authentication module to use OAuth2"

提供具体上下文

• 使用 @ 引用文件，而不是描述代码的位置。Claude 在响应前读取文件。
• 直接粘贴图像。复制/粘贴或拖放图像到提示中。
• 提供 URL 用于文档和 API 参考。使用 /permissions 来允许列表经常使用的域。
• 管道数据 通过运行 cat error.log | claude 直接发送文件内容。
• 让 Claude 获取它需要的东西。告诉 Claude 使用 Bash 命令、MCP 工具或通过读取文件来自己拉取上下文。

slash命令

• init
• ask
• plan 分析需求并制定详细步骤计划 绝不改动任何代码 直到你审查并批准它的计划 plan后按Ctrl+G在临时的markdown文件中修改计划细节
• compact
• reset
• powerup

四元数是(i, j, k)和 w 前者是当前轴 w是偏转角度

解决了欧拉角描述姿态变换时的万向锁问题

所谓万向锁 是指当运动轴相互依赖时(如三轴云台、三轴机械臂)第二个轴转到90度位置时 牵动了第三个轴运动平面与第一个轴一致，导致整个体系的运转失去了一个自由度。

Activiz 是 VTK 的 .net绑定版本的惯用名称

ActiViz 是一个用于三维可视化和数据处理的 .NET 库。它展示了 C++ 可视化工具包（VTK） 的 API，可用于 C# 或 VB。

ActiViz 可与许多现有的 C# 应用程序和框架接口，包括 WindowsForm、Windows Presentation Foundation（WPF）、Avalonia 或 Unity 软件。这使得先进算法和渲染技术能够无缝且快速地集成到各种环境中

框架

App Router

SSG & SSR

docker compose 部署

1
2
3
4
5
6

# clone repository
git clone https://github.com/langgenius/dify.git
cd dify/docker
# copy env
cp .env.example .env
docker compose up -d

tavily.com 联网搜索

多文件知识库 做筛选 ->