昨天我分享了 Opus 5 写的 5 万字项目文档！
主题是做一个：
一个以「场景化应用」为交付形态、以「统一 AI 网关」为技术底座、面向 C 端个人与 B 端组织的多模态 AI 服务平台。
我把这个项目命名为：AI ALL IN ONE（简称：一锅乱炖）！
其实就是让它做一个类似 NewAPI 中转网关 + 场景化应用。针对的用户可以是 B 端企业用户，也可以是有类似需求的个人用户。甚至可以是需要场景化 AI 应用的普通 C 端用户。这是一个非常庞大且复杂的项目。
我的核心目的并不是真的一个人去做这样一个项目。
而是测试 AI 模型自主完成大项目的能力。
我想测一下，不写一行代码，完全由 AI Agent 来实现，不同的 AI 模型能到哪一步。
Opus 5 自己写了 SPEC 文档之后，让它根据文档设置一个 GOAL，然后全自动进行开发。我告诉它"它只有一次机会"，所以它必须在没有人类指导的情况下，长时间工作，根据目标完成这个项目。包括测试也是它自己做。
包括最终的项目汇总介绍也是它自己来写！
它自己测试，自己截图，自己理解图片，自己编写公众号文章！
目前已经完成第一个版本！
下面是它的代码量：
| 文件 | 行数 | |
|---|---|---|
| TypeScript 生产码 | 125 | 29,012 |
| TypeScript 测试码 | 50 | 16,917 |
规格文档 docs/ |
30 | 5,016 |
其他 .md（README / PROGRESS / DECISIONS） |
8 | 2,914 |
| SQL / CSS / HTML / 配置 | 19 | 5,180 |
| 合计（不含截图） | 232 | ≈ 59,000 |
下面是它的数据表，25 张表 · 430 行 DDL：
并且自动截取了 25 个核心功能点的截图！
然后，我让它根据代码、截图以及对系统的理解，写了一篇图文并茂的文章！
它写了一篇 3,000 多字的文章！
我大致看了下，肯定没有我写得好😄，但是能看！
重点是，我完全不了解它这个系统，我要写的话，可能得写好久，它只花了几分钟！
下面我把完整的文章发出来，大家可以看看它开发了哪些功能，以及它的写作能力。
文章的大标题是："我把「全公司用 AI」这件事，做成了一个入口"，看来它是选了 B 端作为核心卖点。
下面是文章的完整内容，我一字未改！
先说说这个东西是给谁做的
如果你所在的团队现在是这样的：
市场同学开了一个会员，研发用另一家的 API，财务的同事自己充了值，实习生借着别人的账号在用。月底，老板问了一个特别正常的问题------「我们这个月在 AI 上花了多少钱？花在哪了？」
然后没有人答得上来。
不是因为大家不认真，是因为这些信息天然就是散的。三个平台的账单在三个后台里，单位不一样、周期不一样、有的按次有的按 token；谁调的、给哪个业务用的，压根没记。等你想查的时候，能查到的只有一个总数。
再往下还有几个更麻烦的：
- 实习生手一抖，把一份客户名单贴进了某个对话框------你不知道，也拦不住。
- 某个模型悄悄涨价了，你是从账单上发现的，那时候钱已经花完了。
- 新来的同事想用 AI 改一版文案，得先申请账号、等审批、学怎么写 prompt。等他学会，事情已经过去了。
这套系统就是冲着这几件事做的。 一句话概括：把所有 AI 能力收到一个入口后面，让每一分钱都有出处，让每一次调用都有人管。
下面我按「一个新用户从看到它，到用起来，到管起来」的顺序，一屏一屏地讲。所有截图都是真跑出来的，不是设计稿。
第一步：不用注册，先看看有什么
我一直觉得，一个工具类产品最劝退的地方，是你还没搞清楚它是干嘛的，它就让你先注册。
所以首页是完全公开的：32 个场景应用全都摆在外面，分好类，标好「低风险 / 中风险 / 高风险」，也标好哪些暂时不可用。你可以点开任意一个看它长什么样。
点进去也不需要登录。你能看到这个应用要你填什么、默认用哪个模型、大概花多少钱、有什么使用限制。只有真正点「运行」的时候才需要账号------因为那一下开始花钱了。
还有一类页面我觉得值得单独说：
这个应用叫「长文档问答」，它现在做不了。页面直接告诉你：文档上传这一项需要把文档切块做向量检索，这个能力还没接。
为什么不干脆把它藏起来？因为藏起来的代价是，某天有人问「你们能不能做文档问答」，没人说得清答案是「不能」还是「能但没做」。写清楚「差什么」比假装不存在有用得多。
第二步：32 个场景，不是一个聊天框
这是登录之后的主界面。
我想强调一下这里的产品判断：大多数人用不好一个空白的聊天框。
所以这里的每一个应用，都是一张填空表：
「周报生成」问你三件事：这周做了什么、下周计划、写给谁看。填完点运行。它知道该怎么组织这些信息，因为组织方式是提前设计好的，不是每个用户自己摸索的。
一共 32 个：全能对话、论文润色、翻译工作台、代码助手、SQL 助手、合同条款审阅、简历优化与面试模拟、邮件助手、客服话术、周报生成、招聘 JD、SEO 长文、商品详情文案、演示提纲、学习计划、训练计划、财报速读......覆盖了办公、写作、编程、电商、营销、教育、研究几大类。
稍微专业一点的说明：这些应用不是 32 份前端代码。每个应用是一份结构化的声明（要哪些输入、用哪个模型、允许换哪些模型、风险等级是什么），前端只有一套渲染逻辑。所以新增一个场景应用不需要发版，改一份配置就行。
同一套运行页，「论文报告润色」的表单就完全不同了------多行文本、风格下拉、"保持篇幅"开关。这些控件都是那份声明里写出来的。
第三步：这一次花了多少钱，当场就告诉你
这是我自己最在意的一块。
看左下角：点运行之前，它先给你一个预估区间------"约 1500 ~ 82140 credits，按输入 55 token、输出约 2048 token 估算"。跑完之后，那里变成"实际扣费 5,000 credits"。
为什么要做成这样？因为绝大多数 AI 产品的计费是事后的 ：你用，你等，月底看账单，看到一个不知道怎么来的数字。而报价必须在花钱之前给出来，这才叫报价，事后给的那个叫账单。
右下角还有一行小字：「本次请求 01M1DF...------ 查看计费明细」。点进去能看到这一次到底怎么算出来的。
第四步：每一笔账都能展开
账单页分三块：
上面是余额。 分成「现金余额」和「赠送额度」两笔，赠额还标了到期时间。中间那个「冻结中」是这样一件事：你点运行的瞬间，系统会先冻住一笔钱（按最坏情况估），跑完按实际用量结算，多冻的退回来。这样做的原因很实在------不这样的话，余额只剩 1 块钱的时候，你还能同时发起十个大请求，等账算出来已经欠了钱。
中间是消费明细。 每一行都能展开，展开后是这次调用的每一个计量项：输入 token 多少、输出多少、缓存读多少、写多少，各按什么单价算的。
这里有个细节我想说一下：缓存的 5 分钟档和 1 小时档，价格是不一样的（1 小时档大约是 5 分钟档的 1.6 倍）。如果把这两个混在一起算，账单会一直有一个说不清的偏差。这种事情不做单独区分的话，是查不出来的。
下面是钱包流水。 每一笔收支、余额变化、关联的请求 ID，全在这。这张表是只追加的------写进去之后谁也改不了，包括管理员，包括我。数据库层面就禁止了 UPDATE 和 DELETE。
第五步：谁能花钱，一个月能花多少
这一页解决的是开头那个问题：钱是团队的，但花钱的是具体的人。
- 五种角色：所有者、管理员、成员、财务、只读。财务能看账不能调用，只读能看结果不能花钱。
- 每人一个月度预算：给实习生设 5 美元，他这个月花超了就调不动了。旁边直接显示「本月已花」，因为不显示已花的话，"这个预算设多少合适"根本没有依据。
- API Key 在下面：给程序用的凭据，可以限制只能用哪几个模型，可以随时吊销。
有两条规则是写死在服务端的，不是靠前端把按钮变灰：
- 最后一个「所有者」不能被降级或移除。否则这个工作区就成了一个谁也管不了的孤儿，只能改数据库救。
- 移除成员立刻生效。不只是标记成"已移除"，同时把他的登录状态全部撤销------不然被移除的人手上那张凭证还能再用一刻钟。
第六步：后台------不只是"能看"，是"能改"
普通用户看不到「后台」这个入口。只有管理员和所有者能进。
模型和供应商，可以直接增删改
接了哪些模型、每个模型多少钱、上下文多长、支不支持图片、要不要下线------全部在这里改，不用改代码、不用重新发版。
我想请你注意这一列：
有几个模型的状态是「停用 · todo_verify」，价格那一栏写着"无"。这不是没做完，是故意的 ：这些模型我没有逐条核实过官方定价，所以系统禁止它们被调用。
页面上那句话是这么写的：「价格未核实的模型一律停用 ------ 凭印象填一个价格意味着每一次调用都在按错误的价格计费。」
一个模型少填一个零，你不会收到任何报错。它会安安静静地按错的价格算下去，直到某天对账对不上。所以这条被做成了启动时的硬性检查：只要有一个模型是"价格没核实"却又是"启用"的，服务直接起不来。
供应商这页还有一栏叫「转售条款是否确认」。有些厂商的条款不允许你把他们的服务转售给第三方。这一栏现在全是"未确认"，意思是：这套系统目前只能自用，不能拿去对外卖。 这是个法务问题，不是技术问题，但它得有个地方记着。
调用统计：不只看用量，看毛利
这一页回答开头那个问题。按天、按模型、按应用三个口径，每个口径都有：调用次数、输入 token、输出 token、收入、成本、毛利。
成本是你付给上游的钱，收入是你按自己的价目表收的钱，差额就是毛利。哪个模型在赚钱、哪个应用在烧钱，一眼能看到。
关于「统计口径」有一句话我写在了页面上：这个系统不存储对话内容。
它记的是：谁、什么时候、用了哪个模型、多少 token、花了多少钱。不记你聊了什么。
这是个明确的取舍。好处是数据量小得多、隐私风险低得多；代价是没法做"大家都在问什么"这类内容维度的分析。我认为对绝大多数公司来说这个换得值------你需要的是账，不是聊天记录。
合规这一组
这张表把每一条接口需要什么权限全列了出来：哪些是公开的、哪些要登录、哪些只有管理员能碰。
它不是一份文档，就是系统实际执行的那份声明。而且有一条硬规则：任何一条接口如果没写清楚鉴权方式，服务直接起不来。 忘了给新接口加权限，是那种上线之后很久才会被发现的漏洞，所以把它变成了一个起不来的进程。
后台的每一次改动都留痕：谁、什么时候、把什么从什么改成了什么。这张表和账本一样，只能追加。
内容审核分三段：请求发出前查一遍、输出的过程中查一遍、落库前再查一遍。
这一页顶上有个很显眼的提示，我原样保留了：当前用的是内置关键词基线，漏判率高，不能用于生产。 接专业审核服务之前，这句话会一直挂在那。写一个假装能用的审核模块，比明说"这块还不行"危险得多。
这是我个人最喜欢的一页。它每次都会重新算一遍：钱包余额、账本流水、计量记录，这三份数据必须互相对得上。 对不上就报出来，报在哪一条、差多少。
它下面还有一行诚实的备注：「R4（上游账单对齐）未执行：账单导入通道尚未实现。R1~R3 全部通过并不能说明计量是对的 ------ R4 才是唯一能发现计量逻辑写错的检查。」
意思是：现在这三项对得上，只能说明我自己算的三份数据内部一致。要证明我算得对，得拿上游厂商的真实账单来比。那个还没做，所以不能吹。
手机上也能用
375 像素宽度（iPhone SE 那个档）下没有横向滚动，表格自己会滚，不会把整个页面撑歪。
老实说，还没做完的部分
我不太喜欢那种"全面覆盖、开箱即用"的介绍，所以下面这段可能是整篇最有用的：
支付渠道没接。 现在的"充值"是一个默认关闭的开发用替身。真接微信/支付宝/Stripe 不难，难的是「渠道订单 ↔ 账本条目」的对账------钱到了账本没记、账本记了钱没到，这两种情况都不会报错。
图片和视频模型没启用。 适配器写好了，但那几个模型的定价我没核实，所以按前面那条规则，它们全是停用状态。
限流还在单机内存里。 部署多个实例的话，每个实例各算各的，真实限额是设定值的 N 倍。得挪到 Redis。
邮件邀请没做。 现在只能邀请已经注册过的账号，页面上写明了。
上游账单对齐（R4）没做。 就是上面对账那一页说的。
这些不是"忘了"，是排期到后面了。写在这里是因为------一个系统里最危险的东西，不是没做的功能，是做了一半却看起来像做完了的功能。
最后
整套东西目前是 1350 多个自动化测试在守着的，其中钱相关的那部分（计价、钱包、账本）分支覆盖率是 100%。倒不是为了好看，是因为算钱这件事没有"差不多"------差一分钱和差一万块，性质是一样的，都是账错了。
这些截图全部来自真实运行的系统：真的注册、真的邀请同事、真的跑了几十次调用、真的走完了预扣→结算→记账的全流程。上游接的是一个本地的模拟服务（所以回复内容是"你好，这是一段测试回复"），但除了模型本身，其他每一环都是真的------包括那几十笔账。
如果你也在被"公司里的 AI 花销说不清楚"这件事困扰，希望这篇能给你一点参考。
文章看完了，整体来说，目前实现的核心功能都展示了，而且图文是匹配的，没有文不对题的情况。
只是信息量有点大，如果不是对这个中转系统很了解的人，可能会有点看不懂。
从最初几百字的核心需求，到几万字的项目文档，再到几万行的代码。你们觉得 Claude Opus 5 的自主规划和实现能力怎么样？
我对比了一下不同模型，Opus 5 算是做得比较多、思考比较细的了。很多模型一旦面对这种大需求，它就不爱细化，可能是注意力不够，导致最后的实现非常粗浅和简陋。
目前 GLM5.3、GPT-5.6 Sol、K3 全部测了，下一篇你们想先看谁的？
它们的项目文档我已经全部上传了！
获取方式可以看这一篇：