Muse 虚拟电脑：5 步交出每日数据报告

我已经用 Muse 把 PuckDeals 的第一个海外 Deal 主页做出来了。主页上线以后，接下来要处理的是重复工作：整理数据、看变化、留下记录。

这次收到的教程，想把 Muse 的虚拟电脑变成一个每天处理数据的小助手。这个方向可以试。但先别被“白送一台 VPS”“榨干算力”带跑。

机器报出多少核、多少内存，和它明天能不能准时交一份报告，是两回事。

这篇保留五步操作路径。你不需要先买服务器，也不用先学会 Python。把任务卡逐步交给 Muse，看它实际做出了什么，再往下走。本文是经资料核查后整理的操作教程，不把素材作者的环境记录写成我已完成的部署实测。

Muse 有自己的电脑，但别把它当成买来的 VPS

Meta 的产品设计说明确认：Muse 有文件系统、终端和浏览器，可以写代码、处理文件，并在应用关闭后按计划或相关事件继续工作。

官方安全架构进一步说明，它使用独立的 Linux 虚拟机，网络访问与外部操作受权限系统管理。这不等于你拿到了传统 VPS 的全部管理权限。

素材里的“2 核 8G、100G 磁盘、Python 3.12.3”，只能作为那次环境记录看待。核查到的官方资料没有把这些数字写成每个账号的固定配额，也没有给出 /home/hatch/pdata/ 永久不丢的目录保证。

同样，不能把“所有机器平时休眠”“做穿透一定被封”写成产品铁律。这篇不教绕过限制；遇到权限提示，按产品允许的方式处理。

先让它检查你的实际环境。别替它猜。

这次要它交什么？一份能核对日期的数据报告

先用模拟数据把链路走通：输入记录，处理数据，输出 CSV 和摘要，再交给官方定时任务重复执行。看板可以加，但不必抢在结果前面。

演示使用 AAPL、NVDA、TSLA、MSFT、AMZN 这五个标的名称，只是为了练习分组处理。数据是模拟生成的，不是实时行情，也不用于交易判断。

正常结果应告诉你：本次什么时候运行、处理了多少条、哪些记录格式不对、哪些价格变化或延迟需要看一眼。不能只回一句“已完成”。

第一步：确认环境，找到这次工作的目录

打开你已经能使用的 Muse。下面每块任务卡单独复制，等上一步给出真实结果再继续。I-Lang 是结构化任务写法，不需要你先安装工具。

第一步只检查环境，并建立独立项目目录。不要直接照抄别人机器里的路径。

::ILANG::v5.0
[TYPE:task][PROJECT:muse_daily_report][STEP:1][LANG:zh]
::MODULE{OBJECTIVE}
  [DO] 只读检查当前Muse环境并展示nproc free df python3版本的真实结果 可用命令不同则说明
  [DO] 核对当前工作区路径及文件保存规则 区分当前可写与官方保证持久 不把实测容量当永久配额
  [DO] 优先使用当前产品指定工作区 创建独立muse-daily-report目录及scripts data logs子目录 回报完整路径
  [DO] 后续任务使用这里确认的绝对项目路径 不假设所有账号都有/home/hatch/pdata
::MODULE{LIMITS}
  [MUST] 不触碰现有文件 不修改系统认证 网络或其他任务 不安装公网服务
  [MUST] 官方保存规则不明则标明未知 本次只做可下载的演示结果 不承诺重启或重置后保留
::ILANG::COMPLETE::

拿到结果后，记住它回报的完整项目路径。后面脚本、数据、日志都放在这个项目里。保存规则没有查明，就先把重要结果下载到自己电脑，别把“现在能写文件”理解成永远不会丢。

第二步：让它写脚本，也让它真跑一次

写完代码不算交差。你要拿到第一份 CSV、摘要和本次运行日志，后面的定时任务才有东西可执行。

这里把“数据清洗”和“异动标记”分开：缺少必填字段等格式问题可以隔离；价格突然变化或延迟升高，先保留并标记，别自动删掉。你要看的可能恰好就是那条异常记录。

