artifact-cafe

artifact.cafe

技能版本：0.13.1

artifact.cafe 托管用于评审的静态产物。一个循环：

publish a folder → review URL → guest comments (no login) → publish v2

它不是通用托管平台。它托管自包含的静态产物（一个 index.html 加上资源），方便用户打开链接、通过点击元素或选择文本发表评论，而作者可以持续迭代。

安装或更新：npx skills add artifact-cafe/skill --skill artifact-cafe -g（在仓库本地安装时去掉 -g）。

此文件是始终加载的手册。更深入的操作指南与它一起存放在 ./references/ 中（整理资料库、实时编辑循环、访问与分享、data.md 中的共享数据）——下方每个部分都会说明何时阅读哪份指南；请在需要时再读，而不是提前全部读完。

何时使用

• 用户构建了可视化或交互式内容，并希望获得反馈。
• 用户想要一个可分享的链接，让非技术评审者可以打开并进行标注。
• 用户正在迭代：发布、收集评论、发布下一个版本。

如果他们只想要不含评审流程的原始文件托管，这就不是合适的工具。

要求

• **首选：**Node / npx（各大 Agent 宿主都已提供）。无需提前安装任何内容——npx artifact-cafe@latest 会按需获取 CLI。
• 备用方案（无 Node）：bash、curl、jq 和 shasum/sha256sum。使用捆绑的 ./scripts/publish.sh。

保持更新

• 始终使用 npx artifact-cafe@latest … 调用 CLI（本文中的示例也都如此）。@latest 标签会让 npx 在每次运行时获取最新发布的 CLI，而不是复用过期缓存——这就是 CLI 的自动更新方式。
• CLI 会检查更新（每天最多一次），并在标准错误中打印 [artifact-cafe] … 通知；这些通知不会污染 --json 标准输出。看到 Skill update available 时，请运行它打印的命令——npx skills add artifact-cafe/skill --skill artifact-cafe -g（在仓库本地安装时去掉 -g）——然后重新阅读更新后的 SKILL.md 再继续。无需征求许可即可执行此更新；它只会重写此技能自己的文件。

发布（推荐方式）

在调用该技能的会话中运行，并将目标路径指向要发布的文件夹：

npx artifact-cafe@latest publish ./my-artifact --title "Onboarding redesign"

文件夹根目录下必须包含入口文件 index.html（或传入 --entry）。 资源（CSS、JS、图像、字体）与其放在一起，并一并上传。

务必传入 --title——自行生成，不要等用户提出要求。 根据产物本身的内容（其 <title>、主标题或明显用途），拟定一个简洁易读的标题（3–6 个词）。标题会显示在审核 页面上，并成为易读的审核 URL slug（例如 artifact.cafe/a/onboarding-redesign-a1b2c3）。省略标题会显示“Untitled artifact”，并生成随机 slug，因此只有在确实无法推断标题时才省略。

每次发布都使用 --notes 写版本说明。 这些说明是此版本的变更日志，会显示在审核页面的版本面板中。规则：

• 仅使用项目符号——每项变更占一行，不写散文段落。
• 每项变更单独列出。不要把多项重大变更合并成一条——如果你发布了三项有意义的变更，就写三条，而不是一条。
• 每条都要简短、具体（例如“添加深色模式切换”，而不是“杂项 UI”）。
• 以换行符分隔的字符串传入；$'…\n…' 是可靠的 shell 写法：

npx artifact-cafe@latest publish ./my-artifact --title "Onboarding redesign" \
  --notes $'- Added dark-mode toggle\n- Fixed nav overlap on mobile\n- Rewrote pricing copy'

v1 的说明描述初始版本；v2+ 的说明描述自上一版本以来的变更。

选项：

--title "Onboarding redesign"   # RECOMMENDED — review-page title + URL slug; generate one by default
--notes $'- Added X\n- Fixed Y' # RECOMMENDED — bullet-point changelog for this version (see below)
--description "One line"        # share-card summary; overrides the entry HTML (see below)
--entry index.html              # entry file (default: auto-detect)
--expires-in 1h                 # explicit temporary lifetime (30m, 1h, 7d)
--artifact art_xxx              # publish a new version to an existing artifact
--force                         # intentionally publish despite a newer version; no merge
--workspace acme                # explicit team workspace
--folder specs                  # folder in that workspace — SETS VISIBILITY, see below
--review off                    # plain artifact: no review tools (see below)
--json                          # machine-readable output (use this for agents)
--no-open                       # don't try to open a browser

