本体建模是什么 和知识图谱区别
「本体知识建模」是「龙虾部署大师」技能市场中的知识图谱技能：用实体、属性和关系表示人员、项目、任务、文档、事件等对象，变更以追加日志写入 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 模型能力有关，不同模型下的表现可能存在差异。
如何用 AI 按条件选股
「智能选股」是「龙虾部署大师」技能市场中的股票池筛选技能：它基于东方财富妙想 API，用自然语言按行情指标、财务指标、行业、板块、指数成分股等条件筛选 A 股、港股、美股、板块和 ETF，输出可直接打开的 CSV、结果说明和原始 JSON，帮助快速形成候选股票池。 技能效果 做今日选股时，它筛出涨幅超2%、成交额靠前的二十只A股，按半导体、PCB等板块分组，列出涨幅、成交额和换手率。 选股条件一多，筛起来就吃力 投研前期常要从全市场里圈出一批候选股：今天涨幅超过某个阈值的、市盈率低于某个倍数且股价高于某个价位的、某个行业里近期放量的。条件单看简单，叠在一起手工筛就吃力——要在不同筛选器之间反复切换、把结果导出再合并，口径稍有不一致就得重来。靠大模型凭记忆"推荐几只"更不可取，它的数据可能早已过时。「智能选股」要做的，是把自然语言条件直接翻译成对官方接口的筛选请求，一次跑出候选池。 多条件层层过滤，收敛成候选池 全市场标的 行情条件（涨幅/换手） 财务条件（PE/股价） 候选股票池 这个技能能帮你做什么 它的核心是"按条件筛"，和单纯查价格、查资讯不同。解析层面，它把自然语言选股条件解析为行情、财务或板块筛选请求；范围层面，支持 A 股、港股、美股、ETF、行业板块和指数成分股查询；输出层面，产出可直接打开的 CSV、结果说明和 API 原始 JSON；校验层面，它会核对接口状态、字段映射和返回数量，并提示空结果该如何处理。这样得到的候选清单基于实时官方数据，避免依赖大模型的过时信息做基础筛选。 自然语言条件涨幅/PE/行业 妙想 API 筛选 CSV 候选池+ 说明 + 原始 JSON 基于实时官方数据，按组看 用前须知 该技能需要东方财富妙想 API Key，通过 MX_APIKEY 环境变量设置；它用 Python 脚本输出 CSV、说明文本和原始 JSON，数据来自官方 API。它做的是按条件筛选、形成候选池，不对个股做推荐或评级，结果仅供研究参考，不构成投资建议。 怎么用它 用法是把选股条件用自然语言说清楚，并指定排序或取数口径。例如可以这样对它说： 可以这样对它说 "筛出今天涨幅超过 2%、成交额靠前且换手率不低的 A 股前二十只，按组看。" "找市盈率低于 20 倍、股价大于 50 元的沪深 300 银行股，按股息率排序。" "港股里股价大于 50 元、近三日放量的公司有哪些，按成交额降序，把口径写清。" 它适合这些场景：筛选今日涨幅超过特定阈值的 A 股或板块成分股；查找股价、市盈率、行业属性共同满足条件的股票；投研前期从自然语言条件生成候选股票清单；以及在模型知识可能过时时，用实时官方数据完成基础筛选。适用于投研助理、量化研究初学者、财经运营和需要快速形成股票候选池的数据分析人员。 大家常问 为什么按多个条件组合选股，通常比只看单一指标更可靠？ 单一指标只反映一个维度，低 PE 可能是价值陷阱、高 ROE 可能靠高杠杆堆出来。多条件取交集能让信号纯度提升、缩小踩雷概率，基本面、技术面、资金面互补，分别回答买什么、有没有人买、什么时候买，相互印证时决策才更稳。 基本面选股和技术面选股，本质上有什么区别？ 基本面选股研究企业价值，看 PE、PB、ROE、营收增速等财务数据，时间尺度偏中长期，假设价格终将回归价值；技术面选股研究市场行为，看均线、量价、MACD 等信号，时间尺度偏中短期，假设历史模式会重复。两者并非对立，常用基本面建池、技术面择时。 按条件筛出来的候选股票池，为什么不能直接当成买入名单？ 条件选股的本质是缩小关注范围，而不是确认买入价值。候选池还需经过定性分析、估值评估、风险管理和持续跟踪——财务指标覆盖不了管理层、行业格局、政策等因素。历史表现不代表未来收益，任何选股逻辑都消除不了市场的不确定性。 选股时为什么通常要先加上市值和流动性的过滤条件？ 市值和流动性过滤往往放在筛选第一层，原理有三：小市值低成交额的股票价格易被少数交易左右，产生伪信号、扭曲指标；缩小样本能降低多重比较带来的过拟合风险；更现实的是保证策略可执行，避免冲击成本过大或买不进卖不出。它是数据可信、样本合理、策略可执行的共同保障。 想用上这个技能？ 「智能选股」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
如何用 AI 制定减脂计划
「健康减脂顾问」是「龙虾部署大师」技能市场中的减重规划技能：作用是根据你的身体数据、健康限制、运动基础和饮食条件，算出科学的减重方案——它会计算 BMI、BMR、TDEE 和建议的热量缺口与周期，生成 4 周渐进的运动计划、每日食谱框架和执行检查清单，并提示医学边界和危险信号识别标准。 技能效果 给出身高体重让它做减脂计划，它先估算了BMI和每日消耗，再排出四周递进的方案，把每周的摄入热量和运动频率列成表。 减重总是反复，问题常常出在"凭感觉" 大多数减重失败，并不是不够努力，而是缺乏量化依据。常见三种误区：一是热量没算清，不知道自己每天该吃多少、缺口留多大，要么饿到坚持不了，要么明明在控制却毫无变化；二是运动饮食两张皮，只盯着运动或只盯着吃，没有把两者放进同一个能量账里；三是不会判断进度，两周没动就慌、下降太快又不知道是否伤身。减重本质是能量缺口的管理，把摄入、消耗和目标算清，方向才稳。 能量账：消耗 > 摄入 = 减脂 每日摄入 饮食
Supabase 的 RLS 行级安全怎么配
「Supabase Postgres 最佳实践」是「龙虾部署大师」技能市场中的数据库诊断优化技能：作用是先收集诊断数据、再按问题类型选择工作流，定位慢查询、缺失索引、连接过多和 RLS 性能问题，并给出可用 EXPLAIN 验证的 SQL 修改、索引方案、连接池配置和监控建议，把"凭经验猜"换成"按证据查"。 技能效果 面对一条大表上很慢的 Supabase 查询时，它先讲清没索引时会全表扫描加排序，再给出该建的复合索引和优化后执行计划会怎么变。 Supabase 数据库变慢，常见症状有哪些 Supabase 上的 Postgres 性能问题往往以几种典型症状出现：接口超时、查询慢得离谱，多半是慢查询或缺了索引；频繁报 Too many connections，通常是连接池配置或连接泄漏；开了行级安全（RLS）之后接口突然变慢，问题常在策略函数的写法和它能不能用上索引；还有表数据量涨上来后，没有合适的复合索引或分区，查询逐渐拖垮。这些症状有时单独出现，有时几个叠在一起，单靠肉眼看 SQL 很难判断根因。 四类常见症状 → 对应根因 查询超时 / 慢慢查询 · 缺索引 连接数爆掉连接池 · 泄漏 开 RLS 后变慢策略函数 · 索引 表越来越大复合索引 · 分区 先收诊断数据 这个技能能帮你诊断和改什么 它的工作方式是"先取证、再开方"：要求先读取相关规则、收集诊断数据，再按 Too many connections、慢查询、RLS 变慢、连接池配置或多症状这几类问题选择对应的工作流或参考规则，通过必要的门禁查询后才给建议，避免凭经验误判。覆盖的诊断维度包括查询性能、连接管理、安全 RLS 和 Schema 设计，可以定位慢查询的成因、缺失的索引、连接耗尽、RLS 策略的性能开销，并给出复合索引、部分索引、分区方案、权限检查和连接池配置。关键是每条修改建议都配 EXPLAIN 验证步骤，让你能确认改动真的生效。 读规则收诊断数据 选工作流按症状分类 门禁 + 定位根因索引/连接/RLS 给方案 + EXPLAIN可验证改动 把"先收集证据再下结论"做成强制门禁，正是这套实践和随手调优的区别：数据库性能问题最忌猜，EXPLAIN 验证保证给出的索引或改写确实改善了执行计划，而不是看起来合理。 用前须知 核心指南无需密钥即可参考；其中的诊断脚本（如 pg_diagnose）需要 Python 与数据库连接串才能运行。连接 Supabase 或 Postgres 实例时，应使用只读或受控权限，并妥善保护连接凭据，避免在诊断过程中误改生产数据。 怎么用它 用法是把数据库当前的症状用自然语言描述给它，由它按流程取证、定位并给出可验证的方案。例如可以这样对它说： 可以这样对它说 "Supabase 查询老超时，先跑诊断，再看是不是缺索引、执行计划哪里有问题。" "开了 RLS 之后接口变慢，检查一下策略写法、函数调用和过滤成本。" "连接数经常爆掉，按连接池和慢查询一起排查 Postgres 的瓶颈。" 它适合这些场景：Supabase 项目出现慢查询、超时或 Too many connections 错误；启用 RLS 后接口变慢、需要检查策略函数和索引使用；表增长后要设计复合索引、部分索引或分区策略；上线前要审查 SQL、权限、连接池和监控配置是否安全。适合 Supabase 开发者、后端工程师、数据库管理员、全栈团队，以及要优化 Postgres 性能与安全策略的技术负责人。 大家常问 Supabase 的 RLS（行级安全）到底是什么，为什么一定要开 RLS 是 Postgres 内置的行级安全：把"哪一行谁能看、谁能改"的规则下沉到数据库，执行每条 SQL 时逐行评估策略，返回 true 才放行。Supabase 客户端直连数据库，不开 RLS 时任何拿到 anon key 的人都能读全表，所以它是匿名访问下的最后一道防线。 为什么 Supabase 开了 RLS（行级安全）之后接口反而变慢了 RLS 不是查询前的一次性闸机，而是给每行追加策略判断的 WHERE。最常见的坑是策略里裸写 auth.uid()，它会被逐行调用；用 (SELECT auth.uid()) 包一层就只算一次。另外策略涉及的列若没建索引，会退化成全表扫描，表越大越慢。 为什么 Postgres 查询缺了索引就会变慢 没有索引时 Postgres 只能顺序扫描（Seq Scan），从头到尾逐页读完整张表再筛选，代价随行数线性增长；有 B-Tree 索引则直接定位到目标行，代价几乎恒定。表越大差距越大，百万行级别可相差上万倍，EXPLAIN 里能直接看到 Seq Scan 还是 Index Scan。 Supabase 为什么会报 Too many connections（连接数爆掉） Postgres 是进程模型，每个连接占 1-3MB 内存且套餐有上限，超过 max_connections 就拒绝新连接。常见原因是应用没走连接池、Serverless 函数每次冷启动都新建连接、连接泄漏未归还，或直连 5432 而非走 PgBouncer 的 6543 端口。改用连接池复用少量真连接即可缓解。 想用上这个技能？ 「Supabase Postgres 最佳实践」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
批判性阅读怎么做才算读懂一篇文章
「深度阅读分析」是「龙虾部署大师」技能市场中的长文研读技能：支持 URL、PDF、DOCX、TXT 和粘贴文本输入，先提取正文，再按快速、标准、深度、研究四级模式调用 SCQA、5W2H、批判性思维、第一性原理等框架，把长文拆成核心论证，并输出可复用的学习笔记、写作素材或决策框架。 技能效果 让它深读一篇正念训练与工作记忆的实证论文，它拆出 SCQA 与 5W2H、揪出剂量不匹配和缺中介分析等四处漏洞，再给论证强度打了 6.5 分并列出该补的引用。 长文读完就忘，问题出在哪 论文、报告、策略长文读起来都费时，但"读过"和"读懂、能用"之间常常隔着一道坎。很多人通读一遍后只留下零散印象：抓不住核心主张，分不清哪些是事实、哪些是作者观点；看不出论证里的证据强弱和逻辑漏洞；想引用或落地时，又得回头重读。归根结底，是缺少一套和阅读目的匹配的拆解方法，于是阅读停留在"看完"，没有沉淀成可复用的结构化产物。 长文论文/报告 通读一遍 零散印象抓不住主张/分不清事实观点 要用时回头重读 这个技能怎么把长文读"透" 它先识别输入类型（URL、PDF、DOCX、TXT 或粘贴文本）并提取正文，再询问你的阅读目的、想要的分析深度和偏好框架，然后按四级模式推进——快速、标准、深度、研究，深度越高调用的思维框架组合越完整。可用的框架包括 SCQA、5W2H、批判性思维、逆向思维、第一性原理、系统思维等，用来拆解核心论证、评估证据质量、找出逻辑缺口。它在输出时会刻意保留事实、观点和行动项的边界，便于后续验证和复用。 提取正文URL/PDF/DOCX 按目的选深度，调用框架 快速 · SCQA 标准 · 5W2H 深度 · 批判性 研究 · 第一性原理 结构化产物 学习笔记 / 写作素材 决策框架 / 行动项 保留事实 · 观点 · 行动边界 用前须知 该技能无需 API Key。处理 PDF / DOCX 时，正文提取依赖 Python 及 pdfplumber、python-docx 或 docx2txt；输入 URL 时需要网络可访问该内容。它做的是结构化拆解与提炼，关键事实和引用仍建议回到原文核对。 怎么用它 用法是把要读的材料（链接、文件或粘贴文本）交给它，说清阅读目的和想要的深度。例如可以这样对它说： 可以这样对它说 "这篇论文按标准深度读，帮我拆出主张、证据和逻辑漏洞，再评估论证强度。" "这份报告太长，做成学习笔记，列出可用的框架，最后提三条可执行的动作。" "把这篇文章用 SCQA 和逆向思维分析，找出可以落地的启发，别只做摘要。" 它适合这些场景：阅读研究论文时，需要提炼核心假设、证据质量和局限性；处理商业长文或策略报告，希望得到可落地的行动方案；为写作引用整理关键论点、证据、反方视角和内容缺口；面对复杂决策材料，需要从多个角度评估风险、收益和备选项。 大家常问 什么是批判性阅读？它和普通通读一篇文章有什么不同？ 批判性阅读是带着审视和质疑去读，主动分析、评估、重构文本，而不是被动接收信息。普通通读像观众看电影，跟着内容走，读完只剩大致印象；批判性阅读像影评人，要追问作者想证明什么、论据是否可信、有没有漏洞，最后沉淀成结构化笔记。 读一篇文章时，怎么区分哪些内容是事实、哪些是作者的观点？ 一条简单法则：事实可以用对错检验、能追溯能验证，观点只能用好坏或应该来评论。看信号词，「研究表明」「根据数据」多是事实陈述，「我认为」「应该」「最好」多是主观或价值判断。可以用两种标记分别标事实和观点，若观点远多于事实，论证基础就值得怀疑。 要评估一篇文章里的论据是否可信，可以从哪些方面入手？ 不能只看有没有引用，而要逐一考察：来源是一手还是转述、是否权威可追溯；数据的时效性；样本是否充分且有代表性；从数据到结论有没有逻辑跳跃；是否回应了对立观点；有无利益冲突；结论是否可被公开验证或复现。模糊引用如「有专家指出」往往是危险信号。 拆解一本书或一篇长文的论证结构，到底是在拆哪些东西？ 拆的是作者的思维骨架：先提取主旨和分论点，区分哪些是论述、哪些是论据；再看论证类型是演绎、归纳、类比还是因果，把隐含前提显式化，检查从前提到结论有没有逻辑断环。注意别把选题范围当主旨，也别把概念当成主张。 想用上这个技能？ 「深度阅读分析」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 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 模型能力有关，不同模型下的表现可能存在差异。
提示