Blotz：为高拖延用户设计一个从「想做」到「真的去做」的 AI 任务系统

核心问题： 当用户知道自己“应该做什么”，却迟迟无法开始时，产品能不能通过任务拆解、软截止时间和执行反馈，降低从“想做”到“行动”的摩擦？

项目概览

Blotz 最初并不是一个经过完整商业验证后启动的产品。当时我们的第一目标很直接：学习并实践前后端开发，而任务管理系统是一个相对适合入门的完整产品形态。

但这个选题也来自真实生活。在墨尔本读书期间，我每天同时需要处理课程与作业、学校讲座和社团活动、校外社群活动，以及买东西、打扫、洗衣等生活杂事。我已经在使用 Google Calendar 和 Apple Notes，但依然经常拖延。固定时间的课程、活动和作业截止时间很容易放进 Calendar；真正容易被推迟的，反而是那些“今天不做也不会立刻出问题”的事情。

和身边朋友交流后，我们发现这种情况并不只发生在我一个人身上。于是，Blotz 从一个普通的待办事项产品，逐渐演变成一个更具体的产品探索：能不能通过 AI 给容易拖延的用户提供更多外部结构，让任务更容易开始，也更容易完成？

01｜我们最初以为用户需要的是一个更好的待办清单

Blotz 的第一版非常基础，核心能力只有传统任务管理产品都会有的创建、编辑、删除、查看和状态管理。从开发学习的角度，这个范围很合理，但从产品角度看，问题很快出现了：市场上已经有大量成熟的任务管理工具。

更重要的是，我们逐渐意识到，不同用户对任务管理产品的需求并不相同。计划习惯非常强的人，往往已经有自己成熟的方法和工具体系，并不需要我们重新教他如何管理任务；而轻度拖延的人，即使偶尔忘记一些事情，也未必愿意为了这个问题长期使用一个独立的任务管理产品。

真正可能持续需要帮助的，是那些拖延已经明显影响学习或生活、面对大任务容易产生启动困难，即使知道事情需要做，也很难建立稳定执行节奏的用户。在进一步查阅拖延和 ADHD 相关论文、网上资料，并结合团队成员自己的体验后，我们发现了一个值得验证的方向：把一个大任务拆成更小、更明确的行动步骤，可能降低用户的启动成本。 这成为后续 AI Task Breakdown（AI 任务拆解）的起点。

02｜真正的问题不是“记不住”，而是“缺少外部结构”

我自己原本的任务管理方式很典型：Google Calendar 用来放上课、活动、讲座和有硬性截止时间的事务；Apple Notes 则用来记买东西、打扫和其他没有明确时间要求的杂事。

问题在于，有明确时间约束的事情很难无限推迟，而没有截止时间的事情可以一直拖。例如，下周一有一份作业要交，在截止时间到来之前，我可能会因为作业本身产生焦虑，并持续拖延；而在拖延作业的同时，我往往连打扫卫生、买生活用品等日常事务也一起推迟。最后的节奏经常变成：一直焦虑地拖延作业，截止时间前集中完成，交完作业后才开始处理之前堆积的生活杂事。

这让我意识到，问题并不只是用户有没有记录任务，而是很多弹性任务缺少一个能够推动行动的时间结构。于是我们形成了一个新的产品假设：如果现实世界没有给一项任务明确的截止时间，产品能不能帮助用户创造一个合理的“软截止时间”？

03｜从待办清单到三层执行机制

Blotz 后续逐渐形成了三个核心产品机制：先帮助用户把任务拆小，再为弹性任务安排一个具体时间，最后通过完成反馈强化进展感。

AI Task Breakdown（AI 任务拆解）

用户可以把一个比较模糊、比较大的任务交给 AI，例如“准备下周的课程展示”，由 AI 拆成更容易开始的子任务。目标并不是让 AI 替用户完成全部规划，而是降低用户面对一个空白大任务时的认知负担，减少“不知道第一步做什么”“觉得任务规模太大”“光是开始规划就产生压力”等启动前的摩擦。

