AI 泡沫争论背后，企业究竟能用 AI 做成什么？Busabase 团队的 7 项落地实践

模型越来越强，围绕 AI 的投入也越来越大。但企业负责人关心的往往是更具体的问题：买了工具、接了模型之后，到底哪一项工作变好了？

“AI 泡沫”（AI bubble）讨论的是，今天的估值与投入，能否被未来的需求、收入和利润支撑。这与“AI 能不能完成一项任务”有关，却不是同一个问题。一个工具有用，整个行业也可能存在过度投资；一场演示很惊艳，也未必意味着公司已经用出了回报。

把问题放回企业内部，判断就具体多了。一篇稿子能否正式发布？报告里的机会有没有人跟进？代码完成之后，谁来验收？负责人要看的是这些工作有没有向前推进。

Busabase 团队把 AI 用进了自己的内容、运营与协作。以下七项实践，来自实际使用中的工作记录。它们展示了已经完成的工作，也保留了目前还需要人处理的部分。

先看共同的工作方式：观察、决策、行动

这七项工作可以放进同一个小循环：观察 → 决策 → 行动 → 下一轮观察。数据、需求、用户反馈和上轮结果进入观察；智能体整理成报告或建议，人通过聊天补充判断、品味和取舍；确定的行动形成任务，执行结果再写回记录。

日常入口可以就是你已经连接的智能体聊天窗口。它展示报告，你说“同意这个方向，但先补证据”或“按这个标准做”，智能体把意见关联到具体方案，再创建或更新任务。报告是决策的依据，审阅是其中的活动；实际权限和已有授权决定哪些工作可以执行。

下面保留已经发生的实践，并为每项补上一套可照着搭建的起步结构。表名、字段和聊天内容是简化示例，配图是产品风格的界面示意，不是内部截图或真实经营数据，也不代表公开了团队的完整内部表结构。

准备一个工作区

先按智能体入门指南连接已有智能体。每个场景用一个文件夹归拢资源，复用已有数据表。**数据表节点（Base）**保存记录；**文档节点（Doc）**保存目标、政策和质量标准；**技能节点（Skill）**保存智能体反复执行的方法。报告表也属于数据表：报告正文可以使用 Markdown 字段，周期、来源、决定和任务关联使用各自的字段。

各表之间用关联字段连接，时间用日期字段，进度用单选字段，指标用数字字段，证据和外部产出用网址或附件字段。长报告放正文，能决定下一步的状态和关联单独保存。人的一次性意见留在报告或任务中，可重复使用的标准写入文档或技能。

外部数据仍需要接好的接口、导出文件或采集工具；智能体及其工具负责执行，调度器负责定时启动。仅创建节点，不会自动接通分析平台、发邮件或部署代码。先手动跑通一轮，再设置定时或事件触发。

01 一批多语言文章，从“稿子写完了”走到正式发布

一篇文章可能同时有五种语言，正文、封面和修改意见分散在不同地方。编辑确认之后，还需要有人找到最终版本、提交内容、保留日期，并检查上线结果。最后这一段工作很容易被低估。

最近一次交付里，团队把 25 篇文章、125 个语言版本经过确认的正文和配图提交到 Busabase CMS。每篇文章的五个语言版本作为一个 变更请求 提交、合并，之后回读正式记录，逐个检查生产链接。最终，125 个文章直链全部返回正常响应。

其中有四篇是后来补交的旧任务。整理时，团队回到原始关联日报核对日期，让它们分别归回原来的两天，而不是全部显示为补交当天。这看似是一个小细节，实际需要任务依据、最终内容和发布记录能对得起来。

智能体承担的是获授权后的上传、提交、合并与核验。标题、正文、视觉是否可以发布，仍由内容负责人确认。链接可访问也只是上线检查的一部分，不能代替对内容质量与阅读体验的判断。

这项实践的产物很具体：正式文章、对应语言版本、配图，以及每次变更的记录。以后改一个事实或一张图，能定位到应改的版本。

查看完整示意图

在 Busabase 中怎么搭建

在“内容交付”文件夹中，先组合三类数据表，并准备“编辑与发布标准”文档和“多语言内容交付”技能：

