2026-10-25 · 第1场直播

本文把2026年10月25日晚至26日晨的企智AI落地派直播整理为一份可独立阅读的知识文档。按项目与问题分章，将分散在不同时间的补充、质疑和改法放在同一处；保留有用细节，删除寒暄、重复和私人内容。

案例按讲者口述呈现；尚在开发的部分会就地注明，未公开的步骤不替讲者补造。读者可以直接阅读正文中的具体做法与适用条件。

一、从接小单到进企业：一个AI服务创业者的实际路径

这位讲者原来做医药代表，开始时不懂编程，也不懂AI。他最初尝试漫剧，没有顺利做下去，随后转向AIGC定制接单。改变方向的关键是：不先花一两个月做一个自己的产品再找买家，而是让已有需求决定学什么、做什么。

1. 第一批订单怎么来

他提到淘宝、闲鱼、京东两种路径：自己开店，或者找已经经营相关业务的店铺合作。向店铺介绍自己能承接什么任务，再发送练习时做的案例，让对方判断是否能把需求交过来。这里的案例是让别人知道“你能交付什么”的样品，不是先建设完整商业平台。

收到具体需求后再完成交付。小单可能是几百元，也可能三千、五千元；需求越来越多，才接触更多类型的任务。他自述沟通过约五六百个需求，完成约一两百个成品。这些数字是讲者的经历口径，没有订单明细；值得学的是获客与学习顺序，而不是把数量当成入行门槛。

2. 案例为什么要积累，而不只是存一张成品图

他进入企业后发现，每个部门的工作流里，都能看到过去小单的影子。因此，小单阶段积累的核心是实际需求的类型，以及解决需求的路径。只练某个软件按钮，遇到不同业务仍不知道如何拆；只保留漂亮结果，也难以复用。

把这个经验整理成可执行的案例档案，可以保存客户想解决的问题、收到的输入、交付物、用到的能力、修改原因。这是对其经验的整理方式，讲者没有展示现成档案模板。

3. 从个人接单转到公司服务

他自述，合作客户邀请他在新品发布会上分享，进一步发现合作空间，随后获得投资成立公司。业务同时保留三条线：AI定制、AI培训、进入企业实施FDE；线上店铺的小单继续由工作室承接。

这个过程里的重要前提是：已经有合作关系与交付经历，才获得更大的合作机会，并非先凭一个demo拿到完整企业业务。讲者认为，案例、公司主体、合作伙伴和投资人背书都有助于企业信任，但其“五万、十万以上个人接不了”的判断只是个人体会，不是市场上限。

4. 进企业后怎么理解需求

他提出四项能力：知道AI能解决哪些类型的问题；有足够多案例可类比；能和部门人员对齐需求；具备企业认可的交付主体与支持。

沟通时先找“树干”：这个部门的工作流第一步、第二步、第三步分别做什么，输入从哪里来、结果交给谁。梳理出主干后再补“树叶”功能。直接冲着一个局部按钮开发，可能把部门的整体关系漏掉，最后功能做出来却接不进业务。

介绍项目时，另一位讲者提供了四个表达维度：属性、差异、价值、证据。以知识检索为例，不只说“做了一个知识库”，还要讲原来怎么查、现在怎么查、准确率与并发表现、成本和已完成的交付证据。这个表达方法可以直接用于向客户介绍方案。

5. 真正卡住他的不是订单，而是交付人才

他带同事进部门沟通时，发现对方听不懂业务，双方说的不是同一个问题；而既懂业务又能交付的人，又有自己创业的动机。结果是订单在手，也不敢继续承接。这说明AI服务公司扩张并不只取决于工具速度，还取决于能否培养独立承担需求与交付的人。

他当时在考虑两条扩张方向。一条是培训：集中时间教一批人，比逐个项目交付更快收款，但占用同一批核心人的时间。另一条是垂直复用：以店群上架为例，把一个客户的重复工作跑通，再尝试服务同类商家，甚至设专门电商部门。

店群项目当时还准备交付测试；跨客户60%复用尚未跑通，80%—90%仍是未来设想。 这条经历已经走到了“有订单、缺交付容量”的阶段，但尚未解决规模化复制。

二、广告视频怎么批量做：Claude、Codex、飞书与HTML的组合

这是本场最具体的一条制作流程。讲者进入一家电商企业后，处理的是参考视频复刻为自家产品广告素材的工作。

原来为什么慢

员工各用各的软件，生成复刻提示词的结果还要人工改；首尾帧往往从参考视频里手动截，效果也不稳定。问题不是完全不会生成视频，而是做法分散、每条重复操作多，结果也难统一。

先手动把一条跑通

1. 把参考视频交给Claude聊天界面，让它拆解视频。
2. 让它分别给出首帧、尾帧的图像提示词，以及视频生成提示词。
3. 把图像提示词交给生图工具，生成需要的图片。
4. 结合生成的图片、自家产品和视频提示词，产出广告素材视频。
5. 检查这一套是否能产出需要的结果，再封装重复部分。

