作者归档:admin

AI 大时代要懂的 2 种「编程范式」

2023 年 AI 新突破导出不穷,隔两个月就会有一个爆点出来,AI 迎来了一个新的里程碑时刻。从 OpenAI 推出的 ChatGPT 到 Midjourney 发布的 V5/V6 版本,AI 在各个领域都取得了突破性的进展。随着 AI 技术的日益成熟,我们也开始思考如何更好地利用 AI 工具来提高工作效率。

到 2024 年, AI 应用、AI 配套的框架和工具如雨后春笋。

在这个 AI 大时代,有两种「编程范式」值得我们关注。为什么要打上引号呢?

因为这里所说的编程,已经不再局限于传统意义上的写代码,而是泛指利用各种工具和模型,将它们灵活组合,创造出新的应用和价值。

第一种范式是基于 ComfyUI 的编程。ComfyUI 是一个模块化的 AI 图像生成工具,它允许用户通过拖拽和连接不同的节点,轻松创建出令人惊艳的 AI 艺术作品。在 ComfyUI 上编程,你无需掌握复杂的代码知识,只需要理解每个模块的功能,并将它们以合理的方式组合在一起,就能得到理想的结果。这种直观、易用的特点,使得 ComfyUI 成为了平面设计、插画创作等领域的得力助手。

第二种范式则是基于 LangChain 的编程。与 ComfyUI 注重视觉创作不同,LangChain 的重点在于自然语言处理。通过 LangChain,开发者可以将语言模型与外部数据源相结合,快速构建功能丰富的聊天机器人、智能文档助手等应用。LangChain 提供了一系列现成的模块和接口,使得即使是非 NLP 专业的程序员,也能在短时间内上手并应用到实际项目中。从客户服务到数据分析,LangChain 正在各行各业发挥着重要作用。

相比传统的编程范式,AI 编程更加注重模块化和灵活组合。我们无需从零开始构建一个完整的系统,而是站在巨人的肩膀上,将现有的模型和工具进行拼装和优化。这种方式不仅大大降低了开发门槛,也极大地提高了开发效率。当然,AI 编程范式也并非完美无缺。对于一些需要高度定制化的场景,传统的代码编程仍然不可或缺。此外,AI 工具的使用也对开发者提出了更高的要求,需要我们对各种模型和算法有更全面的理解和把控。

接下来,简单聊一聊这两种「编程范式」,

comfyUI

ComfyUI 是一个基于 Stable Diffusion 的开源 AI 绘图工具,采用了模块化的节点式工作流设计。它通过将 Stable Diffusion 的各个组件和处理步骤抽象为独立的节点,使得用户可以通过直观的拖拽、连接操作来构建复杂的图像生成流程。

ComfyUI 解决了传统 AI 绘图工具易用性差、扩展性低的问题。其模块化设计和直观的 Web 界面大大降低了用户的使用门槛,无需深入了解底层技术细节,即可快速构建和调整工作流。同时,ComfyUI 还提供了强大的自定义节点机制,允许开发者轻松扩展新的功能和模型,使其能够适应不断发展的AI绘图领域。

ComfyUI 最初由开发者 Comfyanonymous 在 2022 年末发起,旨在提供一个简单、直观的 Stable Diffusion Web UI。早期版本实现了基本的节点类型和 Web 界面,展示了其模块化设计的优势,吸引了一批 AI 绘图爱好者的关注。

在 2023 年春夏,ComfyUI 进入了快速发展阶段。项目不断增加新的节点类型,如 ControlNet、Inpaint、Upscale等,支持更多的图像控制和后处理功能。同时,ComfyUI 引入了自定义节点机制,大大扩展了其功能和适用范围。项目也集成了更多 Stable Diffusion 衍生模型,为用户提供了更多选择。

随着用户社区的不断壮大,ComfyUI 的生态也日益丰富。社区成员积极贡献工作流、节点脚本、训练模型等资源,推动项目的发展。ComfyUI 举办了一系列社区活动,促进了用户间的交流和创作。项目代码库也迎来了更多贡献者,社区力量成为 ComfyUI 发展的重要推动力。

2023 年冬至今,ComfyUI 开始着眼于生态融合和应用拓展。项目与其他 AI 绘图工具建立了联系,支持工作流的导入导出和 API 集成。ComfyUI 也开始探索更多应用场景,如虚拟主播、游戏 mod 等,拓宽了 AI绘图的应用范围。越来越多的开发者和公司开始关注和使用 ComfyUI,其发展前景备受看好。未来,ComfyUI 将继续完善节点系统,引入更先进的 AI 技术,并加强生态建设,有望成为 AI 绘图领域的重要基础设施。

ComfyUI 中节点之间的关联是通过连接节点的输入和输出端口来实现的。每个节点都有预定义的输入和输出端口,用户可以在 UI 界面上将一个节点的输出端口连接到另一个节点的输入端口,从而建立节点之间的数据流和执行顺序。

在 ComfyUI 的后端实现中,这种节点关联是通过一个有向无环图来表示的。DAG 是一种常用的数据结构,用于描述一组节点之间的依赖关系和执行顺序。

