在电商场景中，评论回复是商家维护用户关系、提升服务体验的核心环节，尤其是差评的及时、精准回复，直接影响品牌口碑。本文将分享我们基于大模型构建「AI 智能评论回复助手」的技术实践，从需求拆解、核心设计到工程落地，完整还原大模型在实际业务场景中的应用思路与开发细节。

一、需求背景与核心挑战

电商平台的评论具有「数量大、维度杂、情感差异显著」的特点，人工回复存在效率低、话术不统一、差评响应不及时等问题。我们希望通过大模型实现智能回复生成，但落地过程中面临几个核心挑战：

1. 场景适配性：不同品牌有不同的语气风格（如「真诚致歉」「专业解答」），回复需贴合品牌调性；
2. 内容精准性：需识别评论核心问题（如质量、物流、服务），避免回复千篇一律；
3. 工程可靠性：批量生成时需控制并发，避免打爆大模型接口，同时要有失败兜底策略；
4. 业务闭环：需支持人工审核、编辑、重生成，兼顾 AI 效率与人工把控。

针对这些挑战，我们设计了一套「评论分析 - 模板构建 - 大模型生成 - 人工审核」的全流程解决方案，核心代码覆盖 ORM 模型、服务层、接口层三个维度，实现了从数据存储到业务落地的完整闭环。

二、核心设计思路与技术实现

2.1 数据模型设计：兼顾业务属性与扩展性

首先需要设计贴合业务的 ORM 模型，支撑「回复草稿」和「品牌配置」两大核心数据存储，这是整个系统的基础。

1. 回复草稿模型（ReviewReply）

针对单条评论的回复草稿，我们不仅存储生成的内容，还记录了评论的核心特征（情感、维度、评分），避免后续反复关联查询：

class ReviewReply(Base):
    __tablename__ = "review_replies"
    id: Mapped[str] = mapped_column(String(36), primary_key=True, default=lambda: str(uuid.uuid4()))
    dataset_id: Mapped[str] = mapped_column(String(36), ForeignKey("datasets.id"), nullable=False, index=True)
    review_id: Mapped[str] = mapped_column(String(36), ForeignKey("reviews.id"), nullable=False, index=True)
    
    # 评论快照（避免join）
    review_content: Mapped[Optional[str]] = mapped_column(Text)
    rating: Mapped[Optional[int]] = mapped_column(Integer)
    sentiment: Mapped[Optional[str]] = mapped_column(String(20))  # positive/neutral/negative
    main_dimension: Mapped[Optional[str]] = mapped_column(String(20))  # 质量/物流/外观/服务/价格
    
    # 回复核心字段
    draft_content: Mapped[Optional[str]] = mapped_column(Text)  # AI生成草稿
    edited_content: Mapped[Optional[str]] = mapped_column(Text)  # 人工编辑稿
    tone: Mapped[Optional[str]] = mapped_column(String(30))  # 品牌语气
    status: Mapped[Optional[str]] = mapped_column(String(20), default="draft", index=True)  # 草稿/审核通过/驳回
    priority: Mapped[Optional[int]] = mapped_column(Integer, default=0)  # 差评优先排序

设计思考：

• 引入「评论快照」：评论数据可能被修改，快照存储避免后续关联查询的不一致性；
• 区分「draft_content」和「edited_content」：AI 生成稿与人工编辑稿分离，审核通过后以编辑稿为准，兼顾 AI 效率与人工修正；
• 优先级（priority）字段：基于情感和评分计算（差评 > 中评 > 好评，评分越低优先级越高），支持回复列表按紧急程度排序。

2. 品牌配置模型（ReplySettings）

按数据集（品牌）维度存储个性化配置，让回复贴合品牌风格：

class ReplySettings(Base):
    __tablename__ = "reply_settings"
    dataset_id: Mapped[str] = mapped_column(String(36), ForeignKey("datasets.id"), primary_key=True)
    brand_name: Mapped[Optional[str]] = mapped_column(String(100), default="")
    tone: Mapped[Optional[str]] = mapped_column(String(30), default="真诚专业")  # 语气基调
    signature: Mapped[Optional[str]] = mapped_column(String(200), default="")  # 落款
    banned_words: Mapped[Optional[str]] = mapped_column(Text, default="")  # 禁用词
    max_length: Mapped[Optional[int]] = mapped_column(Integer, default=120)  # 字数上限

设计思考：配置与数据集绑定，支持多品牌隔离；禁用词、字数上限等配置直接约束大模型生成逻辑，避免生成违规内容。

2.2 服务层核心逻辑：大模型调用的工程化封装

服务层是整个系统的核心，负责评论分析、Prompt 构建、大模型调用、批量生成控制，也是工作量投入最大的部分。

1. 评论特征分析：精准识别回复方向

首先需要对评论进行「情感分类」和「维度识别」，为 Prompt 构建提供依据：

