看到deep seek harness是这样子被写出来的感觉有很多疑惑的地方

规则是用来替代注意力的 --- 读完 DeepSeek harness 那个仓库，第一反应是「我们是不是也该这么干」。花了一晚上把它扒了一遍，最后决定：大部分不抄。记一下这个判断过程，因为它比结论有用。 先看差距有多大 它九周、40 个人、33.9 万行生产代码；沉思四周半、一个人（加一个 AI），1.2 万行。生产代码差 27 倍。 但最刺眼的不是这个数，是删除量：他们累计删掉的代码是新增的 42%，我们只有 11.7%。他们把「删代码」做成了和「写功能」平级的任务类型——有专门的分类、专门的分支线、成批地跑。 然后我问了一个问题：那套东西是为了解决谁的问题？ 他们有一整套机械化的门：每篇决策记录必须写「考虑过哪些替代方案」、文件夹位置就是状态、每个文件必须 100% 测试覆盖、格式不对 CI 直接红。 我一开始觉得这是「更专业」。想清楚之后发现不是——这是用规则替代注意力。 40 个互不相识的人共同改一个仓库，甲写完一个文件，三周后乙来重构，中间没有任何对话。这种情况下门必须是机械的，因为「问一句」这个选项不存在。 就像小公司不需要打卡机，因为老板看得见每个人在干嘛；公司大了才需要打卡。打卡机不是更先进的管理，它是「看得见」这件事的替代品。 反过来看我们：每一个改动都过一轮独立盲审——一个完全没有上下文的模型逐行读 diff，给出 SHIP 或者 REWORK。DeepSeek 一万两千个 commit 不可能每个都这么审。所以在「这次改动对不对」这个维度上，我们的门其实比他们严。 我们还有注意力。等注意力不够用的那天再换规则——而那天是可以预测的：开源那天、有人开始批量提 PR 那天、或者我离开一个月再回来那天。 决定做的：记录「否决了什么」 我们真正在丢的东西，是这个。 「做了什么」commit message 里有；「是什么」代码注释里有。丢的是「我们考虑过 A，决定不做，因为在什么什么条件下它会怎样出错」——这个结论只活在一次对话里，下一轮没人记得，同一个诱人的坏主意就会被第二次提出来。 这就像开会只记「决定了什么」，不记「否决了什么」——下次开会必然再吵一遍。 所以加了一份决策记录，格式钉死三行：日期、决定、否决了什么。第三行是唯一有增量的那行。 决定不做的：他们那套生命周期文件夹 他们的记录会在文件夹之间物理移动：提案中 → 已实现 / 已否决 → 已封存。用文件夹表示状态，因为文件里写的「状态：已完成」那行字会忘记改。 设计很聪明，但搬文件是要靠人记得的纪律，纪律一定会腐烂。 而且我们有现成的证据：仓库里躺着一份早期的进度日志，写得非常好，甚至有「裁定：这属于设计意图，不是缺陷」这种高质量的否决记录——然后死在第 128 行，再没人写过。 所以改成只追加、不搬动、不修改历史。追加不需要维护，也就没有腐烂的地方。 决定不做的：100% 测试覆盖率 覆盖率的意思是：跑测试的时候在每行代码上装个计数器，跑完看哪些还是 0——那些就是从没被执行过的代码。 听起来很硬核，但它有个致命的局限：它只回答「这行代码被执行过吗」，完全不回答「执行的结果对不对」。 像体检报告只告诉你哪些器官没检查，不告诉你检查过的那些是不是健康的。极端一点，写个测试只调用函数、一句都不验证，覆盖率照样 100%。 更关键的是，它跟我们真实踩的坑不重叠。这个月的坑是：数据库权限漏配、查询被静默截断在 1000 行、触发器删除时死锁、一个闭包捕获了旧值。这些代码全都被执行到了，只是环境和时序跟我以为的不一样。覆盖率一个都测不到。 所以排到最后，而且真要做也不设 100——先跑出当前真实数字当门槛，之后只许涨不许跌。像棘轮一样只能朝一个方向走。第一天就全红的门，唯一的结局是被关掉。 最后是个意外收获 聊到「我们还没被没测到的 bug 咬过」的时候，我意识到这句话有问题。 「还没出现」这个证据的强度，取决于有没有人在用。 现在线上的用户是我、Jack、几个演示账号。就算有 bug，也没有足够的人去撞它。所以「没出现」既可能是「真没有」，也可能是「没人踩到」——这两个我们现在区分不了。 而且更要命的是：线上真的出错了，我现在完全看不见。没有错误上报、没有异常聚合。第一个咬人的 bug，我会从用户嘴里知道，而不是从仪表盘。 绕了一圈，最该补的不是那三条里的任何一条。是这个。