「街名侦探」，和一个模型怎么都绕不开的老问题

周日上午十点，Jeff 发了一个他做的小项目：

「给大家一个好玩的小工具，探索自己家周边街道的名字背后有什么有意思的命名规律，例如鸟类、名人、航空、地理。」 —— Jeff

这就是 街名侦探 · 非标新西兰——输入地址，它把周边街道按命名主题分类讲给你听。Jeff 特意强调了一句隐私边界：「大家不用担心暴露门牌号码，网站不做收集，只做一些简单的统计。」

致敬一篇帖子

Arthur 一眼认出了这个题材：「我做过类似的研究，但是没想过自动化。」Jeff 的回应很直接——Arthur 之前发的帖子给了他灵感：「我这个是致敬你的帖子。」技术栈全部选的免费档：Google Places、Overpass 地图数据、维基百科、Gemini API。「为了全免费，只能到这了。」连 UI 风格都不是随便定的，Jeff 特意约束成了和自己小红书发帖一致的风格。

两种「用 AI 写代码」的路子

Tim 问了句所有做过东西的人都会问的问题——「这是你手搓的？」Jeff 的回答，是这场对话里信息量最密的一句：

「我只约束了 UI 风格，这个和小红书发帖的风格是一致的。我有一个多 agent 协同的治理 skill，然后让 codex 写的 PRD，cursor 接到开发任务开发的。」 —— Jeff

后来他补了一句更具体的分工：「UI 风格是我之前的 SKILL 约定的，代码是 CURSOR GROK4.6 开发的。」一条清晰的流水线——治理 skill 定风格，codex 写需求文档，cursor 接 Grok 4.6 写代码。

Tim 的路子完全是另一个方向：

「cursor 用下来感觉如何？之前用 claude 和 codex，发现太大局限了，后来自己在 opencode 里手搓，目标要实现 LLM 无关化。」 —— Tim

一个拥抱多 agent 编排、让不同工具各司其职；一个干脆自己动手，图的是不被任何一家模型锁死。没有谁对谁错，群里现在同时跑着这两种真实的工作方式。

一个说得挺熟悉的老问题

工具做完、玩得挺开心的时候，Jeff 顺手暴露了一个更值得记下来的细节：

「里面暴露出来 gemini 每次在回复相同街区的主题的时候使用了相同意思的不同文字，这就是那天讲座里面提到的一个问题——如何保证模型输出的一致性，很显然不一致，导致一个地方出现了不同的描述没有合并。」 —— Jeff

同一个街区，同一个主题，模型每次生成的描述意思一样、措辞不同——结果就是本该合并成一条的内容，被拆成了好几条重复项。这不是 Jeff 的工程问题，是几乎所有拿 LLM 批量生成结构化内容的人都会撞上的老问题：模型很会说话，但不擅长「每次说得一样」。