11API 文档中心

Appearance

站长运营手册 ​

这页不是给终端用户看的，是给 11API 站长自己用的。

目标只有 3 个：

  1. 快速看清当前有哪些渠道
  2. 一键把上游模型同步到 New API
  3. 用模板批量写定价，而不是手工在后台一个个配

1. 运营脚本位置 ​

服务器项目目录：

text
/opt/11api/deploy/scripts/new_api_ops.py

默认会读取：

text
/opt/11api/deploy/.env

并使用首发时生成的管理员账号与 access token 自动登录后台。

2. 先看当前渠道 ​

bash
cd /opt/11api/deploy
python3 scripts/new_api_ops.py list-channels

输出里重点看：

  1. id
  2. name
  3. group
  4. base_url
  5. model_count
  6. test_model

如果只想看某个渠道：

bash
python3 scripts/new_api_ops.py show-channel --channel-id 1

3. 同步上游模型 ​

同步单个渠道 ​

bash
python3 scripts/new_api_ops.py sync-channel-models --channel-id 1

先预览再真正写入 ​

bash
python3 scripts/new_api_ops.py sync-channel-models --channel-id 1 --dry-run

同步全部渠道 ​

bash
python3 scripts/new_api_ops.py sync-channel-models --all

脚本会自动：

  1. 调用后台读取该渠道真实上游模型列表
  2. 回写到渠道的 models
  3. 自动选择可用的 test_model
  4. 最后重建一次能力表

这一步就是你以后“模型上新 / 模型下架 / 上游调整”时最该先做的事。

4. 批量写定价模板 ​

模板目录：

text
deploy/static/ops-templates/

当前内置 5 份：

  1. starter-commercial.pricing-template.json
  2. codex-openai.pricing-template.json
  3. upstream-onboarding.example.json
  4. client-acceptance.example.json
  5. upstream-authorizations.example.json

先预览模板会改什么 ​

bash
python3 scripts/new_api_ops.py apply-pricing-template \
  --template static/ops-templates/starter-commercial.pricing-template.json \
  --dry-run

真正写入 ​

bash
python3 scripts/new_api_ops.py apply-pricing-template \
  --template static/ops-templates/starter-commercial.pricing-template.json

给 Codex / OpenAI 线补起步定价 ​

bash
python3 scripts/new_api_ops.py apply-pricing-template \
  --template static/ops-templates/codex-openai.pricing-template.json

5. 从上游元数据自动生成模板 ​

如果你的上游 /models 接口除了模型名，还会返回：

  1. input_token_price
  2. output_token_price
  3. cache_read_token_price
  4. cache_write_token_price

那么就可以直接生成模板。

这类上游的典型例子就是 IO Intelligence。

示例：

bash
python3 scripts/new_api_ops.py build-openai-metadata-template \
  --base-url https://api.intelligence.io.solutions/api/v1 \
  --api-key 你的上游key \
  --output runtime/io-intelligence.pricing-template.json

生成后，再执行：

bash
python3 scripts/new_api_ops.py apply-pricing-template \
  --template runtime/io-intelligence.pricing-template.json

6. 最快可运营的上线顺序 ​

不要一开始就追求“全模型、全上游、全套餐”。

建议按下面顺序来：

  1. 先接 2 到 3 家主上游
  2. 每条销售线只放 5 到 10 个主卖模型
  3. 跑一次 sync-channel-models
  4. 跑一次 apply-pricing-template
  5. 再去前台检查模型广场、测试令牌和下游接入

7. 建议的销售线 ​

稳定主线 ​

适合放：

  1. gpt-5.x
  2. gpt-5.x-codex
  3. claude
  4. gemini

特点：

  1. 价格高一点
  2. 讲稳定性
  3. 留更大售后和风控空间

低价线 ​

适合放：

  1. deepseek
  2. glm
  3. qwen
  4. kimi

特点：

  1. 用来走量
  2. 适合工作流、脚本和普通文本任务

图像 / 视频线 ​

单独成线，不和文本混卖。

