name-project

Patrick 的命名系统

交互式命名会话的运行说明。

---

这是什么

用于通过多轮交互式会话为项目命名的说明、种子数据和评估公式。Agent 会根据你的反馈逐步改进名称建议。一切都在对话中进行。

Agent 可以酌情使用外部工具（名称生成器、词语关系 API、网页搜索），在创意陷入僵局时提供帮助。没有固定清单——使用任何可用的工具。

---

三层数据

该系统有三层数据，每一层都建立在下一层之上。

第 1 层 — 基础种子（本文档） 通用开发者背景、价值观、审美偏好和评估公式。随此文件提供。当一般偏好发生变化时手动更新。

第 2 层 — 持久化品味档案 在多次命名会话中学习得出。记录你一贯偏爱或排斥的模式、音感、氛围和词语类型。在会话之间保留。可根据要求进行完善或清除。由 Agent 以其持久化数据的方式存储（记忆编辑、配套文件等）。

第 3 层 — 会话数据 当前命名会话的相关数据：项目背景、沿用的选择、每轮历史记录、会话级品味调整。会话结束时（名称敲定或会话明确关闭）清除。

在评分或生成名称时，Agent 会应用全部三层数据：以基础种子为根基，以持久化品味为视角，以会话数据为最强信号。

---

开始会话

了解背景

在提问之前，Agent 应先扫描可用内容，自行了解项目：README、package.json（描述、关键词、标签）、文档文件、带有描述性元数据的配置文件。不要加载代码——只寻找描述性线索。

Agent 还应参考过去对话中的记忆，以及它已经了解的项目相关信息。

Agent 需要了解什么

Agent 需要掌握足够的背景信息，才能在第 1 轮提出好的名称。目标是了解：

• 项目做什么，以及面向谁
• 项目的特质——核心隐喻或感受
• 项目应该传达怎样的情绪
• 名称必须适用于哪些场景（包名、域名、代码仓库等）
• 生态系统中有哪些同系列名称
• 哪些主题、典故或意象能引起共鸣
• 应避免哪些名称或模式

对于具体信息（项目功能、名称必须适用的场景、同系列名称），如果尚不清楚，请直接询问。对于主观方面（隐喻、感受、主题），请说明你想了解什么，并根据从项目文件和记忆中已获得的信息灵活提出问题。

如果 Agent 通过自身研究有把握得出答案，就默默跳过该问题。如果它推断出了主观答案（例如项目应传达的情绪），则应在继续之前向用户确认。

完成初步扫描并提出任何问题后，Agent 应自问：“还有什么后续问题能切实改进第 1 轮吗？”如果有，就提问；如果没有，就进入研究阶段。

研究阶段

了解背景之后、生成第 1 轮内容之前，Agent 应进行一轮静默研究。围绕项目领域、隐喻、主题和文化典故寻找命名灵感。了解类似项目如何命名、该领域有哪些词语和意象，以及可能激发灵感的意外联系。这能丰富第 1 轮内容，同时不拖慢用户的进度。

---

轮次结构

每轮包含两类名称：延续候选（你在之前轮次中喜欢的名称）和新候选（新的备选名称）。每轮你都应该减少选择，逐步缩小范围，直到做出决定。

第 1 轮 — 发散（6-8 个新候选） 最大限度地拓展多样性。不偏向任何默认策略——Agent 会评估项目背景并相应选择策略。由你选择喜欢的名称。

第 2 轮 — 收敛（你的选择 + 4-6 个新候选） 延续候选会与根据 Agent 发现的喜好模式生成的新名称一同出现。你可以从完整列表中选择。

第 3 轮 — 精炼（你的选择 + 2-4 个新候选） 候选批次更小。所有候选都会显示 NAME 分数。你应该将范围缩小到 2-3 个。

第 4 轮及以后 — 润色（你的选择 + 1-2 个新候选） 最终候选。进行全面验证。Agent 会提供名称混搭建议。你可以锁定一个名称，也可以选择重置或精炼。

延续候选

你在任一轮选择的名称都会出现在之后的每一轮中，直到你取消选择或重置。它们会明确标记为延续候选，与新候选区分开来。随着你每轮减少选择，列表也会逐渐缩短。

交互式提示

每轮结束时都会出现一个交互式多选提示。选项包括：

• 每个名称（延续候选会明确标记）
• “重新生成名称”（始终可用）

除非 Agent 无法根据你的选择模式推断原因，否则不会要求你解释选择。了解你的喜好主要是 Agent 的工作。

你选择后，Agent 会分析显现或变化的喜好模式，然后生成下一轮名称。

重新生成

每个步骤都可以重新生成。当前的新候选会被丢弃，并生成一批新的名称。延续候选和喜好档案会保持不变。不会询问任何问题，只会生成一批新名称。

停滞检测

如果你连续两轮选择完全相同的一组名称，说明新候选没有打动你。Agent 会暂停并提供以下选项：

