一个人开发多个独立项目，如何打造适合 AI 全栈开发的 Workspace？

现在越来越多独立开发者开始使用 ChatGPT、Codex、Claude Code、Cursor 等 AI 工具参与软件开发。

AI 已经不仅仅是帮我们“补几行代码”，而是逐渐参与到需求分析、架构设计、编码、测试、重构、文档维护，甚至项目管理中。

但使用一段时间之后，会出现一个很现实的问题：

项目越来越多，AI 每次进入一个项目，都要重新理解一遍。

尤其是一个人同时维护多个独立项目时，这个问题会越来越明显。

比如：

一个官网项目
一个 SaaS 项目
一个微信小程序
一个 AI 工具
一个实验性项目
一个后台管理系统

这些项目彼此之间可能完全没有关系，技术栈不同、数据库不同、部署方式不同、生命周期也不同。

如果只是随便把它们放在几个文件夹里，短期看没有问题。

但半年、一年以后，你可能连自己都会忘记：

这个项目当初为什么这样设计？
当前开发到哪一步了？
下一步准备做什么？
为什么当时选择 PostgreSQL 而不是 MongoDB？
哪些功能已经完成？
哪些问题还没有解决？
这个项目现在还能不能正常部署？
AI 修改代码时，需要遵守哪些规则？

所以，如果准备长期利用 AI 做全栈开发，我认为应该建立一套属于自己的：

AI-First Workspace。

它不是简单的代码目录，而是一套让 AI 和自己都能长期理解、维护和管理项目的工作空间。

一、先明确一个前提：不要把独立项目设计成 Monorepo

如果你是一个人开发，而且 apps/ 目录里的项目大多数彼此独立，那么不要把整个 Workspace 设计成大型公司的 Monorepo。

例如：

project-a = 法律网站
project-b = AI 写作工具
project-c = 微信小程序
project-d = SaaS 产品
project-e = 技术实验

这些项目：

没有共同业务
不共享数据库
不共享服务
不共享部署
甚至技术栈都不同

这时候，如果在 Workspace 根目录设计大量：

packages/
services/
database/
shared/

反而容易让结构变复杂。

更严重的是，AI 可能会误以为：

“这些项目属于同一个系统，可以互相依赖。”

实际上，我们真正需要的是：

Workspace 管理方法，Project 管理业务。

也就是说：

Workspace 负责统一规则
Workspace 负责模板
Workspace 负责 AI Skills
Workspace 负责 Prompt
Workspace 负责自动化脚本
每个项目则保持完全独立

这是整套设计的核心。

二、推荐的 Workspace 目录结构

对于独立开发者，我更推荐下面这种结构：

Workspace/
│
├── README.md
├── AGENTS.md
├── PROJECTS.md
│
├── apps/
│   ├── project-a/
│   ├── project-b/
│   ├── project-c/
│   └── ...
│
├── templates/
│   ├── base-project/
│   ├── web-app/
│   ├── api/
│   ├── ai-app/
│   └── miniapp/
│
├── skills/
│   ├── code-review/
│   ├── project-init/
│   ├── documentation/
│   └── release-check/
│
├── prompts/
│   ├── coding/
│   ├── debugging/
│   ├── review/
│   └── planning/
│
├── scripts/
│   ├── new-project
│   ├── project-status
│   ├── project-check
│   └── backup
│
├── docs/
│   ├── coding-standards.md
│   ├── ai-development.md
│   └── project-management.md
│
└── archive/
    ├── completed/
    └── deprecated/

这个结构看起来很简单，但它解决的是长期问题。

三、apps 目录：每个项目完全独立

apps/ 是最重要的业务项目目录。

例如：

apps/
├── website/
├── ai-writer/
├── miniapp/
├── admin-tool/
└── demo-project/

建议默认：

每个项目独立 Git
每个项目独立依赖
每个项目独立数据库
每个项目独立环境变量
每个项目独立部署

比如：

apps/project-a/.git
apps/project-b/.git
apps/project-c/.git

也就是说，Workspace 本身不一定需要成为一个统一 Git 仓库。

项目之间默认：

完全隔离。

除非未来确实有非常明确的共享需求，否则不要为了“统一”而强行共享业务代码。

因为真正宝贵的不是“所有项目都长得一样”，而是：

每个项目都可以独立生存。

四、Workspace 根目录只负责管理整个开发体系

根目录最核心的三个文件，我建议是：

README.md
AGENTS.md
PROJECTS.md

它们分别解决三个不同的问题。

五、README.md：给自己看的工作空间说明书

Workspace 的 README.md 不需要写得特别复杂，它主要回答：

这个 Workspace 是怎么组织的？

例如：

# Workspace

这是我的个人软件开发工作空间。

