5.9 KiB
1
我现在准备做一个系统/产品的开发，暂时叫“The Mindscape of Bro Tsong”，包括了两个子系统：
- 模型库管理，包括从文章中进行模型提炼，模型卡和模型Index的管理
- 问题回答，输入问题，用我的模型来回答
现在要讨论的是，路径规划。
- 建立一个
work-projects，这里面放独立的每个具体开发项目，The Mindscape of Bro Tsong放在其下，远程库也叫work-projects和本地库对应。 - 直接建立
the-mindscape-of-bro-tsong项目文件夹，远程库也用独立的项目文件夹。之后新项目也都独立放置。
这两种方式，各有什么优劣？ 你建议用哪个？
建议用一个折中但偏第二种的结构：
work-projects 只作为本地上层目录，不作为承载所有项目代码的远程大仓库。
也就是：
C:\Users\wangq\Documents\Codex\work-projects\
the-mindscape-of-bro-tsong\ # 独立 git repo
远程库叫：
the-mindscape-of-bro-tsong
方案 A：work-projects 作为本地库和远程总库
优点是入口统一，所有开发项目都在一个地方，早期很省事；共享脚本、模板、规范也方便。缺点是边界会慢慢变糊：不同项目的 Git 历史、CI、issue、发布节奏、依赖、权限和归档都混在一起。等某个项目真正长大，想单独部署、开源、迁移、回滚或交给子线程长期维护时，会变麻烦。
这个方案适合：多个项目本来就是同一个产品矩阵，共用大量代码，同一套发布节奏，同一批维护者。
方案 B：每个项目独立 repo
优点是产品身份清楚，生命周期独立，远程仓库、README、issue、版本、部署、权限都能围绕这个产品组织。The Mindscape of Bro Tsong 现在已经不是一个零散实验，而是一个系统：模型库管理、模型提炼、模型卡、模型 Index、基于模型的问题回答。这种东西很可能会形成自己的数据结构、运行时、CLI/API、文档和测试体系，独立 repo 更稳。
缺点是如果未来有很多小项目，会多一些仓库管理成本；共享工具不能直接丢在同一个总仓里，需要抽成模板、脚手架、公共包或单独的 skills/tools 仓库。
我的建议
用第二种作为正式工程边界：the-mindscape-of-bro-tsong 独立 repo。
但本地可以保留 work-projects 这个目录作为工作区容器，不把它本身变成远程代码总仓。这样你同时得到：
本地管理统一：work-projects/
项目边界清楚：the-mindscape-of-bro-tsong 独立 repo
远程身份清楚：the-mindscape-of-bro-tsong
项目内部可以先这样分：
the-mindscape-of-bro-tsong/
docs/
apps/
packages/
data/
workbench/
两个子系统先放在同一个产品 repo 内，因为它们共享“模型”这个核心对象；不要一开始拆成两个 repo。等接口稳定后，再考虑是否把模型库、问答运行时、提炼工具拆成独立包。
这个选择也更符合你之前一贯的边界偏好：把“生产项目”和“上游讨论/资料/可复用工具”分清楚，项目内只放这个产品真正需要承担的东西。
2
我同意你的建议。
我使用ChatGPT的GPT做规划，用Codex做执行。
这是ChatGPT给的一个项目初始化说明：C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\ChatGPT成果\2026-06-16-给 Codex 的项目初始化说明 v0.1.md
我理解文档中的项目名model_library_mvp只是我的这个系统的the-mindscape-of-bro-tsong第一阶段工作，那么我是建立一个嵌套关系还是独立建立model_library_mvp。
work-projects\the-mindscape-of-bro-tsong\model_library_mvp\
or
work-projects\the-mindscape-of-bro-tsong\
work-projects\model_library_mvp\
注：work-projects按照你的建议，只是文件夹。
我建议：不要建 work-projects\model_library_mvp\，也不要先建成 the-mindscape-of-bro-tsong\model_library_mvp\。
直接用：
work-projects\the-mindscape-of-bro-tsong\
然后把 model_library_mvp 当作第一阶段名称，而不是项目根目录名。
理由很简单：ChatGPT 那份文档里的 model_library_mvp 本质上是在描述“模型管理子系统 MVP”，不是一个应该脱离总产品存在的独立产品。它明确说未来整体产品还有“问题回答子系统”，而当前只是先做第一个子系统的 MVP。
我会这样落地：
work-projects\
the-mindscape-of-bro-tsong\
README.md
AGENTS.md
docs\
PROJECT_BRIEF.md
DATA_CONTRACT.md
WORKFLOW.md
DECISIONS.md
NON_GOALS.md
HANDOFF_TEMPLATE.md
schemas\
models\
cards\
sources\
tests\
selector\
scripts\
reports\
在 README.md 里写清楚：
Project: The Mindscape of Bro Tsong
Current phase: model_library_mvp
Current subsystem: Model Library / Model Management MVP
不建议这个：
work-projects\model_library_mvp\
因为它会把第一阶段误提升为独立产品。以后问题回答子系统进来时，项目关系会断。
也暂时不建议这个：
work-projects\the-mindscape-of-bro-tsong\model_library_mvp\
因为现在还没有复杂到需要多层 monorepo。这样会让 Codex 每次都要判断“根目录规则”和“子项目规则”谁优先，README.md、AGENTS.md、docs/ 的位置也会变得不自然。
更稳的判断是：
the-mindscape-of-bro-tsong = 产品 / 系统边界
model_library_mvp = 第一阶段工程目标
等未来第二阶段“问题回答子系统”真的开始时，再决定是否演进为：
the-mindscape-of-bro-tsong\
model-library\
qa-engine\
shared\
但现在第一步不需要提前拆。当前就把 ChatGPT 初始化说明中的 model_library_mvp/ 去掉一层，内容直接初始化到 the-mindscape-of-bro-tsong 根目录即可。