AI 生成的子任务仍然允许用户修改，因为模型可能出现幻觉，也可能生成不现实或不符合个人情况的安排。对我来说，AI 在这里更像是帮助用户启动和提供思路，而不是替用户完全接管决策。

AI Scheduling（AI 排期）

仅仅拆任务还不够。用户即使知道“应该做什么”，仍然可能不断告诉自己“晚一点再做”，因此我们又设计了 AI 排期能力。

用户输入当前所有任务、每个任务的最晚完成期限，以及已有的固定时间安排，AI 再根据这些约束寻找合适的完成时间。这里最重要的不是“AI 会自动排日历”这件事本身，而是它试图解决一个具体行为问题：弹性任务之所以容易被一再推迟，恰恰是因为现实中没有明确的外部截止时间。

例如，作业下周一必须提交，但打扫卫生和采购理论上什么时候都可以做。AI 可以尝试在真实约束中，为这些柔性任务安排一个更明确的执行时间，让“我之后要做”变成“我计划周六下午做”。

成就反馈 / 完成反馈

我们还发现，任务管理产品如果只负责不断提醒用户“还有什么没做”，很容易让产品本身变成另一个压力来源。因此我们希望加入正向反馈机制，完整设想包括积分、周报、完成进度和成就系统。

但在 MVP 阶段，我们选择了更简单的方案：完成任务后给予视觉庆祝反馈，例如撒花动画。它不是最终的完整成就系统，但体现了一个明确方向——用户除了需要一定的执行约束，也需要持续感受到自己的完成进展。后续如果继续迭代，我会更强调“鼓励完成”，而不是让未完成本身变成新的压力。

04｜关键产品决策：不把 Blotz 做成“什么都能做”的 AI 产品

在期末复习期间，我们曾经考虑过一个看起来非常自然的新功能：用户上传考纲和教材，让 AI 自动拆解整个复习计划。这个功能和已有的 AI 任务拆解很像，从表面上看，似乎只是把“完成这个任务”换成“复习这门课”。

但进一步思考后，我认为这会让 Blotz 偏离主线。复习计划拆解涉及不同专业的知识结构、课程内容理解、大量额外上下文、教材和考试范围，以及更高的模型准确性要求。如果为了支持这个功能，我们需要为不同课程、不同用户维护大量专业内容，那么 Blotz 就会从“任务执行工具”逐渐变成“学习内容理解和复习规划工具”，这已经属于另一个产品问题。

因此我更倾向于保持 Blotz 在任务管理与执行上的边界。未来如果有成熟的学习规划服务，更合理的方式可能是通过 API 或导入能力，把已经拆好的学习任务接入 Blotz，而不是自己把整个垂直能力重新开发一遍。

这个取舍让我第一次比较明确地意识到：技术上能实现，并不代表产品上就应该自己做；产品边界本身也是一种决策。

05｜关键产品决策：删除确认弹窗还是 Undo（撤销）

Blotz 的另一个真实问题来自误删，尤其当 AI 把一个大任务拆成一整组子任务后，如果用户误删整个任务组，恢复成本会非常高。

一个常见解决方案是删除前弹出二次确认，但我没有优先选择这个方案。确认弹窗会让每一次正常删除都多一步操作，高频出现时会打断用户，而且用户也可能逐渐形成“无脑点确认”的习惯。相比之下，我们的数据库本来就不是立即物理删除记录，而是通过 isDeleted 这样的状态字段进行软删除，因此 Undo（撤销）与现有数据结构非常适配。

因此我们更倾向于先让正常操作保持顺畅，再给用户提供恢复能力。这个功能对我来说是一个很典型的例子：一个好的产品方案，往往来自用户体验、数据结构和实现成本三者之间的共同约束。

06｜关键产品决策：我们太早决定了“做网页”

