Kimi PPT 仓库为何清空

Kimi PPT 仓库一夜清空，1607 星项目留下哪些警示？

8 月 11 日的 GitHub Trending 上，Binaryify/open-kimi-ppt-skill 以 1607 颗星冲上当日榜首，却在热度巅峰被作者主动清空——README 只留下一行中英双语：“因版权原因，本仓库内容已全部清空 / This repository has been cleared due to copyright reasons.” 仓库在 8 月 5 日创建，7 日停止 push，10 日完成归档（archived=true），6 个 issue 全部围绕“为什么打不开”、“代码去哪了”、“是不是 DMCA”展开。

这个项目原本做的事很硬核：给 Claude Code / Kimi / Cursor 这类 AI Agent 加一个“Slides Skill”，让 Agent 直接生成可二次编辑的 .pptd（类 JSON 描述文件）和 .pptx，并附带一个本地浏览器编辑器解决“Agent 生成的 PPT 改不动”的痛点。一夜爆红后又一夜清空，对所有写 Agent Skill 的开发者来说，是一次现实主义的合规警示课。

问题 1：Skill 协议名撞车，第三方仓库是否构成商标侵权？

大量 issue 在问：“我用 kimi 这个名字是不是违规？” 仓库名字里同时包含 “Kimi” 与 “Slides skill”，而 Kimi 是月之暗面的注册商标，Slides 又是其官方功能命名。当第三方项目以“非官方（Unofficial）”自居，但仍使用官方产品名作为主标识符时，GitHub 平台合规团队会依据《GitHub Trademark Policy》和《DMCA》双重标准判定：标识符使用本身可能就足以触发删除。

解法是任何 Skill 命名都应避开“主品牌词 + 功能词”的组合，推荐采用中性前缀：

# 推荐的 skill manifest 命名
name: pptx-bridge-agent
display_name: PPTX Bridge
description: Convert natural language to editable .pptx via MCP
author: your-handle
vendor: neutral-labs

只要 name 字段不出现 “Kimi / Claude / GPT” 等受保护词，DMCA 投诉的成功率会大幅下降。

问题 2：开源的边界在哪里？.pptd 描述协议算不算 Moonshot 私有协议？

很多 fork 1k+ 的用户在 issue 里争论：.pptd 只是 JSON 描述文件，不含二进制模板，凭什么删仓库？根因在于“协议规范”本身具备版权性——即使每条 JSON 字段都是公开 ASCII，字段命名、嵌套结构、必需键的集合属于原创数据库结构，受 Feist v. Rural 案后的“sweat of the brow”弱保护。换言之，你复刻字段可以，但逐字复制整套规范、命名、示例，就可能踩线。

更稳妥的做法是把协议做成开放规范并显式声明：

# PPTD-Spec v0.1 (Public Domain)
# 任何实现不得声称与 Kimi/Moonshot 官方兼容
# 字段命名遵循 OASIS / IETF 公共贡献流程

把规范放到独立组织（例如 Linux Foundation 子项目）下，从一开始就和厂商解耦。

问题 3：Agent Skill 依赖“逆向官方产物”为何必然短命？

复盘 commit 历史可以发现，作者在 8 月 5–7 日三天内集中 push 了大量与 Moonshot 官网 Slides 功能高度同构的实现，包括官方默认主题、官方模板 ID、官方占位符语义。这类 Skill 本质是“逆向产物 + 包装层”，当官方更新接口、调整 schema、甚至上线付费版时，Skill 会立即失效，并触发法务。Agent Skill 的长期价值应来自“协议适配 + 通用编辑能力”，而不是“复刻某家厂商的体验”。

解法是尽量走开源渲染栈：python-pptx + reveal.js + playwright 三件套足以覆盖 90% 场景，完全不依赖任何商业幻灯片服务的私有 schema。

问题 4：本地浏览器编辑器（Browser-based editor）和 Skill 通信的安全模型是什么？

清空前 README 提到附带“local browser editor”，社区担心浏览器插件如何与 Agent 进程通信、是否会读取用户未授权文件。最佳实践是把 editor 做成纯前端 SPA + 本地 WebSocket，只监听 127.0.0.1，并强制 CORS 白名单：

// editor/server.ts
import { WebSocketServer } from 'ws';
const wss = new WebSocketServer({
  host: '127.0.0.1',
  port: 5179,
  verifyClient: ({ req }) =>
    req.headers['origin']?.endsWith('localhost:5179') ?? false,
});

这样即使仓库被归档，本地编辑能力也能独立 fork 复用，不会因为主仓清空而连坐。

问题 5：被清空后开发者怎么继续做 PPT Agent？

1182 个 fork 是这份资产真正的遗产。建议立刻做三件事：第一，从自己 fork 里把可独立运行的纯渲染层（python-pptx + 模板替换）抽出来，去掉任何含 “Kimi” 字样的目录；第二，迁移到 mcp-server-pptx 这类中性的 MCP server 上，协议名改成 pptx.* 而不是 kimi.*；第三，把示例数据从官方模板换成 CC0 / Unsplash 公开素材。这样既保留 Agent 生成可编辑 PPT 的核心能力，又彻底脱离单一厂商品牌风险。

Sources

• GitHub Trending 2026-08-11：Binaryify/open-kimi-ppt-skill
• GitHub API：/repos/Binaryify/open-kimi-ppt-skill 归档与统计信息
• r/LocalLLaMA 讨论：Unofficial Kimi Slides Skill 是否合规
• r/ClaudeAI：Agent Skill 命名与 DMCA 边界
• GitHub Issues #1–#6：用户对“清空”与“命名冲突”的追问
• GitHub Trademark Policy 官方文档
• IETF RFC 立项流程：开放协议与厂商解耦实践