我用 Python 拆解了 WorkBuddy 工作台共创大赛的 1997 件作品：AI 应用创业的供需断层在哪里

今年参加了 WorkBuddy 的「AI 工作台模板共创大赛」。作为参赛者，我交了两件作品；但作为半个数据分析爱好者，我更想搞清楚一件事：这 1997 件作品背后，到底藏着什么信号？

我关心两个问题：

1. 大家做的工作台，普遍缺什么？
2. 真正的商业需求，到底在哪里？

主办方把作品和投票都摊在一个公开页面上。于是我没忍住，把数据全扒下来做了一遍分析。这篇把过程、代码、结论都记下来——既是一次真实的数据分析实战，也是给所有想做 AI 应用的开发者一份「避坑地图」。

先交代数据底座（全样本，非抽样）：

• 参赛作品 1997 件（已展示 1856、已下架 140、待审 1）
• 投票流水 6034 条，去重投票人 4128
• 创作者 1716 位，其中 94.1% 只交了 1 件

下面所有数字都来自这套全量数据。

一、数据从哪来：抓取一个动态渲染的参赛页

第一个坑就来了：你直接 curl 这个页面，拿到的只有空 HTML 骨架——正文是前端 JS 动态渲染的，正文数据在接口里，普通 HTTP 抓不到。

我探出来的链路是四步：

1. 抓发布页 HTML，里面有一段 window.__PUBLISH_BOOTSTRAP__ 内联 JSON；
2. 从 bootstrap 里拿到 artifact.url（静态资源根目录）；
3. 去拉 index.html，拿到页面正文骨架，再翻出背后的「资料库」databaseId；
4. 用资料库脚本把多维表格读成 CSV。

核心就这么两段：

import re, json

# 第 1 步：从发布页提取内联 bootstrap
html = open("page.html", encoding="utf-8").read()
m = re.search(r"window\.__PUBLISH_BOOTSTRAP__=(\{.*?\});?</script>", html, re.S)
boot = json.loads(m.group(1))

# 第 2 步：拿到静态资源根目录，再去拉 index.html 取正文骨架
static_root = boot["artifact"]["url"]
print("静态资源根:", static_root)

拿到 databaseId 之后，用资料库脚本读取（访问令牌通过 stdin 喂入，避免明文出现在进程参数里）：

# 通过 WorkBuddy 资料库技能获取 open_token（一次性访问令牌）
OPEN_TOKEN="你的资料库 open token"

# 作品表
printf '%s' "$OPEN_TOKEN" | python get_database_content.py \
  --token-stdin \
  --database-id "FOXI83QASXlbMyh8BHeOXd" > works.csv

# 投票流水表
printf '%s' "$OPEN_TOKEN" | python get_database_content.py \
  --token-stdin \
  --database-id "ozXREzG9w5Nd57BL2bRZyG" > votes.csv

拿到两张 CSV，后面就是纯 pandas 活了。

踩坑提示：动态渲染页面的「正文」永远不在 HTML 里，先找 bootstrap / __INITIAL_STATE__ 这类内联对象，再顺藤摸瓜找数据源。直接 requests.get 拿到的字符串基本没用。

二、供给侧诊断：1997 件作品暴露的 8 个共性问题

把数据跑一遍，最扎心的是：绝大多数作品不是「做错了某个功能」，而是「用错了产品范式」。我列八条，每条都有数据。

1. 命名同质化严重

49.9% 的作品名字里带「工作台」三个字，名字平均长度 9 个字。翻投票页时，十几个「XX 工作台」排在一起，用户根本分不清谁是谁。名字是产品的第一屏，这批作品集体放弃了辨识度。

2. 功能高度雷同

对描述文本做关键词统计（按出现率）：

本质是一套「表单 + 看板 + 导出」模板在换皮。真正有差异化的交互（拖拽、甘特、可视化）少得可怜。

3. 把「记录」当成了「处理」——最大的方向性错误

我算了每个功能词的「得票提升比（lift）= 带该词作品的均票 ÷ 全场均票(3.22)」：

• 正相关：拍照 3.03、日报 2.11、分析 1.76、上传 1.68、识别 1.62、图表 1.57
• 负相关：习惯 0.53、日历 0.67、提醒 0.78、待办 0.82、统计 0.88

