WorkBuddy 实战：怎样用有限积分跑通一个 MVP？

很多人刚开始用 WorkBuddy，最先关心的是：积分怎么拿？怎么薅羊毛？

但我用了几次以后发现，真正值得研究的不是“怎样攒更多积分”，而是：

怎样把有限的积分，花在真正能推进项目的地方。

对我来说，一套更顺手的 WorkBuddy 工作流是：

积分降低试错成本 → 先把需求想清楚 → 找合适的专家执行 → 直接发布 MVP → 用真实反馈继续迭代

这篇不讲功能大全，只分享三个我觉得最实用的经验：积分、专家和部署。

一、积分不是福利，是你的 AI 项目预算

先说最朴素的一点：我目前在 WorkBuddy 里看到，每日打卡可以领 100 积分，也可以通过完成成长任务领取积分。

这类积分规则和活动可能会调整，大家以自己账户内的实际页面为准。但有一个思路不会变：

把积分当作做 AI 项目的预算，而不只是聊天额度。

很多积分并不是花在“做了一个困难任务”上，而是花在来回修正上。

比如一开始只说：

帮我做一个网站。

AI 不知道你的目标用户是谁、网站要解决什么问题、有哪些页面、要不要登录、需不需要保存数据。它只能边猜边做。你再不断补充“不是这个风格”“这里还要加一个功能”“数据不能这样展示”，一次次返工，积分自然就花掉了。

我现在会把积分主要留给两类任务：

1. 已经有明确目标的执行任务 比如“根据 PRD 完成一个预约页面”“把访谈记录整理成用户需求表”“为这组数据生成可编辑的图表”。
2. 能直接产出可验证结果的任务 比如生成可预览网页、完成代码修改、发布一个能让用户打开的链接。

而不是把大量积分消耗在模糊探索里。

如果你只是刚有一个念头，先和熟悉业务的人聊聊，或用更适合开放讨论的工具把问题想明白；当任务已经清晰，再让 WorkBuddy 开始执行。这样通常更省积分，也更容易拿到可用结果。

一个小提醒：开始做任务前，先去完成成长任务或领取每日积分；创建、对话、调用专家等常见动作，有时本身也可能对应成长任务。先看清任务条件，再操作，避免做完才发现没有计入进度。

每天打卡领积分

做任务也领积分

二、专家不是“全能顾问”，而是专业执行者

我很喜欢 WorkBuddy 的“专家”思路。

它不是让一个通用 AI 什么都做，而是为不同场景准备了有对应方法、工具和工作方式的专家。官方把专家定义为“人设 + 方法论 + 工具链”的角色化执行机制；对于复杂任务，还可以使用多位专家协作的专家团。

但我觉得更关键的不是“专家越多越好”，而是：

专业的事情，交给合适的专家；真正的问题定义，还是要由人来完成。

例如，我要做一个 MVP 网站，通常会把工作拆成两段。

第一段：先梳理问题，不急着开工

这一步要回答的是：

• 谁会用这个产品？
• 他们现在遇到什么问题？
• MVP 最少需要验证什么？
• 哪些功能这次不做？
• 做完以后，怎样判断它有没有用？

这部分特别依赖业务背景、用户访谈和真实判断。AI 可以帮助发散、归纳或挑战假设，但如果连“到底要做什么”都没有想清楚，就急着让开发专家写代码，很可能只是更快地做出一个没人需要的产品。

所以我更愿意在这个阶段找了解业务的人交流，或使用更适合长期对话、理解上下文的 AI 工具，先把需求收敛下来。

第二段：任务明确后，再召唤专家执行

当需求已经比较清楚时，再把资料交给对应的专家。

我会尽量一次性提供这些信息：

• 目标：要解决什么问题；
• 用户：谁会使用；
• 资料：PRD、参考链接、已有文案、数据或设计稿；
• 交付物：网页、功能、表格、报告，具体要产出什么；
• 约束：技术栈、页面风格、不能改动的内容；
• 验收标准：完成后我应该看到什么。

