电商运营用 WorkBuddy：详情文案、评价汇总与上下架清单怎么交出去

2026-08-08

电商运营的一天，大半时间不在”想策略”上，而在三摊碎活里：新品要写详情页卖点，客服说某个尺码差评变多、你得翻几百条评价确认，月底还要把上下架计划、库存数、活动价对成一张能给仓库看的表。

这三摊活有个共同点——输入都是现成的文字和表格，输出都有固定结构。这正是 WorkBuddy（Tencent WorkBuddy）这类桌面 Agent 相对擅长的区间：读你授权目录里的文件、按你定的规则归类、直接产出文档和表格。

但也有个共同的坑：电商的每一句对外文案都带合规责任。这篇讲三件事怎么交出去、交付物怎么验收，以及为什么最后那道合规扫描不能省。

一、先划清楚哪半段能交

环节	能不能交	说明
把产品参数表整理成详情页文案结构	能	参数得你给，它不会知道
几百条评价按主题归类、统计出现次数	能	这是文本整理，它的强项
上下架清单、库存表的合并去重与格式统一	能	规则要说死
判断某个卖点该不该主推	不能	这是经营判断
确认参数与实物是否一致	不能	它只看得到你给的文件
定价、促销规则、赠品口径的最终确认	不能	出错是真金白银

第五行是本篇最需要强调的一条。详情页出事故，十有八九不是文笔问题，是参数写错了——标称容量、材质成分、适用机型、保修年限。这些数据它无从核实，你给它什么它写什么；你没给，它就用一句听着合理的话把位置填上。这是所有生成式工具的共同边界，只是电商场景的代价格外高。

二、详情页文案：卖点必须长在参数上

官方《实践案例·文档生成与编辑》给的方法很朴素：直接描述文档目标、对象、语气和结构要求。配合《创建任务》里的四要素——目标 / 输入 / 输出格式 / 约束条件——写成一条完整指令：

【目标】为一款新品写商品详情页文案框架，供我后续排版使用。

【输入】读取 D:/电商/新品/参数表.xlsx（含规格、材质、尺寸、适用范围、
保修条款）和「同类在售3款的详情页文本.md」。
目标人群：25-40 岁、给家里买第二台的用户，不是首次购买。
使用场景：家庭日常使用，非商用。

【输出格式】Markdown，保存到 D:/电商/新品/文案草稿 目录，文件名带日期。
结构固定为五段：一句话卖点 / 核心卖点 3 条（每条一个小标题 + 两句说明）/
参数表（原样搬运，不要改写）/ 使用场景说明 / 常见疑问 3 条。

【约束】
1. 每条卖点后面必须标注它来自参数表的哪一行；找不到对应参数的卖点，
   直接删掉，不要用形容词补位。
2. 禁止出现绝对化和排他性表述：最、第一、顶级、极致、国家级、
   销量冠军、行业领先、唯一、100%、永久、根治、彻底。
3. 不要写疗效、功效、健康收益类的承诺性表述。
4. 不要写价格、优惠、赠品、活动时间，这些我另外填。
5. 参数表里没有的数据一律留成 [ 待补：xxx ]，不要推算，不要取近似值。

第 1 条堵住”凭空生卖点”，第 5 条堵住”凭空填数字”。官方在《10 个上手技巧》里给的公式是 做什么 + 有什么 + 怎么样，“有什么”这半截在电商场景就是参数表本身——它不是可选的补充材料，是这条指令能不能成立的前提。没有参数表就让它写详情页，产出的东西看着完整，逐句核起来全是空的。

第 2 条那份禁用词表建议单独存成一个文件长期维护。广告相关法规和各平台规则对绝对化、排他性用语都有明确限制，这类词在促销语境里又特别容易被顺手写出来——“同价位里最能打的一款”这种句子，读着自然，发出去就是风险。写进约束能挡掉大部分，但挡不干净，所以第五节还有一道人工扫描。

第 4 条把价格和活动排除在外，是因为这些数字要对客户兑现，让它参与只会多一个出错环节。

三、评价汇总：这一段的价值最高

三件事里，最值得交出去的是评价整理。几百条评价靠人读，读到第八十条注意力就散了，而且人容易被最近看到的几条带偏——今天读到三条说包装破损，就觉得包装是主要问题，其实占比可能不到 5%。归类和计数这件事，机器天然比人稳。

官方《实践案例·数据分析并可视化》给的做法是：已有文件就拖入对话或明确告知路径，描述需求时一次说明分析指标、图表类型、统计维度或时间范围、是否输出报告。评价文本属于其中的文字数据整理，套进去是这样：

【目标】把导出的买家评价做一次分类汇总，我要找出反复出现的质量问题。

【输入】D:/电商/评价/2026-07全量评价.csv，字段包括评价时间、星级、
SKU、评价正文、是否追评。时间范围：2026 年 7 月全月。

【输出格式】生成一份 Markdown 报告 + 一张汇总表格，保存到
D:/电商/评价/分析 目录。表格三列：问题类别 / 出现条数 / 占该 SKU 评价总数比例。

【处理规则】
1. 先按 SKU 分组，再在组内分成三类：好评提到的具体优点、
   差评提到的具体问题、提到但看不出褒贬的中性描述。
2. 分类必须基于评价里说出来的具体事项（例如"拉链卡住""发货慢两天"），
   不要按情绪强弱分类，不要归纳成"整体满意"这种大类。
3. 每个问题类别下，原样摘录 3 条原始评价作为例证，标出评价时间和星级，
   不要改写、不要节选到看不出上下文。
4. 出现 5 条以上的类别单独列一节，标题写清楚是哪个 SKU 的哪个环节。
5. 不要给改进建议，我只要事实归类。

