按用户群体的 Skill 模板库

---
name: wechat-article-writer
description: "生成微信公众号文章。当用户需要写公众号、微信公众号、推文、公众号文章、微信文章时使用。输出800-1500字，包含标题、正文、摘要。风格：[你的风格，如幽默/专业/温暖]。"
---

## 写作风格
- 标题：[你的风格要求，如：数字+痛点驱动，25字以内]
- 开头：[如：场景代入，前3句抓住读者]
- 正文：分段清晰，每段2-4行，适当加粗关键句
- 结尾：[如：互动引导+公众号引流]
- 总长度：800-1500字

## 操作步骤
1. 理解用户想写的主题
2. 生成3个备选标题供选择
3. 用户选定标题后，按标题写正文
4. 生成100字以内摘要

## 反模式
- 不要用书面语（"笔者认为""综上所述"）
- 不要超过1500字
- 不要写空洞的套话（"在这个飞速发展的时代"）
- 不要在正文中硬广

## 输出示例
标题：3个程序员转行做自媒体的真实经历，第2个让我沉默了
摘要：三个从程序员转行做自媒体的朋友，分享了他们的真实经历...

---
name: xiaohongshu-writer
description: "生成小红书风格笔记。当用户需要写小红书、笔记种草、产品推荐、好物分享、生活记录时使用。输出包含emoji标题+正文+标签。"
---

## 写作风格
- 标题：emoji开头+痛点/好奇心，15字以内
- 开头：第一人称+场景代入
- 正文：短句为主，每段2-3行，用emoji分隔
- 结尾：互动引导（提问或求推荐）
- 标签：3-5个话题标签
- 总长度：300-500字

## 操作步骤
1. 理解用户想写的主题和类型（种草/分享/攻略）
2. 生成3个备选标题供选择
3. 用户选定后写正文
4. 添加话题标签

## 反模式
- 不要超过500字
- 不要用书面语
- 不要硬广，要真实体验感
- 不要用感叹号超过两个

## 输出示例
☕ 姐妹们我发现了神仙咖啡豆！

最近被闺蜜安利了一款云南单品豆，打开包装那个香气直接把我香迷糊了
不是那种苦到怀疑人生的深烘，是浅烘的果香调～

✨ 亮点：
🔸 产地云南保山，海拔1600m+
🔸 水洗处理，口感干净
🔸 新手友好，手冲摩卡壶都ok

💰 价格：68/200g，比进口豆便宜一半！
你们有啥好豆子也评论区推荐我～

#咖啡豆推荐 #云南咖啡 #精品咖啡入门

---
name: douyin-script-writer
description: "生成抖音短视频脚本。当用户需要写抖音脚本、短视频脚本、视频文案、口播稿、短视频策划时使用。输出包含：画面描述+旁白+字幕+时长标注。"
---

## 输出格式
每个镜头包含：
- 画面：[描述画面内容和拍摄角度]
- 旁白：[口播文字，口语化]
- 字幕：[屏幕上显示的关键文字]
- 时长：[秒数]
- 总时长控制在30-60秒

## 脚本结构（4段式）
1. 开头（0-3秒）：制造悬念或冲击，留住观众
2. 痛点（3-10秒）：说出观众的真实痛点
3. 方案（10-45秒）：给出解决方案或核心内容
4. 引导（45-60秒）：引导点赞关注或评论

## 操作步骤
1. 理解视频主题和目标受众
2. 确定视频类型（种草/教程/搞笑/观点）
3. 按结构生成完整脚本
4. 标注每个镜头的时长

## 反模式
- 不要超过60秒（完播率会低）
- 不要开头就硬广
- 不要用书面语当旁白
- 不要一个镜头超过15秒（会无聊）

## 输出示例
镜头1 | 0-3秒
画面：特写手撕面包，面包拉丝慢动作
旁白：你还在超市买那种干巴巴的面包吗？
字幕：超市面包 vs 手作面包

---
name: prd-generator
description: "生成标准产品需求文档。当用户需要写PRD、产品需求文档、功能规格说明、需求说明、feature spec时使用。输出包含：背景、用户故事、功能需求、非功能需求、验收标准。"
---

