开发后期：
高频测试正在开发的功能: 一旦后端提供了一个接口，或者前端实现了一个初步的 UI，你就应该立即去试用。不要等到功能完全“完成”再去测试。 提供即时反馈: “感觉不对”: 即使说不出技术原因，但如果你觉得某个交互流程不顺畅、某个按钮位置很奇怪、某个文案有歧义，马上提出来。这种“感觉”对工程师非常有价值，能帮助他们从用户视角调整实现。 发现 Bug 和边界情况: 尝试各种“非正常”操作，比如输入奇怪的字符、快速点击、在网络不好的情况下操作等。你发现的每一个 Bug 都能为项目节省后续的调试时间。 守护用户体验的一致性: 不同的工程师可能负责不同的模块，他们的实现可能会有细微的风格差异。你需要确保整个产品的交互逻辑、文案风格、视觉元素保持一致性，让用户感觉这是一个整体。
开发中期
澄清模糊的需求: 当工程师问“这个地方如果用户这么操作，应该怎么办？”时，你需要快速地从产品和用户角度给出明确的答案或提出几种方案供讨论。 在技术实现与用户体验间做权衡: 工程师可能会说：“实现 A 方案需要3天，但实现一个效果 80% 的 B 方案只需要1天。” 你需要快速判断，这 20% 的体验差距是否值得多花2天时间，并结合我们的 MVP 目标（快速验证核心价值）做出决策。这需要你对我们之前定义的优先级有深刻的理解。 坚决地“砍需求” (The Art of Saying “No”): 这是 Hackathon 中最难但最重要的技能。开发过程中，团队成员（包括你自己）可能会冒出很多“酷炫”的新想法。你需要像一个“守财奴”一样守护我们已经确定的 MVP 范围。 面对新想法，问自己：“这个功能对于验证我们的核心假设是必不可少的吗？它在我们的 P0/P1 列表里吗？如果现在不做，天会塌下来吗？” 如果答案是否定的，礼貌而坚决地将其放入“未来考虑 (Parking Lot)”列表，让团队保持专注。
开发前期
记录关键决策和讨论: 在你们的协作工具（如飞书、Notion）中，简要记录下每天的关键讨论、技术权衡和最终决策。这对于项目后续的复盘和新成员的加入非常有价值。 准备“弹药”——产品演示文稿: Hackathon 的最终目标是展示成果。你应该提前开始准备最终的演示 (Demo) 流程和讲稿。 思考如何用一个引人入胜的故事来串联你的产品功能。从用户的痛点开始，展示你的产品如何巧妙地解决了这个问题，最后展望未来的可能性。 根据开发进度，不断更新你的演示流程，确保你能展示出最有亮点的部分。 制作演示用的原型或视频。你可以用 Figma、Keynote 甚至录屏软件，提前制作一些流畅的交互演示，以防现场 Demo 时出现意外。