视频评论分析的早期方案沿用了常见的数据项目思路：先采集评论，落成快照，再做分类、排序和报表。这个方案能够运行，却没有解决使用环节里最费时间的动作。内容运营看到一条“会不会漏”的评论，仍要切回视频确认画面；产品人员看到“换了另一个品牌”，仍要找到原评论判断比较对象；有人问购买链接，运营还得重新打开页面检查简介和置顶评论。数据被搬进了系统，工作却没有缩短。
问题出在产品位置。评论分析不是一个每天独立打开的后台，它发生在看视频、读评论的过程中。把信息复制到另一套工作台，等于强迫使用者在视频页和分析页之间反复核对。因此，原来的独立页面方案被浏览器侧栏插件 SNW Video Lens 取代。它只在用户点击时读取当前页面，把视频已经表达的内容、评论仍在追问的问题和原评论位置放在同一个侧栏里。
改造目标不是把旧界面塞进 Chrome，也不是增加一个“AI 总结”按钮，而是重新定义输入、权限和输出：输入只能是当前网页已经展示的内容；分析结果必须能回到原视频或原评论；没有字幕就明确降级；评论只负责发现问题，不能被包装成市场统计。
插件真正缩短的不是分析时间，而是“发现问题—回看原文—交给负责人”这段核对路径。
研究对象仍然是同一条公开视频
产品设计不能离开具体页面。验证继续使用之前登记的 Ninja Blast 18oz 便携式搅拌机视频，视频标识为 7597521291624631583。画面中出现了饮品洒漏，评论里随即有人追问应该从哪一端打开，也有人提到杯盖、替代品牌和购买入口。
图 1：文章、插件演示报告和评论样本都绑定到同一视频 ID，不再拿无关视频充当画面
这条视频适合作为产品验证样本，因为问题类型很完整。Were you supposed to open it from the top instead? 同时涉及操作说明和潜在风险；Glad I got the Nutribullet instead 给出了真实比较对象；Where did you buy it? 指向购买路径。它们不是同一种“负面情绪”，也不该进入同一个处理队列。
但这个页面同样说明了边界。评论排序不是随机抽样，创作者和平台可以过滤内容，尚未滚动到的评论不会出现在 DOM 中，公开视频也不保证提供可读字幕。因此插件首页首先展示“本次实际读到多少段字幕、多少条评论、形成多少类问题”，而不是先给一个漂亮的情绪比例。
图 2：页面当下可见的集合只是一次观察截面；插件不会把它写成全部观众意见
重新定义产品问题
需求可以压缩成一句话：用户正在看某条视频时，能够在不离开页面的情况下确认视频讲了什么、评论还在问什么，并回到原评论复核。
这句话排除了几种看似合理、实际会让项目失焦的方向。
第一，不做通用视频摘要。字幕摘要、章节和问答已经有大量成熟产品，重新做一遍只能得到另一个摘要按钮。第二，不做评论情绪大屏。正面、负面和中性的占比很容易展示，却无法告诉内容团队应该补拍什么，也无法告诉产品人员哪些话需要验证。第三，不承诺抓取“任何平台的全部评论”。平台接口、登录状态、排序方式和访问资格不同，浏览器插件不能把页面之外的数据说成已经拿到。
第一版只保留三项工作：读取当前页面、对照内容与评论、保存可回查的原文。产品输出也只回答四类业务问题。
| 问题类型 | 插件寻找的信号 | 后续负责人 | 插件不替人下的结论 |
|---|---|---|---|
| 使用问题 | 怎么用、能不能、为什么、清洗与设置 | 内容与客服 | 不能证明说明书一定错误 |
| 产品风险 | 漏、坏、过热、失效、退货与保修 | 产品与售后 | 不能计算故障率 |
| 竞品比较 | 明确品牌、替代方案和比较维度 | 产品营销与选品 | 不能证明竞品整体更好 |
| 购买路径 | 价格、链接、库存、配送和优惠 | 电商运营 | 不能直接等同于购买意愿 |
这样定义以后，系统不需要制造“洞察”。它只要把原本散落在视频和评论中的信息放在一起，并告诉使用者哪些地方仍需人工核对。
为什么必须放在浏览器侧栏
浏览器侧栏有两个直接优势。其一，它与当前标签页共存，运营人员不必复制视频链接或重新建立项目。其二，它能够在用户授权的那一刻读取页面，并在分析后把人带回具体评论。独立网站很难同时满足这两点：要么要求用户导入链接，要么需要更重的采集服务和账号体系。
插件采用 Manifest V3，后台是 Service Worker，界面使用 Chrome Side Panel。用户点击扩展图标后侧栏打开，再点击“分析当前页”。后台查询当前活动标签页，通过 chrome.scripting.executeScript 一次性注入采集函数。采集结束后页面不保留常驻脚本，结果写入本地存储，侧栏负责呈现。
用户点击扩展
→ Side Panel 打开
→ 用户点击“分析当前页”
→ 后台取得 activeTab
→ 一次性注入页面采集器
→ 标准化视频、字幕与评论
→ 本地规则完成内容—评论对照
→ 侧栏展示问题并保留回跳位置这条路径把权限控制放进了交互本身。扩展没有声明 all_urls，也没有安装后常驻读取所有网页。当前版本只申请 activeTab、scripting、sidePanel 和 storage：前两项用于用户主动分析当前页，第三项承载伴随页面的界面，最后一项保存最近一次报告。
图 3：截图直接读取生产构建的 manifest；没有声明全站常驻访问权限
“支持任何视频”必须拆成两层能力
产品文案里最容易失真的一句话是“支持任何视频”。从工程角度看，它至少包含两件不同的事。
第一层是识别视频。只要网页使用标准 HTML5 video 元素，插件通常可以取得当前时间、时长、封面以及页面标题和描述。第二层是理解平台结构。字幕位置、评论节点、点赞数和回复数没有统一标准，YouTube、TikTok 和普通网站需要不同适配器。一个站点改版，选择器就可能失效。
因此，通用视频识别和站点评论适配需要拆开。采集器先判断域名，再选择 YouTube、TikTok 或通用 HTML5 路径；平台差异只停留在基础设施层，领域分析器永远只接收统一的 VideoPageSnapshot。
图 4：站点改版时修改采集适配器，不让 DOM 选择器进入分析规则和界面组件
统一快照只保存完成判断所需的字段：页面地址、标题、描述、字幕段、评论文本、点赞数、回复数和页面定位标识。当前版本不读取评论者头像、签名、私信、Cookie 或账户资料，也不建立用户画像。
interface VideoPageSnapshot {
capturedAt: string;
url: string;
title: string;
description: string;
platform: "youtube" | "tiktok" | "html5";
transcriptSource: "page-transcript" | "text-track" | "unavailable";
transcript: TranscriptSegment[];
comments: PageComment[];
diagnostics: string[];
}这里有一个刻意保留的限制：默认最多处理页面中前 250 个已识别评论节点。这个数字是浏览器端性能保护，不是研究抽样设计。侧栏会明确写“当前页面已经加载的评论”，不会把 250 当成总体规模或覆盖率。
没有字幕时，系统必须承认自己不知道
视频内容和评论能否真正对照，取决于是否取得字幕。YouTube 页面展开文字稿后，采集器可以读取带时间点的片段；普通 HTML5 视频若提供 textTracks，也可以读取字幕轨。TikTok 页面是否提供可访问字幕则取决于当前页面结构、地区和视频本身。
如果一段字幕都没有，系统不会调用模型补写口播，也不会根据评论反推视频讲了什么。它只使用标题和公开描述识别有限的产品主张，并把所有“视频是否已经回答”标记为“需要人工核对”。本次 Ninja Blast 样本就处于这种状态：页面描述里有 It’s definitely worth it!，所以可以记录一个产品主张；但视频是否讲清楚开盖和洒漏，插件没有字幕证据，不能自动宣布“未讲清楚”。
缺少字幕不是模型发挥的机会，而是产品应该停下来的地方。
这一降级行为进入了自动化测试。以后即使更换规则或接入模型，也不能悄悄把“需要人工核对”改成确定结论。
图 5：测试关注业务边界，不只检查函数能否运行
分析器先解决分流，不急着生成长摘要
第一版分析器采用确定性规则，没有接入 LLM。这样做不是因为关键词比模型先进，而是当前产品首先需要稳定的业务口径和可重复的错误样本。评论量不大时，如果直接让模型生成主题，团队很难分清究竟是分类错了、提示词变了，还是模型把一句模糊表达解释过度。
规则表把触发词、覆盖词、负责人和处理建议放在一起。分类时，产品风险、竞品和购买信号优先于普通疑问句。例如 Where can I buy it? 虽然包含疑问句式，业务上应该进入购买路径；Does it leak? 应该先进入产品风险，而不是泛化为使用问题。
图 6：当前规则简单，但命中原因、分类结果和改动影响都可以复查
状态也没有使用伪精确的“置信度 92%”。评论数达到三条，或者互动量达到当前阈值，标为“优先核查”；存在少量证据则标为“留意”；没有足够输入时显示“信息不足”。这些状态只是阅读顺序，不是自动决策。
内容侧采用同样的克制。分析器从标题、描述和字幕里寻找步骤、产品主张、比较和行动提示，再检查评论问题是否出现相应覆盖词。最终形成的不是一段脱离原文的总结，而是“视频信息里出现过什么—评论仍在追问什么—是否需要人工核对”的对照关系。
图 7：规则只负责组织材料；涉及产品风险、竞品结论和经营动作时仍由负责人确认
侧栏首先展示样本边界，然后才展示问题
概览页顶部不设置综合评分，而是先展示本次读取结果。本次同源演示报告显示：0 段字幕、4 条已加载评论、3 类问题。接着才是视频信息中识别到的一条产品主张，以及评论区里的产品风险、竞品比较和购买路径。
图 8：文章里的视频标题、原视频链接、评论文本和插件截图已经统一到同一研究对象
概览页给出的下一步是“先核查产品风险、竞品比较”。这不是说购买路径不重要，而是前两类评论的互动更高、公开回应的风险也更大。购买入口通常可以快速检查，产品故障和竞品结论则需要产品、售后或测试记录支撑。
点击“问题”后，每一类都显示负责人、评论数、互动量、内容覆盖状态、处理建议和原评论。以产品风险为例，两条评论分别涉及洒漏、开盖和零件替换。侧栏不会把它们写成“两起产品故障”，因为评论可能描述同一现象，也可能混合了操作问题和产品问题。它只把材料交给产品与售后继续核查。
图 9：页面没有“AI 洞察”黑盒；判断依据和下一步动作在同一张问题卡中
点击“回到页面”时，后台再次取得当前活动页，把此前写入 DOM 的定位标识交给一次性函数。函数滚动到对应评论，并短暂显示描边。如果页面已经刷新、评论重新排序或节点尚未加载，侧栏会提示“原页面已变化，请重新分析”，而不是跳到一个大概位置。
评论页则保留全部已读取原文，不用中文摘要覆盖英文表达。这一点很重要。open it from the top、button to open the lid 和 spilled 看起来都与杯盖有关，但产品人员需要读原句才能判断它们是同一问题、因果关系，还是几个不同动作。
图 10：分类帮助缩小阅读范围，原评论才是后续判断的输入
这条视频最终留下三项具体工作
插件对这条视频的输出没有写成“用户对产品可靠性担忧较高”之类的套话，而是留下三项可以继续处理的工作。
第一项交给产品与售后：核对杯盖开启方式、按钮结构、洒漏条件和替换件政策。输入是两条原评论和对应视频画面；输出应该是说明书、结构信息、售后口径或实测记录。没有这些材料，内容团队不能公开承诺“不会漏”或把问题全部归因于用户。
第二项交给内容与产品营销：确认 Nutribullet 为什么成为评论里的替代对象。当前评论只证明观众主动提到了这个品牌，不证明它在性能上获胜。后续对比应该限定容量、冰冻水果、续航、清洗和杯架适配等条件，而不是制作没有实验口径的胜负海报。
第三项交给电商运营：检查主页链接、置顶评论、地区可售页面和商品承接。Where did you buy it? 只有一条，不能当成强购买意愿，但修复购买入口的成本很低，因此适合作为当天检查项。
这三项工作都能回到原视频和原评论。插件没有创建新的事实，只是减少了信息在团队之间丢失的机会。
当前版本怎样验证，而不是只展示截图
插件是独立的 WXT、React 和 TypeScript 项目。页面采集、领域分析、浏览器消息和侧栏组件分开实现。构建链执行 vitest run、tsc --noEmit 和 wxt build；当前共有两个测试文件、五个自动化测试，覆盖页面识别、评论数字解析、业务分类、购买提示和无字幕降级。
除自动化测试外，验证过程还使用 Chrome for Testing 加载生产构建目录。浏览器能够识别 Manifest V3 Service Worker，通用 HTML5 验证页成功读取视频和四条已加载评论，点赞与回复数字按预期解析，评论回跳函数返回 true。侧栏截图来自真实扩展页面，不是设计稿。
pnpm test
pnpm compile
pnpm build
pnpm zipZIP 安装包约 92 KB。当前版本不依赖账号、API Key、模型服务和远程后端，分析结果只保存在浏览器本地。这样的部署方式牺牲了跨设备历史和大型模型能力，却使第一版的权限、故障面和验证范围都足够清楚。
“真实产品”不等于功能很多，而是每一项公开能力都有代码、权限、测试和失败路径与之对应。
接入模型之前，先积累哪些错误
确定性规则不会是终点。它会漏掉讽刺、拼写变体、跨句指代和未登记品牌，也无法从画面里识别动作。问题是，直接把这些空白交给 LLM，并不会自动得到可靠产品。
下一步应该记录四类人工反馈：分类错误、遗漏问题、内容覆盖误判和错误负责人。每次人工修改都保存原评论、旧结果、新结果、规则或模型版本。等错误样本达到可评测规模，再比较词典规则、向量召回、轻量分类器和 LLM 结构化输出，指标也不只看准确率，还要看原文定位是否正确、样本边界是否保留、负责人是否接受任务。
画面理解同样应该分阶段加入。第一步可以在用户明确触发后抽取少量关键帧，识别产品、动作和明显事故；第二步才考虑本地或受控服务的语音转写。录制标签页音频会扩大权限和隐私风险，不应为了“支持任何视频”在第一版偷偷启用。
图 11：模型升级以真实错误样本和回归结果为入口，不用模型名称替代产品验证
总结
本次重做改变的不是技术栈，而是产品落点。旧方案把评论搬到独立工作台，能够生成报表，却让使用者继续在系统之间核对。SNW Video Lens 把分析放回视频页面，用 Side Panel 承载当前任务，用 activeTab 限制读取范围，用统一快照隔离站点变化，再用可解释规则把评论分给内容、产品、售后、选品和运营。
它目前能可靠完成的事情很有限：识别页面视频，读取可用字幕和已加载公开评论，整理使用问题、产品风险、竞品比较和购买路径，保留原文并回到页面。它不能读取平台全部评论，不能在没有字幕时还原口播，也不能从少量公开评论推出故障率、市场规模或用户偏好。
这些限制不是发布时需要隐藏的缺陷，而是产品能否被信任的起点。只有先让使用者知道系统读到了什么、没读到什么，以及每个判断来自哪里，后续接入转写、视觉模型和 LLM 才有意义。