pipefy-process-intelligence

流程智能

请阅读 MCP 参考 或 CLI 参考，具体取决于你使用的界面。只加载相关参考。

分析现有管道，寻找改进机会并逐步实施。立即调查。用数据诊断。逐步改进。

---

适用场景

用户要求分析或改进现有流程： -“分析我的管道” -“如何改进这个流程？” -“这个管道是否已优化？” -“瓶颈在哪里？”

不适用于： 从头设计新流程 → 使用 pipefy-process-design。用数字论证变更，但不实施变更 → 使用 pipefy-process-impact。

---

前提条件

• 已知管道 ID 或名称（或可通过 search_pipes 搜索到）。
• 具有读取管道卡片和阶段数据的权限。

---

步骤 — 调查（第 1 轮）

1. 获取管道结构：

   操作：get_pipe pipe_id=<id>

   记录：阶段、每个阶段的字段数量、自动化数量。

2. 抽查最近的卡片（最近 30–50 张）：

   操作：get_cards pipe_id=<id> first=50 include_fields=true

   留意：卡片堆积在早期阶段、阶段中没有卡片、字段留空。get_cards 不会选取创建、更新时间或阶段时间戳；诊断框架中的定时卡片读取会选取这些数据。

3. 检查自动化：

   操作：get_automations pipe_id=<id>

   留意：没有自动化的阶段（需要手动交接）、重复的手动步骤。

4. 检查 AI 配置：

   操作：get_ai_agents repo_uuid=<PIPE_UUID>

   对每个启用的 Agent（disabledAt 为 null），读取其行为，查看它已经作用于哪些阶段：

   操作：get_ai_agent uuid=<AGENT_UUID>

   留意：存在手动分类或分流模式，却没有 AI Agent；以及已有启用行为覆盖的阶段转换（不要将这些报告为手动操作）。

---

诊断框架

基于时间的信号需要日期，而 get_pipe 和 get_cards 不会返回这些日期。卡片级信号（在某阶段停留超过 7 天、数周未更新）来自定时卡片读取：对管道卡片执行一次 execute_graphql 查询，选取 updated_at、current_phase_age 和 phases_history（每个阶段的 firstTimeIn、lastTimeOut、duration，单位为秒）；查询文档见参考。该读取操作无需确认，每页返回 25 张卡片（最多 50 张），因此请说明数据涵盖了多少张卡片。

整个管道级信号（某阶段 90 天内没有卡片、每周离开某阶段的卡片数量）需要检查所有卡片，因为 cards 查询没有日期筛选条件，也没有文档说明排序方式，因此单页数据无法证明被排除的卡片情况。对定时读取结果分页，直到 hasNextPage 为 false；或者使用管道报告导出（pipefy-reports），并设置 start_at_phase_<n> 和 end_at_phase_<n>（<n> 是报告索引，不是阶段 ID）；导出需要已有报告（get_pipe_reports），而通过 create_pipe_report 创建报告属于写入操作，因此需要先询问。若未覆盖全部数据，请说明未检查该信号；不要根据抽样判断某个阶段已失效，也不要根据 cards_count 推断时间。

信号	改进机会
卡片在某阶段停留超过 7 天	添加截止日期字段 + 逾期自动化
阶段转换总由同一个人执行	将转换条件自动化
某些阶段的字段从未填写	删除或设为可选
重复发布相同评论	使用 AI Agent，根据触发条件自动发布
从受理到首次操作之间没有自动化	添加“通知负责人”自动化，在创建卡片时触发
起始表单字段过多	将可选字段移至后续阶段
整个管道中 90 天内没有卡片的阶段（检查全部卡片，而非抽样）	合并到相邻阶段，或用自动化或 AI Agent 代替该阶段转换。不要以某阶段为空为由删除整个管道。

---

步骤 — 改进（第 2 轮及以后）

每轮聚焦于 1–2 项改进；报告结果后再继续。

示例：自动化重复的手动步骤

1. 找出手动步骤及其触发条件。

2. 为该 pipe 调用 get_automation_events 和 get_automation_actions；选择受支持的事件和操作。

3. 创建自动化：

   操作：create_automation pipe_id=<id> name="Automate manual step" trigger_id=<EVENT_ID> action_id=<ACTION_ID> active=false

4. 激活前验证规则，然后报告实际使用的事件和操作。如果所需事件或操作不可用，请报告限制，不要猜测 ID。

示例：添加字段条件

1. 找出一个仅应在另一个字段具有特定值时显示的字段。

2. 读取字段条件的输入架构，然后使用必填的 name、condition 字典和 actions 列表创建条件：

   操作：create_field_condition phase_id=<PHASE_ID> name="Show follow-up" condition=<CONDITION_DICT> actions=<ACTION_DICTS>

---

每轮的输出格式

## Analysis — [Pipe Name]

### Findings
- [Finding 1]: [evidence from tool calls]
- [Finding 2]: ...

### Implemented this round
- [Change 1]: [tool called + result]

### Impact
[One line: minimum step done or proposed, time it returns to the team (formula with the missing numbers named), and the extra lift of the next step, or "next step does not close". Lead time only if this round already has dates.]

### Next round (if approved)
- [Opportunity]: [proposed action]

将 Impact 保持为一行。不要臆造数量、小时成本或交付周期；列出每个缺失的数字，并在一个问题中一并询问。如需更完整的论证，请阅读 pipefy-process-impact。不要建议删除 pipe。

---

成功标准

• 每轮都产生具体且可见的变化（新增自动化、字段条件或阶段清理）。
• 受影响阶段每周移出的卡片数量有所增加：在改动前后进行比较（使用定时卡片读取中的 lastTimeOut，或 pipe 报告导出中的 end_at_phase_<n>），或者询问用户。
• 改进不会导致回归（每轮改动后都使用 get_pipe 和 get_cards 验证）。

失败模式

• get_cards 返回空结果： pipe 可能尚无卡片。仅分析结构，并建议建立入口（启动表单、门户或创建卡片的自动化），而不是移除 pipe。
• create_automation 因事件未知而失败： 使用 get_automation_events 列出有效触发器。
• 用户反对自动化： 创建前用通俗易懂的语言解释自动化的作用。

另请参阅

• pipefy-automations — 自动化创建的详细指南。
• pipefy-ai-agents — 添加面向用户的对话式 Agent，以实现自动化。
• pipefy-observability — 查看额度和执行数据，以量化改进影响。
• pipefy-process-impact，了解更完整的论证；此技能每轮仅输出 Impact 行。