8. 每天最少要做的 4 件事 ​

  1. 看渠道是否掉模型或上游变更
  2. 看价格是否需要调整
  3. 看支付、工单、公告是否需要同步
  4. 看试营业申请是否需要审批或拒绝

对应命令：

bash
python3 scripts/new_api_ops.py list-channels
python3 scripts/new_api_ops.py sync-channel-models --all --dry-run
python3 scripts/new_api_ops.py apply-pricing-template --template static/ops-templates/starter-commercial.pricing-template.json --dry-run

工单入口也要每天快速看一眼：

bash
curl -fsS "https://pay.11api.top/api/admin/support-tickets?limit=20" \
  -H "X-Pay-Admin-Token: $PAY_ADMIN_TOKEN" | python3 -m json.tool

申请入口也要每天处理。公开获客内容优先放 /apply?source=...，不要直接公开长期通用邀请码：

bash
curl -fsS "https://pay.11api.top/api/admin/leads?limit=100" \
  -H "X-Pay-Admin-Token: $PAY_ADMIN_TOKEN" | python3 -m json.tool

合格申请在后台 /admin 点击“批准发码”，系统会创建数据库邀请码并写回申请记录。不合格申请直接拒绝，尤其是共享号、代登、批量注册、绕限速和爬虫滥用需求。

客户拿到 Token 后，优先发配置生成器，而不是手工一条条写客户端字段：

text
https://pay.11api.top/configure

这个页面只在浏览器本地生成 Codex、Claude Code、Cursor、Cherry Studio 和 OpenWebUI 配置，不上传、不保存用户 Token。

manual 收款模式下，客户创建订单后会看到可复制付款信息。每天开张前先确认它还能正常生成：

bash
./scripts/smoke-manual-checkout.sh

订单 fulfilled 后，后台 /admin 的订单行可以点击“复制交付消息”。授权额度消息会带 New API 原生兑换码；BYOK 和 Seat Setup 消息只给人工配置边界和客户端配置页，避免误发本地假码或共享号话术。

上线后验证一次：

bash
./scripts/smoke-delivery-message.sh

BYOK 和 Seat Setup 到账后会自动进入后台 /admin 的“人工交付”队列。每天至少看一次：

bash
curl -fsS "https://pay.11api.top/api/admin/manual-fulfillments?limit=100" \
  -H "X-Pay-Admin-Token: $PAY_ADMIN_TOKEN" | python3 -m json.tool

处理规则：

  1. pending 先指派交付人并标记 in_progress
  2. 等客户补充官方 key、邮箱或付款方式时标记 waiting_user
  3. 完成前必须勾完检查清单，尤其是客户自有 key/账号确认、预算限制、客户端 smoke 和交付消息发送
  4. 超过 due_at 的任务暂停新增同类订单投放，先处理存量

验证人工交付任务：

bash
./scripts/smoke-manual-fulfillment.sh

试营业 KPI 不要手工拼表，直接看接口或后台 /admin 顶部指标：

bash
curl -fsS "https://pay.11api.top/api/admin/launch-metrics" \
  -H "X-Pay-Admin-Token: $PAY_ADMIN_TOKEN" | python3 -m json.tool

重点看：

  1. revenue.thirtyDaysCny
  2. unitEconomics.grossMargin30dCny
  3. unitEconomics.grossMarginRatio30d
  4. unitEconomics.targetReached
  5. unitEconomics.missingCostOrders30d
  6. customers.paidUsers30d
  7. leads.thirtyDays
  8. leads.open
  9. leads.approved30d
  10. manualFulfillments.open
  11. manualFulfillments.overdue
  12. manualFulfillments.waitingUser
  13. risk.floatingCreditAmountCny
  14. risk.syncFailedOrders
  15. risk.openRefundTickets
  16. goCompanyRequired
  17. attentionRequired

每天开张前跑一次机器门禁：

bash
./scripts/check-trial-operations-gate.sh

它会读取 /api/admin/trial-operations-gate 并输出 GO/WARN/STOP。STOP 时不要继续接新付费订单；WARN 时可以保留小范围 BYOK / Seat Setup，但要先处理提示项；Authorized Credits 必须等 canSellAuthorizedCredits=true 才能公开售卖。

