把前端提示词作为仓库资产维护

反复让 ChatGPT 写组件、审 PR，最费时间的往往不是等待生成，而是一遍遍解释团队约定，再修掉同样的问题。作者的做法是把高频提示词写成 Markdown，命名、纳入 Git，并接到编辑器和 agent 的工作入口。

这套方法的价值在于保存团队记忆，让相同任务有稳定的规则、输出结构和验收标准。原文给出了一个很轻的落地方案，也分享了个人使用变化，但没有提供效率提升的对照数据。

为什么代码能编译，还要反复返工

「写一个 Modal」看起来已经交代了任务，实际遗漏了不少决定交付质量的信息：焦点限制（focus-trap）怎么处理、按 Escape 是否关闭、关闭后焦点回到哪里。

类似的问题还包括：加载状态该用 skeleton 还是 spinner，表单使用哪个库，错误信息按什么模式展示，以及 AI 审 PR 时哪些问题该检查、哪些判断留给人。

模型可能生成能编译的代码，却接不上团队最近几个 PR 的习惯。下次换个人提问，还得重新解释一遍。

作者因此把提示词当作代码管理：有名称、有版本、放进仓库。可复用的提示词，保存的是任务背后的交付约定。

不过，作者没有建议把所有聊天都归档。他的门槛是每月至少复用两次，否则继续留在聊天里即可。

一个提示词文件，需要把交付说到多具体

作者把文件放在 prompts/frontend/，每个文件只负责一种任务和一种输出形态：

prompts/frontend/
  pr-review-ai.md          # 模型检查什么，哪些留给人
  new-component.md         # 脚手架、无障碍分类与 token 规则
  design-token-change.md   # 合并前的 changelog / RFC 检查清单
  test-plan.md             # 有效覆盖与虚假绿灯
  agent-ui-diff.md         # 组件边界，不随意修改 token
  accessible-react.md      # 必须提供角色、键盘与对比度报告

这里要看的是每个文件后面的职责边界。new-component.md 不只是要求生成组件，还要约束无障碍和设计 token；pr-review-ai.md 则要明确模型应该放过什么。

为避免文件各写各的，作者使用统一骨架，让人和 agent 都能快速找到上下文、规则和验收要求：

## <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.

## Output format
Numbered sections the reply must include.
Missing a section = reject the turn.

## Done looks like
Concrete acceptance — not “looks good.”

最该关注的是 Missing a section = reject the turn.：缺少必需章节，就判定这次回复不合格。相关 golden files 可以理解为仓库里值得照着做的范例文件，比只写「遵守项目风格」更具体。

作者尤其强调输出格式。让模型按固定章节交代结果，比只要求「写得专业」更容易检查。不过，章节齐全只能证明格式达标，不能证明代码正确。

文件放进仓库后，怎样进入日常工作

只有文件夹，没有使用入口，提示词很容易变成另一份没人打开的文档。

作者建议在 Cursor、Copilot、Claude 的项目指令中引用 prompts/frontend/，或者直接嵌入每天最常用的两份提示词。PR bot 或 agent 可以把 pr-review-ai.md 作为系统层任务说明，但产品判断仍由人负责。

常用任务还可以通过 slash 命令或 snippet 调用，例如让 @new-component 展开组件提示词。这里描述的是需要配置的工作方式，原文没有给出各工具的具体配置，也没有证明它们都会自动读取该目录。

作者还提出一种类似 CI 的使用习惯：回复缺少必需章节，就用同一份文件重新执行。提示词本身的修改，也像 eslint 配置一样走 PR review。

他的迁移经历是：第 1 周有 12 个名为「modal again」的 ChatGPT 对话；第 3 周留下 6 个文件，删掉了一半对话。随后，Button、Modal、Combobox 任务开始使用一致的无障碍报告结构，token 修改不再夹带十六进制颜色字面量，AI 审查也不再纠缠已约定留给人的命名问题。

这些是作者的实践观察，没有量化的返工率或耗时对照。

我的判断

我认可把高频任务的规则和验收要求一起版本化。对前端团队来说，焦点管理、设计 token、表单错误展示这类约束很容易在零散聊天里丢失，放进仓库更方便共同维护。

但「模型擅长填结构」只是经验判断。格式能帮助发现遗漏，无法替代类型检查、测试或实际键盘操作。缺章节后重跑，也只是作者建议的人工习惯，原文没有实现自动校验。

它和统一的项目指令并不冲突：通用规范适合集中维护，任务文件补充本次工作的边界和输出要求。完整样式指南不必复制多份，引用真实文档即可。

还有一个前提：团队已经知道什么叫「做对了」。如果组件规范本身存在分歧，提示词只能保存分歧，解决不了分歧。

能拿来做什么

• 从最常重复的 3 类请求开始，例如新建组件、AI 审 PR、编写测试计划，每类建立一个 Markdown 文件，先别铺开到 30 份。
• 给组件任务写清原生 HTML、设计 token、焦点和键盘规则，并要求按固定结构报告结果，让审查者能逐项核对。
• 给 AI 审 PR 划定范围，例如把命名和产品判断留给人，减少重复出现、又没有行动价值的评论。
• 把提示词接到编辑器常用入口，并定期清理低频文件；一次性调试、营销文案不纳入这个前端库，示例中也不要放秘密、私有 URL 或客户数据。