上位机 AI 开发工作流

Appearance

脱敏案例：AI 从需求到交付完成一个 WPF 数据采集上位机 ​

这个案例参考了一次真实的 AI 辅助 WPF 上位机开发过程，并做了脱敏处理。

案例不提供原项目源码，不暴露客户、设备、协议细节和业务数据。它重点说明一件事：不要把 AI 当成“一次性生成完整软件”的工具，而要把 AI 放进需求分析、界面设计、技术方案、Codex 实现、测试验收、交付复盘这一整条链路里。

本案例的前半段适合在 Web 端 ChatGPT 里完成，主要用于整理需求、设计界面和推导方案。后半段更适合在 Codex 里完成，因为 Codex 能读取项目文件、分析代码结构、做增量修改、运行验证并沉淀交付记录。

1. 案例背景 ​

项目目标：做一个 WPF 数据采集与设备通信上位机。

脱敏后的典型需求：

  1. 支持串口通信。
  2. 支持 TCP 通信。
  3. 解析自定义设备协议帧。
  4. 处理 CRC 校验、粘包、半包、异常帧。
  5. 显示实时采集数据。
  6. 使用图表显示多通道曲线。
  7. 支持 CSV/BIN 数据保存。
  8. 记录运行日志、错误日志和通信日志。
  9. 提供系统配置窗口。
  10. 支持调试、回归验证、性能优化和阶段交付。

这个案例的重点不是“写出某几个类”，而是把项目拆成 AI 能稳定处理的阶段，并在每个阶段设置输入、输出、人工检查点和质量门。

2. 为什么不能一开始就让 AI 写完整项目 ​

很多人第一次会这样问：

text
帮我做一个 WPF 上位机，可以接收设备数据，显示曲线，保存文件。

这个问法太粗，AI 容易出现这些问题：

  1. 把 UI、通信、协议、保存、日志全部写进一个窗口。
  2. 没有区分真实需求和 AI 推测。
  3. 没有处理粘包、半包、CRC 错误、断线、保存失败。
  4. 图表点数无限增长，运行一段时间后卡顿。
  5. 没有验收标准，最后只能凭感觉判断“差不多完成”。
  6. 后期让 Codex 接手时，项目结构混乱，难以增量修改。

正确流程是先把问题、需求、界面、模块、验收拆清楚，再进入代码实现。

3. 标准全链路流程 ​

推荐按下面顺序跑完整项目（以下为本案例的完整流程，权威定义见 00-先读我-阅读路线.md 第 1.1 节）：

text
轻量背景确认
-> 需求分析
-> 界面与交互设计
-> 技术方案和模块边界
-> 开发任务拆解
-> Codex 读取项目结构
-> 增量实现和修正
-> Bug 调查与最小修复
-> 回归测试与验收
-> 发布交付
-> 复盘沉淀

每一步都要明确：

  1. 输入材料是什么。
  2. AI 应该输出什么。
  3. 人工要检查什么。
  4. 通过什么标准才能进入下一步。

💡 关于本文中的 Prompt 模板

文中出现的 Prompt 是参考模板，展示的是"要告诉 AI 哪些信息"和"AI 应该输出什么"。 实际开发时不需要逐字复制——你只需说清目标、给够上下文、列好约束，AI 就能理解。 一条好的 Prompt 往往就是一句话加上必要的限制条件，而不是十几行的指令。

这里要注意：对接上位机项目的人，通常不是最终行业业务的负责人。他不一定需要完整理解客户行业、实验原理、工艺背景和最终业务价值。真正必须弄清楚的是“软件要做什么、显示什么、控制什么、保存什么、怎么验收”。所以问题定义只做轻量确认，不作为主要工作量。

4. 阶段 0：轻量背景确认 ​

目标 ​

只确认足够支撑需求拆解的背景信息。不要把这一步写成复杂的产品调研，也不要要求用户解释完整行业业务。

这一阶段的目标不是理解客户为什么做这个实验，而是避免 AI 完全不知道软件使用环境，从而在界面、通信、保存、验收上做错判断。

需要提供给 AI 的信息 ​

信息示例
软件类型数据采集、设备控制、测试工装、调试工具
使用场景实验室、产线、客户现场、设备调试现场
使用人员操作员、调试工程师、测试人员、售后人员
连接设备FPGA、单片机、PLC、仪表、电源、传感器
第一阶段目标能连接、能采集、能显示、能保存、能看日志
明确不做不做复杂权限、不做报表、不做多设备并发