每天开张前建议同时生成一份可转发的运营日报：

bash
./scripts/daily-ops-report.sh

输出目录默认在 deploy/runtime/daily-ops/<UTC时间>/，其中 daily-ops-report.md 会直接写出：

  1. 是否继续接新单
  2. BYOK Developer、Seat Setup、Authorized Credits 是否可售
  3. 今日、7 天和 30 天收入
  4. 30 天毛利、毛利率和缺成本订单
  5. 待审核申请、人工交付逾期、退款/滥用工单
  6. 授权额度在途余额和上限
  7. 邀请码来源表现
  8. 投放动作是继续、复核还是暂停

如果当天已经有私测码，建议直接跑聚合版首批私测运营日报：

bash
./scripts/first-user-ops-report.sh --invite-code PRIVATE_PILOT_<日期>

它会只读调用 daily-ops-report.sh、private-pilot-monitor.sh 和 siliconflow-rollout-status.sh，最后生成：

text
deploy/runtime/first-user-ops/<UTC时间>/first-user-ops-report.md
deploy/runtime/first-user-ops/<UTC时间>/first-user-ops-report.json

这份报告把三个决策分开：

  1. privatePilot：是否还能继续发 1-3 人手工白名单私测
  2. firstUsers：是否能进入首批邀请制试营业
  3. authorizedCredits：授权额度是否仍关闭

只要 firstUsers=BLOCKED，就不要公开发通用首批码；只要 authorizedCredits=CLOSED，就不能公开卖额度。privatePilot=GO 只代表 BYOK / Seat Setup 的小范围手工私测仍可控，不代表 Cherry Studio Embeddings 或 Authorized Credits 已经放行。

如果申请页已经有用户提交，接着跑申请筛选报告：

bash
./scripts/private-pilot-lead-triage.sh

输出目录默认在：

text
deploy/runtime/private-pilot-lead-triage/<UTC时间>/

这份报告会把 30 天申请分成三队：

  1. readyToContact：可私聊确认，但仍只能发手工白名单私测码
  2. manualReview：需要人工确认用途、客户端、预算、是否 BYOK
  3. rejectOrClarify：疑似共享号/代登/绕限速/爬虫/高风险支付等，不得发码

只要有 rejectOrClarify，先处理这些高风险申请；不要为了凑首批用户批量发码。申请产品不是 BYOK Developer / Seat Setup 的，必须转成允许范围或暂缓。

每天对外发内容前，基于最新日报和申请筛选生成私测获客包：

bash
./scripts/private-pilot-acquisition-kit.sh

如果想先刷新全部依赖报告，再生成获客包：

bash
./scripts/private-pilot-acquisition-kit.sh \
  --refresh \
  --invite-code PRIVATE_PILOT_<日期> \
  --fail-on-unsafe

输出目录默认在：

text
deploy/runtime/private-pilot-acquisition-kit/<UTC时间>/

获客包会生成 .md、.json 和 .csv，里面包含 B站、小红书、微信群和私聊文案、筛选问题、合格/拒绝回复、禁用话术和每日跟进清单。它会根据 firstUsers、authorizedCredits、SiliconFlow 和申请筛选状态自动收紧口径：

  1. firstUsers=BLOCKED 时，只能引导填写手工白名单私测申请，不能公开发通用邀请码。
  2. authorizedCredits=CLOSED 时，公开文案不得出现“充值额度、兑换码库存、秒发额度”等承诺。
  3. SiliconFlow 不是 READY 时，不得宣传已经接通放量。
  4. Cherry Studio embeddings 未验收时，不得宣传全客户端或 embeddings 已跑通。
  5. rejectOrClarify 大于 0 时，先处理高风险申请，不要继续放大投放。

这份获客包可以给运营直接使用，但每次发布前仍要人工检查一次标题、简介、置顶评论和私聊话术，确认没有承诺共享号、代登号、未授权额度、无限额度、USDT/免签/跑分、绕风控或绕限速。

每天收款后，额外生成账单/上游成本对账报告：

bash
./scripts/sanitize-upstream-costs.sh --in /path/to/raw-upstream-costs.csv

