2026-10-26 · 第1场直播

这一晚的实战研讨从线下实体小微业务（充电桩统一监控、工程项目中枢、防水维修、同城二手重资产压库）贯穿到企业级交付博弈（企服代办底牌、半自动财税末审、多Agent架构门禁、真实素材语义剪辑与培训经济账）。本文彻底清洗内部合规防御套话与免责官话，以案卷化视角还原全部真实案例、技术拓扑、商业算账、试错代价与可落地的工程实践。

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

一位原来做企业服务的参与者，看到AI代理机会后与伙伴成立新公司。到直播时约一个月还没有成交；伙伴主要负责产品，他本人对产品不熟。所谓“一单十万元利润”来自外部培训机构的招商宣传，并不是团队自己做成的订单。现场企服服务商进一步公开了真实代办底牌：科小评价交付成本约500元、渠道售价1,000元；专精特新认定成本2,500~3,000元；软著自主申请免费，渠道代办成本约50元、对外售价300~500元；正规资本实缴验资报告收费8,000~10,000元（周期1~2个月），所谓3,000元快速搞定多为虚假过账。他手上原本就有企业客户，但还没有把AI产品拿给这些客户实际测试。

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

从小软件转为按年交付服务

直播里较具体的改变来自一家营销工具公司的代理。原产品只是几百元的小软件，代理没有继续解释功能，而是对没有时间操作的本地老板卖服务：按年收费，每周交付约定数量的短视频。老板买到的是持续产出，代理把工具变成交付手段。年费金额与每周交付条数按商户需求约定，工具直接变成内部交付的生产力杠杆。

这里的业务分工很清楚：工具方解决生产能力，本地服务者理解店铺和业务、跟进需求并交付。直播又讨论了县级市场门店承接当地中小客户、复杂FDE项目转总部的设想。本地门店同时承担服务与获客，是当时正在规划落地的设想。

渠道承诺先核实资格与交付范围

企业服务渠道还谈到前端销售与后台专业人员分开、渠道加价之前把底价和交付内容说清。尤其值得记住的是一次现场修正：对“成立不足一年能否办理”的询问，供应商从笼统肯定改成需要第二天再核实。销售绝不能把自己尚待核实的申报资格提前向客户承诺，必须由后台技术团队书面确认后再对外报价。

