受控式 AI 开发总览（V10）

内容类型：方法说明难度：入门适合：所有使用 AI 辅助上位机开发的工程师阅读时间：约 10 分钟

“受控”不是让所有任务都变慢，也不是每次都要先写计划、填模板、跑全量测试。它真正指的是：Agent 的自主程度、上下文、修改范围和验证证据要与任务风险匹配。

1. 为什么上位机项目需要边界

上位机连接真实设备、通信协议和现场数据。错误可能不只是“界面不好看”，还可能导致：

设备状态判断错误；
参数写错；
协议时序破坏；
联锁/停机后果改变；
历史数据不兼容；
高压、运动、气路等危险动作。

因此 AI 可以大量参与，但不能把“代码能编译”当成最终验收。

2. V10 的第一步：先判断任务类型

text

用户请求
   ↓
只是查当前行为？
├─ 是 → Read-Only Trace
└─ 否
    ↓
目标和业务边界是否明确？
├─ 明确且小 → Fast
├─ 明确但涉及运行行为 → Execution
└─ 仍有关键业务决策 → Discovery

受控式开发不是固定六步，而是一套可按任务伸缩的控制方法。

3. 四种不同强度的例子

只查现状

text

“停机窗口是单帧还是连续判断？”
→ Read-Only Trace
→ 查最短调用链
→ 给证据
→ 结束

不需要构建、测试、修改记录。

改一个 UI 文案

text

“负载电流改成充电电流”
→ Fast / MicroPatch
→ 精确定位
→ 最小修改
→ V0/V1

不需要需求分析和完整 UI 设计。

改运行规则

text

“连续 5 次才报警，但不要停止试验”
→ Execution / BehaviorPatch
→ Trigger / Condition / Action / Reset / Record / NonGoals
→ focused implementation
→ V2/V3

新主流程

text

“新加一个设备自检与正式试验流程，但异常策略还没确定”
→ Discovery
→ Decision Tree / Frontier
→ 关键业务决策确认
→ Execution

4. 控制的是四件事

维度	要控制什么
Scope	这次允许改什么，不允许改什么
Context	当前任务真正需要哪些项目事实
Authority	Agent 可以执行到什么程度，哪些动作必须人工授权
Verification	需要什么证据才能宣称完成

5. Scope：小任务不要自动扩大

明确写出 NonGoals 很有价值，例如：

text

目标：修改报警显示文案
NonGoals：不改报警触发条件、不改 Stop、不改 MES、不改设备命令

如果 Diff 超出这些边界，Agent 应解释原因，而不是把“顺手优化”当默认行为。

6. Context：不是每次加载整个项目知识库

推荐分工：

text

Rules          → 每次必须遵守的工程边界
CONTEXT.md     → 稳定业务术语
.agent-memory  → 项目历史事实
ADR            → 长期重要设计取舍
当前任务       → 本次目标和临时约束

Fast MicroPatch 默认只读目标代码和直接证据；业务语义相关时再读对应 CONTEXT；回归时查相关 Memory；架构变化时读 ADR。

详见项目 Context、Memory 与 ADR。

7. Authority：AI 自主程度 L0–L5

L0–L5 表示你允许 Agent 自主到什么程度，与 V0–V4 验证等级不是一回事。

级别	AI 可以做什么	常见场景
L0	只解释，不修改	学习、Read-Only Trace
L1	给方案和证据	高风险决策、设计评审
L2	生成局部代码/草稿	独立方法、示例
L3	修改明确范围文件并验证	大多数 Fast/Execution
L4	跨模块执行已明确方案	BehaviorPatch、大功能实施
L5	高自主执行	仅适合可隔离、可恢复、非危险实验

L4/L5 也不意味着允许真实高压、运动、继电器等危险设备动作。危险外部动作需要单独明确授权。

真实设备只读查询也不是因为“只读”就自动允许：必须先确认查询不会改变设备状态或清空关键诊断信息、当前现场允许查询，并且不会为了诊断建立第二个互斥设备 Session。详见真实设备操作与验证安全边界。

8. Verification：按 V0–V4，而不是统一全量