./scripts/billing-reconciliation-report.sh \
  --source-dir runtime/daily-ops/<UTC时间> \
  --upstream-costs runtime/upstream-costs.csv

runtime/upstream-costs.csv 必须由导入器生成，只保留 order_no,cost_cny，或 order_no,cost_usd,fx_rate。不要保存 API key、Token、Authorization header、客户 prompt、body、response 或上游账号密钥。RECONCILED 才代表本地直接成本和上游账单在 1% 内；REVIEW_RECONCILIATION 需要人工复核；STOP_RECONCILIATION 时暂停新订单。

公司化/公开放量准备度单独看这份报告：

bash
./scripts/company-readiness-report.sh --source-dir runtime/daily-ops/<UTC时间>

它不阻断个人邀请制试水，但会检查：

  1. 公司主体名称、统一社会信用代码和注册地址
  2. 客服电话、客服时间、隐私负责人和响应时限
  3. ICP 备案、公安备案或不适用结论
  4. 正规商户、税务登记和发票流程
  5. 生成式 AI 服务备案/安全评估/不适用结论
  6. 内容安全、投诉入口和公开协议页面是否去掉占位提示

如果报告显示 PREPARE_COMPANY，开始准备公司化材料；如果显示 COMPANY_REQUIRED_NOT_READY，说明已触发阈值但材料未就绪，应暂停新增付费用户。

Go-Live 行动包生成后，再生成首批试营业作战包：

bash
./scripts/build-trial-ops-pack.py

trial-ops-pack.md 是每天运营的一页执行单：它会写明当天能不能邀请首批用户、能不能启动手工私测、BYOK / Seat Setup / Authorized Credits 哪些可卖、哪些宣传话术禁用、以及优先处理的 blocker/warning。只要它显示 PRE_LAUNCH 或“可以邀请首批用户：否”，当天不要接新用户。

如果阶段显示 PRIVATE_CLAUDE_CHAT_PILOT，它只表示已有生产 Claude Code / Claude-compatible messages 或 OpenAI-compatible chat 的脱敏用量证据，可以做 1-3 个手工白名单私测。这个状态仍然不是公开试营业，不能发通用邀请码，不能公开收款，不能卖 Authorized Credits，也不能宣传 Cursor Responses、Cherry Studio Embeddings 或全客户端证明已经跑通。

私测邀请码必须走单独脚本，不要用首批公开渠道脚本：

bash
./scripts/issue-private-pilot-invites.sh

默认只是 dry-run，会读取最新 trial-ops-pack.json，确认当前阶段是 PRIVATE_CLAUDE_CHAT_PILOT、canStartPrivatePilot=true、canInviteFirstUsers=false，并确认 Authorized Credits 仍关闭。确认无误后再发 1-3 个手工白名单私测码：

bash
./scripts/issue-private-pilot-invites.sh --live --max-uses 3 --expires-days 7

脚本会写出：

text
deploy/runtime/private-pilot-invites-<日期>.json

然后立刻生成私测交付包：

bash
python3 scripts/build-private-pilot-kit.py \
  runtime/private-pilot-invites-<日期>.json \
  --fail-on-dry-run

交付包会生成同名 .md 和 .csv，里面包含筛选问题、私聊话术、跟进表、交付检查清单、允许产品、允许范围和不准承诺的内容。只能发给手工确认的开发者，不能公开视频置顶、不能群发、不能用于 Authorized Credits。私测客户下单前必须明确：当前只验证 Claude Code / Claude-compatible messages 和 OpenAI-compatible chat，Cherry Studio Embeddings 还没作为公开首批验收通过。

私测开始后每天跑一次单码监控：

bash
./scripts/private-pilot-monitor.sh --invite-code PRIVATE_PILOT_<日期>

输出目录默认在：

text
deploy/runtime/private-pilot-monitor/<UTC时间>/

报告会检查：

  1. 私测码是否仍 active、未过期、maxUses <= 3
  2. 是否出现非 BYOK / Seat Setup 订单
  3. 是否误接 Authorized Credits / 兑换码订单
  4. 付费订单是否生成了人工交付任务
  5. 人工交付是否逾期
  6. 剩余名额是否用完

