Appearance
AI 把项目越改越乱，怎么管住？
导读
AI 没有维护结构的意识，几轮迭代后就会私自建目录、散落文件、推翻原有逻辑。抓手是三样：职责槽位管住文件去哪，项目守则管住规则写什么，Git 管住改坏了能不能退回去。
工程化的本质不是写代码，是给项目建立一套没有歧义的职责契约。展开见文件夹结构怎么定，AI 才不会乱放文件？。
项目刚开头，要不要先搭文件夹结构？
要，但不用一次搭全。先定几个职责槽位，让每类东西有唯一去处。
项目初期需求还在变，目录可以少，规则不能没有。你不需要自己维护这套结构，也不建议给 AI 下达「维护文档」的任务——那会分散它的注意力。你要掌握的是抓手：东西该放哪、新增目录怎么命名。
职责槽位是什么？要建几个文件夹？
一个文件夹对应一类固定职责：存什么、能不能改、给谁看、活多久。
基础六个够用：DOCS（规格与约定）、INPUT（只读原料）、OUTPUT（产出，分 draft 与 final）、REFS（外部参考）、METHODS（工作流与运行记录）、ARCHIVE（只进不改）。复杂项目再加 SRC、SCRIPTS、TESTS、ASSETS、TEMP 等。
数字前缀（00_～06_）的好处是：AI 没有额外指令时很少主动建带编号的顶层目录，一旦它私自新建，你一眼就能看出文件漂移。
直接写完整路径不是更准确吗？
不准确，是不可移植。绝对路径绑盘符和本机目录，换台电脑、拷到 U 盘就全断，还很难批量修复。
相对路径以项目根目录为唯一锚点，整个文件夹搬走，引用照样生效。再往上一步：在项目守则里维护一张「语义别名 → 相对路径」的映射表，文档里只写 <DOCS>/spec/constitution.md 这类别名；以后改目录名，只改表里一行，业务文档一个字都不用动。
文件名能用中文吗？
尽量不用。命令行、Git、压缩工具、云同步、部分 AI 工具链都可能因为编码出问题。
中文描述写在文件内部，文件名优先英文、缩写。另外三条硬约束：不用空格（用 - 或 _）；不用 # & ? % ( ) 这类特殊符号；不用 new、test1、最终版 这种没法界定基准的名字。
槽位已经承载了一部分信息，文件名就不用重复。放在 OUTPUT/final/auth/ 里的文件，叫 login-flow.md 就够，不用叫 login方案_final.md。
项目守则到底该写什么？
全局文件只守跨项目不变的底线，项目文件当踩坑手册写。
判断标准只有一条：同一个地方，你纠正过两次以上。纠正一次可能是随机抽风，两次以上说明这里有个 AI 跨不过去的认知鸿沟，才值得用规则填上。写成可执行指令，不写成愿望——「新增接口一律写在 app/api/ 下」是指令，「注意代码质量」是愿望。
还有一条要记住：注入的规则越多，AI 越保守，回答质量越差。能不写就不写。
写完规则，怎么知道它管不管用？
拿五个词过一遍：歧义、约束力、冲突、可验证、冗余。
有没有没界定的词；换到另一个完全不同的项目是否依然成立（成立说明缺项目特异性）；是否和已有规则矛盾；能否用明确的「是 / 否」判断 AI 遵守了没有；系统提示词或代码库里是不是早就隐含了这条。
五条都过，规则才有约束力；过不了，删掉比留着好。
commit message 怎么写才不算白写？
用 type(scope): 标题 加四行正文：为什么改、来源标记、核心提示词与已知风险、边界。
text
type(scope): 一句话标题，祈使句，≤50字符，不加句号
1. 改动意图（为什么改，不要复述 diff 改了哪一行）
2. 标记来源：AI-generated / AI-assisted / human-fix
3. 核心 prompt 摘要、模型、已知风险、边界限制
4. 方便人和 AI 后续回溯项目进度不要写 update、change、wip 这类模糊描述。写好一次，每次提交就成了一份可回看、可回滚、可交给 AI 审查的轻量状态报告，不用另维护开发流水账。
踩坑库要不要建？
可以不建；建了就要清空。踩坑库只是给人看的历史，AI 不会主动去翻它。
防复发的唯一办法，是把这次排障整理成一条可执行的规则，写进项目守则或提示词，然后从库里删掉。它的终点是被固化、被清空，不是越积越多。整理时可以要求：只写已验证事实，未验证的标 TODO，根因区分「确认」和「推测」，每条写清规则、禁止、验证方式、该固化到哪个文件。
README 该怎么写？
当项目卡片写，不当技术文档写。
固定几项：项目名加一句话简介、背景与目标、当前状态、技术栈、安装与运行、文档入口、相关链接。技术细节让 Agent 补，结构由你定。它答的是「这是什么、东西在哪」，不是「做到哪了」。把每个项目的 README 路径汇总到一个总文档，那个总文档就是你的知识库入口。