2026-11-08 · 企智AI落地派：Agent开发、企业落地与获客经营

这场交流从制造业获客聊到AI开发，再延伸到食品研发、算力生意和本地服务。几个案例反复碰到同一个问题：工具能做一件事，不代表客户愿意改变习惯，也不代表整项业务已经跑通。下面分别展开各人的实际做法、试验和还没解决的问题。

1. 控制柜厂：从地图找客户，慢慢积累经销商

温州戴总在弟弟的控制柜企业工作。厂里设备较先进、用人不多，订单还比较稳定。但他特别纠正了一点：设备自动化，不等于整个企业的数字化已经做好。

他们早期获客很辛苦。从高德地图找经销商，再一个个打电话、加微信；也请业务人员找客户，每找进来一个给几元钱。这样逐步积累下来，他说现在有约15万经销商资源，这也是订单相对稳定的原因之一。他们的做法，是把零散渠道长期做成客户网络。

资源集中在微信，也让他们担心封号。他想找技术人员合作，慢慢做自己的生态，把已有资源迁过去，但还不知道怎么做。

主持人提醒，改变客户已经习惯的使用方式是件很重的事，建议先在微信生态里继续经营。这项迁移还停留在找思路、找技术合作方的阶段。对这家订单正常的工厂来说，先守住稳定生产，再考虑改造，是讨论中的前提。

2. 少爷的开发系统：先看开销，再决定是否加账号

少爷用两个高档CC账号做开发，重度使用时，一周有三天因为额度用完而闲着。他没有先继续加账号，而是让AI分析过去96小时或一周的运行记录，看看上下文和任务结构有没有浪费。

他试过30万、40万上下文，认为已经够用，缓存以及周、月额度的使用也舒服了一些。他提到过97%的压缩比例，但随即说忘了具体数值是36万多还是38.4万，连需要调整的配置项名称也没在现场说清。

他的做法是先分析自己的消耗，再做对比试验。30万到40万是他当时觉得合用的范围，具体配置仍要看自己的项目。

看官方变更，但别让术语牵着业务走

他把自己理解的工具变化归成几个阶段：提示词、上下文管理、Harness、循环执行，以及夜间总结错误、修正规则，让系统逐步自我改进（他称接近RSI）。Harness在这里指围绕模型搭建的任务执行和约束系统，不只是多写一段提示词。

他提到Lydia、Tibo等产品信息渠道，会看厂商的主账号、产品邮件和变更日志，从更新中推测接下来值得研究的方向；也提到让AI分析官方文章与自己方案的相似之处。这套阶段划分，是他用来理解产品变化的思路。

另一位参与者从电商经历回应：平台从铺货走到精铺、品牌和海外仓，每一阶段的方法都会变，不能指望一个技巧永远保密、永远赚钱。主持人则劝少爷，持续追新概念会很累，不如盯住一个稳定的客户问题，例如外贸工厂独立站的流量和询盘。双方的侧重点不同：有人研究工具怎样变强，有人先问它能否让客户愿意付钱。

3. 多Agent怎么分工：少一点，职责说清楚

少爷当时用三个Agent干活。在这三个执行者之外，还有一个负责指挥、派任务，另一个持续观察执行情况，协助修正Harness。他提醒不要一下撒出去几十个角色：部件越多，职责越容易串，后面修系统会很疲惫。

他用班级分工打比方。总指挥、纪律委员、卫生委员各管什么，要事先想清楚。他正在研究的“图设计”，也是从系统角度看每个部件可能处于什么状态、哪里会出错、彼此怎样协调，而不是只把单个Agent做好。他也说，这仍是自己在研究的方案。

他的项目在1.2版约有18.6万行代码，正在做1.3，已经规划到1.5。但他自己也觉得可能臃肿，考虑以后整体整理。他开始关心的是怎样把项目整理得更简洁。

磁盘清理与错误记录

他的1TB硬盘原本剩两三百GB。开发时同时开过七个iOS模拟器，每小时可能增加十几GB数据，他先设了剩余约40GB时暂停的保护条件。

后来系统自己挂了监控进程：在剩余空间接近55GB时做一次深度清理，处理两小时前已经不用的worktree、关闭不用的模拟器，清完恢复到约150GB。他说这段监控并非自己事先明确要求系统写的。

另一个做法是把错误写进lesson文件。累积六条后重新读这些错误，让负责Harness的角色修规则和脚本，再重新加载相关Python脚本和规则。他希望把重复失败留下来，修执行系统，而不是每次只修眼前报错。

不同工具的取舍

他觉得CC更适合上层、跨行业的架构思考；另一款工具修后端很强，但过于防御，如果每条修正建议都照做，项目可能迟迟交付不出。还有一款开中档推理时，在设计上更合他的习惯。

后两款在转写里分别记作“Astrid”和“RDom 4.0”，现场名称不够清楚。他的用法是让不同工具处理不同环节，再自己判断哪些建议值得实施。

4. SEO工具：读到数据只是第一步，交付还得做到流量和询盘

少爷分享过两个网站。第一个名字没说完整，只听到W开头、以AI为后缀。他用了约三个月，帮一家企业做独立站SEO，提到模型账号每月约20美元，但没有限定必须用哪一家。工具通过连接器接Google、Facebook等后台，省去手工导出CSV或截图；他用CC调用连接器，读数据、看竞价词，也说工具有写入修改权限。不过他只研究了自己要用的部分，没有把全部能力都确认一遍。

