AI 提示詞： 軟體開發

Help me design the architecture for a software system.

Project: [describe what you're building and the core problem it solves]
Scale: [current users, expected growth, data volume, peak traffic patterns]
Team: [size, seniority levels, language/framework expertise]
Tech constraints: [required technologies, cloud provider, existing systems to integrate with]
Budget: [infrastructure budget range — monthly]
Timeline: [MVP deadline, full launch date]
Non-functional requirements: [latency SLAs, uptime targets, compliance needs]

Design:
1. **High-level architecture:** describe each component, its responsibility, and how they communicate. Include a text-based diagram showing the flow
2. **Technology stack:** specific recommendation for each layer (language, framework, database, cache, queue, CDN) with reasoning. Flag where you're choosing simplicity over scalability intentionally
3. **Data model overview:** key entities, relationships, and which database type fits each (relational, document, key-value, graph)
4. **API design:** REST vs. GraphQL vs. gRPC for each communication path, with justification. Include auth strategy
5. **Scaling roadmap:** what changes at 100 users, 10K users, 100K users, 1M users. Specifically: what stays the same and what must change
6. **Top 5 architectural risks:** what could go wrong, how likely it is, and the mitigation strategy for each
7. **Decision record:** for the 3 biggest trade-offs, document what you chose, what you rejected, and why — so future developers understand the reasoning

Help me design a database schema for my application.

Application: [describe what the app does and core user workflows]
Data types: [list the main entities you'll store]
Relationships: [how data connects: users have posts, orders have items, etc.]
Top 5 queries: [the most frequent reads and writes, with expected frequency]
Write patterns: [batch inserts? Real-time updates? Append-only?]
Scale: [current data volume, expected growth rate, peak write/read throughput]
Database: [PostgreSQL / MySQL / MongoDB / DynamoDB / undecided — explain preference]

Design:
1. **Complete schema:** tables/collections, columns/fields, types, constraints, and default values. Include CREATE TABLE statements
2. **Relationships:** primary keys, foreign keys, junction tables, and referential integrity rules. Explain each relationship
3. **Indexes:** specific indexes for your top 5 queries with CREATE INDEX statements. Explain what each index accelerates and the write overhead trade-off
4. **Normalization analysis:** where to normalize (data integrity) vs. denormalize (read performance). Justify each decision with your query patterns
5. **Migration strategy:** how to evolve this schema as requirements change without downtime. Include a versioning approach
6. **Query examples:** optimized SQL for your top 5 operations, using the indexes you designed
7. **Scaling plan:** when to add read replicas, partitioning, or sharding — and the specific table/query that will hit limits first

Help me set up a CI/CD pipeline for my project.

Project type: [web app / API / mobile / library / monorepo]
Stack: [languages, frameworks, build tools, test frameworks]
Source control: [GitHub / GitLab / Bitbucket]
Deploy target: [AWS / GCP / Azure / Vercel / Railway / Docker / Kubernetes]
Current deployment: [describe how you deploy now — even if it's manual]
Team size: [number of developers and deployment frequency]
Test suite: [what tests exist and how long they take]
Secrets: [env vars, API keys, certificates that need to be managed]

Build:
1. **Pipeline configuration:** complete YAML file for your CI/CD platform with comments explaining each step
2. **Stage design:** build → lint → test → security scan → deploy. Specific commands for each with failure handling
3. **Branch strategy:** main/develop/feature branches with merge rules, required checks, and auto-deploy triggers
4. **Environment management:** dev → staging → production configuration. What differs between environments and how secrets are injected
5. **Deployment strategy:** blue-green, rolling, or canary — with justification for your scale and risk tolerance
6. **Rollback procedure:** how to revert a bad deployment in under 5 minutes. Specific commands and verification steps
7. **Monitoring hooks:** what to check after each deployment (health checks, smoke tests, error rate comparison)

Help me build a comprehensive testing strategy for my project.

Project type: [web app / mobile / API / library / CLI]
Stack: [languages, frameworks, testing tools already in use]
Current coverage: [percentage or 'none' — be honest]
Team testing culture: [strong / weak / nonexistent / 'we write tests but they're bad']
Most critical features: [the 3-5 things that absolutely cannot break]
CI/CD: [what you use for continuous integration]
Pain points: [flaky tests? Slow test suite? Hard to write tests? No one reviews test quality?]

Design:
1. **Testing pyramid for your stack:** specific ratio of unit/integration/e2e tests with reasoning. Include which framework/tool for each layer
2. **Priority test list:** the first 10 tests to write, ranked by 'what's the worst thing that could happen if this breaks?' Include the test description and what it validates
3. **Testing patterns:** conventions to adopt (arrange-act-assert, test data factories, fixture management, mocking strategy). Include code examples in your stack
4. **5 example tests:** for your most critical feature, complete test code with setup, execution, and assertions
5. **CI integration:** how to run tests automatically, fail fast on critical tests, and parallelize slow suites
6. **Coverage roadmap:** realistic 30/60/90 day plan to reach meaningful coverage. Not just a percentage target — which parts of the codebase to cover first and why
7. **Test quality checks:** how to prevent tests that pass but don't actually verify anything (assertion-free tests, overly broad mocks, testing implementation details)

Help me assess and strategically pay down technical debt in my project.

Project age: [how long in development]
Team size: [developers working on it]
Known pain points: [parts of the codebase everyone avoids or fears touching]
Recent incidents: [bugs, outages, or delays caused by old code]
Upcoming features: [what you need to build in the next 2-3 months]
Current tech stack: [languages, frameworks, dependency versions]
Dependency age: [when were major dependencies last updated?]
Test coverage: [current state]

Provide:
1. **Debt inventory framework:** categories (code quality, architecture, dependencies, testing, documentation, infrastructure) with specific questions to audit each
2. **Risk assessment:** for each category, what's the worst realistic outcome if this debt isn't addressed? Rank by business impact, not engineering aesthetics
3. **Prioritization matrix:** plot each debt item on impact (how much it slows the team) vs. effort (how long to fix). Identify the sweet spot: high impact, low effort
4. **Sprint allocation model:** how to dedicate 20% of each sprint to debt without sacrificing feature velocity. Specific negotiation language for product managers
5. **Quick wins:** 5 debt items fixable in under a day each with disproportionate impact. Include the specific action for each
6. **Dependency audit:** which dependencies are dangerously outdated, which have known vulnerabilities, and the upgrade priority order
7. **Stakeholder communication:** how to explain tech debt to non-technical leadership in terms of business risk, velocity impact, and ROI of paying it down

Help me write technical documentation for [system/API/library/process].

**What I'm documenting:** [describe the system, feature, or process]
**Audience:** [new team members / external developers / ops team / all of the above]
**Current docs:** [none / outdated / scattered across Slack and PRs / exists but nobody reads it]
**Documentation tool:** [Notion / Confluence / README.md / Docusaurus / GitBook / other]
**Key complexity:** [what's the hardest thing to understand about this system?]

Create:
1. **Architecture overview:** high-level explanation of how the system works, aimed at someone joining the team. Include a text diagram of components and data flow
2. **Getting started guide:** from zero to 'I can run this locally and make a change' in under 30 minutes. Every command, every env var, every gotcha
3. **API reference:** for each endpoint or interface, the request/response format, auth requirements, error codes, and a curl/code example
4. **Decision log (ADRs):** template for Architecture Decision Records. Pre-fill with the 3 most important decisions already made and their reasoning
5. **Troubleshooting guide:** the 5 most common issues new developers hit, with symptoms and fixes
6. **Maintenance guide:** how to update dependencies, run migrations, deploy, rollback, and monitor. The runbook for when things go wrong at 2am

Help me write a clear PR description and commit messages for this change.

**What changed:**
```diff
[Paste the git diff or describe the changes]
```

**Why:** [the problem this solves, the feature this implements, or the tech debt this addresses]
**How:** [the approach you took and why you chose it over alternatives]
**Testing:** [how you tested this — manual steps, automated tests added, edge cases verified]
**Risks:** [what could go wrong, backward compatibility concerns, migration needs]
**Related:** [issue/ticket numbers, related PRs, Slack discussions]

Generate:
1. **PR title:** concise, follows conventional format (feat/fix/refactor/docs/chore), under 72 characters
2. **PR description:** structured with Summary, Changes, Testing, and Risks sections. Enough context that a reviewer who doesn't know the codebase can understand the change
3. **Commit messages:** if the PR should be split into multiple commits, suggest the breakdown with a message for each following conventional commits format
4. **Reviewer guidance:** which files to review most carefully, which changes are mechanical/safe to skim, and what specific feedback you want
5. **Checklist:** a PR checklist tailored to this change (tests added, docs updated, migration needed, feature flag required, monitoring added)

Help me get productive in a new programming language quickly.

New language: [the language you want to learn]
Languages I already know well: [your current languages and years of experience]
Goal: [build a specific project / switch jobs / contribute to an open-source project / expand skills]
Specific domain: [web backend / frontend / systems / mobile / data / ML / DevOps]
Timeline: [how quickly I need to be writing production code]
Learning style: [build projects / read docs / solve problems / watch videos]

Create:
1. **Concept mapping:** 'In [known language], you do X. In [new language], the equivalent is Y.' Cover the 15 most important concepts (variables, functions, error handling, concurrency, package management, testing, types)
2. **The 20/80 syntax guide:** the 20% of syntax that covers 80% of daily coding. No encyclopedic reference — just what I need to be productive
3. **First weekend project:** a hands-on project that teaches core language features (not Hello World — something that touches the file system, makes HTTP requests, handles errors, and uses the package manager)
4. **Gotcha guide:** 10 mistakes developers from [known language] make in [new language], with the correct pattern for each
5. **Ecosystem essentials:** the ONE package manager, test framework, linter, formatter, and build tool to use (not 5 options for each — just the default choice)
6. **Progression path:** after the first weekend, what to learn next in order of usefulness. Focus on the language's unique strengths, not just reimplementing what you already know