Skip to content

v1.0.10 · 收款可达性：让「付得进去」这条路真的通

Choose a tag to compare

View all tags
@genesis-plan genesis-plan released this 23 Sep 10:38
· 83 commits to master since this release
v1.0.10
9d132dd

本版只修一件事：让「钱真的能付进来」

不改求解核心。修的全是付款方必经路径上的断点 —— 这些地方写着「等邮件确认 / 数日内到账」，会把诚心想支持的人直接劝退。

1. 付款页不再「必须有订单号才出收款码」

付款页脚本原为 if (!valid) return; —— 不带订单号打开 https://hongchenlingjing.com/pay/ 时完全不显示收款码。而首页页脚、README 给出的入口恰恰就是不带订单号的那个地址，于是唯一的真人付款入口是死路。

该限制的设计初衷是「降低收款码被滥用风险」。但实测 /pay/qr.png 无 Referer 也返回 200 ⇒ 攻击者照样能直接取码：防护对攻击者无效，只挡住了真心想付钱的人。现改为任何情况下都出示收款码；未带订单号时如实提示「无法自动对应成调用额度」，并引导想自动开通额度的人先建单。

2. 收款说明去除「等人工」旧口径（最关键）

建单响应里仍在告诉付款方：

付款务必备注订单号，并邮件 553420544@qq.com 告知以便确认到账。
作者拿对公流水跑 reconcile-bank.js，通常数日内到账。

这是上一版已废除的人工流程残留在付款方必经路径上。现统一为：付款 → 调 pay 传 selfReportPaid:true → 立即入账、立即放行，无需等任何人、无需发邮件。

3. AI Agent 拿不到付款链接

payIntent 原先只有 payToQr（该字段恒为 null），而 agentSteps 第一步却是「向钱包持有者展示 payToQr」⇒ Agent 照步骤执行时拿不到任何可展示的付款入口。现 payIntent 直接带 payUrl，首步即指向它。

4. 仓库简介补上收款入口

GitHub description 原先完全不提托管端点与支持入口 —— 而搜索结果、仓库卡片、分享卡片上显示的就是它，想付费的人从搜索进来看不到任何付款路径。现补入托管端点与 honorPaid 免费放行说明（许可口径不变：非商业免费 / 商业须书面授权）。

配套修正

  • payUrlNotice「备注必须填写订单号」→「建议填写」（与付款页「入账不依赖备注」口径一致）
  • 「无法对应到订单的来款一律原路退回」→ 改为可执行表述（该承诺无法自动执行，与零人工定位冲突）
  • manifest.json 去掉「支持导数/积分/ODE/极限」的能力虚标
  • registry-server.json 版本 1.0.8 → 1.0.10（此前落后两个版本）
  • .gitignore 白名单补入 mcpize.yaml / server.json / registry-server.json —— 此前被漏掉，导致 MCPize 从 GitHub 拉不到部署配置、官方 MCP Registry 读不到 server.json

回归

test/metering_regression.js 149 项全绿（新增 2 条回归锁：付款路径不得再出现「发邮件确认到账 / 数日内到账 / 备注务必填写」；payIntent 必须带 payUrl 且首步指向它）；predeploy_gate.js 40 项、our_method.js 44 项、p0_fix_regression.js 18 项、verify_compliance.js 18 项全绿；公网端到端 29/29。

支持这个工具（可选，完全自愿）

  • 付款页：https://hongchenlingjing.com/pay/（工银e支付聚合码，微信 / 支付宝 / 银联均可扫；付款后自助入账立即生效）
  • 对公转账：广州市红尘灵境数字科技有限公司 · 中国工商银行广州市绿色金融改革创新试验区花都分行 · 3602026809201658423
  • 托管端点：https://hongchenlingjing.com/mcp（¥0.01/次）

不想付费也照常用：调用时传 honorPaid: true，或直接用网页版 / 本地版 npx -y lingshu-solver（永久免费、不限次数、离线）。1 分/次是定价信号，不是硬门槛。

📌 npm 发布说明：本版已发布到 npm —— lingshu-solver@1.0.10，
shasum b2bff9af15a3ee75fb99557711bb1398d3ad6a2a，包内 5 个文件与仓库逐一致。

一个值得记住的坑：registry 大约 30 分钟后才对外可见。期间所有中间信号都长得像失败 ——
单版本端点返回 404、dist-tags.latest 仍是旧版、tarball 404，
重复 npm publish 还会报 409 Cannot publish over previously staged version / cannot publish over the previously published versions，
npm stage list 也是空的。这些都是"发布正在管线中处理"的中间态，不是失败。
正确做法：等足够久后复查单版本端点，以 shasum 与发布票根一致为准 —— 不要中途改号。

另：npm 正在限制「绕过 2FA 的 token 直接发布（direct publishing）」，
长期可改用 Trusted Publishing（GitHub Actions + OIDC） 来免除这类不确定性。

Assets 2
Loading