第二个网站口述字母接近“A H R E F”，他还没实际用，只是在比较不同模型支持的插件时发现它，描述它能做建站和SEO，类似把店铺搭建做得更省事。名字和描述都还不足以确认具体产品，选型时仍需要把功能看清。

主持人把话题拉回客户交付。他举例：客户给4K，可能关心的是三到六个月后有没有流量和询盘，而不只是拿到一张分析图。围绕这个目标，还要做这些事：

• 看网站已有链接，哪些需要调整；

• 找与工厂业务相关、近期出现的关键词；

• 把关键词和真实业务结合，确定文章选题；

• 优化标题，并把后续操作真正做下去。

工具提供数据和部分操作能力，服务商仍要把它组织成客户理解、愿意购买的完整服务。4K在这里是说明问题的例子，不是一份已成交合同。

亚马逊代运营还是下一步计划

主持人还想在下一年做亚马逊代运营，目标是把市场报价至少压低一半。他准备先做较细的店铺运营Agent，尝试让一个人加系统，从原先管理两三家店，提高到管理三十至五十家店。这是他准备试的业务，不是已经达到的产能。

现场也提到不同渠道放不同产品：有品牌先在亚马逊做出名气，再在独立站提供差异化商品。不能只看建站工具，还要想清楚各渠道承担什么任务。

5. 批量私信实验：跑通操作，不等于能持续获客

一位参与者用WorkBuddy整理了约两千名垂直行业抖音博主，分表后尝试通过多个账号发私信，把人引到微信，再销售服务。测试两天后，他发现十到二十条左右就会遇到风控；即使要求出现弹窗就停止，也没解决问题。后来人工联系公开商务微信，约十二到十五人后，也遇到限制。

主持人讲了更早做Instagram的经历：起初点赞、留言跑得顺，扩账号后平台反应过来，反复改程序也只能短暂恢复。真正消耗的不是一次操作的算力，而是技术人员不断重新排查、修复的时间。最后他建议别继续耗在这条路上。

他认为已经收集到的同行资料，可以转去研究公开内容、爆款素材和脚本链接；做商务联系则要回到对方需要什么服务。实验者也解释自己并不想做自媒体，只想找到能卖服务的对象。双方仍没有找到一条能持续跑通的触达办法。

6. 算力资源生意：差价、稳定性和结算周期要一起看

韩总转述过一家三十多人的团队，向客户提供蒸馏所用的资源，从三月做起，月纯利润曾有三百多万，后来降到一百多万。他也提到AI Studio资源不好出、Vertex资源需求更旺，价格从1.6涨到5.5；这笔报价的单位现场没说清。

AWS是另一个例子：海外企业资源成本可能在官方价七五折，而收购报价大致八四折到九二折。拿七五折成本和八六折收入比较，是十一个百分点的价差，还没有扣除全部经营成本。

更接近终端的客户价格可能更好，但垫资更多、时间也长。小时或按天结算的业务，压款相对少。大家还讨论了合同保量与资源风控：有资源不代表持续可用，报价好也不代表马上能成交。后面的算力经营交流继续把这些条件展开。

7. 补贴与园区：政策支持和钱实际到账是两件事

现场有人读了一段江苏支持政策，提到支持比例原则上不超过实际费用的50%、单个主体不超过500万元，同时指出消耗量要接入相关监测平台，才能得到认可。其他人又谈到额度、申报时间和早期支持机会。大家也在追问，支持额度究竟怎样才能到账。

安徽数据标注从业者谈的是另一套项目：省里70%、地方30%的资金结构，地方部分没落实，会影响整体拨付。他还提到人员社保、基地建设，以及南京同行去宿迁看政策支持。江苏与安徽在聊不同项目，实际申报还得分别问当地条件。

争论过程中，有人谈到不规范操作，随后被问及的另一位明确纠正“那不是我说的”。现场最后强调按合同、开票和申报要求做事。

办公场地先看规则，再看实物

南京徐庄一带的参与者说，OPC社区可以申请单独房间，具体看规则。如果要五百、一千平方米，已经更接近普通公司租赁。现场报出物业费7元、租金约1.2元，计费面积和周期还需要实地询问。

他介绍场地较新、有前期优惠，也欢迎大家实地看。对做业务的人，线下见面、看场地、感受合作是否合适，比只在线上听一段介绍更直接。几位小老板还谈到经营压力，甚至需要兼职养公司，这也是讨论政策和成本时的现实背景。

8. 咖啡点单小程序：先做出能用的版本，再讨论数据资产

一位园区经营者买过两三千元的小程序壳，用来咖啡点单。现在想加入链上存证接口，把交易数据存起来，设想以后向数据资产、RWA方向发展，但还不清楚接口怎么接。

主持人建议，如果旧壳的内部结构也不清楚，可以考虑用WorkBuddy重新做一个简单版本。他看重的是与小程序生态对接、发布的便利，不是说存证和资产化已经完成。

新手不会描述界面时，可以找具体对标：风格参考哪个网站，结构参考哪个产品，把成熟页面给工具看，比只说“做得好看点”更容易讲清楚。先动手做到遇见实际问题，再带着问题请教。