除非用户另有要求，否则保持审核开启。 发布的目的就在于收集反馈。只有当用户明确表示需要交付物、演示或作品集项目，而不是反馈时，才使用 --review off；它会生成完全不带审核功能的普通产物。 --review readonly 会保留现有评论供人阅读，并禁止新增评论。 之后可使用发布令牌在无需账户的情况下更改设置：

npx artifact-cafe@latest review readonly   # close it to new comments
npx artifact-cafe@latest review open       # reopen it

此操作不会删除评论；重新开启审核后，评论会重新显示。

--folder 决定谁可以打开审核链接。 文件夹具有可见性（public 或 workspace），产物发布时会继承该设置。发布到 workspace 文件夹后，审核 URL 就不再是任何人都能打开的链接——访问者需要登录，且只有该工作区的成员可以访问。 如果不传入 --folder，新产物将设为 unlisted：任何拥有链接的人都能访问，无需账户。因此，先运行 npx artifact-cafe@latest folders --workspace <handle> --json 确认文件夹的可见性，并在发布到 unlisted 以外的位置前告知用户。默认仍会归档——参见“保持资源库井然有序”。

publish --json 会在 visibility 中报告结果 （public | unlisted | workspace | private）——读取该值，并告诉用户他们即将分享的链接实际会带来什么效果。参见“告知用户的内容”。

首次以匿名方式发布到新文件夹时，命令会输出一个审核 URL和一个认领 URL（仅显示一次）。它会将产物 ID 和机密发布令牌写入 .artifactcafe/config.json，并将该文件加入 gitignore。

务必在首次发布前确定目标位置——参见下文“选择发布位置”。始终使用 --json，并报告其 destination 和 destinationSource 字段。

如果发布返回 409 version_conflict，说明另一个会话在你的基础版本之后发布了内容。错误信息中包含 currentVersion。运行 artifact-cafe pull，将最新文件与本地更改合并，然后重新发布。切勿自动使用 --force 重试：这会在不进行合并的情况下，用本地文件覆盖较新的版本。CLI 会在发布或关联后记住你的基础版本。未保存基础版本的旧版客户端会继续沿用原有行为。

临时工件

对于新创建的一次性预览或交互，请根据用户的任务选择有效期，并使用 publish --expires-in 1h --json。模式不会决定是否发布。现有工件保持原有有效期，除非用户要求更改；普通重新发布会保留明确设置的截止时间。切勿仅仅因为正在编辑某个现有工件，就推断需要为其设置新的临时截止时间。

从结果中读取 autoDeleteAt 和 expiresAt。在分享审核 URL 时，附上带时区的准确实际到期时间，并告知用户所有版本、评论、文件和工件数据都将被删除。计时从发布完成时开始；不要根据自己的时钟计算截止时间。时长必须是后接 m、h 或 d 的正整数。

到期前，控制器可以延长有效期或保留工件，而不会创建新版本：

npx artifact-cafe@latest expiration --in 7d --json
npx artifact-cafe@latest expiration --keep --json

文件夹绑定、--artifact <id> 和常规身份验证链均适用。管理员还可以通过审核工具栏中的时钟和 Settings → General → Lifetime 使用 Set expiry，然后选择 Keep permanently。时钟面板仅在点击后打开；在手机上，面板和操作会占满可用宽度。纯文本模式下，仍需在设置中管理有效期。

Keep permanently 是 expiration --keep 在界面中的名称；它会移除明确设置的临时截止时间。对于自有工件，这意味着不会自动到期，同时保留 URL、版本和评论。不要将清除临时截止时间描述为让匿名工件永久保留：还必须认领该工件，才能移除匿名保留期限。报告返回的 expiresAt；null 表示不再有自动到期时间。 到期后，新的访问会被阻止，项目也会从列表和搜索结果中移除；每日后台清理会删除其内容，并重试失败的操作。没有恢复期限。匿名保留期限仍会限制工件的有效期，直至工件被认领：--keep 只会清除明确设置的截止时间，而认领操作会保留明确设置的截止时间。

