文件夹结构怎么定，AI 才不会乱放文件？

导读

工程化的本质，是给项目建立一套没有歧义的职责契约：职责槽位、相对路径、命名规则。你可以把项目的控制权完全交给 AI，但为了避免几轮之后项目彻底失控，你至少要掌握项目结构的抓手：在项目守则里注册槽位，让 AI 理解每一类内容归属；后续新增目录时，你也有统一的命名方式。

为什么开头很顺利，越往后越难

前期 AI 产出的代码、文档都能正常跑，但迭代几轮之后项目彻底乱掉。造成这样问题的原因简单得令人咋舌：严谨地说，是因为缺乏工程思维造成的，说直白一些，就是没见（没干）过。

AI 没有维护文档的意识

AI 只管产出能运行的结果，它没有长期维护意识，很容易私自新建文件夹、散落文件、改写原有结构。等到你想要修改、扩展功能时，整个项目没有清晰的抓手，你必须把项目整体再扔给 AI，继续依赖 AI 修改；而 AI 二次改动很容易推翻原有逻辑，把项目改到面目全非、彻底废掉。

我同时不建议你给 AI 下达维护文档的任务和指令，因为前文多次提到，这样会分散 AI 的注意力，非常不利于你的项目推进。

这种工程思维其实很好培养

这种工程思维只要或深或浅地参与过（哪怕盯着别人做一个项目），都能仅靠直觉有所领悟，但是要把这种工程思维写出来反而不容易：这就好比网上有很多“如何骑自行车”的帖子，但是初学者很难找到靠谱的《如何学骑自行车》的教材。这是因为前者默认你已经学会了自行车，所谓“如何骑自行车”的话题，实质是高级玩家的经验分享。

你找这种知识是因为没有经验，但学这种知识却要求你有经验。两头堵了属于是。

当然，我依然不建议现在小白去学编程，因为它的性价比只会越来越低。而且它并不能解决你目前的问题。

我给你的建议是一套无门槛的约束框架：职责槽位 + 相对路径规则 + 守则里的别名表 + 命名规范。

同样的，没有必要背，了解即可。

职责槽位：没有歧义的文件夹结构

我们先建立一个核心概念：职责槽位。你可以粗暴地把它理解为一个“专事专用的文件夹”。一个文件夹就代表一类固定职责：存放什么、能不能修改、给谁看、生命周期是什么。

常见的文件夹结构样例：

项目文件夹/
├── README.md          ← 项目卡片：这是什么，东西在哪
├── project-rules.md   ← 规则入口：AI 怎么干活
├── 00_CHANGELOG.md    ← 变更轨迹：每次改了什么，最新在上
├── 01_docs/           ← 决定“怎么做对”的文档
│   ├── spec/
│   ├── lessons.md     ← 踩坑库
│   └── bulletin.md    ← 公告板
├── 02_input/          ← 原料：还没加工的素材
├── 03_output/         ← 产出：将来要交出去的东西
│   ├── draft/         ← 未被确认的文件
│   └── final/         ← 已确认、要交出去的文件
├── 04_references/     ← 外来参照：工具、教程、别人的做法
├── 05_methods/        ← 做法：这件事本身怎么干，连同每一轮运行记录
└── 06_archive/        ← 归档：不再用了，但先别删

数字前缀的好处：视觉上有序、容易识别；AI 在没有额外指令时，很少主动新建带这套编号前缀的顶层目录。一旦 AI 私自新增顶层文件夹，你一眼就能发现它脱离了约定（文件漂移）。

高频基础槽位（绝大多数 AI 协同项目都会用到）

槽位标识	核心职责	读写权限	生命周期说明	常见子分区
DOCS	规格、需求、标准、约束、项目约定、spec、公告板、踩坑经验库	可迭代修订	项目全程持续更新，是项目的 “宪法”	spec、lessons、bulletin
INPUT	原始原料、原始数据、原始素材、外部导入源文件	只读，禁止修改原始文件	一旦入库原则上不改动；数据清洗、衍生产物放到 OUTPUT	可按素材类型分子文件夹
OUTPUT	项目产出、交付物、生成产物	可新增、可修订、定稿后谨慎改动	迭代产出，草稿流转，定稿封存	draft（待确认草稿）、final（确认定稿交付）
REFS	外部参考资料、竞品资料、教程、文献、别人的方案、截图素材	只读查阅	只收集外部素材，不在这里改写内容	可按来源 / 主题分类
METHODS	工作流、处理逻辑、实验方案、运行记录、复盘、处理口径、脚本思路	持续迭代	跟着每一轮实验、开发迭代更新，记录 “怎么做”	runs（每轮运行快照 / 日志）
ARCHIVE	归档、废弃方案、旧版本、淘汰文档、过期中间稿	只读封存，只进不改	移出活跃迭代流，备查，不删除	按版本 / 时间归档

按需扩展槽位（复杂项目、调研、数据分析、Vibe Coding 工程项目启用，简单项目不用建）