Blotz 最大的产品问题，反而来自项目一开始。因为最初目标之一是学习网页全栈开发，我们很早就决定做一个网页产品。当时这在技术学习上是合理的，但用户反馈逐渐暴露出一个根本问题：很难把 Blotz 真正融入日常生活。

我们的目标场景其实包括突然想到一件事时快速记录、在路上查看、收到提醒、做完马上勾选、随时调整日程，以及在生活碎片时间里频繁使用。这些都是非常明显的移动端优先场景，但我们先确定了技术载体，再逐渐理解使用场景。

这也限制了后续的一些产品想法。例如我们曾经考虑过番茄钟和专注能力，但网页端无法真正限制用户切到手机刷其他应用。即使功能本身能做，产品效果也会受到平台限制。后来我们有过迁移到移动端的想法，但考虑到当时项目本身也承担求职和技术学习目标，而澳洲市场的移动开发岗位相对有限，因此最终暂缓。

现在回头看，我认为问题并不是“网页产品一定不适合任务管理”，而是：我们在充分验证使用场景之前，就先做了技术载体选择。 这是这个项目给我最大的产品教训之一。

07｜Calendar View 不是为了“功能更全”，而是给 AI 提供真实约束

后续我们加入了自己的 Calendar View，并支持导入课表。这个功能并不是因为“任务管理产品应该有日历”，而是因为 AI 排期需要更多真实上下文。

如果 AI 不知道用户什么时候上课、哪些时间已经有安排、哪些任务存在明确截止时间，它就很难给出合理的执行时间。因此整个流程逐渐变成：用户提供课表、已有安排、待办任务和最晚期限，AI 在这些约束中安排更合理的任务时间，最后再由 Calendar View 把固定事件和 AI 生成的软截止时间放在同一个时间视图中。

这个过程让我逐渐意识到，AI 产品不是简单把一句提示词发给模型。模型需要产品层主动提供它完成任务所需要的上下文。

08｜一个看似简单的日期问题，让我重新理解 AI 产品

在 AI Scheduling（AI 排期）中，我们曾经遇到一个很基础的问题：用户输入“下周做某件事”，但模型本身并不知道“今天”是哪一天，于是可能生成不合理的截止日期，用户还需要手动修改。

最初这看起来只是一个日期 Bug，但它暴露出的其实是更大的产品问题：模型能力 ≠ 产品能力。 模型本身可能具备推理能力，但如果产品没有把正确的环境信息提供给模型，它仍然无法完成一个可靠的用户任务。

我们后来把当前时间信息传给 AI，也因此开始更认真地考虑时区、本地化设置、用户所在地、日期格式、服务器时间和本地时间等问题。这些并不是纯技术细节，它们会直接影响用户最终看到的结果是否可信。对 AI 产品来说，上下文设计本身就是产品设计的一部分。

09｜真实用户反馈：一个好功能，不一定能形成一个好产品

Blotz 有过真实用户，主要来自团队成员的同学和朋友。我们收到的最重要反馈并不是“某个按钮不好用”，而是一个更根本的问题：很难把这个平台融入已经形成的日常工作流。

尤其是 Google Calendar 已经占据了用户非常稳定的使用习惯。用户并不会因为 Blotz 多了 AI 功能，就自动愿意每天多打开一个新的任务管理平台。后来我们因此增加了 Calendar View、课表导入和更统一的任务展示，但这也暴露出一个更大的产品现实：功能有用，并不等于用户就会真正采用这个产品。

一个产品除了需要解决问题，还必须考虑用户原来的习惯是什么、新产品要替代谁、用户为什么愿意迁移、能不能嵌入已有使用流程，以及打开这个产品的成本是否足够低。对我来说，这是 Blotz 中比任何单一功能都更重要的一次认知变化。

10｜如果现在重新做，我会怎样定义 MVP？

