上位机项目需求拆解表
这个表是整套资料包的核心骨架，但它不是让你一开始就写完整技术规格书。
📋 什么时候必须填、什么时候不用：
- 新项目 / 大功能开发：必填。不填清楚后面全乱。
- 小改功能 / UI 微调：不用。说明目标+影响范围就够了。
- 修复 Bug：不用填整张表。说清现象+期望效果+涉及文件。
- 不确定时：只填第一轮骨架，后面让 AI 帮你补。
真实项目的需求通常是模糊的、零散的、想到哪说到哪。正确做法不是一开始就把按钮、表格、协议细节、日志规则、权限和性能全部填满，而是先把项目大方向搭起来，再让 AI 帮你一步一步细化。
💡 很多拆解工作不需要人工做。 如果你在用 Codex，按
Shift+Tab进入 Plan 模式，直接说"我要做一个 XXX 上位机"，AI 会自动输出数据库设计、接口定义、页面规划、测试用例。你只需要审查、指出遗漏、确认后让它执行。人工只需要做两件事：说清楚目标、做最终确认。中间的分析和拆解让 AI 完成。
如果你连用户是谁、现场怎么用、当前痛点和第一阶段成功标准都还没想清楚，先填写 10-问题定义与用户场景.md。这一步完成后，再回到本表拆功能、页面、通信、数据和验收。
使用原则
- 第一轮只填你现在确定的内容。
- 不确定的地方直接写“不确定”。
- 不要强行猜按钮、控件、绑定字段、粘包半包、重连策略这些技术细节。
- 先让 AI 根据粗需求整理成需求方案。
- 需求方案出来后，再让 AI 反问缺失信息。
- 先确认软件是干什么的，再讨论页面怎么分、通信怎么做、数据怎么存。
- 每次只细化一个方向，不要一次把所有问题都展开。
- 需求确认通常不是一次完成，而是多轮迭代：先粗框架，再追问，再细化，再确认版本。
0. 需求确认的迭代闭环
上位机需求不是一次问清楚的。很多时候用户一开始只有一句模糊想法，或者手上有一份需求说明书，但自己也没完全理解里面的技术含义。
💡 用 Codex Plan 模式可以加速前三轮。 切到 Plan 模式（
Shift+Tab），AI 会自动搭框架、修正理解偏差、细化核心流程。你只需要审查和补充后两轮（细化关键模块 + 准备开发）。如果你不用 Codex 或用普通 ChatGPT，则手动走完五轮。
推荐按这个闭环推进：
问题定义 -> 粗需求 -> AI 整理第一版方案 -> 用户确认/纠正 -> AI 追问关键缺口 -> 单模块细化 -> 形成第二版方案 -> 再确认 -> 质量门检查 -> 进入开发拆解每一轮都只解决一个目标：
| 轮次 | 目标 | 用户做什么 | AI 做什么 | 输出 |
|---|---|---|---|---|
| 第 1 轮 | 搭项目框架 | 说清楚大概想做什么 | 整理第一版需求方案 | 项目目标、核心功能、初步页面和流程 |
| 第 2 轮 | 修正理解偏差 | 确认哪里对、哪里不对 | 修改方案并列关键问题 | 第二版需求方案 |
| 第 3 轮 | 细化核心流程 | 补充真实操作步骤 | 拆业务流程和页面交互 | 可执行的业务流程 |
| 第 4 轮 | 细化关键模块 | 按需补通信、数据、日志、报警 | 拆模块职责和风险点 | 可开发的模块需求 |
| 第 5 轮 | 准备开发 | 确认第一阶段范围 | 输出开发顺序和验收点 | 第一阶段任务清单 |
不要追求第一轮就完整。第一轮的目标只是搭出框架，让用户看到框架后继续想清楚哪里缺、哪里不对、哪里需要补。
进入技术方案前，建议用 12-AI开发质量门.md 检查需求确认门。如果关键流程、设备、数据或验收标准还没说清楚，不要直接让 AI 写代码。
0.1.1 需求到交付的追踪关系
工控软件和上位机项目里，需求不能只停留在“功能列表”。每条重要需求最好能追踪到设计、任务、代码和验收证据。
建议给需求编号：
F-001 功能需求
C-001 通信需求
D-001 数据需求
U-001 界面需求
E-001 异常处理需求
P-001 性能和稳定性需求
S-001 安全或设备动作需求最小追踪表：
| 需求编号 | 需求内容 | 设计/模块 | 开发任务 | 验收方法 | 证据 |
|---|---|---|---|---|---|
| F-001 | 连接设备并显示在线状态 | 通信服务、主界面状态区 | 实现连接/断开状态 | 连接真实设备或模拟器 | 连接日志、界面截图 |
| C-001 | 正确解析设备上传数据 | 协议解析器、接收缓存 | 实现组帧、CRC、业务对象输出 | 正常帧、半包、粘包、CRC 错误测试 | TX/RX/PARSE 日志 |
| D-001 | 保存测试结果 | 数据服务、导出模块 | 实现保存和导出 | 完成一次测试并检查文件字段 | 导出文件样例 |
这张表不要求一开始填满。第一阶段只要把核心需求追踪起来，后续每次新增功能或修改协议时再补充。
发给 AI 时可以这样说：
请根据下面需求方案生成需求追踪表。
要求：
1. 给重要需求自动编号。
2. 每条需求要能对应到设计模块、开发任务和验收方法。
3. 区分功能、通信、数据、界面、异常、性能、安全需求。
4. 不确定的验收方法请标注为待确认。
5. 不要为了完整而编造客户没有要求的功能。
需求方案如下：
【粘贴需求方案】0.1 两种常见入口
入口 A：只有模糊想法
适合这种情况：
我想做一个设备采集软件，可以连设备，显示数据，保存结果，最好有个界面。这种情况不要急着问协议、按钮、数据库、权限。先让 AI 帮你搭框架：
- 软件目标是什么。
- 谁使用。
- 现场怎么操作。
- 可能有哪些核心功能。
- 第一阶段最小版本是什么。
- 哪些信息下一轮必须确认。
入口 B：已经有需求说明书或技术要求
适合这种情况：
我手上有客户给的需求说明书、技术协议、招标要求、设备说明文档或聊天记录。这种情况也不要直接让 AI 写代码。先让 AI 做“需求翻译”和“可执行拆解”：
- 把文档里的自然语言要求翻译成软件功能。
- 区分必须做、可选做、不清楚、存在风险的内容。
- 把大段要求拆成页面、流程、通信、数据、日志、验收。
- 找出文档里没有说清楚但开发必须确认的问题。
- 形成第一阶段开发范围。
0.2 三层填写方式
| 层级 | 目的 | 什么时候填 | 要求 |
|---|---|---|---|
| 第一层：必填骨架 | 先让 AI 知道项目大概是什么 | 第一次沟通 | 尽量用自然语言写，不需要专业 |
| 第二层：AI 初步拆解 | 让 AI 根据骨架反推页面、流程、模块 | 第一层填完后 | AI 输出方案，你来确认对不对 |
| 第三层：专项细化 | 对通信、数据、日志、验收等逐步补充 | 方案基本确认后 | 按项目需要选择填写，不是每项都必填 |
1. 第一层：项目必填骨架
这一部分是第一次必须尽量说清楚的内容。只要能说清楚大方向，后面才有细化的基础。
| 项目项 | 填写内容 |
|---|---|
| 项目名称 | 例如：电机测试上位机、温控采集软件、设备调试工具 |
| 项目类型 | 数据采集 / 设备控制 / 测试工装 / 参数配置 / 监控看板 / 调试工具 / 其他 |
| 新项目还是已有项目 | 新项目 / 已有项目改造 / 只修 Bug / 只做某个模块 |
| 当前阶段 | 只有想法 / 有界面 / 有通信 / 已能运行 / 有 Bug / 准备交付 |
| 软件主要解决什么问题 | 用自然语言说明，例如：采集设备数据并保存、控制设备完成测试、给设备下发参数 |
| 谁使用这个软件 | 操作员 / 调试工程师 / 测试人员 / 售后人员 / 自己使用 |
| 在哪里使用 | 实验室 / 产线 / 设备调试现场 / 客户现场 / 教学演示 / 不确定 |
| 连接什么设备 | PLC、单片机、仪表、电源、扫码枪、传感器、运动控制卡等；不知道型号也可以先写设备类型 |
| 大概有哪些功能 | 用列表写，例如：连接设备、读取数据、设置参数、开始测试、保存结果、查看日志 |
| 最想先做出来的版本 | 第一阶段最小可运行版本，只写最核心功能 |
| 已知限制 | 工控机配置、系统版本、必须用 WPF/WinForm、必须离线运行等 |
2. 第一轮可以这样描述
如果你还没有完整需求，可以先按这种方式写：
我想做一个上位机软件，主要用于：
【写软件用途】
使用人员：
【谁用】
使用现场：
【在哪里用】
连接设备：
【连接什么设备，通信方式知道就写，不知道就写不确定】
大概功能：
1.
2.
3.
第一阶段我最想先实现：
1.
2.
3.
现在不确定的地方：
1.
2.
3.3. 第二层：让 AI 先整理需求方案
第一层填完后，不要直接让 AI 写代码。
先把下面 Prompt 发给 AI：
我正在做一个 C# WPF/WinForm 上位机项目。下面是我目前能说清楚的粗需求。
请先不要写代码，也不要直接设计项目结构。
请你先把这些零散需求整理成一份第一版需求方案。
要求：
1. 不要假设我已经知道所有技术细节。
2. 不要让我一开始就提供按钮、控件、绑定字段、粘包半包、重连策略这些细节。
3. 请先根据我的业务目标，反推可能需要的页面、流程、通信、数据、日志和验收点。
4. 对不确定的地方，请列成“需要确认的问题”，不要直接替我拍死。
请输出：
1. 项目目标。
2. 使用人员和使用场景。
3. 核心业务流程草案。
4. 功能模块草案。
5. 页面规划草案。
6. 通信需求草案。
7. 数据保存草案。
8. 日志、报警、权限是否需要进一步确认。
9. 第一阶段最小可运行版本建议。
10. 已确认内容。
11. AI 推测内容。
12. 下一步最应该确认的 5-10 个问题。
粗需求如下：
【粘贴第一层内容】3.1 如果你已经有需求说明书
如果你手上有完整需求说明书、技术协议、客户文档或聊天记录，可以用下面 Prompt：
我手上有一份上位机项目需求说明书/技术要求。请先不要写代码，也不要直接设计项目结构。
请你先帮我把这份文档拆成可执行的软件需求。
要求：
1. 不要照抄原文，要翻译成上位机开发能执行的功能点。
2. 区分“明确要求”“AI 推测”“需要客户确认”“可能有风险”。
3. 不要默认所有功能都第一阶段完成，请帮我拆第一阶段最小可运行版本。
4. 页面、通信、数据、日志、权限、验收都先做初步拆解，不清楚的地方列问题。
5. 每次只追问最关键的问题，不要一次问几十个细节。
请输出：
1. 需求摘要。
2. 功能模块拆解。
3. 业务流程草案。
4. 页面规划草案。
5. 通信和协议需求。
6. 数据保存需求。
7. 日志、报警、权限需求。
8. 第一阶段范围。
9. 风险点。
10. 下一轮需要确认的问题。
需求说明书/技术要求如下：
【粘贴文档内容】4. 第三层：根据 AI 方案逐步细化
AI 输出第一版需求方案后，再按下面方向逐步细化。不是每个项目都需要全部填写。
4.1 使用场景细化
这一部分不用一开始就特别准确，能描述大概流程即可。
| 项目项 | 填写内容 |
|---|---|
| 使用人员怎么操作 | 例如：打开软件 -> 连接设备 -> 设置参数 -> 开始采集 -> 查看结果 |
| 软件输入来自哪里 | 人工输入 / 扫码枪 / 设备上传 / 文件导入 / 不确定 |
| 软件输出给谁看 | 操作员现场看 / 工程师调试看 / 保存给后续追溯 / 导出给客户 |
| 设备大概会返回什么 | 数值 / 状态 / 报警 / 测试结果 / 原始报文 / 不确定 |
| 软件大概会控制什么 | 只读数据 / 下发参数 / 启停设备 / 执行测试 / 不确定 |
| 现场最怕什么问题 | 数据丢失 / 设备断线 / 操作误点 / 程序卡死 / 结果不准 |
4.2 UI 界面需求细化
页面不是固定的，不是所有项目都需要“参数配置页、实时数据页、历史数据页、报警页”。
先写业务目标，再让 AI 设计页面和控件。
| 项目项 | 填写内容 |
|---|---|
| 用户打开软件后第一眼要看到什么 | 设备状态、当前数据、测试按钮、结果、曲线、日志等 |
| 用户最常用的操作是什么 | 连接、开始、停止、设置参数、保存、导出、查询等 |
| 哪些信息必须一直显示 | 在线状态、当前值、报警状态、测试结果、运行时间等 |
| 哪些信息可以放到二级页面 | 参数设置、历史查询、日志详情、用户管理等 |
| 是否有参考界面或截图 | 有就提供，没有就让 AI 先设计草图 |
| 界面风格偏好 | 工控简洁 / 深色看板 / 触摸屏 / 普通桌面软件 / 不确定 |
发给 AI 时可以这样说：
请根据下面业务功能帮我规划 WPF 上位机页面。
我不确定具体需要哪些控件、按钮、表格和绑定字段，请你根据使用流程先设计。
业务功能：
【粘贴功能和操作流程】
请输出：
1. 建议分几个页面或区域。
2. 每个页面/区域解决什么问题。
3. 每个页面需要显示哪些信息。
4. 每个页面需要哪些主要操作。
5. 哪些内容应该放主界面，哪些可以放二级页面。
6. 需要我确认的问题。4.3 通信需求细化
通信第一轮只需要知道“怎么连”和“有没有协议”。粘包半包、心跳、重连、CRC 等是 AI 和开发时需要主动考虑的风险，不应该一开始要求用户全部判断。
| 项目项 | 填写内容 |
|---|---|
| 通信方式 | 串口 / TCP / UDP / Modbus / HTTP / 不确定 |
| 设备角色 | 软件主动连接设备 / 设备连接软件 / 不确定 |
| 连接参数 | 串口号、波特率、IP、端口；不知道就写不确定 |
| 有没有协议文档 | 有 / 没有 / 只有示例 / 需要现场抓包 |
| 有没有示例报文 | 有就粘贴；没有就写暂无 |
| 通信频率大概怎样 | 手动点击 / 定时读取 / 设备主动上报 / 高频采集 / 不确定 |
| 通信异常最担心什么 | 收不到数据 / 数据错 / 断线 / 卡死 / 不确定 |
发给 AI 时可以这样说：
请根据下面已知通信信息，帮我整理通信需求和风险点。
我不确定是否有粘包半包、是否需要心跳、是否需要断线重连、CRC 怎么做，请你根据通信方式和协议特点主动分析。
已知通信信息：
【粘贴通信方式、连接参数、协议文档或示例报文】
请输出：
1. 通信方式判断。
2. 需要确认的连接参数。
3. 协议是否完整。
4. 是否需要考虑粘包半包、超时、重连、心跳、CRC。
5. 建议的通信模块职责。
6. 需要我继续补充的材料。4.4 业务流程细化
业务流程不能固定成启动、连接、采集、测试、停止。不同软件的流程不同，应该按真实业务写。
先用自然语言写“人怎么操作，软件怎么响应，设备怎么变化”。
| 步骤 | 人做什么 | 软件显示/处理什么 | 设备动作/返回什么 | 不确定点 |
|---|---|---|---|---|
| 1 | ||||
| 2 | ||||
| 3 | ||||
| 4 |
示例：
| 步骤 | 人做什么 | 软件显示/处理什么 | 设备动作/返回什么 | 不确定点 |
|---|---|---|---|---|
| 1 | 打开软件 | 加载上次配置 | 无 | 是否自动连接 |
| 2 | 点击连接 | 显示在线状态 | 设备返回状态 | 是否需要握手 |
| 3 | 点击开始测试 | 显示测试中 | 设备开始返回数据 | 判定规则不确定 |
4.5 数据存储细化
数据存储先确认“要不要保存”和“保存什么”，不要一开始就纠结表字段、索引、保留周期。
| 项目项 | 填写内容 |
|---|---|
| 是否需要保存数据 | 需要 / 不需要 / 不确定 |
| 主要保存什么 | 测试结果 / 实时数据 / 报警记录 / 操作记录 / 参数配置 |
| 保存后用来干什么 | 查询 / 导出 / 追溯 / 报告 / 只是留底 |
| 数据量大概怎样 | 很少 / 每次测试一条 / 每秒多条 / 长时间运行 / 不确定 |
| 希望保存成什么 | CSV / Excel / SQLite / MySQL / 不确定 |
| 是否需要查询导出 | 需要 / 不需要 / 不确定 |
4.6 日志、报警、权限
这些不是所有项目都要重做，先判断需不需要。
| 项目项 | 填写内容 |
|---|---|
| 是否需要日志 | 不需要 / 简单运行日志 / 通信日志 / 错误日志 / 完整操作日志 |
| 是否需要报警 | 不需要 / 简单提示 / 报警列表 / 历史报警 / 报警确认 |
| 是否需要权限 | 不需要 / 简单登录 / 管理员和操作员 / 更复杂权限 |
| 哪些异常必须提示 | 断线、超时、保存失败、数据超限、设备报警等 |
| 哪些内容必须留记录 | 操作、通信、错误、报警、测试结果等 |
4.7 性能与稳定性
先抓通用约束，不要一开始写过细参数。
| 项目项 | 填写内容 |
|---|---|
| 是否需要长时间运行 | 不需要 / 几小时 / 8 小时 / 24 小时 / 多天 |
| 数据刷新是否频繁 | 很低 / 一秒一次 / 一秒多次 / 高频 / 不确定 |
| 数据量是否大 | 很少 / 中等 / 很大 / 不确定 |
| 电脑配置是否一般 | 普通电脑 / 工控机 / 低配置 / 不确定 |
| 是否连接真实设备 | 是 / 否 / 先模拟 |
| 最担心的稳定性问题 | 卡死、断线、数据丢失、误操作、崩溃 |
4.8 验收标准
验收标准先抓通用项，后面再细化。
| 验收项 | 怎么算通过 |
|---|---|
| 软件能启动 | 能正常打开主界面，没有启动报错 |
| 核心功能能跑通 | 第一阶段核心流程能完整操作一遍 |
| 通信能验证 | 能连接设备或模拟设备，能看到预期数据 |
| 数据能保存 | 需要保存的数据能正确保存和打开 |
| 异常有提示 | 断线、参数错误、保存失败等有明确提示 |
| 界面可操作 | 主要按钮、状态显示、数据刷新符合预期 |
| 不明显卡顿 | 普通操作下界面不卡死 |
| 修改不破坏旧功能 | 已有功能还能正常使用 |
5. 已有项目改造时填写
如果是新项目，这一节可以跳过。
已有项目改造也不要一开始强行找文件。先描述目标和现象，让 AI 判断需要哪些材料。
| 项目项 | 填写内容 |
|---|---|
| 当前项目能否运行 | 能 / 不能 |
| 当前主要问题 | 编译错误、运行异常、界面问题、通信问题、数据保存问题 |
| 本次想改什么 | 用自然语言写，例如：连接成功后按钮变成关闭 |
| 当前现象 | 现在软件是什么样，或者现在有什么问题 |
| 期望效果 | 希望改完后是什么样 |
| 不希望影响什么 | 例如：不要影响采集、保存、日志、原有界面风格 |
| 相关材料 | 截图、日志、报错、项目结构；知道文件名再写文件名 |
| 验证方式 | 怎么判断修改成功 |
6. 风险边界
这些问题不一定一开始全知道，但如果涉及，要尽早告诉 AI。
| 风险项 | 是否涉及 | 说明 |
|---|---|---|
| 真实设备控制 | 是 / 否 / 不确定 | 是否控制电机、气缸、加热、运动机构等 |
| 高危险动作 | 是 / 否 / 不确定 | 是否可能造成人身、设备或财产风险 |
| 数据不可丢失 | 是 / 否 / 不确定 | 是否涉及生产记录、质量追溯 |
| 高频采集或长时间运行 | 是 / 否 / 不确定 | 是否有 UI 卡死、数据堆积风险 |
| 数据库结构变更 | 是 / 否 / 不确定 | 已有项目是否会改表结构 |
| 协议不完整 | 是 / 否 / 不确定 | 协议文档是否缺失或需要现场验证 |
| 现场环境复杂 | 是 / 否 / 不确定 | 网络不稳定、设备多、工控机权限受限 |
7. 第一轮发给 AI 的标准提示词
填完第一层骨架后，复制下面这段：
我正在做一个 C# WPF/WinForm 上位机项目。下面是我目前能说清楚的第一轮需求。
请先不要写代码，也不要直接设计项目结构。
这些需求还不完整，有些地方我也不确定。请你先帮我整理成第一版需求方案，并指出哪些地方需要继续确认。
要求：
1. 先理解软件是干什么的、谁用、在哪用、大概有哪些功能。
2. UI 页面不要套固定模板，请根据业务功能和使用流程来规划。
3. 通信部分我只提供已知信息，粘包半包、心跳、重连、CRC 等请你主动作为风险点分析。
4. 业务流程不要固定成某一种流程，请根据我的项目实际内容整理。
5. 日志、报警、权限、性能先判断是否需要，不要默认全部做重。
6. 输出时区分“已确认内容”“AI 推测内容”“需要我确认的问题”。
请输出：
1. 项目目标。
2. 使用场景。
3. 第一阶段核心功能。
4. 业务流程草案。
5. 页面规划草案。
6. 通信需求草案。
7. 数据保存草案。
8. 日志/报警/权限是否需要。
9. 性能和稳定性风险。
10. 第一阶段验收标准。
11. 下一步最应该确认的 5-10 个问题。
第一轮需求如下：
【粘贴第一层内容】8. AI 输出检查清单
AI 给出第一版需求方案后，用下面清单检查：
- 是否先整理需求方案，而不是直接写代码或直接设计项目结构。
- 是否区分了已确认、AI 推测、需要确认的问题。
- 是否没有强行套固定页面模板。
- 是否没有要求用户一开始就提供按钮、控件、绑定字段。
- 是否没有要求用户一开始就判断粘包半包、心跳、重连等通信细节。
- 是否根据业务实际整理流程，而不是固定套启动、连接、采集、测试。
- 是否给出了第一阶段最小可运行版本。
- 是否把日志、报警、权限作为可选项判断，而不是默认全部重做。
- 是否给出了下一步最该确认的问题。
如果以上内容不完整，先让 AI 补充需求拆解，不要急着进入代码阶段。