先理解问题

本周要回答： 用户真正想完成的任务是什么，当前工具为什么没有帮到最后一步？

进入本周前： 已经交付过一个可运行、可恢复的小工具；能观察自己的操作，而不是只列想要的功能。

学习内容与理解目标

本课程把 FDE 思维落实成一个方法：贴近使用场景，把模糊抱怨转换成可验证的改进。本周开始项目 P1——本地周计划工具。这里的“周计划”只是公共教学案例，不绑定职业、法定工时或任何机构规则；每个人自己配置可用时段和任务类型。

需求应区分事实、假设与设计选择。事实可以是“我每次要重复输入相同任务”；假设可以是“模板会减少重复”；设计选择才是“做一个复制上周按钮”。先检查现成设置、表格或普通脚本是否足够，不把 agent 作为预设答案。用户研究方法可从 R74 · GOV.UK Service Manual：Plan user research 选读，但本周只需要一页问题说明。

学习链接与选读范围

实战拆解

1. 完整记录一次自己安排一周任务的过程：从哪里获取任务、何处重复录入、哪里检查冲突、如何导出和修改。可以记步骤与主动时间，不录制私人屏幕。

2. 把观察结果分成痛点、证据和假设，最多挑一个主要摩擦。例如模板重复录入比漂亮的统计图更重要，就先做模板。

3. 写三个验收情景：普通一周、某天不可用、两项任务重叠。明确时长与边界由用户配置，不能把示例安排写成所有人都必须遵守的制度。

4. 为 P1 制作一个薄而完整的纵向功能：输入任务、看见安排、检查冲突、导出预览。优先复用前六周的组件、校验与测试。

5. 对照原流程做一次试用。记录剩余摩擦和明确不做的功能，例如智能聊天、多人协作、云同步；不要因为技术容易加就纳入范围。

交付与验收

不用代码生成器的练习： 自己把一句模糊需求“更智能、更方便”改写成可测试情景；请别人只按该情景判断能否验收，不能先解释你的设计意图。

隐私与安全检查： 研究对象默认是自己的低风险流程。访谈别人前先取得知情同意；不要记录真实客户、单位内部流程或他人的日程。演示数据使用“任务 A”“学习块”等通用名称。

落到日常生活： 把工具放进下一次实际周计划的准备流程。最重要的问题不是“还能加什么”，而是“下次没有这个功能，我会在哪一步觉得麻烦”。

过关或补课判断： 能够说明哪个观察导致哪个功能，且至少一个非目标被真正排除后进入下一周。若所有需求都必须做，先缩小试点。

本周可复制的协作提示

请先帮助我把真实流程拆成步骤、证据和假设，再挑一个高频低风险摩擦。为本地周计划工具写三个验收情景，只实现一个端到端改进。不默认需要 agent、云同步或多人系统。

本周来源与核对范围

来源编号与核对说明沿用课程原文，基线为 2026-09-27。未逐一登录完成外部实验；实施前请核对最新版本与访问条件。

1. R09
   Stanford CS146S：The Modern Software Developer，Fall 2026 ↗

   已核对课程介绍与先修要求；不代表秋季全部讲义和作业已开放。

2. R47
   OpenAI：Harness engineering ↗

   2026-02-11；学习仓库、反馈与约束，不照搬内部案例收益。

3. R74
   GOV.UK Service Manual：Plan user research ↗

   借鉴问题发现方法；不是对特定机构流程的授权。