产研提效 01｜人工智能因何高效

大家好，我叫钟杰，我所在的公司是做低代码的，低代码行业基本都在尝试引入 AI 智能体，通过训练存量客户所搭建的应用数据，来帮助后续客户快速上手产品。大概流程就是：提出类似于“我要搭建一个生鲜市场的出入库管理系统”，之后系统会创建好一个相对完整的表单应用。然后客户在半成品上基于自己的需求，去进行更新。

在 ai 工具出现以前，客户搭建自己的应用是通过内置模板 + 帮助文档，在和公司客户成功团队的帮助下，基于自己的需求，搭建匹配业务的应用，这也是大部分 SAAS 和 低代码工具的运营模式。企业希望通过 AI 工具的引入，借此降低公司客户成功团队和客户之间的沟通时间于成本。从而服务于更多的客户来赚取更多的利润。也许是因为近两年对于各类 AI 的营销，都是以降本增效为卖点，再加上公司的盈利能力在不断下降，公司将 AI 看作了提升人效比的银弹，殊不知人效比的核心在于人（团队）的打造，而不是简单的将 AI 工具，粗暴地代替工作流程的某一个环节。

引入工具但不引入标准

这个问题其实在 ai 工具出现以前，就已经大量存在了。比如

1. “死文档式”记录：引入敏捷开发的站会、看板，却不构造通用语言，依旧以开发 90、开发了一半这种模凌两可的沟通方式。所有的业务知识记录在类似于语雀的外部文档中，随着人员的流动，我们很难追溯已有的逻辑。最后的沟通就变成了“按照线上来”，“线上咋样，不知道啊”。所谓的拆解，工时预估，也不再具有参考意义。
2. 只磨刀不砍柴：质量监测工具(SonarQube，test covery，sentry) 的根本作用在于减少人工发现代码问题的成本，但是发现问题后呢？”测试覆盖率不足是否有制定要求“，“代码重构前是否有覆盖安全网？”。工具越舔越多，质量越来越差。
3. 重复地造轮子：代码的第三方依赖中，往往存在这功能类似的不同外部依赖包，以及不少不知道在什么背景下开发，完全照抄外部依赖的 kpi 代码。完全缺少对依赖引入的审核流程。

而这次分享，我想和你聊聊，作为一个普通的基层开发，我们可以做哪些力所能及的事情，让那些外部工具，发挥真正的作用。

AI 辅助开发，真的那么好用吗

在日常开发中，我们经常会遇到外部依赖库更新导致接口变更的情况。这种变更不仅增加了项目维护的工作量，还可能引发更深层次的问题。如果仅仅是API层面的变更，我们只需花费时间和精力进行代码修改和验证。然而，有时依赖库的更新不仅仅是接口的变更，甚至改变了预期的行为，即所谓的“break change”。这种情况下，我们不仅需要调整代码，还可能需要重新审视和修改业务逻辑，这无疑增加了项目的复杂性和风险。

依赖库的用户越多，其更新影响范围就越广。依赖库的设计者和使用者之间实际上建立了一种“契约”，尽管这种契约没有纸面合同来约束双方。因此，依赖库的设计者在更新时需要谨慎，尽量避免破坏性变更，以减少对使用者的影响。

回到业务代码的设计，我们的代码终究是为了实现功能，让企业能够使用功能来赚到钱。我们设计的API首先需要清晰地表达业务功能。这时有的人可能会说，如果公司不大，人也不多，抬头不见低头见的，直接平时喊一声问一下不就好了。殊不知，公司倒闭的种子，在这时就已埋下。那么在业务代码设计中，技术之间的契约如何规定呢？谜底就在谜面上，想想业务的变更是由谁提出的，是客户。而客户会和企业签订合同，合同就是最好的契约。可以说，我们系统中的每一个功能，在背后都有一个或者多个的合同/客户，一旦这个功能不可使用或者出现违反合同内容的变更，那么带来的便是退款、产品形象损失，甚至是不得不打官司的地步。

可以说，API设计的好坏，决定了当业务发生变更时，我们要如何变更代码、变更的正不正确、变更的成本好坏的问题。AI的引入能解决这个问题吗？显然是不行的。AI它有点像是我们高考英语做的完型填空，所能做的只有基于上下文去在内置语料中，进行选择与拼接。它并不能理解我们的API是解决了什么问题，客户的业务需求又出自什么。也就是说，AI的能力极大依赖于高质量的数据，如果我们代码上下文本身质量就非常糟糕，那么AI也无法解决。

这一个系列做了什么

这个系列从完整实践了从业务建模，测试驱动提升稳定性，以及在每个阶段我使用了什么工具去提升我的效率