跳转至

Git仓库 + AI 编码助手做项目管理

Ch04.140 Git仓库 + AI 编码助手做项目管理

📊 Level ⭐⭐ | 13.2KB | entities/git-repo-based-pm-automation.md

Git仓库 + AI 编码助手做项目管理

Background：本文档基于微信公众号文章《用两个 Git 仓库 + AI 编码助手做项目管理（2026版）》提取。该文来自匿名团队实践分享，介绍了他们如何用 Git 仓库 + AI 编码助手 + Shell 脚本替代传统项目管理的 80% 人肉操作。

核心范式

AI Native 项目管理 = Git 作为 Source of Truth + AI 作为语义整合引擎 + 静态 HTML 作为可视化载体

三个仓库，各司其职：

仓库 职责 数据性质
业务跟踪仓库 进展跟踪（定性的） 定性：做什么、卡在哪、下一步
效能度量仓库 指标量化（定量的） 定量：交付量、代码行数、AI 占比
SKILL.md 工作流定义（可版本化 SOP） 隐性知识编码

关键设计决策

决策 1：Git 是唯一的 Source of Truth

所有状态在 Git 仓库里。Markdown 是数据格式，Git 是版本控制，文件系统是数据库。每次变更有 commit 记录，分支/MR 流程天然可用，不依赖任何第三方 SaaS。

决策 2：降低输入门槛 > 降低处理成本

让人自由写，AI 来结构化。 填写门槛从"打开系统→按字段填写"降低到"写 Markdown 或发文档链接"。阻力越小，数据质量越高——人在没有格式束缚时写更多信息。

AI 整合封装在 merge.sh 里：收集更新文件 → 拼 prompt → 交给 AI 编码助手执行。核心规则是 AI 语义匹配场景、保持文档结构不变、增量追加历史。

决策 3：静态 HTML 是最好的 Dashboard

不需要后端/数据库/登录鉴权/运维。一个 HTML 文件用 Chart.js 渲染，谁都能打开。部署成本约等于零：push 到 Git，CI 自动分发到 CDN。

决策 4：定性和定量分离

进展跟踪（定性）和效能度量（定量）分开——数据源不同、更新节奏不同、消费者不同。管理者看进展 Dashboard 了解"发生了什么"，看效能仪表盘了解"表现如何"。

决策 5：SQL 即度量定义

所有效能指标的定义就是 SQL 本身。SQL 在代码仓库里，可以 review/diff/回测。比任何 BI 平台的"拖拉拽指标配置"都更透明。

数据单测机制

改度量系统 SQL 之前必须做三件事：

  1. 快照基线：把当前版本的 KPI 数字存一份快照
  2. 改完后对比：跑同一周数据跟基线做 diff，验证变化是否符合预期
  3. 多周回测：用过去 3-4 周数据跑一遍，确保改动普遍正确

"没有验证手段的优化不叫优化，叫冒险。" 这个原则同样适用于 AI 整合 prompt 的迭代——每次 prompt 改了都要用历史数据重新跑一遍对比结果。

Skill 作为隐性知识编码

SKILL.md 是整个项目管理系统的心脏——它是一份给 AI 编码助手看的结构化 SOP，定义了：

  • 仓库结构描述
  • 数据流逻辑（原始输入 → 最终产物）
  • 执行步骤和顺序
  • 约束规则
  • 文件映射表（中文场景名 ↔ 英文文件名）
  • 数据源定义（查什么表、怎么关联）
  • 输出格式

Skill 文件本身也在 Git 里版本管理。看 diff 就知道规则变了什么，commit log 里有记录可追溯。

说白了，Skill 就是把项目管理的隐性知识编码成了可执行的代码。只不过这个"代码"的执行引擎不是 Python 解释器，而是 AI 编码助手。

AI 参与项目管理的三个层次

Level 能力 状态
L1 AI 做格式转换 + 数据搬运（自由文本→结构化，SQL→图表） 已完成
L2 AI 做信息整合 + 客观数据采集（语义整合 + 自动采集需求/代码数据） 优化中
L3 AI 做决策辅助（工期预测、资源瓶颈识别、优先级建议） 远期

横切分析才是真正的杠杆点

当所有场景的数据都在统一结构的 Markdown 文件里时，AI 可以做横切分析：

  • 基建依赖分析：哪些基础设施被最多团队依赖？哪个基建的阻塞影响面最大？
  • 协同复杂度对比：哪个场景涉及的角色最多？
  • 阶段分布：N 个场景在 7 级生命周期上的分布是什么？
  • 共性风险识别：多个场景同时报告同一卡点，说明这是系统性瓶颈，不是个别团队问题
  • 进展趋势：连续三周"本周未更新"的场景需要关注

这才是 AI Native 项目管理真正的价值：不是用 AI 替代人做重复性工作，而是用 AI 做人做不了的横向模式识别。

技术架构

数据输入              处理引擎               产出 & 部署
─────────            ────────              ──────────
┌──────────┐       ┌──────────────┐      ┌────────────┐
│ 即时通讯   │─Skill─→│ AI 编码助手   │────→ │ dashboard │
│ 文档      │       │ (语义整合)    │      │ .html     │
└──────────┘       └──────────────┘      └─────┬────┘
┌──────────┐       ┌──────────────┐            │
│ 自由文本   │─Git──→│              │      ┌─────▼──────┐
│ Markdown  │       │              │      │ index.html │
└──────────┘       └──────────────┘      │ detail     │
┌──────────┐       ┌──────────────┐      └────────────┘
│ 数据仓库   │─SQL──→│ Python 脚本  │────→ Chart.js
│ 9张数据表  │       │ (并行查询     │
│ 2个项目   │       │  聚合计算)    │
└──────────┘       └──────────────┘