当用户在 UI 界面上连接两个节点时,实际上是在 DAG 中添加一条边,表示数据从源节点流向目标节点。ComfyUI 会根据 DAG 的拓扑结构,确定节点的执行顺序,并在运行时将数据在节点之间传递。

ComfyUI 中节点关联有一些关键实现细节:

  1. 端口类型匹配:每个节点的输入和输出端口都有预定义的数据类型。在连接节点时,只有类型匹配的端口才能建立连接
  2. 数据传递:当一个节点执行完毕后,它会将结果数据发送到所有连接到其输出端口的节点的输入端口。
  3. 执行调度:ComfyUI 会根据 DAG 的拓扑顺序,确定节点的执行顺序。当一个节点的所有输入数据都准备好时,该节点就可以开始执行。
  4. 并行执行:无依赖关系的节点可以并行执行,提高执行效率。ComfyUI 会自动分析 DAG,找出可以并行执行的节点。
  5. 缓存优化:对于某些计算量大的节点,ComfyUI 会缓存其计算结果,避免重复计算。当节点的输入数据没有变化时,就可以直接使用缓存的结果。

ComfyUI 通过将节点组织成 DAG 的方式,实现了节点之间的关联和数据流控制。这种设计使得用户能够以可视化的方式创建复杂的图像处理工作流,同时也为并行优化和缓存优化提供了便利。

comfyUI 中核心工作都是围绕其节点,其主要节点如下。

  1. Text Prompt(文本提示)节点:提供文本描述,指导图像生成,输入是用户输入的文本提示如”1girl, brown hair, smile”;输出是编码后的文本向量(tokens)。几乎所有的绘图工作流都需要文本提示节点,它是指定图像内容的主要方式。
  2. Latent Image(潜在图像)节点:表示潜在空间中的图像,可以是随机初始化的噪音,也可以来自其他节点的输出。输入是噪音参数(如seed、尺寸等),或其他节点传递的潜在图像。输出是潜在空间中的图像表示。作为采样起点(初始噪音)或中间结果(如图像修补、图生图等)。
  3. Sampler(采样器)节点:根据条件迭代优化潜在图像,使其解码后符合要求。输入是潜在图像、文本向量、其他条件(如 ControlNet 输出等)、采样步数、采样方法等参数。输出是优化后的潜在图像。采样是图像生成的核心,不同的采样器节点可以权衡生成质量和多样性。
  4. ControlNet 节点:根据附加条件(如边缘、姿态、深度等)控制生成图像。输入是潜在图像、条件图(如 Canny 边缘图)、ControlNet 模型参数等。输出是融合条件控制的潜在图像。用于生成满足特定结构、布局或属性要求的图像,如人像、动漫线稿上色等。
  5. VAE Encode(VAE编码)节点:将 RGB 图像编码为潜在空间表示。输入是 RGB 图像,如用户上传的图片。输出是潜在空间中的图像表示。用于图生图、图像修补、图像融合等需要以图像为起点的任务。
  6. VAE Decode(VAE解码)节点:将潜在空间表示解码为 RGB 图像。输入是潜在空间中的图像表示,通常来自采样器节点。输出是 RGB 图像。用于生成最终可见的图像结果。
  7. Upscale(放大)节点:增加图像分辨率,提高细节。输入是 RGB 图像,放大方法和倍数等参数。输出是放大后的 RGB 图像。用于生成高分辨率图像,常在VAE解码后使用。
  8. Inpaint(图像修补)节点:根据 mask 和提示,对图像的指定区域进行编辑。输入是原始图像、mask 图像、修改区域的文本提示等。输出是修改后的图像。用于对生成图像进行局部编辑,如去除伪影、修改细节等。

除了以上常用节点,comfyUI 还有许多其他节点,如图像保存、剪裁、格式转换等,用于图像的后处理和输出。不同节点可以灵活组合,构建多种多样的绘图工作流,满足各类需求。

举个例子,一个常见的工作流是:文本提示节点 -> 潜在图像节点(初始噪音) -> ControlNet节点(添加结构条件) -> 采样器节点(优化潜在图像) -> VAE解码节点(生成RGB图像) -> 放大节点(提高分辨率) -> 图像保存节点(输出最终结果)。

如下图所示:

+-------------------+     +------------------+     +------------------+
|                   |     |                  |     |                  |
|  Load Model Node  |---->|  Text Encode Node|---->|  Latent Image Node |
|                   |     |                  |     |                  |
+-------------------+     +------------------+     +-------------------+
                                                             |
                                                             |
                                                             v
                                                   +-------------------+
                                                   |                   |
                                                   |  ControlNet Node  |
                                                   |                   |
                                                   +-------------------+
                                                             |
                                                             |
                                                             v
+------------------+     +------------------+     +------------------+
|                  |     |                  |     |                  |
|  Upscale Node    |<----|  VAE Decode Node |<----|  Sampler Node    |
|                  |     |                  |     |                  |
+------------------+     +------------------+     +------------------+
         |
         |
         v
+------------------+
|                  |
|  Output Image    |
|                  |
+------------------+

通过对节点的连接配置和参数调整,用户可以精细控制每个步骤,实现理想的 AI 绘图效果。同时,comfyUI 也鼓励用户开发和分享自定义节点,不断扩展其功能和应用领域。

