氛围编程很快，问题来得更快（design-doc v5） - v5 版介绍：用规范化设计文档把它稳住

1.1 不清楚系统到底做了什么

系统能跑，但要逐项核对、验收、对客、交接时，谁也不确定实际会怎样。没有规范，就没有标准和尺子，无法度量。

1.2 同样的提示词得到的结果不一样

稍微变一下，比如换个窗口、换个模型、甚至换个时间，生成的内容就漂了。

粗看好像都能对的上，细看就面目全非了。

究其根因 ¹：从来没有一份确认无疑的设计。这种情况下就不是偶发抽风，是每次都在重新猜测，随意发挥。

1.3 改一处乱一堆

AI只看见眼前这几轮对话，看不见整张图。登录、价格、接口、旧逻辑，常常是按下葫芦浮起瓢。更糟糕的的是：已经不要的做法，会在某次修改里混回来，把刚改好的盖掉。

你都不知道AI什么时候想起了啥，添加了些啥，自由发挥了些啥。

如果碰上冲突（迭代后期，功能多了后几乎不可避免），直接整个系统一塌糊涂。

1.4 演示好看，一用就翻车

对于sunny day的情况和固定的场景，AI相当拿手。空数据、重复提交、中途退出、权限差一档、网络一抖，这些rainning day的事如果没人先写进设计，就得等到上线才算账。业内的人都知道欠的债都是要还的，技术债 ²越往后要还的越多。

1.5 创意活在聊天里，窗口一关就开始忘

对大部分人来说，过两周连自己都想不起来当初为啥要那么做。更别说换人了。代码还在、依据没了，等于从零猜。 很多时候需求的描述就和之前的设计冲突，甚至是设计看上去完美，但在技术架构上又不合理。

对于不合理的要求，AI往往尽量去满足，这就导致了大量的冗余，堆砌，绕线和不明所以的实现和必然的大坑。然后越改越乱，只能推倒重来。

这就是大家说的快速腐烂。

1.6 看起来快，实则慢

用AI写代码，初期进度惊人，一下子就能拿到了演示版;

后期速度也惊人，是那种填不完的坑，改不好的错的那种惊人。

只需要一两周的时间，就会被困在混沌的泥潭中动弹不得。

上面这些问题很少单独出现。共同点很简单：走得太快，什么经得起用的都没留下。

3.1 designdoc 做了什么：

把该交代的摊开——为什么做、谁在用、系统必须有什么、怎么拼、怎么验。

3.2 designdoc不做什么：

designdoc不做决策，他讲你的想法落实成详细的设计后，会汇总给你审核，审核确认之后他才可以定稿，并用做实现代码的依据。 如果中间碰到任何逻辑上的缺陷，碰撞，或是更好的方案。他也会提供方案和建议，供你选择，你做完决策后，他在继续按照你的决策来推进。

3.3 最终效果：

你永远只需要描述你关心的需求，且后期迭代则更多的是具体的功能点这种细节。但是designdoc永远将他放到整个的产品设计规划 ³中去做全盘的分析，设计，规划，复核，审查。确保新增的和已有的整个系统是协调一致的。 并且这个过程中，任何的模糊的地方，都会分析后给出建议方案，并提示你做选择和决策。

3.4 designdoc v5 的特性

1. SSOT： designdoc 遵循唯一真实可信源的设计思想。所有的设计细节都可以索引、依赖，升级、废弃和追踪。
2. 严格的审核机制。任何的设计细节，都需要最终人的审核才能定稿为正式版本。在 v5，定稿过的设计才可作为实现代码的依据——把「人审闸门」立住，也就是那时所说的产品基线雏形。
3. 几十种设计细节类型，如假设，依赖，风险，约束，流程，算法，规则，功能等等，自动的分门别类的整理和管理。不需要人操心设计规范的细节实现。
4. 设计文档采用标准的模板方式，内容涵盖软件工程领域的相关国标，IEEE的规范的内容。并且覆盖有余。
5. 作为一个技能来说，初期可能需要明确的要求AI按照designdoc的技能来编制设计文档。后期基本上只需要正常的描述需求，AI都能识别到并自动使用本技能来管理设计文档。