我以前把 ChatGPT 当成一台自动贩卖机：想要一个 React Hook，就投币问一次；想要一段 PR 总结，就再投币问一次。每次提问都从零开始，技术栈、团队规范、什么叫“完成”，都要重新解释一遍。

结果就是：AI 给出的东西虽然能编译，但经常不符合我们真实交付代码的方式。

后来我发现，真正浪费的不是 token，而是我每次都在重复解释前端规则，然后反复修同样的错误。

于是我不再把提示词当一次性聊天记录，而是把它当代码来管理：有名字、有版本、能进仓库、能被团队反复使用。

一次性提问不会积累

临时问一句当然没问题，但前端工作很少是一次性的。

比如这些场景：

• “帮我写一个 Modal”，但没告诉 AI 我们的焦点捕获、Escape 关闭、返回焦点规则。
• “帮我加加载状态”，但没告诉 AI 我们到底用骨架屏，还是用 loading 圆圈。
• “帮我审一下这个 PR”，但没告诉 AI 哪些事情它该看，哪些事情应该留给人类判断。
• “帮我重构这个表单”，但没告诉 AI 我们用的是哪个表单库，也没有说明错误提示该怎么写。

最后你得到的代码可能可以运行，但它不像你们团队之前写的代码。下一个人，或者明天的你，还得重新解释一遍。

一个提示词库应该放什么

我会建一个很小的文件夹，比如 prompts/frontend/。

它不是长篇文档，也不是团队百科。每个文件只负责一件事，只产出一种固定结果。

示例结构如下：

prompts/frontend/
  pr-review-ai.md          # what the model checks vs leaves for humans（中文：AI 代码审查看什么，哪些留给人类判断）
  new-component.md         # scaffold + a11y buckets + token rules（中文：新建组件脚手架、可访问性要求、设计令牌规则）
  design-token-change.md   # changelog / RFC checklist before merge（中文：修改设计令牌前的变更记录和 RFC 检查清单）
  test-plan.md             # real coverage vs fake green（中文：测试计划：追求真实覆盖，而不是表面全绿）
  agent-ui-diff.md         # component boundaries, no random token edits（中文：约束 Agent 修改 UI 的边界，不要乱改令牌）
  accessible-react.md      # roles / keyboard / contrast report required（中文：要求角色、键盘操作、对比度报告）

这里有个原则：如果一个提示词每个月复用不到两次，就不值得单独变成文件。

一次性聊天就像便利贴，贴在聊天框里可以，但不值得进入团队仓库。

每个提示词都保持同一个形状

为了让人类和 AI 都能快速理解，我会让每个提示词文件保持同一个结构。

# <job name>
# 中文注释：任务名称。一个文件只负责一个任务，输出一种固定结果。

## When to use
One sentence. If it doesn’t match, don’t force it.
# 中文注释：什么时候使用。只写一句话；如果场景不匹配，就不要强行套用。

## Context to paste
- Framework / router / form lib (or “read from repo”)
- Design tokens source of truth
- Related golden files (paths)
# 中文注释：需要粘贴给模型的上下文。例如框架、路由、表单库，或者直接让它读取仓库；设计令牌的唯一来源；相关标准文件路径。

## Hard rules
Bullet list the model must not violate.
Prefer native HTML, keep tokens, no drive-by refactors, etc.
# 中文注释：硬性规则。模型不能违反这些要求，例如优先使用原生 HTML、保留设计令牌、不要顺手重构无关代码。

## Output format
Numbered sections the reply must include.
Missing a section = reject the turn.
# 中文注释：输出格式。回复必须包含编号章节；缺少任何一个章节，就视为不合格，重新生成。

## Done looks like
Concrete acceptance — not “looks good.”
# 中文注释：完成标准。要写清楚可验收的结果，而不是模糊的“看起来不错”。

这里面最关键的是“输出格式”。

模型很擅长按照结构填空。如果你不给结构，它就会自由发挥，给你一堆看起来很合理、但未必符合团队标准的内容。

从聊天框复制，变成编辑器和 Agent 的默认能力

当这些提示词文件存在之后，不要只把它们放在仓库里吃灰。要把它们接到真实工作流里。

可以这样做：

• 在 Cursor、Copilot 或 Claude 的项目说明里，指向 prompts/frontend/，或者把最常用的两三个提示词直接内置进去。
• 在 PR 机器人或 Agent 里，把 pr-review-ai.md 作为系统说明。AI 负责检查规则和一致性，人类继续负责产品判断。
• 做成斜杠命令或代码片段，比如输入 @new-component 就自动展开新建组件提示词，避免每个人重复输入。
• 养成类似 CI 的习惯：如果 AI 的回复缺少必需章节，就当它没有通过检查，让它按同一个提示词重新生成。

你不需要一开始就做一个复杂的提示词管理平台。

Markdown 文件 + Git 仓库就够用了。提示词的修改也可以像审查 ESLint 配置一样，通过 PR 来审查。

一次小迁移带来的变化

第一周，我有很多个叫“modal again”的 ChatGPT 对话。

第三周，我留下了六个提示词文件，删掉了一大半历史对话。

实际变化很明显：

• 新建 Button、Modal、Combobox 时，AI 开始按照同一套可访问性要求输出。
• 修改设计令牌时，AI 不再偷偷往组件里塞十六进制颜色值。
• AI 审查 PR 时，不再纠结命名问题，因为提示词里已经写明：命名问题留给人类处理。

模型还是那些模型，但我需要反复纠正它的次数变少了。

提示词库承担了一部分团队记忆，而聊天界面总是转头就忘。

哪些内容不适合放进提示词库

不是所有东西都应该塞进去。

这些内容通常不适合：

• 产品介绍、营销文案、增长方案。提示词库应该围绕交付 UI 和工程协作。
• 一次性的 debug 记录。如果这个问题以后不会再出现，就没必要沉淀成文件。
• 整份设计规范直接复制进去。正确做法是链接到真正的规范文档，避免两边不同步。
• 密钥、内部私密链接、客户数据。这些绝不能作为示例写进提示词。

提示词库是开发体验基础设施。如果它读起来像一篇博客草稿，那它应该去博客，而不是留在提示词库里。

先从 3 个开始，不要一口气做 30 个

今晚就可以做一件小事：找出你最近反复问 AI 的 3 个问题。

然后给每个问题写一个 Markdown 文件，里面包含：

• When：什么时候用。
• Rules：哪些规则不能违反。
• Output：AI 必须按什么格式输出。
• Done：怎样才算真正完成。

把它们放进仓库，再让你的编辑器或 Agent 指向这个文件夹。

下次你再打开一个空白 ChatGPT 输入框处理前端任务时，先打开对应的提示词文件。粘贴一次，反复使用。

这就是从“一次性提问”到“可复用提示词库”的升级。