他让AI给项目起名，7轮聊出个新域名

给项目起名这件事，能把人逼到什么程度？有位开发者干脆承认：自己起名烂到家，每个项目最后都顶着个占位名。想认真想一个好名字，往往耗掉大把时间，结果还是不满意。

于是他做了个工具，让一群AI代理替他想名字。最近他把整个应用跑在自己的代码仓库上，让这个工具给自己改名——聊了7轮，原来的 Nammit 变成了 namematch（全小写），域名是 namematch.tech。

名字是聊出来的，不是一次生成的

第一轮给出的名字非常直白，之后开始往造词方向走，再往后他稍微把方向拨向"两个词拼起来、念着顺、接上 .tech 好听"的组合。到第7轮，工具递过来 NamePicker、NameFinder、NameChoice、NameSelect 和 NameMatch，每一个都配着一个可注册的免费 .tech 域名。

他坦言自己引导了很多。而这正是对话式流程的意义所在：不是等一个完美答案掉下来，而是一轮轮把方向拧过去。

代理分工，域名查询交给普通代码

整套系统里，工作流负责决定步骤，代理负责做创意判断。他没有让代理之间互相调用，理由是普通的工作流代码更可预测，而且他不确定 Gemma 在多步工具调用上有多可靠。

• Gemma 4 31B 负责 Supervisor 和 Feedback 代理
• Gemma 4 26B 负责起名代理和域名检查，因为它更快
• 每个代理返回的 JSON 都用 zod 校验，出错重试一次
• 域名检查其实不是代理，是直接向注册局（RDAP）查询的普通代码，所以又快又准

其余部分是 Hono 服务器、React + Vite 前端，托管在 Render 上，用 Sentry 做链路追踪。

延迟的锅，一开始差点甩错人

第一次完整跑通后他就接上了 Sentry。每次运行都是一条 trace：工作流、每个代理、每次模型调用、每次域名查询，都能看到耗时、输入输出 token 数、错误和重试次数。成本一栏显示 $0，因为 Sentry 里 Gemma 没有定价，而他跑在免费额度上，所以改看 token。

修复前的数据很难看：生成名字要将近5分钟（4.65 到 4.82 分钟），消耗 16K 到 18K token；一轮反馈要 2 到 4 分钟；加上分析步骤，一轮起名总共 8 到 10 分钟。

拆开 trace 才看清问题在哪：起名代理每次调用要 1.35 到 1.80 分钟、4.2K 到 6.1K token，而名字本身只是几百 token 的 JSON，剩下的全花在"思考"上。域名检查代理更夸张，在一次反馈运行里花了 1.95 分钟和 5.6K token。真正做域名查询的那部分反而很轻，因为它是普通代码。

免费额度还时不时抛 500 错误，每一次都多加一次重试。他说得很直白：没有逐次调用的 token 统计，他大概会去怪谷歌，或者怪域名查询。

把"思考"关掉

Gemma 4 只接受两档思考设置：minimal（关）和 high（开，默认值），中间档会直接报错。在一次起名调用上，开思考是 79 秒、约 3300 个思考 token；关掉是 5 秒、零。

于是他把起名代理、域名检查、Supervisor 的分析步骤全部关掉思考；Supervisor 的规划和挑选、以及 Feedback 保留开启——关掉之后，弱名字会溜进来。

效果：起名代理降到 6.9 秒、727 token；域名检查约 3 秒、不到 500 token；反馈调用 1.2 分钟、2.2K token。最新几次运行没有报错。一轮起名从 8 到 10 分钟压到 2 到 5 分钟。

还慢的是 Supervisor，因为他坚持在那里保留思考。在一次生成后的 trace 里，它的规划和挑选占了 2.71 分钟中的 2.5 分钟；而在修复前的 trace 里，同样两步只花了 1.3 分钟。这是他主动做的取舍：慢一点，换更好的名字。

开放权重带来的另一条路

他跑在谷歌的免费额度上，代价是每分钟 token 有上限，早期运行老是失败，报"起名代理没想出任何名字"——重试全挤在同一个限流窗口里。解决办法就是按谷歌说的时长去等。

但权重是开放的，同一批代理也能用 Ollama 跑在自己机器上，没有上限。他明确说明：这个模式他还没测过，所以是"可能"，不是"已证实"。

域名查询用的是开放数据，RDAP 是注册局自己的公开查询，不需要 API key，也不用付费域名 API。他也提醒，托管版本会把项目描述发给谷歌的 API；如果不想让描述离开自己的机器，可以在本地用 Ollama 跑。

起名要花几小时思考，他宁愿把这些时间花在产品和代码质量上。不过他也承认这事不是瞬间完成：免费额度下一轮要一两分钟，一个好名字可能要聊上几轮。但跟代理聊天，总比盯着空白页、一个个手动查域名舒服得多。