Appearance
AI 在每一步能做什么（V10）
AI 可以帮助你更快理解 C#、WPF、通信和项目结构，但有一个很重要的区别：
学习流程可以故意慢一点，让你看懂每一步；真实生产任务不应该把教学步骤机械套到每个小改。
例如学习时，改一个按钮文字后你可以主动运行程序观察结果；真实项目里，同样的纯文案修改通常只需要 V0 静态检查，不必为了“流程完整”跑整套构建和回归。
1. 先认识两种不同的 AI 使用场景
| 场景 | 目标 | 推荐方式 |
|---|---|---|
| 学习训练 | 理解概念、建立直觉、练习调试 | 可以多解释、多观察、多手工验证 |
| 真实项目 | 准确完成任务并控制返工 | 先判断任务类型，再使用足够但不过量的流程 |
真实项目优先使用 V10：
text
只查现状 → Read-Only Trace
明确小改 → Fast
目标/边界已清楚 → Execution
业务还没想清楚 → Discovery验证再独立按 V0–V4 决定深度。
2. AI 可以帮什么，你必须掌握什么
AI 很适合辅助
- 解释术语和概念，用你熟悉的知识做类比
- 生成简短、可运行的示例代码
- 解释编译错误、异常和日志
- 追踪调用链和数据流
- 把模糊想法整理成需求候选
- 检查代码 Diff 和影响范围
- 设计 focused test、Fake、Replay 和验收清单
- 整理方案、说明书、总结和测试证据
你必须建立的能力
- 能看懂自己项目的核心代码和业务流程
- 能判断 AI 给出的需求是否真是你的需求
- 能看 Git Diff，知道它改了什么
- 能区分编译通过、软件行为正确和真机安全
- 能理解设备动作、现场风险和验收结果
- 涉及高风险真机动作时承担人工确认和 HITL
3. 阶段一：了解概念
| AI 能做 | 你应该亲自做 |
|---|---|
| 解释什么是上位机、WPF、串口、TCP、状态机 | 打开 Visual Studio 看真实项目长什么样 |
| 用前端/后端/测试等经验类比新概念 | 创建一个空白 WPF 项目并运行 |
| 画出技术关系和数据流 | 操作一次串口调试助手或模拟器 |
| 给最小示例 | 改一个参数观察结果 |
这一阶段 AI 更像老师，不追求“替你完成”。
4. 阶段二：认识技术
适合让 AI：
- 解释
Button、Binding、Command、SerialPort、Task； - 写几十行以内的小例子；
- 把报错逐句翻译成人话；
- 给两三个边界输入让你自己预测结果。
推荐学习节奏：
text
先预测
→ 自己写/修改
→ 运行观察
→ 让 AI Review
→ 用自己的话解释不要只复制最终答案。你至少要知道输入是什么、状态怎么变化、输出在哪里。
5. 阶段三：看懂项目
第一次接手陌生项目时，AI 可以帮你建立最小项目地图：
text
启动入口
UI / ViewModel
Application / Workflow
设备与通信
数据/配置/日志
测试但日常只是问：
- “这个按钮最后调用了什么？”
- “这个阈值在哪判断？”
- “当前是单次还是连续？”
就使用 Read-Only Trace：
text
精确目标
→ owner
→ direct caller/callee
→ 最终 sink
→ 结论
→ END不要每个问题都重新扫描整个 solution。
详见 AI 辅助读懂 C# 项目。
6. 阶段四：做项目
新项目/新主流程
AI 可以帮助：
- 发现业务 Frontier；
- 做页面、通信、状态机、数据和线程设计；
- 拆可验证的业务闭环；
- 先接 Fake/Simulation，再接真实设备。
已有项目小改
不要照搬上面的完整流程。
例如：
text
“按钮文字改一下”
→ Fast / MicroPatch
→ 最小 Diff
→ V0/V1text
“连续 5 次高电流才报警，但不要停机”
→ Execution / BehaviorPatch
→ Behavior Contract
→ V3 focused verificationtext
“昨天改完后波形不一样”
→ RegressionFix
→ known-good first7. 新手最容易踩的四个坑
坑一：让 AI 一次性生成完整项目
项目越大，越难知道哪一部分真的正确。
更好：按可观察的业务闭环逐步实现，先 Fake，再真实集成。
坑二：不看 Diff 就接受所有修改
AI 可能顺手重构、改配置、加依赖或碰到任务外文件。
更好：至少检查修改文件、关键行和 NonGoals。
坑三：把“每次都构建运行”当成工程纪律
学习时多运行有助理解；生产里一行文案也跑全量构建会非常慢。
更好：按 V0–V4 选择验证深度。
坑四：AI 说“已修复”就认为根因确认
编译通过、重试恢复、代码看起来合理，都不等于问题已经被证明。
更好：看实际证据，近期回归先比较 known-good。
8. V0–V4：不是每次修改都做同样验证
| 等级 | 常见任务 | 典型验证 |
|---|---|---|
| V0 | 文案、静态内容 | Diff / readback |
| V1 | XAML、普通局部代码 | affected build，必要时页面检查 |
| V2 | 通信、数据、设备规则 | focused test / Fake / Replay |
| V3 | 状态机、联锁、告警后果、并发 | WorkflowSmoke + focused evidence |
| V4 | 发布、大迁移、广泛兼容 | full checkpoint |
学习阶段为了建立理解，你可以主动多做一步；但不要把“多做一步”误写成所有生产任务必须遵守的规则。
9. 真实设备验证不是普通自动测试
真实设备要再单独判断安全性：
text
软件侧验证
→ Fake / Replay
→ 必要的只读设备观察
→ 显式授权的设备动作
→ 高风险动作 HITL高压、电机、阀门、继电器、加热、气路、联锁等动作，不因为代码写好了或 V3/V4 验证需要就自动执行。
未做真机动作时可以准确记录：
text
HardwarePending而不是为了得到“全部通过”去碰真实设备。
详见 真实设备操作与验证安全边界。
10. 一个更好的 AI 协作节奏
不要固定成：
text
所有任务
→ AI先分析
→ AI先出方案
→ 用户确认
→ 才写代码改成：
text
先判断任务类型
│
├─ Read-Only → 只查证据并回答
├─ Fast → 直接最小修改
├─ Execution → 简短契约后实施
└─ Discovery → 才追问业务 Frontier
然后：
→ 看 Diff
→ 按 V0–V4 验证
→ 真实设备动作另走安全授权11. 新手为什么仍然值得走完整教学项目
本站的第一个串口项目会故意让你经历：
text
需求
→ 设计
→ 拆任务
→ 编码
→ 通信
→ Bug
→ 验证这是为了让你学习完整工程链条，不是说以后改一个 Label 也必须重新从需求开始。
学完以后，真实项目应该逐渐学会根据任务风险“减掉不需要的步骤”。
下一步
一句话原则
学习阶段多走一步是为了理解；生产阶段只走当前任务真正需要的步骤，并让验证深度与风险匹配。