AI Coding时代的文档怎么写 关于AI Coding的思考（一）
在没有AI的时代，愿意自己写文档并且文档写得漂亮的程序员，会被认为是非常厉害的程序员。在AI时代来临之后，写文档的门槛变得很低了，也出现了不少流派。
比如有的流派认为应该先把文档写清楚，人来审核文档，AI来依据文档实现代码。这样有个问题，就是代码是在不断迭代的。有的小的改动，直接修改代码可能比从修改文档开始更容易。最终导致的结果就是文档和代码不一致。
如果先写代码，在每个代码文件的头部增加一些文档也是一种思路。但这也面临着同样的问题，AI不能百分之百保证代码更新了，文档一定能更新。
这里其实涉及到两个问题：一个问题是 single source of truth 原则，也就是说一个项目应该只有一个唯一的真相来源，这样可以避免歧义。另外一个问题是，代码的组织结构和文档的组织结构天然是不一样的，一个文档涉及的主题可能横穿多个代码文件。
我自己其实也没有什么好的解法，我现在用的方式其实是这样的。我不追求把一个项目建立完备的文档，我会把我对这个项目的开发经验沉淀成文档，特别是我负责的模块。对于每个项目，我有一个统一的模板。每个项目我会把它变成一个二级目录，然后在同级放一个docs目录。Docs 目录下面有三个一级目录，分别是 current、archive、working，代表三类不同状态的文档，Working 目录下面通常是按照当前的工作主题分的；current 是基于代码主线建立的，通常是按照模块来区分的。
我觉得比较有用的几个思想是：无论哪类文档，我觉得有几个文档是必须的，一个叫术语.md,因为我们有很多口头约定的命名，这些命名最好要和大致的代码位置对应起来，这样 AI 才不会理解出现偏差。比如说我们有一个业务叫拓展屏，它的本质其实是将浏览器的窗口内嵌在微信的数组窗口内部。如果直接对 AI 说“拓展屏”，它是很难理解其逻辑的。第二个文档叫Faq.md。因为代码的变动是非常频繁的，文档如果和代码一一映射，维护起来其实也很麻烦，相当于要维护两份代码。所以我觉得文档应该提纲挈领。对于每个模块，我觉得很多问题没必要把代码中已经清晰的内容放在文档里，还是在文档里面建立一个提问列表。
每次要开发这个模块的内容时，就通过 FAQ 去启动一个会话，让这个会话在一开始就能够了解 FAQ 的内容，建立一个比较可靠的上下文。
这是当前阶段的一些实践与思考，后面应该还会随着实践的增多有一些更系统的输出。