波仔
🧡 第十二章 实战项目1：Chrome扩展
📄 一句话概括

Phase 0 只写一页纸：给谁用、解决哪件事、一次几步、怎么算做完；反例每句都对但动不了手，正例每句都能当场判断。

📝 本节和前面几节的关系

第十二章的起点。前两节说要做什么项目，这一节把【做什么】落成一页能开工的纸。

一、一页纸，四句话

它给谁用：范围越具体越好——【我自己，每天用一次】。 它解决哪件事：一句话说完，不许出现【提升效率】这种词。 一次用几步：把用户的操作写成一条链——【点图标 → 存 → 弹提示】。 怎么算做完了：写一条能当场判断的标准。

二、反例为什么动不了手

反例每一句都对，但每一句你都判断不了有没有做到。 正例每一句都能当场判断——这就是能不能开工的分界线。 判据只有一条：这句话我能不能拿一个具体场景验一下。

三、需求写不清的代价

演示里那个扩展最后写到 1211 行，大半功能都是后来加的。 加的时候每一条都显得合理，合起来就成了一个谁也不敢改的东西。 需求不写清，就不是在做项目，是在做加法——这也正是第 12.8 节那个案例的由来。

四、把这一页纸交给它

开一个新会话，先把这一页纸贴进去——它需要的是背景，不是客套。 然后让它复述一遍：它理解的和你写的是不是同一件事（第 9.2 节）。 这一页纸以后就写进规则文件——下次改这个项目，它一进来就知道要做什么。

五、动手 Demo：需求分析，一页纸

下面把要写清的四句话排开，各配一条反例与一条正例。

TH([u"要写清的四句", u"反例", u"正例"], [16, 32, 34])
T([u"它给谁用", u"【所有人】", u"【我自己，每天用一次】"],
  [16, 32, 34])
T([u"怎么算做完了", u"【好用就行】", u"【三个网页存下来格式都不乱】"],
  [16, 32, 34])

实跑输出：

--------------------------------------------------------------------
需求分析，一页纸
--------------------------------------------------------------------

Phase 0 只做一件事：**把【想让它干什么】写成一页纸**。

写清这四句，就够开工了——注意左边是反例，右边才是能开工的写法：

  要写清的四句     反例             正例
  ----------------------------------------------------------------
  它给谁用         【所有人】       【我自己，每天用一次】
  它解决哪件事     【提升效率】     【一键把当前页存成 Markdown】
  一次用几步       【很多功能】     【点图标 → 存 → 弹提示】
  怎么算做完了     【好用就行】     【三个网页存下来格式都不乱】

反例的共同点：**每句都是对的，但每句都动不了手**。
正例的共同点：**每句都能当场判断有没有做到**。

需求写不清的代价，在这本书的例子身上最直观——
那个扩展最后写到 **1211 行**，其中大半的功能，
**都是【做着做着觉得还可以加一个】加上去的**（第 12.8 节）。

反例的共同点：每句都是对的，但每句都动不了手。 正例的共同点：每句都能当场判断有没有做到——这就是能开工的标准。

30 秒实验

  1. 把你那个想法按四句话写下来，每句后面加一句【怎么验证】。
  2. 拿给别人念一遍——他能不能复述出你要做什么？复述不出就是还没写清。

常见误区

  1. 用【提升效率】【好用就行】这类词。它们听着对，却无法验证。
  2. 需求边写边做。需求不写清，做的就不是项目，是加法（第 12.8 节）。
自测三问（点开对答案） 1. Phase 0 要写清哪四句话？ —— 给谁用、解决哪件事、一次用几步、怎么算做完了。 2. 反例和正例的分界线是什么？ —— 能不能当场判断有没有做到。 3. 那一页纸写完之后交给谁？ —— 贴进会话开头，并写进项目的规则文件。

相关笔记