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