2026-10-26 · 第1场直播

这份文档把企智AI落地派2026年10月26日晚开播的讨论，按项目和问题重新组织。具体讲清需求、已披露的做法、工具分工、经营方式和踩坑；同一主题后来补充或否定的内容合到一起。正文可以独立阅读，来源放在文末。

文中的已用做法、进行中原型与讨论建议分别说明；报价与效果自述贴近案例标明，未披露的步骤不补成虚构SOP。

一、企业AI服务怎么起步：先分清客户池、产品与实际成交

一位原来做企业服务的参与者，看到AI代理机会后与伙伴成立新公司。到直播时约一个月还没有成交；伙伴主要负责产品，他本人对产品不熟。所谓“一单十万元利润”来自他人介绍，并不是自己做成的订单。他手上原本就有企业客户，但还没有把AI产品拿给这些客户实际测试。

这段经历把三个常被混在一起的资产分开了：有企业联系方式，有客户信任，以及能卖出的具体服务，是三回事。 原来的电话销售和企业服务渠道可以提供接触机会，但不能直接证明这些企业愿意为AI付费。另一经营者说过日投放五千至一万元仍觉得客资质量差，这是单一经营经历，也说明把咨询数量当订单会误判。

直播里较具体的改变来自一家营销工具公司的代理。原产品只是几百元的小软件，代理没有继续解释功能，而是对没有时间操作的本地老板卖服务：按年收费，每周交付约定数量的短视频。老板买到的是持续产出，代理把工具变成交付手段。原文没有披露年费、每周具体条数、续费率和利润，不能补成现成报价套餐。

这里的业务分工很清楚：工具方解决生产能力，本地服务者理解店铺和业务、跟进需求并交付。直播又讨论了县级市场门店承接当地中小客户、复杂FDE项目转总部的设想。它可能把本地门店同时作为服务与获客节点，但当时尚未开店验证，不是已经跑通的加盟方案。

企业服务渠道还谈到前端销售与后台专业人员分开、渠道加价之前把底价和交付内容说清。尤其值得记住的是一次现场修正：对“成立不足一年能否办理”的询问，供应商从笼统肯定改成需要第二天再核实。销售不能把自己尚待核实的资格条件先承诺给客户。直播里的申报期限与报价有混乱，本篇不把它们当政策或官方费用。

二、技术、渠道与售后怎样合作：卖得动不等于交付得起

一位做视频工具的技术人员发现，自己直接售卖时客户不买；把东西交给沙龙里善于做业务的伙伴，反而更容易卖。能力相同，销售结果仍然不同，差别在于客户接触、表达和成交过程。直播没有给出销量和转化率，因此只能记作他的渠道体验。

合作随后暴露出另一面：渠道只管卖，部署、客户问题、维护等工作都回到技术方，技术方承担很多劳动却未必拿到主要收益。这里真正值得复用的经验，是按售前、部署、培训、售后和持续维护分别看投入，再讨论分润。仅按“谁找到客户”分钱，会漏掉交付成本。原文没有给出最终达成的合同与分成，不能替他们算出合理比例。

开源也没有自动消除这类劳动。他把一个兴趣驱动的小程序连代码和部署文档交给群友，仍然遇到别人不会部署的问题。源码公开减少的是拿到代码的障碍，用户仍可能需要环境配置、安装和排错服务。他提到市场上类似工具按年收费，那是所见报价，不是自己的已获收入。

工具方还讲过第三方模型停止或变化给产品造成影响的经历。对于购买持续服务的客户，底层供应商变化最终会落到自己的交付上。直播未披露完整替换机制，但这个问题应在经营上单独留账：客户买的是可持续使用，服务方承担的并不只是最初开发一次。

屏幕自动化原型进一步说明了维护负担。作者用屏幕帧、透明框和手动坐标定位，切换目标界面；按客户ID保存独立聊天历史，调用模型生成回复再贴回界面。它只是半成品，作者也承认出现强退、后续没有完善。界面变化、坐标变化以及操作中断都是持续维护事项。原型“能演示”与“能稳定售后”之间，还有很长一段工作。

开源交付为什么仍需要服务

技术人员还举过自己给熟悉的酒馆业务定做小程序的经历：用户反馈不错，但自己谈销售没有耐心，后来在群里给出源码让人自行部署。他提到同类约4000元/年、计时器另外收费，是当时个人市场观察，不是这套软件已经获得的收入。

接着他说，即使给源码和部署文档，群里仍有人装不起来。因此，“把仓库发给客户”与“让客户在自己的环境持续使用”之间，还有环境准备、配置、部署、升级和排错工作。原文没有公布项目名、公开仓库或许可证；群内发源码不能直接当作允许任意商用的开源授权。

这也补全渠道分成讨论：谁负责演示成交，谁负责首次部署、后续更新与投诉，应在合作时一起算。只按首单销售分账，却把持续服务全留给技术方，是讲者已经遇到的合作问题。

三、工程项目知识中枢：从部门反复要数据到按需生成材料

