上位机 AI 开发工作流

Appearance

度量复盘与经验沉淀 ​

这份文件解决一个问题：项目不是验收完就结束，还要知道这次 AI 开发哪里顺、哪里返工、哪里下次要改流程。

如果不做复盘，同样的问题下次还会发生：需求没问清、AI 改太多、通信异常没测、日志不够、现场才发现配置不对。

复盘不用复杂。每次阶段结束或项目交付后，用 10 到 20 分钟记录关键事实即可。

1. 什么时候复盘 ​

建议这些节点做一次：

  1. 第一版需求方案确认后。
  2. 一个大功能完成后。
  3. 一个 Bug 修复并验证后。
  4. 现场联调后。
  5. 项目交付后。
  6. 出现严重返工后。

2. 复盘先看事实 ​

不要只写“AI 不稳定”“需求有变化”。先记录事实。

项目内容
项目/功能名称
时间范围
当前阶段需求 / 设计 / 开发 / 调试 / 测试 / 交付
本阶段目标
实际完成内容
未完成内容
参与人员
使用的 AI 工具或 Skill

3. 需求变化统计 ​

变化项原始说法后来改成变化原因是否影响代码
是 / 否

常见原因：

  1. 现场流程一开始没说清。
  2. 设备协议后来变化。
  3. 客户补充了验收要求。
  4. 第一阶段范围定得太大。
  5. AI 把推测当成了要求。

4. 缺陷来源统计 ​

缺陷或问题来源分类发现阶段影响后续动作
需求遗漏 / 设计问题 / AI 代码问题 / 人工修改问题 / 环境问题 / 设备问题 / 测试遗漏

常见 AI 代码问题：

  1. 改动范围过大。
  2. 误删旧逻辑。
  3. 没处理异常路径。
  4. UI 线程更新不正确。
  5. 通信接收和解析混在一起。
  6. 数据保存字段遗漏。
  7. 配置默认值不兼容。

5. 回归失败项 ​

回归项失败现象根因补救措施是否加入固定清单
是 / 否

如果某类问题重复出现，就应该更新 30-回归测试与验收清单.md 或相关 Prompt。

6. AI 输出质量记录 ​

场景使用的 Prompt 或 Skill输出是否可用问题下次怎么问
需求整理可用 / 部分可用 / 不可用
技术方案可用 / 部分可用 / 不可用
代码修改可用 / 部分可用 / 不可用
Bug 调查可用 / 部分可用 / 不可用
测试清单可用 / 部分可用 / 不可用

重点看：

  1. 哪些提示词让 AI 输出更稳定。
  2. 哪些提示词导致 AI 直接写代码或改太多。
  3. 哪些输入信息缺失导致 AI 猜错。
  4. 哪些 Skill 需要补充模板或示例。

7. 性能和稳定性指标 ​

涉及通信、图表、数据保存、长时间运行时，至少记录：

指标目标实测结果
启动时间通过 / 不通过
连接成功率通过 / 不通过
数据刷新频率通过 / 不通过
保存耗时通过 / 不通过
连续运行时长通过 / 不通过
CPU/内存是否稳定通过 / 不通过
异常帧处理通过 / 不通过

8. 交付后问题 ​

问题发现人发现时间严重程度是否需求内处理结论
高 / 中 / 低是 / 否 / 不确定

如果交付后问题很多，通常要回头检查：

  1. 问题定义是否太粗。
  2. 验收标准是否没有量化。
  3. 真实设备测试是否不足。
  4. 异常路径是否没有测。
  5. 发布环境是否没有记录。

9. 经验沉淀 ​

类型本次经验应该更新到哪里
需求10-问题定义与用户场景.md / 11-上位机项目需求拆解表.md / 50-常用Prompt库.md
设计20-WPF上位机AI开发流程.md / 22-架构决策ADR模板.md
通信21-串口TCP通信任务模板.md / Skill 通信笔记
Bug40-Bug调查与最小修复流程.md / Bug Prompt
测试30-回归测试与验收清单.md
Skillskills/host-computer-dev

写经验时要具体，不要写空话。

不建议写：

text
以后要多测试。

建议写：

text
协议解析修改后，必须补测粘包、半包、CRC 错误、连续 30 分钟接收，否则容易遗漏缓存状态问题。

10. 持续优化闭环 ​

持续优化不是把文档越写越长，而是把真实开发中反复出现的问题，沉淀成更短、更准、更可执行的规则。

每次优化前先确认这条经验来自哪里：