可以这样对智能体说：

检查这篇文章的各语言版本，整理缺少的正文、封面和日期依据。在聊天中把待确认项给我。按我确认的范围提交更新，发布后逐个检查正式页面，把结果关联回这项交付；日期有疑问先查来源，不要改成今天。

例如，内容交付记录先列出各版本的缺项；确认后，每个 CMS 版本关联一条检查结果。发现图片失效，就保留具体失败项并创建修正任务。下一轮读取这些检查记录，只补未完成项。检查通过要覆盖正文与媒体，不能只记录网址返回正常。

02 搜索日报里的一个热词，先成为可核查的问题

“AI bubble”本身就是一个例子。团队的搜索日报记录到这个词在美国的短期搜索热度，同时出现了与中国、泡沫破裂含义有关的关联查询。

如果直接把热词放进标题，再接上一篇产品介绍，文章很容易脱节。搜索者想理解的可能是估值、投资回报或某篇报道，正文却在讲工具操作。

在实际研究记录里，这个词最初被保留为观察项：有热度，但原始事件与独立的读者问题尚未核清，所以没有自动据此创建写作任务。编辑需要先判断，读者是在寻找一篇报道的解释、投资风险分析，还是企业使用 AI 的实际经验。几种需求需要不同的材料；内部业务实践能够提供使用经验，产业估值则需要市场与财务证据。

团队把搜索观察、关键词、目标问题、已有页面和执行任务关联起来。被选中的任务可以回到报告，查到为什么做它、现有内容缺什么、怎样算完成；没被选中的词也保留原因。

这里能检验的结果是：热词有没有变成一个值得回答的问题，任务有没有对应产物。流量和商业回报要继续看发布后的数据。

查看完整示意图

在 Busabase 中怎么搭建

建立“搜索选题”文件夹，配上“读者问题与内容边界”文档和“搜索研究与内容执行”技能：

聊天指令示例：

看本周搜索观察和已有文章，先判断读者要解决什么问题。把证据不足的选题留在观察中。给我一个值得写的方案；确认角度后再创建关联任务，并把最终文章和后续搜索表现写回。

一条选题记录可以是“需要补充原始事件证据，暂不写作”，对应任务就是调查而非发文。确认写作后，沿“观察 → 决定 → 任务 → 文章”追踪。下一份报告按稳定选题标识找到原任务，回看是否交付，再按页面和统计窗口观察效果。

03 同一条社媒内容，先认准作品，再谈表现

运营复盘时，一张“播放量不错”的截图通常不够。它属于哪个账号、哪条作品？什么时候发布，什么时候采集的指标？收藏为零，和暂时读不到收藏数据，需要不同的后续动作。

团队在 Busabase 中分别保存账号、作品、指标和来源状态。实际作品记录包含平台作品身份、公开链接、发布时间，以及播放、点赞、评论或收藏等可读取指标，并标明数据的来源与更新时间。

这让智能体可以围绕明确的作品整理数据，运营人员也能回到对应记录核查。一个主题分发到不同平台，分别保留表现，避免把不同口径混成一个漂亮总数。

并不是每个平台、每条作品的字段都齐全。缺少公开直链就待补；某项指标不可读就保留缺口，不替它填零。团队据此决定补数据、调整表达，还是继续观察。

这一阶段已经做成的是作品与可见表现的关联。是否增加投放、修改内容或再次发布，需要运营判断和相应授权；记录齐全本身不能证明增长。

查看完整示意图

在 Busabase 中怎么搭建

在“社媒运营”文件夹中准备以下数据表，以及“平台指标口径”文档和“采集与复盘”技能：

聊天指令示例：

复盘这批作品，先核对账号、作品链接和采集时间。把缺失指标与零值分开，按平台比较。给我建议；我确认后，生成补数据或调整内容的任务，并保留来源快照。

例如，“收藏数据未取得”会生成采集检查任务，而不是“收藏为零”的内容结论。用“平台＋作品标识”匹配作品，用采集时间区分快照；调整后仍关联原作品或新发布版本。下轮在同口径窗口比较，才知道变化来自哪里。