工程项目总工提出的需求，首先不是写代码，而是减少跨部门反复索取资料。工程部每天记录完成内容与进度，物资、计划等部门分别掌握数据；到了月报、会议纪要或临时汇报时，计划部门还要再找工程部取最新数据。他希望把这些资料汇进项目中枢，提问时直接抽取所需信息。

按他的设想，数据和输出的关系是：

1. 各部门上传本部门每日或阶段性信息。
2. 项目级中枢保存并关联这些材料。
3. 按月报、纪要、即时查询等任务，提取相应数据并组织成所需材料。

他计划在总Agent下面设置五六个部门子Agent，部门人员只使用自己的入口，数据可以上传，不能随意修改。上传权限、修改权限与查询范围，是需求的一部分。 当时没有展示已经实现的权限系统，不能把一句“设好权限”当作验收完成。

作为不熟编程的业务人员，他先用豆包反复讨论想法和整体逻辑，再用办公工具在专用电脑上尝试操作，通过扣子网页做表格相关原型。到直播时，这项尝试才开始不久。这里能学习的是从自己最熟悉的月报和数据联动场景入手，而不是把他的原型误认为已经在项目部正式上线。

关于知识如何保存，参与者给出很具体的文件组织方式：新建项目文件夹作为工作根目录，子目录保存经验、踩坑记录和以后要执行的任务，再让Obsidian读取这套文件。多人输入则可考虑飞书公共入口或多维表格，再把资料汇到本地文件夹。这是组织方式的建议，没有验证豆包、扣子、飞书和本地目录已经自动双向连接。

跨项目复用时，他希望保留行业基础框架，再换入当地标准、公司标准与项目施工特点。这样复用的是资料与流程骨架，不是把一个知识库复制后就自动适用于所有工地。不同地区、公司和项目的差异仍需逐项检查。竣工资料原有费用很高是他的估计，节省七八成则是期望，本场没有给出实际节省记录。

四、工地现场监测是另一条项目线：先把可比对的数据采回来

另一位参与者随即澄清：自己的项目与办公数据共享不同，它涉及现场设备与信息采集。流程是阶段性采集现场信息、定点上传，再根据图纸、材料和工艺要求分析实际情况，指出偏差并给出整改建议。

两个项目应分开理解。办公室中枢主要处理已经存在的部门材料；现场系统先要解决信息能否可靠采集、能否反映施工过程，再谈模型比较标准。讲者认为工程有图纸、规范和可量化要求，适合把重复检查环节交给系统辅助，但没有披露设备型号、采样方法、识别准确率或责任验收。因此“资料员、施工员、监理都被替代”只是愿景，不能当成本次交付结果。

关于本地部署，讨论也没有停在“装在内网就安全”。另一管理单位参与者指出，工作电脑扫描磁盘、拍照、使用U盘都可能受内部制度限制。数据进入系统之前就有边界，本地模型不会自动解除这些限制。工程人员对资料敏感程度的个人判断，也不等于单位已批准使用。

管理单位还提出另一个可落地的小问题：政策文件发布后，财务人员需要人工判断是否废止、是否更新。它与“把所有材料扔给AI审风险”相比，任务更明确——找到文件、确认版本与有效状态、给出可查来源。直播只提出痛点与初步尝试，没有完成这套检索核验流程。

五、两百多个充电桩的经营工作台：先统一看数，再扩运维

一位同时经营快递业务和两百多个充电桩的参与者，从自己的日常工作开始做工具。他的桩分布在驴充充、星星充电、公牛充电、小桔充电等平台，每天分别登录后台、看数据和报表，很麻烦。

他最初没有要求一个复杂大屏，而是要一个统一工作台：每天打开一处，就能看充电数量、订单数量，以及哪些桩存在异常。这个输入输出已经足够明确：输入是四个平台各自的经营数据，输出是统一指标与异常清单。

Agent建议把“人手点一次取数”改为定时脚本，配置运行环境或Docker，周期性采集。他随之意识到，如果脚本跑在自己的电脑，机器需要持续开着。直播没有说明平台接口授权方式、实际频率、失败重试和对账结果，因此不能把“实时抓取四平台”写成稳定完成。

后续需求从经营报表扩展到运维：哪里需要派工、用了什么材料、做了多少施工量、异常点有没有处理、维修人员是否到现场打卡。与前面的充电量相比，这些数据还涉及现场人员录入和任务状态。先做可见的经营数据，再接派工与现场记录，是他需求逐步展开的实际过程。

快递库房的分解、配送统计工具也在调试中。它表明同一经营者可以从多个熟悉业务提出需求，却不证明一套工具已经同时管好两个行业。他说“能帮我做六七成就有价值”，后面又不断审查、排错；这句话适合解释为什么愿意先自用，不能被当作财务或生产系统只要六七成正确就能投产的标准。

六、多Agent协作的两种现实：共享目录与真正可调用的任务链

本场多Agent讨论最有用的部分，是把实际协作能力拆清楚，而不是罗列模型名称。

第一种做法是共享项目目录，由人串联。 一位使用者把项目放在统一根目录，让不同Agent软件访问同一个位置；规定每个Agent开工前读取其他Agent留下的记忆，完成后按版本记下过程、方法和具体修改。方案、架构、开发、审计、调试在这套目录中接续。