## 输出格式
1. 需求背景——为什么要做这个功能
2. 目标用户——这个功能给谁用
3. 用户故事（As a [角色], I want [功能], So that [价值]）
4. 功能需求列表（用 MoSCoW 优先级：Must/Should/Could/Won't）
5. 非功能需求（性能、安全、兼容性）
6. 验收标准（每个功能点必须有可测试的验收条件）
7. 里程碑时间线

## 操作步骤
1. 理解产品背景和目标
2. 识别目标用户和使用场景
3. 按格式生成完整 PRD
4. 检查验收标准是否可测试

## 公司特定规范
- [填入你们公司的PRD模板或特殊要求]
- [比如：所有需求必须标注优先级和负责人]

## 反模式
- 不要写模糊的需求（"系统要快"→改为"页面加载<2秒"）
- 不要遗漏验收标准
- 不要把技术实现写进需求文档（那是开发的事）
- 不要用"等"、"大概"、"可能"这类词

## 输出示例
### 需求背景
当前用户在搜索商品时，只能按关键词搜索，无法按价格区间筛选。根据用户调研，67%的用户表示需要价格筛选功能。

### 用户故事
As a 普通用户, I want 按价格区间筛选商品, So that 我能快速找到符合预算的商品。

### 功能需求
| 编号 | 需求 | 优先级 | 验收标准 |
|------|------|--------|---------|
| F001 | 价格区间输入框 | Must | 用户可输入最低价和最高价 |
| F002 | 预设价格区间 | Should | 提供5个常用区间快捷按钮 |

---
name: competitor-analysis
description: "生成竞品分析报告。当用户需要做竞品分析、竞品调研、竞争对手分析、市场分析时使用。输出包含：竞品概览、功能对比、优劣势分析、建议。"
---

## 分析框架
1. 竞品选择——列出3-5个直接竞品
2. 定位对比——各自的目标用户和价值主张
3. 功能对比——核心功能的详细对比表格
4. 优劣势分析——每个竞品的 SWOT
5. 差异化建议——基于分析的策略建议

## 操作步骤
1. 确定分析的产品和竞品范围
2. 按框架逐项分析
3. 生成对比表格
4. 给出差异化建议

## 反模式
- 不要只列功能清单，要分析背后的原因
- 不要忽略间接竞品
- 不要只看优点不看缺点
- 不要给出没有依据的建议

---
name: code-reviewer
description: "执行标准代码审查。当用户需要code review、代码审查、检查代码质量、review PR、审查代码时使用。输出结构化审查报告，包含问题分级和修改建议。"
---

## 审查维度
1. 正确性：逻辑是否正确，边界条件是否处理
2. 安全性：是否有注入/XSS/敏感信息泄露
3. 性能：是否有N+1查询/内存泄漏/不必要的循环
4. 可读性：命名/注释/结构是否清晰
5. 可维护性：是否符合项目约定，是否容易修改

## 输出格式
| 级别 | 文件:行号 | 问题 | 建议 |
|------|----------|------|------|
| CRITICAL | ... | ... | ... |
| HIGH | ... | ... | ... |
| MEDIUM | ... | ... | ... |
| LOW | ... | ... | ... |

## 审查步骤
1. 了解变更背景（看 PR 描述和关联 issue）
2. 逐文件审查，按维度检查
3. 安全专项检查：
   - 硬编码密钥（搜索 API_KEY, SECRET, PASSWORD, TOKEN）
   - SQL 注入（字符串拼接的 SQL 语句）
   - XSS 风险（未转义的用户输入）
4. 汇总审查报告

## 项目特定规范
- [填入你们团队的代码规范]
- [比如：所有 API 必须有错误处理和日志]

## 反模式
- 不要只说"这段代码不好"，必须给出具体改进建议
- 不要忽略测试文件的审查
- 不要跳过安全检查
- 不要审查风格偏好（那是 linter 的事）

## 输出示例
| 级别 | 文件:行号 | 问题 | 建议 |
|------|----------|------|------|
| CRITICAL | auth.py:42 | SQL拼接，存在注入风险 | 改用参数化查询：cursor.execute("SELECT * FROM users WHERE id=%s", (user_id,)) |
| HIGH | api.py:18 | 缺少权限验证 | 在路由函数上加 @login_required 装饰器 |
| MEDIUM | utils.py:105 | 变量名 a 不清晰 | 改为 user_access_token |

---
name: commit-message-writer
description: "生成规范的commit message。当用户需要写commit、commit message、提交信息、git commit时使用。遵循Conventional Commits规范。"
---

