---
title: "让项目管理也AI Native —— 两个Git仓库干掉了周报、洞察和效能报表"
source_url: https://mp.weixin.qq.com/s/n4iqEWPfrok91b692nFTJw
author: 周志伟
source: 阿里技术
created: 2026-05-28
updated: 2026-05-28
type: raw
sha256: 80191143d23352365a113b73610b972f1209574a89c9d8ff2290700c6eb53194
tags: [article, project-management, ai-native, git, harness-engineering]
---

# 让项目管理也AI Native —— 两个Git仓库干掉了周报、洞察和效能报表

让项目管理也AI Native —— 两个Git仓库干掉了周报、洞察和效能报表

## 前言

这篇文章讲的事情不复杂：我们用两个 Git 仓库 + AI 编码助手 + 几个 Shell 脚本，替代了传统项目管理中至少 80% 的人肉操作——催周报、搬数据、画图表、对齐进展、写汇报。没有搭平台，没有买 SaaS 工具，就是 Markdown + Shell + Python + AI 的朴素组合。

你有没有想过，为什么你的团队每周都在重复这些事情：
• 催 N 个业务线的同学交周报，催到第三遍还是有人没交
• 把即时通讯文档里的零散信息搬到某个在线表格里，格式不统一，粒度随意
• 手动更新一个看板的进度条，更新完发现另一个团队的数据已经过期了
• 从数据平台上捞一堆 SQL 结果，贴到 PPT 里变成"效能报告"
• 开周会的时候发现大家看的信息版本不一样

说白了，这些事情的本质就是信息搬运。从人脑搬到文档，从文档搬到看板，从数据仓库搬到图表。每次搬运都有信息损耗、都有延迟、都需要有人盯着——而且这个人通常是团队里技术最好、最不应该做这些事情的人。

我们的做法是：让 AI 做搬运工，人只做输入和决策。

## 01 全景：两个仓库解决什么问题

我们做了两个独立的 Git 仓库，各管一件事：

两个仓库彼此独立。一个管"进展"，一个管"数据"。进展跟踪是定性的（做了什么、卡在哪、下一步是什么），效能度量是定量的（交付了几个需求、代码行数、AI 工具用了多少）。分开管是故意的——把定性和定量混在一起，两边都做不好。

## 02 业务跟踪仓库：从自由文本到结构化 Dashboard

跟踪 N 个业务场景的周进展，其实就三步：收原始信息 → 语义整合到结构化文档 → 生成可视化视图。

传统做法是拉个在线表格，每个业务方负责填一列。问题大家都知道：格式不统一、信息粒度随意、历史不可追溯、可视化靠手工。更要命的是——要求人填结构化数据这件事本身就是反人性的。

### 2.1 三层数据架构

第一层：原始输入——让人说人话

团队成员在 updates/<日期>/ 下按场景建 Markdown 文件，想怎么写就怎么写：

# 周进展更新

> 填写人: (花名)
> 日期: 2026-05-16
> 业务场景: 某仓储场景

这周完成了 API 接口全量覆盖，可用率从50%提到65%。
知识库云归档已经跑通。
参数构造不准的问题还在，大概还有40%的case走不通。
下周重点搞 Benchmark V2。

降低填写门槛是第一生产力。你让人填 10 个结构化字段，他就不想填。你让人自由写，他反而能写出有价值的信息。

输入来源不止手写一种。我们通过多种 CLI/MCP 工具来降低信息采集的人工成本：
• 即时通讯文档 MCP：团队成员把进展写在即时通讯文档里，通过 MCP Skill 自动读取文档内容（返回 Markdown）
• 代码仓库 CLI：通过 a1 repo file view/list 直接读取远程仓库的文件内容，不需要本地 clone
• 数据平台 CLI：通过 maxc query 查询大数据平台，获取团队人员信息、协同角色映射等

第二层：AI 语义整合——把自由文本变成结构化文档

