DSX AI 风险 review · 2026-05-19

会议核心

起点

问题

左橘长基于 Claude Code + Codex（模型用 Claude 4.7 + GPT 5.5）开发的 agent 平台已部署到阿里云 ECS，准备 5/21 上线聊天（火山引擎大模型 + RAG 知识库）和简历（PDF 上传→AI 打分→优化→HTML/PDF 输出）两个模块。

戴师兄担心可扩展性和上线后的维护风险，邀请芹菜（资深开发）做技术 review，重点：架构合不合理 · 安全有没有坑 · 上线流程是否规范。

结论

输出

当前架构功能完整但部署粗糙。芹菜的判断：

整体平台对一个非科班开发者来说已经很完整（戴师兄评价"特例"）
但生产环境有3 个明确风险：单台 ECS 没扩缩容、AI 直连生产库改表、没有测试环境
另外 4 个建议是规范层面：日志接入、用户限流、敏感信息加密、支付接入路径

课程方向上：AI 课从 1999-2999 试听课改成 1499 完整版，以左橘长为主讲，戴师兄要左橘长先输出章节大纲。

关键决议

本次会议达成的方向性决定

01

周四（5/21）上线两个模块：聊天 + 简历

两个模块对管理员账号全功能开放，普通用户只能用这两个。其他模块（分析师等）暂不开放。

02

部署架构改造：从单台 ECS 改成容器服务 + 网关

阿里云容器服务便宜+可动态扩缩容，单台 ECS 撑不住流量峰值。上层用阿里云网关做负载均衡，把域名绑定到网关。这是 5/19 决议中最重要的一条架构改造。

03

生产库改表流程：AI 不能直连生产库

红线规则：AI 只能生成 SQL（本地或测试环境可以直连），SQL 跟着代码版本管理，到生产库的执行必须人工去阿里云平台执行，要核对改了哪些表、跟预期是否一致。让 AI 直接连生产库改表 = 系统挂掉/数据丢失的高概率事件。

04

必须搭建测试环境，库完全隔离

每次改动先在测试环境跑通，再上生产。库要完全隔离（独立 MySQL 实例），不能共用一个库分 schema。容器服务能简化多机部署。

05

支付接入路径：先支付宝，跳过第三方

域名备案完成后，直接接入支付宝企业账户的 Skill（已经从 SDK 时代进化到 Skill 时代），由 Claude Code / Codex 调用。不走第三方支付聚合（手续费高）。微信支付等其他渠道暂不接入。

06

AI 开发课定价跳变：1499 元正式版

跳过 1999 元试听阶段，下次直接整一个 1499 的完整版，把 AI 开发、AI 产品、AIGC 全打包。以左橘长为主讲，戴师兄围绕他做学习路径设计，要求左橘长先输出一级标题章节大纲。

07

技术债处理顺序：可扩展性后置

芹菜建议："先不管扩展性，每个模块单独上，先把功能都实现，迭代不下去再重构"。戴师兄关心的"可扩展性"问题被推迟到"卡住的时候再说"。一旦遇到瓶颈，让 Claude 4.7 规划重构方案。

技术建议详表

芹菜给出的 7 类建议汇总，按优先级排序

领域	优先级	核心建议
部署架构	P0	单台 ECS → 阿里云容器服务（便宜+弹性扩容）+ 网关（负载均衡+域名绑定）。线上系统单台机器扛不住。
数据库改表	P0	生产库改表必须人工执行 SQL，绝不能让 AI 直连生产库。AI 生成 SQL → 跟代码版本管理 → 人工去生产库执行。
测试环境	P0	必须搭完整的测试环境（库也隔离）。每次改动先在测试跑通再上生产。容器服务能简化这个流程。
用户限流	P1	避免用户疯狂调用大模型烧 token。建议做积分/配额机制（每用户每天 N 次）。当前只在前端做了防点击隔离，后端配额没做。
日志接入	P1	当前日志只打到 ECS 本地磁盘。上容器后用阿里云日志服务（容器一键接入），记录大模型调用日志+操作日志+错误日志。
敏感信息加密	P1	用户密码用 MD5 加盐够用，但简历内容这种敏感信息必须用可逆加密（AES 之类）。MD5 不可逆，不适合存需要还原的内容。
支付接入	P2	域名备案后接入支付宝企业账户的 Skill（不走第三方支付聚合）。Skill 比 SDK 更适合 Claude/Codex 直接调用。
代码 review	P2	登录注册的 SQL 注入风险——如果用了 Prisma 等框架一般已经解决。芹菜要左橘长把代码 push 到 GitHub 给他详细 review 一遍。

TODO 清单

9 条新 TODO，主要是技术债+流程规范

上线前（5/21 之前）

3 items

把代码 push 到 GitHub 发给芹菜 review

P0 左橘长 5/21 前

完整代码仓库发给芹菜，重点看登录注册防注入、整体表结构合理性

▶ 验收：芹菜收到代码并给出反馈

域名备案+绑定

P1 左橘长

当前平台还是 IP 裸奔，必须域名备案后绑定网关才能正式上线

▶ 验收：备案号下发，域名能访问

简历内容 AES 加密

P1 左橘长

让 AI 把简历存储改成 AES 等可逆加密，保护用户隐私

▶ 验收：数据库里看不到明文简历

上线后（5/22 - 6 月）

5 items

部署架构改造：单台 ECS → 容器服务 + 网关

P0 左橘长

先研究阿里云容器服务和网关的接入流程，迁移过程要保证业务连续

▶ 验收：容器跑通+网关接入+域名解析正常

搭建独立测试环境（库完全隔离）

P0 左橘长

完整复制生产环境，但用独立的 MySQL 实例。后续所有改动先过测试环境