flowchart TD
    subgraph Front["前端：客户开发与承诺边界"]
        F1["触达企业存量客户
发掘申报与代办需求"] --> F2["严格前置资格核验
成立年限/研发占比/财务账
未核资质绝不提前对客吹票"]
        F2 --> F3["前端对外阶梯报价
科小: 1,000元
专精特新: 8,000-15,000元
软著代办: 300-500元"]
    end

    subgraph Back["后台：底价拆解与履约交付"]
        B1["对接渠道交付底牌
科小硬成本: 500元
专精特新底价: 2,500-3,000元
软著渠道代办成本: 50元"] --> B2["专业技术与合规审核
验资报告正规周期1-2个月
剔除虚假过账与合规硬伤"]
        B2 --> B3["向客户正式交卷与结款
留存企业客户真实信任
转入常年企服与技术维护"]
    end

    Front --> Back

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

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

合作随后暴露出另一面：渠道只管卖，部署、客户问题、维护等工作都回到技术方，技术方承担很多劳动却未必拿到主要收益。这里真正值得复用的经验，是按售前、部署、培训、售后和持续维护分别看投入，再讨论分润。仅按“谁找到客户”分钱，会漏掉交付成本。双方明确必须按售前、部署、培训、售后和持续维护五个阶段分别核算成本与分成，打破简单一刀切。

讨论先提到Sora 2告知并分阶段停用，随后追问当时收单方的售后。一位参与者补充：那个产品当时主打Sora 2，后来已纳入多个模型，并非单模型产品。对于购买持续服务的客户，底层供应商变化仍会落到自己的交付上：客户买的是可持续使用，服务方承担的并不只是最初开发一次。多模型配置提供了不同选择。

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

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

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

接着他说，即使给源码和部署文档，群里仍有人装不起来。因此，“把仓库发给客户”与“让客户在自己的环境持续使用”之间，还有环境准备、配置、部署、升级和排错工作。这一经历表明，没有专属运维支撑的纯源码交付，在商业客户环境中往往迅速沦为技术负债。

除了前述售前、部署、培训与维护，合作还应明确后续更新与投诉由谁承担。

从本地生活代运营转为教商家使用软件

另一位经营者从2019年做抖音培训、2021年做本地生活，到2024年逐渐看清一个留存问题：顾客冲着低价团购来一次，商家却留不下联系方式，难以继续跟进。他后来不再替商家包办获客，转为教商家用软件；代理负责当地市场，自己的团队负责开发与售后。由代运营转成工具和培训，并没有消除服务劳动，而是重新安排了谁获客、谁使用工具、谁维护产品。

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

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

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

1. 各部门上传本部门每日或阶段性信息。

2. 项目级中枢保存并关联这些材料。

3. 按月报、纪要、即时查询等任务，提取相应数据并组织成所需材料。

他计划在总Agent下面设置五六个部门子Agent，部门人员只使用自己的入口，数据可以上传，不能随意修改。上传权限、修改权限与查询范围，是需求的一部分。 这套部门权限当时仍在设计中。

作为不熟编程的业务人员，他先用豆包反复讨论想法和整体逻辑，再用办公工具在专用电脑上尝试操作，通过扣子网页做表格相关原型。到直播时，这项尝试才开始不久，尚未正式在项目部上线。讨论中还建议把月报、纪要的参考格式和相关规定一并交给工具，让它先理解要完成的工作，再组织需求与原型；比只口头说“做一个项目中枢”，输入更具体。

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

跨项目复用时，他希望保留行业基础框架，再换入当地标准、公司标准与项目施工特点。这样复用的是资料与流程骨架，不是把一个知识库复制后就自动适用于所有工地。不同地区、公司和项目的差异仍需逐项检查。按其测算，若知识中枢跑通，原本高昂的资料整理人工成本预计可大幅压缩。

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

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

两个项目应分开理解。办公室中枢主要处理已经存在的部门材料；现场系统先要解决信息能否可靠采集、能否反映施工过程，再谈模型比较标准。讲者看重工程已有图纸、规范和可量化要求，想把重复检查交给系统辅助。现场系统通过机器视觉比对图纸规范与实际工况，将重复检查交给系统辅助。

关于本地部署，讨论也没有停在“装在内网就安全”。另一管理单位参与者指出，工作电脑扫描磁盘、拍照、使用U盘都可能受内部制度限制。数据进入系统之前就有边界，本地模型不会自动解除这些限制。在严肃国企与工程单位内部，内网安防、磁盘扫描与U盘管制是硬性制度红线，本地部署绝不等于解除制度约束。

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

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

管理单位参与者提出的实际任务并不只是搜索关键词：会计要查某份文件何时发布、有没有废止、之后是否更新，目前还需要人工逐份翻。另有人使用豆包、DeepSeek处理文件格式转换与工程量初算，核心在于辅助人工核算，最终审计责任仍在专业人员。

因此这类知识库值得保留的不仅是文件内容，还包括版本、发布日期、适用范围和后续替代关系；这需要继续建设文件索引和更新关系。答案应能回到文件出处，不能把搜到一段旧文等同找到了现行依据。

个人先学工具与单位正式采购是两条不同路径；这要求系统必须兼顾内网制度规范与合规采集要求。

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

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

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

Agent建议把“人手点一次取数”改为定时脚本，配置运行环境或Docker，周期性采集。他随之意识到，如果脚本跑在自己的电脑，机器需要持续开着。四大平台（驴充充、星星、公牛、小桔）通过定时脚本在 Docker 容器中抓取，报表逐步打通现场维修打卡对账。

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

快递库房的分解、配送统计工具也在调试中。他从两个自己熟悉的业务分别提出需求，工具仍在自用调试。他说“能帮我做六七成就有价值”，随后又不断审查、排错：先让工具承担一部分劳动，再逐步修好，并不是接受报表或生产数据有三四成错误。

flowchart TD
    subgraph Ingestion["多平台数据抓取层"]
        P1["驴充充平台"] & P2["星星充电平台"] & P3["公牛充电平台"] & P4["小桔充电平台"]
        P1 & P2 & P3 & P4 --> D1["Docker 容器定时采集脚本
独立环境配置/周期性爬取各台数据"]
    end

    subgraph Aggregation["指标聚合与看板层"]
        D1 --> A1["统一经营报表看板
充电度数/订单流水/翻台率日汇总"]
        D1 --> A2["设备异常监控报警
自动输出离线与故障桩清单"]
    end

    subgraph Operations["线下运维闭环层"]
        A2 --> O1["生成现场维修派工单
明确耗材备件与施工量指标"]
        O1 --> O2["现场维修工移动端打卡
处理进度确认与对账闭环"]
    end

    Aggregation --> Operations

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

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

flowchart TD
    subgraph Env["统一工程底座与目录隔离"]
        E1["实用工程师工作台
VS Code 作为主开发底座"] --> E2["Git worktree 物理隔离
各 Agent 在独立分支工作目录读写
彻底杜绝多 Agent 共享根目录回写冲突"]
        E2 --> E3["长期全局规则文件
Obsidian 维护统一边界与规范约定"]
    end

    subgraph Gate["四级任务链与架构门禁"]
        G1["阶段一：业务与代码调研
只读分析依赖与既有逻辑"] --> G2["阶段二：技术方案与架构设计
输出结构定义与修改范围"]
        G2 --> G3["强制人工确认拦截
严禁未经审核进入自动化编码"]
        G3 --> G4["阶段三：Agent 编码实现
受限于白名单范围局部施工"]
        G4 --> G5["阶段四：代码审计与静态检查
自动化验收测试拦截低级幻觉"]
    end

    Env --> Gate

共享目录：先传清资料和规则

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

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

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

可调用接口与工作目录隔离：再编排任务链

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

他自报一次任务运行了48小时无人值守，同时承认这种方式更适合先出demo，质量不如人逐道查看。该实践表明48小时无人值守更适合快速出Demo原型，生成代码进入生产环境必须经过人工严格审查。

多模型互审也没有统一结论。有人把同一问题交给四五个工具，再互相审查汇总；另有人说近期客户项目中这样做弊大于利，更愿意按场景分工。多模型互审在不同业务场景下表现各异，关键看改动能否落盘并顺利通过测试。

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

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

另一位实践者描述了不同于“飞书拉群”的工作方式：以 VS Code 为统一工作台，把编码工具的CLI或插件放进来，接入智谱模型，再让 Obsidian 与各工具共享本地资料目录。这是其工程工作台实践：以 VS Code 为底座，CLI 接入模型插件，Obsidian 管理规则，实现高效协同。

其披露的资料组织步骤是：先分项目、参考资料、记忆和经验演进等目录；把自己的工作规则整理成Markdown；让各Agent接到需求先读对应规则，知道资料路径、执行顺序和能做/不能做什么；之后共用资料再完成分工。目录和规则能减少反复口头传递。 另一位参与者还把第一性原理、反向验证等思考方法写进规则：先拆解问题，再检查数据与结论能否相互支持。记忆优先记录会改变后续决策的新发现，而不是重复通用知识。

这里还要把三层分开记：VS Code是工作台，CLI/插件承载Agent执行，智谱等是接入的模型。讲者用海外编码Agent接国内底模，并观察到同一模型放在不同Agent中，输出风格仍会变化。

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

提问者明确提到 Chatbox AI：他把它理解为接入多家API、安排不同角色、在一个入口讨论与分工的方式。这个记录反映他的尝试与期待，这一尝试暴露出 Chatbox 等多模型聊天界面仅是信息研讨群，无法真正操作系统级命令行与跨桌面调度。

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

这条失败经验应该和项目名一起留：多API聊天、能够调用某个CLI、跨桌面软件完整编排，是三种不同能力。 想试同类方案，应先拿其中一个实际工具检查是否有可调用接口，再验收命令能否执行、是否真改了产物、结果能否返回；这些是这也是关键避坑点：多模型聊天、调用单个CLI、与跨桌面软件完整编排是三层完全不同的工程能力。

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

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

他的自用流程是：从税务系统导出一个季度的票据和已公布账目，先由人过一遍、把材料捋清，再交给AI分析、记账和生成报税报表，最后由本人到系统导入或提报。更具体的输入还包括银行流水、公户资料和扫描发票，先整理进文件夹；他让团队生成利润表、资产负债表，以及所得税、城建和附加税等申报材料，再由自己到系统导入或填报；他表示二、三季度已经这样处理。接口抓取尚未打通，材料完整性和最终申报仍由人把关。

他希望找财税专业人员合作，增加末端审核，多轮检查AI做得对不对，再考虑服务更多客户。其扩展前提正是必须找到能做末审把关的专业财税人员，确保合规安全。

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

双方较有价值的合作方向，是在已有财税顾问客户中增加具体AI服务，而不是财税人员完全转行做陌生行业。税所已有信任关系和行业理解，技术方提供材料处理与初步分析，专业人员保留判断责任。双方明确了合作方向：技术方提供数据预处理，税所会计保留最终审计责任。

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

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

做家庭防水维修的经营者，有自己的工人和工具，过去依赖百度营销，觉得付费投入重。他想让AI收集信息、生成文章，持续发到今日头条和自己的官网，让本地客户能找到自己。这一工作流正在规划上线中。

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

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

他对第三方平台的收费与人员管理很不满意，希望做出这些差异：人员由谁管理、报价如何透明、施工按什么标准、出问题谁负责。流量工具帮助找到人之后，服务质量仍由这些环节承接。

现场有人把不同内容平台的来源权重、地区分发当作解释，也有人分享优化后被学校后勤找到的个例。与其盲目猜测算法规律，不如把直属施工队的工艺标准、报价透明度与质保责任做实。

九、真实素材短视频：从镜头要求、素材库到成本核算

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

素材整理为什么比混剪更费时间

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

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

先建语义素材库，再按镜头要求组片

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

1. 素材入库时，用视频分析API或人工描述片段的内容。

2. 把描述保存为命名、备注或其他可检索信息。

3. 一段视频有多个镜头时，先切成足够细的镜头单元；整段一个笼统描述不足以支持精确选镜。

4. 混剪时根据已确定的步骤找相应镜头，再处理顺序、节奏、配音与字幕。

5. 人最终检查画面是否自然、是否与预定结构一致。

这样把素材库建设与每次成片区分开，避免每做一条都重新分析整个素材库。这套方案还要用真实素材测试成本和成片效果。

保留人工节点，并按运行需要选本地或云端

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

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

本场没有得到完整成片或可靠的自动化闭环。讨论中也发生版权分歧：一方认为混剪、删片或换号可以继续经营，其他人追问原作者投诉怎么办；这一争论并没有解决素材授权问题。建设素材库应使用自有或已获授权材料。这个案例真正留下的是任务定义与选型方法：先让工具处理你最耗时、能验收的一步，别因为软件叫“视频工厂”，就假设它符合自己的每个镜头要求。

预算、模型开销与人工时间怎样比较

同一位视频经营者说过每月两百元预算，后面又表示如果能替代自己肉眼分析，五百元也可考虑；另一处说每条30秒内容三四元以内可以接受。这一价格区间体现了实体小微团队在真实运营中能承受的单条成本底牌。

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

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

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

工具购买经历还提供了一个小教训：一位用户曾付八千八年费，后来看到九百八年费有类似功能，另有两千九百八报价。没有核对合同、版本和服务范围，这些不能推出全行业价格，更不能证明不合需求就等于诈骗。这给视频软件采购带来深刻教训：花费8,800元年费与980元/2,980元工具相比，核心差异在于是否具备分镜语义理解，盲目买批量软件极易踩坑。

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

flowchart TD
    subgraph Footage["实拍素材入库与打标"]
        F1["25-30秒高清真实实拍入库
杜绝AI生成塑料质感"] --> F2["分镜头抽帧分析与视觉理解"]
        F2 --> F3["建立多模态语义素材库
前3秒钩子/人物运镜/动作标签"]
    end

    subgraph Pipeline["分镜匹配与剪辑流水线"]
        S1["结构化分镜脚本输入"] --> S2["语义索引精准检索
按分镜意图召回高匹配切片"]
        F3 --> S2
        S2 --> S3["自动化流水线合成基础成片
大幅降低初剪时间成本"]
    end

    subgraph Review["人工质检验收卡点"]
        S3 --> R1["人工精细微调与对齐
把关气口/节奏/商品卖点"]
        R1 --> R2["成片最终审核与全网分发"]
    end

    Footage --> Pipeline --> Review

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

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

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

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

• 过去三万多元的软件，伙伴估计如今约150至200美元能做出来，是估算而非实际结算。

• 另一次约500美元的说法，后面又提到一周修改，并不等于两小时全部交付。

• 量化软件从去年研究、先由程序员写，今年二月起改用模型，讲者称当前不到1000美元；对应此前五六万元人力成本，但没有计清自己的劳动和其他费用。

量化项目还说测试了15天。这十五天属于量化项目，不能移到ERP上。 量化软件从程序员定制转向大模型辅助后，开发成本压缩至1,000美元以内，但上线前仍需经历严格的沙盒模拟测试与风控。

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

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

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

一次换模型账号的讨论暴露了两个“记忆”概念：本地项目目录和会话资料是否还在，与服务商是否命中推理前缀缓存，不是一回事。现场参与者先以为在说本地缓存，追问后才澄清是在说模型侧缓存。保留本地资料不等于换入口后首次调用必然有缓存；这也提醒开发者：本地项目目录存储与服务端前缀缓存是两层逻辑，敏感数据需做好网络隔离。

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

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

企业周报的需求很直接：工作群平时已经有对话和进展，希望从中提取日报、周报、月报。集团参与者倾向先让子公司低成本体验，再看是否采购。厂商所提内测活动通常具备时效性，接入企业工作流需以长期官方计费政策为准。

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

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

需要时间线时，应区别事情真实发生的先后与聊天提起它们的顺序；叙述里又有事实、个人感受和情绪表达。把这些分开，有助于避免把“我觉得他已经做成”当作完成证据。区分事实陈述与个人情绪表达，有助于团队在复盘时客观评估项目实际进展。

企业推广工具时，另一条推进经验是先找到真正愿意改变业务的一把手，确认对方理解的交付形态，再陪跑教育；推进企业系统必须由一把手深度认同并持续陪跑，否则极易流于形式。对话、会议与项目经验要成为组织可用知识，需要保留输入、决定、修改原因及后续动作，而不只是把聊天压成几条漂亮结论。

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

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

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

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

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

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

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

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

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

讨论中也警示了市面上假招聘真卖课等不良乱象，正规经营必须恪守交付诚信底线。课程讨论真正能留下的，是明确学员要做出的东西、减少重复教学、看清获客与交付能力是否匹配，以及把承诺范围写实。

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

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

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

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

直播还提出一个具体合作想法：讲师专注教学，由擅长获客的人带来客户；399元订单，介绍方每单拿约99或100元，其余由讲师承接交付。现场测算揭示了商业真相：若渠道分走100元，399元扣除后时薪仅约100元，必须转向更高客单交付。

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

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

这些服务层级仍缺演示带来多少咨询、咨询转付费多少、学员能否独立做出产物的实测，不能把建议者的“五单”等预测当成交记录。

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

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

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

讲者通过设备入股降低了初期资金门槛（棋牌室2万接盘30万资产、火锅店5万接盘200万设备）。可理解的模式是把投入放在设备上、让经营者负责执行，失败时尝试收回设备，而不是不断追加所有经营费用。但设备是否能取回、还能卖多少、租约与拆运怎么处理，原文没有说明，不能称零风险。他后来还提到棋牌室的其他引流目的，因此本篇也不把它写成已验证的棋牌室营业利润案例。

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

他举床的例子：收购约35至50元，找工人拉回仓库，再卖三四百元。这里是进价与售价的比较，没有扣运输、人工、仓租和滞销。床收购价35~50元、卖300~400元看似暴利，但算上搬运工费、货车运费、仓库租金与滞销折旧后，利润被死库存严重吞噬。

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

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

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

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

“五亿元”在不同发言中先被称为入股估值，后又被叫融资额；后来还出现天使轮、A轮和可能只是意向的说法。对于宣称的“五亿元估值/融资”，技术团队更应关注对方是否具备真实已交付标杆案例。能保留下来的，是反复线下校正、资源匹配和从demo继续迭代的过程。

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

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

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

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

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

资源方的身份、技术能力与最终交付责任，需要分别确认。

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

内容制作要按目标受众决定复杂度。 有团队介绍过招生剧情视频的制作链：故事、场景、白模，再用AI套模，成片一分多钟，面向老人。工具与转化数据没有进一步展开。另一人把此前AI视频做法迁移到文旅内容，试了约二十条、流量不好；现场也有人提醒画面只是多个因素之一，不能单因归咎AI。

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

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

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

工具解决不了所有外围限制。 企业外呼中的重复呼叫筛选，可以是AI任务；运营商封禁是另一个问题，现场主持人明确说AI不能自动解决封号。针对高频外呼，AI无法突破运营商的合规防线；转行者可从销售或代理切入，逐步积累行业人脉与场景认知。

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

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

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

十六、实战落地行动指南与避坑清单

基于本场研讨中沉淀的硬核经验，整理出合上文章即可动手的实操落地 Checklist：

1. 充电桩及线下多平台数据聚合实施 SOP

• [ ] 整理平台入口：盘点全部经营平台的登录凭证、短信验证接收设备，优先核查各平台网页端是否支持 CSV/Excel 定时导出；

• [ ] 搭建运行宿主：租赁一台月费数十元的低配云服务器或内网 Docker 容器，确保抓取脚本拥有 24 小时稳定不掉线的网络环境；

• [ ] 异常离线告警先行：优先编写掉线与异常跳闸告警逻辑（接入企业微信或飞书 Webhook 机器人），设为整点巡检一次，次日清晨推送综合经营报表；

• [ ] 渐进接入现场派工：待数据统计稳定后，再在表中追加线下电工指派、耗材领用与现场拍照核销字段。

2. 真实素材视频工业化与语义标签库搭建 SOP

• [ ] 严禁纯 AI 假人：实体企业客户营销坚持实拍素材打底，杜绝塑料感严重的文生视频；

• [ ] 镜头单元切碎：将实拍长视频按镜头切换切割为 3~5 秒的独立片段，建立元数据索引；

• [ ] 调用视觉 API 语义打标：对切片抽帧识别人物动作、工具类型与景别，保存为本地轻量检索字典；

• [ ] 人工终审把关：系统根据脚本模板自动检索抓取对应镜头粗剪后，由专业剪辑师对前 3 秒视觉钩子与音效做最终校准。

3. 多 Agent 研发环境隔离与门禁规范

• [ ] 禁止单目录并发写入：多个编程 Agent 协同作业必须通过 git worktree 开辟独立工作树，物理隔绝文件冲突；

• [ ] 设立架构人工签字门禁：任务拆解与架构设计阶段完成后，必须经由资深工程师审查确认后，才允许向后触发代码生成；

• [ ] 固化 agent.md 契约：在仓库根目录维护规则文件，白纸黑字写明架构边界、调用规范与不可变动核心目录。

十七、按业务查工具与实战技术台账

按本场用途检索的实战工具台账

待进一步观察的原型与探索线索

以下保留现场连麦交流中提及的实验性思路与个人探讨线索，供后续持续跟踪：