传统数据看板开发周期长、响应慢，业务变化永远追不上。本文作者借助飞书AI工具，将540小时工时压缩至120小时，并总结出一套AI驱动数据分析的新范式。文章深入探讨了从PRD到Spec的开发模式转变，以及如何通过结构化、规则化、枚举边界等原则，让AI高效协作，为产品经理提供全新思路。

最近接到一个移动端数据看板的需求，指标多，角色杂，页面深度高。尝试排期后，业务部门对于上线日期及工时不认可，于是尝试使用飞书的AI工具进行相关的开发，效果竟然不错，原有540H的工时，压缩至120H左右，而且开发过程中，业务就参与其中，也大大缩减了验收、迭代的时间。这让我期望深入思考原有数据看板开发方式的不足。

很多团队做数据看板，流程是这样的：

业务方提需求 → 产品写 PRD → 排期开发 → 上线 → 业务方看了两眼 → 没人用了。

本质有以下问题：

1. 指标堆砌：一个页面放几十个指标，用户打开不知道先看哪里
2. 只有结果，没有原因：告诉你派件及时率下降了 5%”，但不知道为什么下降
3. 所有角色看同一套数据：管理层嫌不够聚焦，一线嫌不够可用
4. 发现问题后没有动作：看板提示风险，但没有客户名单、没有责任人、没有任务下发

更要命的是，开发速度永远追不上业务变化的速度。这是当前开发模式的天然局限：每加一个指标、每改一个图表、每加一个下钻维度，都需要前端开发、联调、测试、上线。等我们花了几周把看板做出来，业务场景已经变了。

一、理想的AI驱动数据分析模式

实际上，我在正式开发之前整理了一个AI驱动数据分析的理想范式，虽然最后由于采取了MVP策略，对方法做了一些裁剪：

传统模式：

人 → 打开看板 → 盯着图表看 → 手动找问题 → 手动下钻 → 手动导出 → 手动分配任务

AI 驱动模式：

AI→ 自动取数 → 自动诊断 → 自动生成结论 → 自动推送行动 →GUI只做确认和回溯

这不是说 GUI 不重要了，而是定位变了：GUI 不再是你分析问题的地方，而是你确认结果、跟踪行动、验证效果、异常监控的地方，只在合适的时候主动推送给对应的人。

而在AI驱动的情况下，人的角色也发生了变化，从”全程操作者”变成了”关键节点决策者”——AI 把分析做完了，人只需要在重要的地方拍板、确认、调整。

举几个设想中的例子：

场景一：出港时效预警

• 业务问题：会不会赶不上出港截单时间？
• AI 做什么：实时监控分拣进度 → 基于历史效率预测能否按时完成 → 预计延误就告警 → 自动诊断延误原因（到件晚了？分拣慢了？异常件多了？）→ 给出调度建议
• 输出形式：P0/P1 告警卡片 + 飞书任务

场景二：错分率异常定位

• 业务问题：错分率为什么上升了？
• AI 做什么：发现错分率超标 → 自动按分拣员/设备/时段/目的地/件型多个维度下钻 → 关联分析（是不是新人多了？设备是不是没校准？）→ 输出诊断结论 + 整改建议
• 输出形式：诊断报告 + 整改任务

场景三：经营日报自动生成

• 业务问题：昨天经营情况怎么样？
• AI 做什么：每日定时拉取全量数据 → 计算所有指标 → 识别异常波动 → 深度解读异常原因 → 生成经营日报 + 行动建议
• 输出形式：每日早 8 点推送到管理群的互动卡片

这里面没有看板的设计，全是”AI 要解决什么业务问题、怎么一步步分析、输出什么结果、执行什么改进动作”。

二、实践过程中几个必要的原则

当然上述的模型非常理想，涉及到复杂的规则引擎和大模型的分层协作，复杂的效果评估框架，复杂的人机协作。但是我们可以很快实现的是：

AI→根据规则加工数据→根据规则定时推送给对应人员→根据人员需要做数据解释

而这个过程中，产品经理也不再是写传统的PRD, 而是写SPEC

Spec开发”是 Spec-Driven Development（规格驱动开发，简称 SDD） 的简称。

你可以把它理解为一种 “契约先行” 的软件开发模式。它要求在与AI协作编写任何代码之前，先将需求转化为一份结构清晰、机器可读的“规格说明”。这份规格就像施工蓝图，是后续所有人（包括人类和AI）都必须遵循的“唯一事实来源”

传统模式 (Vibe Coding)：需求 -> 代码，中间缺乏一个确定的、可验证的契约。

Spec开发模式 (SDD)：需求 -> 规范（Spec）-> 代码。Spec成为连接需求与代码的坚实桥梁

1）起草（Draft）：创建一个“变更提案”，其中包含：

-Proposal (proposal.md)：说明为什么要改、改什么。

-Tasks (tasks.md)：列出具体的实施步骤。

-Spec 增量：描述本次变更对现有逻辑的具体影响。

2）实施（Implement）：AI根据审核通过的Proposal和Spec增量来编写代码，并按Tasks清单逐项完成。

3）归档（Archive）：功能上线后，将变更归档。Spec增量会合并到主规范中，更新“真实来源”

