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

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

📊 Level ⭐⭐ | 21.5KB | entities/ai-native-project-management-git.md

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

Background：本文档来自阿里技术官方公众号，由阿里巴巴工程师周志伟原创撰写，详细介绍了其团队如何用两个 Git 仓库 + AI 编码助手实现"零额外基建投入"的项目管理自动化实践。

核心命题¶

让 AI 做搬运工，人只做输入和决策。 项目管理的本质是信息工程问题而非流程管理问题——一旦接受这个设定，用 Git 管状态、用 AI 做整合、用静态 HTML 做可视化就是顺理成章的选择。

关键设计原则¶

定性 × 定量分离：双仓库架构¶

两个仓库各管一件事，彼此独立：

把定性和定量混在一起，两边都做不好——这是故意分开的。

Git 是唯一的 Source of Truth¶

所有状态都在 Git 仓库里。Markdown 是数据格式，Git 是版本控制，文件系统是数据库。每次变更有 commit 记录可追溯，不依赖任何第三方 SaaS 可用性。

降低输入门槛 > 降低处理成本¶

传统做法：要求人填结构化字段 → 反人性，人不想填 → 数据质量差。

正确做法：让人自由写，AI 来结构化。填写门槛从"打开系统→找表格→按字段填"降低到"写 Markdown 或发 IM 文档链接"。阻力越小，数据质量反而越高。

Skill 即 SOP：把隐性知识编码成可执行代码¶

Skill（SKILL.md）是给 AI 编码助手看的结构化 SOP，定义了工作流的步骤、约束和格式。Skill 文件本身也在 Git 里版本管理——上周整合规则和这周不一样？看 diff 就知道改了什么。

SQL 即度量定义¶

所有效能指标的定义就是 SQL 本身。没有 BI 工具里的拖拉拽"指标配置"，没有只存在于某个人脑子里的"口径说明文档"。SQL 在代码仓库里，可以 review、diff、回测。

三层数据架构（业务跟踪仓库）¶

第一层：原始输入 —— 让人说人话
  updates/<日期>/<场景>.md
  格式随意，想怎么写就怎么写

第二层：AI 语义整合 → merge.sh + AI prompt
  自由文本 → 结构化 Markdown

第三层：Dashboard —— 纯静态 HTML
  模板稳定、数据变化（避免全量重生成）

merge.sh 核心规则¶

三层度量体系（效能度量仓库）¶

杀手级应用：AI 代码质量对比。千行缺陷率分 AI 参与 vs 非 AI 参与两条线——用数据回答"AI 写的代码到底比人写的烂还是好"。

14 个 SQL 并行查询架构¶

汇总查询 9 个 + 人员明细查询 5 个 = 共 14 个 SQL 并行提交
总耗时 ≈ 最慢的那一个查询，而非 14 个串行

问题挖掘 × 依赖协同 Skill¶

Dashboard 回答"各场景走到哪了"，但管理者真正关心：谁卡住了？卡在哪？需要什么帮助？

从结构化场景文档中挖掘问题、识别依赖阻塞、输出协同优先级判断。横切分析能发现"这不是某个团队的问题，而是整个 AI Native 范式的系统性瓶颈"。

没有测试治具的迭代 = 在生产环境上做实验¶

最大的坑：Skill 迭代过程中缺乏验证手段。改了 SQL 过滤条件可能导致某个团队数据消失；调整 Token 消耗的模型归一化逻辑可能让数字跟上周报表对不上。

解法：数据单测 1. 快照基线：存当前版本输出数据 2. 改完后对比：跑同一周数据跟基线做 diff 3. 多周回测：用过去 3-4 周数据跑一遍

每次 Skill 迭代都是一次带验证的变更，不是随手改个参数。

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

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

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

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

五个设计决策¶

1. Git 是唯一的 Source of Truth — 可追溯、可 review、不依赖 SaaS
2. 降低输入门槛 > 降低处理成本 — 让人自由写，AI 结构化
3. 静态 HTML 是最好的 Dashboard — 无需后端/数据库/运维，5 行 YAML 搞定 CI
4. 定性和定量分离 — 两个仓库各管各的
5. SQL 即度量定义 — 可 review/diff/回测，比 BI 平台更透明

