三个 40 岁老程序员决定用 AI 重新出发（五）：AI 辅助的 PLG 增长探索

你好，我是曹犟，欢迎关注我的公众号。

在上一篇文章三个 40 岁老程序员决定用 AI 重新出发（四）：文档驱动的 Spec Coding 实践中，我分享了我们如何用 Spec Coding 的方式，把 Use Case 变成可运行的代码。代码写完了，产品也有了雏形，接下来就是每个创业团队都必须面对的问题：怎么让用户知道你、用你、为你付费？而作为这个系列的主题，我们更关心的是：在这个过程中，AI 能发挥怎样的作用？

在这方面，我们目前也是处于非常早期的阶段，在这篇文章中，主要也是跟大家分享一下我们过去几个月探索的经验，包括与客户沟通、准备 PPT、开发官网、监控竞品这些关键环节。

PART01

什么选择纯 PLG 模式

PLG 是什么

PLG（Product-Led Growth，产品驱动增长）是近年来在 SaaS 领域非常流行的增长模式。简单来说，就是让产品本身成为获客、转化、留存的核心驱动力，而不是依赖大量的销售团队和市场投入。在 PLG 模式下，用户自助注册、自助使用、自助付费，整个流程中尽量减少人工介入。Slack、Notion、Figma、Zoom 等产品都是 PLG 的典型代表。

与之相对的是 SLG（Sales-Led Growth，销售驱动增长）模式。在 SLG 模式下，获客主要靠销售团队主动触达客户，通过 demo 演示、方案定制、商务谈判来完成转化，典型的流程是 SDR 获取线索、AE 跟进商机、SE 提供技术支持、CSM 负责客户成功。Salesforce、Oracle 等企业级软件是 SLG 的典型代表。

为什么适合我们

选择 PLG 并不是因为它“先进”，而是因为它最匹配我们的实际情况。

第一，团队规模和意愿都不支持 SLG。三个人的团队，不可能分出一个人专职做销售。更重要的是，经历了 11 年的中国特色 2B 创业之后，我们三个人对 SLG 模式已经没有太多兴趣和意愿。

第二，产品使用门槛很低，天然适合 PLG。我们的产品直接面向最终用户，不需要复杂的实施和培训，用户注册后很快就能上手体验核心价值。这种“即开即用”的特点，正是 PLG 模式能跑通的前提：如果产品本身足够好用，用户会自发地在圈子里分享和推荐。前期我们在几个微信群里做的小范围传播尝试也初步验证了这一点。

第三，海外市场更适合 PLG。我们的目标市场是海外，海外用户对自助服务的接受度普遍更高，PLG 模式在海外 SaaS 市场也更加成熟。

PLG 的挑战

当然，选择 PLG 也不意味着躺着就能增长，它有自己的挑战：

产品体验要求极高。在 SLG 模式下，即使产品体验一般，优秀的销售团队也可以通过服务来弥补。但在 PLG 模式下，产品就是你的销售员。如果用户在前五分钟内没有感受到价值，他就会离开，没有人有机会挽留他。

需要完善的自助服务。文档、教程、FAQ、Onboarding 流程，这些在 SLG 模式下可以由 CSM 手把手教的东西，在 PLG 模式下都需要产品化。

获客渠道的建设。没有销售团队意味着你需要通过其他方式让目标用户发现你：SEO、内容营销、社区运营、开发者关系等。这些工作看似“轻量”，但做好了同样需要持续投入。

好在，AI 可以在很大程度上帮助我们应对这些挑战。下面我就逐一介绍我们在各个环节中的 AI 实践。

PART02

客户沟通：钉钉录音笔 + Gemini

为什么还需要客户沟通

虽然选择了 PLG，但这并不意味着完全不需要和用户沟通。恰恰相反，在产品早期，面对面的用户沟通是获取真实反馈最高效的方式。PLG 只是说增长引擎是产品本身，但产品的方向和迭代优先级，仍然需要从真实的用户反馈中提炼。

在我们的实践中，客户沟通主要发生在两个场景：一是和潜在用户的需求沟通，了解他们的痛点和期望；二是和早期用户的使用反馈沟通，了解产品哪里好用、哪里不好用。

使用流程

我们的做法是用钉钉录音笔来记录沟通内容，再用Gemini来整理和分析。具体来说：

1.录音：用钉钉录音笔记录沟通全程。我们的客户沟通既有线下面聊，也有远程电话或视频会议，都需要录音。选择钉钉录音笔的一个重要原因是 iPhone 对电话录音非常不友好，而独立硬件不受这个限制，线下和远程场景都能覆盖

2.AI 整理：把录音文件直接交给 Gemini，让它完成转写并按照预设的模板进行结构化整理，包括：会议基本信息、讨论的核心议题、每个议题的关键结论、待办事项、用户原话中的关键表述

3.入库：整理好的沟通记录作为项目文档的一部分，纳入团队的知识库中

