Time Gambler

本项目是由 LXDAO 和 ETHPanda 主办的 SPARK AI Hackathon 比赛的团队成果，在 AI Agent 赛道中获得了亚军，已成功部署上线，可点击链接体验 Demo，也可以查看 GitHub 仓库源代码。

一、项目简介 #

Time Gambler 是一个将拆解任务、完成验证与链上质押连接起来的效率型 Web3 产品 Demo。 产品的功能并不复杂，用户在产品中先为预期完成的目标设定期限，然后质押代币上区块链，接入的 AI Agent 再调用工具协助用户将模糊目标拆成行动步骤，并根据后续用户上传的文字、图片或测验判断任务是否完成，最后由智能合约记录结果。如果用户无法按时完成任务，质押的真金白银则会被惩罚没收，反之则返回代币。

输入一个模糊目标任务
  → AI 拆成可执行步骤
  → 用户选择任务期限并提交链上质押
  → 在期限内执行任务
  → 提交文字、图片或测验结果
  → AI 给出结构化判断
  → 合约记录成功、失败或超时
  → 退回质押，或按规则完成结算

我们的团队一共四人，在 2026.01.27 - 2026.02.01 这五天完成了从产品构想、可交互 Demo 到路演交付的流程。我在此次团队合作中扮演的角色是「产品设计」与「路演宣讲人」，主要负责组织讨论、推动产品理念的明确、持续提出 UI 迭代意见、梳理路演叙事与完成现场展示。项目的代码编写部分则几乎由队友「小白」负责完成。

这是一个团队项目，也是我第一次参加黑客松尝试的项目，但正是经由这一次项目，我开始设想自己在一个互联网产品开发中的定位。

这次分工也让我产生了这样的想法，即产品角色的价值不一定体现在提交了多少代码，而在于能否让不同成员围绕同一个用户问题工作，将讨论变成范围、流程、界面、验收标准与可讲清楚的结果。

二、项目缘起 #

项目的 idea 源于重视自律生活的「小白」的设想。虽然市面上充斥着大量学习资料与效率工具，诸如「待办计划」、「番茄钟」等打卡产品，但从自身出发，我们或多或少都使用过这些软件，实际上无法感受到软件带来的**驱动力**。相反，部分软件的设计约束性太低，用户下载软件得到了心理安慰后继续拖延；或者是产品界面太过花哨，容易分散用户注意力；又或者是产品增加了一项又一项功能，最后常常让用户停留在计划、收藏和反复准备中。

适逢本次黑客松比赛归属于 Web3 主题，我们可以结合区块链质押资金的机制调动用户的「焦虑」/「痛点」来作为驱动力——如果无法任务，便会失去真金白银的代币。这也是本项目的核心所在。

在明确「将金钱惩罚作为驱动力」后，我主张尽力对产品「做减法」。一如反对市面上的各种效率管理软件，我们拒绝增加诸如课程、社区、排行榜或复杂的任务管理这些功能，致力于以**极简的 UI 界面设计**为用户带来聚焦注意力的环境。

由于我们选择了 AI Agent 赛道，因而还在产品增加了 Agent 辅助任务拆解与验证功能：

1. 让目标任务变得具体。 AI Agent 可以将诸如「我要学习 Python」这一类宽泛目标拆解为可执行步骤。
2. 让承诺产生后果。 用户主动设定期限与质押代币后，AI Agent 会将任务定义为不再只是一条可以随时划掉的文字。
3. 让结果得到反馈。 AI Agent 会根据用户提交的证据调用工具进行验证，合约再执行确定性的状态变化。

这形成了 Time Gambler 的核心产品理念：用户不一定需要无限增加方法，往往需要的只是一个帮助自己马上停止观望、立刻行动的开关。

三、产品定义 #

1. 目标用户与场景 #

在介绍了产品的核心机制后，我们也随之明确了目标用户群体，同时也顺着这一方向找到了产品的叙事空间，定义了产品名称 Time Gambler（时间赌徒）。

