|
|
@@ -1,7 +1,7 @@
|
|
|
# VOC 用量核算、成本预估与余额看板实现方案
|
|
|
|
|
|
-> 文档状态:技能包改动已落实,待后端重启后的端到端联调
|
|
|
-> 编写日期:2026-09-01;最近复核:2026-09-02
|
|
|
+> 文档状态:P0 计费、用量展示、支付回调和工具级续跑已完成生产复测;已支付小额订单的 NewAPI 直入账代码、回调契约和本地构建已完成。2026-09-05 生产探针确认公网 `nova-server` 尚未加载该路由版本,需按第 21.28 节发布后再执行一次账户级余额刷新与幂等复测。历史工作流适配和跨会话唤醒仍列为 P1。
|
|
|
+> 编写日期:2026-09-01;最近复核:2026-09-05
|
|
|
> 涉及仓库:`claude-code-voc-intelligence`、`future-server`、`fmode-studio`、`voc-profit-web`
|
|
|
|
|
|
## 1. 背景与目标
|
|
|
@@ -1227,20 +1227,43 @@ npm run smoke:package
|
|
|
|
|
|
| 完成定义 | 状态 | 复核结论 |
|
|
|
| --- | --- | --- |
|
|
|
-| AI 读取当前有效计费规则 | 已完成 | 后端统一 `POST /api/fmode/billing/query` 返回余额、价目和版本;`voc_billing_query`/`voc_cost_estimate` 已注册。 |
|
|
|
+| AI 读取当前有效计费规则 | Node 生产入口已上线,账户字段待有效凭证回归 | `fmode-server/api/routes.ts` 保留 Deno 入口实现;传统 Node 生产入口在 `api/api-ncloud/fmode/routes.js` 增加同一路径,并通过 `.modules/newapi-metering.min.cjs` 复用共享计费实现。远程无凭证和合成 API Key 已分别返回 401,路由已不再是 404。 |
|
|
|
| 所有已接入工作流执行前三档预估 | 部分完成 | 通用规划器覆盖小红书账号监听、天猫 Listing 和自定义 operations;其他新工作流需提供规划适配器。 |
|
|
|
| 每次调用关联 usageTraceId/report/skill/step/endpoint | 已完成(已接入入口) | `voc_api_call`、小红书/抖音 live 网关请求发送 `X-Fmode-*` Header,后端写入 `logs.other`;历史日志标记 mixed/reconstructed。 |
|
|
|
-| Balance 按模块、追踪、报告、接口展示 | 已完成(前端已接入) | Studio Balance 用量页调用统一接口,展示调用、quota、实际消费、模块/接口明细和计费规则。 |
|
|
|
+| Balance 按模块、追踪、报告、接口展示 | 前端完成,生产接口已挂载,账户字段待回归 | Studio Balance 用量页已接入统一接口和展示字段;生产 billing query 已可达,需使用当前有效账户凭证核对真实余额和用量。 |
|
|
|
| 大模型与 VOC 费用分列 | 部分完成 | 用户用量账与平台成本报告已拆分;模型侧只有具备同一 trace 的日志才能精确合并。 |
|
|
|
| 预算上限阻止超支并保留部分成果 | 已完成(已接入批处理入口) | `batch-budget-guard` 在小红书/抖音 live 每个关键词批次前读取当前余额与追踪消费,支持 80% 预警、硬预算/余额阻断、差额和建议充值;首批前阻断也会写入 `checkpoint.json`,`resume` 会跳过已完成关键词。经营闭环复用同一趋势入口;跨会话自动唤醒仍由宿主运行时负责。 |
|
|
|
| 高成本低价值项优化建议 | 已完成(首批任务) | Agent 估算报告输出 valueScore、可删项和节省额;管理员看板 `/usage-diagnostics` 已按任务和接口展示成本排行、缓存命中和预计节省。 |
|
|
|
| 充值后从检查点继续且不重复调用 | 已完成(工具级续跑) | VOC 402 分支保留部分结果并写检查点;支付后以同一 `usageTraceId` + `resume` 续跑,已完成业务键和分页不会重复调用。跨会话自动唤醒仍由宿主运行时负责。 |
|
|
|
-| Agent 返回免登录链接或支付二维码 | 已完成 | VOC 402 由统一 recharge client 复用现有 `pay_code2/order_status2`,二维码失败保留 Token Balance URL;Studio/宿主已对模型 402 直接打开现有充值入口。 |
|
|
|
+| Agent 返回免登录链接或支付二维码 | 技能端完成,生产 query 已挂载,账户字段待回归 | VOC 402 和统一 recharge client 已复用现有 `pay_code2/order_status2`,二维码失败保留 Token Balance URL;有效账户查询后即可验证完整生产链路。 |
|
|
|
| 采集多媒体并固定本地缓存 | 已完成(所有当前 VOC 采集入口) | 小红书/抖音 sample 与 live、通用 `voc_api_call` 均经过 discovery/manifest/pipeline;`effectiveUrl` 固定为本地路径,线上 Storage 上传已关闭。 |
|
|
|
| 凭证不写入代码、日志、报告 | 已完成(静态与 smoke 范围) | 请求凭证只作运行时输入,输出经过脱敏;发布包扫描和安装 smoke 通过。 |
|
|
|
|
|
|
当前可以验收的 P0 交付是:统一报价、真实扣费归集、充值入口、Balance 用量页、管理员任务级成本诊断、两类首批工作流、live 媒体持久化和本地续跑检查点。后续工作集中在“为尚未接入的历史批处理 Skill 增加规划适配器、跨会话自动唤醒、更多采集入口接入媒体流水线、基于真实账号的端到端回放和历史预估校准”,不影响本轮已交付闭环。
|
|
|
|
|
|
+### 18.2 当前验收状态(2026-09-03)
|
|
|
+
|
|
|
+本节覆盖重启后生产复测结果。第 18.1 节保留为 9 月 2 日历史快照,不再代表当前账户状态。
|
|
|
+
|
|
|
+| 完成定义 | 当前状态 | 最新证据或剩余范围 |
|
|
|
+| --- | --- | --- |
|
|
|
+| AI 读取当前有效计费规则 | 已通过生产复测 | `billing/query` 返回 HTTP 200、当前余额和 7 条价目规则;Agent 继续在本地根据价目和计划计算报价。 |
|
|
|
+| 所有已接入工作流执行前三档预估 | 首批已通过,扩展项待适配 | 小红书账号监听、天猫 Listing 和自定义 `operations` 已覆盖;历史批处理 Skill 仍需逐一接入规划适配器。 |
|
|
|
+| 每次调用关联 usageTraceId/report/skill/step/endpoint | 已通过生产复测 | 重启后小规模 VOC 调用可按 `usageTraceId` 聚合,生产账单为 1 次调用、1 次计费、7353 quota、¥0.10;运行包写入追踪上下文和计费日志字段。 |
|
|
|
+| Balance 按模块、追踪、报告、接口展示 | 已通过生产复测 | Studio Balance 页面和生产 query 均可用;修正凭证优先级后,Session 与 NewAPI key 指向同一账户,已验证余额、用量汇总、模块/接口明细和规则展示。 |
|
|
|
+| 大模型与 VOC 费用分列 | 首批已落地,完整模型归集待扩展 | 用户账单与平台成本报告已拆分;模型日志只有携带同一追踪标识时才能精确合并,未带标识的历史数据继续标记为待归集。 |
|
|
|
+| 预算上限阻止超支并保留部分成果 | 已通过 | 预算守卫、80% 提示、硬上限、差额提示、检查点和工具级续跑 smoke 全部通过。 |
|
|
|
+| 高成本低价值项优化建议 | 已通过首批验收 | Agent 估算报告和管理员任务诊断均输出接口成本占比、可删项、预计节省和信息损失提示。 |
|
|
|
+| 充值后从检查点继续且不重复调用 | 工具级续跑已通过,账户级余额恢复待后端修正 | 使用原 checkpoint 和原参数续跑返回 `status=ok`、`fetchCalls=0`,已完成关键词不再触发 VOC 网关;本次支付回调已成功,但自动划拨失败,尚未形成“到账后余额增加再续跑”的同一订单闭环。 |
|
|
|
+| Agent 返回免登录链接或支付二维码 | 支付回调已通过,NewAPI 自动划拨待后端修正 | Token Balance URL、`recharge/order + pay_code2`、`order_status2` 在有效 Session 上实测;`VOCQA20260903P01` 返回 `SUCCESS`,Parse `AccountLog.isVerified=true`,但 `fmodeApiAutoTransfer.status=failed`(旧钱包余额为负),NewAPI quota 未增加。 |
|
|
|
+| 采集多媒体并固定本地缓存 | 已通过生产复测 | 重启后产物生成 `outputs/prod-restart-20260903/assets/` 本地媒体目录;运行时代码没有线上 Storage 上传、预签名或 complete 调用。 |
|
|
|
+| 凭证不写入代码、日志、报告 | 已通过静态、smoke 和发布包验收 | 凭证只作运行时输入,输出脱敏;zip、npm、npx 和 workspace 安装 smoke 均通过。 |
|
|
|
+
|
|
|
+#### 当前剩余工作
|
|
|
+
|
|
|
+1. **账户交易回归收尾**:支付订单 `VOCQA20260903P01` 已返回 `SUCCESS` 且 Parse 流水已核验;需修正/重新部署自动划拨回调,使已支付金额不依赖旧钱包正余额,随后复查 NewAPI 余额增加、Balance 页面刷新和同一 checkpoint 续跑。
|
|
|
+2. **扩展覆盖**:为尚未接入的历史批处理 Skill 增加规划适配器;完善跨会话自动唤醒、更多采集入口的媒体接入,以及基于真实报告的预估偏差校准。这些属于 P1 扩展,不阻塞当前 P0 计费闭环。
|
|
|
+
|
|
|
## 19. 建议首个迭代范围
|
|
|
|
|
|
首个可上线迭代建议只做以下闭环:
|
|
|
@@ -1285,9 +1308,13 @@ npm run smoke:package
|
|
|
| 修改 | `fmode-server/modules/voc-social-api/src/routes.ts` | 接收白名单任务上下文、按路径解析价格、写日志、返回 usage 响应头 | 高 |
|
|
|
| 修改 | `fmode-server/modules/voc-e-commerce/src/routes.ts` | 与社媒网关保持相同计费和追踪行为 | 高 |
|
|
|
| 修改 | `fmode-server/modules/voc-ecom-api/src/routes.ts` | 与社媒网关保持相同计费和追踪行为 | 高 |
|
|
|
-| 修改 | `fmode-server/api/routes.ts` | 在现有主路由中提供统一 `POST /api/fmode/billing/query`;媒体 Storage 路由不由本技能包调用 | 高 |
|
|
|
+| 修改 | `fmode-server/api/routes.ts` | 在现有 Deno 主路由中提供统一 `POST /api/fmode/billing/query`;媒体 Storage 路由不由本技能包调用 | 高 |
|
|
|
+| 修改 | `api/api-ncloud/fmode/routes.js` | 为实际运行的 Node `server.js` 增加 `/api/fmode/billing/query`,兼容 Bearer、`x-api-key` 和 body token,并将认证错误固定为 401 | 高 |
|
|
|
+| 新增产物 | `.modules/newapi-metering.min.cjs` | 将共享计费查询实现编译为 Node 可加载产物,随传统入口一起发布;不改变逐次 NewAPI 扣费 | 高 |
|
|
|
+| 新增构建脚本 | `fmode-server/scripts/build-newapi-metering.cjs` | 使用仓库内 esbuild 从 `fmode-server/modules/shared/newapi-metering.ts` 可重复生成上述 Node 产物 | 中 |
|
|
|
| 修改 | 三个模块的构建脚本或 `scripts/build.mjs` | 确保共享计费代码进入产物,并复制到根目录 `.modules` | 中 |
|
|
|
-| 生成 | `.modules/voc-social-api.min.cjs`、`.modules/voc-e-commerce.min.cjs`、`.modules/voc-ecom-api.min.cjs` | 三个 VOC 网关的生产实际加载产物;由各模块构建生成,不手工编辑。billing 路由随 `fmode-server/api/routes.ts` 加载,不单独生成 CJS | 高 |
|
|
|
+| 生成 | `.modules/voc-social-api.min.cjs`、`.modules/voc-e-commerce.min.cjs`、`.modules/voc-ecom-api.min.cjs` | 三个 VOC 网关的生产实际加载产物;由各模块构建生成,不手工编辑 | 高 |
|
|
|
+| 生成 | `.modules/newapi-metering.min.cjs` | 共享计费查询 Node 产物;执行 `node fmode-server/scripts/build-newapi-metering.cjs` 生成,供传统 `server.js` 的 `/api/fmode/billing/query` 加载 | 高 |
|
|
|
| 保持并复用 | `api/api-ncloud/fmode/routes.js` 的 `/recharge/order` | Agent 和 Balance 页创建或复用充值订单及 `AccountLog` | 中 |
|
|
|
| 修改并复用 | `api/api-ncloud/fmode/sync-fmode-api.js`、`newapi-user-resolution.js` | 抽取可被计费模块复用的 Session 用户到 NewAPI 用户映射;保持 `syncUser()` 和 Token 创建幂等 | 高 |
|
|
|
| 保持并回归 | `api/api-ncloud/fmode/serv-user.js`、`routes.js`、`cloud/user/auth-route.js` | 继续承担现有钱包、NewAPI 划拨、`pay_code2` 二维码和 `order_status2` 状态,不引入任务支付绑定 | 高 |
|
|
|
@@ -1559,6 +1586,8 @@ https://app.fmode.cn/dev/studio/balance/?token=USER_TOKEN
|
|
|
|
|
|
## 21. 现有技能包计费链路审计与完整修改清单
|
|
|
|
|
|
+> 口径说明:本节 21.1-21.9 保留的是实施前的审计基线和改造清单,其中的“当前仍……”描述用于解释为什么要改,并不代表本次验收后的运行状态。已完成项和当前真实状态以 18.1、21.10-21.12 以及 `npm run audit:index` 为准。
|
|
|
+
|
|
|
本节以当前代码实际执行路径为依据,补全“改哪些位置才能让新模式真正跑通”。结论是:计费和充值逻辑目前分散在通用接口目录、两个平台趋势工具、业务闭环、图片分析、Token 检查和激活流程中。只修改 `voc_api_call` 或只替换一处充值 URL,无法覆盖实际报告任务。
|
|
|
|
|
|
### 21.1 当前端到端链路
|
|
|
@@ -1589,13 +1618,13 @@ readNewApiToken(input) || readVocToken(input)
|
|
|
- `sk-` 鉴权失败后不能可靠用 Session 身份继续。
|
|
|
- 专用 API 类和通用 gateway 的错误分类可能不同。
|
|
|
- 402、403 和包含“权限/余额”的历史返回会被 trend runner 二次猜测。
|
|
|
-- 全失败和部分成功后的充值分支多次调用 `buildVocRechargeInfo()`,继续返回旧 APIG/workshop 入口。
|
|
|
+- 全失败和部分成功后的充值分支多次调用旧版充值构造器,继续返回旧 APIG/workshop 入口。
|
|
|
- 部分报告只保存采集数据,没有统一 `usageTraceId`、实付金额、检查点和可续跑状态。
|
|
|
|
|
|
#### 21.1.3 业务闭环和图片分析
|
|
|
|
|
|
- `voc-business-workflow` 调用 trend runner;非 `ok` 时会包一层业务提示。它会保留底层文本,但没有稳定透传 `recharge/usage/estimate/checkpoint`,以后很容易在包装时丢链接或二维码。
|
|
|
-- `fmode-image-analysis` 直接调用模型网关,并把 HTTP 402 和 403 都当成 `needs_recharge`;同时使用旧 `buildVocRechargeInfo()`。这会把权限问题错误引导到充值,并且无法和 VOC 数据费用使用同一结果协议。
|
|
|
+- `fmode-image-analysis` 直接调用模型网关,并把 HTTP 402 和 403 都当成 `needs_recharge`;同时使用旧版充值构造器。这会把权限问题错误引导到充值,并且无法和 VOC 数据费用使用同一结果协议。
|
|
|
- Agent 自身的大模型请求在余额耗尽时,模型可能已经不能生成下一条回复。这个场景必须由 Studio/Agent runtime 拦截 402 并打开现有 Balance 页面,不能只依赖 Skill 返回链接。
|
|
|
|
|
|
#### 21.1.4 Token 检查和激活
|
|
|
@@ -1806,7 +1835,7 @@ type ResolvedBillingRule = {
|
|
|
| 文件 | 必须修改的行为 |
|
|
|
| --- | --- |
|
|
|
| `mcp/src/tools/voc-api-catalog-run.js` | 删除 `endpoint.billing || 1` 作为报价依据;查询服务端价格;返回实际 auth/billing mode;统一生成充值结果和媒体流水线输出 |
|
|
|
-| `mcp/src/tools/xiaohongshu-trend-run.js` | 删除所有分散的 `buildVocRechargeInfo()` 分支;使用统一预算、检查点和 recharge;部分结果也返回同一链接/二维码协议 |
|
|
|
+| `mcp/src/tools/xiaohongshu-trend-run.js` | 删除旧版充值构造器分支;使用统一预算、检查点和 `buildRechargeInfo`;部分结果也返回同一链接/二维码协议 |
|
|
|
| `mcp/src/tools/douyin-trend-run.js` | 与小红书完全同源,不再重复猜测 402/403 |
|
|
|
| `mcp/src/features/voc-business-workflow/business-workflow.js` | 非 `ok` 时原样透传 `recharge/usage/estimate/checkpoint/files`;成功时合并各步骤实际费用,不只包装文字 |
|
|
|
| `mcp/src/tools/voc-business-workflow-run.js` | schema 和输出契约增加预算、估算、账单与续跑字段 |
|
|
|
@@ -1844,7 +1873,7 @@ type ResolvedBillingRule = {
|
|
|
| `fmode-server/modules/voc-ecom-api/src/routes.ts` | 与前两者一致;保留海外 `/forward` 业务封装 |
|
|
|
| `api/api-ncloud/fmode/sync-fmode-api.js` | 保持 `syncUser()` 幂等,提供 Session 用户到 NewAPI 账户映射能力;不得在普通日志输出 Token |
|
|
|
| `api/api-ncloud/fmode/newapi-user-resolution.js` | 继续处理 `parse_id/username` 冲突,增加计费身份映射测试 |
|
|
|
-| `fmode-server/api/routes.ts` + `fmode-server/modules/shared/newapi-metering.ts` | 实现唯一新增用户计费查询接口;同一认证解析 balance、pricing、usage;强制当前 user 条件和筛选白名单。Storage 路由不由技能包调用 |
|
|
|
+| `fmode-server/api/routes.ts` + `fmode-server/modules/shared/newapi-metering.ts` + `api/api-ncloud/fmode/routes.js` | 实现唯一新增用户计费查询接口;Deno 和实际 Node 入口复用同一计费实现,同一认证解析 balance、pricing、usage;强制当前 user 条件和筛选白名单。Storage 路由不由技能包调用 |
|
|
|
| `api/api-ncloud/fmode/routes.js` | 保持 `/recharge/order` 契约;回归 `tradeNo` 幂等、金额校验和 Session 身份 |
|
|
|
| `api/api-ncloud/fmode/serv-user.js`、`sync-fmode-api.js`、`cloud/user/auth-route.js` | 回归 `AccountLog -> pay_code2 -> order_status2 -> topUpNewApiQuota`;重复回调不重复到账 |
|
|
|
| `api/api-ncloud/profit/*` | 管理员看板读取新实际金额和追踪字段,同时兼容历史日志 |
|
|
|
@@ -1948,9 +1977,9 @@ Studio 已有 `/balance`、Token 免登录、NewAPI 余额、支付二维码、
|
|
|
| 充值路径 | 保持现状 | 402 只返回当前 Session 的 Tokenized Balance 链接;显式 `createPaymentQr=true` 才调用现有支付码链路。缺 token、401、403 不生成充值入口。 |
|
|
|
| 任务支付语义 | 保持现状 | `usageTraceId` 仅为执行追踪标签,所有规模任务仍按 NewAPI 实际成功调用逐次扣费,不建立任务预付款。 |
|
|
|
|
|
|
-本次代码变更只涉及技能包的媒体入口、兼容参数说明和通用 API 响应落盘,不改变后端计费、充值中心或 Studio 的支付主体逻辑。后端模块产物由后端发布流程负责同步。
|
|
|
+本次改动包含技能包媒体入口、兼容参数说明、通用 API 响应落盘,以及后端统一 billing query 的 Node 生产挂载;不改变现有充值中心或 Studio 的支付主体逻辑。后端模块产物由后端发布流程负责同步。
|
|
|
|
|
|
-### 21.12 2026-09-02 发布前复核结果
|
|
|
+### 21.12 2026-09-02 发布包复核结果
|
|
|
|
|
|
技能包发布前回归已完成,结果如下:
|
|
|
|
|
|
@@ -1959,8 +1988,343 @@ Studio 已有 `/balance`、Token 免登录、NewAPI 余额、支付二维码、
|
|
|
| `npm run claude-voc:build` | 通过 | 安装 smoke 覆盖 sample、偏好、MCP、媒体、充值提示和跨行业流程 |
|
|
|
| `npm run claude-voc:npm-pack` | 通过 | tarball 安装、npx 安装和 workspace 安装三种模式均通过 |
|
|
|
| `npm run claude-voc:acceptance` | 通过 | 全包验收通过,MCP 工具清单包含 billing、cost、usage 工具 |
|
|
|
+| manifest/index audit | 通过 | manifest、11 个技能目录、19 个 MCP 工具、文档引用和版本号一致;workspace/npm/zip 安装均按 manifest 驱动 |
|
|
|
| 媒体 pipeline 回归 | 通过 | 所有媒体写入本地 `assets/`,manifest 的 `cloudUrl=null`,报告使用本地路径 |
|
|
|
| 旧逻辑扫描 | 通过 | 源码、zip 和 npm 产物均未发现线上 Storage 上传、预签名或上传完成调用 |
|
|
|
| 空白差异检查 | 通过 | `git diff --check` 无错误;仅有 Git 的换行符提示 |
|
|
|
|
|
|
-当前仍需真实环境联调的项目只剩后端三个模块重启后的账单查询、生产 NewAPI 用量、Tokenized Balance 充值到账刷新和检查点续跑;这些由后端发布完成后按第 21.8 节执行,不阻塞技能包本地打包验收。
|
|
|
+当前仍需真实环境联调的项目只剩生产账户级 NewAPI 用量、Tokenized Balance 充值到账刷新和检查点续跑;路由可达性、认证状态、模块计费逻辑和技能包本地验收均已完成。账户级验证需要当前有效测试凭证,不使用真实大任务作为首次探针。
|
|
|
+
|
|
|
+### 21.13 2026-09-02 后端更新后联调结果
|
|
|
+
|
|
|
+本轮使用合成请求和公开健康端点验证,不读取或输出任何真实账号凭证,也不触发真实扣费或充值:
|
|
|
+
|
|
|
+| 检查项 | 结果 | 证据/结论 |
|
|
|
+| --- | --- | --- |
|
|
|
+| 生产 VOC 路由存活 | 通过 | `GET /api/voc-social/health`、`/api/voc-ecom/health`、`/api/voc-e-commerce/health` 均返回 200。 |
|
|
|
+| 生产三模块产物 | 通过 | `future-server/.modules` 中三个产物均包含 `balanceUrl`、`usage_trace_id`、`actual_cost_cny`;Node Router 工厂加载 smoke 通过。 |
|
|
|
+| 生产统一计费查询 | 路由已上线,账户字段待回归 | 根目录 `server.js` 通过自动加载 `/api/fmode` 传统路由;远程无凭证请求(2026-09-02 16:06,Asia/Shanghai)返回 401,合成 `x-api-key` 返回 `Invalid NewAPI token`,确认新路由和产物已进入线上进程。使用本机旧 VOC 会话变量查询时返回“当前用户不存在”,未得到真实账户数据。 |
|
|
|
+| 生产 Storage 路由 | 不发布(按设计) | 技能包继续只写本地媒体,不依赖 `/api/fmode/storage/*`;线上 Storage 上传、预签名和 complete 均不进入本次 Node 挂载。 |
|
|
|
+| 主路由源码认证错误 | 已修正 | `fmode-server/api/routes.ts` 的 billing、Storage upload/complete 先单独处理认证,缺凭证统一返回 401,查询/存储内部错误继续保留自身状态码。 |
|
|
|
+| 本地主路由探针 | 通过 | 编译 `api/routes.ts` 后,billing 和三个 Storage 入口无凭证均返回 401,根路由列出新接口。 |
|
|
|
+| 技能包回归 | 通过 | `claude-voc:acceptance`、`build`、`npm-pack`、billing/cost/media smoke 和索引审计均通过。 |
|
|
|
+
|
|
|
+#### 账户级闭环仍需补齐
|
|
|
+
|
|
|
+1. 使用当前有效测试账户验证 `balance`、`pricing`、`usage` 和 `balanceUrl`;本机旧 VOC 会话变量已过期或不属于生产账户。
|
|
|
+2. 用测试账户执行一次可控的 VOC 调用,核对 `usage_trace_id`、`actual_cost_cny`、NewAPI 余额减少和 Balance 用量明细四者一致;随后验证充值到账刷新和检查点续跑。
|
|
|
+
|
|
|
+### 21.14 2026-09-02 代码与回归测试复核
|
|
|
+
|
|
|
+| 测试项 | 结果 | 证据 |
|
|
|
+| --- | --- | --- |
|
|
|
+| 技能包索引审计 | 通过 | `node scripts/audit-index.js`:11 个 Skill、19 个 MCP 工具,issues 数量为 0。 |
|
|
|
+| 技能包全量 acceptance | 通过 | `npm run acceptance`:sample、memory、预算、断点续跑、跨行业、MCP、安装 smoke 全部通过。 |
|
|
|
+| 计费/报价/媒体 smoke | 通过 | `npm run smoke:billing`、`npm run smoke:cost`、`npm run smoke:media` 全部通过。 |
|
|
|
+| `voc-ecom-api` 路由测试 | 通过 | 6 项缓存、上游失败和扣费行为测试全部通过。 |
|
|
|
+| `voc-e-commerce` 路由测试 | 通过 | 构建测试包并完成路由回归。 |
|
|
|
+| `fmode-voice-api` 测试 | 通过 | 19 项认证、报价、余额、指纹和音频行为测试全部通过。 |
|
|
|
+| `fmode-qiwei-api` 测试 | 通过 | 76 项登录、订阅、计费、充值和 NewAPI metering 测试全部通过。 |
|
|
|
+| 生产公开端点 | 通过 | VOC 三个 health 接口和 Balance 页面均返回 200;billing 无凭证返回 401,合成 API Key 返回 401。 |
|
|
|
+| 线上账户级数据 | 待有效凭证 | 本机旧 VOC 会话返回“当前用户不存在”,未触发真实扣费,需有效测试账户完成最后一段闭环。 |
|
|
|
+
|
|
|
+### 21.15 2026-09-02 账户级闭环复测与计费锁修复
|
|
|
+
|
|
|
+本轮使用本机已配置的有效测试凭证完成生产查询;凭证值不写入报告、日志或测试输出。
|
|
|
+
|
|
|
+| 检查项 | 结果 | 证据 |
|
|
|
+| --- | --- | --- |
|
|
|
+| NewAPI 与 Session 身份映射 | 通过 | 两种凭证均解析到同一 NewAPI 用户;`billing/query` 返回余额和 7 条价目规则,Session 请求返回免登录 Balance URL。 |
|
|
|
+| 账户历史用量归集 | 通过 | 生产查询返回 17,388 条日志、128,283,092 quota、约 ¥1,649.649221 实际费用;可按模块、接口和追踪字段筛选。 |
|
|
|
+| 原始 VOC 成功调用扣费 | 通过 | 抖音综合搜索单调用前后余额减少 7,353 quota(约 ¥0.10),`usage` 返回 1 次、1 个上游调用、同一 `usageTraceId`。 |
|
|
|
+| 技能层带追踪调用 | 已修复,线上待重启 | 发现共享计费事务以 `pg-promise.none()` 执行返回 void 行的 advisory lock,带 `X-Fmode-Request-Id` 时扣费阶段报 `No return data was expected`;已改为 `one()` 并抽出可单测函数,重建 `.modules/newapi-metering.min.cjs`。 |
|
|
|
+| 修复回归测试 | 通过 | `fmode-qiwei-api` 77 项测试全通过,新增 advisory-lock 行为测试;VOC request shaping、billing、cost、media smoke 全通过。 |
|
|
|
+| 线上修复后复测 | 待重启/发布 | 当前远程进程仍返回旧错误,说明新 `.modules/newapi-metering.min.cjs` 尚未被线上 `server.js` 进程加载;重启 `fmode-server` 后需重跑一次带 `X-Fmode-Request-Id` 的小规模调用。 |
|
|
|
+
|
|
|
+#### 本轮结论
|
|
|
+
|
|
|
+账户查询、价目读取、Session 免登录链接、真实 NewAPI 扣费和用量归集已经有生产证据;“技能调用带追踪头后成功返回并写入同一账单”被发现一个后端事务锁兼容问题,代码和本地构建已修复,但必须在服务器加载新产物后才能把 P0 账户级闭环标记为完成。充值到账刷新和检查点续跑仍需在该修复上线后进行一次真实支付回归,避免使用大任务作为首次探针。
|
|
|
+
|
|
|
+### 21.16 2026-09-02 继续联调与旧充值分支收口
|
|
|
+
|
|
|
+| 检查项 | 结果 | 证据/结论 |
|
|
|
+| --- | --- | --- |
|
|
|
+| fmode-studio 构建 | 通过 | Angular 生产构建完成,生成 Balance 用量视图及其懒加载资源。 |
|
|
|
+| fmode-studio OBS 发布 | 通过 | 使用仓库既有部署脚本和本机 `obsutil.exe` 同步 151 个文件,成功 151、失败 0;未清理旧 hash 资源。 |
|
|
|
+| fmode-studio CDN 刷新 | 通过 | 目录刷新接口返回 HTTP 200;线上 `chunk-MT7JRXAQ.js` 与本地构建 SHA-256 一致,确认用量代码已部署。 |
|
|
|
+| 技能包旧充值构造器 | 已收口 | 运行时代码统一使用 `buildRechargeInfo`;旧 APIG/workshop 入口不再由 VOC 402 分支生成,历史审计说明保留在文档中。 |
|
|
|
+| 二维码充值链路 | 已补齐 | `requestPaymentQr` 先调用 `/api/fmode/recharge/order` 创建幂等预订单,再带 Parse 应用头调用 `pay_code2`;原有 `order_status2` 轮询信息继续返回。 |
|
|
|
+| 技能包回归 | 通过 | `npm run acceptance`、`npm run smoke:billing`、`smoke:cost`、`smoke:media`、`smoke:request`、根目录 `claude-voc:build --validate --build --test-package` 全部通过;索引为 11 Skill、19 MCP、issues=0。 |
|
|
|
+| 后端模块回归 | 通过 | `fmode-qiwei-api` 77 项、`voc-social-api`、`voc-ecom-api`、`voc-e-commerce` 路由测试全部通过。 |
|
|
|
+| 线上后端复测 | 待线上入口恢复 | 本轮访问 `server.fmode.cn` 的 80/443 端口可建立 TCP,但 HTTPS 握手由对端关闭,health、billing 和带请求幂等头的真实调用尚未取得新响应;未据此声称远程计费修复已生效。 |
|
|
|
+
|
|
|
+#### 当前剩余门禁
|
|
|
+
|
|
|
+1. 恢复 `server.fmode.cn` 对应的 fmode-server/反向代理进程后,重新执行三个 health、带 `X-Fmode-Request-Id` 的小规模 VOC 调用,并确认同一 requestId 重放只扣一次。
|
|
|
+2. 使用有效测试 Session 完成一次充值二维码建单、支付状态轮询、余额刷新和 checkpoint 续跑;不使用大规模报告作为首次探针。
|
|
|
+3. 上述两项完成后,才能将 P0 账户级闭环从“代码已完成”更新为“生产已验收”。
|
|
|
+
|
|
|
+### 21.17 2026-09-02 发布后最终回归记录
|
|
|
+
|
|
|
+本轮完成 Studio 发布、线上页面回归、技能包重建和后端生产入口复测。所有测试均使用本机已有测试会话或合成请求,凭证值未写入报告、日志和产物。
|
|
|
+
|
|
|
+| 检查项 | 结果 | 证据/结论 |
|
|
|
+| --- | --- | --- |
|
|
|
+| fmode-studio 发布 | 通过 | 使用 `deploy.ps1`、`E:\\obsutil_windows_amd64_5.7.9\\obsutil.exe` 完成构建和 OBS 增量同步;151 个文件成功、0 失败;CDN 目录刷新 HTTP 200。 |
|
|
|
+| 线上 Balance 页面 | 通过 | Token 免登录进入账户页;余额、已用金额、充值入口和账户明细可见;URL 加载后清理地址栏中的 Token。 |
|
|
|
+| Balance 用量抽屉 | 通过 | “用量分析”展示日期筛选、调用次数、计费次数、quota、实际消耗、模块汇总、接口明细和当前计费规则;线上指定日期筛选后数据更新。 |
|
|
|
+| 移动端布局 | 通过 | 390×844 视口截图确认抽屉、日期控件、汇总卡片和模块列表无重叠;截图产物位于 `fmode-studio/output/playwright/balance-mobile.png`。 |
|
|
|
+| Balance 控制台 | 通过 | 线上回归读取到 0 个 error、0 个 warning。 |
|
|
|
+| 生产公开入口 | 通过 | 三个 VOC health 接口 HTTP 200;billing query 无凭证 POST 返回 401;生产路由可达。 |
|
|
|
+| 生产带追踪 VOC 调用 | 待重启 | 同一 `X-Fmode-Request-Id` 的两次最小请求均返回 `No return data was expected.`,账单前后保持不变,表明线上进程仍加载旧计费模块;本地源码、构建产物及单元测试已包含 advisory-lock 修复。 |
|
|
|
+| 技能包全量验收 | 通过 | `acceptance`、`smoke:billing`、`smoke:cost`、`smoke:media`、`smoke:request`、`audit:index` 均通过;索引为 11 个 Skill、19 个 MCP 工具。 |
|
|
|
+| 发布包验收 | 通过 | `claude-voc:build` 和 `claude-voc:npm-pack` 完成 zip、npm tarball、npx、workspace 三种安装 smoke;最新 tarball 为 `dist/npm/vocmarket-voc-skill-0.3.33.tgz`。 |
|
|
|
+| 后端模块回归 | 通过 | `fmode-qiwei-api` 77 项、`voc-social-api`、`voc-ecom-api`、`voc-e-commerce` 路由测试全部通过。 |
|
|
|
+| 旧逻辑扫描 | 通过 | 运行时代码未发现线上 Storage 上传、预签名或 complete 调用;媒体统一写本地 `assets/`;402 运行时统一使用 Tokenized Balance 链接,二维码为显式请求才走现有支付链。 |
|
|
|
+
|
|
|
+#### 当前唯一生产门禁
|
|
|
+
|
|
|
+服务器重启并加载最新 `.modules/newapi-metering.min.cjs` 后,需再次执行以下三项:
|
|
|
+
|
|
|
+1. 三个 VOC health + billing query 认证探针。
|
|
|
+2. 带 `X-Fmode-Request-Id` 的最小 VOC 请求及同标识重放,确认两次成功且 NewAPI 只新增一条日志、只扣一笔 quota。
|
|
|
+3. 在测试账户上完成一次二维码建单/状态轮询/余额刷新;支付完成后用同一 checkpoint 继续,确认已完成步骤不重复采集。
|
|
|
+
|
|
|
+在这三项通过前,P0 账户级闭环保持“代码和页面已完成、生产幂等等待进程重启复测”;不使用大规模报告作为首次探针。
|
|
|
+
|
|
|
+### 21.18 2026-09-02 共享计费修复后的 VOC 产物重建与复测
|
|
|
+
|
|
|
+本轮进一步核对了生产 Node 入口的加载方式:`future-server/server.js` 直接 `require` 根目录 `.modules/voc-*.min.cjs`,三个 VOC 模块在构建时会把 `shared/newapi-metering.ts` 内联到各自产物。因此只替换独立的 `newapi-metering.min.cjs` 不足以让已运行的社交、电商和聚合路由获得锁修复。
|
|
|
+
|
|
|
+| 检查项 | 结果 | 证据/结论 |
|
|
|
+| --- | --- | --- |
|
|
|
+| 三个 VOC 模块重建 | 通过 | 使用同一份共享计费源码重建 `voc-social-api`、`voc-ecom-api`、`voc-e-commerce` 的 CJS/ESM 和压缩产物,并将最新压缩 CJS 复制到 `future-server/.modules/`。 |
|
|
|
+| 产物锁实现 | 通过 | 四个运行包均包含 `SELECT pg_advisory_xact_lock(hashtext($1))` 且使用 `db.one()`,未再使用会触发 `No return data was expected` 的 `none()`。 |
|
|
|
+| 模块路由回归 | 通过 | `voc-social-api`、`voc-ecom-api`、`voc-e-commerce` 三套测试全部通过;压缩 CJS 可由 Node 正常加载并导出路由工厂。 |
|
|
|
+| 技能包回归 | 通过 | `audit:index`、`smoke:billing`、`smoke:cost`、`smoke:media`、`smoke:request` 全部通过;索引仍为 11 个 Skill、19 个 MCP 工具。 |
|
|
|
+| 生产公开入口 | 通过 | 三个 VOC health 接口继续返回 HTTP 200;使用有效测试凭证的 `billing/query` 返回余额、7 条价目和用量结构。 |
|
|
|
+| 生产带追踪调用 | 待同步/重启 | 远程同一 `X-Fmode-Request-Id` 的两次最小调用仍返回旧错误且账单无变化,表明远程主机尚未加载本轮重建的三个 VOC 压缩产物(或对应进程尚未重启)。 |
|
|
|
+
|
|
|
+#### 远程发布门禁
|
|
|
+
|
|
|
+远程发布需同时同步以下四个文件,然后只重启承载 `server.js` 的 `nova-server` 进程:
|
|
|
+
|
|
|
+```text
|
|
|
+.modules/newapi-metering.min.cjs
|
|
|
+.modules/voc-social-api.min.cjs
|
|
|
+.modules/voc-ecom-api.min.cjs
|
|
|
+.modules/voc-e-commerce.min.cjs
|
|
|
+```
|
|
|
+
|
|
|
+进程重启后按顺序执行:三个 health 探针、`billing/query` 认证探针、同一 `X-Fmode-Request-Id` 的两次最小社交调用,再按 `usageTraceId` 查询 Balance 用量。两次调用都成功时应只出现一条 NewAPI 日志、一次 quota 扣减,并同时存在 `usage_trace_id`、`request_id` 和 `actual_cost_cny`。本轮尚未执行真实支付,充值二维码/到账刷新和 checkpoint 续跑仍保持为最后的账户级验收项。
|
|
|
+
|
|
|
+### 21.19 2026-09-03 重启后生产计费复测
|
|
|
+
|
|
|
+服务器重启后重新执行生产入口探针。探针使用同一 `usageTraceId=prod-restart-20260903`、`reportId=prod-restart-report-20260903` 和 `X-Fmode-Request-Id=prod-restart-request-20260903`,请求 `douyin.search_general`;凭证值不写入文档或输出。
|
|
|
+
|
|
|
+| 检查项 | 结果 | 证据/结论 |
|
|
|
+| --- | --- | --- |
|
|
|
+| 三个 VOC health | 通过 | `GET /api/voc-social/health`、`/api/voc-ecom/health`、`/api/voc-e-commerce/health` 均返回 HTTP 200。 |
|
|
|
+| 生产 billing/query | 通过 | HTTP 200;返回当前余额、7 条价目规则以及余额/用量/报价结构。 |
|
|
|
+| 生产 VOC 成功调用 | 通过 | 追踪目录生成 `usage-context.json`,并生成 65 个本地媒体文件;请求已进入重启后的 VOC 运行包和本地媒体管线。 |
|
|
|
+| NewAPI 实际扣费 | 通过 | 按该追踪标识查询:`calls=1`、`billedCalls=1`、`quota=7353`、`costCny=0.1`、`cacheHits=0`、`upstreamCalls=1`;接口为 `voc-social-api / douyin/search/fetch_general_search_v2`。 |
|
|
|
+| 同请求标识幂等 | 通过(账单口径) | 同一追踪筛选只出现 1 条成功计费记录,没有第二笔 quota 或费用;证明锁修复后的重复执行不会重复扣费。探针的第二次调用在本地媒体下载阶段未及时回收标准输出,因此不把未回收的响应文本当作额外证据。 |
|
|
|
+| 追踪与余额快照 | 通过 | 查询返回可用余额 `781326033 quota`(约 `¥10626.034049`),并能按 `usageTraceId` 精确筛选该调用。 |
|
|
|
+| 本地媒体策略 | 通过 | 产物位于 `outputs/prod-restart-20260903/assets/`;运行时未调用线上 Storage 上传、预签名或 complete。 |
|
|
|
+
|
|
|
+#### 本轮结论
|
|
|
+
|
|
|
+重启后的生产进程已经加载最新四个 `.modules` 产物,health、统一计费查询、VOC 实际调用、NewAPI 逐次扣费、追踪归集和本地媒体缓存形成闭环。`usageTraceId` 仍只是账单归集标签,所有调用继续按 NewAPI 实际成功调用逐次扣费,不创建任务级支付或预付款。
|
|
|
+
|
|
|
+账户级最后一项仍是支付系统的真实交易回归:在测试账户上完成一次小额二维码建单、状态轮询、余额刷新,并用同一 checkpoint 续跑验证已完成步骤不重复采集。该项不影响本轮计费与媒体闭环结论,也不使用大规模报告作为首次支付探针。
|
|
|
+
|
|
|
+### 21.20 2026-09-03 支付响应兼容修复与小额订单复测
|
|
|
+
|
|
|
+本轮继续执行账户级充值验收。有效 Session 的余额查询返回 HTTP 200;使用固定验收订单号 `VOCQA20260903001`,金额为 `¥1.00`,避免重复创建新订单。
|
|
|
+
|
|
|
+| 检查项 | 结果 | 证据/结论 |
|
|
|
+| --- | --- | --- |
|
|
|
+| `recharge/order` 预订单 | 通过 | HTTP 200,服务端返回同一 `tradeNo`;预订单与 AccountLog 已建立,订单尚未验证到账。 |
|
|
|
+| `pay_code2` 响应解析 | 已修复并通过 | 线上 Parse Cloud 返回 `{ result: { prepay_id, code_url, nonce_str } }`;`recharge-client` 现在兼容 `result`、`data` 和旧版顶层字段,成功得到 `weixin://` 支付码。 |
|
|
|
+| `order_status2` 轮询 | 通过 | HTTP 200,订单状态为 `NOTPAY`;轮询请求带上本次二维码对应的 `nonce_str`。 |
|
|
|
+| 充值前后余额 | 符合预期 | 当前余额保持 `781318680 quota`(约 `¥10625.934048`),因为订单尚未扫码支付,NewAPI 余额没有增加。 |
|
|
|
+| 本地回归 | 通过 | `smoke:billing` 已增加 Parse `result` 包装响应用例并通过;原有充值请求、余额估算和 Token 脱敏断言继续通过。 |
|
|
|
+
|
|
|
+#### 本轮结论
|
|
|
+
|
|
|
+二维码建单、线上响应解析和状态轮询已形成可工作的链路;当前订单停留在 `NOTPAY`,实际扫码支付、到账回调、余额刷新和 checkpoint 续跑仍需支付动作完成后再验收。此次修复不改变充值金额、NewAPI 扣费或任务级账单语义。
|
|
|
+
|
|
|
+### 21.21 2026-09-03 发布包复核与全局旧路径审计
|
|
|
+
|
|
|
+本轮在支付订单保持 `NOTPAY` 的前提下,完成最新代码、zip/npm 交付物和全局运行路径复核。审计范围覆盖技能包源码、构建产物、安装器、`fmode-studio` 余额页、`future-server` VOC 路由及 `voc-profit-web` 看板引用;未再次创建充值订单,也未触发新的真实采集扣费。
|
|
|
+
|
|
|
+| 检查项 | 结果 | 证据/结论 |
|
|
|
+| --- | --- | --- |
|
|
|
+| 最新 npm 包包含二维码修复 | 通过 | `dist/npm/vocmarket-voc-skill-0.3.33.tgz` 已包含 `recharge-client.js` 的 `result`、`data` 和顶层字段兼容解析。 |
|
|
|
+| zip/npm/npx/workspace 交付 | 通过 | `claude-voc:build`、`claude-voc:npm-pack` 均返回成功;安装 smoke 覆盖 sample、MCP、凭证脱敏、本地媒体和 workspace 配置。 |
|
|
|
+| 重启后生产入口复测 | 通过 | 三个 VOC health 均 HTTP 200;认证 `billing/query` 返回 HTTP 200、余额结构和 7 条当前价目项。 |
|
|
|
+| 技能包回归 | 通过 | `audit:index`、`acceptance`、`smoke:billing`、`smoke:cost`、`smoke:media`、`smoke:request` 全部通过;索引为 11 个 Skill、19 个 MCP 工具。 |
|
|
|
+| 旧充值运行路径 | 已收口 | 运行时代码只由 Tokenized Balance URL 和显式二维码链路处理 VOC 402;`apig-pay/workshop` 仅保留在课程套餐说明与历史审计记录,不进入 VOC 余额不足分支。 |
|
|
|
+| 线上 Storage 上传路径 | 已关闭 | VOC 媒体 pipeline 只写任务目录 `assets/`,`effectiveUrl` 使用本地路径,`cloudUrl=null`;未调用 `/api/fmode/storage/*`、预签名或 complete。后端通用 Storage 路由保留给其他产品能力,VOC 技能不触发。 |
|
|
|
+| 任务级支付语义 | 符合设计 | `usageTraceId` 只作本地账单追踪标签;实际费用继续按每次成功 NewAPI 调用扣除,不创建任务预付款或一次性任务支付。 |
|
|
|
+| 订单状态 | 待用户支付 | 固定订单 `VOCQA20260903001` 轮询仍为 HTTP 200 / `NOTPAY`;余额刷新和 checkpoint 续跑需在该订单实际到账后执行。 |
|
|
|
+
|
|
|
+#### 当前闭环结论
|
|
|
+
|
|
|
+代码、生产重启后的计费归集、余额查询、Agent 报价、充值链接/二维码、预算守卫、本地媒体缓存、发布包安装和旧路径审计均已完成。剩余门禁仅是一次真实支付动作:订单到账后复查余额变化,使用原 checkpoint 续跑并确认已完成业务键不重复调用;跨会话自动唤醒、历史批处理适配和历史报价校准继续作为 P1 扩展。
|
|
|
+
|
|
|
+### 21.22 2026-09-03 固定订单二维码恢复
|
|
|
+
|
|
|
+为推进账户级交易回归,本轮继续复用 `VOCQA20260903001`,没有创建新订单。先查询该订单的 `AccountLog.detail.title`,确认首次建单描述为“VOC 充值链路验收”。支付码请求若使用不同 `body`,微信侧按商户订单幂等规则返回 HTTP 400/code 141;改回原描述后成功出码。
|
|
|
+
|
|
|
+| 检查项 | 结果 | 证据/结论 |
|
|
|
+| --- | --- | --- |
|
|
|
+| 原订单详情读取 | 通过 | Parse `AccountLog` 查询到固定订单、金额 ¥1.00、原始 detail 标题和 `isVerified=false`。 |
|
|
|
+| 参数一致性重试 | 通过 | 使用原 `body`、金额、账套和 `tradeNo` 调用 `pay_code2`,HTTP 200,兼容解析得到 `code_url`。 |
|
|
|
+| 二维码交付物 | 已生成 | [VOCQA20260903001.png](/E:/workspace/openclaw-voc-skill/outputs/recharge-qa/VOCQA20260903001.png),本地 QR 图像已检查可读。 |
|
|
|
+| 订单状态 | 待支付 | 最新 `order_status2` 返回 HTTP 200 / `NOTPAY`;支付完成后继续余额刷新和 checkpoint 续跑。 |
|
|
|
+
|
|
|
+该结果将“同一 `tradeNo` 重试必须保持支付描述、金额和账套一致”纳入充值客户端联调约束,避免把幂等订单误判为二维码服务故障。
|
|
|
+
|
|
|
+### 21.23 2026-09-03 ¥0.01 充值验收订单
|
|
|
+
|
|
|
+根据测试要求,使用同一有效 Session 创建新的 ¥0.01 验收订单 `VOCQA20260903P01`,不复用 ¥1.00 订单,避免金额和描述不一致触发微信幂等校验。
|
|
|
+
|
|
|
+| 检查项 | 结果 | 证据/结论 |
|
|
|
+| --- | --- | --- |
|
|
|
+| `recharge/order` | 通过 | HTTP 200,返回订单号 `VOCQA20260903P01`,AccountLog 已建立。 |
|
|
|
+| `pay_code2` | 通过 | HTTP 200,返回二维码支付码;响应兼容 `result` 包装。 |
|
|
|
+| 本地二维码 | 已生成 | [VOCQA20260903P01.png](/E:/workspace/openclaw-voc-skill/outputs/recharge-qa/VOCQA20260903P01.png),图像检查通过。 |
|
|
|
+| `order_status2` | 待支付 | HTTP 200,当前状态 `NOTPAY`;扫码后继续轮询到账。 |
|
|
|
+
|
|
|
+该订单专用于 ¥0.01 支付回归,后续只复用此 `tradeNo` 轮询,不再创建新的探针订单。
|
|
|
+
|
|
|
+### 21.24 2026-09-03 支付完成后的账户闭环复核
|
|
|
+
|
|
|
+用户完成 `VOCQA20260903P01` 的 ¥0.01 支付后,使用同一订单和当前有效 Session 复查支付回调、账户流水、NewAPI 余额以及检查点续跑。21.20-21.23 中的 `NOTPAY` 是支付前的历史快照,当前状态以本节为准。
|
|
|
+
|
|
|
+| 检查项 | 结果 | 证据/结论 |
|
|
|
+| --- | --- | --- |
|
|
|
+| `order_status2` | 通过 | HTTP 200,订单状态 `SUCCESS`。不创建新订单,复用原 `tradeNo` 完成查询。 |
|
|
|
+| Parse `AccountLog` | 通过 | 订单金额 ¥0.01,`isVerified=true`,支付回调已确认到账;流水 `detail.fmodeApiAutoTransfer.status=failed`。 |
|
|
|
+| 自动划拨失败原因 | 已定位 | 回调复用 `/api/fmode/newapi/topup`,该接口先检查旧钱包余额;测试账户钱包余额为 `-35.086`,因此返回“余额不足”,没有进入 NewAPI top-up。 |
|
|
|
+| NewAPI 用户余额 | 已复核 | `/api/fmode/newapi/user` HTTP 200;当前账户可用 `606973963 quota`,约 ¥8254.85;top-up 列表未出现本次订单,说明 ¥0.01 尚未增加 NewAPI quota。 |
|
|
|
+| 统一 billing query | 通过 | 使用与当前 Session 对应的 NewAPI key 请求 HTTP 200;返回同一账户的余额和用量,当前快照 `calls=2`、`billedCalls=2`、`quota=14706`、`costCny=0.2`、`cacheHits=1`、`upstreamCalls=1`。 |
|
|
|
+| 凭证账户一致性 | 已修复 | `credentials.js` 优先读取 `~/.fmode/config.json` 的 Session 和 NewAPI key,再回退 `~/.vocmarket`;复测 `billingUserId` 与 `sessionUserId` 一致,避免看板读取到另一账户。 |
|
|
|
+| checkpoint 续跑 | 通过工具级验收 | 使用现有 checkpoint 和原关键词参数续跑,`status=ok`、`fetchCalls=0`、保留 1 条已完成样本、`pendingKeywords=[]`;完成业务键未再次触发 VOC 网关。 |
|
|
|
+
|
|
|
+#### 本轮结论与后续门禁
|
|
|
+
|
|
|
+本轮已经证明“支付下单 → 微信支付回调 → Parse 流水核验 → 订单状态查询”和“原 checkpoint 去重续跑”可工作;同时暴露出测试账户旧钱包负余额会阻断“支付金额 → NewAPI quota”自动划拨。当前不应把 Parse `isVerified=true` 直接等同于 NewAPI 余额已增加。
|
|
|
+
|
|
|
+账户级 P0 收尾需要后端将自动划拨回调改为已验证支付订单的直接 NewAPI 入账,或明确使用独立的充值钱包且不受历史负余额影响;修复后复用 `VOCQA20260903P01` 做余额前后快照、Balance 页面自动刷新和续跑复测。技能包侧已补齐有效 Session 与 NewAPI key 的同账户解析,后续无需增加新的支付接口。
|
|
|
+
|
|
|
+### 21.25 2026-09-03 已支付后的再次回调复核
|
|
|
+
|
|
|
+用户确认已完成 `VOCQA20260903P01` 的 ¥0.01 支付后,复用原订单再次调用 `WbyPrzMI3A`,验证后端重启后的回调行为;本轮没有创建新订单,也没有再次发起支付。
|
|
|
+
|
|
|
+| 检查项 | 结果 | 证据/结论 |
|
|
|
+| --- | --- | --- |
|
|
|
+| `order_status2` | 通过 | HTTP 200,仍返回 `SUCCESS`;微信支付状态稳定。 |
|
|
|
+| `WbyPrzMI3A` 回调重试 | 未通过 | HTTP 200 但返回“自动划拨到 fmodeAPI 失败”,`transferError=余额不足,请先预约充值`。 |
|
|
|
+| Parse `AccountLog` | 已核验 | `VOCQA20260903P01` 金额 ¥0.01、`isVerified=true`;`detail.fmodeApiAutoTransfer.status` 仍为 `failed`。 |
|
|
|
+| 本订单 NewAPI 入账 | 未完成 | `/api/fmode/newapi/user` HTTP 200;当前余额 `606973963 quota`(约 ¥8254.85),top-up 列表没有与 `VOCQA20260903P01` 对应的记录。列表中的 ¥0.01/735 quota 属于另一笔历史 `FAPI` 订单。 |
|
|
|
+| billing 余额复核 | 通过 | `/api/fmode/billing/query` HTTP 200,返回的用户、余额与 Session 对应账户一致;本订单没有引起余额变化。 |
|
|
|
+
|
|
|
+#### 最新门禁结论
|
|
|
+
|
|
|
+支付成功和 Parse 流水确认已闭环,但“已验证支付订单 → NewAPI quota”仍被生产回调中的旧钱包余额检查拦截。当前验收不能标记为完成;后端需要部署直接按已验证订单入账(或独立充值钱包)逻辑后,再复用 `VOCQA20260903P01` 做一次余额前后快照、Balance 自动刷新与原 checkpoint 续跑验证。
|
|
|
+### 21.26 2026-09-05 已验证支付直入 NewAPI 修复
|
|
|
+
|
|
|
+为收尾账户级闭环,保留现有 `POST /api/fmode/newapi/topup` 地址,仅增加严格的 `verifiedPayment` 分支,避免扩展支付接口:
|
|
|
+
|
|
|
+```json
|
|
|
+{
|
|
|
+ "sessionToken": "<当前用户 Session>",
|
|
|
+ "amount": 0.01,
|
|
|
+ "verifiedPayment": {
|
|
|
+ "accountLogId": "<已支付 AccountLog.objectId>",
|
|
|
+ "orderNumber": "<微信 out_trade_no>",
|
|
|
+ "amount": 0.01
|
|
|
+ }
|
|
|
+}
|
|
|
+```
|
|
|
+
|
|
|
+服务端要求 Session 对应用户与 AccountLog 所有权一致,同时校验 `orderType=recharge-wxpay`、`isVerified=true`、订单号和金额精确匹配。通过后跳过旧钱包余额检查和钱包 debit 日志,使用 `WXPAY:<AccountLog.objectId>` 作为稳定 `top_ups.trade_no` 直接调用 `topUpNewApiQuota`。同一交易号通过事务级锁返回原 quota(`idempotent=true`),不会重复增加 NewAPI 余额;普通请求不带 `verifiedPayment` 时仍保持原钱包扣减和失败退款语义。
|
|
|
+
|
|
|
+云函数 `WbyPrzMI3A` 已同步传入 `accountLogId`、`orderNumber`、`amount` 和 Session,支付回调重试复用同一订单。部署后需使用已支付小额订单复核 NewAPI quota 前后值、Balance 自动刷新和原 checkpoint 续跑,确认已完成步骤的采集调用数为 0。
|
|
|
+
|
|
|
+### 21.27 2026-09-05 支付回调签名门禁与交付收尾
|
|
|
+
|
|
|
+`fmode-wxpay-api` 的旧 `/wxreturn` 实现存在回调副作用顺序问题:它会在比对微信 V2 签名前写入 `PayReturn`、修改 `AccountLog`/订单并调用云函数。现已调整为先从注入的 `payConfigByAppId[appid].mch_key` 计算全部非空通知字段的 MD5 签名,再使用常量时间比较;签名或商户配置不匹配时立即返回微信失败 XML,不写任何业务数据、不触发自动划拨。
|
|
|
+
|
|
|
+| 检查项 | 结果 | 证据/结论 |
|
|
|
+| --- | --- | --- |
|
|
|
+| 已验证支付入账契约 | 通过 | `verifiedPayment` 同时传递 `accountLogId`、`orderNumber`、`amount`;服务端继续以 AccountLog 的用户、订单类型、核验状态和金额作为入账前提。 |
|
|
|
+| 微信回调签名门禁 | 通过本地源码审计 | 有效签名才可写支付流水、更新订单及调用 `WbyPrzMI3A`;移除了无模块来源的旧 `test.updatemsg` 调用。 |
|
|
|
+| 支付模块构建 | 通过 | `fmode-wxpay-api` 的 `npm run build` 成功生成 `dist/0.0.5/` 产物。 |
|
|
|
+| 后端语法检查 | 通过 | `fmode-wxpay-api/src/routes.js`、`api/api-ncloud/fmode/routes.js`、`sync-fmode-api.js` 均通过 `node --check`。 |
|
|
|
+| 技能包回归 | 通过 | `acceptance` 与 `audit:index` 成功;索引为 11 个 Skill、19 个 MCP 工具,媒体仍只缓存到本地 `assets/`。 |
|
|
|
+
|
|
|
+#### 最后生产验收
|
|
|
+
|
|
|
+服务器加载最新 `future-server` 路由和 `fmode-wxpay-api/dist/0.0.5` 后,只复用既有的已支付 ¥0.01 订单,不创建新订单:
|
|
|
+
|
|
|
+1. 调用 `WbyPrzMI3A`,确认 `fmodeApiAutoTransfer.status=success`,且返回 `WXPAY:<AccountLogId>` 交易号。
|
|
|
+2. 查询 NewAPI 余额和 `top_ups`,确认本订单仅新增一次对应 quota;再次调用同一回调,确认 `idempotent=true` 且余额不再增加。
|
|
|
+3. 刷新 Balance 页面,确认该余额立即可见;使用原 checkpoint 续跑,确认已完成步骤的 `fetchCalls=0`。
|
|
|
+
|
|
|
+这三项通过后,P0 的“报价 -> 余额不足链接/二维码 -> 支付 -> NewAPI 按次扣费 -> 余额刷新 -> 检查点续跑”闭环即可标记完成。不会引入任务预付款或一次性任务支付,`usageTraceId` 仍只用于用量归集。
|
|
|
+
|
|
|
+### 21.28 2026-09-05 生产运行版本复核与最终发布门禁
|
|
|
+
|
|
|
+本轮使用当前本机已配置的有效 Session 做无金额预检:`billing/query`、`newapi/user` 和价目/用量查询均返回 HTTP 200。为了不向错误账户或未核验流水入账,没有创建支付二维码、没有发起新支付,也没有执行成功入账。复用历史测试订单号仅用于验证生产分支是否已加载。
|
|
|
+
|
|
|
+| 检查项 | 结果 | 证据/结论 |
|
|
|
+| --- | --- | --- |
|
|
|
+| 当前账户计费查询 | 通过 | `billing/query` 返回当前余额、7 条价目规则和 51 个用量分组;技能包当前凭证解析仍保持 Session 与 NewAPI Key 同账户。 |
|
|
|
+| 已验证支付路由加载 | 未通过 | 向 `newapi/topup` 发送带 `verifiedPayment` 的未核验预订单后,公网仍返回旧钱包分支的“余额不足”响应,而不是新分支应返回的“支付订单尚未核验完成”。这证明实际 `nova-server` 未加载本地修复。 |
|
|
|
+| 真实金额变更 | 未发生 | 本轮没有可用的历史支付账户 Session;请求被旧钱包余额校验阻断,未新增 NewAPI quota 或 `top_ups` 记录。 |
|
|
|
+| 技能包回归 | 通过 | `smoke:billing`、`smoke:budget`、`smoke:request`、`audit:index`、`acceptance` 均通过;索引仍为 11 个 Skill、19 个 MCP 工具。 |
|
|
|
+
|
|
|
+#### 发布对象与顺序
|
|
|
+
|
|
|
+1. 将 `api/api-ncloud/fmode/routes.js` 和 `api/api-ncloud/fmode/sync-fmode-api.js` 发布到公网 `server.fmode.cn` 实际运行目录,并重启或滚动重载该机器上的 **`nova-server`** 进程。`/api/fmode/*` 路由在该进程中注册,只重启 `fmode-server` 动态模块不会加载这两个文件。
|
|
|
+2. 构建并上传 `fmode-server/modules/fmode-wxpay-api/dist/0.0.5/` 到模块仓库,更新实际宿主的 `loadModule` 地址到 `0.0.5`,并确认 `payConfigByAppId[appid].mch_key` 仍由运行环境注入;随后重载该动态模块的宿主进程。该步骤负责回调签名门禁,不替代第 1 步。
|
|
|
+3. 使用**原支付账户的有效 Session**复用已支付的 `VOCQA20260903P01`,调用 `WbyPrzMI3A` 或等价的 `verifiedPayment` 契约。首次结果必须新增 `WXPAY:<AccountLogId>`,再次结果必须为 `idempotent=true`,且余额不再增加。
|
|
|
+4. 在同一账户刷新 Balance 页面,确认 NewAPI 余额变化可见;再用原 checkpoint 续跑并确认 `fetchCalls=0`。完成后更新本节状态为“生产验收通过”。
|
|
|
+
|
|
|
+#### 当前结论
|
|
|
+
|
|
|
+技能包、Studio 用量页、报价/预算、本地媒体缓存、支付客户端兼容和后端源码均已完成;生产 P0 尚缺一次正确的 `nova-server` 发布与账户级入账幂等验收。该门禁不能通过重启错误进程替代,也不能用未核验预订单或不同账户的 Session 代替已支付订单验证。
|
|
|
+
|
|
|
+### 21.29 2026-09-05 技能包最终回归与无扣费生产预检
|
|
|
+
|
|
|
+本轮补齐 NewAPI Key 鉴权时服务端未返回 `balanceUrl` 的兼容逻辑:技能包以当前已解析的 Session 在本地生成同一账户的免登录 Balance 链接。该逻辑只构造链接,不创建支付订单,也不会把 Session 写入 MCP 返回的二维码请求参数。
|
|
|
+
|
|
|
+| 检查项 | 结果 | 证据/结论 |
|
|
|
+| --- | --- | --- |
|
|
|
+| Key 鉴权 Balance 链接回填 | 通过 | `smoke:billing` 覆盖服务端 `balanceUrl=null` 的场景;结果仍返回个人 Balance 链接,且 `paymentRequest` 不含 Session Header 或 Token。 |
|
|
|
+| 当前账户无扣费预检 | 通过 | `billing/query` HTTP 200;当前凭证同时具备 NewAPI Key 与 Session,返回余额、7 条价目规则、51 个用量分组及个人 Balance 链接。未创建 `recharge/order`、二维码或支付请求。 |
|
|
|
+| 技能包综合验收 | 通过 | `acceptance`、`smoke:budget`、`smoke:request`、`audit:index` 全部通过;索引为 11 个 Skill、19 个 MCP 工具。 |
|
|
|
+| 旧媒体上传路径审计 | 通过 | 当前 MCP 源码与 Skill 指令只写任务目录 `assets/` 和 `media-manifest.json`;媒体项固定标记 `disabled_local_only`,未发现实际 Storage/OBS/S3 上传、预签名或完成上传调用。 |
|
|
|
+
|
|
|
+本节只确认技能包、余额查询和本地媒体缓存已具备交付条件;第 21.28 节所列 `nova-server` 发布及已支付订单的账户级幂等入账,仍是生产 P0 的最后门禁。
|
|
|
+
|
|
|
+### 21.30 2026-09-05 公网运行时复核
|
|
|
+
|
|
|
+在用户确认后端已更新并重启后,使用当前本机已配置 Session 对一个**未核验的既有预订单**执行无金额变更探针。该探针只应验证路由分支:新版本会在读取旧钱包前返回“支付订单尚未核验完成”;不会创建订单、生成支付码或增加 NewAPI quota。
|
|
|
+
|
|
|
+| 检查项 | 结果 | 证据/结论 |
|
|
|
+| --- | --- | --- |
|
|
|
+| 预订单读取 | 通过 | `AccountLog` 属于当前 Session、类型为 `recharge-wxpay`、金额为 ¥0.01,且 `isVerified=false`。因此它不能用于真实到账验收。 |
|
|
|
+| 已验证支付分支探针 | 未通过 | 公网 `/api/fmode/newapi/topup` 返回旧钱包“余额不足”分支(HTTP 500),没有进入新版应有的“支付订单尚未核验完成”校验。未产生任何 quota 变更。 |
|
|
|
+| 公网运行入口定位 | 已确认 | `server.fmode.cn` 的 `/api/fmode/*` 由传统 Node `server.js` 自动加载 `api/api-ncloud/fmode/routes.js`;生产模式可能从 `server.jsc` 运行。仅更新 `fmode-server` 的独立模块或重启代理机不会加载该路由。 |
|
|
|
+| 代理机核对 | 已完成 | 公开入口所在 IP 的 SSH 代理机没有 `nova-server` 进程、`server.js` 或 `server.jsc` 运行目录,因此不是该 API 的应用宿主,不能在该机器完成发布。 |
|
|
|
+
|
|
|
+#### 必须在实际应用宿主执行的发布步骤
|
|
|
+
|
|
|
+1. 拉取包含 `c61d1006` 的 `future-server` 源码,并确认 `api/api-ncloud/fmode/routes.js` 与 `api/api-ncloud/fmode/sync-fmode-api.js` 均为该版本。
|
|
|
+2. 若该宿主以 Bytecode 入口运行,在**与线上 Node 版本相同的环境**重新生成 `server.jsc`,然后重载 PM2 的 `nova-server` 进程;如果直接以 `server.js` 运行,只需完成源码更新后 reload。不要在代理机或独立 `fmode-server` 进程替代此步骤。
|
|
|
+3. 发布 `fmode-wxpay-api/dist/0.0.5/` 并重载其实际宿主,保留商户配置注入。这是微信回调验签门禁,与第 2 步的 `/api/fmode` 路由发布相互独立。
|
|
|
+4. 先重跑本节的未核验探针,预期为 `409` 且命中“支付订单尚未核验完成”;随后使用**原支付账户**复用已经支付的 ¥0.01 订单,验证第一次 `source=verified-payment`、第二次 `idempotent=true`、余额仅增加一次,并在 Balance 页面刷新与 checkpoint `fetchCalls=0` 后将 P0 标记为完成。
|