4.按需调用：在后续的产品迭代、Use Case 更新、竞品分析等工作中，这些沟通记录会作为上下文被引用和参考。

这里选择 Gemini 的原因和之前系列文章中提到的一样：长上下文窗口在处理长时间录音转写时优势明显。

价值

这套流程的价值非常直接：

第一，不遗漏任何用户反馈。人在沟通的时候往往记不住所有细节，尤其是那些当时觉得不重要、但事后回想起来很关键的信息。有了录音和 AI 整理，所有信息都完整保留。

第二，快速发现共性问题。当沟通次数多了之后，手动回顾所有记录不现实。让 AI 做交叉分析，很容易发现哪些问题被不同用户反复提到，这些就是最高优先级的改进方向。

第三，成为各项工作的共享知识基础。这些整理好的沟通记录入库之后，在后续的 Use Case 迭代、客户 PPT 准备、官网文案撰写、竞品分析等环节都会被反复引用。信息记录一次，多处复用，这正是“入库”这个步骤的核心价值。

PART03

PPT 生成：Claude Skills + Nano Banana Pro

为什么需要 PPT

在产品早期，你仍然需要向潜在的合作伙伴、种子用户、渠道中间人介绍你的产品。一份专业的介绍 PPT 是必需品。

而且，不同的对象需要不同版本的 PPT。面向技术决策者的 PPT 需要突出架构和性能，面向业务负责人的 PPT 需要突出 ROI 和案例，面向某个具体客户的 PPT 还需要做针对性的定制。传统做法下，一个人可能需要花几个小时来做一份 PPT，而我们需要的是快速生成多个版本。

工具组合：Claude Skills + Nano Banana Pro

我们的解决方案是用 Claude Skills生成 PPT 的内容大纲，再用 Nano Banana Pro将大纲转化为视觉化的 PPT 文件。

Claude Skills 生成大纲

我们为 Claude Code 开发了一个专门的 PPT 生成 Skill。这个 Skill 的工作流程是这样的：

1.读取资料：首先读取项目中的基础资料，包括 BP、Use Case 文档、产品截图等

2.分析内容：根据目标受众和使用场景，从资料中提取最相关的内容

3.生成大纲：按照 2B 获客 PPT 的标准范式，生成结构化的 PPT 大纲

这里的“标准范式”是什么意思？一份 2B 获客 PPT 通常需要包含这些要素：客户痛点（为什么需要这个产品）、解决方案（产品是什么、怎么解决问题）、差异化优势（为什么选你而不是竞品）、成功案例或数据佐证、行动号召（下一步该做什么）。

更有价值的是，这个 Skill 支持客制化方案生成。当我们面对一个具体的潜在客户时，可以让 AI 先做一轮初步调研，了解这个客户的行业背景、业务模式、可能面临的痛点，再结合之前沟通中记录的客户需求，生成一份完全针对性的方案 PPT。这在传统模式下需要一个售前团队花几天时间来完成的工作，现在一个人几分钟就能搞定。

Nano Banana Pro 生成 PPT

有了结构化的大纲之后，下一步是把它变成视觉化的 PPT。我们使用的是 Nano Banana Pro。

整个流程的成本和效率：

-成本：大约 5 元人民币一份 PPT（主要是 AI API 调用费用）

-时间：从输入需求到拿到成品 PPT，通常在 10 分钟以内

-质量：可以达到“80 分”水平——不如专业设计师精心制作的 PPT，但完全够用，尤其是在产品早期需要快速迭代的阶段

实操技巧

分享几个我们在实践中总结的技巧：

第一，大纲的质量决定了 PPT 的质量。不要指望 AI 从一个模糊的描述中生成出色的 PPT。你需要在大纲阶段就明确每一页的核心信息和逻辑关系。Skill 中预置的 2B PPT 范式模板在这方面帮了大忙。

第二，针对不同客群准备不同的基础模板。我们为技术决策者、业务负责人、C-Level 等不同角色准备了不同的模板，每次生成时只需要选择对应的模板，再叠加客户的具体信息即可。

第三，PPT 只是敲门砖，不是成交工具。在 PLG 模式下，PPT 的作用是让对方产生兴趣去试用产品，而不是替代产品体验。所以 PPT 不需要面面俱到，只需要抓住最能打动对方的一两个点。

PART04

官网生成：Claude Code

为什么官网很重要

在 PLG 模式下，官网是用户接触产品的第一个触点。官网需要在几秒钟内回答三个问题：你是什么、你能解决什么问题、我怎么开始用。回答不好，用户就走了。

用 Claude Code 生成官网

我们的做法是用 Claude Code 直接生成完整的官网代码。

具体的方法是这样的：

第一步，确定官网的核心叙事逻辑。对于目标用户来说，最关心的问题是：你比我现在的解决方案好在哪里？所以官网的核心逻辑就是围绕这个问题展开：先讲用户当前面临的痛点，再用一张详细的对比表格把我们和现有方案做全方位对比，最后给出可衡量的价值承诺和简单的启动流程。同时，因为面向海外市场，我们从一开始就设计为中英文双语架构。

