开能健康 × WorkBuddy

业务背景

开能健康此前的 BI 由业务人员基于传统 BI 平台自行搭建，但真正能独立完成的人很少——每个业务部门往往只能找出一到两位，有些部门甚至一个都没有。传统 BI 平台一旦模板做好就相对固化，指标、风格、展现元素都受平台框架限制，业务想要新指标或换个呈现方式，还要回到 IT 排期。数据分析的门槛，把大多数业务人员挡在了门外。

应用方式

开能健康把数据能力直接下放到业务人员手中：对多数场景，IT 在数据库中建立只读账号交给业务，业务人员用 WorkBuddy 直接连接、自助分析；对数据量大、需要更强受控的场景（如财务），则由 IT 把数据能力封装成 MCP 服务提供调用。业务人员只要能把想要的东西表达清楚、拿到准确的数据源，就能得到结果。

应用价值

• 门槛大幅降低：无需掌握 BI 搭建技能，业务人员用自然语言即可产出看板，能自助做数据分析的业务人员从少数专员扩大到多数业务人员。
• 展现形式不限：同一份指标，觉得风格不合适可随时让 WorkBuddy 调整，动画、上钻下钻等呈现方式更丰富。
• 响应更快：有新指标、新要求随时生成，不再受制于平台框架，也不必回到 IT 排期。

传统 BI 比较固化，做好一个模板就只能是这个模板；用 WorkBuddy 随时有新指标、新要求都能很快生成。以前每个业务部门最多找出一两个人能做 BI，有些部门还找不出来，现在几乎所有人都可以，只要能把想要的东西表达清楚、拿到准确的数据源就行。

业务背景

开能健康各业务部门每月要向管理层做经营汇报。过去汇报依赖固化的 BI 驾驶舱，里面的指标是开发时就定好的，每个月都照着同一套内容讲。但实际上，公司战略关注点、各业务部门的阶段侧重、汇报人的个人偏好每个月都不一样——销售年初关注全年计划与预测、年中复盘达成情况，营运则要在库存偏高的月份重点讲解决方案。固化的看板难以承载这些灵活变化的表达诉求。

典型场景

应用方式

应用价值

• 汇报灵活化：摆脱固化驾驶舱，每月按战略关注点、部门侧重、个人偏好自由组织内容，汇报更有针对性。
• 业务自闭环：汇报材料、分析报告的编写由业务人员自助完成，不必再依赖 IT 或专人代做。
• 内容更丰满：WorkBuddy 不仅整合数据，还能针对经营问题给出建议参考，让汇报从"读数字"升级为"讲思路"。

以前月度汇报是每个部门领导拿着自己的驾驶舱讲，内容是固化的；现在不一样了，每个月汇报的侧重点都不同，让 WorkBuddy 结合当月主题去生成，很灵活、很方便，碰到经营问题它还能给我们一些建议参考。

业务背景

传统模式下，一个系统需求要经历"业务一句话提出 → 需求沟通会 → IT 落成需求文档 → 多轮会议确认"的漫长链条。业务方最初往往只能笼统地讲个大概，需求的细节要靠反复沟通才能对齐，跨团队沟通的摩擦成本和时间成本都很高。

典型场景

应用方式

应用价值

• 提需范式改变：业务方从"提一句模糊的话"变成"交付一版可见、可改的原型"，在搭 Demo 的过程中主动把需求想细、想清楚。
• 沟通成本大降：原来需要一两个月的前期调研与需求确认，现在开发前的这段工作约一个月即可完成，整体交付周期缩短约两个月。
• 对齐更高效：WorkBuddy 会对不合理之处给出反馈，需求内容更丰满，前端设计与蓝图环节的时间大幅压缩。

需求方提需求的范式变了。以前是一句话，然后开会沟通、写需求文档、再确认；现在业务方自己就能搭一个原型，把菜单、字段、跳转都想清楚，我们基于原型现场对齐、不对就改，确认后照着实现——整个前期工作的时间大大缩短，交付周期能减少差不多两个月。

业务背景

开能健康集团于 2022 年完成数字化转型，IT 部的角色也几经演变：转型前以自建开发为主，2022 年起转向采用外部成熟产品搭建信息化体系。但外部产品都有自己的框架，面对企业个性化需求，有些难以实现、有些实现成本很高。随着 AI 能力成熟，公司希望把内部系统逐步转为自建，IT 部又回到了"做开发"的角色，只是这一次借助的是 AI 的能力。

应用方式

IT 团队把 WorkBuddy 作为研发的工作平台与项目管理平台——对接腾讯 TAPD 与 CNB，搭建项目流水线，管理 IT 开发类项目；并持续探索 agent coding / loop engineering 的研发范式，让 AI 参与需求解析与方案设计。与此同时，业务端的一次性、临时性小需求（如员工食堂调研问卷），业务人员也能用 WorkBuddy 自己完成开发、收集数据、生成报告，不必再压到 IT 身上。

应用价值

• 能力边界扩展：借助 AI，软件开发人员的个人能力边界大大增强，同样的团队规模能支撑更多的开发需求。
• 团队不扩编：过去要支撑集团开发需求，团队规模至少要翻一倍；现在用现有人员即可支撑。
• 业务从无到有：非 IT 人员也具备了简单的开发能力，临时性小需求业务端自己就能闭环，不再挤占 IT 资源。

因为有了 AI，软件开发人员的能力边界大大增强了。以前要做这些事，团队规模至少得增加一倍才能支撑集团的开发需求；现在用现在的人就能支撑了。而且很多小需求，业务人员自己就能闭环，不用都压到 IT 身上。

业务背景

水处理板块的业务部门每天围着市场、项目、客户转，脑子里其实装着不少想法：想要一个收集数据的表单、一个活动报名页、一本部门台账、一个自动汇总日报周报的小工具。这些想法单个都不大，但过去要落地就得先"提需求"——讲给别人听、写清楚、排进队列、等实现。业务人员对数字化的理解长期停留在"用系统"而不是"建工具"：系统给了什么就用什么，给不了的就退回表格、群接龙和人工统计凑合。想法在业务脑子里，落地却在别人手上，中间隔着一层说不清、也等不起的距离。

应用方式

现在业务部门换了一种做法：用业务语言把自己的想法讲清楚，由 WorkBuddy 直接生成可用的应用，业务团队自己试用、自己调整、再在部门里推广开来——从"提需求的人"变成"做工具的人"。数据收集、活动报名、部门台账、日报周报工具，业务团队想到就能做、做完就能用、用完还能改。IT 只需要在最后把运行环境与上线保障接住，让业务做出来的东西跑得稳。

应用价值

• 需求响应自己掌握：想到就能做、做完就能用，业务部门的临时性、个性化需求不再受外部排期约束。
• 工具更贴合业务：做工具的人就是提需求的人，不用再跨团队反复对齐，功能天然贴近真实使用场景。
• 数字化意识转变：业务部门从"用系统"走向"建工具"，遇到问题第一反应是自己做个工具解决，而不是等别人来接。
• 能力留在部门：做出来的小工具和建工具的方法沉淀在业务团队内部，可以复用，也可以传帮带给新人。