【免费下载链接】openbotA local-first desktop workspace for persistent AI teammates. Run Codex, Claude, and Grok with dedicated workspaces, task queues, file sharing, browser control, and agent-to-agent collaboration.项目地址https://gitcode.com/GitHub_Trending/openbo/openbot点击查看免费下载Hillclimb 是 OpenBot 生产目录中 pstack 技能包poteto-mode的一个 playbook专门处理“围绕一个可度量指标做持续迭代改进”这类任务。它不是一次性修 bug而是一套带决策日志、可复现度量、逐次验证的工程循环。读完本文你能完整掌握该 playbook 的八个步骤、每一步背后的原理技能支撑并能直接复用仓库里现成的dev:bench度量设施作为自己的 harness 起点。Hillclimb 在 poteto-mode 中的定位poteto-mode是一个“模式型”技能mode: true它本身不直接干活而是把任务路由到对应的 playbook。在 SKILL.md 的 playbook 清单里三个容易混淆的条目正好构成了一个梯度Playbook适用场景交付物Bug fix已报告的缺陷需要先复现再定位根因修复 运行期证据Perf issue一次性的“这里慢”对着基线追踪并改善基线数 → 修复数 差值Hillclimb针对某个指标、某个目标做持续的科学式改进循环假设 前后测量 决策日志 每个胜出一次提交清单原文对 Hillclimb 的描述是“Sustained, scientific improvement of one metric against a target: loop hypotheses with before/after measurement, a decision log, and one commit per accepted win. Distinct from Perf issue, which is a one-off fix.”而 hillclimb.md 开篇就划清了责任边界You own the metric and the experiments integrity. Supervise and review. Delegate the attempts.也就是说主线程不写实现代码它负责三件事定义指标与停止条件、维护测量的可信度、审查下属 agent 的 diff。真正的改动交给 subagent。核心纪律只有一句话原文第 5 行One change, one measurement, keep or revert. Never stack untested changes, and never claim a win from code inspection.一次改动、一次测量、保留或回滚。绝不叠加未验证的改动也绝不靠“读代码觉得快了”来宣布胜利。后半句直接引用了 principle-prove-it-works验证必须针对真实产物而不是代理指标、自我报告或“能编译”。触发条件与前置判断从 SKILL.md 的 Non-negotiables 段落能看出进入 Hillclimb 前通常已经触发了几个前置条件非平凡改动或架构判断 → 先跑how技能建立架构模型即将就“哪种方案更好”向人提问 → 先分类如果答案是可以通过运行观察的事实行为、耗时、布局、输出、性能甚至“某个 eval 是否能把两种情况区分开”那就不该由人来拍板要跑 benchmark、自测性能、报告加速或回归 → 报告或依据数字行动前必须先过benchmark-checklist技能。这三条正好构成 Hillclimb 步骤 1 与步骤 2 的入口。步骤 1先落地 workload 与架构再选指标原文第 7 行要求三件事顺序不能颠倒。第一用 how 技能跑一遍目标。how/SKILL.md 规定复杂问题拆成 2 到 4 个探索角度每个角度一个只读的generalPurposesubagent 并行探索随后由一个 explainer 汇总简单问题单模块、小工具、窄问题不再分层直接一个 explainer 一次跑完。输出段落固定为 Overview、Key Concepts、How It Works、Where Things Live、Gotchas不适用的段可省略。这一步不是形式主义。Hillclimb 后面的每个假设都要“锚定在第 1 步的架构模型上”步骤 4 原文没有这个模型假设就只能退化成“试试加个缓存”。第二命名能真正撬动结果的工作负载维度。原文点名了四类数据规模data size、历史长度history、状态量、并发度concurrency。这些维度决定了你的复现用例长什么样。第三选定能复现用户抱怨的用例。原文给了一条硬性否决If no case reproduces it, fix the repro instead of hillclimbing.如果你造不出能复现症状的用例正确的下一步是修这个复现而不是开始爬山。这条与 principle-prove-it-works 一致“When verification fails, suspect the observation method before suspecting the system.”然后才定义三件套一个指标不是一组哪个方向算更好上升还是下降可检查的停止谓词且必须同时包含“目标值”和“最少尝试次数下限”。原文给的示例形状是at least 50% better than baseline and at least 10 iterations为什么要给尝试次数加下限因为一个幸运的早期胜出不该提前结束整轮爬坡。只写“提升 50% 就停”第一次碰巧命中就收工你既没学到机制也不知道这是不是噪声。加了“至少 10 次迭代”谓词才同时约束了效果与证据量。最后一句是优先级规则用户给了数字就用用户的数字没给就先和用户对齐数字。步骤 2建度量 harness证明它灵敏然后冻结这是整个 playbook 里技术含量最高的一步原文第 8 行把它拆成四段。2.1 先证明 harness 有分辨力Run contrasting realistic workloads and confirm the target case reproduces the symptom while easier cases separate as expected. If the harness cannot distinguish them, revise the workload or metric.注意顺序不是先测基线而是先确认 harness 能把“有症状的用例”和“明显更轻松的用例”区分开。如果区分不开要改的是 workload 或指标不是被测代码。2.2 冻结前用 benchmark-checklist 体检benchmark-checklist 的七个问题就是这一步的体检表。它要求先用“你会写进 PR 的那句话”把预期结论写下来让这些问题去检验这句话。#问题要回答什么常见陷阱1Why not double?命名限速因素limiter并把它映射到源码热点压测机自己先饱和你测的是压测机优化没动数字说明 limiter 没找对2Was it tuned?两侧都按生产配置跑release 构建、生产 flag、批处理/事务设置、连接池、缓存冷热、同版本同数据一侧跑默认配置你比较的是配置而不是实现3Did it break limits?做算术字节/秒对磁盘与网络带宽ops × 单次成本对核数省下的时间对被测片段的耗时占比去掉只占 10% 的片段最多快约 11%超出上限说明测到了缓存、no-op 或 bug4Did it error?统计失败数与非成功响应数并校验输出正确而非仅仅存在拒绝通常很快超时与重试很慢不数错误就会把失败当加速5Does it reproduce?每侧至少 5 次交替 A/B 跑报中位数与区间差值小于波动区间就是“无可测差异”接近时用 rank-sum 检验6Does it matter?微基准旁边必须测用户实际等待的端到端路径并把微结果报为整体占比1% 的辅助函数再快也只能让请求快 1%7Did it even happen?确认工作在计时区间内真的发生了请求到达、行写入、字节读出、结果被使用惰性生成器、未被 await 的 Promise、被 JIT 丢弃的结果、超时还有两条运行前检查值得照做用uptime看负载、nproc看核数如果机器忙且停不下来就让两侧交替跑使它们吃到同样的噪声并在报告中写明。报告格式也有硬要求先给判决faster / slower / no measurable difference / inconclusive再给数字、单位、运行次数、区间与 limiter。示例p50 41 ms → 33 ms, median of 7 runs per side, range 32 to 35 ms after, bound by JSON parsing on one core.如果“声称有差异但说不出 limiter”“某一侧没调优”“问题 4 和 7 无法检查”判决必须写成 inconclusive并点明缺口。2.3 冻结并让 harness 自己打印错误数与工作量原文的两条要求非常具体冻结之后一条可重复的命令就能输出指标采样要足够多以压过噪声即median of N而不是单次运行harness 要打印错误计数和已完成工作量的计数。后一条是把 checklist 的问题 4 与问题 7 内置进工具。原文在 benchmark-checklist 里解释了收益Vet theHillclimbplaybooks harness before it is frozen. The frozen harness then prints error and work counts, so each keep-or-revert checks questions 4 and 7 for free.也就是说冻结之后每一次“保留还是回滚”的判断自动完成了“有没有出错”和“工作是否真的发生”这两项核查不需要额外成本。从工具形态上讲这就是 principle-build-the-lever 的应用不要手工做造出做这件事或证明这件事的工具codemod、脚本、生成器工具才是 reviewer 可以重跑的产物。该原则还给了一条可自检的判据“Applying this principle produces a file. If you cited it and there is no codemod, script, generator, or delegate skill in the diff, you didnt apply it.”2.4 记录基线并让回归门禁先绿在任何改动之前必须完成两件事记录基线指标值记录回归门禁the tests that must keep passing的一次全绿运行。这里的“回归门禁”不是“全量测试”。OpenBot 仓库的 AGENTS.md 明确禁止在本地跑大范围检查因为它会压垮开发机新 worktree 先跑bun install --frozen-lockfile默认用bun run test:changed它只跑单 worker那些导入了你改动文件的 desktop 与 mobile 测试针对具名源文件用bun run test:related -- source单个测试文件用bun run test:desktop -- path类型检查一次只跑一个项目bun run typecheck:node、bun run typecheck:renderer或改动所在包的typecheck脚本不要跑bun run format用biome check --write --max-diagnosticsnone paths。因此在本仓库做 Hillclimb 时回归门禁应当定义为一小组窄范围、与改动路径直接相关、且每次都完全相同的测试命令。这与 playbook 的要求并不冲突门禁的关键是“固定且可重复”而不是“跑得多”。docs/development-checks.md 解释了这些命令的设计取舍包含 tsrs 与tsc的差异、CI 使用 tsrs 而 Windows 发布任务不做类型检查等前提。步骤 3打开决策日志原文第 9 行Open the decision log via the show-me-your-work skill. Adecision.tsv, one row per attempt: id, hypothesis, change, before, after, delta, tests, verdict (kept or reverted), note. Read it before each attempt. Keep it out of the tree (gitignored).这里有两个必须讲清的事实细节。其一列集与规范基线不同。show-me-your-work 定义的规范表头只有六列ts phase decision why evidence resulttsISO8601 时间戳phase阶段或工作流decision选了什么、做了什么一行why用平实语言写原因如果是某个原则驱动的就把话说白不要只贴术语标签evidence能证明它的链接或路径commit SHA、PR 号、file:line、产物或截图路径绝不写整段散文result结果或谓词状态如tests green、reverted、pixel-diff 0、INCONCLUSIVE、open。而 hillclimb 要求的实验列是 id / hypothesis / change / before / after / delta / tests / verdict / note。两者可以调和把六列作为骨架实验字段编码进decision假设与改动、evidence前后数字与产物路径、resultkept / reverted 与门禁状态。这是从两份文档推导出的实践建议不是原文的强制规定实际使用时以你所在团队选定的表头为准并保持全程一致。其二文件名有单复数差异。playbook 写decision.tsvshow-me-your-work 写decisions.tsv其他 playbook如 orchestrate.md 与 autopilot 系列用的是decisions.tsv。按 show-me-your-work 的说法其他技能应当“引用它并让该技能拥有格式”所以选decisions.tsv与仓库其余部分更一致。用脚本写行而不是手拼 TSVlog.sh 是一个六参数的追加脚本log.sh logfile phase decision why evidence result它做了四件容易被手写漏掉的事源码 L21-L41文件为空时先写表头用而非网络盘上的存在性判断失败最多多一行表头而不是丢掉数据用date -u %Y-%m-%dT%H:%M:%SZ盖 UTC 时间戳把单元格里的 Tab、换行、CR 替换成空格保证单元格单行对首字符是、、-、的单元格前置单引号防止在表格软件里被当成公式执行注释明确说这条是为“攻击者可控的 evidence 字段”准备的。模板文件只有一行表头见 decision-log-template.tsv。放置位置默认是工作产物而非提交物放在工作目录的decisions.tsv多线并行时放到.audit/task-slug.tsv并加入 gitignore。只有当日志本身是“让 reviewer 相信结论”的必要证据时才提交。三条规则只追加写错的判断用新行取代绝不编辑或删除历史优先使用已提交脚本产出的证据而不是手工一次性产物每次尝试前先读日志。步骤 4假设必须命名机制原文第 10 行对假设的质量给了可判定的标准names a specific mechanism (defer X off the boot path because it blocks first paint), not try memoizing something“因为 X 阻塞了首屏绘制所以把 X 推迟出启动路径”是假设“试试加个记忆化”不是。对性能类指标原文要求按 perf-issue.md 第 2 步的性能口诀排序但只借用顺序不借用那一步的停止规则Dont do it.停掉结果没人用的工作而不是把它变便宜。Do it, but dont do it again.不重复做。Do it less.少做。Do it later.晚点做。Do it when theyre not looking.在没人看的时候做。Do it concurrently.并发做。Do it cheaper.做得更便宜。顺序即代价顺序越靠前的口诀通常越彻底、越不引入复杂度和并发风险。原文在 perf-issue 里还有一句“When an earlier mantra meets the target, stop.” 但 hillclimb 明确排除这条停止规则因为 hillclimb 的目标是持续改进而非一次性达标。步骤 5循环体一次迭代一个假设原文第 11 至 16 行把循环体固化成四项动作。5.1 把改动派给 subagent使用你配置的 hillclimb 模型默认grok-4.7-xhigh-fast给出紧致的作用域你的工作是监督与审查 diff而不是自己敲代码理由引用了 principle-guard-the-context-window把体量大的输出路由给 subagent主线程只保留摘要。当多个独立假设同时成立时扇出到并行 subagent每个都在自己的 worktree 里依据是 principle-separate-before-serializing-shared-state并发方可能写同一个文件、分支、键或对象时先消除共享只有当“单一共享写目标”是真正的不变量时才用锁文件、串行阶段或单写者去结构化地串行化。模型选择来自 setup-pstack。该技能把每个角色的模型写进~/.cursor/rules/pstack-models.mdcalwaysApply: true其中就有一行# budget: large (xhigh) hillclimb: grok-4.7-xhigh-fast预算标签会改写 slug 末端的思考强度 tokenmaxxhighhighmediumlowunlimited把claude-opus-5-5-xhigh变成-maxsmall把它变成-medium。Grok 系列上限是xhigh所以在unlimited下grok-4.7-xhigh-fast保持不变。角色值写成inherit-parent或auto时该角色跑在父会话模型上即省略 Task 的model参数。每次重跑该技能都会整文件覆写保证幂等。5.2 用冻结的 harness 测前后并跑回归门禁测量必须使用步骤 2 冻结的同一套 harness且门禁必须保持绿。这里有个容易被忽略的配套原则principle-sequence-verifiable-units 把每次改动定义为一个“前后括号”——已知良好状态、一次改动、跑检查、再前进。它同时给了交付侧的规范形状“先写失败测试再在其上放修复”其他叙事顺序还包括“先做减法再重塑”“先采基线再做处理”“先搭脚手架再做功能”。5.3 只接受越过噪声的改动Accept only when the metric moves past noise and the gate stays green. Otherwise revert the change in full. A tweak that might help is not kept.“越过噪声”的判定标准就在 benchmark-checklist 的问题 5差值小于 Run-to-Run 波动就是无可测差异接近时用 rank-sum 检验或 harness 自带统计。“A tweak that might help is not kept” 这条会与工程直觉冲突加一层缓存、加个 memo看起来无害。原文的立场是无法测量的改动就是污染了后续所有测量的噪声源必须整份回滚而不是“留着看看”。5.4 每个被接受的修复一次提交一次被接受的修复 一次提交只暂存你改过的文件git add files绝不git add -A无论保留还是回滚都要写一行日志。每个迭代在下一个开始前以一次检查收尾principle-sequence-verifiable-units。如果整轮是无人值守的原文允许借用 autonomous-run.md 的唤醒机制但不要借用它的停止规则有可观察事件CI、合并、某个 ref 前进→ 用 watcher subagent 在事件发生时唤醒长周期心跳作兜底无可观察事件 → 用固定间隔心跳间隔按“结果何时值得重新检查”来定。停止规则的差异要点在于autonomous-run 的第 6 步是“谓词满足即停平台期不是停止理由”hillclimb 的第 7 步额外允许“剩余想法边际收益低于成本”时停止。两者不可混用。步骤 6越过第一个平台期原文第 17 行列出平台期的应对手段并给了一条价值排序On a stall, several rejects in a row, pivot category, combine near-misses, re-read the source, or try something more radical before concluding the hill is climbed. Correctness and simplicity outrank the number.换类别始终在同一类口诀里打转往往说明第 4 步的假设排序已经耗尽合并“差一点”的方案单个未过噪声的改动组合后可能过线重读源码对应 checklist 的问题 1limiter 映射错了后面所有假设都建立错的前提下试更激进的做法在宣布“山已经爬完”之前。最后一句是硬约束正确性与简单性优先于数字。具体到操作有两条一个赢了数字但破坏了行为的改动回滚一个保持数字不变的简化保留。依据是 principle-laziness-protocol最小 diff 优先于“优雅”样板同一个决定不要在多处重复。这条规则在真实仓库里是可执行的因为 benchmark-checklist 要求统计错误数并校验输出正确性。数字好看但错误数上升就是这个场景的典型信号。步骤 7停止条件原文第 18 行Stop when the predicate is met, or when the remaining ideas are marginal and not worth their cost. Dont relax the predicate to meet it, and dont quit while cheap untried hypotheses remain. If you are stuck, surface it instead of spinning.拆成四条可执行判断谓词满足 → 停剩余想法边际收益不抵成本 → 停绝不放宽谓词去“达成”它这条与 autonomous-run 的“never relax the predicate to declare victory”同源还有便宜且未试的假设时不许退真的卡住就上报而不是空转。步骤 8开 PR原文第 19 行RunOpening a PRwith the accepted commits stacked in the order they landed.也就是说被接受的提交按落地顺序堆叠成一个 stack而不是压成一个巨大的 commit。opening-a-pr.md 的要点如下。标题Conventional Commits 形式type(scope): subject句尾不加句号type 用feat、fix、docs、refactor、test、chore、perfscope 是区域名如pstacksubject 短、祈使语气当某个真实符号承载了改动时把它写进 subject。描述一段“一分钟简报”给手上有 diff 的 reviewer 看。用##标题按此顺序没内容的段直接删掉段落内容## Why问题与方法1 至 3 个短句不写 SHA、rebase 家谱或“基于 main”## What changed1 至 3 个短条目只在符号/路径承载改动时才点名重命名要写两侧## Scope必写。覆盖什么、刻意不覆盖什么后续项、已知缺口## Tradeoffs只写 reviewer 会追问的被否方案没有真实取舍就删掉## Blast Radius1 至 2 句影响谁/什么为何安全或为何有风险## Verification1 至 3 条真实运行路径与结果。性能类给一个主数字带单位、before → after其余证据放链接产物规模与堆叠宁可五个窄 PR不要一个巨型 PR。stack 是一条 base 分支链根 PR 指向主干每个子分支 rebase 到父分支的确切 tip其 PR 指向父分支gh pr create --base parent-branch重定向用gh pr edit pr --base parent-branch。就绪状态一律以 ready 打开绝不开成 draft。不要自动 babysit开 PR 不等于开始盯 PR。先把整轮或整个 stack 建完只有用户明确要求时才单独跑一轮 babysit。用 OpenBot 的dev:bench当现成的重型 harness仓库里已经有一套与 hillclimb 要求高度同构的度量设施bun run dev:bench对应tsx scripts/dev-automation/bench.ts见 package.json。它不是为 pstack 写的但它的设计刚好示范了“冻结的 harness 该长什么样”。命令与参数bench.ts 的用法行bun run dev:bench --scenarioid|prefix|all [--runsn] [--labelname] [--comparereport.json] [--cpu-profile] [--frames] [--call-counts]参数取值与默认含义--scenario必填all、逗号分隔的 id 或前缀前缀匹配规则是scenario.id name或scenario.id.startsWith(name -)无匹配会报错并列出已知 id--runs默认3整数 1 至 20每个场景的重复次数多轮归约为中位数与区间--label默认当前 ISO 时间戳把:与.换成-只允许字母、数字、点、短横线、下划线--compare一份此前的报告 JSON 路径读取并校验报告结构不合格直接报错--cpu-profile布尔场景稳定后录 15 秒窗口的 renderer cpuprofile仅首轮--frames布尔统计动画帧请求速率--call-counts布尔输出顶层函数调用计数仅首轮产物与可重跑性报告写到.openbot-build/dev-automation/bench/label.json带每次 run 明细的完整报告每个场景结束后就落盘一次所以长跑在后期失败也能保住已测到的部分label.md人读版表格label.compare.md与基线比较的差值表传了--compare时。这正是 principle-build-the-lever 说的“reviewer 可以重跑的产物”。中位数与区间是内建语义bench-stats.ts 的median与spread返回{ median, min, max }summarizeRuns对 peak / mean / settled 三种统计各归约一次。表格渲染时首行就写明样本量与单位约定L266-L2833 run(s). Median (min–max). MB for rss/heap, % of one core for cpu.这直接对应 benchmark-checklist 的问题 5报中位数与区间而不是单次跑。比较只取中位数因为波动区间才是判断差值是否为噪声的依据L305-L331当 before 为 0 时百分比记作null并渲染成–避免除零伪造出天文数字。错误计数与工作量计数被写进 settled 读数这是最能对应“harness 要打印错误数与工作量”的实现细节。在 bench.ts监听页面的consoleerror 与pageerror把消息塞进pageErrorssettled 里写入errors.page: pageErrors.length同时写入frames.requestsPerSecond由ANIMATION_FRAME_REQUESTS求值注释解释了这个计数的必要性“A render error can leave the window empty, which reads as a large saving.”渲染错误会让窗口空白看起来像省了一大笔这正是 checklist 问题 4 与问题 7 的落地形态加速数字旁边永远有一个错误计数空白窗口会被识别成破损运行而不是巨大优化。headline 指标表里还有render.calls、render.longTasks、render.longTaskMs、render.framesOver17ms、render.framesOver50ms、render.layouts、render.styleRecalcs等工作量类指标HEADLINE_METRICS让你能看见“工作到底做没做”。场景设计harness 的自检排在最前bench-scenarios.ts 里的场景 id 有一套按维度组织的命名维度场景 id 示例自检s0-smoke展示种子空闲 20 秒冷启与空闲s1-cold-empty、s2-idle-visible、s2-idle-closed、s2-idle-minimized规模s3-scaled-small10 agents × 200 消息、s3-scaled-large50 agents × 2000 消息5 channels × 1000 消息历史长度s4-long-chat2000 条消息的会话滚到顶再回来再切换 10 个 agent并发与流式s5-stream-provider、s6-parallel-provider-count生命周期s7-release-claude空闲释放阈值 10 分钟、s8-soak协作面s9-channel、s10-browser-count其他子系统s11-computer-use、s12-island-on/s12-island-off、s13-imagess0-smoke的说明是 “Harness check: showcase seed, idle 20 s”它把“harness 能否跑通并给出可解释读数”作为第一个场景——这就是步骤 2 里“证明 harness 有分辨力”的工程化表达。而s12-island-on/s12-island-off这类成对场景正是“对比真实负载、确认目标用例复现症状、更容易的用例按预期分开”的现成模板。隔离与共享状态三个隔离设计值得抄独立 profilebench 用由本 worktree 路径哈希派生出的独立实例 iddevelopmentInstanceIdForWorktree(${PROJECT_ROOT}#bench)注释写明“a bench never seeds over the isolated dev profile of this worktree”复用已登录会话reseed 时保留加密的openbot-central-auth-v1.bin让每次 run 像回访用户那样打开工作区避免在计测窗口内做登录只动自己的进程组文件头注释声明它只碰 bench profile 和它启动的进程组绝不触及 dev 实例、其他 worktree 或开发者自己的 profile。这三条合起来就是 principle-separate-before-serializing-shared-state 的“先消除共享再谈串行化”。并行 subagent 各自在自己的 worktree 跑 bench正是同一思路在 agent 层的复用。一个必须写进报告的成本提示bench-scenarios.ts的文件头注释说明turn 类场景跑真实的claude、opencode、grokCLI因此会消耗开发者自己的模型配额且从不启动 Codex。如果你的 hillclimb 假设需要这类场景这既是成本约束也是“工作负载必须贴近真实用户路径”的代价。把它写进日志的 note 列别让下一轮的人重新踩一遍。把“回复”写成可审计的交付摘要原文第 21 行要求回复必须包含指标与目标从基线到终值的百分比变化迭代次数保留 vs 回滚每个被接受的修复各占一行decision.tsv的路径如果继续推进你会试的下一个最好的想法。这六项与 show-me-your-work 的收尾流程配套交回之前要用本次运行的 transcript 审计日志每一行是否对应真实决策或动作、evidence 指针是否可解析并确实指向所声称的内容、有没有影响工作但未记录的岔路审计只修正日志、绝不修改或删除历史行再用不同模型家族的 subagent 做一次跨模型复核并在回复末尾附一个 Attention 段首行写reviewed by model。同时poteto-mode的 Non-negotiables 还要求在回复中点出每一个影响了决策的原则以及它具体改变了哪个选择且只能引用你本次会话中真正读过其 leaf SKILL.md 的原则。这条规则直接约束了本文的引用方式凡是提到某个原则技能读者都应当去读对应目录下的SKILL.md例如 principle-prove-it-works、principle-guard-the-context-window。常见失败模式对照表现象违反了哪一步正确做法复现不出用户抱怨就开始优化步骤 1先修复现用例一次迭代里塞了三个改动步骤 5 核心纪律拆成三个假设各自测量声称更快但说不出 limiterchecklist 问题 1判决写 inconclusive补 profiling只跑一次就下结论checklist 问题 5 / 步骤 2每侧至少 5 次交替跑报中位数与区间压测一侧跑默认配置checklist 问题 2两侧都按生产配置或不要从那轮里选赢家数字很好看但错误数上升checklist 问题 4视为破损运行整份回滚加速来自“什么都没做”checklist 问题 7在计时区间内校验工作量计数早期幸运胜出结束整轮步骤 1 谓词设计目标值 最少尝试次数下限只写“试试 memoize”步骤 4命名机制“把 X 移出启动路径因为它在阻塞首屏”放宽谓词来宣布成功步骤 7上报卡住而不是改判据用git add -A提交步骤 5git add files一个修复一次提交多个 subagent 在同一 worktree 并行步骤 5 共享状态原则每个假设一个 worktree日志里 evidence 写成品段散文show-me-your-work 格式写 commit SHA、PR 号、file:line或产物路径结语式的落地顺序如果你今天就要在 OpenBot 仓库里跑第一次 Hillclimb最小可行路径是用how建架构模型从dev:bench的场景 id 里挑一个能复现抱怨的用bun run dev:bench --scenarioid --runs5 --labelbaseline记录基线同时按 AGENTS.md 的窄范围规则跑一次回归门禁并记下全绿用log.sh开decisions.tsv每行一次尝试一次一个假设交给配置好的hillclimb模型 subagent在独立 worktree 里改用同一条冻结命令测前后--compare生成差值表错误计数与门禁状态一起看过噪声就git add files提交否则整份回滚并记一行每个被接受的修复按落地顺序堆叠最后按Opening a PR的六段式写描述Verification 只放一个主数字加before → after。这套流程的价值不在“更快”而在“可验证”每一个被保留的改动都有一条可重跑的命令、一个错误计数、一次全绿门禁和一行日志作为依据。赞分享【免费下载链接】openbotA local-first desktop workspace for persistent AI teammates. Run Codex, Claude, and Grok with dedicated workspaces, task queues, file sharing, browser control, and agent-to-agent collaboration.项目地址https://gitcode.com/GitHub_Trending/openbo/openbot点击查看免费下载相关推荐DLSS Swapper 免费 DLSS 版本切换指南不等游戏更新自由切换 DLSS、FSR、XeSS 版本DLSS Swapper 免费 DLSS 版本切换指南不等游戏更新自由切换 DLSS、FSR、XeSS 版本 DLSS Swapper 是一款面向 Wind桌面应用游戏开发OpenBot pstack Bug fix 实战指南用运行时证据驱动的六步缺陷修复流程OpenBot pstack Bug fix 实战指南用运行时证据驱动的六步缺陷修复流程 本文以 OpenBot 生产目录中 pstack 技能包的 BugOpenBot Marketplace 中的 pstack Autonomous run 实战用可判定谓词驱动无人值守的自主执行OpenBot Marketplace 中的 pstack Autonomous run 实战用可判定谓词驱动无人值守的自主执行 Autonomous run上一篇告别信息孤岛FastGPT如何重塑远程团队协作与知识管理下一篇LiteLLM终极性能基准测试指南负载测试与容量规划完全解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考