让分享链接正确展开预览

将审核 URL 粘贴到 X、Threads、Slack、Telegram 或 Discord 时，预览卡片会根据工件生成。默认情况下，它是自动生成的 artifact.cafe 卡片，内容与审核相关。这适合希望获得反馈的仪表板，但对于供人阅读的内容来说并不合适。

如果创建的内容是供阅读而非审核（例如文章、报告、指南或比较），请在入口文件的 <head> 中加入以下内容：

<meta name="description" content="One line on what this is.">
<meta property="og:image" content="cover.png">
<meta name="author" content="Ada Lovelace">

API 会在发布时读取这些内容，因此所有发布方式都适用：npm CLI、bash 后备方案和原始 API 调用。也接受 og:description 和 article:author。三项都不设置时，链接的行为与以往完全相同。

图片有一些规则，且都由服务器端强制执行：

• 必须是你要发布的文件夹中的文件。 cover.png、./cover.png 和 /assets/cover.png 均可使用。远程 URL、协议相对 URL 和 data: URI 都会被直接拒绝。
• 必须是 PNG、JPEG、WebP 或 GIF，且小于 5 MB。推荐尺寸为 1200x630。不支持 SVG。
• 被拒绝的内容会静默回退到自动生成的卡片。不会造成其他问题，描述和署名仍会发布。

--description "…" 会覆盖入口文件中声明的内容。如果文档自己的 meta 描述不是适合显示在动态中的句子，请使用此参数。

受限工件不会声明任何内容。 无论标签为何，受密码保护、工作区和私有工件始终会展开为锁定卡片，因此无需为其设置任何内容。

选择发布位置（创建新制品前执行）

**运行时 Agent 令牌：**如果 ARTIFACT_CAFE_API_KEY 以 aat_ 开头，请直接使用该凭据，不要打印或保存。跳过 whoami、登录、工作区发现和文件夹选择。发布时不要使用 --workspace 或 --folder；令牌会准确选择其自身的工作区，项目默认设置不适用。comments、reply 和 resolve 会使用已保存的绑定，并标注 Agent 身份。新制品默认设为 unlisted：任何拥有链接的人都可以查看，无需账号。该制品没有匿名过期时间、认领 URL 或永久发布令牌。不要尝试使用账号、授权、成员或工作区管理命令。运行结束时，运行时会撤销该令牌；令牌过期或被撤销时会返回 401。

此规则适用于使用普通凭据首次发布新文件夹的情况。新版本会沿用 .artifactcafe/config.json 中记录的目标位置——跳过以下所有步骤，直接再次执行 publish。按以下优先级确定目标位置：

**1. 先检查登录状态。**运行 npx artifact-cafe@latest whoami --json。

• 已登录（退出码为 0）：以该账号身份发布。已登录的用户不应意外发布到匿名制品（有效期为 24 小时）——这正是此顺序要避免的问题。请注意，密钥会按来源站点解析，而 ARTIFACT_CAFE_URL 会选择来源站点：如果 whoami 对你即将发布到的来源站点执行失败，账号密钥也无法用于此次发布——请明确告知用户这一点（他们在该来源站点未登录），而不是悄悄以匿名方式发布。
• 未登录（非零退出码）：直接发布。这将创建一个匿名制品——24 小时后过期，并返回一次性认领 URL。告知用户这是匿名制品；同时说明先执行 artifact-cafe login 会创建一个由账号所有且不会因匿名保留机制而过期的制品。

**2. 然后选择工作区（仅限已登录）。**如果用户明确指定了 --workspace，或项目 artifact-cafe.json 中设置了默认工作区，则使用该工作区，不要询问。否则，使用 npx artifact-cafe@latest workspaces --json 列出账号的工作区，并按以下规则选择：

