引言：把大问题拆成可执行模块

“做一个AI网站”，听起来像是一个宏大工程，很容易在落地时遗漏关键环节。

说到底，就是把一个看似模糊的愿望，拆解成具体可执行的任务模块。

先从目标出发，再按产品、页面、接口、模型、数据、部署、安全和运营逐层拆解。

最后把依赖关系和验收标准都写清楚。

这篇文章给出了一套从零到上线的工作分解结构，专为个人开发者或小团队量身定制，可以直接拿过来执行。

一、目标定义

以一个“AI 内容助手”产品为例。

核心用户流程是这样的：注册/登录 → 选择任务 → 输入材料 → AI 生成 → 用户编辑 → 保存/导出。

整体链路不算复杂，但每一步都得扎扎实实。

第一版范围就收窄一些，只覆盖几个核心场景：

• 文本输入
• 一种主要生成任务
• 查看最近的历史记录
• 按用户设置限额

至于复杂团队协作、插件市场、多模型路由这些，统统留到后续再说。

成功指标可以这样设定：

• 生成成功率高于98%
• P95完整响应时间在业务可接受范围内
• 目标用户的结果采纳率达到预设门槛
• 单次成本不超过预算

二、系统分层

1. 表现层

负责网页交互这块。可以用Vue、React、Next.js，选你顺手的就行。

关键页面包括首页、工作台、历史记录、登录页和用户设置页。

2. 接口层

向前端提供统一的API，功能上包括鉴权、参数校验、限流和错误转换。

要让前端直接接触模型凭证？那可不行。

3. 业务层

处理模板选择、额度扣减、会话管理、内容保存、导出以及失败时的补偿逻辑。

4. AI 能力层

封装通义千问的调用，统一管理模型名称、系统提示词、温度、最大输出、超时、重试和用量统计。

模型和接口参数要从配置读取，编码时决不能散落在各处。

5. 数据层

保存用户、会话、消息、用量和订单。

大文件就放到OSS，数据库只保存文件地址和元数据。

6. 基础设施层

由阿里云提供计算、网络、域名、证书、日志、监控和告警。

模型的话，通过阿里云百炼这类官方入口来调用通义千问。

三、组件选型决策

模块	起步方案	何时升级
前端	静态构建 + OSS/CDN	需要服务端渲染时使用函数、容器或ECS
后端	函数计算	长任务、常驻服务或稳定高负载时评估容器/ECS
模型	满足任务的通义千问模型	质量测试不达标时调整模型或流程
数据库	托管关系型数据库	数据规模、并发或检索模式发生变化时升级
文件	OSS	通常通过生命周期和存储类型优化
缓存	初期可不设	热点数据、会话和限流需要时引入
监控	云监控 + 应用日志	增加链路追踪和精细指标

四、接口结构

接口设计上，至少得规划下面这几组：

POST   /api/auth/login  登录
POST   /api/generations 创建生成任务
GET    /api/generations/:id     查询任务或结果
GET    /api/conversations 获取历史会话
DELETE /api/conversations/:id   删除会话
GET    /api/usage 查询剩余额度

举个例子，创建生成任务的请求体长这样：

{
  "template": "product_copy",
  "input": "一款适合通勤的轻量双肩包",
  "stream": true
}

而错误结构也要统一，避免前端去消化各家模型供应商的原始错误码：

{
  "request_id": "req_xxx",
  "code": "MODEL_TIMEOUT",
  "message": "生成超时，请稍后重试"
}

五、数据结构

数据表的设计，最小化起步即可，主要包括以下四张表：

users

• id
• account
• status
• created_at

conversations

• id
• user_id
• title
• created_at
• updated_at

messages

• id
• conversation_id
• role
• content 或脱敏后的内容引用
• model
• input_tokens
• output_tokens
• latency_ms
• created_at

usage_records

• id
• user_id
• request_id
• model
• token_usage
• cost_estimate
• status
• created_at

值得特别提一句：如果内容涉及敏感信息，那就得重新评估是否要保存原文、保存多久、谁能读取，以及用户如何删除。

六、开发顺序

第 1 个里程碑：模型闭环

在本地后端先完成一次通义千问的调用。

凭证从环境变量读取，记录延迟、用量和错误，然后用20到50个真实样本评估质量。

这一步最快，也最核心。

第 2 个里程碑：前后端闭环

完成输入、提交、加载、流式显示、停止、错误提示和重新生成。

这一阶段可以先不着急保存历史记录。

第 3 个里程碑：用户与数据闭环

增加登录、会话历史、额度控制和删除功能。

重点提醒：数据库操作一定要做用户归属校验，决不能只凭前端传来的user_id就判定权限。

第 4 个里程碑：云上部署

1. 部署后端计算服务；
2. 配置运行时环境变量或密钥服务；
3. 创建数据库和最小权限账号；
4. 发布前端静态资源；
5. 配置域名、DNS、HTTPS 和备案；
6. 检查跨域、Cookie、安全响应头和上传权限。

第 5 个里程碑：运营闭环

增加访问量、生成成功率、模型错误率、Token用量、日成本和用户留存指标，并设置告警。

到这个阶段，产品才算真正跑起来了。

七、安全检查清单

身份与权限

• 后端校验用户身份；
• 管理端和用户端权限分离；
• 数据查询必须附带所属用户条件；
• 云账号采用最小权限，避免长期使用高权限主账号密钥。

输入与输出

• 限制文本长度、文件类型和文件大小；
• 防止提示词注入影响系统指令或泄露内部信息；
• 不执行模型输出的代码或命令；
• 公开内容建立审核、举报与处置机制。

费用保护

• 用户/IP 限流；
• 每日或每月额度；
• 单次最大输出限制；
• 请求超时与有限重试；
• 费用预算和异常突增告警。

数据保护

• 全站 HTTPS；
• 日志脱敏；
• 备份和恢复演练；
• 明确数据保留与删除策略；
• 上传文件使用私有权限和临时签名访问。

八、测试矩阵

类型	核心测试
功能	正常生成、历史保存、删除、额度扣减
模型质量	典型问题、边界问题、错误信息、不充分信息
性能	并发、首字延迟、P95、超时
安全	越权、刷接口、恶意文件、超长输入、密钥泄露
可靠性	模型限流、数据库断开、网络抖动、重复提交
成本	长上下文、长输出、异常重试和机器人调用

九、上线后的指标树

产品成功
├─ 用户价值：生成完成率、采纳率、复访率
├─ 模型质量：满意率、事实错误率、人工修改率
├─ 系统体验：成功率、首字延迟、P95 延迟
├─ 商业效率：单用户收入、单次成本、毛利
└─ 风险控制：违规率、投诉率、异常调用量

结论

结构化推理最直接的价值，就是把“做一个AI网站”从一个模糊的愿望，变成了层次分明的架构、接口、数据表、里程碑和测试矩阵。

执行时，先完成模型闭环，再做用户闭环，最后补上运营闭环。

每增加一个云组件，都要对应一个明确需求、一个责任人、一个可验证的指标。

这样一步步走下来，心里踏实，结果也清晰。