波仔
🐦 第2章 扣子 AI 应用开发平台介绍
📄 一句话概括

四类人在用：内容创作者、业务部门的人、独立开发者、传统软件团队。 他们能走到的地方不一样，卡住的地方却几乎在同一处——平台之外的东西：自己写的接口、 自己机房里的库。 这一节把三类人的天花板量出来，也回答一个实际问题：团队里该派谁去学。

📝 本章和前面几章的关系

前三节讲平台本身，这一节讲用它的人。 这一节的判断会直接影响你读到第 11 到 16 章那些案例时的心态—— 那些案例是「产品经理照着做也能做出来」的难度，不是「运营照着做也能做出来」。 如果你的团队里只有运营，建议先做 7 章之前的东西，把案例章节当参考而不是作业。

一、四类人，四种动机

内容创作者要的是产能：一条素材变十条、一篇稿子变五个标题。 他们不在乎架构，只在乎今天能不能多发两条。 业务部门的人要的是把重复劳动接走：录入、登记、答疑、汇总。 他们最清楚痛点在哪，也最能判断做出来的东西有没有用。 独立开发者要的是快速验证：一个想法，两天内做出能给人试的版本。

传统软件团队要的是不重复造轮子：模型调用、知识库检索这些，自己写要两个月，平台上一周能接完。 四种动机对应四种做法：创作者堆模板，业务部门堆流程，独立开发者堆速度，软件团队堆集成。 同一套功能，用法完全不同。

二、三类人的天花板

演示里六个需求交给三类人：不写代码的运营、会点技术的产品、能写代码的开发者。 结果是运营一项、产品四项、开发者六项。 运营那唯一一项是「把公司制度做成问答机器人」——资料类需求，正好是平台最成熟的一块。

产品能多做三项：接飞书表格、做多轮对话流、改卡片配色。 这三项的共同点是「要理解数据结构」，但还不需要写代码。 开发者六项全过。差的不是聪明，是那两条路——代码节点和自定义插件——只有他会走。

三、卡住的地方几乎在同一处

三个卡点：写接口、连内网、接自家数据库。 后两个其实是同一件事：平台之外的东西。 你自己写的接口，你自己机房里的库。 这也解释了一个常见现象：平台上的官方演示都很顺，一接到公司真实系统就卡住。 不是平台不行，是演示里从来没有「公司真实系统」这一环。

所以评估一个项目能不能做成，别问「平台支持吗」，问「它要连的那几个系统，有没有一个能出接口的人」。

四、团队里该派谁去学

先派一个业务侧的人。 他懂痛点，能判断做出来的东西有没有用。 他学不会写代码没关系，前七章够他做出六成的东西。 再配一个能写代码的。 不用全职，一周抽半天。 他的活是把那两成卡点打通：写一个插件、连一个库、调一个接口。 别派一个完全不懂业务的人。 他会做出一堆技术上很漂亮、没人用的东西。 平台降低了技术门槛，抬高了「想清楚要做什么」的门槛。

这个配置在演示里能对上：业务侧的人负责那六项里的四项，技术侧的人补剩下两项。

五、动手 Demo：六个需求，三类人

六个典型需求，按「不写代码的运营、会点技术的产品、能写代码的开发者」三类人各判一次：做不了、 要人帮、能独立做完。

# 0 = 做不了，1 = 能做但要人帮，2 = 能独立做完
NEEDS = [
    ('把公司制度做成问答机器人', 2, 2, 2),
    ('接飞书多维表格当资料源',   1, 2, 2),
    ('按接口文档写一个自定义插件', 0, 1, 2),
    ('做一个多轮追问的客服对话流', 1, 2, 2),
    ('把回答卡片改成品牌配色',   1, 2, 2),
    ('接自家内网数据库',         0, 0, 2),
]
for name, a, b, c in NEEDS:
    print(name, a, b, c)

实跑输出：

--------------------------------------------------------------------
三类人，三种天花板
--------------------------------------------------------------------


  ① 六个需求，谁能自己做完
  --------------------------------------------------------------------

| 需求 | 不写代码的运营 | 会点技术的产品 | 能写代码的开发者 |
|---|:---:|:---:|:---:|
| 把公司制度做成问答机器人 | 独立 | 独立 | 独立 |
| 接飞书多维表格当资料源 | 要人帮 | 独立 | 独立 |
| 按接口文档写一个自定义插件 | 做不了 | 要人帮 | 独立 |
| 做一个多轮追问的客服对话流 | 要人帮 | 独立 | 独立 |
| 把回答卡片改成品牌配色 | 要人帮 | 独立 | 独立 |
| 接自家内网数据库 | 做不了 | 做不了 | 独立 |

  六项里能独立做完的：运营 1 项、产品 4 项、开发者 6 项。
  ! 运营唯一能独立做完的那项，正好落在「资料类」——这也是平台最成熟的一块。

  ② 卡住的地方几乎都在同一处
  --------------------------------------------------------------------
  运营卡在「写接口」和「连内网」；产品卡在「连内网」；开发者六项全过。
  三项卡点里两项是同一个东西：平台之外的东西——你自己写的接口、你自己机房里的库。
  这也解释了一个常见现象：平台上的演示都很顺，一接到公司真实系统就卡住。

①六项里运营只能独立做完一项，产品四项，开发者六项。 这个分布不是能力歧视，是「会不会写那两段代码」的差别。 ②运营能做完的那一项，正好是「资料类」——上传文档、配个检索、调个提示词。 这也是平台做得最成熟的地方。 ③三个卡点里两个是「平台之外」：自己写的接口、自己机房里的库。 平台演示里永远没有这两样，所以演示总是很顺。 ④团队配置那条值得单独记：一个懂业务的加半个能写代码的。 全派技术侧会做出没人用的东西，全派业务侧会卡在那两成上。

30 秒实验

  1. 把你团队里的需求按这六项对一遍，看有几项落在「运营做不了」那一列。那就是要找人帮的地方。
  2. 找一个人，问他：我们公司哪几个系统能出接口。答不上来说明这件事还没人管。
  3. 如果你是运营，先做资料类需求。它是投入产出比最高的一块。

常见误区

  1. 「零代码平台谁都能用。」能用和能做完是两件事。六项里运营只能独立做完一项。
  2. 「派个技术最强的去学。」技术强的人容易做出技术上漂亮、业务上没用的东西。先派懂痛点的人。
  3. 「演示能跑通就能落地。」演示里没有内网、没有自家接口。落地时卡的就是这两样。
自测三问（点开对答案） 1. 运营能独立做完的是哪一类需求？ —— 资料类。上传文档、配检索、调提示词，这一块平台做得最成熟。 2. 三个卡点为什么说「几乎在同一处」？ —— 因为后两个都是平台之外的东西——自己写的接口、自己机房里的库。平台演示里永远没有这两样。 3. 团队里该派谁去学？ —— 一个懂业务的人加半个能写代码的人。前者判断有没有用，后者打通那两成卡点。

人到齐了，该看图纸了。 下一节把平台拆成五层：模型、能力、编排、知识、发布，看每一层各管什么、缺一层会出什么事。

相关笔记