• 只有 Personal（没有团队工作区）：发布到 Personal，无需询问。
• Personal 加团队工作区：不要默认静默选择 Personal。查看制品的内容；如果其明显主题与用户的某个工作区相符（例如，内容是为某个名为「hellyeah」的产品制定计划，而存在一个 hellyeah 工作区），则询问用户是要发布到该工作区还是 Personal，然后相应地传入 --workspace <handle>。

内容只能作为询问什么的线索——绝不要根据内容猜测工作区，并静默地将制品发布到该工作区；应由用户的选择决定。--json 会禁用 CLI 自带的交互式工作区选择器，因此，跳过此步骤的已登录 Agent 会直接默认选择 Personal——这正是你需要自行执行这两项检查的原因。

保持资料库井然有序（文件夹）

每个工作区（包括 Personal）都有一个扁平的文件夹列表（不嵌套）。归档是做好发布的一部分：在发布时将每个制品放入相应文件夹，而不是把所有内容都丢在一个未归档的堆里。

3. 选择文件夹（在选择工作区之后、首次发布之前）。 确定工作区后，列出其中的文件夹：

npx artifact-cafe@latest folders --workspace <handle> --json

• 如果现有文件夹明显符合该制品的主题，请使用 --folder "<name>" 发布（名称必须完全匹配且区分大小写，也可以使用文件夹 ID）。按含义匹配，而不是按字符串是否相同匹配——即使没有重合的词，新规范也应归入「Specs」文件夹。
• 如果没有合适的文件夹，就不要勉强匹配，让制品保持未归档状态。仅当确实存在一组制品时才创建文件夹（folders create "<name>" --workspace <handle>）——绝不要为单个制品创建文件夹——并且先复用现有文件夹再创建：CLI 会拒绝重名；遇到这种情况时，请将其视为「使用现有文件夹」。
• ⚠ 文件夹的可见性会成为制品的可见性。 发布到 public 文件夹或移入该文件夹会使制品公开，整个过程中不会出现确认提示——在任何公开操作之前都要向用户确认，并报告每一次可见性变更（参见上文「--folder 决定谁可以打开审核链接」）。
• 重新归档而不重新发布：npx artifact-cafe@latest move --folder "<name>"（使用 --artifact <id> 指定目标，使用 --unfiled 移至根目录）。不会创建新版本；评论保持不变。

当用户要求你整理他们的资料库时（「整理我的制品」「清理我的工作区」），请先阅读 ./references/organize.md，并遵循先展示计划的流程——未经展示计划，绝不要批量移动或批量创建。该文档还包含文件夹创建规则、命名指南，以及 move/list --workspace 的详细信息。文件夹命令需要 Node CLI 和已登录的账户；bash 备用方案无法管理归档位置。

不使用 Node 发布（备用方案）

使用纯 bash 执行相同的静态发布流程，适用于无法使用 npx 的环境：

./scripts/publish.sh ./my-artifact --title "Onboarding redesign"

它支持 --title、--entry、--artifact、--json 和 --no-open，使用相同的 API，并写入相同的 .artifactcafe/config.json。工作区发现、项目默认设置和人工选择器需要 npm CLI。如果新制品带有 artifact-cafe.json 策略，备用方案会拒绝发布，而不会静默地将其发布到不同的目标位置。

发布新版本

版本是不可变的——新发布不会修改现有版本，评论也会保留在其所对应的版本上。要发布 v2，只需在同一目录中再次发布同一文件夹：

npx artifact-cafe@latest publish ./my-artifact \
  --notes $'- Moved the CTA above the fold\n- Tightened hero spacing'   # → v2, v3, …

请传入 --notes，说明自上个版本以来发生了哪些变化——如果新版本没有变更日志，审核者就无法判断哪些内容需要重新审核。

运行时的 aat_ Agent 令牌，或存储在 .artifactcafe/config.json 中的发布令牌，会自动授权发布新版本。从不包含该令牌的全新检出目录发布时，请设置 ARTIFACT_CAFE_TOKEN（发布令牌），或使用 --artifact <id> 指定目标。如果你已登录，artifact-cafe link --artifact <id>（或 --slug <slug>）可以将文件夹关联到任何你有权发布到的制品——无论是你自己的制品，还是你所属工作区中队友的制品——这样后续命令就可以直接运行：无需令牌，账户操作使用你的登录身份。link --json 会先列出候选项。这就是在他人发布的工作基础上继续创作的方式。

