one-week-demo-requirements-and-schedule.md 9.4 KB

提号 AI 1.0 Demo 需求表与工期评估

更新时间:2026-05-12

1. 版本目标

1.0 Demo 的目标不是一次性做完整系统,而是在 1 周左右跑通最小闭环:

上传 / 输入 Brief -> AI 解析需求 -> 调用本地资源库和外部达人数据源 -> 生成推荐媒体名单 -> 支持表格查看和下载 -> 业务同事可试用并反馈。

本版本优先验证:

  • 这个流程对商务同事是否有用。
  • 本地资源库和外部供应商数据是否能对得上。
  • 外部 API 是否能稳定支持“按需求找博主”。
  • AI 解析 Brief 和推荐理由是否能达到业务可复核程度。

2. 1.0 Demo 范围

2.1 必须完成

模块 功能内容 1.0 完成标准 备注
Brief 输入 支持上传 Brief 文件或粘贴 Brief 文本 能提交客户需求,进入 AI 解析流程 文件解析可先简化,必要时先支持文本粘贴
AI 需求解析 提取品牌、品类、平台、关键词、预算、数量、城市、达人类型、排除项 页面展示结构化解析结果,可人工确认或简单修改 使用公司现有 AI 模型
本地资源库接入 导入或读取客户提供的优秀资源表 / 打包表格 能按账号 ID、昵称、平台、关键词等字段做匹配和补充 不直接让 AI 读取整张大表,先入库或结构化缓存
外部数据源接入 接入 Just One 等外部达人搜索 API 能根据 Brief 条件召回候选博主 优先小红书 / 抖音,按已开通账号能力决定
内容采样验证 接入 TikHub 或同类接口做基础内容采样 能补充近期内容、账号活跃、风格判断所需字段 1.0 可先做轻量版,不追求完整评论 VOC
候选融合 合并本地资源库和外部候选 同一账号可识别去重,本地已有账号优先补联系方式 / 优惠政策等内部字段 本地资源库是优先推荐资产
推荐评分 根据 Brief 条件、预算、平台、标签、地域、报价、历史资源标记生成排序 能输出可解释的推荐顺序和推荐理由 1.0 规则可先固定,不做复杂规则中心
推荐名单页 展示推荐账号表格 包含账号名、平台、主页/ID、粉丝、报价、地域、标签、来源、推荐理由、风险提示 字段以可复核为主
Excel 下载 导出推荐名单 商务可下载表格用于内部沟通或客户初稿 样式可简单
基础日志 记录每次 Brief、查询条件、外部 API 返回状态、生成结果 便于排查供应商接口和推荐问题 不做完整审计系统

2.2 暂不纳入 1.0

暂不做内容 原因
完整 OA 数据库深度对接 OA 数据结构包含供应商、联系方式、结算等复杂关系,1.0 先用资源表/轻量库验证流程
完整规则库沉淀 1.0 先跑通推荐闭环,规则沉淀放到后续版本
完整客户反馈学习 先人工收集试用反馈,后续再做反馈转规则
完整权限体系 Demo 阶段可用简单登录或内网访问
多角色工作流 1.0 聚焦商务试用,不做复杂审批流
复杂页面和高级交互 页面可以简单,只要流程能跑
全量评论 VOC 分析 成本和稳定性较高,先做内容风格和近期表现验证
完整供应商监控平台 先记录日志,后续再做可视化监控

3. 需求与工期表

口径说明:

  • 评估按“普通中级工程师”估算。
  • 按完整 1.0 Demo 基准估算约 16 人天。
  • 如果必须 1 周交付,建议 2 人并行投入,并通过裁剪深度采样、页面细节和异常处理压缩到约 14 人天。
  • 如果由非常熟悉公司 AI 模型、TikHub、后端框架的同学主导,实际开发时间可能低于该估算。
