最近深切的感觉vible coding 的时候，项目文档的重要性。如果谁不信文档的重要性可以用ai试试几个大项目就知道了，可能有的人最后还会怪ai写代码不行。最近做了好几个项目，基本上都是用ai 生成代码的，我没写过一个字。
我还是不愿意自己写，虽然自己之前写过很多年的代码，但是当遇到要重复写，大批量的写的时候，还是ai 来直接写好一些。节约时间而且不会让人很累。
当用ai写的时候，好的文档设计就是关键。这个跟做架构师和项目经理一样的道理，只有清晰的目标路线计划和分工才能把项目做的大做的强。但如果只是简单的demo可能就不需要太多的文档设计。这里说的文档设计是一个持续迭代和更新的项目。
我的实际经验的坑就是。第一在项目开发过程中，很多模块和细节的实现是随着项目的开发进度进行到一定阶段才出现的，那么有些实现的方式和细节可能会影响到后续的模块。或者后续的模块会把之前某个阶段定下来的实现方式给修改了。所以在确定了一些实现方式和架构后，就要把这些内容沉淀下来。
沉淀的地方最好就是一个地方，不能今天叫一个模块的名字，明天有加一个模块的名字，最后会非常的混乱。而且你在做其他模块开发的时候，如果把模块说明文件都加到上下文中，消耗会非常快，所以最好的方式就是把模块的实现和架构提炼和总结一下，不要ai在开发过程中生成的设计文档，规划文化和进度文档，这些都不要，开发完了或者到了一定阶段，就提炼总结到整体项目说明中，而且要精炼。
我找ai聊了下，主要确定了以下6个关键文档，这几个是要持续更新和最核心的文档。其他的比如每次开发一个模块，可能要单独生成一些模块设计，开发规划这些文档作为历史清单就行了，不要每次都传给模型，反而耽误事情。
1.业务目标文档：
1.1描述项目要解决什么问题（这里可以在每次增加模块的时候把内容补充进来，要持续更新）
1.2不解决什么问题（这里已是，持续更新）
1.3当前阶段（这里已是，持续更新）
1.4 成功标准（这个还要考虑下）
1.5技术&产品底线（这个我还不知道要写啥）
2.领域文档（就是统一一些术语，有可能你想的和ai想的不一样，把一些你要明确的概念确定下来）
就是名词解释（就写可能会有歧义的，其他通用的ai肯定比我们懂，精简）
3.模块拆分
3.1具体有哪些模块
3.2 每个模块都是做什么的，有什么要求，哪些模块ai可以改，哪些ai不能改（不过我觉得都是ai在写，还能有他不能改的？）
4.表设计
表的作用。核心表名，字段。
5.开发规范（这个就是之前写的一些rules，比如单文件多少代码，模块多少文件等）
6.决策记录（记录什么时候确定了什么方案或者约束，影响范围）
要把这个文档的说明本身作为作为一个开发规范加入到 第 5 条中。第 5 条应该作为用户根目录的rules，在项目目录中还应该有个第 5 条的rules，把文档说明加入项目的规范文档中。
用户/rules 定位用户基础的，沟通方式（中文，昵称（这个比较屌，如果不称呼你，可以就把基础规则忘了）），通用开发规范（模块拆分规范，命名规范，文件代码数量，模块文件数量），
项目/rules0定位项目基础的，项目开发规范（环境，技术选择，文档更新方式，6 个文档结构的提炼），
项目/doc/核心文档，就是上面的 6 个文档的详细（要不要全部作为上下文，放到项目rules中，再测试下，因为前面有提炼过的了）
项目/doc/模块文档，就是每次开发的时候，要做一些设计方案规划进度这些，可以放在这里。
