你的技术栈
你已经有的仓库,或者一个从零开始的
识别是捷径,从来不是门槛。标记文件我们认得的仓库,会白拿到它的安装、运行和校验三条命令;认不得的会被明确记为未识别,再由你自己的模型对着眼前这棵目录树把命令写出来。
01你的技术栈
你手上的仓库,或者从零开始的新项目。
下面这份清单是捷径,不是门槛。识别得出的技术栈,会直接拿到构建、测试和 lint 命令,不必问任何人;识别不出的会被明确记为未识别,再由你自己的模型来写这些命令。
- 你已经有的仓库
- 任何语言,包括没人愿意打开的那部分。我们读一遍目录树,能预置的命令就预置,并明说哪些是我们推断出来的。
- 清单之外的一切
- 记为未识别,而不是硬塞进最接近的一行。构建、测试和 lint 命令会针对你的仓库现写,而不是从表里读出来,并且运行记录会写明是哪一种。
- 从零开始的新项目
- 空仓库会用自家框架搭起来,调用的是该框架自己的生成器。我们不内置任何模板,也绝不会把已有的目录树改写成某个框架: 那是需要人来批准的变更,不是脚手架。
开箱即识别
- Bun
- Node
- Python
- Go
- Rust
- Ruby
- ultimate
这里没有一项要求技术栈被识别。识别清单只决定最初那几条命令是不是白送的。
一个仓库是怎么被接手的
靠标记文件识别
检测只读 checkout 的最顶层,不读别的: bun.lock, package.json, pyproject.toml, requirements.txt, setup.py, go.mod, Cargo.toml, Gemfile。越具体的标记越优先,所以 lockfile 和清单文件放在一起时由前者定行。不走网络拉取任何东西,也不从仓库名字去猜。
未识别不等于被拒绝
没有任何已知标记的目录树会被记为未识别,而不是硬塞进最接近的那一行。接下来由你自己的模型读一遍仓库,把三条命令写出来,运行记录会写明走的是哪一条路。
你的命令说了算
预置命令以脚本的形式落在仓库里,而每一次写入都不覆盖已有文件。你自己带的安装、运行或校验脚本原样保留,事后你改写的也就一直是你改写的那份。
命令为什么要紧
校验命令是 agent 用来证明自己那份 pull request 的东西,也是深度评审跑在 diff 上的东西。有三条真命令的仓库会被机器打分;一条都没有的,评审时就少了这道关。
清单是捷径,不是天花板
识别清单存在的意义,是让一个我们能机械地叫出名字的仓库,在问模型任何问题之前就已经有一道能跑的关。除此之外它什么都不决定。清单之外的仓库照样克隆、照样读、照样干活,也照样开 pull request;它失去的只是那三条白送的命令,而你自己的模型把三条都写出来,它就又拿回来了。这就是全部的附加条件,我们宁可把它印出来,也不愿意去卖一份我们并不维护的语言清单。
从零开始
只有一个自家框架
空仓库是调用自家框架自己的生成器搭起来的,而不是拷贝我们这边存的模板。我们不内置任何模板,所以你拿到的是该框架今天发布的版本,而不是一份过期的副本。
或者把自家结构用在你的栈上
在新仓库上指定另一个技术栈,它拿到的就是自家的仓库结构: Bun, Node, Python, Go, Rust, Ruby。清单之外的栈会被点名拒绝,理由写进记录,而不是默不作声地滑向一个空底座。
已有的目录树永远不会被改写
没有迁移命令,以后也不会有。把一个框架套到已经有代码的仓库上,是一次需要人来批准的重写,所以脚手架会点名拒绝它,而不是把它缩成一个看起来像成功的半成品。
让一支 AI 开发者团队开始干活 少维护。
带上你自己的密钥和机器,放一个 .dz/maintainer/maintainer.yml,剩下的交给循环去跑。全程可审计。目前为邀请制。