第 3 条是防断章取义的关键。归类过程本质上是把一句话压成一个标签，压缩过程中最容易丢掉转折——“一开始以为不好用，看了说明书发现是我装反了”，只取前半句就变成差评。强制保留原文摘录，等于给每个结论留了回溯路径，你抽查三条就能判断这一类分得对不对。

第 5 条把建议关掉也是有意的。它给的改进建议大概率是”加强质检""优化包装”这类正确的废话，反而稀释了真正有用的部分——那张按出现次数排序的问题表。判断在看完表之后由你来做：拉链问题占某 SKU 差评三成，那是供应商的事，不是文案能解决的事。

按官方”小步快跑”的建议，这个活也别一轮到底。第一轮只要分类结果和计数，不要报告；你先扫一遍类别划分合不合理——有没有把”物流慢”和”发货慢”拆成两类，有没有把两个 SKU 的问题串到一起。确认之后再让它出完整报告。官方在《任务对话》里说明，继续追问时它会基于之前的上下文继续处理，不需要重复描述背景，所以”把第 3 类和第 7 类合并""按出现次数从高到低重排”这类调整直接说就行。

四、上下架与库存清单：规则说死，数量对账

第三摊活最枯燥也最容易出错。官方《实践案例·文件内容识别与处理》的批量处理示例里带着一句关键的话——“并先展示预览结果”，这半句在电商场景不能删：

【目标】把本月上下架计划整理成一张给仓库看的执行清单。

【输入】读取 D:/电商/上下架/ 目录下三份表格：在售清单.xlsx、
本月新品.xlsx、清仓下架.xlsx。

【输出格式】合并成一张表，列为：SKU / 品名 / 当前状态 / 目标状态 /
生效日期 / 现有库存 / 备注。按生效日期升序。
输出 Excel 到 D:/电商/上下架/执行 目录。

【约束】
1. 三份表里 SKU 重复的，单独列在文末"冲突"区，不要自动取其一。
2. 缺字段的行不要丢弃，保留并在备注注明缺哪个字段。
3. 先输出合并结果的行数统计（各来源多少行、合并后多少行、
   冲突多少行），我确认后再写文件。
4. 不要修改原始三份表格。

第 3 条那个行数统计就是数量对账。合并类任务最隐蔽的错误不是写错，是悄悄少了几行——去重逻辑理解偏了、空行被跳过、编码问题导致某几行读不出来。你不主动要计数，就看不出来，等仓库按表操作才发现某个 SKU 没下架。

官方技巧第 8 条讲得很直接：它可能”改过头”——删掉你想保留的内容、打乱原有格式，成熟用法不是期待它永不出错，而是提前备好回退方案，改文档表格前先复制一份备份（文件名加 _备份 或当天日期）。库存表尤其如此。

模式上，这类会写文件的任务适合想一想（Plan）模式——先生成执行计划、确认后再操作，正好对上官方给它标的”多步骤、需审阅改动范围”。目录按官方建议按任务类型分开建（文案草稿 / 评价分析 / 上下架执行）：它读得到哪个目录取决于你授权了哪个目录，分细了等于留了道隔离带。

五、验收：四处必查，第一处不能省

合规词扫描（必须人工再过一遍）。 指令里禁了不等于成稿里没有——换个说法它照样写得出来，“没有之一""断层”这类变体尤其难拦。成稿后用编辑器搜索一遍禁用词表，再通读一遍找有没有变体表述，以及有没有混进功效承诺。这一步两分钟，省不得：详情页长期挂在那儿，风险不会随时间消失。
参数与实物核对。 逐条对着参数表看文案里每个数字和每个技术词，重点是单位、型号、适配范围、保修年限。有条件的话拿实物或包装再核一遍——参数表本身也可能是错的，它只会忠实地把错误放大到详情页上。
评价归类抽样回溯。 随机挑两三个类别，点进摘录的原始评价读全文，看结论站不站得住。特别注意那些”差评里提到”的条目，有没有把反讽、追评改口、对物流的抱怨错记到产品头上。
清单数量对账。 拿它给的行数统计和三份原表的实际行数手动加一遍，对不上就退回去重跑。冲突区的每一行都要人工裁决，别让它替你选。

六、四种情况，别交给它

第一，需要真实使用体验的种草内容。 详情页里那些”用了两周""实测比上一代安静”的表述，它写得出来但那是编的。这类内容要么你自己写，要么用真实买家评价做素材，而不是让它假托体验。

第二，涉及功效、疗效和质量承诺的表述。 食品、保健、化妆品、母婴、医疗器械这类品类措辞边界很细，平台尺度还各不相同。让它起草，你拿到的是好听的话，不是能过审的话。

第三，价格、促销规则和活动口径的最终确认。 满减叠加、预售尾款、赠品条件，这些是要对客户兑现的承诺，出错直接是赔付。让它帮你排版可以，最终数字必须你自己敲定。

第四，评价里的售后处理。 汇总能告诉你哪类问题反复出现，但具体某位客户怎么回复、怎么赔付，是有人在等答复的事。

小结

电商这三摊活，能交出去的是结构化这一层：把参数变成有层次的文案框架、把散评价变成按次数排序的问题表、把三张表合成一张能执行的清单。交不出去的是事实和判断：参数从哪来、卖点该不该主推、价格怎么定、这条差评怎么答复。

指令按目标 / 输入 / 输出格式 / 约束四要素写；评价汇总先要分类再要报告，强制保留原文摘录；合并类任务一定要行数统计。最后那道合规扫描无论如何要人工再过一遍——这是电商和其他办公场景最不一样的地方。