这一步的重要之处在于：先通过直接交互理解流程，知道哪一步能得到什么，再写批处理。讲者没有公布生图和视频服务的具体型号，也没有公布完整提示词，不能把某个模型名称或参数补进这条链路。

再让Codex组织执行

讲者把跑通的流程交给Codex组织和优化，并通过其可调用的工具完成后续工作。原文把封装物说成“SQL码”“sql”，也可能混有其他术语，不能确定究竟是SQL、skill还是代码。可以确定的业务结构是：先梳理，再封装，再调用工具执行；不能写成Codex本体天然提供视频或图片生成能力。

飞书负责需求入口，HTML负责结果交付

员工把参考视频与制作需求放进飞书表格。讲者建立飞书应用，让执行端读取表格中的数据；系统根据需求拆视频、运行已封装的生成流程，再把结果组织成HTML。

HTML不是给开发者看的日志，而是给员工使用的分发页面：按员工分配当天素材，发到工作群，每个人点击自己的名字，就能取到对应内容，再复制粘贴到后续工作中。

可以把这条链路记成：

飞书表格里的参考视频与需求 → 拆解与提示词 → 图片和视频生成 → 按员工组织HTML → 工作群分发 → 员工领取使用。

他自述一天约50条、约90%成片率；这里的90%指成片率，不是销售转化率，也没有统一验收定义或统计样本。真正可复用的是输入、处理和分发方式。

为什么没有把最后的复制粘贴也做掉

有人追问：只剩复制粘贴，为何不彻底自动化？讲者表示自己的目的并不是开除员工，而是让员工做得更多。因此，人工末步是当时的组织选择，不能简单归因为技术做不到。

他还分享了两次落地受阻的经验：外部FDE会碰到权限、利益和协作阻力；此前做AI客服时，公司业务规则还没制定好，效果也不好。后来他选择进入企业内部，从岗位或部门的小范围开始。

具体做法是和员工一起了解工作，不先列一堆计划，不给一线增加额外填报负担；把岗位内容拆细，逐步实践，封装到离开实施者也能继续运行。他说约半个月能沉淀一轮，这是其经验时间，不是所有企业的工期承诺。

三、把售后、产品资料和经营数据变成可用服务

食品售后知识库：从翻文档变成在飞书里提问

数据产品经理介绍的已落地项目，和其尚在开发的漫剧工具是两回事。他在企业内做了数据中台与知识库。

食品售后会碰到变质、异物等不同情形，处理与赔偿办法不同。原先客服需要打开多个文档找规则；知识库把资料变成可检索内容，客服在飞书里发起提问，就能找到对应问题与处理方式，再回复客户或执行处理。

这条项目的价值链是：产品与售后规则资料 → 按问题检索 → 飞书入口 → 客服确认后处理。 不需要一开始就把所有售后决策交给AI。它减少的是找资料和拼接答案的工作，责任仍在业务处理环节。

数据中台最费功夫的地方

讲者负责的业务维度包括线上、线下、物流、商品、品牌、客服、私域、商务达人和财务。进入项目后需要逐项弄清：每个人持有什么数据、谁负责维护、接过来后应该展示哪些维度。

接通数据以后，还要核对原系统与展示页面的数据是否一致。前后端能跑、页面能显示，不等于数据对。讲者特别强调这种业务校验能力，而不是只会把页面部署出来。

他还做了一个部门需求与任务跟踪系统，重点字段很朴素：谁有需求、谁在做、做到哪一步、卡在哪里、需要谁配合。这里值得记住的是业务状态，不是“大中台”的名字。

库存、交期和投流联动：把信息送到做决定的人面前

另一位电商经营者原先每天要打开聚水潭ERP、销售平台、飞书等多个页面。运营投广告时，有时并不知道商品已经缺货，还在继续花钱；工厂补货周期也没有同步到投放决策里。

其改进思路是把库存与生产交期一起提供给运营：一个款没有货，工厂多久能出货，面料还需要多久，当前预售窗口能否覆盖。系统不仅提醒“没有库存”，还提供选择：不继续推就不开计划；继续推则考虑缩小预算。

例如，讲者用过“出货需20天、预售最多25天”的情境解释这种决策。这是具体业务条件的示例，不是任何商品的统一阈值。

这类项目不一定要先替换已有ERP。另一位供应者的方案，就是保留原来的SaaS，把它们作为Agent可调用的工具，连接原本分散的数据。先建立可信的数据和权限，再让AI把跨系统信息组合成业务判断。 工资、文件读写等也应按用户权限隔离，不能因为接通数据就让所有人看到所有内容。

既有ERP保留库存等数据，平台保存经营信息，飞书承担内部协作。直播没有提供聚水潭接口、授权方式或同步配置，不能据此认为已经开放了任意读写权限。

四、AI漫剧工具怎样定位、降本和拆出能卖的模块

产品最初想解决什么

一位开发者想服务刚入门的人：不必先学ComfyUI、模型部署和复杂提示词，在网页里选择人物、风格等选项，由前端拼接提示词，完成生图、剧本导入、人物关联、分镜与视频生成。

