如何用 AI 构建知识库
「LLM 知识库构建」是「龙虾部署大师」技能市场中的知识库技能：作用是基于扁平 Markdown 文件实现文档入库、查询、链接索引、OCR 和矛盾检测，无需数据库。入库时它感知现有 wiki 状态，判断该新建还是更新页面；查询时基于页面摘要选定起始页、遍历 Wikilinks、综合作答并返回来源。脚本负责结构与读写，LLM 负责语义判断，既保留原始文件，又能持续维护一个便于追踪来源的知识库。 技能效果 把三条带 [[双链]] 的笔记交给它入库时，它解析出各页面的出链入链关系，画了反向链接图谱，并把「向量数据库→Embedding→RAG」这条知识链梳理成表。 散落的文档，为什么越攒越查不动 很多团队的资料其实不少，难的是把它们变成能查、能维护、能追溯的知识库。文档格式杂——PDF、图片、Office、Markdown 混在一起；新增资料时，到底是该建新页面还是更新旧页面，靠人判断既慢又容易留下重复条目；查一个问题，往往要在多份文件里翻找，还说不清答案出自哪一页。更麻烦的是时间一长，不同文档之间会出现互相矛盾的说法，却没人发现。攒得越多，反而越查不动。 PDF 图片 Office 散乱、重复、矛盾 入库 + 语义判断新建 or 更新 Markdown 知识库 页面 + 摘要 + 双向链接 可追溯来源 这个技能怎么把文件变成可查知识库 它的核心思路是分工：脚本负责结构、读写和遍历，LLM 负责语义判断，全程基于扁平 Markdown 文件、不依赖数据库。入库时，用 ingest_file 把 PDF、图片、Office、Markdown 等文件吸收进来，并感知现有 wiki 状态——能合并的更新旧页面，确需新增的才建新页，避免重复。查询时，它先按页面摘要选定起始页，再遍历 Wikilinks 双向链接，综合得出答案并返回来源页面和遍历路径。维护层面，它生成并校验 Wikilinks 索引、识别孤立页面，还能执行 OCR 和矛盾检测，把结果连同版本记录一并保存。因为原始文件始终保留，知识库可以长期演进、来源可追。 入库ingest_file 查询摘要选页/遍历链接 索引Wikilinks/孤立页 校验OCR/矛盾检测 用前须知 该技能需要本机具备 Python，依赖 requests 2.28.0 及以上与 pyyaml 6.0 及以上；认证从 ~/.AI agent/ 目录自动读取。处理大文档时，建议把执行超时提高到 1 小时，以免长文档入库或 OCR 中途被打断。 怎么用它 用法是把要入库的文件或要问的问题用自然语言交给它，由它判断入库方式或遍历作答。例如可以这样对它说： 可以这样对它说 "把这些 Markdown 笔记入库，自动生成页面、摘要和双向链接。" "新增会议纪要时检查旧页面，能合并的就更新，别新建重复页面。" "问知识库里某个主题的内容，按摘要选页再综合回答，并给出来源和脉络。" 它适合这些场景：个人或团队希望把散落文档编译成 Markdown 知识库；查询知识库问题、需要返回答案、来源页面和遍历路径；新增资料可能更新已有页面、需要由判断新建还是合并；知识库长期维护中、需要检测页面之间的矛盾和孤立链接。 大家常问 为什么 LLM 直接作答容易出现幻觉，需要外挂一个知识库？ 大模型本质是按概率续写下一个 token，参数里只有训练截止前的知识，且生成过程不会主动查证。遇到记不清或没见过的内容，它仍会生成语法通顺却无来源的文字，这就是幻觉。外挂知识库的作用是在生成路径上插入"检索→验证"环节，让模型基于真实文档片段作答而非凭空生成。 知识库里的分块（chunking）是什么意思，为什么不能把整份文档直接丢进去？ 分块是把长文档切成语义连续的小段（通常 256–1024 token，留 10%–20% 重叠），每段独立做向量化和检索。整份丢进去会撞上上下文窗口上限，关键信息也会被海量无关文本稀释，无法精准命中。先切块再检索，才能把最相关的几段拼进 prompt 给模型作答。 知识库回答问题时为什么要返回来源页和遍历路径？ 检索召回是基于语义相似度的近似匹配，重排序又是模型内部的黑箱打分，单看答案无法判断结论是不是真被原文支持。返回来源页让用户能跳回原文核对，遍历路径展示这段内容在文档章节里的层级位置——这是把"黑箱生成"变成"可验证引用"的必要环节，也是幻觉发生时人工纠错的入口。 同一份资料再次入库时，为什么建议合并旧页面而不是直接新建？ 直接新建会在向量空间里制造大量近似副本：检索时 Top-K 被同义副本挤占、多样性下降，重排序分数失稳，倒排索引词频膨胀让混合检索权重失衡，引用路径碎片化让溯源失真。更糟的是旧版与新版内容矛盾时模型会同时引用产生自相矛盾的回答。合并能保持 chunk 集合幂等，从源头压低信噪比恶化。 想用上这个技能？ 「LLM 知识库构建」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
如何用AI写专利申请文件
「专利撰写」是「龙虾部署大师」技能市场中的专利文本起草技能：作用是把一项发明披露，从可专利性预评估，到独立权利要求、从属权利要求与说明书框架的撰写，再到现有技术风险与司法辖区差异的标注，整理成一份可防守、可继续修改的专利草案。它重点覆盖 USPTO 实务，并兼顾 CNIPA、EPO 和 PCT 的规则差异。 技能效果 把一套AI视觉质检流程描述给它，它先从新颖性、创造性逐项评估可专利性风险，再起草权利要求，并提醒咨询专利代理师。 专利申请文件难在哪里？ 专利申请最难的不是有发明，而是把发明写成一份既站得住脚、又有保护范围的法律文本。一份草案要同时回答几个不在同一维度上的问题：这个方案到底新不新、相对现有技术有没有非显而易见的进步、属不属于可授权的客体、说明书有没有充分公开。任何一项没处理好，后续都可能在审查阶段被驳回。 更现实的难点在于权利要求的"范围取舍"。写得太宽，容易被现有技术覆盖而被驳回；写得太窄，又留下大量绕开空间，专利形同虚设。同一发明在美国、中国、欧洲和 PCT 体系下的撰写口径还不一样，发明人和研发团队往往缺少时间逐条比对这些规则。 权利要求范围怎么取舍 范围太宽 易被现有技术 覆盖、被驳回 范围太窄 易被绕开 保护形同虚设 这个技能能帮你做什么？ 这个技能把专利草案的撰写拆成"先评估、再起草、后标注风险"三个环节。预评估阶段，它从新颖性、非显而易见性、专利适格性和公开充分性四个维度,对发明披露做初步判断，把潜在风险先说清楚；起草阶段，它撰写可防守的独立权利要求、从属权利要求，以及方法、系统、装置和计算机可读介质（CRM）的权利要求组合，并搭起背景、摘要、详细描述和多实施例的说明书框架；收尾阶段，它标注现有技术差异、司法辖区差异和权利要求范围取舍，便于形成后续的检索和代理沟通材料。 它还能针对审查意见组织答复：分析现有技术差异、区分发明特征，辅助回应 102（新颖性）、103（非显而易见性）、101（适格性）和 112（公开充分性）类驳回。 发明披露 方案 + 目标市场 可专利性预评估 新颖 / 非显而易见 起草权利要求 独立 / 从属 / CRM + 说明书框架 风险标注 + 代理建议 用前须知 该技能无需 API Key 或本地依赖。但需要明确：它输出的是法律技术草案，不能替代注册专利律师或专利代理师的意见，更不构成正式法律建议。任何正式提交都应由目标法域的专业人员审核定稿，草案中标注的现有技术风险与范围取舍也仅供参考。 怎么用它？ 用法是把发明方案、目标提交体系，或收到的审查意见，用自然语言交给它，无需记忆权利要求的格式规范。例如可以这样对它说： 可以这样对它说 "按 USPTO 口径给这个方案写系统权利要求和三个从属项，别用 means for 的写法。" "这件申请被 103 驳回了，帮我整理区别点和答复思路，按审查意见逐条来写。" "这个软件方案打算走 PCT，先做可专利性预评估，再起草独立权利要求，把现有技术风险标出来。" 它适合这些场景：发明人需要把软件、硬件、机械或生物技术方案转成权利要求草案；提交前想判断最接近的现有技术和整体可专利性风险等级；收到 USPTO 审查意见后需要组织修改、区分特征和答复论证；计划在多个法域提交、需要先比较关键规则差异。它服务于草案准备和风险预评估，最终定稿仍交由专业代理人完成。 大家常问 独立权利要求和从属权利要求是什么关系？ 独立权利要求列出实现发明所必需的全部必要技术特征，从整体上限定保护范围；从属权利要求引用在先权利要求，在其基础上再补充附加技术特征。两者构成一棵权利要求树：根是独立项，分支是从属项，从属项的特征集合是独立项特征集合的超集，用来给出更具体的优选方案或实现方式。 专利说明书里的「充分公开」具体指什么？ 充分公开是中国《专利法》第二十六条第三款的核心要求：说明书要把发明写得清楚、完整，让所属技术领域的技术人员能够照着实现。本质是以公开换保护——披露技术方案换取排他权。每个权利要求特征都必须在说明书里有对应的技术手段、参数或实施例支撑，参数范围还要有中间和端点实施例，否则就构成公开不充分。 USPTO 的 103 驳回和 102 驳回有什么区别？ 102 是新颖性驳回，标准是一份对比文件就公开了权利要求的全部技术特征，看的是「别人已经做过」。103 是创造性驳回，允许多篇对比文件组合，要论证本领域普通技术人员存在组合的教导、启示或动机，并有合理的成功预期，看的是「别人稍微一想就能做」。前者偏事实比对，后者偏法律推理。 想用上这个技能？ 「专利撰写」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
Shopify开发怎么落地？覆盖Liquid主题和API
「Shopify 开发」是「龙虾部署大师」技能市场中的店铺开发参考技能：它面向 2026-01 API 版本，覆盖 Liquid 模板、OS 2.0 主题、GraphQL Admin 与 Storefront API、Ajax 购物车、应用、Functions、Hydrogen 等开发主题，按需求给出主题代码、API 调用示例、扩展实现思路和迁移排障建议。 技能效果 要在商品页按选中变体显示库存时，它写出了判断现货、仅剩N件、缺货的Liquid代码片段，顺手把集合页过滤器写规范，还说明显示不对怎么结合日志定位。 Shopify 开发栈太宽，资料总在四处找 Shopify 的技术栈横跨好几层：前端有 Liquid 模板和 OS 2.0 主题，数据有 GraphQL Admin 和 Storefront API，交互有 Ajax 购物车，业务规则有 Functions，无头店面又是 Hydrogen 那一套。每一层的语法、对象、版本约定都不一样，开发者要么在官方文档里来回翻，要么凭旧经验写、再被废弃提示打回来。尤其是版本演进——Scripts 要迁到 Functions、Polaris React 要换成 Web Components，这些迁移路径如果没人梳理清楚，很容易写出过时的实现。 同一个店铺，要同时面对几层技术栈 前端层：Liquid · OS 2.0 主题 交互层：Ajax 购物车 API 数据层：GraphQL Admin/Storefront 业务层：Functions 无头层：Hydrogen 店面 迁移：Scripts → Functions Polaris → Web Components 这个技能能帮你查到什么 它是一份覆盖完整 Shopify 开发栈的参考，按你手头的任务给出对应资料。主题方向，它梳理 Liquid 的标签、过滤器、对象和 OS 2.0 主题架构，支持你改 .liquid 模板或 JSON section；API 方向，它指导 GraphQL Admin、Storefront 和 Ajax API 的安全调用；扩展方向，它支持应用、Functions、Hydrogen 和扩展的开发路径；工程方向，它提供性能优化、废弃迁移和 Liquid/API 的故障排查参考。输出包括主题代码、API 调用示例、扩展实现思路、迁移提示和排障建议，帮你按官方栈把功能落地。 说清你的需求 改主题/集成/迁移 匹配对应栈资料 按 2026-01 版本 代码示例 + 迁移/排障 用前须知 建议本地安装 Node.js 与 Shopify CLI（npm install -g @shopify/cli）。调用 Admin/Storefront API 需要店铺访问令牌，主题开发需要相应的 Shopify 店铺权限。该技能提供的是开发参考与代码思路，实际部署到店铺仍由你在自己的环境中完成。 怎么用它 用法是把开发任务和约束（哪个接口、哪个版本、要不要迁移）用自然语言交给它，由它给出对应的代码与思路。例如可以这样对它说： 可以这样对它说 "这个 Liquid 模板要显示变体库存，顺便把过滤器写得更规范一些。" "帮我把旧的 Scripts 迁到 Functions，说明实现方式和部署步骤。" "Hydrogen 页面要拉商品数据，查询按新版接口写，并说明缓存策略。" 它适合这些场景：需要修改 .liquid 模板或 JSON section 来实现自定义商品展示；应用需要通过 GraphQL Admin API 读取或变更商品、订单数据；主题购物车交互异常、要排查 Ajax API 或 JavaScript 问题；以及从 Scripts 或 Polaris React 迁移到 Functions 与 Web Components。 大家常问 Shopify 的 Scripts 和 Functions 有什么区别？为什么现在要从 Scripts 迁移到 Functions？ 两者都用来写购物车折扣、运费、支付限制等自定义逻辑，但 Scripts 用 Ruby、只兼容旧版结账、共享运行时、难调试；Functions 编译成 WebAssembly 跑在独立沙箱、执行时间有上限、用 Shopify CLI 部署、支持版本管理。要迁移是因为旧版 Checkout 正被淘汰，Scripts 已停更，新功能只基于 Functions 开发。本技能可给出迁移路径与实现思路。 Shopify 主题开发里说的 OS 2.0 和老主题有什么区别？Liquid 模板和 JSON section 是什么关系？ OS 2.0 把编辑权还给商家：所有页面都能在可视化编辑器里拖拽配置、原生支持元字段、App 通过 App Blocks 注入不易冲突；老主题大多硬编码在 Liquid 里、商家改不了。关系上，JSON 模板是"布局清单"，列出页面用哪些 section、顺序和参数；Liquid section 是"功能单元"，定义长什么样、取什么数据。本技能按这套架构给主题代码。 Shopify 的 Hydrogen、无头（Headless）店面是什么意思？和直接改 Liquid 主题有什么区别？ 无头是把前端（头）和 Shopify 后端（身体）分离：后端仍管商品库存结账，前端自选 React/Vue 等技术栈，通过 Storefront API 取数据，性能和定制自由度更高但开发运维更重。Hydrogen 是 Shopify 官方的无头 React 框架、内置电商组件。改 Liquid 主题则是一体化、开箱即用、适合多数中小商家。本技能能讲清各路径取舍与落地。 Shopify 主题里购物车交互（加购、改数量）异常，一般和 Ajax Cart API 是什么关系？ 主题购物车的加购、改数量在前端通过 Ajax Cart API 异步操作：/cart/add.js 加购、/cart/change.js 改数量、/cart.js 取购物车，不刷新页面就更新数据。交互异常多在这条链路上：JS 没绑定事件就请求不发出、回调没刷新 UI 就角标价格不动、特殊 SKU 会返 422。本技能可对照 Network 请求与 API 返回逐项排查。 想用上这个技能？ 「Shopify 开发」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
1688以图搜源怎么做？按图找货源提19字段存CSV
「1688 以图搜源」是「龙虾部署大师」技能市场中的反向找货源技能：给定图片 URL 或本地图片，它构建 1688 以图搜索链接、等待页面加载后用固定选择器提取数据，把原图、1688 图片、产品链接、价格、销量、工厂年限、复购率、供应商等 19 个字段整理成本地 CSV 或 JSON。 技能效果 演示用一张蓝牙耳机产品图在1688以图搜源时，它讲清了从图片到货源的六步流程，列出能匹配到的报价区间、起订量、发货地等字段，并说明结果会存成CSV和JSON。 看着竞品图找货源，慢在哪 跨境选品里有一类高频动作：看到一张竞品图或一款产品图，想反查它在 1688 上的同款或相似货源。人工做这件事很慢——要一张张上传图片到 1688、在搜索结果里逐条点开、再手动抄录价格、销量、工厂年限、复购率、发货地这些字段。一批图片搜下来，不仅耗时，抄录还容易漏字段、记错价，几十款产品的供应商候选清单很难快速成形。 人工逐张搜、逐条抄，越多越慢 竞品图 手动上传 逐条点开 人工抄字段 易漏价/销量 表很慢 这个技能能帮你拿到什么 它把"以图找货源"做成一条标准化、可校验的流程。输入上，它支持图片 URL 列表和本地图片文件两种模式；检索上，它构建 1688 以图搜索链接，并等待页面完整加载后再用固定的 DOM 选择器提取数据；校验上，它对每条结果强制核验产品图片、链接、价格、销量、供应商等 19 个字段的完整性，缺字段不会蒙混过去；交付上，它把结果保存为本地 CSV 或 JSON，并明确返回文件路径。输出覆盖原图链接、1688 图片、产品链接、名称、价格、销量、工厂年限、复购率、服务评分和供应商信息——这些正是选品对比时要看的维度。 图片 URL 或本地图 1688 以图搜 等页面加载 提取 + 校验 19 个字段 缺一不放过 CSV / JSON 用前须知 该技能需要可用的浏览器自动化能力和访问 1688 的网络，输入可以是图片 URL 或本地图片，结果保存为本地 CSV/JSON，无需外部表格工具。它依赖 1688 页面结构，当页面结构变化导致字段缺失时，它会停止任务并记录错误信息，而不是返回不完整的结果。它做的是相似产品检索，匹配结果仍需你结合实际比对确认。 怎么用它 用法是把要找货源的图片来源用自然语言交给它，说明保存格式即可。例如可以这样对它说： 可以这样对它说 "用这几张产品图去 1688 找相似货源，结果同时保存成 CSV 和 JSON。" "亚马逊选品想反查供应商，图片链接都在表里，按行逐个搜索并保存结果。" "搜不到商品链接时用站内搜索页兜底，保存前确认 19 个字段别漏。" 它适合这些场景：亚马逊运营要根据竞品图片快速寻找 1688 相似货源；采购团队要批量搜索多个产品图、导出供应商候选清单；选品人员要对比价格、销量、复购率和发货地等字段；以及页面结构变化导致字段缺失时，需要明确停止任务并记录错误的稳妥处理。 大家常问 1688 以图搜源（按图搜款）找货源，为什么有时候搜出来的是相似款而不是一模一样的同款？ 因为以图搜图走的是图像特征匹配，不是比对同一张原图：系统把图转成特征向量，再找指纹最接近的商品，相似度达阈值就展示。常见于上家换了主图、图片被裁切调色加水印、该商品本就没在 1688 上架，或没找到高置信度匹配而降级展示相似款。用无水印主图、裁掉背景只留商品主体，能提高找同款命中率。 亚马逊选品时为什么很多人会用竞品主图反查 1688 货源？这种以图找源能看出什么？ 亚马逊很多产品是从源头工厂采购后贴牌或轻微改款发到 FBA，用竞品主图反查 1688 等于逆向追溯供应链、把零售品还原到出厂状态。能看出出厂价与利润空间、最小起订量和阶梯定价、同款供应商数量（竞争密度）、更细的材质尺寸规格，以及工厂是否支持 OEM/改款，判断能否做差异化。本技能可批量按图取回这些字段。 在 1688 上看供应商，复购率、工厂年限、服务评分这些字段分别说明什么、怎么理解？ 复购率是老客户再次下单占比，越高越说明质量稳定、交期靠谱，但新店基数小易虚高，要结合年限看；工厂年限反映抗风险能力和供应链成熟度，一般 3 年以上较稳；服务评分多拆响应、发货、买家评价三项、满分 5 分，低于 4.5 要警惕。建议组合判断、先初筛再发样品单。本技能会把这些字段一并抓取下来对比。 用图片在 1688 以图搜源时，为什么有时会搜不到对应的商品，或者抓取到的字段不完整？ 搜不到多因图片过小、被过度精修抠图、含密集文字水印或是杂乱场景图，也可能商品已下架、本就不来自 1688，或图片走防盗链 CDN 被拒抓。字段不完整则多是页面异步加载没等够——价格、销量、复购率等字段是分批后到的，或小厂本就没填这些数据。本技能要求等加载完成再提取，并校验图片链接与 19 字段完整性。 想用上这个技能？ 「1688 以图搜源」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
知识漫画怎么创作？把文章转成分镜提示词，保持角色一致
「知识漫画创作」是「龙虾部署大师」技能市场中的内容视觉化技能：它把文章、教程或主题材料转化为原创教育漫画。输入来源内容、画风、基调、版式、比例和语言后，它会加载偏好、分析内容、确认风格，依次生成分镜、角色设定、图像提示词、角色参考图、连续页面图片和 PDF，并能根据内容信号推荐清线、日漫、写实、水墨等风格，支持只出分镜、只出提示词、按角色参考图重绘指定页或重新合成 PDF。 技能效果 把图灵生平做成知识漫画时，它先给出人物色标与造型设定，再画出开头几页的分镜。 把知识画成漫画，难在哪 知识漫画的门槛不在画工，而在"成体系"。一篇教程要变成连贯漫画，需要先拆出分镜节奏、立住角色、写清每页画面，再保证多页之间同一个角色长得一样、风格不跑偏。靠人工或零散工具，常出现两类问题：角色每页脸都不同，读起来出戏；画风与内容气质不搭，科普配了违和的风格。更现实的是，全部画完才发现分镜不对，返工成本极高。 连续多页 · 角色要一致 第 1 页 第 2 页 第 3 页 合成PDF 这个技能怎么把内容变成漫画 它把成漫画的过程拆成一条可追溯的链路。先根据内容信号自动推荐画风、基调、版式或预设风格——清线、日漫、写实、水墨等组合都在选项里；再依次生成内容分析、分镜脚本、角色定义和每页的图像提示词。关键一步是它先生成角色参考图，再据此生成页面，从而让同一角色在多页之间保持视觉一致；最后把连续页面合成为 PDF。它还支持灵活的局部操作：只先出分镜或只出提示词、增删页面、以提示词优先更新，或基于角色参考图重绘指定页后重新合成 PDF。 分析内容定风格 分镜脚本+ 提示词 角色参考图定形象 连续页面保持一致 合成 PDF 用前须知 该技能无需外部图像 API Key，Seedream 凭证会从本地配置目录自动读取。本地需要 Python 环境以及 openai、pillow；PDF 合成脚本则需要可运行的 Node/TypeScript 环境。 怎么用它 用法是把要改编的素材连同想要的画风、节奏和产出方式告诉它，它会先出方向再逐步生成。例如可以这样对它说： 可以这样对它说 "把这篇图灵传记改成温暖清线风知识漫画，先出分镜和角色设定，文字别多。" "只先出量子计算科普漫画的分镜，暂时不用生成图片，页面节奏也标明。" "用水墨动作风讲孙子兵法，每页角色造型保持一致，先生成参考图。" 它适合这些场景：把技术教程、科普文章或人物故事改编成连续知识漫画；按清线、日漫、写实、水墨或粉笔等风格输出教学内容；已有漫画页面需要修改某一页并重新合成完整 PDF；以及团队希望先审阅分镜或提示词，再决定是否生成全部图片。 大家常问 知识漫画的「分镜」到底是什么？为什么直接照着文章画漫画反而读不下去？ 分镜不是把画面排进格子，而是控制读者视线在时间中的运动——格子之间的空白才是核心，读者在脑中自动闭合。文章是线性「告诉」，漫画是二维「展示」，照着文章逐段画会变成插图说明书：节奏均匀、抽象概念被堆在对话气泡里，反而失去漫画的叙事力。 为什么 AI 生成的漫画里同一个角色每页脸都不一样？这种「视觉一致性」是怎么丢的？ 每一格在生成时都是独立事件单元，系统没有跨格的「角色身份记忆」。叙事描述只说「发生了什么」、不说「角色长什么样」，五官细节在「叙事→视觉」转换中被压缩。再加上构图优先级把动作排在角色之前，结果就是单格都成立、连起来角色却变了——必须先固定角色参考图、再生成页面。 知识漫画选画风（清线 / 日漫 / 写实 / 水墨）凭什么？为什么内容气质和画风不搭就读不进去？ 画风是读者与内容之间的「认知契约」——线条、色彩、造型在翻页第一秒就暗示了内容类型与可信度。清线偏中立适合传记历史，日漫情绪符号发达适合教程科普，写实重信任感适合成人专业，水墨靠留白笔意适合东方文化。气质和画风不搭会触发潜意识的「不对劲」，读者说不出哪里别扭，但就是读不进去。 漫画的「对话框」和「旁白框」怎么区分？为什么放错位置会破坏阅读节奏？ 对话框是圆形/椭圆形带引尾、指向说话角色，承载「故事内」声音；旁白框是矩形无引尾、放在画格角落，承载「故事外」叙述。两者层级不同，混用会让读者把叙述当成角色对白、视角错乱。位置放错还会打断 Z 字阅读路径，造成视线折返、因果颠倒、节奏卡顿——读者就要倒回去重读。 想用上这个技能？ 「知识漫画创作」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
如何用AI查天气
「天气查询」是「龙虾部署大师」技能市场中的天气获取技能：作用是按城市、机场代码或坐标查询当前天气和预报，返回天气状况、温度、湿度、风向风速、月相等信息，默认使用 wttr.in 输出简洁文本、紧凑格式、完整预报或 PNG 图片，必要时改用 Open-Meteo 的 JSON 接口作为备选，适合快速查询、出行准备和程序化天气展示。 技能效果 查杭州明天天气时，它把早晨与傍晚分开，分别给出降雨概率、湿度和风力。 查天气，为什么也值得做成一个技能？ 看一眼今天几度并不难，难的是把天气信息按需要的形式取出来。出行前想知道的不是一个温度数字，而是"早晚分别冷不冷、周末适不适合户外、风力湿度怎么样"；做报告或看板时，又希望天气以固定格式嵌进去，而不是每次手动复制粘贴；偶尔还需要一张天气图片用于分享或展示。 普通天气网站给的是给人看的页面，既不方便按字段取用，也不适合放进自动化流程。把查询、格式和数据源统一成一个技能，正是为了让"取天气"这件小事变得可控、可复用。 同一份天气，多种取用形式 简洁文本 ☀ 紧凑格式 嵌入看板 PNG 图片 报告 / 分享 JSON 程序处理 这个技能能帮你做什么？ 这个技能默认通过 wttr.in 查询，支持按城市名、机场代码（如 JFK）或经过编码的地点取天气；可以按格式返回温度、湿度、风速、地点、月相等指定字段，输出形式覆盖当前天气、今日预报、完整预报和 PNG 天气图。需要程序化处理时，它能改用 Open-Meteo 的坐标接口返回 JSON，结构清晰、便于嵌入脚本或看板；当 wttr.in 不稳定时，Open-Meteo 也充当备选数据源，保证查询不中断。 地点 + 单位 + 输出格式 天气查询 wttr.in 主源 Open-Meteo 备选 天气字段 温度 / 湿度 / 风速 月相 / 预报 输出 用前须知 该技能无需 API Key。但需要可访问 wttr.in 或 Open-Meteo 的网络环境，并具备 curl 或等效的 HTTP 请求工具；城市名含空格时需要进行 URL 编码。预报数据来自第三方服务，仅作出行和展示参考。 怎么用它？ 用法是把地点、关心的指标和想要的单位说清楚，要图片或要分时段也直接讲。例如可以这样对它说： 可以这样对它说 "查一下杭州明天会不会下雨，顺便看风力和湿度，早晚分开说清楚。" "纽约这周天气按华氏度说，周末适不适合徒步，白天夜里分别看。" "用机场代码 JFK 查当前天气，温度和风速都要有，按英制单位显示。" 它适合这些场景：想快速查看某城市当前温度、天气、湿度和风速；脚本或看板需要以固定格式嵌入天气摘要；需要生成天气 PNG 图片用于报告、分享或可视化；以及在主数据源不稳定时改用 JSON 接口获取数据。 大家常问 为什么不同来源的天气预报对同一天的结果会不一样？ 天气预报底层是数值模型，不同机构的初始观测、模型分辨率和物理参数化方案都不一样，加上大气本身的混沌特性，初始条件的微小差异会被放大，所以同一天的预报结果会出现差异。 体感温度和实际温度的差别是什么，怎么用来判断穿衣？ 实际温度只是空气温度计的读数，体感温度还叠加了湿度和风速对人体散热的影响。夏天高湿会让体感比实际更热，冬天大风会让体感更冷，穿衣建议要按体感来分层，而不是只看实际气温。 暴雨橙色预警和黄色预警在出行决策上有什么区别？ 黄色预警对应"谨慎出行"，降雨量较大但未到致灾临界，可规划备选路线后出门；橙色预警的小时雨强和内涝、山洪风险显著升高，建议非必要不出行，已在外的人优先就近避险而不是继续移动。 想用上这个技能？ 「天气查询」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
提示