@ghyper9023/pi-dev-workflow 0.2.0 → 0.3.0

package/ai/346/217/220/347/244/272/350/257/215/344/274/230/345/214/226.md

@@ -1,341 +0,0 @@
-# 🧠 AI 编程提示词模板库（按 Git Commit 类型分类）
-
-> 融合 **Anthropic / Claude Code 官方最佳实践**、**OpenAI Codex CLI 文档**、**社区 1000+ 提示词审查** 以及 **吴恩达提示词工程课程** 的核心原则，提供可直接复制、填充的提示词模板。  
-> 覆盖 `feat` `fix` `doc` `refactor` `test` `chore` `perf` `style`，并补充 `security` 等高频类型。
-
----
-
-## 🧩 通用骨架（适用于所有类型）
-
-每个高质量提示词都应包含以下结构，优先保证 **角色 + 任务 + 上下文** 清晰：
-
-```text
-[类型] 简短标题（≤50字符）
-
-**角色**：你是一个资深 [语言/框架/领域] 工程师/专家。
-**背景/上下文**：项目技术栈、关键约束、当前现状、目标受众。
-**具体任务**：明确要做什么，精确到文件/函数/行号。
-**输出格式**：指定 diff / Markdown / 表格 / 列表 / 代码块等。
-**验证指令**：要求 AI 提供自检方法（测试命令、预期输出、性能基准）。
-**硬性约束**：禁止的行为（NEVER）、必须保持的规则、最小改动原则。
-**深度思考**：对复杂问题要求列出权衡方案，客观分析利弊，避免谄媚。
-```
-
-> ⚠️ 关键原则：**上下文精准 · 验证驱动 · 极简主义 · Plan 先行 · 硬性约束 · 对抗谄媚**
-
----
-
-## 1. `feat` — 新功能 / 创意生成
-
-> 核心口诀：**Plan 先行，验证兜底**  
-> 适合场景：头脑风暴新方案、功能设计、产品创意、模块开发
-
-### 📝 详细版模板
-```text
-[feat] 在 [模块/文件] 中实现 [功能描述]
-
-**角色**：你是一个资深 [TypeScript / Python / Rust] 工程师。
-**背景**：项目使用 [技术栈，如 NestJS + Prisma]，当前缺少 [具体能力]，用户痛点是 [具体痛点]。
-**任务**：
-1. 先分析代码库结构，给出逐步实施计划（列出要修改/创建的文件、数据库迁移、对现有代码的假设）。
-2. 计划经我确认后再编写代码。
-3. 实现后编写测试用例验证核心逻辑，并运行 [测试命令] 确认通过。
-**输出**：提供 unified diff 和两句话的变更说明。
-**约束**：禁止顺手重构无关代码；保持所有公共 API 签名兼容；不要为假设性需求添加抽象层。
-**验证**：运行 [npm test / cargo test] 确保无回归。
-```
-
-### ⚡ 精简版模板
-```text
-Plan first — no code yet.
-Implement [功能] in @file:[路径]。
-Tech: [框架/库]。
-Write a test to verify, then run [命令]。
-```
-
-### 🔑 关键提示
-- 涉及 >2 个文件时，必须先进入 **Plan Mode**，Review 计划后动手。
-- 明确 **角色 + 任务 + 上下文**，开局第一句话决定成败。
-- 要求 AI 提供 **验证自己工作的方法**（测试、截图、预期输出），这是最高杠杆的实践。
-
----
-
-## 2. `fix` — 问题排查 / 错误修正
-
-> 核心口诀：**根因修复，不消除症状**  
-> 适合场景：调试代码、修正逻辑错误、分析失败原因
-
-### 📝 详细版模板
-```text
-[fix] 修复 @file:[文件路径] #L[行号] 中的 [Bug 描述]
-
-**背景**：
-- 输入：[粘贴出错内容或描述现象]
-- 预期行为：[正确的结果]
-- 当前错误：[错误信息/不符合预期的输出]
-**任务**：
-1. 不要仅仅消除报错（Suppress），要解决根本原因。
-2. 先读取相关代码和日志，诊断根因（多步推理，不要先给结论）。
-3. 提供至少一种修复方案，并说明为什么这样做。
-4. 编写测试用例复现该 Bug 并确认修复有效。
-**输出**：提供 diff 和两句话的根因分析。
-**约束**：只修 bug，不做重构；最小化改动；不要假设错误是微不足道的。
-**验证**：运行 [测试命令] 确认修复。
-```
-
-### ⚡ 精简版模板
-```text
-Fix root cause, not the symptom.
-@file:[路径] #L[行号] — [Bug 简述]。
-Diagnose before patching. Minimum change only.
-Write a test to verify.
-```
-
-### 🔑 关键提示
-- 明确 **诊断先于修补**，防止 AI 用 try-catch 吞掉错误。
-- 精确指定 **文件和行号**，避免 AI 通读整个仓库。
-- 要求 **编写测试** 来复现 Bug，确保修复有效且不会回归。
-
----
-
-## 3. `doc` — 文档生成 / 总结
-
-> 核心口诀：**面向读者，结构优先**  
-> 适合场景：撰写说明、注释、会议纪要、API 文档、README
-
-### 📝 详细版模板
-```text
-[doc] 为 [模块/API] 撰写一份 [用户手册 / API 文档 / 决策报告]
-
-**角色**：你是一位技术文档工程师。
-**背景**：目标受众是 [小白 / 前端开发者 / 架构师]，他们需要了解 [关键信息点]。
-**已有材料**：[上传文件 / 粘贴原始笔记]
-**任务**：
-1. 提取核心要点，按逻辑结构重组（概述 → 快速开始 → 详细说明 → 常见问题）。
-2. 添加至少 2 个真实可运行的示例（使用 [语言] 语法高亮）。
-3. 如存在争议点，列出不同观点并注明“无共识”。
-**输出格式**：Markdown 层级标题，必要时插入表格/列表。
-**约束**：避免空洞词汇（如“细致入微”“深入探究”）；每段都应有实质信息；保持原意，不添加原文没有的事实。
-**验证**：请先提供大纲，经我确认后再扩展。
-```
-
-### ⚡ 精简版模板
-```text
-Document [模块/API] for [目标读者].
-Structure: overview → quickstart → API reference → ≥2 real examples.
-Ensure code examples are runnable. Output Markdown.
-```
-
-### 🔑 关键提示
-- 明确 **目标受众** 和 **输出格式**，让文档可落地。
-- 要求 **先出大纲**，避免一次性生成冗长且离题的内容。
-- 强调 **示例可运行**，提升文档的实用性。
-
----
-
-## 4. `refactor` — 重构 / 优化现有结构
-
-> 核心口诀：**手术式修改，行为不变**  
-> 适合场景：改进代码结构、拆分模块、改善可读性/可维护性
-
-### 📝 详细版模板
-```text
-[refactor] 对 @file:[文件路径]（约 [行数] 行）进行重构，提升 [可读性 / 可维护性]
-
-**背景**：当前代码存在 [具体问题，如重复逻辑、耦合度高]。
-**任务**：
-1. 识别 3 个主要问题。
-2. 提出重构方案，说明改动前后差异。
-3. 输出重构后的完整版本。
-**硬性约束**：
-- 不改变任何行为，保留所有公共 API 签名不变。
-- 禁止顺手优化、禁止添加新功能、禁止修改业务逻辑。
-- 拆分后运行 [测试命令] 确认无回归。
-**输出**：提供 diff 和新模块的依赖关系图。
-**验证**：运行 [测试命令] 并确保全部通过。
-```
-
-### ⚡ 精简版模板
-```text
-Surgical changes only.
-Refactor @file:[路径] — [目标]。
-Zero behavior change. Keep all public API signatures.
-Run [测试命令] after. No optimization.
-```
-
-### 🔑 关键提示
-- 遵循 **Andrej Karpathy 的 “Surgical Changes”** 原则，只改必须改的地方。
-- 明确“**不改变任何行为**”并用测试证明，是区分熟练使用者和新手的关键习惯。
-
----
-
-## 5. `test` — 测试用例 / 评估
-
-> 核心口诀：**表驱动，先红后绿**  
-> 适合场景：生成测试数据、编写单元/集成测试、设计验证标准
-
-### 📝 详细版模板
-```text
-[test] 为 @file:[文件路径] 中的变更生成表驱动测试
-
-**角色**：你是一个资深测试工程师。
-**背景**：使用 [Jest / Vitest / pytest] 框架，追求 ≥[90]% 分支覆盖率。
-**任务**：
-1. 覆盖维度：null 值、空值、超时、幂等性、重试、成功路径、4xx/5xx 错误、边界条件 [列举具体边界]。
-2. 优先让测试先失败（红），再提供补丁使其通过（绿）。
-**输出格式**：表格列出场景 → 预期结果 → 权重，末尾附评分模板。
-**约束**：评分准则必须无歧义；不要假设输入总是合法的。
-**验证**：运行 [测试命令] 并展示覆盖率报告。
-```
-
-### ⚡ 精简版模板
-```text
-Table-driven tests for @file:[路径].
-Cover: nulls, timeouts, idempotency, edge cases.
-Fail first, then pass. Use [框架]. Target ≥[90]% coverage.
-```
-
-### 🔑 关键提示
-- **表驱动测试**（Table-Driven Tests）能覆盖更多边界条件。
-- **先红后绿**（让测试先失败再通过）是验证测试有效性的最佳方式。
-
----
-
-## 6. `chore` — 日常维护 / 杂项自动化
-
-> 核心口诀：**只做必须，禁止顺手**  
-> 适合场景：依赖更新、构建配置、CI 调整、批量重命名、环境配置
-
-### 📝 详细版模板
-```text
-[chore] 在 @file:[配置文件路径] 中 [更新依赖 / 修改构建脚本 / 调整 CI]
-
-**角色**：你是一个 DevOps 工程师。
-**背景**：当前环境 [描述]，目标版本 [版本号]。
-**任务**：
-1. 只做 [具体任务]，不做任何其他改动。
-2. 改动后运行 [验证命令] 确认无破坏性变更。
-**硬性约束**：
-- NEVER 修改生产环境配置文件（如 config/production.yml）。
-- NEVER 运行任何部署命令（除非用户明确要求）。
-- 禁止顺手升级无关依赖、禁止修改代码逻辑。
-**输出**：提供变更前后对比和影响说明。
-**验证**：运行 [验证命令] 并展示结果。
-```
-
-### ⚡ 精简版模板
-```text
-Only [具体任务] — no other changes.
-@file:[路径] — [操作描述]。
-NEVER touch production configs.
-Run [验证命令] after.
-```
-
-### 🔑 关键提示
-- 使用 **NEVER + 明确豁免条件** 来锁死危险行为，比“尽量不要”有效得多。
-- 明确 **“只做必须的”**，防止 AI 在杂务中顺手“优化”导致 CI 崩溃。
-
----
-
-## 7. `perf` — 性能优化
-
-> 核心口诀：**先测量，后优化**  
-> 适合场景：查询优化、缓存策略、算法改进、减少 token 消耗
-
-### 📝 详细版模板
-```text
-[perf] 优化 @file:[文件路径] 中的 [瓶颈描述]
-
-**角色**：你是一位性能优化专家。
-**背景**：当前执行耗时约 [X 秒] / 成本约 $Y，用户可接受的延迟为 [Z ms]。
-**任务**：
-1. Think deeply about this performance issue.
-2. 先分析当前性能数据，给出基准指标。
-3. 列出 ≥2 种优化方案，分析每个方案的预估提升幅度、实现复杂度、潜在风险。
-4. 选择推荐方案并实现。优化后运行 [基准测试命令] 对比前后数据。
-**输出**：提供 before/after 性能对比表格。
-**约束**：不要牺牲核心准确性；优先给出低风险改动；不为了微优化牺牲可读性。
-```
-
-### ⚡ 精简版模板
-```text
-Think deeply.
-Optimize @file:[路径] — [瓶颈]。
-≥2 approaches with trade-offs. Benchmark before & after.
-```
-
-### 🔑 关键提示
-- **“Think deeply”** 能触发 AI 的权衡分析，避免表面答案。
-- **必须提供基准对比**，数据驱动决策，拒绝凭感觉优化。
-
----
-
-## 8. `style` — 风格 / 格式调整
-
-> 核心口诀：**保持原意，统一规范**  
-> 适合场景：改写语气、统一术语、格式化代码、调整注释风格
-
-### 📝 详细版模板
-```text
-[style] 将以下 [代码/文本] 调整为 [正式商务 / 幽默 / 简洁要点式 / Prettier 规范]
-
-**原文**：[粘贴内容]
-**任务**：
-1. 保持原意和信息完整，仅改变表达风格 / 代码格式。
-2. 术语统一为 [术语表，可选]。
-3. 输出两种备选风格供我对比。
-**约束**：不要添加原文没有的新事实，不要改变关键数据和逻辑；同时指出原文中可能存在的歧义表达。
-**验证**：对代码运行 [linter / formatter 检查命令] 确保符合规范。
-```
-
-### ⚡ 精简版模板
-```text
-Reformat [代码/文本] to [风格]。
-Keep original meaning. Provide 2 style options for comparison.
-Run [linter] after if code.
-```
-
-### 🔑 关键提示
-- 明确 **风格目标** 和 **术语表**，避免 AI 自由发挥。
-- 对代码风格调整，务必配合 **自动化格式化工具** 验证。
-
----
-
-## 🛡️ 补充类型
-
-| 类型       | 用途     | 核心口诀               | 示例场景                               |
-| ---------- | -------- | ---------------------- | -------------------------------------- |
-| `security` | 安全审查 | 独立审查，逐项排查     | 检查代码漏洞、提示词注入风险、密钥泄露 |
-| `explain`  | 概念解释 | 类比引导，由浅入深     | 向小白讲解复杂原理                     |
-| `compare`  | 对比评估 | 多维矩阵，客观打分     | 多产品/多方案的优劣势分析              |
-| `forecast` | 预测趋势 | 数据驱动，标明不确定性 | 基于数据预测未来走向                   |
-
-### `security` 详细模板
-```text
-[security] 对 @file:[文件路径] 运行安全审查
-
-**角色**：你是一名安全审计专家（独立于编写代码的 Agent）。
-**任务**：
-1. 审查清单：认证边界、注入漏洞、敏感数据暴露、CSRF/CORS 配置、权限校验缺失。
-2. 提供带行号的修复方案及理由。
-3. 只审查不修改，输出审查报告。
-**硬性约束**：在隔离上下文中运行，不继承主 Agent 的记忆。
-**输出**：Markdown 报告，每个问题包含严重级别、行号、风险描述、修复建议。
-```
-
----
-
-## 🧪 使用建议（融合最佳实践）
-
-1. **启动新话题** — 清空无关上下文，每次新会话用 `Resume project X` 恢复状态（依赖 SESSION.md）。  
-2. **Plan 先行** — 对复杂任务（涉及 >2 个文件），先让 AI 输出计划，Review 后再编码。  
-3. **对抗谄媚** — 在约束中写明：“请客观评价，不要只说优点。若有不足，请明确指出。”  
-4. **渐进迭代** — 先让 AI 输出大纲/问题列表，反馈确认后再生成最终结果。  
-5. **多模型验证** — 将同一提示词发给 ChatGPT、Claude、Gemini，选出最佳输出。  
-6. **持久化规则** — 将团队规范、构建命令、常见陷阱写入 `CLAUDE.md` 或 `AGENTS.md`，每次会话自动加载。  
-7. **新会话 = 新开始** — 避免超长对话，上下文压缩风险在新会话中降至零。
-
----
-
-> 💡 **核心原则**：上下文精准 · 验证驱动 · 极简主义 · Plan 先行 · 硬性约束 · 深度思考  
-> 模板中的 `[ ]` 为必填占位符，直接替换即可使用。