这几天用 AI 撸了个 PDF 翻译平台，没写一行代码

先说结论：我花了大概五天时间，从产品定位、UI 草图、后端架构、前端页面、迁移脚本、API 文档到上线部署，全程没自己敲过一行代码（也就 git commit -m "..." 自己点的），整出来一个叫「译档」的 PDF 翻译平台。今天来摸个鱼，顺便聊聊我是怎么被 AI 按在地上摩擦的。

这玩意儿是干嘛的

一句话：把 PDF 丢进去，把翻译好的 PDF 拿出来。

具体一点 ——

• 📄 上传 PDF，先解析页数和 token ，告诉你”这一份大概要多少积分”
• 🧾 确认下单，冻结积分，跑翻译 worker
• 🪞 保留版式输出（ PyMuPDF + Chromium 渲染，不是那种把段落拍扁重排的）
• 👀 左右对照预览，原文 / 译文并排翻页，专业 PDF 读着踏实
• 💰 按 token 结算，任务失败积分原路退回
• 🔌 对外开放 API，有 OpenAPI 文档 + API Key 管理页，开发者可以直接 curl 调
• 💬 微信扫码支付，找零钱都不用了

适合合同、论文、金融研报、公司介绍、跨境电商说明书这类”我要保留结构 + 复核一遍”的文档。

我没写一行代码，但它真的在跑

打开仓库你们能看到的东西：

api/           # FastAPI 后端（用户、文件、积分、支付、worker 调度）
web/           # Vite + React + TS 前端（工作台、历史、积分、API 管理）
skills/        # PDF 翻译 CLI （核心引擎，被 worker subprocess 调用）
tests/         # 单元测试 + Playwright e2e
docs/          # 设计稿 + 实施计划 + 现在这篇软文

具体数字我也没数，反正 api/ 一个目录就是几十个文件。我做的事情只有三件：

1. 告诉 AI 我要什么。比如「做一个翻译任务的下单流程，上传后预估积分，确认后冻结」。
2. 挑刺。AI 写完我看一眼，改改命名、砍几个多余字段、补两个边界 case 。
3. 按回车。

整个过程最像产品经理 / 架构师，而不是程序员。写代码的是 AI ，我就是个会 ctrl+c / ctrl+v 的产品 😂。

几个我觉得拿得出手的细节

• 冻结-结算-退回：任务确认时把预估积分 hold 起来，跑完按实际 token 结算，多退少不补。失败自动 refund ，不会出现”任务挂了积分没了”的灵异事件。
• 失败状态可追溯：解析失败、翻译失败、PDF 生成失败，分别返回不同错误码，前端不把异常包装成”成功”。
• 动态超时：30 页的 PDF 和 300 页的 PDF 不是一个 timeout ，按 CLI_TIMEOUT_PER_PAGE_SECONDS 加权计算。
• 公开 API + 密钥管理：登录后可以创建 API Key 、查看用量、配额、调用记录。OpenAPI YAML 我也没手写，全是 AI 整理的，文档站都给你生成了。
• 微信支付 v3：Native 扫码下单 + 回调验签 + AES-GCM 解密 + 主动同步，生产环境真能收款，不是 demo 级别。
• 离线模式：PDF_TRANSLATE_PROVIDER=mock 直接跑通全链路，不需要真模型也能演示。

为什么选”零代码”这个角度

因为我本来就是想验证一件事：2026 年了，一个独立开发者从 0 到上线一个完整 SaaS ，到底要花多少人工。

答案是：基本只需要产品决策 + 决策。剩下的，AI 已经能帮我做了。

不夸张。我甚至连 OpenAPI 文档站点、SEO 着陆页、邀请注册流程、找回密码邮件模板，都是让 AI 顺带输出的。

部署/试用

• 主页：https://translate.qkfintech.cn/r/R7A60326B
• 注册送体验积分，无需信用卡
• API 文档站和 Skill 包都在主页上有入口

几个我承认的局限

• 复杂扫描件效果取决于 OCR ，扫描版 PDF 还是建议先 OCR 再传
• 不承诺”逐像素复刻”原文 PDF 的版式，但段落、表格、页码线索尽量保留
• 不接 OCR 、不接支付宝、不接小程序支付——下一版再说

感兴趣可以来摸一摸，也可以直接 API 怼上去。如果你们也在用 AI 写代码，欢迎评论区一起聊点踩过的坑，比如”AI 写出来的迁移脚本把生产数据库 drop 了”之类的真实故事 🐶。