只有报告显示 GO 才继续发给白名单用户；WARN 先处理逾期或复盘事项；STOP 立刻暂停私测码继续使用。

SiliconFlow Embeddings 收口 ​

Cherry Studio 需要同时跑通 OpenAI-compatible chat 和 /v1/embeddings。当前推荐先用 SiliconFlow 的 BAAI/bge-m3 补 embedding-only channel，不把 OpenAI / Anthropic 未授权额度当成公开转售商品。

服务器上不要把 SiliconFlow key 写进命令历史，也不要贴到聊天记录。拿到 key 后，在服务器执行：

bash
cd /opt/11api/deploy
read -rsp "SiliconFlow API Key: " SF_KEY; echo
printf '%s\n' "$SF_KEY" | ./scripts/complete-siliconflow-embeddings-rollout.sh --install-key-from-stdin
unset SF_KEY

这条命令会自动：

  1. 把 key 写入 runtime/secrets/siliconflow-api-key.txt，权限设为 600
  2. 创建 siliconflow-embeddings-main 渠道，默认模型 BAAI/bge-m3
  3. 更新 EMBEDDINGS_SMOKE_MODEL=BAAI/bge-m3
  4. 重建 smoke Token 的可用模型限制
  5. 重新跑 collect-client-acceptance.sh
  6. 刷新 Go-Live 行动包和 Trial Ops 包

如果只是想预检 channel 创建计划，不写入渠道、.env、Token 或报告：

bash
./scripts/complete-siliconflow-embeddings-rollout.sh --dry-run

配置完成后看脱敏摘要：

bash
python3 - <<'PY'
import json
from pathlib import Path
p=json.loads(Path("runtime/client-acceptance.json").read_text(encoding="utf-8"))
print(json.dumps({
  "passedCount": p["summary"]["passedCount"],
  "readyForFirstUsers": p["summary"]["readyForFirstUsers"],
  "blockers": p["summary"]["blockers"],
  "clients": [{"id": c["id"], "usageVerified": c["usageVerified"], "usageSummary": c["usageSummary"]} for c in p["clients"]]
}, ensure_ascii=False, indent=2))
PY

只有 cursor、claude-code、cherry-studio 都 usageVerified=true，且 Go-Live / Trial Ops 没有其它 blocker，才可以从 PRIVATE_CLAUDE_CHAT_PILOT 进入邀请制首批试营业。Authorized Credits 仍然要等上游授权证据和对账证据，不因为 SiliconFlow embeddings 跑通就自动可卖。

如果决定“首批就先用 SiliconFlow”，不要只建 embedding channel，而是跑完整 SiliconFlow 网关收口：

bash
cd /opt/11api/deploy
read -rsp "SiliconFlow API Key: " SF_KEY; echo
printf '%s\n' "$SF_KEY" | ./scripts/complete-siliconflow-rollout.sh --install-key-from-stdin
unset SF_KEY

这条完整路径会自动：

  1. 安装 server-local SiliconFlow key，权限设为 600
  2. 创建或复用 siliconflow-main
  3. 创建或复用 siliconflow-embeddings-main
  4. 将 smoke 模型切到 SiliconFlow：chat/responses/Claude-compatible 默认 deepseek-ai/DeepSeek-V3，embeddings 默认 BAAI/bge-m3
  5. 重建 smoke-only New API Token 模型白名单
  6. 跑真实客户端验收并刷新 Go-Live / Trial Ops 报告

如需预检但不写渠道、.env、Token 或报告：

bash
./scripts/complete-siliconflow-rollout.sh --dry-run

也可以先跑只读状态巡检，确认当前卡点：

bash
./scripts/siliconflow-rollout-status.sh

它会生成：

text
runtime/siliconflow-rollout-status/<UTC时间>/

报告会检查：

  1. SiliconFlow key 文件是否存在、权限是否为 600
  2. siliconflow-main 和 siliconflow-embeddings-main 是否已创建
  3. smoke 模型是否已切到 SiliconFlow
  4. Cherry Studio embeddings 是否已有非零用量证据
  5. Go-Live / Trial Ops 是否允许首批邀请