比如，不要只说：

帮我做一个活动报名网站。

可以改成：

请根据附件 PRD 制作一个活动报名网页应用。用户可以查看活动介绍、选择场次、填写姓名和手机号提交报名；管理员需要看到报名列表。第一版重点验证报名流程，不做支付功能。完成后请给出可预览版本，并说明如何发布。

这不是“提示词技巧”本身有多高深，而是把一个模糊愿望变成了能被执行、能被验收的任务。

也因此，我现在会把专家理解成：

一个具备特定专业工作方法的执行者，而不是替我承担所有判断的全能工具。

需要注意的是，专家团并不天然更划算。官方文档提示：专家团涉及多位专家并行和多轮交互，积分消耗通常可能是单专家的 3—5 倍，具体以实际任务为准。

所以我的选择原则很简单：

• 单点、明确的问题：优先找一个对应专家；
• 需要多角色配合、交付物复杂：再考虑专家团；
• 问题都还没定义清楚：先别急着调用专家。

对应搜索我需要的专家，再召唤

三、做 MVP 时，直接发布往往比“代码写完了”更重要

以前我用 Netlify 发布小网站，开发体验没问题；但当我想把链接发到微信里给朋友看时，经常还要考虑打开路径、浏览器跳转等问题。

对我现在做 MVP 的场景来说，WorkBuddy 内的直接发布更顺手：从生成页面到给别人一个能访问的链接，链路更短。

WorkBuddy 目前提供两种很适合 MVP 的发布方式：

1. 轻量发布：适合静态页面、小工具和看板

如果你已经有一个 HTML 页面，或者做的是简单展示页、数据看板、任务台账，可以通过“发布为网站”生成在线链接。

它特别适合：

• 个人作品集；
• 活动页或落地页；
• 用 HTML + CSV 做的小看板；
• 需要快速分享给朋友试用的网页原型。

轻量发布的重点不是搭建一套完整产品，而是快速把“本地文件”变成“别人能打开的网页”。

2. 网页应用：适合需要数据、登录或交互的 MVP

如果你的 MVP 需要用户注册、提交表单、保存数据、上传文件，或者区分管理员和普通用户，就更适合选择网页应用。

WorkBuddy 的网页应用支持按需启用数据库、身份认证和文件存储；应用做好后，可以在预览区点击“分享”，或直接让它“发布 / 上线”，获得独立链接。

这里我想强调一个 MVP 原则：

先让真实用户用上，再决定要不要把它做得更复杂。

第一版不需要把架构做到最完整，也不必一上来就接入所有功能。先让用户完成一个核心动作，拿到真实反馈，再判断下一步要不要投入更多时间和积分。

当然，直接发布不代表可以忽略风险。发布前需要确认：

• 页面里没有敏感信息、测试数据或私密链接；
• 链接适合公开访问；
• 如果是正式长期使用的产品，还要进一步考虑域名、权限、数据安全、稳定性和后续维护。

用自然语言部署MVP产品链接

四、我的 WorkBuddy 使用顺序

最后，把上面三件事串起来，就是我目前更推荐的使用顺序：

1. 先领取可用积分，把它当作试验预算；
2. 先和人或更擅长理解业务上下文的工具一起梳理需求；
3. 用 PRD、资料和清晰指令，把任务交给合适的专家；
4. 不盲目上专家团，先判断任务是否真的需要多角色协作；
5. 生成后尽快发布，让 MVP 进入真实使用场景；
6. 根据反馈再迭代，而不是在第一版无限打磨。

对我来说，WorkBuddy 最有价值的地方不是“替我回答问题”，而是把从想法到可验证结果之间的步骤缩短了。

积分要省，但更重要的是避免浪费在模糊和返工上；专家要用，但前提是你已经知道要让它完成什么；部署要快，但发布以后才是真正开始验证的时刻。

如果你也在用 AI 做个人项目，最想把它做成什么样的 MVP？评论区聊一聊？