亚马逊PPC怎么投？三广告结构按ACoS收割优胜词
「亚马逊 PPC 投放管理」是「龙虾部署大师」技能市场中的广告运营技能：它提供新品三广告活动发布蓝图（精准匹配、广泛匹配、自动广告），定义 ACoS、TACoS、CTR、CVR、ROAS 等指标基准，给出提价、降价、暂停和否定关键词的规则，输出广告结构、关键词迁移策略、预算分配和周度优化清单。 技能效果 面对每天300美金的新品预算，它搭出自动加手动五个广告活动的结构表，标清各自日预算、初始竞价和定位，并给出前两周的优化节奏。 PPC 钱花得快，效果却说不清 亚马逊 PPC 最常见的困扰是：广告搭得乱，预算分不清该投哪；ACoS 居高不下，却不知道是哪些词在亏钱；每周的搜索词报告动辄上百行，没时间逐条看，优胜词没收割、无效词没否定。结果就是预算在烧、自然排名却没被带起来。 这个技能能帮你做什么 它把 PPC 从搭建到优化串成一套有章法的流程。结构上，它给新品设计精准匹配核心词、广泛匹配发现词、自动广告收割词的三活动蓝图；指标上，它解释 ACoS、TACoS、CTR、CVR、ROAS 和盈亏平衡点该看到什么程度；优化上，它按转化、展示份额和花费表现给出提价、降价、暂停的规则；并从搜索词报告里收割优胜词、维护否定关键词列表。 新品三广告活动结构 精准匹配核心词收量 广泛匹配发现新词 自动广告兜底收割词 其中最省事的，是它把"自动广告 → 挑出值得转精准的词 → 建精准组并加否定词"这条收割链路理清楚，让广告预算逐步流向真正转化的词： 搜索词报告 挑优胜词 建精准组 加否定词 用前须知 该技能无需 API Key 或脚本依赖，但需要你提供卖家中心广告数据、搜索词报告、利润率、目标关键词和预算信息来给出建议；具体的竞价调整与投放动作仍在亚马逊广告平台执行。 怎么用它 用法是把投放目标或当前问题用自然语言交给它。例如可以这样对它说： 可以这样对它说 "新品上线预算三百美金，搭一套自动加手动 PPC 结构并分日预算。" "ACoS 连续两周太高，找该降竞价和加否词的词，按订单判断。" "把自动广告搜索词里值得转精准的词挑出来建组，同时加否定词。" 它适合这些场景：新品上线前搭建首轮 PPC 结构并分配每日预算；广告 ACoS 偏高、需要判断哪些词降价暂停或加否定；想用 PPC 推动指定关键词自然排名、制定蜜月期策略；每周复盘搜索词报告、提取长尾转化词并减少无效花费。 大家常问 亚马逊广告里的 ACoS 和 TACoS 有什么区别，为什么只看 ACoS 会误判广告效果？ ACoS=广告花费÷广告带来的销售额，只衡量广告自身效率，是活动/关键词层面的指标；TACoS=广告花费÷总销售额（含自然流量），是店铺整体层面的指标。只看 ACoS 会误判：ACoS 升高可能是广告在养自然排名（此时 TACoS 反而下降）；ACoS 很低却可能全靠广告、没有自然流量资产，停投即归零。所以两者要相互验证——ACoS 高+TACoS 低是好现象，ACoS 低+TACoS 高是危险信号。 亚马逊的自动广告和手动广告分别适合什么阶段，为什么新品期建议两个一起开？ 自动广告由系统按 Listing 匹配，最适合新品冷启动期采集真实搜索词；手动广告由卖家选词、可控匹配类型与出价，成长期靠手动精准推关键词排名。新品期两个一起开的核心是分工闭环：自动广告"探路"，最快 3—7 天跑出搜索词报告，把高点击高转化的词收割进手动精准"收割"；两套入口互补覆盖已知与未知搜索词；还能加速蜜月期的系统学习。单开一个效果远不如双开。 亚马逊 PPC 里的否定关键词是什么，为什么不加否词广告费会越烧越浪费？ 否定关键词是一张屏蔽名单，告诉亚马逊买家搜到这些词时不展示你的广告，分否定精准和否定词组两种。不加否词，广泛匹配会把不相关搜索（如卖不锈钢保温杯却被"便宜塑料瓶""婴儿水杯"触发）也带进来：无关点击吞预算、低点击率拖垮质量分让 CPC 越来越贵、零转化拉高 ACoS 还减少广告展示份额。做法是开广告 7—14 天后下载搜索词报告，把点击≥10 次零转化或明显不相关的词否定掉，每两周复盘一次。 亚马逊广告的盈亏平衡 ACoS 是怎么算的，为什么高 ACoS 不一定就是亏？ 盈亏平衡 ACoS ≈ 毛利率：售价 30、总成本 18，毛利率 40%，则 ACoS 低于 40% 就盈利、高于就在广告层面亏。但高 ACoS 不一定真亏，因为广告报告没算上被广告吸引、过两天从自然位下单的归因外订单；广告还有冲新品排名、品牌曝光、防御竞品等非直接回报。所以真正要看 TACoS 和全链路利润——把自然订单算进去，真实盈亏平衡 ACoS ≈ 毛利率×(1+自然订单比例)，可能远高于毛利率本身。 想用上这个技能？ 「亚马逊 PPC 投放管理」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
CJ接口怎么对接？管商品库存订单和物流
「CJ Dropshipping 接口助手」是「龙虾部署大师」技能市场中的代发对接技能：它面向 CJ Dropshipping API V2.0 集成，覆盖商品、规格、库存、刊登、订单、物流、Webhook 和 Shopify 配送模板；用 accio-mcp-cli 完成 OAuth 授权并读取令牌，业务调用走 REST API，输出接口路径、参数、请求体、自动化流程和故障修复建议。 技能效果 查一款蓝牙耳机时，它列出各规格变体、中美德三仓库存和多条物流渠道的运费时效，再按美国仓优先筛出运费1.98美金的最划算发货方案。 对接 CJ 代发，繁琐都在接口细节里 把 CJ Dropshipping 接进自己的店铺或系统，难点不在某一步，而在环节多、细节碎：先要走 OAuth 拿令牌，再分别对接商品、规格、库存、刊登、订单、运费、物流多个接口；刊登到 Shopify 还要绑配送模板，报个 7001001 之类的错误码就得翻文档查半天。自己一点点啃 API 文档，进度很慢。 这个技能能帮你做什么 它把 CJ API V2.0 的对接整理成可直接照做的接口指引。授权上，它用 accio-mcp-cli 完成 CJ OAuth 并读取访问令牌（业务调用统一带 CJ-Access-Token 请求头）；业务上，它覆盖商品列表与详情、规格、库存查询、批量刊登、我的商品和评价管理；交易上，它支持创建订单、支付余额、计算运费、查询物流跟踪；配置上，它处理 Shopify 配送模板、仓库位置、Webhook 设置和常见刊登错误码排查。 CJ API对接 商品 / 规格 / 库存 订单 / 运费 / 物流 Shopify 配送模板 / Webhook 错误码排查 最常见的"把 CJ 商品同步刊登到 Shopify"这条链路，它会替你串清楚——从授权、选品到绑定配送模板、处理刊登错误： OAuth 取令牌 查商品库存 刊登+配送模板 下单+物流 用前须知 使用前需用 accio-mcp-cli 完成 CJ OAuth，并用 get_cj_access_token 获取 CJ-Access-Token；业务接口通过 HTTPS REST 调用，需具备 CJ 开发者权限与店铺授权。 怎么用它 用法是把要对接的接口任务用自然语言说清楚即可。例如可以这样对它说： 可以这样对它说 "用 CJ 接口查这批 SKU 的库存、变体和物流价格，按美国仓优先过滤。" "把选中的 CJ 商品刊登到 Shopify，带上配送模板和店铺分类。" "查美国仓可发货的瑜伽垫，返回商品详情、库存、运费和变体，图片也保留。" 它适合这些场景：把 CJ 商品批量刊登到 Shopify 并绑定配送模板；订单产生后创建 CJ 购物订单、确认支付并跟踪物流；按 SKU 或规格 ID 查库存决定是否继续销售；刊登报 7001001、7001003 等错误时自动修复配送模板配置。 大家常问 对接 CJ Dropshipping 时，accio-mcp-cli 的 OAuth 授权和后面的 REST 业务接口是什么关系？ 简单说，OAuth 授权是"门禁"、REST 接口是"房间"。accio-mcp-cli 只负责一次性的身份认证：通过 start_cj_auth 让用户登录授权、再用 get_cj_access_token 读取 accessToken 和 refreshToken，全程不做任何业务操作。之后所有商品查询、下单、物流、Webhook 等都是标准 HTTP 请求，直连 developers.cjdropshipping.com，请求头带上 CJ-Access-Token 即可。授权只做一次（除非令牌过期），业务接口则持续调用。 把 CJ 商品刊登到 Shopify 时报 7001001 或 7001003，一般是什么原因引起的？ 两者都和 Shopify 配送模板（Delivery Profile）配置有关。7001001 是缺少配送模板——店铺开启了配送模板功能，但批量刊登 listedByPids 时没传 templateShopCategoryVOList 或缺有效的 deliveryProfileId；解决办法是先查可用模板再把模板 ID 传入。7001003 是模板里没启用 CJ 仓库位置（fromCj:true），CJ 关联不到发货仓；办法是在模板里勾选 CJ Dropshipping 位置或新建含 CJ 位置的模板。两者多在初次配置 CJ+Shopify 集成时出现，配好后一般不再复现。 CJ 接口里的 CJ-Access-Token 是干什么用的，为什么不能写死在代码里长期复用？ CJ-Access-Token 是 API V2.0 的身份凭证，调用任何业务接口都要在请求头携带它来证明身份与权限，通过 OAuth 流程换取。不能写死有三个原因：它有明确过期时间（accessTokenExpiryDate），过期后写死的 Token 全线返回 401；CJ 配套提供 refreshToken，本就是让你定期刷新而非用户重新授权；写死在代码（尤其前端或公开仓库）会造成 Token 泄露、无法单独吊销的安全隐患。正确做法是运行时动态获取并缓存，临期用 refreshToken 自动续期。 用 CJ 接口做代发，下单前为什么要先查实时库存和仓库位置，而不是只看商品详情？ 因为商品详情页的库存是静态预设、不实时更新，热销规格可能在你浏览后已售罄，只看详情下单本质是赌运气，易超卖引发退款和客诉。要用库存接口按规格（颜色/尺寸）查实时可售量和哪个仓有货。仓库位置同样关键：CJ 在中国、美国、欧洲多地有仓，同一商品从不同仓发货时效与运费差别很大，且 Shopify 配送模板需绑定 fromCj:true 的仓库，不查清楚会刊登报 7001003。正确顺序是详情→查实时库存→查仓库位置加运费→再下单。 想用上这个技能？ 「CJ Dropshipping 接口助手」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
测试驱动开发怎么落地红绿重构循环
「TDD 开发指南」是「龙虾部署大师」技能市场中的测试驱动开发技能：作用是根据源码、目标框架或新功能需求，生成单元测试脚手架、happy path、错误路径和边界用例，解析覆盖率报告标注优先级缺口，准备 fixture 与 mock 数据，并按 RED、GREEN、REFACTOR 每个阶段给出验证要求，覆盖 Jest、Pytest、JUnit、Vitest、Mocha 等主流框架。 技能效果 把一个登录函数交给它补测时，它用 Pytest 写出正常登录、用户不存在、密码错误等用例，异常路径都用断言覆盖到位。 写测试这件事，为什么常常被拖着 测试该写、要写，但落地时总卡在几个点：补测试时不知道从哪开始，happy path 容易想到，错误路径和边界用例最容易漏，恰恰也最容易出 bug；覆盖率报告打出一长串未覆盖行，分不清哪些是核心分支、哪些可以缓一缓；测试数据准备成本高，造一组贴合实体的 fixture 和 mock 往往比写断言还费时；想按 TDD 先写失败测试再实现，却常常忍不住先写实现、回头补测试。这些摩擦叠加，测试就被一拖再拖。 最容易漏测的，往往最容易出 bug happy path 最常被覆盖 错误路径 常被遗漏 边界用例 最易出 bug，却最常漏 这个技能能帮你做哪些测试工作 它围绕测试驱动开发的全流程提供支持。生成测试方面，它能读 TypeScript、JavaScript、Python、Java 源码，自动产出测试脚手架以及 happy path、错误路径、边界用例。覆盖率分析方面，它解析 LCOV、JSON、XML 覆盖率报告，按 P0/P1/P2 标注哪些缺口最该先补。测试数据方面，它按实体生成 fixture 和 mock 样本，省去手工造数据。流程驱动方面，它按 RED（先写失败测试）、GREEN（写最小通过实现）、REFACTOR（重构）三个阶段推进，并对每个阶段给出验证要求。它还能在 Jest、Pytest、JUnit、Vitest、Mocha 之间适配，按项目语言切换框架。 红 → 绿 → 重构 循环 RED 写失败测试 GREEN 最小实现 REFACTOR 重构优化 先写失败测试再写实现，看似多一步，实则把"这段代码到底要满足什么"先用断言固定下来，实现自然更聚焦；覆盖率缺口按优先级排序，则保证有限的补测试时间花在最关键的分支上。 用前须知 该技能随附的脚本需要 Python 运行；具体生成与执行测试时，要按项目语言配置好 Jest、Pytest、JUnit、Vitest 或 Mocha。覆盖率分析需要你提供 LCOV、JSON 或 XML 格式的覆盖率报告，报告越完整，缺口标注越准确。 怎么用它 用法是把要补测的源码、覆盖率报告或新功能需求用自然语言交给它，由它生成用例、标注缺口或带着你走红绿重构。例如可以这样对它说： 可以这样对它说 "这个登录函数先按 Pytest 补单测，异常路径也要覆盖到断言里。" "看这份覆盖率报告，先挑最该补的分支写测试，登录失败优先。" "新做优惠券功能，先写失败用例再走红绿重构，别急着写实现。" 它适合这些场景：已有函数或模块缺单测，需要快速生成 happy path 与边界用例；覆盖率低于阈值，要定位未覆盖的错误路径和核心分支；新功能开发要求先写失败测试再实现最小通过代码；测试数据准备成本高，需要按实体生成 fixture 和 mock。适合软件工程师、测试工程师、技术负责人、开源维护者，以及希望把 TDD 引入日常开发的研发团队。 大家常问 测试驱动开发为什么要先写失败的测试、再写实现？ 先写一个失败的测试，等于把需求翻译成可自动验证的验收标准，开发到测试变绿就该停手，避免过度设计。看着它从红变绿，也能确认测试真的在检测目标行为；而且这迫使你以调用者视角先想接口该怎么用，设计自然更聚焦、更清晰。 TDD 的红-绿-重构循环每一步分别在做什么？ 红：写一个会失败的测试，确认它真的失败，描述你想要的一小段行为。绿：用最简代码让它通过，允许硬编码，只求最快变绿。重构：在测试保护下消除重复、改善命名结构，且不改变外部行为。三步一循环，每轮只推进一小步。 单元测试、集成测试和端到端测试有什么区别？ 单元测试只测单个函数或类、隔离外部依赖、毫秒级最快；集成测试验证多个模块间的协作与接口契约，可能用到真实或仿真依赖、秒级；端到端测试串起从界面到数据库的完整用户流程、最慢也最脆弱。三者互补，不能互相替代。 测试覆盖率高就代表测试做得好吗？ 不一定。覆盖率只反映哪些代码被执行过，不代表行为被正确验证——所有断言都是恒真也能跑到 100%。把它当硬性考核指标，还会诱导团队写只执行不验证的凑数测试。它更适合当探索工具，用来发现漏掉的分支和边界。 想用上这个技能？ 「TDD 开发指南」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
程序化 SEO 怎么做？按模板和数据批量产可排名页并监控
「程序化 SEO」是「龙虾部署大师」技能市场中的规模化建页技能：它基于模板和数据批量创建可排名页面，适合模板页、目录页、地点页、对比页、集成页等增长模式；从关键词模式、数据来源和竞争格局入手，设计 URL、标题、页面结构和 Schema 模板，规划内链架构与索引策略，同时守住"每页要有独特价值"的底线，避免门页和薄内容惩罚。 技能效果 为简历模板站规划程序化SEO时，它用多套页面类型叠加，避免薄内容，每类都有独立搜索意图。 想批量铺页面，风险在哪 程序化 SEO 的诱惑很直接：用一套模板乘以一批数据，一次性生成几百到几千个落地页，覆盖海量长尾词。但规模化本身就是风险来源。如果每个页面只是把变量套进同一个壳子、内容彼此雷同，就会被判定为薄内容或门页（doorway page），不仅排不上，还可能拖累整站。真正的难点不是"能不能批量生成"，而是"批量生成的同时，怎么让每一页都站得住"。 模板 × 数据 → 批量页面 模板 × 数据 每页有独特价值 → 可排名 内容雷同 → 薄内容/门页惩罚 同一种乘法，两种结局 这个技能能帮你规划什么 它把程序化 SEO 从"机会验证"一路推进到"技术落地"。机会层面，它评估关键词模式、变量组合、搜索需求分布和竞争可行性，判断哪些组合值得做；选型层面，它从模板、目录、对比、地点、集成等十二类 playbook 中选合适的规模化模式；模板层面，它设计 URL、标题、元描述、页面结构和 Schema 模板；架构层面，它规划 Hub-Spoke 内链、站点地图、索引优先级和质量监控。它始终强调每页必须有独特价值、匹配真实搜索意图、使用子目录结构，并提供上线后的质量检查与监控框架。 机会验证关键词模式/竞争 选 playbook12 类模式 页面模板URL/标题/Schema 内链与索引Hub-Spoke/监控 用前须知 该技能无需 API Key 或特定依赖，但规划要靠你提供业务数据、关键词调研和网站技术栈信息。要把规划变成上线页面，还需要 CMS、前端框架或静态生成能力的配合。它解决的是"页面体系怎么设计"，真正的页面构建依赖你的技术栈落地。 怎么用它 用法是把业务目标、可用数据和页面规模用自然语言交给它。例如可以这样对它说： 可以这样对它说 "为简历模板站规划程序化 SEO 页面，别做薄内容，先定页面类型。" "用城市和服务组合生成落地页，先看关键词模式和内链结构。" "这个工具目录页要扩到几百页，设计 URL 和模板，避免重复内容。" 它适合这些场景：产品拥有大量模板、工具、资料、地点或行业组合页机会；计划上线数百到数千个页面、但要避开重复和薄内容风险；拥有专有数据或用户数据、希望转化为搜索可见的页面资产；需要设计目录页、竞品对比页、集成页或本地服务页架构。它适合 SEO 负责人、增长团队、内容负责人、SaaS 创业者和技术市场团队。 大家常问 程序化 SEO 和普通 SEO 在做法上为什么不一样？ 普通 SEO 是逐篇创作、人工审核，靠单页投入抢头部词；程序化 SEO 改用「模板 + 数据」批量生产，覆盖海量长尾。规模一上来，质量控制就得在模板层做：差异化变量、独立的搜索意图分支、内链网络在模板阶段就规划好，否则页面只会变成关键词替换的复制品。 程序化 SEO 为什么容易踩到薄内容和重复内容惩罚？ 薄内容来自只换关键词的模板、数据量不足撑不起一页，以及全是公开数据拼凑没有信息增量；重复内容则是大量页面正文 60–80% 相似，搜索引擎归入近似重复，索引被选择性忽略。规避的核心不是「藏住模板」，而是让每页都有独立存在理由：差异化数据、意图精确匹配、元数据各自有信息增量。 同样是批量生成页面，为什么有的会被判为门页（doorway pages），有的不会？ 判定门页不看「批量」，看页面是否是用户的信息终点。若内容差异只是关键词替换、句法骨架完全一致、多个页面针对同一意图重复入口，就被算法聚类为门页。安全的程序化 SEO 让差异来自底层数据组合而非文本模板，每页提供完整可消费的信息，并按真实搜索需求量控制生成粒度。 程序化 SEO 里说的 Hub-Spoke 内链结构是什么意思？ Hub 是聚合主题的中心页，Spoke 是辐射出去的细分长尾页；Spoke 全部回链 Hub，相关 Spoke 之间再互链，形成网状结构。它解决程序化 SEO 三个核心问题：权重在主题集群内集中再分发、主题相关性向搜索引擎讲清楚、爬虫能高效发现所有页面而不留下孤儿页。 想用上这个技能？ 「程序化 SEO」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
Shopify加购增购策略，按场景规划升级套装提客单价
「Shopify 加购增购策略」是「龙虾部署大师」技能市场中的追加销售策略技能：它在产品页、购物车和购后感谢页设计 Upsell 升级与 Cross-sell 互补推荐，按主商品价格、毛利、使用场景和功能互补判断该推什么、推在哪里，目标是提高客单价和每访客收入。 技能效果 为买了瑜伽垫的订单设计购后增购时，它把推荐位放在订单完成的Thank-you页，搭配瑜伽砖和拉伸带的限时组合价，解释了为什么这样不打断主商品下单。 转化稳定了，客单价却抬不动 很多 Shopify 店铺把主商品转化做稳之后，会卡在另一个瓶颈：客单价上不去，每个访客带来的收入有限。问题通常不是没做加购，而是加购做得没章法——升级款和互补品分不清，配件推荐塞在错误的环节打断了下单，购物车里硬塞高价商品反而劝退，购后感谢页这个本该顺手追加的位置又空着。推荐位放几个、推荐什么价位、用什么文案引导，全凭感觉摆，自然带不动订单价值。 两种推荐，对应不同时机 Upsell 升级 同类换更好/更大包装 适合在产品页比对 Cross-sell 互补 配件/搭配品 适合购物车/购后追加 这个技能帮你设计什么 它把加购增购拆成"推什么、推在哪、用什么规则"来系统设计。在类型判断上，它区分 Upsell 升级与 Cross-sell 互补，为每种匹配最合适的展示时机；在关联规则上，它依据功能互补、场景绑定、耗材续购和礼品化组合来设计搭配关系；在推荐位规划上，它覆盖产品页、购物车和购后一键加购三个位置的展示方案；在落地支持上，它给出 Metafields、Recommendations API 和自动折扣的实现思路，并通过推荐位的位置、数量、标题和价格做实验持续优化。它还会守住分寸，比如购后追加的推荐品价格不宜超过主商品的一半，避免决策成本过高。 同一笔订单，三个位置接力提价 产品页 升级款 / 套装 购物车 低价互补配件 购后感谢页 一键追加 用前须知 该技能做的是策略设计，无需密钥即可直接使用。若要把推荐方案落地到 Shopify 原生能力上，需要店铺后台权限，以及 Metafields、Recommendations API 或 Checkout 扩展的配置。它给出的是组合规则与落地思路，实际配置在你的店铺中完成。 怎么用它 用法是把主商品、想提升的目标和约束用自然语言交给它，由它产出推荐组合与展示方案。例如可以这样对它说： 可以这样对它说 "瑜伽垫下单后推荐瑜伽砖和辅助带，出现在加购之后、别打断购买流程。" "购物车里加一个搭配购模块，规则按互补产品、价格和库存一起配。" "购后一键加购想提高客单价，推荐品价格别超过主商品的一半。" 它适合这些场景：主商品转化稳定但客单价偏低，需要设计大包装或升级款推荐；购物车阶段适合补充低价配件、提高订单附加收入；支付成功后想展示低决策成本的商品、实现一键追加购买；以及需要比较 2 个、3 个或 4 个推荐位对点击和收入的影响。 大家常问 电商里说的 Upsell（增购）和 Cross-sell（交叉销售/搭配购）有什么区别？分别适合在什么时候推？ 一句话记：Upsell 是"往上走"、让用户买更好更贵的同类款（如 128G 换 256G），看客单价；Cross-sell 是"往旁边走"、推不同类但相关的搭配品（如手机配壳和充电器），看连带率。Upsell 适合在还在决策的详情页和加购时推，Cross-sell 各阶段都能用、重在购物车和购后。本技能据购买阶段帮你匹配最佳展示时机。 为什么很多店铺转化率稳定，但客单价（AOV）一直上不去？提升客单价一般从哪几个方向入手？ 常见原因是客户愿意买、但不愿一次多买或买更贵：品类本身低频单买、页面缺搭配和升级引导、优惠策略单一、流量偏低价捡便宜。提升客单价可从六个方向入手——搭配套餐与加价购、满减满赠阶梯、升级款大容量、会员储值订阅、详情页购物引导、调整流量结构。本技能据主商品价格毛利和场景设计关联规则。 为什么推荐加购的商品价格不宜超过主商品太多？购后一键加购为什么更适合推低价配件？ 主商品价格会形成心理锚点，加购品一旦比它还贵就触发防御性比价，用户跳出去单独比价、订单流失，转化率随价格比上升而断崖下跌。购后一键加购发生在已付款的瞬间，用户转为"拥有者心态"、只问配不配套不再比价，且无需重走支付、摩擦近零，低价配件决策成本最低、顺手就买，是纯增量。本技能按这些原则设计推荐。 在商品页、购物车、购后感谢页这三个位置做追加推荐，效果和侧重点有什么不同？ 三个位置分工不同：商品页处于浏览决策阶段，推搭配和升级、负责让用户买更多品类，当期转化中等；购物车即将付款，推凑单和强关联，当期转化和客单价拉动最强，但别挡住结算按钮；购后感谢页已付款，推复购钩子和下一场景，当期几乎不增收却对复购很强。本技能会按位置规划推荐方案与数量。 想用上这个技能？ 「Shopify 加购增购策略」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
本体建模是什么 和知识图谱区别
「本体知识建模」是「龙虾部署大师」技能市场中的知识图谱技能：用实体、属性和关系表示人员、项目、任务、文档、事件等对象，变更以追加日志写入 graph.jsonl，并可通过 schema 约束必填字段、枚举、关系类型和无环依赖，帮助多个技能共享结构化状态并保留可追溯的历史。 技能效果 让它记住“Alice 负责官网改版、关联到三月发布”，它把人物和任务建成结构化本体，连 responsible_for、part_of 两条关系链和查询命令都生成好了。 让 AGENT 记住事情，为什么这么难 让代理"记住"某个人负责什么项目、某个任务被谁阻塞，听起来简单，做起来却容易散。把信息写成自由文本，时间一长就互相矛盾、查不回去；每个技能各自维护一份状态，就成了互不相通的数据孤岛；想表达"任务 A 阻塞任务 B"这类关系，纯文本既存不住结构，也无法做类型检查和合法性校验。结果是记录越积越多，可靠地查询、关联和复用却越来越难。 自由文本记忆 散落的笔记 互相矛盾 技能各存一份 · 孤岛 类型化知识图谱 人员 项目 任务 负责 包含 这个技能用什么方式管理知识 它提供一个类型化的知识图谱：把人员、组织、项目、任务、事件、文档、消息、笔记、账户、策略等都建成带类型的实体对象，再用 has_owner、blocks 这类关系把它们连起来，且关联是幂等的（重复建立不会产生脏数据）。所有变更以追加日志的形式写入技能目录内的 graph.jsonl，因此保留完整的可追溯历史；通过 schema.yaml 可以约束必填属性、枚举值、关系类型、基数以及无环依赖，对知识库结构施加类型检查。查询、遍历和过滤则用来获取任务、依赖、文档与上下文。 创建实体 / 关联 schema 校验必填 / 枚举 / 基数无环依赖 追加日志graph.jsonl可追溯历史 查询 / 遍历多技能共享 用前须知 该技能无需外部 API Key。首次使用需运行 Python setup 脚本安装依赖；数据保存在技能的 memory/ontology 目录下，已有的日志和 schema 应以追加合并的方式处理，而不是覆盖。它支持后续扩展到 SQLite。该技能偏向开发者与自动化场景，用于构建可验证、可追溯的结构化状态。 怎么用它 用法是用自然语言告诉它要记住的对象、关系，或要查询的内容。例如可以这样对它说： 可以这样对它说 "记住 Alice 负责官网改版，并把它关联到三月的发布任务，别丢掉关系链。" "查一下 CRM 项目下面还有哪些处于阻塞中的任务，按负责人分组列出来。" "把这份会议纪要连到增长实验项目和参会人，保留文档路径和来源。" 它适合这些场景：需要让代理记住某个人、项目、任务或文档，并能在后续查询；多步骤计划需要表示为可验证的图变更、依赖关系和回滚步骤；跨技能共享任务、承诺、事件等状态，避免各自维护孤岛数据；希望对知识库结构施加类型检查、关系基数和无环约束规则。 大家常问 本体知识建模到底是什么？用实体、属性、关系来表示知识是什么意思？ 本体是对一个领域的概念及其关系所做的形式化、明确的规格说明，它定义"知识应该长什么样"。建模时把世界里有身份的事物建成实体，用属性描述实体自身的特征，用关系连接实体之间的连线，于是知识不再是散乱词语，而是一张可计算、可共享、可校验的网。 本体和知识图谱有什么区别？ 本体是模式层，规定有哪些概念、属性、关系和约束，相当于一张带规则的蓝图；知识图谱是在这张蓝图上填充大量实例数据所形成的关系网络，是数据层。一句话：本体定义知识结构，知识图谱把真实数据装进去。知识图谱可以基于本体构建，也可以没有严格本体约束。 is-a（是一种）关系和 part-of（是一部分）关系有什么区别？ is-a 是分类归属，子类的每个实例也是父类实例，并自动继承父类属性，判断靠"替代性测试"——能不能用子类替换父类。part-of 是组成结构，部分不继承整体的属性，判断靠"删除测试"。常见错误是把方向盘建成"是一种汽车"，正确应是"汽车的一部分"。 为什么要给本体知识建模加 schema 一致性约束（必填、枚举、基数、无环依赖）？ 约束是本体区别于术语表和松散图谱的本质特征。必填属性保证实例的最低知识完整度，枚举值把取值限定在有界集合避免语义漂移，基数约束让关系网络有确定拓扑，无环依赖保证层次结构有效、推理能终止。没有约束，知识虽自由却无法被一致地计算。 想用上这个技能？ 「本体知识建模」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
提示