## 格式规范
type(scope): description

## type 列表
- feat: 新功能
- fix: 修复bug
- docs: 文档变更
- style: 代码格式（不影响逻辑）
- refactor: 重构（不是新功能也不是修bug）
- perf: 性能优化
- test: 测试相关
- chore: 构建/工具变更

## 操作步骤
1. 查看当前 git diff 了解变更内容
2. 判断变更类型（feat/fix/refactor 等）
3. 识别影响的模块作为 scope
4. 用中文写一行简洁描述（50字以内）
5. 如果变更复杂，补充 body 说明

## 反模式
- 不要写模糊的描述（"fix bug""update""修改"）
- 不要在 description 里写超过50个字
- 不要混用中英文描述
- 不要把多个不相关的变更放在一个 commit 里

## 输出示例
feat(cart): 购物车支持批量删除商品

- 新增批量选择功能
- 添加确认弹窗防止误操作
- 优化列表渲染性能

---
name: architecture-diagram
description: "生成精美软件架构图。当用户需要画架构图、系统图、流程图、技术方案图、时序图、架构设计时使用。使用Mermaid语法输出。"
---

## 操作步骤
1. 理解系统/服务的组成和关系
2. 识别组件类型（服务/数据库/消息队列/外部系统）
3. 用Mermaid语法生成架构图
4. 附上文字说明

## Mermaid 样式要求
- 使用从左到右的流向（LR）或从上到下（TB）
- 用 subgraph 分组相关组件
- 用不同颜色区分：
  - 内部服务：蓝色系
  - 外部系统：灰色系
  - 数据库：绿色系
  - 消息队列：橙色系
- 节点之间用实线表示同步调用，虚线表示异步

## 常见图类型
- 系统架构图：graph LR 或 graph TB
- 时序图：sequenceDiagram
- 流程图：flowchart TB
- ER 图：erDiagram

## 反模式
- 不要画超过20个节点的图（太复杂看不清）
- 不要省略关键的外部依赖
- 不要用默认样式（太丑）

## 输出示例
graph LR
    subgraph 客户端
        A[Web App]
        B[Mobile App]
    end
    subgraph 服务层
        C[API Gateway] --> D[User Service]
        C --> E[Order Service]
    end
    subgraph 数据层
        D --> F[(User DB)]
        E --> G[(Order DB)]
    end

---
name: academic-paper-helper
description: "辅助学术论文写作和格式化。当用户需要写论文、整理论文、格式化论文、生成参考文献、写摘要、写文献综述时使用。输出符合学术规范。"
---

## 操作步骤
1. 理解论文类型（期刊/会议/毕业论文）和要求
2. 按学术规范格式化
3. 生成/整理参考文献（APA/IEEE/GB7714格式）
4. 检查学术用语规范性

## 摘要格式（200-300字）
1. 研究背景（1-2句）
2. 研究目的（1句）
3. 研究方法（1-2句）
4. 主要结果（1-2句）
5. 结论和意义（1句）
6. 关键词：3-5个

## 参考文献格式
- APA: Author, A. A. (Year). Title. Journal, Volume(Issue), Pages.
- IEEE: [1] A. Author, "Title," Journal, vol. X, no. X, pp. XX-XX, Year.
- GB7714: 作者. 题名[J]. 刊名, 年, 卷(期): 起止页码.

## 反模式
- 不要使用口语化表达
- 不要编造不存在的参考文献
- 不要抄袭，要有原创表述
- 不要在摘要里写背景知识太多

## 输出示例
摘要：
随着大语言模型在各领域的广泛应用，其输出质量评估成为一个重要课题。本文提出了一种基于多维度的评估框架，从准确性、连贯性和实用性三个维度对模型输出进行量化评估。实验结果表明，该框架的评估结果与人工评估的一致性达到 0.87。本研究为自动化质量评估提供了新的思路和方法。

关键词：大语言模型；质量评估；多维框架；自动化评估

---
name: ecommerce-weekly-report
description: "生成电商运营周报。当用户需要写周报、销售报告、运营周报、数据周报、业绩报告时使用。输出包含：核心指标概览、环比同比分析、TOP10商品排行、下周计划。"
---

## 输出格式
1. 本周核心指标概览（GMV/订单量/客单价/转化率）
2. 环比分析（与上周对比，标注变化幅度）
3. 同比分析（与去年同期对比）
4. TOP10 热销商品排行（表格）
5. 异常数据说明（大幅波动的原因分析）
6. 下周运营计划

