# UG/NX 全版本 AI 外挂 —— 总规划与范例调研 v1.0

> 编制日期：2026-10-16　适用机器：本机实测（NX 2212 + NX 2412 双版本共存）
> 配套文档：`01_资产盘点与优化评估.md`、`02_TraeCN施工任务书.md`、`../NX多版本外部程序技术可行性报告.md`

---

## 0. 一页结论

**产品定位**：NX Copilot —— 一个**独立安装、自动识别本机全部 NX 版本、可自由切换、断网可用**的 AI 自动编程软件；NX 内只留一层"极薄桥接"，用户感知上就是一个独立软件而非插件。

### 三条基于真机核验的硬结论

| # | 结论 | 证据 |
|---|---|---|
| 1 | **"非插件"必须分级实现，不能一刀切。** 纯外部 EXE 无法 attach 到用户已打开的 NX 会话，读不到"当前部件"、做不了菜单；要实时交互，必须有代码跑在 NX 进程内。 | 技术可行性报告第二/三节；官方 internal/external/batch/remote 四模式差异 |
| 2 | **多版本的真难点是 API 绑定，不是版本探测。** 本机 `NXBIN\managed\NXOpen.dll` 分别是 `2212.0.0.0` 与 `2412.0.0.0` 两个独立程序集 → 桥接 DLL **必须按 NX 版本各编一份**；宿主机（.NET Framework 4.8 + `csc.exe`）已具备编译能力，不需要 Visual Studio。 | 本机实测：`E:\Program Files\Siemens\NX2212\NXBIN\managed\`、`NX2412\NXBIN\managed\` |
| 3 | **NX 的 Python 是"以 DLL 形式内嵌"的，Python journal 完全可用**（不需要独立 `python.exe`）。真正的多版本难点仍是编译型 API 绑定。 | 本机实测：`NX2212\NXBIN\python310.dll`(3.10.6)、`NX2412\NXBIN\python311.dll`(3.11.9)、`NX2412\NXBIN\nxpythonldr.dll`，且 `NX2412\NXBIN\python\` 下有完整的 `NXOpen.pyd` / `NXOpen_*.pyd` |

### 一句话战略

> **不做第六个"星空外挂"（拼功能数量），做第一个"会自己变强的 NX 编程助手"（拼经验资产）。**
> 功能面用"批处理工具 + 电极/模具"先活下去，护城河押在"**人工修正 → 结构化经验 → 资产库 → 灰度发布**"这条数据闭环上。

---

## 1. 需求拆解与硬约束

| 你的需求 | 真实技术含义 | 满足方式 | 主要风险 |
|---|---|---|---|
| 非插件 | 不改 NX 安装目录、不写 `custom_dirs.dat`、不做 .men/.tbr 菜单侵入 | 独立 EXE 主控 + 进程级环境变量 + 用户级定制目录（`UGII_USER_DIR`） | 完全"零侵入"则拿不到实时数据 |
| 全版本 | NX4 ~ NX2606 跨度 20 年，API/CLR/签名全变 | **双轨**：老版本走 journal 脚本，新版本走薄桥接 DLL；脚本由**目标版本自带解释器**执行 | 逐版本编译与适配的持续维护成本 |
| 自动识别 | 本机可能装 N 个版本、装在任意盘 | 三源交叉探测（注册表 Siemens 键 + Uninstall 项 + 可执行文件校验） | 绿色版/免安装版探测不到 |
| 自由切换 | 同一台机器按项目切版本 | 每次调用**构造干净子进程环境**（`UGII_BASE_DIR`/`PATH` 独立），绝不动全局环境变量 | 全局 `PATH` 污染会导致加载错版本 DLL 而崩溃 |
| 断网可用 | 车间内网常无外网 | Local-first：本地记忆 + 本地小模型 + 本地规则库为主，云端只做增量同步 | 离线时 AI 能力降级，需要明确降级策略 |
| 长期自我优化 | 不是"记住聊天记录"，是"沉淀可复用资产" | 技能库（脚本）+ 规则库（playbook）+ 流程库，版本化 + 灰度 + 可回滚 | 无审核的自动写入会永久污染 |
| 云端记忆 | 跨设备、跨用户复利 | 本地为唯一事实来源，云端做**脱敏知识原子**的归并与分发 | **合规与数据出境**；以及下面这个已发现的严重问题 ↓ |

> ⚠️ **已发现的头号风险（必须先修）**：现有的 `UG连云端_oneclick` 是一个**明文 HTTP + 硬编码共享 token + 任意命令执行**的远程控制通道（云端下发 cmd 字符串，本机 `cmd /c` 直接执行），文件夹里还放着**未加密的 SSH 私钥**。这套东西自己用都很危险，**绝对不能装到客户机器上**。详见 `01_资产盘点与优化评估.md` 的云侧章节与 `02_TraeCN施工任务书.md` 的 P0-4。

---

## 2. 范例调研结论

### 2.1 国产商业 NX 外挂（对手盘点）

| 产品 | 版本策略 | 集成形态 | 价格量级 | 可学到的 |
|---|---|---|---|---|
| **星空外挂**（青岛星宫） | 官网称 NX4.0+；实则按档分包：NX1847+/NX12/NX11/NX10.0.3.5/NX9/NX8.5/NX4-8 | 写自定义目录 `D:\QuickCAM` + 改 `custom_dirs.dat` 追加版本子目录 + 每版本一份 `config.ini`；支持 GRX/DLL/exe 混合挂载 | 个人版 980/10年（狗）或 240/年（云锁）；企业版 50000/2许可 | 一个安装包对外、**内部按版本分叉**；升级 NX 后必须逐版本补丁（NX2506→2512→2606 各一条更新记录） |
| **模圣软件**（成都） | NX10.0+ | 标准 `startup` + `application` 双目录，DLL 由 NX 启动加载（社区报错截图给了 `libmsraf_x64.dll` / `_new.dll` 两份二进制） | 798 元 / 12 年（硬件锁） | `_x64` 与 `_new` 双份二进制 = 按位数与版本维护多套产物的工业级形态 |
| **优品 UPin** | NX4 ~ NX1953 极宽 | 菜单式外挂 | 免费版引流 + 正式版 | 极宽版本跨度的代价是**免注册版全网流传**，商业模式被破解击穿 |
| **益模科技** | 未公开 | **"NX 后台"自动编程**：前端备数据 → 后端自动获取 → 生成机床程式 → 驱动机床；对接 MES/ERP | 订阅制 | **这正是"外部 EXE + NX 批处理"路线的商业先例**，也是最贴近你"非插件"设想的对标 |
| **模德宝** | — | 模云平台 + MES；专利《基于 UGNX 模型分析的电极形体自动识别的实现方法》CN114742850B；行业标准《模具零件特征信息颜色识别规范》 | 平台级 | 走"特征识别 → 后端系统"路线，NX 只是数据源 |
| **燕秀外挂** | NX8.0-2412 + AutoCAD/中望/浩辰 | USB 狗；个人版"NX 投影 + CAD 标注"，企业版才有"纯 UG 标注" | — | **跨 CAD 用"接力"方案落地**：NX 出投影、CAD 出图，规避 NX 侧 DOM 限制 |
| **浩强工具** | — | **GRIP（.grx）** 而非 NX Open | — | 作者自述理由值得深思：GRIP"普通工程师 10 分钟学会"，"流行外挂里 grx 占很大一部分"——**低门槛脚本语言是这个市场的真实需求** |
| **CAP 工具箱** | NX6.0+ | 周边工具：一键装 NX/VT、许可证配置、外挂管理、缩略图修复 | — | 做"外挂的管理器"本身也是生意 |

**关键判断**：这八家**没有一家解决"多版本自动识别 + 自由切换"**——它们全都要求用户在安装时手动选版本、手动改配置、升级后重装。**这是你最直接、最容易讲清楚的差异化。**

### 2.2 你手上的实物参照：草莓 CM 3AXIS 自动编程软件

`C:\Users\Administrator\Desktop\UG插件制作\草莓(CM)3AXIS自动编程软件3.6至2030\CMNXCam\` 是一份现成的商业外挂成品，很有参考价值：

- 目录结构：`Bmp` / `Config` / `Data` / `Nxenv` / **`Nxversion`** / `Postprocessor` / `ProcessingPlan` / `Template`
- 为 **NX10 / NX12 / NX19 / NX22 / NX23 / NX24 / NX25** 各提供一份安装说明
- 即"**一套产品 + 每版本一个环境/版本目录**"的做法——和星空/模圣同构，属于**手动分版本**，而不是自动探测。

> 结论：整个行业都在"用工程手段硬扛多版本"。你把它做成**自动识别 + 自动切换**，就是一次降维。

### 2.3 国际侧与 AI CAM 现状

| 产品 | 机理 | 定性 |
|---|---|---|
| **CloudNC CAM Assist**（NX 版） | 几何计算 + 混合 AI：识别可加工特征 → 在机床/刀具约束下枚举加工方法 → 统计学习选组合；另有 Cutting Parameters AI 按物理模型给进给转速 | **混合型**，是目前最接近"AI 自动编程"的商用产品；支持 NX 2306/2312/2406/2412/2506；**明确是 NX 内插件**；自认只做 3 轴与 3+2 轴 |
| **Siemens NX FBM** | 规则库驱动（原 MKE 的规则库并入 FBM） | **规则模板**，官方能力，不是 AI |
| **hyperMILL / TEBIS** | 特征识别 + 工艺规则/流程包 | **规则模板为主**；TEBIS 绕过 NX 兼容问题的方法是"自成体系 + CAD 接口" |
| **国产（益模/精雕/CAXA/中望）** | 特定零件族的固定套路 + 二次开发 | **规则模板 + 少量算法推荐** |

**结论**：**至今没有"纯学习型端到端出刀路"的商用产品**。AI 在 CAM 的真实落点是"特征枚举 → 约束下选组合 → 参数模型"三段式，人工确认必不可少。

### 2.4 AI 编程的可复用技术栈

| 层 | 可复用 | 说明 |
|---|---|---|
| 特征识别 | **AAGNet**（gAAG 几何属性邻接图，MIT）、**BRepNet**（Autodesk）、UV-Net | 把 B-Rep 喂给 GNN 的最成熟范式；用于补足 NX 原生 AFR 在非标特征上的短板 |
| 数据 | Fusion 360 Gallery（8,625 条真实设计序列）、ABC Dataset、MFCAD++ | 训练特征识别/序列生成的公开数据 |
| 刀具标准 | **ISO 13399 / GTC（Generic Tool Catalog）格式与映射规范** | 刀具库标准化的现成答案，打通"刀具库 ↔ CAM ↔ 测量" |
| 参数来源 | Sandvik Coromant 切削数据（无公开 API）、MachiningCloud（商业授权） | 参数库要自建，或买授权 |
| LLM 生成代码 | `lyq5123/nx-skills`（NX 参数化建模 agent skill，最贴近本课题） | 参考其"skill 化"封装方式 |
| **不要做** | LLM 端到端直接生成可用刀路/G 代码 | 学术上仅有"正确性由构造保证"的雏形，工业不可用 |

### 2.5 长期记忆与自我进化（这是护城河所在）

| 项目 | 定位 | License | 结论 |
|---|---|---|---|
| Mem0 | 记忆抽取即服务 | Apache-2.0 | 做**抽取器**可以，**不要当多租户底座** |
| Letta/MemGPT | 有状态 Agent 运行时 | Apache-2.0 | 单租户，做平台过重 |
| **Graphiti/Zep** | 双时态知识图谱 | Apache-2.0 | 工程质量最高，适合"规则随版本失效"这类关系型知识，作为**旁路** |
| Cognee | 图谱+向量统一，可全本地 | Apache-2.0 | 全私有化部署候选 |
| **LangMem** | LangGraph 记忆 SDK | MIT | **落地最省事**，namespace 天然多租户 |
| Voyager | 技能库（可执行代码）+ 自动课程 | — | **核心范式**：技能以代码入库、按 embedding 检索、成功才入库 |
| Reflexion / Self-Refine | 失败反思 | — | 教训：**无验证器的自评会放大错误**，必须配客观校验 |
| ExpeL / AWM | 经验 insight / 工作流模板 | — | 经验→可复用 workflow |
| **ACE**（Agentic Context Engineering） | 把上下文当"演化中的 playbook"，生成器/反思器/**策展器**三角色增量更新 | Apache-2.0 | **最贴合**：策展器 = 你的服务端离线归并任务 |

**三库分治**（务必按这个建模，不要混成一个向量库）：
1. **技能库** — 可执行脚本/宏，带前置条件、成功率、适用版本区间
2. **规则库 / playbook** — 自然语言工艺规范，版本化，带 `superseded_by` 链
3. **流程库** — 工序编排模板（workflow）

**防"越学越蠢"**：固定金标回归集（200~500 条真实任务）+ 负向指标（token、延迟、过期规则引用率、冲突数），每次发布必跑；任何自动写入必须**可溯源、可灰度、可一键回滚**。

### 2.6 从范例中提炼的十条结论

1. 多版本的事实解法 = **一套源码 + 按版本多份二进制 + 运行时按版本加载**；对外只露一个安装包。
2. **注入式插件是行业主流**，因为业务要操作 NX 内存对象；但**"外部 EXE + NX 后台"也有商业先例（益模）**，且更贴合你的"非插件"诉求。
3. `startup` + `application` 双目录 + `custom_dirs.dat`/`UGII_USER_DIR` 是注册的通用手法——**但你要尽量避免写它**，改用"用户级目录 + 启动时注入"。
4. 行业里**没人做好自动识别与自由切换**，这就是切入点。
5. 商业模式几乎统一为**硬件加密狗 + 云锁**，同时**破解泛滥**（免注册版全网流传）——定价与防盗必须一开始就想清楚。
6. AI CAM 的真实形态是**规则/模板兜底 + AI 做选择与编排**，不是端到端。
7. **识别 ≠ 程序**：选刀、参数、策略、后处理每一环都吃工时，这正是 AI 的用武之地。
8. 刀具与参数要按 **ISO 13399 / GTC** 标准化建模，否则经验无法跨机床迁移。
9. 记忆的价值在于**资产化**，上下文塞得越多越蠢。
10. **图纸本体永不出厂**，云端只收抽象化知识原子——这既是合规要求，也是销售话术。

---

## 3. 技术路线决策

### 3.1 三种集成架构对比

| 维度 | **A：外部 EXE + Journal（run_journal 驱动）** | B：外部 EXE + 每版本适配程序集（external 模式） | **C：极薄桥接 DLL（NX 进程内）+ 外部主控** |
|---|---|---|---|
| 实时交互 | ❌ | ❌ | ✅ |
| 读"当前打开部件" | ❌ | ❌（只能开自己的件） | ✅ |
| NX 内菜单/按钮 | ❌ | ❌ | ✅（可选，非必需） |
| 拿到模型/刀路数据 | ✅（批处理过程内，快照级） | ✅（进程内 API 全量） | ✅（实时） |
| 多版本成本 | **低**（脚本由目标版本解释器解析） | 高（每版本编译 + CLR 分叉 + 签名） | 中（DLL 需每版本编译，但很薄） |
| 难度 | 低–中 | 中–高 | 中 |
| 改 NX 安装目录 | 不需要 | 不需要 | 不需要 |

### 3.2 ✅ 选定方案：**A 为骨干 + C 为增强，B 暂不做**

```
┌────────────────────────────────────────────────────────────┐
│  主控（独立 EXE / 桌面软件，用户眼里的"这个软件"）          │
│  · 版本管理器（探测 / 选择 / 环境构造）                     │
│  · 任务编排（批处理队列、断点续跑）                         │
│  · 资产库（技能/规则/流程）+ 本地记忆                       │
│  · 云同步（脱敏知识原子）                                   │
└───────┬──────────────────────────────┬─────────────────────┘
        │ A：子进程 + 干净环境          │ C：文件信箱 IPC
        │ run_journal.exe <journal.cs>  │ inbox/outbox + status.json
        ▼                               ▼
