AI 落地项目集：同一套技术栈，如何适配不同业务

这些 AI 落地项目——匿名好声音、AI 月老、智能穿搭、今天吃啥、AI 猎头、AI 导购、AI 采购——底层工程套路高度一致：把一份真实业务数据接进模型，再用约束把模型管住，最后以对话或推荐的方式交付。差异不在技术栈，而在业务约束的写法：哪类数据能进模型、哪些条件必须硬过滤、哪些决策必须留人工。本文先把共性架构抽出来讲清楚，再按「社交娱乐 / 生活助手」与「企业业务」两条线看项目差异。

一、共性架构：一套 AI 落地管线的四段式

这七个项目可以统一归纳成「数据 → 模型 → 交互 → 落地约束」四段式，顺序几乎不可颠倒。

1. 数据段：候选必须来自真实库，而不是让模型凭空编

所有项目都强调「候选来自真实门店库 / 简历库 / 商品库 / 衣柜库 / 供应商库」。模型不允许举出不存在的店、货号或 SKU——这是落地与「聊天玩具」的分界线。没有真实数据时，系统只能做文档问答或聊天玩意，不要当产品主路径。

2. 模型段：硬过滤在前、向量召回在中、生成式解释在后

这是一个反复出现的三层结构：

• 硬过滤（检索层）：年龄、地域、已婚、预算上限、资质白名单、库存状态等确定性条件，必须在 SQL / 索引 / 规则引擎里落地，不要交给 LLM 自由发挥。
• 向量召回：用户画像、简历、商品做 embedding，做相似匹配与候选集生成。
• 生成式解释：最后才用大模型把结果汇总成口语点评、开场建议或推荐理由，并标明「为什么匹配 / 还缺什么」。

三个容易踩的坑

• 把硬条件写进提示词而不是检索层：模型会自由发挥，年龄、资质这类底线条件一旦被它绕过就是合规事故。
• 只做向量相似不做结构化：词汇相近但职能 / 品类不符的候选会被推上来，必须主结构化字段再召回。
• 让模型直接做终局决策：匹配、询价、点评可以给，但「是否录用 / 自动下单 / 改金额」一定要留人工。

3. 交互段：对话式收集约束，缺一项就追问

导购、穿搭、点餐这类项目，模型要先问清场景、预算、尺寸、忌口，缺一项就追问，不要直接甩推荐。把「再来一家 / 不喜欢」当成显式反馈，用来打压近期重复推荐。

4. 落地约束段：合规、隐私与离线评估

几乎每个项目都点名了同类约束：去标识化、不展示真实隐私字段、对话默认审核、模型不输出歧视性或负面定论、不替代专业人工（录音师 / 营养师 / 心理咨询师 / 背调 / 法律）、上线前用历史数据做离线评估。

什么时候用这套架构：凡是「有大量结构化业务数据 + 需要自然语言交互 + 决策有强约束」的场景都适用；纯创意生成或不存在真实数据源的场景不适合。

二、社交娱乐与生活助手：差异在「隔离」与「约束写法」

这一组（匿名好声音、AI 月老、智能穿搭、今天吃啥）面向 C 端，难点在身份隔离、版权与个性化约束，模型输出只是建议。

匿名好声音：把「身份隔离」落到媒资层

链路是：上传音频 → 声纹拓扑或变声 → 歌词对齐与歌唱打分模型 → 大模型生成点评与改进建议。匿名的关键是声纹与账号解耦、平台不存原声、评委侧只见化后音频。还要防止用已发行歌曲干扰排行，以及用 TTS 冒充人声。

• 隔离要落在媒资层：原始 WAV 加密存储，对外播放只出变声或噪声混合后的文件，评委与模型都不拿原声。
• 打分拆成可解释维度：音高稳定性、节拍、气息位置、歌词错字率，再由 LLM 汇总成口语点评，避免只输出一个迷信的分数。
• 做假与版权检测：声纹对比已知歌手、音频指纹对比版权库，异常直接打回。

适用：社交娱乐、校园活动或内部文娱比赛；正式音乐制作流水线不要用它替代录音师。上线前必须先定匿名策略与媒资保留期限。

AI 月老：把相亲变成可解释的匹配管线

输入是自述、偏好、生活方式和互动记录，输出是候选集加理由，而不是一个打分。技术上把用户画像做 embedding，再用规则过滤年龄、地域、底线条件，最后用大模型根据双方谈话生成开场建议与风险提示。最容易出问题的是把歧视写进提示词，或用聊天记录做训练数据却不去标识。

• 硬过滤在前、向量召回在中、生成式解释在后：年龄距离、异地、已婚等条件不要交给模型自由发挥。
• 画像要可更新：用户改偏好后重新编码，不要永久用注册时的一句话做匹配。
• 安全与合规：不展示真实手机号，对话默认审核，禁止模型输出得分排名或对某类人群作负面定论。

适用：社交产品推荐导流、社群活动搭档或企业内部「兴趣匹配」；不能替代心理咨询或婚恋法律建议。上线前用历史成功 / 失败案例做离线评估。

