1.3 账号、权限与预算：动手前的准备清单

方案定了，我趁着劲头拉了一张准备清单。前一份工作我吃过亏：项目做到一半发现某个服务没开权限，临时找管理员审批，一等就是两天，进度直接卡死。这次我先把账号、权限、预算三件事一次性理清，跟 CEO 照过之后直接开干，后面四周动工的时候果然一次都没因为权限卡过壳。

账号开通的顺序

开账号也有讲究，顺序错了会绕路。我是按依赖关系开的：先开通智能体平台（编排核心，最优先验证可行性），再开对象存储 COS（知识库原文要先进去），然后是 API 网关（联调的时候才用上，但提前开好不耽误事），CVM 和云函数是现有服务的延续，本来就有，只补了子账号权限。CVM 上还跑着订单和用户接口，AI 助手要查的订单数据就在它上面，所以服务器这一环基本是现成的，省了一大笔事。

之所以先开平台而不是先囤服务器，是因为整个项目的关键路径在平台侧——平台的智能体能不能跑通我们的客服场景，是这件事成不成的前提；服务器和接口是基本盘，早就验证过。把最不确定的事情最先做掉，这是这些年被项目排期毒打出来的经验：脏活累活先干完，后面的路越走越快。

顺带说明，为什么先不急着碰官网代码：官网聊天窗的集成在第四篇，那一步要等智能体发布成 API 之后才有意义。前面所有准备工作都是为了让后面的节奏不被打断——开账号、批预算这些杂事堆在一起做，最伤效率。

账号与权限准备清单

公司主账号在 CEO 手里，我作为技术负责人拿了一个子账号，再给开发和客服组长各开了子账号。五个产品，各管各的事：

清单里产品的名字按我们实际用的写，权限只给最小集合。比如客服组长的账号只读对话记录，不能碰编排；开发的账号不能动线上网关的限流配置；我的账号能管全流程但不持有主账号。这三条对应的是三种风险：数据外泄、线上被误改、单点依赖。

智能体平台、COS 这些产品的开通入口在控制台里都很好找，按提示点下来就行，需要确认费用的地方先选按量计费，跑一周看账单再决定要不要换包月。给每个子账号开通的时候顺手把用途备注写上，三个月后你会感谢自己。

预算预估

老板最关心的问题：要花多少钱。我按 MVP 阶段的量级估了一张表，不算精确，但足够拍板。跟老板谈预算有个技巧：别只给一个总数，给他对照——同样的钱够再雇半个客服，还招不到、留不住；AI 助手是每月固定的小钱，换的是六成重复工单的人力。CEO 听完对照，两分钟就批了。

表里有两个数要重点解释一下。每次对话平均 1500 token 左右，这个数怎么来的：问题加检索到的三四个知识片段拼起来作输入，约 1000 token，回答输出 400 到 500 token。知识库切片越规范，这个数越稳。模型 token 的计价每个模型不同，一般输入和输出分开计价，输出更贵。所以估预算的核心动作是：先测出单次对话的平均 token 量，再乘以预估日活对话数，乘上单价就是日成本。另外每天 500 次这个量级，是按官网日均访客的一小部分灰度估算的，灰度裂变之后会重估一遍。

全部加起来，MVP 阶段的月成本比客服组一个人一天的工资高不了多少，这个账怎么算都划算。真要细算，得等上线有真实数据后复盘，第五篇会专门做这件事。

提醒一句：这里的量级是基于我们官网日均访客和工单量推的，每个公司差异很大，别照抄数字，照抄方法。估的时候拿你自己的日均问答量乘上平均 token 数，先有个数量级再细化。这表里没列云函数，因为它在这种量级下基本不花钱，函数每月免费额度对 MVP 阶段的回调通知绰绰有余。

预算估出来之后我做的第一件事不是批，是设线：给每项费用定一个心里阈值，超过就有预警。因为按量计费的东西最怕的就是悄悄涨，等你看到月账单已经晚了。这个习惯最早是管服务器时候养成的，那台 CVM 前年被爬虫刷过一次流量，账单翻了好几倍才发现。预算估得再细，不设预警线，照样会在不经意间超。

费用这件事对比着看最有感觉：ADP 智能体开发平台新客的优惠价目在控制台能看到，我先开了账号领了新客福利再估算，首月成本比表里估的还低一截。服务器和底座的开销参考腾讯云五件套实战里的配比思路，不重复估。

我还顺手做了个监控：在云监控里给几个关键费用项设了阈值提醒，超过预算线立刻有通知。上线之后这个告警救过我两次——有一次提示词没调好，单次对话把知识库上下文拼得太满，token 用量直线上涨，告警比账单早到了三天。云监控的配置入口在控制台里，按计费维度设阈值就行，不用写代码。上线之后真正值得盯的两个数：单次对话平均 token 和每日调用量，前者衡量提示词和切片有没有失控，后者衡量流量是不是在预期内。

顺带说一句监控的副产品：告警邮件我拉了 CEO 进收件人名单。不是邀功，是让他对这件事的运行状态有体感，后面要扩预算的时候不用从零解释。这也是一种向上管理的小技巧。

权限最小化原则

子账号的权限我卡得很死，原因有三：第一，知识库里会有客户问答记录，全文检索放开之后不希望被随意下载；第二，网关的密钥和限流配置动了就是线上事故，让开发误改限流等于把官网入口攥在别人手里；第三，智能体发布权限如果人人都有，调试中的半成品可能被直接挂到官网。

按角色给权限、按资源给读写，出问题能追到人，新人想试新功能就自己开测试环境而不是改线上的。这套做法跟我们部署后端的习惯一致，服务器常见问题里也聊过线上权限的排查思路。主账号我碰都不碰，所有操作走子账号，这既是安全习惯，也强制自己把权限边界想清楚。

再补一个真实教训：开通 COS 的时候图省事给过一次全桶读写权限，第二天开发同事为了测试顺手把一个测试桶清空了——里面是他自己一周攒的测试文件，但那一刻我后背发凉：如果连错桶，知识库原文就没了。从那之后所有桶都按业务前缀限定，访问密钥不落到代码里，根配置和删除权限统一收回到我这里。

COS 的存储桶命名和权限配置有官方快速入门可查，操作细节见对象存储快速入门文档，把桶建好、权限选对，这一步就算打完收工。服务器本机的规则配置同理，对接细节见云服务器文档。

动工前的最后一道检查

账号、权限、预算三张表过完后，我拉着客服组长做了一次开工前的对齐，确认了三件事：知识库原料谁负责收集（老周），订单接口谁负责改造（我），每周验收节奏怎么走（周五下午）。三件事看起来琐碎，但少了任何一样，第二周就会开始互相等。老周当时还问我要不要先招个实习生帮忙，我否了——MVP 阶段人越少扯皮越少，五个人各自多扛一点，一个月也就过去了。老周也表示理解，毕竟能少一个天天加班拼体力的人，大家心里都乐见。至此准备工作全部就绪，只差一份明确的第一版目标。

一份不卡壳的节奏

清单走完，预算批了，接下来就是定 MVP：第一版到底做哪些、不做哪些。如果你也在跟着这本书动手，建议你把这两张表直接复制成你们团队的项目文档，逐项找管理员签字，一次性把账号、权限、预算三件事钉死，后面会顺畅很多。磨刀不误砍柴工，这句话在云项目里特别写实。

延伸阅读

• 线上部署和权限排查，看服务器常见问题。
• 本地服务器知识库方案对比，看NAS 家庭服务器。