程序幻境画师如果你印象里的 GitHub Projects 还停留在“把 Issues 拖进三列看板”，那这篇文章可能会让你重新评估它。过去一年，我把一个 3 人内部后台项目和一个 12 人客户交付项目全部迁到 GitHub Projects 上，从只会用 Board 视图拖卡片，到把自定义字段、多视图、自动化工作流、时间线图全部跑起来，最大的感受是：看板只是入口，真正提效的是背后那一套数据结构和规则。
这篇文章不讲基础拖拽操作，就说一件事：怎么把 GitHub Projects 从“便利贴墙”变成“项目底座”。我会拿一个真实场景举例——一个 SaaS 后台管理系统的 1.4 版本迭代，带你把高级能力逐项落地，顺便把那些官方文档里不会写的坑也讲清楚。
1. 看板之外的第一道坎：三列视图为什么越用越累
很多人第一次打开 GitHub Projects，看到的就是三个默认列：Todo、In Progress、Done。用起来也顺，拖一拖卡片，看起来团队在协作。但这种用法本质上只是把一张实体白板电子化了，项目里真正需要关心的信息仍然散落在 Issue 描述、评论、聊天记录和某人的脑子里。
1.1 一张典型的需求卡，在三列看板里丢了什么
以我们当时的登录权限改造为例，卡片看起来是“In Progress”，但实际状态非常复杂：接口文档做完了，前端只写了一半，后端还差环境配置，测试用例还没补。三列看板里只能显示“进行中”，具体卡在哪一步，必须点开卡片看评论才能摸到真相。
更麻烦的是跨部门信息。运营想知道这个需求排在哪个版本，测试想知道预计什么时候提测，前端想看接口联调是否就绪。如果看板里没有这些字段，每一次信息同步都要“点开卡片 → 翻评论 → 找人确认”，一天下来大量时间就耗在这种无意义的信息考古里。
这不是 GitHub Projects 的局限，而是你没有用它真正的数据结构。Projects 的底层不是一块看板，而是一张“具有动态视图的数据库表”。每一个 Item（Issue、PR、草稿卡片）都拥有一组字段值，列只是某个字段在视图里的映射。
1.2 先搭一个项目底座：新项目开启时的四步配置
我在新项目里不会先建看板，而是先搭底座。操作路径是：GitHub 仓库或组织页 → Projects → 新建 Project。
这里有一个关键选择：项目归组织所有还是个人所有。只要涉及多人协作，一律建在 Organization 下，这样项目不会被某位成员的离职带走，权限也能统一管。项目类型选 Table 模式，Board 视图等后面再加，因为 Table 能看到所有字段的值，配置起来最直观。
建完后立刻做四件事：
- 添加数据源：Project 设置里把需要进入项目的仓库全部关联上，后续 Issue 和 PR 会自动涌入，不需要手动贴链接。
- 加字段：删掉默认的 Status 字段，按自己团队的流程重建，后面我会给出一套可复制的字段组合。
- 加视图：先保留一个 All Items 的总表，一个按状态分组的看板，一个按迭代分组的时间线，后面再按角色补充。
- 设权限：管理成员是 Admin，核心研发是 Write，业务方和领导用 Read-only，避免有人顺手改掉结构。
提示：创建完项目后，默认会生成一个链接。把这个链接固定到团队文档的头部，否则三个月后就没人知道入口在哪了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 自定义字段：让每张卡片把背景说清楚
Projects v2 的自定义字段是整个系统的灵魂。很多人做项目管理，喜欢把信息写在 Issue 标题里，比如“【重要】登录页验证码倒计时优化”，等 Issue 一多，搜索、排序、统计全部失效。正确的做法是把流程属性拆成字段，标题只描述“做什么”。
2.1 内置字段与自定义字段，到底怎么选
GitHub Projects 提供的字段类型包括 Single select、Iteration、Number、Date、Text、Milestone、Labels、Revi