t5-ai 上线评估报告

对象:客服团队 / 主题:氛围编程(vibe coding)系统能否替换智齿 / 2026-10-22

结论

功能已经跑通,离正式上线还差一段路。
研发作为协力单位,先花约 2 周一起把在线客服和自动化接口迁移做稳;之后的新功能和其他站台,照我们平常的合作方式推进。

1发生了什么

客服同事用 AI 做出了一套很实用的系统,希望能替换智齿。

项目内容
做了什么t5-ai:物件开启、延期等自动化请求,加上在线问答
怎么做的客服通过氛围编程(让 AI 写代码),没有研发参与
想要的结果对外给会员使用,并替换第三方付费产品智齿

2检查发现:45 个问题

我们对照了智齿和 t5-ai 的代码,也做了一轮 AI 安全检查,整理出 45 个待处理的问题。

业务逻辑 24 部署与并发 13 仍用旧接口 8
主要风险白话说
会员资料隔离A 会员可能看到或改到 B 会员的物件,属于资安事故
聊天送达、办理结果消息没送到;延期办了两次;开启没成功却回复"已完成"
发布流程、数据恢复出了问题无法回滚,改错的数据救不回来

明细: 业务逻辑(24) · 仍用旧接口(8) · 部署与并发(13)

3根因:氛围编程擅长做功能,后续维护是它的短板

这 45 个修完后,每次加功能,还可能带出新的问题。

🏠
像没有图纸、边住边加盖的房子。能住人,但水管电线走在哪里没人说得清。想加一间房,得先把墙拆开看看里面是什么,一不小心还会碰坏别处。这 45 个问题,大多就藏在这种"墙里面"。

对外产品每加一个功能,都会进入这样的循环:

① 加新功能 ② 用 AI 扫描每次都要扫、都要修 ③ AI 漏扫代码又没人看 ④ 补丁越打越多代码臃肿,下次更难 越做越难
环节正常研发做的系统氛围编程做的系统
维护有结构、有文档,很快能定位问题没人知道整体逻辑,修一处可能坏另一处
扩展留好了接口,照规矩往上加原来没考虑扩展,常常要推倒重来
研发接手照规范读代码,很快上手要花很多时间先读懂,接手不容易

4分析:三个关键判断

判断一:对内可以先用,对外要多一层把关

✓ 对内个人用

自己或少数同事用,不碰外部数据。出了错只影响自己,重来一次就好。可以小范围用。

! 对外给会员用

成千上万会员同时用,也会有人故意乱试。一旦出错,就可能是资料外泄和客诉。建议和研发一起把关。

判断二:做出来了,离替换智齿还有距离

🧊
"做出来"只是冰山露出水面的那一角。智齿收的钱,除了买功能,也是在买专业团队维护、大量客户验证过的稳定性,以及出了事有人负责。
做出来 ← 只算这一块,看起来几乎免费 研发审查和修复(这次就有 45 个问题) 长期维护:修 bug、跟着系统升级 每次改动都要做资安扫描 出事成本:客诉、赔偿、商誉 迁移:工单依赖、历史数据、在途业务 水面下才是大头
智齿提供的自己做就得自己负担的
很多企业在用,问题早被人踩过、修过所有问题都由我们第一个踩到
专业工程团队长期维护研发抽人长期维护,挤占原本的业务开发
有服务承诺,出事有人负责出了事要靠我们自己处理

判断三:长期维护不该只落在客服同事身上

维护要有的能力客服同事的现状
看懂代码、定位问题代码由 AI 生成,还没人逐行看过
处理资安、并发、接口升级属于工程专业,不在客服的日常工作里
出事时快速止损、回滚目前还没有这套机制

5方案:研发作为协力单位,先一起把这一段做稳

这次先聚焦在线客服和接口迁移;后续需求照平常的合作流程走,大家节奏都比较好安排。

这一段 · 研发协力约 2 周 • 在线客服 • 开启、延期等自动化接口迁移 • 修完高优先级问题并验收 → 先小范围启用 后续 · 照平常合作流程 • 新增功能 • 扩展到其他站台 • 提需求,研发评估后排期 → 和其他需求一起安排
角色以后负责什么
客服用氛围编程做原型,把需求直接演示出来,比写文档更清楚;同时负责业务规则和验收
研发作为协力单位,一起负责对外系统的安全、稳定和长期维护

待确认

一句话版本

"你们做的原型很有价值,证明了这件事值得做。要给会员用的话,安全和维护的担子不该只压在你们身上。研发会作为协力单位,先花大约 2 周一起把在线客服和接口迁移做稳;之后想加功能或给其他站台用,我们照平常的方式一起排。"