最近踩坑经历总结---充分借助AI工具

约一个月前，收到一个任务，做第三方NVR插件。NVR本地插件，就是将对方的接口转成我们自己的协议，与云端进行交互。

第三方文档1142页。虽然做过服务器的NVR，也刚开发完了miniNVR，但真和对方对接一个完整的专业的NVR，还是有点懵。 

而且为了搞这个文档，问了几个圈，才有中文版本的，你可以想象，并没有其他可以值得参考的。

拿到文档，快速过一遍，分解功能 和 模块。主要是两大块，一个信息的get 和 set ,一个就是流的转发了。前者http 实现，后者rtsp实现。

这两块都要鉴权。那就先把 第一块弄通。 

这个插件，也可以理解成NVR的客户端/代理端/转发端，从终端转发到前端显示和操作。既然是交互，之前用过MFC，那就先搞个简易的客户端。

最开始，从之前miniNVR 的http移过来，直接get。

难点一：授权，没那么简单

他们的授权用的digest，虽然 借助postman  和 deepseek, 授权代码很快出来了，但是和http结合还是有不少问题。主要是格式问题，

第三方不是标准的http换行，加上之前http的c文件写的也不标准。经过不停的调试，和修改，终于跑通。

所以，总结几个重要的点：

1. windows的单步调试非常方便，特别是对一个完全新的东西，能逐步跟踪，非常直观的看到第一步的结果还是很重要的。

2.一定要先搭建NVR+IPC的可以直接操作的环境。

3.postman 调试http命令非常方便。

4. 借助AI工具，具体很多代码可以交付给AI。我这里用的deepseek。

难点二：rtsp客户端从无到有

对于我和公司而言，应该都没有完整的自己手搓过rtsp客户端，所以要弄一个完整的可用的rtsp播放工具，还是有难度的。

真的手搓吗，时间很紧，不现实。 前面授权已经尝到了AI一点点甜头。于是开始寻求AI帮忙。但是过程没有这么直接快速。

因为我们不是同样的，这个rtsp也是要先授权的，sdp的格式和要求也是不一样的。而且AI虽然能写代码，但是也容易坏错误。

再加上，我没从头到尾弄过rtsp协议，对sdp的格式也是一个大白，后面写文件对h264的起始码和sps pps等也是第一次知道。

所以一周搞定rtsp，到写文件能出图，我觉得速度还是可以的。但真的是很费脑的，还需要二进制分析。分享几个截图：

 

 

 

 

 最后，仍然感谢 deepseek ,为我提供了完整的，可以交付的rtsp客户端。如果没有它的帮助，自己手搓，我真的不敢想像。

AI工具真的可以抵一个初级到中级的工程师，当然他对你的需求不是很了解，也会犯错误，所以你需要做的是：

1. 模块/接口的设计；

2. 代码的审查；

3. 调试分析，调整代码。

难点三：API接口之多

一个完整的产品，一千多页都是介绍接口。所以如何快速的将这些接口分类(快递里面的分拣)是对我的一个要求。

这次我再次借助了 postman 和 deepseek, 每一个接口，先用postman 找到内容，再设计接口，再交给deepseek。

其实deepseek的工作很大部分是对json格式的封装和解析。

如此反复，可以说上百个get/put接口就弄完了，我称呼为 批量生成接口。

 所以，这里除了借助这些工具外，重要的厘清思路厘清你的需求，进行合理的设计。

 

前面说的都是主体中的主体，后面还有一些插曲的经验，也值得总结：

1.  标清不出图，主要是通道号变了，子码流和主码流 对应一个算法，子码流在主码流基础上加一。

2.  回放不出图，是因为rtsp协议中可以定义扩展字段。

这两个问题都各自折腾了两三天，主要还是对协议不熟悉！

 

我再总结一下今天wifi 信道的踩坑经历：

2.4G  一般1-13信道，而日本支持14信道，我们考虑干扰的原因需要14信道进行测试，可是14信道设置了，wifi相关的进程就是起不来。

和厂家的反馈几次，也没实质的建议。所以今天各种尝试，

1. 尝试设置频点的准确性

2. 尝试不止于日本的国家码，BO TM CN US 都试了。

3. 尝试设置 b g 的模式

4.最后，死马当活马医，设置HT20模式，竟然生效了！！！

在这个过程中，也问过AI，他的建议一直是国家码和厂家类似，最后我跟它说的结果后，他做的总结：

 后面和我硬件老大交流，在IPC测试中发现了这个规律，是对的。 所以还是多交流，多总结。