可写可不写的信息 ​

下面这些信息有帮助，但不是第一轮必须项：

信息什么时候需要
行业背景需要做正式方案或给甲方讲价值时
实验原理会影响测试流程、判定规则、单位和数据含义时
客户业务目标需要拆验收标准、报表或追溯要求时
现场组织流程多角色、多班次、权限或交接班场景才需要

如果用户只知道“我要做一个采集软件，3 个 ADC 曲线、4 个电源曲线、串口连接、日志、保存数据”，这已经足够进入需求分析。不要卡在行业问题定义上。

推荐 Prompt ​

text
请你作为 C# WPF/WinForms 上位机产品和需求分析助手。

我现在还不想写代码，也不想直接设计项目结构。
请先根据下面信息，帮我做轻量背景确认，并判断是否足够进入需求分析。

已知信息：
【粘贴软件类型、连接设备、使用场景、第一阶段目标】

请输出：
1. 这个软件大概属于什么类型。
2. 已经明确的软件目标。
3. 已经明确的设备和通信信息。
4. 第一阶段最小目标。
5. 暂不需要深挖的行业背景。
6. 进入需求分析前最少还缺什么。

人工检查 ​

检查项通过标准
不过度追问行业背景不要求用户解释完整实验原理或客户业务
软件目标可理解知道大概要采集、显示、控制还是保存
设备和场景大概清楚至少知道连接什么设备、在哪类现场用
能进入需求拆解已经能继续问界面、通信、数据、验收

如果这一阶段信息不全，也不一定要停。只要需求本身足够清楚，可以继续需求分析，并把缺失背景列为“后续确认”。

5. 阶段 1：需求分析 ​

目标 ​

把零散想法、聊天记录、客户文档或技术要求，整理成可开发的第一版需求方案。

对目标用户来说，需求分析是主流程，不是可选项。需求决定界面怎么排、通信怎么做、按钮放哪里、数据怎么保存、后面 Codex 改代码要改哪些模块。

正确拆法 ​

模块要拆清楚什么
业务流程用户先做什么、软件怎么响应、设备返回什么、何时结束
UI 页面主界面、配置页、日志页、历史数据页是否需要
通信串口/TCP、连接参数、收发方向、协议文档、示例报文
协议帧头、长度、类型、数据区、CRC、异常帧
图表显示哪些通道、刷新频率、最大点数
存储保存什么、保存格式、文件路径、文件大小、失败提示
日志运行日志、错误日志、通信日志、是否保存原始报文
验收每个功能如何验证，通过标准是什么

案例中的实际需求提炼 ​

在真实开发过程中，前期讨论的重点不是复杂行业背景，而是不断把软件需求和界面需求说清楚：

需求类别具体内容
主界面布局曲线图和日志尽量显示在同一个 Dashboard，不要拆成多个 Tab
图表数量3 个 ADC 图表，4 个电源通道图表，底部实时日志
串口设置主界面只保留连接/断开入口，详细连接设置进二级配置页
中文化软件名称、按钮、标签、状态信息都要显示中文
协议FPGA 到上位机报文使用 CRC-16/MODBUS，多项式 0xA001，初值 0xFFFF，CRC 高字节在先
UI 细节深色主题下文字要清晰，状态颜色要统一，图表信息框不能像可编辑输入框
视觉回退如果布局优化方向错了，要回退到 3 ADC + 4 电源 + 日志的 Dashboard 布局
功能补充抽采参数配置、手动采样按钮、中文乱码修复

这些信息比“这个实验为什么做”更直接决定开发工作。用户可以不完全懂行业背景，但必须把这些软件需求说清楚。

推荐 Prompt ​

text
我正在做一个 C# WPF/WinForms 上位机项目。下面是我目前能说清楚的粗需求。

请先不要写代码，也不要直接设计项目结构。

请你先把这些零散需求整理成一份第一版需求方案。

要求：
1. 不要假设我已经知道所有技术细节。
2. 不要让我一开始就提供按钮、控件、绑定字段、粘包半包、重连策略这些细节。
3. 请先根据业务目标，反推可能需要的页面、流程、通信、数据、日志和验收点。
4. 对不确定的地方，请列成“需要确认的问题”，不要直接替我决定。

