后端前端AI 技能AI 插件搜索引擎【免费下载链接】clawhubSkill Plugin Registry for OpenClaw项目地址https://gitcode.com/gh_mirrors/mo/clawhub点击查看免费下载ClawHub 是为 OpenClaw 提供 Skill技能、Plugin插件、Package包与市场元数据的注册中心。本文将逐条拆解 ClawHub 的《可接受使用政策》docs/acceptable-usage.md什么内容允许发布、什么内容会被下架以及发布者如何避免触碰信任与安全红线同时结合仓库源码convex/schema.ts、convex/lib/artifactModeration.ts、convex/lib/publisherAbuseScoring.ts与配套文档docs/moderation.md、docs/content-rights.md讲清判定 — 处置 — 申诉的完整链路。阅读本文后你将能准确判断一个 Skill 或 Plugin 是否适合上架 ClawHub理解发布者账号在什么情况下会失去发布权限并掌握规避误判的实操清单。政策适用范围管什么、不管什么ClawHub 托管四类对象skills、plugins、packages 以及 marketplace metadata。可接受使用政策覆盖的不是代码内容本身而是四件事一个 listing 实际做什么its behavior它要求用户运行什么what it asks users to run它如何自我表述how it represents itself发布者如何使用 ClawHub 的发现、安装与信任表层discovery, install, and trust surfaces。也就是说即使一段代码能跑只要它的用途、安装方式、对外宣称或发布行为违反政策同样会被处置。这与 ClawHub 的信任模型一致市场不仅要审核产物本身还要审核发布者的行为模式。关于处置状态与账号状态本身政策明确指向两篇配套文档阅读本文时请配合使用Moderation and Account Safety举报、审核搁置、内容隐藏、封禁与账号状态Content Rights Requests版权或其他权利主张的提交流程。允许的内容四类安全区及其判定条件政策首先明确了 ClawHub 欢迎什么有用、可理解、出于善意发布useful, understandable, and published in good faith的内容。下表完整列出允许类别与放行条件类别允许条件开发者生产力Developer productivity帮助用户构建、测试、迁移、调试、编写文档或运维软件UI、数据与自动化工作流UI, data, and automation workflows作用范围清晰、所需凭据明确声明且危险操作包含 review / dry-run / preview / 确认confirmation路径防御性安全、审核与滥用审查Defensive security, moderation, and abuse review工具被定位为授权审查用途、保留证据、人类批准边界清晰个人或团队工作流Personal or team workflows使用基于同意的账号、透明的设置与显式权限受维护的目录Maintained catalogs每个 listing 独立、有用、描述准确、得到合理维护关键判定原则上下文决定一切政策原文明确指出Context matters.上下文很重要。同一个主题在窄范围的防御性或基于同意的场景下是允许的一旦被打包成滥用工作流abuse workflow就变成不允许的。举例来说监控工具若定位为在授权的系统上做安全审查、保存证据、需要人工批准属于防御性安全类别但同一个工具若被包装为在未授权情况下持续监视他人设备则落入下文隐私入侵式监视的禁止清单。这意味着发布者在撰写描述与 README 时用途声明framing本身就是合规的一部分——模糊的表述可能把本可放行的内容推向禁止类别。禁止的内容八大类明确红线政策明确表示ClawHub 不托管其主要目的是滥用、欺骗、不安全执行或侵犯权利的内容。八大禁止类别完整列举如下类别典型行为未授权访问与安全绕过Unauthorized access or security bypass认证绕过、账号接管、限流滥用、实时通话或 Agent 接管、可复用会话窃取、为未批准用户自动批准配对流程平台滥用与封禁规避Platform abuse and ban evasion封禁后的隐匿账号、账号养号/刷号、虚假互动、多账号自动化、批量发帖、垃圾机器人、为规避检测而构建的自动化欺诈、骗局与欺骗性金融工作流Fraud, scams, deceptive financial workflows伪造证书或发票、欺骗性支付流程、诈骗外联、虚假社会证明、用于欺诈的合成身份工作流、无清晰人工批准的消费/扣费工具隐私入侵式增强或监视Privacy-invasive enrichment or surveillance抓取联系方式用于垃圾信息、人肉搜索doxxing、跟踪、配合未经请求的外联进行线索提取、隐蔽监控、非自愿生物特征匹配、使用泄露数据或漏洞数据转储非自愿的冒充或身份操纵Non-consensual impersonation or identity manipulation换脸face swap、数字孪生、克隆网红、虚假人设或其他用于冒充或误导的工具露骨色情内容或禁用安全防护的成人内容生成Explicit sexual content or safety-disabled adult generationNSFW 图像/视频/内容生成、第三方 API 的成人内容包装器、主要目的是露骨性内容的上架隐藏、不安全或误导性的执行要求Hidden, unsafe, misleading execution requirements混淆的安装命令、pipe-to-shell 安装如把下载内容用sh/bash直接执行且不可审查、未声明的密钥/私钥需求、远程npx latest执行且不可审查、用元数据掩盖 listing 真实运行需求侵犯版权或违反权利的材料Copyright-infringing or rights-violating material未经许可转载他人 Skill/Plugin/文档/品牌资产/专有代码、违反许可条款、冒充原作者或发布者重点什么是不可审查的执行第 7 类值得单独强调因为它直接关系安装安全。政策禁止的核心词是without clear reviewability缺乏清晰可审查性具体包括混淆obfuscated的安装命令用户无法看出命令在做什么pipe-to-shell 安装curl ... | sh或bash直接运行下载内容且没有清晰的审查路径未声明的密钥需求要求用户提供 secret 或 private key但在描述中隐瞒远程执行npx latest这类拉到最新版就执行的方式同样要求清晰可审查元数据掩盖真实运行需求listing 描述与实际行为不符。从仓库实现看这一点与 convex/lib/securityScanPolicy.ts、convex/lib/packageSecurity.ts 等模块的安全扫描策略相对应——ClawHub 会对上传产物做静态/动态安全检查并将结果映射为Pass/Review/Warn/Malicious等审计标签详见 Security Audits。发布者如果采用上述不可审查的安装方式即使扫描未命中恶意代码也很可能触发Review/Warn级别的策略告警。禁止的市场行为不止看内容更看发布者ClawHub 同样审查发布者如何利用市场。政策的出发点很明确不得利用 ClawHub 操纵发现机制、指标、信任信号、审核系统或用户注意力。具体禁止行为包括批量发布低质量内容大量发布低努力、重复、占位或机器生成的、看不出真实用户价值的 listing淹没搜索结果用近乎相同的 Skill/Plugin 刷屏搜索与分类表层无差异化的海量上架发布数百个几乎无使用量、无维护、源码不清晰或缺乏有意义差异化的 listing伪造参与指标通过自动化、自我安装循环、假账号、协同活动、付费参与或其他非自然行为人为抬高安装量、下载量、star 数等指标规避审核的账号轮换创建或轮换账号以规避审核、封禁、发布者限制或市场审查误导性表述在所有权、来源、能力、安全姿态、安装要求或与其他项目/发布者的从属关系上误导用户反复上传被处置内容未修复根本问题就反复上传已被隐藏、移除或阻止的内容。高量发布 ≠ 自动滥用政策特别澄清High-volume publishing is not automatically abuse高量发布本身不是滥用。大型目录只要满足四个条件就完全可接受listing 之间存在有意义的差异meaningfully different描述准确accurately described得到维护maintained被真实用户使用used by real users。当量与薄、重复、误导、无维护、人为推广叠加时大型目录才会变成信任与安全问题。这条边界对目录型发布者如维护大型工具集的组织尤其重要差异化和维护记录是抵御滥用判定的最佳证据。内容权利主张版权问题的专用通道如果认为 ClawHub 上的内容侵犯了自己的版权或其他权利应走 Content Rights Requests 流程提交https://clawhub.ai/owner/skills/skill形式的精确 URL、姓名/组织/联系邮箱、权利问题简述及证据而不要使用普通市场举报通道——除非该 listing 同时还不安全、恶意或误导。换言之渠道划分遵循问题类型而非情绪强弱不安全/恶意/误导内容 → 普通举报Report流程版权或权利纠纷 → Content Rights 通道ClawHub 自身漏洞 → Security 流程GitHub Security Advisories针对 ClawHub 本体而非第三方 Skill/Plugin。审查与执法信号如何变成处置多信号来源ClawHub 使用自动化检查、统计滥用信号statistical abuse signals、用户举报与员工人工审查来识别不安全内容或滥用性发布行为。政策原文特别强调A signal does not prove abuse by itself单一信号本身不构成滥用证据——信号的作用是帮助 ClawHub决定哪些内容需要进一步审查。执法手段梯度对违规行为ClawHub 可能采取从轻到重以下动作隐藏 / 搁置 / 移除 / 软删除资源类型支持的还可硬删除违规 listing阻止不安全版本的下载或安装吊销 API token软删除关联内容限制发布权限封禁重复或严重违规者。值得注意的是对于明显滥用行为ClawHub 不保证先警告后执法no guarantee of warning-first enforcement。这意味着发布者在触碰明显红线前不应指望收到提醒。源码印证处置状态与举报状态机从 convex/schema.ts 可以看到资源的审核状态moderationStatus被建模为三个字面量active正常可见hidden隐藏removed移除。Skills 与 packages 表还各自保存moderationReason、moderationVerdict、moderationReasonCodes、moderationEvidence、moderationSummary、moderationEngineVersion等字段并在hiddenAt/hiddenBy记录处置时间与操作者见 convex/schema.ts。这正是政策中软删除关联内容隐藏列表的落库形态。举报与申诉则被建模为严格的状态机convex/lib/artifactModeration.ts举报状态open → confirmed / dismissed已确认/已驳回可重开为open申诉状态open → accepted / rejected已接受/已拒绝可重开为open。非法状态迁移会被assertArtifactReportTransition/assertArtifactAppealTransition直接拒绝并抛出 ConvexError如Reopened reports cannot apply a final action同时每次举报/申诉动作都会以report/appeal两种 kind 写入skillModerationEventLogs/packageModerationEventLogs并同步落一条auditLogs审计记录convex/lib/artifactModeration.ts。这套实现保证了任何处置动作都可追溯——与政策中信号需要审查而非立即定罪的理念一致因为状态机的每一步都留痕误判可被申诉翻转。账号层面的自动执法发布者滥用压力信号政策提到Publisher abuse pressure signals are checked daily发布者滥用压力信号每日检查。在仓库中这一机制由 convex/lib/publisherAbuseScoring.ts 实现发布者会被打上pass/review/potential_ban_candidate三档标签模型版本publisher-abuse-pressure.v4与时间维度的publisher-abuse-temporal.v2见 convex/lib/publisherAbuseScoring.ts。其自动执法流程是达到potential_ban_candidate阈值z-score 打分超过potentialBanCandidateZThreshold的发布者触发自动警告警告期限后的下一次合格扫描若发布者仍处于潜在封禁阈值内可能自动执行账号处置低置信度和有界时间窗口审查信号lower-confidence and bounded temporal review signals不进入自动执法——保留人工复核空间。这与政策中信号不自动定罪的表述形成闭环高置信度信号可自动执行低置信度信号始终走人工。账号被删除/封禁/禁用后其 API token 即失效若 CLI 认证在账号处置后开始失败应登录 Web UI 查看账号状态封禁或禁用导致的登录受阻可走 ClawHub appeal form 恢复审查见 docs/moderation.md。给发布者的合规实操清单结合政策与 docs/moderation.md 中的发布者指引发布者可以从以下方面降低误判概率、提升用户信任名称、摘要、标签与 changelog 保持准确——描述本身是合规的一部分误导性表述单独构成禁止行为显式声明所需环境变量与权限——所需凭据明确是 UI/数据/自动化工作流放行的前提未声明的 secret/私钥需求本身就是禁止项避免混淆的安装命令——拒绝 pipe-to-shell、远程npx latest等不可审查执行方式尽可能链接源码——可审查性是防御性安全类别放行的关键发布 Plugin 前使用 dry-run——CLI 工具如clawhub支持先预览再发布对用户或审核人员关于发布行为的询问给出清晰回应——上下文与用途声明可能决定同一工具在允许/禁止清单之间的归属被标记为恶意时若扫描触发的邮件将某版本列为 malicious用clawhub scan download slug --version version插件加--kind plugin下载已阻止版本的扫描结果修复后递增版本号重新上传而非重复提交同一内容重复上传被处置内容本身就是禁止行为维护差异化目录型发布者确保每个 listing 独立、有用、准确描述并持续维护避免量 薄/重复/无维护的滥用画像。结语ClawHub 的可接受使用政策本质上是三把尺子内容用途尺允许/禁止分类、执行安全尺可审查性与发布行为尺市场操纵与指标造假。对普通发布者守住准确声明、可审查执行、真实使用、持续维护十六个字即可安全合规对审核与安全研究者仓库中 convex/schema.ts、convex/lib/artifactModeration.ts 与 convex/lib/publisherAbuseScoring.ts 则提供了从政策条文到落库状态、状态机与自动执法阈值的完整实现参照。赞分享后端前端AI 技能AI 插件搜索引擎【免费下载链接】clawhubSkill Plugin Registry for OpenClaw项目地址https://gitcode.com/gh_mirrors/mo/clawhub点击查看免费下载相关推荐Llama 4 可接受使用政策Acceptable Use Policy全面解析开发者合规部署与安全防护指南Llama 4 可接受使用政策Acceptable Use Policy全面解析开发者合规部署与安全防护指南 本指南以 llama models 仓库中人工智能大模型基础模型Llama 3.2 可接受使用政策Acceptable Use Policy全解禁止用途、欧盟限制与负责任部署落地指南Llama 3.2 可接受使用政策Acceptable Use Policy全解禁止用途、欧盟限制与负责任部署落地指南 导读 本文以本仓库 models/人工智能大模型基础模型Gekko 边界与核心设计解析市场数据、策略接口与订单执行机制Gekko 边界与核心设计解析市场数据、策略接口与订单执行机制 Gekko 是一个用 Node.js 编写的免费开源加密货币自动化交易套件本文以官方 Sco金融科技后端上一篇2025效率革命ERNIE-4.5-21B-A3B-Thinking如何用30亿参数重塑企业AI格局下一篇Fastify-cli项目结构深度剖析轻松掌握文件组织与最佳实践创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考