成本清单¶

横切分析：AI Native 项目管理的真正杠杆点¶

当所有场景数据都在统一结构的 Markdown 文件里时，AI 可以做横切模式识别： - 基建依赖热力：哪个基础能力被最多团队依赖？直接影响平台投资优先级 - 协同复杂度可视化：9 个圆点表示协同角色数（实心=有，空心=无） - 共性风险识别：多个场景同时报告同一卡点 = 系统性瓶颈而非团队问题 - 阶段分布分析：7 级生命周期的分布——多少已在"业务使用"，多少卡在"评测" - 趋势追踪：某场景连续三周"本周未更新" = 需关注

这才是 AI Native 项目管理的真正价值：用 AI 做人做不了的横向模式识别。

相关实体¶

• Git Repo Based Pm Automation
• Harness Engineering Jk Launcher Baijiajie
• Harness Design Long Running Apps
• Staragent Webterminal Cli Ali Infra Cli As Agent Hands
• Alibaba Agentic Cloud

→ 原文存档

• Impeccable Frontend Design Skill Harness Vibecoder

深度分析¶

信息工程范式的核心突破¶

本文提出的最根本性命题是"项目管理本质上是一个信息工程问题，而不是流程管理问题"。这个断言的深层含义是：传统项目管理之所以低效，不是因为流程设计得不够好，而是因为信息在流动过程中不断损耗、延迟、失真。流程只是表象，信息才是根因。

从信息工程的角度看，本文实际上是在构建一个最小化的信息基础设施：用 Markdown 作为数据结构格式，用 Git 作为版本控制和协作层，用 AI 作为语义处理器，用静态 HTML 作为可视化终端。这四层加起来，恰好覆盖了信息工程中的采集、存储、处理、呈现四个基本环节，而每一层都没有引入任何超出必要范围的复杂性。

这个设计的精妙之处在于它没有试图用技术替代人，而是顺应了工程师已有的工作习惯。Git 是工程师每天都在用的工具，Markdown 是工程师每天都在写的格式，AI 编码助手是工程师已经习惯的助手。当这些熟悉的工具组合起来形成一个新的工作流时，工程师不需要学习任何新的概念或操作方式。

双仓库设计的深层逻辑¶

业务跟踪仓库（定性）和效能度量仓库（定量）的分离，不仅仅是"职责分离"这么表面的设计决策。这个分离背后有更深的信息论基础：不同类型的信息具有不同的生命周期和更新频率，混合管理会导致一方拖累另一方。

业务跟踪的本质是事件驱动的叙事信息——它记录"发生了什么"，需要人主动输入，频率不稳定，可能一周内多次更新，也可能整周没有新进展。这类信息的价值在于它的丰富性和上下文，结构化程度反而是次要的。

效能度量的本质是时间序列的定量数据——它记录"数量是多少"，可以通过自动化采集，频率稳定（通常以周为周期），价值在于纵向可比性和横向汇总能力。这类信息必须高度结构化才能进行计算。

把这两类信息混在同一个仓库里，要么是为了兼容性而牺牲结构的丰富性（业务跟踪被强制结构化），要么是为了灵活性而牺牲汇总的可计算性（效能度量被迫接受非结构化输入）。分离是必然的选择，而不是可选的优化。

Skill 作为知识编码机制的突破性意义¶

把 Skill 定义为"给 AI 编码助手看的结构化 SOP"，这个表述看似简单，实际上触及了 AI Native 工作方式的核心：知识不再需要被人类执行才能发挥作用，而是可以被 AI 执行。

传统的 SOP（标准操作规程）是给人看的文档。人读懂了 SOP，按照步骤执行，SOP 的价值就实现了。但人的时间和注意力是有限的，同一时间只能处理有限数量的 SOP，而且人执行 SOP 的质量会因疲劳、情绪、注意力分散而波动。

Skill 作为给 AI 看的 SOP，突破了这些限制：AI 可以同时处理无限数量的 Skill，AI 不会疲劳，AI 执行的一致性是 100% 的。更重要的是，Skill 本身也可以被版本管理、被 review、被 diff——这意味着项目管理的最佳实践不再只存在于某个资深 PM 的脑子里，而是可以被固化、传递、迭代、继承。