这能降低重新解释背景的成本，但并没有自动解决调度。另一使用者尝试用聊天入口接多个API角色，再让主工具充当CEO；有的工具可通过CLI调用，有的不开放MCP或CLI。即使用过通用CLI封装项目，他仍然无法直接控制某个桌面工具，只能让对方读文件理解任务，中间由人操作一次。任务文件能传递信息，不等于软件之间已能自动互相下命令。

共享目录也有代价。有人报告多个编码Agent在同一路径工作，即使用git，仍出现回写冲突、声称完成却找不到相应修改的情况。网络、磁盘或时序原因没有查清，不能把它简单归因于某一个模型。实际缺口是需要知道谁在做什么、哪项修改真正落盘，以及当前应由谁继续。

第二种做法是工具可调用后，再编排任务序列。 另一参与者介绍了通信接口、git worktree隔离与任务序列，依次安排调研、架构、编码、测试、审计。最关键的人工节点放在架构之后：每层模块、要求和接口写细，由人确认，再允许后面的任务继续。测试或审计失败则回到修改，而非把“完成”消息直接当成功。

他自报一次任务运行了48小时无人值守，同时承认这种方式更适合先出demo，质量不如人逐道查看。这是个案自述，没有日志验收。“某工具做测试”在现场还是举例，不应固化成通用最优工具分工。

多模型互审也没有统一结论。有人把同一问题交给四五个工具，再互相审查汇总；另有人说近期客户项目中这样做弊大于利，更愿意按场景分工。可以保留两种经验，不需要替直播裁决一个赢家。最终是否可靠仍要看具体任务、真实改动和验收结果。

共享记忆则有一条较明确的小经验：目录可以分项目、参考材料、记忆与后续演进，规则文件写清路径、工作步骤和边界。长期记忆优先保留会改变未来决策的新发现、纠错和可回溯节点，别重复塞入通用常识。把旧对话全总结进去虽然能继续，但使用者也遇到变慢和质量下降；把客户端上下文窗口设大，并不能证明后台模型真正支持同等容量。

一套实际在搭的工作台：VS Code、CLI、智谱与Obsidian

另一位实践者描述了不同于“飞书拉群”的工作方式：以 VS Code 为统一工作台，把编码工具的CLI或插件放进来，接入智谱模型，再让 Obsidian 与各工具共享本地资料目录。这是他正在搭的框架，没有展示完整安装命令、插件清单或一键调度。

其披露的资料组织步骤是：先分项目、参考资料、记忆和经验演进等目录；把自己的工作规则整理成Markdown；让各Agent接到需求先读对应规则，知道资料路径、执行顺序和能做/不能做什么；之后共用资料再完成分工。目录和规则能减少反复口头传递，但不能因此认定并发写文件不会冲突。

这里还要把三层分开记：VS Code是工作台，CLI/插件承载Agent执行，智谱等是接入的模型。讲者说的是编码工具来自海外、底模接国内模型，不是“海外版VS Code”。同一模型在不同Agent里输出风格不同，是他的使用观察，不是模型能力排行榜。

Chatbox AI与anything-CLI：接了多模型仍不等于控制所有软件

提问者明确提到 Chatbox AI：他把它理解为接入多家API、安排不同角色、在一个入口讨论与分工的方式。这个记录反映他的尝试与期待，本场没有操作演示，不能将所述“像开部门会议”当作Chatbox任意版本原生提供的完整协作功能。

之后他改用另一个办公Agent当“CEO”，希望指挥其他软件；又从GitHub找到原词为 anything-CLI 的项目，尝试把工具封装成CLI/MCP入口，但仍未解决某个桌面工具无法直接连接的问题，最后要由工具读任务文件，再人工接续。

这条失败经验应该和项目名一起留：多API聊天、能够调用某个CLI、跨桌面软件完整编排，是三种不同能力。 想试同类方案，应先拿其中一个实际工具检查是否有可调用接口，再验收命令能否执行、是否真改了产物、结果能否返回；这些是根据本例整理的检查项，不是原文已完成的配置教程。anything-CLI没有仓库地址，保留原词待确认，不替它绑定网上同名项目。

七、AI财税的真实流程：半自动材料处理，加专业人员末审

财税案例在讨论中发生了一次重要澄清。最初听起来像是自动抓发票、记账和报税，作者随后说明：接口抓取尚未吃透，自己现在做的是半自动，资料由人工准备。

他的自用流程是：从税务系统导出一个季度的票据和已公布账目，先由人过一遍、把材料捋清，再交给AI分析、记账和生成报税报表，最后由本人到系统导入或提报。这里的输入不是“网上自动拿来的全部真实经营数据”，输出也不是无需检查的最终申报。

他希望找财税专业人员合作，增加末端审核，多轮检查AI做得对不对，再考虑服务更多客户。计划一年做几十家与已经稳定服务几十家，是不同阶段。作者主动提出担心风险，是这条流程的重要组成部分。

