在 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 三个筛选选项。下方截图清晰地展示了两个协作入口位于同一页面，而非散落在仓库设置的某个角落。
- 入口：目标仓库顶部的 Community。操作：先浏览现有条目，再利用标题筛选框搜索相近问题。成功标志：列表中没有重复议题，左侧两个新建按钮均可看到。出错了怎么办：如果只看到登录提示，请先登录 Hugging Face 账号；如果找不到新建按钮，请确认你打开的是具体仓库，而非全站搜索结果页。
- 入口：Community 列表上方的类型筛选。操作：点击 Pull requests，仅查看涉及文件改动的协作内容。成功标志：Pull requests 按钮处于选中状态，列表条目均以绿色分支图标标识。出错了怎么办：如果列表为空，请打开 View closed 检查已关闭或已合并的记录，避免重复提交旧改动。
筛选生效后，页面上仍会保留 New discussion 和 New pull request 按钮，右侧的 View closed 可切换查看已结束的记录。若遇到“明明有人改过，但列表里找不到”的情况，建议先到 View closed 中查找，通常比重开一条新记录更高效。
发起 Discussion 清晰描述问题
若没有文件改动，请点击 New discussion。标题应直接写明问题或预期结果，例如“模型卡缺少推理示例”。正文中需补充复现条件、期望结果以及你已经尝试过的方法。编辑区支持 Markdown 和 LaTeX，长日志只需保留能定位问题的关键片段，避免全部粘贴。
- 入口：Community 左侧的 New discussion。操作：填写明确的标题和可复现的描述后提交。成功标志：跳转到带编号的详情页，标题下方显示 Discussion 类型，正文下方即为评论区。出错了怎么办：如果提交按钮无法点击，请检查账号是否已登录、标题是否为空；若涉及私有仓库，还需确认账号拥有访问权限。
- 入口：Discussion 详情页底部的评论框。操作：补充测试结果或回复维护者的问题。成功标志：新评论出现在时间线中。出错了怎么办：如果评论框无法输入，请先查看该线程是否已被锁定；锁定后旧评论仍可阅读，但无法添加新评论。
普通 Discussion 页面仅包含讨论线索，不会出现文件差异标签。下方截图中的标题旁编号、Discussion 标记和正文区域，是判断入口类型的依据。未登录时也能查看公开内容，但回复功能受登录状态限制。
编辑、置顶、锁定和隐藏评论的权限说明
讨论发起者、仓库作者或拥有写权限的成员，均可编辑标题。置顶和锁定操作需要仓库写权限。评论作者可以编辑自己发布的评论，有写权限的成员也能处理评论；页面会保留所有编辑历史。
隐藏评论之前务必慎重：此操作不可逆。锁定则不同，它不会删除现有内容，只是禁止他人再发新评论。公开协作时，建议先发布一条说明原因的回复，再锁定线程，这样其他参与者更容易理解为何事情已结束。
通过 Pull Request 提交可审阅的改动
如果你已经修改了模型卡、数据文件或 Space 代码，请点击 New pull request。简单改动可直接在网页上编辑文件后创建 PR；若需修改多个文件、进行多次提交或需要在本地测试，建议使用高级模式或 Git 工作流。高级模式创建后默认为 Draft 状态，确认内容完整后再发布为 Open；发布后无法退回 Draft。
- 入口：Community 左侧的 New pull request，或文件编辑后的创建 PR 选项。操作：核对目标分支，填写标题和改动说明，然后创建。成功标志：详情页标题下方同时显示 base 目标分支和 from 来源引用，并出现 Discussion、Files changed 两个标签。出错了怎么办：如果只能创建 Discussion，说明当前没有可提交的文件改动；如果目标分支不正确，请勿发布，退回创建页重新选择即可。
- 入口：Draft PR 页面。操作：补充提交内容、说明和测试结果后再发布。成功标志：状态由 Draft 变为 Open，维护者可按正式 PR 进行审阅。出错了怎么办：发布前若发现内容不足，可继续保留 Draft；一旦转为 Open，页面不支持恢复 Draft，只能继续修改或关闭。
PR 标题下的 base: refs/heads/main 表示目标分支，from: refs/pr/218 表示该 PR 的来源引用。该页面也说明 Hub 的 PR 不依赖 fork：改动是通过编号引用保存在来源仓库中的。
在 Files changed 页面审阅后合并
- 入口：PR 详情页的 Files changed。操作：按文件逐项检查增删行，确认改动范围与标题描述一致。成功标志：页面顶部的文件数、绿色新增行数和红色删除行数均与预期相符，差异区无无关文件。出错了怎么办：发现误删、密钥、缓存或大文件时，切勿合并，应回到来源分支修正后再推送，新提交会自动加入同一 PR。
- 入口：PR 的 Discussion 标签。操作：撰写具体的审阅意见，说明是哪个文件、哪个位置、期望修改成什么样。成功标志：作者可根据评论继续提交改动，Files changed 会随新提交更新。出错了怎么办：如果方向尚未确定，建议先关闭或保留 Draft，避免将讨论性意见直接当作可合并的结论。
- 入口：拥有写权限的维护者操作区。操作：确认文件差异和讨论均已解决后再合并；不采用的改动则关闭。成功标志：PR 进入 merged 或 closed 状态，可在 View closed 中查到。出错了怎么办：若看不到按钮，通常是因为没有写权限，需由仓库维护者完成最终操作。
Files changed 页面会将每个文件的差异直接列出。绿色代表新增行，红色代表删除行，顶部的统计数据能快速发现“只想改一行，却带进了整份文件”这类问题。
需要在本地检查 PR 时怎么办
PR 引用可按编号获取。例如，编号为 42 时，对应引用为 refs/pr/42。本地检查时，将该远程引用抓取到临时分支中，再运行仓库自带的测试。确认无误后，再回到网页完成讨论或合并。
关闭或合并后的 PR 引用可删除以释放存储空间，但此操作不可逆。只有确认再也不需要从该引用恢复提交时才可删除；如果只是暂时不合并，保留关闭状态更为稳妥。
完成一次协作前的核对清单
- 仅讨论问题使用 Discussion，有真实文件改动使用 Pull Request。
- 新建前已检查 All、类型筛选和 View closed，确保无重复条目。
- 标题能说明对象和结果，正文包含复现条件、改动范围或测试结果。
- PR 的目标分支和来源引用正确，Files changed 中无无关文件或敏感内容。
- 每条审阅意见均指出具体位置和预期修改方式，合并前已解决关键讨论。
- 锁定、隐藏评论和删除 PR 引用前，已确认权限和不可逆影响。
