很多团队接到“用 AI 优化电商标题”的需求时拿到的原始描述往往只有一句话“你是一位专业的标题优化师需根据用户提供的原始标题严格遵循指定规则生成一个全新、合规、高质量的中文电商标题。”这句话本身没有错。但如果你真的把它原封不动丢给大模型结果大概率是标题看起来通顺却可能踩中平台规则和广告法红线或者关键词堆砌导致搜索降权又或者长度超限、符号混乱根本没法直接使用。问题不在于“让 AI 写标题”这个方向而在于提示词只定义了角色没有定义输入结构、规则参数和输出校验。换句话说它只是一个起点不是一个可落地的方案。这篇文章就从这类真实需求出发把一句提示词扩展成一套完整可运行的电商标题优化系统。我会先拆解“一个合格电商标题”到底由什么组成再讲清楚系统模块如何划分、提示词该怎么设计最后用 Python FastAPI 给出一份可以直接修改投产的代码实现并补充合规校验、质量评分、常见问题和生产环境最佳实践。读完你可以得到三样东西一份能跑通的标题优化服务代码一套判断“AI 结果行不行”的校验思路以及关于如何安全上线这类工具的方法论。1. 电商标题优化为什么值得做成系统先看一个常见的运营场景。商家上架一款连衣裙原始标题可能只是“女装连衣裙夏季新款”。运营同学需要根据商品属性、搜索热词、平台规则把它优化成既能被搜索命中、又具备可读性和转化力的标题。这件事人工做效率很低。一个运营每天面对几十上百个 SKU每个标题都要反复斟酌关键词顺序、字数、卖点优先级很难保证标准一致。更麻烦的是不同平台对标题长度、特殊符号、关键词堆砌的判断规则不一样人工记忆成本极高。用大模型生成标题能解决“写得出来”的问题但解决不了“写得对不对”的问题。模型训练数据里的电商标题五花八门它很可能给你生成一个包含“全网最低”“顶级品质”的标题——这些词在广告法语境下是明确的合规风险。所以值得做成系统的原因有三点标准统一。同一个商品无论谁提交请求输出的标题都要符合同一套规则。合规可控。通过代码层面的校验可以在模型输出之后再做一层拦截避免违规词直接流出。可度量。标题质量不能再靠“感觉还行”而是要用关键词覆盖率、长度合理性、信息增益这些指标打分。这篇文章更偏向后端开发者和运营工具开发者。如果你正在搭建商品管理后台、电商自动化工具或者想把大模型能力接入运营工作流这篇文章的代码和思路可以直接参考。2. 一个合格电商标题的组成与规则在写代码之前先明确标准。很多开发同学对电商标题的理解是“把关键词拼在一起”这是最大的误区。一个真正合格的电商标题是在平台规则和合规红线之间平衡搜索相关性与用户可读性的结果。2.1 标题的四个要素电商标题虽然看起来只是一段文本但内部有清晰的信息层次要素作用示例核心商品词告诉搜索引擎“你卖的是什么”必须保留连衣裙属性词描述材质、款式、版型提升匹配精度法式碎花、收腰、中长款场景词说明使用场景或季节扩大长尾流量夏季、约会、通勤营销词突出卖点或人群但必须真实合规显瘦、新款核心商品词是标题的“锚”。模型可以调整它的位置但不能把它丢掉更不应该替换成另一个类目的词否则会误导搜索和用户判断。2.2 平台规则与合规约束平台规则是标题优化里最容易被忽略的部分。不同平台对标题的字符数限制不同一般电商平台标题会控制在 30 个字符左右部分平台允许 60 个字符。超出长度轻则截断展示重则无法保存。特殊符号也需要关注。很多平台不允许标题里出现感叹号、括号、星号等符号因为这些字符会被搜索引擎特殊处理也可能被判定为恶意堆砌。更关键的是合规问题。广告法对极限词有明确约束“最”“第一”“顶级”“国家级”“全网唯一”这类词在商品标题里使用风险很高。实际开发中需要一个可维护的禁用词库并且要能处理“最新款”“最近”这类包含“最”但不是极限词的场景。2.3 容易被忽略的质量维度合规校验通过不代表标题质量高。真正的好标题还要满足三点搜索相关性。用户搜索“碎花连衣裙”你的标题里就要出现这个词而不是只写“法式长裙”。可读性。标题应该像一句顺畅的短语而不是关键词的无脑堆砌。堆砌关键词会在部分平台触发降权。信息密度。同样的 30 个字覆盖的属性信息越多获取流量的机会越大。这就是为什么系统里不能只有生成模块还要有校验模块和评分模块。3. 系统整体设计从提示词到服务把一句话扩展成服务核心是拆解流程。整个标题优化链路可以分成五步接收请求原始标题、类目、属性、关键词、平台规则。组装提示词把请求内容和规则动态注入预设模板。调用大模型获得候选标题。合规校验检查长度、禁用词、特殊符号。质量评分计算关键词覆盖率、长度合理性、信息增益。模块划分清晰之后每个模块都独立可测替换成本也低。比如今天用 A 模型明天想换 B 模型只需要改调用层不需要动提示词和校验逻辑。这里有一个容易踩的坑很多人把合规校验放在提示词里指望模型自己守住底线。但大模型的输出本质是概率性的今天不违规不代表明天不违规。所以一定要把合规校验作为模型输出后的强制拦截层用确定性规则兜底。同样也不要让模型自己给自己打分。模型对“标题是否够好”的判断不稳定远不如通过关键词覆盖率、字长分布这些客观指标来计算评分。4. 提示词工程定义一个真正可执行的“标题优化师”如果你只是告诉模型“你是标题优化师”模型并不知道你的平台限制、禁用词列表、输出格式要求。提示词的本质是把业务规则翻译成模型能理解并执行的语言。4.1 提示词不是越长越好提示词过长模型会丢失部分约束提示词过短输出不可控。比较好的结构是角色定义。任务说明。硬性规则。参考示例。输入数据。硬性规则要尽可能可验证。不要说“标题要高质量”要说“标题长度不超过 30 个字符”“不得使用以下禁用词”“只输出标题本身”这样后续代码才能校验模型是否真的遵守了。4.2 完整提示词模板下面是一个可以直接使用的提示词模板# prompts.py SYSTEM_PROMPT_TEMPLATE 你是一位专业的电商标题优化师拥有多年电商运营和搜索排序优化经验。 你的任务根据用户提供的原始标题、商品类目、属性、目标平台规则和核心关键词生成一个全新、合规、高质量的中文电商标题。 你必须遵守以下规则 1. 保留核心商品词不得随意替换商品类目词。 2. 标题长度不超过 {max_length} 个字符推荐控制在 {prefer_length} 字左右。 3. 禁止使用以下极限词或违规词{disallowed_words}。 4. 不得堆砌同义关键词不得使用虚假或夸大宣传词汇。 5. 标题需要兼顾搜索相关性与可读性核心词尽量靠前属性词按重要程度排列。 6. 不使用全角特殊符号、表情符号或乱码字符。 7. 只输出标题本身不要输出任何解释、序号、引号或前缀。 参考示例 原始标题女装连衣裙夏季新款 商品类目连衣裙 商品属性法式碎花、收腰、显瘦、中长款 目标平台淘宝 优化标题法式碎花收腰连衣裙女夏新款显瘦中长款 请开始处理下面的商品。 USER_PROMPT_TEMPLATE 原始标题{original_title} 商品类目{category} 商品属性{attributes} 目标平台{platform} 核心关键词{keywords} 请生成优化后的标题。注意参考示例很重要。模型对规则的遵守能力很大程度上依赖示例传递的模式。示例尽量选一个典型的“属性词前置 核心商品词保留 场景词补充”的结构模型会倾向于模仿这种风格。4.3 输出格式为什么要约法三章提示词里有一条容易被忽略只输出标题本身。如果你不限制这一点模型很可能会输出“优化后的标题是……”或者用引号包裹标题这会给后续处理带来麻烦。在代码层我们还要做好兜底。即使提示词说了不要引号实际返回时依然可能出现引号所以调用完成后要做一次字符串清理再进入校验模块。5. 环境准备与项目结构了解了设计思路下面进入实操。我会使用 Python 3.10 及以上版本技术栈如下FastAPI提供 HTTP 接口。httpx调用大模型 Chat Completion 接口。pydantic请求参数校验。uvicorn本地启动服务。大模型接口采用 OpenAI 风格的 Chat Completions 协议。如果你使用的是国内可正常访问的大模型服务只需要把base_url和model换成服务商提供的对应值其他逻辑不变。项目目录结构如下title-optimizer/ ├── config.py ├── prompts.py ├── llm_client.py ├── validator.py ├── scorer.py ├── main.py └── requirements.txt安装依赖pip install fastapi uvicorn httpx pydantic6. 核心代码实现下面按照模块逐个实现。先看配置模块它负责统一管理环境变量和业务参数。6.1 配置与提示词模板# config.py import os # 大模型接口配置兼容 OpenAI 风格接口 LLM_API_KEY os.environ.get(LLM_API_KEY, ) LLM_BASE_URL os.environ.get(LLM_BASE_URL, https://api.openai.com/v1) LLM_MODEL os.environ.get(LLM_MODEL, gpt-4o-mini) LLM_TEMPERATURE float(os.environ.get(LLM_TEMPERATURE, 0.7)) # 电商平台标题限制按需调整 TITLE_MAX_LENGTH int(os.environ.get(TITLE_MAX_LENGTH, 30)) TITLE_PREFER_LENGTH int(os.environ.get(TITLE_PREFER_LENGTH, 26)) # 默认禁用词实际项目请结合广告法合规词库完善 DISALLOWED_WORDS [ 最, 第一, 顶级, 极致, 全网, 国家级, 世界级, 最佳, 独一无二, 仅此一家, 绝无仅有, 销量第一, ]这里有一个关键设计把禁用词独立成配置。因为一旦合规要求更新你只需要修改配置并重新发布不需要改动生成和校验逻辑。LLM 调用层使用 httpx主要避免绑定某个厂商的 SDK# llm_client.py import httpx from config import LLM_API_KEY, LLM_BASE_URL, LLM_MODEL, LLM_TEMPERATURE def call_chat_completion(system_prompt: str, user_prompt: str) - str: 调用大模型 Chat Completion 接口返回纯文本结果。 if not LLM_API_KEY: raise RuntimeError(未设置 LLM_API_KEY 环境变量) payload { model: LLM_MODEL, messages: [ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ], temperature: LLM_TEMPERATURE, } with httpx.Client(timeout60) as client: resp client.post( f{LLM_BASE_URL}/chat/completions, headers{Authorization: fBearer {LLM_API_KEY}}, jsonpayload, ) resp.raise_for_status() data resp.json() return data[choices][0][message][content].strip()调用失败时resp.raise_for_status()会抛出异常上层可以根据错误码决定重试还是降级。6.2 合规校验模块合规校验是整个系统的安全底线。这里的职责不是判断标题好不好而是判断标题能不能用。# validator.py import re from config import DISALLOWED_WORDS, TITLE_MAX_LENGTH # 常见全角/半角特殊符号可按平台规则继续扩充 SPECIAL_SYMBOLS re.compile( r[!#$%^*()_\[\]{}|\\;:\?/。、“”‘’【】] ) def check_disallowed_words(title: str) - list[str]: 检查是否命中极限词/违规词返回命中的词列表。 hits [] for word in DISALLOWED_WORDS: if word in title: hits.append(word) return hits def check_length(title: str, max_length: int TITLE_MAX_LENGTH) - bool: 检查标题长度是否符合平台限制。 return len(title) max_length def check_special_symbols(title: str) - bool: 检查标题中是否出现特殊符号。 return SPECIAL_SYMBOLS.search(title) is None def validate_title(title: str) - dict: 执行全套规则校验返回结构化校验结果。 disallowed check_disallowed_words(title) return { is_valid: ( not disallowed and check_length(title) and check_special_symbols(title) ), length: len(title), max_length: TITLE_MAX_LENGTH, disallowed_word_hits: disallowed, has_special_symbols: not check_special_symbols(title), }这个模块有一个需要运维同学注意的地方“最”字在真实场景里会被“最近”“最新款”误伤。实际项目中不要直接做字符串包含判断建议引入分词或自定义白名单例如“最新”和“最近”不作为违规词处理。这里为了演示逻辑保留最简实现。6.3 质量评分模块评分模块负责回答“这个标题质量怎么样”。我们用三个客观指标计算综合得分核心关键词覆盖率关键词命中的比例。长度合理性太短信息量不足太长可能超限或堆砌。信息增益优化后的标题是否保留了原始标题的核心词。# scorer.py from typing import Iterable def score_title( title: str, original_title: str, keywords: Iterable[str], max_length: int 30, ) - dict: 从关键词覆盖、长度合理性、信息增量三个角度给标题打分。 keyword_list list(keywords) keyword_hits [kw for kw in keyword_list if kw and kw in title] keyword_coverage len(keyword_hits) / len(keyword_list) if keyword_list else 0.0 length_score 1.0 if len(title) max_length: length_score 0.0 elif len(title) max_length - 4: length_score 0.8 elif len(title) 15: length_score 0.9 else: length_score 0.6 core_words [w for w in original_title.split() if len(w) 2] info_gain 0.0 if core_words: info_gain sum(1 for w in core_words if w in title) / len(core_words) total round( keyword_coverage * 0.5 length_score * 0.3 info_gain * 0.2, 2, ) return { total_score: total, keyword_coverage: round(keyword_coverage, 2), length_score: length_score, info_gain: round(info_gain, 2), keyword_hits: keyword_hits, }评分结果一方面可以给运营同学做参考另一方面也可以作为后续 A/B 测试的基线数据。当模型参数调整后看平均总得分是否上升。6.4 FastAPI 接口服务最后用 FastAPI 把整个流程串起来对外提供一个简单的POST /optimize接口。# main.py from fastapi import FastAPI from pydantic import BaseModel, Field from config import TITLE_MAX_LENGTH, TITLE_PREFER_LENGTH, DISALLOWED_WORDS from prompts import SYSTEM_PROMPT_TEMPLATE, USER_PROMPT_TEMPLATE from llm_client import call_chat_completion from validator import validate_title from scorer import score_title app FastAPI(title电商标题优化服务) class OptimizeRequest(BaseModel): original_title: str Field(..., description原始标题) category: str Field(..., description商品类目) attributes: list[str] Field(default_factorylist, description商品属性) keywords: list[str] Field(default_factorylist, description核心关键词) platform: str Field(通用平台, description目标平台) max_length: int Field(TITLE_MAX_LENGTH, description标题最大长度) app.post(/optimize) def optimize(req: OptimizeRequest): system_prompt SYSTEM_PROMPT_TEMPLATE.format( max_lengthreq.max_length, prefer_lengthmin(TITLE_PREFER_LENGTH, req.max_length), disallowed_words、.join(DISALLOWED_WORDS), ) user_prompt USER_PROMPT_TEMPLATE.format( original_titlereq.original_title, categoryreq.category, attributes、.join(req.attributes) if req.attributes else 无, platformreq.platform, keywords、.join(req.keywords) if req.keywords else 无, ) generated_title call_chat_completion(system_prompt, user_prompt) # 去除可能存在的引号和前缀 generated_title ( generated_title.strip() .strip() .strip(“) .strip(”) .strip() ) validation validate_title(generated_title) scoring score_title( generated_title, req.original_title, req.keywords, max_lengthreq.max_length, ) return { generated_title: generated_title, validation: validation, scoring: scoring, }7. 运行结果与效果验证先配置大模型服务的环境变量export LLM_API_KEYyour-api-key # 如果使用其他兼容 OpenAI 格式的服务再设置下面两个变量 # export LLM_BASE_URLhttps://your-endpoint/v1 # export LLM_MODELyour-model启动服务uvicorn main:app --reload --port 8000用 curl 测试接口curl -X POST http://localhost:8000/optimize \ -H Content-Type: application/json \ -d { original_title: 女装连衣裙夏季新款, category: 连衣裙, attributes: [法式碎花, 收腰, 显瘦, 中长款], keywords: [连衣裙, 碎花, 收腰显瘦, 夏季], platform: 淘宝, max_length: 30 }接口返回的格式类似下面的示例。注意实际模型输出会随模型和参数变化不一定与示例完全一致{ generated_title: 法式碎花收腰连衣裙女夏新款显瘦中长款, validation: { is_valid: true, length: 20, max_length: 30, disallowed_word_hits: [], has_special_symbols: false }, scoring: { total_score: 0.9, keyword_coverage: 1.0, length_score: 0.9, info_gain: 1.0, keyword_hits: [连衣裙, 碎花, 收腰显瘦, 夏季] } }如何判断生成结果是否合格看validation.is_valid是否为true。如果为false再看具体哪个字段异常定位是长度问题、禁用词问题还是特殊符号问题。看keyword_coverage是否接近 1.0。如果核心关键词没有命中说明提示词中的关键词没有被充分使用。再看length_score。如果经常超长可能需要在提示词中把max_length写得更醒目或者降低模型的temperature。如果接口返回 500 或超时第一件事是打开 uvicorn 的终端日志。日志里会直接显示错误堆栈常见原因包括 API Key 无效、依赖包未安装、请求参数格式错误。先解决日志里最顶部的异常再重新请求。8. 常见问题与排查思路问题现象可能原因排查方式解决方案请求返回 401API Key 未设置或无效检查环境变量 LLM_API_KEY 是否已生效重新生成合法 API Key重启服务进程模型输出带引号或“标题”前缀提示词对输出格式约束不足打印模型原始返回内容增强提示词规则并在代码中去掉引号标题命中“最”字被判违规禁用词规则过于粗糙查看命中词列表将“最新”“最近”加入白名单或改用分词判断生成标题总是超长提示词未真实约束长度或温度过高检查 max_length 传递是否正确降低 temperature并在代码层做硬截断并发一高就超时大模型接口响应慢同步调用阻塞查看日志耗时分布改为异步调用增加超时和重试机制必要时加缓存这里特别说明一下“标题总是超长”的问题。单纯提示词约束不可靠如果业务对长度有硬性要求代码层应该在返回前做一次检查。超长的情况下要么重新调用模型生成一次要么用规则截断并输出一个告警字段提醒人工复核。9. 最佳实践与生产环境建议代码能跑通只是第一步。如果这个服务要接入正式运营流程下面几个问题比代码更值得关注。9.1 合规红线要前置禁用词库不要只维护一份“够用就行”的列表。至少应该包含广告法明确约束的极限词并区分“绝对禁止词”和“高风险词”。高风险词可以允许生成但必须在结果里标记出来提醒运营人工确认。合规规则要独立维护由运营或法务同学参与更新不要埋在核心代码里。9.2 引入人工审核环节大模型生成的标题自动校验通过后并不意味着可以直接发布。建议在工具流程中加入审核队列机器生成后先落到待审核状态运营确认后再同步到商品系统。这样既保留了效率又给错误留了兜底。9.3 控制成本与延迟大模型接口的调用成本不可忽略。可以考虑两层优化第一层是结果缓存同样的商品属性组合在短时间内重复请求直接返回上一次结果第二层是异步队列如果系统对实时性要求不高可以把优化任务丢到消息队列里批量处理避免高并发直接打到大模型接口。9.4 用评分数据做灰度验证上线新提示词或新模型之前先在历史商品数据上跑一批样本对比平均评分。评分下降就不要直接切全量可以拿部分商品做 A/B 测试观察搜索点击率数据后再决定是否全量。9.5 数据回流与持续迭代标题优化的效果不应该停留在“生成完成”。把每个标题在线上实际获得的曝光、点击、转化数据回传按关键词维度做统计分析。你会发现哪些属性词对点击贡献大哪些场景词几乎没有带来流量这些数据又反过来指导运营同学优化商品信息。工具的价值会随着数据积累越来越大。10. 总结与下一步可以做的事回到最初的需求“你是一位专业的标题优化师……”这句话定义了角色但没有定义流程。真正的落地实现至少需要补齐三层规则层负责告诉模型什么叫合规生成层负责调用模型输出候选结果校验与评分层负责在返回前拦截问题和度量质量。从工程角度看这个系统的每一个模块都是可替换的。提示词可以换模型可以换禁用词库可以持续更新评分公式可以根据业务调整。只要模块边界清晰整个工具就不会因为某个环节变化而推翻重来。下一步值得尝试的方向有三个接入更多电商平台的标题规范做成配置化规则把接口能力嵌入现有的商品管理后台让运营在编辑页直接调用积累一定样本后考虑基于开源模型做轻量微调进一步降低接口调用成本。如果你正在做一个类似的运营提效工具建议先不要追求功能完整而是先把“生成 - 校验 - 评分”这条链路跑通再逐步加上审核、缓存和数据回流。这套流程越早跑起来你越能看清大模型在业务里的真实边界在哪里。