因地制宜 - 惯性聚合

你好，我是小树。这是我为你写的第 128 封信。每期都会同步更新在微信公众号一颗小树。

这周参与了一个讨论，大致是说编程 + AI 和低代码 + AI 来实现需求孰优孰劣。

这篇文章聊下我的一点思考和最近用低代码做公众号数据分析的案例，欢迎讨论和指正。

编程 + AI 通常说的是借助 AI 的能力来完成业务流程的代码实现，低代码 + AI 往往说的是在已有的业务流程基础上，通过 AI 更好的解决流程中某个节点的问题。

我认为这两种方式并无高低之分，只是适用于不同人群和不同场景。

我在日常工作里会接触很多客户，不同行业和知识背景的客户对工具的接受程度差别非常大。

举几个例子：

如果我处在一个高知识密度的组织，可能 AI 加持的代码编辑器能够极大地提升员工创造力的上限。

但如果是在已有的业务流程上做改动，或者想让更多的人用 AI 解决问题，不可能寄希望于所有人都能学会编程，替换或修改已有的整套实现。

实际上，开发一个应用背后的成本远远高于低代码搭建。

开发可以分为两部分：创造和维护，两者的区别是从 0 到 1 和从 1 到 10。

得益于大模型性能的突飞猛进和云服务的蓬勃发展，创造对于愿意学习和钻研的人来说已经不是什么难事。

我们很容易让 AI 帮我们写一个网页部署到云端，成为自己的作品。

这是因为云服务厂商转嫁了我们部署、运维等环节的成本，让我们可以专注在想要实现的功能上。

但如果我们想更进一步，修改已有的功能，调试问题或者在此基础上加入新的功能，AI 就会像一个爱走神的乙方，并不能完全按照我们的心意来做事。更不必说业务逐渐发展到一定规模后会逐步面临的复杂技术问题。

即便目前的 AI 已经非常强大，但我在实际使用的时候还是达不到“精准”控制。就像医生手中的手术刀，大部分时候还是需要依靠自己本身的技术能力来精确完成问题的排查和修复。

因此，AI 可以看做个人能力的杠杆，它可以放大我们已有的能力，降低启动门槛，但不能让我们一步登天。

低代码的好处之一是模块化。

通过功能的封装，屏蔽掉中间不需要被使用者理解的细节，添加一些约束，构成一个开箱即用的功能模块。

通过这种方式，很容易保障功能体验的下限，最差也是平台经过各种业务场景打磨过的。

举一个具体的例子，假如我想实现一个发送钉钉消息的功能，如果用代码来实现，用户可能需要理解如何鉴权、调用哪些接口、内容如何转换为消息需要的格式、服务的稳定性和可用性和各种场景的边界情况等。

如果通过低代码，用户只需要配置发给谁、发什么，消息就能在合适的时机发送出去。

另一方面，通过低代码搭建的业务流程，很容易被复制、迁移和修改。

如果我是决策者，我往往希望买的不是一次性的代码模板，而是实际能运行的业务流程，并且要能自己上手维护和应对未来业务场景的拓展能力。

如果对方来和我聊解决方案，讲代码就太晦涩了，但通过低代码搭建一个工作流是更直观、更容易让我买单的。

当然，低代码一定是牺牲了部分灵活性的，仅支持有限的配置能力，尤其在 UI 上就更难实现定制化，如果想要在 C 端实现比较好的体验是比较困难的。

再来讲讲我最近使用低代码提升效率的一个案例。

我日常的工作内容主要是写代码，各类功能都习惯自己开发实现。

最近刚好想要总结一下自己今年公众号的文章数据，但是公众号后台的数据分析和导出能力实在太差了。

去年我用 JavaScript 在浏览器里实现了一个简单脚本，支持自动翻页并将文章的访问、点赞等数据导出为 CSV 格式。

但我今年想尝试用低代码的方式来解决这个问题。最终花了几个小时时间，用 RPA 工具配置出了自动化应用，只需要点一下运行按钮，就可以自动化抓取页面上的数据并结构化，简单处理后批量写入多维表格。

完整流程如下：

熟悉 Python 的小伙伴会很容易理解这个流程在做什么，实际上就是把每行代码抽象成了一个个流程节点，有常用的列表和字典数据结构，还有条件分支和循环。

获取已打开的网页对象是用 Chrome 浏览器插件的 API 来实现对浏览器的控制，借助工具我完全不需要了解插件开发。

批量数据抓取非常方便，我只需要简单点选页面上的某个元素，工具可以自动帮我匹配到页面上所有相似的内容自动抓取为不同行的内容，完全不需要了解 DOM 选择器或者 XPath 之类的前置知识。

再借助多维表格仪表盘的能力，就可以为自己搭建一个独一无二的年终总结（图片非真实数据）。

单单从解决问题的效率角度来说，下次再去实现这种非标准化的数据分析场景，我就不会考虑通过写代码来实现了。

最后小结一下：

谢谢你的关注，我们下期再见。👋🏻

你也可以在这里找到我：即刻、Twitter、微信公众号一颗小树。

如果你觉得这篇文章对你有用，欢迎分享给更多好友。

推荐订阅源