改一版、跑一遍、翻报告、猜是哪一步没对、回去再改，再跑一遍。这个循环我一周要转几十次，转到后来手指比脑子快，脑子已经懒得转了。
上周一 arXiv 上挂了一篇 HLSClaw 的论文，八个人做的，编号 2611.02784，主分类挂在机器学习下面，交叉分类到软件工程。HLS 我一行都不写，点进去纯粹是因为标题里有 vibe coding。看完的第一反应跟芯片没关系，是我自己那堆破脚本。
标题带 vibe coding 的论文今年多得数不过来，大部分就是把“让 LLM 改代码”换个说法。这篇不是。它先承认 LLM 智能体在普通软件开发里把 vibe coding 推起来了，然后直接指出：到了 HLS，效果明显往下掉。承认自己这套东西在哪儿不灵，这一点至少诚实。
它干的事一句话能说完：把 HLS 优化从一条写死的、固定顺序的变换流水线，重新说成一件“由 agent 按技能去调度”的事。论文里管这个叫 skill-based agentic harness。harness 这个词我一直翻不好，脚手架？套具？随便吧。但结构我一眼就认出来了——把每一步拆成有名字、能单独调用的技能，再让一个能看见反馈的调度器决定下一步叫哪个、要不要往回退。
它批评现状那两句也挺准。一类是启发式规则堆出来的，另一类是最近拿 LLM 辅助的流水线，这两类共同的毛病是“固定抽象层次”和“弱耦合”。换成我这边的说法：顺序是写死的，每一步只在自己的小圈子里调，谁也不看谁的结果。这病我太熟了。
前阵子我那条发版前检查，四十二行 bash，从头串到尾。第七步挂掉，后面全不跑；我想只跑最后三步看看，做不到；想删中间某一行，不敢，因为不记得那行是谁加的、删了会怎样。这条脚本我越写越不敢动，最后它变成了一段供起来、不敢碰的黑箱。
所以看到论文里把“技能”和“调度”这两件事拆开讲，我当天晚上就把那条 bash 拆了。
现在长这样：
.claude/skills/
bump-version/SKILL.md
changelog/SKILL.md
smoke-test/SKILL.md
每个文件头上就一小段：
---
name: smoke-test
description: 发版前跑冒烟，只在 src/ 下有改动时值得跑
---
正文三行：跑哪条命令、挂了把哪段日志贴回来、别自己重试。⚡这一下，变的不是速度——是我可以只跑第四个。以前改一行文案，也得等前六步陪跑完，现在点一下就到，爽！
技能本身没什么新鲜的，斜杠命令、脚本、Makefile 里的一个 target，本质都是“一个有名字的动作”。新鲜的是论文的另一半：反馈驱动的编排器。它不按 1 到 7 死排，而是看着上一步的结果决定下一步叫谁，还能在“改代码结构”和“搜指令参数”这两个空间里来回跳。这一半我完全没有，我拆完技能，还是老老实实按顺序硬排。
这里我得回来改个口。上个月我还跟人说，把重复动作串成一条脚本最省事，串得越长越省。现在收回一半：串得越长，你越不敢改它，等你已经记不清中间那段 if 是防什么的时候，它就不再是自动化，是负债。
然后是频率。别什么都做成技能。一天用不到一次的动作，写成 SKILL.md 就是给自己攒债——三个月后你打开目录，看见一个叫 fix-that-thing 的，完全想不起来它修的是什么，只好留着继续吃灰。这跟给一天按一次的操作绑快捷键是一个道理，键位记不住，还占着你的肌肉记忆。
论文里那个 39.12 倍的几何平均延迟加速，我没复现，也不打算复现，跑基准不是我的活，我也没那套 HLS 环境。相对 ScaleHLS 是 1.98 倍，比 Claude Code 高 1.86 倍，比 Codex 高 1.70 倍。这些数字是论文的，信不信你自己判断。我能确认的只有我这边的事：这套结构放到发版流程里，这周用下来是真的顺！顺在“只跑需要的那一步”，不在快多少倍。
有一类场景这招不灵，老实说：步骤之间强依赖、错一步后面全废的，硬拆成技能反而多出组装成本，还得额外维护“谁该先跑”。这种流程老老实实一条脚本串着，比拆开省心。
拆这五个技能花了大概四十分钟，大头花在想清楚“哪几步其实是独立的”上面，写文件本身没花几分钟。四十分钟换一个以后改流程不用从头读整条脚本，我觉得回本了，但也就到这儿，不敢吹更多。
你们要是有把技能和调度器玩得更顺的写法，教教我，抄的地方留给你们。