knowledge-vault/discussions/technology/Codex/5.工作项目/2026-06-16工作目录规划.md

171 lines
5.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 1
我现在准备做一个系统/产品的开发暂时叫“The Mindscape of Bro Tsong”包括了两个子系统
1. 模型库管理包括从文章中进行模型提炼模型卡和模型Index的管理
2. 问题回答,输入问题,用我的模型来回答
现在要讨论的是,路径规划。
* 建立一个`work-projects`,这里面放独立的每个具体开发项目,`The Mindscape of Bro Tsong`放在其下,远程库也叫`work-projects`和本地库对应。
* 直接建立`the-mindscape-of-bro-tsong`项目文件夹,远程库也用独立的项目文件夹。之后新项目也都独立放置。
这两种方式,各有什么优劣?
你建议用哪个?
建议用一个折中但偏第二种的结构:
`work-projects` 只作为本地上层目录,不作为承载所有项目代码的远程大仓库。
也就是:
```text
C:\Users\wangq\Documents\Codex\work-projects\
the-mindscape-of-bro-tsong\ # 独立 git repo
```
远程库叫:
```text
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` 这个目录作为工作区容器,不把它本身变成远程代码总仓。这样你同时得到:
```text
本地管理统一work-projects/
项目边界清楚the-mindscape-of-bro-tsong 独立 repo
远程身份清楚the-mindscape-of-bro-tsong
```
项目内部可以先这样分:
```text
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\`
直接用:
```text
work-projects\the-mindscape-of-bro-tsong\
```
然后把 `model_library_mvp` 当作第一阶段名称,而不是项目根目录名。
理由很简单ChatGPT 那份文档里的 `model_library_mvp` 本质上是在描述“模型管理子系统 MVP”不是一个应该脱离总产品存在的独立产品。它明确说未来整体产品还有“问题回答子系统”而当前只是先做第一个子系统的 MVP。
我会这样落地:
```text
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` 里写清楚:
```text
Project: The Mindscape of Bro Tsong
Current phase: model_library_mvp
Current subsystem: Model Library / Model Management MVP
```
不建议这个:
```text
work-projects\model_library_mvp\
```
因为它会把第一阶段误提升为独立产品。以后问题回答子系统进来时,项目关系会断。
也暂时不建议这个:
```text
work-projects\the-mindscape-of-bro-tsong\model_library_mvp\
```
因为现在还没有复杂到需要多层 monorepo。这样会让 Codex 每次都要判断“根目录规则”和“子项目规则”谁优先,`README.md`、`AGENTS.md`、`docs/` 的位置也会变得不自然。
更稳的判断是:
```text
the-mindscape-of-bro-tsong = 产品 / 系统边界
model_library_mvp = 第一阶段工程目标
```
等未来第二阶段“问题回答子系统”真的开始时,再决定是否演进为:
```text
the-mindscape-of-bro-tsong\
model-library\
qa-engine\
shared\
```
但现在第一步不需要提前拆。当前就把 ChatGPT 初始化说明中的 `model_library_mvp/` 去掉一层,内容直接初始化到 `the-mindscape-of-bro-tsong` 根目录即可。