其收费想法是：不赚模型积分差价，只卖工具订阅，例如设想每月30元；用户自己租云电脑、部署模型并承担算力。这样把软件费用和生成费用分开。

当时API链路已跑通，本地模型链路还未完成，也没有完整制作过一部短剧。租用云电脑上的本地部署，是在那台远程机器里运行模型，不能理解成用户自己的电脑全程离线。

低时薪不直接等于低交付成本

讲者举过云电脑约2.8元/小时、测试中约10分钟生成15秒片段的例子，也有人反驳某些平台生成并不贵。两边真正需要比较的，是达到相同质量的一条可用视频，包含多少次失败、多少人工处理，以及整部剧能否保持一致。

讨论里更有用的降本经验是按工序选模型：剧本、场景资产、人物资产、具体镜头不必都用同一个最高档模型。特别是简单场景，不一定要使用最贵能力；把不同任务分别安排，比一键全用最高规格更可能控制成本。

专业制作还需要什么

业内讲者强调，成熟制作不止“输入剧本得到视频”：还有资产管理、剧本拆读、分镜、导演台、镜头安排和剪辑。人物、服装或标识的细节可能要求严格一致，单次生成看着漂亮不等于连续剧可用。

产品因此至少有两种路线：帮助新手完成第一条内容，或者帮助专业团队稳定制作高质量作品。客户、交付标准和愿意付费的理由不同，不能用同一套话术包揽。

为什么“有功能”仍然难卖

培训机构或传媒公司可能已经买断、开发了自己的软件，免费给学员使用，再从算力消耗中获益。另一个订阅工具进入这种渠道，会改变对方原有的商业结构。对方是否采用，不只看页面功能，还看它如何影响自己的收入。

如果改做直客，就要回答持续获客从哪里来、用户为什么留下。开发者当时计划发短视频宣传、去工作室交流，但没有给出获客和续费结果。

讨论中出现的三个窄切口

• 校园小剧场与有声书： 把拆脚本、分镜、风格和语音合成串起来，服务校园内容，而不是竞争所有商业短剧。
• 企业产品宣发： 从大画布中抽取特定工作流，围绕企业家和产品展示做工具，类似把一套工作流单独交付。
• 行业口播或账号内容： 用行业常见故事、钩子和固定风格生成脚本，可能不需要电影级导演能力。

这些是讲者分享的案例或见闻，销量没有被核验。它们提供的产品思路是：把一个明确模块做得好，可能比把所有功能缝成一个平台更容易解释和交付。

用短镜头与后期换取可交付质量

业内参与者补充了另一条制作路径：不执着于一次生成30秒、一镜到底，而是生成3秒、10秒、20秒等较短镜头，再做音画同步、剪辑和包装。这样把模型难以稳定完成的长镜头，拆成可以分别挑选和修整的单元。它用更多人工调度换取生成可控性，是否更便宜仍须连同剪辑时间计算。

同一人举过能源类项目偏好皮克斯风格的例子，说明客户指定的表现形式，可能比追逐最新型号更影响交付。另有政企项目连徽章的杠数都要核对；“画面好看”和“业务细节正确”是两个检查项。涉及影视工业要求时，他提到 Blender白模、ACE Studio等音乐/声音工具，但没有披露参数、工程文件或接口连接，不能把它们写成一键制作链。

画布选型还给出一项具体测试任务：讲者在自己的特定开源架构中遇到约300节点后卡顿，因此建议把真实项目扩到约300个以上节点，观察拖拽和操作是否仍流畅；他以60帧作为自己的检查目标。这个数字属于其特定环境经验，不是统一行业标准。值得照搬的是用大项目测交互性能，而不是根据空画布演示决定二开框架。

内容也可能是广告入口，经营收入不只来自卖成片

另一位经营者把短剧、漫剧或小程序看作内容入口，口述的收入路径是：制作或购入内容→吸引观看→承接广告展示→按平台安排分润。他说过向创作者收购跑量剧、给保底的设想，但没有展示授权合同、平台资格、结算单或实际利润。

这提供了与“向客户卖一条成片”不同的业务结构：内容生产者、分发经营者、平台与广告商是不同角色，前者的制作成本、后者的分发成本和广告结算收入要分别看。不能把低价购入内容直接算成利润，也不能从口述推导任何人上传就有分成。

若进一步研究这条线索，先确认素材权利、平台开放项目、准入及结算条件；本场没有提供这些信息，故这里只保留商业模式，不给未授权搬运、诱导点击或规避平台规则的操作。

五、人物回忆录视频：卖的不是生成次数，而是人生故事的交付

回忆录不是把老人照片统一套模板。讨论给出的购买动机，是把年轻时的经历、人生高光和来时路变成可以给家人或朋友观看的视频。

客户与获客

主持人建议从本地有一定支付能力、愿意讲人生故事的人开始，例如企业经营者和养老机构中的老人。获客依赖采访、社交和商务能力；有人通过本地团队接触养老机构，不是只靠线上生成页面自动成交。

需求怎么确认