04 一次身份更正，让客户与伙伴的后续工作少走弯路

业务资料中，同一个名字可能出现在多个地方。有人是潜在客户，有人是合作伙伴；如果仅凭名字相同就合并，后续跟进很容易建立在错误关系上。

团队有一次实际资料整理：负责人明确某位联系人是伙伴，随后更正资料归属，保留确认依据，并列出机构、合作分工等仍待补的信息。这个更正没有被写成一次新会谈，也没有顺手与另一份同名客户记录合并。

智能体可以从获授权的沟通材料里整理要点、识别待补字段、准备变更，让业务负责人核对。身份、商业条件、合作承诺和下一步日期，由有依据的人确认。

产物是一份下一位同事能接着使用的资料：关系是什么，确认到哪一步，还有什么未知。它降低了“重新翻聊天、重新猜关系”的必要性。

企业从这里起步，并不需要先做一个全自动销售系统。把一次沟通中的已知与未知分开，就已经能改善交接条件。

查看完整示意图

在 Busabase 中怎么搭建

在“客户与伙伴协作”文件夹中复用现有联系人资料，并准备“关系确认与交接标准”文档和“资料整理”技能：

聊天指令示例：

根据这次沟通核对联系人资料。把确认事实、推断和未知分开，给我看修改建议。此人是合作伙伴；只按这个决定更正分类，缺少的组织与分工创建补充任务，不要合并其他同名记录。

结果应当是原联系人分类被正确更新，核对记录保留人的决定，跟进任务保留未知事项。找不到稳定身份依据时，先标为待确认。下一次沟通补齐资料后更新原任务，不把资料纠错写成一次新会谈或新增商机。

05 研发交付，让“验证通过”旁边有可查看的证据

AI 可以很快改出代码，但“代码写完了”之后还有很多问题：需求是否满足，关键界面是否正常，测试覆盖的是哪些场景？负责人需要能据此判断，而不只是收到一条完成通知。

团队把代码变更、问题与验收记录放在 Busabase 中组织。实际验收记录中，有“通过”的结论，也有附在对应记录下的证据图片。复核时可以回到具体变更，查看当时依据了什么。

在这个过程中，智能体适合准备检查项、执行被允许的检查、整理失败情况与结果。验收者判断证据是否覆盖需求，是否还需要补测。一次检查通过只覆盖当次检查范围；发布和部署还要遵循各自的授权流程。

这项实践让验收依据有了固定位置。问题复现时，团队可以回看旧证据、发现漏项，再更新后续检查方法。

查看完整示意图

在 Busabase 中怎么搭建

建立“研发交付”文件夹，用“验收与发布标准”文档保存预期体验和检查范围，用技能说明复现、验证与回填方法：

聊天指令示例：

根据这个问题和验收标准，在允许的环境中复现并修复。把检查场景、结果和证据写入关联验收记录。在聊天里说明覆盖和缺口；按已确认的发布范围推进，并保存实际部署版本与生产复测结果。

示例任务可以是“提交失败时，按钮应恢复可用并显示解释”。验收记录要指向实际版本和操作证据；失败就回到原任务继续修复。部署后复测另存结果，下一次出现同类问题时回看漏掉的环境或步骤。不会因为验收表里写了“通过”，就自动获得发布权限。

06 产品周报，把“用户来了”继续追问到“用户用了什么”

如果周报只写新增注册人数，团队可能会错过更重要的问题：这些人有没有完成第一项有价值的动作？卡在哪里？下周先改获客，还是先改上手流程？

团队的产品周报把注册与使用行为放到一起分析，并保存指标窗口、来源及后续判断。有一份实际周报指出了新增与后续使用之间的落差，而没有只把新增当作增长成果。

对比也需要核口径。当上一期发布快照与这次统计窗口不一致，报告会说明哪些数值只能作为方向参考，不能直接当作严格的环比变化。

智能体在这里准备可核对的数据和分析材料。经营负责人决定目标、优先级和资源投入。下一期再回看行动是否执行、问题有没有改善。

形成的产物是一份可以继续追问的周报。负责人可以据此讨论下一轮行动。

