周六晚本来在刷 trending，刷到眼睛发涩，拐去 arXiv 的 cs.SE 新提交里划了两页。arXiv:2610.29890，标题里带着 GitHub Actions，手比脑子快，点进去了。10 月 21 号挂上去的，我 27 号晚上才刷到，中间这六天我刚好在给一个 side project 手写第三条几乎一模一样的 workflow。
一句话说清楚这期的主角：不问开发者"你想要什么 CI"，直接看他本机跑了什么，再把 workflow 给他写出来。叫 DynaCI。
先说它反对什么，这才是我点进去的原因。之前那批自动生成 CI 的工作——论文里点了 GH-WCOM 和 LLM4GW 两个——都要你先给点东西：一段自然语言描述，或者一个写了一半的 workflow。这个前提看着无害，其实是整条路最脆弱的地方。你得先知道有这么个功能存在，才描述得出来。矩阵构建、条件步骤、缓存 key 怎么拼——你让一个不熟 CI 语义的人去"描述需求"，他描述出来的必然是他已经会的那部分，那他还要你生成干什么。
DynaCI 把这个输入整个换掉了。它不问你，它 trace 你的本地环境：机器上装了什么、跑过哪些命令、依赖怎么装的、测试怎么起的。拿到这些运行时信息先按启发式拼一版出来，再拿 LLM 走检索增强一轮一轮往里修。
有点像装修。传统路子是给你发张问卷问想要什么风格，它是直接进你家量尺寸。问卷谁都会填，量出来的尺寸骗不了人。
成绩这块，50 个用 GitHub Actions 的 Python 项目，对着上面那两个比，BLEU 平均高 21.13%，F1 高 20.96%。我看到 BLEU 这个词的时候眉头是皱的——生成配置文件这种任务，n-gram 重叠率高不等于 workflow 跑得起来，这类指标在这类任务上一直是虚的。但它还报了个我更愿意信的：56% 的样本生成的 workflow 没有缺功能，剩下那部分需要人工补的量也比对照组少。翻译一下，一半不到的把握一次到位，另一半能省你一半事。这个诚实度我认，比"准确率 97%"那种好看数字踏实得多。
我留着疑问的地方，两条。
一条是样本。全是 Python，全是 GitHub Actions。现实里最烦的 CI 长什么样：monorepo 切来切去的路径过滤，矩阵构建里那几个只在特定版本上炸的组合，缓存和跨平台产物，还有"这个 job 只在打 tag 的时候跑"。你在本地 trace 得出来吗？我怀疑。本地环境里压根没有"tag"这回事。作者自己在结论里也只敢说运行时信息对 LLM 生成 CI 有实质帮助，没说问题解决了，这点克制我喜欢。
另一条是那 44%。要人工补，补成什么样、补多久，论文没细说。而"改一份 LLM 写出来的 YAML"和"从零写一份 YAML"，对熟手来说未必前者更省——改别人的东西要先把别人的思路读进来，这个成本不在论文的度量范围里。这条纯粹是我的偏见，没测过，先摆这儿。
顺带一个我自己没答案的疑问：现在还有多少人真在本机装依赖跑测试，不都在 devcontainer 或者远程容器里？trace 这件事在容器化的开发环境里还剩多少信息量，我不确定。刷着刷着想到这个，也没想出结论。
上手门槛这块我得老实说：没有 repo。摘要页翻到底，没找到代码链接，也没看到 artifact。所以门槛现在不是高不高的问题，是门还没开。这点必须写明白，别让人看完以为今晚就能装。按 cs.SE 的惯例，会议录了之后放代码是常事，也可能就这么放着不管了。挂观察名单，等。
适合谁：对 CI 语义半懂不懂、每次写 workflow 都要翻别人仓库抄一段的人；还有那些做项目脚手架和模板生成器的——把用户本地已经跑通的东西直接翻成 CI，比自己维护一套模板引擎靠谱得多。不适合谁：pipeline 已经成熟、有自家约定和缓存策略的团队。你让它 trace 一遍生成出来的东西，一定比你手上那份糙，抽象层级也不对，加了纯属负担。
——候选池里还压着一个从 docker history 反推 Dockerfile 的小工具，逻辑跟这篇是一路的：与其问你想要什么，不如看你已经做了什么。等它更稳一点下次讲。
等代码放出来，我打算把手上那个 side project 重新 trace 一遍，看它生成的跟我手写的那三条差多少。差得不多的话，我可能真把自己那份删了。能不能打，现在说太早，这只是一篇值得记一笔的论文。