AI 提示詞： 程式設計與編程

Explain this code so I can understand and confidently modify it.

```[language]
[Paste the code block — include imports and calling context]
```

Language/framework: [language and version if relevant]
My skill level: [beginner / intermediate / advanced]
What I need to do with it: [modify / extend / debug / understand before reviewing a PR]
What's confusing me: [specific parts, if any]

Provide:
1. **Plain-English summary:** what this code does in 2-3 sentences a non-developer could understand
2. **Block-by-block walkthrough:** annotate each logical section with what it does, why it's structured this way, and what happens if it fails
3. **Patterns and idioms:** identify any design patterns, framework conventions, or language idioms being used — explain why they're used here (not just what they are)
4. **Hidden complexity:** potential bugs, edge cases, race conditions, or gotchas that aren't obvious from a quick read
5. **Modification guide:** how I would change this code to [describe intended change], with the specific lines to modify and what to watch out for
6. **Dependency map:** what this code depends on and what depends on it — so I know the blast radius of any changes

Help me find and fix this bug.

**Code:**
```[language]
[Paste the relevant code — include the function and its callers]
```

**Error message:**
```
[Paste the EXACT error message and full stack trace]
```

Expected behavior: [what should happen]
Actual behavior: [what actually happens — include specific values if relevant]
Reproduction steps: [how to trigger the bug]
What I've already tried: [debugging steps taken and their results]
Environment: [language version, OS, framework versions, relevant dependencies]

Provide:
1. **Root cause:** what's actually causing this error and WHERE in the code the problem originates (not just where it manifests)
2. **The fix:** corrected code with the specific changes highlighted. Explain each change
3. **Why this works:** the underlying concept that was wrong — so I understand the principle, not just the patch
4. **Collateral check:** related bugs that often accompany this one. Check the surrounding code for similar patterns
5. **Prevention strategy:** a linting rule, type annotation, or test that would catch this bug class automatically
6. **Test case:** a specific test to verify the fix and prevent regression, with expected input/output

Review this code as if you were a senior engineer on my team.

**PR Description:** [what this change does and why]

```[language]
[Paste the code or diff]
```

Framework: [framework and version]
Team conventions: [style guide, naming patterns, architecture patterns, test requirements]
Priority: [shipping fast / production-critical / library code / hackathon]
Security context: [handles user input? PII? Payments? Auth?]

Review across 4 tiers:
1. **Blockers** (must fix before merge): bugs, security vulnerabilities, data loss risks, broken error handling. For each: exact location, what's wrong, and the fix
2. **Should fix:** design issues, missing abstractions, performance concerns, insufficient error handling. For each: what's suboptimal, why it matters, and the recommended change
3. **Suggestions:** naming improvements, readability, documentation gaps, minor refactors. Non-blocking but would improve quality
4. **Questions:** things that need clarification from the author before I can assess correctness

Also provide:
- **Test coverage gaps:** specific scenarios that aren't tested but should be
- **Verdict:** ship as-is / ship after minor fixes / needs significant rework. With reasoning

Review and refactor this code for better quality.

```[language]
[Paste the code to refactor]
```

Language/framework: [language and version]
What this code does: [brief description of its purpose]
Primary concern: [readability / performance / maintainability / testability / all]
Constraints: [backward compatibility requirements, team style guide, performance SLAs]
Upcoming changes: [features being built that will touch this code next]

Provide:
1. **Quality assessment:** what's good (preserve these), what needs work (change these), and what's dangerous (fix these immediately)
2. **Refactored code:** the improved version with all changes applied
3. **Change log:** every modification explained — what changed, why, and the specific quality dimension it improves
4. **Performance analysis:** did the refactoring change performance? Better, same, or trade-offs to be aware of
5. **Testability improvement:** how the refactored code is easier (or harder) to test, with example test structure
6. **Verification checklist:** how to confirm the refactored code behaves identically to the original — specific inputs/outputs to test

Help me solve this algorithm/data structure problem.

**Problem:** [paste the problem statement or describe it clearly]
Language: [preferred language for the solution]
Context: [interview prep / competitive programming / real project / learning]
Constraints: [time complexity requirement, space limits, input size range]
What I've tried: [approaches attempted and where they fail]
Pattern guess: [what type of problem you think this is, if any]

Provide:
1. **Problem classification:** identify the pattern (sliding window, two pointer, dynamic programming, graph traversal, etc.) and explain WHY this pattern applies
2. **Brute force solution:** working code with time/space complexity analysis. This is the baseline
3. **Optimized solution:** improved algorithm with explanation of the optimization insight — what observation makes the better approach possible?
4. **Dry run:** step-by-step walkthrough with a small example input showing how the algorithm progresses
5. **Edge cases:** specific inputs that break naive implementations (empty input, single element, all same values, maximum size, negative numbers)
6. **Related problems:** 3 similar problems that use the same pattern, so I can practice the technique

Help me integrate with this API in production-ready code.

API: [service name and version]
What I need: [specific operations: fetch data, send data, webhook handling, etc.]
My stack: [language, framework, existing HTTP client/SDK]
Auth type: [API key / OAuth 2.0 / JWT / Basic / custom]
Sample response:
```json
[Paste a sample API response if available]
```
Error handling needs: [retry on failure / fail fast / degrade gracefully / queue and retry later]
Rate limits: [if known]

