一位会做表格的兼职者想帮社区运动队整理报名信息。她看见一门课程承诺能用 AI 很快接单，也收到一款自动化工具的试用邀请。她可以用一周验证需求，先用虚构报名记录做演示，再判断课程和工具是否补上实际缺口。最终产物是一页需求记录、一张采购核对表和一份可以复现的试验报告。
先验证谁需要这项服务
把“帮运动队做自动化”缩小成“每周把两个来源的报名名单合成一张可核对的签到表”。约几位负责排班的组织者，问他们上周用了哪些表、哪里需要返工、谁确认最后的名单。把原话里的动作与自己的猜测分开。有人说名单“有点乱”，可以追问上一次重复报名是怎么发现的、有没有人因此漏签。保留具体例子，给未核实的频率或成本标上待确认。
把访谈汇总成四列：角色、发生过的任务、已有解决办法、下一次发生的时间。若其中两人都能用现成模板解决，先确认模板能否复用。若问题集中在两个报名渠道对同一人使用不同编号，就把试做目标定为发现冲突并交给负责人处理。问对方能否提供虚构或脱敏样例、谁会验收结果，以及何时有空看演示。愿意参加演示是一项观察，愿意为具体范围付费是另一项观察，分别记录。
把宣传写成可以核实的主张
将课程或工具页面里的承诺逐条抄进核对表。记录原页面日期、实际交付、运行前提和可核实证据。比如“十分钟生成报名系统”需要拆成搭建表单、导出数据、处理重复项和交接文档。请对方指出样例覆盖哪些步骤，并用同一份虚构报名表复现。若只展示生成页面的录像，保留能看见的结果，再把数据导出与冲突处理记为待测。
遇到收益截图，先查有没有对应的服务范围、交付成本、观察周期和样本口径。即使能确认某笔成交，也无法从单笔记录推算自己的需求或报价。课程费用之外，单独记录运行额度、依赖服务与维护时间。明确你想补的是哪一步，例如导出字段对齐，再看公开文档、样课或现有流程是否能完成。无法核实的承诺保留为未知，不把它计入预计回报。
对工具试用另列权限。报名表测试只需访问测试环境和模拟姓名，写入正式报名系统是独立动作。若试用要求连接真实通讯录或提交客户资料，先向提供方了解为何需要、数据由谁处理，以及如何撤回。用不含真实个人信息的样例验证导出是否可用，确认无法用测试数据复现时，把该候选放回待评估清单。
设计一个有结束条件的小试验
先写假设：负责两条报名渠道的队长，可以用一份核对表在十分钟内找到重复报名，并知道如何处理未匹配的记录。准备八条虚构报名，其中有一组完全重复、一组姓名相同但编号不同，还有一条缺少队别。交付先用表格加一页操作说明，记录准备、核对和返工各用了多久。演示后让队长自己操作一次，把他停下来问的问题记在步骤旁。
若要试用带表单的演示页，可以用关联的 Webapp Testing 执行浏览器验收。给它本地或获准访问的测试地址、虚构数据和每条用例的预期结果。检查缺少队别时表单是否提示补填，检查重复提交是否留下两条测试记录，再确认导出按钮可以拿到样例表。保存失败页面和复现动作。访谈、购买决定和正式报名仍由负责人处理。
在开始前定一个上限，例如两小时做演示、三次试用、只验证一支队伍的周末报名。结束后根据证据选择下一步。有人能独立使用且愿意再拿一批样例，就安排第二轮。若每人都卡在合并规则，就改说明并复跑同一组记录。若多数人实际需要的是代填报名表，就回到访谈确认范围。把下一轮的新增成本与前一轮得到的证据放在同一张表里。
一次验收怎样改变决定
假设工具演示顺利，但导出后把两个同名队员合并成一条。先暂停用这份结果生成签到表，留下两条原始输入、导出文件和合并规则。改成优先按报名编号对齐，缺编号才交给队长确认。复跑同名用例和原本通过的正常记录，核对总行数及未匹配列表。若公开示例已足够让团队修复这个问题，就先用修复后的流程验证第二批报名，再根据剩余问题决定是否需要付费学习。
把报告交给没参与演示的人。请他指出哪些记录已核对、哪些还要人工判断、哪条证据支持试验继续。若报告只有演示链接和一句“功能正常”，补上输入版本、测试时间、预期输出和实际结果。第二周接手的人可以照原样复跑，不必重新解释整套系统。
常见问题
受访者都说想用，是否可以开始收费？
先约定一次范围清楚的试做，把交付内容、所需样例、验收人和时间写出来。记录对方是否同意这些条件，再决定要不要投入更多时间。接受演示的反馈仍能用于改进，但与同意试做的记录分列。
候选的演示无法复现怎么办？
核对演示版本、运行环境、输入格式及是否依赖额外服务。把错误步骤记在核对表，请提供方给一份同版本样例。仍无法复现的功能保持待测，先用已有方法完成能验证的部分。
到了截止时间还有很多想法怎么办？
只保留与当前目标直接相关的证据，把新想法写入候选列表。先交付已核对的表格和未解决的问题。下一轮挑一个有负责人的缺口，约定成本和验收条件后再试。