先问客户想重现哪段经历、哪种年代场景，以及更喜欢真人感还是卡通表现。比如一位60岁的客户想看到10岁时的农村生活，需要的不仅是年轻面孔，还包括当时的生活环境。客户想留下的故事不同，交付也不能统一套一种风格。

讨论建议将片长控制在5—10分钟，以免长片变成重交付。可确认的交付方向包括旧照片修复、AIGC场景重现与人生故事视频；完整采访提纲、模型参数与逐镜头制作步骤尚未披露。

报价与经营逻辑

主持人提过5—10分钟收费5—10万元、个别项目最高约30万元，也说县城可以降低价格。这些是报价与成交的口述，不能当作通行价或收入保证。

其商业逻辑仍值得理解：用户购买的是故事被理解、素材被整理、人物与时代感被呈现，以及可分享的成片，不是AI调用次数。社交与采访能力、审美、交付质量都属于产品的一部分。讲者也提醒，不能拿粗糙结果糊弄高预期客户。

一项真实踩坑：做完不代表能公开样片

有人做过客户回忆录，后来客户不再允许展示，团队只能另做公共样片。制作授权与宣传授权要分别谈；原本“客户满意”的项目，也未必能继续充当公开销售材料。

讨论还延伸到婚礼中的恋爱经历视频。可以借鉴的是根据特定人生场景定制故事，而不是复制直播中涉及第三方肖像或影视片段的做法。

六、花卉二维码、数字工牌与工地眼镜：怎样从一个动作找到项目

花卉吊牌：把一次销售连到后续养护

花店的具体麻烦是买家不会养花，后续不断来问怎么施肥、怎么照料。方案是在花卉吊牌上放二维码，扫码进入统一花卉数据库，用户搜索自己购买的植物，查看对应养护信息；入口还能显示商家信息。

原讨论特意澄清：不是每个二维码直接跳到一条专属植物视频，也不是每盆花配一个独立模型。统一知识库＋商品上的入口＋商家信息，就组成了售后解释和再次触达的服务。

定价引发过争论，未证明高客单价能成交。把同样入口迁移到展馆或景区，是讨论里的新场景设想，不是已经落地的第二个案例。

售后入口还可以承接新品，但内容要有人维护

花卉吊牌讨论里还有一个容易丢掉的小设计：知识库入口不只放养护回答，也可以显示商家信息、商品价格和新品，甚至接一个小商城。别人看到这盆花后扫码，也能找到原商家。养护服务与后续商品触达因此共用一个入口。

讲者同时说，商家可以继续添加新的养护知识。这里应保留“谁更新内容”这一责任：最初建库不是永久交付结束。现场也有人提NFC作为展馆等场景的入口替代，但没有演示设备兼容或成本。小商城、新品更新与NFC都是讨论方案，尚无成交、复购率或节省人工的验证。

同一花卉方案还澄清过客户更偏集中绿植/花卉批发经营者，而非所有街面小花店；高价是否能卖仍有异议，选客群时不能抹掉这一差别。

数字工牌：从销售录音里提取可改进的话术

讨论中的数字工牌构想，是记录员工与客户的交流，分析哪些表达可以优化，再把有效经验沉淀下来。它和单纯“有录音”不同，价值在后面的复盘和带教。

此处主要是转述及方案讨论，没有公开验收效果、硬件规格或销售提升数据。录音采集与员工经验使用需要有明确授权，不能把设备佩戴等同允许无限收集和公开。

工地眼镜：让镜头对准人正在干什么

工地项目想采集实际作业，结合规范与老工人的经验，判断是否按工艺施工、是否存在偏差，然后发出纠正提示。

讲者为什么考虑眼镜？人在狭小空间工作时，胸前的广角记录仪可能看不到手部作业面；眼镜较接近视线方向。他人提出安全帽前方是否也能做到，说明视角与安装位置尚在讨论。

另一个知识层是非标准情况怎么处理：把做过相似工程的人处理问题的经验提取出来，形成可查询指导，不只放规范文件。

这条项目仍在进行、没有正式落地。摄像头视角、采样回传、功耗、漏检与误报并未验收，不能据此宣称已经替代监理。它留下的是一套需求发现办法：先找到现场最难看见、最难传递的动作，再考虑采集与知识如何帮助人纠偏。

现场采集的三个取舍：回传、耗电与漏检

眼镜/安全帽方案里，需求方并不要求一直联网实时纠偏：野外信号可能断续，计划当天回到固定地点再上传，后台分析后反馈。采集也不一定全天连续录像，现场讨论过间隔约十分钟录一次、每次几分钟，以控制电量和存储；一天上传后清空，或者保留几天循环，也是不同提议，尚未定成规格。

这些细节值得留，因为它们把“要一个摄像头”拆成了作业视角、照明、抗磨损、连续录制功耗、存储和上传时机。720P/1080P只是他人问到的备选，不是已经验证的最低清晰度；间歇采样可能漏掉关键工序，需要用真实任务再验。它当时是回看纠偏构想，不能同时宣称实时发现所有安全问题。

智慧工地安全教育则出现另一种交付：人员到专门培训房间，戴VR眼镜体验对应工种危险。它与施工中的眼镜采集是两种用途；没有给出培训效果或准入规范，不把展示项目写成已经满足监管要求。