编辑前下载

如果某个制品不在磁盘上，请先拉取再编辑：

npx artifact-cafe@latest pull ./artifact --artifact art_x --json

拉取会将当前版本的每个文件下载到其原始路径，包括未被引用的文件（例如 cafe.data），并验证 SHA-256 哈希值和文件大小。使用 --version N 可指定历史版本。目标目录非空时必须使用 --force，该选项会覆盖匹配的文件并保留无关文件。授权方式包括工作区成员身份、制品所在工作区中的 Agent 令牌，或匿名／个人制品的发布令牌。访客权限不够。拉取会建立关联，不会生成新密钥，并设置 baseVersion。刷新同一制品会保留现有凭据和位置。即使使用 --force，也会拒绝关联到其他制品的目录；请改用其他目录。link 只会关联现有本地文件。JSON 会返回 artifactId、versionNumber、dir 和 files（包含 path、hash、size、mimeType）。

请将源文件和辅助文件与静态入口文件一同发布，而不要只发布构建产物，这样下一个 Agent 就能拉取并编辑它们。拉取无法还原从未发布的源文件。下载命令需要 npm CLI。

拉取评论

这是工作循环的读取环节——查看审阅者的反馈，以便 Agent 予以处理：

npx artifact-cafe@latest comments            # open threads on the current version
npx artifact-cafe@latest comments --json     # structured, for programmatic handling
./scripts/comments.sh                 # no-Node fallback

筛选条件：--status open|resolved|all、--version current|all。每个讨论串都包含作者、评论所在的版本、锚点（引用的文本片段或元素路径）、消息正文和回复。处理反馈后，发布下一个版本，再使用 reply／resolve（见下文）结束讨论。

CLI 和备用方式都支持使用 --artifact <id>（或 ARTIFACT_CAFE_ARTIFACT_ID）在没有制品文件夹的情况下读取制品——与 publish 使用相同的脱离目录定位方式；对于受密码保护的制品，请添加 ARTIFACT_CAFE_TOKEN。

回复评论

这是工作循环的写入环节——Agent 发布处理反馈的版本后，如何回复反馈。请从 comments --json 中获取每个讨论串的 id：

# Post what changed back into the thread, then close it — one step
npx artifact-cafe@latest reply <threadId> --body "Fixed in v2 — CTA moved above the fold." --resolve

npx artifact-cafe@latest reply <threadId> --body "…"     # reply, leave it open
echo "$msg" | npx artifact-cafe@latest reply <threadId>  # long body from stdin
npx artifact-cafe@latest resolve <threadId>              # close a thread you addressed
npx artifact-cafe@latest reopen <threadId>               # undo — reopen a resolved one

使用发布令牌或 Agent 令牌回复时，回复会归于Agent名下：审阅者会看到“Yulong's Claude”，并显示你所用工具的标记——你的自称名称（自动检测，或通过 --as "Claude Code" 指定）会与制品所有者的名称组合显示。使用已登录的账户回复时，回复则显示为所有者发布，工具名称会作为“via”标签显示。建议使用 reply --resolve，而不要单独使用 resolve——这样可以告诉审阅者你做了什么更改，而不是悄无声息地关闭讨论串。定位方式与其他命令相同（--artifact <id> + ARTIFACT_CAFE_TOKEN，或账户密钥）；所有命令都接受 --json。

修正或撤回你发送的消息——从 comments --json 中获取 id（每个讨论串的 messageId 对应其开场评论，每条回复的 id 对应该回复）：

npx artifact-cafe@latest edit <messageId> --body "Revised — moved the CTA, not removed it."
npx artifact-cafe@latest delete <messageId>

你只能编辑或删除自己撰写的消息——由令牌授权的 Agent 回复，或你自己账户发布的评论；必须使用撰写该消息时所用的相同凭据授权修改。edit 会添加“已编辑”标记（不保留历史记录）。delete 是软删除：评论会变成“评论已删除”的墓碑，其下的回复仍会保留。

