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

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

引入工具但不引入标准

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

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

建立标准前，我们可以思考什么

在技术转管理上，要避免哪些事？

技术转管理有几大天坑，救火、被动、技术崇拜：

• 救火：
  遇到问题时，身为第一个冲上去救火，大家觉得已经有人顶着了，自动就往后退。越是解决问题，底下人就越依赖，大家也就越不想挑头。最终陷入管理者累死累活，作为团队却却没什么产出的境地。
• 被动：
  在救火上耗费精力越多，自然就难以做主动管理。认为团队的动力和能力都和自己一样，交代工作时，认为只要简单把问题讲一下，团队自己就能干，其实根本做不了。最终变成“头儿，如果我能这么好，我就不在你手下当兵了。如果你真的那么牛，你也不用管我们这群大头兵了。”
• 技术崇拜：
  时刻准备着引入各种工具，逃避理解真正问题并给出定义，最后变成只会倒腾各种技术方案的架构师。

这是因为在做单纯的技术开发时，我们只需要追求解决未知技术难题带来的成就感就好了。而到了管理层以后，我们不仅要花时间精进技术能力，还得花时间在帮助他人身上（带着大家一起干成一件事）。在这里如何带就是我们要如何建立标准

面试八股文少了，如何更好的描述项目？

在过去几年，公司多，岗位多，大家都在组件团队拼谁的业务更快出来。为此快速招人，就不能那么精细，像各种原理、基础、八股等，再衡量能干活上，又快又不容易出现差错。

但是现在企业岗位减少，八股只能体现这个人准备了面试，缺不能体现出他是否能写好功能。企业为了精挑细选，自然会问点实际项目解决的问题。毕竟招一个不能胜任的人写的代码，往往会给后来的维护者带来了数不尽的麻烦。那么如何在面试甚至是简历阶段，快速体现出对项目的把控和理解能力，就变得至关重要。

如何避免能跑就行的代码？

随着生成式 AI 的发展，软件开发者渐渐从面向 google 编程，转变为了面向 AI 编程。而 AI 往往通过暴力而非抽象概念来解决问题（毕竟 AI 的长上下文输出并不怎么样），比如使用大量 if 判断条件，而非使用策略模式。开发者过度依赖生成式 AI 的结果，导致他们更加容易在“能用但很糟糕”的代码中迷失方向。在这种场景下，所谓的 codereview，不过是浪费时间走一个过场罢了。毕竟 review 出了问题，也没有方向和精力去改正。

标准从何而来

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

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

我们平时的开发中，搞库造轮子的场景还是比较少的，更多的时候还是不断和产品 battle，然后在已经不知道经历过多少风霜的代码上堆叠。我们最常见的问题就是无法准确描述出，产品需求对业务的影响与产出，也就难以获取业务方的信任，并展开特定的讨论。最终就变成了“预估开发时间超出业务预期了，业务觉得研发故意往大的预估，预估开发时间小于业务预期了，业务总会总会被插入一些看上去不大，实际带来非常多坑的所谓小功能”。我们在这里需要定义 2 套标准：一套是开发者之间的 API 协定，如何设计 API 来更好地表达业务知识，另一套标准则是如何设计通用语言让产品和开发之间，快速且精准地传递业务信息。为了构造这两套标准，我们则需要参考《领域驱动设计：软件核心复杂性应对之道》中的指导，基于业务去构造领域模型。基于模型去设计软件架构和通用语言，可以带来诸多好处，比如：

1. 新入职的人理解了模型，就能大致理解代码的结构，更快的达到 on boarding 的状态；
2. 在讨论需求的时候，研发人员可以很容易明白需要改动的代码，并对风险与进度有更好地评估；
3. 模型比代码更简洁，毕竟模型是抽象出来的，因而有更低的传递成本；

业务建模：难以落地的方法论

在 2023.10 月的时候，我初步在一次重构任务中，按照《用户故事与敏捷开发》中的事件风暴流程，进行了模型的建立。但是很遗憾，并没有很好的结果。我想主要原因在于，事件风暴是一个多人发散思考的建模方式，既然有发散，自然需要组织者负责聚合。而聚合思路并筛选这个行为，对于一个初学者来说，还是太难了，最终整个流程就变为了“看了，懂了，做了，完啦！”，在挤占 2、3 次同事的时间之后，就很难再有机会去改正之前实践中发现的问题了，提取到一半模型也就不了了之。业务建模和许多优秀的工程实践一样，难以落地的原因就在于带头落地的人，学了，但几乎不可能在第一次就学好，要学好又必须亲身实践，糟糕的落地实践加上占据了可贵的业务资源，如果实操个 3 次左右也没有良好的效果，就再也不会有下文，更不用说把实践总结下来的方法论，传授给同事了。