在 Hugging Face Hub 上开展协作，核心任务无非两类：要么进行问题讨论，要么提交代码或文件变更。无论选择哪种方式，都需要从仓库的 Community 入口进入。但两者有明显区别：纯讨论问题应使用 Discussion；若涉及实际文件改动，则需发起 Pull Request。正确选择入口后，维护者接收到的信息——包括入口类型、状态标识、审核记录——会更加清晰，从而显著提升协作效率。

这套规则适用于模型、数据集和 Space 仓库。日常交流中，可以确认需求、反馈问题、商讨方案，毫无限制；但 Pull Request 则不同，它绑定真实的文件变更，页面会额外显示来源引用和 Files changed 标签。值得注意的一点是，Hub 的 PR 无需先 fork 仓库，改动直接保存在来源仓库的自定义 Git 引用中，省去了不少中间环节。

首先进入 Community 选择正确入口

打开目标仓库，点击仓库导航栏中的 Community。页面左侧会显示 New discussion 和 New pull request 两个按钮，列表上方还有 All、Discussions 和 Pull requests 三个筛选选项。下方截图清晰地展示了两个协作入口位于同一页面，而非散落在仓库设置的某个角落。

1. 入口：目标仓库顶部的 Community。操作：先浏览现有条目，再利用标题筛选框搜索相近问题。成功标志：列表中没有重复议题，左侧两个新建按钮均可看到。出错了怎么办：如果只看到登录提示，请先登录 Hugging Face 账号；如果找不到新建按钮，请确认你打开的是具体仓库，而非全站搜索结果页。
2. 入口：Community 列表上方的类型筛选。操作：点击 Pull requests，仅查看涉及文件改动的协作内容。成功标志：Pull requests 按钮处于选中状态，列表条目均以绿色分支图标标识。出错了怎么办：如果列表为空，请打开 View closed 检查已关闭或已合并的记录，避免重复提交旧改动。

筛选生效后，页面上仍会保留 New discussion 和 New pull request 按钮，右侧的 View closed 可切换查看已结束的记录。若遇到“明明有人改过，但列表里找不到”的情况，建议先到 View closed 中查找，通常比重开一条新记录更高效。

发起 Discussion 清晰描述问题

若没有文件改动，请点击 New discussion。标题应直接写明问题或预期结果，例如“模型卡缺少推理示例”。正文中需补充复现条件、期望结果以及你已经尝试过的方法。编辑区支持 Markdown 和 LaTeX，长日志只需保留能定位问题的关键片段，避免全部粘贴。

1. 入口：Community 左侧的 New discussion。操作：填写明确的标题和可复现的描述后提交。成功标志：跳转到带编号的详情页，标题下方显示 Discussion 类型，正文下方即为评论区。出错了怎么办：如果提交按钮无法点击，请检查账号是否已登录、标题是否为空；若涉及私有仓库，还需确认账号拥有访问权限。
2. 入口：Discussion 详情页底部的评论框。操作：补充测试结果或回复维护者的问题。成功标志：新评论出现在时间线中。出错了怎么办：如果评论框无法输入，请先查看该线程是否已被锁定；锁定后旧评论仍可阅读，但无法添加新评论。

普通 Discussion 页面仅包含讨论线索，不会出现文件差异标签。下方截图中的标题旁编号、Discussion 标记和正文区域，是判断入口类型的依据。未登录时也能查看公开内容，但回复功能受登录状态限制。

编辑、置顶、锁定和隐藏评论的权限说明

讨论发起者、仓库作者或拥有写权限的成员，均可编辑标题。置顶和锁定操作需要仓库写权限。评论作者可以编辑自己发布的评论，有写权限的成员也能处理评论；页面会保留所有编辑历史。

隐藏评论之前务必慎重：此操作不可逆。锁定则不同，它不会删除现有内容，只是禁止他人再发新评论。公开协作时，建议先发布一条说明原因的回复，再锁定线程，这样其他参与者更容易理解为何事情已结束。