现场有人更推荐Codex，担心新人用能力受限的工具会误判AI。主持人回应，这其实是两个问题：一个是眼前要交付国内小程序，另一个是怎样深入学习AI编程。选择不能只争谁更强，还要看当前想完成什么。

9. 张总的工厂：自用先短、轻、快，对外服务再整理方法

张总此前用DeepSeek解决过实际生产问题。后来有人建议，他可以搭一个线上“公司”：老板、生产、销售、研发、财务各有Agent，他正准备配电脑试试。还有建议给销售配录音卡、给车间加摄像头，分析客户反馈和工序布局。

主持人不赞成马上把自用场景做重。添设备之后，员工会不会用、是否习惯、要不要额外监督，都会多出环节。能直接问AI、直接验证的事，不必先搭整套系统。这个意见针对张总当前的工作路径，不等于所有企业都不需要录音或摄像头。

对外做FDE服务又是另一回事。FDE在这里指贴近企业现场，把问题诊断、方案和实际落地连起来。服务别人的企业，需要更清楚地收集信息，形成可重复的方法。

从16个问题缩到10个问题

张总曾设计16个问题，想了解企业的来龙去脉和优缺点。跟老板实际聊过，觉得太长，又缩成10问。但A4答卷不容易写出细节，他开始考虑用聊天替代填表：

1. 录下和老板交流的内容；

2. 整成文件，让AI帮忙梳理问题、提示词或话术；

3. 再让老板围绕近期生产、销售、财务中最头疼的事继续追问。

这次主要谈了十问怎么用，没有逐题展开。录音也不必先买特定设备，手机、录音笔、手表能完成任务就行。

10. 配方研发：AI给线索，行业经验和小试负责验证

张总讲了一个很具体的动作：AI给出调料配方后，他第二天去找原料，跑了三家才找到木香，回来烤干、粉碎，试了两三次，觉得口味不错。

这类用法的价值在于，做这一行的人知道去哪里找原料、怎么试、怎样判断口感。不是把AI的一句话直接当成成品，而是用自己的生产经验把建议做成样品。

馒头代工带来的新品思路

朋友介绍的一位客户想做添加提取粉料的馒头，张总已帮忙做出样品，口感等方面尚可，对方提出让他代工。张总想到，自己已有儿童牛奶馒头，也在做苦荞、燕麦、青稞复配的杂粮馒头，能否结合对方思路继续开发。

他并不知道对方的完整配方，只是沿着交流得到的思路和AI讨论，再到阿里巴巴查桑叶提取物等原料，也到其他地方查相关知识，计划买回来试。他提到母亲是糖尿病人，也尝试过给母亲做面食。关于新品效果会更好的想法，仍待后续试验。

李校长特别提醒：做面食经验丰富，不代表了解每种提取物的反应；超出自己认识的成分，需要请机构分析检测。张总回应，常规产品现在每年做检测，新配方也要先做样品、再送检。他准备继续做样品和检测，把想法落实到可判断的结果。

谷朊粉：买到什么细度，会影响口感

杂粮面食粗糙、没筋度，是张总要解决的实际问题。AI建议加小麦面筋粉，也就是谷朊粉。第一次买回来的颗粒像酵母，他后来又买了细得接近面粉的规格，加入后口感明显不同，粗糙、拉嗓子的感觉有改善。

这段值得保留的细节是二次采购时改变了粉的细度。他谈到了细度变化带来的口感改善，具体目数和添加比例还没有展开。

从产品配方，继续查到市场和供应商

张总不只问AI怎么配，也用它了解杂粮食品的市场。他会再去百度和电商平台看商品销量、活动和复购情况，找到山东一家口感较好的粉料供应商。对方会先预处理原料来改善口感，他也继续了解其产品和扩产情况。

他由这些资料想到，食品企业也许可以从普通主食转向更细分的人群和需求。主持人支持继续试，但建议先把产品实验、检测认证做完，再谈扩大销售和产能。市场资料可以帮助确定方向，最终还得回到产品本身。

11. 工程图变更：通知发出去了，员工为什么还照旧图做

小张收集到一个工厂ERP需求：工程图更新后，系统会发邮件、企业微信通知，但一线人员不看，仍按旧图加工。工厂想要的不只是“再通知一次”，而是让员工确认变更后，才能继续在生产电脑上操作。

这就解释了为什么一些看起来简单的建议没打中问题。有人建议电子看板，举类似麦当劳取餐屏的做法；小张回应，大屏、邮件、企微都可能被忽略，自己要解决的是强制确认。

难点不只在电脑怎么连

有人说十几台电脑可以装后台脚本，用局域网由一台运行Agent的电脑管理其他电脑。动态IP又引出几种建议：固定IP或绑定地址、用向日葵，或者反过来由客户端请求固定服务器。

但这些只是联网和展示手段。真正的业务映射在ERP里：产品、BOM、班次不同，对应的员工也会变化。买用友ERP时没要API，厂里只有维护人员，集团IT还要服务多个子公司，未必能长期为一个工厂开发。

讨论后又澄清，这并不是让AI直接控制机床，而是考虑限制Windows上位机上的参数录入。即使电脑端能做拦截，人员映射怎样从ERP取出，仍是待解决的问题。有人建议找原厂补服务，也有人提只读数据库；交付后加需求需要付开发费，不能因为已经买过ERP就假定所有改造都包含在内。

