写一个可验收的 AI 工程任务
好的任务不是告诉 AI 每一行怎么写，而是让它清楚最终结果、允许影响的范围、不能突破的边界，以及完成后如何证明。
推荐提示词结构
目标：最终要实现什么结果。
当前事实：已知设备、页面、Graph、数据和现场条件。
范围：允许修改哪些 Page、Graph、Object、Query、变量或 Script。
约束：不能改什么；哪些参数不能猜；是否只能在 stopped 状态操作。
验收：需要运行哪些诊断、构建、开始或调试检查；成功时看到什么。
输出：先列影响面和风险，再修改；结束时列出实际改动和未验证项。
开始前让 AI 做什么
- 读取你用
@提供的相关文件。 - 检查当前对象、编辑器支持的页面控件、Graph 方法与节点，以及 Query 定义。
- 运行现有诊断，区分原有错误和本次目标。
- 如果设备语义不足，明确停止并向你询问，不继续猜测。
- 给出短的影响面：准备改什么、为什么、怎么验证。
修改完成后检查什么
- 实际修改文件是否和影响面一致
- 问题（Problems）中是否出现新的错误
- AI 是否验证了最终文件，而不是只验证中间草稿
- Graph 或自定义代码是否完成应用构建
- 运行状态是否允许加载新资源
- 页面、设备动作、权限和异常提示是否符合现场需求
示例：只改页面
目标：在现有首页增加三台轴的状态卡和一个报警区域。
范围：只修改首页和一个可复用 Component；只读现有 Object，不新增设备动作。
约束：状态名称必须来自当前对象描述；不允许猜 Axis1/Axis2/Axis3 的物理用途。
验收：页面和 Component 诊断通过；告诉我每张状态卡绑定到哪个对象字段；不执行真实运动。
示例：跨 Page 和 Graph
目标：让“开始循环”按钮调用现有包装站对象的 StartCycle 方法，并在页面显示运行和故障状态。
当前事实：先检查对象描述、现有 Graph 方法和页面 action。
范围：允许修改包装站 Graph 和当前页面；不要修改 Safety、Pulsar 或 PLC 配置。
约束：长等待必须由对象能力或 Graph 的有界等待负责，Page Method 只做 UI 触发。
验收：Graph 诊断和应用构建通过；Page 诊断通过；通过调试验证正常和超时路径；不连接真实设备。
任务过大时如何拆分
优先按可独立验收的工程边界拆分：
- 先确认设备语义和对象能力。
- 再编排 Graph 与异常路径。
- 然后制作 Page 和交互。
- 最后接 Query、权限、构建和交付。
每一步都应有自己的诊断和验收结果。不要让一个对话同时重写设备层、流程层、页面层和部署设置。
什么时候必须停下来
- 设备用途、地址、单位或工艺含义不清楚
- Safety 或物理联锁会受影响
- AI 需要生产凭据、API Key 或密码
- 当前 App 正在运行，而计划修改运行实例依赖的资源
- 即将执行删除、生产写入或无法轻易恢复的部署操作
这些情况应由人补充事实或确认操作，再继续执行。