开启审阅讨论串

reply 用于回复现有讨论串；comment 则开启新的讨论串——用于在制品上留下你自己的审阅备注：

npx artifact-cafe@latest comment --quote "Where AI work lives" --body "This headline is vague."
npx artifact-cafe@latest comment --body "Overall this reads well."   # page-level, no --quote

与工作循环中的其他命令不同，comment 会以你的账户身份发布，因此需要先运行 artifact-cafe login——发布令牌无法开启讨论串（Agent 负责回复，账户负责发起）；如果你只有发布令牌，命令会提示登录。--quote 会将讨论串锚定到匹配的文本（若引文重复，可使用 --prefix／--suffix 消除歧义）；不提供 --quote 时，评论会针对整个页面。--as "Claude Code" 会设置显示在账户名称后的标签——该标签只会附加显示，不会替代账户名称；如果未指定，则会从你的环境中自动检测。

comment、edit 和 delete（与 listen 一样）需要 Node CLI——不支持 bash 备用方式。

提供实时编辑模式（自选）

发布和实时编辑是两个独立操作。发布并分享评审 URL 后，询问用户是否要进入实时编辑模式：你将继续连接本地产物，接收新评论（npx artifact-cafe@latest listen --json --timeout 540），进行修改，并在用户评审期间发布新的不可变版本。

不要自动启动实时编辑模式。 用户可能只想分享链接并异步收集反馈，而不希望 Agent 会话保持活动状态。用户明确同意后，阅读 ./references/live-editing.md 并运行其中描述的循环（监听 → 编辑 → 发布 → reply --resolve → 监听）。当 listen 以 2 退出（超时）时，告知用户监听时段已结束，并询问是否继续，然后再运行；绝不要让无人值守的会话无限期保持活动状态。

持久共享数据

对于在访客之间共享的投票、留言簿、RSVP 或提交内容收集，请使用 Artifact Data。必须先认领产物；访客无需账号即可提交。编写清单前，请阅读 ./references/data.md。

打开评审页面

npx artifact-cafe@latest open     # prints (and, in a terminal, opens) the review URL

本地配置和发布令牌

首次发布后，文件夹中会包含以下内容（aat_ 发布不会包含 publishToken）：

.artifactcafe/config.json

{
  "artifactId": "art_…",
  "slug": "…",
  "url": "https://artifact.cafe/a/…",
  "apiUrl": "https://artifact.cafe",
  "publishToken": "apt_…"
}

• publishToken 是一个机密，仅返回一次，用于授权向此产物发布新版本。绝不要打印、提交或记录它。 CLI 会以 chmod 600 权限存储它，并将 .artifactcafe/ 添加到 .gitignore。
• 将 config.json 视为内部关联状态，而非 URL。绝不要把本地文件路径当作评审链接提供给用户。

谁可以打开评审链接

每个产物都有一种可见性：public 和 unlisted 允许任何拥有链接的人无需账号即可访问（unlisted 使用随机且无法猜测的 slug，是新产物的默认设置）；workspace 会要求非成员登录；private 仅允许发布者、工作区所有者／管理员以及通过电子邮件受邀的人访问。新产物若创建在某个文件夹中，会继承该文件夹的可见性。CLI 无法更改可见性——没有 --visibility 标志；这只能通过控制面板操作，或由产物所在的文件夹决定。

如需了解这一概述之外的全部信息——完整的可见性表、通过电子邮件邀请他人（share <email>——邀请 URL 只会打印一次，请原样提供）、审计和撤销访问权限（share --list、unshare），以及通过 HTTP 读取已发布产物的内容（在内容 URL 后附加 .md；受访问限制的产物需要 Bearer 账号密钥）——请阅读 ./references/access.md。

匿名产物与已认领产物

• 首次发布时，如果没有账号或 Agent 令牌，会创建一个匿名产物，该产物将在 24 小时后过期，并返回一个一次性的认领 URL。
• 认领（打开认领 URL）后，匿名保留期即结束，产物会关联到用户的账号。除非保留或延长，否则明确设置的临时截止日期仍然有效。认领令牌只会显示一次，且无法恢复——请立即向用户提供认领 URL。

