最近，我在网上看到一种学习网站：学生可以领养宠物，通过学习积攒能量，让宠物成长。界面很萌，使用理由也很直接——今天学一点，自己的小伙伴就长大一点。
概念插图：学习一点，伙伴成长一点。此图为生成插画，表达体验设想。
我还不了解它的实际留存和学习效果，但这个体验设想让我停下来想了一件事：TeachFlow 是不是做得太重了？
我们希望支持教师和学生，让教学上下文、学习任务和 AI 帮助连接起来。这个方向可以展开很多功能，也很容易让人沿着“完整平台”的思路继续建设。可一个老师第一次接触产品时，需要的是能够马上理解、愿意尝试的理由。
如果他要先理解一套系统、整理数据、改变工作习惯，才能体验核心价值，我们要求他提前支付的成本就很高。
我们还没有算清楚，为什么值得做平台
最初，我把这个问题理解成产品太慢、太重。继续想下去，发现更准确的问题是 ROI，也就是投入与回报。
这里有两笔账。学校要算使用产品是否划算，我们要算建设和经营它是否值得。学校付出的包括采购、接入、学习和日常维护成本；我们付出的包括开发、模型调用、实施支持，以及持续维护多个模块的成本。
一个教学功能有价值，并不能直接证明值得为它建设一个平台。平台需要另外回答：统一建设比几个独立工具多带来了什么？这些收益能否覆盖额外投入？
目前，我们还没有算清这笔账，就已经把平台当作产品要抵达的形态。这是我需要重新审视的地方。
尤其容易漏算的是验证被推迟的成本。多花几个月补全平台，也可能意味着晚几个月才知道：学生到底愿不愿意用，老师到底愿不愿意继续带着班级用。
通用助手改变了收益的比较基准
WorkBuddy 这类通用助手，让这笔账变得更紧迫。按照官方产品介绍，它支持通过自然语言规划和执行任务，处理本地文件，并生成文档、表格和 PPT。这些是官方描述的产品能力，具体教学任务中的可靠性仍需实际检验。WorkBuddy 官方产品介绍
对 TeachFlow 而言，这意味着比较对象需要更新。以前容易比较“老师手工做”和“使用我们的产品”；现在还必须比较“学校现有工具加通用助手”和“使用 TeachFlow”。
用一个假设例子说明：完成同一项工作，手工需要 120 分钟，通用助手加人工检查需要 30 分钟，TeachFlow 需要 20 分钟。在完成质量相当的前提下，我们相对通用助手节省的是 10 分钟。这 10 分钟需要抵消额外的学习、接入和使用成本。
假设示例：条形长度按分钟同比例绘制，不代表产品实测结果。
我因此倾向于判断：主要依赖通用生成能力的平台，预期收益会承受越来越大的压力。功能可能更快被追上，用户也可能在平台回本之前找到更方便的替代方案。
但这不等于所有平台的 ROI 都必然下降。AI 同时可能降低我们的开发和交付成本。真正要看的是，未来一段时间内，新增收益能否覆盖新增成本，以及优势能维持多久。
把功能拆成能独立成立的小产品
我开始考虑另一种推进方式：围绕一个明确的学习结果，先做出可以独立使用的小产品，把它打磨好，再决定下一步。
拆分的单位需要谨慎。“出题”“聊天”“宠物”“学习记录”都是功能，分开建设后，用户可能仍然需要自己把它们拼起来。
一个能够独立成立的承诺可以是：学生每天完成几分钟练习，遇到困难时得到提示，完成后看见宠物成长，愿意明天再来。
这个产品可以包含多个功能，但它的使用理由很集中。我们也能清楚地验证：学生能否完成第一次练习？新鲜感过去之后是否还会回来？老师每周需要花多少时间维护？每服务一个班，我们需要承担多少成本？
宠物成长本身不能证明学习效果。奖励也可能让学生只关注积分。因此，初期需要分别观察参与、认真尝试和学习表现，不能把活跃直接解释成学会了。
“小”意味着更早获得反馈，也意味着能力有限。学校如果明确要求统一身份、权限与记录才能试用，这些条件仍然要满足。轻量产品的范围需要服从真实使用条件。
独到之处，需要在使用中经营
我希望逐渐形成的差异，落在具体体验上：什么样的任务让学生愿意开始？卡住时怎样提示才能帮助他继续？如何让奖励鼓励认真尝试？老师怎样用很少的操作组织活动？
这些问题的答案需要通过持续使用积累。模型升级可以改善生成和理解能力，我们则需要检验它在学习过程中如何发挥作用。
下面是我准备采用的投资判断表，用来明确每一阶段继续投入的条件：
| 投入阶段 | 需要回答的问题 | 支持继续投入的证据 |
|---|---|---|
| 一个独立产品 | 是否有人持续需要它？ | 重复使用、任务完成、老师总投入时间 |
| 第二个相关产品 | 是否解决了已出现的新问题？ | 用户实际需求，以及相对现有工具的收益 |
| 共享能力 | 分开维护是否造成明显负担？ | 重复操作、数据衔接问题、可核算的维护成本 |
| 平台化 | 统一后是否整体更划算？ | 协作收益和成本节省足以覆盖迁移与建设投入 |
关键是先把一个产品做成立，再决定第二个。提前规划十个小产品并逐个开发，同样可能积累大量未经验证的投入。
平台应该在什么条件下出现
如果学生持续需要复习之前没掌握的内容，我们可以考虑有针对性的复习产品。如果老师反复手工分配任务，可以考虑任务分配能力。如果多个产品重复维护账号和学习记录，再判断是否抽取共享服务。
连接会带来收益，也会带来统一规则、迁移和维护的成本。因此，几个产品放在一起，并不自动形成有价值的体系。
我会用三个条件判断平台化时机：多个产品已经有持续使用价值；用户确实需要跨产品协作；统一建设能够降低总成本，或产生明确的新增收益。若这三个条件尚未成立，保持独立形态也可以是合理选择。
决策示意：每一步由需求与收益支撑，平台化并非必经终点。
更长远的生态，还需要教师、内容创作者或其他开发者愿意参与贡献。产品组合成熟之后，才有依据判断是否值得建设这些参与机制。
TeachFlow 仍然可以承载长期方向，但接下来的投入需要更具体：选择一个能独立成立的学习场景，和用户实际可用的替代方案比较，验证它的收益，再决定扩展。
已经投入的工作可以复用，却不能单独成为继续扩大的理由。从今天开始，每一步都应回答：投入什么，帮助谁得到什么，用什么证据决定继续。
平台应当是需求被验证后形成的结果。即使最后没有成为一个大平台，我们也应该已经做出了值得被持续使用的产品。