在理解 ComfyUI 的原理时,其核心还是理解 SD 的原理,简单来讲是通过大模型、CLIP 和 VAE 编码器以及采样器的协同工作,将文本提示转换为特征马赛克,再通过 VAE 解码器还原成图像,从而实现基于文本描述生成图像的功能。

LangChain

什么是 LangChain?

LangChain 是一个开源的 Python 框架,旨在帮助开发者更容易地构建基于大语言模型(LLM)的应用。它提供了一系列工具和组件,可以方便地与各种 LLM 模型集成,如OpenAI GPT、Anthropic Claude、Google PaLM等,而无需从头开始构建或进行大量的微调。

LangChain 旨在简化和统一语言模型与外部数据和应用程序的集成过程。它为开发者提供了一套灵活的工具和组件,可以轻松地将 OpenAI、Hugging Face 等流行的语言模型与知识库、API 等数据源相结合,从而快速构建功能强大的自然语言处理应用,如聊天机器人、智能文档助手、问答系统等。

LangChain 解决了语言模型应用开发中的诸多痛点。在 LangChain 出现之前,开发者需要编写大量的胶水代码来处理不同模型和数据源之间的交互,这不仅耗时耗力,也容易引入错误。LangChain 通过提供一致的接口和预构建的组件,大大简化了这一过程。它还引入了 Prompt Engineering 的理念,允许开发者通过设计优化的提示模板来引导模型生成更准确、更符合需求的输出。

LangChain 的发展历程可以追溯到 2021 年底。最初,它只是一个简单的概念验证项目,旨在探索如何将语言模型与外部数据集成。随着 ChatGPT 等大语言模型的出现和 NLP 技术的快速发展,LangChain 的潜力开始受到关注。

2022 年,LangChain 迎来了重大更新和扩展。它引入了更多的集成选项,支持了更多种类的数据源和下游应用。同时,LangChain 的社区也在不断壮大,越来越多的开发者开始贡献代码和分享经验。

2023 年,伴随着 AI 的大爆发,LangChain 迎来了爆发式增长。它成为了开发 AI 应用的必备工具之一,在各大技术论坛和社交平台上频频被提及。LangChain 也加速了版本迭代和功能更新,引入了更多高级特性,如 Agent 和 Memory,进一步增强了其适用性和性能。

如今,LangChain 已经发展成为一个成熟而强大的 NLP 应用开发框架。它不仅帮助开发者大幅提高了开发效率,也为各行各业带来了前所未有的智能化应用。展望未来,LangChain 还将持续演进,与最新的 AI 模型和技术保持同步,为开发者和用户带来更多惊喜。

LangChain 的核心是将 LLM 与外部数据源连接,并通过 prompt engineering 技术来优化 LLM 的输入输出,从而生成更加准确、相关的结果。它的主要组件和功能如下:

  1. 模型输入输出(Model I/O):对接各种 LLM 模型的 API,提供统一的接口。支持 OpenAI、Anthropic、Hugging Face 等主流 LLM 服务商。
    • 语言模型(Language Models):支持大型语言模型(LLM)和聊天模型(ChatModel)的交互接口。
    • 提示模板(Prompt Templates):用于生成模型输入的预定义配方,支持两种主要类型是:PromptTemplate:生成字符串提示 和 ChatPromptTemplate:生成聊天消息列表提示。
    • 示例选择器(Example Selectors):提供训练、调优、测试和控制模型行为的示例输入输出。
    • 输出解析器(Output Parsers):用于将模型返回的文本结果格式化为目标对象、JSON 或数组等。
  2. 数据连接(Data Connection):在许多 LLM 应用程序中,用户特定的数据不在模型的训练集中,这可能是通过检索增强生成(RAG)实现的。RAG 的主要方法是检索外部数据,并在生成步骤中传递给 LLM。这样,LLM 就可以使用外部数据来增强生成的结果,从而提高应用程序的性能和准确性。
    • 文档加载器(Document Loaders):将不同数据源的非结构化文本加载为文档对象,并支持延迟加载。
    • 文档转换器(Document Transformers):对加载的文档进行处理,包括文本拆分、冗余过滤、元数据提取等。
    • 文本嵌入模型(Text Embedding Models):将文本转换为向量表示,用于文本检索、信息推荐、知识挖掘等。
    • 矢量存储(Vector Stores):负责存储嵌入数据并执行矢量搜索。
    • 检索器(Retrievers):从大规模文本库中检索与查询相关的文本段落,提供问答系统的额外上下文支持。
  3. 链(Chains):组件化的方式将一系列操作连接在一起形成数据处理的工作流,如数据检索、内容生成、翻译等可复用的任务执行流程。常见的链包括 LLMChain、SequentialChain、RouterChain 等。
    • 基础链(LLMChain):围绕语言模型的简单链。由提示模板和语言模型组成,用于格式化提示并返回 LLM 输出。
    • 路由链(RouterChain):可以动态选择下一条链,包括 LLMRouterChain 和 EmbeddingRouterChain。
    • 顺序链(SequentialChain):将多个链顺序连接,支持 SimpleSequentialChain 和更通用的 SequentialChain。
    • 转换链(TransformChain):在链之间添加自定义转换函数。
    • 文档链(DocumentsChain):处理多个文档输入。
  4. 记忆(Memory):为 Chains 和 Agents 提供对话状态记忆能力,用于在链之间存储和传递信息,实现上下文感知。常见的包括 ConversationBufferMemory、ChatMessageHistory 等。
  5. 代理(Agents):一种特殊的 Chain,可根据目标进行工具选择、动作规划和迭代求精。使用 LLM 作为大脑自动思考和决策,执行动作完成任务。包括 ZeroShotAgent、ReAct、Self Ask With Search 等。
  6. 回调(Callbacks):连接到 LLM 申请的各个阶段,用于日志记录、监控等。

