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

八条建议的共同点都是给自己留退路：小步、可验、能退回——用 AI 做项目，决定成败的还是这三件事。

📝 本节和前面几节的关系

第十二章收尾。前面八节走完一个完整项目，这一节把经验收成一张清单。

一、八条建议

先跑通最小版本、一次只加一个功能、每加完就自己验一次。 权限只要必需的、写一份简短 README、用 git 存档。 上架前读一遍政策、小项目别上框架。 每一条都能在你正在做的这个项目里立刻用上。

二、共同点：给自己留退路

小步——一次只动一点，出错范围就是那一点。 可验——每一步都有能当场判断的标准。 能退回——git 存档，坏了大不了退回去重来。 三条都在做同一件事：把【做错】的代价压到最低。

三、为什么这三件事在 AI 时代更值钱

它写代码快，所以【试错】的次数也变多了。 次数多了，单次错误的代价就成了主要成本（第 10.2 节）。 所以小步、可验、能退回，不是保守，是让快的部分真的变成优势。

四、这一章之后你要做的事

别停在读：拿你那个想法，按 Phase 0~5 真的做一遍（第 12.2 节）。 做完回头看一遍这两节：重构案例与这份清单（第 12.8 节）。 下一章换一个项目——内容创作自动化，把同样的流程再走一遍，重点换到 skill 与多智能体。

五、动手 Demo：项目实践建议

下面把八条建议与各自的理由排开。

TH([u"建议", u"为什么"], [26, 52])
T([u"一次只加一个功能", u"出问题才知道该怀疑哪一段"], [26, 52])
T([u"小项目别上框架", u"175 行能做的事，不需要 175 行的依赖"], [26, 52])

实跑输出：

--------------------------------------------------------------------
项目实践建议
--------------------------------------------------------------------

把这一章的经验收成一张清单，下次开新项目照着走：

  建议                   为什么
  -----------------------------------------------------------
  先跑通最小版本         能装上、能点开，就是第一个里程碑
  一次只加一个功能       出问题才知道该怀疑哪一段
  每加完就自己验一次     它写的代码看着都对，只有跑才判真假
  权限只要必需的         权限越多，用户越不敢装
  写一份简短 README      三天后的你也算【别人】
  用 git 存档            改坏了能退回去，比什么技巧都值
  上架前读一遍政策       被下架重来，代价远大于先读一遍
  小项目别上框架         175 行能做的事，不需要 175 行的依赖

这些建议有一个共同点：**都是在给你自己留退路**。

    小步、可验、能退回——
    **用 AI 做项目，真正决定成败的还是这三件事。**

八条建议的共同点：都是在给你自己留退路——小步、可验、能退回。 用它写代码快，试错次数就多，所以单次错误的代价成了主要成本。

30 秒实验

  1. 把八条抄进这个项目的规则文件，下次它就是你的默认纪律。
  2. 给自己定一条：每跑通一个模块就 git 存一次档——退路是攒出来的。

常见误区

  1. 把这份清单当成【以后再说】。它每一条在你手上这个项目里立刻能用。
  2. 以为小步是保守。它写代码越快，单次错误的代价就越贵——小步才让快变成优势。
自测三问（点开对答案） 1. 八条建议是哪八条？ —— 先跑通最小版本、一次只加一个功能、每加完就自己验、权限只要必需的、写简短 README、用 git 存档、上架前读政策、小项目别上框架。 2. 它们的共同点是什么？ —— 都是给自己留退路——小步、可验、能退回。 3. 为什么这三件事在 AI 时代更值钱？ —— 它写代码快、试错次数多，单次错误的代价就成了主要成本。

相关笔记