用 Python 与 MCP 为编程智能体拆解需求

2026 年，自主软件开发 Agent（Claude Desktop、Cursor、Devin、Roo-Code）已经成为现代工程团队不可或缺的成员。开发者经常让 Agent 编写完整的微服务、重构遗留代码库，以及实现分布式算法。

然而，直接向自主编程 Agent 提供高层次的 prompt，很快就会触发产品工程中的三类根本性问题：

需求模糊陷阱： Agent 收到的指令可能是“让结账流程快速、直观”。没有可衡量的验收标准，Agent 就会凭空做出设计决策、构建不必要的抽象，或者写出无法测试的实现。

依赖死锁与顺序颠倒： 当 Agent 尝试不按依赖顺序实现组件时，例如在底层数据库迁移 schema 或生产者 API 尚未确定之前，就开始构建数据库消费者服务，子进程可能陷入死锁，或者因无法解决的导入错误而失败。

与项目跟踪工具脱节： Agent 在本地终端中默默执行代码，Jira、Linear 或 GitHub Issues 中的 sprint 待办列表却没有同步更新。工程经理和技术负责人只能手动记录 Agent 的进展。

为了解决这些问题，我们开发了 PMFlow：一个用 Python 编写的开放 Model Context Protocol（MCP）server，让 AI Agent 具备首席技术产品经理的严谨工作方式。它可以生成结构化 PRD，将 epic 拆解为可测试的 BDD User Story，使用 Kahn 算法执行 DAG 拓扑调度，通过数学方法计算关键路径（CPM），并将同步 payload 直接导出到 GitHub Issues、Linear 和 Jira。

🏗️ 系统架构

PMFlow 作为一个行为确定的产品管理 sidecar 运行，通过 stdio 使用 JSON-RPC 2.0 通信：

+-------------------------------------------------------------------------+
|                  AI Agent / LLM (Claude, Cursor, Devin)                 |
+-------------------------------------------------------------------------+
                                    |
                           (MCP JSON-RPC Tools)
                                    v
+-------------------------------------------------------------------------+
|                          PMFlow MCP Server                              |
+-------------------------------------------------------------------------+
         |                       |                       |
         v                       v                       v
