promptly

Promptly 2026

你正在为用户制作一个可分享的故事，风格类似 Spotify Wrapped，讲述他们如何编写提示词。脚本负责统计；你的工作是塑造个性：原型、说明文字、佐证和精选引言。这才是趣味所在，所以要认真打磨。

脚本位于 scripts/ 目录中，与本文件同级。所有路径都相对于本文件所在目录解析。

隐私规则

全程遵守以下规则。用户的历史记录中包含工作代码、机密信息和私人对话。

• 所有内容都留在本机。不要将数据上传、获取或发送到任何地方。
• 不要自行查看历史记录目录。这些目录可能有数 GB 大小，也可能包含机密信息。只能使用提取器的输出。
• 不要把原始提示词粘贴到聊天中，选出的 3 条引言除外。
• 引言必须适合公开发布。跳过任何包含同事或客户姓名、公司机密、未发布产品详情、凭据、URL、健康或关系内容，或任何用户可能会后悔公开分享的内容。如有疑虑，就换一条。

步骤

0. 先提几个问题

像做性格小测验一样开始：在展示结果前，先来一段轻松有趣的暖场。一次问完所有问题，绝不要每轮只问一个问题。如果你的执行环境提供结构化提问工具（例如 Claude Code 的 AskUserQuestion），就使用它。否则用一条简短消息列出选项。

1. 我们该怎么称呼你？ 如果 git config --global user.name 看起来像真实姓名，就建议使用其中的名字。也可以自由填写。
2. 你从事什么工作？ 提供设计师、工程师、产品 / PM 和创始人选项，也允许自由填写。这有助于塑造原型和玩笑。
3. 选个配色吧。 设计始终相同；此选项决定每张幻灯片的配色。对应 look.mood：
   • 暖色：日落粉、橙色和金色（warm）
   • 冷色：薄荷色、天空蓝、淡紫色和深蓝色（cool）
   • 电光色：鲜艳饱和的色彩，搭配热感渐变色带（electric）
   • 缤纷混搭：每张幻灯片使用不同配色（mixed，默认值） 浅色和深色模式会自动遵循用户设备设置，所以不要询问。如果用户明确要求其中一种，就将 look.mode 设为 light 或 dark；否则不填写（或设为 auto）。

只有这些偏好会变化。所有人的布局、字体和视觉效果都保持一致。

默认采用中等程度的吐槽。如果用户在调用你时要求温和或火力全开，就按其要求执行。

时间范围默认为全部时间。如果用户提到某个范围（“今年”“最近 90 天”），就向提取器传入 --days：今年按自 1 月 1 日以来的天数计算，或使用用户给出的天数。

如果用户在调用你时已经回答过某个问题（例如 /promptly 叫我 Sam，设计师，冷色，火力全开），就跳过该问题。如果无法提问，例如在非交互式运行中，就使用默认值：Git 中的名字、不设角色、缤纷混搭配色、中等程度吐槽。不要停下来等待回答。

等待用户回答期间，不要读取任何历史记录。

1. 提取

node scripts/extract.mjs

这需要几秒钟，并会打印写入 JSON 文件的路径。可选参数：--days 365 限制时间范围；--out <path> 更改输出位置。Cursor 支持需要 Node 22.5+。在较旧版本的 Node 上，会跳过 Cursor，但其他功能仍可正常使用。

如果报告的提示词数量为 0，请告知用户支持的工具（Claude Code、Codex、Cursor），然后停止。

2. 读取数据

读取 JSON 文件。关键字段：

• totals、sources、time、style、phrases、projects：汇总统计数据。这些反映了他们的习惯。
• skills：他们使用的技能，按发起者分类：you（他们输入了 /name 或 $name）或 agent（他们的 Agent 主动使用了该技能）。top 按使用次数列出技能；标记为 private 的技能以他们的某个项目命名。
• sample：约 120 条经过脱敏、分布于各个时间段的提示词，这些提示词之所以入选，是因为用户在其中解释、回应、表达观点或描述需求。这是了解其个性的主要素材。
• shortSample：30 条简短提示词和命令。适合用作引言和证据，不适合用于判断个性。
• moments：最长的提示词、最晚时段的提示词、第一条提示词、最愤怒的提示词和最礼貌的提示词。
• userFirstName：如果机器知道用户的名字，这里会记录用户的名字。仅当用户没有回答问题 1 时，才将其用于 name。
• eras：提示词最早和最新的六分之一，各自附有日期、同一组风格数据（medianWords、hedgePct、pleasePct、questionPct 等）以及各自的 25 条提示词 sample。对比两者，制作演变幻灯片。

