github projects 是 github 数据的视图层，状态变更须通过 issue、pr 或手动更新字段触发；选“板”适合迭代跟踪，“路线图”仅用于版本时间线规划；需规范使用 issue/pr、自定义字段及自动化才能真正联动开发流程。
GitHub Projects 不是“项目管理软件的平替”，它本质是 GitHub 数据的视图层——所有状态变更必须通过 Issue、Pull Request 或手动更新字段触发，直接拖拽卡片不会自动关 Issue、也不会合并 PR。
创建 Projects 时该选“板”还是“路线图”
选“板”（Kanban-style）适合日常迭代跟踪，比如 PyTorch 模型训练任务拆解：每个实验对应一个 Issue，状态列按 To-Do → In Progress → Review → Done 排布，能直观看出卡点在哪；选“路线图”仅适合版本级规划，比如把 v1.2 Milestone 下所有绑定的 Issue 按截止日期横向铺开——但它不支持手动拖拽调整顺序，也不能关联 PR 状态，纯看时间线用。
容易踩的坑：
- 新建项目时误选“表”视图，后续才发现无法拖拽卡片——“表”只支持排序/筛选，不能做状态流转
- 组织项目默认不继承仓库权限，新成员看不到项目，需单独在
Settings → Access中添加 - 从模板创建时勾选了
Import items from repository，结果把过去两年的旧Issue全塞进来，导致看板杂乱
如何让 Projects 真正联动开发流程
Projects 本身不驱动流程，真正起作用的是你对 Issue 和 Pull Request 的使用方式。例如在 PyTorch 项目中，一个“优化 DataLoader 性能”的任务不该只建一个 Issue，而应拆成：
-
Issue #127：复现瓶颈（附脚本 + GPU 日志） -
Issue #128：对比 pin_memory / num_workers 组合（绑定到同一 Milestone） -
Pull Request #135：提交修改后的data_loader.py，标题带[perf]前缀
然后统一将这三个条目拖进 Projects 的 In Progress 列。这时 Projects 才算开始反映真实进度——否则只是静态看板。
关键细节：
-
Pull Request必须与Issue在同一仓库，跨 repo 的 PR 不会自动出现在 Projects 中 - 如果
Pull Request描述里写了Closes #127，合并后Issue #127会自动关闭，Projects 中对应卡片也会变灰（但列位置不变，需手动拖到Done） - 用 GitHub Actions 自动更新字段更可靠，比如 PR 打开时自动设
Status = In Review，避免人工遗漏
字段（Fields）不是摆设，但别滥用
默认 Projects 只有 Title、Status、Milestone 几个字段，但你可以加自定义字段来补信息差。比如在 IoT 项目中加一个 Hardware Target 单选字段（值为 ESP32 / Raspberry Pi / Custom PCB），再配合筛选器，就能快速找出所有要适配 ESP32 的任务。
但注意：
- 字段类型选错会导致数据混乱：
Number字段输 “v2.1” 会报错，得用Text - 字段名别用空格或特殊符号，否则 GitHub API 调用时容易出问题，推荐用
est_hours而非Estimated Hours - 字段值超过 255 字符会被截断，日志类内容别往
Text字段里硬塞
Projects 最容易被忽略的一点：它不保存历史快照。今天看到的“已完成 12 项”，明天有人删掉两个 Issue，数字就变成 10——没有审计日志，也没有回收站。真要留痕，得靠 Milestone 的关闭动作，或者用 GitHub API 定期导出 ProjectItems 到外部数据库。