这实际上是实现了管理学上长期以来的一个理想：让最佳实践可执行化。以前说"要把经验沉淀成文档"，但文档终究只是文字，只有被人读到并执行才能产生价值。现在 Skill 是直接可执行的，它的价值实现不再依赖人的主观能动性。

数据单测机制的方法论价值¶

文章提到的"数据单测"机制——快照基线、改完对比、多周回测——看似只是一个技术技巧，但实际上这是 AI Native 工作方式的方法论核心之一。

在传统软件开发中，测试是保证质量的标配手段。单元测试、集成测试、系统测试，每一层都有明确的验证目标和范围。测试驱动开发（TDD）甚至把测试放在了开发之前。

但在 AI Native 的工作流中，长期以来缺乏类似的验证手段。Skill 的迭代——无论是修改 AI prompt、调整 SQL 逻辑、还是改变数据处理规则——都是在"生产环境"上直接做实验。结果要么靠人工抽查，要么靠"到时候看看有没有人投诉"，完全没有系统性的质量保证。

数据单测的本质是把软件工程中成熟的测试理念引入 AI Native 工作流：用历史数据作为测试用例集，用快照对比作为断言机制，用多周回测作为回归验证。这让 Skill 的每次迭代都变成一个有纪律的变更过程，而不是盲目的试错。

这个方法论可以泛化到所有 AI Native 工作流：任何基于 AI 的处理逻辑，都应该有对应的验证手段来保证输出质量的稳定性。没有验证的 AI 工作流，就像没有测试的代码——随着复杂度增加，迟早会出现没人知道原因的回归问题。

AI 参与层级的演化路径¶

文章提出的三个参与层级——格式转换 → 信息整合 → 决策辅助——实际上描述了一个 AI 内化项目管理知识的演进路径。

Level 1 是纯工具层：AI 替代的是重复性机械劳动，把人从"把信息从 A 搬到 B"的工作中解放出来。这个层级最简单，但也最重要——它证明了 AI 可以可靠地替代某些工作，也为后续的复杂应用奠定了基础。

Level 2 是知识层：AI 开始参与信息的整合和模式识别，不仅做格式转换，还做语义的提取和综合。这个层级的关键突破是横切分析能力——AI 可以同时扫描所有场景文档，发现跨文档的共性模式，这是人类很难规模化做到的。

Level 3 是决策层：AI 开始基于历史数据提供预测和建议。这个层级的挑战不是技术，而是信任——管理者是否愿意根据 AI 的建议做决策？AI 的建议是否可以被解释和验证？这需要Level 2积累足够多的高质量数据和足够深的领域理解。

这三个层级不是跳跃式发展的，而是渐进式的：每一层都为下一层提供数据基础和方法论验证。没有 Level 1 的格式转换，就没有结构化的场景文档可供 AI 分析；没有 Level 2 的横切分析，就没有足够的历史数据供 AI 学习模式。

实践启示¶

立即可落地的最小化实践¶

对于任何一个想尝试 AI Native 项目管理的团队，建议从以下最小化配置开始：

工具栈：一个 Git 仓库 + Markdown 文件 + CI/CD（GitHub Actions/GitLab CI）+ AI 编码助手。这四样东西加在一起，已经足够支撑一个基本的信息流转闭环，不需要购买任何额外的 SaaS 工具或搭建任何后端服务。

启动方式：选一个中等规模的项目或团队（5-10 人），让成员每周在 updates/<周次>/ 下按自己习惯的方式写进展。可以是自由文本，可以是对话截图的描述，可以是任意格式。关键是降低输入门槛，而不是规范格式。

第一个 Skill：写一个 merge.sh，调用 AI 编码助手把 updates/ 下的所有文件整合成一个结构化的 project-status.md。AI prompt 的核心指令是：保持原始信息不变，只做格式重组；如果某个信息在多个文件里都出现，合并但不重复；标注"本周未更新"的场景。

第一个 Dashboard：用纯静态 HTML 写一个简单的状态展示页，通过 CI 在每次 project-status.md 更新时自动重新生成。

