申请工作样本 · Celeste Deng

Hi Jason,

看到你发帖找技术合伙做 token 出海后，我理解是：Sub2API 现在是个强技术项目，需要有人把它整理成海外用户看得懂、用得起来的东西。 所以我没继续做虚的营销 demo，直接把第一周我会真正负责的事拆出来了。

我快速调研后的判断

  • Sub2API 是个账号池 + API key + 计费 + 调度 + 后台运维 + 合规压力叠在一起的 gateway，跟普通 proxy 不一样。
  • 早期最重要的事：开发者信任。部署路径、OpenAI-compatible contract、粘性会话、请求归因、透明 usage——这些比页面好看重要得多。
  • 社区帖当需求信号看，但产品计划和运维决策的真相源在官方文档、release 和 GitHub issue。
  • 所以第一周不是一个网站上线周，是一个验证冲刺——边跑部署边读 issue 边写 runbook，搞清楚边界再承诺。
Day 1

先验证项目真相源和定位边界

不急着写页面。第一天搞清楚几件事：Sub2API 现在能做什么、不能过度承诺什么。第一批海外用户大概是谁。哪些场景可以安全公开说，哪些不能说。

参考资料

Day 2

跑一遍受控自托管部署，写 runbook

先把最朴素的路径跑通。依赖、PostgreSQL、Redis、Docker、反代、密钥、健康检查——跑通之后再写部署 checklist。公开文案等部署摸清楚了再决定怎么写。

参考资料

Day 3

按真实兼容性需求写开发者文档

不用想象。翻一下社区里别人怎么接 Sub2API 的——x-video-translator 怎么集成的、模型列表有什么缺口、哪个 endpoint 有坑——拿这些信号来写 docs，少凭空设计。

参考资料

Day 4

梳理用量、计费、支付和账号生命周期风险

计费不能只当 UI。我先搞清运营模型：credits 怎么算、充值走什么、单次请求扣多少、上游账号是谁的、refresh token 锁在哪、sticky session 怎么处理。这些都是会出生产事故的地方。

参考资料

Day 5

Dashboard 先围绕运维，而不是装饰

搭后台骨架的话，不应该从 UI 开始想。从真实运维痛点和 GitHub issue 倒推：真实 client IP、env 漂移、DB 健康、多实例限制、API key 和 usage 一眼能看到。

参考资料

Day 6

这时再写公开站和 SEO-safe 解释

技术和风险边界摸清楚了，公开页面才知道该碰什么、不该碰什么。自托管、私用、管理员合规确认、上游 ToS 风险——这些说清楚。但不要写成「放心用，完全合法」那种过度承诺。

参考资料

Day 7

用社区信号启动反馈循环

社区帖当需求信号看，不当技术真理。我看下来有用的模式是自托管、多账号、外部访问、工具集成和多服务共存——这些对应真实运维场景，不是虚的。

参考资料

我还写了一份 API contract 样本——展示我对 endpoint 设计、billing 字段、error model 和开发者接入体验的理解。

看 API contract →

补充参考信号

下面这些没进某一天的具体计划，但帮我理解了周边生态和潜在坑位。

七月上旬可全职到岗 · 微信直接聊，或者约 20 分钟我展开讲。

English  ·  ← 返回简历