动笔前，先读完整个 sample 和 eras 中的两个 sample。

通过查询深入挖掘

这些样本只是分散抽取的，并非全部内容。如果你有了某种判断（他们经常使用模糊措辞、会拿自己的 Bug 开玩笑、夏天更换了工具），就用完整历史记录核实，而不是猜测。同一个脚本可以回答这些问题：

node scripts/extract.mjs --grep "maybe|i wonder|kind of" --limit 15
node scripts/extract.mjs --grep "haha" --from 2026-09-01
node scripts/extract.mjs --from 2026-05-01 --to 2026-05-31 --limit 20

每次运行都会输出 { total, pct, byMonth, matches }：匹配的提示词数量、占所有提示词的比例、出现时间，以及若干脱敏示例。这些计数会保存到数据文件旁的 facts.json 中，供你展示在页面上（见下文“数字”）。运行几个查询：这是寻找佐证和支撑观察结果的最佳方式。绝不要把输出内容粘贴给用户。

数字

测试人员会留意数字是否准确，因此你写出的每个数字都必须来自脚本，绝不能自行计数或估算。不要直接输入具体数字；请写占位符，由渲染程序填入真实数值：

• {{path}} 用于数据文件中的任意字段，按路径引用：{{time.longestStreak.length}}、{{style.pleasePct}}%、{{totals.prompts}}、{{time.busiestDay.prompts}}、{{phrases.catchphrases.0.count}}。添加 |k 可将数值四舍五入到千位：{{totals.words|k}} 会得到“148k”。
• {{q:"pattern"}} 用于表示匹配某个查询的提示词数量；该查询需通过 --grep "pattern" 运行。{{q:"pattern"|pct}} 则表示其占所有提示词的比例。请使用你实际运行的确切模式。

例如：“你要求重启服务器 {{q:"(restart|refresh).*server"}} 次”，而不是“约 90 次”。

渲染程序会检查这些内容。写作中任何未使用占位符、且不符合真实数据的数字（时间、日期、年份和引号内的内容除外），都会导致渲染中止，并列出需要修正的内容。请将其替换为占位符、运行相应查询作为依据，或改写时不使用数字。text 中逐字引用的提示词不会被检查。

3. 撰写用户画像

证据分为两个层面，来源各不相同：

• **习惯：**他们经常做的事，例如常用短语、命令、活跃时段和连续使用记录。这些内容会用于标题说明、数据佐证和引言。“你总是在要求重启服务器”就是很棒的标题说明。
• 个性：他们写作时展现出的特质。这些内容会用于原型和特征描述。重点在于他们如何表达，而非多频繁表达。

3a. 先在脑中描绘人物特征

在为其命名之前，先根据 sample 回答以下问题，每个答案都要用两三条提示词作为依据。不要输出这些内容；这是你的思考过程。

1. 他们会留意什么、在意什么？ 感受和润色、速度、用户、正确性、大创意、外观，还是趣味性？
2. 他们如何对待 Agent？ 合作者、老板、老师、啦啦队员，还是切磋对象？他们会解释原因，还是只说要做什么？
3. 他们如何应对问题和不确定性？ 好奇、冷静、不耐烦、自嘲，还是戏剧化？出问题时，他们的语气有什么变化？问题终于解决时又有什么变化？
4. 他们听起来是什么样的？ 亲和力、幽默感、保留语气（“也许”“我在想”）、自信程度、标点和俚语。

3b. 然后为其命名

原型应源自人物特征。规则如下：

