namer

Namer

从语言、技术和平台维度生成、评估并验证名称。提供按排名排列的选项、可用性矩阵和可执行的后续步骤。

不用于注册域名、制定品牌策略或设计 Logo。不用于审查现有代码中的命名规范。

Dispatch

$ARGUMENTS	Action
<thing to name> (with optional flags)	命名 — 完整流程：简述 → 生成 → 筛选 → 检查 → 评分 → 排名
check <name> [name2...]	检查 — 仅进行可用性审查（跳过生成）
expand <name>	扩展 — 生成现有名称的变体／修改形式
compare <name1> vs <name2> [vs...]	比较 — 对指定名称进行并排评分
resume [# or keyword]	继续 — 加载之前的命名会话
list	列表 — 显示已保存的命名会话
preferences	偏好设置 — 显示累积的命名档案和记忆统计信息
Empty	示例库 — 显示示例及“你要为​​什么命名？”提示

Gallery (Empty Arguments)

#	Context	Example
1	CLI Tool	“我正在用 Rust 构建一个终端文件管理器”
2	SaaS Product	“用于代码审查的开发者效率工具”
3	OSS Library	“用于数据验证的 Python 库”
4	Startup	“AI 驱动的招聘平台”
5	Side Project	“周末项目——书签管理器”
6	Brand	“专注于开发者工具的设计工作室”

选择一个数字，描述你要命名的对象，或输入“guide me”。

Guided Intake

如果用户输入“guide me”，提出三个问题：

1. 你要为​​什么命名？“CLI 工具、SaaS 产品、OSS 库、初创公司、品牌，还是其他？”
2. 它有什么作用？“用一句话描述。”
3. 你希望呈现什么风格？“活泼、严肃、技术感、温暖、前卫、极简，或者描述你自己的风格。”

动态上下文分类

根据用户的描述自动检测。调整平台优先级和评分权重。

上下文信号	类别	主要平台	次要平台
"CLI tool", "command", "binary"	CLI 工具	GitHub、npm/PyPI/Crates、Homebrew、.dev	社交平台
"package", "library", "framework", "SDK"	开源软件库	GitHub、npm/PyPI/Crates、.dev/.io	社交平台
"app", "product", "startup", "SaaS"	产品	.com、X/Twitter、LinkedIn、GitHub	开发者注册平台
"company", "brand", "agency", "studio"	品牌	.com、X/Twitter、Instagram、LinkedIn、YouTube	开发者注册平台
"game", "content", "media", "community"	创意项目	.com、YouTube、TikTok、X/Twitter、Reddit、Discord	开发者注册平台
"open source", "OSS", "contrib"	开源项目	GitHub、npm/PyPI/Crates、.dev、Discord	社交平台
含义模糊	均衡	.com、GitHub、X/Twitter、npm/PyPI	其他所有平台

评分预设——每种上下文都采用不同的内在／外在维度权重，以及不同的内在／外在权重占比。完整权重表请参阅 references/scoring-rubric.md § Context Presets。主要区别：

• CLI 工具：内在／外在权重占比为 30/70——易于输入（30%）和注册平台（35%）在外在因素中占主导
• 品牌：占比为 50/50——语音特点（30%）和域名（35%）是首要考虑因素
• 个人项目：占比为 25/75——优先考虑可用性；易于输入（40%）和注册平台（20%）在外在因素中占主导

向用户展示分类结果和预设。用户可以通过 --style 覆盖预设，或手动调整权重。

核心工作流（6 个阶段）

阶段 -1：加载记忆（每个会话运行一次）

!uv run python scripts/memory.py load

如果存在记忆，则将其纳入会话：

• 原型偏好 → 调整阶段 1 的生成比例（例如，如果用户偏好引人联想的名称，则占 35%）
• 语音偏好／禁忌 → 将禁忌项加入阶段 1 的硬性筛选条件，并为偏好项增加软性评分
• 长度偏好 → 调整阶段 1 的长度限制
• 权重覆盖 → 预先填入阶段 3 的评分权重
• 上下文默认值 → 在阶段 0 简报中建议上下文（“上次你要给 CLI 工具命名——这次也一样吗？”）
• 灵感来源 → 在阶段 1 的生成中将其作为风格锚点
• 过去的选择 → 避免重新生成用户已选过的名称

如果没有记忆，则按常规流程继续。记忆仅起补充作用——即使缺少记忆，也绝不阻塞任何阶段。

阶段 0：简报（按顺序进行，交互式）

1. 解析命名对象、上下文和限制条件
2. 自动分类命名上下文 → 选择预设
3. 向用户展示分类结果和调整后的权重
4. 接受覆盖设置：--style、--thorough、手动调整权重
5. 接受灵感来源：“我喜欢像 Vercel、Stripe、Neon 这样的名字”

阶段 1：生成与筛选（内联、单轮）

加载 references/naming-strategies.md，了解命名原型的详情和声音象征指南。

跨 6 种命名原型生成 40-60 个候选项：

原型	描述	示例
虚构词	通过语音构造的新词	Kodak、Xerox、Hulu、Roku
隐喻迁移	来自其他领域的概念	Amazon、Safari、Slack、Rust
复合混成词	混成词、词素组合	Instagram、Pinterest、YouTube
古典词根	拉丁语、希腊语、梵语词源	Nike、Astra、Veritas、Lumen
意象片段	简短有力、抽象的感觉	Figma、Sumo、Neon、Zed
描述性创意词	含义明确且富有特色	Cloudflare、Datadog、Fastly

硬性筛选条件（二元通过/不通过，须在检查可用性之前执行）：

运行 !uv run python scripts/generate.py filter --input candidates.json 进行自动筛选，然后内联应用仅限 AI 的筛选条件：

1. 英语中的脏话／粗俗用语（脚本：generate.py filter）
2. 在全球前 10 大语言中的冒犯性含义（仅限 AI：使用 brave_web_search）
3. 与同类别前 1000 大品牌完全重名（仅限 AI：使用 brave_web_search）
4. 超出长度限制（产品名 15 个字符、CLI 8 个字符、库名 12 个字符）（脚本：generate.py filter）
5. 难以发音的辅音簇（脚本：generate.py filter）
6. 主流编程语言中的保留字（脚本：generate.py filter）
7. 含连字符／特殊字符（适用于包名）（脚本：generate.py filter）

对内在维度评分（语音、语义、易记性、形态灵活性、视觉质量）。使用 !uv run python scripts/generate.py analyze <name> 进行语音分析，为语音质量评分提供依据。选出前 20-25 个候选项进行可用性检查。

--thorough 模式：通过不同提示词运行多轮生成，提升多样性。

阶段 2：可用性全面检查（并行子代理）

加载 references/platform-checks.md，了解各平台的检查方法。

分派 4 个并行子代理，每个子代理检查其类别中的所有候选项：

子代理 A — 域名检查器：

• 通过 RDAP 检查 .com/.net：GET https://rdap.verisign.com/com/v1/domain/{name}.com → 404 = 可用
• 通过 brave_web_search 检查 .dev/.io/.ai/.app
• 价格：对前 5 个候选项使用 brave_web_search

子代理 B — 开发者注册表检查器（直接 API）：

• GitHub：GET https://api.github.com/users/{name} → 404 = 可用
• npm：GET https://registry.npmjs.org/{name} → 404 = 可用
• PyPI：GET https://pypi.org/pypi/{name}/json → 404 = 可用
• Crates：GET https://crates.io/api/v1/crates/{name} → 404 = 可用

子代理 C — 社交平台与用户名检查器：

• Reddit：GET https://www.reddit.com/api/username_available.json?user={name}
• Bluesky：AT Protocol 句柄解析
• X/Twitter、YouTube、Instagram、LinkedIn：使用 site: 前缀进行 brave_web_search

子代理 D — 冲突与独特性检查器：

• 搜索冲突结果量：brave_web_search '"{name}" software'
• 商标（--thorough）：brave_web_search "USPTO TESS {name}"

或者通过脚本运行确定性检查： !uv run python scripts/availability.py check-all candidate1 candidate2 ...

扩展规模：

• ≤10 个候选项：4 个并行子代理
• 11-25 个候选项：先用快速 .com RDAP 预筛选，再全面检查前 10-15 个
• --thorough：检查所有社交平台、商标和 Wikipedia

阶段 2.5：变体生成（有条件）

对于内在评分最高但未通过可用性检查的前 5 个候选项：

• 每个生成 3-5 个变体：前缀（go-、un-）、后缀（-kit、-lab、-ify）、去掉元音（namr）、改拼写（nomer）、限定范围（@scope/name）
• 对变体运行可用性检查（采用相同的子代理模式，但批次规模较小）

阶段 3：评分与排名（内联）

加载 references/scoring-rubric.md，查看详细标准。

10 个评分维度（0–10 分，按上下文加权）：

维度	方法
域名可用性	.com=10，.dev/.io=7，.ai/.app=5，已停放=3，无=0
注册商可用性	目标注册商中可用的比例
社交账号一致性	目标社交平台中可用的比例
易记性	长度加分 + 音节数 + 意象
语音质量	辅音/元音流畅度、重音、声音象征
语义契合度	与领域的相关性、情感基调、隐喻丰富度
易输入性	字符数、键盘位置、无特殊字符
搜索独特性	搜索结果数量的倒数
形态灵活性	能否用作动词/名词/复合词？是否支持产品系列？
视觉质量	字母平衡、升部/降部、URL 美观度

综合分：(0.4 × intrinsic_avg) + (0.6 × extrinsic_avg) — 用户可以调整权重比例。

运行 !uv run python scripts/score.py score --input candidates.json 进行确定性评分。输入 JSON 必须包含 {"candidates": [{"name": "...", "intrinsic": {...}, "availability": {...}}], "preset": "cli-tool"}。

阶段 4：展示（内联）

加载 references/output-formats.md 查看模板。

三种排名视图：

1. 最佳名称 — 按内在质量排名（显示可用性，但不纳入评分）
2. 最佳可用名称 — 按综合分排名（默认推荐）
3. 最佳变体名称 — 展示内在质量最高且有可用修改形式的名称

每种视图都包含带有可用性矩阵（✅ ❌ ⚠️ ❓）、分数和理由的排名表。

详细卡片：每种视图中的前 3 个名称，包含完整评分明细、优势、风险和后续步骤。

可执行的后续步骤：“以每年 $12 的价格注册 neon.dev”、“在 GitHub 上认领 @neon”、“npm init neon”

交互式优化：“更多类似 #3 的名称”、“更短”、“更有技术感”、“避免使用 X 音”

仪表板：生成所有视图和卡片后，将完整会话整理为 references/output-formats.md § Structured Output Schema 中的 JSON 格式。读取 templates/dashboard.html，将 <script id="data" type="application/json">{}</script> 中的 {} 替换为该 JSON，并将结果写入 ~/.{gemini|copilot|codex|claude}/namer/{session-slug}-dashboard.html。打印打开命令：open ~/.{gemini|copilot|codex|claude}/namer/{slug}-dashboard.html

保存会话

在阶段 1（候选名称）、阶段 2（可用性）和阶段 4（排名）完成后，分别将会话保存至 ~/.{gemini|copilot|codex|claude}/namer/{YYYY-MM-DD}-{context}-{slug}.md，并附上 YAML frontmatter。支持恢复会话。

记忆保存触发条件

在自然的决策节点保存记忆。切勿为保存记忆而拖慢某个阶段——务必在交付主要输出后再保存。

触发条件	命令
阶段 0：用户说明风格偏好	memory.py save-preference --type vibe --value "..."
阶段 0：用户提及灵感来源名称	memory.py save-inspiration --name "..." --context "..."
阶段 0：用户调整权重	memory.py save-weights --intrinsic-split F --extrinsic-split F
阶段 1：用户说“避免听起来像 X”	memory.py save-rejection --pattern "X" --type phonetic --reason "..."
阶段 4：用户选定一个名称	memory.py save-selection --name "..." --archetype "..." --context "..." --score N --query "..."
优化：“更像 #N”	memory.py save-preference --type archetype --value "..." --like
优化：“更短”/“更长”	memory.py save-preference --type length --value "max=5" 或 "min=8"
任何阶段：用户否定某种风格	memory.py save-rejection --pattern "..." --type archetype --reason "..."

当一次会话产生多条记忆时，在同一条消息中批量保存。所有 memory.py 命令前都要加上 !uv run python scripts/。

规范词汇

术语	定义
简述	命名要求：命名对象、背景、风格和限制条件
候选项	可用性检查前生成的名称
原型	命名策略：自造词、隐喻、复合词、古典风格、唤起意象、描述性
内在评分	基于语言和创意维度的质量评分（不涉及 I/O）
外在评分	通过平台检查获得的可用性评分（I/O 密集）
综合评分	内在评分与外在评分的加权组合
硬性筛选	二元通过/不通过关卡：脏话、长度、易读性
变体	对候选项的修改：添加前缀、后缀或改变拼写
命名空间报告	跨所有平台的逐候选项可用性矩阵
背景预设	针对命名对象自动配置权重和平台
记忆	存储于 `~/.{gemini
原型倾向度	根据用户选择计算得出的偏好命名原型加权分布
选定项	用户选作首选并储存以用于偏好学习的名称
否定项	明确不想要的模式（语音、原型或具体名称）

参考文件索引

文件	内容	阅读时机
references/naming-strategies.md	6 种原型、声音象征、语音指南、语素库	阶段 1（生成）
references/platform-checks.md	各平台：URL、方法、响应解析、速率限制	阶段 2（可用性）
references/scoring-rubric.md	10 个维度的详细说明、6 个预设、硬性筛选条件、综合评分公式	阶段 3（评分）
references/output-formats.md	3 种视图的模板、名称卡片、变体表、后续步骤	阶段 4（呈现）
templates/dashboard.html	独立的 GUI——注入来自 § Structured Output Schema 的结构化 JSON	阶段 4（仪表盘渲染）
scripts/memory.py	用于持久化命名偏好的 CLI（加载、保存、清理、统计）	阶段 -1（加载）、会话结束时（保存）

每次只加载一个参考文件，并遵循“阅读时机”列中的说明。

关键规则

1. 绝不跳过可用性检查——未经检查的名称毫无推荐价值
2. 始终透明地展示评分标准——不得使用黑箱排名
3. 绝不捏造可用性数据——如果检查失败，标记为“❓ 未知”，绝不能标记为“✅ 可用”
4. 始终先运行硬性筛选，再检查可用性——不要把 API 调用浪费在不合格的名称上
5. 进入完整可用性检查流程的候选项最多为 25 个——合理规划工具调用
6. 始终指出商标/冲突风险——法律问题优先于名称质量
7. 绝不修改用户文件——除 ~/.{gemini|copilot|codex|claude}/namer/ 中的会话日志外，命名器只能读取文件
8. 始终提供全部三种输出视图——最佳名称、最佳可用项、最佳变体名称
9. 始终提供可执行的后续步骤——例如“在 Y 注册 X，费用为 $Z”，而不只是“X 可用”
10. 生成时必须使用多种原型——绝不能只采用一种策略生成候选项
11. 生成前先进行上下文分类——权重和平台取决于分类结果
12. 分别展示内在分数和外在分数——用户需要了解两者之间的取舍
13. 在阶段 0 之前加载用户记忆（阶段 -1）。交付主要输出后再保存记忆——绝不能因写入记忆而阻塞某个阶段