LangChain 主要解决了以下问题:

  • 简化了与不同语言模型的交互。
  • 提供了标准化的方法来生成和管理提示。
  • 允许用户为模型提供示例输入输出,以优化模型性能。
  • 支持非结构化文本的加载、转换和处理。
  • 使文本嵌入和检索更加方便,支持向量空间中的各种运算。
  • 通过链的概念,允许将多个组件组合成复杂的工作流程。
  • 实现了对话的上下文感知能力。
  • 通过代理自动执行任务,提高了应用的智能化水平。

那如何使用呢?

使用 LangChain 的一般步骤可能包括:

  1. 根据需求选择合适的组件,如语言模型、提示模板等。
  2. 使用文档加载器加载数据,并利用文档转换器进行预处理。
  3. 配置链,将不同的组件组合起来,创建工作流程。
  4. 利用记忆组件在链之间传递上下文信息。
  5. 定义代理,使用 LLM 进行自动决策和执行。
  6. 设置回调,进行日志记录和监控。
  7. 根据具体应用场景进行调整和优化。

在使用过程中有一些注意的事项:

  1. 根据任务选择合适的 LLM:不同的 LLM 适用不同任务,并有不同的使用成本,需要根据实际情况权衡。在使用 LangChain 前,需要明确了解自己的需求和应用场景,选择和配置合适的组件和模型。
  2. 注意提示工程:LLM 的效果很大程度取决于提示的设计,需要遵循最佳实践,多进行实验和迭代。
  3. 数据的隐私和安全:在涉及用户数据时,注意数据的安全性和隐私保护,遵循相关法律法规和最佳实践。特别是在 fine-tuning 或者数据索引时,要注意数据的隐私和版权问题。
  4. 模型的公平性和伦理性:LLM 可能会放大数据中的偏见,产生有害或者不道德的内容,需要谨慎使用。
  5. 应用的可解释性:端到端的 LLM pipeline 往往是个黑盒,要考虑如何向用户解释其工作原理和局限性。
  6. 成本和效率优化:要密切关注 LLM 调用次数、向量检索等环节的耗时和费用,权衡精度和成本。对于大规模数据处理或高吞吐量的应用,需关注性能优化,可能需要并行处理、缓存机制、硬件加速等手段。

通过合理的使用和配置,LangChain 可以极大地简化复杂 AI 应用的开发流程,提高开发效率和应用性能。LangChain 的设计使得开发者可以灵活地构建和定制 AI 应用程序,以适应不同的业务需求。

LangChain 适用于构建各种 LLM 驱动的应用,比如智能对话助手、知识库问答、数据分析、文案创作等。LangChain 正在成为 LLM 应用开发领域的生产力工具,促进更多创新产品和服务的诞生。

小结

AI 编程范式正在为我们开启一个全新的创作空间。ComfyUI 让设计变得前所未有的简单,LangChain 则让智能对话唾手可得。站在时代的十字路口,拥抱 AI,学习新的编程范式,我们就能更从容地迎接未来的挑战与机遇。

但,纸上得来终觉浅,绝知此事要躬行。

在实际的工作中,这些要用起来,才能有更深刻的体会。

以上。

SaaS 产品的定制路线和集成路线

最近有和一些做 SaaS 的技术负责人交流,原来专注于做线上 SaaS 业务,今年也开始开放了定制逻辑。

回想之前看到的艾瑞咨询 2024 年发布的《中国企业级 SaaS 行业研究报告》,SaaS 行业有如下的一些变化:

  1. 市场规模、增长预测和行业趋势

    • 2023 年中国企业级 SaaS 市场规模达到 888 亿元人民币,同比增长 13.0%。
    • 预计未来三年,市场规模的增速将稳定在 15%-20% 区间,复合增速约为 15%。
    • SaaS 行业正在经历关键转折点,由快速扩张向精细化运营转变。
    • 宏观经济放缓和资本退潮加速了市场的淘汰过程。
  2. AIGC 技术

    • AIGC 技术在 SaaS 行业的应用,特别是在医疗、人力资源、电商、设计等领域。
    • SaaS 厂商利用 AIGC 技术进行自然语言处理、文本和数据处理,提升服务能力。
    • AIGC 可能重塑 toB 市场未来,SaaS 行业迎来重估时刻。
  3. 企业实践

    • SaaS 在企业中的渗透率不断提升,大型企业倾向于定制集成,中型企业成为平台生态模式的主流应用群体。
    • SaaS 生成的底层逻辑从简单的流量互换转向更深层次的产品融合,集成和被集成可灵活
  4. 投融资情况

    • 投融资活动自 2019 年以来逐步下滑,显示出融资轮次后移的趋势。
    • 2023 年 SaaS 领域的天使轮和 A 轮融资占比回升,过亿元融资事件数量下滑。
    • 投资热度下滑,创业公司需要加强自我造血能力。
    • 行业垂直型厂商在融资轮次上更偏早期,显示出成长机会。
    • 投资机构关注 SaaS 模式的核心价值,重视企业健康度和垂直赛道成长性。