规律极清晰：凡是「加工信息」的全正，凡是「记录信息」的全负。 用户用脚投票告诉我们——他们要的是「帮我算出来 / 帮我识别出来」，不是「再给我一个本子记下来」。而 1997 件里大量作品在做的是后者。

4. 浅层游戏化是减分项（反直觉，但数据硬）

我本以为加点积分、打卡、成就能提分。结果：

• 「游戏」lift 1.42（因为只有产品本身就是游戏才加分：抽卡盲盒、打怪掉血条这类）
• 「奖励」lift 0.36、「闯关」0.48、「积分」0.50

往一个待办工具上贴「积分贴纸」，确定减分。用户分得清「这东西好玩」和「这东西在哄我玩」。

5. 不会讲故事

高分作品的描述都在写「我现在有多痛、做完后省了多少」；大量低分作品只罗列功能清单。前者让人「秒懂自己要不要」，后者让人「看完不知道解决啥」。

6. 60% 不做任何分发

1119 件作品（约 60%）没填上传平台。而统计显示：做了分发的作品，平均得票是没分发的 3.1 倍。 做完就扔，等于主动放弃被看见。

7. 篇幅踩错区间

描述长度和得票呈「倒 U」关系：300–499 字最佳，太短（<50 字占 14%）说不清，太长又没人看。

8. 94.1% 的作者只做一件

1716 位创作者里，只有不到 6% 交过 2 件以上。全是 Demo，没有一个被当成产品来迭代——没有留存设计、没有用户反馈闭环、没有版本 2。

三、需求侧挖掘：票数比任何调研都真实

投票是「市场用脚投票」最硬的信号。按赛道拆分已展示作品的冷热：

最刺眼的洼地：团队协作

它只占 1.8% 的供给，却拿到全场最高均票、最低零票率。看似黄金赛道——但拆开看，赢的全是行业垂直系统（货代 CRM 108 票、生产计划 12、班组管理 8），输的全是通用工具（团队协作工作台 4 票、项目管理 2 票）。

结论很现实：通用协作没有缝隙（飞书、钉钉、企微都在），真正有价值的是「某个具体行业的协作系统」。

票数和商业价值，是两套指标

这是我整个分析里最重要的一条方法论：

• 「收款台」——真实的多源对账场景，309 家企业、96.1% 匹配率，1 票；
• 「中小企业月度结账 SOP AI 工作台」——25 年财务经验、F01–F05 五步法、描述极扎实，0 票。

大众投票奖励「好玩、易懂、有情绪」；而商业价值藏在「某个具体岗位的重复性苦活」里——投票人里没有会计，所以会计的痛没人投。

从高分作品里挖出的真实需求（精选）

我逐篇精读了票数最高的 100 件作品的描述——这批作者写的是自己真实的活儿，不是编的需求。精选几条有代表性的：

• To B 岗位垂直：货代行业的订舱/报关/清关 CRM；车间班组的点检与产线管理；护理项目的临床路径管理；建工项目的验收材料归档；教师的两类——班主任家校沟通、辅导员的学生台账；电商的进销存与退货；企业行政的公文运转。
• To C 兴趣情绪：收藏图鉴（手办/盲盒/书影音）；「今天吃什么」的三餐决策；减脂的热量与 TDEE 计算；小月龄宝宝的疫苗/辅食跟踪；穿搭衣橱管理；旅行行程与 AA 分账。

共同点：它们都绑定一个具体的人、一个具体的重复动作、一个具体的现有解法缺口。这比任何市场调研问卷都真。

完整 36 条需求清单（21 条 To B + 11 条 To C + 4 条被验证的产品手法）我整理在独立报告里，篇幅所限这里只列代表。

四、投票审计：防刷票，技术上到底防不防得住

分析做到这，我顺手审了一遍投票流水——结果比作品本身还有意思。

审计方法

投票人标识是浏览器 localStorage 生成的匿名串，规则是 "v" + Date.now().toString(36) + 随机6位。关键突破口：标识里编码了生成它的毫秒时间戳。我把它解出来，就能看到每张票的「出生时刻」：

# 页面生成投票人标识的规则： "v" + Date.now().toString(36) + 随机6位
def decode_ts(voter_id: str) -> int:
    return int(voter_id[1:-6], 36)   # 去掉前缀 v 和尾部6位随机，剩下是36进制时间戳