请输出：
1. 项目目标。
2. 使用人员和使用场景。
3. 核心业务流程草案。
4. 功能模块草案。
5. 页面规划草案。
6. 通信需求草案。
7. 数据保存草案。
8. 日志、报警、权限是否需要进一步确认。
9. 第一阶段最小可运行版本建议。
10. 已确认内容。
11. AI 推测内容。
12. 下一步最应该确认的 5-10 个问题。

粗需求如下：
【粘贴需求】

人工检查 ​

检查项通过标准
已确认和 AI 推测分开推测内容没有被当成客户要求
第一阶段范围合理不把全部功能都塞进第一版
关键流程可执行能说清用户从启动到结束怎么操作
通信风险已列出粘包、半包、CRC、超时、断线没有被漏掉
验收标准可测每个核心功能都有验证方法

6. 阶段 2：界面与交互设计 ​

目标 ​

让 AI 先设计用户能看懂、能操作、能验收的界面方案，而不是马上写 XAML。

这一阶段要服务于需求，不要为了"好看"反复重排布局。数据采集上位机的界面重点是同屏观察、状态清楚、操作路径短。

本案例的主界面规划 ​

区域内容设计目的
顶部状态栏连接状态、通信模式、运行状态、接收速率操作员第一眼判断软件是否正常
左侧控制区连接、断开、开始采集、停止采集、配置高频操作集中放置
中间图表区多通道实时曲线观察数据变化趋势
右侧数据区当前值、采样计数、错误计数、设备状态显示关键实时指标
底部日志区运行日志、错误日志、通信摘要出问题时能追踪
配置窗口串口、TCP、保存路径、采样参数把低频配置从主界面移出

案例中的界面经验 ​

一个很重要的经验：当 Dashboard 布局已经接近可用时，不要继续让 AI 大幅重新设计布局。正确做法是锁定布局，再修细节。

应保留的布局：

text
第一行：ADC芯片1 / ADC芯片2 / ADC芯片3
第二行：电源通道1 / 电源通道2
第三行：电源通道3 / 电源通道4
第四行：实时日志，高度约 180~220px

不建议：

  1. 把曲线和日志拆到多个 Tab。
  2. 用 StackPanel 纵向堆叠导致窗口利用率低。
  3. 为了视觉优化减少图表数量。
  4. 删除实时日志区域。
  5. 让串口参数长期占据主界面。

建议：

  1. 主界面只放连接、采集、手动采样、抽采设置等高频操作。
  2. 串口参数、保存路径、配置查看放到菜单或二级配置窗口。
  3. 图表自动填满窗口，使用 Grid 行列布局。
  4. 深色主题下标题、坐标轴、状态文字必须有足够对比度。
  5. 图表无数据时不要显示 double.MaxValue 这类异常数值。

推荐 Prompt ​

text
请帮我设计一个 WPF 工控上位机主界面方案。

请先不要写 WPF 代码，也不要直接生成 XAML。

界面需要支持：
1. 连接设备。
2. 开始和停止采集。
3. 显示多通道实时曲线。
4. 显示当前关键数据和错误计数。
5. 查看运行日志和通信日志。
6. 打开配置窗口设置串口、TCP、保存路径和采样参数。

请输出：
1. 页面区域布局。
2. 每个区域显示什么。
3. 每个区域有哪些操作。
4. 哪些信息必须在主界面，哪些可以放到配置窗口。
5. 按钮状态如何随连接/采集状态变化。
6. 异常状态如何提示。
7. 后续写 XAML 前还需要确认的问题。

人工检查 ​

检查项通过标准
主界面不拥挤高频信息在主界面，低频配置进二级窗口
按钮状态明确未连接、已连接、采集中、异常、断线状态都能判断
异常可见连接失败、CRC 错误、保存失败、断线不会被藏起来
适合现场使用操作路径短，关键状态明显

7. 阶段 3：技术方案和模块边界 ​

目标 ​

把需求和界面方案转换成可维护的 WPF 项目结构。

推荐结构 ​

text
Models/
  AcquisitionData
  DeviceStatus
  AppConfig
  LogEntry
  ProtocolPacket

Views/
  MainWindow
  SettingsWindow
  LogWindow

ViewModels/
  MainViewModel
  SettingsViewModel
  ChartViewModel

Services/
  AcquisitionService
  ConfigService
  LogService
  FileStorageService

Communication/
  IDeviceConnection
  SerialConnection
  TcpClientConnection
  ReceiveQueue