七、本地客服与智慧水务：把“AI不好用”拆成可以处理的问题

客服真正问的是高峰期能不能及时回复

一位商家询问本地知识库、模型调优和多并发。其原因是活动时会同时出现大量咨询，回复晚了，卖标品的客户可能转向其他店。

讨论里有人建议五万元工作站，有人认为不需要这么高预算，也有人提GPU服务器。缺少同时请求数、上下文长度、回复时限和问题质量要求，不能直接确定某个价位或32B模型一定够。

可吸收的经验是把“并发服务器多少钱”改问成一组业务问题：活动高峰有多少咨询、每人问几轮、哪些问题必须立即答、哪些可以排队或转人工、本地数据限制是什么。先测获准使用的样例和峰值，再选硬件，是编辑把讨论整理出的实施顺序。

同场还有外置摄像头＋本地模型＋USB键鼠模拟的电脑控制原型：让模型看屏幕，再模拟人操作。讲者没有展示可靠性测试；它是设备交互思路，不是可以买来保证完成客服的成熟方案。

智慧水务为什么一面有用，一面增加工作量

水务使用者最初抱怨投入很大，却增加了工作。继续解释后，可以分出三种情况：

1. 已有数据能自动取得，系统可以做预警与台账导出。
2. 缺少采集条件的数据，仍要现场人员手工填写，系统反而新增录入负担。
3. 老厂管网若要增加传感设备，可能涉及昂贵改造；新建时同步布置，条件不同。

其认可的具体用途包括提前提示水质指标异常，让人调整工艺，以及把已采集数据导出台账。厂内提前预警阈值与排放标准不是一回事；本场标准名称转写不可靠，不保留为环保数值指导。

分阶段付款与真实问题反馈

使用者还提到，项目并未一次付清，运行人员会逐条反映问题，供应者修正，验收不满足要求就不签字。这是具体项目的付款与验收安排，不代表行业统一比例。

这段经历说明，评估项目可以逐项问：哪些价值来自采集、哪些来自普通软件规则、哪些确实需要模型？缺什么硬件？多了谁的工作？不要只围绕“它算不算AI”争论。

八、AI产品怎么卖：授权选品、区域回访、演示与试用

一位销售出身的讲者不负责底层研发，他做的是已有AI产品的渠道销售。其起点是原有企业客户关系，而不是从零有一套技术就自然能成交。

他实际采取的流程

1. 寻找有成品的公司合作，取得授权，理解产品可以用于哪些业务。
2. 按区域划分地推工作，让人员熟悉当地企业情况。
3. 回访原来的企业客户，介绍新增服务，了解他们现在想解决什么。
4. 手机配好可演示的产品，面对面直接展示。
5. 给合适客户试用一周、十天或半个月，根据实际使用反馈继续谈需求和付费。

他当时并没有搭建线上AI商城，只是有这种想法。不要把其业务写成已经运营成熟的平台。现场演示和试用是他的销售方式，没有披露试用转化率。

“不懂技术”到底指什么

后续争论澄清了一个区别：销售不一定要自己实现所有模型和代码，但仍要知道东西能不能用于客户场景。讲者自己的标准是先用，自己用得上、觉得合适才推广；用不上就放弃。

另一方强调应尊重技术，业务、销售与技术需要配合。把这段经验简化成“不需要懂任何产品，只要会讲就能赚钱”，会漏掉可交付能力和团队分工。

有渠道以后，是代理还是自建

餐饮资源拥有者想从语音记账扩到财税、会员、收银和获客的一整套系统，也想过开发或贴牌。但他自己担心投入、推广和试运营后没有效果。

讨论中有人提供现成产品试用。值得保留的决策是：已有客户关系不等于已经验证客户会为新产品付费；先试用和确认需求，可能比先做全套系统更省成本。 原文没有给出最终采购或成交结果。

驾校题库也是类似提醒：一个人可以借AI写出软件，但数据整理、题库使用权和后续推广仍是工作。他当时还没有推广，自评效果并不理想，不能当作成功变现案例。

招聘信息聚合：卖检索便利，不能暗示保证就业

另一位教育从业者经历过“做出小程序却没有用户、难变现”，随后转向大学生选岗。他披露的产品结构是：收集招聘官网链接和岗位信息，按学生专业筛选，并设计了分销功能；系统已做出，计划月底推广，当时还没有推广后的付费与就业结果。

这个小产品对应的痛点很明确：用户原来要逐个官网找入口，聚合后减少寻找与筛选。它没有披露如何验证岗位有效期、去重和更新频率，也没有证明能覆盖全部招聘。

现场另一人用自己所在企业的内部调配经历反驳“普遍对外招聘”，随后又区分校招与社招。可留下的知识是：公开招聘信息、某家企业内部用工观察、最终录用资格，应分开处理。卖的是信息整理与筛选便利，不能把它表述成有内部名额或保证入职的服务。

把获客方法变成一次可检验的小实验

