项目复盘 4 分钟阅读
一次 Young 阶段 0 的仓库起步记录
记录如何在一次 Codex 协作中，为 Young 办公系统建立顶层目录、代码规范、本地基础设施入口和中文开发文档。
背景
Young 是一个面向企业办公场景的系统建设项目，目标不只是做一个普通 Web 后台，而是逐步覆盖 Web 管理端、桌面用户端、后端服务、组织权限、项目管理、OA 审批，以及未来可能连接 CAD、Tribon 等 Windows 工程软件的本地集成层。
这类项目最容易在起步时陷入两个极端：要么一上来就铺开大量空代码，让仓库看起来很完整；要么只写几份路线文档，迟迟没有可继续演进的工程入口。这次阶段 0 的目标，是在两者之间找到一个稳一点的位置：先建立仓库基础规范，但不提前制造业务实现。
关键问题
这次协作开始时，仓库里已经有技术路线和分步实施提示词。真正要回答的是几个很朴素的问题：
- 顶层目录应该如何摆放，才能承载后端、前端、桌面端和本地集成层。
- 哪些配置属于现在就应该确定的基础规范。
- 本地开发依赖应该如何被后来的人快速理解。
- 技术决策要记录在哪里，避免后续反复口头讨论。
- Docker Compose 至少应该提供哪些基础设施入口。
阶段 0 的边界也很重要：只做骨架和文档，不初始化 Maven 多模块、不生成 Vite 应用、不创建 Electron 或 .NET 占位代码。这样仓库不会被“看起来像完成了”的空实现污染，下一阶段也能从干净的基础上继续推进。
实施过程
我先让 Codex 读取了项目的技术路线文档和实施提示词，再检查当前仓库状态。文档里已经明确了 Young 的长期路线：后端采用 Java 21 LTS + Spring Boot 3.5.x + Spring Modulith，前端采用 Vue 3 + TypeScript + Vite + pnpm，桌面端采用 Electron，Windows 本地集成层采用 .NET 10 LTS + C#，工作流引擎选择 Flowable。
在这个基础上，阶段 0 落地了几个最小但必要的部分。
第一是顶层目录。仓库新增了 backend/、frontend/、desktop/、integration-host/、infra/ 和 docs/ 这些入口。每个工程目录只放中文说明文件，用来解释未来职责，不放置假代码。
第二是通用仓库规范。新增 .editorconfig 统一 UTF-8、换行、缩进和尾随空白规则；新增 .gitignore 覆盖 Java、Node、Electron、.NET、Docker、本地环境文件和常见临时产物。
第三是本地基础设施入口。infra/docker-compose.yml 先提供 PostgreSQL、Redis 和 MinIO，作为后续后端、缓存、对象存储能力的共同起点。这个 Compose 文件不是生产部署方案，而是让本地开发依赖有一个稳定入口。
第四是中文开发文档。README.md 被扩展为项目入口，指向技术路线、实施提示词、架构决策记录和本地开发说明；docs/local-development.md 说明本机需要安装的 Java、Maven、Node.js、pnpm、.NET SDK 和 Docker；docs/architecture-decisions.md 用 ADR 形式记录了关键选择。
结果
阶段 0 结束后，仓库已经具备了继续演进的基本形状：
- 根目录结构清晰，后续每个技术栈都有自己的入口。
- README 能把读者带到核心文档。
- 本地开发依赖和基础设施启动方式有文档可查。
- Docker Compose 配置可以作为后续 PostgreSQL、Redis、MinIO 的统一入口。
- 关键技术路线以 ADR 形式留下了上下文，而不是散在一次对话里。
验证也保持在阶段 0 应有的尺度：检查目录结构、查看 Git 状态，并运行 Docker Compose 配置解析，确认基础设施配置语法有效。
复盘
这一步真正有价值的地方，不是新增了多少文件，而是把“项目会长成什么样”先变成了可维护的约定。
对一个长期项目来说，仓库骨架不是装饰。它会影响后续模块边界、开发入口、文档习惯和协作成本。尤其是 Young 这种同时包含 Web、桌面、本地集成和后端业务的系统，如果阶段 0 不把边界说清楚，后面很容易把本地能力写进前端页面，把业务模块互相调用成一团，或者让基础设施配置散落到各处。
下一步可以进入后端模块化单体骨架：在 backend/ 下初始化 Maven 多模块工程，让 young-server 至少能启动并提供健康检查。那时就会从“仓库规范”进入“可运行系统”的第一块地基。