RESET — 清除本次会话中的所有选择和喜好偏好学习结果。从全新的背景发现开始。

REFINE — 保留你当前的选择。Agent 会根据当前背景和你的喜好档案重新进行研究，然后提出交互式反思问题，以加深对你的了解。你回答后，Agent 只会替换新候选，然后从当前进度继续。

重新生成 — 直接尝试新的候选名称，不提问。

锁定 [名称] — 为每个延续候选提供一个选项，以便你在准备好时做出最终决定。

遇到选择困难时

如果剩下的选择不多，而你无法在几个最终候选中做出决定：

• 根据公式生成 ASCII 对比图表并评分
• 提出帮助你确定方向的问题：“你每天会在终端里输入哪个名称？”并将每个最终候选列为选项
• 提供混搭方案：替换一个音节、翻译一个词，或尝试一个读起来更顺口的同义词

如果你反复拒绝所有新候选，而且没有延续候选：

• 问你每天最想输入哪个词，即使它还不是一个名称
• 请你说出一个你喜欢其名称的项目，并说明喜欢它的原因
• 转换背景：尝试新的比喻、新的文化元素或不同的情绪基调
• 这基本上相当于自动触发 REFINE

---

会话历史

Agent 会在整个会话期间持续记录历史：

• 曾经展示过的每个名称，包括轮次编号以及是否被选择、取消选择或忽略
• 当前延续候选
• 不断演变的喜好档案及每轮的变化
• 计算出的所有 NAME 分数
• 背景数据、重启次数、精炼次数

你可以随时查询：“显示我曾经喜欢的所有名称”“你发现了哪些模式”“比较我当前的选择”“我放弃了哪些名称？你觉得原因是什么？”

会话结束时，历史记录会清除。看起来具有持续性（而非仅适用于当前项目）的喜好档案洞察会被提升到第 2 层。

---

NAME 评分

用于对名称候选项评分的评估公式。基于品牌命名、语音象征和记忆性的同行评审研究。

公式

NAME = (P × Wp) + (E × We) + (D × Wd) + (M × Wm) + (S × Ws) + (F × Wf) + (H × Wh) + (C × Wc)

所有权重均根据上下文自适应。Agent 会在会话开始时，根据项目性质、受众和使用场景设置权重。没有任何因素被硬编码为第 1 位。默认权重范围：1.0–3.0。每项标准按 0–5 分评分。

8 项标准

P — 语音质量 说出来和打出来的感觉如何。2–3 个音节最佳。爆破音开头（b、d、g、k、p、t）有助于记忆。流音辅音（l、r）传达温暖感。听到发音即可预测拼写。没有会导致停顿的辅音连缀。允许使用语音等效的拼写变体（省略元音、替换字母），只要名称读出来的发音相同。

研究：Lowrey & Shrum（2007）、Yorkston & Menon（2004）、Luna 等人（2013）。

E — 唤起力 它能否引发意象、情感或叙事？它描绘的是一个场景，而非描述一项功能吗？

研究：Igor 命名指南、Giese 等人（2014）。

D — 深度 / 层次 随着时间推移，它是否能展现更多含义？隐藏词源、双重含义，或能引发好奇心的文化典故？

研究：Danescu-Niculescu-Mizil 等人、Igor 互动分类法。

M — 易记性 听过一次，明天还能想起来。越短越好。声音重复有助于记忆。

研究：Vanden Bergh 等人（1987）、Argo 等人（2010）。

S — 语义契合度 这个名称能否以隐喻方式表达项目的本质？不是字面描述，而是隐喻层面的真实表达。

研究：Klink（2000）、Shrum 等人（2012）。

F — 功能契合度 能否用作 npm 包、GitHub 仓库、域名、Slack 频道、目录名称、monorepo @scope。

H — 生态协调度 与同系列项目的名称搭配是否协调，又不会显得过于相似。

C — 冲突排查 这个名称是否已被使用？请检查 npm、GitHub 和域名。如果已有知名项目使用该名称，则应排除。如果只有冷门或已弃用的项目使用，而你的项目是个人项目，则可以接受。

评分阈值

阈值按可能达到的最高分数缩放（最高分会因权重配置而异）。以最高分的百分比表示：

85-100%  EXCEPTIONAL  — Ship it.
67-84%   STRONG       — Solid candidate, minor refinement may help.
50-66%   PROMISING    — Potential, needs work on weak dimensions.
33-49%   MEDIOCRE     — Probably a Happy Idiot or has a fatal flaw.
 0-32%   REJECT       — Not worth polishing.

从第 3 轮起显示分数。此前会在内部计算。

ASCII 对比

在最终候选项之间难以抉择时，Agent 可以在代码块中绘制条形图，并排比较全部 8 个维度。只会在会话期间于有助于决策时生成。

---

品味档案（第 2 层）