这套“老客户回访—现场演示—短期试用”也在减少先研发、后找需求的风险。其前提是已有企业客户关系和获授权的产品，不能照搬成“零资源也能同样获客”。

从这个做法可整理出一张下一次回访能用的记录单：客户原有任务是什么、当前花多少人工；演示哪一个具体动作；试用由谁实际使用；试用后哪一步有帮助、哪一步仍要人工；是否愿意继续付费，以及卡在功能、交付还是价格。记录单是整理者对本例的归纳，讲者没有展示这些字段或相应转化数据。

它对应一种轻资产创业路径：先用现成产品验证需求，再判断是否值得自建；渠道方负责客户发现与反馈，技术与交付方承担产品和服务。授权范围、持续维护、分账和客户责任仍须分别谈清。试用账号数量、客户资源和热情反馈都不是利润，真正的继续条件应回到客户是否使用、是否愿意付费及履约成本。

九、阶梯薪酬与留人

一位淘宝电商经营者把公司用AI分成两个层次：第一层是员工和AI对话解决问题，第二层是员工借AI创造工具，持续解决本岗位的问题。他认为自己的团队正在第二层。

从“软件做完了吗”改成“业务有没有改善”

他的变化是要求技术人员也对业务指标负责，不只交一个软件。比如小程序希望达到日活五千UV，就让人员围绕这个目标设计产品、活动和工具。五千是他举的目标例子，不是公布的实测结果。

薪酬怎么和结果连起来

他描述了一万、两万、三万元的阶梯薪资；达到更高利润贡献后，再增加提成。例如月度创造二十五万元利润，加10%提成。这样希望把技术思路转向业务思路，也借此筛选能承担结果的人。

讲者自述团队从35人缩到7人，当前GMV约1200万元，部分人员月收入约七万元。但GMV不等于利润，也没有时间口径和因果对照，不能推导“换这套薪酬就能复制相同成绩”。

为什么高能力人员愿意留下

经营者的回答不只是股份，而是自己提供业务项目和资源调配，配合较高报酬与较舒适的工作条件。他说当前工作时间约五到六小时，未来考虑上四休三。前者是其现状自述，后者是计划，不能写成都已实行。

其他人提出的实际问题

业务贡献能否清楚量化？岗位原来的工作边界是否被抹掉？收入差距扩大后，员工是否认同？老板觉得舒适的环境，是否真是员工要的？这些质疑说明，结果导向需要可理解的归因与明确责任，不能直接要求所有岗位都变成销售。

这段经营经验可记成：经营者提供资源和目标，员工用AI建工具，薪酬与可衡量贡献相连，同时考虑留人条件。 它是一种组织试验，有明确的适用前提与争议，不是通用绩效模板。

十、软件采购、内部负责人和结果托管，分别怎么经营

业务方为什么说“我想找个人”，而不是“买个软件”

劳务业务的经营者希望有人长期负责、带领原有团队、提高产出。软件曾经出现升级或bug后不好用的情况，买到功能并不等于一直有人管。他可以谈工资，也愿意谈股份，核心是持续负责与团队带教。

技术方担心时间投入、维护成本和合作后的退出风险。对方说不需要技术方出钱，并不代表零投入：时间和技术工作本身就是成本。这段分歧不能简单归为技术人员不想奋斗，或经营者一定在画饼。

一种模式：客户继续用原有系统，服务商做接入与优化

保留ERP、SaaS与员工的主要流程，把数据和工具接到Agent上。适合不想大改组织的客户。它需要双方指定负责人，明确业务不配合、数据不到位或技术没完成分别由谁处理。

长期维护会遇到模型升级、下线和提示词变化。一方提出自动路由，另一方追问两个模型的输出是否一致。这里的经营成本不只在首次开发，还在持续保障。

另一种模式：不卖工具，外包持续结果

供应者描述的“3＋X”，是让客户保留少数审核人员，外部团队用人和Agent承担执行。Agent在服务商自己的环境运行，由程序员与运维维护，客户购买持续产物，不必自己培养同等工具使用能力。

这种模式的交付可以是图片、文案等工作成果；客户仍有人提出指标、安排任务并审核，不是所有人退出。

这项业务怎样收钱

讲者先后描述过：第一笔按被优化岗位年工资的一定比例收实施费；后面收账号、机房和人员运维等持续费用；次年再收服务费。

具体口述出现过首年工资40%或50%、每月六万元或六到十万元、次年按节省工资25%等不同说法，后段又用“两百万先付一半、搭好再付一半”举例。这些不能拼成统一收费表，却能看清前期实施收入＋持续运维收入＋后续服务收入的结构。

客户提出的好问题是：只需要五个账号，服务商为什么可能按二十个账号收费？成本如何透明？这直接影响长期信任。

长期粘性与退出风险是一件事的两面

供应者把“执行人员和系统在我这里，客户不容易换”视为优势；另一位经营者担心被绑定。双方都提出了真实问题。经营这类业务时，服务可持续与客户可迁移需要一起设计，不能只靠“你走不了”当护城河。

另外有人采取不同切口：不替代现有部门，而是新增一个增长、渠道或商业策划模块，绕开原有流程改造。两种业务的需求、阻力和结果口径不同。原文没有证明哪一种普遍更赚钱。

