上游 · 理解本功能前需先掌握的（2）：
下游 · 依赖/承接本功能的（0）：
暂无下游（建议学完它再进阶）
前置依赖包含从属概念升级流程承接
边方向 = 学习顺序（A→B 表示先学 A 再学 B）
为什么需要它
心智模型
Issue 是按「待办」排的，但团队关心的是「现在进行到哪一步了」。看板（Kanban）就是把工作项按状态摆成几列——待办、进行中、已完成——像便利贴墙一样一目了然。Projects 看板把 GitHub 的 Issue 和 PR 变成一张可拖拽的协作面板，让整个团队对进度有共同认知。
历史背景 · 它为什么诞生诞生于 2016
诞生团队工作流不只在issue列表，需要可视化看板来规划从想法到发布的进度。2016-09-14 GitHub在Universe推出Projects：从issue/PR/备注创建卡片、自定义列、拖拽调整优先级，让项目管理不离开仓库即完成。
演进2016-10扩展到组织级项目；2017增加自动化看板模板；2021-06全新GitHub Issues重构为"项目表格"（电子表格式过滤/排序/分组+自定义字段+迭代），实现从看板到数据库式规划工具的转型。
历史教训
看板不是终点而是起点：把卡片拖拽的隐喻升级为可过滤排序的表格，说明"可视化"之后下一步通常是"结构化"。功能形态应随用户从轻量追踪到重规划的需求演化。
功能介绍
Projects 看板（Projects）是 GitHub 内置的可适配项目规划工具（Projects 是 GitHub 的项目管理功能，Kanban 指其经典看板布局）。它像一个「数字化便利贴墙」：看板上的每一项（Item）可以是一个问题（Issue）、一个拉取请求（Pull Request），也可以是一张草稿卡片（Draft）。Projects 支持三种核心布局：表格（Table，像电子表格一样排序筛选）、看板（Board，也就是经典的 Kanban 列式面板）、时间线（Timeline / Roadmap，按时间排版本计划）。它的强大之处在于与 Issue 双向同步：你在看板上拖动一张卡片的状态，对应 Issue 的状态会跟着变；反过来在 Issue 里做变更，看板也同步更新。你可以为项目设置多个视图（View），比如「我的任务」「待评审」，同一个看板满足不同人的视角。适合从单仓库到大型多团队项目的规划场景。
核心术语
Projects（项目）看板（Kanban）项（Item）草稿卡片（Draft）视图（View）
适用场景
- 当团队需要看清「哪些在做、哪些在做完、哪些还没开始」时，用看板布局分列。
- 当你想集中规划一批 Issue 和 PR 时，建一个 Projects 并把它们作为项（Item）拖入。
- 当你想按版本排期或给项目设定时间计划时，用时间线（Roadmap）布局。
- 当你想从自己视角查看进度时，为看板创建「我的任务」等自定义视图（View）。
怎么操作（网页 vs 命令行 双轨）
🖱️ 网页操作 (GitHub.com)
- 进入仓库或组织，点击 Projects 标签 → New project，选择表格或看板模板。
- 点击加号把 Issue / PR 添加为看板项，或创建草稿卡片（Draft）占位。
- 设置列（如 To do / In progress / Done）和视图，拖拽卡片切换状态。
- 通过 Projects 设置关联仓库范围，让指定仓库的 Issue 都能被添加进来。
⌨️ 命令行 (进阶)
gh api -X POST /repos/你的账号/仓库名/projects -f name=我的看板gh project list --owner 你的账号gh project view 1 --owner 你的账号
新手建议先从网页操作入手，熟悉概念后再尝试命令行。命令行是真实开发中更常用的方式。
与其他功能的关系
| 关系（前置依赖 / 包含从属 / 概念升级 / 流程承接） | 说明 |
|---|---|
| 包含从属问题（Issue） | issue 作为 items 进入项目看板 |
| 包含从属拉取请求（Pull Request） | PR 也是项目 items 之一 |
官方文档
小结
SUMMARY
Projects 看板是拖拽式的任务面板：表格、看板、时间线三种布局，与 Issue/PR 双向同步。它把「有什么要做」升级为「做到哪一步了」。下一步学 Discussions，把开放式讨论从 Issue 里解放出来。