这个最小化配置的价值在于：它证明了"AI 可以可靠地处理项目信息"，同时不会因为过度设计而造成沉没成本。如果这个配置运行一段时间后被证明有价值，再逐步引入效能度量仓库、SQL 指标定义、横切分析 Skill 等更复杂的组件。

避免常见的启动陷阱¶

陷阱一：过早引入结构化字段。很多团队在启动 AI Native 项目管理时，犯的错误是第一步就要求所有成员填写结构化字段（场景名称、状态、风险等级、责任人等）。这违反了"降低输入门槛"的核心原则，会导致数据质量急剧下降。正确的做法是让成员自由写，AI 来做结构化。等 AI 的结构化能力稳定了，再根据实际需要决定哪些字段值得保留。

陷阱二：试图用一个仓库解决所有问题。有些团队试图在业务跟踪仓库里同时管理进展、效能、风险、资源调度等多维度的信息。这会迅速导致仓库变得臃肿而难以维护。双仓库架构（定性/定量分离）看起来增加了复杂度，但实际上保持了关注点清晰，是长期维护的关键。

陷阱三：跳过数据验证直接上线。在 Skill 迭代过程中，数据单测机制（快照基线、对比验证、多周回测）不是"锦上添花"，而是"必备条件"。没有验证手段的 Skill 迭代是冒险行为，一旦某个 SQL 逻辑错误导致数据偏差，很难定位和回滚。

陷阱四：低估"让人自由写"的心理障碍。很多管理者担心"让人自由写会导致信息过于零散，无法汇总"。这个担心是合理的，但它解决的是 AI 的问题，不是人的问题——AI 的价值恰恰在于处理零散的非结构化信息。管理者需要转变观念：不是"人需要输出结构化信息给 AI"，而是"AI 需要适应人输出信息的方式"。降低门槛、提高数据质量，这条路绕不开。

中期演进路径¶

当最小化配置稳定运行 4-8 周后，可以考虑以下方向的演进：

接入客观数据源：通过 MCP/Slack API 等方式，让 AI 自动从需求管理平台（如 Jira、TAPD）、代码仓库（GitHub/GitLab）、CI 系统等获取客观数据。客观数据的作用是补充而不是替代人的主观判断。哪些信息适合机器采集、哪些必须依赖人输入，这个边界需要通过实践反复验证。

引入效能度量仓库：从业务跟踪仓库中分离出定量数据的管理。新仓库专门负责效能指标的定义、采集、计算和可视化。SQL 是度量定义的载体，每个指标的 SQL 查询都应该被 review 和版本管理。

构建横切分析 Skill：基于结构化的场景文档，写一个 AI Skill 做跨文档的模式识别。典型的横切分析维度包括：基建依赖热力图、协同复杂度排序、共性风险列表、阶段分布统计、趋势异常检测。横切分析的价值是发现单文档分析发现不了的系统性模式。

建立数据单测流程：为每个涉及数据处理的 Skill 建立测试流程：定期快照输出数据、Skill 迭代前对比快照、发现偏差立即告警。这是保证 AI 工作流稳定性的基础设施工具。

长期生态建设的方向¶

AI Native 项目管理的终极目标不是"用 AI 替代人的某些工作"，而是构建一个自我进化的项目管理知识系统。这个系统随着时间积累，能够： - 基于历史交付数据预测新需求的工期 - 识别组织中最频繁出现的瓶颈模式并提前预警 - 自动生成符合不同受众（技术团队、管理层、合作方）关注点的差异化汇报 - 将项目管理的最佳实践编码成可执行的 Skill 并在整个组织内传递

实现这些目标需要：足够长的时间积累数据、足够深的领域理解编码规则、足够广的场景覆盖验证泛化能力。这不是一蹴而就的项目，而是持续迭代的过程。

关键的原则是：保持信息基础设施的简洁和稳定，让上层的 AI 能力逐步增强。Git + Markdown 的基础架构不需要频繁变更，真正需要迭代的是 Skill、SQL 查询和 AI prompt。这些组件的版本管理和测试验证是长期维护的核心工作。