查看完整示意图

在 Busabase 中怎么搭建

在“产品运营”文件夹中准备指标口径与产品目标文档，技能规定读取数据、汇报、创建任务和复查结果的步骤：

需要查看操作路径时，可以用 GA4 漏斗探索观察各步骤的完成情况，用 Clarity 行为指标寻找连续点击等线索，再回到具体操作验证。

聊天指令示例：

看本周注册和关键操作数据，结合已经接入的 GA4 摘要、Clarity 证据与用户反馈。说明统计口径和缺口，提出一项上手体验改进。确认后创建调查或修复任务；下周先回看它是否上线、是否解决原问题，再比较行为变化。

例如，流失与连续点击只构成调查线索。负责人确认先调查，编码智能体复现后再判断是否修复。不要把分析平台中的不同用户或会话强行对应。周报关联原始观察和改进任务，后续窗口带上部署版本，区分“还没做”“已上线待验证”和“证据支持改善”。

07 把一次修正写进技能，下一次运行重新验证

一个智能体在某次对话里终于理解了规则，并不意味着下一个会话也知道。每次重讲，工作量会回来；没有读到新规则，旧错误也会回来。

团队把部分操作方法维护为 Busabase 中的技能。自动任务开始时读取当前方法，并在运行记录里留下加载版本的信息。这样，当执行结果不对时，可以核查它究竟用了哪套规则。

实际操作中，团队也遇到过方法已经更新、任务入口仍保留旧文字的情况。处理不仅是修改一份说明，还要检查后续实际运行有没有读到新版本、有没有按要求执行。

这让流程维护有了可检查的对象：方法、版本、执行入口和运行结果。有效步骤可以继续复用，出错的地方也能被修正。每项技能的权限范围和审核条件仍要明确，复用不会自动扩大智能体的授权。

企业能从一项反复做的工作开始：把输入、步骤、例外和验收条件写下来，让另一个智能体按同一方法接手，再检查它交出的结果。

查看完整示意图

在 Busabase 中怎么搭建

在“工作方法”文件夹中，把可执行的方法与实际运行分开保存：

聊天指令示例：

把这次纠错整理成工作方法的修改建议，保留失败样例。按我确认的要求更新技能和相关任务入口；下一次运行先读取当前技能，记录版本或内容哈希，再用这个样例核对结果。不要只回复“已记住”。

记录到“技能已更新”还不算闭环。要能从改进记录打开技能变更，再找到读取了新方法的运行及其交付证据。如果入口仍引用旧指令，就修正入口后再验证。先选一个重复任务试跑，达到验收要求后再扩展到其他任务。

企业 AI 的价值，要到实际工作里检验

这七项实践没有解决所有问题。文章上线后是否带来有效访问，整理数据后是否减少复核成本，研发证据是否缩短验收时间，都需要继续测量。

它们已经把一些具体工作往前推进了：内容走到正式发布，热词进入有依据的选题判断，作品与指标能够对齐，业务关系可以核查，验收依据能够回看，周报能追问使用，方法能够跨运行维护。

这些变化给企业提供了一个比观看演示更实在的起点。选一项每周都会重复、输入相对清楚、有人负责验收的工作，约定产物，跑完一轮，再让另一位同事接手。记录实际花费的执行和复核时间，以及返工、采用和业务结果，才能判断要不要扩大投入。

Busabase把数据表、文档、技能与 AirApp 放在团队共同使用的工作区。智能体通过技能、MCP、CLI 或 API 接入，每次写入保留变更历史，需要人确认的重要改动可以等待审核。同事与后续智能体再从这些记录继续工作。

今天可以先跑哪一轮

选一个场景，用上面的起步表结构保存一条输入，让智能体提出一项建议。在聊天里给出真实的取舍，再把一个任务跟踪到结果。检查你能否沿记录找到：原始依据、人的决定、实际产出，以及下一轮该读取什么。

如果想进一步搭建周期运行的机制，可以接着读如何用 Busabase 搭建自我改进的智能体。它把同一套循环展开到 SEO、邮件和产品运营。先验证一轮交付与接手，再决定是否扩大投入。