# 对 5888 条有效投票，100% 可解码 —— 拿到每张票的浏览器生成时刻
ts_list = [decode_ts(v) for v in votes]
print("可解码比例:", len(ts_list) / len(votes))   # 1.0

如果有人用脚本批量刷票，标识会成批生成（间隔一两秒）。我按「同一秒内生成的标识」归簇：

from collections import defaultdict

buckets = defaultdict(list)
for vid, ts in zip(voter_ids, ts_list):
    buckets[ts // 1000].append(vid)

print("全场最大标识簇:", max(len(v) for v in buckets.values()))   # = 3

最大簇只有 3，没有批量生成的迹象。 也就是说，没发现规模性机器刷票。

能确证的违规，只有 45 票

逐条按规则查，硬违规只有三类：

• 同作品重复投票 43 张（30 组，最狠的一人对某作品投了 7 次）；
• 单人超 5 票 2 张；
• 指向非已展示作品 146 张（本来就没计入排名）。

合计只减 45 票，占 5888 的 0.8%。前 8 名排名一个没动，我的作品 159→158 票仍是第 4。

但防刷链路，未生效（基于公开页面的可复现观察）

以下结论均来自对大赛公开页面的前端代码与投票流水的技术复现，任何人按相同方法都能验证，不含对内部实现的猜测。

我重新拉了页面 JS，发现防刷逻辑设计得很认真：取真实 UID、自投拦截、UserID 落库，四道防线都在。从公开代码看，逻辑是完整的——

5888 张票，UserID 字段 0 条有值。

原因（基于公开代码推断）：取 UID 的接口 getCurrentUid() 打的是 workbuddy.link（发布域），而登录态在主站 workbuddy.cn，跨域拿不到，于是 .catch(){ return "" } 静默降级为空。接口是活的，但发布域读不到登录态，不报错、照常计票、用户无感。

判据写的是「同 UID 批量投票」，而 UID 从第一天起就全空——规则本身没错，只是发布域这一环没有接通，输入始终为空。

就算 UID 全通了，也防不住

这是给产品同学的提醒：假设登录态打通，能防「换浏览器自投」，但防不住「一个人多个号」「群里发红包求票」「同行互换投票」——后三者都是真实的人、真实的账号、投真实的票，在数据上和「自然传播」一模一样。这是产品机制问题，不是算法问题。

如果以后你做投票/榜单/评分类产品，四条建议：

1. 投票必须强制登录，且登录域要打通；降级就降级到「不计票/进待审」，别静默照常计。
2. 大众投票权重别给太高——这次大众 50% + 评委 50%，大众端最易被冲，评委权重应更高。
3. 用行为数据代替点击计数：留存、使用时长、真实操作路径，比「点一下赞」难刷得多。
4. 异常检测只当兜底——它抓的是「懒得换浏览器的懒人」，抓不了有动机的刷票者。

五、给 AI 应用开发者的方向建议

把以上所有证据收敛成一张「地图」：

值得进的方向

• 某个具体行业的垂直系统（货代、车间、护理、建工、教务、电商进销存），而不是通用协作/通用待办；
• 「帮我把信息加工出来」的工具（识别、分析、图表、对账），而不是「再给我一个本子记」；
• 绑定真实岗位职责里「每月/每周必做、现在靠 Excel 硬扛」的苦活；
• 产品本身就是游戏（抽卡、打怪），而不是往工具上贴积分。

不值得卷的方向

• 通用「工作台 / 待办 / 日历 / 习惯打卡」——供给过剩、均票最低；
• 浅层游戏化包装；
• 只做 Demo 不迭代——94.1% 的人止步于此，这也是你弯道超车的空间。

如果只先做一件事

从你自己的真实岗位痛点出发，做一个「加工信息」而非「记录信息」的垂直小工具，补齐分发（发到能搜到的地方），把描述写到 300–499 字并填上一句话亮点。这一套，是这次 1997 件作品里最稀缺的组合。

写在最后

这场大赛对我而言，价值不在获奖，而在它把「大家都在做什么、用户真正要什么」摊开成了可计算的数据。供需断层是真实存在的：供给侧挤在通用工具里内卷，需求侧渴求垂直行业的苦活解法。

如果你也在做 AI 应用，希望这 1997 件作品踩过的坑，能让你少走几步。也欢迎在评论区聊聊你观察到的情况——尤其是你所在行业的那个「还在用 Excel 硬扛」的痛点，说不定就是下一个值得做的产品。