12. 昂哥的自研Agent：开源启发与产品验证要分开

昂哥介绍了自己给Agent接逆向工具、开发笔记和技能的尝试，还宣称能处理某些本地密码验证。现场其他人追问加密、数据库和开发能力，双方没有拿出一个能普遍适用的结论。他打算把项目给大家看，让别人用Agent读代码、技能和笔记，再继续研究。

他还用两天两夜做过一个小型CPU知识问答引擎。据他说，针对约一万字文档可以回答问题，连知识资源约300MB，引擎本身几MB，老电脑能跑。但之后让Agent连续改了十几次，把有突破的版本改坏了，准备修回来再给主持人试。

有人认为与其重做，不如微调已有预训练模型，也分享了自己试语义网络和小神经网络效果不如Transformer的经历。主持人更看重开源尝试能带来启发。这个项目还在修复、试用的阶段。

13. 庚庚的免费Codex课：用课程找客户，也让学员做出东西

郑州的庚庚做免费基础培训，想通过它找客户、找合作资源，也看看能不能找到未来员工、试出商业模式。学员来自短视频和线下渠道。

两整天课程这样安排：

• 第一天上午认识、下载安装并使用Codex；下午理解知识库的用途，再自己搭。有学员五六个小时没完成，晚上还接着做。

• 第二天先讲自己想实现什么，把思路和架构理顺。先做看得见的中控台，再做日志回传，通过日志找出哪个节点不通，然后逐个接起来。

他展示的教学方向包括文生图、图生图、图生视频，接口可以选国内或国外，不绑一家。他说有学员两小时左右能接出中控台，但这不是“说一句话就自动生成完整作品”。让日志看得见、问题找得到，才容易继续调试。

地图商家资源与短视频获客，还要看实际触达和成交

他给美容商家做软件时，对方追问能不能解决获客，于是又研究同城商家信息和短视频曝光。他提到自己掌握的是商家信息资源，不是已经加上三十万微信好友，更不是已经获得同等数量的客户。

他尝试把本地商家资料与平台推荐、小额投放结合，也说自己做过评论区触达，但量少、账号损耗大。有人追问推荐比例，他讲了自己的观察；当时仍停留在自己的试验观察。

这段讨论里，他还主动提到工商信息采集曾被联系，数据获取能够追踪，拿来商用分发有风险。对这类资源，数量大只是第一步：资料是否适合使用、能否联系到真实需求、最后有没有成交，都得分别看，名单只是接触客户的起点。

另一位老师的线下班

开场时，另一位老师说自己已办三期线下班，每期二十多到三十多人，宣传线上、线下结合，下一步想把直播也做起来。他也在尝试把课程、内容和线下交流连起来。

14. 一位上市公司员工的反问：先找陌生付费客户

“加州女孩”介绍，所在公司已有四十年行业积累，几千名员工、上千客户，传统大项目能到数千万元；AI产品本地买GPU部署，也有约五十家客户。这些项目背后，有多年行业关系和客户基础。

他所在公司在推动员工做数字员工，先用于知识问答，再希望协助写代码。但他自己有业务原始数据时，反而觉得用Copilot或更强模型多轮沟通，比固定系统更顺手。

所以他给独立开发者的建议很直接：早点找陌生的、愿意付钱的客户，别研究很久才发现市场不买。基础模型持续变强，也会覆盖一些中间产品原先的卖点。企业大项目能成交，往往还靠多年客户关系，而不是只比一次演示谁更惊艳。

回到ERP改造，他更倾向向供应商要服务和权限，而不是先想绕过原系统。现场有人提到开源导出工具收到律师函的经历，提醒开发者，技术上能做与商业上适不适合做是两回事。

15. OpenTory：小工具的价值，可能在旧电脑上

现场提到一个叫OpenTory的小型Agent，主持人听到它只有几百KB时，想到的是工厂里的老电脑。

有些老板不愿升级Windows XP、Windows 7设备，新工具装不上，而旧生产环境又暂时不能动。如果轻量工具能在这些电脑上处理适合的任务，就有具体落地价值。主持人看重的是它可能解决新工具装不上的问题。

参与者提到群内仓库、GitHub等分享方式，但现场没有给出足够清楚的地址。想试用时应先拿到对应项目，不能只凭近音名字找一个相似工具来替代。

16. 算力用量先统一口径，再比较价格

后续资源对接中，主持人拿一款DeepSeek渠道资源举例，说最低可到3.8折、月量要求3万以上；具体版本在口述中不够清楚。另有客户问Kimi某型号、每天十万的消耗。现场没有立即报出后者的最新折扣，而是说次日去问。

讨论一度把token数量、金额和模型类型混在一起。对方后来澄清，每天十万、每月三百万说的是人民币。文本问答、代码开发和视频批量生成的消耗不能直接类比；不同渠道说“官K”，也可能指原厂接口，或运营商、云平台部署的资源，得把具体来源和模型确认清楚。

有人特别关心“满血”以及压测表现。便宜之外，还要确认拿到的是什么服务、能否稳定调用；单次问答花得少，不代表完整开发或批量生产也花得少。

17. 从科研、装车到3D查重：先分清AI到底做哪一步

