使用 AI Command Center 完成并验收任务
AI Command Center 可以帮助你理解当前 App、修改源码与配置、排查问题和准备候选实现。一个可靠的任务不以“AI 已完成”为终点，而以保存内容、验证结果、实际差异和必要的人工检查为证据。
开始前
- 打开正确的 App，并保存本次任务可能涉及的编辑器草稿。
- 在系统设置 → AI 设置中确认 Provider 可用，再选择适合任务的模型。
- 写清目标、允许修改的范围、不能触碰的内容和成功条件。
- 真实设备、Safety、权限或生产运行必须有明确的人工负责人。
- 不要在对话、附件或截图中发送密码、API Key、访问令牌或无权上传的客户数据。
Provider 尚未配置时，先参见配置 Provider 与模型。
1. 新建一个边界清楚的任务
- 选择编辑器工具栏中的 AI 图标，或按
Cmd/Ctrl+I。 - 独立目标使用新对话；继续同一目标时回到已有会话。
- 明确选择 Provider、模型和思考等级。
- 需要专注时使用全屏；需要边看页面或源码边交流时选择停靠为 Tab。
- 发送第一条消息后，从任务详情观察当前步骤、文件操作和检查结果。
切换到其他会话不会停止正在执行的任务。停止只终止当前选中的会话，并清除它尚未执行的排队消息。不要让两个会话同时修改同一个文件；确需并行时，先划分互不重叠的文件范围。
2. 用 @ 给出准确上下文
- 在输入框键入
@。 - 选择当前 App 中与目标直接相关的已保存文件或 Skill。
- 说明每个引用要解决什么问题，以及哪些内容禁止修改。
- 新文件或刚修改的文件找不到时，先保存，再重新搜索。
例如：
使用
@选择当前设备总览页面和页面设计 Skill。保留现有配色，增加轴状态、报警和复位区；不要修改 QG、设备地址或 Safety。完成后列出修改文件，Validate 最终保存内容，并说明仍需人工确认的行为。
引用用于提供上下文，不是权限边界。即使只引用一个文件，也要在任务中明确“只允许修改哪些文件”，并在完成后检查 Git 差异。AI 会根据当前 App 的真实文件和能力完成工作，用户不需要指定内部工具调用顺序。
3. 写一个可验收的任务
按以下顺序描述：
- 目标：用户最终要得到什么。
- 范围：AI 可以读取和修改哪些资源。
- 约束：哪些接口、设备参数、Safety 或既有行为必须保持不变。
- 验收：要运行哪些检查，什么结果才算通过。
可直接套用：
目标：为包装工位增加手动操作页面。范围：只修改引用的
.qp页面和必需的.qpc事件处理。约束：复用现有 Object，不修改.qg、设备地址或 Safety。验收：保存最终文件；Validate 整个 App 且没有阻塞诊断；按目标分辨率审查页面快照；列出实际修改、未完成项和人工检查。
“做完这个功能”不是完整的验收条件。界面尺寸、受影响语言、错误场景、运行目标和禁止改动项越明确，结果越容易核对。
4. 先 Validate 保存内容
要求 AI 在修改后 Validate 最终保存的 App：
- Validate 是只读检查，不会 Build、Deploy、启动 Runtime，也不会授予这些操作的权限。
- Validate 以磁盘上的已保存内容为准。编辑器中未保存的草稿不会进入整个 App 的最终检查。
- 整个 App 的 Validate 适合交付前的跨文件检查；单个受支持文档的 Validate 适合定位局部错误。
- Build 还会检查项目解析和打包，因此 Validate 通过不代表 Build 或运行一定通过。
- 如果上游 Object 配置无效，应先修复根因；不要把由此产生的后续诊断当成多个独立问题。
新页面或布局、样式、图片、可见文本发生变化时，还应让 AI 在目标分辨率和受影响语言下审查已保存页面的快照。该步骤需要支持图像输入的模型。快照可以发现裁切、溢出、层级或内容缺失，但不能证明交互、真实 Object 数据、权限、Safety 或 Runtime 行为。
5. 审查实际修改
- 阅读 AI 的完成摘要、Validate 结果、未完成项和假设。
- 打开任务详情，确认执行过的检查及其成功或失败状态。
- 在 Git 面板检查每个差异，确认修改文件没有超出任务范围。
- 打开受影响的页面、QG、Object 或设置，核对结构、属性和可见结果。
- 检查 Problems，确认最终保存内容没有新增阻塞错误。
AI 的文字结论不能替代这些证据。发现范围外修改时先停止验收，要求同一会话做最小范围修正。
6. 明确授权 Build 和 Runtime 操作
只有当前请求明确点名某个操作，或明确要求调试 Runtime，AI 才能查询或改变运行目标。“完成修改”“验证一下”或普通源码任务都不包含这项授权。
| 操作 | 用户会得到什么 | 确认与权限 |
|---|---|---|
| Status | 查看所选目标的当前 Deployment 和 Runtime 状态 | 只读，不弹确认；有效目标会话可查看 |
| Clean | 只删除当前 App 与目标对应的本机 Build 结果 | 需要允许一次；不会 Build、Deploy 或改变目标状态 |
| Build | 使用已保存文件 Build，并把该版本交付到所选目标 | 需要允许一次和目标 Admin；不会 Preview 或启动 |
| Preview / Run / Debug / Stop | 对目标上当前已 Deploy 的 App 执行指定 Runtime 操作 | 每次需要允许一次和目标 Admin |
授权面板会显示操作、目标和当前状态。选择拒绝后，本次操作结束；AI 不应自动重试。选择允许一次只批准当前显示的操作，不批准后续操作、Object 方法调用、运动、I/O、Safety 变更或业务动作。
Build 只读取已保存文件，不会替你保存编辑器草稿。Preview、Run 和 Debug 只使用目标上当前已交付的版本，不会隐式 Build。要让源码变化进入 Runtime，先明确 Build，再单独明确请求 Preview、Run 或 Debug。
目标 User 可以查看状态并使用已经 Running 的 App，但不能执行 Build、Deploy 或 Runtime mutation。App Admin 也不会因此获得目标 Runtime 管理权限。完整边界参见账号、角色与权限。
7. 完成最终验收
- 确认实际修改与任务范围一致，Validate 和 Problems 结果可追溯到最终保存内容。
- 对视觉变化核对目标分辨率、受影响语言和快照中发现的问题。
- 根据风险执行明确授权的 Build、Run 或 Debug，并以工具返回的目标状态为准。
- 测试正常、边界、失败和恢复场景。
- 让设备、Safety、权限和生产负责人确认各自领域。
- 验收通过后再 Commit、Push 或进入交付流程。
成功表现
- 会话绑定正确的 App，并使用预期的 Provider、模型和引用。
- AI 明确列出修改范围、Validate 结果、剩余问题和人工决策。
- Git 差异只包含授权修改。
- 约定的页面审查、Problems、Build 或 Runtime 检查通过。
- 实际行为符合提示词中的成功条件，而不只是文件格式有效。
常见问题
模型列表为空
返回 AI 设置，检查登录或 API Key、保存状态和 Provider 行错误，再刷新模型。参见配置 Provider 与模型。
@ 找不到刚创建的文件
先保存文件，在 Files 或 Resources 中确认它存在，再重新键入 @ 搜索。
Validate 检查的不是最新内容
先保存所有相关草稿，再要求 AI Validate 整个 App。Validate 不读取未保存的编辑器状态。
Validate 通过，但 Build 失败
这是可能的：Build 还检查项目依赖和交付准备。根据 Build 返回的诊断修复已保存工程文件，再重新 Validate 和 Build；不要把 Validate 当成运行证明。
Build 完成，但 App 没有启动
这是预期行为。Build 会 Deploy，但不会 Preview 或启动。确认目标状态后，再明确请求 Run、Debug 或 Preview。
Runtime 操作没有执行
确认请求明确点名了操作、授权面板选择了允许一次，并且当前目标会话具有 Admin 权限。被拒绝或权限不足的操作不会被当作成功，也不会自动重试。
AI 不断扩大修改范围
选择停止，重新声明允许修改的文件、禁止区域和最小验收目标。旧目标已经干扰上下文时，新建一个范围更小的会话。
AI 已完成，但还不能确定能否上线
要求 AI 列出未验证假设，然后由页面、设备、Safety、权限和交付负责人分别验收。Validate、快照和 Build 都不能代替现场确认。
安全边界
@引用帮助 AI 理解上下文，但不会自动限制可修改范围；范围必须写进任务并用 Git 差异核对。- Validate 和页面快照是工程证据的一部分，不是设备、Safety、权限或生产运行的批准。
- Runtime 的一次确认只授权弹窗显示的操作，不授权 AI 直接调用 Object 方法或执行运动、I/O 和业务命令。
- 设备地址、单位、极性、限位、安全状态、联锁和生产顺序必须由了解现场的人提供并验收。
- 凭据只输入专用字段；如果凭据出现在聊天或 Git 中，应立即撤销并轮换。