通过 Pull Request 提交可审阅的改动

如果你已经修改了模型卡、数据文件或 Space 代码，请点击 New pull request。简单改动可直接在网页上编辑文件后创建 PR；若需修改多个文件、进行多次提交或需要在本地测试，建议使用高级模式或 Git 工作流。高级模式创建后默认为 Draft 状态，确认内容完整后再发布为 Open；发布后无法退回 Draft。

1. 入口：Community 左侧的 New pull request，或文件编辑后的创建 PR 选项。操作：核对目标分支，填写标题和改动说明，然后创建。成功标志：详情页标题下方同时显示 base 目标分支和 from 来源引用，并出现 Discussion、Files changed 两个标签。出错了怎么办：如果只能创建 Discussion，说明当前没有可提交的文件改动；如果目标分支不正确，请勿发布，退回创建页重新选择即可。
2. 入口：Draft PR 页面。操作：补充提交内容、说明和测试结果后再发布。成功标志：状态由 Draft 变为 Open，维护者可按正式 PR 进行审阅。出错了怎么办：发布前若发现内容不足，可继续保留 Draft；一旦转为 Open，页面不支持恢复 Draft，只能继续修改或关闭。

PR 标题下的 base: refs/heads/main 表示目标分支，from: refs/pr/218 表示该 PR 的来源引用。该页面也说明 Hub 的 PR 不依赖 fork：改动是通过编号引用保存在来源仓库中的。

在 Files changed 页面审阅后合并

1. 入口：PR 详情页的 Files changed。操作：按文件逐项检查增删行，确认改动范围与标题描述一致。成功标志：页面顶部的文件数、绿色新增行数和红色删除行数均与预期相符，差异区无无关文件。出错了怎么办：发现误删、密钥、缓存或大文件时，切勿合并，应回到来源分支修正后再推送，新提交会自动加入同一 PR。
2. 入口：PR 的 Discussion 标签。操作：撰写具体的审阅意见，说明是哪个文件、哪个位置、期望修改成什么样。成功标志：作者可根据评论继续提交改动，Files changed 会随新提交更新。出错了怎么办：如果方向尚未确定，建议先关闭或保留 Draft，避免将讨论性意见直接当作可合并的结论。
3. 入口：拥有写权限的维护者操作区。操作：确认文件差异和讨论均已解决后再合并；不采用的改动则关闭。成功标志：PR 进入 merged 或 closed 状态，可在 View closed 中查到。出错了怎么办：若看不到按钮，通常是因为没有写权限，需由仓库维护者完成最终操作。

Files changed 页面会将每个文件的差异直接列出。绿色代表新增行，红色代表删除行，顶部的统计数据能快速发现“只想改一行，却带进了整份文件”这类问题。

需要在本地检查 PR 时怎么办

PR 引用可按编号获取。例如，编号为 42 时，对应引用为 refs/pr/42。本地检查时，将该远程引用抓取到临时分支中，再运行仓库自带的测试。确认无误后，再回到网页完成讨论或合并。

关闭或合并后的 PR 引用可删除以释放存储空间，但此操作不可逆。只有确认再也不需要从该引用恢复提交时才可删除；如果只是暂时不合并，保留关闭状态更为稳妥。

完成一次协作前的核对清单

• 仅讨论问题使用 Discussion，有真实文件改动使用 Pull Request。
• 新建前已检查 All、类型筛选和 View closed，确保无重复条目。
• 标题能说明对象和结果，正文包含复现条件、改动范围或测试结果。
• PR 的目标分支和来源引用正确，Files changed 中无无关文件或敏感内容。
• 每条审阅意见均指出具体位置和预期修改方式，合并前已解决关键讨论。
• 锁定、隐藏评论和删除 PR 引用前，已确认权限和不可逆影响。