Protocol/
  ProtocolParser
  Crc16
  ProtocolConstants
  PacketFactory

Storage/
  CsvWriter
  BinaryWriter
  FileRotationPolicy

Tests/
  ProtocolParserTests
  StorageTests
  ConfigTests

关键边界 ​

边界正确做法不建议做法
UI 和通信ViewModel 调服务，服务负责通信在按钮事件里直接收发和解析
接收和解析接收线程只收字节，解析器独立组帧接收事件里做 CRC、保存、刷新 UI
解析和业务解析器输出业务对象解析器直接操作界面或写文件
显示和保存显示限频，保存按数据流写入每包数据都刷新 UI 并频繁打开文件
日志和主流程日志异步或批量写入高频日志阻塞通信或 UI

推荐 Prompt ​

text
请根据已经确认的需求方案和界面方案，设计 WPF 上位机技术方案。

请先不要写代码。

请输出：
1. 推荐项目结构。
2. Models、Views、ViewModels、Services、Communication、Protocol、Storage 的职责。
3. 串口和 TCP 是否需要统一接口。
4. 接收、解析、显示、保存、日志的数据流。
5. 线程模型：哪些在后台线程，哪些回到 UI 线程。
6. 关键风险点。
7. 开发顺序。
8. 每个阶段的验收检查点。

人工检查 ​

检查项通过标准
模块职责清楚能说清每个目录负责什么
数据流清楚原始字节到界面显示、文件保存、日志记录路径明确
高风险点已设计协议、线程、文件保存、图表刷新都有策略
开发顺序可执行先骨架，再通信，再协议，再显示，再保存，再优化

8. 阶段 4：开发任务拆解 ​

目标 ​

把“做一个上位机”拆成 Codex 可以逐步完成的小任务。

推荐任务顺序 ​

顺序任务完成标准
1建立 WPF 项目骨架能编译启动，主窗口能打开
2建立 MVVM 基础ViewModel、命令、绑定可用
3做主界面布局状态栏、控制区、图表区、数据区、日志区成型
4做配置窗口串口、TCP、保存路径、采样参数能保存加载
5抽象通信接口串口/TCP 有统一连接、断开、发送、接收事件
6实现串口通信能打开、关闭、发送、接收、异常提示
7实现 TCP 通信能连接、断开、收发、处理断线
8实现协议解析器支持完整帧、半包、粘包、CRC 错误
9接入实时数据流解析后的数据能刷新当前值
10接入图表控制最大点数和刷新频率
11接入文件保存CSV/BIN 能创建、写入、关闭、异常提示
12接入日志UI 日志和文件日志可追踪
13性能优化UI 不明显卡顿，数据不会无限堆积
14回归测试正常路径、异常路径、长稳测试通过
15交付整理发布包、配置说明、已知风险、验收记录完整

已有初版项目时的实际任务顺序 ​

如果已有初版界面和部分功能，可以按以下节奏推进：

顺序任务说明
1锁定 Dashboard 布局3 ADC + 4 电源 + 日志同屏显示
2回退错误布局如果优化后只剩少量图表或大片空白，先回退
3修视觉细节字体、颜色、标题、坐标轴、状态栏可读性
4修图表异常显示关闭数据点标签，避免显示异常数值
5中文化和编码修复界面统一中文，文件保存为 UTF-8
6补抽采参数配置输入抽采倍率，校验范围，发送配置命令
7补手动采样点击按钮发送请求指令，显示成功/失败
8固化协议处理按规则实现 CRC 校验和测试
9做回归验收布局、通信、协议、保存、日志、异常逐项验证

不建议的流程 ​

  1. 一次让 AI 生成整个项目。
  2. 需求没确认就写代码。
  3. UI、通信、协议、保存同时改。
  4. 只验证能编译，不验证真实流程。
  5. 接近交付时还做大重构。

9. 阶段 5：进入 Codex 后先读项目 ​

目标 ​

如果项目已经在 Codex 里做到一部分，第一步不是继续写代码，而是让 Codex 建立项目地图。

Codex 应先检查 ​

检查项目的
项目能否编译判断当前基线是否可用
入口文件和主窗口找到启动路径
Views/ViewModels理解界面和状态绑定
Communication/Protocol理解收发和解析链路
Storage/Logs/Config理解保存、日志、配置
最近修改和未完成项判断继续开发还是先修问题
是否有测试判断验证基础

推荐 Prompt ​