证据来源可以优化什么不建议直接优化什么
实际项目返工需求表、质量门、回归清单不要只改宣传性描述
Bug 调查记录Bug 分级、日志要求、最小修复模板不要把偶发猜测写成固定规则
通信联调问题协议模板、通信测试项、长稳记录不要在没有日志时改通信结论
现场验收反馈验收表、发布检查、配置说明不要把单个客户偏好当通用要求
AI 输出失败Prompt、Skill 模板、禁止事项不要只写“AI 要更谨慎”这种空话

推荐按这个顺序更新：

text
现场问题或返工
  -> 记录事实和证据
  -> 判断属于需求、设计、通信、Bug、测试、Skill 哪一类
  -> 更新对应文档或 Skill 模板
  -> 给 30-回归测试与验收清单 增加可验证项
  -> 下一次项目用新规则验证是否减少返工

10.1 什么内容值得加入工作流 ​

符合下面条件之一，就值得沉淀：

  1. 同类问题出现过两次以上。
  2. 一次问题造成明显返工、现场风险或交付延期。
  3. AI 经常在同一类任务上误判，例如通信接收和解析混在一起。
  4. 人工验收时才发现，但本可以在开发阶段提前检查。
  5. 用户经常不知道怎么描述，导致 AI 需要反复追问。

不建议加入工作流：

  1. 只适用于某一个客户的临时偏好。
  2. 没有日志、代码、截图或测试结果支撑的猜测。
  3. 已经被现有质量门覆盖，只是换一种说法。
  4. 会让小改也被迫走完整重流程的规则。

10.2 优化记录表 ​

日期触发原因证据更新位置新增规则下次验证方式
返工 / Bug / 现场反馈 / AI 输出失败日志、截图、提交记录、验收记录文档或 Skill 路径具体新增了什么怎么判断有效

10.3 更新粒度 ​

优先改最靠近问题的位置：

问题类型优先更新
用户说不清需求10-问题定义与用户场景.md 或 11-上位机项目需求拆解表.md
AI 直接写代码、跳过确认12-AI开发质量门.md 或对应 Skill 的 SKILL.md
WPF 页面容易返工20-WPF上位机AI开发流程.md 或 23-界面原型到WPF开发流程.md
通信联调反复出错21-串口TCP通信任务模板.md 和通信 Skill 笔记
Bug 修复范围变大40-Bug调查与最小修复流程.md 或 Bug 修复 Skill
验收漏测30-回归测试与验收清单.md
Prompt 不稳定50-常用Prompt库.md 或对应 TEMPLATE.md / EXAMPLE.md

10.4 优化后的检查 ​

每次改完工作流内容，至少检查：

  1. 新规则是否能指导下一步动作，而不是只表达态度。
  2. 是否会让 L1/L2 小改变得过重。
  3. 是否给 L4/L5 高风险任务补了证据、日志或验收要求。
  4. 是否和 00-先读我-阅读路线.md、02-资料包文件用途总览.md 的阅读路线冲突。
  5. 是否需要同步更新 Skill 的 TEMPLATE.md 或 EXAMPLE.md。

11. 发给 AI 的复盘 Prompt ​

text
请你作为 C# WPF/WinForms 上位机 AI 开发复盘助手。

下面是本阶段的需求、修改记录、Bug、测试结果和交付情况。
请帮我整理一次复盘，不要写代码。

材料：
【粘贴需求变化、修改内容、Bug、回归结果、验收结果、现场反馈】

请输出：
1. 本阶段目标和实际完成内容。
2. 需求变化统计。
3. 缺陷来源分类。
4. AI 输出质量问题。
5. 回归失败项。
6. 性能和稳定性指标。
7. 交付后问题。
8. 下次必须调整的流程。
9. 应该更新到哪些文档、Prompt 或 Skill。

12. 发给 AI 的工作流优化 Prompt ​

text
请你作为 C# WPF/WinForms 上位机 AI 工作流优化助手。

下面是一次真实项目中的返工、Bug、现场反馈或 AI 输出失败记录。
请不要直接改代码，也不要泛泛总结。

材料：
【粘贴问题现象、日志、截图说明、修改记录、验收结果或复盘记录】

请输出：
1. 这个问题属于需求、设计、通信、Bug、测试、交付还是 Skill 流程问题。
2. 证据是否充分；如果不充分，还缺什么。
3. 应该更新哪一个文档或 Skill 文件。
4. 建议新增或修改的具体规则。
5. 是否需要同步更新回归测试或验收清单。
6. 这条规则适合所有项目，还是只适合某类项目。
7. 下一次如何验证这次优化是否有效。

上位机 AI 开发工作流资料包 | 閑魚：別來無恙 | QQ群：1016188499

Copyright © 2026 別來無恙