税所参与者进一步补上行业经验：医美内部还有直客与渠道业务，利润、耗材和人员成本比例不同，业务模式也会改变审核重点。懂医美不等于懂建筑财税。一个通用工具看到的账票材料不完整时，分析也无法补出没有提供的真实业务。

双方较有价值的合作方向，是在已有财税顾问客户中增加具体AI服务，而不是财税人员完全转行做陌生行业。税所已有信任关系和行业理解，技术方提供材料处理与初步分析，专业人员保留判断责任。这只是合作探索，当时没有披露签约、价格或部署验收。

软件本地打包与持续升级也被提出，目的是降低企业部署门槛、兼顾数据可控；技术供方同时担心自己的知识库和业务规则被转卖。客户隐私、供方知识产权、数据完整性与专业审查，是不同问题，不能靠“本地部署”一个词全部解决。

八、房屋防水维修：AI获客要接得住真实施工服务

做家庭防水维修的经营者，有自己的工人和工具，过去依赖百度营销，觉得付费投入重。他想让AI收集信息、生成文章，持续发到今日头条和自己的官网，让本地客户能找到自己。别人追问后，他明确说还没用过这套新工作流，所以不能记成已自动发布、已获得订单。

他的经营目标比“多发文章”更具体：先从东莞一个城市做起，每个区域逐步建立自己的施工队，采用直属人员，明确施工流程、报价和保修责任。小程序或软件用于承接这套服务，不是先造全国平台。

这段可以连成完整的需求链：本地客户发现维修需求→通过内容或搜索找到服务→联系或下单→区域施工队执行→按标准报价施工→后续保修可追责。其中只有原有工人和维修业务是当前基础，内容自动化、软件与区域扩张仍在规划，原文没有披露已经实现的订单流转接口。

他对第三方平台的收费与人员管理很不满意，本篇不把这种指责扩成对整个行业的事实。真正能够保留的是他想解决的差异：人员由谁管理、报价如何透明、施工按什么标准、出问题谁负责。流量工具帮助找到人之后，服务质量仍由这些环节承接。

现场有人把不同内容平台的来源权重、地区分发当作解释，也有人分享优化后被学校后勤找到的个例。它们没有形成可验证的搜索算法规律。对这个项目而言，先把自己的服务范围、真实案例和可承担责任讲清，比承诺某平台一定推荐更有根据。

九、真实素材短视频：先澄清镜头要求，再选择自动化程度

本场时间最长的一次工具讨论，起初被回答成“选哪个AI视频模型”，实际需求后来才明确：经营者需要约25至30秒的真实素材视频，画面要可信，不想出现AI生成感。他已经写好三大类结构，哪一秒出现什么步骤、近景远景、人在做什么，都有要求。

他现在最费时间的环节在前半段：从大量参考账号和视频中找合适片段、人工裁切，再放入分类文件夹。后面的混剪、配音、发布可用现成工具做一部分。买过的软件虽然能批量产出，却不符合他的固定镜头、字幕、滤镜和节奏要求，因此弃用。“能生成很多视频”和“能按指定过程选对每一个镜头”，不是同一项能力。

讨论把现有软件大致分成三类：随机素材排列组合、按预设分镜文件夹排列、口播制作。前两类能变化组合，却不一定理解每段素材正在发生什么。用户要的恰恰是语义匹配，而非随机替换。他更偏好可直接调用的视频分析接口，不想为了一个小功能重新开发、部署并长期维护整套软件。

一个有用的方案是先建立素材语义库：

1. 素材入库时，用视频分析API或人工描述片段的内容。
2. 把描述保存为命名、备注或其他可检索信息。
3. 一段视频有多个镜头时，先切成足够细的镜头单元；整段一个笼统描述不足以支持精确选镜。
4. 混剪时根据已确定的步骤找相应镜头，再处理顺序、节奏、配音与字幕。
5. 人最终检查画面是否自然、是否与预定结构一致。

这样把素材库建设与每次成片区分开，避免每做一条都重新分析整个素材库。它是现场提出的实现思路，尚未有实际成本与成片验收，不能写成已经能一键运行的系统。

另一个范围缩减是由本人继续找素材，只自动处理后面的镜头理解和剪辑；甚至让AI先出一版，本人指出哪里不对、人工质检。固定滤镜有时可模板化，但用户说不同片段仍要改缩放和参数，所以“把一个滤镜固定下来”没有解决所有审美问题。

部署讨论也澄清了两个层次。工作流可以放在本地电脑或云服务器，视觉模型可以另外通过API调用。用户希望电脑不开机、手机上传素材后继续运行，才偏向云端。把编排程序搬上服务器，不代表视觉推理也必须自建大模型；反过来，本地有程序也不等于数据没有发往云端。

本场没有得到完整成片或可靠的自动化闭环。关于未授权素材、抹除他人标识和换号应对投诉的讨论，不属于可复制的工具使用流程；素材库方案应用于自有或已获授权材料。这个案例真正留下的是任务定义与选型方法：先让工具处理你最耗时、能验收的一步，别因为软件叫“视频工厂”，就假设它符合自己的每个镜头要求。

十、视频成本怎么比较：预算、模型开销与人工时间分开记

