波仔
🐳 第八章 设计自己的Harness
📄 一句话概括

造 Harness 的第一个动作不是【翻插件列表】，而是先写清要干什么、绝不允许干什么——需求定了，插件只是它的答案。

📝 本节和前面几节的关系

第 7 章把 Runtime 的大件看完了，这一章换立场：从【看别人怎么装】变成【自己也装一套】。第一件事是改起手式。

一、两种起手式

前者看着快，其实把判断权交给了工具的名字——一个包叫什么，跟它该不该出现在你的组合里，没有必然关系。

二、为什么【从插件出发】必然走偏

本课实测的配置树里，顶层注册项有 183 条。

183 个名字摆在一起，你没法凭名字回答：这一件该不该在我的组合里？ 因为该不该是需求决定的，不是能力决定的——同一件工具，在审查预设里多余，在开发预设里必需。

三、需求清单写四栏

【不做】这一栏是本课的常客：2.2 的工作区先划边界，4.5 的权限先定档位，都是同一个动作。

四、需求怎么落到配置上

一条需求 → 一种能力 → 配置树上的一行。

反过来不成立：树上的一行，未必对得上任何一条需求——那它就不该装。

这就是 8.3 那个最终项目的做法：五步里前两步都在写清单，写 YAML 只是第三步。

五、动手 Demo：两种起手式，差在哪

同一个任务，两种起手式的第一步就不一样：

need = ["读文件", "按内容搜索", "登记待办", "出报告"]
never = ["执行命令", "改文件", "装插件"]
print("要做 %d 条, 不做的一开始就写死 %d 条" % (len(need), len(never)))
print("接下来才是去配置树里找对应的件——顺序不能反")

实跑输出：

--------------------------------------------------------------------
两种起手式，差在哪
--------------------------------------------------------------------
  任务：给一个代码仓库做【只读代码审查】。

  起手式             第一步动作                      结果
  --------------------------------------------------------------------------
  从插件列表出发     翻 183 个包，挑看起来有用的     挑出 12 件，4 件用不上
  从需求出发         先写要做什么、不能做什么        每条需求都能对上件
  --------------------------------------------------------------------------

  两种起手式的差别不在【快慢】，在于**顺序**：
  先挑工具，等于让工具决定你能干什么；
  **先写需求，工具只是需求的答案**。

差别不在快慢，在顺序：先挑工具，等于让工具决定你能干什么。 先写需求，工具只是需求的答案——对不上的就不装。 这也是后面五步里，前两步都在写清单的原因。

30 秒实验

  1. 拿你手头一件真事，先只在纸上写【要做 / 不做 / 范围 / 交付】四栏。
  2. 写完后，再去配置树里找件——数一数有多少件是【需求没提但你想装】的。
  3. 把那些件划掉，看看剩下的组合还够不够干活。

常见误区

  1. 错误：能力越多越好，先装上再说。——纠正：装上去就要有人管——每一件都进工具表，模型每一次选择都在 183 个名字里挑，而多出来的件还可能带来你不想要的动作。
  2. 错误：需求写一遍就够了，改配置时不用回头看。——纠正：配置是需求的投影——需求变了配置不改，树里就会留下一条谁也说不清为什么在的件。
  3. 错误：先搭起来，再慢慢砍。——纠正：砍比不装难得多——装是一件件加，砍要逐条确认【谁在用它、撤了会不会塌】；本课第 5 章整章都在讲撤下的代价。
自测三问（点开对答案） 1. 为什么第一动作不是翻插件列表？ —— 因为**该不该装是需求决定的**——183 个名字摆着，凭名字判断不出它在你的组合里该不该在。 2. 需求清单写哪四栏？ —— **要做 / 不做 / 范围 / 交付**——其中【不做】比【要做】更关键。 3. 需求怎么落到配置上？ —— 一条需求 → 一种能力 → 树上的一行；**反过来不成立**，树上对不上需求的件就不该装。

相关笔记