一位参与者接触过杭州生命科学客户，也提到看过斯坦福酶研究的报道：AI先从一千多个候选缩到两百多个，再交专家实验。他借此说明，不同客户研发阶段不同，算力消耗也不同。报道中的八年与五个月，是他引用来说明问题的例子，不是所有科研项目的统一效率。

他自己的跨境物流装车项目，涉及陆运、铁路、海运，目标是装得更多。他参考海外产品后发现，客户还关心可视化、时间、装载和超载约束。这促使他判断，AI产品不能只停留在文字问答，还得能进入具体操作和交互过程。

3D图纸查重：开发成本和运行成本分开算

另一位参与者问，客户有ProE、STP等专业3D图纸，想查重会花多少token。首先要弄清文件是专业3D格式，不是普通PNG、JPG图片。

现场建议，把确定性的查重逻辑尽量交给代码或脚本，只有确实需要模糊判断的部分，再考虑AI。AI帮忙写程序消耗的token，与程序上线后每次运行消耗多少，是两笔账。

文件量大时，有人建议让脚本考虑多线程，不过能开多少线程、查得多快，还要看客户电脑的CPU。报价前也要问清更看重速度、质量还是低成本，几项要求会相互牵制。收费也可以分开谈：软件开发是一笔费用，确实需要持续调用模型的部分，再说明后续调用费用。

一位开发者举了另一个任务：自己当晚做约五六小时的软件，计划卖两千元，粗估用了二三十元订阅额度。他也没有精算。这不是那套3D查重软件的成交案例，更不能按这个数字给所有项目报价。模型之间也不能只比token个数，最终应比同一任务完成后的费用、质量和时间。

聊到网络稳定时，参与者也谈过线路出口、DNS配置和带宽分配的排查。低带宽线路未必适合下载大文件，调用API与大文件传输也不能只看一个总带宽数字。这些是他试过的使用条件，不是保证账号不会遇到限制的方法。

18. 用友金融员工的实践：先解决自己的问题，再理解组件

一位用友金融原厂员工说，自己当前主要是在提升个人生产力、打磨开源产品，并没有展开一项已经完成的商业交付。

他觉得大企业产品很庞大，实施、培训都重，也不一定比小团队更快用好AI。员工如果要自己承担token费用，推动使用又会多一道阻力。简单日常任务可能靠国内免费积分就够，没必要不看任务先选最贵模型。

ComfyUI从安装到虚拟形象

他做QQ机器人虚拟形象时，让Claude协助下载、安装、配置和运行ComfyUI及模型，也让AI帮忙处理提示词。素材和风格参考逐步整理，再生成真实风格形象、Q版和表情包，约两天完成。

他并不是先把每个组件、模型原理全部学完，而是边做边问：这个组件干什么、为什么要这样配。使用变慢时，他让AI排查，才知道是内存满，不是硬盘不够，从而理解自己该补什么硬件。

豆包查FAQ，反而解决了代理问题

他还给出一个模型比较的反例：代理出现问题时，用DeepSeek查了一个多小时没解决；第二天用豆包查官方FAQ，很快找到所谓无限流量实际上存在软限制的说明。

这里有用的是排障动作：回到官方说明，核实服务的真实限制。这次解决问题的关键，是查到了与故障对应的服务说明。

数百GB企业知识，按项目和共享层组织

ERP从业者追问生产级代码质量时，这位员工也坦承，企业里还常见AI生成后人工复制、审核的用法。总部平台汇总历史补丁和开发规范，但体验并不轻。这套方式仍在探索怎样嵌入企业开发流程。

对于几百GB资料一次塞进平台不好用的问题，他建议拆开：各项目保留各自知识，通用知识抽到共享层，银行、税务等不同客户的差异留在各项目里。

如果从新项目开始，可以把需求讨论、纪要、接口和开发文档、变更、客户要求、录音与员工产出持续整理给AI。老项目难在资料回收不全。这里的关键是知识怎么形成和更新，不是换一个聊天框就能把企业历史补齐。

19. 十八个后台想收成几个：先把产品和功能列清楚

另一位并非职业开发者的参与者，用三周做一个智能终端。想法从网站变成客户端，又加3D展示、Agent互通和项目看板，十几个Agent并行，最后有十八个后台，其中不少功能重叠。临近想开源时，他希望合并成一到四个。

别人给出的第一步不是再找一个更强的Agent，而是先把现有功能列全，哪些重复、哪些能合并，梳理产品需求和架构，再划分模块。可以由主Agent维护计划、安排任务，执行者各管一块，另有人验收；并行本身不一定有问题，边界不清才会互相影响。

提问者解释，自己也有主Agent，但后来扛不住就分成几路。他不满意自动派单，想自己接管，而且希望每个Agent都有看得见的窗口，能够随时汇报。

分歧一：看过程，还是按结果验收

另一方建议按功能结果和测试验收，不要逐步盯每个动作。提问者却说，子Agent对话不好找，自己不看界面就不放心。这个可见性需求没有被一句“相信AI”解决，仍是他设计客户端的原因之一。

分歧二：需求要先定，还是边做边改

大家提醒，需求持续改变、旧新文档冲突，再要求AI“用最快方式修好”，容易修这一处又破坏别处。提问者反驳，创新本来就要边做边看，遇到技术卡点也得改方案。