本产品面向的并非所有的效率工具用户，也不是需要医学干预的人群。事实上，我们设想的是会主动选择强约束并愿意接受风险的用户群体，他们往往已经有明确的改变意愿，却容易在启动阶段拖延、在执行中分心，并且愿意主动接受高风险约束的人群。

我们认为，人都有体验特定情感的需求。如同柏拉图在《诗学》中提到的，生活中人们其实离不开对于诸如爱、恨、情、仇等情感的体验，因而古希腊人往往会通过诗歌、戏剧这样的形式来让自己感受不同的情感经验。在此基础上，我假设当代人——特别是 Web3 领域中做投资与量化部分的群体——在工作中会存在一种「挑战自我、超越自我」，乃至可以被称为「极限」的情感表达过程。

那么一场以金钱得失为筹码的时间赌博游戏，或许正是这样一个群体需要的呢？

产品面向的典型场景并不复杂，它可以是一个边界清楚、在短时间内足以验证的任务，例如

我今晚想完成一章课程或一组练习，但过去经常把计划拖到第二天；我愿意将时间设定为在 3 小时内完成，并质押 50 个 USDT。

2. 黑客松 Demo 的范围 #

需要指出的是，我们的产品显然不算严格意义上的「产品」，连 MVP 暂且还算不上。对于一个五天时间要交付成果的黑客松而言，我们定然需要明确成果为一个可以运行、展示的 Demo。对于我们的 Demo 来说，我们期望实现的是「创建承诺—执行—提交证据—获得结果」这样一条链路。

Demo 作为比赛的材料，应当更强调愿景与视觉效果，但 MVP 则涉及以最低的成本验证项目是否可以真正解决问题并且可以持续迭代。

3. 四条 Demo 原则 #

1. **以真实资金的惩罚作为驱动力。**以真金白银的得失作为核心驱动，但质押必须由用户主动选择，强约束不应变成诱导，金额、风险与退出边界需要清楚可见
2. 做减法，而不是再造一个复杂效率平台。 每项功能都必须直接服务「开始—执行—验证」的闭环
3. AI 处理模糊性，合约处理确定性。 AI 可以拆解目标、理解证据，但最终状态与资金规则应由可检查的程序执行。
4. 验证结果必须可解释、可质疑。 「AI 反馈『用户失败了』」不应该成为不可申诉的最终答案

四、核心体验：两个 Agent 任务，一条承诺闭环 #

1. 开始前：把「我想做」转化为「下一步做什么」 #

用户在 Demo 中输入目标后，任务拆解 Agent 会生成若干子任务、预计时间与执行建议。设置这一 Agent 的目的是降低用户开始执行的成本——用户不必先完成一轮复杂规划，便能看到第一步应该做什么。

代码中的拆解结果使用结构化字段返回，前端再把它呈现为行动建议。当模型不可用时，系统会保留基础降级结果，以保证黑客松演示不会完全中断。

2. 创建承诺：把期限与质押写进任务 #

用户确认目标后，可以选择期限与质押金额并创建链上任务。

合约会记录任务所有者、描述、金额、截止时间和状态：

• 验证通过后，任务进入成功状态，用户可以取回质押
• 验证失败或超过期限后，任务进入失败或结算流程
• 当前合约把未退回部分按规则分配到平台金库与奖励池

对链上机制的价值理解不应只是停留在「使用了 Web3」，应该看到它让承诺规则在任务开始后可以不被随意修改——这正是区块链最大的特点。当然，这同时引入了资金风险、交易成本和用户焦虑，因此目前它只能被视为待验证的产品假设，不能因为技术上可实现就默认对用户有益。

3. 结束后：让 AI 判断「证据是否与目标相关」 #

在完成任务后，用户可以提交文字说明、图片证据，或完成 AI 根据任务生成的选择题。

验证 Agent 会结合原任务与提交内容，返回以下结果：

