扫描 PDF 怎么转 Word？离线 OCR 输出可编辑
「PDF OCR 提取」是「龙虾部署大师」技能市场中的文字识别技能：它使用 EasyOCR 把扫描版或图片型 PDF 离线识别成可编辑的 Word 文档，也可输出纯文本；过程中会按页裁切页眉页脚、保留无文本的图像页和封面页，并能对过大的 DOCX 压缩嵌入图片，方便交付。 技能效果 处理中英混排扫描合同时，它讲清了OCR识别、保留图片页、再转成格式完整Word的整个流程。 扫描件里的文字，为什么不好用 纸质资料扫描成 PDF 后，文字其实是"图片"，无法复制、检索或编辑。想把内容整理成 Word，常见三个麻烦：一是手工逐页敲字，量一大就成了重活；二是中英文混排的文件，普通工具识别不全或排版错乱；三是出于保密考虑，合同、档案这类材料不便上传到云端 OCR 服务。结果就是大量内容锁在扫描件里，用不起来。 扫描版 PDF（图片） 不能复制/检索 离线 OCREasyOCR 可编辑 Word 这个技能能帮你做什么 它的核心是把图片型内容还原成可编辑文字，且全程在本地完成。识别上，它对扫描版或图片型 PDF 做离线 OCR；输出上，它生成可编辑的 DOCX，必要时也能输出纯文本结果；版面上，它按页面类型裁切页眉页脚、保留图像页面，对封面页、无文本图页这类识别效果有限的页面会保留原图供人工复核；交付上，当 OCR 后的 Word 文件因嵌入图片过大时，它可以压缩图片降低体积。它支持中英文混排识别。 逐页识别 按页面类型处理裁页眉页脚保留图像页 DOCX/ 纯文本中英文混排 压缩大图交付 用前须知 该技能无需 API Key，完全本地运行。需要安装 PyMuPDF、python-docx、Pillow、EasyOCR、NumPy；首次运行会下载 OCR 模型，之后即可离线使用。运行前需确认 PDF 路径、输出目录和 OCR 语言。 怎么用它 用法是把待识别的 PDF 和对结果的要求用自然语言交给它。例如可以这样对它说： 可以这样对它说 "这份扫描版合同转成 Word，中文和英文都识别，图片页也保留。" "把这个图片型 PDF 跑 OCR，结果另存为可编辑文档，页码和标题别丢。" "这本英文教材扫描件只识别英文，输出纯文本并保留章节层级。" 它适合这些场景：纸质资料扫描成 PDF 后、需要提取文字整理为 Word；中英文混排文件需要离线识别、避免上传到云端；图片页、封面页或图表页识别效果有限、需要保留原图供人工复核；批量 OCR 后生成的 Word 文件过大、需要压缩图片降低体积。它适合处理扫描合同、教材、档案、论文复印件和图片型 PDF 的行政、法务、教育、研究与档案整理人员。 大家常问 扫描版 PDF 为什么复制不出文字？ 扫描版 PDF 本质是图片集合，每页都是像素位图，计算机只记录颜色不存字符编码，所以无法选中或复制。要拿到可编辑文本，必须用 OCR 把字形重新识别成字符。 双层 PDF 和单层 PDF 怎么区分？ 单层 PDF 只有扫描图像，文字不可选；双层 PDF 在图像层上叠了一层透明文字层，外观一样但可选可搜可复制。最直观的判断是拖选文字，能高亮并复制就是双层。 扫描件 OCR 识别率低，一般是什么原因？ 主要受图像质量影响：分辨率低于 300 DPI 笔画细节丢失，扫描歪斜、噪点、对比度差会让二值化和字符分割出错。字号过小、字符粘连、语言包不匹配也会拉低识别率。 中英文混排扫描件离线 OCR 容易在哪里出错？ 中文靠笔画内部、英文靠外轮廓，同样 DPI 下中文先退化；中英字间距规律不同会让字符分割出现双峰，二值化阈值和语言模型也难同时适配两套字符。 想用上这个技能？ 「PDF OCR 提取」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
怎么用AI查航班动态
「飞常准航班查询」是「龙虾部署大师」技能市场中的航班动态查询技能：作用是基于飞常准官方接口，查询实时航班动态和两个机场之间的航班列表——它识别你是要查某条航班的实时状态，还是查某日某起降机场之间有哪些航班，再把结果整理成表格或简洁说明，展示航班号、航司、计划与实际起降、机型、准点率、延误原因和当前位置等关键信息。 技能效果 查一条航班时，它用一个示例航班展示能拿到的字段——航班号、计划与实际起降、状态、航站楼等及返回格式。 查个航班状态，为什么总要来回切好几个地方 麻烦在于信息分散且口径不一。临出行或接送人时常遇到三种情况：一是动态查得零碎，航班是否延误、实际几点落地、停哪个航站楼，往往要在好几个页面里翻；二是按城市找航班费劲，只知道"深圳到西安明早"，却要先查机场代码、再逐个比对班次和准点率；三是要整理给别人看时格式杂乱，客服或差旅人员把计划起降和当前状态汇总成一张清楚的表，靠手抄又慢又容易错。基于官方民航数据、一次问清，才省去这些来回。 一条航班，关键状态一次看清 出发 计划 / 实际 航站楼 ✈ 在途 / 准点率 到达 实际落地 延误原因 这个技能能帮你查到什么 它把航班查询统一到官方数据上，分两种意图自动处理。给出一个航班号时，它返回该航班的实时动态；给出某日和起降机场（或城市）时，它返回这两地之间的航班列表。它会先把城市名映射成常用机场代码、补全查询参数，再调用官方接口取数，最后把返回的 JSON 整理成表格或简洁的状态摘要。展示的字段包括航班号、航司、计划起降时间、实际状态、机型、准点率、延误原因和当前位置，让"延误了吗、几点落地、停哪个航站楼"这类问题一次说清。 说出查询意图 航班号 / 城市+日期 补全机场代码 映射 + 取官方数据 整理 JSON 表格 / 状态摘要 关键 状态 用前须知 该技能需要 Node.js 运行环境和飞常准的 VARIFLIGHT_API_KEY，可参考 .env.example 配置好 VARIFLIGHT_API_KEY 后再运行查询脚本。它的数据来自官方民航接口，建议以官方公布信息为准；航班状态实时变动，出行前请以航司和机场的最新通知为准。 怎么用它 用法是把航班号或出发到达城市和日期用自然语言说清楚，它会判断意图、补全参数并取数。例如可以这样对它说： 可以这样对它说 "查今天 CA1202 的实时状态，起飞延误、落地时间和航站楼都要看。" "深圳到西安明早有哪些航班，按起飞时间排，准点率也放进表格。" "看一下 CZ3101 今天到没到，如果延误就把原因和实际落地时间说清楚。" 它适合这些场景：旅客想查某个航班今天是否延误、取消、起飞或到达；出行规划时想看指定城市或机场之间某日有哪些航班；客服或差旅人员要快速整理一批航班的计划起降和当前状态；以及只提供城市名、需要自动映射机场代码并补全查询参数的情况。 大家常问 航班状态显示"前方起飞"和"已起飞"在含义上有什么区别？ "已起飞"指你预订的这班飞机已经离开出发机场地面；"前方起飞"指执行你这班航班的飞机（同一机尾号）正在执行上一段航程，已经从上一个机场起飞、但还没飞到你所在机场。前者是你这班的最终确认，后者只表示"飞机在路上、还要等"。 同一个航班号在不同来源看到的状态为什么会对不上？ 因为多个独立系统在描述同一架飞机的不同侧面：空管看的是"是否已获放行许可"，机场运控看的是"是否已关舱门、推出"，ADS-B 信号源看的是"是否已离地"。同一个"延误"标签，在不同来源指向的事件阶段不同，加上各系统更新延迟不一致，自然会对不上。 航班动态里的 ETD 和 ETA 为什么会一直跳变？ ETD 和 ETA 是预估值，由前序航班实际起降、空域流量管制、目的地气象、地面保障进度等多源数据实时融合算出。任何一项变化都会让推算起点改变，所以本质上是一个随新证据不断收敛的概率值，而不是固定时刻——每次跳变都意味着系统拿到了新信息并修正了预测。 想用上这个技能？ 「飞常准航班查询」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
如何用 AI 写对 Next.js 代码
「Next.js 最佳实践」是「龙虾部署大师」技能市场中的规范型技能：作用是指导 Next.js 项目的编写、审查与重构，覆盖文件约定、React Server Component 边界、异步 API、数据获取、路由处理、元数据、图片字体优化、脚本加载和打包问题。它按主题进入对应参考文档，识别风险模式并给出符合版本特性的修正建议，帮助团队减少水瀑请求、边界误用、hydration 错误和部署配置偏差。 技能效果 拿到一段用 useEffect 客户端取数的 Next.js 页面时，它按最佳实践重构成 async 服务端组件加 Suspense 取数，并解释了为何这样更稳。 App Router 的坑，为什么不容易自己发现 Next.js 进入 App Router 时代后，许多问题不是"报错"，而是"写法不符合框架预期"。服务端组件和客户端组件的边界没划清，可能引出 hydration 错误或把不该上客户端的逻辑带过去；数据获取顺序没排好，一串串行请求拖成水瀑式加载；升级到 Next.js 15 后，params、cookies、headers 变成异步 API，旧写法会冒出构建警告和运行时报错；metadata、OG 图、图片字体优化和自托管部署各有约定，稍不留意就偏离规范。这些坑往往要等性能下滑或线上异常才暴露。 水瀑式串行请求（慢） 请求 A 请求 B 请求 C 并行 / 边界正确（快） ABC RSC 边界 · 异步 API · 数据获取，写法决定快慢与稳定 这个技能怎么帮你写对 Next.js 它是一套规则型指南，按主题进入对应参考文档，专门识别 Next.js 项目里的风险模式并给出符合版本特性的修正。文件约定方面，梳理特殊文件和路由段的组织规则，统一目录结构与命名。边界方面，检查 RSC 边界、客户端组件和 Server Action 的使用风险，是处理 hydration 错误的关键。迁移方面，指导异步 params、cookies、headers 等新 API 的正确写法，避免升级后构建警告与运行时报错。优化方面，提供图片、字体、脚本、打包和自托管的准则。它的定位是"审查与重构"——告诉你哪里写得不对、该怎么改，而非替你从零搭项目。 文件约定路由段/特殊文件 RSC 边界客户端/Server Action 异步 APIparams/cookies 优化准则图片/字体/打包/部署 用前须知 该技能无需 API Key 或额外服务，作为规则型文档使用。若要在此基础上执行项目构建与诊断，需要本机具备 Node.js、Next.js 项目依赖和相应的包管理器。 怎么用它 用法是把要审查或重构的 Next.js 代码、要解决的问题用自然语言说清楚，由它对照规范给出修正。例如可以这样对它说： 可以这样对它说 "这个 Next.js 路由用了客户端取数，按最佳实践帮我重构得稳一点。" "检查 App Router 项目的 metadata 和 OG 图写法是否合规。" "把 Next.js 15 的异步 params 改对，别再出构建警告和运行时报错。" 它适合这些场景：新建 Next.js 应用时统一目录结构、路由命名和特殊文件放置；审查 App Router 项目中服务端组件、客户端组件和数据流边界；升级 Next.js 15+ 后处理异步 API、元数据和错误页面变化；定位 hydration 错误、打包异常、图片字体加载或自托管部署问题。 大家常问 在 Next.js 里，服务端组件和客户端组件到底有什么区别？ App Router 里组件默认是服务端组件（RSC），可直接 async 取数、查数据库、不打进客户端 JS；只有文件顶部写了 "use client" 才成为客户端组件，用来处理 useState、事件和浏览器 API。最佳实践是把客户端组件推到叶子节点，需要交互的地方才切边界。 Next.js App Router 项目里为什么会出现"水瀑式"串行请求，慢在哪里？ 本可并行的请求被迫排队，后一个等前一个完成。App Router 里布局嵌套、RSC 逐层渲染、客户端组件等 RSC Payload 到达才发请求，三层串行叠加，所以更易出现。把数据获取提升到同一层用 Promise.all 并行、用同级 Suspense 流式输出，能消除瓶颈。 Next.js 15 里 params、cookies 这些为什么从同步变成了异步，旧写法会怎样？ 这是向 React 19 异步数据模型对齐：同步读取会阻塞流式渲染管道，改成 Promise 后组件可 await，下游静态部分先流出。Next.js 15 仍兼容旧的同步写法但会报 deprecation 警告，到 16 直接报错；可用 @next/codemod 自动迁移。 Next.js 的 App Router 和 Pages Router 是什么关系，定位有什么不同？ Pages Router 是传统路由，组件默认客户端、靠 getServerSideProps 等取数，无原生嵌套布局与流式渲染。App Router 是 13.4+ 推荐方案，基于 RSC，服务端组件优先、原生支持嵌套布局、Suspense 流式和 Server Actions。新项目建议用 App Router，存量项目无需强制迁移。 想用上这个技能？ 「Next.js 最佳实践」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
RAG 检索召回率怎么提升
「RAG 知识检索」是「龙虾部署大师」技能市场中的本地知识库检索技能：作用是把图片、PDF、Word、Markdown、TXT、PPT 等多格式文档解析、切分并建成向量索引，提问时先改写问题，再用向量检索、BM25、LLM 分词、RRF 融合与重排序找出最相关的片段喂给大模型，让回答有据可依，而不是凭原文整篇硬塞。 技能效果 把年假政策和报销流程两份资料建索引后，它按用户问题检索作答：入职两年休五天年假，报销三千需主管加总监二次审批，还标了来源。 为什么把整份文档塞给大模型行不通 直接把整份资料丢给大模型回答问题，会遇到三个工程上的硬约束：一是上下文窗口有限，几十页的合同或一整本教材根本放不进去；二是塞进去的无关内容越多，模型越容易被干扰、答非所问，准确率反而下降；三是用户的提问往往很口语、很模糊，和原文里的措辞对不上，直接拿原话去匹配经常漏掉真正相关的段落。RAG（检索增强生成）就是为了解决这一类问题：先检索出少量真正相关的片段，再让模型基于这些片段作答。 两种喂法的对比 整份原文硬塞 超窗口 · 被无关内容干扰 先检索再作答 只取相关片段 · 有出处 这个技能把 RAG 流程做成了什么 它把"建库"和"检索"两个阶段串成一条完整流程。建库阶段，它解析图片、PDF、Word、Markdown、TXT、PPT 等多种格式（图片走 OCR 后入库），把内容切分并写入 sqlite-vec 向量数据库；这里用的是 smart 模式，会跳过已索引过的重复文件、只追加新文档，或在需要时定向重建索引，避免每次都从头跑一遍。检索阶段，它不会拿用户原话直接去查，而是先把口语化、模糊的问题改写成精准的查询词和子查询，再并行执行向量检索、BM25 关键词检索、LLM 分词，用 RRF 把多路结果融合，最后做一次 LLM 重排序，返回排在最前的相关片段。 阶段 0 · 建库 多格式文档 解析 + 切分图片走 OCR sqlite-vec 索引smart 增量 阶段 1 · 检索 口语问题改写为查询词 向量 + BM25 + 分词RRF 融合 · 重排序 相关片段喂给模型 这套混合检索加重排序的设计，目的是同时兼顾"语义相近"和"关键词命中"两种召回，比单一向量检索更不容易漏；问题改写则解决了"用户说得太口语、和原文对不上"的老问题。 用前须知 该技能依赖 sqlite-vec、requests、python-docx、python-pptx 等运行环境，并从 AI agent 身份文件读取 uid/token；每次开启新会话需先运行 check_env.py 初始化环境。一个重要约束是：回答时只引用检索出来的片段，不绕过检索直接翻整份原文，这样才能保证回答可溯源。 怎么用它 用法是用自然语言把"要建库的资料"或"要回答的问题"交给它，建库与检索的细节由它按流程处理，无需手动跑脚本或调参数。例如可以这样对它说： 可以这样对它说 "把这批 PDF 和 Word 建好索引，之后按用户问题检索相关片段来回答。" "我的问题问得比较口语，先帮我改写成精确检索词，再跑一遍混合检索和重排。" "这些图片资料先 OCR 入库，查询时只看检索到的片段，不要直接翻原文。" 它适合这些场景：用户上传教材、合同、论文或资料包，需要先建立统一的本地知识索引库；围绕已索引资料做问答，且要求答案只引用检索片段而非整份原文；新增或更新文件后，要避免重复索引、保留已有数据库内容；提问较模糊，需要先改写成结构化查询词以提升召回质量。适合做本地资料问答、课程辅助、文档研究和企业知识库检索，尤其是多格式文档混在一起的场景。 大家常问 RAG 检索里说的「混合检索」是什么意思？ 混合检索不是某种单一算法，而是把两路检索的结果融合起来：一路用 BM25 等稀疏检索做关键词字面匹配，一路用向量做稠密语义匹配，再用 RRF 等方式按排名融合去重。目的是同时兼顾"精确命中"和"语义相近"，比只用一路更不容易漏掉相关片段。 向量检索和关键词检索（BM25）有什么区别？ BM25 是稀疏检索，靠词频与倒排索引做字面匹配，词对不上就漏，但对专有名词、型号、代码很精确且可解释。向量检索是稠密检索，把文本编码成向量比语义相似度，能识别同义改写，但对罕见实体和精确匹配偏弱。一个管字面命中，一个管语义关联，互补大于竞争。 为什么混合检索之后还要再做一次重排序（rerank）？ 混合检索为了保召回会"广撒网"，两路打分都是轻量近似——BM25 只看词频、向量是有损压缩，正确答案大概率在候选里却不一定排最前，还混着噪声。重排序用交叉编码器让查询和每个候选做细粒度交互精排，把真正相关的提到前面。它只在几十到几百条候选上跑，负责"收网"。 检索评测里的召回率和精确率有什么区别？ 召回率回答"该找的有没有漏"，是命中的相关文档数除以全部相关文档数；精确率回答"找回来的有没有用"，是命中的相关文档数除以返回的总条数。两者通常矛盾：多返回结果召回率升、精确率降。工程上常用大候选集保召回，再靠重排序和元数据过滤把精确率提上去。 想用上这个技能？ 「RAG 知识检索」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
Jungle Scout选品怎么分析？算11项指标出报告
「Jungle Scout 深度分析」是「龙虾部署大师」技能市场中的选品分析技能：它面向 Amazon 选品和市场进入判断，用 Jungle Scout API 数据、竞品指标、关键词趋势和品牌声量构建指标框架，输入关键词和可选 ASIN 后采集多源数据、生成 8 维子问题、逐维分析，输出三层商品推荐、供应商线索和一份 final_report.md。 技能效果 深挖亚马逊空气炸锅品类时，它按八维框架分析了搜索热度、价格带和竞争强度，判定整机已是红海，并给新卖家配件和食谱书两条低风险切入路线。 高投入选品，凭感觉进场风险太大 开发一款新品、砸进生产和广告预算之前，最怕的是"凭感觉进场"。一个 Amazon 细分市场到底值不值得做，要看需求大不大、竞争激不激烈、利润还有没有空间、有没有进入壁垒——这些维度散在各处数据里，靠零散查看很难拼出一个能支撑决策的完整判断。 这个技能能帮你分析什么 它把选品做成一份证据化的市场研究。数据上，它单次批量采集关键词、趋势、产品库和品牌声量等多源数据；框架上，它计算 11 项指标，并据此生成 8 个由异常驱动的子问题；分析上，它结合数据逐维回答需求、竞争、利润和壁垒；产出上，它给出分三层的商品推荐、供应商线索，以及一份 final_report.md 报告。即使某个步骤的数据缺失，它也要求基于现有数据产出报告，而不是中途停摆。 8 维分析 需求规模 竞争强度 利润空间 进入壁垒 关键词趋势 品牌声量 整体流程是"采数 → 逐维分析 → 出报告"，最终交付一份可在选品会上引用的材料： 多源数据采集 11 指标 / 8 维逐项分析 商品推荐 + 报告final_report.md 用前须知 该技能需要 Jungle Scout API 凭证或工具已配置，并具备工作区读写权限；Python 脚本随技能提供，供应商和商品补充依赖可用的搜索工具。数据质量取决于 Jungle Scout 的来源。 怎么用它 用法是把要研究的品类或关键词用自然语言交给它即可。例如可以这样对它说： 可以这样对它说 "用 Jungle Scout 深挖空气炸锅词，判断亚马逊机会和竞争强度。" "分析这个 ASIN 的关键词、竞品和品牌份额，写完整报告和风险。" "对这类产品做八维问题分析，再筛一批可卖 ASIN，别推配件类。" 它适合这些场景：评估某个 Amazon 细分市场是否值得进入、需要完整数据论证；分析竞品 ASIN 的流量关键词、销量估算和差异化机会；比较关键词需求、PPC 出价、季节性和市场集中度；为选品会议准备可引用的产品推荐、风险判断和供应商线索。 大家常问 为什么有些亚马逊细分市场销量很大，却反而不建议新卖家进入？ 高销量往往意味着该细分已进入成熟或饱和期，头部卖家在 Review 数量、采购成本、广告与自然流量上形成结构性壁垒，新卖家容易掉进"高销量≠高利润"的利润陷阱，还要面对跟卖、差评攻击与高退货风险。比起硬挤大市场，需求已验证、竞争未白热化、有差异化空间的小利基更适合新卖家起步。 亚马逊选品为什么不能只看销量，还要看利润空间？ 销量反映的是市场容量，不等于盈利能力。高需求品类常被市场教育出"价格锚点"压住提价空间，FBA 仓储/配送费与大词广告成本刚性，再加上退货的隐形折旧，很容易变成"给平台和物流打工"。健康的选品要把采购、头程、FBA 费用、广告、退货损耗、关税一起算进去，看单品净利润是否够厚。 亚马逊选品里说的"市场集中度"高，对新卖家是机会还是壁垒？ 要看是"同质化的寡头垄断"还是"有差异化空间的灯塔型"。前者在规模、Review、广告三方面都把门关着，不建议正面进入；后者头部高销量已验证需求、却只覆盖大众款，新卖家可从差评和细分需求切入、用差异化避开价格战。所以集中度本身不是壁垒，"同质化的高集中度"才是。 亚马逊选品为什么必须考虑季节性？忽略季节性有什么风险？ 季节性产品的流量是"脉冲式"倒计时：旺季仓储费是淡季的数倍，过季滞销会被长期仓储费和清仓甩卖吞掉利润，非旺季推广还会拉低点击率、推高 ACoS 让算法把 Listing 误判为低转化。选品时要先判定产品是否季节性，按可销售月数核算定价，首批宁少勿多、验证后再补货。 想用上这个技能？ 「Jungle Scout 深度分析」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
千川投放数据怎么分析 ROI 与转化成本
「巨量千川数据分析」是「龙虾部署大师」技能市场中的投放查询技能：它查询千川广告账户、余额、消耗报表、计划列表、素材效果、直播间表现和实时监控信号，全程只读不改账户，通过统一入口管理 Token、四层监控和开播实时调控，用于日常巡检、复盘和投放异常发现。 技能效果 查千川账户时，它列出余额、今日消耗和整体ROI，再按计划分组算出各自的转化成本，把消耗一起摆出来。 千川数据散在各处，巡检全靠手点 抖音电商投放最耗精力的不是出创意，而是每天的巡检：账户消耗、ROI、余额要看，低效计划要挑，素材效果要排，直播间开播后还得盯着流量来源和大屏数据。这些信息分散在不同页面，靠人工逐个点开、抄数、对比，一轮看下来时间就过去了；开播期间数据变化快，等手工汇总完，调控时机可能已经错过。「巨量千川数据分析」要做的，是把这些查询统一到一个入口，按需要的维度一次性拉齐。 四层监控：从账户到开播实时 账户层 · 消耗 / ROI / 余额 计划层 · 计划列表 / 低效计划 素材层 · 素材效果 / 转化 直播层 · 开播实时大屏 这个技能能帮你查到什么 它的能力围绕"查询"展开，覆盖四块。账户层面，可查账户信息、余额、日预算、广告计划和消耗报表；直播层面，可分析直播间列表、大屏数据、流量来源和历史直播报表；汇总层面，可整合标准推广、全域推广、素材效果和低效计划的表现，形成综合报告；授权层面，它管理 Token 的获取、保存、状态查看、手动刷新和安全删除。需要强调的是，它只做查询，不写入或修改账户设置，巡检过程不会动到任何投放配置。 账户消耗 计划/素材 直播间表现 综合报告 只读查询，不改账户设置 用前须知 该技能需要千川的 app_id、secret、auth_code、advertiser_id 和 Access Token，本地需 Python 环境。Token 以明文保存在用户目录，保存和自动刷新都必须经过你的确认，请注意 Token 的安全。aweme_id、room_id 等参数需按正确流程获取。它提供的是数据查询与分析，不构成投放或经营建议。 怎么用它 用法是把要查的账户、时间范围和关注的维度用自然语言说清楚。例如可以这样对它说： 可以这样对它说 "查千川账户今天的消耗、ROI 和余额，按计划分组看转化成本，消耗一起看。" "直播间开播后监控千川数据，发现低效计划就标出来，别改设置，消耗写清。" "近 7 天素材效果拉一遍，找出花费高、转化低的素材，按消耗降序，转化也看。" 它适合这些场景：广告运营查看近七天账户消耗、ROI、余额和低效计划；直播投放期间监控直播间状态、流量来源和实时大屏数据；同时整合标准推广与全域推广、形成账户综合汇总报告；以及首次授权千川账户后安全保存 Token 或排查权限不足。适合抖音电商投手、直播运营、广告分析师和代运营人员的日常巡检与复盘。 大家常问 千川投放里的 ROI 是什么意思？看到一个 ROI 数值怎么判断它算高还是低？ ROI 即投产比，等于千川渠道成交金额除以消耗，代表每花 1 元广告费换回多少成交。判断高低不看绝对值，而是对照盈亏平衡 ROI（约等于 1 除以毛利率）：高于平衡线才盈利，越往上放量空间越大，接近或低于平衡线就要降出价、查素材。 千川数据里的转化成本是什么？为什么要按计划分组分别看，而不是只看账户总数？ 转化成本等于消耗除以转化数，即每获得一次下单或成交平均花了多少钱。只看账户平均会被大计划的低成本拉漂亮，掩盖那些消耗小、成本高的亏损计划。按计划分组才能看清成本分布，找出真正在浪费预算的计划单独处理。 怎么判断一条千川广告计划是不是低效计划？从哪些数据上能看出来？ 先看消耗与投产是否匹配：高消耗加低 ROI 基本就是纯亏。再看实际转化成本与出价的偏离，成熟期成本超出价 1.5 倍以上即成本失控。还要看点击率和转化率，两者双低是典型低效特征。学习期 ROI 低属正常，转化数攒够再判断。 千川的素材衰退是什么意思？为什么巡检时要专门把素材效果拉出来按消耗排？ 素材衰退指一条素材随曝光增加、效果指标持续恶化：点击率和转化率下滑、转化成本上升、系统减少给量。本质是人群被洗过一轮后频次过高、边际效用递减。按消耗排是因为约两成素材花掉八成预算，先盯高消耗素材就抓住了影响账户的主要矛盾。 想用上这个技能？ 「巨量千川数据分析」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
提示