如果巡检显示 BLOCKED，不要邀请首批用户；先处理第一条 next。如果显示 READY，仍只代表客户端验收和 SiliconFlow 技术接入通过，不代表 Authorized Credits 可以售卖。

如果 SiliconFlow 后台没有开通默认聊天模型，可在执行前覆盖：

bash
SILICONFLOW_CHAT_MODEL=你确认可用的模型 \
SILICONFLOW_RESPONSES_MODEL=你确认可用的模型 \
SILICONFLOW_CLAUDE_MODEL=你确认可用的模型 \
./scripts/complete-siliconflow-rollout.sh

注意：这只代表技术上接入 SiliconFlow 官方 API；Authorized Credits 仍然必须等 runtime/upstream-authorizations.json 有真实、未过期、已批准的授权证据，以及账单对账证据就绪后再开放。

每天收款后导出两张对账表：

bash
curl -fsS "https://pay.11api.top/api/admin/exports/orders.csv?days=30" \
  -H "X-Pay-Admin-Token: $PAY_ADMIN_TOKEN" > orders-30d.csv

curl -fsS "https://pay.11api.top/api/admin/exports/invites.csv?days=30" \
  -H "X-Pay-Admin-Token: $PAY_ADMIN_TOKEN" > invites-30d.csv

curl -fsS "https://pay.11api.top/api/admin/exports/leads.csv?days=30" \
  -H "X-Pay-Admin-Token: $PAY_ADMIN_TOKEN" > leads-30d.csv

curl -fsS "https://pay.11api.top/api/admin/exports/manual-fulfillments.csv?days=30" \
  -H "X-Pay-Admin-Token: $PAY_ADMIN_TOKEN" > manual-fulfillments-30d.csv

orders-30d.csv 用来核对收款、退款、兑换码和履约状态；invites-30d.csv 用来看每个内容/社群来源是否真的带来付费；leads-30d.csv 用来看申请来源、审批质量和发码结果；manual-fulfillments-30d.csv 用来看 BYOK / Seat Setup 交付是否逾期、谁负责、清单是否完整。

首批用户不要共用一个长期邀请码。先用批量脚本给每个来源单独发码：

bash
./scripts/issue-first-batch-invites.sh --dry-run
./scripts/issue-first-batch-invites.sh

默认会生成：

  1. BILI_DEV_<日期>：B站第一批开发者
  2. XHS_API_<日期>：小红书 API 教程
  3. WECHAT_DEV_<日期>：微信群开发者

脚本会把申请链接、配置页和私聊话术写到：

text
deploy/runtime/first-batch-invites-<日期>.json

自定义渠道：

bash
./scripts/issue-first-batch-invites.sh \
  --channel BILI_CLAUDE:B站 Claude Code 教程:20:BILI_CLAUDE \
  --channel XHS_CURSOR:小红书 Cursor 教程:15:XHS_CURSOR

每天看一次邀请码使用情况：

bash
curl -fsS "https://pay.11api.top/api/admin/invite-codes?limit=100" \
  -H "X-Pay-Admin-Token: $PAY_ADMIN_TOKEN" | python3 -m json.tool

上线或改版后，排障时可以单独跑这些 smoke：

bash
./scripts/smoke-client-config.sh
./scripts/smoke-leads.sh
./scripts/smoke-invite-codes.sh
./scripts/test-issue-first-batch-invites.sh
./scripts/smoke-manual-fulfillment.sh
./scripts/smoke-launch-metrics.sh
./scripts/smoke-trial-operations-gate.sh
./scripts/smoke-admin-exports.sh
./scripts/smoke-support-tickets.sh refund

上线、改价、换上游或投放前，直接跑生产上线总闸门。它会先做生产配置和商业 MVP 预检，再跑完整验收、生成不含密钥的证据包，并打印 Go/No-Go 结论：

bash
./scripts/production-launch-gate.sh

证据包默认保存到：

text
deploy/runtime/evidence/<UTC时间>/