基于这此变化,不难看出,放开定制是一个不得已的选择,或者说是另一条在中国值得尝试的出路。

之前上过公司组织的《商战模拟》培训课,给我印象最深刻的是一切执行动作都需要先选择客户,选择市场

以 SaaS 为例,如果你选择是头部客户,大企业客户,那定制化需求会非常多;如果选择的是尾部客户,则 SaaS 公司面对的定制化需求就很少;而腰部客户的定制化需求介于两者之间。

而在中国做 SaaS 公司,定制是一个跨不过的点,当一个单几百万甚至上千万,需要定制功能,是做还是不做?

这里我觉得决策的点在于当前的公司状态,以及选择的客户,保持战略定力。

今天主要是聊一下头部客户的定制路线,和腰部客户的集成路线。

头部客户的定制路线

SaaS 公司选择头部客户的定制开发,这其实是企业成长过程中的一个重要机会。对于大型企业客户而言,标准化的 SaaS 产品无法完全满足他们个性化的业务需求。这时,SaaS 公司如果能够抓住机会,为客户提供深度定制化的解决方案,不仅可以带来可观的收入,更能建立深厚的合作关系,实现共同成长。

在中国的大企业定制,特别是金融企业、国企等,更加的困难,常见的一些挑战如下:

  1. 部署环境差异大

    • 信创环境要求:随着国家对信息技术应用创新的重视,很多大企业都面临信创改造。这要求 SaaS 产品能适配国产芯片、操作系统、中间件等,并提供相应的兼容性测试报告。同时还要符合信创标准规范,对接国家认证平台。
    • 网络环境复杂:大企业分支机构遍布全国,网络环境千差万别。有的地区带宽不足,有的办公场所内外网隔离,还可能存在多个专有网络。SaaS 产品需要适应不同的网络状况,在保证性能的同时,还要做好异地多活、断网续传等机制。
  2. 安全要求高

    • 网络安全:大企业非常重视网络安全,要求 SaaS 产品提供全方位的防护。比如异常流量检测、DDoS攻击防御、蠕虫病毒查杀等。还要支持细粒度的访问控制和审计日志,对各种网络威胁做到实时预警、快速处置。
    • 应用安全:SaaS 产品自身也要做好安全防护,从代码级别进行安全审计,避免常见的注入、跨站、越权等漏洞。敏感数据要加密存储,访问要严格授权。要定期开展渗透测试,及时修复潜在风险。部署上要实现服务隔离,防止单点故障。
  3. 兼容与迁移

    • 兼容已有系统:大企业的 IT 系统往往经过多年积累,包含各种自研、外采的应用。SaaS 产品要尽量兼容原有系统,减少客户的改造成本。比如对接已有的单点登录、支持常见的数据交换格式、提供标准化的 API 接口等。
    • 平滑迁移数据:从原有系统迁移到 SaaS 平台,数据迁移是一个重要工作。需要做好数据清洗、格式转换、一致性校验等。迁移过程要尽量减少业务中断时间,必要时提供回滚机制。对于数据量大的情况,还要采用增量迁移等策略,平衡时间和成本。
  4. 定制化需求严重

    • 个性化开发:大企业各部门的业务差异很大,标准功能往往难以满足。SaaS 公司需要深入了解各种业务场景,量身定制个性化方案。在产品设计上要预留足够的灵活性和扩展点,便于快速响应定制需求。
    • 定制流程规范:定制开发往往涉及复杂的需求梳理、方案设计、项目实施等,需要有规范的流程把控。比如需求评审会、技术方案会、进度评估会等。要让甲乙双方形成统一的理解和预期,并全程跟踪需求的变化。
    • 定制成果积累:每个定制项目都包含大量的需求分析、技术方案、测试用例等成果。SaaS公司要注重积累这些知识财富,建立完善的知识库。优秀的方案要进行抽象和提炼,形成可复用的功能模型。这既能提升后续项目的交付效率,也能反哺标准产品的研发迭代。

这些挑战落到 SaaS 企业的定制交付团队,实际有如下的困难:

  1. 资源投入大。为头部客户进行定制开发,需要投入大量的人力、物力和时间,这对 SaaS 公司的资源配置提出了更高要求。

  2. 项目管理难度高。定制项目往往涉及复杂的业务逻辑和深度整合,对项目管理能力是一个考验。需要在控制成本、进度和质量间寻求平衡。

  3. 后期维护成本高。由于定制项目的个性化程度高,后期的运维和升级也更加复杂,需要投入专门的团队。

  4. 通用性不足,规模化困难。过度定制可能影响产品的通用性,不利于标准化和规模化发展。

所以在决定是否接受定制开发时,SaaS 公司需要审慎评估自身的能力和资源情况,平衡好短期收益和长期发展。头部客户的地位和资源固然重要,但盲目迎合可能会偏离初心,产品价值也会被稀释。