# 复用差评归因的五维关键词，覆盖90%以上的电商评论场景
DIMENSION_KEYWORDS = {
    "quality": ["质量", "品质", "做工", "材质"],
    "logistics": ["物流", "快递", "配送", "发货"],
    "appearance": ["外观", "颜值", "颜色", "款式"],
    "service": ["客服", "服务", "态度", "售后"],
    "price": ["价格", "性价比", "划算", "贵"],
}

def detect_dimension(content: str) -> Optional[str]:
    """识别评论核心维度（命中关键词最多的维度）"""
    best, best_cnt = None, 0
    for dim, kws in DIMENSION_KEYWORDS.items():
        cnt = sum(1 for k in kws if k in content)
        if cnt > best_cnt:
            best, best_cnt = dim, cnt
    return best

def classify_sentiment(rating: Optional[float], sentiment_score: Optional[float]) -> str:
    """综合评分与情感分判定情感倾向"""
    if rating is not None:
        r = float(rating)
        if r <= 2: return "negative"
        if r >= 4: return "positive"
        return "neutral"
    # 兜底：基于情感分判断
    ...

思考与优化：

• 关键词维度复用「差评归因」成果，避免重复造轮子；
• 情感分类优先用评分（更直观），情感分作为兜底，符合电商场景的实际业务逻辑；
• 维度识别采用「关键词计数」，简单高效且准确率能满足业务需求（复杂场景可引入文本分类模型）。

2. Prompt 工程：让大模型生成贴合场景的回复

Prompt 是大模型应用的核心，我们设计了「系统指令 + 场景引导 + 用户输入」的三层 Prompt 结构，兼顾通用性与个性化：

def _build_prompt(self, review: Dict, settings: Dict) -> List[Dict]:
    brand = settings.get("brand_name") or "本店"
    tone = settings.get("tone") or "真诚专业"
    max_len = settings.get("max_length") or 120
    
    # 系统指令：定义角色、语气、规则
    sys = (
        f"你是「{brand}」的金牌电商客服，负责撰写公开的商家回复。"
        f"语气基调：{tone}。回复要求：真实、得体、不卑不亢，控制在{max_len}字以内。"
    )
    # 禁用词约束
    if settings.get("banned_words"):
        sys += f" 严禁出现以下词语：{settings['banned_words']}。"
    
    # 场景引导：按情感差异定制回复逻辑
    sentiment = review.get("sentiment")
    if sentiment == "negative":
        guide = f"这是一条差评，核心问题集中在「{DIM_CN.get(review.get('main_dimension'))}」。请先共情致歉，再给出具体改进方案，并引导私下联系客服。"
    elif sentiment == "neutral":
        guide = "这是一条中评，请感谢反馈，正面回应顾虑，表达改进意愿。"
    else:
        guide = "这是一条好评，请热情感谢，强化品牌好感，邀请复购。"
    
    # 用户输入：评论内容
    user = f"{guide}\n\n顾客评论（{review.get('rating')}星）：\n{review.get('content')[:400]}"
    
    return [
        {"role": "system", "content": sys},
        {"role": "user", "content": user},
    ]

Prompt 设计思考：

• 角色定义清晰：明确「金牌电商客服」身份，让回复更贴合场景；
• 个性化注入：品牌名、语气、禁用词、字数上限等配置动态融入，避免硬编码；
• 场景化引导：差评强调「共情 + 解决方案」，中评强调「感谢 + 改进」，好评强调「感谢 + 复购」，符合电商回复的业务逻辑；
• 长度限制：截断超长评论（400 字），避免 Prompt 过长影响生成效果。

3. 大模型调用：并发控制与失败兜底

批量生成时需控制并发，避免大模型接口过载，同时设计兜底模板，保证服务可用性：

# 并发上限，避免瞬时打爆LLM
_SEM = asyncio.Semaphore(5)

async def generate_one(self, review: Dict, settings: Dict, llm_client) -> Dict:
    messages = self._build_prompt(review, settings)
    draft = ""
    try:
        async with _SEM:
            # 调用大模型异步接口，控制温度（0.6）保证回复稳定性
            draft = await llm_client.achat(messages, temperature=0.6, max_tokens=400)
        draft = draft.strip().strip('"')  # 清洗生成结果
    except Exception as e:
        logger.warning(f"回复生成失败 review_id={review.get('id')}: {e}")
        # 失败兜底：按情感返回通用模板
        if review.get("sentiment") == "negative":
            draft = "非常抱歉给您带来不好的体验，我们已记录问题并会尽快改进，烦请联系客服处理。"
        elif review.get("sentiment") == "positive":
            draft = "感谢您的认可！我们会继续努力，期待再次为您服务。"
        else:
            draft = "感谢您的反馈，我们会持续优化，欢迎随时联系客服。"
    return {"review_id": review.get("id"), "draft_content": draft, ...}