重点检查：

  1. pay-policy.json 仍为邀请制
  2. pay-plans.json 套餐成本毛利口径正确
  3. upstreams.json 不含 API key
  4. launch-metrics.json 毛利率达标、无缺成本订单
  5. trial-operations-gate.json 不能是 STOP
  6. manual-fulfillments.json 无逾期人工交付任务
  7. orders-30d.csv、invites-30d.csv、leads-30d.csv 和 manual-fulfillments-30d.csv 可用于对账、来源复盘、申请审批复盘和交付复盘
  8. client-acceptance.json 至少包含 Cursor、Claude Code、Cherry Studio 3 个真实 smoke 通过记录；Codex 建议作为额外记录保留
  9. upstream-authorizations.json 有 Authorized Credits 的真实上游授权证据
  10. go-no-go-summary.txt 显示 Decision: GO
  11. daily-ops-report.md 显示可继续接新单，且投放动作不是暂停
  12. billing-reconciliation-report.md 不显示 STOP_RECONCILIATION
  13. 若对外宣称“账单与上游成本误差 <1%”，billing-reconciliation-report.json 必须显示 upstreamCosts.provided=true 和 upstreamCosts.withinTolerance=true
  14. company-readiness-report.md 没有在触发公司化阈值后显示 COMPANY_REQUIRED_NOT_READY

如果 Go/No-Go 报告是 NO_GO，不要投放新流量。先处理 go-no-go-report.json 里的 blocker，例如毛利不达标、缺成本订单、人工交付逾期、同步失败、退款/滥用工单、客户端验收缺失、上游授权证据缺失或公司主体阈值触发。

9. Authorized Credits 授权证据 ​

公开供应商目录和渠道 key 只能证明“技术上能接入”，不能证明“商业上可以卖额度”。如果保留 Authorized Credits 套餐，必须在服务器上维护：

text
deploy/runtime/upstream-authorizations.json

初始化：

bash
mkdir -p runtime
cp static/ops-templates/upstream-authorizations.example.json runtime/upstream-authorizations.json
vim runtime/upstream-authorizations.json

生产要求：

  1. includedCreditEnabled=true
  2. summary.readyForAuthorizedCredits=true
  3. summary.blockers=[]
  4. 至少一条 status=approved
  5. scope 必须是 included_credit、resale 或 integration_distribution
  6. validUntil 未过期
  7. evidence 只写证据引用，不写合同正文、API key 或客户信息

OpenAI/Anthropic 在未取得书面转售或分发授权前只能登记为 scope=byok_only、status=not_allowed，不能用来支撑 Authorized Credits。若暂时没有任何已批准上游，先关闭授权额度收款，只卖 BYOK Developer 和 Seat Setup。

pay-service 会在运行时读取这份文件。未就绪时，/api/plans 仍会展示 Authorized Credits，但会返回 purchasable=false、salesStatus=authorization_required；POST /api/orders 会返回 423，不会创建订单。生产不要打开 UPSTREAM_AUTHORIZATIONS_ALLOW_LOCAL_TEST_ONLY，那只用于本地 E2E。

10. 你现在最应该怎么用 ​

结合当前 11API 的状态，建议你直接这样推进：

  1. 先用现有 io.net 渠道跑通低价线
  2. 再补一条 OpenAI 官方 Responses API 线给 Codex
  3. 最后补 Claude 稳定线

这样你就能从“站能打开”升级到“真的能卖”。

10. 试营业前验收 ​

服务器首次部署时，不要只看首页能不能打开，直接执行：

bash
cd /opt/11api/deploy
python3 scripts/launch-gap-audit.py .env \
  --json-out runtime/launch-gap-report.json \
  --md-out runtime/launch-gap-report.md \
  --fail-on-blocker

缺口报告没有 blocker 后，再跑总闸门：

bash
cd /opt/11api/deploy
./scripts/production-launch-gate.sh --deploy --ensure-test-token

已经部署过的服务器复验使用：

bash
./scripts/production-launch-gate.sh

只有最后显示 Decision: GO，才可以邀请首批开发者。然后按项目根目录的 GO-LIVE-CHECKLIST.md 记录证据。这个清单覆盖合规边界、测试 Token、支付兑换、申请审批、邀请码、Claude Code、客服工单和首批用户范围。