AI 整合的过程封装在 merge.sh 里。核心规则：
• 根据文件名/内容匹配对应场景——不靠人工指定映射，AI 语义理解
• 保持文档结构不变——section 标题、表格格式一字不改
• 在"进展历史"追加本周条目——增量追加而非覆盖
• 风险有新的加、解决的移除——保持风险列表鲜活
• 禁止编造原始数据没有的内容——这是底线
• 未更新的场景标注"本周未更新"——诚实比美化更重要

第三层：Dashboard——纯静态 HTML

一个暗色调的单页 HTML。模板稳定、数据变化，避免重新生成导致布局回退。

### 2.2 问题挖掘与依赖协同 Skill

Dashboard 回答的是"各场景走到哪了"，但管理者真正关心的是：谁卡住了？卡在什么地方？需要什么帮助？该投资什么基建？

从结构化场景文档中挖掘问题，识别依赖阻塞，输出协同优先级判断。

举个实际例子。某一周 AI 横切扫描后发现：N 个场景同时报告了"AI 自主测试验证"相关的卡点。如果按传统的"一个团队一个团队汇报"模式，这个信号会淹没在各自的进展列表里。但横切一看，这不是某个团队的问题，而是整个 AI Native 范式的系统性瓶颈。

基于这个判断，Skill 自动把"测试→归因→修复自动联动"标记为 P0 基建优先级，并列出受影响的场景和各自的具体表现。

## 03 效能度量仓库：从数据仓库到交互式报表

第二个仓库做的事情更硬核：从大数据平台拉数据，跑计算，生成效能报表。

整套数据采集依赖两个关键 CLI 工具：maxc（大数据平台命令行）和 a1（代码平台命令行）。前者负责"拿数据"，后者负责"发布结果"。没有写一行后端代码。

### 3.1 三层度量体系

L3 是最终结果：团队产出了什么、快不快。L2 是过程质量：代码质量好不好。L1 是手段投入：AI 工具用了多少、用得深不深。

这个体系的杀手级应用是 AI 代码的质量对比。千行缺陷率分 AI 参与 vs 非 AI 参与两条线，让你一眼看出来"AI 写的代码到底比人写的烂还是好"。

### 3.2 数据源与查询架构

数据从大数据平台的多张表汇聚，覆盖了研发全链路：

汇总查询 9 个 + 人员明细查询 5 个 = 共 14 个 SQL 并行提交

核心架构（伪代码）：
jobs = {}
for name, sql in build_all_queries(dept, week):
    jobs[name] = client.submit(sql)  # 14个SQL同时提交
results = {}
for name, job_id in jobs.items():
    results[name] = client.wait_result(job_id)  # 并行等待
# 总耗时 ≈ 最慢的那一个查询，而非14个串行

### 3.3 最大的坑：没有数据验证就改 Skill，改一次废一次

真正反复折腾我们的，是 Skill 迭代过程中缺乏验证手段。

改之前必须做的三件事：
1. 快照基线：把当前版本的输出数据存一份快照
2. 改完后对比：跑同一周的数据，跟基线快照做 diff
3. 多周回测：用过去 3-4 周的数据跑一遍

说白了，这跟写代码一样——你不会在没有测试的情况下重构核心模块。度量系统的 SQL 和聚合逻辑就是"核心模块"，每次改动都需要验证手段。没有验证手段的优化不叫优化，叫冒险。

### 3.4 多团队配置与门户

每个团队生成独立的 index.html + detail.html。还有一个门户页 public/index.html，卡片式列出所有团队，点击进入各自的报表。

### 3.5 产出：交互式 HTML 仪表盘

主仪表盘用 Chart.js 渲染，支持多视图切换。

## 04 技术架构全景

公共基座：Git + Markdown + 静态HTML + Push-to-Deploy

架构核心：
• 数据输入层：即时通讯文档（Skill）、自由文本 Markdown（Git）
• 处理引擎：AI 编码助手（语义整合）、Python 脚本（并行查询 + 聚合计算 + HTML生成）
• 产出 & 部署：Git Push → CI/CD → Pages

## 05 Skill：把隐性知识变成代码