text
请先阅读当前 WPF 上位机项目结构，不要急着改代码。

目标：
【说明当前要完成的功能或交付目标】

请输出：
1. 项目入口和主要页面。
2. 当前模块划分。
3. UI、ViewModel、通信、协议、存储、日志、配置分别在哪些文件。
4. 当前看起来已经完成的功能。
5. 可能缺失或风险较高的功能。
6. 建议下一步先补什么。
7. 如果要继续开发，需要先看哪些文件。

质量门 ​

只有当 Codex 能说明“当前项目有什么、缺什么、风险在哪”时，才进入修改。

10. 阶段 6：项目已经完成 90% 时怎么接管 ​

如果项目功能已经做到 90% 多，不要重新按新项目流程走一遍。应该走“接管审计 -> 补缺 -> 回归 -> 交付”的流程。

第一步：功能盘点 ​

让 Codex 按模块生成状态表：

模块状态证据缺口风险
主界面已完成 / 部分完成 / 未完成对应文件、截图或运行结果
配置窗口已完成 / 部分完成 / 未完成
串口通信已完成 / 部分完成 / 未完成
TCP 通信已完成 / 部分完成 / 未完成
协议解析已完成 / 部分完成 / 未完成
图表显示已完成 / 部分完成 / 未完成
数据保存已完成 / 部分完成 / 未完成
日志已完成 / 部分完成 / 未完成
异常处理已完成 / 部分完成 / 未完成
回归测试已完成 / 部分完成 / 未完成
发布交付已完成 / 部分完成 / 未完成

第二步：按风险补缺 ​

90% 阶段最容易漏的不是“按钮还没放”，而是这些隐性问题：

  1. 断线后 UI 状态没有恢复。
  2. CRC 错误后缓存处理不正确。
  3. 粘包、半包、异常帧没有测试。
  4. 图表长期运行点数过多。
  5. 高频日志导致 UI 卡顿。
  6. 停止采集后文件句柄未释放。
  7. 保存路径无权限时程序崩溃。
  8. 配置保存后没有重新加载或没有应用到通信。
  9. 发布环境缺少 .NET 运行时、驱动或配置文件。
  10. 没有保留上一版和旧配置，现场无法回滚。

第三步：只做最小补齐 ​

对 90% 项目，Codex 每次只处理一个缺口：

text
请基于当前项目做一次功能补缺，不要重构。

本次只处理：
【例如：停止采集后文件释放不完整】

要求：
1. 先说明可能涉及哪些文件。
2. 先给最小修改方案。
3. 不改无关 UI，不改无关通信逻辑。
4. 修改后给出验证步骤。
5. 如果发现影响范围变大，先停下来说明。

第四步：补齐交付材料 ​

90% 功能完成后，至少补这些材料：

材料内容
功能清单已完成、未完成、已知限制
配置说明串口、TCP、保存路径、日志路径
验收清单功能、通信、数据、UI、异常、性能
测试记录编译、启动、模拟器、真实设备、长稳
发布说明版本号、运行环境、依赖、回滚方式
已知风险未测设备、协议待确认、性能边界

11. 阶段 7：通信和协议实现 ​

正确数据流 ​

text
串口/TCP 接收
-> 原始字节进入队列
-> 协议解析器组帧
-> CRC 校验
-> 输出业务数据对象
-> 分发到界面显示、图表、保存、日志

协议解析必须覆盖 ​

场景处理要求
完整帧能正常解析并输出业务数据
半包缓存等待后续数据
粘包连续解析多个完整帧
CRC 错误记录错误，尝试查找下一个有效帧头
噪声字节丢弃无效前缀，不影响后续有效帧
长度异常不越界，不死循环，不清空全部有效缓存

推荐 Prompt ​

text
请设计或检查当前协议解析器。

要求：
1. 接收和解析分开。
2. 支持半包、粘包、CRC 错误和噪声字节。
3. CRC 失败时不能直接清空全部缓存，要尽量找到下一个有效帧头。
4. 解析器只输出业务对象，不直接刷新 UI 或写文件。

请输出：
1. 当前或建议的缓存处理流程。
2. 完整帧判断规则。
3. CRC 校验流程。
4. 错误帧处理策略。
5. 需要补充的测试报文。
6. 对现有代码的最小修改建议。

12. 阶段 8：图表、日志、保存的性能控制 ​

图表 ​

实时曲线不能无限追加数据。