这段讨论没有得出不许改需求的结论。更实际的问题是，变化发生后，怎样让当前任务、文档和各Agent理解的一致，而不是让它们继续各写各的。

会话、开发流程和测试的建议

一位参与者习惯让一个会话负责一个功能模块，拆任务给子Agent，汇总文档后再开新对话，减少旧上下文负担。他说自己通常只开一到三个主会话，这是个人工作方式，不是固定人数规范。

现场还提到一套GitHub开发方法，名称近音BMAD-Method，按需求、架构、UI、用户故事、编码、review、测试分阶段，也提了spec coding和Kiro一类工具。大家有些名字记不清，但讨论目标很明确：不要只有“尽快写完”，要把需求、实现和验收连接起来。TDD先测试再实现，也是现场提出的方法之一，落地时还要在真实项目里检验。

怎么赚钱，也有几条不同路径

参与者列了算力、企业定制和个人小需求订单几种路。企业定制又可以自己做小ERP或单点工具，也可以基于第三方产品做配置和交付。他听过两三千元智能体成交的例子，但这不等于每个人都能按同样价格重复成交。

那位员工说，自己目前收入最多的是算力，约十五到近二十“个”，后面继续展开这门生意的资源和风险。几种收入路径需要的资源和能力不同。

20. 算力卖给谁：先找具体用途和圈子

一位卖家说，自己到当时赚了十五到接近二十“个”，没在现场说明统计周期。他的上游来自QQ群、微信群、TG和行业社区，是边做边积累的。主持人仍继续追问：从哪里拿货，下游是谁，为什么会找你买？

另一位从业者把C端和B端分开讲。个人用户可以从小圈子的真实用途入手，例如小红书里玩“酒馆”的人，有自己的模型偏好和术语，常用Gemini，圈内叫“太子”。做内容时先了解这些人需要什么，再吸引他们来试，而不是面对所有人泛泛推销AI。

企业采购则涉及主体背调、合同、发票和结算。供应商会看公司情况，客户月用几十万、上百万元时，问的问题也和个人小额充值不同。做账号、开直播、讲行业认知，以及在圈子里建立信任，都是从业者提到的获客方式。

他回顾，New API等建站工具、Coze工作流和后来更易上手的Agent产品，逐步让普通用户和企业认识这些服务。专业开发者偏爱哪款工具，与普通公司首先听说哪款工具，是两个层面。WorkBuddy的推广和生态触达，是他认为它能带来客户认知的原因之一。

21. 新人先搭中转站，还是先做分销

现场有两种路线。

一种是自己搭站接上游。用户从自己的入口使用，后续客户维护和售后更容易掌握。想长期独立经营，确实需要懂站点部署、服务器和整条链路。

另一种意见是，先别花时间把站搭完，再发现没有用户。可以先做上游的分销，验证自己能不能找到人、把产品卖出去。现场提到带AFF的邀请链接，按充值返佣，举了5%或5%到10%的例子；具体比例取决于平台。销售跑通后，再花钱找人搭站，也是一种选择。

这不是技术能力越少越好，而是初期先验证最缺的那一环。产品做到八十五分或九十五分，并不会自动有人来买。服务器看起来只有两三百元，也不代表经营没有成本，后续还会有故障、保活和客户问题。

22. 大流水、薄利润：有些单宁可不接

三麦说，自己收到过月量两千万元、利润一两个点的业务，也不愿轻易接。他更愿意做两三百万元、能够稳妥落地的量。

顾虑包括上游是否可靠、客户款怎样结算、税务和审计，以及自己能不能承受资金风险。他举例，小额交易都正常后，信任建立，突然转出五百万元，对方如果跑掉，之前那点利润根本补不回来。这是他说明风险的例子，不是这次已经发生的损失。

现场也讨论过敏感内容生成业务。有人想投入做代理，另有人转述隔壁公司做相关业务被抓的经历，劝不要只盯最快变现。对风险判断大家并不一致，但讨论确实让几位参与者重新考虑，是否有必要承接这种客户。这些拒单原因，也影响了他们对业务的选择。

他更偏好国内主体、对公付款、合同票据能对应的业务。熟人或同城上游，也不能代替对履约能力和资金的判断。

23. 便宜的模型资源，是不是同一种货

有人拿到很低的视频报价，三麦就追问规格和来源。原生分辨率与后处理超分，不是一回事；返回链接看着像官方，也不能单凭外观判断服务来源。

他反对把低成本超分结果当原厂货卖。如果说明白规格、处理方式和价格，客户愿意接受，那又是另一种交易。关键在于承诺的东西与真正交付的一致。

有人想做模型校验器，但当时只是想法。讨论中没有展示一个已经完成、能准确识别所有掺假的检测工具。

渠道表不是一份统一价目表

三麦说，自己花几个月积累了约四十家渠道、二十多个模型的表格，知道用量到什么档，可能争取什么价格，也有人持续通知他上新。

别人想拿统一价目表，他只愿先给模型清单。量级、质量、货型都不一样：官方接口转接、自部署服务、账号池，不能只看名字相同就当同一种货。月用一两百万元，与三五百万元的报价也可能不同，得逐单谈。