同一位视频经营者说过每月两百元预算，后面又表示如果能替代自己肉眼分析，五百元也可考虑；另一处说每条30秒内容三四元以内可以接受。这些是支付意愿，不能当成系统的实际运行成本。

现场对模型费用争论很大：有人认为便宜的视觉模型足够，有人指出每天五条成片之前还要看很多素材，不会只按最终视频长度付费；有人提醒素材分析、剪辑后检查和返工都要消耗。争论没有给出实际用量账单，因此也没有测出哪个模型在此流程最省。

对这类业务，讨论至少明确了需要分别统计的环节：输入素材总长度、抽帧与理解、镜头选择、成片检查、返工，以及人工最后修改。只计算“分镜之后的混剪”，会遗漏最重的素材观看；只按最终30秒成片估算，也会低估输入量。反复全库扫描和入库分析一次再复用，成本结构又不同。

人工比较也应保持工作量一致。直播提到四千元月薪、每天五条的估计，但没有同地区、同质量和同任务范围的账目。有人花钱买软件仍需自己找素材、改滤镜和修镜头，这些时间没有消失，不能只拿软件订阅费对比一个完整岗位。

工具购买经历还提供了一个小教训：一位用户曾付八千八年费，后来看到九百八年费有类似功能，另有两千九百八报价。没有核对合同、版本和服务范围，这些不能推出全行业价格，更不能证明不合需求就等于诈骗。现场也有人直接反对这种判断。采购时真正需要验证的是自己的样片能否达到指定镜头、节奏和修改要求，而不是只看功能数量。

自动化成本过高时，保留人工找片、切片，只自动组合和部分检查，是现场讨论过的折中。它没有“一次彻底无人化”那么好听，却把范围缩到了使用者能支付、能检查的部分。

十一、AI编码经验：两小时生成、一天调试与正式交付不是同一时钟

一位过去做开发的经营者说，有些管理软件需求明确后，两小时能生成大部分，一天连调试做出。他列出工作台、数据看板、CRM、线索、工时、报价、合同、材料、供应链、财务报销发票与员工权限等模块。

但继续追问后，协作方式和时间范围变得更清楚：本人主要写需求，国外合伙人运行编码工具；并不是本人独立点一下，全系统自动完成。别的参与者也指出，复杂系统不可能只凭一轮生成就结束，正式交付还要打磨与测试。列出了模块，不能证明模块间业务、权限与真实部署均已验收。

成本说法同样不能合成一句“只花几百美元”。直播中出现了不同项目和口径：

• 过去三万多元的软件，伙伴估计如今约150至200美元能做出来，是估算而非实际结算。
• 另一次约500美元的说法，后面又提到一周修改，并不等于两小时全部交付。
• 量化软件从去年研究、先由程序员写，今年二月起改用模型，讲者称当前不到1000美元；对应此前五六万元人力成本，但没有计清自己的劳动和其他费用。

量化项目还说测试了15天。这十五天属于量化项目，不能移到ERP上。 其中盈利自述与否定句还有转写不清，缺乏交易日志与外部核验，本篇不将其作为投资工具或收益经验。

另一个工厂ERP使用者遇到了相反的提醒：自己平常点击各功能感觉没bug，准备部署时让AI按专业部署工程师、架构师角色审查，却不断查出新问题，两天额度消耗很快。现场给出的路径建议是先把架构设计清楚，再执行，再独立测试；工具品牌只是当时个人偏好，不能代替验收。

从两个案例可以保留下来的操作重点是：需求说明、代码初次生成、功能调试、专业检查和正式部署应分别记录。使用专业审查角度，确实能暴露原来没想到的问题；但模型不断提出新问题也不自动证明每个问题都真实存在，应回到代码和可复现行为确认。

本地项目资料、服务端缓存与模型路由分别记录

一次换模型账号的讨论暴露了两个“记忆”概念：本地项目目录和会话资料是否还在，与服务商是否命中推理前缀缓存，不是一回事。现场参与者先以为在说本地缓存，追问后才澄清是在说模型侧缓存。保留本地资料不等于换入口后首次调用必然有缓存；直播也没有测量命中率或账单。其“服务商不留信息”的保证没有被验证，不能从项目存本地推出服务端不接收数据。

另一个可记录的实现思路是 按输入类型路由模型：某位开发者称，收到图片时把本次和接下来几轮切到能处理图片的Flash模型，过了该窗口再回到文本主模型。可复用的是临时切换、保留后续几轮视觉上下文、再切回的策略；模型具体音译与版本未核实，也没测出它在所有任务上更好。应用自己的路由时，应检查切换后能否继续理解前面图片与任务，而不只检查API是否返回成功。

十二、工作记录与录音怎样变成可继续使用的资料

企业周报的需求很直接：工作群平时已经有对话和进展，希望从中提取日报、周报、月报。集团参与者倾向先让子公司低成本体验，再看是否采购。厂商所说内测和免费期限，只是当时介绍，没有经过当前官方核验，不在这里当作长期入口。