在做定制开发过程中,关键是要在满足大客户需求的同时,尽量保持 SaaS 产品的相对独立性,将部分定制功能抽象和沉淀下来,形成可复用的模块。这样既能交付项目,又能保证核心产品不断完善,实现可持续发展。定制开发应该成为锦上添花,而非翻越不可的高山。

从方法论的角度来看:高度的定制化,其实是高度的模块化。

腰部客户的集成路线

相比起大型企业的全量定制,腰部客户的需求往往没那么极端。他们追求的是性价比,希望用更低的成本获得符合自身业务场景的解决方案。这时,与第三方产品的集成就成了很好的选择。

SaaS 公司可以保持自己的产品专注度,通过开放 API 等方式,与行业内的各种产品无缝连接。这种去中心化、平台化的生态模式,能充分发挥各方优势,为客户提供一揽子服务,提升整体竞争力。

对腰部客户来说,与成熟 SaaS 产品的集成优势明显:

  1. 实施周期短,见效快:借助现有系统,企业可以快速上线新功能,满足业务变化。
  2. 使用成本更低:直接调用成熟的产品能力,无需额外的开发和运维投入。
  3. 升级更加便捷:随着 SaaS 产品的迭代,客户也能持续受益,保持业务创新。
  4. 专业性更强:每个产品各司其职,发挥自身专长,客户可获得最佳实践。

集成可以分为三个层次:

  1. 轻度集成

    • 集成方式:轻度集成主要基于双方现有的 API 接口,进行基础的功能连接,例如单点登录(SSO)和相对标准化的点对点数据交换。
    • 适用场景:这种集成通常不需要大量的定制开发,适用于功能相对独立、不需要深层次交互的场景。
    • 优点:快速实施,成本低,风险小,易于管理和维护。
    • 不足:功能集成有限,可能无法满足复杂的业务需求,且数据和流程的整合程度较低。
  2. 中度集成

    • 集成方式:中度集成利用集成工具进行跨系统的业务流程和审批流程集成,将不同系统的数据整合到统一的数据看板中进行集中展示和分析。
    • 适用场景:这种集成层次需要更多的协调和数据同步,适用于需要跨系统视图和报告的业务场景。例如,CRM 系统与 ERP 系统的集成,以实现销售和库存管理的协同。
    • 优点:提供更全面的业务视图和流程自动化,增强数据一致性和流程效率。
    • 不足:集成复杂性增加,需要更多的技术投入;可能需要解决数据一致性和系统集成的技术难题。
  3. 重度集成

    • 集成方式:重度集成涉及双方产品在技术和业务层面的深度融合,可能包括账号体系打通、消息体系打通,以及基于深度数据集成满足更复杂的业务流程需求。
    • 适用场景:这种集成层次要求双方在产品开发和业务流程上有更深层次的合作,适用于需要高度协同和定制化的业务场景。
    • 优点:能够实现高度个性化和优化的业务流程;提供更深层次的业务洞察和自动化。
    • 不足:高度集成可能导致技术依赖和复杂性;成本和风险较高,需要专业团队进行维护。

每个集成层次都有其特定的应用场景和需求,SaaS 厂商在选择集成深度时需要考虑产品特性、客户需求、技术能力以及资源投入等因素。随着集成深度的增加,厂商能够提供更加丰富和个性化的服务,但同时也可能面临更高的技术挑战和成本投入。

从企业数字化的角度来看,轻度集成有助于企业快速实现基本的数字化功能,适合初期探索和小型项目;中度集成可以提高企业的运营效率,通过流程和数据的整合,实现更高效的业务管理;重度集成为企业提供了深度定制化的解决方案,有助于构建复杂的业务生态系统,但同时也要求企业具备相应的技术能力和管理水平。

从 SaaS 企业的角度出发:

在产品层面需要需要明确定位,兼顾灵活性和把控节奏

  • 明确定位:SaaS 企业首先要明确自身的产品定位和核心价值,究竟是要做通用型平台,还是聚焦特定领域的专业解决方案。这决定了后续的集成策略和生态布局。
  • 兼顾灵活性:产品在设计之初就要考虑到集成的需求,要预留足够的接口和扩展点。既要保证产品的专业性和完整性,又要兼顾灵活性和可集成性。
  • 把控节奏:产品规划要统筹兼顾,协调好自研和集成的节奏。自研核心功能来保证竞争力,同时也要联合优质合作伙伴,快速完善产品矩阵,满足市场多元化需求。

在技术架构层面需要保持架构开放,制定集成标准以及实现集成工具

  • 架构开放:SaaS 平台要采用开放式的技术架构,基于微服务、容器化等先进理念,实现松耦合、高内聚。要开放丰富的 API,涵盖数据接口、功能接口、流程接口等,便于第三方应用的灵活集成。
  • 集成标准:要制定清晰的集成标准和规范,包括接口定义、安全认证、数据格式等。既要满足通用性,又要兼顾特殊场景。标准要随技术发展持续演进,保持与行业主流的同步性。
  • 集成工具:要提供配套的集成开发工具包,帮助合作伙伴快速完成适配。比如API管理平台、开发者社区、在线调试工具等。还可提供低代码开发平台,降低集成门槛。