• 是否通过；
• 判断理由；
• 0 — 100 的评分；
• 供后续状态更新使用的结构化结果。

在路演中，我们把这部分概括为 Graph Workflow：不同证明方式经过分析后汇合成可供合约使用的布尔结果。实际仓库当前主要通过 FastAPI 与 Verify Agent 的多个接口实现，再由前端发起链上状态更新。

这种设计让 Demo 能够跑通，不过也暴露了本 Demo 面临的核心难题：**证据相关不等于任务真实完成，模型给出高分也不等于判断客观。**例如，有的线下任务难以通过线上查验准确验证。因此，如果 Demo 需要持续迭代，可能还需要加入固定评测集、规则透明度、人工申诉与异常处理等功能，而非直接将模型输出当作事实。

4. 用状态与陪伴角色补全反馈 #

在 Demo 中，任务看板会展示进行中、已完成和全部任务，创建、等待验证、通过与失败也会有对应反馈。

小白主张在 Demo 界面的右侧下方增加一个 AI 动漫角色，以用更具情绪张力的语言提醒用户下注或提交证明，试图让产品从冷冰冰的合约工具变成一个始终在场的「数字监督者」。不过坦诚说，这与我个人主张的「极简风」有所相悖，我设想的是一个只用在屏幕上显示文字的「隐身」陪伴 AI，而非增加一个可见的卡通角色。但他几乎承担了所有的代码编写部分，从团队合作角度出发，我最终还是选择支持他。

目前，这一角色在黑客松展示中帮助产品建立了记忆点，但它目前主要承担文案与氛围功能，还不是基于长期行为数据工作的个性化 Agent。

五、AI 与链上架构 #

React Native / Expo 前端
├─ 创建目标、期限与质押
├─ 展示 AI 拆解结果
├─ 提交文字、图片或测验
└─ 展示任务与验证状态

FastAPI + SpoonOS
├─ Breakdown Agent：目标 → 子任务与时间建议
├─ Verify Agent：目标 + 证据 → 通过 / 理由 / 评分
└─ Quiz：生成题目并评分

Solidity 合约
├─ 保存任务、期限、质押与状态
├─ 限制验证者权限
└─ 处理退款、失败与超时结算

出于训练架构思维的需要，这里回顾一下 Demo 的架构。我认为这对产品设计而言有助于明确开发和设计的责任边界，一如上述架构中的分工。

• 模型擅长处理非结构化输入。 它可以理解自然语言目标、图片和证明文本。
• 接口负责把不确定输出变成产品可用的格式。 前端需要稳定的字段，而非一段无法执行的自由回答。
• 合约擅长执行确定规则。 智能合约无法判断一张图片意味着什么，因此只用于接收验证结果并改变状态。
• 产品必须处理系统之间的缝隙。 模型超时、解析失败、链上交易失败、前端本地状态与合约状态不一致，都会破坏完整体验。

这里还需要补充一点，即当前的 Demo 实现带有明显的黑客松特征，这意味着 AI 服务会提供演示降级逻辑，链上验证由客户端继续提交，公开页面与本地链环境并非完整的生产部署。这些做法便于在短时间内交付 Demo，但显然无法直接用于真实的场景。

六、测试迭代 #

迭代一：从「功能更多」转向「后果更明确」 #

在我们团队早期的产品理念讨论中，其实也难以避免地滑向一个功能齐全的效率平台：任务、计时、打卡、社区、奖励都可以加入。

但同类产品实在太多，因而我们决定采用「减法」重新判断优先级：任务管理只是载体，真正需要被验证的是，当承诺带有主动选择的后果时，用户是否更愿意开始并完成任务。 这让质押、期限与验证成为优先级。

迭代二：将泛化的「AI 监督」拆解为两个具体的方向 #

「让 AI 监督用户」只是一个抽象的说法，要转化为可以落地的界面，则需要拆解为两个发生在不同时间点的任务：

• 行动前，AI 是规划者，负责把模糊目标变成下一步
• 行动后，AI 是验证者，负责判断提交内容是否与原目标相关