槽位标识	核心职责	读写权限	生命周期说明	常见子分区
SRC	手写源代码、业务代码（前端 / 后端脚本）	频繁修改	项目核心开发区，持续迭代	components、utils、api、hooks 等代码子目录
SCRIPTS	一次性工具脚本、数据清洗脚本、导出脚本、辅助工具，和主业务代码解耦	可修改	用完可留存，废弃脚本移入 archive	按用途分组
TESTS	测试用例、测试脚本、测试报告、校验规则	随代码 /spec 同步更新	跟随迭代维护	unit、e2e
ASSETS	项目内使用的素材：图标、配图、字体，参与打包编译	可新增、替换	随项目迭代更新	区分处理后资源
PUBLIC	静态资源，直接对外托管、不经过编译处理	可新增、替换	对外静态访问
TEMPLATES	文档模板、报表模板、提示词模板、组件模板	谨慎修改，模板一旦定版尽量不动	模板是基准，实例化副本放到 output
NOTES	私人随手笔记、临时想法、碎片化思路，不对外	自由读写	低约束，仅个人备忘，不纳入正式交付
TEMP	真正临时缓存、中转文件、一次性中间产物	可随时删除	用完即清，gitignore，绝对不长期留存	不要和 archive 混为一谈
BACKUP	项目快照、独立异地备份（一般放在项目根之外，跨盘）	只写入，不直接在备份里编辑	备份只读，源文件修改后再生成新快照	按版本 / 哈希归档

文件夹命名不是固定的，中英文都行，你能看懂，而且AI 不会产生歧义就足够，但客观上确实存在优劣之分：没有歧义是底线，行业里的固定搭配优先使用。

举具体例子：

plan 和 methods 在中文里都可能被叫成“方法、计划”，但在英文里，plan 更偏向“打算怎么做”，methods 更偏向“用什么方法去做”。

所以用来存放想法和未验证的工作流，以及每一轮怎么干的运行记录，最好选择 methods 给这个文件夹命名。

让槽位真正生效：相对路径 + 别名表

真正让这套契约跑起来的是两层机制：

第一层：使用相对路径，替代绝对路径

• 绝对路径： 绑定盘符、本机目录，项目迁移、拷贝到 U 盘、换电脑，链接直接失效，而且很难批量修复。

绝对路径样例：D:\project\openbook\docs\spec\constitution.md。

• 相对路径： 以项目根目录作为唯一锚点。只要项目文件夹整体迁移，根锚点不变，所有引用自动生效。它解决可移植性。

相对路径样例：docs/spec/constitution.md

绝对路径是 \；相对路径是 /。

第二层：别名代号，维护单一真相源

在项目守则里维护一张映射表：语义别名 → 相对路径。文档里只写别名，例如 <DOCS>/spec/constitution.md。后续如果你调整了文件夹名字、调换层级，只修改守则里的某一行映射，所有业务文档不用改动。

总结

在项目文档里新建一份项目守则，里面放一个这样的表格。

代号	含义	真实位置
<ROOT>	项目根目录	./
<DOCS>	标准与规格文档	01_docs
<INPUT>	原始输入原料，不可修改	02_input
<OUTPUT>	交付产出物	03_output
<REFS>	外部参考资料	04_references
<METHODS>	工作方法、迭代记录	05_methods
<ARCHIVE>	归档封存目录	06_archive
<BACKUP>	独立外部备份	F:\backup\my-project

这才是这套体系的核心：文档依赖语义，不依赖磁盘路径。 AI 收到指令「写一份 spec 文档」，它不需要猜路径，直接查表，把内容放到对应槽位。

文件命名规则：同目录下，区分单个文件

这里面存在一个经常被人忽视的细节，槽位（文件夹）已经承载一部分信息了，所以文件名尽量折叠，不用已经明确的信息。比如文件放在 <OUTPUT>/final/auth/，槽位已经说明：产出、定稿、认证模块。

• ❌ login方案_final.md

• ✅ login-flow-spec.md

完整文件命名公式（上限，按需折叠）：

[三位编号]_[领域]_[简短描述]_[文档类型].[扩展名]

示例：042_auth_login-flow-spec.md

普通文档直接精简为：login-flow.md、refund-rules.md、meeting-notes_2026-09-30.md

版本号规范：优先语义版本 + Git 短哈希

版本号用于快照、打包交付物（zip、pdf 等）。 哈希本身是内容唯一标识，自带迭代身份，是这套体系的主干。

推荐主格式：[项目名]-v[语义版本]-[Git短哈希].[扩展名] 示例：todo-list-v1.0-a3f8c21.zip

语义版本给人看：v1.0 可用版，v1.1 微调，v2.0 重大变更； 短哈希给机器、给核验用：相同哈希 = 内容完全一致，规避人工忘改版本号的问题。

日期属于可选附加字段，不是必需品。如果你需要一眼看交付时间，可以追加： [项目名]-v[语义版本]-[Git短哈希]-[日期].[扩展名] 示例：todo-list-v1.0-a3f8c21-2026-09-30.zip

还没有使用 Git 时，退化为简化版：[项目名]-v[版本]-[日期].[扩展名]

硬约束（全局生效）

① 文件名尽量不用中文 中文文件名存在编码兼容风险：命令行、Git、压缩工具、云同步、部分 AI 工具链都可能出现乱码、读取失败。中文描述写在文件内部，文件名优先英文、缩写。

② 不要用空格 空格在终端里会被识别成参数分隔符；用 - 或者 _ 替代。

③ 规避特殊符号 # & ? % ( ) 等符号在 URL、命令行有特殊语义，容易转义报错；文件名只使用字母、数字、-、_、.。

④ 拒绝无意义、容易产生版本灾难的名字

禁用词	风险说明
new	无法界定 “新” 的基准，版本混乱
test1/test2	如果它需要留存，它就不是临时测试文件
最终版、最最终版	人为版本标记不可靠，容易无限套娃