2026-10-25 · 第1场直播

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

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

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

flowchart LR
    A["阶段一：线上轻量小单
(淘宝/闲鱼/京东店铺合作
几百至三五千元/单)"] --> B["阶段二：案例库沉淀
(收录需求痛点/输入物/
交付成片/修改原因)"]
    B --> C["阶段三：线下发布会曝光
(长沙案例分享获 100 万投资
成立公司设立 FDE 专线)"]
    C --> D["阶段四：企业级 FDE 交付
(入企梳理部门工作流主干
40+ FDE 订单落地)"]

1. 第一批订单怎么来

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

收到具体需求后再完成交付。小单可能是几百元，也可能三千、五千元；需求越来越多，才接触更多类型的任务。他自述沟通过约五六百个需求，完成约一两百个成品。积累这些小单，让他能把后来企业里的工作流与已经做过的需求对应起来。

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

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

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

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

合作客户邀请他到长沙的新品发布会分享，发现进一步合作空间后投资成立公司，业务同时保留AI定制、AI培训和入企FDE三条线，线上小单继续由工作室承接。他回顾四月至八月接触AI后的收入约三十多万元；老板投入一百万元后，公司开始接触电商、地产商业管理、物业和财务等部门，FDE订单四十多，线上小单每月三四万元。这几项分别是其个人阶段收入、投资、订单数量和工作室月收入，不能相加当作公司利润。

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

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

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

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

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

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

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

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

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

讨论里另有一位朋友的湖北女装店群案例：讲者提到上线一个多月，上链接、运营已跑通，售前约80%由AI处理，但售后仍全部需要人工解决，原公司六百多人减少到两百多人。这是另一位参与者的转述案例，与前述创业者当时尚待交付测试的店群项目并非同一阶段，不能合并为同一个人或团队的成效。

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

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

原来为什么慢

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

先手动把一条跑通

1. 把参考视频交给Claude聊天界面，让它拆解视频。

2. 让它分别给出首帧、尾帧的图像提示词，以及视频生成提示词。

3. 把图像提示词交给生图工具，生成需要的图片。

4. 结合生成的图片、自家产品和视频提示词，产出广告素材视频。

5. 检查这一套是否能产出需要的结果，再封装重复部分。

先通过直接交互理解流程，知道每一步能得到什么，再写批处理。具体生图、视频型号与完整提示词在讨论中没有展开。

再让Codex组织执行

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

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

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

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

可以把这条链路记成：

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

flowchart LR
    A["飞书多维表格
(业务员录入参考视频URL与需求)"] --> B["Claude Vision 拆解
(反推分镜、首尾帧提示词与视频Prompt)"]
    B --> C["Codex 调度执行
(批量调用生图与视频模型 API)"]
    C --> D["参数化 HTML 聚合看板
(按员工席位自动分组归档产物)"]
    D --> E["企业工作群分发
(员工一键点击认领/复制素材)"]

他报告一天约50条、约90%成片率。这里说的是素材成片，不是销售转化；具体验收口径没有展开。

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

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

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

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

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

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

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

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

这条项目的价值链是：产品与售后规则资料 → 按问题检索 → 飞书入口 → 客服确认后处理。 运营找产品基础信息、图片，也可以在飞书群里艾特机器人取回，不再为每次查资料都找技术部。他在这家公司已工作约两年半。中台最初并非用AI搭建，后来才接AI和知识库，把既有数据通过聊天入口交给各部门使用。

数据中台最费功夫的地方

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

接通数据以后，他用SQL查询和脚本核对前端页面与测试数据是否一致。前后端能跑、页面能显示，不等于数据对。讲者特别强调这种业务校验能力，而不是只会把页面部署出来。

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

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

另一位电商经营者原先每天要打开聚水潭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都是讨论方案，尚无成交、复购率或节省人工的验证。

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

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

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

现场举了面向4S店、美业店的数字工牌案例：用已有录音卡收集交流，把销冠话术蒸馏成知识库，供新人跟学、员工每日复盘，再针对个人表达提出优化改法。讲者提到一万元的售价；它的定价切口是复用原有的录音卡硬件，不要求老板另购一套新设备。

另一位业务经理也想用低成本工牌让同事先体验语音AI，再引导他们改变工作流。他调研的Muse随身方案被讨论到局限：需要全程联网、必须挂外接主机且一台主机通常只能连两到三台设备，还需额外部署语音转换模型及面对续航限制；主持人建议先找已有低成本数字工牌产品。Muse名称和设备配置仍需确认。

这仍是方案讨论。实际使用要处理录音授权、经验复盘与带教三个环节。

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

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

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

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

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

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

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

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

另一位参与者曾调研定位工牌，提到简化定位方案一百多元，带摄像头安全帽约五百元到两三千元，区别不只在摄像头，还在续航、抗磨损和采集质量。他又回顾亲属买过的智慧工地系统：第一个工地纯软件一百五十万元，类似的第二个八十万元，共二百三十万元，不含硬件。系统接人员考勤、劳务、机械车辆、物资、视频等模块并要求私有化部署，不能与东哥尚未落地的眼镜纠偏构想当作同一份报价。

智慧工地安全教育则出现另一种交付：人员到专门培训房间，戴VR眼镜体验对应工种危险。它与施工中的眼镜采集是两种用途；具体培训效果与准入要求没有展开。

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

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

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

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

可吸收的经验是把“并发服务器多少钱”改问成一组业务问题：活动高峰有多少咨询、每人问几轮、哪些问题必须立即答、哪些可以排队或转人工、本地数据限制是什么。用样例和峰值负载测试，才能把硬件选型落到具体任务上。

同场还有一个外置摄像头＋本地模型＋USB键鼠模拟的电脑控制原型。设计者称模型放在定制摄像头内，以视频流看屏幕，语音接受任务，再模拟键鼠操作；他已经做出原型并自用测试，目标是通用电脑操作，而非只抄代码。设备装在屏幕上方，支杆需伸出一定距离才能覆盖全屏，外观和屏幕定位因此也是硬件设计问题。

他设想一次买断、离线使用。其他人则追问摄像头内的模型容量、视频处理算力，以及本地模型和云端模型能力差异；他没有公开基座和测试数据。有人愿意转介特殊单位的代码搬运需求，但也有人指出设备准入和摄像头使用仍需审核，本地运行不能直接推出获准使用。普通用户的语音操作也未必需要新硬件，现场有人提出二十元左右麦克风即可解决输入问题。

电商商家还指出，活动时可能同时有三十至五十人咨询，关键是并发读取商品资料并及时回复；逐个语音指挥电脑不能直接替代这类客服系统。硬件控制、语音输入和多用户客服是三种不同任务，应分别拿真实任务测试。

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

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

1. 已有数据能自动取得，系统可以做预警与台账导出。

2. 缺少采集条件的数据，仍要现场人员手工填写，系统反而新增录入负担。

3. 老厂管网若要增加传感设备，可能涉及昂贵改造；新建时同步布置，条件不同。

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

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

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

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

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

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

他实际采取的流程

1. 寻找有成品的公司合作，取得授权，理解产品可以用于哪些业务。

2. 按区域划分地推工作，让人员熟悉当地企业情况。

3. 回访原来的企业客户，介绍新增服务，了解他们现在想解决什么。

4. 手机配好可演示的产品，面对面直接展示。

5. 给合适客户试用一周、十天或半个月，根据实际使用反馈继续谈需求和付费。

他在浙江安排四五个人分区跑客户，手里有六十多个试用账号，多数是销售类产品。业务员手机上直接带着软件演示，试用一周到半个月后再问实际需求。他当时没有线上选品商城，运营的是授权销售与线下服务。

他举了一种销售跟进产品：用AI生成素材，分享后在后台查看客户浏览时长、次数和转发，再有针对性地联系感兴趣的人。他用这种方式介绍产品价值，具体平台与采集方式仍需向产品方了解。

人员激励也调整过。他说原先近十人的民资服务团队领底薪、在外跑业务却缺少有效回报，后来改成高提成，按回款调整；例如一万元业务赚两千元，可以给执行者一千至一千三百元。这是这位渠道商的分账例子；后文另一家电商公司的阶梯薪酬是另一套经营实践。

他也在尝试内容获客：先写企业经营、运营思路和方法，再自然衔接AI用途，而非篇篇直接推销AI产品。这一方向仍在写文案和学习阶段。

商协会沙龙与内容备货：同一渠道商的后续尝试

这位渠道商后来补充，自己与协会、商会合作，请对方找二十至三十名企业经营者，自己邀请老师开小沙龙，再谈分润。他说已办两场，但现场给出的财务口径跳动很大：先说一个月赚十几二十万元，后又说两场成交两百多至三百万元、可分近半，还混用了利润和再分账的说法。这些收入、成交额、利润和再分账口径在对话中没有被对齐。沙龙由商协会邀约、老师授课，再由合作方选品、交付与分账。

他想做个人IP，却还兼顾原来两项业务，于是计划先写二十至三十篇文案、集中拍成视频，再让剪辑按日发布，给忙碌时留内容库存。当时尚未正式开始发布。他也承认老客户资源有限，估计自己能有效推广一段时间，后面会遇到资源用尽或别人超过自己的问题。

另一位参与者做个人IP时采取了并行测试法：同时找三四位剪辑与账号运营，自己配合不同人的打法，只给正常底薪（例如每天两百元）；先看谁真正把后台播放与互动数据跑起来，再决定重点投入谁。向客户展示时，他也主张直接拿后台成交数据、每天投入时间与变现金额说话，而不是空泛讲概念。

另一位做流量的经营者则想转向更大的撮合平台：把企业客户聚起来，让有产品的团队演示和交付，自己收佣金。他称每天新增三百至四百个微信，真正有效企业客户不足10%，约三十至四十个。这个口径区分了新增联系人与有效客户；其想法也源于亲自做企业内部交付后感到维护和推进负担过重。

“不懂技术”到底指什么

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

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

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

一位资源方说自己接触约四百家餐饮门店，另一位做供应链的朋友联系约两百家副食店、小超市。他准备把实体店的财税、管理、获客、会员和支付接在一套系统中，语音记账是其中第一个板块：例如外卖收入一千元、店内收入五千元，再口述买菜五百元、工资等支出，生成每天的台账。这是他解释构想的示例账目，当时还没有产品。

这位被称为宝哥的餐饮资源方，其四百多家餐饮客户来自多年餐饮燃料供应（从柴油到甲醇等新型燃料持续配送建立的信任关系）。他和合伙人曾商量过自研或找厂家贴牌收银管理硬件，涉及约五十万元投资，但回顾2019年推广蜻蜓、青蛙等扫脸支付设备的经历，他们担心商家难以感知实际痛点而不愿为软硬件买单，自投风险较高，因而将自研项目暂时待定，转而考虑直接代理已有成熟产品。

前述渠道商给出的现成餐饮产品更偏管理，自己也说拓客部分做得不够好。他介绍一个主账号可配三至五个子账号，并愿意给资源方试用一周至半个月，不合适便收回账号。资源方一方面考虑自研或贴牌，另一方面担心前期投入和试运营无效；这正是先试现成产品、再决定是否开发的分岔。

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

在讨论产品付费意愿时，一位经营者以公司女同事为例：尽管某款美图软件功能简陋，但因提供了一种她想要的特定风格，每月愿意支付约79美元；他以此认为垂直情绪或特定美学需求具备强付费力。现场另一位女性参与者随即提出不同经历：自己每月AI工具支出达七八百美元，却舍不得开通美图会员。这一反例表明消费决策取决于具体业务需求与预算分配，不能单凭性别标签推断付费意愿。

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

驾校经营者也分享了推广中的实际反思：为了固定开播时间，她选择自己容易早起的早上六七点开播；其他讨论者指出，驾校直播挂团购走的是本地团购流量，考驾照的年轻人很少在清晨刷直播，开播时段应配合目标学员的活跃时间。此外，她曾遇到外请主播把账号播废的问题，希望用AI自动筛选出高意向学员再交由人工销售，但咨询某家宣传很好的红熊AI后，觉得报价过高且不确定效果，决定自己先行测试。

算力转介：销售的是已有需求，不是模型概念

另一位参与者分享了算力销售副业：他把中转服务商介绍给两家制作短剧、漫剧的公司，对方确实需要调用视频模型生产内容；双方的股东、技术负责人和服务商进群对接，企业接入端口后按实际消耗形成销售分成。他说自己能在账户看到成交消耗与收入，约四十二天账户显示二十多万元，但没有拆解结算、成本或实际到账。

这里的生意入口是已有企业关系和持续生成视频的用量需求。介绍人未掌握底层技术，却把需求方、供给方和负责落地的人拉到一起；这与从零寻找陌生客户的销售条件不同。随后对话追问低价算力来源，有人直说上游用“不好的操作”压低成本，介绍方表示自己不管上游。对话没有继续说明上游具体做法或结算条件。

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

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

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

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

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

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

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

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

九、阶梯薪酬与留人

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

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

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

薪酬怎么和结果连起来

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

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

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

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

其他人提出的实际问题

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

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

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

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

一位做了约十年劳务业务的经营者介绍，他服务的厂区在职人员约一千人，公司有约五十名专员，手里约一百五十个内容账号，其中二十人做剪辑和发布。他想引入懂AI的人带原团队提高获客产出，而非把团队全换掉。他用每天一千份简历提高到一千五百或两千份举例说明目标，这些是期望，不是已经实现的增长。

他两年前曾到厦门、广东考察并买软件，课程演示听起来很好，实际使用不到一个月便碰上升级、bug、停顿等问题。所以他需要的既有软件，也有长期负责运行、教团队使用的人。合作方式可以谈固定工资、保底、分红或股份，当时还在找人，尚无谈定的合作。

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

业务与技术如何分工：先把0到1梳理通，再按回款分账

一位女装经营者转向企业AI服务，是从身边客户的具体痛点起步。她介绍，一位跨境商家此前投入一千多万元搭系统，仍有难以解决的问题，她把懂技术的朋友介绍过去，自己负责识别需求和梳理业务逻辑，促成了合作。从去年年底开始推进，先签基础服务费和年度框架，后续再谈股份或效益分成；这些层次并非一开始都已兑现。

她披露自己的技术合作分账：先把客户需求和0到1链路梳理清楚，甲方实际付多少钱，就把其中70%交给技术交付方。客户按月付就按月分，按季度付就按季度分；一年一百万元、分七十万元只是解释算法的例子。渠道不是只介绍联系人，还要理解改造后哪里可能亏钱、哪些环节可能变得更差，技术方则需要迅速学懂业务。

她谈到的另一条需求来自台湾连锁超市：几十家店，采购经验靠上一代带了多年，采购员仍需逐层培训；商品品类、品牌的选择与物流、分发、线上引流到店没有被既有定制系统充分串起来。这是洽谈中的需求，尚无技术进场后的结果。她自己仍保留女装业务，由原运营团队管理，并以自家电商、跨境、律所和财税案例建立客户信任。

她开始给自己做短视频账号后，即使粉丝少，也有人主动联系承接技术任务。这是她获得交付伙伴的一条新渠道。至于企业内部经验丰富的员工，她举的协作办法是保持原来三万元月薪，让对方减少工作量，以实际收益降低抵触；不是先要求员工交出经验，再讨论待遇。

有经营者将内部系统优化岗位称为“全栈产品经理”：市面上虽难招到成熟人选，但通过招聘找不到工作的计算机专业毕业生，为他们定下清晰的内部优化或业务指标，让他们以产品经理身份推进内部系统优化和工具落地。这种内部团队由于已有技术承接人，对外部通用FDE的需求相对较低。

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

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

该服务商把每个岗位做成不同工作台，预编排常用任务，员工点按钮、用聊天框，或通过通用Agent调用MCP。招聘场景里，他举了从简历信息到联系、约面试的链路；这一描述是产品能力介绍，并非现场演示的招聘效果。底座还包含按员工限制文件读写、禁止查询其他员工工资、模型预算上限、用量账单和防空转等控制。

他首先用“银行级安全”和可自动转账形容系统，随后解释转账走预设代码逻辑，数据侧做权限、加密或脱敏。这些是他的安全主张；其他人继续追问：接云模型时哪些信息仍上传、脱敏后还能处理哪些任务、与大厂工具相比究竟增加什么保障。

这位服务商的收费示例是节省一百万元、首年取其中80%、以后每年15%，达不到约定效果按比例退款；与后面另一位“3＋X”供应者的报价不是一套方案。长期维护会遇到模型升级、下线和提示词变化。一方提出自动路由，另一方追问两个模型的输出是否一致。这里的经营成本不只在首次开发，还在持续保障。

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

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

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

进企业评估时，该结果托管方的一套经验是先问“部门里哪些员工可以远程办公”：凡是能纯远程办公、不涉及过多线下人际沟通的线上岗位，交付物与AI能做出的成果属性较一致，就列为AI化与托管的初筛重点。他们以此为一家餐饮连锁将原有四十人的设计团队优化到六名审核管理人员，其余交付交由外部人和AI完成。

这位结果托管供应者称，餐饮连锁原有四十人的设计团队缩到六名审核与管理人员，其他执行交给其人和AI；他也说约三百人的工作已在这边托管，但客户数仍不多，业务逻辑刚跑完。这几个数字分别是客户团队、托管规模与客户数量，不能互换。

交付物可以仍是Word、Excel，通过邮件、飞书或钉钉发给主管；内部程序主要给AI调用，尽量不做一整套供客户学习的UI。他们曾因交软件后的培训和维护过重而转型：员工速度快了，却接手被裁同事的活，还需最后签字，抵触并没有自然消失。

这项业务怎样收钱

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

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

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

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

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

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

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

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

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

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

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

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

架构是怎样变的

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

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

框架名称与情感识别模块仍待确认，已披露的重点是执行、规划与记忆的分工。

项目当时进展到哪里

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

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

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

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

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

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

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

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

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

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

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

多Agent分工还带来上下文成本与Token消耗的取舍：频繁将小任务向外派发给不同副Agent，会导致主Agent的上下文和背景信息被反复搬运，消耗大量Token。尽管大模型端存在KV Cache缓存机制可以复用相同前缀，但跨角色传递仍会带来额外开销。因此是否拆分Agent并非越多越好，而是一个需要权衡执行策略与Token成本的工程决策。

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

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

flowchart TD
    subgraph MultiAgentTier["多 Agent 协同分层与 Token 预算门禁"]
        M["主控协调 Agent (持有长期目标/目录/预算)"] -->|"明确业务约束 + 强验收门禁 (Checklist)"| W1["执行 Worker A (短期单点任务)"]
        M -->|"明确业务约束 + 强验收门禁 (Checklist)"| W2["执行 Worker B (短期单点任务)"]
        W1 & W2 -->|"结构化交付物 + 决策依据证据 (拒绝黑盒自嗨)"| M
    end

    subgraph MemoryTier["三层记忆物理解耦"]
        L1["用户个人偏好层 (提示词习惯/口吻风格)"]
        L2["岗位执行方法层 (当前角色 SOP/动态工具链)"]
        L3["公司业务规则层 (全局风控/数据红线/合规标准)"]
    end

    MultiAgentTier -.->|"按需隔离挂载，杜绝上下文污染"| MemoryTier

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

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

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

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

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

对Markdown记忆的批评主要针对规则混放、难以重新组织的问题。

最后看经营闭环

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

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

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

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

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

一位医疗企业业务经理在分享中证实了这种阻力：他曾为上级做过AI管家，因个人微信有封号风险而接入企业微信，每天早上九点准时将群内销售情况整理成简报发送。但公司手工统计销售数据的同事担心客户信息泄露，也产生“你统计完了我干啥”的岗位防卫，领导依然不放心。经历多次沟通受阻后，他决定不再执着说服全公司，转而先把自己带的小组工作流改好，做出提效实效后再行推广。

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

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

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

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

测试与原型各解决什么

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

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

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

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

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

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

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

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

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

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

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

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

• 开始前给出任务边界和验收现象。 写明要解决什么、允许改哪些部分、预期看到什么结果；不要只说“所有bug一次修完”。原文中的使用者已经反复要求检查、换会话读维护手册，仍在返工，所以保存文档本身不是验收。

• 交接保存工作方法，别只存个人偏好。 将公司规则、自己处理工作的办法和表达偏好分开，接新任务读取相应规则。是否有效要看下一次任务是否遵守约束、交出可检查产物，而不是记忆文件越来越大。

这组约定把反复要求“再检查”改成拆分、独立审查和验证产物。

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

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

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

以下保留现场讨论中提及的个人探索与未开源原型线索，供后续跟踪研判：