到手价计算：先确认真正需要操作哪个入口

电商经营者还提出一个尚未解决的小任务：平台活动很多，叠加优惠后才得到实际到手价；按其经验需要操作App，自己一直没有找到替代现有十五人团队的方案。供应者提出可交PDF结果，并连同得出结果的链路一起交付，让客户审核，但明确还要回去调研，没有承诺已经能做。

这个例子补上了结果服务的一个具体输入输出：输入是指定商品和实际活动条件，输出不只是一个价格，还要能说明计算与操作链路。只抓页面标价可能不回答到手价问题；先确定入口和验收样例，再报价，和单凭团队工资推算节省金额是两件事。

十一、潜在客户激活Agent：一个开发中项目怎样收缩范围与改架构

这个项目原先想做全流程AI销售：销售、售后、方案和订单打通。开发者后来缩到一个环节——对聊过一次但没后续的潜在客户进行激活。

给定一批潜在客户，系统规划何时联系、说什么，并根据一轮轮对话改变策略。达到合适的产品匹配阶段后，交给人工销售，不把成交后所有事务也包含进来。

架构是怎样变的

最初是十多个节点的图式多Agent流程。开发者发现销售场景复杂，后来换成一个负责实际交流、记忆和技能积累的Agent，再单独设一个意图分析与规划Agent。

每轮问答结束，规划端做总结、调整策略；执行端按总目标行动。其特别提到记忆选取问题：已有十份记忆，下次主动联系时应该用哪一份？有记忆库和在合适时机取对记忆，是两件事。

框架名称在转写里不够可靠，本章保留架构与问题，不凭相似发音补链接。情感识别模块也没有足够信息可独立复现。

项目当时进展到哪里

核心功能已做出来，仍在测试、修改提示词和记忆优先顺序，开发者明确说还有很多问题。“转化率10%到12%”只是目标例子，没有实际对照结果。

主持人建议先给潜在客户或熟人试用一个月，收集好坏反馈，随时改不适用功能；觉得有用再付费。这是一种试点与商业验证安排，不等于已经通过性能压力测试。

这个项目值得吸收的是：大范围设想遇到复杂性后，缩到一个可交付环节；把交流执行与策略调整分开；用真实使用反馈改系统。 原文追求“似真人”的表述不应变成冒充真人的实施建议。

十二、无人办公怎么推进：任务、知识、反馈和多Agent交接

一位讲者在做多电脑、多手机的AI办公实验，场景包括自有品牌内容、带货和电商操作。他给AI配工具、账号、设备和预算，追求更少人工参与。虽然自述部分链路已实现，但同时明确持续投入、没有盈利，不能把愿景写成自动赚钱教程。

第一层：稳定工作流先复刻

后来的技术讨论把任务分为两类。第一类状态稳定、可重复，适合把已知流程写成代码和工具调用。第二类必须根据外部反馈改变策略，不只是多执行几次。

因此先问“这个岗位到底是什么任务”，比先问“买哪个Agent软件”更有效。人工做成过，不代表AI已在变化条件下稳定做成；执行快，也不代表更快找到正确决策。

第二层：长期目标与短期任务分开

实验者提出：上层协调者持有长期项目目标、目录、推进状态；底层角色完成短期任务，再汇报结果。这个结构类似项目管理，而不是让每个Agent都无限延长对话。

它解决的是目标与分工安排，不能自动保证信息不丢。任务下发时只给输入输出、没有说明目的和约束，下面可能只满足一部分；下层做完只报结论，上层也不知道实际改了什么。来回两次信息压缩，最终就可能错位。

把讨论整理成一个实用交接单，可以列出目标、输入、约束、允许操作、产物、检查方式，以及完成后的变更和未解决问题。这是编辑提炼的使用方法；不要求模型披露隐藏思维链，保存可公开的决策理由与操作证据即可。

任务交接则有一个更具体的改法：除说明目标，还写能实际检查的完成条件，例如运行指定代码或验证产物满足要求。SOP里的“务必做好”是软要求，实际检查能发现“口头报完成但产物没完成”。现场没有交付验收程序，因此应按自己的任务另写检查，不宣称增加这句话就能保证Agent可靠。

第三层：知识别都塞进同一个记忆文件

讲者区分三类：个人喜好、个人处理工作的办法、公司级规则。喜欢怎样表达，与公司要求怎样处理业务，不能无差别混用。

同样，记录“上次点了这个按钮”只保存了动作。为什么点？当时看到了什么异常？什么条件下不该点？如果这些没有留下，换个情况仍可能照抄。稳定SOP可以直接存成流程；需要判断的经验，则要保存触发条件、依据与后果。

文档、向量检索与更结构化的关系表示都是候选方式。本场对skills追加过多的批评，指向知识没有重新组织的问题，不等于所有skills都有害，也不证明一种知识系统适合所有任务。

