跳到主要内容

AI 与人工责任边界

Theseus 推荐 AI-first，但不是 AI-only。默认先让 AI 理解目标、检查当前 App 并完成可自动化的工作；人负责给出边界、看懂结果、验证真实行为，并批准高影响操作。

基础概念不是为了让每个人手写底层文件，而是让你能清楚地告诉 AI 要改什么、检查它改了什么，并在需要时接管。

为什么需要知道​

AI 可以显著加快页面、流程、查询和代码工作，但它无法凭空知道现场工艺、真实接线、设备极限和组织责任。明确分工，既能让日常任务更快，也能避免把“生成完成”误认为“可以上线”。

何时会遇到​

  • 让 AI 创建 Page、Graph、Object、Query 或 Script；
  • 让 AI 修复 Problems、构建错误或运行故障；
  • 修改 PLC、运动、Vision、Safety、权限或外部系统写入；
  • 准备 Run、Debug、Deploy、Stop、删除或上线；
  • AI 询问目标、约束、文件范围或验收方式。

一条共同的工作流​

无论主要由 AI 还是人工完成，都使用同一个闭环：

  1. 说明目标：描述想得到的业务结果。
  2. 限定范围：说明允许修改的资源、不能改变的内容和目标 Runtime target。
  3. 让 AI 检查当前 App：先基于现有 Page、Object、Graph、Variable 和 Query 判断影响面。
  4. 生成或修改：AI 完成明确范围内的工作，并列出改动资源。
  5. 在编辑器中复核：查看 Resources、属性、连线和 Problems，而不是只读 AI 的完成说明。
  6. Build 与运行验证：按影响面执行 Build、Run 或 Debug，覆盖正常、异常和超时分支。
  7. 人工批准：高影响变更由对应责任人确认，再提交、部署或交付。

一个清晰的请求可以这样写：

目标：为当前工位增加启动前检查。
范围：可以修改 startup Graph 和相关页面提示；不要修改 Safety 或设备地址。
约束：检查失败时不能执行启动动作，必须显示明确原因。
验收：Build 通过；Debug 中验证成功、失败和超时三条路径。
完成后：列出修改的资源、验证结果和仍需人工确认的项目。

谁负责什么​

任务AI 适合承担人必须确认
Page、Component、文案和布局创建、调整、检查绑定和一致性操作员是否看得懂、能否避免误操作
Page method、Graph 和一般流程编排步骤、补齐参数、检查类型、分析错误工艺顺序、异常分支、超时和恢复策略
Object、Query 和自定义代码生成结构、封装调用、修复诊断真实协议、地址、单位、认证方式和外部写入目标
PLC、运动和 Vision辅助配置、生成候选实现、分析测试结果现场参数、设备极限、样本覆盖和真实设备试运行
Safety解释配置、检查一致性、提示风险由合格工程人员设计和批准；硬件安全措施始终独立存在
用户、角色和权限生成建议、检查遗漏人员职责、最小权限和上线账号
Build 与诊断执行可用检查、收集错误、帮助定位构建结果是否符合预期，是否可以进入运行验证
Run、Debug、Deploy、Stop、删除和发布说明影响、准备测试或操作步骤、分析返回结果由有权限的人发起并监看真实运行，明确批准高影响操作

API Key、密码和其他凭据应通过对应设置界面输入，不要放进普通对话、提示词、页面、Graph 或版本库。

人工验收的最小清单​

  • AI 列出的修改资源与我授权的范围一致。
  • 我能在编辑器中找到并解释关键 Page、Object、Graph、Variable 或 Query。
  • Problems 中没有阻止运行的错误，必要的 Build 已通过。
  • 已确认 Navbar 选择了正确的 Runtime target。
  • Run 或 Debug 覆盖了正常、失败、超时和恢复路径。
  • 真实设备地址、单位、运动参数、外部写入和权限已经由负责人确认。
  • Safety 相关变更经过独立工程审核，不依赖 AI 结论代替硬件或认证安全措施。

常见误解​

  • AI 写完不等于运行时已经更新。 保存只更新编辑态，新的运行版本仍需按生命周期验证。
  • 理解概念不等于手写 JSON。 你只需要能判断资源归属、运行阶段和验收结果。
  • 画面正确不等于设备逻辑安全。 真实动作、异常和联锁必须单独验证。
  • Build 成功不等于可以上线。 它只证明运行产物可以生成。
  • AI 不只用于生成。 它也适合解释现有工程、比较方案、检查影响面和定位问题。
  • 不用 AI 的用户仍然走同一套编辑器和验收流程。 AI 是协作入口，不是另一套工程格式。

下一步​