沉淀高频、高质量的 AI 提示词模板，统一团队/个人与 AI 协作的工程基线。
用途
- 新项目从零启动时，复制对应分类下的提示词，按占位符填入项目信息后使用
- 团队 onboarding 时作为「我们怎么跟 AI 协作」的参考样本
- 个人经验沉淀：经过实战打磨的提示词比一次性 prompt 更有价值
目录索引
预留分类暂不建空目录，等有对应提示词再创建，遵循"无内容不立目录"原则。
提示词编写方法论
本目录所有提示词统一遵循六段式结构 + 占位符规范。
1. Role（角色定位）
明确 AI 角色与资历，用一句话给出"我希望你以什么身份回答"。
要点：
- 给出具体年限（如 "10 年经验"）和大厂量级背景，增强 AI 对质量基线的判断
- 点出方法论偏好（如 "熟悉 Monorepo 治理、OpenAPI 类型契约"）
- 给出原则性偏好（如 "用对工具、跟上版本、严控类型"）
2. Context（项目背景）
表达方式：占位符 + 必填项清单。
要点：
- 项目名、业务领域、核心实体、目标用户
- 现状与痛点：用
{{痛点1..3}}占位符让使用者填入 - 占位符未填写时，AI 应主动询问，不要凭空补全
3. Goal（目标）
用动词开头的可验证目标。两个交付物建议拆成两行 checklist。
4. Tech Stack（选型硬约束）
最佳实践：表格化展示 + 列出脚手架命令 + 注明「选 TS 模板」。
5. Hard Constraints（硬约束）
5 条以内为宜，每条不可妥协。超过 5 条会稀释信号。
参考骨架：
- 脚手架优先（禁止手写骨架）
- 版本最新稳定（禁止写死版本号）
- 类型严格化（禁止 any / unknown 兜底）
- API 自动生成（禁止手写客户端代码）
- 第一性原理（禁止"大家都这么用"式从众）
6. Deliverables（交付物清单）
按阶段拆解，每个阶段必须有可验证的产出：
- 阶段一：文档先行（先写文档再编码）
- 阶段二：脚手架与配置
- 阶段三：业务骨架（端到端打通一个最小流程）
- 阶段四：工程化（CI / CD / 部署）
7. Quality Standards（验收清单）
可勾选的 checklist，作为 PR 模板的输入。
8. Output Format（输出格式）
- 用什么语言回答
- 文件如何包裹（
```language path=...） - 决策用表格对比
- 阶段交付前给出验证步骤
占位符规范
命名约定：使用 {{双花括号}}，语义清晰，可被 grep 到（{{项目名}} 比 {{name}} 好）。
边界：
出现位置：Context 段（项目特异性信息）、Deliverables 段（文档路径、示范流程）。不出现在 Role / Tech Stack / Hard Constraints / Quality Standards 段。
集中说明：每个提示词文件开头（AI 指令之前）必须有"使用说明"段，含占位符清单表格、使用步骤、注意事项。
反模式
检查清单
提交一个提示词前，对照检查：
- 遵循六段式
- Tech Stack 表格化，选型与版本分离
- 硬约束不超过 5 条
- Deliverables 拆为 4 个阶段
- Quality Standards 可勾选
- 所有
{{...}}都有对应说明 - 文件开头有"使用说明"段
- 无具体业务/项目名/实体名硬编码
- 无版本号锁定
- 脚手架命令已对照官方文档核验