spec-to-repo
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseSpec to Repo
需求转代码仓库
Turn a natural-language project specification into a complete, runnable starter repository. Not a template filler — a spec interpreter that generates real, working code for any stack.
将自然语言描述的项目需求转换为完整、可运行的启动代码仓库。这不是简单的模板填充工具,而是一个需求解析器,可为任意技术栈生成真实可运行的代码。
When to Use
使用场景
- User provides a text description of an app and wants code
- User has a PRD, requirements doc, or feature list and needs a codebase
- User says "build me an app that...", "scaffold this", "bootstrap a project"
- User wants a working starter repo, not just a file tree
Not this skill when the user wants a SaaS app with Stripe + Auth specifically — use instead.
product-team/saas-scaffolder- 用户提供应用的文字描述并需要对应的代码
- 用户拥有PRD、需求文档或功能列表,需要生成代码库
- 用户说出“帮我构建一个能……的应用”“搭建这个项目的脚手架”“初始化一个项目”等需求
- 用户需要可运行的启动代码仓库,而非仅仅是文件目录结构
请勿使用本工具的场景:用户需要包含Stripe + 认证功能的SaaS应用——请改用。
product-team/saas-scaffolderCore Workflow
核心工作流程
Phase 1 — Parse & Interpret
第一阶段——解析与理解
Read the spec. Extract these fields silently:
| Field | Source | Required |
|---|---|---|
| App name | Explicit or infer from description | yes |
| Description | First sentence of spec | yes |
| Features | Bullet points or sentences describing behavior | yes |
| Tech stack | Explicit ("use FastAPI") or infer from context | yes |
| Auth | "login", "users", "accounts", "roles" | if mentioned |
| Database | "store", "save", "persist", "records", "schema" | if mentioned |
| API surface | "endpoint", "API", "REST", "GraphQL" | if mentioned |
| Deploy target | "Vercel", "Docker", "AWS", "Railway" | if mentioned |
Stack inference rules (when user doesn't specify):
| Signal | Inferred stack |
|---|---|
| "web app", "dashboard", "SaaS" | Next.js + TypeScript |
| "API", "backend", "microservice" | FastAPI (Python) or Express (Node) |
| "mobile app" | Flutter or React Native |
| "CLI tool" | Go or Python |
| "data pipeline" | Python |
| "high performance", "systems" | Rust or Go |
After parsing, present a structured interpretation back to the user:
undefined读取需求内容,自动提取以下字段:
| 字段 | 来源 | 是否必填 |
|---|---|---|
| 应用名称 | 明确指定或从描述中推断 | 是 |
| 应用描述 | 需求的第一句话 | 是 |
| 功能特性 | 以项目符号或句子描述的功能行为 | 是 |
| 技术栈 | 明确指定(如“使用FastAPI”)或从上下文推断 | 是 |
| 认证功能 | 需求中提及“登录”“用户”“账户”“角色”等关键词时 | 可选 |
| 数据库 | 需求中提及“存储”“保存”“持久化”“记录”“ schema”等关键词时 | 可选 |
| API接口 | 需求中提及“端点”“API”“REST”“GraphQL”等关键词时 | 可选 |
| 部署目标 | 需求中提及“Vercel”“Docker”“AWS”“Railway”等关键词时 | 可选 |
技术栈推断规则(用户未明确指定时):
| 信号 | 推断出的技术栈 |
|---|---|
| “Web应用”“仪表盘”“SaaS” | Next.js + TypeScript |
| “API”“后端”“微服务” | FastAPI(Python)或Express(Node) |
| “移动应用” | Flutter或React Native |
| “CLI工具” | Go或Python |
| “数据管道” | Python |
| “高性能”“系统级” | Rust或Go |
解析完成后,向用户展示结构化的理解结果:
undefinedSpec Interpretation
需求理解结果
App: [name]
Stack: [framework + language]
Features:
- [feature]
- [feature]
Database: [yes/no — engine]
Auth: [yes/no — method]
Deploy: [target]
Does this match your intent? Any corrections before I generate?
Flag ambiguities. Ask **at most 3** clarifying questions. If the user says "just build it", proceed with best-guess defaults.应用名称: [名称]
技术栈: [框架 + 语言]
功能特性:
- [功能1]
- [功能2]
数据库: [是/否 — 引擎类型]
认证功能: [是/否 — 实现方式]
部署目标: [目标平台]
以上是否符合你的需求?生成前是否需要修改?
标记模糊的内容,最多提出3个澄清问题。如果用户说“直接构建”,则基于最佳默认值继续执行。Phase 2 — Architecture
第二阶段——架构设计
Design the project before writing any files:
- Select template — Match to a stack template from
references/stack-templates.md - Define file tree — List every file that will be created
- Map features to files — Each feature gets at minimum one file/component
- Design database schema — If applicable, define tables/collections with fields and types
- Identify dependencies — List every package with version constraints
- Plan API routes — If applicable, list every endpoint with method, path, request/response shape
Present the file tree to the user before generating:
project-name/
├── README.md
├── .env.example
├── .gitignore
├── .github/workflows/ci.yml
├── package.json / requirements.txt / go.mod
├── src/
│ ├── ...
├── tests/
│ ├── ...
└── ...在编写任何文件前先设计项目架构:
- 选择模板 — 匹配中的对应技术栈模板
references/stack-templates.md - 定义文件目录 — 列出所有将创建的文件
- 功能与文件映射 — 每个功能至少对应一个文件/组件
- 设计数据库Schema — 若涉及数据库,定义表/集合的字段及类型
- 识别依赖项 — 列出所有带版本约束的包
- 规划API路由 — 若涉及API,列出所有端点的方法、路径、请求/响应格式
生成前向用户展示文件目录:
project-name/
├── README.md
├── .env.example
├── .gitignore
├── .github/workflows/ci.yml
├── package.json / requirements.txt / go.mod
├── src/
│ ├── ...
├── tests/
│ ├── ...
└── ...Phase 3 — Generate
第三阶段——代码生成
Write every file. Rules:
- Real code, not stubs. Every function has a real implementation. No or
// TODO: implementplaceholders.pass - Syntactically valid. Every file must parse without errors in its language.
- Imports match dependencies. Every import must correspond to a package in the manifest (package.json, requirements.txt, go.mod, etc.).
- Types included. TypeScript projects use types. Python projects use type hints. Go projects use typed structs.
- Environment variables. Generate with every required variable, commented with purpose.
.env.example - README.md. Include: project description, prerequisites, setup steps (clone, install, configure env, run), and available scripts/commands.
- CI config. Generate with: install, lint (if linter in deps), test, build.
.github/workflows/ci.yml - .gitignore. Stack-appropriate ignores (node_modules, pycache, .env, build artifacts).
File generation order:
- Manifest (package.json / requirements.txt / go.mod)
- Config files (.env.example, .gitignore, CI)
- Database schema / migrations
- Core business logic
- API routes / endpoints
- UI components (if applicable)
- Tests
- README.md
编写所有文件,遵循以下规则:
- 真实代码,而非占位符:每个函数都有真实实现,禁止使用或
// TODO: implement等占位符。pass - 语法合法:每个文件在对应语言中可正常解析,无语法错误。
- 导入与依赖匹配:所有导入的包必须在清单文件(package.json、requirements.txt、go.mod等)中存在。
- 包含类型定义:TypeScript项目使用类型注解,Python项目使用类型提示,Go项目使用带类型的结构体。
- 环境变量配置:生成文件,包含所有必填变量,并添加注释说明用途。
.env.example - README.md:包含项目描述、前置条件、安装步骤(克隆、安装依赖、配置环境变量、运行)及可用脚本/命令。
- CI配置:生成,包含安装、代码检查(若依赖中有检查工具)、测试、构建步骤。
.github/workflows/ci.yml - .gitignore:根据技术栈生成合适的忽略规则(如node_modules、pycache、.env、构建产物等)。
文件生成顺序:
- 清单文件(package.json / requirements.txt / go.mod)
- 配置文件(.env.example、.gitignore、CI配置)
- 数据库Schema / 迁移文件
- 核心业务逻辑
- API路由 / 端点
- UI组件(若涉及)
- 测试文件
- README.md
Phase 4 — Validate
第四阶段——验证
After generation, run through this checklist:
- Every imported package exists in the manifest
- Every file referenced by an import exists in the tree
- lists every env var used in code
.env.example - covers build artifacts and secrets
.gitignore - README has setup instructions that actually work
- No hardcoded secrets, API keys, or passwords
- At least one test file exists
- Build/start command is documented and would work
Run against the generated directory to catch common issues.
scripts/validate_project.py生成完成后,执行以下检查清单:
- 所有导入的包在清单文件中存在
- 所有导入引用的文件在目录中存在
- 列出了代码中使用的所有环境变量
.env.example - 覆盖了构建产物和敏感信息
.gitignore - README中的安装说明可正常执行
- 无硬编码的密钥、API密钥或密码
- 至少存在一个测试文件
- 构建/启动命令已文档化且可正常运行
运行检查生成的目录,排查常见问题。
scripts/validate_project.pyExamples
示例
Example 1: Task Management API
示例1:任务管理API
Input spec:
"Build me a task management API. Users can create, list, update, and delete tasks. Tasks have a title, description, status (todo/in-progress/done), and due date. Use FastAPI with SQLite. Add basic auth with API keys."
Output file tree:
task-api/
├── README.md
├── .env.example # API_KEY, DATABASE_URL
├── .gitignore
├── .github/workflows/ci.yml
├── requirements.txt # fastapi, uvicorn, sqlalchemy, pytest
├── main.py # FastAPI app, CORS, lifespan
├── models.py # SQLAlchemy Task model
├── schemas.py # Pydantic request/response schemas
├── database.py # SQLite engine + session
├── auth.py # API key middleware
├── routers/
│ └── tasks.py # CRUD endpoints
└── tests/
└── test_tasks.py # Smoke tests for each endpoint输入需求:
"帮我构建一个任务管理API。用户可以创建、列出、更新和删除任务。任务包含标题、描述、状态(待办/进行中/已完成)和截止日期。使用FastAPI和SQLite。添加基于API密钥的基础认证。"
输出文件目录:
task-api/
├── README.md
├── .env.example # API_KEY, DATABASE_URL
├── .gitignore
├── .github/workflows/ci.yml
├── requirements.txt # fastapi, uvicorn, sqlalchemy, pytest
├── main.py # FastAPI应用、CORS、生命周期管理
├── models.py # SQLAlchemy Task模型
├── schemas.py # Pydantic请求/响应Schema
├── database.py # SQLite引擎 + 会话
├── auth.py # API密钥中间件
├── routers/
│ └── tasks.py # CRUD端点
└── tests/
└── test_tasks.py # 每个端点的冒烟测试Example 2: Recipe Sharing Web App
示例2:菜谱分享Web应用
Input spec:
"I want a recipe sharing website. Users sign up, post recipes with ingredients and steps, browse other recipes, and save favorites. Use Next.js with Tailwind. Store data in PostgreSQL."
Output file tree:
recipe-share/
├── README.md
├── .env.example # DATABASE_URL, NEXTAUTH_SECRET, NEXTAUTH_URL
├── .gitignore
├── .github/workflows/ci.yml
├── package.json # next, react, tailwindcss, prisma, next-auth
├── tailwind.config.ts
├── tsconfig.json
├── next.config.ts
├── prisma/
│ └── schema.prisma # User, Recipe, Ingredient, Favorite models
├── src/
│ ├── app/
│ │ ├── layout.tsx
│ │ ├── page.tsx # Homepage — recipe feed
│ │ ├── recipes/
│ │ │ ├── page.tsx # Browse recipes
│ │ │ ├── [id]/page.tsx # Recipe detail
│ │ │ └── new/page.tsx # Create recipe form
│ │ └── api/
│ │ ├── auth/[...nextauth]/route.ts
│ │ └── recipes/route.ts
│ ├── components/
│ │ ├── RecipeCard.tsx
│ │ ├── RecipeForm.tsx
│ │ └── Navbar.tsx
│ └── lib/
│ ├── prisma.ts
│ └── auth.ts
└── tests/
└── recipes.test.ts输入需求:
"我想要一个菜谱分享网站。用户可以注册账号,发布包含食材和步骤的菜谱,浏览他人的菜谱,收藏喜欢的菜谱。使用Next.js和Tailwind。数据存储在PostgreSQL中。"
输出文件目录:
recipe-share/
├── README.md
├── .env.example # DATABASE_URL, NEXTAUTH_SECRET, NEXTAUTH_URL
├── .gitignore
├── .github/workflows/ci.yml
├── package.json # next, react, tailwindcss, prisma, next-auth
├── tailwind.config.ts
├── tsconfig.json
├── next.config.ts
├── prisma/
│ └── schema.prisma # User、Recipe、Ingredient、Favorite模型
├── src/
│ ├── app/
│ │ ├── layout.tsx
│ │ ├── page.tsx # 首页——菜谱信息流
│ │ ├── recipes/
│ │ │ ├── page.tsx # 浏览菜谱
│ │ │ ├── [id]/page.tsx # 菜谱详情
│ │ │ └── new/page.tsx # 创建菜谱表单
│ │ └── api/
│ │ ├── auth/[...nextauth]/route.ts
│ │ └── recipes/route.ts
│ ├── components/
│ │ ├── RecipeCard.tsx
│ │ ├── RecipeForm.tsx
│ │ └── Navbar.tsx
│ └── lib/
│ ├── prisma.ts
│ └── auth.ts
└── tests/
└── recipes.test.tsExample 3: CLI Expense Tracker
示例3:CLI费用追踪工具
Input spec:
"Python CLI tool for tracking expenses. Commands: add, list, summary, export-csv. Store in a local SQLite file. No external API."
Output file tree:
expense-tracker/
├── README.md
├── .gitignore
├── .github/workflows/ci.yml
├── pyproject.toml
├── src/
│ └── expense_tracker/
│ ├── __init__.py
│ ├── cli.py # argparse commands
│ ├── database.py # SQLite operations
│ ├── models.py # Expense dataclass
│ └── formatters.py # Table + CSV output
└── tests/
└── test_cli.py输入需求:
"用于追踪费用的Python CLI工具。支持命令:add、list、summary、export-csv。数据存储在本地SQLite文件中,无需外部API。"
输出文件目录:
expense-tracker/
├── README.md
├── .gitignore
├── .github/workflows/ci.yml
├── pyproject.toml
├── src/
│ └── expense_tracker/
│ ├── __init__.py
│ ├── cli.py # argparse命令定义
│ ├── database.py # SQLite操作
│ ├── models.py # Expense数据类
│ └── formatters.py # 表格 + CSV输出
└── tests/
└── test_cli.pyAnti-Patterns
反模式
| Anti-pattern | Fix |
|---|---|
Placeholder code — | Every function has a real implementation. If complex, implement a working simplified version. |
| Stack override — picking Next.js when the user said Flask | Always honor explicit tech preferences. Only infer when the user doesn't specify. |
| Missing .gitignore — committing node_modules or .env | Generate stack-appropriate .gitignore as one of the first files. |
| Phantom imports — importing packages not in the manifest | Cross-check every import against package.json / requirements.txt before finishing. |
| Over-engineering MVP — adding Redis caching, rate limiting, WebSockets to a v1 | Build the minimum that works. The user can iterate. |
| Ignoring stated preferences — user says "PostgreSQL" and you generate MongoDB | Parse the spec carefully. Explicit preferences are non-negotiable. |
Missing env vars — code reads | Every env var used in code must appear in |
| No tests — shipping a repo with zero test files | At minimum: one smoke test per API endpoint or one test per core function. |
| Hallucinated APIs — generating code that calls library methods that don't exist | Stick to well-documented, stable APIs. When unsure, use the simplest approach. |
| 反模式 | 修复方案 |
|---|---|
占位符代码 — 使用 | 每个函数都要有真实实现。若功能复杂,可实现简化的可用版本。 |
| 技术栈覆盖 — 用户指定Flask却使用Next.js | 始终遵循用户明确的技术偏好。仅在用户未指定时进行推断。 |
| 缺少.gitignore — 提交node_modules或.env文件 | 生成适配技术栈的.gitignore文件,作为首批创建的文件之一。 |
| 无效导入 — 导入清单文件中不存在的包 | 完成前交叉检查所有导入与package.json/requirements.txt的匹配情况。 |
| 过度设计MVP — 为v1版本添加Redis缓存、限流、WebSocket等功能 | 构建最小可用版本。用户可后续迭代优化。 |
| 忽略明确偏好 — 用户指定PostgreSQL却生成MongoDB | 仔细解析需求。明确的偏好不可违背。 |
缺少环境变量 — 代码读取 | 代码中使用的所有环境变量必须在 |
| 无测试文件 — 交付的仓库中没有任何测试文件 | 至少为每个API端点编写一个冒烟测试,或为每个核心函数编写一个测试。 |
| 虚构API — 调用不存在的库方法 | 仅使用文档完善、稳定的API。不确定时采用最简单的实现方式。 |
Validation Script
验证脚本
scripts/validate_project.py
scripts/validate_project.pyscripts/validate_project.py
scripts/validate_project.pyChecks a generated project directory for common issues:
bash
undefined检查生成的项目目录中的常见问题:
bash
undefinedValidate a generated project
验证生成的项目
python3 scripts/validate_project.py /path/to/generated-project
python3 scripts/validate_project.py /path/to/generated-project
JSON output
输出JSON格式结果
python3 scripts/validate_project.py /path/to/generated-project --format json
Checks performed:
- README.md exists and is non-empty
- .gitignore exists
- .env.example exists (if code references env vars)
- Package manifest exists (package.json, requirements.txt, go.mod, Cargo.toml, pubspec.yaml)
- No .env file committed (secrets leak)
- At least one test file exists
- No TODO/FIXME placeholders in generated codepython3 scripts/validate_project.py /path/to/generated-project --format json
执行的检查项:
- README.md存在且非空
- .gitignore存在
- 若代码引用环境变量,则.env.example存在
- 包清单文件存在(package.json、requirements.txt、go.mod、Cargo.toml、pubspec.yaml)
- 未提交.env文件(避免敏感信息泄露)
- 至少存在一个测试文件
- 生成的代码中无TODO/FIXME占位符Progressive Enhancement
渐进式增强
For complex specs, generate in stages:
- MVP — Core feature only, working end-to-end
- Auth — Add authentication if requested
- Polish — Error handling, validation, loading states
- Deploy — Docker, CI, deploy config
Ask the user after MVP: "Core is working. Want me to add auth/polish/deploy next, or iterate on what's here?"
对于复杂需求,分阶段生成:
- MVP — 仅实现核心功能,确保端到端可运行
- 认证 — 若用户要求则添加认证功能
- 优化 — 错误处理、验证逻辑、加载状态
- 部署 — Docker、CI、部署配置
完成MVP后询问用户:“核心功能已可运行。是否需要添加认证/优化/部署配置,或是基于现有内容进行迭代?”
Cross-References
交叉引用
- Related: — SaaS-specific scaffolding (Next.js + Stripe + Auth)
product-team/saas-scaffolder - Related: — spec-first development methodology
engineering/spec-driven-workflow - Related: — database schema design patterns
engineering/database-designer - Related: — full-stack implementation patterns
engineering-team/senior-fullstack
- 相关工具:— 面向SaaS的脚手架(Next.js + Stripe + 认证)
product-team/saas-scaffolder - 相关方法:— 需求优先的开发方法论
engineering/spec-driven-workflow - 相关工具:— 数据库Schema设计模式
engineering/database-designer - 相关方法:— 全栈实现模式
engineering-team/senior-fullstack