我的软件工程经验集（草稿）

需要有一个固定的功能测试流程，可以写成行为脚本让人工测试，或者写成程序脚本跑程序测试，这是为了避免“每更新一次就出一个BUG”——我5月24日对EZTor进行了前端更新，但是后端数据库接口出了BUG，还好用的人不多（日活几近于零）。

需要有一个测试服务器，用于容灾上线，等上线测试没有BUG之后，再用极小的改动平滑上线正式服务器。

不需要学任何东西才能开始软件制作，因为有AI了。AI是普通人拓展能力边界最低成本的工具。

需要有一个经验记录集，可以是你的本子，可以是你的电脑，也可以是一个像这样的博客网站，用于记录自己在运行网站/制作软件的时候出现了什么BUG，怎么修复的。作业抄多了也会做（看AI做多了，自己记下来了，自己也会了）

当涉及到终端指令时，别直接描述问题让AI给指令然后直接输入到终端里，因为AI没有验证思维，它不知道现在是什么情况，听了你一点描述就以为自己知道全貌了，然后给了一堆指令，这些指令可能无法解决你的问题，甚至可能不适配你的环境/系统。正确做法是：先让告诉AI，终端指令运行在什么系统下，贴回给AI，然后再让AI给出验证问题所在的指令，再贴回给AI，最后再用AI给的指令执行

以退为进。如果我问AI有没有BUG，AI说实在没有BUG了，真的没有BUG了，不要相信AI，因为有时候AI也不能全面看待事物。代码运行没有BUG，用户操作时，程序互相叠加就有可能触发BUG。方法：比如说要添加一个功能，AI会给出方案，AI把这个方案吹的天花乱坠，这时，说“我想驳回这个建议/方案，请给我理由”，这时AI就会老实找出BUG了

需求是否为真？每当我们想添加新功能/开发新项目时，先冷静下来，不要开发，因为这个需求可能早已经有替代品了，或者可能就是一个伪需求。怎么做呢？先放个两三天，如果这两三天里，你老是想，“如果有这个功能就好了”，那就做，如果不是老想，就再放一放，直到自己发现，原来不用这个也可以的时候，就证明了这是一个伪需求。当然，开发热情可能就此被磨灭。然而，其实并非磨灭，而是保留，因为开发出来的东西不能满足需求才是最打击人的。