- 修改 shouldVerifyCacheManager_withMaximumIntegerTtl 为 shouldVerifyCacheManager_withMaximumAllowedTtl - 使用正确的最大TTL值(10080分钟,7天)而不是 Integer.MAX_VALUE - 新增 shouldThrowException_whenTtlExceedsMaximum 测试验证边界检查 - 所有1266个测试用例通过 - 覆盖率: 指令81.89%, 行88.48%, 分支51.55% docs: 添加项目状态报告 - 生成 PROJECT_STATUS_REPORT.md 详细记录项目当前状态 - 包含质量指标、已完成功能、待办事项和技术债务
21 KiB
蚊子项目 - 企业级产品战略审查报告
审查人:企业级产品经理专家(20年+经验) 审查日期:2026年1月21日 审查方法:基于产品战略、用户体验、技术实现、商业可行性多维度深度分析
执行摘要
项目定位:面向B端市场的SaaS级裂变营销平台,通过API集成方式帮助企业实现低成本获客。
当前状态:技术架构基础良好,但产品化成熟度约55%,存在多个阻碍上线的关键缺陷,距离企业生产级交付标准还有显著差距。
核心发现:项目在战略定位、价值验证、功能完整性、安全保障、数据准确性、前端体验等核心产品维度存在严重缺陷,建议立即重新评估产品规划。
一、产品战略维度审查
1.1 产品定位模糊度:⚠️ 高风险
| 检查项 | 现状 | 问题描述 | 风险等级 |
|---|---|---|---|
| 目标客户画像 | ❌ 未明确 | PRD中仅抽象描述"活动管理员",缺乏行业垂直度、企业规模、技术能力等具体画像 | 严重 |
| 市场细分策略 | ❌ 缺失 | 未区分电商、教育、SaaS等不同行业的裂变场景差异 | 严重 |
| 商业模式验证 | ❌ 未设计 | 缺乏定价策略、客户成功指标、流失率预测 | 严重 |
| 竞争差异化 | ❌ 不清晰 | 与现成方案(如GrowingIO、诸葛io)的差异化优势未明确 | 高 |
产品经理视角:当前PRD更像技术需求文档而非产品战略文档。20年经验的产品经理会要求补充:
- TAM/SAM/SOM市场分析
- 竞品功能对比矩阵
- 客户价值主张画布
- 产品市场契合度验证计划
1.2 价值主张缺陷:🔴 致命问题
PRD承诺的价值:
"将客户的平均获客成本(CAC)降低50%以上,K因子大于1"
实际交付的问题:
// StatisticsAggregationJob.java:52-59 - 关键统计数据完全随机!
public DailyActivityStats aggregateStatsForActivity(Activity activity, LocalDate date) {
Random random = new Random();
stats.setViews(1000 + random.nextInt(500)); // ❌ 假数据
stats.setShares(200 + random.nextInt(100)); // ❌ 假数据
stats.setNewRegistrations(50 + random.nextInt(50)); // ❌ 假数据
}
产品经理评估:
- 无法衡量CAC:缺少成本追踪模块
- 无法计算K因子:多级邀请关系未完整实现
- 数据完全不可信:生产环境使用随机数模拟统计数据
建议立即行动:暂停所有开发,先实现真实数据追踪链路。
二、用户价值维度审查
2.1 核心用户旅程断裂:🔴 关键缺陷
PRD承诺的用户故事:
"作为管理员,我希望设置优惠券奖励"
实际实现:
// ActivityService.java:274-284
public void createReward(Reward reward, boolean skipValidation) {
if (reward.getRewardType() == RewardType.COUPON && !skipValidation) {
throw new UnsupportedOperationException(
"优惠券验证功能尚未实现。"
);
}
}
用户旅程断裂点分析:
| 用户场景 | 期望流程 | 实际情况 | 阻断原因 |
|---|---|---|---|
| 运营创建带优惠券活动 | 选择优惠券→填写批次ID→验证有效→发布 | ❌ 到验证环节直接报错 | 功能未实现 |
| 用户完成邀请获得奖励 | 触发回调→计算奖励→发放优惠券→通知用户 | ❌ 发放逻辑缺失 | 队列系统未对接 |
| 运营查看活动ROI | 访问仪表盘→查看CAC/K因子→导出报告 | ❌ CAC为0,K因子不可计算 | 数据链路缺失 |
产品评估:核心价值主张"自动激励"完全无法兑现。
2.2 API集成体验:⚠️ 高风险
问题1:API Key安全设计缺陷
// ApiKeyAuthInterceptor.java:25
String prefix = rawApiKey.substring(0, Math.min(12, rawApiKey.length())).trim();
安全专家评估(基于security skill):
- 前缀12位过长:增加泄露风险,建议8位
- 缺少速率限制:暴力破解防御缺失
- 未记录失败尝试:无法检测异常访问
问题2:回调API设计混乱
// docs/api.md:75-80
POST /api/v1/api-keys/{id}/use // 按ID校验
POST /api/v1/api-keys/validate // 仅凭密钥校验
RESTful设计评估(基于api-design skill):
- 违反REST规范:同一资源多个端点
- 语义不清晰:
usevsvalidate概念混淆 - 缺少幂等性保证:未说明重复调用行为
产品建议:
- 统一为
POST /api/v1/callbacks接受tracking_id - 使用单一认证机制(Header中的X-API-Key)
- 提供SDK降低集成难度
2.3 前端体验严重缺失:🔴 致命问题
| 前端模块 | PRD承诺 | 实际情况 | 影响 |
|---|---|---|---|
| 管理后台 | 活动管理、数据看板 | ❌ 完全缺失 | 管理员无法使用系统 |
| 用户端H5 | 邀请链接、海报生成 | ❌ 完全缺失 | 用户无法分享 |
| 海报渲染 | Canvas降级方案 | ⚠️ 后端有但未对接 | 降级策略不可用 |
| 移动端适配 | 响应式设计 | ❌ 未实现 | 移动体验差 |
产品评估:B端SaaS产品缺乏前端界面,无法交付。
三、技术实现维度审查
3.1 数据模型设计问题:⚠️ 高风险
问题1:多级奖励规则未关联到活动
-- V3__Create_multi_level_reward_rules_table.sql
CREATE TABLE multi_level_reward_rules (
activity_id BIGINT NOT NULL, -- ✅ 有外键
level INT NOT NULL,
decay_coefficient DECIMAL(5, 4) NOT NULL
);
// Activity.java:15
private List<MultiLevelRewardRule> multiLevelRewardRules; // ⚠️ 仅在内存,未持久化
数据库评估(基于database skill):
- 规则未保存到数据库:
ActivityService.createActivity()未持久化multiLevelRewardRules - 数据不一致:Domain层和Persistence层不同步
- 功能不可用:多级奖励计算逻辑存在但无实际数据支撑
问题2:link_clicks表设计缺陷
-- V14__Create_link_clicks_table.sql
CREATE TABLE link_clicks (
code VARCHAR(32) NOT NULL,
activity_id BIGINT, -- ⚠️ 允许NULL
inviter_user_id BIGINT, -- ⚠️ 允许NULL
created_at TIMESTAMP WITH TIME ZONE NOT NULL
);
数据完整性评估:
- 缺失关键索引:未创建联合索引
(code, activity_id) - 允许NULL字段:activity_id和inviter_user_id可为空,违反数据完整性
- 查询性能差:按活动查询时无索引,大数据量下严重卡顿
建议DDL修复:
-- 修复约束
ALTER TABLE link_clicks
ALTER COLUMN activity_id SET NOT NULL,
ALTER COLUMN inviter_user_id SET NOT NULL;
-- 添加联合索引
CREATE INDEX idx_link_clicks_activity_code ON link_clicks(activity_id, code);
3.2 API设计专业度评估:🔴 严重不及格
基于api-design技能标准评估:
| 设计原则 | 期望标准 | 实际情况 | 评分 |
|---|---|---|---|
| RESTful命名 | /users, /activities |
/api/v1/activities ✅ |
8/10 |
| HTTP语义 | GET/POST/PUT/DELETE正确使用 | 基本正确 | 7/10 |
| 版本控制 | URL版本或Header版本 | 混用,不一致 | 4/10 |
| 错误处理 | 统一错误码和格式 | 部分不一致 | 5/10 |
| 文档完整性 | OpenAPI 3.0规范 | Swagger注解不完整 | 4/10 |
关键API设计缺陷:
缺陷1:短链接重定向缺少追踪
// ShortLinkController.java:39-76
@GetMapping("/r/{code}")
public ResponseEntity<Void> redirect(@PathVariable String code) {
// ❌ 未记录点击到link_clicks表
// ❌ 未更新邀请关系
// ❌ 未触发奖励计算
return ResponseEntity.status(HttpStatus.FOUND).location(URI.create(originalUrl)).build();
}
业务逻辑缺失:
- PRD承诺的"追踪传播路径"完全未实现
- ShareTrackingService.recordClick()存在但未被调用
- 短链接跳转和业务逻辑断裂
缺陷2:活动状态机缺失
// ActivityEntity.java - status字段存在但无状态机
private String status = "draft"; // 仅draft/active/paused/ended字符串
建议实现状态机:
public enum ActivityStatus {
DRAFT, ACTIVE, PAUSED, ENDED;
public boolean canTransitionTo(ActivityStatus target) {
return switch(this) {
case DRAFT -> target == ACTIVE;
case ACTIVE -> target == PAUSED || target == ENDED;
case PAUSED -> target == ACTIVE || target == ENDED;
case ENDED -> false;
};
}
}
四、商业可行性维度审查
4.1 成本追踪缺失:🔴 致命缺陷
PRD指标:CAC(用户获客成本)
现状分析:
// 数据库中完全没有成本相关表结构
// user_rewards表只记录了发放,没有成本来源
// 缺少:活动预算、奖励单价、实际支出、ROI计算
产品评估:
- 无法计算CAC:缺少支出数据
- 无法控制成本:没有预算上限机制
- 无法衡量ROI:收入数据完全缺失
建议数据模型补充:
CREATE TABLE activity_budgets (
activity_id BIGINT PRIMARY KEY,
total_budget DECIMAL(10, 2),
spent_amount DECIMAL(10, 2),
currency VARCHAR(3) DEFAULT 'CNY'
);
CREATE TABLE reward_cost_logs (
id BIGINT PRIMARY KEY,
user_reward_id BIGINT,
cost DECIMAL(10, 2),
calculated_at TIMESTAMP
);
4.2 风控机制严重不足:⚠️ 高风险
PRD承诺:
"需要能初步识别和拦截刷单行为"
实际实现:
| 风控场景 | PRD承诺 | 实际实现 | 评估 |
|---|---|---|---|
| IP限流 | 基础防刷 | 仅有简单IP计数 | ❌ 不足 |
| 设备指纹 | 提及 | 未实现 | ❌ 缺失 |
| 异常检测 | 提及 | 无规则引擎 | ❌ 缺失 |
| 黑名单 | 未提 | 无黑名单系统 | ❌ 缺失 |
| 人工审核 | 未提 | 无审核后台 | ❌ 缺失 |
产品风险评估:
- 刷单成本极低:专业羊毛党可轻松绕过
- 成本失控风险:无预算熔断机制
- 客户信任风险:数据造假导致客户投诉
建议风控方案:
- 设备指纹集成:使用FingerprintJS或类似方案
- 实时规则引擎:基于Drools或自研轻量规则引擎
- 预算熔断:超出预算自动停止奖励发放
- 人工审核流:大额奖励进入待审核队列
五、运营支持维度审查
5.1 监控可观测性:⚠️ 不足
现有监控:
# application.properties:35-41
management.endpoints.web.exposure.include=health,info,metrics
缺失的关键指标:
| 指标类别 | 缺失指标 | 影响 |
|---|---|---|
| 业务指标 | 活动创建数、奖励发放数、K因子、CAC | 无法判断产品健康度 |
| 技术指标 | API成功率、回调延迟、队列堆积 | 无法快速定位问题 |
| 安全指标 | API密钥异常使用、刷单尝试次数 | 无法及时发现攻击 |
| 成本指标 | 资源使用成本、奖励支出趋势 | 无法优化运营成本 |
| 前端指标 | 页面加载时间、API调用失败率、用户交互热力图 | 无法优化前端体验 |
建议监控方案:
// 添加业务指标埋点
@Component
public class BusinessMetrics {
private final MeterRegistry meterRegistry;
public void recordRewardIssued(Long activityId, int points) {
meterRegistry.counter("reward.issued",
"activity_id", String.valueOf(activityId),
"reward_type", "points"
).increment();
}
public void recordCallbackLatency(Long durationMs) {
meterRegistry.timer("callback.latency").record(durationMs, TimeUnit.MILLISECONDS);
}
public void recordFrontendApiCall(String endpoint, int statusCode, long durationMs) {
meterRegistry.counter("frontend.api.call",
"endpoint", endpoint,
"status", String.valueOf(statusCode)
).increment();
meterRegistry.timer("frontend.api.latency",
"endpoint", endpoint
).record(durationMs, TimeUnit.MILLISECONDS);
}
}
5.2 客户支持工具缺失:❌ 严重不足
缺失的工具:
- 客户查询后台:无法快速回答客户问题
- 问题诊断工具:无法追踪用户失败原因
- 批量操作工具:无法处理特殊需求
- 应急回滚工具:发布问题后无法快速回滚
产品评估:SaaS产品至少需要20%的功能用于客户支持,当前接近0%。
六、运维与稳定性维度审查
6.1 运维复杂度评估:⚠️ 中等
当前运维痛点:
| 运维场景 | 现状 | 问题 |
|---|---|---|
| 部署 | 需手动配置数据库、Redis | 无Docker化,部署复杂 |
| 监控 | 仅基础健康检查 | 缺少业务监控告警 |
| 日志 | Logback控制台输出 | 无聚合,难以排查 |
| 备份 | 未定义 | 数据无备份策略 |
| 扩容 | 无方案 | 无法应对流量激增 |
| 降级 | 部分开关存在 | 无统一降级策略 |
6.2 稳定性风险:⚠️ 中等
稳定性隐患:
| 稳定性维度 | 风险点 | 影响 |
|---|---|---|
| 单点故障 | PostgreSQL、Redis无高可用 | 服务中断 |
| 限流 | 仅全局限流 | 单用户可刷爆 |
| 熔断 | 未实现 | 级联故障风险 |
| 幂等性 | 回调API无保证 | 重复奖励风险 |
| 数据一致性 | 无分布式事务 | 数据不一致 |
七、产品成熟度综合评估
7.1 功能完成度矩阵
| 功能模块 | PRD承诺 | 实现状态 | 可用性 | 优先级 |
|---|---|---|---|---|
| 活动创建 | ✅ | ✅ 基础实现 | 70% | P0 |
| 活动管理(编辑/删除) | ✅ | ✅ 已实现 | 85% | P0 |
| 阶梯奖励 | ✅ | ✅ 已实现 | 80% | P0 |
| 多级奖励 | ✅ | ⚠️ 数据未持久化 | 40% | P0 |
| 优惠券发放 | ✅ | ❌ 未实现 | 0% | P0 |
| 活动统计 | ✅ | ⚠️ 使用假数据 | 20% | P0 |
| 邀请关系追踪 | ✅ | ❌ 跳转逻辑缺失 | 30% | P0 |
| API密钥管理 | ✅ | ✅ 已实现 | 75% | P1 |
| 活动排行榜 | ✅ | ✅ 已实现 | 85% | P1 |
| 裂变网络图 | ✅ | ⚠️ 性能问题 | 50% | P2 |
| 海报生成 | ✅ | ⚠️ 降级方案未完善 | 60% | P2 |
| 防刷单 | ✅ | ⚠️ 仅基础实现 | 30% | P0 |
| 成本追踪 | ✅ | ❌ 完全缺失 | 0% | P0 |
| 管理后台 | ✅ | ❌ 完全缺失 | 0% | P0 |
| 用户端H5 | ✅ | ❌ 完全缺失 | 0% | P0 |
| 海报渲染降级 | ✅ | ⚠️ 前端未对接 | 30% | P1 |
整体完成度:约55%
7.2 质量门禁评估
| 质量维度 | 企业标准 | 当前状态 | 评估结果 |
|---|---|---|---|
| 功能完整性 | 100% PRD功能已实现 | 55% | ❌ 不通过 |
| 测试覆盖率 | 核心业务>90% | ~70% | ⚠️ 需提升 |
| 安全性 | 无高危漏洞 | 存在多个中高危问题 | ❌ 不通过 |
| 性能 | 响应<200ms, 支持500 QPS | 未压力测试 | ⚠️ 未验证 |
| 可观测性 | 关键指标全量埋点 | 缺失业务+前端指标 | ❌ 不通过 |
| 文档完整性 | API/部署/运维文档齐全 | 缺失生产部署文档 | ⚠️ 需补充 |
| 合规性 | 满足数据隐私法规 | 未进行合规审查 | ❌ 不通过 |
| 运维自动化 | 部署/监控/备份自动化 | 缺失 | ❌ 不通过 |
| 稳定性保障 | 限流/熔断/降级/幂等 | 部分实现 | ⚠️ 需完善 |
八、紧急修复清单(按优先级)
🔴 P0级 - 阻碍上线(2周内完成)
| 编号 | 问题 | 影响 | 预估工时 |
|---|---|---|---|
| P0-001 | 优惠券发放功能未实现 | 核心价值无法兑现 | 5人日 |
| P0-002 | 统计数据使用随机数 | 所有决策数据造假 | 3人日 |
| P0-003 | 多级奖励规则未持久化 | 核心功能不可用 | 2人日 |
| P0-004 | 短链接跳转未记录追踪 | 传播路径黑盒 | 3人日 |
| P0-005 | 缺少成本追踪模块 | 无法计算CAC/ROI | 5人日 |
| P0-006 | 防刷单机制严重不足 | 成本失控风险 | 5人日 |
| P0-007 | API Key前缀12位过长 | 安全风险 | 0.5人日 |
| P0-008 | 硬编码加密密钥 | 生产环境致命问题 | 0.5人日 |
| P0-009 | 管理后台完全缺失 | 管理员无法使用 | 10人日(前端) |
| P0-010 | 用户端H5完全缺失 | 用户无法分享 | 8人日(前端) |
后端总计:约24人日(3人团队8天完成) 前端总计:约18人日(1人团队18天完成) 总计:约42人日(按并行安排,约3周完成)
🟡 P1级 - 影响体验(1个月内完成)
| 编号 | 问题 | 影响 | 预估工时 |
|---|---|---|---|
| P1-001 | 活动状态机缺失 | 状态管理混乱 | 3人日 |
| P1-002 | 客户支持工具缺失 | 客服效率低下 | 8人日(含前端) |
| P1-003 | 业务监控指标缺失 | 运营盲区 | 4人日(含前端) |
| P1-004 | API设计不一致 | 集成体验差 | 3人日 |
| P1-005 | link_clicks表优化 | 性能隐患 | 1人日 |
| P1-006 | 限流熔断完善 | 稳定性风险 | 3人日 |
| P1-007 | 健康检查增强 | 可观测性不足 | 2人日 |
| P1-008 | 海报渲染降级对接 | 性能优化 | 3人日(前端) |
🔵 P2级 - 长期优化(Q2完成)
- 客户查询后台
- 高级风控规则引擎
- 客户自助分析工具
- 多租户隔离
- 移动端原生应用
九、战略建议
建议1:重新定义MVP范围(强烈建议)
当前问题:试图在V1.0交付全部功能,导致质量失控。
建议MVP缩减:
保留核心功能:
✅ 活动创建/管理
✅ 阶梯奖励(积分类型)
✅ 短链接基础追踪
✅ 活动统计(真实数据)
✅ API密钥管理
✅ 基础管理后台(仅活动CRUD)
✅ 基础用户端H5(仅邀请链接)
延后功能:
⏸️ 多级奖励
⏸️ 优惠券发放
⏸️ 裂变网络图
⏸️ 高级风控
⏸️ 数据分析看板
预期效果:将完成度从55%提升至85%,2个月可上线MVP。
建议2:引入产品决策委员会
建议成立由以下角色组成的委员会:
- 产品负责人:负责产品方向和优先级决策
- 技术负责人:负责技术可行性评估
- 客户成功负责人:负责客户反馈和需求验证
- 合规负责人:负责法律风险评估
建议3:启动"四周冲刺"质量专项行动
目标:修复所有P0级问题,完成前端基础功能
计划:
Week 1(P0后端核心):
├─ Day 1-2: P0-008 安全问题 + P0-007 API前缀
├─ Day 3-4: P0-002 真实数据聚合 + P0-004 短链接追踪
├─ Day 5: P0-003 多级奖励持久化
└─ Day 6-7: 前端框架搭建 + 基础组件
Week 2(P0后端完整性 + 前端后台):
├─ Day 1-3: P0-001 优惠券发放
├─ Day 4-5: P0-006 基础防刷(限流)
├─ Day 6-7: 管理后台开发(活动CRUD)
Week 3(P0前端用户端 + P1运维):
├─ Day 1-3: P0-010 用户端H5(邀请链接)
├─ Day 4-5: P1-006 限流熔断完善
└─ Day 6-7: P1-007 健康检查增强
Week 4(集成测试 + 优化):
├─ Day 1-3: P0-005 成本追踪基础
├─ Day 4-5: 集成测试 + 稳定性验证
└─ Day 6-7: 部署文档 + 监控配置
十、最终评估
| 评估维度 | 评分(1-10) | 状态 |
|---|---|---|
| 产品战略清晰度 | 3/10 | ❌ 严重不足 |
| 用户价值实现 | 4/10 | ❌ 核心功能缺失 |
| 技术架构稳健性 | 7/10 | ⚠️ 需优化 |
| 商业可行性 | 2/10 | ❌ 关键缺陷 |
| 运营支撑能力 | 3/10 | ❌ 严重不足 |
| 前端用户体验 | 1/10 | ❌ 完全缺失 |
| 运维自动化 | 4/10 | ⚠️ 严重不足 |
| 稳定性保障 | 5/10 | ⚠️ 部分实现 |
| 上线准备度 | 3/10 | ❌ 不满足标准 |
综合评分:3.3/10
结论:项目不建议按当前计划上线,建议启动为期4周的"质量专项行动"修复P0级问题并完成前端基础功能,或重新定义MVP范围。
附录:审查方法论
本次审查基于以下专业标准和最佳实践:
- 产品战略:基于硅谷产品方法论(AARRR、Jobs-to-be-Done)
- 用户体验:基于双钻模型和用户旅程映射
- 技术评估:基于OWASP安全标准、RESTful设计原则、数据库规范化理论
- 商业可行性:基于精益创业方法论和SaaS指标体系
- 运维稳定性:基于Site Reliability Engineering (SRE) 最佳实践
- 前端评估:基于Web性能优化和用户体验设计原则
审查结束