序号 工作项 具体内容 输出物 估算人天 负责人建议
1 需求冻结与接口确认 确认 1.0 只做一个工作台闭环;确认 Brief 样例、资源表样例、Just One / TikHub 账号、服务器信息 1.0 范围清单、字段清单、接口账号准备清单 0.5 产品 / 技术负责人
2 环境与项目部署准备 云服务器、Node/后端服务、前端部署方式、环境变量、密钥配置 可部署的测试环境 1 后端
3 数据库 / 结构化缓存设计 设计 Brief、任务、资源库账号、外部候选、推荐结果、接口日志等基础表 Demo 版数据库表或结构化存储 1 后端
4 本地资源库导入 将客户提供的小红书 / 抖音等资源表统一字段,导入轻量库;处理模板不一致问题 本地资源库导入脚本或后台导入接口 2 后端
5 本地资源库检索 按平台、账号 ID、昵称、关键词、标签、报价、城市等字段检索本地账号 本地资源召回接口 1 后端
6 AI Brief 解析 对接公司 AI 模型,输出结构化需求字段;支持失败兜底和人工修改 Brief 解析接口、结构化结果 1.5 AI / 后端
7 Just One 外部召回 对接外部达人搜索 API,按关键词、平台、预算、标签等条件召回候选 外部候选召回接口 1.5 后端
8 TikHub 内容采样 对候选账号做基础近期内容采样,用于活跃度和风格判断 内容采样接口、采样结果字段 1.5 后端
9 候选融合与去重 合并本地资源库和外部候选;识别同平台同账号;本地字段优先补充联系方式、优惠政策等 统一候选池接口 1 后端
10 推荐评分与排序 基于 Brief 条件、预算、平台、标签、地域、来源可信度、本地优先级生成排序和推荐理由 推荐结果生成接口 1.5 后端 / AI
11 工作台前端 一个页面完成 Brief 输入、解析确认、开始推荐、进度展示、推荐结果表格 1.0 Demo 工作台页面 2 前端
12 推荐名单导出 支持 Excel / xls 下载,包含客户可看的核心字段 推荐名单下载文件 0.5 前端 / 后端
13 联调与试跑 用 2-3 个真实 Brief 跑通完整流程,记录接口问题、字段缺失、推荐跑偏点 联调问题清单、可试用 Demo 1 全员

基准合计:约 16 人天。

压缩到 1 周交付的处理方式:

  • 两人并行开发,后端优先打通接口,前端先接 Mock 再换真实接口。
  • 1.0 只做一个工作台,不做完整后台管理。
  • 本地资源库先支持固定模板或少量样例表,不处理所有历史表格差异。
  • 推荐评分先用固定规则 + AI 推荐理由,不做复杂可配置规则中心。
  • TikHub 内容采样先做基础字段,不做深度评论 VOC。
  • 如工期被卡死在 7 天内,TikHub 可先只做账号近期内容基础采样,评论采样和 VOC 判断顺延到 2.0。

4. 7 天排期建议

日期 重点工作 当天验收
Day 1 冻结 1.0 范围;确认 Brief 样例、资源表、API key、服务器;完成数据表设计 能明确输入、输出字段和接口清单
Day 2 本地资源库导入和检索;前端工作台骨架 能从本地库查到候选账号
Day 3 AI Brief 解析;Just One 外部召回 能从 Brief 解析出条件,并用外部 API 召回候选
Day 4 TikHub 内容采样;候选融合去重 能合并本地和外部候选,补近期内容字段
Day 5 推荐评分、推荐理由、结果表格 能生成可查看的推荐名单
Day 6 Excel 下载、异常处理、接口日志、页面细节 商务可下载名单,问题可追踪
Day 7 真实 Brief 试跑、修复关键问题、整理试用说明 交付可试用 Demo 和已知问题清单

5. 1.0 验收标准

  1. 商务能输入或上传一个 Brief。
  2. 系统能解析出核心需求字段,并允许人工确认。
  3. 系统能同时查询本地资源库和至少一个外部达人数据源。
  4. 本地资源库中已有账号能被识别并优先补充内部字段。
  5. 系统能生成一份推荐媒体名单,包含推荐理由和风险提示。
  6. 推荐名单能下载为表格。
  7. 至少 2 个真实 Brief 能跑完整流程。
  8. 外部 API 的失败、余额不足、字段缺失等情况有日志可查。

6. 客户需提前准备

资料 / 账号 用途 期望时间
2-3 个真实 Brief 用于开发联调和验收试跑 Day 1 前
本地优秀资源表 / 打包表格 用于导入本地资源库 Day 1 前
字段说明 说明资源表中账号 ID、昵称、平台、报价、联系方式、优惠政策等字段含义 Day 1 前
Just One API 账号 外部商业达人召回 Day 1 前
TikHub API 账号 内容采样验证 Day 1 前
云服务器或测试环境 部署 Demo Day 1 前
公司 AI 模型调用方式 Brief 解析和推荐理由生成 Day 1 前

7. 后续 2.0 方向

  1. 完整规则库:把人工经验、客户反馈、排除项沉淀为可启停规则。
  2. 完整 OA 对接:同步供应商、联系方式、合作状态、结算、黑名单等内部字段。
  3. 多供应商适配:Just One、TikHub、KOLRank、官方蒲公英 / 星图等统一适配。
  4. 反馈学习:客户反馈自动提炼为待确认规则。
  5. 数据质量监控:监控外部 API 成功率、余额、字段覆盖率、推荐采纳率。
  6. 客户版 / 内部版名单:区分对客推荐理由和内部风险复核字段。