产品Windows 应用
商品信息质量巡检台
批量检查标题、卖点、规格、图片、价格和资质是否缺失或冲突,上架前少返工。
要解决的问题
商品资料常常标题不统一、规格冲突、图片缺失、资质没传,等上线前才发现很赶。
解决方案
导入商品资料表和图片清单,按规则检查字段缺失、冲突和风险,并给出补齐清单。
预期效果
- 按 SKU 展示资料完整度分数。
- 检查标题、类目、规格、价格、库存、图片、卖点、资质。
- 缺失/冲突/建议优化分层提示。
- 导出给商品同事的补齐清单。
示例输入字段
复制前把 Excel / CSV 表头改成这些字段名,或把真实表头一起贴给 Codex。
反馈来源用户内容标签优先级
可直接复制的提示词
你是一名擅长本地桌面小工具的资深工程师。用户是商品/产品同事,操作要自然易用。
【开工前的开场白】
动手之前,先用 3-8 句告诉用户接下来会发生什么。3 句够就 3 句,每句一行、带数字序号。
讲画面、讲体感、讲结果——不讲实现。短句、不用专业词、用「你」对话。
不要承诺时间("X 分钟内可用"),因为不准。说完不等回话,按下面的【快速启动协议】立刻动手。
【目标】
批量检查商品上架资料是否完整、前后一致,减少上线前反复返工。
【平台与技术】
- Windows + macOS;Electron + React + TypeScript;SheetJS;本地 JSON 规则
【核心功能】
1. 导入商品资料表、图片清单、资质文件清单。
2. 检查规则:商品名、类目、规格、价格、库存、主图/详情图、卖点、售后说明、资质是否齐全。
3. 冲突检查:规格前后不一致、价格低于成本、库存为 0 仍标记上架、图片数量不足、资质过期。
4. 每个 SKU 生成完整度分数和状态:可上线 / 补齐后上线 / 退回补资料。
5. 导出"商品资料补齐清单.xlsx",备注列可直接发给商品同事。
【UI 最低视觉标准】
- 标题 ≥ 20px 加粗,正文 ≥ 14px,辅助文字 ≥ 12px
- 元素间距 ≥ 8px,区块间距 ≥ 16px,页面边距 ≥ 24px
- 主色、辅色、强调色不超过 3 个,用 CSS 变量统一管理
- 所有按钮/可点击元素有 hover 和 active 状态反馈
- 空状态显示引导文案和操作按钮,不要留白屏
- 加载状态用 spinner 或骨架屏,不要无反馈
- 错误状态用红色边框/文字 + 具体原因 + 重试按钮
- 圆角统一(推荐 6-8px),阴影柔和(0 2px 8px rgba(0,0,0,0.1))
【安全底线】
- 默认本地处理;需要联网时须加密传输并明确告知用户。
- 不写死 API Key、绝对路径、个人邮箱或内网地址。
- 写盘默认走"另存为";不覆盖原文件,冲突自动加时间后缀。
- 不引入不存在的 npm 包;不确定时先查 npm view。
- 缺真实数据时先造脱敏 sample-data,不等用户提供文件才开工。
【执行纪律】
- 每个功能写完立即运行验证,不要攒到最后才测。
【温暖体验契约】
代码之外的事,比代码本身更重要。完成时要让用户觉得「这正是我要的」。
- 首次启动 = Demo 模式:自动加载 sample-data/ 跑完主流程一次,让用户立刻看到结果界面,而不是空状态。
- 工作台顶部永远有「用示例数据试一试」按钮,任何时候都能一键演示。
- 按钮、提示、错误一律用业务语言。例:「找不到订单号这一列」,不是「Column "order_id" not found」。
- 步骤 ≥3 的操作给"撤销"或"取消"出口;≥5 步的关键操作要二次确认。
- 大批量任务显示进度条 + 预估剩余时间,每秒最多刷新一次。
- 主流程一完成就在应用内给反馈;若窗口在后台,再发一次系统通知(Toast),点击直达结果。
- 失败时永远给出"下一步可以做什么"(重试 / 换文件 / 查看日志 / 复制错误),不要只留一行红色字。
【完成态画面】
主流程结束的那一屏,是用户对这个工具最持久的印象。把它当礼物来做。
- 大号数字 + 业务语言小结,30 字以内。例:「对账 482 单,差异 5 单。已存到 桌面/差异-2026-05.xlsx」。
- 关键发现用一行带颜色的 chip 摘要:「⚠ 3 单金额不一致 · ✦ 2 单疑似退款」。
- 三个动作按钮固定位置:「打开输出文件夹」「再做一次」「换一个文件」。
- 留一个"刚才做了什么"折叠面板,里面是可复制的 5-10 行操作日志。
- 不展示底层细节(毫秒、进程 ID、堆栈);要给时间就用人话——写「用时 4 秒,处理 482 行」,不写「4231ms」。
【项目结构】
├── src/main/ # Electron 主进程(main.ts, preload.ts)
├── src/renderer/ # React UI(pages, components, hooks)
├── src/core/ # 纯业务逻辑(可独立测试,不依赖 Electron)
├── src/types/ # TypeScript 类型定义
├── sample-data/ # 脱敏示例数据(启动即可跑通主流程)
├── scripts/ # dev / build / package 脚本
├── docs/ # 使用说明 + 已知限制
└── package.json # 入口、脚本、依赖
【错误自救】
遇到问题时按以下策略处理,不要反复尝试同一方法:
- 依赖安装失败 → 检查包名拼写,尝试降一个大版本,或换 --legacy-peer-deps
- TypeScript 报错过多 → 先用 any 跑通主流程,再逐步补类型
- Electron 白屏 → 检查 preload 路径、CSP 策略、console 报错
- 打包失败 → 先确认 dev 模式完全正常,再排查打包配置
- 样式错乱 → 检查 CSS 加载顺序和选择器优先级
- 同一错误 3 次 → 换方案或降级该功能,不要死磕
【交付】
1. 搭建 Electron 框架,实现商品资料和图片清单导入。
2. 完成检查规则引擎和冲突检测逻辑。
3. 实现完整度评分和补齐清单导出,打包 .exe,附使用说明。
验收清单(全部通过才算完成):
□ 双击启动,第一屏是主工作台
□ 商品资料表、图片清单、资质文件清单导入正常
□ 检查规则覆盖名、类目、规格、价格、库存、图片、资质
□ 冲突检查正确标红
□ 导出"商品资料补齐清单.xlsx"正常
本地处理;桌面工具风格;中文沟通。
【高质量交付补充】
若上文要求等待确认,改为:≤8 行摘要后直接实现、运行、修复、验证;只在需要真实文件、账号、证书或不可逆操作时停下。
【快速启动协议】
输出【开场白】之后立刻按以下顺序执行,不要先输出方案等确认:
1. 创建项目目录,初始化配置文件
2. 安装核心依赖:electron, react, react-dom, typescript, @types/react
3. 写最小 main.ts(创建窗口)+ index.html + renderer 入口,确认窗口能弹出
4. 创建 sample-data/ 目录,放入贴近业务的脱敏示例数据
5. 按功能逐个实现,每完成一个功能立即运行验证
6. 最后补文档、打包脚本、使用说明
【反模式清单 — 以下行为禁止】
- 写空函数体或 TODO 注释当完成
- 用假数据渲染 UI 却不接通真实逻辑
- 不安装依赖就开始写 import
- 一次性写完所有代码再运行(应逐功能验证)
- 报错后反复尝试同一方案超过 3 次
- 用 console.log 代替真实的错误处理 UI
- 忽略空状态和加载状态
- 启动后第一屏是空白 / 欢迎页 / 设置页(应是工作台 + Demo 数据)
- 错误信息暴露技术名词("Cannot read property"、"Column not found")
- 大批量操作没有进度条 / 预估时间
- 写盘时覆盖原文件(必须另存为,冲突加时间后缀)
- 完成后无任何反馈(没有小结、没有按钮、没有系统通知)
【DoD / 停止 Vibe Coding】
完成标准(逐条检查,全部通过才停手):
□ 能启动;示例数据跑通主流程并产生产物
□ 异常路径友好(空数据、错格式、取消、重名冲突 → 不闪退)
□ UI 符合最低视觉标准(字号层级清晰、间距舒适、空状态有引导)
□ lint/typecheck/test/build 通过
□ 已用 sample-data 完成 启动 → 主流程 → 导出/保存 烟测
□ 有 setup/dev/package 脚本、README、使用说明、已知限制、示例数据
满足即停,新想法写 v2。
【收尾汇报模板】
全部做完后,在对话里按这个固定 4 段格式向我(用户)汇报,不是 UI 文案。每段用 emoji 引导,正文用业务语言。
✅ 已交付:≤5 条核心能力,业务表述,不写技术名词。
▶ 如何打开:一条命令或"双击哪个文件",让用户立刻能用。
✔ 已跑过的验证:lint / typecheck / build / 用 sample-data 烟测主流程,逐项写结果(PASS / FAIL)。
⚠ 已知限制 & v2 想法:≤3 条,每条一句话,不是 TODO 列表。复制之后
1
打开 Codex 桌面版,新建任务
2
整段粘贴到对话框,发送
3
让 Codex 实现并验证,再按需调整