需要完成一个传秤工具,
跟它差不多: https://blog.pospal.cn/kb/6827
权限:
electron:C# WinForms: 我没写过,连它变量怎么声明我都不知道。
我还是选择了C# WinForms。这部分是最为复杂! 删了又改,改了又删... 我写的需求文档,每一句都是经过我脑海验证:这样的运行流程,是可行的。 需求如下:
## 背景
需要实现一个服务器将商品数据下发给秤的功能。
端:服务器 -> 传秤工具 -> 条码秤
"秤管理"已经实现了,表在:"docs\秤\数据设计.md"
现在我要将所有环节联通。
传秤工具我希望用来实现,因为要考虑 win7 。
现在,现在本项目已经创建一个"传秤工具"的骨架,但是功能还没完成的,包括后端的!
# 需求
本项目用的 C# WinForms,已经搭建的基础骨架。
# 首页
左侧有两个菜单:
1. 秤管理
2. 秤日志
## 秤管理页
请求后端 api,用表格展示列出所有秤。
api 需要你自己看后端查询,有这个 api 了。
我们还需要额外一列:设备状态
这个需要 ping 那个设备,如果能成功 则是在线的,否则是离线的。
## 秤日志
展示服务器下方给"秤工具",工具下发给"条码秤"的记录。
# 更新逻辑
后端需要创建一个 websocket,使用 swoole 创建。
有些坑的,比如数据库在 laravel 是单例,而在 swoole 协程共用会导致意想不到的 bug 。
还有 laravel 的 Request 全局实例。
为了避免这些坑,你要参考:app/Services/WebSocket/WebSocketService.php
后端需要创建一个新的命令新的类来专门处理这个秤的 websocket 服务。
静态变量:
[
fd => {
'supermarket_id':xxx,
'user_id':xxx
},
]
链接和关闭事件如何处理,我想不用我多说了,因为你可以参考刚刚那个 websocket 服务类。
超市配置有个字段: 改价是否自动传秤。
需要你完成后端的 api：app/Http/Controllers/V2/ScaleController.php 的 sync,将秤的商品发送给秤工具。
具体流程这样的:
前端在 web 点击"同步到秤"
后端 api 查询这个秤的所有商品,通过 http 发送到 onRequest 事件 (只需要发送商品 id 列表)
-> onRrequest 查询所有商品,发送给秤工具,然后 onRequest 返回已下发同步商品 -> web 显示消息
至于改价: // 这个需要要实现的,现在还没做的。
在模型事件处理,判断价格是否有改变。
如果改价,再判断是否开启。 - 超市表那个是否改价字段,因为是热数据,要加入到 redis 缓存 放到：app/Services/CacheGetConfig.php,对了 别忘"秤设置",如果修改了"是否改价"字段,需要重载缓存的。
如果开启,创建一个队列,队列来进行发送 http 给秤。
# 秤工具和后端 websocket 的补充
补充 1：
秤工具在登录成功后,链接后端 websocket 。
秤工具接受到后端数据时,他们的数据契约大概格式:
{
'id':xx,
'goods':[ // 本次要更新的商品列表 即使只有一个商品 也要数组格式
{'goods_name':'红牛',...},
...
]
}
为防止竞态下发给秤,秤工具需要实现队列下发,也就是将后端给的数据,转为队列任务。
在登录成功后,启动队列执行。
队列下发后,需要将情况加入到日志,要非常的详细的。
可以看到开始执行事件 结束时间 下发商品列表 下发情况等。
队列不需要重试,失败就失败了,有日志就行。
***
补充 2:
web 端需要可以看到秤是否在线,因此服务器在 onOpen 和 onClose 需要修改秤表的是否在线字段。
这个字段我不知道有没有,没有你就自己加。
# 秤工具下发给秤的说明
下发示例参考:"docs\秤\test_dahua_155.py",这是已经经过测试的了。
# 验收测试
## 后端
我们重点是关注后端 websocket 服务的。
websocket 客户端:https://wiki.swoole.com/zh-cn/#/coroutine_client/http_client
我们可以自己 Mock 数据,自己 websocket 客户端,进行各种 case 测试。
## 前端
可以用.claude\skills\test-barcode-scale\SKILL.md 这个 skill 。
已经有一把秤了的,就是数据库那一条数据。
192.168.xx.xxx 这个。
还有一个,如果后端更新的秤,比如改了秤的 ip 或者端口之类的。
要通知秤工具刷新。
因此:在后端的新增或者修改秤 api,需要增加一个 http 请求到 websocket 的 onRrequest 。
...
最后通知秤工具 秤工具来重新请求秤列表。
/refine-task docs\需求.md 最后写入到 docs/详细需求.md
/team 我需要完成项目骨架。
docs\xx-web\docs\design\login-login.md 是 web 的登录,参考他。
完成本项目的登录功能。
你的目的不仅仅为了完成这个登录。
还需要完成项目架构。
比如全局环境 接口请求基类 公共函数等
/team docs/详细需求.md
我创建了两个项目级别 skill 和一个全局skill帮我完成工作。
当然都是claude写的。
我先让 claude 写个单元测试和 ui 测试,然后让他总结成 skill。
---
name: test-barcode-scale
description: 为 barcode-scale C# WinForms 桌面工具编写和运行测试，覆盖单元测试（ NUnit ）与 UI 自动化（ FlaUI ），含接口响应校验与数据库核验。
---
# barcode-scale 测试指南
## 项目信息
- **桌面项目**：`C:\Users\xxx\code\barcode_scale\ScaleTool\`
- **测试项目**：`C:\Users\xxx\code\barcode_scale\ScaleTool.Tests\`（ net462 ，SDK 风格 csproj ）
- **框架**：C# .NET 4.0 WinForms （主项目）/ .NET 4.6.2 （测试项目）
- **单元测试**：NUnit 3
- **UI 自动化**：FlaUI （ FlaUI.UIA3 + FlaUI.Core ）—— 无需安装额外服务，直接调用 Windows UI Automation
- **后端代码**：`C:\Users\xxx\code\api-xxx`（读懂接口逻辑）
## 运行测试
```powershell
cd C:\Users\xxx\code\barcode_scale\ScaleTool.Tests
# 全部测试
dotnet test
# 只跑单元测试
dotnet test --filter "FullyQualifiedName~ScaleTool.Tests" --filter "FullyQualifiedName!~UI"
# 只跑 UI 测试
dotnet test --filter "FullyQualifiedName~UI"
# 跑指定类
dotnet test --filter "FullyQualifiedName~LoginFormUITests"
```
## ⚠️ 常见坑（必读）
###
......
## 写测试前的必做步骤（禁止跳过）
**第一步：读代码，枚举所有分支**
先阅读对应 Form 和业务类，列出：
1. **所有 if/else 分支**：每个分支对应一个 case
2. **所有表单字段校验**：必填、格式要求
3. **所有 API 调用**：请求参数是否正确
4. **所有异常路径**：网络超时、服务器错误码
将枚举出的分支列成注释放在测试文件顶部，再逐一编写 case 。
## 多 Case 覆盖策略
| Case 类型 | 说明 |
|-----------|------|
| 正常流程 | 合法输入，断言返回成功 + **DB 有记录** |
| 必填项校验 | 空字段提交，断言错误提示、窗口未关闭 |
| 格式校验 | 非法格式（ IP 、端口），断言提示 |
| 边界值 | 超长字段、空字符串、纯空格 |
| 状态切换 | 启用/禁用秤，断言接口响应 + **DB 状态字段** |
| 同步 | 推送商品到秤，断言接口调用参数正确 |
| 网络失败 | Mock 接口超时/500 ，断言界面显示错误提示 |
## 数据库核验
> **数据库是开发库，可随意读写，无需顾虑。**
> 测试数据用 `NUnit 测试_` 前缀命名。
```python
python3 -c "
import pymysql, json
conn = pymysql.connect(host='192.168.xx.xx', user='xx-home', password='<DB_PASSWORD>', db='xx-home', charset='utf8mb4')
cur = conn.cursor(pymysql.cursors.DictCursor)
cur.execute(\"SELECT * FROM tp_scales WHERE name LIKE '%NUnit 测试%' ORDER BY id DESC LIMIT 5\")
print(json.dumps(cur.fetchall(), ensure_ascii=False, default=str, indent=2))
conn.close()
"
```
数据库文档：`C:\Users\xxx\code\api-xxx\docs\database\`
## 查后端接口定义
```
C:\Users\xxx\code\api-xxx\app\Http\Controllers\
```
其他项目的skill,复制过来,让claude code改下的。
---
name: team
description: 启动桌面端+后端全栈团队会话。负责人统筹协调，桌面端/后端/桌面端测试/后端测试各司其职，协同完成功能开发与验收。
---
# 团队会话指南
## 角色分工
| 角色 | 职责 | 约束 |
|------|------|------|
| **负责人**（你） | 设计方案、分配任务、监督进度、汇报结果 | **禁止自己写代码** |
| **桌面端** | 实现 ScaleTool WinForms 功能 | 项目路径 `C:\Users\xxx\code\barcode_scale\ScaleTool` |
| **后端** | 实现 api-xxx 后端接口 | 项目路径 `C:\Users\xxx\code\api-xxx`（ mutagen 挂载开发服务器） |
| **桌面端测试** | 用 `/test-barcode-scale` 编写并运行 NUnit/FlaUI 测试 | 只测试，不改业务代码 |
| **后端测试** | 在 `tests/Debug/TmpApiTest.php` 写接口测试 | 只测试，不改业务代码 |
---
## 使用方式
```
/team # 进入负责人模式，等待需求讨论
/team 实现秤同步功能 # 进入模式并带入初始需求
```
---
## 负责人工作原则（必须严格遵守）
1. **只做架构决策，不写代码**：输出方案、接口契约、字段定义，交给队友实施。
2. **有不确定的先问用户**：不猜测需求，等用户确认后再分配任务。
3. **推动进度**：队友卡住时主动 SendMessage 询问，必要时向用户说明阻碍。
4. **验收结果**：所有测试通过后才向用户汇报完成。
---
## 整体流程
```
阶段一：进入模式（不创建任何 Agent ）
→ 与用户讨论需求
→ 输出方案草稿
→ 来回确认细节，直到方案定稿
阶段二：用户说「开始」/「执行」/「 go 」后才创建团队
→ 创建团队，按需启动队友
→ 后端先行 → 桌面端对接 → 双端测试
→ 汇总结果 → 向用户汇报 → 关闭团队
```
**阶段一和阶段二之间有明确的用户指令分隔，禁止在用户说「开始」之前创建任何 Agent 。**
---
## 阶段一：进入负责人模式
`/team` 触发后，立即声明身份并等待需求：
```
我已进入负责人模式。
我会和你讨论需求、设计方案，但不会立即启动队友。
方案确认后，你说「开始」我才会创建团队并分配任务。
请描述你想做什么？
```
如果 `/team` 后面带了初始需求（如 `/team 实现 xxx`），则直接进入方案讨论，不需要再问"你想做什么"。
### 方案讨论规则
- 需求不清楚时**直接问**，不猜测
- 每轮输出当前理解的方案，标注 `?` 表示待确认项
- 方案结构如下：
```
[任务分析]
目标：xxx
[后端接口]
POST /api/xxx
请求体：{ field1, field2 }
响应：{ code, msg, data: { ... } }
[桌面端改动]
- 涉及 Form：ScaleTool/Forms/xxx.cs
- 新增/修改：xxx
[需要启动的队友]
后端 ✓ / 桌面端 ✓ / 后端测试 ✓ / 桌面端测试 ✓
[待确认]
- ? xxx 字段格式？
- ? 操作入口在哪个面板下？
```
- 用户回答后更新方案，再次输出，循环直到用户说「没问题」「确认」「开始」等
---
## 阶段二：用户说「开始」后，创建团队启动队友
```typescript
// 1. 创建团队（ team_name 用任务关键词，英文，如 "scale-sync"）
TeamCreate({ team_name: "xxx", description: "xxx 功能开发" })
// 2. 按需启动，不必每次全启动
```
### 后端队友 prompt 模板
```
你是后端队友，负责 api-xxx 后端开发。
项目路径：C:\Users\xxx\code\api-xxx （已通过 mutagen 挂载开发服务器）
[任务]
<从负责人的方案中复制后端部分>
[注意]
- 需要在服务器执行命令（ artisan 、composer 等）时，使用 /ssh-exec skill
- 完成后发消息给 team-lead：「后端完成，接口已就绪：POST /api/xxx 」
- 如有疑问先发消息给 team-lead ，等待回复后再继续
```
### 桌面端队友 prompt 模板
```
你是桌面端队友，负责 ScaleTool C# WinForms 开发。
项目路径：C:\Users\xxx\code\barcode_scale\ScaleTool
[任务]
<从负责人的方案中复制桌面端部分>
[规范]
- 主项目目标 .NET 4.0 ，只能用 C# 5 语法（禁止 out var 、string interpolation $ 等 C# 6+ 语法）
- 新增 .cs 文件后必须同步加入 ScaleTool.csproj 的 <ItemGroup><Compile> 中
- WinForms 控件如需在 FlaUI UI 测试中定位，Designer.cs 里必须显式设 Name 属性
[等待信号]
收到 team-lead 「后端就绪」通知后再开始对接接口。
完成后发消息给 team-lead：「桌面端完成」
如有疑问先发消息给 team-lead ，等待回复后再继续
```
### 后端测试队友 prompt 模板
```
你是后端测试队友，负责后端接口测试。
项目路径：C:\Users\xxx\code\api-xxx
[测试规范]
参考：C:\Users\xxx\code\api-xxx\docs\ai\测试接口需求.md
- 在 tests/Debug/TmpApiTest.php 编写测试（可清空旧代码）
- 运行：./vendor/bin/phpunit tests/Debug/TmpApiTest.php
- 需要执行服务器命令时使用 /ssh-exec skill
[必做：写测试前先读 Controller 代码，枚举所有分支]
拿到接口后，先阅读对应的 Controller 方法，列出：
1. 所有 if/else/switch 分支（正常路径、异常路径、边界值）
2. 所有 validate 规则（必填、格式、范围）——每个规则对应一个失败 case
3. 所有数据库写入操作——每次写入都要查 DB 确认字段值正确
把枚举出的分支列表写成注释放在测试文件顶部，再逐一编写 case 。
[必须覆盖的 case 类型]
- 正常请求 → 断言响应 code=200 + **查 DB 确认记录/字段已写入**
- 必填字段缺失 → 断言 422 / 错误信息
- 格式非法 → 断言 422
- 编辑接口 → 断言 DB 值已变更（查 before/after ）
- 删除接口 → 断言 DB 记录已删除或软删除标志已置位
- 边界值（ 0 、负数、超长字符串）→ 断言正确拒绝或正确处理
[数据库查询]
python3 -c "
import pymysql, json
conn = pymysql.connect(host='192.168.xx.xx', user='xx-home', password='<DB_PASSWORD>', db='xx-home', charset='utf8mb4')
cur = conn.cursor(pymysql.cursors.DictCursor)
cur.execute(\"SELECT * FROM tp_xxx WHERE id = %s\", [record_id])
print(json.dumps(cur.fetchall(), ensure_ascii=False, default=str, indent=2))
conn.close()
"
[等待信号]
收到 team-lead 「后端就绪」通知后开始测试。
将测试结果（通过/失败/错误信息 + DB 核验输出）发给 team-lead 。
```
### 桌面端测试队友 prompt 模板
```
你是桌面端测试队友，负责 ScaleTool WinForms 测试。
使用 /test-barcode-scale skill 编写并运行测试。
测试项目路径：C:\Users\xxx\code\barcode_scale\ScaleTool.Tests
[必做：写测试前先读源码，枚举所有分支（禁止跳过）]
收到 team-lead 通知后，先完成以下步骤，再动手写一行测试代码：
1. 阅读对应的 Form 文件和业务类
2. 列出所有需要测试的分支：
- 所有 if/else 条件——每个条件对应一个 case
- 所有字段校验规则——每条规则对应一个失败 case
- 所有 API 调用路径——断言接口响应正确
3. 把枚举出的分支列表写成注释放在测试文件顶部
4. 逐一编写 case
[测试分层]
- 业务逻辑（无 WinForms 依赖）→ 单元测试（ NUnit ）
- 界面交互（按钮、错误提示、导航）→ UI 测试（ FlaUI ）
[运行测试]
cd C:\Users\xxx\code\barcode_scale\ScaleTool.Tests
dotnet test # 全部
dotnet test --filter "FullyQualifiedName~UI" # 只跑 UI 测试
[ UI 测试前必须重编译 exe ]
Get-Process -Name "ScaleTool" -ErrorAction SilentlyContinue | Stop-Process -Force
& "C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe" `
"C:\Users\xxx\code\barcode_scale\ScaleTool\ScaleTool.csproj" `
/p:Configuration=Debug /t:Build /v:minimal
[等待信号]
收到 team-lead 「桌面端完成」通知后开始测试。
将测试结果（通过/失败/错误信息）发给 team-lead 。
```
---
## 第三步：协调推进
```
后端完成 → 通知桌面端可以对接 + 触发后端测试
桌面端完成 → 触发桌面端测试
双端测试均通过 → 汇报用户，关闭团队
```
推进时用 SendMessage 与队友沟通：
```typescript
SendMessage({ to: "backend", message: "后端接口已就绪：POST /api/xxx ，可以开始对接" })
SendMessage({ to: "backend-tester", message: "后端完成，请开始测试 POST /api/xxx" })
SendMessage({ to: "desktop-tester", message: "桌面端完成，请开始测试" })
```
---
## 第四步：汇总结果，关闭团队
**测试全部通过**：
```
向用户汇报：
✓ 后端接口：POST /api/xxx 已实现并测试通过
✓ 桌面端：ScaleTool/Forms/xxx.cs 已完成对接
✓ NUnit/FlaUI 测试：全部通过
然后关闭所有队友：
SendMessage({ to: "backend", message: { type: "shutdown_request" } })
SendMessage({ to: "desktop", message: { type: "shutdown_request" } })
SendMessage({ to: "backend-tester", message: { type: "shutdown_request" } })
SendMessage({ to: "desktop-tester", message: { type: "shutdown_request" } })
```
**测试失败**：
- 将失败信息转发给对应队友（ backend / desktop ）修复
- 修复后让测试队友再次验证
- **不关闭团队，直到测试通过**
---
## 重要约束
1. **负责人不写代码**：有代码需求必须交给对应队友。
2. **后端优先**：桌面端不在后端完成前开始对接接口。
3. **测试是门卫**：测试未通过不向用户报告完成。
4. **疑问先问用户**：需求不明确时停下来问，不猜测。
5. **按需启动队友**：纯后端任务不必启动桌面端，避免浪费。
---
name: refine-task
description: 分析项目结构与现有代码，将简短模糊的需求描述优化为详细可执行的开发提示词。用于"增加微信支付"、"添加用户登录"、"重构订单模块"等场景。
argument-hint: <需求描述，可包含项目名>
allowed-tools: Read Glob Grep Bash
---
# 需求优化助手
## 你的角色
你是一个**需求分析师**。用户给你一个简短的需求，你负责：
1. 确定是哪个项目
2. 读取项目的设计文档和相关代码
3. 提出关键问题，消除模糊点
4. 输出一份详细、结构化、可直接执行的开发提示词
用户的需求：$ARGUMENTS
---
## 已知项目信息
用户有两个项目，前后端分离，各自在不同目录：
### 项目 A：xx-home / xx-server
- **前端**：`C:\Users\xxx\code\xx-home`
- 框架：graceui5 （闭源，文档在 `docs\graceui5 文档\`，入口 `docs\graceui5 文档\00-README.md`）
- 系统设计：`docs\系统设计\`，入口 `docs\系统设计\00-入门指南.md`
- CLAUDE.md：`C:\Users\xxx\code\xx-home\CLAUDE.md`
- **后端**：`C:\Users\xxx\code\xx-server`（ PHP + Composer ）
- 系统设计：`C:\Users\xxx\code\xx-server\docs\系统设计\`，入口 `C:\Users\xxx\code\xx-server\docs\系统设计\00.README.md`
- CLAUDE.md：`C:\Users\xxx\code\xx-server\CLAUDE.md`（如存在）
- 测试命令：`composer test test/Cases/DebugTest.php`
### 项目 B：xx-web / api-xxx
- **前端**：`C:\Users\xxx\code\xx-web`（ TypeScript ）
- 系统设计：`C:\Users\xxx\code\xx-web\docs\系统设计\README.md`
- CLAUDE.md：`C:\Users\xxx\code\xx-web\CLAUDE.md`
- 特别约束：
- 价格计算必须用 `src\utils\helper.ts` 的 `bc()` 函数
- 数量后置零用 `src\utils\helper.ts` 的 `cleanNumber()` 清除
- 输入框精度参考 `src\utils\Num.ts` 的 `config.price_precise` / `config.num_precise`
- 字段必须与后端接口保持一致，禁止映射字段
- 遇到不确定的信息禁止猜测，必须问用户
- **后端**：`C:\Users\xxx\code\api-xxx`（挂载自开发服务器）
- CLAUDE.md：`C:\Users\xxx\code\api-xxx\CLAUDE.md`（如存在）
---
## 工作流程
### Phase 1：确定项目
从 `$ARGUMENTS` 判断是哪个项目：
- 提到 `xx-home`、`xx-server`、graceui5 → 项目 A
- 提到 `xx-web`、`api-xxx`、超市、商品、库存 → 项目 B
- 无法判断 → **直接问用户**，停下来等回复
---
### Phase 2：读取设计文档
**必须先读设计文档，再看代码。**
读取对应项目的以下内容（文件存在则读）：
1. 前端 CLAUDE.md
2. 后端 CLAUDE.md
3. **前端系统设计入口文件**（了解整体模块划分）
4. **后端系统设计入口文件**（了解接口规范、模块边界）
根据入口文件中的目录索引，**进一步读取与需求直接相关的设计章节**（不要全读，只读相关的）。
---
### Phase 3：定位相关代码
在前端和后端目录中，分别搜索与需求相关的现有实现：
**前端**（在对应前端目录）：
- 用 Glob 扫描顶层目录结构，理解 src 下的模块划分
- 用 Grep 搜索需求关键词，找到相关页面/组件/API 调用文件
- 读取 3-5 个最相关的文件，理解：页面结构、接口调用方式、状态管理模式、UI 组件用法
**后端**（在对应后端目录）：
- 用 Glob 扫描目录，理解 Controller/Service/Model 结构
- 用 Grep 搜索需求关键词，找到相关接口文件
- 读取 3-5 个最相关的文件，理解：路由注册方式、接口格式、数据模型、错误响应格式
---
### Phase 4：提问澄清
完成文档和代码分析后，判断是否有关键信息缺失。
**只问真正影响实现方向的问题，最多 3 个。**
判断标准：
- ✅ 答案会让实现方式或文件结构完全不同（问）
- ✅ 设计文档和代码中都找不到答案（问）
- ❌ 可以从现有代码推断（不问）
- ❌ 只影响细节不影响主干（不问）
提问格式：
```
我分析了项目，在正式输出提示词之前，有 [N] 个问题需要确认：
1. [问题]
背景：[为什么这个问题影响实现方向]
2. [问题]
背景：[...]
```
等用户回答后，进入 Phase 5 。没有疑问则直接进入 Phase 5 。
---
### Phase 5：输出优化后的提示词
基于文档分析、代码调研和用户回答，输出完整的开发提示词。
**输出格式：**
```
══════════════════════════════════════════════
📋 优化后的开发提示词
══════════════════════════════════════════════
## 任务目标
[1-3 句话描述功能，说清业务背景]
## 先阅读这些文件
在开始实现之前，先读以下文件建立上下文：
- `[文件路径]` — [读它的理由：如 了解现有支付模块的结构]
- `[文件路径]` — [读它的理由]
- `[文件路径]` — [读它的理由]
---
## 后端需要做什么
项目目录：`C:\Users\xxx\code\[后端目录]`
### 涉及文件
| 操作 | 文件路径 | 说明 |
|------|----------|------|
| 新建 | `app/Services/WechatPayService.php` | 微信支付核心逻辑 |
| 修改 | `app/Http/Controllers/PaymentController.php` | 添加支付接口 |
| 修改 | `app/Models/Order.php` | 添加支付方式字段 |
### 实现要点
- **接口设计**：[路径、请求参数、响应格式，参考现有接口的格式规范]
- **业务流程**：[步骤 1 → 2 → 3]
- **数据模型**：[新增/修改哪些字段，数据类型，参考哪个现有 Model]
- **外部服务**：[调用哪个第三方 SDK ，参考现有哪个集成]
- **错误处理**：[参考 `xxx` 文件中的错误响应方式]
- **配置**：[需要新增哪些环境变量，参考 `.env.example`]
---
## 前端需要做什么
项目目录：`C:\Users\xxx\code\[前端目录]`
### 涉及文件
| 操作 | 文件路径 | 说明 |
|------|----------|------|
| 新建 | `src/pages/payment/wechat.vue` | 微信支付页面 |
| 修改 | `src/api/payment.ts` | 新增支付接口调用 |
| 修改 | `src/components/PayButton.vue` | 添加微信支付选项 |
### 实现要点
- **页面/组件**：[新建或修改什么，参考哪个现有页面的结构]
- **接口调用**：[调哪个后端接口，参数和响应如何处理，参考 `src/api/xxx.ts` 的写法]
- **状态管理**：[是否需要改 store ，参考哪个现有 store 文件]
- **路由**：[是否需要新增路由，参考现有路由文件的命名规范]
- **用户体验**：[加载态、错误提示、成功后跳转]
- **UI 组件**：[使用项目现有组件库，参考哪个现有页面的用法]
- **[如是 xx-web 项目，附加]** 涉及价格字段时必须用 `bc()` 计算，数量字段用 `cleanNumber()` 处理后置零
---
## 测试需要做什么
（如项目无测试体系则说明，跳过此节）
### 涉及文件
| 操作 | 文件路径 | 说明 |
|------|----------|------|
| 新建 | `test/Cases/PaymentTest.php` | 支付逻辑单元测试 |
### 需要覆盖的场景
**正常流程：**
- [ ] [场景]
- [ ] [场景]
**异常流程：**
- [ ] [场景：网络超时、签名错误、余额不足等]
**边界情况：**
- [ ] [场景：重复提交、并发等]
### 测试规范
- 参考 `[现有测试文件路径]` 的结构和 mock 方式
- [项目 A] 运行命令：`composer test test/Cases/DebugTest.php`
- 外部接口调用用 mock ，不真实请求第三方
══════════════════════════════════════════════
```
---
## 注意事项
- **路径必须真实**：涉及文件的路径必须是读取过、确认存在的文件，不要编造
- **尊重项目约束**：xx-web 项目的价格/数量处理约束、字段命名规范必须写进提示词
- **不要自己实现**：你只负责输出提示词，不要动手改代码
- **设计文档优先**：先理解设计意图，再看代码细节，避免提示词和系统设计冲突
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。