典型使用场景
前置：先在 AI 配置里把模型接好（推荐预置的 DeepSeek-V4-Pro / Flash），并打开一个工作空间。
场景一：在流程图上拆需求、改流程（需求分析师）
适用：把一段口头需求落成流程图；让老流程图“体检”；新增 / 改名节点。
- 在用户视图中添加流程图控件（或用已有流程图）；
- 在该控件上 右键 → 召唤AI特工 → 需求分析师，画布上出现特工头像；
- 直接说需求，例如：
我：这是一条来料检测流程。我想在【缺料检查】这个环节下再加两步：
先拍照留档，再判断是否需要人工复核。你先分析下这样合理吗？
AI：合理。当前【缺料检查】是叶子节点，没有失败分支。
建议：在其下新增【拍照留档】→【人工复核判定】两个子节点，
并把“判定失败走人工复核”标注出来。
我将执行以下改动（新增2个节点）…[flowchart-actions]
- AI 先一句话说明改动意图，再输出结构化改动，程序解析后真实落到流程图上；
- 不满意就让 AI 改 / 撤销，全程对话可回滚（改动集中在流程图节点文字，不碰算子程序）。
什么时候不适合：想改的是算子程序（参数、连接、Job），不是用户视图的流程图标签——流程图控件管的是“流程/需求层文案”，程序执行仍由程序编辑器控制。
场景二：贴图问报错（视觉分析助手）
适用：程序报错、界面异常、现场照片，说不清就“直接上图”。
我：（粘贴报错弹窗截图 + 运行时日志）
AI：整体概览：这是一张 ToolBank 运行报错弹窗。
文本识别：标题“算子执行失败”，正文“DL_ObjectDetection：无法加载模型
C:\...\model.onnx”。
异常/风险：红色错误条提示“模型路径不存在”。
建议下一步：① 检查该算子 ModelPath 是否指向已安装模型的 Models 目录；
② 若刚换过工作空间，重新选择模型文件；③ 把完整报错复制到
“诊断信息”类问题里排查。
要点：视觉分析助手按固定结构输出，识别不出的会明说（“不识别 / 信息不足”）而不是脑补，这比凭感觉猜靠谱得多。
场景三：审查代码（代码审查员）
适用：审查你正在开发的插件 / 脚本 / 算法代码。
我：（贴一段 C++ 算子实现，约 40 行）
AI：总体评分：7/10。代码主路径清晰，但有三处健壮性隐患：
[高] 输入图像为空时未判空，GaussianBlur 会崩 → 建议前置判空并 SET_ERROR；
[中] 卷积核参数未校验上下界；
[低] 硬编码字符串建议改为常量。
修改建议（片段）：
if (m_InputImage.empty()) { SET_ERROR("输入图像为空"); return ECode::LOGIC_ERROR; }
它要求对未验证的外部依赖明确标注（如“这段调了摄像头 SDK，未验证其线程模型”），避免把猜测当结论。
场景四：日常打杂（通用助理）
- 把一大段运行日志贴给它：“总结成 5 条要点，目标读者：产线调试工程师”；
- “用中文解释这个算子的输入输出，再给一个测试用例表”；
- “把这 20 行配置改写成我要求的格式”；
- “写一份 YOLO 精度验收清单”（它会引用 ToolBank 的算子能力常识，但请把具体字段名和界面里的实际参数核对一遍）。
让 AI 回答得更准的四个技巧
- 给足上下文：优先在“选中了某个节点 / 变量”的状态下提问，AI 的上下文快照里就有它；比手打描述准。
- 一句话说清目标与约束：目标（“给产线新人写步骤”）、约束（“只能离线用 Ollama”）、输出格式（“表格”）。
- 让它先说方案再动手：对会改动内容的操作，先让它“分析 / 给方案”，确认后再下令“执行”。
- 重要结论要核验：涉及文件路径、API、模型名的回答，以界面里实际看到的为准——模型偶尔会“一本正经地编造”，核验成本远低于返工成本。
常见问题
召唤了需求分析师，但它说看不到流程图？
它必须在流程图控件上被召唤（控件右键菜单），而不是在 AI 面板里直接选。检查召唤菜单里的勾选状态；或把它“送走”后重新召唤。
AI 说已经改了流程图，但画布没变化？
一般两种情况：① 改动指令没被识别为合法 flowchart-actions（比如节点 id 是编的）——看它回复里的 JSON 是否引用了快照中不存在的 id；② 改动被宿主校验拦下。此时把 AI 的“原始响应”发给它让它修正，或手动在流程图上改。
同一个流程图能同时召唤两个特工吗？
可以。流程图右键菜单会列出当前所有已启用特工，各自独立召唤、独立会话。注意它们共享同一份流程图事实，如果让两个特工同时改同一处节点，可能互相覆盖——建议同一时刻只让一个特工执行写操作。