在客户服务层面,为不同层次的集成提供针对性的服务

  • 轻度集成:要提供清晰的集成文档和开发指南,帮助客户快速上手。通过在线支持、社区互助等方式,及时解决客户的问题。提供基本的监控功能,帮助客户掌握集成应用的运行状况。
  • 中度集成:除文档支持外,还要提供架构咨询、最佳实践等服务,帮助客户优化集成方案。协助客户进行数据迁移、流程整合等工作。建立预警机制,主动发现并解决潜在的集成问题。
  • 重度集成:要组建专业的集成服务团队,提供端到端的咨询、实施、优化等服务。与客户形成长期的战略合作关系,深入理解客户业务,持续优化集成方案。提供定制化的 SLA,保障关键业务系统的高可用性。

对于 SaaS 企业来说,腰部客户的集成是一个循序渐进的过程。站在客户的角度,理解不同业务场景下的集成需求,匹配相应的产品能力和服务支持。

小结

当下,SaaS 行业正在经历关键转折点,由快速扩张向精细化运营转变。宏观经济放缓和资本退潮加速了市场的淘汰过程。

肖总说:「行情好的时候你们就是人力资源,行情不好的时候,你们就是人力成本

这其实对于 SaaS 行业来说是一个逆境。

冯唐说面对逆境:看脚下,不断行,莫存顺逆

《微信背后的产品观》中张小龙给了研发同学 3 点建议

一直说要把《微信背后的产品观》这本书看完,一直没顾得上,这次临时出差到厦门的路上带上了,动车上的时间把书看完了,去的时候看了一遍,回的时候看了一遍,看完,写下这篇文章。

这本与其说是书,不如说是演讲实录。书的内容来源自张小龙在 2012 年的那次著名的 8 小时演讲,2016 年被整理成书稿,在 2021 年决定出版。好的内容是经得起时间考验的,在 9 年之后出版,在 12 年后的今天来看也不过时,甚至部分观点会刷新我们的一些认知。

以下是我在读这本书的过程感受比较强烈的三个观点或建议。

1 如果解决方案非常复杂,一定是问题错了。

这是从一个开发能力很强很全面的在朋友圈抱怨:「觉得微信的代码越来越复杂了,开始搞不定了」,张小龙在下面评论说:「如果一个问题的解决方案太复杂,一定是问题本身错了。事实上就是这样子的。

一个好的问题不应该导致解决方案太复杂。

从研发的角度来看,引申出来有 3 点:

1. 如果解决方案非常复杂,一定是问题错了或者是需求有问题

很多时候,我们在面对一个问题时,容易陷入复杂的解决方案中或者限入为了解决问题而解决问题。但其实当一个解决方案变得非常复杂时,我们应该反思问题的提法是否正确,需求是否是真正的需求。一个好的问题应该能够用一个相对简洁优雅的方案去解决。

陷入困境时我们要学会换个角度或者跳出问题来思考问题。当感到解决方案过于复杂时,不妨退一步问问自己,是不是对需求或问题有误解,有没有更本质更简单的诉求。化繁为简,用简单的方法解决问题,是一种智慧。

2. 优秀的工程师其实可以帮助产品经理矫正需求

产品经理提出的需求,研发同学往往会无条件去满足。但优秀的工程师,应该具备产品思维,有能力去审视和质疑需求背后的逻辑,去引导产品经理矫正需求。

一味地满足需求,只会让产品变得复杂和庞大。优秀的工程师应该成为产品经理的思想伙伴,而不仅仅是执行者。在开发过程中提出合理化建议,做有价值的事,把控产品的定位和走向,这是更高境界的工程师素养。

3. 写代码只是其次,思考和讨论产品也是重要的工作

作为研发同学,不能把自己局限在写代码上。思考产品,了解用户,参与需求讨论,才能真正驱动产品的进步。

代码只是工具,而洞察需求,理解人性,思考产品形态,决定产品体验,这些应该是每一个研发同学的内功。要把自己的视野拓展到产品层面,主动去思考为什么做这个功能、用户会喜欢吗、还能怎么改进体验。唯有这样,才能成为真正优秀的工程师。

2 抽象方能化繁为简

这个观点应该是大部分场景下面,研发同学都认同的。

当面对大量繁杂的需求时,与其逐一满足,不如试图提炼出其中的共性和本质,将之抽象为更少量、更高层次的需求。这个过程就是「抽象」。

以订阅内容为例,如果把各类内容提供方(如企业、个人、媒体等)的形形色色的诉求都一一满足,系统必然会变得非常复杂。但若能抽象出一个统一的账号体系和内容载体,就能用一套接口来服务各方,大大简化了系统。

抽象的层次越高,派生出的子需求就越多。比如将 100 个需求抽象、归纳为 10 个,甚至 1 个,则原本的 100 个需求都可以被这 10 个或 1 个「母需求」所覆盖。

要做好抽象,关键是要找准需求的共性、本质之处,即所谓的不变量,而非沉陷于各自差异化的细枝末节。唯有升维思考,才能在更高层次上对繁复的事物进行归纳和简化。

通过「以简御繁」「归一化」的抽象思路,可以大大降低系统复杂度,提升开发和管理效率。同时让产品对用户更加友好,使用更加简单统一。

