作者 |张凯峰.
策展 |凌敏.
长期以来，软件行业一直在降低成本和提高效率。 庞大的开发周期，无望的发布时间，以及不断涌现的缺陷，都配不上这支精英团队。 生成式AI似乎带来了曙光，其表现令人耳目一新，很多人会这么认为：生成式AI可以自动生成**，成本低，可重复，也就是说，抛出的能力就像云上的资源一样。 这是否意味着不需要那么多精锐士兵？
生成式人工智能偶尔会为我们的问题抛出一个险恶的答案，但如果你稍微搜索一下，答案是不费吹灰之力的：它要么不存在，要么是无稽之谈，这与人工智能的声望不符。 这就是所谓的生成式人工智能的幻觉，它拼凑出一个虚假的答案，因为没有真实可靠的语料库。
大型模型技术仍在更新中，人们感知幻觉的程度正在逐渐下降。 但是，当它被投入到特定的领域和用例中时，幻觉效应仍在发生。 在这篇文章中，我将分享生成式人工智能在软件开发中的应用，以及它带来的三种幻觉。
不同的软件工具供应商正在迭代他们的助手产品，最著名的是 GitHub 的 Copilot，它声称可以将程序员完成任务的速度提高 55% 以上，而这些清晰的演示看起来就像在飞翔。
但这是否意味着软件的交付速度可以提高 50%？
那些用作演示的程序员是可疑的，越来越多的程序员在他们自己的项目中采用 Copilot 的反馈似乎表明，加速大多只出现在少数常用的功能实现中。 例如，对数组进行排序、初始化数据结构或一些简单的模板。
可重复的工具**留给 AI。 但是对于一个正在开发的软件，有多少类似的**需要重新开发？恐怕这值得讨论。 更不用说大多数时候，它们只需要模塑一次，包装即可使用。 还有相当大的业务量**，程序员会以多快的速度完成？您可以将足够数量的业务**交给 AI 进行生成，但安全性可能是一个更大的问题。
这里还有另外两个问题需要关注。
一是程序员是人工智能的最佳选择。 人工智能非常容易实现多套方法，以至于程序员不可避免地不得不尝试找出其中的最佳选择。
这很好？或者这样好吗？嘿，有五种不同的实现。 在切换到下一个实现之前，您需要阅读每个实现。 这种实现很优雅，但不幸的是，单元测试失败了。 替换下一个。程序员的好奇心被**助手充分激起了。 心是猿，线性思维习惯被打破了。 程序员忘记的不仅仅是开发规则，而是时间。
二是软件自身的生命周期。
显然，当轮到程序员开始编写时，已经发生了很多事情，在系统上线之前，还会有更多事情发生。 这些事情包括但不限于：收集需求、理解需求（从需求描述到用户故事）、测试、维护基础结构以及那些正在进行的修复。
我的意思是，无论人工智能帮助程序员编写的速度有多快，这个阶段都只是软件生命周期的一部分。 据统计，程序员每天只花30%的时间在写作上，更多的时间试图理解他们想要实现什么功能，以及设计和学习新技能。
人写的**难免会有缺陷，这是软件质量的基本共识。 而且似乎程序员越有经验，就越有可能产生需要很长时间才能发现的晦涩难懂的问题。 网络问题更可怕，但这种担忧是难以避免的。
AI生成的**，听起来也很高级，它会带来足够完美的结果吗？不幸的是，答案可能令人失望。
生成式AI背后的大模型是基于互联网上大量的语料库**，尽管大模型的技术一直在改进，但网络上已经存在的有偏见的数据量是相当大的。 这也包括大量的缺陷品。 这意味着程序员在助手中挑选的内容也可能有缺陷。 因为这个有缺陷的**，来自世界另一端的人可能恰好是地球这一边的选择。
可悲的是，生成式人工智能具有放大器的力量。 简而言之，如果程序员使用有缺陷的构建，Copilot 将记录该行为，并将在未来继续建议有缺陷或类似的构建。 AI 不会读取这样的**，它只是被鼓励继续交付。 我们可以预测最终结果。
prompt：a programmer is sitting at a computer desk, looking confused and frustrated. the computer screen shows a code editor with a pop-up window of github copilot suggesting incorrect code, symbolized by red error indicators and crossed-out lines in the code. the programmer is scratching their head, surrounded by crumpled **indicating multiple failed attempts. the scene conveys a sense of challenge and confusion due to the reliance on incorrect ai-generated code suggestions, leading to quality issues in software development. the room is cluttered, reflecting the chaotic situation. ）
程序员应该严格遵守团队的开发纪律，保持一致的**规范，因为这样别人就可以阅读它，并且更容易发现潜在的问题并修复它。 但助手提供的不同似乎也带来了更多的混乱。
*有缺陷，但只是其中的一个问题，软件最终会爆发成无法挽回的问题**，哪怕是一小部分。 构建软件的过程实际上是知识生产和创造的过程。 在软件生命周期不同阶段加入的角色，共同理解和分析软件的需求，然后转化为第一个需求，并在团队和人员流动的过程中传达这些肤浅的需求和知识信息。
但通常情况下，知识会衰减，知识资产的交付不可避免地会导致池子的贫乏。 例如，我看不懂**，我不能一直更新文档，整个团队被替换，等等。 这些是软件不断产生错误和问题的原因。 人工智能一直无法解决软件工程中的这些棘手问题，至少在短期内无法解决。
人工智能的助手看起来确实像消息灵通的程序员。 有些人甚至愿意将其视为结对编程实践中的合作伙伴。 招聘人员的成本一直是 IT 团队头疼的问题，因为好人太贵了，找不到合适的人，而且从头开始培训熟练的程序员需要很长时间。 有了人工智能和**助手的加持，是不是意味着一半的人可以缩小规模？
人工智能和助手不仅不能提供上述速度和高质量的保证，还期望用户有足够的经验丰富的程序员来充分发挥他们的优势。 这个有经验的程序员需要具备判断**的优缺点的能力，判断对现有生产的影响**，也需要有耐心和技巧去仔细调整提示词。
在这篇文章中，作者谈到了她在使用**助手时需要注意的诸多问题，以及她一丝不苟的内心戏。因为助手带来的不确定性，可能会造成两类风险，一类是影响第一类的质量，二类是浪费时间。 这里展示的是一个足够有经验的程序员的内省。
只有这样，助理才能安心地扮演消息灵通的新手，而经验丰富的程序员则充当守门员，而她是负责提交的人。 通过这种方式，人工智能正在改变编程体验。
作者将助手想象成一个急于帮忙、固执、说话清晰但缺乏经验的角色，所以他用AI画了这个**形象）。
人工智能和助手可以有效地解决简单和重复的问题。 但是在构建软件的过程中，有更多的场景需要人员和专业知识来解决复杂的问题。 例如，软件系统的架构复杂性和范围不断增加，对市场和业务需求的响应，跨角色的沟通和协作，以及更时尚的道德和安全问题。
虽然判断一个程序员是否足够专业和熟练还不如计数那么明显，但我们也可以说，引入AI和助手再减少开发团队的结果是不确定的，目前弊大于利。
生成式AI的本质是模式转换，从一种形式的文本到另一种形式的文本，高级助手的能力也是无与伦比的。 如果我们将涉足软件构建的人工智能助手视为许多软件工程挑战的解决方案，那么我们只是将复杂的问题视为过于简单化。
在这一点上，我们在谈论什么？
我们真正谈论的是如何衡量在软件开发中投资人工智能的有效性。 投资人工智能并不像购买助手许可证，然后坐下来降低成本和提高效率那么简单。 不断问，“我们如何衡量投资人工智能和助手的有效性？而不是问，“我们到底要测量什么？”。从 DORA 定义的四个关键指标开始是一个明智的主意：变更提前期、部署频率、平均恢复时间 （MTTR） 和变更失败率。
以下是一些基本的测量原则供参考：
衡量团队效率，而不是个人绩效。 衡量结果，而不是输出。 查看随时间推移的趋势，而不是比较不同团队的绝对值。 使用仪表板上的数据开始对话，而不是就此结束。 衡量有用的东西，而不是容易衡量的东西。 原文链接：生成式AI给软件开发带来的三大错觉：速度、高质量、人少 生成式AI 张凯峰 InfoQ 专题文章。