一位录音卡使用者分享了磁吸手机记录、转写和总结的体验，自购口述价为999元，型号没有说清。他的方法比价格更值得记：把原始转写与生成摘要分别导出Markdown，再交给Agent对照。 如果只给摘要，第一轮遗漏的小细节往后就很难找回来。保留原转写，才能检查工具名、数字和后面的修正。

直播知识整理也不必先决定“最精彩的十分钟”。有人建议先按技术需要分段，盘点每段发生了什么，再按明确指标筛选；评论、点赞和礼物可以提供线索，但每个人理解的精彩不同，它们不自动等于知识价值。

需要时间线时，应区别事情真实发生的先后与聊天提起它们的顺序；叙述里又有事实、个人感受和情绪表达。把这些分开，有助于避免把“我觉得他已经做成”当作完成证据。现场没有提供可靠的情绪识别方法，也不应把情绪标签当客观测量。

企业推广工具时，另一条推进经验是先找到真正愿意改变业务的一把手，确认对方理解的交付形态，再陪跑教育；接上CRM、MES、ERP的想法，并不等于已经接通。对话、会议与项目经验要成为组织可用知识，需要保留输入、决定、修改原因及后续动作，而不只是把聊天压成几条漂亮结论。

政策与文件问答要能回答“这份还有效吗”

管理单位参与者提出的实际任务并不只是搜索关键词：会计要查某份文件何时发布、有没有废止、之后是否更新，目前还需要人工逐份翻。另有人只是先用豆包、DeepSeek做文件转换和工程量核算，属于个人尝试，并非审计风险已全部自动识别。

因此这类知识库值得保留的不仅是文件内容，还包括版本、发布日期、适用范围和后续替代关系；这是从原文需求提炼的整理建议，本场没有交付现成连接器或规则库。答案应能回到文件出处，不能把搜到一段旧文等同找到了现行依据。

数据入口本身也有约束：对方说扫描磁盘、拍照和插U盘都有制度限制。即使推理部署在本地，资料怎样进入系统仍未解决；个人先学工具与单位正式采购是两条不同路径。

十三、AI培训的具体产品：三小时一对一与标准化内容的取舍

一位刚起步的讲师公开了自己的实际产品：399元，三小时一对一，带用户搭一个简单工作流。通常拿电商商品文案举例，讲清语言、视频等模型的区别，以及工作流和智能体的基本概念。他没有承诺教会某个垂直行业的完整经营。

他的新账号发了约三十条视频、约千余粉，缺的是客户，因此询问自动获客。他说一天有两三单就够，再多自己也忙不过来。这个细节很关键：三小时一对一意味着收入既受获客限制，也受本人交付时间限制。另一人说“两小时能成交五单、一天挣两千”，只是建议者预测，不是已经做出的经营数据。

现场提出了两种改变，均未给出实际执行结果。

第一种是让客户主动咨询：真人直播，在电脑上演示一部分工具与效果，再承接有需求的人。与直接批量私信相比，它试图让需求在演示中显现。需要演示什么、咨询如何转化、每单服务到哪一步仍要明确，不是开播就必然成交。

第二种是把固定内容录下来。对于同一套表格或简单工作流，录成课程供用户自己看、自己操作；遇到问题再一对一服务，减少反复讲同样入门知识。另一套分层方案则提到39.9元录播入门、399或599元一对一、3999元企业课，再按需要配行业工具。这些是现场设计的产品价格梯度，不是推荐售价，也没有相应付费转化和满意度数据。

工具配套的思路是：别只讲概念，给出可操作的工具和工作流，让用户能做出具体产物。与此同时，课程教方法、代搭建交付一个工具、持续陪跑经营、承诺收益，是不同服务。把工具或一本书写进合同，不会自动回答退款与结果责任问题。现场就有人追问“不能变现能退款吗”，也有人明确反对“学完赚大钱”的话术。这种质疑应跟产品方案一起保留。

线下培训参与者想做长期项目，甚至同时考虑自习室和卖货；其他人更偏向线上快速变现。分歧不是谁一定正确，而是目标与投入不同。较具体的建议是先有一批真实用户，再承担场地、老师和组织成本；线上内容或广告引来咨询，再选择是否到线下交付。原文没有披露一所已成功运营的AI培训店。

选方向时还要看自己的已有能力。讲师有机会向熟人学习直播带货，对方日销售十几二十万元、本人估计利润一两万元；现场对利润就有异议。销售额不能直接当净利润，也不能因为熟人愿意教，就忽略供应链、投流和自己的试错成本。

本场还出现了制造恐惧、虚假招聘转培训、用空壳切割责任等说法，它们不作为可复用经营方案。课程讨论真正能留下的，是明确学员要做出的东西、减少重复教学、看清获客与交付能力是否匹配，以及把承诺范围写实。

授课材料里也有可拆出的重复工序

一位有办公教学经验的人说，自己先把讲课内容写好，再放进已有PPT模板生成，之后简单调整就能讲课。原文没有说明生成软件或模板来源，不据此添加某款演示工具。这条小经验对应的是把重复版式与每次变化的内容分开：可先标准化模板，再把时间留给本次教学内容与演示检查，而不是每次重做整套样式。

