产研提效 01｜打破和 AI 的知识壁垒

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

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

引入工具但不引入标准

对于工具的盲目崇拜，其实在 ai 工具出现以前，就已经大量存在了。比如

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

软件开发：获取、学习并传递知识

%% 应该查找《活文档》，《知识管理》 %%

在《知识创造公司》中指出，“知识创造是一个动态的过程，涉及到隐性知识到显性知识的转化。组织需要建立一个能够促进这种转化的环境”。正如在软件开发中，开发者需要深入理解用户需求（隐性知识），设计出高效、可靠的解决方案（显性知识）。另外，在《知识管理：理论与实践》中强调“知识管理的核心在于如何有效地获取、存储、传递和应用知识。组织需要建立有效的沟通机制和平台，促进知识的流动和共享”。对于程序员来说，其实就是写的代码是否可读，下一个人维护的人是能否理解。所谓的引入 AI，无非是把知识的传递对象，变为一台机器罢了。作为程序员，我们要做的依旧是获取、学习并传递知识的过程。

标准从何而来

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

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

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

难以同频的方法论

极客时间上有相当多的课程，如《如何落地业务建模》《遗留系统开发实战》等，但无一例外都是以 Java 为示例，而且有些代码是以伪代码的形式给出的。虽说基本原理和语言及框架无关，但是在本身就知识密度极高的情况下，在脑子里重新做一层“翻译”还是非常累的。把课程链接分享给同事，效果也不是特别好。另一方面，团队价值观也不足以支撑我们将“成熟的方法论”从上至下地去推广落地。唯一的方式是，先要求自己，按照期望的流程去落地总结，