Appearance
AI 开发质量门
这份文件解决一个问题：什么时候可以进入下一步，什么时候必须停下来补信息、补设计或补测试。
AI 辅助开发最容易出问题的地方，不是不会写代码，而是跳过了关键确认点。需求没确认就设计，设计没确认就写代码，代码没验证就交付，最后容易变成"看起来完成了，现场一跑就出问题"。
质量门适用于中高风险任务（通信、数据库、线程、真实设备、正式交付）。低风险小改（拼写、按钮位置、简单样式）可以跳过，不用走完整质量门流程。
1. 总原则
每个阶段都要回答三个问题：
- 当前阶段的输入够不够。
- 当前阶段的输出能不能被人检查。
- 进入下一阶段会不会带着明显风险。
如果答案不清楚，就不要进入下一阶段。
1.1 先选协作模式
质量门不是要求所有任务都走重流程。每次开始前，先判断用哪种 AI 协作模式。
| 模式 | 适合任务 | AI 可以做什么 | 必须限制什么 |
|---|---|---|---|
| 自主发挥模式 | 需求模糊、低风险小改、初步方案、普通页面调整 | 反推问题、给方案、拆任务、建议材料 | 不直接大改代码，不替用户确认高风险需求 |
| 详细模板模式 | 新项目、大功能、通信、数据库、线程、真实设备、交付验收 | 按模板整理需求、设计、任务、验收 | 不跳过确认，不把推测当要求 |
切换规则：
- 一开始不知道怎么说，可以先用自主发挥模式。
- AI 一旦要写代码、改通信、改数据库、改线程或碰真实设备，就切到详细模板模式。
- 小改可以保持自主发挥模式，但要有最便宜验证。
- 出现返工、误改、需求不清或影响范围扩大时，立刻切到详细模板模式。
推荐 Prompt：
text
请先判断本任务应该用“自主发挥模式”还是“详细模板模式”。
如果是自主发挥模式，请先根据我的自然语言目标反推方案、需要的材料和最小任务拆解。
如果是详细模板模式，请按需求、设计、任务、风险、验收逐步输出，不要直接写代码。
任务如下：
【描述目标或问题】2. 备份与可恢复性门
AI 辅助开发有风险。它可能误改文件、扩大修改范围、删除原有逻辑，甚至在编码异常、工具异常或误操作时把文件改坏。上位机项目往往包含通信、协议、配置、日志、界面和发布文件，一旦改乱又没有备份，恢复成本会很高。
所以，在让 AI 修改任何代码、XAML、配置、项目文件或交付文档之前，必须先确认“能恢复”。
2.1 推荐备份方式
| 方式 | 推荐程度 | 说明 |
|---|---|---|
| Git / GitHub / Gitee | 强烈推荐 | 最适合长期项目，可以查看差异、回退版本、保留修改历史 |
| 本地压缩包备份 | 推荐 | 适合不会 Git 的用户，修改前把整个项目复制或压缩一份 |
| Skill 自带本地文件备份 | 推荐 | host-computer-dev Skill 写入前会做本地备份，适合降低 AI 改坏文件的风险 |
| 只靠“撤销” | 不推荐 | 多文件修改、工具自动写入或关闭软件后可能无法恢复 |
2.2 最低要求
进入代码修改前，至少满足下面任意一种：
- 项目已经纳入 Git，并且当前状态已经提交或至少确认工作区变更可区分。
- 已经把整个项目复制到一个备份目录。
- 已经把项目压缩成一个备份包。
- 使用
host-computer-devSkill，并确认它会在写入前创建本地备份。
如果是正式交付、真实设备、数据库、协议、线程、项目文件或大量 UI 修改，建议同时使用 Git 和本地备份。
2.3 修改前检查表
| 检查项 | 是否通过 | 备注 |
|---|---|---|
| 当前项目能否恢复到修改前 | 是 / 否 | Git 提交、压缩包、复制目录或 Skill 备份 |
| 是否知道本次 AI 预计修改哪些文件 | 是 / 否 | 不知道就先让 AI 做影响分析 |
| 是否禁止 AI 顺手大改无关文件 | 是 / 否 | 明确写进 Prompt |
| 是否能查看修改差异 | 是 / 否 | Git diff、工具差异视图或人工对比 |
| 是否有回滚方法 | 是 / 否 | 出问题后怎么恢复 |
2.4 推荐给 AI 的备份提示
text
在修改代码前，请先检查当前项目是否有 Git 或可恢复备份。
要求：
1. 不要直接大面积修改文件。
2. 先列出预计修改文件和影响范围。
3. 如果支持本地备份，请先为即将修改的文件创建备份。
4. 修改后请列出实际修改文件。
5. 请说明如果改坏了，应该如何恢复。如果使用 host-computer-dev Skill，可以补一句：
text
请按 host-computer-dev 的写入安全流程执行，写入前创建本地 RecoverySnapshot，修改后做回读检查。3. 阶段质量门总览
text
问题定义 -> 需求确认 -> 技术方案 -> 实现计划 -> 代码修改 -> 回归验收 -> 发布交付 -> 复盘沉淀| 阶段 | 主要产物 | 可以进入下一步的条件 | 不能继续的情况 |
|---|---|---|---|
| 问题定义 | 用户、场景、痛点、成功标准 | 目标和非目标说清楚 | 只知道“做个软件”，不知道谁用、为什么用 |
| 需求确认 | 第一版/第二版需求方案 | 已区分明确要求、AI 推测、待确认项 | 关键流程、设备、数据或验收标准不清楚 |
| 技术方案 | 架构、模块、通信、数据、线程方案 | 模块边界和高风险点明确 | 直接让 AI 建项目或写大段代码 |
| 实现计划 | 文件范围、修改步骤、回滚思路 | 影响范围明确，任务可拆小，备份方式明确 | 一次改 UI、通信、数据库、日志多个方向 |
| 代码修改 | 最小 patch 或增量实现 | 修改只覆盖计划内范围，修改前已有可恢复备份 | 顺手重构、扩大范围、替换无关代码 |
| 回归验收 | 回归清单、验收记录 | 关键正常路径和异常路径通过 | 只看编译通过，没有实际验证 |
| 发布交付 | 发布包、配置说明、已知风险 | 环境、版本、回滚方式明确 | 真实设备或生产环境未经人工审核 |
| 复盘沉淀 | 问题、返工、经验、模板更新 | 记录可复用经验 | 同类问题下次还从头摸索 |
4. 问题定义门
进入 11-上位机项目需求拆解表.md 之前，先确认：
| 检查项 | 是否通过 | 备注 |
|---|---|---|
| 谁使用这个软件 | 是 / 否 | 操作员、调试人员、工程师、客户现场人员 |
| 在什么现场使用 | 是 / 否 | 实验室、产线、客户现场、售后调试 |
| 要解决什么痛点 | 是 / 否 | 手工记录、通信调试、数据追溯、自动测试 |
| 第一阶段成功标准 | 是 / 否 | 能连接、能采集、能保存、能生成报告 |
| 明确不做什么 | 是 / 否 | 暂不做权限、暂不做数据库、暂不做报表 |
| 关键风险 | 是 / 否 | 真实设备、危险动作、生产数据、协议不完整 |
没有通过时，先补 10-问题定义与用户场景.md。
5. 需求确认门
进入技术方案前，必须至少有一版经过人工确认的需求方案。
建议检查：
| 检查项 | 是否通过 | 备注 |
|---|---|---|
| 项目目标明确 | 是 / 否 | 不只是功能列表 |
| 操作流程明确 | 是 / 否 | 谁先点什么、设备什么时候响应 |
| 页面需求明确 | 是 / 否 | 要显示什么、操作什么、提示什么 |
| 通信需求明确 | 是 / 否 / 不涉及 | 串口/TCP、协议、示例报文、异常 |
| 数据需求明确 | 是 / 否 / 不涉及 | 保存字段、格式、路径、查询、导出 |
| 验收标准明确 | 是 / 否 | 每个重要需求可验证 |
| AI 推测已标注 | 是 / 否 | 不能把推测当客户要求 |
| 待确认项已处理 | 是 / 否 | 关键问题不能留到编码阶段 |
如果还有关键待确认项，只能做问题清单或备选方案，不要进入代码实现。
6. 技术方案门
进入代码实现前，必须先确认：
| 检查项 | 是否通过 | 备注 |
|---|---|---|
| 技术栈明确 | 是 / 否 | WPF/WinForms、.NET 版本、图表库、数据库 |
| 模块边界明确 | 是 / 否 | View、ViewModel、Service、Model、Storage |
| 通信线程模型明确 | 是 / 否 / 不涉及 | 接收、解析、分发、UI 刷新不能混在一起 |
| 数据流明确 | 是 / 否 | 从设备到显示、保存、报警、日志 |
| 高风险点明确 | 是 / 否 | 协议、线程、数据库、真实设备、发布版本 |
| ADR 已记录 | 是 / 否 / 不需要 | 重要技术选择要留下理由 |
| 测试策略明确 | 是 / 否 | 最少要知道怎么验证 |
如果技术方案没有通过，只能继续让 AI 做设计，不要让 AI 直接生成完整项目。
7. 实现计划门
每次修改前，先让 AI 输出影响分析和最小修改计划。
| 检查项 | 是否通过 | 备注 |
|---|---|---|
| 本次只解决一个目标 | 是 / 否 | 不混入无关优化 |
| 影响页面和模块列清楚 | 是 / 否 | UI、通信、数据、日志、配置 |
| 预计修改文件列清楚 | 是 / 否 | 新增、修改、删除分别说明 |
| 备份方式已确认 | 是 / 否 | Git、本地压缩包、复制目录或 Skill 本地备份 |
| 回滚方式说明清楚 | 是 / 否 | 出问题时怎么退回 |
| 回归范围提前列出 | 是 / 否 | 不是改完才想怎么测 |
没有实现计划时，不要接受 AI 的大段代码输出。
8. 代码修改门
AI 真正开始写代码、改 XAML、改配置或改项目文件前，必须确认：
| 检查项 | 是否通过 | 备注 |
|---|---|---|
| 已完成备份 | 是 / 否 | 没有备份不要进入修改 |
| 修改范围和文件已列出 | 是 / 否 | 预计修改文件和实际修改文件要能对上 |
| 不改内容已明确 | 是 / 否 | 不重构、不改无关 UI、不改无关协议 |
| 能查看差异 | 是 / 否 | 修改后要能看到改了什么 |
| 修改后能回读 | 是 / 否 | 确认文件没有乱码、空文件或异常缩短 |
如果出现下面情况，必须停止继续修改，先恢复或人工检查：
- 文件变成乱码。
- 文件内容异常减少。
- 项目文件损坏。
- AI 修改了计划外的大量文件。
- 编译错误明显来自无关文件被误改。
- Git diff 或工具差异看不懂。
9. 回归验收门
交付前至少通过：
- 编译和启动检查。
- 本次修改目标验证。
- 相关旧功能回归。
- 异常路径验证。
- 需求对应验收项。
- 已知风险记录。
涉及真实设备、生产数据、数据库结构、发布版本时，必须使用 30-回归测试与验收清单.md 的 L5 范围。
10. 发布交付门
准备给客户、产线或现场使用前，确认：
| 检查项 | 是否通过 | 备注 |
|---|---|---|
| 发布版本号明确 | 是 / 否 | 文件名或版本号可追踪 |
| 运行环境明确 | 是 / 否 | Windows、.NET、驱动、权限 |
| 配置文件说明明确 | 是 / 否 | 串口、IP、路径、数据库 |
| 回滚方式明确 | 是 / 否 | 保留上一版本和旧配置 |
| 源码或项目备份完成 | 是 / 否 | Git 提交、压缩包或项目备份 |
| 已知风险写清楚 | 是 / 否 | 未测设备、未覆盖场景、客户待确认项 |
| 人工审核完成 | 是 / 否 | 真实设备和危险动作必须人工审核 |
11. 复盘门
项目结束或阶段交付后，不要只停在“完成”。至少记录：
- 哪些需求后来变了。
- 哪些 Bug 是 AI 造成的。
- 哪些提示词有效。
- 哪些测试漏掉了问题。
- 哪些模板应该更新。
复盘使用 31-度量复盘与经验沉淀.md。
12. 发给 AI 的质量门 Prompt
text
请你作为 C# WPF/WinForms 上位机 AI 开发流程检查助手。
我准备进入下一阶段，请先帮我做质量门检查，不要写代码。
当前阶段：
【备份与可恢复性 / 问题定义 / 需求确认 / 技术方案 / 实现计划 / 代码修改 / 回归验收 / 发布交付】
已有材料：
【粘贴需求方案、技术方案、修改计划或测试记录】
请输出：
1. 当前阶段是否可以进入下一步：可以 / 不建议 / 必须停止。
2. 已满足的条件。
3. 缺失的信息。
4. 高风险点。
5. 当前是否已有可恢复备份。
6. 必须人工确认的问题。
7. 下一步建议。