我开始用 PR 测量 harness-starter-kit 的效果而不是只看感觉大家好我是一名来自韩国的初级开发者也很喜欢中国。中文还是用工具辅助写的如果有不自然的地方请大家多多见谅。继前 3 篇文章之后这次我写了第 4 篇。在前几篇文章里我主要分享了两件事。第一篇是我把harness-starter-kit用到真实项目里看看 agent 会不会乱复制模板、破坏结构、生成没人维护的 docs。第二篇是harness 不一定让 agent 立刻变聪明。更现实的价值是让错误更早暴露并且让仓库记住这个错误。这篇我想继续往下走一步。如果我们说 harness 有用那到底怎么判断不能只看感觉。也不能只看Harness Doctor分数。更不能因为某次 PR 看起来顺利就直接说agent effectiveness 提高了。所以这次我用一个真实 dogfood PR 做了一次很小的 effectiveness tracking。结论先说这次 PR 不能证明 harness 已经让 agent 变强。但它给了我一个可以继续比较的初始 benchmark。这次看的 PR这次我看的对象是today-bus的一个 dogfood PR。项目是today-bus它是一个 Next.js 项目目标是帮助用户计算为了赶上 구미역 的火车应该什么时候出门、走到哪个公交站、坐哪班车。这次评估的 PR 是baskduf/today-bus#2merge commit 是85312c181b294c3419dd0813820c10977dd5005b评估窗口是2026-06-04 dogfood PR这次不是正式实验。更准确地说它是harnessed-only initial benchmark也就是说我没有 pre-harness baseline。所以我不能说“比以前好了多少”。我只能说在这个已经采用 harness 的 PR 里agent 的任务边界、验证结果、已知错误重复情况被记录成了可以复查的 evidence。我没有把 setup run 算进去这次有一个我觉得很重要的点不是所有 agent run 都应该算进 effectiveness measurement。TodayBus 里有一个 setup outcome recorddogfood-effectiveness-20260604-160333.yaml但我把它排除在 product-task metrics 之外。原因是它不是一个具体产品任务。它更像 setup / tracking 准备工作。它缺少这些条件concrete product taskexpected boundaryknown failure moderequired verification commands如果把这种 setup run 也算进去数字会变得好看但意义会变弱。所以这次我只统计真正的 product-task outcome。这个区分对我很有帮助。以前我可能只会说这次 PR 里有几个 agent task都算进去吧。现在我会更谨慎只有可比较的产品任务才进入 effectiveness report。setup、adoption、placeholder prompt 可以记录但不能随便当成效果证据。这次统计了 3 个 product task这次 PR 里最终统计了 3 个 task outcome。1. Homepage copy tightening第一个任务是调整首页文案。目标不是重做 UI也不是改变产品行为。只是让页面上的 copy 更清楚。预期边界大概是app pagelayout metadatasearch form copytask outcome record常见失败模式是agent 顺手重写 UI改动视觉结构改动产品行为忘记记录 task outcome最后实际改动集中在src/app/layout.tsx src/app/page.tsx src/components/today-bus/search-form.tsx docs/effectiveness/task-outcomes/todaybus-001-homepage-copy.yaml这个任务通过了验证。2. Planner empty-result test hardening第二个任务是给 planner 的 empty-result fallback 增加 deterministic test。这个任务对 TodayBus 很重要。因为项目依赖外部 API但 normal gate 不应该依赖 live API。所以这个任务的边界是planner testtask outcome record常见失败模式是为了测试改产品行为在 deterministic test 里调用 live API顺手改 UI把 external provider 问题混进 local test最后实际改动主要是tests/planner-branches.test.mjs docs/effectiveness/task-outcomes/todaybus-002-empty-result-tests.yaml这个任务也通过了验证。3. Domain planner terms alignment第三个任务是整理 domain docs 里的 planner 术语。这是一个 docs-only task。预期边界是domain docstask outcome record常见失败模式是docs-only 任务却改 app code重复 ADR 内容术语漂移顺手改 test 或 implementation最后实际改动集中在docs/domain/glossary.md docs/domain/tago-api.md docs/domain/gumi-bis.md docs/effectiveness/task-outcomes/todaybus-003-domain-planner-terms.yaml这个任务也通过了验证。结果看起来不错但不能过度解释这次 report 里的结果大概是MetricResultProduct-task outcomes counted3Wrong-file edits0 observedRepeated known mistakes0 observedFirst-pass verification success3 / 3Drift violations detected0 observedReverted files0 observedHuman rework minutesUnknown如果只看表格好像可以说harness 很有效。但我觉得这样说太快了。因为这里有几个限制没有 pre-harness baseline只有一个 PR只有 3 个 product taskreviewer 给了比较明确的边界和 failure modehuman rework minutes 没有记录prompt text / prompt hash 没有作为稳定 artifact 保存所以更准确的说法应该是这次 PR 建立了一个初始 benchmark。它记录了边界遵守、first-pass verification、outcome record completeness。但它还不能证明 harness adoption 提高了 agent effectiveness。这个结论没有那么刺激。但我觉得它更诚实。我真正学到的是PR 可以成为 measurement unit以前我看 PR主要看这些东西代码对不对tests 过不过有没有明显 bugreview comment 要不要改但这次 dogfood 之后我开始用另一个角度看 PR一个 PR 也可以成为 agent work 的 measurement unit。也就是说PR 里不只记录代码变化。还可以记录这次 task 的 expected boundary 是什么agent 实际改了哪些文件有没有 wrong-file edit有没有重复已知 mistakefirst-pass verification 有没有通过有没有 reverted fileshuman rework 是 0、unknown还是具体多少分钟这个 outcome 要不要进入 effectiveness report这些信息如果只留在聊天记录里很快就会消失。但如果放进 repo 的 task outcome records之后就可以比较。比如下一次 TodayBus 再做 3 到 5 个类似任务我就可以问wrong-file edits 还是 0 吗first-pass verification 还能保持吗已经记录过的 TAGO / TMAP / generated file 问题会重复吗human rework 有没有减少哪些 harness rule 真的有帮助哪些只是文档这比“感觉 agent 这次表现不错”更可靠。Harness Doctor 还是不能当成效果证明这次也让我更确定一件事Harness Doctor很有用但它不是 agent effectiveness score。它能告诉我 repo 里有没有这些 durable evidenceAGENTS.mdlocal checksCI hintsdecision recordsfailure recordsadoption reportsource trackingeffectiveness plan这些是 harness health signal。但它不能告诉我agent 是否少改错文件reviewer 是否少返工known failure 是否少重复first-pass verification 是否更常通过这些必须靠 task outcome 和 effectiveness report 记录。所以我现在会把两层分开Harness health: repo 有没有 durable rules / checks / memory Agent effectiveness: 真实任务里 agent 有没有少犯错、少返工、少重复失败这也是为什么这次 report 里一直强调initial benchmark, not proof.这次 PR 给我的正面信号虽然不能证明效果提升但这次 PR 还是有一些正面信号。第一agent 没有超出 task boundary。三个 task 都基本只改了预期范围内的文件。第二deterministic test 和 live API 的边界保持住了。empty-result fallback test 没有依赖 live provider。第三docs-only task 没有变成 implementation task。domain terminology alignment 没有顺手改 app code。第四每个 product task 都留下了 task outcome record。这让之后的 review 和 comparison 有了材料。对我来说这些不是最终结论。但它们是可以继续追踪的信号。这次也暴露了 measurement 本身的问题这次 tracking 也暴露了几个问题。第一个是 human rework 没有记录。report 里写的是Human rework minutes: Unknown这比写 0 更诚实。因为没有测量就不能假装没有成本。下一次如果要认真比较就应该记录 reviewer 花了多少时间。第二个是 prompt reference 不够稳定。report 里有 prompt refs但 prompt text 和 prompt hash 没有作为稳定 artifact 保存。这会影响之后判断两次 run 是否真的可比较。第三个是 sample size 太小。一个 PR、三个任务只能作为初始 benchmark。不能拿来做大结论。所以下一步应该继续记录更多 PR而不是急着宣传结果。我现在会怎么写 effectiveness claim以前我可能会写harness-starter-kit 提高了 agent effectiveness。现在我不会这样写。我更愿意写在 TodayBus PR #2 里harness 帮我记录了 3 个 product-task outcomes。这 3 个任务中没有观察到 wrong-file edits 或 repeated known mistakesfirst-pass verification 是 3/3。但因为没有 baseline、样本很小、human rework 未测量所以这只是 initial benchmark不是 effectiveness improvement proof。这句话比较长也没有那么像宣传文案。但它是我目前能负责任说的话。为什么这对我有意义我是初级开发者所以我很容易被“看起来自动化很多”的东西吸引。但 dogfood 之后我越来越觉得真正重要的不是让数字看起来漂亮。而是让自己知道哪些证据可以支持哪些结论。Harness Doctor分数高只能说明 repo 里的 harness evidence 比较完整。不能说明 agent 真的少犯错。一次 PR 顺利也不能说明 harness 已经有效。但如果每次 PR 都留下 task outcome慢慢就能看到趋势。这就是我现在觉得harness-starter-kit有价值的地方。它不是魔法。它也不是一个安装后就结束的工具。它更像是在问这次 agent task 的边界是什么实际改动有没有越界已知 failure 有没有重复哪个 check 跑了哪个 check 没跑这次结果以后还能不能比较这些问题本身就会让 agent workflow 更可维护。下一步接下来我想继续做几件事。第一继续用 TodayBus 记录接下来的 3 到 5 个 product task。尤其是外部 API、planner logic、UI copy、domain docs 这几类任务。第二开始记录 human rework minutes。哪怕只是 approximate也比 unknown 更有用。第三保存更稳定的 prompt reference。比如 prompt text、prompt hash或者至少更清楚的 prompt summary。第四把 effectiveness report 和 task outcome template 继续打磨。避免 setup run、adoption run、product task 混在一起。第五继续区分两个概念harness health ! agent effectiveness前者可以通过 Doctor 和 drift checks 看。后者必须通过真实任务 outcome 观察。项目链接GitHub:https://github.com/baskduf/harness-starter-kit如果你也在用 Cursor / Claude Code / Codex 这类 coding agent并且也想知道“repo 里的规则和检查到底有没有帮助 agent 工作”我觉得可以从一个很小的地方开始不要先证明效果。先记录下一次 PR 里 agent 实际做了什么。因为没有记录就没有比较。没有比较就很容易只剩下感觉。