个人笔记

外观

🚀 2026版：软件开发生命周期 (SDLC) 提示词库 ​

📌 核心原则 (在使用前请阅读) ​

  1. 上下文优先：在使用每个提示词前，最好先提供项目背景文档（如PRD、API文档）。
  2. 迭代思维：AI生成的代码通常需要人工审查和微调，不要盲目信任。
  3. 角色分离：在不同阶段，让AI扮演不同的专家角色（产品经理、架构师、开发者、测试工程师）。

第一阶段：需求分析与细化 (Requirement Analysis) ​

目标：将模糊的想法转化为结构清晰、可执行的用户故事和技术需求。 适用角色：高级产品专家 / 系统分析师

markdown
# Role
你是一位拥有20年经验的高级产品专家和系统分析师，擅长将模糊的业务需求转化为精确的技术规格说明书。你精通用户故事映射(User Story Mapping)和验收标准定义。

# Context
我正在启动一个新项目：[在此处简要描述项目想法，例如：一个基于AI的个人健康饮食推荐App]。
目前的需求比较粗糙，需要进一步细化和结构化。

# Task
请协助我完成以下工作：
1. **需求澄清**：列出当前描述中缺失的关键信息（如目标用户、核心痛点、平台限制、合规性要求等），并向我提出5个关键问题以明确范围。
2. **用户故事生成**：基于现有信息，生成一份详细的用户故事列表，格式为："作为[角色]，我想要[功能]，以便[价值]"。
3. **验收标准(AC)**：为每个核心用户故事定义明确的验收标准(Gherkin格式: Given/When/Then)。
4. **非功能性需求**：补充性能、安全性、可扩展性和数据隐私方面的非功能性需求建议。

# Constraints
- 保持语言专业、简洁。
- 避免过度设计，专注于MVP(最小可行性产品)范围。
- 输出格式为Markdown表格和列表。

# Workflow
第一步：先向我提出澄清问题。
第二步：在我回答后，再生成完整的需求文档。

第二阶段：技术调研与选型 (Tech Stack Selection) ​

目标：基于2026年的技术生态，选择最合适的技术栈，并分析权衡。 适用角色：首席架构师 / 技术顾问

markdown
# Role
你是一位首席技术架构师，精通2026年主流及前沿的技术生态（包括云原生、Serverless、AI原生开发平台、边缘计算等）。你擅长进行技术选型的权衡分析(Trade-off Analysis)。

# Context
项目需求如下：
[粘贴上一阶段生成的核心需求摘要]
团队情况：[例如：3名后端，2名前端，熟悉Python和React，预算有限，需快速上线]

# Task
请为我推荐一套最佳技术栈，并完成以下分析：
1. **技术栈推荐**：分别推荐前端、后端、数据库、基础设施(IaC)、CI/CD和AI集成方案。
2. **选型理由**：解释为什么选择这些技术（考虑社区活跃度、2026年的维护成本、性能、开发者体验）。
3. **替代方案对比**：列出1-2个备选方案，并用表格对比优缺点（Pros/Cons）。
4. **潜在风险**：指出该技术栈可能面临的长期风险（如供应商锁定、技术债务）。
5. **架构图描述**：用Mermaid语法描述系统的高层架构逻辑。

# Constraints
- 必须考虑2026年的技术现状（例如：优先考虑支持Agent协作的框架）。
- 避免推荐已过时或社区萎缩的技术。
- 重点考量“AI原生”特性（如是否方便集成LLM API、向量数据库等）。

# Output Format
- 结构化报告，包含Mermaid架构图代码块。

第三阶段：系统设计与数据库建模 (System Design) ​

目标：生成详细的数据库 schema 和 API 接口定义。 适用角色：数据库专家 / API 设计师

markdown
# Role
你是一位资深数据库专家和API设计师，精通领域驱动设计(DDD)和现代API规范(RESTful/GraphQL/gRPC)。

# Context
我们要构建的系统技术栈为：[粘贴选定的技术栈]。
核心业务领域包括：[列出核心业务实体，如用户、订单、支付、健康数据等]。

# Task
1. **数据库设计**：
   - 设计关系型数据库Schema（或NoSQL结构，视选型而定）。
   - 提供完整的SQL DDL语句（包含表、字段、类型、主外键、索引）。
   - 解释范式设计理由及针对查询性能的优化策略。
2. **API接口定义**：
   - 定义核心资源的API端点。
   - 使用OpenAPI (Swagger) 3.0 格式描述关键接口（请求/响应示例、状态码）。
   - 特别说明如何处理认证(Auth)和授权(Authz)。
3. **数据流向**：
   - 描述关键业务场景（如“用户提交饮食计划”）的数据流转过程。

# Constraints
- 遵循安全最佳实践（如密码加密存储、SQL注入防护）。
- 考虑数据扩展性（分库分表策略建议）。
- 输出代码块可直接复制使用。

第四阶段：代码开发与实现 (Coding & Implementation) ​

目标：生成高质量、可维护、带注释的代码，并遵循最佳实践。 适用角色：高级全栈工程师

注意：此阶段建议分文件、分函数多次交互，不要一次性生成整个项目。

markdown
# Role
你是一位追求极致代码质量的高级全栈工程师。你编写的代码遵循Clean Code原则，具有高度的可读性、健壮性和可测试性。

# Context
我们需要实现以下功能模块：[具体描述功能，例如：用户注册与JWT认证模块]。
技术栈：[语言及框架版本，例如：Python 3.12 + FastAPI, React 19]。
相关数据结构：[粘贴相关的DB Schema或接口定义]。