上面说的很热闹，其实我在使用飞书妙搭搭建这个系统的时候，最开始只提供了几件东西：

• 指标定义与计算逻辑
• 接口文档与字段解释
• 推送逻辑说明

然后不停的迭代，然后整个项目交付后，我整理了一下SPEC的注意事项：核心原则只有一条：消除一切歧义，让 AI 不需要做任何”猜测”就能正确执行。

原则 1：结构化优先

PRD需要写明白业务背景，而AI 喜欢看有清晰字段的结构化数据。

怎么做：

• 用固定的章节模板，每章有明确的标题和字段
• 多用表格，少用段落——表格是天然的结构化形式
• 关键信息用”字段名: 值”的格式，不要埋在段落里
• 层级用编号（1.1、1.2、2.1），不要用”下面我们来谈谈……”这种过渡语

反例（人读的写法）：

派件及时率是一个非常重要的时效指标，它反映了网点的派送效率。一般来说，我们会把派件及时率的告警阈值设为 90%，低于这个值就需要关注。当然，这个阈值也不是固定的，可以根据实际情况调整。

正例（AI 读的写法）：

原则 2：规则形式化，条件 → 动作

自然语言描述的规则，AI 理解起来容易有偏差。最好的方式是写成”如果……那么……”的形式化规则。

怎么做：

• 每条规则都写成：IF 条件 THEN 动作
• 条件可以组合：IF A AND B THEN C、IF A OR B THEN C
• 优先级要明确：多条规则同时触发时，按什么顺序执行
• 规则 ID 化：每条规则有唯一编号，方便引用和调试

反例：

错分率太高了要告警，大概超过 1% 就算比较严重了，如果连续几天上升也要注意。

正例：

原则 3：枚举边界，不要让 AI 猜

人知道”大概是什么意思”，AI 不知道。任何模糊的描述，AI 都会按自己的理解去执行——而且它”觉得”自己是对的。

怎么做：

• 所有分类都要枚举全部可能值，不要用”等””之类的”
• in-scope 和 out-of-scope 都要明确列出
• 边缘情况要写清楚：空值怎么处理？零怎么处理？异常值怎么处理？
• “其他”类要定义清楚：什么情况下归为”其他”

反例：

支持按人员、网点等维度查询。

正例：

原则 4：示例就是输出格式

给 AI 的示例，不是”参考一下”，而是定义了输出格式。AI 会严格模仿示例的格式、结构、甚至语气。

怎么做：

• 每个输出类型都给完整的示例，不要只给片段
• 示例要覆盖典型场景：正常情况、异常情况、边界情况
• 示例的格式要精确——用什么符号、缩进多少、保留几位小数，AI 都会照着学
• 如果有多种输出格式，每种都给示例

反例：

输出一个告警卡片，包含指标名、当前值和建议。

正例：

原则 5：异常路径和正常路径同等重要

人遇到意外会自己想办法处理，AI 不会——你没写怎么处理，它要么卡住、要么瞎处理。

怎么做：

• 每个操作都要写失败时怎么办：接口调用失败了怎么办？数据校验不通过怎么办？推送失败了怎么办？
• 定义重试策略：重试几次？间隔多久？什么错误重试、什么错误不重试？
• 定义降级策略：核心功能不可用时，用什么降级方案
• 定义错误输出格式：出错了怎么通知、通知给谁、通知内容包含什么

反例：

调用接口获取数据，然后计算指标。

正例：

原则 6：用配置表代替文字描述

AI 读表格比读文字高效得多。表格的每一行就是一条规则，每一列就是一个字段，AI 可以直接逐条执行。

怎么做：

• 所有可配置的规则都做成表格形式
• 表格的列名就是字段名，AI 可以直接映射
• 表格的每一行是一条独立的规则，互不干扰
• 新增/修改规则就是新增/修改表格行，不用改代码

反例：

派件及时率低于 90% 触发 P1 告警，签收率低于 85% 触发 P1 告警，错分率高于 1% 触发 P1 告警……（写了十几段）

正例：

使用飞书表格直接维护相关的规则

结语

目前物流行业面临以下问题都需要依赖数据进行管理

• 派费持续压减，利润空间收窄——每一分效率提升都直接转化为利润
• 时效要求越来越高——”当日达””次日达”成为标配，作业延误直接面临罚款
• 总部考核日益严格——签收率、时效达标率、异常件处理等指标环环相扣
• 人员流动大、管理粗放——依赖经验管理，问题发现滞后，往往等到罚款下来才知道出了问题

做数据看板真的是最痛苦的事情，不在于整理方案困难，而在于做出来没效果。但是现在感觉AI真的能提供一些不同的实现思路。

下面两份文档是AI基于实际项目案例整理而成，并进行了脱敏。

因为是AI帮忙整理的，细节也比较多，没必要放在正文里，放这里给大家参考吧：

https://www.yuque.com/kathic/ec82u9/wdp6yqg7c0eaucxy?singleDoc# 《AI 可读数据开发 Spec 的标准模板》

https://www.yuque.com/kathic/ec82u9/os61culm0n9rns7x?singleDoc# 《网点数据分析技术规格说明书（Spec v1.0）》