本场实际提到了 embedding检索、LLM Wiki（原文也写WikiLLM）、ontology/本体 三种组织线索。讲者的比较是：固定客服话术或SOP，可以先存文本，再通过检索取出；Wiki式互联文档用链接组织关联；涉及概念与关系的知识，可以考虑更结构化的表达。它们是不同方向，不是现场已经做过效果对照的三款软件，也没有给出某个LLM Wiki仓库。

这些分类来自讨论；不能把“某个产品记忆都混在Markdown里”的口述当作对产品内部实现的审计。

最后看经营闭环

还要有人处理设备故障、异常和验证。多模型通信、重复失败、账号与算力都消耗成本。“未来一定能覆盖token费用”不是当前利润表。先把一个明确业务回路的成功、失败、人工介入与收入成本测清，再扩张，比无限增加设备更容易知道进展在哪里。

自有品牌、带货佣金与持续服务要分开算

实验者明确不想只替别人带货拿佣金，而想慢慢经营自己的品牌；另一方认为先用短链路取得正反馈更实际。两种路线的目标不同：自有品牌要承担持续内容、产品和经营投入，较短的带货链路也不代表已跑通或没有成本。本场没有证明品牌无人经营已经盈利。

另有渠道经营者提出：工具更新很快，给客户的东西需要一次又一次升级，是否每次都收费？这是持续服务的真实经营问题，现场没有给出统一答案。可以留下的成本项包括维护时间、模型与账号、异常处理和履约责任，不能把代理或介绍资源视为完全不投入。

与长线实验相对，企业内部推广还有一个小步做法：先自己用，再让所在小组试用，拿到具体改善后扩大。它降低的是一次全员切换的组织负担，不等于可以跳过授权、数据和验收。

十三、AI编程和工具经验：具体用在哪里，怎样少走弯路

一个真实困境：让AI反复检查，bug还是修不完

不会编程的使用者做了网站和小程序，每次要求“一次性修完”，AI都说没问题，再检查却又找到问题；换对话前读维护手册，也没消除反复返工。

回答者没有承诺换模型就能治好，而是建议把开发拆成设计、拆分、实现和审查：先多轮审查架构，再拆成小模块，让执行角色完成具体部分，最后做最终review。用另一段独立上下文或角色检查，减少同一段对话沿用自己前提的问题，但仍需具体复现条件与验证。

测试与原型各解决什么

讨论把“先写测试”和“先做mockup”放在一起，也混用了英文名。可取的两层工作要分别保留：先用原型确认页面和流程，再用可执行测试确认行为。原型看起来对，不代表程序行为正确；AI口头说修好了，也不是验收。

一个可执行的工作顺序是：描述问题和预期结果 → 确认结构与任务边界 → 小块实现 → 用实际操作或测试检查 → 记录还存在的问题。这是对本场方法的整理，不是声称讲者公布了完整工程仓库。

按任务查工具：制作、交付与编码

关于订阅，较可复用的经验是先从基础额度开始，熟悉功能，再根据实际用量升级。口述价格和免费额度容易变化，本篇不把直播报价当当前购买指南；付费也不能代替任务定义与验收。

技术学习最后积累的是什么

有位讲者回顾微调、RAG、知识图谱等尝试，认为经历不同路径的价值，是知道它们能做什么、代价是什么、边界在哪里。遇到业务问题时能比较路线，而不是每次只套自己最熟悉的一种技术。

这种学习方式重在积累路线的适用条件，下一次遇到业务问题时能选得更准。

把AI建议带回现实试作，再把失败描述反馈进去

馒头经营者的转述案例保留了一个很朴素的反馈回路：先提出巧克力馒头需求，取得配方建议，实际蒸一批，再把“口感不好、太苦”等观察反馈给工具，调整后继续试作。讲者称迭代两三个版本后口感改善；这只是转述，未有配方和感官评测数据。

值得学的是 建议→真实试作→具体失败描述→修订→再试，而不是把AI的一轮回答当最终研发成果。同段关于特定疾病人群能否食用的说法没有医学证据，不随案例保留为饮食结论。

AI提效的方法卡：把“请再检查”改成具体工作约定

本场的返工案例可以提炼成一组可直接使用的约定。它适合AI写网站、小程序或处理分步骤工作，不是某款模型的专属提示词技巧。

• 开始前给出任务边界和验收现象。 写明要解决什么、允许改哪些部分、预期看到什么结果；不要只说“所有bug一次修完”。原文中的使用者已经反复要求检查、换会话读维护手册，仍在返工，所以保存文档本身不是验收。
• 交接保存工作方法，别只存个人偏好。 将公司规则、自己处理工作的办法和表达偏好分开，接新任务读取相应规则。是否有效要看下一次任务是否遵守约束、交出可检查产物，而不是记忆文件越来越大。

以上为依据本场讨论整理的操作建议；没有现场对照实验或统一提效比例。能复用的是拆分、独立审查和验证产物的方式，不能据此承诺换一个Agent就不再出错。

制作与知识组织工具的源码入口

下表补充源码或官网入口，以及开发、经营和知识组织中的用途。链接供查找；使用体验不等于效果对照，源码、商业平台与概念方法也不是同一种授权。

待确认的工具与项目线索

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