WorkBuddy 粉皮书
WorkBuddy 从 0 到 1
实战与进阶08

三个从 0 到 1 实战项目

高阶120-210 分钟，建议分三次完成第 10 / 12 章

独立完成办公自动化、能力复用和应用开发三个完整项目

学完本章你能做到

  • 独立完成一个办公自动化项目
  • 建立一个可复用的能力工作流
  • 使用 CloudBase 从零开发一个简单的全栈应用
  • 积累从需求到交付的完整项目经验

结课实战

用办公交付、Skill 复用和本地应用三个项目证明成果真实可用

数字正确、第二次可复用、应用真实可打开

跟着做

先建三套独立目录，再开始任何操作

不要把三个项目混在桌面上。先创建 workbuddy-practice 文件夹，再创建 project-a-office、project-b-skill、project-c-app 三个子目录。每个目录里继续分 input、output、evidence 三层：input 只放原始资料，output 只放 WorkBuddy 生成的成果，evidence 用来保存验收记录。 完成后先检查：原始文件有副本；输出目录为空；目录里没有客户数据、密码、Token 或个人隐私。项目 C 只在测试环境操作。

看个例子

项目 A 第 1 步：准备一份可公开的办公任务包

在 project-a-office/input 中放入两份材料：meeting.md（8—15 行会议原始记录）和 sales.csv（至少包含日期、产品、地区、销售额、退款额）。先自己打开 CSV，记录总行数，并用表格软件算出订单数、销售额、退款额、净销售额四个基准值。 你应该看到：两个输入文件可以正常打开；基准值被写进 evidence/baseline.md；output 目录仍为空。做不到这三点，先不要提交任务。
先准备、先备份，再让 AI 写入 output

跟着做

项目 A 第 2 步：先预览计划，再生成四份交付物

打开 project-a-office 作为工作空间，选择计划模式。先让 WorkBuddy 复述输入、计算口径、输出文件名和停止条件；确认无误后再执行。禁止修改 input，所有新文件只能写入 output。
可直接使用的提示词
请读取 input/meeting.md 和 input/sales.csv，先不要写文件。先输出执行计划，并确认：
1. 会议纪要要包含结论、行动项、负责人和截止时间；
2. 销售分析要复算订单数、销售额、退款额和净销售额，并写清口径；
3. 生成 output/会议纪要.md、output/销售分析.md、output/管理层摘要.md、output/验收清单.md；
4. 不修改 input；遇到缺失值不擅自填 0；数字无法对齐时停止写管理建议。
等我回复“确认执行”后再开始。

先停一下

项目 A 第 3 步：人工复算，数字错了就停止

执行完成后，不要只看“任务已完成”。逐个打开四份文件：先把销售分析中的四个指标与 evidence/baseline.md 对照，再检查会议纪要的负责人和截止时间是否来自原文。若任何数字不一致，把错误行、当前值和基准值回传给 WorkBuddy，要求只修正相关文件。 通过标准：四个指标一致；所有文件能打开；管理建议能追溯到数据；input 文件的修改时间没有变化。
关键数字对齐后，管理建议才有意义
让 WorkBuddy 明确输入、指标、交付物、复算、停止条件和证据

看个例子

项目 B 第 1 步：先把一次成功流程写成规格

在 project-b-skill/input 准备 product-a.md，内容包含用户、问题、约束和期望结果。先手工完成一次“需求澄清 → MVP 拆解 → 风险检查”，再把稳定做法拆成四部分：输入变量、固定步骤、安全规则、输出模板。这里的目标不是做一个万能 Skill，而是让同一类需求第二次可以复用。

跟着做

项目 B 第 2 步：创建最小 Skill

进入技能页，选择“创建技能”。只描述一类稳定任务，不要把项目背景硬编码进去。要求它在信息不足时先提问；涉及写文件时只写 output；关键事实没有来源就标记未知。创建后先关闭其他无关技能，避免执行时调用错能力。
可直接使用的提示词
请创建一个“需求澄清与 MVP 拆解”技能。
输入变量：产品背景、目标用户、核心问题、限制条件。
固定步骤：检查输入 → 提出最多 8 个澄清问题 → 汇总已知与未知 → 拆出最小可行版本 → 列风险与验收。
输出：01-澄清问题.md、02-MVP规格.md、03-验收清单.md。
规则：不猜测未知事实；不直接开发；没有确认前不写入原始文件。
Skill 固化的是稳定做法，不是某一次任务的全部背景