这个拆分同时帮助产品与技术对齐：团队能够为每个 Agent 定义输入、输出和失败状态，路演也能用一条前后呼应的流程说明 AI 为什么存在。

迭代三：从页面拼接转向状态完整 #

黑客松 Demo 不只是需要几张漂亮页面，还需要观众看懂任务怎样从创建变成成功或失败。

因此 UI 迭代逐渐围绕状态展开：空任务、填写目标、AI 分析、确认质押、等待完成、提交证据、验证成功和验证失败。

我在这一阶段频繁提出界面层级、状态反馈和视觉表达上的修改。对我而言，这也是第一次把「这里不好看」逐步转成更具体的问题：

当前页面最重要的信息是什么、用户接下来应该点哪里、状态改变是否能被立即看见。

迭代四：从介绍技术转向讲清人的选择 #

路演最初很容易堆砌 Web3、SpoonOS、ReAct Agent、Graph Agent 与智能合约等概念，但在 4 ~ 5 分钟内的展示里定然解释不清楚这些术语，评委和听众想听的也不是这些复杂的技术栈，而是假设在一个业务场景中，用户为什么愿意使用这样一个 Demo。

我想，换句话说，就是如何讲好一个故事。

最后我采取的方案是解释 Demo 的技术逻辑与背后可能的人文故事。

资源越来越多，但行动仍然困难
  → 普通工具缺少真正的约束
  → 用户存在特定的情感表达诉求，Demo 理念可以满足
  → Time Gambler 让用户为当下主动下注
  → AI 帮助开始，也负责检查结果
  → 合约让承诺产生确定后果
  → Demo 展示完整流程
  → 最后再说明技术结构与未来愿景

这次路演给予我的收获有两点，其一为产品表达并非开发完成后的包装，而是对产品逻辑的再次检验。如果一句话讲不清用户、问题和机制，往往说明产品本身还没有收敛；其二是社会科学、人文知识的融入似乎真的能让展示内容变得更为丰富。有时候并非纯粹的逻辑才能说服人，感情、共鸣也是打动用户的重要利器。

七、测评 #

虽然这一项目还停留在 Demo 阶段而非走向产品，但我还是想尝试对项目进行测评。

在此基础上，如果后续还要推进项目，我想可以邀请 5 — 8 位目标用户完成一次从目标输入到证明提交的任务测试，并记录以下内容：

• 从输入目标到成功创建任务的完成率与放弃点
• AI 拆解建议被直接接受、修改或忽略的比例
• 用户能否理解质押后果，以及金额选择是否产生压力
• 证明提交完成率，以及用户与 AI 对验证结果的分歧
• 在无质押、模拟质押与小额质押条件下，完成率是否真的变化
• 用户对产品的信任、焦虑、后悔与再次使用意愿

以上指标反馈会比项目的奖项更能证明本项目追求的强约束是否有效……

八、我从 Time Gambler 学到什么 #

作为我的第一次黑客松项目尝试，虽然项目并不具备成熟的产品性质，但对我来说还是别具意义，因此还是想在此记录我第一次走进产品设计与团队交付的过程：

• 我第一次推动与组织多人讨论，尝试让不同背景的成员（虽然其实我们四个都不具备专业的开发背景）围绕同一个产品问题进行交流，并且乐于参与其中
• 我第一次把抽象理念拆成目标用户、核心流程、界面状态与四分钟叙事
• 我第一次在没有主导代码的情况下理解自己的责任：推动决策、同步上下文、持续验收，并如实说明贡献边界
• 我第一次在线上面向许多比我更具专业开发背景的听众、评委宣传自己团队的「产品」
• 我也第一次发现，公开表达可以反过来迫使产品变得更清楚

我完全没有想到我们的项目最终会获得亚军，不管它在多大程度上可以证明我们的能力，都给了我们以重要的正向反馈。

特别是在我心中埋下了参与产品开发的种子。