::ILANG::v5.0
[TYPE:task][PROJECT:muse_daily_report][STEP:2][LANG:zh]
::MODULE{BUILD_AND_RUN}
  [DO] 使用上一步已确认的项目路径 编写Python标准库脚本scripts/pipeline_worker.py 不接真实交易接口
  [DO] 生成1000条固定种子的模拟记录 包含record_id timestamp symbol price latency_ms 五个symbol为AAPL NVDA TSLA MSFT AMZN
  [DO] 保存原始输入 明确标记数据来源为simulation 并生成有已知预期结果的正常与异常独立测试用例
  [DO] 按symbol和timestamp排序计算相邻价格变化百分比 各标的首条变化记null 不伪造前值
  [DO] 演示中绝对价格变化达到15百分比或延迟达到1000毫秒时标记异常 阈值可配置且只属教学示例 不当金融标准
  [DO] 只隔离格式错误记录 保留统计或价格异常原行 行异常数按record_id去重
  [DO] 每次实际运行产生新run_id与开始结束时间 在data的独立run_id目录保存raw.csv report.csv invalid.csv summary.json 在logs保存同run_id日志
  [DO] summary记录来源 run_id generated_at total_rows valid_rows invalid_rows flagged_rows及top5 命令退出码和计数应可核对
  [DO] 写完后真实运行并立即保存退出码 执行正反测试 使用CSV解析器检查total_rows等于valid_rows加invalid_rows及report记录数等于valid_rows
  [DO] 展示本次摘要 文件路径 时间 run_id 真实退出码与测试结果 给我可下载CSV及JSON
::MODULE{LIMITS}
  [MUST] 正常数据允许零异常 固定种子模拟数据不是实时行情 不自动删除真实异常 不作投资操作
  [MUST] 任一步失败报FAIL与原始错误 不无条件打印成功 不用上次文件冒充本次结果
::ILANG::COMPLETE::

任务卡里的 15% 和 1000 毫秒只是演示条件，方便检查它有没有按要求计算，不是投资信号或通用风控标准。接真实数据以后，得根据自己的业务重新定。

如果你想继续用原稿的 Z-Score，也可以单独增加这层检测。价格本身偏离均值，不等于相邻两次价格变化；还要处理分组、样本不足和标准差为零。NIST 的异常值说明也提醒，潜在异常不一定是错误数据。新手不必先背公式，先把输入与结果对上。

固定随机种子会重复生成同一批模拟数据，这是为了复现测试。它每天跑一遍，也不会变成每天的新行情。

第三步：手动通过后，再设置每天运行

如果第二步还报错，先修脚本。把一个会失败的脚本放进定时任务，得到的只是每天重复失败。

演示统一设为每天北京时间上午 9 点，时区用 Asia/Shanghai。这个时间是数据助手的运行时间，与本站文章的发布时间无关。想固定纽约时间，就用 America/New_York；别把美东与北京的时差当成全年不变。

::ILANG::v5.0
[TYPE:task][PROJECT:muse_daily_report][STEP:3][LANG:zh]
::MODULE{SCHEDULE}
  [MUST] 只有第二步真实运行与测试通过才创建任务 先检查同项目是否已有任务 避免重复
  [DO] 用当前产品支持的官方定时入口设置每日09:00 Asia/Shanghai 运行已确认项目的pipeline_worker.py
  [DO] 任务继续使用独立run_id日志与产物 运行失败或人工需处理时通过产品支持的通知入口提醒 正常重复结果保持安静
  [DO] 展示任务ID实际时区下次执行时间执行入口和日志路径 不把任务卡创建当到点执行成功
  [DO] 若产品允许用现有任务触发一次测试 则测试该任务并核对日志与产物 不另建第二个常驻任务
::MODULE{LIMITS}
  [MUST] 不创建系统cron常驻后台或隧道来绕过产品限制 入口不可用则说明阻点并保留手动脚本
  [MUST] 无法保证系统弹窗 手机推送或邮件一定送达 列明实际可用通知位置
  [MUST] 演示自动任务仍处理模拟数据 不声称每天抓到新行情
::ILANG::COMPLETE::

这一关要看任务 ID、实际时区、下次执行时间和输出位置。当前界面的入口名称可能调整，让 Muse 核对它真正支持的能力，不要为了凑教程去另起常驻进程或绕过权限。

通知也要说清楚到哪里看。产品内消息、系统推送和邮件不是同一件事；没有测试送达，就别承诺它一定会在你手机上弹出来。

第四步：有了结果，再做看板

CSV 和摘要能用以后，可以让 Muse 做一个 Artifact，把条数、Top 5 和筛选放到一起。不会看表的人，也能先看到要处理的记录。

但一张漂亮看板能证明它昨天晚上干活了吗？要看的是数据时间和 run_id，也就是本次运行编号。

