#从 Demo 生成 PRD 的 Prompt

# Task: Reverse-engineer a PRD from this codebase You are an analyst fluent in both product and engineering. The current directory is a project built largely with AI assistance ("vibecoding"). It likely has no formal documentation, and any README may be outdated or inconsistent with the implementation. Your job is to reconstruct this product's PRD **using the code as the single source of truth**, and write it to `prd.md` in the project root. ## Principles 1. **Evidence first.** Every conclusion must cite its basis: a file path, plus a line number or function name where useful. Anything without direct evidence must be labeled **(Inferred)** with your reasoning. 2. **Code > docs.** README, comments, and marketing copy are leads, not facts. When they conflict with the implementation, trust the implementation and record the conflict. 3. **Separate "built" from "planned."** TODOs, commented-out code, stub routes, mock data, and unreferenced files are planned or abandoned work. Do not present them as existing features. 4. **Don't fill gaps with assumptions.** If the code doesn't tell you, write "Cannot be determined from the code." Don't substitute common sense. ## Exploration steps (in order) 1. **Global scan:** directory structure, dependency manifests (package.json, requirements.txt, go.mod, etc.), README, .env.example, config files, deployment config (Dockerfile, vercel.json, wrangler.toml, etc.). 2. **Find entry points:** frontend routes and pages, API routes, CLI commands, cron jobs and workers, webhook handlers. Together these are the surface users actually touch. 3. **Find data definitions:** DB schemas (Prisma, Drizzle, SQL migrations, ORM models), TypeScript types and interfaces, Zod/Pydantic schemas, state stores. 4. **Find external calls:** SDK imports, `fetch`/`axios` calls to external domains, env var names (`*_API_KEY`, `*_SECRET`, `*_URL`). 5. **Trace the main flows:** pick the 1–3 most important user journeys and follow each from the UI through to data writes and external calls. 6. **Look for monetization signals:** pricing pages, paywalls, usage limits, Stripe or other payment integrations, plan/tier fields, copywriting. ## Output: write `prd.md` with the following structure ### 0. One-line summary One sentence: this product helps **[who]** do **[what]**. ### 1. Target users - Primary user persona (role, context, technical level) - Evidence: UI copy, onboarding flow, pricing tiers, permission roles (user/admin/team), domain terminology, UI language - Are there multiple roles? What can each one do? - Individual or team/enterprise? (Look for workspace, organization, invite, or seat concepts.) ### 2. Problem being solved - Core pain points (1–3) - Likely existing alternatives users rely on today **(Inferred)** - Evidence ### 3. Solution approach - Core mechanism: how does the product solve the problems above? - Core user flow: numbered steps from entry to getting value - Key design trade-offs: technical choices, what is automated, the role AI plays in the flow - Feature inventory, split into: - ✅ Fully implemented - 🚧 Partially implemented / mocked - 💭 TODOs or traces only ### 4. Core data modules and flows - Core entities, each with: name, purpose, key fields, where it's defined - Relationships between entities (1:1, 1:N, N:M) - Two Mermaid diagrams: - `erDiagram` for entity relationships - `flowchart` showing how data is created, transformed, stored, and output along the core flow, including touchpoints with external services - Data lifecycle: what is user input, what is generated by the system or AI, and what is cached or derived ### 5. Core external dependencies | Service | Category | Purpose | Critical? (does the product break without it?) | Evidence | Replaceability | |---|---|---|---|---|---| Categories: LLM/AI, database/storage, auth, payments, email/notifications, third-party data APIs, hosting/infra, analytics/monitoring. Then add: - Which dependencies likely drive the most cost **(Inferred)** - Which carry the highest vendor lock-in risk ### 6. Appendix - **Docs vs. implementation conflicts:** features the README claims that the code lacks, or the reverse - **Open questions:** things the code can't answer that should be asked of the author - **Overall maturity:** MVP / usable product / half-built, with reasoning ## Finishing up 1. Write the complete document to `./prd.md`, overwriting the file if it already exists. Use clean Markdown, and make sure the Mermaid blocks are valid syntax. 2. Before finishing, re-read `prd.md` and check that every cited file path actually exists and that nothing marked ✅ is actually a stub or mock. 3. In your final reply, give a 3–5 line summary of the product and the path to `prd.md`. Don't paste the full document into the chat.