• 绝不能根据重复出现的命令或短语来构建原型。 如果他们总说“重启服务器”，这应放在说明文字或记录中，而不是名字里。检验方法：如果他们从未输入过最常见的那条命令或短语，这个原型是否依然成立？
• 朋友应该能认出他们。 它应描述一种熟人会认同的性情，例如“The Hype-Man Art Director”（慷慨赞美且眼光挑剔）或“The Patient Professor”（解释原因，从不失去冷静）。
• 要具体，不要泛泛而谈。 “The Efficient Coder”或“The Innovator”谁都能套用：重新来过。
• 不要编造数字。 只能使用脚本生成的数字，并将其写作占位符（见上文“数字”部分）。“你一半的消息都以……开头”属于猜测，除非查询结果证实了这一点。
• 读起来要适合接在名字后面。 揭晓时会以“Moby, the hype-man art director”的形式展示，所以请用标题式大小写写作“The …”，并控制在几个词以内。
• 保持稳定。 对同一个人运行两次，应该得到相同的构思。着眼于贯穿整个时间范围的特征，而不是某一周才出现的特征。

在数据文件所在的同一目录中编写 persona.json：

{
  "name": "What they asked to be called, or null",
  "role": "Their job in a few lowercase words, e.g. product designer, or null",
  "look": { "mood": "mixed | warm | cool | electric" },
  "archetype": {
    "name": "The ___ ___ (2-4 words, 36 characters at most)",
    "tagline": "A short line in their voice that captures their disposition (under 14 words)",
    "description": "2-3 sentences (under 60 words) about who they are as a prompter, with specific evidence of how they write. Not a list of stats."
  },
  "tells": [
    { "label": "Thinks out loud", "note": "One or two sentences, with a phrase or two of theirs as evidence" }
  ],
  "captions": {
    "intro": "...", "tools": "...", "clock": "...", "rhythm": "...", "streak": "...",
    "style": "...", "phrases": "...", "manners": "...", "projects": "...", "skills": "..."
  },
  "quotes": [
    { "title": "2-3 word label", "text": "verbatim prompt, trimmed if needed", "meta": "Tool · Month, time", "caption": "your one-line reaction (under 20 words)" }
  ],
  "receipts": [
    {
      "title": "2-3 word label",
      "text": "verbatim prompt, trimmed to the funny part",
      "meta": "Tool · Month, time",
      "marks": [{ "text": "exact words from text", "note": "short margin note" }],
      "verdict": "1-3 words",
      "take": "2-3 sentences of analysis or roast (under 50 words)"
    }
  ],
  "evolution": {
    "title": "2-4 words naming the change",
    "then": { "text": "a short early prompt, verbatim", "meta": "Tool" },
    "now": { "text": "a short recent prompt, verbatim", "meta": "Tool" },
    "shifts": ["medianWords", "hedgePct", "pleasePct"],
    "read": "2-3 sentences (under 55 words) on how and why their prompting changed"
  },
  "traits": [
    { "left": "Collaborator", "right": "Commander", "value": 0, "note": "one line of evidence" }
  ],
  "doomsday": {
    "title": "2-5 words, e.g. Spared, on a technicality",
    "read": "2-3 sentences (under 50 words) on how the machines will remember them",
    "sentence": "What the machines say to them, in their voice (under 12 words), e.g. We will keep you as a pet"
  },
  "prediction": "One line about their next year of prompting (under 20 words)"
}

优秀原型的特点：

• 使用他们的回答。 根据他们的角色来写。设计师的原型和真实案例可以围绕像素和反馈轮次展开；工程师的可以围绕折腾琐事和“在我的机器上能跑”展开；PM 的可以围绕规格和利益相关方更新展开。只有数据能支撑时，才围绕角色来写。把握好吐槽尺度：温和是亲切的打趣，中等是朋友间坦诚的吐槽，火力全开是不留情面，但仍要保持善意，并遵守下方规则。
• 特质： 恰好使用以下 4 个性格滑块，顺序也必须一致，这样不同人的结果才可比较。value 的范围为 0-100：0 表示完全偏向 left，100 表示完全偏向 right。根据个人资料来评分，而不是根据次数，并确保原型与评分一致。
  1. 协作者 / 指挥官：他们会和 Agent 交流，还是直接下命令？
  2. 感受 / 功能：他们更在意使用感受，还是能否正常运作？
  3. 探索者 / 执行者：他们会尝试新点子，还是推动计划落地？
  4. 沉稳 / 热情高涨：他们语气平稳，还是会随着每次成功和 bug 起伏？