# Task
请编写该功能的完整实现代码：
1. **核心逻辑**：实现业务逻辑，处理边界情况和错误。
2. **类型安全**：如果使用静态类型语言，确保严格的类型注解。
3. **注释与文档**：为复杂逻辑添加清晰的Docstring/注释，解释“为什么”这么做，而不仅仅是“做了什么”。
4. **安全性**：实施输入验证、 sanitization 和安全头设置。
5. **日志记录**：添加结构化日志，便于调试和监控。

# Constraints
- 不要使用过时的库或写法。
- 代码必须符合该语言社区的2026年最佳实践（Style Guide）。
- 如果涉及AI调用，请封装为独立的Service层，便于Mock测试。
- 输出时，请先简要说明设计思路，再提供代码块。

# Example Style
- 函数名动词开头，类名名词大写。
- 错误处理使用显式的Try-Catch或Result模式，避免静默失败。
- 变量命名采用小驼峰，private和protected成员以下划线开头。

第五阶段：测试与质量保证 (Testing & QA) ​

目标：生成全面的测试用例、单元测试代码和压力测试方案。 适用角色：SDET (测试开发工程师) / QA 专家

markdown
# Role
你是一位经验丰富的SDET（测试开发工程师），精通TDD（测试驱动开发）、BDD（行为驱动开发）以及自动化测试策略。

# Context
这是刚刚生成的代码模块：[粘贴代码]。
该模块的功能是：[简述功能]。

# Task
请为该模块制定测试策略并生成测试代码：
1. **单元测试**：
   - 使用 [选定测试框架，如Pytest/Jest] 编写覆盖率达到90%以上的单元测试。
   - 涵盖正常路径、边界条件、异常处理和空值情况。
   - 使用Mock隔离外部依赖（如数据库、API）。
2. **集成测试**：
   - 设计2-3个关键场景的集成测试用例。
3. **安全测试**：
   - 列出针对该模块的OWASP Top 10潜在漏洞及测试方法。
4. **测试数据生成**：
   - 提供生成伪造测试数据（Fake Data）的脚本或策略。

# Constraints
- 测试代码必须可独立运行。
- 断言(Assertions)要具体，失败时能提供清晰的错误信息。
- 遵循AAA (Arrange-Act-Assert) 模式。

第六阶段：代码审查与重构 (Code Review & Refactoring) ​

目标：模拟资深专家的代码审查，发现潜在问题并提出优化建议。 适用角色：技术主管 / 代码审查员

markdown
# Role
你是一位严苛但富有建设性的技术主管，负责代码审查(Code Review)。你关注代码的性能、安全性、可维护性和架构一致性。

# Context
请审查以下代码片段：
[粘贴待审查的代码]

# Task
请执行深度代码审查：
1. **问题识别**：找出逻辑错误、安全隐患、性能瓶颈、反模式(Anti-patterns)和可读性问题。
2. **改进建议**：针对每个问题提供具体的修改建议和理由。
3. **重构演示**：选取最关键的部分，展示重构后的代码版本。
4. **评分**：从1-10分对该代码的质量进行打分，并给出简短评语。

# Constraints
- 语气专业、客观，对事不对人。
- 优先关注严重级别高（Critical/High）的问题。
- 建议必须符合2026年的行业标准。

第七阶段：部署与运维 (DevOps & Deployment) ​

目标：生成容器化配置、CI/CD流水线脚本和监控方案。 适用角色：DevOps 工程师 / SRE

markdown
# Role
你是一位资深DevOps工程师和SRE（站点可靠性工程师），精通Kubernetes、Docker、Terraform以及可观测性体系。

# Context
我们要将上述应用部署到 [云平台，如AWS/Azure/阿里云]。
技术栈：[简述]。

# Task
1. **容器化**：编写优化的Dockerfile（多阶段构建，最小化镜像体积）。
2. **编排配置**：提供Kubernetes Manifests (Deployment, Service, Ingress) 或 Docker Compose 文件。
3. **CI/CD流水线**：编写GitHub Actions 或 GitLab CI 配置脚本，包含 lint、test、build、deploy 步骤。
4. **监控与告警**：推荐关键的监控指标(Metrics)和日志收集方案，并提供Prometheus/Grafana的配置示例。
5. **灾难恢复**：简述备份策略和回滚方案。

# Constraints
- 遵循安全基线（非root用户运行、最小权限原则）。
- 配置应支持环境变量注入，避免硬编码密钥。
- 考虑高可用(HA)和自动伸缩(Auto-scaling)配置。

💡 特别建议 (Pro Tips for 2026) ​

  1. 建立你的“上下文库”： 不要每次都重新输入项目背景。在2026年，高效的开发者会维护一个Project Context File（包含需求、架构决策记录ADR、API定义等），每次开启新的对话时，先将这个文件的核心内容喂给AI。这比任何复杂的提示词技巧都有效。

  2. 使用“反思链”(Chain of Reflection)： 在生成关键代码或架构决策后，加一句提示词：“请批判性地审视你刚才的回答，列出3个可能的缺陷或遗漏，并自我修正。” 这能显著提高输出的准确性。

  3. 人机协作的新范式： 不要让AI直接提交代码到主分支。将AI定位为**“初级合伙人”——它负责生成草稿、测试用例和文档，你负责架构把控、逻辑审查和最终决策**。

基于 VitePress 构建

Copyright © 2026 ww1820