第二步，逐页生成内容和代码。我们把每个页面的内容需求告诉 Claude Code，它会同时生成页面内容和前端代码。这里的关键是：内容不是凭空编造的，而是从 BP 、Use Case、客户沟通记录中提取和改写的，确保官网上的每一句话都和我们的产品定位一致。

第三步，迭代优化。初版生成之后，我们会根据实际效果不断调整。比如首页最醒目的那句核心标语，从最初的功能描述，迭代到现在直接突出和现有方案的对比优势，每次都是让 AI 基于新的认知重新生成，然后人来做最终选择。

第四步，AI 驱动的技术博客。这是一个特别值得一提的做法。我们让 AI 根据产品的业务认知和技术特点，定期生成技术博客文章。这些文章一方面可以帮助 SEO，另一方面也在持续向目标用户传递产品的专业形象。每篇博客的生成流程和 PPT 类似：先从项目的知识库中提取素材，再按照技术博客的范式生成内容，人审核后发布。

效果

坦率地说，结果超出了我们的预期：

开发时间：从零到上线，整个官网的开发时间只不过是一个人的半天。相比较神策之前维护官网的团队规模和效率，这是一个巨大的提升。

代码质量：AI 生成的前端代码在响应式设计、SEO 优化、性能等方面都达到了不错的水准。当然，不是完美的，但作为 MVP 阶段的官网完全够用。

后续维护：因为代码是 AI 生成的，后续的修改也可以让 AI 来做。改一段文案、加一个页面、调整一个样式，直接用自然语言告诉 Claude Code 就行，不需要去翻代码。

PART05

竞品调研：AI 驱动的自动化监测

为什么需要竞品调研

在 AI 领域，竞品的迭代速度非常快，一周不关注就可能错过重要的变化。但竞品调研是一个典型的“重要但容易被忽略”的工作。

我们的做法：Competitor Watch Skill

为了解决这个问题，我们为 Claude Code 开发了一个竞品动态监测 Skill。这个 Skill 的工作流程如下：

第一，维护一份竞品清单。我们在项目中维护了一份结构化的竞品配置文件，按威胁等级分层。每个竞品记录了名称、官网、目标客群、以及各种信息源（Changelog、博客、GitHub、Twitter、LinkedIn 等）。

第二，自动采集信息。Skill 会按照优先级依次访问各个信息源，采集监测区间内的变化。采集的维度包括：产品功能更新、技术动态、市场动态（融资、媒体报道、用户评价等）。

第三，智能增量更新。如果之前已经生成过竞品报告，Skill 会自动识别上次报告的日期，只采集增量信息，避免重复工作。对于新增的竞品，则会做一次完整的初始调研。

第四，分析与洞察。采集完信息之后，AI 会进一步做威胁评估、机会发现、趋势判断，并给出具体可执行的行动建议。

最终产出的是一份结构化的竞品分析报告，包含每个竞品的详细动态、综合分析、以及行动建议。

价值

这个 Skill 的核心价值是把“想起来才做”变成了“定期自动做”。我们只需要定期运行一次这个 Skill，就能得到一份全面的竞品动态报告，不需要人去一个一个网站翻看。

更重要的是，AI 的分析视角有时候会给你一些意想不到的洞察。比如它可能注意到两个竞品同时在招聘某个方向的工程师，进而推断出这个方向可能是未来的趋势。这种跨信息源的关联分析，人工做起来非常费力，但 AI 可以自然地完成。

PART06

阶段性小结

写到这里，一共五篇文章，我们分享了一个三人团队如何尝试用 AI 来支撑从 0 到 1 的各个环节。

这套方法论的核心

回顾整个系列，我们的方法论可以概括为八个字：文档驱动，AI 放大。

文档驱动意味着，无论是商业计划、产品设计、技术实现还是增长获客，一切的起点都是一份结构化的文档。BP 是商业思考的文档化，Use Case 是产品设计的文档化，Spec 是技术方案的文档化。文档不是代码的附属品，而是一切行动的前置条件。

AI放大意味着，AI 的作用是把人的认知和决策放大 10 倍、100 倍地执行出去。人想清楚了“做什么”和“为什么做”，AI 负责高效地“怎么做”。在前面介绍的每一个环节中，AI 都扮演了这样的“放大器”角色。

但放大器不会改变输入信号的方向。如果你的商业判断是错的，AI 只会让你更快地在错误的方向上狂奔。在 AI 时代，南辕北辙会跑得更快。AI 放大的是人的认知，不是替代人的思考。

这个系列还会继续。后续我会根据实际进展，继续分享在 PMF 验证、定价策略、营销推广、GTM 等环节的认知和经验。

以上都是一家之言，仅供参考。欢迎大家与我交流讨论

END