这种化繁为简的抽象思维,是一种非常重要的思考方式和设计原则,对于管理大型复杂系统、满足多元需求有重要指导意义。不仅开发人员要掌握,其他非技术人员也很有必要学习这种思维方式。

3 改变旧世界的意愿

在书中,改变旧世界的意愿是在气质篇的第一篇,从其定义上更多的是一些日常记录的点。

在「改变旧世界的意愿」这一点上,张小龙提到了自己:「对于对iPhone5的唯一期待是,像iPad(3G)一样,不支持电话功能。这样,我少了电话费,但你可以用kik跟我短信,用 googlevoice跟我通话,用 facetime 跟我视频。」

做一个产品,意愿是很重要的。我们有没有去一个改变旧世界的意愿

作为一个研发团队的管理者,改变旧世界的意愿是一个团队管理中的核心逻辑。上次和小帅聊天,也有聊到我们在团队管理岗上,我们始终应该改变点什么

「改变旧世界」的意愿,本质上是一种创新驱动和价值追求。它意味着不满足于现状,主动去探索和尝试新的可能性,并以之来重塑既有的产品形态、技术架构乃至商业模式。这种意愿需要从管理者开始,成为团队的共识和愿景,并指引技术决策和项目实践的方向。

技术管理者需要与团队一起,去思考如何用技术的力量去创造更多的附加价值,解决用户和业务的痛点。要审视自己的产品定位和技术路线,看是否还有优化和颠覆的空间。同时要放眼行业前沿和未来趋势,去探索下一个风口和变革点。唯有确立了明确的变革方向和价值诉求,才能凝聚共识,激发动力。

事实上,很多时候阻碍我们「改变旧世界」的,恰恰是技术和架构层面的「旧世界」。长期累积下来的历史债务,割裂的系统,低效的架构,过时的技术栈,都成为了创新的桎梏。团队往往需要耗费大量时间和精力在修修补补和「打补丁」上,而无暇去思考和实现变革。

这就需要技术管理者下定决心,带领团队去正视和解决技术债务。要客观评估既有系统的健康度,识别出最急需重构和升级的部分。同时要重新思考整个技术架构,看如何通过解耦、重构、引入新技术等手段,来提升系统的灵活性、可扩展性和创新友好度。只有在架构层面打好基础,才能为变革扫清障碍。

除了对技术、架构、债务的改变,「改变旧世界」的意愿,还需要适配研发团队的现状和组织形态。如果团队长期处于产品需求的压力之下,缺乏思考和探索的时间;如果组织过于层级化和官僚化,创新的想法很难被听到和采纳;如果绩效考核过于短视和功利,大家不愿承担变革的风险,那么这种意愿就很难真正落地。

技术管理者需要为团队争取一定的自主权和探索空间。在项目排期和任务分配上,要预留出一定比例的「创新时间」或者技术时间,鼓励大家尝试新的 idea。同时要优化组织架构和流程,让信息和想法能够更顺畅地在团队中流动,减少决策链路,提升反应速度。绩效评估也要将创新和长期价值纳入考量,为「改变」提供合理的回报。

从技术管理者自身来说,站在产品和技术实现交汇的点上,对产品的认知和对实现细节的认知让研发管理可以更高效,更合理的决策技术方案和产品规划,从而更好地引领技术团队实现产品价值和商业目标。

作为管理者,要具备产品视角和技术视角的双重思维,一方面深入了解业务需求和用户痛点,另一方面洞悉技术方案的可行性和优劣。要善于在两个视角之间切换和权衡,找到既能满足需求,又能控制成本和风险的平衡点。也要能跳出具体实现,从更宏观的层面去思考技术战略和产品演进路径,看清下一步的发力点和布局方向。

在具体的实践过程中,技术管理者需要深入了解产品需求的来龙去脉。不能仅停留在需求文档上,而要主动与产品经理甚至客户沟通,理解需求背后的业务逻辑、用户痛点和产品价值。唯有对需求有了全面的认知,才能在技术选型、架构设计、任务拆分等环节做出正确的决策。

同时,技术管理者要对技术实现有足够的了解。这并不意味着要事无巨细地参与到每一行代码中,而是要对关键技术难点、潜在风险、优化方向等有把握。要与技术骨干保持频繁的讨论,时刻掌握开发进度和问题。只有将宏观的需求理解和微观的实现细节结合起来,才能站在全局的高度去调配资源、优化流程、控制质量。

管理者要营造产品和研发的良性互动。鼓励研发团队主动了解业务,引导产品经理关注技术价值,提倡双方同理共情、互相成就。打造一种「产品驱动研发,研发反哺产品」的良性循环,激发团队斗志,凝聚团队向心力。

小结

以书中提到的微信 4.0.1 和 4.2 发布时的文案作为本篇文章的结尾:

很喜欢这句话:如你所知,微信不只是一个聊天工具;如你所见,微信,是一个生活方式。

你曾经在微博上虚掷光阴
如今又在微信里蹉跎岁月
你以为通过手机就连接了世界,
其实只是躲在屏幕后面获取了安全感。
是时候放下手机,和朋友面对面了!
如若不能,试试微信视频通话
少发微信,多和朋友见见面!