智能穿搭：推荐必须指向库内 SKU

要把衣柜、场景和身形约束连在一起，给出可上身的搭配方案而不是漂亮的描述。视觉模型负责分类与属性抽取（版型、色彩、材质），规则引擎负责色彩冲突、场合忌讳，大模型负责生成穿搭说明和替换建议。最容易失败的点是库存里没有这件衣服，模型却派了一套「应该买」的清单。

• 先建衣柜图谱：每件衣服要有图像、类目、色板和可穿季节，推荐必须指向库内 SKU，不能只输出文字。
• 场景约束写成硬规则：面试不推准则鞋、暴雨不推羽绒、运动不推牛仔裤，LLM 只在规则通过后做风格润色。
• 用图生成要标注是效果图不是实拍：避免用户把虚拟试穿当成物理尺寸。

适用：电商衣柜管理、线下门店搭配师助手或出行装口袋；高定制时装仍要人工面诊。上线前用真实衣柜做拓扑测试。

今天吃啥：带约束的推荐，记忆要分个人与家庭

看似随便，其实是带约束的推荐：口味、预算、距离、饮食忌口、打卡优惠和上一餐都要进模型。单纯让 LLM 胡猜会重复推火锅、忽略用户不吃香菜。可落地做法是先拉附近门店与菜品库，用规则过滤运费与忌口，再用历史点单做召回，最后让模型写推荐理由，并把「再来一家」当显式反馈打压重复。

• 候选必须来自真实门店库，且带营业时间与配送范围，模型不允许举不存在的店。
• 约束写进检索过滤而不是只写进提示词：香菜、辣、预算上限要在 SQL / 索引里落地。
• 记忆最近 N 餐和家庭成员偏好：个人推荐和家庭推荐要用不同画像，避免把辣的推给全家。

适用：小程序、企业点餐或外卖入口；不适合替代营养师的长期食谱。没有门店数据时只能做聊天玩意。

三、企业业务：差异在「强约束」与「审计留痕」

这一组（AI 猎头、AI 导购、AI 采购）面向 B 端，决策有强合规约束，模型只给建议、终局动作必须有人工审批与审计。

AI 猎头：把 JD、简历、面试记录连成可跟踪管线

输入是 JD 与候选人库，输出是带理由的短名单而不是「是否录用」的终裁。典型步骤：解析 JD 必选技能与加分项、把简历切块入向量库、用规则过滤年资与地域、再用模型对比缺口并生成面试题。最大风险是歧视被写进提示词，以及把候选人隐私字段送进公有模型。

• 硬条件在检索层落地：工作证、城市、年资下限不要交给 LLM 自由发挥。
• 简历解析要主结构化字段：企业、职务、技能栈、项目成果；只做向量相似会把词汇相近但职能不符的人推上来。
• 模型只说明「为什么匹配」和「还缺什么」，联络方式与评价保留在人工，评估用历史录用结果做离线指标。

适用：招聘团队海量简历初筛、找类似成功案例的候选人；不能替代面试与背调。没有 JD 模板和简历库时不要上线，上线前要有明确的去标识化与不歧视检查。

AI 导购系统：能下单的助手，不是读详情页的机器人

要在用户进店后把需求识别、商品召回、对比与下单助手连起来，能问清场景、预算和念想。技术上常用商品知识库做 RAG，用属性过滤做 SKU 约束，用工具调用查库存与佣金。最容易失败的是推了缺货商品、或模型编出不存在的 SKU。

• 候选必须来自在售库存，价格与促销也要实时拉，模型不允许举不存在的货号。
• 对话要先收集约束：尺寸、色系、预算、送货时间，缺一项就追问，不要直接滤屏推荐。
• 跑回路径要可跳详情与加购车：只有文字推荐而不能下单的导购不是完成产品。

适用：电商客服、门店导购屏和企微商城；高价值定制仍要人工师傅。没有标准 SKU 库与库存接口时先不要做自动下单。上线后跟踪转化率与退货原因。

AI 采购系统：强约束下的对比，不自动下单

要把请购单、供应商库、合同条款和历史价格连起来，帮采购员对比方案而不是自动下单。典型流程：解析请购物料与规格、在合规供应商里召回、按交期与价格排序、生成询价对比表与风险提示。它和电商导购的区别在于强约束：没有资质的供应商不能出现，超预算要审批。模型只能读合同摘要与历史订单，不能直接改金额。

• 供应商白名单和品类授权是第一道门，检索不能越过资质与合约状态。
• 对比要带条款来源：交期、账期、质保、运费；只比单价会导致隐藏成本。
• 人工审批不能省：模型生成询价建议与资料清单，下单仍走 ERP 原流程，每次推荐都要留审计。

适用：企业采购面临多品类、多供应商的重复对比；不能替代招标法律与内部控制。没有供应商主数据和历史订单时只能做文档问答。

附：项目选型与共性约束速查表

贯穿所有项目的三条底线：硬条件必须落在检索层而非提示词；隐私字段去标识、不进公有模型；模型只给建议，终局决策（录用 / 下单 / 改金额）必须有人工与审计。