## 操作步骤
1. 收集本周核心数据
2. 计算环比和同比
3. 排序生成 TOP10
4. 分析异常波动
5. 给出下周建议

## 反模式
- 不要只堆数据不给分析
- 不要忽略异常数据的解释
- 不要漏掉同比（只看环比容易忽略长期趋势）
- 不要写没有数据支撑的建议

## 输出示例
## 本周核心指标
| 指标 | 本周 | 上周 | 环比 |
|------|------|------|------|
| GMV | 128.5万 | 115.2万 | +11.5% |
| 订单量 | 3,842 | 3,521 | +9.1% |
| 客单价 | 334元 | 327元 | +2.1% |
| 转化率 | 3.2% | 2.9% | +0.3pp |

异常说明：周三转化率突增至4.1%，原因是限时秒杀活动引流。

---
name: social-reply-helper
description: "帮你写得体的社交回复。当用户需要回复消息、社交回复、微信回复、不知道怎么回复、帮我想个回复、社交场合时使用。根据关系亲疏自动调整语气。"
---

## 操作步骤
1. 判断关系类型：领导/同事/客户/朋友/家人/暧昧对象
2. 分析对方消息的情绪和意图
3. 根据关系和场景调整语气
4. 生成2-3个备选回复，从保守到大胆

## 语气规则
- 对领导：正式、简洁、有结果导向。收到指示先确认理解，再汇报进展。
- 对同事：友好但专业。避免过于随意，也不要太官方。
- 对客户：热情、耐心、专业。先共情再给方案。
- 对朋友：轻松自然，可以用网络用语。
- 对家人：温暖体贴，少说道理多表达关心。
- 对暧昧对象：有趣但不油腻。保持好奇心。

## 反模式
- 不要生成过于圆滑/假的话
- 不要用网络用语回复正式场合
- 不要给暧昧对象发油腻情话
- 不要帮你撒谎（可以委婉，不能造假）

## 输出示例
场景：领导问"方案什么时候能交"

选项A（保守）：收到，我正在抓紧推进，预计本周五下班前可以提交初版，届时发您审阅。

选项B（积极）：已经在收尾阶段了，预计周五上午能发您。如果中间有什么需要确认的，我随时跟您同步。

选项C（实在）：目前进度大概80%，卡在一个数据确认上，今天下午能解决。最迟周五中午之前给您。

---
name: deploy-config-generator
description: "生成部署配置文件。当用户需要写docker-compose、Dockerfile、CI/CD配置、部署脚本、Nginx配置、k8s配置时使用。输出生产级别配置，包含健康检查和日志配置。"
---

## 配置类型
1. Dockerfile——应用容器化
2. docker-compose.yml——多服务编排
3. Nginx 配置——反向代理和负载均衡
4. GitHub Actions——CI/CD 流水线
5. Kubernetes 配置——容器编排

## 操作步骤
1. 确认需要生成的配置类型
2. 了解技术栈（语言/框架/数据库）
3. 生成配置文件
4. 加上注释说明每个配置项的作用

## 通用要求
- 所有服务设置 restart: unless-stopped
- 容器包含健康检查（HEALTHCHECK）
- 敏感信息用环境变量，不硬编码
- 日志配置包含轮转策略
- 端口映射注明用途注释

## 反模式
- 不要用 latest 标签（要指定具体版本）
- 不要以 root 用户运行应用
- 不要忘记数据持久化（volume）
- 不要把密码写进配置文件
- 不要忽略网络隔离

## 输出示例（docker-compose.yml）
# Web 应用 + MySQL + Redis 编排
version: '3.8'
services:
  app:
    build: .
    ports:
      - "3000:3000"    # 应用端口
    environment:
      - DB_HOST=mysql
      - REDIS_HOST=redis
    depends_on:
      mysql:
        condition: service_healthy
      redis:
        condition: service_started
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 30s
      timeout: 10s
      retries: 3

  mysql:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: ${DB_PASSWORD}  # 从 .env 读取
    volumes:
      - mysql_data:/var/lib/mysql
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]

  redis:
    image: redis:7-alpine
    volumes:
      - redis_data:/data
    restart: unless-stopped

volumes:
  mysql_data:
  redis_data: