壹知心理：心理测评平台从 0 到 1 交付

背景

产品是一个综合性心理测评服务平台：C 端用户在小程序里做测评、拿报告、付费咨询，B 端企业客户通过管理后台查看团体测评结果与运营数据。

交付上的难点不在某个模块，而在面太宽。一个从 0 到 1 的产品里同时包含在线测评与报告生成、三方支付、AI 客服、大数据运营分析四类差异很大的能力，团队要同时对接产品、算法、数据三方，任何一条链路延期都会拖住整体上线。

我的职责

作为技术经理与项目负责人，我负责的是范围与节奏：

• 制定版本里程碑与迭代计划
• 协调产品、后端、前端、算法（AI 模型微调）、数据（大数据链路搭建）多方资源
• 明确接口契约与交付节点，推动 AI 能力与数据平台同现有系统的集成落地
• 协调大数据基础设施（Kafka 数据采集、Flink 实时计算、Quick BI 报表）的资源排期与联调
• 向上同步进度与风险，向下推动阻塞点解决

技术架构

• 业务服务层：SpringCloud Alibaba 微服务体系，基于阿里云 ECS 自建 K8s 集群实现容器化编排
• 云产品托管：阿里云 RDS（MySQL）、Redis、RocketMQ、CDN/全站加速、轻量应用负载均衡
• 自建中间件：ECS 实例群部署 Nacos、Seata、Zookeeper、Kafka
• AI 与数据层：Python（FastAPI）+ PyTorch + SpringAI + Milvus
• 大数据链路：Kafka（采集）→ HDFS + HBase（存储）→ Flink（实时计算）→ 阿里云 Quick BI（展示）

关键决策与取舍

AI 客服先灰度、并准备降级方案。 这是产品里最不确定的一环：模型有响应延迟与幻觉两类风险，全量放开意味着答错会直接变成客诉。因此上线前就把降级方案与灰度发布策略准备好，而不是等出问题再补。

托管与自建混用的部署顺序要显式管起来。 项目同时用了阿里云托管产品与自建集群，托管部分省运维但要按它的约束走，自建部分灵活但要自己保证稳定。混合架构下真正的风险往往不是单个组件，而是依赖顺序与资源排期，所以这部分被单独作为协调项处理。

支付回调必须按幂等设计。 支付对接了微信与支付宝两条渠道，资质申请需要商务与法务配合；而回调可能被渠道重复通知，处理不当就是重复发货或重复记账。

结果

• 产品按里程碑交付，项目按时交付率达 95%
• AI 客服按灰度方式平稳上线
• 支付链路跑通微信与支付宝双渠道，回调幂等设计下做到支付零差错
• 推行 GitFlow 协作规范与 Code Review 机制，建立版本发布 Checklist，线上缺陷率同比下降

反思

这个项目最大的经验是把不确定性单独拎出来处理。AI 客服的风险、混合架构的部署顺序、支付回调的重复通知，共同点是「不做预案就大概率出事」。项目管理的价值多半体现在这类地方：不是让顺利的事更快，而是让可能出事的地方不出事。