如果今天重新开始 Blotz，我不会先从完整的基础任务增删改查开始，而会把 MVP 收窄到三个能力：AI 任务生成与拆解、AI 日程排列，以及更强的任务提醒。

AI 任务拆解负责降低大任务的启动成本；AI 排期根据真实约束，为弹性任务创建合理执行时间；提醒系统则负责把已经排好的计划真正推进到执行阶段。与此同时，我会优先选择移动端，因为这个产品的使用场景本身高度碎片化、即时化。

相比“功能做得更多”，我现在更想先验证两个问题：第一，用户是否真的愿意让 AI 帮自己决定弹性任务的执行时间；第二，AI 拆解和软截止时间是否真的能提高任务完成率。

11｜如果有 1000 个用户，我会重点看什么？

第一版我会关注四类指标。

激活： 用户首次进入后，有多少人真正创建了任务、使用过 AI 能力，并完成至少一个任务。这个指标可以帮助判断用户是否真正理解并进入了产品的核心流程。

AI 功能使用率： 我会观察任务分别有多少来自手动创建、AI 生成和外部导入，从而判断 AI 是否真的成为核心使用方式，而不只是一个“看起来很 AI”的展示功能。

任务完成提升： 我会重点比较使用 AI 任务拆解或 AI 排期的任务，与普通任务之间的完成率差异。如果没有明显提升，就需要重新判断 AI 功能是否真的解决了问题。

留存： 我尤其会关注用户一周后、四周后是否仍然回来完成计划任务，因为 Blotz 的真实反馈已经说明，最大的风险不是用户第一次觉得功能有趣，而是产品无法进入长期生活习惯。

12｜我会怎么判断 AI Task Breakdown 是否应该继续存在？

AI Task Breakdown（AI 任务拆解）不能因为“看起来很 AI”就一直保留。它存在的理由应该是：用户通过这个功能，更容易真正完成任务。

如果数据最终显示，大量用户尝试过这个功能，但拆解后的任务完成率没有提升，或者用户很快放弃使用，那么我会考虑修改拆解方式、调整目标用户、把它降级为辅助功能，甚至直接删除。

对我来说，这是 Blotz 后期越来越重要的一个认知：AI 功能的成功标准不是“模型成功生成了内容”，而是它是否真正改变了用户的行为结果。

13｜项目反思

Blotz 最初是一个学习如何开发完整前后端系统的项目，但真正让我开始理解产品工作的，反而是那些“功能做出来以后仍然不成立”的部分。

第一，用户缺的未必是功能，而可能是结构。市场已经有大量待办事项产品，Blotz 真正值得探索的并不是“还能不能做一个更好的任务列表”，而是“对于高拖延用户，什么样的外部结构能帮助他们开始行动”。

第二，产品边界需要主动选择。考试复习拆解并不是做不到，但做得到不代表应该做。保持核心问题清晰，有时候比不断增加能力更重要。

第三，AI 的价值不在于生成，而在于改变结果。无论是任务拆解、排期还是截止时间生成，最终都应该回到同一个问题：它有没有提高用户真正完成任务的概率？

第四，应该先理解使用场景，再决定技术载体。Blotz 最大的前期错误之一，是因为学习目标先选择了网页端，再逐渐发现它与核心使用场景存在冲突。如果重新做，我会先回答用户什么时候会用、在哪里用、使用频率有多高、为什么会打开，以及需要怎样的提醒和系统能力，再决定产品应该存在于网页、App、小程序、Calendar 集成，还是其他入口。

最终核心收获

Blotz 让我意识到：一个有用的功能，并不会自动形成一个有竞争力的产品。

任务管理市场并不缺功能，真正困难的是找到足够强的用户问题、进入已经形成的生活习惯、为 AI 提供正确上下文、保持清晰的产品边界，并最终证明功能真的改善了用户行为结果。

如果重新开始，我会更少从“我们能做什么”出发，而更多从一个更基础的问题出发：用户为什么会长期需要它？