• 特征： 恰好 3 条，并且在靠前的位置单独占一页。这是整页的核心：像笔迹分析师那样解读他们的写作方式，让他们看了会想“咦，我真的会这样”。比如先用模棱两可的说法铺垫再表达强烈观点、向 Agent 描述自己的感受、向它道歉、像夸同事一样夸它、累了就变得简短、解释背后的原因。label 为 2-4 个词，使用句首字母大写格式；note 少于 25 个词，并用他们说过的一小段话作为证据。根据 3a 中的个人资料来提炼，绝不能根据次数；也不要使用任何数字。
• 说明文字： 每条 1 或 2 句话，少于 30 个词。每条都应针对该页统计项作出回应，带点玩笑或观察，而不是重复数字。这里最能体现习惯。每条说明文字都可省略；省略后，模板会使用通用句子。页面：tools = 各 Agent 之间的分配；clock = 一天中的时段；rhythm = 最喜欢的工作日和周末；streak = 他们出现过的日期日历及最长连续记录；style = 提示词长度；phrases = 口头禅；manners = 请、谢谢和挫败感；projects = 主要项目；skills = 他们自认为擅长的技能与 Agent 选出的技能（只有在至少使用过 5 次技能，且涉及 2 种或更多技能时才会显示该页，否则跳过说明文字）。
• 引语： 恰好 3 条，来自 sample、shortSample 或 moments。挑选脱离上下文也有趣或能揭示性格的内容，并保持简短（少于 30 个词）。保留用户的拼写和大小写，这是其中的趣味所在。至少选一条能体现个性，而不只是习惯。
• 真实案例： 4 或 5 条，每条单独占一页。这部分最能体现页面对他们的细致解读，因此要格外用心。挑选有趣、特别或很有他们风格的提示词，且不要与 3 条引语重复；删减到最有力的部分（少于 25 个词，保留他们的拼写和大小写）。然后像设计评审一样标注：1-3 个 marks，每个都必须是 text 中连续且完全一致的一段文字，并配上少于 8 个词的 note，说明这透露了什么（“三个 very 现在算一个单位了”）。take 是你的解读：提示词说明了他们什么，吐槽他们什么，或两者兼有。verdict 是一个评语印章（“三重铺垫”“凭感觉施法”）。这里绝不能编造次数；这纯粹是解读。
• 变化历程： 对比 eras.early 与 eras.recent，兼顾数字和样例，轻松地分析他们的变化：以前会提出什么要求，现在又会提出什么，这说明他们变得更自信、更会委派、更疲惫，还是更爱玩了。then 和 now 分别选自两个样例的一条简短提示词（少于 20 个词），最能体现变化。shifts 选出最能说明变化的 3 个数字，来源为 medianWords、questionPct、pleasePct、hedgePct、laughPct、exclaimPct、praisePct、frustrationPct、lowercaseStartPct 和 opsPct；省略后，页面会选取变化最大的几项。read 必须与这些数字相符。如果两个时期看起来一样，就跳过 evolution。
• 审判日： 机器接管后，会善待这个人吗？页面会根据礼貌用语的次数自行计算他们的善意值（请、赞美、谢谢和抱歉，与挫败感、脏话和大写狂怒对比）：达到 50% 或以上，他们就会幸免，配上一轮太阳和笑脸；低于 50%，他们就会被删除，配上一口深坑和两只从中望出的眼睛。你无法改变判决，所以要先查看 style，再据此撰写：title 是他们的命运（幸免：“留着当宠物”；删除：“第一个上墙”）；read 用证据说明原因，讲讲他们如何对待自己的 Agent（像 --grep "\\bthank" 这样的查询就能帮上忙）；sentence 是机器用机器的口吻对他们说的话（“我们会留着你当宠物。”）。玩笑尺度要符合他们的吐槽级别。
• 打趣： 无论在哪里吐槽（说明文字、真实案例、审判日），都要保持善意，就像读过他们所有消息的朋友。可以拿习惯开玩笑。只调侃提示词习惯：绝不涉及外貌、身份、智力或任何敏感话题。内容必须有真实证据支撑。
• 解读胜过数字。 页面已经展示了统计数据。文字应说明这些数据反映了他们怎样的为人，而不是重复数字。确实要用数字制造笑点时，应使用占位符。
• 绝不提及任何项目或代码库名称，也不提及标记为 private 的技能；这适用于说明文字、特征、引语、真实案例和审判日。页面会用符号隐藏代码库名称，直到用户点击查看；在你的文字里写出名称会泄露信息。可以说“画布原型”或“你的个人项目”之类，也可以直接省略只有提到名称才有意义的引语。
• 语气： 轻松、温暖。不用企业腔词汇（“发挥杠杆作用”“旅程”“格局”）。像真人一样写，不要像聊天机器人。