客观数据 + 主观反馈的融合模式

核心原则：客观事实让机器采集，主观判断让人精准表达，AI 负责把两者融合成完整进展。

客观数据（自动采集） 主观信息（人补充）
需求状态流转事件 这周遇到的核心困难
代码提交和 MR 合入 需要什么跨团队帮助
排期变更记录 方案变更的原因和背景
效能数据 下周的重点和优先级调整

人的输入从"写一大段周进展"变成"回答三两个关键问题"（卡在哪、需要什么帮助、下周重点是什么）。

成本清单

  • Git 仓库 × 2：免费
  • Markdown 文件若干：免费
  • Shell 脚本 3 个：几十行代码
  • Python 脚本 1 个：~800行
  • SKILL.md 2 个：工作流定义
  • CI 配置 5 行 YAML：免费
  • Pages 部署：免费
  • AI 编码助手：已有

总计：零额外基建投入，替代了项目管理工具 + BI平台 + 效能报表系统。

真正的门槛不在技术，在思路转变——你得相信项目管理本质上是一个信息工程问题，而不是一个流程管理问题。

深度分析

信息工程范式的本质

这套方法论之所以有效，根本原因在于它重新定义了项目管理的本质——信息工程问题，而非流程管理问题。传统项目管理工具（Jira、Asana、Linear）解决的是"流程可见性"，而这套 Git + AI 方案解决的是"信息流动性"。两者看似相似，本质不同：流程管理假设人的行为可以被预定义的有限状态机描述；信息工程承认人的行为是高度非结构化的，但信息本身可以被提取、结构化和分析。

Git 作为 Source of Truth 的选择看似朴素，实则精妙。Git 的内容寻址特性天然解决了版本问题和数据一致性问题——每次 commit 是原子快照，分支是独立的命名空间，MR/PR 是天然的 Review 机制。这些都是项目管理工具需要额外设计的功能，在 Git 里是免费的。

AI 语义整合的边界

当前 LLM 在项目管理中的角色还停留在 L2（信息整合） 阶段，距离 L3（决策辅助） 有本质差距。差距不在于模型能力，而在于数据基础设施。L3 需要足够多的历史交付数据来建立预测模型，但大多数团队的 Git 历史里只有 commit 记录，没有足够丰富的场景级别的进展数据来支撑时序预测。

更值得注意的是，文章提到的"数据单测"机制本质上是在用工程化的思路来处理 AI 输出的不稳定性——对每个 prompt 变更做回测，确保不引入回归。这个思路和传统的 CI/CD 非常像：代码变更要跑测试，prompt 变更也要跑测试。Skill 的迭代变成了一次有验证的变更，而不是随手改参数。

横切分析的价值

"横切分析才是真正的杠杆点"这个观点值得深入思考。传统项目管理是纵向的——每个团队汇报自己的事情，管理者在脑子里做综合判断。这个过程有三个问题：信息衰减（汇报时过滤细节）、信息滞后（周报天然是滞后的）、信息孤岛（团队之间不了解彼此的依赖）。

当所有场景的数据都在统一结构的 Markdown 文件里时，AI 可以做横向模式识别——这不是"用 AI 替代人做重复性工作"，而是"用 AI 做人做不了的事情"。多个场景同时报告同一卡点，说明这是系统性瓶颈；某个场景连续三周未更新，说明这是持续阻塞。这些模式在纵向汇报里很难浮现，在横向数据里可以被自动发现。

实践启示

起步路径

对于想尝试这套方案的团队，建议从最小可行系统开始：

  1. 单仓库、单场景：先用一个 Git 仓库、一个业务场景跑通全流程——原始输入 → AI 整合 → HTML Dashboard
  2. 先跑通 L1：格式转换和数据搬运是最容易验证价值的部分，AI 不会出错的部分
  3. Skill 先行：在跑通流程之前先写好 SKILL.md，把数据流、执行步骤、约束规则定义清楚
  4. 增量扩展：验证后再增加场景数量，不要一开始就设计多团队、多仓库的复杂架构

关键陷阱

  • 过早追求自动化：在数据流还没跑通之前不要急着做自动采集（a1 repo CLI、maxc query），手工流程先跑几周，理解数据特征
  • Skill 不迭代：SKILL.md 不是一次性文档，每次遇到 AI 整合结果不符合预期的问题，都要先改 Skill 再调 prompt
  • 忽视数据单测：prompt 改了不跑回测，等于在生产环境盲改代码
  • 定性定量混在一起：业务跟踪仓库和效能度量仓库的分离是有意为之，不要早期就合并

适用场景判断

这套方案最适合：中小型研发团队（10-50人）、多业务线并行、缺乏统一项目管理工具、工程师主导的团队。最不适用的场景：高度依赖非技术干系人的合规场景、需要审批流转的项目管理、无法接受 Git 工作流的运营/非技术团队。

相关实体

→ 原文存档