最低要求：

  1. 每条曲线有最大点数。
  2. UI 刷新限频，例如按 100ms、200ms 或 500ms 批量刷新。
  3. 数据保存和界面显示分离。
  4. 不在 UI 线程做大量解析和文件写入。

日志 ​

日志要能定位问题，但不能拖慢界面。

最低要求：

  1. UI 只保留最近 N 条日志。
  2. 文件日志异步或批量写入。
  3. 通信原始报文和普通运行日志可以分开。
  4. 错误日志包含时间、模块、异常、关键参数。

保存 ​

数据采集软件要考虑长时间运行。

最低要求：

  1. 文件按时间、大小或测试批次轮转。
  2. 停止采集时 Flush 和 Dispose。
  3. 保存失败有提示和日志。
  4. 路径不存在或无权限时不崩溃。
  5. CSV 字段和 BIN 格式要有说明。

13. 阶段 9：Bug 调查和最小修复 ​

不要直接让 AI 大改 ​

Bug 阶段先分级：

等级示例处理方式
L1文案、按钮位置、简单样式直接小改 + 当前页面验证
L2绑定错误、空值、路径错误快速修复 + 相关功能验证
L3普通功能异常轻量分析 + 最小修复
L4通信、协议、偶发、性能问题先调查根因，再修复
L5真实设备、数据、发布版本完整风险评估和回归

推荐 Prompt ​

text
请先帮我判断这个上位机问题属于哪个等级，不要一上来就改代码。

问题现象：
期望效果：
是否能复现：
截图/报错/日志：
是否涉及通信、数据保存、协议解析、线程、真实设备：

请输出：
1. 建议等级。
2. 为什么是这个等级。
3. 应该直接修、快速修、轻量分析，还是完整调查。
4. 需要我补充哪些材料。
5. 最小处理路径。

典型问题 ​

问题常见根因验证重点
CRC 错误后一直解析失败错误帧后清空缓存或没有重新找帧头异常帧后继续发送正常帧
图表运行一段时间卡顿点数无限增长或刷新过频长时间运行和内存趋势
停止采集后文件被占用没有 Flush/Dispose停止后重新开始采集
断线后按钮状态不对状态机不完整断线、重连、手动断开
保存失败程序崩溃路径权限和异常未处理无权限路径、磁盘满、路径不存在

14. 阶段 10：回归测试与验收 ​

回归不是机械全测 ​

先问三个问题：

  1. 这次改了什么？
  2. 可能影响什么？
  3. 哪些问题开发时不容易触发？

本案例最低回归范围 ​

分类验证项
编译启动Release/Debug 能编译，软件能启动
UI页面能打开，按钮状态正确，数据刷新正常
通信串口/TCP 能连接、断开、发送、接收
协议完整帧、半包、粘包、CRC 错误、噪声字节
图表曲线刷新，点数有限制，运行一段时间不卡顿
保存CSV/BIN 能创建、写入、关闭，失败有提示
日志UI 日志、文件日志、异常日志可追踪
配置参数能加载、保存、应用，错误参数有提示
异常断线、超时、路径无权限、错误帧不崩溃
长稳连续运行 30 分钟、1 小时或按交付要求测试

验收表模板 ​

需求编号需求/技术要求验收方法通过标准结果备注
R-001软件能连接指定设备连接真实设备或模拟器状态显示在线，日志有连接记录通过 / 不通过
R-002能显示实时数据发送测试报文界面数值和报文一致通过 / 不通过
R-003能保存采集数据完成一次采集文件存在，字段完整，可打开通过 / 不通过
R-004能处理异常帧发送 CRC 错误和半包报文不崩溃，后续正常帧可解析通过 / 不通过
P-001连续运行稳定连续运行指定时长无崩溃、无明显卡顿、内存可接受通过 / 不通过

推荐 Prompt ​

text
请根据当前上位机项目需求和最近修改内容，生成回归测试和验收清单。

要求：
1. 不要机械列全量清单，请先判断影响范围。
2. 验收项必须和需求功能项、技术要求、性能要求对应。
3. 每个验收项要包含验收方法和通过标准。
4. 标出必须人工确认的项目。

材料：
【粘贴需求方案、修改内容、已完成模块、已知风险】

15. 阶段 11：发布交付 ​

交付前必须确认 ​