Skill 的本质是什么？它是一份给 AI 编码助手看的结构化 SOP，定义了工作流的步骤、约束和格式。

这样做的好处是：工作流不绑定到某个人脑子里。你团队里那个"最了解各业务线进展"的 PM，他脑子里的信息组织方式，现在变成了场景文件的 9 个 section。他每周做的信息整合，变成了 merge.sh + AI prompt。

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

## 06 为什么这套方案 Work？—— 五个设计决策

决策 1：Git 是唯一的 Source of Truth
• 每次变更有 commit 记录，可追溯
• 分支/MR 流程天然可用
• 不依赖任何第三方 SaaS 的可用性

决策 2：降低输入门槛 > 降低处理成本
传统工具要求人按模板填写结构化数据。我们反过来——让人自由写，AI 来结构化。填写门槛从"打开某个系统 → 找到对应的表格 → 按字段填写"降低到了"写个 Markdown 文件或发个即时通讯文档链接"。

决策 3：静态 HTML 是最好的 Dashboard
不需要后端，不需要数据库，不需要登录鉴权，不需要运维。五行 YAML 搞定 CI 配置。

决策 4：定性和定量分离
进展跟踪是定性的，效能度量是定量的。两个仓库各管各的。

决策 5：SQL 即度量定义
所有效能指标的定义就是 SQL 本身。SQL 在代码仓库里，可以 review、可以 diff、可以回测。

## 07 从个体实践到横切分析：项目管理的 AI Native 范式

传统项目管理是纵向的——每个团队汇报自己的事情，管理者要自己在脑子里做综合判断。但当所有场景的数据都在统一结构的 Markdown 文件里时，AI 可以帮你做横切：

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

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

## 08 正在进行的实践：对接需求管理和代码仓库

我们正在通过 CLI 工具把需求管理平台和代码仓库的数据接进来，让 AI 拿到更多客观信息后，再结合人的主观输入生成更完整的周进展。

但我们也清楚，当前的数据流还可以更好——客观数据可以更多地叠加进来，减少人工输入的成本。注意，我说的是"叠加"而不是"替代"：项目中遇到什么困难、需要什么帮助、跨团队协同的痛点在哪里——这些信息很难从需求状态变更和代码 Commit 里挖出来，它们本质上是主观判断，必须依赖人的反馈。

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

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

Level 1: AI 做格式转换 + 数据搬运（已完成）
• 自由文本 → 结构化 Markdown
• SQL 结果 → 可视化图表
• 多数据源 → 统一报表

Level 2: AI 做信息整合 + 客观数据采集（优化中）
• 从需求平台/代码仓库采集客观事实
• 叠加人的主观反馈，语义整合到结构化文档
• 横切分析识别共性风险
• 自动生成 Dashboard 和汇报文档

Level 3: AI 做决策辅助（远期）
• 基于历史交付数据做工期预测
• 识别资源瓶颈和关键路径
• 自动生成优先级建议

## 09 写在最后

AI Native 项目管理这个词听起来很唬人。但你把它拆开看，每一步都是开发者已经会的东西：

• 会写 Markdown？你就能定义场景文档的结构
• 会写 Shell 脚本？你就能串起整个数据采集和生成流程
• 会写 SQL？你就能从数据仓库捞出度量指标
• 会用 Git？你就天然有了版本管理、协作和部署

说白了，这套东西没有任何一个技术门槛超过"写一个 CRUD 接口"的难度。没有分布式系统，没有微服务架构，没有任何需要额外学习的框架。

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

之所以 work，不是因为技术多先进，而是因为顺应了工程师的工作习惯，而不是对抗它。

最终成本清单：
• Git 仓库 × 2 —— 免费
• Markdown 文件若干 —— 免费
• Shell 脚本 3 个 —— 几十行代码
• Python 脚本 1 个 —— ~800行
• SKILL.md 2 个 —— 工作流定义
• CI 配置 5 行 YAML —— 免费
• Pages 部署 —— 免费
• AI 编码助手 —— 已有
• 总计：零额外基建投入
• 替代了：项目管理工具 + BI平台 + 效能报表系统