## 目录

apps/
独立项目

templates/
项目模板

skills/
AI Skills

prompts/
通用 Prompt

scripts/
自动化脚本

docs/
个人开发规范

archive/
已完成或停止维护的项目

## Principles

- 项目之间默认独立
- 不跨项目共享业务代码
- 重要信息必须进入项目文件
- 不依赖聊天记录保存长期上下文
- AI 修改项目之前必须先读取项目文档

这个文件更像 Workspace 使用说明。

六、AGENTS.md：整个工作空间最重要的 AI 文件

如果长期使用 AI Coding Agent，我认为 AGENTS.md 是整个 Workspace 中最重要的文件之一。

它的作用类似：

AI 开发团队的员工手册。

但 Workspace 根目录的 AGENTS.md 不应该规定具体技术栈，不要在这里强制规定所有项目必须使用同一个框架、数据库或 CSS 方案。

根级 AGENTS.md 更适合规定 AI 应该如何工作：

# Workspace AI Rules

这是一个独立开发者的多项目工作空间。

apps/ 下的项目默认：

- 相互独立
- 独立 Git 仓库
- 独立技术栈
- 独立依赖
- 独立数据库
- 独立部署
- 独立环境变量

除非项目文档明确说明，否则不要：

- 建立跨项目依赖
- 修改其他项目
- 复制其他项目业务逻辑
- 强制不同项目采用相同技术栈

## Before Coding

进入某个项目后：

1. 阅读项目 AGENTS.md
2. 阅读 PROJECT.md
3. 阅读 STATUS.md
4. 阅读 ARCHITECTURE.md
5. 检查现有代码
6. 搜索是否已经存在相关实现
7. 再开始修改代码

项目级规则优先于 Workspace 级规则。

## Development Principle

优先顺序：

reuse
>
extend
>
create

不要未经调查直接新建：

- component
- service
- API
- database table
- dependency
- utility

## Completion

任务完成后，需要说明：

- 修改了什么
- 修改了哪些文件
- 是否影响架构
- 是否影响数据库
- 是否影响 API
- 是否完成测试
- 是否存在风险

这样，无论未来换什么 AI 工具，只要它能读取这个文件，就可以快速理解你的工作方式。

七、PROJECTS.md：单人开发者的项目驾驶舱

一个人维护多个项目时，最容易失控的不是代码，而是忘了自己到底有多少项目。

因此非常建议在 Workspace 根目录增加一个 PROJECTS.md，把它当作整个 Workspace 的项目总台账。

# Projects

| Project | Path | Status | Type | Stack | Priority | Next |
|---|---|---|---|---|---|---|
| Website | apps/website | Active | Web | Next.js | P1 | 完成文章系统 |
| AI Writer | apps/ai-writer | Active | AI App | Python | P2 | 接入支付 |
| MiniApp | apps/miniapp | Planning | WeChat | Native | P2 | 完成原型 |
| Demo X | apps/demo-x | Paused | Experiment | Vue | P3 | 暂停 |

以后还可以增加 Repository、Production URL、Deployment、Database、Last Updated 等字段。

这样，半年以后重新打开 Workspace，你可以在一分钟之内知道整个开发情况。

八、每个项目必须做到“自解释”

Workspace 设计再漂亮，如果每个项目内部一团乱，AI 还是无法长期维护。

我认为每个项目应该达到一个目标：

随便让一个新的 AI Agent 进入项目，它能快速理解项目是什么、做到哪里、为什么这样设计。

因此推荐每个项目采用：

project/
│
├── README.md
├── AGENTS.md
├── PROJECT.md
├── STATUS.md
├── ARCHITECTURE.md
├── DECISIONS.md
│
├── docs/
├── src/
├── tests/
├── scripts/
│
├── .env.example
├── .gitignore
└── package.json / pyproject.toml / ...

对于一个人开发来说，这套已经足够。

九、为什么我只推荐 6 个核心文件

团队开发可能需要 PRD、TASKS、CHANGELOG、API、DATABASE、SECURITY、TESTING、DEPLOYMENT 等文件。

但如果你一个人同时维护十几个项目，就会出现一个问题：

维护文档本身变成了工作。

所以更推荐下面六个文件作为基础：

README.md
AGENTS.md
PROJECT.md
STATUS.md
ARCHITECTURE.md
DECISIONS.md

真正有需要的时候，再继续拆分。

十、README.md：告诉人“怎么运行”

项目里的 README.md 建议保持偏工程化，包含：

项目名称
安装依赖
环境配置
本地运行
测试
构建
部署

它回答的是：

这个项目怎么跑起来？

不要把所有业务说明全部塞进 README。

十一、PROJECT.md：告诉 AI“这是什么项目”

