- 主题:今年我最想感谢的是lvsoft老师
每天一万行代码，不说debug、调整，连基础功能测试的时间都不够吧。
【 在 hotfix 的大作中提到: 】
: lv老师做了很多关于AI的分享，他说的很多观点我都认同，大多是因为心底本来就是这样想的，所以很容易产生共鸣。
:
: 但对我触动最大的是，得知他每天可以用AI写一万行以上的代码。
: ...................
--来自微微水木3.5.16
--
FROM 114.85.152.*
我估计你没明白我的意思。举个简单例子吧：做个网页登录页面，大概也就几百行代码吧。实现是否合乎要求有很多地方需要检查的：比如用户名的字符集；用户名最长最短限制；密码最长最短限制；密码错误时的提示是对话框还是消息框，一直保留还是定时自动消除；密码输错几次后要不要暂时锁定，三次锁定还是五次锁定....定义出这些行为就需要很多时间，检查它们需要更多的时间，上万行代码则意味着是上面几十倍的工作量....你说用AI生成自动检查/测试的代码是吧，那么还要先检查/测试这些自动检查/测试的代码...
最后说一句，在软件开发项目里面，coding只占很小一部分，AI辅助确实可以大幅度提高coding的效率，但是整体的工作效率其实提高远没那么多。
【 在 prettyPIG 的大作中提到: 】
: 我理解你这就跟lvsoft的认知和能力不同，对他来说可能debug，调整，测试都大部分
: 是自动的。
: 【 在 debi 的大作中提到: 】
: ...................
--来自微微水木3.5.16
--
修改:debi FROM 114.85.152.*
FROM 114.85.152.*
前天写了很多被吞了，再写试试。
其实我想说的是：代码量大了以后各种问题都会碰到，即使不考虑coding的错误，还有大量的其他问题。我前面举的网页登录的例子说的是需求描述很难早期就很详尽，需要不断检查改进，这些都需要大量时间。还有比如算法不够全面无法覆盖所有场景，比如性能不足，比如很难考虑到的并发问题等等，这些都是我曾经碰到过的问题，而这些可能都需要花费很多时间去发现去解决。
以楼主所说的每天一万行代码的速度，我写过的所有代码加起来恐怕还不到人家一个月的量。那么我碰到过的问题他是不是也应该都会碰到过类似的。下面是几个我曾经碰到过的困难，看看哪个能在有AI的情况下轻松解决：
好多年前我参与研制第一代国产数字式声呐，数字信号处理部分我们用的是一个比较小众的DSP处理器，波束形成部分的性能要求最高，为了充分利用处理器的并行能力，我花了两个星期的时间，把整个数据结构大调整几次，把最内层循环从21条汇编指令减少到19条，还发现并绕过了一个处理器的BUG。
还是好多年前在华为北研所呆过大半年，当时有一个intel新出的网络处理器，华为准备用这个处理器做一个路由器上的转发板。操作系统是vxworks，因为板载存储空间有限，所以板子上只有一个BSP（board support package），由这个BSP做一些基础自检，设备驱动然后加载操作系统。intel有一个demo板以及相应的BSP，这个BSP是从网口加载操作系统。而华为自己开发的板子要从串口加载操作系统。我的工作就是做这个BSP，主要就是在人家BSP的基础上把网口驱动换成串口驱动，简单吧。我的程序在intel的demo板上跑的很好；同时，硬件团队做的板子跑intel的BSP也很好，但是他们的板子跑我的程序就跑飞了。因为这个时候什么驱动都没有，没有输入输出，常规调试手段都没有。板子上有4个led灯可以控制开关，就是0～15共16个状态。我就靠这个来做调试。硬件团队在深圳，他们说他们板子跑intel提供的BSP很好，所以问题肯定是软件，所以没人配合我调试。我自己一个人调了两星期没搞定，最后华为放弃了intel的网片呵呵。多年以后回想，我怀疑是板子的供电部分有问题，导致某些器件供电不稳，但只是一个永远无法获得答案的猜测了。
下面一个事情刚好就是上周五我跟团队回顾上个月生产环境问题中的一个。一个生产问题的原由之一是数据库有两条商品价格记录，商品名这些都相同，只是规格一个是1T，另一个是1t。我就问这个数据库里应该是一条记录还是两条记录，大家想想觉得应该是一条记录，大概是由于某些数据导入时造成的。那我就说去检查一下数据库是否还有类似情况，同时也看看导入时是否要对大小写进行处理。然后通过需求产品到业务沟通一圈，两个小时以后的结论是保持不变。具体到这个例子（1T和1t的商品）很可能是一个东西，但是不排除某些商品会有比如3X和3x是不同规格的情况，我们现在无法区分，就只能保留。
【 在 hothail 的大作中提到: 】
: 我想替lvsoft说几句，虽然我只是部分认同他的想法
:
: 他可能主要方面，可能是性能密集的，无/少UI的， 可以的指标评判的一些功能/函数
: ...................
--来自微微水木3.5.16
--
FROM 114.85.152.*
你似乎误解了我说的这个问题。
现在从业务的反馈是，不能排除存在这样的情况：某种商品的规格是大小写敏感的。比如说，都是A厂生产的钢管，一个规格是3X，另一个规格是3x，是两种不同的钢管，所以系统需要支持这种情况。
而我们生产问题的状况是：有两种商品，其他信息都相同，规格分别为1T和1t，这里的T/t是ton的意思。这两条记录我们人为判断应该合并为一条，产生的原因是原来系统里已有规格为1T的商品，后来通过数据导入从外部系统里导入了一条规格为1t的商品，系统无法判断这个1t与已有的1T是否是同一种商品。外部系统不是我们能控制的，不存在能标识商品种类的唯一性ID。
【 在 KnightZorro 的大作中提到: 】
: 我有一个电商系统, 物品上架系统因为描述有大小写不同, 相同物品上架了两次, 如何改进系统?
:
: 这是一个非常典型、而且“成熟系统一定会踩到”的问题。可以从技术层、业务层、流程层三个维度系统性改进，而不是只做“字符串转小写”这种补丁式修复。
: ...................
--来自微微水木3.5.16
--
FROM 114.85.152.*
不是藏着不说。而是现实中很多信息很多规则都不是一开始就全部给你摆出来的，是在实际运行中碰到问题才逐步发掘的。
这种情况不是现在引入AI就能迅速解决的，这就是我所说的：整个软件项目里coding占的时间只是很小一部分。目前的AI可以帮助大幅提高coding效率，但整体效率很难有楼主说的那么夸张。
【 在 hotfix 的大作中提到: 】
: lv老师做了很多关于AI的分享，他说的很多观点我都认同，大多是因为心底本来就是这样想的，所以很容易产生共鸣。
:
: 但对我触动最大的是，得知他每天可以用AI写一万行以上的代码。
: ...................
--来自微微水木3.5.16
--
FROM 101.84.198.*