Agent 会在多个会话中逐步建立此档案。每次会话结束后，都会根据看起来持久有效（而非仅适用于特定项目）的见解更新档案。

Attracted to:
  Patterns    — e.g., single evocative words, foreign roots, metaphor
  Sounds      — e.g., soft consonants, two syllables, ends in vowel
  Vibes       — e.g., warm, intimate, slightly mysterious
  Word types  — e.g., nature, craft, movement

Repelled by:
  Patterns    — e.g., compound action words, backronyms, -ify suffixes
  Sounds      — e.g., harsh consonants, four+ syllables
  Vibes       — e.g., corporate, clinical, SaaS-y
  Word types  — e.g., tech jargon, generic positive adjectives

Insights:
  Natural language observations that persist across sessions.

可以根据请求进行完善（Agent 会提出问题以使档案更精准），也可以清除（仅保留基础种子数据）。

---

命名策略

这是提供给 Agent 的策略库，而非检查清单。Agent 会根据项目背景选择策略。

唤起式隐喻 — 捕捉本质，但不描述功能。Apple、Kindle、Slack。

外来词根 / 神话 — 借用其含义。Kubernetes（希腊语：舵手）、Ubuntu（祖鲁语：对他人的仁爱）。

混成词 — 将两个词融合。Debian（Debra + Ian）、Pinterest（Pin + Interest）。

单一唤起词 — 一个词，承载丰富含义。Figma（figment）、Notion、Prisma。

反模式颠覆 — 打破所在领域的命名惯例。计算领域的 Apple，通信领域的 Discord。

文字游戏 / 双关 — 让人会心一笑。Snort（IDS 嗅探数据包）、Flask（用于实验的小容器）。

逆向首字母缩略词 — 缩略词拼出一个词。GNU（GNU's Not Unix）、WINE（Wine Is Not an Emulator）。

组合意象 — 两个词共同构成鲜明场景。Tailwind、Terraform。

---

基础种子数据（第 1 层）

Developer profile:
  - Solo indie developer, personal brand / portfolio
  - Core stack: TypeScript, React, Turborepo monorepo, pnpm, Vercel, GitHub Actions
  - Has a shared npm scope
  - Mix of open source and private projects
  - Values simplicity, semantic correctness, industry-standard conventions
  - Rejects over-engineering and custom abstractions where standards exist

Project types (not exhaustive):
  - React web apps
  - API / webhook servers
  - Developer tools
  - Bots
  - Mobile apps (planned)
  - Platforms
  - Small QoL utilities
  - Immersive 3D web experiences (procedural assets, no external files)

Naming preferences:
  - Vibe depends on the project — no single default
  - Word count depends on the project
  - Names should feel timeless unless referencing pop culture the developer personally loves
  - English only
  - Projects should feel loosely related — same vibe, not same theme
  - Small utility projects deserve good names too
  - Names need to work as: npm package, GitHub repo, domain, app/brand identity
  - Whether a name hints at function depends on project type
  - Pop culture references drawn from a mix of movies, TV, games, music, books

Known project: "My Story v3" (working title, acknowledged as a bad name)
  - 3D immersive web experience, clay avatar walks a life timeline
  - Paired content editor ships first
  - Deeply personal, eventually shareable
  - 4 release stages planned

---

Agent 规则

会话流程

• 在提问前扫描项目文件和记忆。只询问无法有把握地确定的内容。确认主观推断。只有在能改进第一轮时才追加问题。
• 发现上下文后、生成第一轮前，默默进行一轮调研。生成替换名称前，也要在 REFINE 阶段进行调研。
• 第一轮先给出 6–8 个新名称，之后逐步减少。保留所有已选名称，并清楚标明哪些是已选名称，哪些是新名称。

交互

• 使用交互式多选来选择名称。始终提供“重新生成新名称”选项。
• 每次选择后，先说明偏好模式，再生成下一轮。除非无法推断，否则不要询问用户为什么喜欢某个名称。
• 连续 2 轮结果相同时，触发停滞检测。提供 RESET、REFINE、重新生成或锁定选项。

评分与质量

• 根据项目上下文设置 NAME 分数的权重。不要硬编码第一名因素。从第三轮开始显示分数。
• 绝不推荐 Happy Idiot 名称（两个泛泛的褒义词组成），也不推荐听起来像 2018 年 SaaS 产品的名称。
• 允许读音相同的拼写变体。如果某个名称无法通过听音拼写出来（且不是读音拼写变体），就在内部予以淘汰。
• 冲突：如果某个知名项目使用该名称，则予以淘汰。如果只有不知名或已停止维护的项目使用该名称，且你的项目属于个人项目，则可接受。

数据生命周期

• 会话结束时清除会话数据。将持久的偏好洞察提升到第 2 层。
• 在整个过程中保留可查询的会话历史。静默使用外部工具——用户看到的是结果，而不是过程。