Provide:
1. **Complete working code** with all imports, types/interfaces, and configuration
2. **Auth setup:** secure credential handling (env vars, not hardcoded). Include token refresh logic if OAuth
3. **Type definitions:** request/response types that match the actual API contract
4. **Error handling:** specific handlers for each failure mode (rate limits, auth expiry, timeout, 4xx, 5xx). Not just try/catch everything
5. **Retry strategy:** exponential backoff with jitter, configurable max retries, and circuit breaker pattern for sustained failures
6. **Integration test:** a test that verifies the integration works against the real API (or a mock). Include setup/teardown

Write comprehensive tests for this code.

```[language]
[Paste the code to test]
```

Test framework: [Jest / pytest / JUnit / Go testing / RSpec / other]
What this code does: [brief description]
Critical invariants: [what must ALWAYS be true — e.g., 'balance never goes negative,' 'auth tokens expire after 1 hour']
External dependencies: [databases, APIs, file system, time-dependent behavior]
Existing test patterns: [describe your team's test conventions if any]

Generate:
1. **Happy path tests:** the main use cases that should always work. 3-5 tests covering core functionality
2. **Edge case tests:** empty inputs, boundary values, maximum sizes, null/undefined, Unicode, special characters. 5+ tests
3. **Error path tests:** what happens when things fail — invalid input, network errors, permission denied, timeout. 3-5 tests
4. **Integration tests:** if the code touches external services, tests with mocks/stubs that verify the interaction contract
5. **Regression tests:** based on the code's complexity, tests for specific bugs that are likely to be introduced during future changes
6. **Test data factory:** reusable fixtures or builders for the test data, so future tests are easy to write

Help me write or optimize this SQL query.

**What I need:** [describe the data you want to retrieve or modify]
**Database:** [PostgreSQL / MySQL / SQLite / SQL Server / other]
**Current query (if optimizing):**
```sql
[Paste the current query]
```
**Table schema:**
```sql
[Paste relevant CREATE TABLE statements or describe the schema]
```
**Current indexes:** [list existing indexes if known]
**Table sizes:** [approximate row counts for each table involved]
**EXPLAIN output:** [paste if available]
**Performance issue:** [slow reads / slow writes / lock contention / timeout / N+1]

Provide:
1. **Optimized query:** the best SQL for this task with explanation of approach
2. **EXPLAIN analysis:** what the execution plan tells us and where the bottleneck is
3. **Index recommendations:** specific indexes to create (with CREATE INDEX statements) and why each one helps
4. **Query alternatives:** 2-3 different approaches (subquery vs. JOIN vs. CTE vs. window function) with trade-offs
5. **Anti-patterns check:** common SQL mistakes in the original query (SELECT *, implicit conversions, functions on indexed columns, unnecessary JOINs)
6. **Scaling considerations:** will this query still perform at 10x and 100x current data volume? What breaks first?

Help me build a regular expression for this pattern.

**What I need to match:** [describe the pattern in plain English]
**Language/tool:** [JavaScript / Python / Go / Java / grep / other — regex flavors differ!]
**Test strings that SHOULD match:**
```
[List 5+ examples]
```
**Test strings that should NOT match:**
```
[List 5+ counter-examples]
```
**Capture groups needed:** [what specific parts do I need to extract?]
**Performance context:** [running once on a string / running on millions of lines / real-time input validation]

Provide:
1. **The regex pattern** with a character-by-character explanation of what each part does
2. **Visual breakdown:** annotated regex showing groups, quantifiers, and anchors
3. **Test results:** run all provided test strings and show match/no-match for each
4. **Edge cases I haven't considered:** patterns that would match incorrectly or fail to match valid inputs
5. **Performance notes:** is this regex safe from catastrophic backtracking? ReDoS risk assessment
6. **Alternative approaches:** if regex is the wrong tool for this (parsing HTML, complex nesting), say so and recommend the right tool

Help me find and fix performance bottlenecks in my code.

**What's slow:** [specific operation, endpoint, page load, build time, test suite]
**Current performance:** [measured response time, throughput, memory usage — be specific]
**Target performance:** [what you need it to be]
**Code:**
```[language]
[Paste the relevant code or describe the architecture]
```
**Profiling data (if available):**
```
[Paste profiler output, flame graph description, or timing logs]
```
**Infrastructure:** [language version, server specs, database, caching layer]
**Scale:** [requests per second, data volume, concurrent users]

Provide:
1. **Bottleneck identification:** analyze the code/profiling data to identify the top 3 performance bottlenecks. Rank by impact
2. **Quick wins:** optimizations that take under 30 minutes and yield measurable improvement. Specific code changes
3. **Architecture improvements:** structural changes that require more effort but unlock significant performance gains (caching, query optimization, async processing, connection pooling)
4. **Memory analysis:** are there memory leaks, excessive allocations, or unbounded growth? Specific patterns to fix
5. **Benchmark template:** code to measure before/after performance accurately so you can prove the optimization worked
6. **Scaling ceiling:** at what point does this code need a fundamentally different approach? When should you re-architect vs. keep optimizing?