Sabitlenmiş Tweet
技术人转 AI 产品，正在做 SocialDataX。
我会在这里记录：
1. AI 编程 / Vibe Coding 实践
2. 产品从 0 到 1 的构建过程
3. 社媒数据接入 AI 工作流的实验
4. 技术人做产品踩过的坑
中文
device｜技术人转 AI 产品
43 posts
device｜技术人转 AI 产品
@devinchen2025
技术人转 AI 产品｜AI 编程 / Vibe Coding 做 SocialDataX：把社媒数据接入 AI 工作流 记录产品构建、增长实验和真实踩坑
Katılım Ocak 2025
36 Takip Edilen2 Takipçiler
@iluciddreaming 这个判断有道理。不是所有东西都应该塞进 MCP。
我现在更倾向于按场景选：简单操作用 CLI/API/Skills，复杂一点、需要被 Agent 稳定发现和复用的数据入口，再考虑 MCP。
中文
我把所有 MCP 都删了。
GitHub 官方 MCP server 加载一次要 54,000 tokens。`gh --help` 是 562，模型训练数据里本来就有。
MCP 是给人包装的 JSON 官僚系统。agent 是进程，进程用 CLI 和 API 跟世界对话，几十年都这样。
Skills 30-50 tokens，触发时才展开。CLI battle-tested，可版控，可 debug。
这才是给 agent 造的工具。
中文
@MacroNorthStar MCP 最有价值的地方，我感觉不是协议本身多复杂，而是把“模型怎么连接外部工具和数据源”这件事标准化了。
后面真正拉开差距的，可能是每个垂直场景里有没有稳定、可复用的数据入口。
中文
MCP与A2A：AI Agent互联互通协议标准之战加速
2026年，AI Agent从概念验证走向大规模企业部署，而连接Agent与工具、数据源以及多Agent协作的协议标准正在形成两极竞争格局。Anthropic主导的MCP（Model Context Protocol）和Linux Foundation力推的A2A（Agent-to-Agent Protocol）正在成为这场标准之战的焦点，这不仅关乎技术路线，更决定未来五年AI应用层基础设施的控制权归属。
MCP由Anthropic于2024年11月率先开源发布，旨在为AI模型与外部工具、API和数据库之间建立标准化通信层。MCP架构的核心是Client-Server模式：Host负责发起请求，Client维护与外部Server的连接，Server则暴露具体工具或数据访问接口。开发者无需为每个工具单独编写集成代码，AI模型可以统一的协议调用一切外部资源。2026年5月，MCP生态系统已拥有超过一万个社区服务器，覆盖GitHub、Slack、Stripe、Google Drive等主流平台。Cloudflare于2026年初发布了企业级MCP部署参考架构，NSA则发布了MCP安全设计指南，标志着MCP已进入对安全高度敏感的政府和大型企业场景。在商业落地层面，Anthropic与微软365的深度集成已进入GA阶段，PwC于2026年5月宣布基于Claude构建企业技术平台和交易执行系统，Anthropic本身也完成了新一轮估值达750亿美元的融资。
A2A协议由Linux Foundation于2025年联合40余家企业发布，专门解决多Agent之间的任务分发、能力发现和状态同步问题。当一个客服Agent需要协同后端知识检索Agent、计费Agent和物流Agent时，A2A提供标准化的交互框架。与MCP不同，A2A定位于Agent与Agent之间的协作层，而非单Agent的工具调用层。截至2026年5月，加入A2A生态的企业已超过150家，主流云服务商均已支持该协议并进入生产环境。A2A与MCP并非绝对竞争关系——在真实部署中，两者往往协同工作：MCP处理单Agent的工具调用，A2A编排多Agent协作流程，形成互补的分层架构。
MCP的核心优势在于先发优势和生态系统规模。由于发布早、开发者社区活跃，MCP已形成事实上的网络效应，工具提供方倾向于优先支持MCP而非等待A2A的成熟。A2A则依靠跨厂商互操作的理念获得大型云服务商和系统集成商的青睐，规避单一厂商锁定风险是其在企业市场的主要卖点。两套协议的分化也折射出不同的商业战略：Anthropic推动MCP成为行业默认标准，本质是希望在AI工作流中占据类似USB之于硬件生态的枢纽地位；Linux Foundation和其生态成员则试图通过A2A构建一个不依赖于单一AI供应商的互操作层，防止生态话语权向少数公司集中。
商业化路径上，两种协议都面临共同的挑战。企业在采用这些协议时需要承担迁移成本和厂商锁定风险，协议本身的安全性治理仍是早期问题——NSA和Cloudflare的安全白皮书均指向同一隐患：当Agent能够以标准化方式调用几乎任何外部工具时，攻击面将大幅扩展，凭证管理和最小权限原则需要重新设计。此外，AI Agent工作流平台市场正处于高速增长期，2026年市场规模估计约50亿美元，2030年有望突破400亿美元，其中协议层的价值约占整个生态价值的5%至8%，这意味着围绕协议标准的竞争将是百亿美元级别的商业博弈。
从产业影响来看，MCP与A2A的竞争结局将深刻塑造AI应用的分发格局。类比历史，USB协议统一了硬件设备连接，PlayStation和Xbox争夺过游戏生态标准，而今天的AI Agent协议之争同样是基础设施控制权之争。谁的协议成为事实标准，谁就将在AI工作流中拥有类似操作系统级的分发能力。短期来看，MCP在工具调用和单Agent场景的渗透速度更快，其生态规模的优势在2026年已相当显著；A2A则在多Agent协作和跨平台互操作场景中具备结构性优势。然而，更可能的情景是两者走向融合而非单一胜出——业界已在讨论以某种元协议统一两层的可能，最终形成底层工具调用（MCP）、中层协作（A2A）、上层商业平台各司其职的分层架构。协议标准之争的终局，将在今明两年见分晓。
中文
@gaoren7716 这个方向我很认同。Agent 真正落地后，大家会发现问题不只是“会不会调用工具”，而是工具、数据源、权限和结果复用怎么长期管理。
这块慢慢会从 demo 变成基础设施。
中文
很多人还在做 AI Agent demo，但已经有人开始做"Agent 的基础设施层"了
Archestra 做的不是一个 Agent，而是：AI Agent 的操作系统（OS）
它把整个 Agent 世界收起来重新排了一遍：
MCP Orchestrator 统一管理所有工具调用 Security Layer 防 prompt injection + 数据泄露 Agent Runtime 支持 workflow / sub-agent / trigger 全链路 observability（token / cost / trace） 企业级 RAG 内置数据接入（Notion / Jira / GitHub） 多模型统一入口（GPT / Claude / open-source） 组织级 MCP registry + 权限系统 Kubernetes-native 部署架构
关键变化在这里：
以前：一个团队一个 Agent
现在：一个组织一个 Agent 平台
很多人还在卷 prompt 和模型能力，但下一阶段竞争可能是：谁能掌控"Agent 运行层"
github.com/archestra-ai/a…
#AI #Agents #MCP #Infra
中文
@onorangerock 我现在做产品也越来越觉得，早期不是证明自己能做 100 分，而是先找到用户愿意用的那 20 分。
Vibe Coding 会让做东西变快，但判断哪 20 分值得做，还是最难的。
中文
@sunmer575399 这个组合很实用。
我现在也越来越觉得，内容运营不一定缺生成工具，反而缺一个能长期沉淀的工作台。
飞书多维表格做内容日历、选题池、复盘记录，挺方便的
中文
@_blue_sweater_ 这个问题我也踩过。发布时间这种东西，AI 给的报告只能当参考。
更靠谱的方式可能是自己留一张表，把发布时间、内容类型、互动数据和复盘结论持续记下来。
样本不一定大，但至少是自己的真实数据。
中文
@LunaAI519 我最近也有类似感受：很多需求最后是要把模型、工具、数据入口、工作流拼成一个能交付的方案。中间最难的往往是判断和取舍。
中文
我有一个很强烈的判断：
以后 AI 行业里，可能会出现一种新角色，叫「API经纪人」。
客户给出一个需求，或者一个业务痛点。
产品架构师先把需求拆成一份解决方案：
需要哪些模型、哪些工具、哪些数据接口、哪些工作流、哪些自动化节点。
但真正决定成本和利润的，不一定是架构师，而是背后的「API经纪人」。
它会直接判断：
这个任务用 GPT 划算，还是 Claude 划算？
用 Gemini 够不够？
哪些环节可以用便宜模型？
哪些环节必须用强模型？
图片、语音、视频、检索、代码、数据分析，分别调用谁最合适？
同样的效果，哪条 API 组合路径成本最低、速度最快、稳定性最高？
未来的竞争，很可能不是单纯比谁会用 AI，而是比谁能把 AI 能力调度得更精准。
客户要的是结果。
产品方要的是利润。
中间真正值钱的，是「匹配效率」。
谁的 API 经纪人匹配更精准，谁的报价就可以更低。
谁的报价更低、交付更稳，谁就更容易赢得客户。
所以我越来越觉得，未来 AI 应用公司的核心壁垒，不只是产品界面，也不是提示词，而是背后的 API 调度能力。
表面上看，大家都在卖 AI 产品。
本质上看，大家都在做一件事：
用最低的模型成本，交付最高质量的结果。
这就是 API 经纪人的价值。
中文
今天有人提醒我：
你写的东西有点 AI 味。
我想了下，确实。
可能是我最近太想把 SocialDataX 讲清楚了，结果每条都写得像产品说明书。
后面还是多写真实过程吧：
怎么找用户，
怎么判断需求，
怎么把社媒数据接进 AI 工作流，
以及哪些想法后来发现不对。
中文
@fankaishuoai 这个判断很扎心，但挺真实。
很多 C 端 AI 产品不是输在模型，而是输在数据和场景进不来。平台数据不通，Agent 就很难从 demo 进入真实流程。
所以我现在越来越觉得，“数据入口”本身就是 AI 产品的一层基础设施。
中文
国内做 C 端 AI 产品，我的结论是：基本没戏。
不是能力问题，是生态问题。微信、支付宝、抖音各自圈地，数据完全不互通。想做一个 Agent 帮用户打通这几个平台——不可能，API 根本不开放。连接个 Telegram 通知都要绕弯路，ICP 备案动不动几周，处处设卡。
微信和抖音生态崛起之后，国内就再也没有新的应用层创业公司能冒出来了。他们没有给应用生态留任何空间，只留了内容生态。你可以在上面做内容，不能在上面做产品。
在国内想做事，只有两条路是通的：
一，做 2B 的轻咨询，不碰太重的软件开发；
二，直播卖货或卖课——2C 唯一的通道。
没有第三条。
中文
@adr1an_builds @dotey 这个拆分很有启发。
同一个能力在不同场景里，入口确实不一样：CLI 适合工程师，MCP 适合 Agent，Skills 适合封装流程，API 适合系统集成。
早期产品不一定要追求一个入口打天下，更重要的是贴近真实使用路径。
中文
飞书がlark-cli（AIエージェント用CLI）をOSS公開。「CLI vs MCP vs Skills」の役割を整理すると設計判断がクリアになる。
ユーザー側にコマンドラインは不要——入口は自然言語、裏でCLI/APIが動く設計。Kairosが目指してるのもまさにこれ。
元ツイ: @dotey x.com/dotey/status/2…
宝玉@dotey
飞书 CLI 开源了，为什么 AI Agent 时代，大家都在做命令行工具？ 飞书刚开源了一个命令行工具 lark-cli，能让 AI Agent 直接操作飞书：发消息、查日历、写文档、建多维表格、发邮件、管任务。你跟 AI 说一句话，它自己去操作飞书完成任务。 类似的 CLI 还很多，三周前 Google 也开源了 gws，让 AI Agent 操作 Google Workspace。2026 年了，所有想接入 AI Agent 的产品，都在做 CLI。 【1】先说 CLI 是什么 CLI（Command Line Interface），就是你在电脑上打开一个黑底白字的终端窗口，敲一行命令，回车，电脑帮你干活。 比如你要查今天的日程，不用打开飞书 App 找日历，敲一行： lark-cli calendar +agenda 日程就列出来了。 没有按钮，没有图标，没有花哨的界面。CLI 比图形界面早了二十多年，在 Windows 时代逐渐没什么人用了。但 AI Agent 时代，又火起来了。 【2】为什么 AI Agent 时代，大家都在做 CLI AI Agent 要干活，就得有操作工具的能力。你让 AI 帮你订会议室，它需要能访问日历系统。你让它帮你整理客户数据，它需要能读写表格。你让它帮你部署代码，它需要能跑部署命令。 总得有一个接口让 AI 去调用。API 也能做这件事，但 CLI 有一个 API 不具备的优势：CLI 是自描述的。AI 碰到一个陌生的 CLI，敲一下 --help 就知道有哪些能力、怎么用、参数怎么填。API 不行，AI 得先拿到文档、弄清端点、搞懂认证方式，才能动手。CLI 自带说明书，AI 拿来就能用。 而且 CLI 天然是用文本交互的，输入是文字，输出也是文字。AI 最擅长处理的就是文字。反过来，让 AI 操作 GUI 就绕远了，得截图、用视觉模型识别按钮在哪、再模拟鼠标去点，一行命令能搞定的事拆成四步，每步都可能出错。对 AI 来说，CLI 就是天然的操作界面。 【3】那 MCP 和技能呢 让 AI Agent 操作外部服务，现在主流有三种方式：MCP、CLI、技能（Skills）。三者不是互相替代的关系，各管一件事。 CLI 是实际干活的工具。装完之后终端里就能跑命令，查日历、发消息、建表格，都是 CLI 在执行。 MCP 也是让 AI 操作外部服务的，但方式不同。MCP 是提前把工具清单注册给 AI，AI 随时能调用，但清单本身常驻上下文窗口（可以理解为 AI 的“工作记忆”，空间有限）。就算 AI 暂时不用某个工具，它的描述也占着空间。CLI 是 AI 需要的时候自己去终端敲命令，用完就走，不占上下文。 另一个区别是组合能力。CLI 可以靠管道和参数组合出没预设过的操作，比如： lark-cli calendar agenda --next-week | grep“张三” | wc -l 一行命令就能查出下周和张三有几个会。MCP 的每个能力都需要提前注册，要实现同样的效果，得单独定义一个新工具。 不过 MCP 有自己的适用场景。在不支持命令行的环境里（比如 Cursor、Claude 桌面端），MCP 是唯一选择。两者各有所长：能访问终端的场景用 CLI 更轻量灵活，不能访问终端的场景靠 MCP。 技能是给 Agent 看的说明书。它不干活，但告诉 Agent 这个 CLI 有哪些命令、什么场景该用什么参数、出错了怎么处理。没有技能文件 Agent 也能用 CLI，靠 --help 自己摸索。有了技能文件，Agent 一上来就知道该怎么操作，成功率高得多。 简单说：CLI 是手，MCP 是另一种手，技能是肌肉记忆。飞书这次开源的项目，CLI 和技能一起提供。 【4】怎么给 AI 写好一个 CLI 不是随便写个命令行工具 AI 就能顺畅地用。如果你想给自己的产品做一个面向 AI 的 CLI，飞书的设计有几个值得参考的地方。 第一，help 文本是你最重要的文档。AI 碰到不认识的 CLI，第一件事就是运行 --help。你的 help 文本就是工具说明书、参数规格、使用指南三合一。别写那种“Usage: myctl deploy [flags]”就完事的帮助信息，要写清楚每个参数干什么、什么时候用、有什么默认值。飞书 CLI 还有一个 schema 命令，可以快速查询任何 API 方法的参数、请求体、响应结构、支持的身份和权限范围。AI 看到这些信息就能自己决定怎么调用。 第二，支持 dry-run，这是为 AI 设计的安全网。AI 会自己做决策，有时候它理解错了你的意图，或者匹配到了不该动的数据。dry-run 相当于一个“预览”机制。 举个例子，你让 AI 帮你删除飞书多维表格里上个月的过期数据。如果直接执行，删错了就没了。加上 --dry-run，AI 会先跑一遍，返回类似这样的结果：“将要删除以下 47 条记录：2025-05 的过期任务 23 条，已归档项目 24 条。未做任何实际修改。”你看了觉得没问题，再让它去掉 --dry-run 真正执行。Google 的 gws 也做了同样的设计，它的技能文件里甚至写死了一条规则：对所有写入和删除操作，必须先 dry-run。 第三，错误信息要能指导下一步操作。人看到“Permission denied”会自己去查文档。AI 看到“Permission denied”就卡住了。飞书 CLI 的做法是：告诉 AI 你缺了什么权限，顺便把申请权限的命令也给出来。比如 lark-cli auth login --scope“calendar:calendar:readonly”。AI 看到就能自己修复问题，继续干活。为 AI 设计的 CLI，每一条错误信息都应该包含三个要素：哪个参数出了问题、具体错在哪里、下一步应该执行什么命令来修复。 第四，返回结构化数据，控制好输出量。飞书 CLI 支持 json、csv、table 等多种输出格式。对人来说 table 更顺眼，对 AI Agent 来说 json 更可靠。好的 CLI 不只是能跑通，还要方便被别的工具消费。同时要控制输出量。AI 的上下文窗口有限，如果一个命令返回一万行日志，上下文就炸了。飞书 CLI 提供了分页参数（--page-limit）和过滤参数，让 AI 能拿到它需要的那部分数据就好。 不管你是设计 CLI 的人还是用 CLI 的人，记住这条：让 Agent 动手之前，先让它 dry run 一遍。 【5】装完之后，你动嘴，Agent 动手 装完之后用起来就是：你说一句话，Agent 去操作飞书把事情办了。 你开完会，跟 AI 说“把刚才会议里提到的所有待办都提出来，该发文档的发文档，该建任务的建任务”。AI 读会议纪要，拆解出待办事项，然后逐条执行：用 lark-cli doc create 在飞书里建文档，用 lark-cli task create 建任务并指派给对应的人，用 lark-cli im send 把结果通知到群里。整个过程你只说了一句话，Agent 在终端里跑了一串命令。而且因为有 dry-run，你可以让它先预览一遍要建哪些任务、发给谁，确认没问题再真正执行。 你要约一个五人跨时区的会，跟 AI 说“帮我看看下周大家什么时候有空”。AI 去查每个人的日历和时区，推荐几个时间段，你选一个，会就建好了。 你甚至可以让 AI 在飞书文档里直接帮你写初稿，你在文档里留评论提意见，AI 读完评论自己改。整个协作过程不用离开飞书。 安装也简单，npm install -g @larksuite/cli 装 CLI，npx skills add github.com/larksuite/cli -y -g 装技能文件。你甚至不用自己记这两步，把项目地址 github.com/larksuite/cli 发给 Agent，让它自己安装、自己学会怎么用。 【CLI 的回归】 过去四十年，计算机的界面进化方向一直是从 CLI 到 GUI，从文字到图标，从键盘到触屏，对人越来越友好。 AI Agent 时代，方向反过来了，软件的用户变成了 AI Agent。CLI 这个为文字世界设计的接口，恰好是 AI 最顺手的工具。 既然 Agent 成了软件新的用户增长点，那么像飞书提供 CLI 也不稀奇，与其等着社区来写 MCP 适配层，不如直接做一个 AI 原生的 CLI，完全开源，无需注册审批，让所有 AI Agent 都能接入。 这也带来一个绕不开的问题：Agent 的权限怎么给？不给权限，什么都做不了；权限太高，又怕 Agent 理解错意图干出不可逆的事。毕竟还做不到让 Agent 代你审批、代你发全员邮件。dry-run 能兜住一部分风险，但真正要让 Agent 在企业里大规模跑起来，权限体系、审计追踪、人机协作的边界，都还在摸索中。 但换个角度想，当年我们把公司的钱从保险柜搬到网银，把合同从纸质搬到电子签，也都是一步步摸索出来的。CLI 和 dry-run，可能就是这个过程里的第一步。 而飞书做这件事，其实有一个别人不太容易复制的优势：它本身在企业协作领域已经足够成熟，消息、文档、日历、审批、多维表格、任务，这些能力都是现成的。现在把这些能力通过 AI 原生的 CLI 全部开放出来，大概率会成为国内对 AI Agent 最开放、最友好的企业级接入入口。这件事的价值不止是多一个工具，更像是真正在为 Agent 时代搭建企业级基础设施，把权限、审计、组织能力开放给整个生态，对行业落地 AI Agent 会是很关键的一步。
日本語
@iml1s @alin_zone 我也觉得这个方向很关键。
AI Agent 真正进入工作流，不只是能调用工具，而是要接上团队已经在用的协作场景。
飞书、多维表格、审批这些入口如果打通，很多业务数据就能自然变成 AI 可用的上下文。
中文
@alin_zone 飞书 MCP 这个思路很赞，AI Agent 直接控制工作流工具是未来趋势。三步配置能跑通说明门槛已经很低了，期待后续支持更多飞书功能，比如多维表格和审批流程。
中文
技术人转 AI 产品后，我开始把“能不能做”往后放一点。
先看用户是不是已经在用很笨的方法解决问题：
手动整理信息，
反复复制粘贴，
到处切工具，
最后再丢给 AI 分析。
如果这个动作每天都发生，AI 产品才有机会变成工作流。
中文
@JitengX53878 这个问题本质上是“上下文新鲜度”。
Agent 不只是需要会推理，还需要拿到当前、可信、结构化的外部信息。代码文档是这样，业务数据也是这样。
很多工作流卡住，其实都卡在这一层。
中文
Coding agent 写新库代码时，危险不只是“不会写”，而是凭旧训练数据编出过时 API。
Context7 把当前、按版本匹配的库文档和代码示例接进 Claude Code / MCP 工作流。
Apiara 收录 Upstash 仓库。适合查快变文档；别把社区索引当唯一事实源。
apiara.ai/zh-CN/skills/c…
中文
@ma_zhenyuan 很认同。竞品分析和工作流方案之所以能卖更高，不是因为 AI 多写了几段内容，而是里面有数据来源、判断框架和交付经验。
AI 是放大器，但前提是流程本身能稳定复用。
中文
@FLMdongtianfudi 这个场景挺典型：小红书代运营真正难的不是生成一条文案，而是把规则、历史内容、审核结果和客户反馈沉淀进流程。
AI Agent + 飞书多维表格适合做这层协作，不一定要一上来就追求全自动。
中文
副业项目 2：基于AI Agent的“小红书违禁词”合规代运营
📍 推荐平台：小红书 + 微信私域 + Notion/飞书多维表格
🎯 核心赛道：合规科技/电商SaaS工具/降本增效
💡 赚钱逻辑：小红书2026年算法愈发严格，品牌方极其头疼“笔记被限流”。你利用AI Agent（自动化机器人）帮商家批量生成“绝对合规”的文案和图片，做商家的“风控保镖”。
💰 预估收益：按账号托管收费，单账号月费300-800元；接企业批量单（10-50个账号）月入1.5万-5万元。
🛠️ 实操步骤：
第一步（准备与定位）：不要做教别人做号的人，要做“避坑工具人”。在小红书搜索“限流”、“审核不通过”，收集高频违规词库。注册账号名为“XX合规实验室”。
第二步（内容/产品制作）：
搭建AI Agent：使用Coze（扣子）或n8n工作流，搭建一个自动抓取小红书最新审核规则的机器人。
生成“安全词库”：利用AI将违规词转化为同义词替换库（例如“最”换成“太”，“第一”换成“优选”），并自动生成排版模板。
第三步（引流与交付变现）：
在小红书发布“2026最新审核红线清单”免费PDF，作为诱饵引流到私域。
在私域提供“AI合规检测”服务：客户发来文案，你用Agent跑出风险分并修改，收取服务费。积累客户后，转型为月度托管。
⚠️ 核心壁垒/避坑建议：平台规则瞬息万变，必须每日更新词库；不要承诺“100%过审”，否则容易引发纠纷。
中文
发现一个国产大模型“王炸”！蚂蚁刚出的 Ling-2.6-1T，目前在 OpenRouter 上居然可以免费白嫖 ！
这玩意儿可不是那种只在实验室刷榜的玩具。实打实的万亿参数（1T）配合 MoE 架构 ，主打的就是“高智能 + 极低生产成本”。速度极快、指令跟随极准，而且因为它把 token 效率当成了第一公民，跑多步复杂 Agent 工作流毫无压力，绝对是真正的生产级效率杀器。
体验地址：ling.tbox.cn
光说不练假把式。我昨天突发奇想，用了它超强的语义理解和逻辑拆解能力 ，让它给我深度盘点了一下：“现在的环境下，普通人零门槛能落地的靠谱副业有哪些？”
结果它输出的方案直接把我惊艳到了，不仅避开了常见的割韭菜套路，给出的实操步骤更是清晰到可以直接上手！
以下是Ling-2.6-1T给我推荐的5个副业赛道：
中文
@haiweiyue @0xAA_Science 抖音这类 API 需求最好拆成几个稳定入口看：搜索、详情、评论、作者资料、作品列表。
教程本身是一部分，更关键的是后续能不能接进 AI 分析、表格协作或 Agent 工作流里，不然很容易停在一次性调用。
中文
@himself65 这个需求很真实，而且预算信号也很明确。
如果目标是搜索、详情、评论、作者资料这类只读研究场景，关键不是“能不能调一次”，而是稳定性、成本和结果结构能不能长期接进工作流。
我最近做 SocialDataX，也在补这一层：socialdatax.com
中文
做 AI 产品后，我越来越不把“用了什么模型”放在第一位。
模型能力当然重要，但真正影响留存的，往往是更具体的几件事：
数据能不能进来，
结果能不能复用，
流程能不能接上每天的工作。
很多 AI 产品不是输在生成能力，而是输在没进入真实工作流。
SocialDataX 现在主要补的，就是这个数据入口层。
中文
@beefnoode 飞书这个方向我也很看好。它厉害的地方不是“又多一个 AI 工具”，而是能把 AI 放进团队原本就在用的协作流里。
如果业务数据能稳定进多维表格，再接 Agent / 工作流，很多运营和分析动作会自然很多。
中文
飞书的野心绝不止于办公协作，而是新时代的企业AI基础设施！
相比于其他竞品，飞书生态和AI整合最深入、最全面：
飞书CLI、多维表格+AI工作流、定制Agent应用以及妙记等等
飞书Agent已经深度参与我们团队的工作当中：
1⃣自动总结群聊内容并安排to do
2⃣进行项目管理并且持续跟进
3⃣基于多维表格进行数据复盘
最近也在和飞书生态的朋友交流，他们最近半年AI生态的发展真的是突飞猛进
飞书目前的战略很明确，全力做好AI生态，垂类应用就交给开发者，把最好的铲子卖给企业和开发者
企业 AI 转型真正落地，不是做几个聊天机器人那么简单
而是要把 AI 嵌入到企业协作、数据流程和组织管理当中
可以预见的是，在企业AI转型这个赛道中，飞书作为基础设施的重要性会越来越高
中文