async def generate_batch(self, reviews: List[Dict], settings: Dict, llm_client) -> List[Dict]:
    """批量并发生成，基于asyncio.gather实现"""
    tasks = [self.generate_one(r, settings, llm_client) for r in reviews]
    return await asyncio.gather(*tasks)

工程化思考：

• 并发控制：使用asyncio.Semaphore限制并发数（5），适配大模型接口的 QPS 限制；
• 失败兜底：异常时返回通用模板，避免单个评论生成失败导致批量任务中断；
• 温度控制：temperature=0.6，平衡回复的多样性与稳定性（电商回复需规范，不宜过于随机）；
• 结果清洗：去除生成结果的引号、多余符号，提升用户体验。

2.3 接口层：构建完整的业务闭环

接口层基于 FastAPI 实现，覆盖「批量生成、单条重生成、人工审核、配置管理」等核心功能，支撑前端交互：

# 批量生成接口（异步任务）
@router.post("/generate/{dataset_id}")
async def generate_replies(
    dataset_id: str,
    body: GenerateBody,
    background_tasks: BackgroundTasks,
    db: AsyncSession = Depends(get_db),
):
    # 1. 创建任务记录（用于进度跟踪）
    task_id = str(uuid.uuid4())
    task = AnalysisTask(id=task_id, dataset_id=dataset_id, task_type="reply", status="pending")
    db.add(task)
    await db.commit()
    # 2. 后台执行生成任务（避免接口阻塞）
    background_tasks.add_task(_run_generate, task_id, dataset_id, body.only_negative, body.limit)
    return ok({"task_id": task_id, "status": "pending"})

# 人工审核/编辑接口
@router.patch("/{reply_id}")
async def patch_reply(reply_id: str, body: PatchBody, db: AsyncSession = Depends(get_db)):
    row = (await db.execute(select(ReviewReply).where(ReviewReply.id == reply_id))).scalar_one_or_none()
    if not row:
        return {"code": 404, "message": "回复记录不存在"}
    # 更新人工编辑内容、审核状态、审核人
    if body.edited_content is not None:
        row.edited_content = body.edited_content
    if body.status is not None:
        row.status = body.status
    await db.commit()
    return ok(_serialize(row))

接口设计思考：

• 异步任务：批量生成接口采用后台任务（BackgroundTasks），避免长耗时操作阻塞接口；
• 进度跟踪：引入内存级进度字典 + 数据库任务表，支持前端查询生成进度；
• 业务闭环：支持单条重生成、人工编辑、审核状态修改，满足实际运营需求；
• 分页查询：回复列表支持按状态、情感筛选，按优先级排序，提升运营效率。

三、核心亮点与工程化考量

3.1 大模型应用的工程化落地

1. 并发控制：通过信号量限制并发数，避免大模型接口过载；
2. 失败兜底：异常时返回通用模板，保证服务可用性；
3. 数据隔离：按数据集（品牌）隔离配置和回复，支持多租户；
4. 性能优化：评论快照避免反复关联查询，索引优化查询效率。

3.2 业务与技术的结合

1. 优先级排序：基于情感和评分计算优先级，优先处理差评，符合电商运营逻辑；
2. 个性化配置：品牌名、语气、禁用词等配置让回复更贴合品牌风格；
3. 人工介入：AI 生成 + 人工审核的模式，兼顾效率与风险控制。

3.3 可扩展性设计

1. 维度关键词可配置：DIMENSION_KEYWORDS 可扩展更多维度（如「体验」「功能」）；
2. Prompt 模板可扩展：支持自定义指令（custom_instructions），满足特殊品牌的需求；
3. 模型替换兼容：llm_client 封装为抽象接口，可无缝替换为不同的大模型（如 GPT、文心一言、通义千问）。

四、总结与后续规划

本次 AI 智能评论回复助手的开发，核心是将大模型能力与电商评论回复的业务场景深度结合，从「数据模型 - 服务层 - 接口层」三层架构出发，解决了大模型应用落地的适配性、可靠性、业务闭环等核心问题。整个开发过程中，我们投入的核心工作量包括：

1. 业务需求拆解与数据模型设计（约 2 天）；
2. 评论分析与 Prompt 工程（约 3 天，反复调试 Prompt 模板以提升生成效果）；
3. 大模型调用的工程化封装（并发控制、失败兜底，约 2 天）；
4. 接口层开发与业务闭环（批量生成、审核、配置，约 3 天）；
5. 测试与优化（边界场景测试、性能优化，约 2 天）。

五、总结思考

大模型的落地不是简单的 API 调用，而是「业务理解 + Prompt 工程 + 工程化封装 + 业务闭环」的综合能力体现。只有深入理解业务场景，才能让大模型真正发挥价值，解决实际问题。