┌──────────────────────┐   ┌──────────────────────────────────┐
│ 目标版本 NX 批处理    │   │ 目标版本 NX 交互会话              │
│ (无 GUI，吃许可)      │   │ + NxBridge_<ver>.dll（极薄）      │
│ 跑 C#/VB journal      │   │ 只做：收命令/读当前部件/执行/回报 │
└──────────────────────┘   └──────────────────────────────────┘
```

**为什么 C 里的 DLL 必须"极薄"**：它绑定在 NX 进程内、每个 NX 版本要单独编译、NX1926+ 还有签名校验。**把业务逻辑放在 DLL 里 = 每个版本都要重测全部功能**；把 DLL 做成"手和眼"（收发消息、读写当前部件、执行脚本），业务逻辑全放外部主控，多版本的维护成本就从 O(功能数 × 版本数) 降到 O(版本数)。**这是整个架构最重要的一条设计原则。**

### 3.3 版本自动识别（已在真机验证可行）

三源交叉，任何一个命中即可，互相校验：

| 来源 | 本机实测结果 | 说明 |
|---|---|---|
| ① `HKLM\SOFTWARE\Siemens\NX <ver>` | `NX 2212`、`NX 2412` 两个键，含 `INSTALLDIR`、`UGII_BASE_DIR`、`LICENSESERVER`、`LANGUAGE`；NX2412 另有 `NXOPEN_INSTALL=NO` | **首选**，一条注册表遍历就拿到 |
| ② `Uninstall` 项 | `Siemens NX 2212 / 22.12.1700.00000`、`Siemens NX 2412 / 24.12.7002.00005`，含 `InstallLocation` | 补充精确版本号 |
| ③ 目录扫描 + 可执行文件校验 | `E:\Program Files\Siemens\NX2212`、`NX2412`；每目录下 `NXBIN\run_journal.exe`(2212.1700/2412.5501)、`NXBIN\ugraf.exe`、`NXBIN\ug_inspect.exe` 全部存在 | 兜底 + **校验安装是否完整** |

补充要点：
- 安装根目录**不一定是** `%ProgramFiles%`（本机在 `E:\`）→ 必须扫注册表给出的路径，而非硬扫 C 盘。
- 若注册表 `NXOPEN_INSTALL=NO`（本机就是），说明**未装 NX Open 开发包**——不影响用 `NXBIN\managed` 里的程序集编译插件，但**影响 C++ 开发与官方 Examples**。
- 探测结果必须包含"**能力位**"：是否有 `run_journal.exe`、是否有 `NXBIN\managed`、是否有内置 Python、CLR 版本（≤24xx 为 .NET Framework 4.x，2506 起官方 KB 给的是 .NET 8）——这决定该版本走哪条执行路径。

### 3.4 执行路径分派（版本能力决定走哪条路）

| NX 版本 | 执行路径 | 说明 |
|---|---|---|
| NX 4 ~ NX 10 | GRIP / 老式 journal（VB）| 无 `NXBIN\run_journal`（NX11 起才移到 NXBIN），需按老路径 `UGII\run_journal.exe` 处理 |
| NX 11 ~ 24xx | **Python journal 优先**（目标版本自带解释器，版本无关性最好）+ C#/VB journal 兜底 + 薄桥接 DLL（.NET Framework 4.x） | 本机 2212 = Python 3.10.6、2412 = Python 3.11.9；API 由目标版本自带的 `NXOpen.pyd` 提供 |
| NX 2506+ | C# journal（.NET 8）+ 薄桥接 DLL（.NET 8） | 官方 KB 明确 .NET 8 + VS2022 工程创建方式 |

### 3.5 许可与合规红线

- 外部驱动本质是"起一个 NX"，**batch 运行同样占用许可**；纯 journal 录制/回放**不需要 NX Open Author 许可**，但编译型 NX Open（internal/external）与 remoting **需要 Author 许可**。
- **不得重分发** NX 自带的 `NXOpen*.dll` / `libufun` 等；终端用户自备 NX 与许可。
- **不得帮用户绕过 NX 授权**（星空外挂用"不支持正版 NX"区分版本，这是它的原罪，也是你走正版路线的卖点）。
- 云端面向公众提供生成式 AI 服务需履行备案义务；个人信息处理遵循最小必要 + 单独同意 + 可删除。

---

## 4. 目标架构（产品形态）

```
┌─ 桌面主控（独立软件，可离线）───────────────────────────────┐
│ ① 版本中心：探测 / 列表 / 切换 / 环境构造 / 能力位          │
│ ② 任务中心：批处理队列、进度、断点续跑、失败重试、日志      │
│ ③ 资产中心：技能库 / 规则库 / 流程库（本地优先）             │
│ ④ 记忆中心：本地向量库 + 情景记忆 + 反馈采集                │
│ ⑤ AI 编排：意图理解 → 选技能/规则 → 生成脚本 → 仿真校验     │
│ ⑥ 脱敏守卫：上传前 PII/图号/尺寸过滤，用户可预览            │
└──────┬───────────────────────────┬──────────────────────────┘
       │ A 路径                     │ C 路径
       ▼                            ▼
  run_journal 批处理          NxBridge_<ver>.dll（极薄）
       │                            │
       └──────────┬─────────────────┘
                  ▼
        ┌───────────────────────┐
        │ 云端知识层（自建境内） │
        │ 网关鉴权/租户隔离      │
        │ Postgres + pgvector    │
        │ 离线归并 + ACE 策展    │
        │ 版本化 + 灰度 + 回滚   │
        │ 金标回归集 CI          │
        └───────────┬───────────┘
                    ▼
        ┌───────────────────────┐
        │ 模型层：DeepSeek/千问  │
        │ （境内直连 + 前缀缓存）│
        │ 本地小模型做意图/脱敏  │
        └───────────────────────┘
