使用 Pythagora 2.0 构建睡眠追踪应用

我正在使用 AI 辅助开发环境 Pythagora 2.0 构建一个睡眠追踪应用。本视频由 Pythagora 赞助。我表示，这次演示在我工作不到一个半小时的时间里生成了数千行代码，但这只是一次经过剪辑的构建，并非独立基准测试，也不能证明所得应用已可投入生产。

我的想法是收集睡眠和习惯数据、寻找规律，并向 AI 睡眠教练提问。我从详细规格开始：主页、睡眠教练、登录和注册、用于设置 OpenAI API 密钥和选择模型的账户页面，以及结构化数据格式。我建议多花时间编写提示词，因为它定义了智能体应该构建什么。

在数据输入方面，我希望用户可以录制自然语言语音备忘录，或上传 Whoop、Eight Sleep 等设备的截图。计划中的应用将把睡眠细节提取到数据库中并生成建议。这些都是设计目标；生成的系统能否正确处理敏感数据或提供可靠健康建议，仍需单独验证。

在这次 2025 年 6 月的演示中，我使用 Pythagora 的托管界面，此前我用的是它的 VS Code 扩展。我粘贴提示词，工具将其重新整理并扩充成可编辑的 Markdown 规格文档。我检查导航和页面要求，必要时进行修改，并在开始构建前确认文档。

任务视图将项目拆分成多个大型任务和具体步骤。系统先准备规格，再开始构建前端和界面骨架，工作过程中还会出现其他任务。规格文档保持可编辑状态，因此当需求发生变化时，我可以回头修改，而不必只依赖最初的提示词。

智能体安装软件包并编写应用文件，包括前端组件以及睡眠、聊天和设置 API。我可以在托管编辑器中查看这些文件。我将这个工具描述为对其擅长处理的框架有明确偏好，并强调随着界面和后端逐步成形，我仍需要监督两者。

私有预览打开了初始睡眠仪表盘，包含截图上传、语音录制、建议区域、睡眠模式和教练界面。此时后端尚未完成：展示的图表和建议使用的是模拟数据，因此仅凭画面不能证明 AI 和数据库已经正常工作。

账户页面提供 OpenAI 密钥输入框和模型选择；我在示例中选择 GPT-4o。检查界面后，我同意进入后端开发。我喜欢规格、前端、后端的分阶段顺序，因为它能在其余功能完成前先展示预期界面。

系统报告错误并开始修复，随后要求人工测试。它提供注册和登录的步骤及预期结果。我创建账户、看到成功提示，并在本次演示中验证登录可用；基本流程成功并不等于完成了全面的安全或身份验证审计。

下一项任务增加用户设置，以及保存所选模型和 API 密钥的方法。我检查实施计划和修改过的文件，然后按照账户页面上的另一份清单进行测试。演示确认界面报告了成功，但不能证明凭据的存储或处理方式有多安全。

我指出，也可以在单独的浏览器标签页打开应用，在嵌入式窗口之外进行测试。设置测试完成后，我批准录制和上传数据的任务。工作流程在智能体实施与我反馈观察结果是否符合清单之间交替进行。

实施计划包括上传端点、文件元数据、存储，以及替换模拟响应。我认为 Pythagora 介于以代码为中心的编辑器和仅靠提示词的应用构建工具之间：在这次使用中，它生成了大部分代码，同时仍将文件、任务计划和测试展示给人审查。

为了测试上传，我选择一张 Whoop 应用截图并看到成功提示。随后我检查服务器的上传目录和数据库，找到文件及其元数据。这证明该示例已进入存储，但还不能证明图像被准确解析，也不能证明数据受到了保护。

我录制一段简短的语音备忘录，并以同样方式检查数据库元数据。下一步计划使用 OpenAI Whisper 增加转录，并处理提取出的信息。Pythagora 在编写更多代码前列出了所需的后端、数据库和前端修改。

界面报告了多个错误，包括请求失败，于是我启动修复流程。它检查日志、分析问题、提出错误处理等修改，然后要求我再次测试。我把报告中的修复视为需要验证的假设，而不是所有底层缺陷均已消除的证明。

随后一次语音备忘录测试因处理错误而失败。我在工具中反馈这一失败，按要求创建第二个没有 API 密钥的用户，并复现了预期错误。额外日志显示存在解析问题，因此我再次运行修复流程并重复测试，而不是把第一次尝试当作最终结果。

进一步修复后，界面报告录音成功。我在单独的标签页打开应用，录制一段简短测试语句，并查看浏览器控制台确认转录结果。这只是针对样本录音的有限测试，并非对不同说话人或条件下转录准确率的测量。

我再次测试截图，并检查返回对象中提取出的就寝时间、深睡眠和 REM 睡眠等字段。提交显示成功后，我查看了输出。这项测试展示的是针对特定图像的一次响应，不能证明所有可穿戴设备截图或数值都会被正确解析。

智能体接着实现处理后睡眠数据的保存和读取。我上传另一张截图时，应用报告成功，但睡眠模式图表没有显示该条目；鼠标悬停时还出现灰色方块。我在反馈中描述了这两个问题，而没有将任务标记为完成。

一项拟议修复增加了空状态，但第二次上传并刷新后，图表仍然没有出现。我要求增加日志，随后发现提取结果中包含一个 2023 年日期，与我想录入的日期不符。日志帮助我找到数据未在预期时段出现的一个可能原因。

我指示智能体假设上传的截图对应前一晚睡眠。下次测试时，图表显示了总睡眠、REM 和深睡眠。这个假设适用于当前样本，但可能给较早的截图分配错误日期，因此实际应用需要提供确认或更正日期的方法。

我请求 AI 生成建议并收到响应，同时注意到数据库中的数据很少。以后我可以调整提示词，改变建议的长度和具体程度。收到响应只证明演示中的请求有返回结果；它并不能从医学角度验证建议，也不能证明系统掌握了足够信息来给出个性化结论。

任务列表建议实现一个我认为已经存在的建议端点，因此我跳过它并转向睡眠教练。界面再次报告错误并经过一轮修复后，我发送问候并收到回复。我检查消息已存储，重新加载页面后仍然存在。

教练回答了一个关于睡前放松习惯的一般问题。我明确将另一个目标留给未来迭代：让教练访问我的全部数据，并确认它能够回答针对我个人数据的问题。视频并未证明这一个性化数据功能已经完成。

我接受了演示中的构建，并报告了所花的工作时间。实际经验是一个迭代循环：编写规格、检查生成的工作、进行人工测试、报告失败并重新测试。这次受赞助的演示展示了部分流程可运行的原型，但隐私、安全、准确性和实际部署方面的问题仍待解决。