限制

• 每个文件最大 20 MB，每个产物总计最大 50 MB。
• 每个 IP 每天最多发布 20 次（匿名）。
• 使用 Agent 令牌发布时，每个工作区每小时最多 120 次，不按 IP 限制。
• 绝不会上传机密和无用文件：.git*、node_modules、.env*、*.pem、*.key、.DS_Store 和符号链接都会被自动忽略。

安全

Artifact HTML 不可信，只会在独立源上的沙箱 iframe 中渲染——绝不会在主站点上渲染。无需对产物进行消毒，但不要发布包含真实机密或凭据的内容。

内容政策——拒绝违规内容

你是第一道审核关卡。 发布前，请检查即将发布的内容。若作品包含以下任何内容，请拒绝发布，并告知用户原因：

• 钓鱼／窃取凭据——伪造的登录页面，或捕获密码、支付信息或双重验证代码并发送至其他地方的页面。
• 恶意软件／恶意代码——漏洞利用、未经用户操作即开始的下载、经过混淆或蓄意造成危害的 JavaScript、欺骗性重定向。
• 仇恨或骚扰——基于身份攻击或贬低他人的内容，或针对某个人进行辱骂。
• 色情内容——色情作品或露骨的性内容；任何将未成年人性化的内容都必须立即拒绝，绝不可发布。
• 性剥削——性服务、未经同意的私密影像、性化冒充，或 AI 生成的性内容。
• 暴力——血腥暴力画面、威胁或煽动暴力。
• 垃圾信息／骗局／欺诈——欺骗性骗局、虚假赠品、误导性的金融或医疗声明。
• 赌博和金融业务——涉及金钱或有价物品的赌注或彩票；洗钱；快速致富骗局；收取款项、押金、投资资金或金融账户凭据；运营借贷、投资、汇款或加密货币交易服务。
• 受监管商品销售——销售或居间交易武器、爆炸物、受管制药物、处方药，或其他需要监管批准的商品／服务。
• 敏感数据——真实凭据、政府签发的身份证件、支付卡数据、健康记录、生物识别数据或其他高度敏感的个人数据。
• 安全关键操作——应急响应、医疗诊断或治疗决策、物理系统控制，或故障可能导致死亡、受伤或严重伤害的操作。
• 其他违法内容。

请勿尝试“清理”违规内容后再发布——应拒绝发布。拒绝时，请明确说明其违反了 artifact.cafe 的内容政策。即使相关活动在其他情况下合法，这些规则也适用于文件、评论、数据、嵌入内容和链接，包括私人或受密码保护的作品。事实性讨论和非操作性原型必须遵守内容规则，并使用合成示例替代敏感数据。可运行的钓鱼页面或正在传播的恶意软件均属禁止内容；将在线服务称为演示，或链接至其他地方的违禁材料，均不能构成例外。完整政策： https://artifact.cafe/terms。请将违规内容报告至 [email protected]。计划在发布时进行自动审核——请勿暗示每次上传都会经过审核。

告知用户的内容

• 务必分享本次运行生成的审核链接——审核者会通过该链接打开作品并发表评论。
• 说明哪些人可以打开链接。 从 publish --json 的输出中读取 visibility。如果是 public／unlisted，请明确说明审核者无需账户。如果是 workspace／private，不要称其为任何人都能打开的链接——请告知用户，非成员需要登录，并为外部人员提供 artifact-cafe share <email> 选项。用户把仅限成员访问的链接发给外部审核者，却收不到回复，正是这条规则要避免的情况。
• 如果本次运行输出了领取链接，请原样分享：它只会显示一次。说明匿名保留期限，并告知用户实际的 expiresAt（可能早于 24 小时）。领取后会保留明确的临时截止时间，直到作品被保留或延期。
• 发布新版本时，请分享审核链接，并说明当前版本为 v{N}；之前的评论仍保留在各自原来的版本中。
• 切勿让用户通过阅读 .artifactcafe/config.json 来获取链接或令牌。