这与前面的录播方案相连：固定入门操作可以录下来，变化的问题再一对一处理。但对已经熟练使用办公软件、当前不做这些任务的人，这门课未必有用。产品价值要匹配具体使用者，不是“用了AI”就自动产生购买理由。

获客与交付分工：先算每单余量，再谈把流量外包

直播还提出一个具体合作想法：讲师专注教学，由擅长获客的人带来客户；399元订单，介绍方每单拿约99或100元，其余由讲师承接交付。这是现场建议，并没有披露已签合作或真实获客成本。

按这一建议作条件计算：每单剩约299—300元；若仍按三小时一对一交付，折合每教学小时约100元，尚未扣除备课、答疑、退款、工具和税费等成本。这是对口述报价的算术整理，不是讲师实际利润。若渠道另有保证金或固定费用，单量不足时可能连前期成本都收不回，现场也明确提醒了这一点。

因此这条商业模式值得留下的不是“给别人佣金就能自动来客”，而是把职责与单位经济一起看：谁承诺什么、什么算有效订单、谁授课答疑、退款后佣金如何处理、自己每天能交付几单。后一组是由本例归纳的合作核对项，直播没有给出合同模板或最终分账规则。

获客方法的另一条线是本人上镜、电脑演示部分实际效果，让有需求的人主动咨询；它与固定内容录播、个别问题一对一，可以组合成不同服务层级。但演示带来多少咨询、咨询转付费多少、学员能否独立做出产物，本场都没有实测，不能把建议者的“五单”等预测当成交记录。

十四、二手设备与实体经营：高加价背后的资金周转

本场一位新媒体从业者转做同城二手回收，接触倒闭店铺、公司、酒店的整包设备。他说自己因此看到很多实体经营困难，但这个样本天然集中于退出市场的商家，不能推出所有实体行业都不能做。

他讲了一种设备参与经营的方式：收购已经装修或配置过的门店设备，与房东商量短租试运营，再用自己熟悉的新媒体方式获客。棋牌室例子是别人原投入约30万元，他自述约2万元接设备，先付三个月租金；运营起来后找人接手，执行者拿七成、自己三成。火锅店则举了原投入200万元、自己约5万元取得设备的对比。

这些金额与分成均是讲者自述，没有合同或账目。可理解的模式是把投入放在设备上、让经营者负责执行，失败时尝试收回设备，而不是不断追加所有经营费用。但设备是否能取回、还能卖多少、租约与拆运怎么处理，原文没有说明，不能称零风险。他后来还提到棋牌室的其他引流目的，因此本篇也不把它写成已验证的棋牌室营业利润案例。

二手业务自身的变化更有启发。最初做撮合，货不进仓；后来觉得利润薄，改成自己收货，仓库从三百到五百平方米扩张。账面上拥有更多货、单件加价更高，却可能把赚来的钱全部压在仓库里。其他人提醒他，库存和现金流必须一起梳理。

他举床的例子：收购约35至50元，找工人拉回仓库，再卖三四百元。这里是进价与售价的比较，没有扣运输、人工、仓租和滞销。原文说“毛利三百个百分点”等口径混乱，不应把加价率直接写成毛利率，更不能当净利。

另一人拿高周转分销作对照：同样一笔钱，一个月转几轮，与二手货压半年一年，收益结构不同。即使单件利润低，快周转可能更有效率；但“1%也不怕”不是所有业务通用结论，仍要计坏账、在途、仓储、人员和变现时间。对二手经营，低租金可以减负，不能让库存占款自动消失。

工业二手设备、叉车、二奢等方向被提到，但讲者自己承认未研究大型工业设备，还涉及安全、鉴别和专业门槛。听说利润高，与有能力判断设备状态、承担售后，是两回事。本章能复用的是识别资金与责任落在哪，而不是给出入行稳赚名单。

十五、资源撮合与FDE平台：先验证供需连接，再讨论规模

直播间本身展示了一种资源连接过程：经营流量的一方与做FDE交付的一方认识，线下多次互访、核对彼此能力，再讨论合作。对外叙述的项目是FDE案例互认和企业下单、交付方接单的平台，demo仍在内测，主持人尚未看过最新版本。

“五亿元”在不同发言中先被称为入股估值，后又被叫融资额；后来还出现天使轮、A轮和可能只是意向的说法。因此本场不能确认融资到账，更不能把它写成平台商业模式已经成功的证据。能保留下来的，是反复线下校正、资源匹配和从demo继续迭代的过程。

另一位考虑转行者先实地看团队和小项目公司，再比较自己学习自建与找成熟公司合作、成立分支机构。到直播时没有最终决定。它提醒的是先了解对方实际交付，而不是被融资故事替代了考察。

平台是否只做撮合，也被问得很具体。讨论到H100、H200等硬件采购时，需求方关心货源是否可靠、报价是否合理、坏了谁保修。供应商竞争规则、三方合同、类似担保的安排只是建议，还没有解决硬件鉴别和售后责任。平台从介绍双方升级到“保障交付”，承担的工作会明显增加。