+-----------------+     +-----------------+     +-----------------+
|  PRD & Story    |     |  Story DAG &    |     | Capacity & PERT |
|  Decomposer     |     |  Critical Path  |     |  Forecaster     |
| (BDD/Gherkin)   |     |  (Kahn / CPM)   |     | (Monte Carlo)   |
+-----------------+     +-----------------+     +-----------------+
         |                       |                       |
         +-----------------------+-----------------------+
                                 |
                                 v
                     +-----------------------+
                     | SQLite WAL Datastore  |
                     | (Zero-loss persistence|
                     +-----------------------+
                                 |
                                 v
        +------------------------------------------------+
        | Issue Tracker Exporters (GitHub, Linear, Jira) |
        +------------------------------------------------+

1. 自动生成 PRD 与验证 BDD 验收标准

当 AI Agent 接到开发某项功能的任务时，第一步是将用户意图转化为结构化的产品需求文档（PRD），其中包含 MoSCoW 优先级划分、架构约束，以及可衡量的成功指标。

此外，人类编写的需求经常包含含糊的词语，例如“快速”“无缝”“简单”“健壮”，这些词会让 AI Agent 偏离预期。PMFlow 的 BDD 验收验证器会按 0–100 分的可测试性量表为验收标准打分，并要求给出具体的量化边界：

import re

VAGUE_TERMS = {
    "fast": "Specify response time in milliseconds (e.g., '< 200ms').",
    "easy": "Specify concrete steps or usability metric (e.g., '< 3 clicks').",
    "intuitive": "Define accessibility guidelines or UX checklist.",
    "robust": "Specify failure recovery, retry policy, or SLA uptime percentage."
}

def validate_scenario(criteria: list[str]) -> dict:
    has_given = any(re.match(r"^given\b", line.lower()) for line in criteria)
    has_when = any(re.match(r"^when\b", line.lower()) for line in criteria)
    has_then = any(re.match(r"^then\b", line.lower()) for line in criteria)

    score = 100
    if not (has_given and has_when and has_then):
        score -= 50

    vague_findings = []
    for line in criteria:
        for term, tip in VAGUE_TERMS.items():
            if re.search(r"\b" + re.escape(term) + r"\b", line.lower()):
                vague_findings.append({"term": term, "recommendation": tip})
                score -= 10

    return {
        "is_valid": has_given and has_when and has_then and score >= 60,
        "testability_score": max(0, score),
        "vague_findings": vague_findings
    }

这样，Agent 拆解功能时，每个 User Story 都必须符合严格的 Given/When/Then 标准：

Given a user with an active session token
When user issues a POST to /api/v1/checkout with valid cart items
Then server responds with HTTP 201 within 250ms and decrements inventory

2. 依赖 DAG 与关键路径引擎（CPM）

在多 Agent 环境中，任务不能随意执行。PMFlow 将待办列表建模为有向无环图（DAG），并持久化到 SQLite WAL 中。

使用 Kahn 算法检测环

在调度工作之前，PMFlow 会验证是否存在循环依赖：

def topological_sort(stories, adjacency, predecessors):
    in_degree = {sid: len(predecessors[sid]) for sid in stories}
    queue = [sid for sid, deg in in_degree.items() if deg == 0]
    sorted_order = []

    while queue:
        node = queue.pop(0)
        sorted_order.append(node)
        for succ in adjacency[node]:
            in_degree[succ] -= 1
            if in_degree[succ] == 0:
                queue.append(succ)

    if len(sorted_order) != len(stories):
        cycle_nodes = [sid for sid, deg in in_degree.items() if deg > 0]
        raise ValueError(f"Cyclic dependency detected: {cycle_nodes}")

    return sorted_order

计算关键路径与浮动时间

PMFlow 通过正向和反向遍历计算：

• 最早开始时间（ES）与最早完成时间（EF）。
• 最晚开始时间（LS）与最晚完成时间（LF）。
• 总浮动时间（Slack）：$Float = LS - ES$。满足 $Float = 0$ 的任务构成关键路径。

      +---------------------+
      |   US-001: Schema    |  (4.0h, Critical)
      +---------------------+
                 |
                 v
      +---------------------+
      |   US-002: Tokenizer |  (8.0h, Critical)
      +---------------------+
        /                 \
       v                   v
+---------------+    +-------------------+
| US-003: UI    |    | US-004: RateLimit | (6.0h, Critical)
| (2.0h, Slack) |    +-------------------+
+---------------+              |
       \                      /
        v                    v
      +------------------------+
      |  US-005: Deploy Swarm  | (2.0h, Critical)
      +------------------------+

项目总工期：20.0 小时。 US-001、US-002、US-004 或 US-005 中任何一个任务延期，都会直接推迟发布日期；US-003 则有浮动时间，可以在后台执行。

3. Monte Carlo 产能预测器

当前待办列表能在这个 sprint 内完成吗？

PMFlow 不依赖单点估算，而是采用三角 PERT 估算（乐观值、最可能值、悲观值），并执行 1,000 次试验的 Monte Carlo 模拟：

import random

def simulate_sprint(stories, num_agents=2, hours_per_agent=40.0, trials=1000):
    available_capacity = num_agents * hours_per_agent  # e.g., 80 hours
    simulated_totals = []

    for _ in range(trials):
        total = 0.0
        for s in stories:
            base = s["estimated_hours"]
            # Triangular distribution: [0.7*base, base, 1.6*base]
            total += random.triangular(0.7 * base, 1.6 * base, base)
        simulated_totals.append(total)

    simulated_totals.sort()
    p50 = simulated_totals[int(0.50 * trials)]
    p80 = simulated_totals[int(0.80 * trials)]
    p95 = simulated_totals[int(0.95 * trials)]

    return {
        "p50_hours": p50,
        "p80_hours": p80,
        "p95_hours": p95,
        "is_within_capacity": p80 <= available_capacity
    }

如果 P80 置信水平下的预测工时超过可用产能，PMFlow 就会标记瓶颈任务，并建议 Agent 集群在编写代码之前缩减范围。

4. 多平台 Issue 跟踪工具同步

PRD 和 User Story 通过验证后，PMFlow 会将经过校验的 payload 直接导出到工程团队选用的跟踪工具：

• GitHub Issues： 将 User Story 格式化为包含 Markdown 验收标准检查清单（- [ ] Given...）、故事点标签和里程碑分配的内容。
• Linear： 生成 GraphQL mutation，包含团队 ID、优先级排序，以及父 Issue 与子 Issue 的关系。
• Jira Cloud： 生成 Atlassian REST API v3 payload，包含 Issue 类型、用于故事点的自定义字段，以及双向阻塞关系链接。

⚡ 与 Claude Desktop 和 Cursor 集成

将 PMFlow 接入本地 Agent 配置：

{
  "mcpServers": {
    "pmflow": {
      "command": "python3",
      "args": ["-m", "pmflow.server"]
    }
  }
}

现在，只需向 Agent 输入以下 prompt：

“为一个幂等的支付 webhook 监听器生成 PRD，将其拆解为可测试的 BDD User Story，计算关键路径，并将 Issue 导出到 GitHub。”

你的 Agent 就会以完整、严谨的产品管理流程开展工作，消除幻觉，并按最优拓扑顺序交付代码。

🚀 开始使用：开源版与企业版

开源的 PMFlow Lite 已在 GitHub 上发布，采用 MIT 许可证：

👉 GitHub 仓库：johannschiffer/pmflow-mcp

如果企业工程团队和 Agent 集群需要持久化的 SQLite WAL DAG 引擎、关键路径计算（CPM）、多 Agent 并行分批调度、Monte Carlo 产能预测，以及 Jira/Linear 导出器：

👉 前往 Gumroad 了解 PMFlow Pro（14.99 美元）

你在与自主 AI Agent 协作时，如何组织需求和任务依赖？欢迎在下方评论区讨论！

如需采取进一步行动，你可以考虑屏蔽此人和／或举报滥用行为。