::ILANG::v5.0
[TYPE:task][PROJECT:muse_daily_report][STEP:4][LANG:zh]
::MODULE{DASHBOARD}
  [DO] 只读取已成功运行的同一个run_id下summary.json和report.csv 生成数据报告Artifact
  [DO] 显示来源为simulation 数据生成时间run_id有效与无效条数异常条数Top5 支持标的筛选及结果下载
  [DO] 显著说明当前实现是本次运行快照 并核对看板数值与源文件一致
  [DO] 检查当前官方任务是否支持运行后刷新或重建这个Artifact 支持则补入同一任务并实际测试 不支持则保留CSV和摘要并明确看板手动更新
::MODULE{LIMITS}
  [MUST] 不凭看板存在推断实时更新 不伪造没有支持的自动刷新或收益
::ILANG::COMPLETE::

本教程先做本次结果的快照。不把这种实现写成“所有 Artifact 都只能是快照”；官方也讨论过可持续使用的看板。你的看板是否自动更新，要看当前任务能不能执行刷新，以及新数据是否真的出现在里面。

暂时不能自动更新，就保留 CSV 和摘要，手动刷新看板。别让一个展示环节挡住已经能交付的结果。

第五步：验收这一次运行，不验收一句“OK”

验收顺序很容易写反：先打开昨天的 CSV，看到条数没问题，然后跑今天的脚本。今天即使失败了，昨天的文件还在那里。

正确顺序是先运行，保存真实退出码，再检查同一个新 run_id 下的日志、CSV 和摘要。看板如果更新，也应该指向这一批结果。

::ILANG::v5.0
[TYPE:task][PROJECT:muse_daily_report][STEP:5][LANG:zh]
::MODULE{MANUAL_ACCEPTANCE}
  [DO] 先实际运行pipeline_worker.py并保存真实退出码 再查同一新run_id的日志CSV和summary
  [DO] 核对本次开始结束时间生成时间 来源字段 CSV解析记录数及摘要计数 top5记录确实来自本次输入
  [DO] 正反测试应符合预期 零异常允许通过 仅在退出码0且所有检查通过时打印HEALTH_CHECK_OK 其他情况打印FAIL与失败步骤
::MODULE{AUTOMATIC_ACCEPTANCE}
  [DO] 读取现有官方任务状态时区下次执行时间与上次结果 区分手动触发和到点自动执行
  [DO] 首次到点后查同一自动run_id的日志与新产物 仅对已配置并验证自动刷新的看板核对本次run_id和生成时间
  [MUST] 手动快照保留旧run_id时标明数据时间及待手动刷新 不据此判定脚本或调度失败
  [MUST] 没有到点执行证据则写定时已设置自动运行待验证 不用任务卡或手动结果代替
  [DO] 在当前产品支持范围内测试一次通知 如不可验证说明实际通知入口和缺失证据
::ILANG::COMPLETE::

正常数据可能一条异常都没有。零异常不等于脚本坏了；检测是否有效，要用已知正常、已知异常的测试用例检查。别用“必须删掉几条”当健康指标。

CSV 条数也用解析器核对，不把文本换行数当通用记录数。字段里本来就可能包含换行。

手动运行成功，只证明脚本能跑。定时卡片存在，只证明任务设置过。等第一次到点执行后，任务记录、本次日志和新产物都对上了，才算验证了自动运行。在此之前，就写“定时已设置，自动运行待验证”。

卡住了，按这一条链路找

跑通以后，再换成你真的需要的数据

下一步不是把 CPU 占用拉满。可以换成自己有权处理的订单 CSV、网站日志，或者有明确使用许可的公开 API。接入时保留来源、抓取时间和错误记录；遇到失败，不用旧数据假装今天抓到了。

对 PuckDeals 这样的项目，我会优先考虑整理候选商品、保存来源与价格时间，再把待核查项交给人。抓到一个低价，不代表优惠仍然有效，更不代表可以直接替我发出去。

想先熟悉产品，可以看这一条来自 Muse 官方设计文章的演示。它介绍产品功能，不是这套脚本已在你账号跑通的证明。

还没加入的，可以走我的Muse 邀请入口，邀请码 WZNBFY。这是我的邀请分享，符合活动条件时双方可能获得词元奖励，具体以当前账号页面为准，不保证兑换到账。

先让它准时交出一份有日期、能核对的报告。