```

---

## 5. AI 自动编程能力路线（L0 → L4）

| 等级 | 能力 | 人工角色 | 技术依赖 | 商用可行性 |
|---|---|---|---|---|
| **L0** | 模板/规则批量执行（批量出图、批量后处理、程序单、BOM） | 全程操作 | Journal 脚本 | ✅ 立刻可卖 |
| **L1** | 规则驱动生成工序骨架与选刀建议 | 逐条确认 | 规则库 + 刀具库(ISO 13399) | ✅ 半年内 |
| **L2** | 学习型推荐（选刀/参数/策略排序） | 确认或改 | 历史修正数据 + 分类/排序模型 | ✅ 一年内 |
| **L3** | LLM 工序编排与自然语言交互（"先粗后精，φ10 立铣开粗" → 生成脚本） | 审核 + 仿真验收 | L2 + RAG + 脚本生成 + 仿真校验 | ⚠️ 需严格护栏 |
| **L4** | 全自动闭环（无人值守出程序并自检） | 抽检 | L3 + 撞刀/过切自动校验 | ❌ 现阶段不承诺 |

**铁律**：任何 AI 输出**必须过 NX 仿真/过切检查**才能交付；**人工确认闭环是产品的一部分，不是缺陷**——它同时是数据来源。

**数据闭环（护城河）**：每一次人工修正记录为三元组
`(特征上下文, 系统建议, 人工最终值)` → 脱敏 → 云端归并 → 训练/检索资产 → 灰度发布。

---

## 6. 云端记忆与自我进化（含安全重做要求）

### 6.1 三层记忆
| 层 | 内容 | 存储 | 同步 |
|---|---|---|---|
| 情景记忆 | 这次会话做了什么、结果如何 | 本地 SQLite | 摘要上行 |
| 语义记忆 | 抽象化的规则/经验原子 | 本地向量库 + 云端 pgvector | 增量双向 |
| 程序性记忆 | **技能脚本/宏**（带前置条件与成功率） | 本地文件 + 云端版本库 | 版本号拉取 |

### 6.2 云端必须做到（当前完全缺失）
- TLS + **每设备独立密钥**（当前是共享 token + 明文 HTTP，必须废弃）
- 设备注册 / 吊销 / 心跳 / 审计日志
- **命令白名单 + 签名任务单**（当前是任意 `cmd /c`，等于给云端开了 RCE 后门）
- 多租户隔离（Postgres RLS）
- 离线归并作业 + 灰度发布 + 一键回滚 + 金标回归 CI
- **不上传图纸本体**，只上传抽象化知识原子

### 6.3 成本量级（自算，落地需按实际复算）
- 桌面端：嵌入模型与意图模型跑本地（bge-m3 / Qwen3-4B~8B），边际成本≈电费
- 云端：万级用户 × 万条记忆 ≈ 1 亿向量；1024 维 float32 原始约 400GB，**必须量化**（int8 ≈ 100GB），生产按 100~150GB 常驻内存规划
- 模型：境内 API + **前缀缓存**（缓存命中 vs 未命中价差可达数十倍），把资产库压到 2~4k token 内是省钱关键
- **嵌入模型必须自托管**，否则把全部知识外发且成本高一个数量级

---

## 7. 路线图

| 阶段 | 周期 | 交付物 | 验收标准 |
|---|---|---|---|
| **P0 打地基** | 0–1 月 | 版本中心（自动识别/切换/能力位）+ 批处理执行器（run_journal 驱动）+ 统一日志；**废弃现有高危云通道** | 本机 2212/2412 均能一键跑通"批量出图/批量转档"；探测结果与手工核对一致 |
| **P1 变成产品** | 1–3 月 | 桌面 UI 收敛、任务队列、失败重试、安装/卸载器、许可与授权（机器码绑定） | 在**一台全新电脑**上双击安装即可用；卸载无残留 |
| **P2 长出脑子** | 3–6 月 | 极薄桥接 DLL（2212/2412 两版）+ 实时读部件 + 规则库 + 刀具库标准化 | 能读当前部件并给出选刀/参数建议，工程师采纳率可测 |
| **P3 学会经验** | 6–12 月 | 反馈采集 + 云端归并 + 资产库 + 灰度发布 + 金标回归 | 新用户开箱即享老用户沉淀的规则（可量化对比） |
| **P4 卖出去** | 12–18 月 | 加密授权、多租户云、企业版私有化、跨机床参数迁移 | 首个付费客户 + 复购 |
| **P5 拓边界** | 18–36 月 | 多 CAD（Mastercam/PowerMill）、工艺知识共享池（严格法务设计） | — |

---

## 8. 风险登记册

| 风险 | 等级 | 对策 |
|---|---|---|
| **云通道被利用为 RCE 跳板 / 私钥泄露** | 🔴 极高 | 立即废弃现有 oneclick 通道；TLS + 设备密钥 + 命令白名单 + 审计 |
| 多版本适配维护成本失控 | 🔴 高 | 桥接 DLL 做"极薄"；业务逻辑外置；建立版本回归矩阵自动化 |
| NX 小版本升级导致签名/API 变更 | 🟠 中高 | 按版本能力位分派路径；保留纯 journal 兜底（不依赖编译产物） |
| 免注册版破解泛滥 | 🟠 中高 | 机器码 + 云锁 + 服务化（把核心能力放云端而非本地 jar） |
| AI 出错导致撞刀/报废 | 🟠 中高 | 仿真强制校验 + 人工确认 + 免责与操作留痕 |
| 越学越蠢 | 🟡 中 | 金标回归集 + 负向指标 + 灰度 + 可回滚 |
| 数据合规（图纸/个人信息出境） | 🟡 中 | 图纸不出本地；境内模型；备案 |
| 单人开发带宽不足 | 🟠 高 | 用 AI 编程（Trae CN / 本 Harness）承担样板代码；人只做决策与验收 |

---

## 9. 待一次性真机标定的清单

1. `run_journal.exe` 的完整参数表（`-args` 已证实存在；`-automation`/`-nlm` 待标定）
2. `ugraf.exe -batch` 的官方语义与是否可用
3. batch 模式实际占用的 license feature 名
4. NX 2212/2412 上 **Python journal 与 C# journal** 的真实录制/回放（本机 Python 为内嵌 DLL；需实测 `run_journal.exe x.py` 与 `x.cs` 两条通路）
5. `NXBIN\managed` 程序集在 2212/2412 上的编译-加载一致性（签名校验强度）
6. 双版本同时运行时是否互相干扰（环境变量、共享配置）
7. `custom_dirs.dat` 当前是否已被修改（本机两版本大小均为 2419 字节，疑似原版）

---

## 10. 与既有资产的关系

你（用 Trae CN）已经产出：**NX 内插件 NxCamWizard + Python 桌面工具 NxCamToolkit + 文件信箱桥接 + 云连接脚手架 + 硅基流动批处理**。
- **保留并升级**：文件信箱 IPC 协议（设计是对的）、刀具/材料/转速进给数据、NX 侧 DLL 骨架、批处理思路
- **必须重做**：云端连接层（安全问题）、三代并行桥接收敛为一套、版本处理方式（从"手动分版本"改为"自动识别"）
- 详见 `01_资产盘点与优化评估.md`