有些资源号称自部署，价格低、TPM又高，他自己也会怀疑是否真是所说的来源。企业验货还要看吞吐、并发、服务约定、错误率、首token等待时间和延迟分位值。视频服务如果中途停供，客户一批内容做了一半，也会直接影响合作。

他说部分渠道有自己的进货底线，不愿为了海外视频一笔约两个点的差价去承接。出货价要在进货基础上继续覆盖自己的成本和服务。

他举自己当时的视频资源渠道为例：原厂接口资源的进货底线约七六折，官方接口转接约七三折。另有人拿到四八折报价，他怀疑规格和来源不同，可能包含低分辨率生成后再超分。谈企业文本资源时，也报过自部署约三三至三五折的供货案例。这些是具体渠道、货型和用量下的议价；账号池口述的一点几、两倍又是另一种报价口径，不能直接放在同一张折扣表里比较。

24. 大B客户的交付：背靠背合同，技术支持找谁

大客户并不一定都用卖家自己的公共中转站。有时由上游建立独立入口、服务器和专线，一家或一两家企业使用一台服务器。卖家处理上下游背靠背合同，客户付款后再付上游，会计处理票据，上游提供技术支持。

普通文本接口相对省事，视频模型接入往往要做额外适配。聚合工作台则把文本、图片、视频放到一个入口，方便客户按用途选择。

有人拿OpenRouter和硅基流动来问，是否有一个入口能选择多家模型。从业者回应，国内也有聚合平台，但价格、模型范围和商务条件各不相同。讨论集中在入口和经营方式，没有展开这两款服务的完整实测。

代理还担心，客户会越过自己直接找上游。卖家说，可以单独建站，不放上游联系方式，由代理自己的品牌入口承接。这与新人先用AFF链接验证销售，是面向不同阶段的安排。

C端用户的问题更零碎，多家上游还要持续检查可用性；B端前期难谈，但流程建立后，有时反而更顺。客户先测服务、压测、反馈问题，过关后才继续谈预付、合同和打款，成交周期因此可能很长。

网络并不一定便宜

有人说普通四核十六GB服务器每月百元出头，但企业还在意首token响应和低延迟，专线可能每月约两千元；视频、图片业务还需要更高带宽。只算CPU和内存，就会漏掉真实成本。

客户如果问API能否接触企业数据，不能只靠卖家一句“我没必要卖数据”解决。讨论中的回答只是经营者的表态，客户对数据流向和隔离的顾虑，仍需要在具体服务里讲清。

25. H3漫剧客户：样片刚接好，产能和收入还在验证

一位卖家接到山东漫剧工作室客户，对方想做三块收入：收学费、卖一键出剧工具，以及作品在视频号上获得广告分成。

客户希望教学演示先把成本压低，能跑完流程；学员以后要做精品，再换更好的模型。现场说真人效果不理想，动画更适合这种试验，剧情冲突、节奏和目标观众口味也影响选择。精品内容仍需要人工投入，一键生成与精品制作不是同一项产品。

报价先连着规格看

这笔渠道业务口述模型为MiniMax H3、768P，按每秒0.07元给客户，整部成本粗估两百元上下，工作流还会用超分。客户对低成本流程和高画质作品的要求不同，报价也不能混算。

有人说两三小时能做一两部整剧，再设想几十台电脑一天做上百部。到后面追问时，卖家明确澄清：昨天还在调试，今天才接好，只充了一两千元，尚未正式跑量。月用大几十万甚至上百万元，是客户提出的预期。

平台分成几几开，现场也有人只是猜测。这个业务当时还没有稳定产量和利润账本，但已经有了样片、接口和初步客户反馈。

为什么愿意为这个客户接新接口

卖家说，正是听到客户提出较大的预期用量，才去接H3。加一个模型还要适配和维护，不是有人问就值得做。他还试接了一个口述近音“慕斯”的接口，但刚上线、不稳定，客户只是考虑以后使用。

他称自己有二十七种H3渠道，当前选的是自己觉得较好的一种；看过客户样片后，对方也有介绍其他客户的意向。这是一个具体的经营动作：先把客户当前要跑的东西服务好，再争取转介绍。

至于横店是否一定有需求，现场回答是不清楚，要自己去找。相比之下，传媒、漫剧工作室更接近他已接触的使用场景，传统制造企业未必有相同用量。

另一类30秒广告产品：客户也会拿真人服务来比价

另一位做微商视频工具的参与者，做的是手机上生成30秒以内的口播或创意广告，包含文案分析、参考视频分析和生成，和前面的整部漫剧是不同产品。他说一条30秒视频成本约7元；另一人转述，徒弟从其他渠道拿到的报价可能只有3至4元。两笔报价没对齐画质、规格和渠道，是他们继续找货时的比较线索。

现场还提到，有人养主播，真人代拍、剪辑和文案一起约10元一条。做自动化视频产品，面对的替代选择可能也包括这种真人服务，而不只是另一款生成模型。

一位尝试本地跑视频模型的人说，生成5秒要二三十分钟。自部署不付接口费，仍有电费和运行耗时；是否接第三方接口，要连生成速度和用量一起看。

26. 算力利润的两个点，不能只看流水

有人觉得转售可以加价20%，三麦回应，走量业务常常只剩两三个点。按每月一百万元、两个点粗算，就是两万元，还得继续考虑自己的服务成本和税费。