先停一下

项目 B 第 3 步：换一个需求做第二次运行

把 product-a.md 换成内容不同的 product-b.md，只替换输入变量，不改技能规则。再次运行后比较两次输出的文件结构、问题顺序和验收格式。 通过标准：第二次无需重写整段提示词；两次输出结构一致；内容随新需求变化；未知信息仍被明确标注。如果第二次仍要重新教它完整流程，就回到上一步缩小 Skill 的职责。
第二次只换变量，才能证明能力真的可复用
从输入变量、安全规则到 A/B 两次运行的完整检查路径

跟着做

项目 C 第 1 步：先写待办应用 MVP，不急着部署

在 project-c-app/evidence/mvp.md 写清最小范围：能新增待办、标记完成、删除待办；页面刷新后数据仍存在；桌面和手机都能使用。明确暂不做登录、多人协作、复杂权限和正式生产数据。先让 WorkBuddy 输出实现计划、文件清单、测试步骤与回滚点，确认后才允许生成代码。
可直接使用的提示词
请为一个待办事项 Web 应用制定实现计划，技术栈使用 React + Vite。首版只做新增、完成、删除和持久化。先输出：页面结构、文件清单、数据结构、本地运行命令、5 条验收用例和回滚办法。不要部署，不要连接生产数据，等我确认计划后再生成代码。

跟着做

项目 C 第 2 步：在本地地址完成四项测试

确认计划后让 WorkBuddy 生成项目，并按它给出的命令安装依赖、启动本地服务。不要把“构建成功”当成完成：复制本地地址到浏览器，依次新增两条待办、完成一条、删除一条、刷新页面。把地址、测试时间和每一步结果写入 evidence/local-test.md。 如果页面打不开，先读终端错误，再确认端口和运行命令；不要连续重启多个服务。
构建通过以后，还要从浏览器入口完成真实操作
MVP、文件结构、本地运行、四项测试、留证和测试部署逐步完成

先停一下

项目 C 第 3 步：可选接入 CloudBase 测试环境

只有本地测试全部通过后才进入云端。先确认 CloudBase 测试环境、账号、区域、权限、可能费用和回滚点；再启用 CloudBase 能力，创建 todos 集合并接入数据读写。部署完成后，用全新浏览器会话打开公开地址，桌面与手机各做一次新增和刷新测试。 控制台显示成功、上传成功或构建成功都不是最终证据；公开地址真实打开且核心动作可用才算通过。
可直接使用的提示词
请先检查当前是否连接的是 CloudBase 测试环境，并列出账号、区域、目标集合、权限、可能费用和回滚步骤。得到我确认后，再创建 todos 集合、接入数据读写并部署到独立测试地址。部署后请返回公开地址和最小验收步骤，不要使用生产数据。
部署状态不是最终结果，公开地址回读才是

先理解

三项目总验收：用证据判定，不凭感觉

最后打开三个 evidence 目录逐项判定。项目 A 要有四个正确指标和四份可打开文件；项目 B 要有两个不同需求的复用记录；项目 C 要有真实可打开的本地地址，若部署则还要有公开地址回读。每项只允许写“通过、失败、未知”，并记录失败原因和回滚方法。任何没有真实验证的结果都保持未知。

三项目学习工作簿

建议分三次完成。每次只做一个项目，并把真实结果写进 evidence 目录

  1. 1建立 project-a-office、project-b-skill、project-c-app 三套目录
  2. 2完成项目 A，并复算四个销售指标
  3. 3完成项目 B，再用第二份需求验证复用
  4. 4完成项目 C 的本地运行与四项浏览器测试
  5. 5如需部署，只使用测试环境并完成公开地址回读
  6. 6为三个项目分别记录失败、停止条件和回滚方法

验收清单

  • 项目 A 四个指标正确，四份交付文件都能打开
  • 项目 B 第二次运行不需要重写全部规则
  • 项目 C 从真实用户入口打开并完成核心操作
  • 三个项目都保留原始输入、验收记录和回滚点
  • 所有未实测项目明确标为未知，没有冒充成功

小贴士不要一口气做完三个项目，建议每天做一个，消化吸收后再继续

小贴士应用开发项目如果遇到困难，可以先从更简单的"零代码本地应用"开始

学完后记得保存进度

完成标记保存在当前浏览器；登录后，会记住上次阅读的章节与位置。