模型中转的安全讨论同样不能用一个承诺结束。有人提出高权限Agent可能接受伪造的工具返回，执行不该执行的操作，这是威胁模型，没有展示实际攻击日志。再加一个只读审计Agent，也不能独立证明中转经营者不读取资料。端到端加密方案还需要源端协议配合，普通HTTPS连接或某张证书不能自动证明这些能力。

对小规模起步，参与者另提出一种更轻的路径：已有直播社区先连接有业务问题的人与能交付小工具的人，不一定一开始就造全国平台。模式方提供获客和项目经验，执行者负责落地；有人建议执行方多拿、资源方拿三成，但这是谈法而非统一行情。原文没有实际项目结算，所以仍需按真实交付责任讨论。

项目组织还有一条反向经验：一位做自家Agent产品的人，明确它只管理自己的Agent闭环，不负责控制所有外部软件；群聊功能因为没有必须用的业务场景，后来删掉了。功能能做不等于必须保留。资源聚合、任务编排、交付担保与跨软件控制是不同产品问题，先说清服务哪一种，再谈规模。

资源平台要回答的交付问题：报价之外还有真假与保修

平台模式讨论落到硬件时，举了H100、H200和原词Pro6000等货源例子。问题从“能找到卖家”变成：货是否真实、报价口径是什么、出了问题谁保修、平台如何协调。有人建议让供应商竞争、制定规则、采用三方合同和类似担保的安排；这些仍是提议，没有展示已经执行的验货和赔付流程。

同段模型中转讨论还指出一个风险模型：如果Agent放开了本地执行权限，中间服务返回的内容或工具调用可能影响本地动作。这不是现场已复现攻击。只读审计Agent、承诺“不作恶”或普通HTTPS，也没有在本场证明能消除服务端风险。可留下的经营要求是把可验证的交付责任和权限边界讲清，不能把一句担保或身份背书当作技术验收。

十六、值得单独留下的小经验：聚焦、验证和工具选择

内容制作要按目标受众决定复杂度。 有团队介绍过招生剧情视频的制作链：故事、场景、白模，再用AI套模，成片一分多钟，面向老人。它是实际披露的流程骨架，没有给出工具、提示词和转化指标，不补成完整制作教程。另一人把此前AI视频做法迁移到文旅内容，试了约二十条、流量不好；现场也有人提醒画面只是多个因素之一，不能单因归咎AI。

兴趣项目与经营项目用不同验收。 数字宠物形象、不同年龄版本、虚拟旅游和社交是参与者的兴趣实践与产品探索；生成旅游照片不是真实出行，内容有反馈也不等于收入。若目标是经营，另一讲者建议先看业务能否产生收入，再谈提效和成本，以一个月至两三个月设个人试验期限。这是他的止损习惯，不是所有行业的统一盈利窗口。

一个垂直小业务可以很大，不必什么都做。 一位旅游经营者说自己只卖景区票，没有同时包揽整个旅游行业。他介绍平台挂链接、用户购买、平台核销的链路，但没说明AI具体负责哪一步，不能把平台本身的核销功能算作Agent成果。海外景点提前购票需求仅作为待研究机会，不把当时口述当当前购票政策。

筛选和替人决定有边界。 购物助手的讨论从“自动买”转向给候选一二三，由人最后确认。了解偏好可以帮助比较，不能直接推出付款授权；购买过程本身也可能是用户想保留的体验。

工具解决不了所有外围限制。 企业外呼中的重复呼叫筛选，可以是AI任务；运营商封禁是另一个问题，现场主持人明确说AI不能自动解决封号。讨论中的线路规避不作为工具经验。零基础求职者被建议先从平台、算力销售或代理接触客户，积累行业需求与渠道，这是个人职业建议，未核验岗位，不保证一定最快转行。

采集行业知识先问具体数据任务。 有参与者转向具身智能数据采集，提到动作、触觉等任务场景。数据规模、采集区域和未来需求下降等没有实证，不将它包装成完整赚钱赛道。行业词很大，能记录的仍应落在具体需要采什么、用来解决什么问题。

不把一次失败或热情承诺当全部结论。 一位创业者用十次尝试可能只有两次成功说明自己如何接受失败，并举预期一百万元、实际二十万元也能接受的心态例子。这不是成功率统计。与另一人提出设备投入和短期试验相连看，有用的是事先知道自己投入什么、失败后还能留下什么，以及实际结果是否达到自己的继续条件。

本场反复出现“任何行业都能赚钱”“营销治百病”“三年窗口”“几成的人赚钱”等绝对说法，各方数字还互相冲突。可独立留下的是上面具体的人、任务、输入输出、尝试与限制；这些小而可核对的经验，比把口号再压缩一次更便于使用。

工具、源码入口与待确认线索补录

以下按本场实际提到的用途保留名称。带链接的是本轮额外核对的官方入口或仓库；链接仅帮助查找，不证明直播中所述效果。源码可见、社区开源版、商业平台和概念方法分别标明，不把它们统称为免费开源工具。

待确认的工具与项目线索

这些名称确实出现在原转写中，保留其任务与使用状态以便继续查找；音译、同名、版本或开源授权没有确认。不根据搜索到的相似名称代填仓库，也不把未跑通的尝试列为成功工具链。