PROJECT.md 和 README 的职责不同。

README 是怎么运行，PROJECT 是为什么存在。

# Project

## Overview

这是一个帮助用户管理 XXX 的 Web 应用。

## Problem

用户目前存在：

- 问题 A
- 问题 B
- 问题 C

## Users

主要用户：

- 用户 A
- 用户 B

## Core Features

- 用户注册
- 内容管理
- 搜索
- AI 问答

## Scope

本项目负责：

...

本项目不负责：

...

## Tech Stack

Frontend:
Backend:
Database:
AI:
Deployment:

## External Services

- OpenAI
- Stripe
- AWS

对于中小型项目，甚至可以把 PRD 直接合并到这里，减少文件数量。

十二、STATUS.md：告诉 AI“现在做到哪里了”

AI 最大的问题之一是：它知道代码是什么，但不知道项目现在处于什么阶段。

例如：

# Status

## Current

当前正在开发：

- AI 搜索

## Next

- [ ] 完成向量数据库
- [ ] 完成搜索页面
- [ ] 添加测试

## Bugs

- [ ] 移动端搜索框错位

## Backlog

- [ ] 国际化
- [ ] Dark Mode

## Recently Completed

- [x] 用户登录
- [x] 文章系统

对于独立开发者，我建议直接把 TASKS.md 合并到 STATUS.md。AI 只要读取一个文件，就知道现在在做什么、下一步做什么、有什么 Bug、有哪些待办以及最近完成了什么。

十三、ARCHITECTURE.md：告诉 AI“系统是怎么组成的”

这个文件不建议省略，因为 AI Coding 最常见的问题之一就是没有理解现有架构，就开始添加新代码。

# Architecture

## Stack

Frontend:
Next.js

Database:
PostgreSQL

Auth:
Supabase

Deployment:
Vercel

## Structure

src/app
页面和路由

src/components
UI 组件

src/lib
基础能力

src/services
业务逻辑

## Rules

页面不直接访问数据库。

数据访问统一通过：

src/services

## Main Data Flow

UI
↓
Server Action
↓
Service
↓
Database

它不用写得很长，几十行到几百行已经非常有价值。

十四、DECISIONS.md：给未来的自己留下记忆

这是单人开发者特别应该维护的文件。

团队可以问“这个东西当初是谁设计的”，但一个人开发半年之后，很可能连自己都忘了。

# Decisions

## 2026-09-26 - Use PostgreSQL

### Decision

使用 PostgreSQL。

### Reason

需要：

- 关系型数据
- 全文搜索
- Vector Search

### Alternatives

MongoDB

### Why Not

当前业务关系较强，没有必要增加新的数据库类型。

以后 AI 看到 PostgreSQL 时，就不会突然建议“要不全部改 MongoDB”，因为它可以看到这是一个已经做过权衡的设计决定。

这实际上是在建立项目的长期记忆。

十五、.env.example 也非常重要

虽然它不是文档，但推荐所有项目都有 .env.example：

DATABASE_URL=

OPENAI_API_KEY=

REDIS_URL=

STORAGE_ENDPOINT=

JWT_SECRET=

不要提交真实 Secret，但一定要让 AI 和未来的自己知道这个项目依赖哪些环境变量。

十六、什么时候需要继续拆 docs？

当项目变复杂以后，再从核心文件中拆出来：

docs/
├── PRD.md
├── API.md
├── DATABASE.md
├── SECURITY.md
├── TESTING.md
└── DEPLOYMENT.md

不需要所有项目一开始就拥有这些文件，文档应该跟项目复杂度一起增长，而不是为了“规范”而创建一堆空文件。

小项目有 PROJECT.md、STATUS.md、ARCHITECTURE.md、DECISIONS.md 就已经够用；中型项目再增加 API、DATABASE、DEPLOYMENT；大型项目再继续增加 PRD、Security、Testing、ADR、Runbook、Monitoring。

十七、Workspace 真正应该共享什么？

对于多个彼此独立的项目，不建议共享业务代码。

真正值得共享的是：

templates/
skills/
prompts/
scripts/
docs/

也就是：

共享开发能力，而不是共享业务。

这是独立开发者 Workspace 最重要的设计原则之一。

十八、templates：让新项目标准化

templates/base-project 可以直接带上：

README.md
AGENTS.md
PROJECT.md
STATUS.md
ARCHITECTURE.md
DECISIONS.md
.env.example
.gitignore

以后创建新项目，不再从空目录开始，而是复制模板、修改 PROJECT.md，再让 AI 开始开发。

十九、skills：把重复工作交给 AI

如果未来越来越依赖 AI，可以建立：

skills/
├── project-init/
├── code-review/
├── documentation/
├── security-review/
└── release-check/