检查项内容
版本号发布包名称、程序版本、日期
运行环境Windows 版本、.NET 运行时、驱动、权限
配置文件默认串口、IP、端口、保存路径、日志路径
数据目录是否自动创建，是否可写
日志目录是否可写，是否需要清理策略
回滚方式保留上一版程序和旧配置
已知风险哪些设备、场景、性能边界未完全验证
验收记录功能、通信、数据、异常、性能结果

交付包建议结构 ​

text
Release/
  App/
    上位机程序.exe
    依赖文件
  Config/
    默认配置示例
  Docs/
    使用说明.md
    配置说明.md
    验收记录.md
    已知风险.md
  Logs/
    空目录或说明

发布前 Prompt ​

text
请作为上位机项目发布检查助手，帮我检查是否可以交付。

当前版本：
已完成功能：
测试记录：
运行环境：
配置文件：
已知风险：

请输出：
1. 是否建议交付：可以 / 有条件可以 / 不建议。
2. 缺失材料。
3. 发布包应包含哪些文件。
4. 现场部署步骤。
5. 回滚方案。
6. 必须人工确认的风险。

16. 阶段 12：复盘沉淀 ​

项目交付后不要只停在“完成”。至少记录：

  1. 哪些需求后来变了。
  2. 哪些问题是需求没问清导致的。
  3. 哪些问题是 AI 代码导致的。
  4. 哪些 Bug 是测试遗漏导致的。
  5. 哪些 Prompt 最有效。
  6. 哪些模板应该更新。

复盘 Prompt ​

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

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

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

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

17. 对原流程的修正建议 ​

结合这个案例，原流程里最需要修正的是：

  1. 不要把“问题定义”写得过重。目标用户主要关心接到项目后怎么把需求变成软件，不需要完整掌握最终客户的行业业务。
  2. 需求分析要作为主流程。用户必须说清软件要显示什么、控制什么、保存什么、通信协议是什么、怎么验收。
  3. 界面设计要跟着需求走。像数据采集软件，Dashboard 同屏显示比多 Tab 更合适。
  4. 当界面布局已经接近可用时，不要继续让 AI 大改布局。应该锁定布局，只修颜色、字体、状态、交互细节。
  5. 不要在 Web 端直接要求生成完整 WPF 项目；Web 端更适合做需求、界面、协议和 Codex 指令。
  6. 进入 Codex 后，第一步应该是读项目结构和建立项目地图，不是继续凭记忆写代码。
  7. 如果项目已完成 90%，不要重做架构，应该做功能盘点、风险补缺和回归验收。
  8. 通信、协议、线程、保存、发布这些高风险内容，不能只凭“能跑”判断完成。
  9. 每次修改必须有影响范围和回归清单。
  10. 最终交付必须包含配置说明、运行环境、验收记录和回滚方案。

18. 这个案例给用户的实际用法 ​

如果用户是从 0 开始：

  1. 先做轻量背景确认：知道软件类型、连接设备、使用场景即可，不要卡在行业问题定义上。
  2. 重点填写 11-上位机项目需求拆解表.md：功能、界面、通信、数据、日志、验收必须说清楚。
  3. 如果背景确实很模糊，再补读 10-问题定义与用户场景.md，但它不是每个项目的硬门槛。
  4. 用 Web 端 ChatGPT 整理需求、界面方案、协议说明和 Codex 修改指令。
  5. 用 12-AI开发质量门.md 判断能不能进入技术方案。
  6. 进入 Codex 后先读项目结构，再分阶段实现。
  7. 每个阶段结束后用 30-回归测试与验收清单.md 做验证。
  8. 交付后用 31-度量复盘与经验沉淀.md 复盘。

如果用户已有 90% 项目：

  1. 不要重写。
  2. 让 Codex 先生成项目地图。
  3. 按模块盘点已完成、未完成和风险项。
  4. 每次只补一个缺口。
  5. 优先补通信异常、协议边界、保存释放、图表性能、日志追踪和发布材料。
  6. 最后按验收清单和发布检查完成交付。

19. 案例边界 ​

这个案例用于学习项目拆解和 AI 协作流程。

  1. 它展示方法论、流程、检查点和提示词。
  2. 它不包含原项目源码。
  3. 它不代表可以直接复制生成所有同类项目。
  4. 真实项目仍然要结合设备、协议、源码、测试环境和人工审核。
  5. 涉及真实设备动作、生产数据、客户现场交付时，必须人工确认安全风险。

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

Copyright © 2026 別來無恙