他提到，一些北上广客户月用三四百万元，愿为更好的货和更高并发付钱；中小企业可能会选更便宜的DeepSeek。重点不是“有电脑的企业都是客户”，而是问清用途、真实用量、规格和预算。

某单他线下谈了三个月，后来签一年，双方磨合顺了以后，也不愿轻易换供应商。渠道关系、合作成本甚至灰色利益，都可能影响采购，不是只便宜一个点就一定拿到订单。

发票税率不要直接从利润里减

现场有人把两个点利润直接减去六个点票税，算出亏四个点，引发反驳。大家随后混着谈进项、销项和不同税费，说明这笔账必须放回主体和实际交易里核。

对经营者来说，先把进货、出货、票据、结算和实际税费理清，再判断还能剩多少，远比只看一个折扣数字重要。

27. 青岛创业者：有企业名单，还没形成付费客户

青岛一位参与者手里有企业名录，也认识一些老板，想做培训、行业定制和token供应。公司现金流不算宽裕，正考虑招销售，但自己对模型和技术还不熟。

别人先问他，究竟准备靠什么赚钱。不会写代码可以找技术方合作，但得说清服务对象、需求和交付标准。招人以后还有工资、社保等成本，自己如果判断不了技术人员能力，也会很被动。他最在意的，则是找到稳定、能长期做口碑的技术伙伴。

名单里能联系到一个人，与这个人能拍板、确实有需求，又是几件不同的事。青岛参与者也承认，熟悉的老板当前AI用量并不大，还需要继续开发。

线上、扫楼和县城标品，没有一条被证明通吃

上海另一位参与者计划招一人扫楼、准备传单，另有剪辑和美工做线上。他的线下还没开始，线上一直在做，觉得纯自然流难，需要广告。

县城听众问，没有写字楼怎么办。有人建议到市里、工厂，也有人建议先卖AI短视频等更容易解释的标品；还有人不看好餐饮作为自己的目标客户。三麦则说，自己通过账号和直播面对全国客户，不依赖所在城市。

这些路径对应不同人手和产品，也有不同的目标客户。三麦也会给个人用户免费体验某款DeepSeek模型，以此引流。先把一个真实需求成交，再判断下一步扩什么，比先想全国铺开更具体。

28. GEO代理：报价之外，先说清客户买什么效果

青岛参与者还考虑做GEO，服务报价一年1.5万元，给代理约一半利润，自己的进货成本七八千元，再向客户卖一万多。他担心的不是单纯技术实现，而是本地市场到底认不认可。

GEO在这里指让企业、品牌更容易出现在AI搜索回答里。一方认为，它仍离不开内容和外链，之前关于“AI投毒”的曝光又让业务更难卖；另一方则说，既然有人用豆包搜企业和产品，就确实存在被找到的需求。

出现一次，和长期达到要求，不能混为一谈

客户可能会问：哪个关键词、问什么问题、出现多少次、维持多久？有人会签具体上榜要求，三个月做不到就掉信任；也有人做长期内容维护，客户没有同样的排名验收。

还有人强调长尾词和组合问题，而不是只盯一个词。曝光、表单、咨询和利润，也应分开看。客户的验收要求不同，服务商要逐单讲清楚。

一项二手车案例

一位参与者讲到，二手车商做SEO已有一两年，每年花十来万元。他听销售说有客户通过豆包找到商家，自己也试过DeepSeek和豆包，多次推荐的三四家里包含这家。

这让他看到，长期内容投入可能成为AI搜索的信源。这个案例接下来还值得跟踪实际咨询和成交，看看搜索曝光能带来多少生意。

百元文章成本，不代表整套服务成本

有人说工具可能一年千元、一个月百元上下，随即有人补充，真实服务还可能涉及企查查、地图、官网等，不只是发文章。

因此报价不能只拿“生成一篇内容花多少钱”来比较。代理方要知道上游究竟交付什么，客户愿意为什么付费，效果怎样约定，以及持续维护需要哪些动作。双方对这门生意的看法不同，但都绕不开这几个实际问题。

29. FDE要进现场：同一行业也不能一套复制到底

谈到企业定制，现场有人强调，要先进入企业看流程，找出能半自动、能自动的节点，再看部门之间如何协同。同一行业的两家企业也会有差别，不能预先做一个万能Agent到处复制。

另一方希望先选垂直行业，尽量形成可重复的产品。两种方向可以继续磨合，但前提都是先知道客户的问题在哪，而不是先把工具卖出去再找用途。

有参与者按每月两单推演年收入，那只是鼓励新人尝试的测算。培训、定制、算力、个人小订单，看似都能接，实际各有不同的技术、人脉和销售要求。先把自己能交付的那一件事跑通，更容易看清后面缺什么。

30. 算力券和OPC支持：拿到的究竟是哪一种资源

后段有人转述杭州、滨江一带算力券的经验：可能要用指定平台，平台价格未必低于自己已有渠道，且有上限、审核和发放条件。和前面讨论的支持比例一样，政策名字相似，不代表使用条件一样。

大家还把券、免息贷款、设备、工位和直接现金分开讨论。有项目、有成果、通过审核，可能才有相应资格。真正做预算时，要弄清支持的是什么、能否用在自己的业务、什么时间能够使用，不能只把宣传中的额度当作手里现金。