问题框架

这是本课程的第一次正式作业，直接对应本节课讲的"问题框架"（problem framing）方法论——目标是训练学生按照结构化的发散/收敛流程，找到一个"真实需求"（而非"创造需求"）的问题，并用证据支撑自己的判断，而不是凭直觉或"清醒的梦"式的自我说服。

TL;DR

• 作业先发散个人相关领域与候选问题，再用严重性、可行性、个人洞察和证据收敛，避免过早依附某个解决方案。
• 每个入选问题都要识别直接与间接利益相关者，并用至少五条可追溯证据或对标方案证明需求真实存在。
• 功能构思必须解释如何回应问题；“想做一个应用”或“现有技术不够好”都不是独立于方案存在的用户问题。
• 最终方案还需满足可用完整、动态、原创和真实需求四项标准；LLM 可帮助扩展候选，但保留、排除和论证仍由作者负责。

五个任务

1. 领域任务（Domains Task）：从个人兴趣、活动或经历出发，列出 10 个感兴趣的领域；从中选 3 个，用几句话说明为什么对每个领域感兴趣。
2. 问题任务（Problems Task）：为每个领域各找 3 个问题（共 9 个）；从中选出 3 个问题，分别写出标题和说明，并论证为什么选它们；对被排除的问题也要说明排除理由（是否足够严重、可行性、个人洞察力等）。
3. 利益相关者任务（Stakeholders Task）：对每个入选问题，至少找出 3 个利益相关者（不仅是直接用户，也包括间接受影响的人），给出名字、一句定义性描述，并说明该问题如何影响到他们——这直接呼应本节课"忽视关键利益相关者"（Ignoring Key Stakeholders）这一失败模式（如 Google Glass 案例）。
4. 证据任务（Evidence Task）：为每个问题收集至少 5 条证据或对标产品/服务（comparables），并附引用链接和解释性文字，说明这些证据如何证明问题的严重性。来源可以是维基百科、文章、博客、问答论坛，优先使用定量数据。这一步正是在践行"寻找冷漠信号 / 寻找'不不'信号"的方法，用证据代替自我说服。
5. 功能任务（Features Task）：为每个入选问题构思 3 个功能（共 9 个），每个功能要有标题、功能说明、以及它如何解决问题的解释。

项目标准与课程方法的呼应

作业明确要求最终方案必须满足：

• 可用且完整（usable and complete）：功能要能完整支撑预期的工作流程，不能有明显缺口
• 真实需求（authentic demand）：解决真实存在的用户需求，有真实的潜在价值——这正是本节课反复强调的"真实需求 vs 创造需求"的区分
• 动态（dynamic）：存储会随用户动作演化的状态，而不是一次性的函数调用
• 原创（original）：在现有方案基础上有创新组合或改进，而不是简单的克隆

评分标准（节选）

技能维度	成功标志	常见失败
发散广度	领域覆盖个人/社交/职业等多方面	范围过窄、领域过于宽泛、选择过于常规
问题识别	问题清晰、可解决，代表真实用户困境	含糊的抱怨；把"问题"和"解决方案"搞混
利益相关者分析	利益相关者各不相同，且有实质性影响说明	只考虑终端用户；未解释具体影响
证据收集	5+ 条相关、有引用的证据，能说明问题重要性	证据过少或不相关；引用太泛
批判性使用工具	深思熟虑地使用 LLM，保留个人判断	过度依赖未经修改的 AI 输出

提交方式

1. 在个人 GitHub 作品集仓库中创建作业文件，并在仓库主 README 中链接到它；提交前 commit + push，记下 commit hash
2. 通过提交表单填写仓库链接和 commit hash
3. 在截止日期后 24 小时内完成课程调查问卷

关键建议：尽早开始，给自己留出反思的时间；优先保证质量和清晰度而非篇幅；善用 LLM 辅助但不能替代个人判断；一个"问题"应当是独立于任何解决方案而存在的用户困境，而不是技术限制。