▶ 验收：测试环境能跑通+生产环境零误操作

建立改库 SQL 版本管理流程

P0 左橘长

所有改表 SQL 跟代码一起 commit，生产库执行由人工去阿里云平台手动跑

▶ 验收：第一次生产改表按新流程跑通

阿里云日志服务接入

P1 左橘长

容器接入阿里云日志服务，记录大模型调用+操作日志+错误日志，便于 debug

▶ 验收：日志能在控制台查询

用户限流/配额机制（每日 N 次）

P1 左橘长

每用户每天能调用大模型 N 次，或者用积分机制。避免用户烧光 token

▶ 验收：超额触发限制提示

课程相关

1 item

输出 AI 开发课一级标题章节大纲

P1 左橘长

写一级章节标题+每章的小知识点，戴师兄基于此规划学习路径和作业。课程定价 1499 元

▶ 验收：大纲文档发给戴师兄

我的判断与建议

基于 project_memory 历史信息的串联分析

CONFLICT

课程定价决议有重大变化，需要在团队内同步

5/28 课程定位会议（在 decisions.md 里）明确"AI 项目实战课 / AI 数据分析课定价 1999-2999"，但本次会议（5/19，时间更早）戴师兄说"下次直接整 1499 的"。两个表述看起来矛盾。

实际上 5/19 在 5/28 之前，所以 5/28 的 1999-2999 是后定的决议，应该是有效版本。但 5/19 的 1499 数字是怎么演化出来的？是不是 AI 开发课和 AI 项目实战课/AI 数据分析课定位不一样？建议下次会议明确：AI 开发课（左橘长主讲）和付费课两条线（项目实战/数据分析）是否是三条独立的课，各自定价不同？

📎 历史关联：查看 decisions.md 里 2026-05-28 课程定位会议的相关决议

PEOPLE

左橘长在 people.md 里的角色定位需要更新

people.md 里左橘长是"工具课核心创作者"，但这次会议显示他实际是：
① 独立开发了 agent 平台（聊天 + 简历 + RAG）
② 即将成为 AI 开发课的主讲（戴师兄："以你为主"）
③ 数仓+数分背景，统计专业自学，靠 AI 协作开发

这个角色比"工具课创作者"重要得多。建议在 people.md 里明确：左橘长 = 工具课+AI 开发课双线创作者，是团队 AI 协作开发的标杆案例（戴师兄："我以为一个人能搞起来这种平台是特例"）。

📎 历史关联：查看 people.md 里左橘长的当前角色定位

PEOPLE

芹菜的角色定位也有微妙变化

people.md 里芹菜是"AI 开发课讲师"，但本次会议显示这门课主讲变成了左橘长，芹菜实际承担的是"技术顾问"角色（review 代码、给架构建议）。建议 people.md 改为：芹菜 = AI 开发课技术顾问 / 资深开发 review。

WIN

芹菜的 review 模型值得固化成团队流程

本次 review 的方式很高效：左橘长演示功能 → 芹菜按"部署/安全/上线"三维度提问 → 给出具体技术建议。整个 38 分钟产出了 7 类建议+至少 8 条 TODO。

建议把这个流程做成 SOP：每个 AI 写的项目上线前必须过一次芹菜 review。下个 AI 项目实战课（5/28 决议）里 6 个学员项目的上线，也应该走这个 review 流程。这是项目质量兜底的关键环节。

CORE

"AI 写代码 + 人审架构"模式的具体边界

本次 review 暴露了 AI 协作开发的3 类典型盲区：
① 架构盲区：AI 不会主动推荐容器服务，只会照单台 ECS 写
② 流程盲区：AI 会直连生产库改表（高危），不会自动建立 SQL 版本管理
③ 安全盲区：AI 不会主动加 AES 加密、不会主动做用户配额

这 3 类问题不是 AI 能力问题，是"AI 不知道这些是问题"。建议在 AI 项目实战课里加一节"AI 看不到的工程盲区"，把今天 review 的 7 条建议作为教学案例。这就是 AI 开发课 vs AI 项目实战课最核心的差异。

📎 历史关联：这条建议跟 5/28 AI 项目实战课的"6 个项目"设计是互补的（学员做项目时会遇到同样的盲区）

风险与开放问题

OPEN

5/21 上线前能完成所有 P0 改造吗？

本次会议在 5/19 晚 21:09，到 5/21 上线只剩约 36 小时。3 条 P0 TODO（容器迁移、测试环境、改库流程）短时间内不可能全做完。实际上线时极大概率还是单台 ECS 裸奔。建议明确：5/21 是"功能上线"，架构改造在 5/21 后第一周完成，期间限制访问量避免事故。

OPEN

AI 开发课定价 1499 元是否经过商业测算？

5/28 决议里付费课是 1999-2999 元区间，这次的 1499 元是怎么定的？是对左橘长的能力定价更保守，还是跟 AI 项目实战课形成价格梯队（实战课 1999、开发课 1499）？这个数字会影响整体课程矩阵的设计，建议下次商业评审专门讨论。

OPEN

用户限流策略：按次数还是按 token？

芹菜建议"每用户每天 N 次"，但实际大模型成本是按 token 算的。一个用户调用 5 次但每次输入 10 万 token，跟 50 次每次 500 token，成本差 50 倍。建议限流改成按 token 配额而不是按次数，更贴近成本控制。

OPEN

代码 review 走 GitHub 的话，仓库公开还是私有？

左橘长说"代码在 GitHub 上面，我待会推一个最新的给你"。如果是私有仓库需要邀请芹菜协作；如果是公开仓库，要确认没有 token / secret 硬编码。建议先 grep 一遍敏感信息再开放。