首批用户的获客与交付用根目录这两份资料：

text
GTM-PLAYBOOK.md
CUSTOMER-DELIVERY-KIT.md

10. 为什么现在模型少 ​

如果前台模型广场只有二十几个模型，不要先怀疑“同步没跑完”。

先看渠道数：

bash
python3 scripts/new_api_ops.py list-channels

如果只有 1 条真实上游渠道，那么模型少的根因就是：

  1. 现在只接了 1 家供应商
  2. sync-channel-models 只能把这一家供应商暴露出来的模型同步进来
  3. 不会自动长出 OpenAI / Claude / Gemini / Grok 这些主力模型

也就是说，模型少通常不是“没接完”，而是“根本还没接更多上游”。

11. 公开供应商目录 ​

仓库里已经内置一份公开供应商目录：

text
deploy/static/provider-catalog/commercial-upstreams.catalog.json

覆盖了 4 类常用商用上游：

  1. core-official
  2. broad-aggregator
  3. value-openai-compatible
  4. cn-official

直接列出来看：

bash
python3 scripts/new_api_ops.py list-provider-catalog

只看某一组：

bash
python3 scripts/new_api_ops.py list-provider-catalog --bundle core-official
python3 scripts/new_api_ops.py list-provider-catalog --bundle china-friendly-starter

建议你理解成这几条销售线：

  1. OpenAI / Anthropic / Gemini / xAI
  2. OpenRouter
  3. Groq / Together / Fireworks / Cerebras
  4. DeepSeek / Qwen / GLM / Kimi / MiniMax / SiliconFlow / 火山方舟

12. 先生成“待填 key”的接入计划 ​

不要先手工进后台建十几次渠道。

先生成一份计划文件，再把真实 key 填进去：

bash
python3 scripts/new_api_ops.py build-provider-plan-template \
  --bundle core-official \
  --bundle broad-aggregator \
  --bundle cn-official \
  --output runtime/commercial-upstreams.plan.json

也可以只生成特定几家：

bash
python3 scripts/new_api_ops.py build-provider-plan-template \
  --provider openai-official \
  --provider anthropic-official \
  --provider openrouter \
  --output runtime/core.plan.json

生成后的每一项都可以填：

  1. enabled
  2. api_key
  3. name
  4. base_url
  5. group
  6. models
  7. test_model

注意：

  1. models 可以先留空
  2. 创建完成后脚本会自动去上游拉真实模型
  3. 所以这套方案比手工预填模型更稳

13. 按计划批量创建渠道 ​

计划文件填好后，直接批量创建：

bash
python3 scripts/new_api_ops.py create-channels-from-plan \
  --plan runtime/commercial-upstreams.plan.json

脚本会自动：

  1. 逐条创建渠道
  2. 自动识别新建的渠道 ID
  3. 自动同步上游模型
  4. 最后重建能力表

如果你只想预览：

bash
python3 scripts/new_api_ops.py create-channels-from-plan \
  --plan runtime/commercial-upstreams.plan.json \
  --dry-run

14. 商用站推荐接入顺序 ​

如果你不是一次性拿到所有 key，建议按这个顺序：

  1. OpenRouter
  2. DeepSeek
  3. SiliconFlow
  4. OpenAI
  5. Anthropic
  6. Gemini
  7. xAI

原因很简单：

  1. 前 3 条更容易先把模型池做厚、把站真正运营起来
  2. 后 4 条才是补齐主力旗舰模型
  3. Codex / GPT 真正要卖起来，最终还是要回到 OpenAI 官方

15. 当前最实用的理解 ​

你可以把现在这套能力理解成两层：

  1. 11API / New API 是你的零售前台和控制台
  2. OpenAI / OpenRouter / DeepSeek / 其他官方供应商 才是你的上游货源

所以后面每新增一家上游，核心动作都只有 3 步：

  1. 拿到真实 API key
  2. 跑 create-channels-from-plan
  3. 检查模型广场、测试令牌和定价

基于 VitePress 构建

Copyright © 2026