供应商绩效怎么管理？算准时率缺陷率识别供应风险
「供应商绩效管理」是「龙虾部署大师」技能市场中的采购供应链技能：它系统化监控采购订单、收货、质检、交付周期和供应商健康度，计算准时交付率、填充率、缺陷率和综合健康分，并识别单一供应商依赖、交期波动和认证到期等供应风险，输出评分与行动建议。 技能效果 给三家供应商打绩效分时，它按准时率、到货率、质检退货率设权重算出综合得分和排名，把低于阈值的指标标红预警，并对每家给出合作建议。 供应商好不好，凭印象说不清 采购对供应商的评价常常停留在印象层面："这家发货还行""那家偶尔出次品"，但具体准时率是多少、缺陷率有没有恶化、交期波动有多大，往往拿不出数据。更要命的是几类隐患容易被忽视：库存系统只凭装箱单入账、不做实物清点，问题货混进了库存；供应商发票单价和 PO 对不上、却没有三单匹配的环节去拦；核心 SKU 过度依赖单一供应商，一旦对方掉链子，大促前就可能断货。没有统一的计分口径，这些问题只能等出事了才发现。 凭印象 vs 用数据评供应商 凭印象 "还行 / 偶尔出问题" 出事才发现 用数据 准时率/填充率/缺陷率 综合健康分排序 这个技能能帮你管清什么 它把供应商管理拆成从下单到评估的一条闭环。在订单环节，它标准化采购订单字段，明确 SKU 映射、约定单价、交期和贸易条款；在收货环节，它建立到货实物清点、短缺处理、质量对比和库存入账流程，让入账不再只凭装箱单；在评估环节，它计算准时交付率、填充率、缺陷率和供应商综合健康分，形成可排序的计分卡；在风控环节，它识别单一供应商依赖、交期波动和认证到期等风险。它还支持三单匹配——把采购单、收货单和发票对齐，发现发票单价与 PO 不一致的问题。输出可以是供应商得分、安全库存调整、认证到期提醒和行动建议。 三单匹配：对齐后才入账与付款 采购单 PO约定单价/数量 = 收货单实物清点 = 发票单价核对 入账付款 用前须知 该技能无需 API Key 或专用运行环境，可基于你提供的采购订单、收货、质检和供应商台账数据建模。它做的是评估与建模，把流程和计分卡真正系统化落地时，需要连接 ERP/WMS 或数据库。数据越完整，评分和风险提示越可靠。 怎么用它 用法是把供应商的历史表现数据或要处理的采购问题用自然语言交给它，由它评分、给建议。例如可以这样对它说： 可以这样对它说 "把这三家供应商近半年的准时率、到货率和质检退货评个分，差的标红。" "这个采购单拖了两个月没关，帮我核一下缺货和补款该怎么收。" "按交期波动和残次率重新算安全库存，别让爆款在大促前断货三天。" 它适合这些场景：把供应商的交期、缺货和质检问题纳入月度评估；库存系统不能只凭装箱单入账、需要增加实物清点和 QC 门槛；供应商发票与 PO 单价不一致、需要建立三单匹配流程；以及核心 SKU 过度依赖单一供应商、需要规划备选供应商和安全库存。 大家常问 供应商绩效一般从哪几个维度评？准时交付率、填充率、缺陷率分别是什么意思？ 常分五个维度：交付、质量、成本、服务响应、合规与风险。其中交付绩效最常用，含三个关键指标：准时交付率＝约定交期内交付订单数÷总订单数，看时间；填充率＝实收数量÷订购数量，看是否足量；缺陷率＝质检不合格数÷实收数，看质量。三者要合并看，本技能据此算出供应商综合健康分。 采购里说的三单匹配（PO、收货单、发票）是什么？为什么发票和采购单单价对不上要先卡住？ 三单匹配是付款前把采购订单、收货单、发票两两核对：PO 对收货单看数量、收货单对发票看开票量、PO 对发票看单价。单价对不上要先卡住，因为 PO 单价是经审批的书面约定，直接照发票付＝默认接受供应商单方涨价，或掩盖录错、计量单位不符等错误。本技能内置三单匹配流程，差异先暂停再核。 为什么库存入账不能只凭供应商的装箱单？实物清点和 QC 质检这一步是为了防什么？ 装箱单是供应商自报的"承诺"、不是仓库的"事实"。实物清点防短少、多发错发和运输损坏，避免账面虚高、无法追责；QC 质检防批量质量问题、规格版本不符与安全合规风险，并留下扣款索赔的证据链。本技能要求按到货清点加 QC 审核再入账，把这步当成防火墙，而非凭装箱单签收。 安全库存是什么？为什么交期波动大、残次率高的供应商，对应的安全库存要设得更高？ 安全库存是应对供应链不确定性的缓冲库存，不用于满足正常需求、只为防断货。交期波动大时只能按最长可能交期备货，波动越大放大越明显；残次率高则实际可用量低于账面、相当于变相缩短补货周期，需把安全库存除以(1−残次率)放大。本技能按交期波动和残次率重算安全库存并分级建议。 想用上这个技能？ 「供应商绩效管理」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
如何用 AI 优化提示词
「状态化提示词优化」是「龙虾部署大师」技能市场中的提示词改写技能：作用是自动识别并改进复杂、技术、可复用、需求含糊或精度关键的提示词。它结合 APE、OPRO、DSPy 等模式做多轮优化，冷启动模式可直接套用研究驱动的改写策略，状态化模式则借助嵌入索引的历史样本、相似提示检索、反馈记录和质量评分持续学习，输出优化后的提示词、改进依据、迭代次数和收敛判断。 技能效果 丢给它一句含糊的「把用户反馈整理一下」，它改写成可复用的结构化提示词，补上分类维度、优先级标注、成功标准和后续动作。 提示词写得不稳，问题出在哪 同一个任务，提示词措辞稍有不同，输出就忽好忽坏：需求写得含糊，模型自由发挥太多；约束堆得太满，又变得脆弱、一改就崩。更麻烦的是缺少积累——每次都从头调，调好的版本没沉淀下来，下次遇到类似任务又得重来。对于代码生成、分析报告这类需要稳定结构和验收标准的任务，提示词不稳定，直接拖累产出的可靠性。 含糊提示 自由发挥太多 堆满约束 脆弱、一改就崩 清晰、可测量、可复用 约束简洁有效 这个技能能帮你优化什么 它把"凭手感调提示词"变成"有方法、可积累的优化过程"。核心能力有四块：一是识别复杂、多步骤、技术输出、模板和精度关键型的提示词，判断哪些值得优化；二是调用优化流程，生成改写版本、改进说明和迭代建议，并控制迭代次数与收敛条件，避免过度优化反而变脆；三是在状态化模式下，基于历史向量检索、相似提示、反馈记录和成功率持续学习，让后续改写越用越准；四是结合 APE、OPRO、DSPy 等研究驱动的策略，把含糊需求改写成清晰、可测量、可复用的指令。优化结果会附上改进依据和迭代次数，让你看清"为什么这样改"。 原提示词含糊/脆弱 多轮优化APE/OPRO/DSPy+ 历史检索 迭代收敛 优化后提示词清晰 / 可测量附改进依据 用前须知 冷启动模式无需安装即可使用。若要启用状态化学习（基于历史样本持续改进），需要 Node.js 18+、Docker、Qdrant、Redis 以及 prompt-learning MCP，并配置 OPENAI_API_KEY 用于嵌入与评估。 怎么用它 用法是把你要优化的提示词和期望的稳定效果用自然语言交给它，它会改写并说明依据。例如可以这样对它说： 可以这样对它说 "把这个长任务提示词优化成可复用版本，并设清楚成功标准。" "这段代理提示老跑偏，按历史效果压缩约束，减少无关发挥。" "改进这个代码审查提示词，让输出稳定覆盖关键风险点和缺失测试。" 它适合这些场景：要把含糊需求改写成可复用的系统提示词或任务模板；代码生成、分析报告或结构化输出需要更稳定的约束和验收标准；长期项目希望记录提示词表现并基于成功案例持续改进；复杂代理流程要在不增加脆弱性的前提下提升指令清晰度。 大家常问 为什么同一个任务，提示词措辞稍微改一下，模型输出就忽好忽坏？ 大模型每次调用都是无状态的独立计算，没有对上一次输出好坏的记忆，措辞稍变就走到不同的生成路径上，输出自然不稳。状态化提示词优化的做法是在调用之间建一条反馈回路：把历史输入、输出和评分累积起来，挑高分样本做滚动 Few-shot，再用反思-改写循环抑制随机波动，让"忽好忽坏"收敛成稳定输出。 什么是提示词的冷启动模式和状态化模式，它们的差别是什么？ 冷启动模式是每次都从零构建提示词，不查、不留任何历史，效果完全取决于本次写得好不好。状态化模式则把每次提示词、响应和质量评分记录下来，建嵌入索引和成功率统计，新任务先检索相似的高分历史样本作参考。差别在于学习能力：冷启动每次原地重来，状态化越用越准，但需要存储和检索基础设施。 为什么提示词不能一次写好，需要多轮迭代和收敛判断？ 因为你写提示词时脑子里的"理想输出"模型并不知道，模型对模糊指令的默认倾向也要等它真的产出文本才能看见。多轮迭代实际上是用实测数据反向修正你对模型的假设：上下文累积灌入你的标准，反思-改写分离诊断和修复，A/B 替换让数据决定哪种措辞活下来。收敛判断（连续几轮改进幅度低于阈值、评分达标、Token 预算耗尽等）则避免越改越脆的过度优化。 怎么判断一段提示词是『含糊型』还是『精度关键型』，对应的改写策略有什么不同？ 把提示词套入「80% 正确是否仍然有用」这一问：写产品介绍、做主观分析这类回答"是"的属于含糊型；代码生成、信息抽取、SQL 查询这类回答"否"的属于精度关键型。含糊型改写重点在风格引导和方向一致——上下文用追加式累积偏好，Few-shot 选风格范例，预算可宽松；精度关键型重点在压缩误差——规则约束严格优先于历史，Few-shot 滚动覆盖易错边缘案例，强制开启链式思维做审计追踪。 想用上这个技能？ 「状态化提示词优化」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
翻译助手怎么做多语言翻译？保留变量格式并处理文化习语
「翻译助手」是「龙虾部署大师」技能市场中的多语言翻译技能：作用是在保留原始格式、变量和技术元素的前提下完成翻译，并按目标地区处理语气、复数、性别、日期、单位和文化表达，输出结构稳定、术语一致、符合目标语习惯的译文，适合产品本地化、技术资料翻译和跨语言内容改写。 技能效果 把一段含变量和 Markdown 链接的产品文案译成法语时，它原样保留了变量与链接格式，只翻译可读文本。 机器翻译一过，格式乱了、术语也飘了 把界面文案或技术文档丢进通用翻译，常见两类麻烦。一是格式被破坏：`{name}`、`%s` 这类变量占位符被一起翻译，Markdown 链接和代码块结构错位，HTML 标签被改写，译文一上线就报错或排版崩坏。二是表达不地道、术语不统一：直译腔重，不符合当地用户习惯；同一个术语在长文档或多个文件里前后翻得不一样，读起来割裂。翻译的真正难点，是同时守住格式稳定和译文自然这两头。 原文 Hi {name} [文档](url) ＜b＞术语 A＜/b＞ 通用翻译：占位符被译 链接错位 · 术语前后不一 本技能：变量 / 标签原样保留 术语一致 · 表达地道 这个技能能帮你译出什么 它把翻译当成一项有规则的工程，而不是逐句替换。格式上，它会保留代码块、Markdown、HTML 标签和变量占位符，区分出品牌名、技术术语、URL、邮箱、接口和文件扩展名这些不可译元素，只翻该翻的部分。语言上，它按目标语言处理复数、性别、正式程度和 RTL 文字方向，并结合文化语境调整习语、单位、日期、货币和数字格式。流程上，它强调先读完整上下文、建立术语一致性，再动笔，确保同一术语在整篇或多文件中前后统一。 读全文上下文 建术语一致性 › 隔离不可译元素 变量 · 标签 · 接口 › 本地化输出 习语 · 单位 · 日期 用前须知 该技能无需 API Key、Python 或 Node 依赖。使用前最好提供源语言、目标语言、受众、语气要求和术语表；涉及 JSON 等结构化文件时，要明确哪些键或字段可以翻译、哪些必须保留，译文才能既准确又不破坏结构。 怎么用它 用法是把要翻译的内容、目标语言和保留要求用自然语言交给它，它会守住格式再做本地化。例如可以这样对它说： 可以这样对它说 "把这段产品文案译成法语，变量和 Markdown 链接格式都别动。" "这份客服邮件翻成日语，语气礼貌但别太生硬，像真人客服回复，少点套话。" "JSON 里的键名保留英文，只翻译每个文案值，数组结构别乱改。" 它适合这些场景：产品界面文案含 `{name}`、`%s` 等变量占位符需要翻译；Markdown 文档要保持标题、链接、强调和代码块结构不变；营销或帮助中心内容要从直译改为当地用户习惯表达；同一术语在长文档或多文件中必须保持一致。 大家常问 直译和意译到底怎么区分，什么时候该用直译、什么时候该用意译？ 直译保留原文的词汇、结构和修辞意象，追求形式一致；意译放弃字面形式、只保留核心意义，按目标语习惯重新组织。判断分四个维度：字面意义与实际意义是否一致、两种语言结构差异大小、是否带文化负载、文本功能偏信息还是偏表达。法律科技偏直译，文学广告偏意译，实际往往交替使用。 为什么同一个术语在长文档或多文件里经常前后翻得不一样，要怎么守住术语一致性？ 这叫术语漂移，根源是语境会让译者临场换词、人的工作记忆有限、源语和目标语词汇又非一一对应。守一致性靠流程而非记忆：动笔前建术语底盘列出源语到目标语的映射和约束，按"行业标准 > 项目约定 > 上下文自然度 > 字面直译"定优先级，分段翻译逐段回溯检查，终审再做一轮术语专项扫查。 文化负载词为什么特别难翻译，处理时主要在权衡哪些东西？ 难是因为这类词在源语文化里绑定了独特的价值、制度或生活经验，目标语文化中根本没有对应物，字面译完语用意义大量流失。处理时要在四对张力中取舍：忠实与可读、归化与异化、形式对等与语用对等、文化保留与情感共鸣。没有标准答案，译者只能根据读者、用途和文本类型做有依据的取舍。 机器翻译输出的质量到底怎么评估，靠 BLEU、COMET 这类自动指标够吗？ 不够。BLEU 只测词汇 n-gram 重叠，对同义改写和语序变化不敏感；COMET 用神经模型拟合人工评分，相关性更高但仍会漏判事实性错误（数字、否定词、剂量翻错也可能得高分），且在低资源语言和专业领域偏差大。实际做法是自动指标做粗筛、规则检查覆盖术语和数字、关键节点保留人工审查，三者互补不能互相替代。 想用上这个技能？ 「翻译助手」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
一件代发供应商怎么整合？库存同步加幂等下单核利润
「一件代发供应商整合」是「龙虾部署大师」技能市场中的代发系统设计技能：它规划供应商接入、订单路由、库存同步和利润核算，区分 API、CSV/SFTP、邮件、Webhook 等接入方式，给出数据结构、供应商选择逻辑、库存缓冲和自动履单模板，并明确不直接调用真实供应商接口。 技能效果 设计双供应商代发方案时，它给出库存安全缓冲防超卖的公式、按利润时效库存三因素打分的路由模型，还有缺货自动切换和拆单的处理逻辑。 接多个代发供应商，麻烦从对接那天就开始 店铺一旦接入多个代发供应商，问题接踵而至：有的供应商给 API，有的只给 CSV 或邮件，接入方式各不相同；库存同步稍有延迟就会超卖；同款多个供应商供货时该路由给谁说不清；扣掉运费和广告后每单到底赚多少，更是一笔糊涂账。这些都属于"系统怎么设计"的问题，光靠手工对单撑不住。 这个技能能帮你设计什么 它帮你把代发系统的骨架搭起来。接入上，它评估 API、CSV、SFTP、邮件、Webhook 等不同对接方式各自适合什么场景；数据上，它设计供应商商品、库存、成本和履单的数据结构与订单路由逻辑；同步上，它提供库存同步、库存缓冲、幂等下单和物流追踪的模板，防止延迟导致超卖和重复下单；核算上，它用净贡献瀑布把商品成本、运费、手续费和获客成本一层层扣清，算出每单真实利润。 多个供应商API/CSV/邮件 订单路由按价/库存/位置选最优 幂等下单防超卖/重复 履单追踪 利润这块它用瀑布逐项扣减，让"看着有单、实际不赚"无所遁形： 售价 净贡献 商品成本 运费 手续费 获客成本 用前须知 该技能本身无需 API Key，示例以 TypeScript 架构模板为主，不执行真实供应商 API；实际落地需要对应平台和供应商的凭证。它解决的是"系统怎么设计"，落地仍需你的工程实现。 怎么用它 用法是把你的代发场景和约束用自然语言描述出来即可。例如可以这样对它说： 可以这样对它说 "我们要接两个代发供应商，设计库存同步和路由规则，先不碰接口。" "这批订单有多仓代发，拆履单和利润核算逻辑，看净贡献是否够。" "供应商只给 CSV 库存，做一版定时同步方案和代码，要有容错。" 它适合这些场景：店铺新增代发品类、要把订单自动路由到外部供应商；多个供应商同时供货、按价格库存和位置选最优履单方；供应商库存通过 CSV 或 API 同步、必须防止延迟超卖；想核算每笔代发订单扣除运费和广告后的真实利润。 大家常问 对接一件代发供应商，API、CSV/SFTP、邮件、Webhook 这几种方式有什么区别，怎么选？ 区别在于数据是推还是拉、实时性和自动化程度。API 双向、秒级实时、全自动，但要求供应商有接口、开发门槛高，适合高频订单和库存波动大的品类；CSV/SFTP 是按周期拉取文件、单向、有 4—24 小时延迟，几乎所有供应商都能给，适合库存稳定的批量更新；邮件门槛最低但可靠性最差，多用于初期或异常兜底；Webhook 是事件触发的实时推送，适合物流状态通知，但通常要搭配 API。选型先看供应商支持什么，再按日订单量和库存波动决定，常见是库存走 CSV/API、订单走 API、物流走 Webhook 的组合。 多个代发供应商供同一款货时，订单路由按什么逻辑选履单方比较合理？ 核心目标是在满足服务水平的前提下最小化综合成本，按优先级逐层筛：先按实时库存可用性过滤掉缺货的；再按客户承诺时效匹配，区域内"最近仓优先"；然后在候选里按总成本（商品成本+运费+附加费，而非单纯单价）排序；最后用供应商评分卡（缺货率、准时率、退货差评率、客服、包装）加权，价格相近（±5%内）时优先选评分高的。新供应商先灰度小流量观察，并设兜底重路由，VIP 客户可优先稳定而非最低价。 代发库存同步为什么容易导致超卖，库存缓冲和幂等下单分别解决什么问题？ 超卖的根源是你看到的永远是"过去的数据"：定时同步有时间窗口差、并发下单存在竞争条件、且供应商的同款货同时供给几十上百个分销商共享。库存缓冲是不上架全部库存、预留一段安全区（如显示 80/100），用牺牲一点可售量换取同步延迟和抢购突刺的容错，防的是"跟别人抢"。幂等下单是每个采购请求带唯一幂等键，供应商对重复键直接返回已处理，防的是网络超时重试或用户重复点击导致"同一单下两次"。两者针对不同问题，配合使用才稳。 代发订单看着有毛利却不赚钱，净贡献瀑布是怎么把利润一层层算清楚的？ 净贡献瀑布把利润从毛收入开始逐层扣减：先扣退款退货，再扣拿货成本（到此是毛利，往往看着很高），接着扣物流履约、扣营销（推广费+平台扣点+达人佣金，常是最大的隐形支出）、扣运营固定成本，最后才是净贡献——真利润。一个售价 99、毛利率看似 52% 的耳机单，扣完各层可能反而亏几元，这就是"有毛利没净利"的真相。所以要画自己的瀑布图找利润黑洞、用倒推法选品、看净贡献率而非毛利率。 想用上这个技能？ 「一件代发供应商整合」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
如何用 AI 抓取动态网页数据
「网页抓取」是「龙虾部署大师」技能市场中的网页采集技能：作用是基于 Scrapling，按页面难度分层处理——从简单的 HTTP 请求，到需要 JavaScript 渲染的动态页面，再到受反爬保护（如 Cloudflare Turnstile）的站点，用 CSS、XPath、文本匹配提取目标内容，并能构建支持并发、多会话、代理轮换、断点续爬的爬虫，输出 Markdown、HTML、文本或结构化数据。 技能效果 让它抓取 example.com 时，它真的请求了页面，把标题和正文整理成 Markdown 存成本地文件，并展示出保存下来的内容和摘要。 抓网页的难度，为什么差这么多 "抓个网页"听起来简单，实际难度跨度很大。最简单的静态页面，一个 HTTP 请求就能拿到完整 HTML；但现代 Web 应用大量靠 JavaScript 渲染，直接请求只能拿到空壳，必须等内容渲染出来才提取得到；更进一步，不少站点上了 Cloudflare Turnstile 等反爬保护，普通请求直接被拦。再加上大规模采集时还要处理并发、会话保持、代理轮换、跑挂了能不能续爬——用一套固定的抓法去硬碰各种页面，要么抓不到，要么很快被封。 按难度分层处理 静态页面 get · 一次 HTTP 请求拿全文 动态页面（JS 渲染） fetch · 等内容渲染后再提取 反爬保护页面 stealthy-fetch · 隐身浏览绕过 Turnstile 这个技能能帮你抓到和产出什么 它基于 Scrapling，把抓取按难度分成三层：get 处理静态页面，fetch 处理需要 JavaScript 渲染的动态页面，stealthy-fetch 用隐身浏览应对受反爬保护、需要绕过 Cloudflare Turnstile 的页面——先用轻量方式试，必要时再升级到浏览器抓取。内容提取上，它支持 CSS 选择器、XPath、文本匹配和元素关系定位目标内容。产出格式按文件扩展名决定，可输出 Markdown、HTML、纯文本或结构化数据（如 JSON）。面对大规模站点，它还能构建支持并发、多会话、代理轮换、暂停恢复（断点续爬）和实时统计的爬虫。 目标 URL+ 选择器 分层抓取get / fetch/ stealthy-fetch 提取 + 清洗CSS / XPath文本 / 关系 结构化输出Markdown/JSONHTML/文本 这种"先轻量、再升级"的分层策略是关键：能用 HTTP 请求解决就不动用浏览器，既快又省资源；只有遇到 JS 渲染或反爬时才升级到更重的抓法，避免一上来就用最重的方案拖慢整体。 用前须知 该技能需要 Python 3.10+，并安装 scrapling[all]>=0.4.2 与配套的浏览器安装命令；默认无需 API Key。中国大陆网络环境下可能需要固定 Playwright 版本并配置镜像源。请在合规、获得授权的前提下采集公开网页内容，遵守目标站点的使用条款。 怎么用它 用法是把目标网址、要提取的内容和保存格式用自然语言交给它，抓取层级和选择器策略由它按页面情况选择。例如可以这样对它说： 可以这样对它说 "抓这个新闻站的文章标题和正文，先用 Markdown 保存成本地文件。" "这个页面靠 JS 加载商品列表，要等内容出现再提取价格和库存字段。" "目标站有 Cloudflare 拦截，试试隐身浏览抓指定选择器的内容。" 它适合这些场景：把博客、新闻或文档页面抓成 Markdown 便于阅读归档；现代 Web 应用必须等 JavaScript 渲染后才能提取内容；受反爬保护的页面需要更稳健的浏览器抓取和选择器策略；大规模站点采集需要并发爬虫、断点续爬和实时统计。适合数据工程师、研究人员、自动化开发者、增长分析师，以及需要合规采集公开网页的团队，尤其是从小规模提取扩展到爬虫项目的场景。 大家常问 为什么很多网页直接用 HTTP 请求抓，拿到的内容是空的？ 纯 HTTP 请求只拿到服务器返回的初始 HTML。现代页面常是「空壳」，真正的数据由浏览器执行 JavaScript、再调接口异步填进 DOM。请求端没有 JS 引擎、不会跑后续脚本，所以拿到的是没装修的毛坯，内容自然缺失。 静态网页和动态网页在抓取上有什么区别？ 静态页的数据已嵌在初始 HTML 里，一次请求加解析就能取到，开销低；动态页初始 HTML 只是壳，要等 JavaScript 渲染、DOM 稳定后才提取，需无头浏览器执行，开销高。工程上优先走静态路径，能嗅探内嵌 JSON 就别开浏览器。 网页抓取里说的「反爬」到底是什么，为什么普通请求会被拦？ 反爬是网站靠多维信号判断请求是否「像人」：检查请求头是否完整、单 IP 频率是否过高、行为模式是否机械、能否执行 JS 计算挑战签名。普通请求缺这些特征，就被限流或拦截。合理做法是控制频率、遵守 robots，而非硬碰。 抓取公开网页数据时，怎样才算合规？ 围绕四条原则：检查并遵守目标站 robots.txt 的 Disallow；阅读使用条款，公共可访问不等于可随意复用；两次请求间留足间隔、收到 429 就停；绝不绕过登录、验证码等访问控制。需要破解才能拿到的，就不属于公开数据。 想用上这个技能？ 「网页抓取」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
命令行邮件怎么用 AI 收发
「喜马拉雅内容助手」是「龙虾部署大师」技能市场中的终端邮件管理技能：它基于 Himalaya 邮件客户端，让你用自然语言在终端完成列出文件夹、查询邮件、阅读正文、回复、转发、撰写、移动、复制、删除、管理标记和下载附件等操作，支持 IMAP、SMTP、Notmuch、Sendmail 等多种收发方式与多账号，并专门处理了中文编码与发送场景。 技能效果 管理邮箱时，它列出收件箱、按关键词搜索、把邮件按主题归类，并示范了起草回复。 在终端里收发邮件，难在哪 命令行邮件客户端本身高效，但门槛集中在三处：一是配置繁琐，IMAP/SMTP 服务器、端口、授权码、编辑器变量要逐项填对，QQ、163、Gmail、iCloud 各家规则还不一样；二是中文与附件容易出问题，终端编辑器对中文正文的编码处理稍有偏差就发成乱码，带附件发送的命令也难记；三是多账号切换混乱，工作邮箱和个人邮箱并存时，列邮件、读信、发送都要小心指定到正确账号。三点叠加，让本该轻量的终端收发变成一件需要反复查文档的事。 $ himalaya --account work list ? IMAP host / port / 授权码 … ? $EDITOR 未设置 ! 中文正文 → 乱码 ! 附件命令记不住 ? work 还是 personal 账号？ 这些都是机械、可被规则化的工作——记住每家邮箱的连通规则、处理好编码、把账号选对，正是这个技能要替你扛下的部分。 这个技能能帮你做什么 它把 Himalaya 邮件客户端包装成一个能听懂自然语言的助手，覆盖终端邮件的完整生命周期。读取层面，它能检查平台、二进制、配置文件、编辑器变量和账号连通性，列出文件夹和邮件并支持分页、文件夹切换与查询条件，按发件人、主题或关键词筛选后读取正文；处理层面，它能回复、回复全部、转发、移动、复制、删除和管理标记；撰写层面，它通过脚本发送含中文正文和附件的邮件，并支持 dry-run 先预览再发出；账号层面，它在多账号环境下按你指定的邮箱执行操作，避免发错账号。 自然语言 指令 喜马拉雅 内容助手 列表 / 查询 回复 / 转发 撰写 / 附件 移动 / 标记 IMAP / SMTP 收发结果 它把"在终端逐条敲 Himalaya 命令、记各家邮箱规则"这件事，转成"用一句话说清要做什么"。中文正文和附件发送被专门处理，多账号也由它按指令选对，避免编码与发错账号这两类最常见的事故。 用前须知 该技能依赖 Himalaya CLI，Windows 可用 winget 安装；首次使用需配置 config.toml、账号凭据和 $EDITOR 变量。QQ、163、Gmail、iCloud 等邮箱通常需要授权码或 App Password 而非登录密码。配置就绪后，列表、阅读、发送等操作才能正常连通。它面向偏好命令行的开发者、运维和技术支持人员，不提供音频内容管理能力。 怎么用它 用法是把要做的邮件操作用自然语言说清楚——查哪个文件夹、按什么条件搜、回复给谁、正文写什么——无需记命令和参数。例如可以这样对它说： 可以这样对它说 "用工作邮箱看收件箱最近二十封邮件，按发件人帮我整理出重点。" "把第四十二封邮件回复给所有人，正文用中文先拟好，别太长，语气自然些。" "从邮箱里搜主题含 invoice 的邮件，把原文和附件线索一并导出来。" 它适合这些场景：偏好在终端处理邮件、不想离开命令行去开网页客户端；需要按发件人、主题或关键词快速检索并阅读正文；要发送带附件的中文邮件又想绕开交互式编辑器的兼容问题；以及在工作邮箱与个人邮箱并存的多账号环境下，明确指定某个账号执行列表、阅读或发送。 大家常问 在终端里用 Himalaya CLI 收发邮件，需要哪些基础协议配置？只讲 Himalaya 邮件管理 CLI 的操作原理（IMAP/SMTP 配置、folder、message id、attachment、模板、过滤），不要提及任何其他邮件客户端、GUI 邮箱软件或邮件服务商。 Himalaya 采用双后端架构：IMAP 负责收信（默认 993，TLS），SMTP 负责发信（默认 587，STARTTLS）。两者各自在 config.toml 里以 host、port、encryption 类型和认证方式（password 或 oauth2）单独声明，密码可用 raw、外部 cmd 或 keyring 三种方式提供，配置就绪后命令才能正常连通。 在命令行邮件客户端里，为什么直接发的中文邮件容易出现乱码？ 核心是编码链路对不齐：MIME 编译时若未声明 charset=UTF-8、Subject 等头部没按 RFC 2047 编码、终端或编辑器保存编码与 Himalaya 默认期待不一致、SMTP 服务器不支持 8BITMIME/SMTPUTF8 扩展，任一环节失配，接收方都会把 UTF-8 字节按错码表解读，出现「测试」之类的乱码。 命令行邮件管理里 folder、message id、flag 这些概念分别是什么？ folder 是 IMAP 服务器端的邮箱目录（INBOX、Sent、Drafts 等），所有操作都在当前 folder 上下文内执行；message id 是 Himalaya 在该 folder 输出列表里临时分配的序号，删除或换文件夹后会变；flag 则是存在服务器上的状态标志（seen、answered、flagged、deleted 等），由 IMAP STORE 命令更新，跨客户端同步。 在多账号的命令行邮件管理里，account 这个概念是在哪一层生效的？ account 是 config.toml 里 [accounts.] 段落，把身份、IMAP、SMTP、folder 别名、下载目录绑成一个完整命名空间。--account 选哪个就加载哪段配置、起独立的 TLS 连接，folder 列表、message id、附件路径、发件 From 与签名都隔离，跨账号不互通也无法跨账号搜索。 想用上这个技能？ 「喜马拉雅内容助手」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
提示