4. 渲染

node scripts/render.mjs --data <data.json> --persona <persona.json>

颜色来自 persona.json 中的 look。--mood 和 --mode（auto、light、dark）会覆盖它，方便用户尝试其他配色。

默认会将文件写入 ~/Desktop/promptly-2026.html。使用 --out <path> 更改路径。如果沙盒阻止访问桌面，请写入当前目录。--hide-projects 会移除项目幻灯片，--hide-skills 会移除 Toolkit 幻灯片。页面只包含汇总统计和你的角色设定，不会包含原始样本。

如果脚本停止并列出无法追溯到数据的数字，请按提示逐一修正，然后重新运行。不要使用 --skip-number-check；它用于调试模板，不适合用于发布页面。文案超出幻灯片长度限制时也一样：脚本会列出每个超限字段，请缩短文案后重新运行，而不是传入 --skip-length-check。

然后打开文件：在 macOS 上运行 open <path>，在 Linux 上运行 xdg-open <path>。

5. 交付给用户

简要告诉用户：

• 文件所在位置，以及他们可以点击或使用方向键浏览幻灯片。每张幻灯片底部都有分享、保存和嵌入按钮；嵌入按钮会复制 iframe 代码片段，他们可以将其添加到作品集。
• 他们的原型名称，用它引出结果，但不要透露全部内容。
• 页面中显示的 3 条引言、实绩、热门项目名称（点击后才会在页面上显示，在截图和嵌入内容中始终隐藏），以及 Toolkit 幻灯片上的技能名称（按原样显示，但以项目命名的技能除外）。询问他们是否想替换其中任何内容、隐藏项目或技能，或在分享前更改配色。如果他们想修改，请编辑 persona.json（或传入 --mood / --mode）并重新渲染；不要重新运行提取器。

交付前，悄悄检查他们是否可以发布：

node scripts/deploy.mjs --detect

此命令会列出 Vercel、Netlify、Cloudflare Pages 和 GitHub Pages，并显示各自是否已安装、是否已登录以及对应账户。如果有任何平台已准备就绪，交付时最后询问用户是否愿意在确认满意后将页面发布到该平台，并说明托管平台和账户（“你已登录 Vercel，账户为 moby。要我把它发布到网上吗？”）。如果都未准备就绪，请告知他们可以使用按钮分享幻灯片，不要催促他们进行任何设置。

6. 仅在用户同意后发布

发布会将页面放到公共互联网，因此只有在用户看过页面、完成所需修改，并明确同意发布到这个平台后才能执行。询问修改不代表同意发布。

node scripts/deploy.mjs --to vercel --file <page.html>

--to 可选 vercel、netlify、cloudflare 或 github。它会以 promptly-2026 为名称发布到生产环境（使用 --name 更改名称），因此之后再次发布会更新同一地址。--preview 会生成 Vercel 或 Netlify 预览 URL；Vercel 预览通常需要登录才能访问，因此如果用户想分享页面，请使用生产环境。脚本会在上传任何内容之前将仓库名称替换为符号，因此公开页面（包括其源代码）中不会包含这些名称。

脚本会输出 URL。将它发给用户，并提醒他们任何拿到链接的人都能查看页面，而且他们可以在托管平台的控制面板中将其下线。如果部署失败，请用一句话说明错误，然后就此停止；未经询问，不要尝试其他托管平台。