等级	典型验证
V0	Diff/static
V1	affected build / 必要 focused test
V2	Fake/Replay/focused integration
V3	workflow/state/interlock smoke
V4	release/full checkpoint

“0 tests matched”不能写 Verified；软件/构建/权限环境阻断写 EnvironmentBlocked；需要真机/HITL 但尚未执行写 HardwarePending。

最终验证状态统一为：

text

Verified
Unverified
EnvironmentBlocked
HardwarePending

Fake / Replay 通过只能证明对应软件侧行为，不自动等于真实设备已经验收。

详见 AI 开发验证体系。

9. 人和 AI 怎么分工

Agent 更适合自主完成

找代码和调用链；
查当前配置事实；
比较 Git Diff；
普通源码修改；
Fake/Replay；
安全的构建和 focused test；
日志整理；
技术文档草拟与证据检查。

人必须保留最终决定

用户真正想要什么业务后果；
安全联锁和设备风险接受；
危险真实设备动作授权；
现场验收；
破坏性数据操作；
最终发布和交付责任。

10. “事实”和“决策”不要都问用户

Agent 能通过仓库、日志、配置、Git 查到的事实，先自己查。

例如：

text

“阈值现在是多少？” → Agent 查
“超过阈值后应该停机还是只报警？” → 用户决策

这会显著减少反复确认。

11. AI 说“完成”时至少应包含什么

根据任务大小，结果可以很短，但要说明：

text

Changed
VerificationLevel
VerificationState
Evidence
ResidualRisk

如果是回归问题，还应区分：

text

RolledBackToKnownGood
RegressionFixed

回退到旧版本恢复正常，不等于已经修复当前版本的 causal behavior delta。

对于 Read-Only 问题，则给：

text

CurrentBehavior
Evidence
Unknowns

12. 长对话和项目记忆

不要求“跨天必须新开对话”，也不要求每次都重新加载完整上下文。

更实用的规则：

同一个目标、同一组边界仍然有效 → 可以继续；
目标明显切换、旧约束冲突、上下文开始污染 → 新建任务/对话；
项目长期知识放文件，不靠聊天窗口保存；
当前任务状态可从 Git Diff、任务记录和最近验证恢复。

详见 AI 长对话管理。

13. 一个最终模型

text

先分任务
→ 只加载需要的 Context
→ 设定 Scope / Authority
→ 最小执行
→ 按风险验证
→ 结论跟证据强度走
→ 高价值经验才沉淀

下一步

一句话原则

受控式 AI 开发不是“每一步都不能跳”，而是任何被跳过的步骤都应当因为当前任务确实不需要，而不是因为没人想到。

受控式 AI 开发总览（V10） ​

1. 为什么上位机项目需要边界 ​

2. V10 的第一步：先判断任务类型 ​

3. 四种不同强度的例子 ​

只查现状 ​

改一个 UI 文案 ​

改运行规则 ​

新主流程 ​

4. 控制的是四件事 ​

5. Scope：小任务不要自动扩大 ​

6. Context：不是每次加载整个项目知识库 ​

7. Authority：AI 自主程度 L0–L5 ​

8. Verification：按 V0–V4，而不是统一全量 ​

9. 人和 AI 怎么分工 ​

Agent 更适合自主完成 ​

人必须保留最终决定 ​

10. “事实”和“决策”不要都问用户 ​

11. AI 说“完成”时至少应包含什么 ​

12. 长对话和项目记忆 ​

13. 一个最终模型 ​

下一步 ​

一句话原则 ​

受控式 AI 开发总览（V10）

1. 为什么上位机项目需要边界

2. V10 的第一步：先判断任务类型

3. 四种不同强度的例子

只查现状

改一个 UI 文案

改运行规则

新主流程

4. 控制的是四件事

5. Scope：小任务不要自动扩大

6. Context：不是每次加载整个项目知识库

7. Authority：AI 自主程度 L0–L5

8. Verification：按 V0–V4，而不是统一全量

9. 人和 AI 怎么分工

Agent 更适合自主完成

人必须保留最终决定

10. “事实”和“决策”不要都问用户

11. AI 说“完成”时至少应包含什么

12. 长对话和项目记忆

13. 一个最终模型

下一步

一句话原则