例如，project-init 负责读取需求、生成项目结构、创建核心文件、初始化 Git 和生成基础 README；release-check 负责检查测试、环境变量、构建、安全问题和部署文档。

这样你的开发流程会逐渐从“每次重新告诉 AI 怎么做”变成“AI 按既定流程执行”。

二十、prompts：保存真正高价值的 Prompt

一些频繁使用的 Prompt 不要每次重新输入：

prompts/
├── coding/
├── debugging/
├── review/
└── planning/

例如保存 feature-development.md、bug-analysis.md、architecture-review.md、performance-review.md、security-review.md。

久而久之，这些会形成你自己的 AI 开发方法论。

二十一、scripts：把重复操作自动化

随着项目增加，创建项目、检查项目状态、运行测试、更新依赖、备份和生成项目列表等操作会不断重复。

可以逐渐积累：

scripts/
├── new-project
├── project-status
├── project-check
└── backup

一个好的 Workspace，后期应该越来越少依赖手工操作。

二十二、archive：不要舍不得归档项目

当某个项目已经结束、长期不维护、实验失败或被替代，就移动到：

archive/
├── completed/
└── deprecated/

让 apps/ 始终只保留当前仍然值得关注的项目，这会极大降低心理负担。

二十三、最终推荐结构

综合下来，我最推荐独立开发者采用这套 Workspace：

Workspace/
│
├── README.md
├── AGENTS.md
├── PROJECTS.md
│
├── apps/
│   ├── project-a/
│   ├── project-b/
│   └── project-c/
│
├── templates/
│   ├── base-project/
│   ├── web-app/
│   ├── api/
│   └── ai-app/
│
├── skills/
├── prompts/
├── scripts/
├── docs/
│   ├── coding-standards.md
│   ├── ai-development.md
│   └── project-management.md
└── archive/

而单个项目：

project/
│
├── README.md
├── AGENTS.md
├── PROJECT.md
├── STATUS.md
├── ARCHITECTURE.md
├── DECISIONS.md
│
├── docs/
├── src/
├── tests/
├── scripts/
│
├── .env.example
├── .gitignore
└── package.json / pyproject.toml / ...

二十四、这套结构真正解决的是什么？

表面上看，我们只是在设计文件夹。实际上是在解决五个长期问题。

1. AI 上下文丢失

通过 PROJECT.md、STATUS.md、ARCHITECTURE.md、DECISIONS.md，让 AI 不依赖聊天记录理解项目。

2. 项目越来越多以后难以管理

通过 PROJECTS.md 建立统一项目索引。

3. AI 随意修改架构

通过 AGENTS.md、ARCHITECTURE.md、DECISIONS.md 约束 AI 的开发方式。

4. 重复创建相同东西

通过 templates、skills、prompts、scripts 不断积累个人开发资产。

5. 自己半年以后忘了项目

通过 STATUS.md、DECISIONS.md、PROJECT.md 给未来的自己保留足够的信息。

二十五、我认为最重要的一条原则

如果只保留这篇文章中的一条原则，我会选择：

所有重要项目上下文，都应该进入 Git，而不是只存在于 AI 对话历史中。

聊天窗口会变，AI 工具会变，模型会变，Prompt 会变，甚至你以后可能不再使用现在的 AI 产品。

但只要项目里还有：

Code
+
Git
+
PROJECT.md
+
STATUS.md
+
ARCHITECTURE.md
+
DECISIONS.md
+
AGENTS.md

任何一个新的 AI Agent 都可以重新接手项目。

这才是真正稳定的 AI 开发工作流。

结语

对于独立开发者来说，AI 全栈开发最大的价值，并不是单纯提升写代码的速度。

真正有价值的是：

一个人开始拥有过去只有小型开发团队才能拥有的执行能力。

但前提是，你不能让所有知识都存在脑子里，也不能让所有项目上下文都存在聊天记录里。

一个好的 Workspace，本质上是在建立：

属于独立开发者自己的 AI 软件开发操作系统。

它不需要复杂。一开始只需要：

Workspace/
├── AGENTS.md
├── PROJECTS.md
└── apps/

以及每个项目中的：

AGENTS.md
PROJECT.md
STATUS.md
ARCHITECTURE.md
DECISIONS.md

就已经足以让 AI 的长期开发体验发生明显变化。

随着项目越来越多，再逐渐加入 templates、skills、prompts、scripts、archive。

不要一开始设计一个庞大的体系，先建立最小规则，然后让这套 Workspace 随着你的项目一起成长。

最终你管理的就不再只是几个代码文件夹，而是一套真正可以持续迭代、长期维护，并且能够被不同 AI 工具共同理解的：

个人 AI 全栈开发系统。