2026-10-12 · 第1场直播

企业AI工程、问数与交付报价、航运知识库、铁路检测、珠宝培训、财务提效和内容经营的具体方法与失败经验。

这场讨论围绕AI工程、企业交付与个人经营展开：从需求澄清、代码与文档，到问数、行业工具与客户经营。

1. 把Agent纳入经营实验，先交代资源和人工责任

工具试用量与Skill实验，只能先保留为使用线索

主持人提Muse、GrokBot两工具，主观试用体感不错。一位来宾说Muse十亿token已用近五亿，具体计量口径和产品身份不清。来宾前一晚整理提示词、架构、类似Skill的框架，白天反复测试，认为加Skill后有改善；没有给出完整效果和系统验收结果。国内大厂两个月追平Muse是个人预测，非进度承诺。

把经营范围、预算、资源和授权交给Agent，人工仍处理线下与责任

杨总正在试把公司经营范围、资源、预算和授权提供给个人Agent，要求其定策略、执行、复盘后迭代；Agent主动提示某项进展需要本人出差和线下跟进，否则线上工作没有结果。人仍要决策、担责、关联客户资源，“办公室全部人能替代”仍是他的判断，没有完成裁员的证据。旁人输入多年炒股理念、阈值后让Agent提醒买卖是二手用法，未证收益，尚不构成全自动投资有效的证明。前述Muse、豆子/Dose/GrokBot近音产品身份待确认。

技能快速迭代的体验，不等于某职业已经消失

杨总称自己早期用Coze做公司产品，发豆包获得大几千访问，后来平台智能体下架，仍在Coze；这只是本人转述。又以熟悉Premiere、3D Max、剪映、做过二百多篇视频新闻的经验，判断AI会替代逐帧剪辑、遮罩等工作，甚至称今年八到十月岗位到尾声，属预测。另一人说百炼、千问、DeepSeek、火山等一两周就迭代，旧版要更新，是自己维护负担。曾积极推广豆包的摄影徐导也可能追不上技能变化，讨论价值在以实际结果检验能力，而非只会演示熟悉工具。另一参与者将自己首产品十几天、每天十八小时与第二产品两天相比，未说明项目等复杂度，也不能归成生产率倍数，次日见CTO的说法后来纠正为见CEO汇报，不当应聘事实。

2. 十万元基金系统：最后一成与场景容错

全 AI 敏捷开发的“尾部陷阱”：前 90% 只要几天，最后 10% 死磕一个月

资深企业数字化服务操盘手杨总，复盘了去年 6 月带领团队为一家金融机构交付“十万元基金管理系统”的切身经历：

AI 极速开发的高光时刻：团队深度采用当时前沿的前端与全栈 AI 代码生成工具（如 v0.dev 等），仅用了短短几天时间，就极其惊艳地完成了系统约 85% 至 90% 的页面布局、路由框架、交互表单与基础业务逻辑；
最后 10% 吞噬整月工期：然而，当项目进入真实的业务深水区时，最后的 10% 却让团队整整折腾了近一个月：
金融场景中严苛的边缘状态处理（如多币种清算截断、特定权限下的不可逆审核流、并发修改冲突）；
大模型在长流程中偶发的细微逻辑幻觉，使得生成代码在某些特定参数下频频产生隐蔽 Bug，导致团队陷入反复推倒重来与代码审查的漫长泥潭；
工程启示：AI 可以在第一阶段大幅缩短原型开发周期，但绝不等于工程尾部交付成本为零。越是严肃场景，边缘边界与异常处理越需要资深人类工程师的强工程兜底。

幻觉治理的工程经济学：定义场景容错，拒绝空谈“百分百消除”

杨总结合基金管理系统的实战教训，提出了对大模型“幻觉问题”的工程化思考：

盲目追求 100% 消除幻觉在经济上是不可行的：大模型的底层基于概率分布采样，理论上无法通过简单的 Prompt 调优做到数学级绝对精确。如果一个团队为了追求 100% 零幻觉而无限增加校验链条与模型轮询，由此引发的延迟与算力成本将彻底摧毁商业可行性；
按场景严格划分容错等级（Fault Tolerance Hierarchy）：真正的企业级架构应当根据业务场景的破坏性后果，定义明确的容错边界：
零容错区（硬编码熔断）：涉及基金申购赎回计算、资金划拨、交易权限审计等核心环节，绝不允许大模型自由发挥，必须交由确定性的后端业务规则引擎与数学公式执行；
高容错区（大模型主导）：对于研报核心观点提炼、同业竞品舆情摘要、多维市场信息初筛等辅助展示环节，允许在一定置信度区间内由模型自主生成，并明确提示业务人员做终审把关。

落地自查与实操演练建议：AI 敏捷开发尾部风控与幻觉分级 Checklist

工期预估“二八黄金法则”：
在使用全 AI 编程工具承接外包或自研项目时，切忌按“首版 Demo 耗时”线性推导交付时间；必须将总工期的 50%–60% 预留给最后的联调测试、数据边界与异常状态排障；
核心业务“三层容错矩阵”落地：
在系统架构设计之初，梳理业务字段清单：标注哪些属于“强确定性写操作（必须规则校验）”，哪些属于“宽容性只读展示（允许模型润色）”，杜绝将核心资金链条交给大模型裸跑。

3. 博思AI：从多模型辩论需求起步

杨总博思AI从多模型辩论的单点需求开始

随后受邀分享的嘉宾被介绍为杨思毅/思怡，前蚂蚁数据中台人员、博思AI与思维编译器相关创始CTO。姓名近音与“数据小天瑞士认证”等称谓不清，无外部履历认证；开源MetaStor及第一代/五代架构口述，其官方项目史仍待核实。他自述十几年写代码，三月才开始用AI，一个原本人工两小时的JSON银行卡消费报文解析任务，AI不到五分钟完成结构化，带来震撼；

博思AI需求来自身边人每次要分别问千问、豆包、DeepSeek，得到不同回答。于是做聚合平台让多个模型辩论，保留短期与长期记忆、不同角度结论，给用户共识和差异自行判断。“最中性”是产品目标，不是多个模型共识就可靠的证明。开始只做Spring Boot工程与模型适配SPI，不先上动态扩容、复杂CI/CD、全套架构；新增需求出现后再改造。初版同样出现一两百行一个方法，不是用了AI就自动高质量。

从参数膨胀发现领域模型，把重构约束写进Prompt

嘉宾举前后端传参从两三个增加到五六七八个，可抽成通用model/DTO。AI不会主动替你选择业务边界，要明确它哪些模块可复用、哪些必须分开。他习惯每步多想一点：对象会不会成为大对象、并发下选何种map、回收和内存怎么处理，再把这些约束写成Prompt，要求一边实现需求一边重构。其中GVM、corporate hashmap等为近音未确认的技术词；重要的是指出资源/线程安全约束，而不是机械套某容器。

多Agent按模块做抽象与整合，策略、工厂、观察者等只是可选模式，不是必须每种都加。他自述以前一次大升级连测试、灰度上线约一个月，如今一晚约两小时，14天时间线上有七百多或九百用例全绿，数字本身不定；未独立核仓库和测试范围，不能当普遍倍数或生产正确性认证。LLM适配模块可从博思AI单独抽为可部署通用模块，以异构数据源中间件经验设计，不表示自己训练基础模型，他明确模型调参没做。

4. 工程路径：需求边界、选型与业务编排

工程可实施路径：需求理解、边界与技术选型分别沉淀

嘉宾将可复用路径分需求理解、需求边界、技术架构。架构清单包括Spring Boot应用、结构化/非结构化/元数据存哪、一级二级缓存怎么取存、高可用、压测、多实例部署。产品经理可更懂需求，不必先掌握每种存储的全部底层调参，但要知道组件解决什么问题；Redis、OSS、MySQL以及向量库被举作用。Milvus又被口述或识别为Mistral，原词不稳定，不能把向量数据库等同完整知识图谱数据库或据此编API教程。文件图片视频、关系数据、语义检索是不同用途，应依业务确认。

他说推广时日活五百到七百、累计百万使用，自己烧钱，现在未续费推广且在线人少，这是使用与投入自述，不是付费客户或盈利。他提到主页的Git入口和46分钟通俗讲解，仓库地址与许可待确认。

理解框架解决的问题，才决定能否按业务改写

嘉宾说在自己的有向无环图、longchings/long graph等近音框架中重写了部分逻辑，但没有仓库或实现可核，不能直接认证LangChain/LangGraph版本。Harness、loop、context、prompt被看作编排、workflow或状态流转的框架，需与业务结合，而非知道名称就能照搬。并行计算参考Hadoop和Storm的批流思路，多worker进程、容器CPU内存和core资源；线程不是无限起，过多上下文切换会拖垮负载。ResourceManager HA、双活再加Agent控制只是探索假设，不是成熟容灾方案。

5. 把决策和Bug复盘固化为可接手的工程资产

将每次决策和Bug复盘写进Docs与Skill，才有可接手的AI工程

从0到1后，生产化不只看可运行：单测、用例、用户动线、每个决策时间点、每个Bug复盘都要留。嘉宾要求AI出Bug后复盘，把方法沉为Skill；仓库留部署、架构、决策、重构、CI/CD、演进时间线、流程图、数据字典、为什么某节点抽象等文档。当前一个人OPC更需要这些，否则以后加入的同事不知道怎么改，甚至不知道该怎样用自然语言向AI提问。文档不是把AI聊天全存下来，而是能解释需求与改动原因的上下文。

让AI扫哪些重复模块可合并，仅提供候选；是否合并由业务理解决定。已有良好抽象后新需求是扩展，而非每次先堆屎山再大重构。压力约千并发时服务器有限，他会追问“是否还有更好方案、假设出现另一情形还成立吗”，不只是从模型给的ABCD选一个。

第二产品两天做到“半生产级”，后续见的是CEO

嘉宾把前套可实施路径用于第二产品，先覆盖幂等、组件降级、异步消息、全盘故障监控告警、熔断与切换等场景，再将容器配置、日志链路、灰度、数据备份、安全权限留为模板。他称两天串起流程与功能、全局高可用扩展设计，但主动限定只能算半自动化或半生产级，这与两天交付已验收的生产系统仍有距离。相比第一产品约一个月，是自述且任务范围未统一。前面说次日面试CTO，后文纠正为先见CEO汇报；最终并无CTO应聘成果的确认。

金融核心全球支付链路即便全测绿仍不能轻率上线，是他提出的风险边界；99.999和“三个九”混用且明确假设，不采用精确SLA。配置态或外围代码与核心运行交易代码需区别，不表示所有CRUD都无风险。Muse“已上线支付”只是别人评论触发他回应，不是产品官方事实。

前后端的竞争力不只在语法，而在可验证用户与系统结果

嘉宾不赞同“前端已死”：Node.js、JSX、React等是实现方式，价值还在产品审美、体感、流程串接与后端数据结构理解。例如页面从三秒变零点五秒是可衡量优化目标，文中并没展示这次已做到。懂业务如何在接口与用户动线间流转，比仅为学某技能而学更有迁移性。其认为工程基础有价值，与前人“剪辑岗位消失”预测是不同人的观点，不压成一致结论。

6. AICP旁路控制面：错误记忆、审计与token成本

终端命令失控的避坑重构：AICP 旁路控制面（堡垒机架构）

技术操盘手郭总在利用开源底座（如 DeepSeek 配合开源 Harness 编排框架）执行设备调试与后端轻量开发时，深刻体会到底层小模型在复杂系统交互中的脆弱性：

致命执行事故频发：小模型在输出系统级命令时，极易因路径反斜杠漏写、Linux 提权参数拼错、目标服务器端口或库名混淆，造成意外删除、服务宕机或安全审计违规；
自研 AICP（AI Control Plane）控制面：团队没有盲目去微调或重训底座模型，而是在大模型与受控服务器之间架构了一层独立旁路控制面（AICP，类似运维堡垒机机制）：
命令拦截与合规沙箱：所有由 Agent 生成的 Shell 命令和数据库查询，必须经由 AICP 的语法树解析与危险指令黑名单（如 rm -rf、带通配符的表级操作）扫描，直接拦截越界高危动作；
错误记忆与自进化熔断（Error Memory）：将每次真实运行中报错的上下文（输入指令、报错堆栈、失败原因）格式化写入 SQLite/向量数据库。当 Agent 下次生成相似指令时，控制面前置比对错误记忆库，一旦命中已知错误模式，强制拦截并在 Prompt 中即时注入反向避坑提示，形成无需重训模型的“经验自进化闭环”；
权限审计与全链路可回溯：对每一步 Agent 调用的输入、输出、耗时和受影响资产做结构化存盘，满足企业生产网合规要求。

降本的核心抓手：三层漏斗与高频缓存拦截

讨论中对比了企业级 Agent 在面对多轮调用与多子 Agent 编排时的真实 Token 账单：

庞大 Prompt 膨胀的成本危机：随着子 Agent 数量增多，每个任务都要携带巨幅系统设定、历史对话与工具定义，单次执行消耗数万 Token，算力账单急速上升；
博思 AI 的三层漏斗实战范式：杨总分享了其在企业服务中沉淀的成熟降本漏斗：
第一层（精确/分词检索拦截）：针对企业常见的高频重复问题，直接通过本地分词库或精确键值比对匹配标准答案，命中直接返回，完全不调用大模型（0 算力成本）；
第二层（向量相似度检索）：未命中精确库时，通过轻量向量库检索经过验证的高质量问答对，相似度高于阈值直接复用历史结果；
第三层（大模型兜底推理）：只有前两层均未命中的未知长尾问题，才路由给后端大模型进行深度思考与推理；通过该三层漏斗，在保证服务质量的同时极大压低了 Token 消耗与推理延迟。

落地实操演练建议：终端 Agent 旁路控制面设计规范

指令白名单与参数化模板强制约束：
严禁允许 Agent 裸执行任意拼接的字符串命令；必须将合法运维/业务动作固化为带参数的函数接口（如 restart_service(service_name)），由控制面做严格的枚举白名单校验；
错误自检三步法（Error-Handling Loop）：
编写一段轻量拦截中间件：在命令发出前，检索当月历史错误库；若存在完全相同的命令模式且未做参数变更，直接向 Agent 返回“该模式在某月某日导致过某异常，请重新调整逻辑”，避免重复踩坑。

7. 陌生旧系统排障：沿输入输出补齐业务链

一位原七八人排班团队问老系统不稳、OOM、模块不熟怎么快速定位。杨总回应自己在浦发项目只剩需求人员时，先看报错cause by找类，再跟需求方确认该行之前做了什么、上游返回什么、每个方法对象输入输出什么，每次事故串好链。缺error日志时从现有info逐步往下加日志，第一次费劲但要留记录；即使猜接口猜中，次日复盘也要说明为什么，不能长期靠时间点捞个关键词猜。约一月把业务逻辑串通是本人历史经验。

业务稳定后如有大变更，可与产品/甲方讨论另起新系统，通过灰度引流、数据割接替换；这是建议，不是已经执行的迁移。提问者说现在截图交AI可语义关联定位，比以前快，嘉宾将深度思考比多人辩论。与“看模型思考”相比，可保留价值是证据和业务链的复盘。

8. 未上市IDE：先还原需求，再编程和人工发布

另一位二十多年开发者的IDE：自然语言与草图先还原需求

新来开发者说自己的IDE/Agent尚未完工未上市，正在最后外观包装，称三四个月前已申请专利但未核受理或授权，没有确认专利已获授权。他面向不懂技术的老板或业务经理：口语甚至方言先识别、拼出其认为约80%意思，再重构需求规格，自评审完善，有疑问问用户；业务逻辑→数据库设计→页面，也能文字加草图反推需求与库结构。需求说明、数据库、界面、功能细节、设计说明齐后评分过再自动编程，测试改Bug、打包，最后人工确认发布。普通用户可反馈看得见的外观，专业用户可提架构建议。他的目标是有半自动和全自动两套体系，质量、迭代与token成本才是难点。

IDE差异定位与套壳商业：保密内网需求不等于所有推理已内网

开发者主张只做Java和C++、驱动、嵌入式、算法和跨硬件环境测试，认为与大厂通用语言Agent不同。一个人加AI的团队规模、专利时间、产品领先都是其自述，没独立测试。他愿付费定制功能、给客户品牌套壳，但不影响自己的独立上市；谈判价未给，不能当已售授权。有人问与WorkBuddy、Zcode、Codex、CC、DeepSeek Harness (DSH)等区别，他承认不少竞品没用，只用Claude Code和Cursor。

面向ToG/ToB有开发需求者，提出保密场景在内网使用；但被追问模型时又说可用开源模型，也可访问国内公网大模型。不能把本地Agent误写成底层推理数据不出网的保证。源码可深度定制、开源二开也可能有版权安全问题，均需核具体许可。未具名“DeepSeek DSH”与自称开源的另一开发者都是线索，尚无可确认的GitHub地址。

自研、二开、兴趣与商业机会，是四个不同问题

争论中有人认为Agent红海不如开源二开、该教育市场；开发者认为不同价位酒店仍有生存空间，主持人肯定个人兴趣开源或探索，不保证商业成功。二开钉钉的客户单、武汉想做比飞书更好IM、万人甚至十万人群是转述例子和目标，不是现成百万并发数据。关于OpenAI七百多数学成果没人研究是未证新闻，不作技术事实。能保留的判断方法是区分是否满足具体客户、自研必要性、许可与安全，以及是否有销售/交付能力，而不是“大厂有了任何小团队都不能做”或“只要敢做就会赢”。

9. 既有客户问数：接数据库只是第一步

大白的既有客户问数项目：困难不只是接一根AI接口

大白自述两月没上麦，走访约二十家旅游、地产、生产等中型企业，普遍AI尝鲜后低频，是其样本感受，不是总体统计。他认为编程、设计、视频短漫剧提效明显，提十二兆类似PS工具能做90%场景、朋友海外漫剧平台一天几部抽卡少，均未具名验证；品牌包装设计后的打样、生产仍在线下。WorkBuddy、豆包工作、千问工作、Codex、Claude是观察到的工具。

自己主要围绕过去进销存和供应链客户做AI统计分析，以前客户每要统计就加代码加公式，成本高。现尝试MySQL、SQL Server自有数据库，自建MCP接自建Agent，处理格式匹配、清洗；还有本地/云文件、第三方系统与电商接口，满意度仍不高。另一人也说做一年多集中清洗准确率，不能混成大白团队投入年限。正常字段匹配查询可做，复杂跨表、跨库、时效数据更难；未给经过验证的统一准确率。

问数的客户不是都能自己开发，要限定原有系统与实施范围

有原BI从业者主要接银行、保险、电信，认为此类客户已有IT团队，问数技术没多大门槛，项目本质常是现场外包或人力。大白回应自己做地方民营既有客户：过去已买其定制ERP/供应链软件，熟悉系统后再加AI升级，不主张一开始陌生客户就上整套AI。各地年销两三亿、十来亿企业缺IT能力、海南百家难有一家IT等是其走访自述。另一位坦承此前经验偏大金融通信，所说民营保险数据多系统分散还是十五年前案例，不能当今天现状。

聚水潭例子提示：不会用、不了解与主动不买，要分别验证

大白说见天猫、京东、拼多多多店仍各开浏览器人工统计，企业甚至不知道聚水潭类订单中台，ToB销售仍用Excel；买过的少数企业月末季末统一订单和业务统计很方便。另一人提醒统一账号可能触发平台关联处罚，但大白明确不熟悉不作结论。数字化工具可以买到不代表团队会操作；另有人正做FDE客户买SaaS仍靠Excel结合，未披露该项目具体成果。是否省钱、没听过、不会部署或担心账号，是不同原因。

10. MES说明书、源码图谱与RAG如何配合

工业存量系统之痛：文档遗失、千表复杂性与单纯 RAG 的死胡同

在传统重工业制造企业推行智能问数与 AI 助手时，技术团队普遍面临存量 MES/ERP 系统的致命泥潭：

十年老系统的文档断层：经过多代外包与老员工更替，企业存量 MES 系统中上千个页面和业务表根本没有最新的说明书，连内部一线调度员都不清楚某些冷门统计报表背后的复杂计算公式；
单纯 RAG 的致命盲区：如果仅仅把零碎的 PDF 操作手册塞进向量知识库做简单 RAG，大模型只能回答单页面的字面定义，根本无法理解“页面 A 输入工单 $\to$ 触发后台存储过程 B $\to$ 锁定物料批次表 C”这一深层数据调用链，导致在生成 SQL 或业务解释时频频产生致命幻觉。

源码逆向工程：从业务代码抽取 Markdown 手册与“源码知识图谱”

一位资深制造业数字化开发者分享了一套行之有效的破解架构：

源码反向生成页面说明书：编写脚本扫描 MES 系统的前端代码与控制器，提取每个路由页面的输入表单、查询参数、校验规则与业务流转说明，批量生成标准化的 Markdown 格式用户手册，系统性补齐企业知识短板；
构建“页面—实体—存储过程—字段”源码知识图谱：深入分析后端数据访问层（DAL）与数据库，抽取每张页面关联的物理数据表、外键依赖、调用的复杂存储过程以及最终允许对外呈现的字段，构建起系统级的源码知识图谱；
两阶段精准路由与字段白名单防线：
当用户提出自然语言取数需求时，系统首先利用知识图谱将问题精准映射到对应的业务模块与功能页面；
提取该页面严格绑定的字段白名单（Field Whitelist），只允许大模型在该白名单限定的物理列名与关联关系内组装 SQL，坚决杜绝大模型在千表环境中无端外键拼接；
安全隔离铁律：只读从库与写操作硬隔离：智能问数底座必须严格接入企业的只读只分析数据库从库账号，严禁赋予任何生产主库的写权限；对于涉及修改生产排程或工单状态的操作，必须通过标准 API 走人工审批流，彻底杜绝数据污染隐患。

落地实操演练建议：传统工业系统源码图谱构建三步法

扫描控制器逆向提取路由与参数字典：
编写 Python 脚本解析存量 Web 项目的 Controller/API 路由注解，提取出所有对外接口的输入参数、返回结构体与核心业务说明，导出为 JSON 规范清单；
建立表级与字段级语义映射字典：
为高频涉及的核心生产表（如物料表、批次表、质检结果表）编写别名与业务口径对照表，将冷门英文缩写与一线业务行话做双向对齐；
部署 Dify 工作流双轨分流：
在 Dify 等编排平台上构建问答分支：规则与制度咨询走非结构化文档知识库，数据查询走结构化图谱路由与参数化 SQL 模板，实现清晰的架构隔离。

11. 老板问数的需求与三层误差，要同时保留

问数三个风险与支持方回应，保留完整分歧

反对者指出老板问题漂移、需来回确认会不耐烦；语义层与LLM有幻觉；底层MES/WMS/ERP数据本就可能错，三层叠加后体验差，最终仍开会问现场。他说除了汽车行业几乎全不准是泛化判断，没有数据。支持方说自己已演示给中型客户，他们少开电脑、手机电话找财务或经理“帮查数”才是真需求；但复杂跨库跨表准确率仍低。

票券发行五十万张后查核销/未核销、区域门店和销售团队排名、指标、库存周转与调库是举例，不是本项目真实处理量或准确率。临时问数可帮助老板估资金和预备金，准确财务经营结论仍需部门会议；支持方也对软件真实价值和市场机会打问号。他又把图片视频软件市场说成大厂已全部占完、问数唯一机会，这是主观立场，与前述鼓励垂直自研的分歧并存。

自动汇报PPT随领导指标变化失效，是组织需求风险

一位曾在电动重卡企业的人说公司自动做汇报PPT的功能因一年后换领导、岗位指标变而全废；他明确从立项就反对，不是他接的订单。别人认为通用PPT大厂更强，应找企业差异化功能，但不能写成所有PPT定制都无价值。案例提示要区分现有报表持续使用和单一汇报偏好变化，不能因AI能做就把长期维护需求假设固定。

12. 农业投料和排程：先核现场闭环与数字化条件

农业数字化的使用能力，与饲料投料验证缺口是两人的经验

大白说自己另一团队做十年农产品电商，想给农业企业做商城、供应链数字化或物联网，却发现不少亲属式团队没有人会操作；其概括“不具备能力、资金和团队”不能推广全国。另一位自称双胞胎集团前自动化总监，用饲料投料反驳“大企业已经做到极限”：中控员对讲机通知现场投哪种料、哪投料口，现场口头报完，中控代报工，系统不能确认是否真正投料、重量或品类是否正确；投错影响库存、产品和客户投诉。他明确说这里只举需求例子，不知道怎么解决。

对方追问历史错误概率、老板重视程度，回应集团大小会都谈。真实问题存在，不等于有预算、有人愿改或能用AI解决；既不能把投料例子写成已部署视觉/称重系统，也不能因企业多年未数字化就判没机会。现场没有就此达成一致。

先问数字化为什么没做，再问AI能否落地

有人用“企业基因”解释数字化意愿，另有农业企业经历者提醒：有钱、有示范工厂不等于业务数据和流程真的通了，很多系统仅用于给领导展示报表。项目诊断应把预算、团队能力、业务目的、数据、模型和实际执行串起来，不能看到“灯塔工厂”就假设数据可直接供AI使用。“基因”只是讨论者的判断框架，不是不可改变的企业属性。

离散制造的排程例子尤其具体：计划要求先生产某件，但现场缺料，工程师便转做别的任务；排程系统如果接不到这种变化，计划就悬空。有人以自己的 Dassault APS 经历批评这类问题，这支持“核实现场约束与反馈”这一检查项，不能推广成所有APS无效，更不能推出每个问题都要AI解决。

13. 问数项目筛选、报价与真实交付毛刺

智能问数客户的筛选铁律：数据健康度比付费意愿更致命

一线走访食品、精密加工与连锁零售企业的技术顾问分享了残酷的获客现实：

付费意愿不等于交付可行性：许多传统老板看到炫酷的“对话问数”演示后兴奋不已、极有付费意愿，但深入其机房才发现其底层数据是一团乱麻——只有老旧简陋的进销存，财务与收银系统各搞一套，历史订单全靠人工手账补录；
防范“一揽子包干陷阱”：初创团队最容易犯的致命错误，是在合同中将“数据清洗、旧系统打通、数据治理与智能问数”混为一谈并给出一个固定的死价格。最终团队会被迫承担数月极其繁重恶心的数据泥潭清洗工作，导致整个项目深度亏损。因此，必须将“数据底座治理是否达标”作为售前立项的一票否决条件。

真实账本复盘：30 万元合同为何最终净利只剩 10%？

一位深耕制造与医疗问数交付的技术负责人，深度复盘了一笔刚完成验收的真实合同账本：

初期的美好预期：合同金额 30 余万元，原计划 5 个月开发完成，扣除基础人力与服务器开销后，预计能保留约 50%（约 15 万元）的高额毛利；
拖延吞噬一切利润的深渊：
数据私有化部署摩擦：客户数据严禁出域，团队被迫派驻人员在客户机房封闭开发，差旅食宿与异地运维成本直线上升；
脏数据带来的语义黑洞：大模型一连数据库就频频翻车，归根结底是历史数据中大量空值、乱码与非标缩写，团队不得不替客户倒贴 2 个月时间重做数据校验清洗；
无休止的新增报表需求：客户各业务部门中途不断追加“顺便把这一类统计也加进来”的非标需求；
最终惨烈回报：工期从 5 个月被迫拉长到 8 至 10 个月，团队人力被死死绑架，扣除全流程综合成本后，最终实际净利润仅剩 10% 至 15%（约 3–4 万元），扣除团队机会成本后在商业上基本等于完全失败。

落地自查清单：企业智能问数项目售前筛选四原则

数据治理成熟度前置评估表：
进场前向客户发出《数据健康自评表》：核心指标是否拥有唯一计算口径？核心业务表是否存在系统性缺失？数据是否拥有规范的数据字典？低于 70 分的项目坚决不做一口价总包；
两阶段分离签约机制：
严格将项目拆分为【一期：存量数据探查与指标治理（咨询与清洗收费）】与【二期：智能问数 Agent 搭建（技术部署收费）】两份独立合同；未通过一期数据验收，绝不盲目开启二期承诺。

14. 外包复制与ERP转包：差价之外的维护和责任

外包的隐性成本是后续产能被锁住

维护旧客户不是没有价值，但如果每次交付都需重建、大量驻场，人员会被旧单占住，无法接下一单。讨论提出两条方向：纵向聚焦一条行业产品线，以少量改动复制；或做足够小、交付边界清楚的AI任务。十家、百家、千家客户边际成本下降，是目标而非已经实现的规模效应。

“新增需求就加钱”只是一种建议，现场没有证明客户都会接受；软件项目外包与人员外包也有不同合同和责任结构，不能一句话判定都不可做。

ERP转包的差价，不会自动消除主承包责任

有人设想二百万项目交给别人一百五十万，留下五十万；其他参与者提醒，合同可能禁止转包，客户追责仍找主承包商，承接方也可能退出。另一个实际ERP实施故事口述总盘“五百个”、实施分到八十多到一百多个，单位没有澄清，不能自动写成百万元。

三方链条是产品总部、客户与现场实施人员。现场报告问题，总部认为实施人员没理解，又让其重做，返工与沟通延迟把短工期拉长。这个故事支持提前写清问题判定权、产品缺陷与实施责任、客户变更流程，而不是证明转包一定有暴利。

15. 酒店评价表达工具：小需求、渠道承诺和竞品

大白从酒店运营朋友收到的需求，是让离店客人写飞猪、携程、同程评价时表达更完整。他口述两小时用 WorkBuddy 做了一个网页工具，朋友给了相当于“一个月加油钱”的红包，没有明确金额。对方说能帮推几十、上百套，是渠道承诺，不是已经卖出这些数量；小程序、App也未因此完成。

适用边界应是帮助真实客人表达真实经历，不能把它变成伪造消费评价。后续有人说用过有赞类似产品，9.9元起初不限量，三个月后改为100条；这是个人历史使用口述，不是当前官方价。发现竞品应回到自己的用户入口、实际操作便利与渠道，而不是仅因“已有工具”就否定需求。

16. 航运工作台：从纸面经验到关联业务数据库

航运重资产知识的结构化闭环：300天打磨20个岗位关联数据库

一位深耕国际远洋航运业数十年的高管，在离职后历时 300 多天，亲手用 AI 模拟并重构了近 20 个航运关键岗位（包括租船经纪、海务调度、机务工程、法务风控、航次财务等）的端到端工作流：

拒绝“孤立问答”假象：通用大模型根本无法回答航运业的真实商业问题（例如“国际低硫燃油每吨上涨 50 美元，对我司当前船队有何影响？”）。因为答案不仅取决于油价，更取决于每艘船签署的具体租船合同条款（如长达 60 多页的 NYPE 纽约土产交易所期租合同标准范本中关于油耗补差的约定）、当前航线港口加油价格、装载吃水与经济航速等动态上下文；
构建全关联多维数据库：管理者将航运领域海量的纸面规范、判例合同与船舶参数迁移至 Notion/知识库中，自建了跨领域与子领域的关联图谱（合同条款 $\leftrightarrow$ 法律风险 $\leftrightarrow$ 海事工程 SOP $\leftrightarrow$ 实时船位调度）。当一份真实合同上传后，Agent 能够自动提取所有核心权责并关联沿途港口气象与补给建议，彻底打破传统部门间的信息孤岛。

船舶安全配载的人机协同：AI 提方案、老船长把关签字

在极其严肃的船舶装载配载（Stowage Plan）环节，团队确立了严谨的人机分工边界：

多约束计算交由 Agent 初排：将货品清单 Excel、集装箱重量分布、货舱尺寸结构、甲板局部受力强度限值等繁琐参数投喂给系统，由 Agent 快速生成多套符合船舶初稳性与剪切力平衡的初步配载建议；
安全底线始终由持证船长守住：模型生成的方案绝非最终执行令，必须由资深持证老船长亲自复核审查、比对偏差并手动调校签字确认。这种人机协同将原本繁重的试算耗时缩减数倍，但在生死攸关的安全决策上坚决守住人类专业责任底线。

复杂业务极速新人赋能：大专英语小白接手专业海运流转

该系统展现出最具商业价值的人效突破：

航运传统岗位通常需要重点海事院校本科以上、且具备流利专业英语与数年经验的高薪人才；
管理者找来一位大专毕业、完全不懂航运专业英语的新人，让其在全套关联系统与 Agent 导航下开展日常跟单、船岸沟通与标准流程复核。系统自动将晦涩的英文海事电报翻译并关联对应 SOP，不仅使新人能够在短时间内独立上手复杂业务，更证明了“将顶层专家经验固化为知识系统”才是对抗员工流动与人才昂贵的最强护城河。

落地演练抓手：重资产行业全关联知识库搭建三步法

核心合同与标准范式结构化拆解：
选取行业最通用的长篇标准合同（如航运 NYPE、工程 FIDIC），拆解出关键权利义务与抗辩责任要点，录入向量库并打上规范的元数据标签；
构建“资产—任务—规则”三维关联表：
在协同平台（Notion/Feishu/轻代码）中建立三张核心表：物理设备资产表（船舶/产线）、动态业务任务表（航次/工单）、外部环境参数表（油价/天气），设置双向外键关联，使提问天然携带多维上下文。

17. 航运多Agent咨询的二手案例与验证边界

她转述一位做气象导航咨询的同事：将案例放入 Obsidian，用 MiniMax 接四个飞书机器人，收到天气或索赔咨询后让它们按Skill讨论，口述四百次再给结果。没有提供配置、运行日志、成本或准确率。她自己的方式则是先给初步意见、再讨论与折中，并不相同。

四百轮不能推出“没有幻觉”，更不能证明专业法律和航行判断可以无人复核。可复用的是多角色材料组织与反复检查的构想，不是某个轮数的安全保证。

18. 企业AI落地的组织协作与FDE分工

企业AI落地需要授权与协作，不是单纯买模型

讨论者提出有意愿的老板、能协调内部的负责人很关键。员工担心知识被抽走后裁员，老板不愿公开核心数据，都会影响数据获取。有人主张必须得罪人才能推进，主持人要求给实际案例，这不是已证实的组织规律。

是否由一个全能FDE承担所有事情也有分歧。更稳妥的任务划分是识别业务需求、数据授权、现场约束与技术支撑的责任人，不把岗位名当交付能力证明。

商务人员想要的，是需求与技术能力之间的翻译器

一位商务人员希望把Workbot等工具能做什么整理成能力目录，接到客户需求后可拆任务、判断可行性、成本和实施方式。现场认为这类工具可以做，但目录不能取代现场行业经验和特殊约束。

FDE究竟是岗位、部门还是一个OPC包办，有不同看法。成熟厂商的客户关系、品牌和长期服务形成信任，技术能力只是其中一部分。做过十年技术的人反思自己项目停滞，更倾向在既有系统里补一块确实需要的能力，而非每次重建全部系统。浪潮、软通智慧、华胜天成、腾讯企微、金蝶、用友是讨论里的厂商线索，不代表它们为任何特定交付背书。

19. 短剧出海：分发链、投流与生成成本分开算

潘多拉口述最高每天三十万美元投流，是广告支出，不是日收入或利润。其路径涉及真人内容、国内短剧平台、海外TikTok/YouTube分发，万播收益不好，转向海外TikTok/YouTube仍不理想后，自述做了自己的App；未披露该App用户、营收或验收结果，不能把每一步都写成已验证的AI短剧闭环。

字节 Seedance 2.5的720p报价0.33元每秒，和主持人口播八分钟四五元不是同一类成片，不能直接比较为谁便宜。Dola (字节跳动海外AI助理)被说有五条免费视频，也仅是个人口述额度，未核当前规则。海外公司企业账户三个月可用的经历不能推出地区绕过风控的普遍方法；自动注册、退费等操作不保留为教程。对DeepSeek、Claude及本地H3/5090包装的评价属于个人判断，没有同题评测。

20. 未来生态与个人创新：设想、资源和现金流

有人把豆包、飞书、Coze、视频生成、短剧、VR、智能家居串成未来产品想象，提出VR课程、学校新内容、家庭JARVIS等方向。没有官方路线或真实交付，不写成某公司的确定战略。Notion无限层级、飞书三层、用户上亿等口述也不能当现行规格。

讨论中另一种有效动力是持续改善自己的工作、用知识视频让原本不愿表达的人表达。是否需要资本、普通小团队应做创新还是现金流业务有明显分歧：现金流与有限风险是一种选择，已有资源的人探索未来也是一种选择，“没资本不能创新”并非现场共识。

21. 农家乐要的是客流，工具需要明确利益

云庄主口述农家乐经营十八年、年营业额不到一千万元、约二十名员工，是营业额自述，不是利润。其问题是增加顾客，管理工具即使免费也可能闲置。过去转卖朋友圈互动小工具，口述每月十几元或年三百多、卖过几十套，未提供账单；这种使用还涉及平台限制，未形成可靠合规的业务路径。

这个工具最初是他自己发现并购买的：发朋友圈后，总有人立即点赞，引起他的注意；自己用后，朋友来问从哪里买，又带出了转售。把所做业务写进昵称，互动时也会露出业务身份。他觉得秒点赞过于机械，希望能延迟几秒，让互动更自然。

另一个SEO工具“everything”体验是找不到主功能，提醒产品要让用户尽快完成一个具体任务。对员工说AI将裁人，容易得不到合作；把原两三小时工作减到一小时、提升报酬作为共同利益，是讨论建议，未展示效果。万兴视频每分钟五六十元等价格也只是听闻。

22. 银发MV与人生传记：情绪价值、报价和授权

朋友看到退休音乐爱好者有稳定收入，设想用 Suno 与 Seedance 2.5 做自己的MV、留念并向同伴分享，尚未实施；另一个为父亲做的视频获得好评，也不等于付费订单。录音整理口述史、再做书，是有人朋友圈已在做的方向，未披露统一流程和定价。

主持人称面向本地中老年企业家做AI视频传记已跑通，五到十分钟五到十万元。老板喜欢五分钟样片后提出与年轻时偶像的故事，十万元是报价而非已收款；肖像、身份与素材授权不能默认已有。主持人认为这类生意还依赖本地人脉与向上社交能力，可按单承制，后续服务相对少；这是其经营判断，不是所有项目的成本保证。他也表示可提供承制合作，现场没有达成订单。另有媒体经历者举退休人士希望把自己的书法作品逐篇介绍、整理成册，是作品留存与表达的需求线索。

另一个未具名工具线索是Android手机罗盘，用于定方位，口述收费“188”但单位和付费方式不清；“赚了不少钱”只是讲述者印象，没有收入账，也不据此验证风水判断。

23. 低价客服工具的标准化经营自述

曹操口述个微/企微自动回复小工具售价1988、试用99，曾有单日一万多流水。过去大B项目消耗资源，转向低价标准化走量。旧项目“千把几十万”的口述不清，不猜精确金额。

同一业务的前后讨论：2026-10-10的相关讨论；2026-10-15的相关讨论。

24. OPC先验证订单，再承担经营风险

先有工作或小范围副业测试，找到少数真实愿意付钱的人，再考虑公司化；“十人中两人愿买”是举例，不是某产品转化数据。AI减少生产劳动，不会自动替代获客、注册、税务、收款和失败处理能力。家庭负债和最大可承受损失是约束，不能把背债等同能力差，也不能用成功故事鼓励无界加杠杆。

现场关于一人公司与无限责任的说法相互混杂，未论清账户混同和主体类型；此处尚不能据此认定法律责任。更可靠的经营知识是先确认真实付费、资源投入与可承受损失。

25. 知识动画：从熟悉选题做小样

有人观察到少数知识动画账号几条视频就吸引十几二十万粉丝、百万赞，提到VR5、OBS、可优新表情、Opus5.5等近音/明确工具，名称不统一时不猜官方品牌。中国文化迁移、历史故事、“AI万里征程”被具体解释为用动画或视频讲长征过程中发生的故事；活动与平台推流状态仅为当晚口述，未核实时规则。牡丹跨时代叙事也是选题举例，不把“牡丹是国花”等口述当事实。

另有产品演示用轻模型制作动画的个人尝试，觉得未来可替代PPT，这是用途探索，不是所有演示都该取消PPT。可迁移的方法是先选自己有知识积累的题目，做一个小样看实际表达与受众，而非复制样本账号的粉丝数。

26. U盘本地部署脚本：技术已有，市场待验证

年轻自动化从业者把轻量本地AI部署脚本放进U盘，插入后执行命令自动部署，面向个人、小知识库与剪辑等需求，明确不同于“小龙虾U盘”。没有给出模型、硬件、系统、许可证或仓库，不能替他补一个可复现安装SOP；部门五十多人可能需要更大算力是意见，不是容量测试。

他技术较强、营销弱，拟与跨境或视频伙伴合作，别人建议直播、闲鱼和反馈迭代。AI助手教人执行脚本是未来构想；并非Codex已经一键完成。十四亿人口不能直接当有效市场规模，尚无成交证明。

27. 法律文书与云服务代理的独立项目线索

小花介绍面向小企业的混合应用及法律案例知识库，强调理解行业框架与准确描述需求。不能把“提示词不清会出错”扩成所有幻觉都由用户提示导致，也不能与另一位不会编程的律师混成同一作者。

SK介绍国内大云服务采购与续费代理，称价格更便宜，有人表示想联系；没有折扣表、合同或已成交记录，不认证官方身份或节省幅度。

28. 年轻受众与情绪消费：洞察不能代替真实验证

商务参与者从社群昵称、测测、Soul、街猫等观察到情绪陪伴与文化兴趣。街猫付费用户喜欢流浪猫，但现场没有讲平台完整机制，不能自行补成具体硬件商业模式。木制品五元成本卖五百、百万粉丝二十个私域群等是个人或二手自述，没有成交与利润账。

可记录的想法是物理成本不能解释所有购买动机，纪念、文化认同、陪伴与圈层表达也可能形成价值；手机壳、挂件等周边是探索例子。不要把跨标签兴趣简化成只投同品类标签，也不要把伪装玄学大师、承诺改命当方法。对于未成年人、心理健康、文化和野生动物边界，需要谨慎；“零门槛零成本蓝海”并非共识。技术公司有许多点子、最终还是懂行业的技术负责人承接项目，也说明资源和执行条件不能照抄。

29. DJ歌单Agent：用行业经验描述明确需求

夜场朋友提出每周或三天更新歌单，分上中下三套，每套一到一个半小时、十五到二十首；每三首引导一次风格是提议者个人从业习惯，不是全行业标准。新手面对曲库不知如何选和排，资深DJ已有经验；期望给定今天风格便推荐有顺序的歌单。

讲述者懂这个行业，认为可以报好价，实际上才考虑两天，没有合同、开发或试用结果。音频混音、BPM、调性衔接均未披露。

30. 珠宝销冠陪练与美业：采集、训练和交付复制

黄金珠宝水贝生态：智能工牌采录、销冠对练与知识库闭环

深耕深圳水贝与李朗黄金珠宝产业带的操盘手财神，分享了其团队在珠宝连锁门店落地“AI 销冠陪练”的完整业务链路：

线下门店的真实痛点：传统金店员工流动率极高，老销售往往对核心话术秘而不宣，新入职员工培训成本高、开单周期长；
声卡/智能工牌数据采集链路：为门店一线销售配备专业音频采集工牌，在日常真实接待顾客沟通过程中持续录音，经脱敏后回传至总部私有化系统。大模型从中提炼出成单率最高的话术模式、异议处理技巧（如克重金价计算、打折博弈、送礼寓意解答）以及 30 多个垂直子知识库；
模拟客户实战对练与过关考核： Agent 根据提炼的知识库，模拟各种刁钻画像的进店顾客（挑剔型、比价型、预算有限型等）与新人销售进行实时语音多轮对练。系统对新人的倾听度、引导话术、产品知识准确性进行多维自动打分，只有对练考核达标才允许其实际上岗接客。

线下推行的隐性阻力：员工对抗心理与隐私利益博弈

与会行业专家深刻揭示了线下服务业推行 AI 工牌与对练系统时必须跨越的非技术暗坑：

一线老员工的本能抵触：在真实销售谈判中，销售员为了促成大单，常常会使用一些游走在边缘的私密承诺、人情让利或灵活话术。工牌全天候录音会让老销售产生严重的被监视感和不信任感，甚至引发故意遮挡工牌麦克风等软性对抗；
美业/线下服务业的交付人力黑洞：类似项目在向生活美容、美发等非标生活服务业推广时遭遇了严重的规模化瓶颈：美业店员数字化素养普遍偏低，仅仅把 SOP 包装成软件界面根本推不动，必须配备大量驻场服务人员手把手教学，高昂的人力实施成本会迅速吃空软件的毛利。

落地自查清单：线下服务业销冠对练系统的推行阻力防范准则

利益分享机制前置设计：
严禁单向将智能工牌作为考勤与惩罚工具；必须建立激励机制（例如：贡献优质沟通案例被系统采纳录入知识库的员工，享受每月带单提成奖励或荣誉津贴），化被动抵触为主动参与；
合规提示与隐私脱敏红线：
门店必须在显著位置向进店顾客提供《服务沟通录音声明》，音频处理必须在边缘端对顾客姓名、手机号、支付卡号等个人敏感隐私做实时脱敏。

31. 教培咨询销售Agent：成熟话术变成诊断与跟进

另一位做了十多年开发、没有专职销售且主要服务老客户的人，介绍自己刚完成并开始推广的教培Agent。教培本身有咨询式销售流程和培训话术：录音转写后分析咨询过程、打分，再给下一次跟进的话术或微信表达。其回答认可大模型与RPA调度组合，未说明具体架构。

这套方法用行业标准约束模型，而非只堆固定脚本。已完成开发、开始推广不等于已有付费规模；它与财神珠宝系统是不同项目。数字医生分身是另一项待开发方向。

32. 婴儿哭声产品：行业资源之外还缺数据验证

提供者称为母婴产品公司做录音豆/AI工牌模型衍生产品：采集不同哭声，父母纠正对错，训练模型，接类似天猫精灵硬件辅助理解饥饿或不舒服。说需要育儿专家、儿科医生、数字医生分身及互联网医院合作；客户本身有专家资源。主持人反复质疑哭声训练数据、情绪标签来源，提供者也承认数据难且贵、细情绪判断不了。没有数据规模、验证准确率或临床结果。宠物叫声只是未来可迁移想法，明确暂未做。另一位说朋友想长期记录婴儿睡姿、提醒父母以免头型睡偏，仅朋友想法，无项目落地或医学结论。

33. 银行ERP员工的AI成长、插件与个人知识库

十四自述电商专业毕业，自学前端Java；2024末接触低代码Agent，2025试AIGC一两个月后因设计与提示词要求放弃，暑期进用友金融做银行内网ERP维护/测试，后因AI知识成为培训组组长、转正并两次谈薪，口述“薪资翻了一半”不能改成翻倍。公司一个月日常AI开发自述每天2–3亿tokens，无账单核验；成本催生中转代充。其赚“小二十万”“十五个左右”口径及周期不清，不能造利润账。仍在职并办公司、补财税法务知识。

银行内网许多操作不能直接让AI做，他做了DSH插件，称昨天下班后第一版改完；直接说DeepSeek Harness，口述开源及DeepSeek V4.1 Flash未经仓库版本核验。仿WorkBuddy专家团队，售前、需求、研发、实施、测试、运维角色技能集成，入口对话分派子Agent；领导知道并支持，业务知识将来由公司给，不是全公司知识已完成接入或系统已全员验证。他认为ERP实施往往比开发重要，把行业业务知识加入工具更重要。

个人已用Codex每天定时总结工作写Obsidian，近700文档、上百万字为估算，含项目问题和解决过程及旅行信息，再集成DSH技能库。记忆能否完整召回未经验证。他已用DOT（口头拼为D-O-T）在云端分析流量、蒸馏博主，反馈额度消耗很快；另外准备做视频推广，环境刚搭好，计划充值后测试能否带来流量。成都大会和济南/成都线下活动是计划。200美元GPT Pro一天用掉周额度是个人经历，不是产品统一配额说明。模型近音版本及代理直签关系均保留待核，不将规避账号限制写教程。

34. 直播蒸馏：从项目索引走向可复用知识

直播蒸馏有三个不同层次：索引、知识与二创

CCC用Codex和WorkBuddy蒸馏直播，已测试四五天，目前只抓什么人做什么项目的大概，尚未调好精确提示词，想对照主持人版本检验准确度；同时跑本场及另两门课程，扩到更多直播间还在准确性测试。小故事、音频二创是下一步设想，未称有商业结果。主持人欢迎自用蒸馏、二创，转发其他平台要求注明（具体授权措辞未清），不能扩成无条件商业版权授权；主持人的整理在知识星球“AI情报站”。

多直播监控：已运行三路与二十路扩展猜想要分开

CCC称AI帮装插件采集录音、自动报告，已一个号监控三场/课程，自己也不懂具体底层；它究竟用API还是浏览器/录音源没有说明。另一人猜音频分段→转文字→整理，类滚动日志，并建议多进程、多机/工控机、声卡采集卡扩输入支持20路；这些硬件方案未实际搭建、200路会受性能限制，不是已验证架构。询问“巨量引擎官方API”的人最后说网上没搜到，不能把它写已可用官方接口。可先找现成工具省研发，口述微信订阅号“袋鼠弟”开源蒸馏工具待核，无仓库名。打字速度/准确表达需求影响与模型交互效率是小经验。

35. 家乡动画地图：先做可体验的能力样品

CCC受动态《清明上河图》小游戏启发，试做家乡1–2公里商业区，小角色可移动、辨认街景，先把熟悉区域做成可体验样品，再投本地美食群等，以“这是我家乡”的好奇感引流到个人AI服务IP。当前已试约一周但未成熟，准备完善后发抖音，并非已获文旅局订单。商业区/学校/老城区分片做，之后可组合；文旅合作、NPC任务、虚拟迷宫解题都只是衍生建议。大学生拿数千万美元故事是转述未核，不能做融资案例事实。

制作方法：把想法先与Codex多轮谈到符合实际，再看成品逐点改；不必先装Skills/Agent，卡住可把链接/需求交WorkBuddy再改。先做小范围，不等素材所有齐备。另一人展示过内部ERP桌面宠物狗引导员工问功能，与3D城市地图是不同案例。

36. 工厂虚拟参观：先定义展示精度与素材输入

外贸参与者想给外国客户看厂区/样板间概况，不要求管道划痕、车流等极细节。建议拍主要通道，照片汇入PPT/PDF，配位置草图、每区关键词，让AI先建出可修改版本，再补真实照片。百度地图3D截图让Codex或CC复现仅适合有相应图的区域，不能默认为百度拥有厂区内部。另一人提无人机拍摄/360照片→付费软件高斯渲染→模型→Codex接交互，软件名忘记、没给可复现全流程；学校模型上官网也是转述。

被推荐的3D工具口述band/bander，明确拼字B A N D E R，称可开源、接图片/自然语言做3D并消耗较多额度（“20G”意义不明）。不能直接纠正成Blender或挂仓库。推荐者曾做AI游戏，但不常用。Google地图及高德高精地图/API是不同建议，精细度和授权成本未验证；Glock/Cetins2.5等30秒不到10元也是旁听报价，不能确认模型名或固定成本。

37. 中转站转ToC：流量、分成与完整服务的成本

新的中转站经营者自述原有5名技术每月采购3–5万元，自用后被科技企业预付款推动经营，合同固定了资源池、开票及供给义务，资产越来越重、利润薄；并非缺B端回款。他想转ToC摊成本，称0.5–1折，国内可开票、国外某些算力不能，119模型、集群/K8S三四台、低延迟均是供方自述，不是实测。执照、合同、实名、备案也不能推导所有转供合法。其“不保存信息”后又承认硬做可取得，不能认证隐私零风险。

建议包括代理/达人推广、自有流量池、行业客户端，但有人认为只是套UI无获客价值。关键区分：普通充值前台他已有（NewAPI），能解决行业问题且有用户的客户端他没有。另一人提出自己做行业工具接他的网关，若直接官方没有分成，就需要合理利益分配；30%/10%仅谈判假设，供方说需加价才有空间，没签约。必须算接入收益、扩容、持续维护、稳定性和供应链风险，不能只看折扣。供方明确反对再次加重资产和维护负担；ToC一定优于ToB未证。

38. 界面原型和商业软件之间，还有测试维护

争论一方说AI几小时可复制壳，另一方指出相似界面≠功能、测试、服务器、模型算法全完成；服务器端算法不能靠客户端复现取回。项目越大，上下文/幻觉/细节遗漏风险越大，需要细分模块且有人把握架构、预知坑、验证。记忆库不保证每点完整。百万行或论文负号等数字都是口头类比/未核新闻，不当可靠故障率统计。前端“从不需维护”的说法被多方质疑；技术简单也不消除迭代和获客成本。GitHub每日涨星榜也是发现工具的一条途径。

界面原型、开源复用与可维护成品之间，还隔着后端能力、测试和持续维护。

39. 餐饮宣传片：成片交付与模板API的两种业务

餐饮短宣传片：低价自动化交付靠成本、分辨率和并发匹配

制作者接朋友商圈餐饮商家需求，交付一分钟内视频，200多–300元/条，不是某宝接单。客户给大概要求，他蒸馏优质视频文案/剧情提示词、装相关Skills、AI生产，称已自动化跑，当前交付成片，不对外提供视频生成API。2.5/2.0/H3是原话模型线索，无完整官方名；与会者报30秒100多、2.0 1080p15秒约50、720p再超分20来元，彼此报价差异不能拼成统一价格表。可用较低分辨率+超分控成本，H3本机能做但产出并发慢，所以倾向云端。效果与时间都需匹配订单，不把任一报价当利润保证。

把视频外包产品化的建议：行业模板比通用生成按钮更贴近需求

独立站用户要视频展示栏目，内置10–20套模板，选商品/传图后一键生成并发布，最好一次出5–6个供选。他不想通过微信电话反复找人。10秒视频云端也可能等几分钟，一键提交不等于零生成时间。卖鞋、衣服、农产品分行业模板/案例，可降低用户不会提示词的门槛；普通工作流还需打开软件再加载Agent，使用步骤太多。用户强调可维护API与服务质量，开源工作流并不自动有稳定保障；制作者明确不做此服务，因此是需求/产品化机会，不是其现有接口已上线。

40. 翡翠行业：先理解非标商品与真实调货流程

十多年翡翠经营者自述批发起家、近两年批零并行、利润薄需求下行，业内靠口碑人情、货源与客户群，仍保留老本行和历史数据，尚未具体把AI用进业务。他反对把非标翡翠简单当标准商品预测价：无完全相同商品，工艺之外还有许多因素，与金银不同；公开鉴定/报价还牵涉责任。高端不会掉价及行业全球趋势仅经营者看法，不作投资保证；NGTC是提及专业检测机构，不等于普通AI不能做任何库存分析。

另一人建议办公先上手，再查库存/销售、调货数据、减少积压、获客节流，经营者认为对方没理解实际调货流程并不愿披露。自动拨电话/AI调货只是建议，无部署；80%提升90%只是假设。可用教训是先采真实流程、同类数据和权限约束，不能以通用术语替代行业访谈；行业经验本身也不等于已经验证新AI业务。短剧出口50亿到1000亿、只有10%赚钱等均现场未核传闻，不能引用作行业统计。

41. 财务AI：从一个疲劳环节走向模块集成

财务AI分三层：采集治理、岗位自动化、辅助决策

财务询问者想企业自主逐步完善系统，不是要求全自动取代会计。技术建议先让发票等数据入系统，多系统CRM/ERP/MES做治理统一平台，查缺项和格式，再出成本/利润报表、告警和决策建议，未来预测更高阶。强调公司全局与个人成本会计、出纳需求不同；既有用友/金蝶/SAP导出的Excel等格式化数据可先做局部脚本，五张表汇总、Word转Excel、调整参数输出网页/报表。不要求初学者写Python，但需有运行环境，让AI调用包生成并保留通用脚本，需求变化再改。Python/JS包丰富程度是讲者个人经验，非绝对能力结论。

财务本人认可流程但追问非计算机人员怎么动手，另一非技术参与者指出技术回答没对齐甲方：个人小提效容易，商用/团队系统还要理解GitHub、数据库、服务器与本地环境。别从完整系统起步，先选一个疲劳环节、定义目标、搭环境、验结果迭代。原讲者称跑通过网站操作、文档转表、固定周月报；没展示生产财税验收。

浏览器填报与安全隔离：人保留采集、检查和提交责任

财务询问税务网站自动申报，建议浏览器操作Skill从Excel填表，原名Playway/Play with不清，工具身份待确认。按正常人节奏登录、不高频刷；安装本地可调用环境的客户端，网页聊天不一定能触达本机。把流程跑对后固化模板/脚本，定期运行，用户保留数据采集及输出查看。没有展示税站验证码、授权、申报校验全覆盖，不编成全自动报税SOP。

关键安全做法：专用目录放文件副本，限制AI操作范围，初期用权限受限模式，要求不自行危险操作；改完检查后再复制回，原文件不直接改。目录隔离减风险而不是保证绝对不会损害系统。有人用chatbook近音的免费客户端、自配Skills，API另付费可换DeepSeek/GLM；Workbot等名称近音及只能用自家云的说法待核。Codex建议：先让它执行实际步骤→人工指出不合格处→改到合格→要求把成功流程做成Skill，下次调用。固化成功路径而非第一次输出。

财务多角色协作：模块化低耦合，个人脚本和FDE集成是两种规模

成本、销售、出纳按树形结构分模块、再分机器成本；处理一次后固化脚本，换电脑改路径仍可复用。低耦合让A运行少影响B，但数据准确、业务逻辑和接口约定仍是前提。有人建议多Skill聚成Agent、严格提示词使输出稳定，这属于方案主张，不是稳定性实测。财务追问不同人做的模块怎么组合，回应若要求成熟跨角色系统可找FDE，不要自己拖很久。

FDE建议用授权数据库/API直接接用友、金蝶、SAP，减少窗口导入导出；统一数据中心/API消除孤岛，权限拿不到就不能拿数据。个人办公脚本与企业集成的成本、职责不同。附近企业5000–10000招FDE、小企不愿花钱均个人观察，不是薪资市场结论。

42. 电商素材量与职业教育获客：产能不等于成交

电商自动化的失败边界：素材量不是成交能力

另一位无货源电商经营者说已将有/无API动作都封MCP，图片视频广告都做，每品日出100–200甚至300–500素材仍干不过同行；未接无人/数字人直播，担心再耗时间且平台限制。口述三五百店、11平台，自称月赚六七万，但不想再追爆款把人锁住，正在考虑转企业AI，不能写其电商已完全无收入或AI自动化稳赚。同行权重、付费投流、渠道等约束不被产能单一解决。单次大任务丢给AI后睡觉是另一人的方法，不代表无人监管全天稳定交付。

职业资格教育平台：产品库存、老渠道与扩大付费获客的不同阶段

平台方自述投入300多万开发成本（先说几百万，追问不是推广费），AI教师课、实操课、3D模型/小游戏，目前约30专业，几百专业是潜在规模口径；每科4000–5000小程序/小游戏为自述未核。一级/二级建造师、注册会计师等职业资格学员是目标，卖平台会员而非把课程软件一次交出去。低价300–400元、高价约2000，前称一单1000–2000利润约一半，均自述区间非每单保证。

尚未开始新一轮推广/付费跑量，正准备招商代理，同时原有老销售渠道已带来几千会员，不能写完全没客源或付费广告已验证。打算扩科目、投流并给代理更多利润。电商方担心投流ROI不好，不是已测失败；讨论100元投放成交100即ROI1只是收入/广告费口径，盈亏还需产品成本。平台建议精准考试私域，提高需求匹配及转化；同投1000元带来10客户或50客户是举例。客户绑定、云服务/硬件绑定可减少被复制后流失，是经营建议；“技术40%变现60%”为观点，不能当研究结论。

43. 模型排错与可迁移工作流：用真实任务并测

一人Codex生图改一天，最后称是协议/HTML传输方式问题，换两条网络也没好，具体协议未披露，不能杜撰修复参数。国产API接好后稳定、进口会员便宜等是互相不同使用经验，未经同任务对比；GLM新高速、5.3、500字/秒、GPT百万token几毛都是口述待核，非技术规格。会员模拟API等不整理为绕限制教程。

可执行方法是API调用设计通用配置，换URL与配置切换厂商；脚本/模板开发时拿三家模型同任务并测，避免只贴合单一API，一换厂商性能崩溃。按业务选择模型，而非一个模型包打天下；有的业务一个好、另一个不好就换。百分之70可用、95%成功率及可进化模型每月更新、AGI几十年等是个人估计，不作为基准或事实。明确目标和可判对错的验收条件，比无标准的生成更易检验。彩票随机数/概率说法未给可靠证明，不传播成提高中奖方法，保留时间投入应与真实结果比较的提醒即可。

44. 铁路检测与交通预测：具体痛点，不等于已有成熟方案

接触网照片的海量人工比对

一位铁路检测企业管理者说，公司2019年已用卷积神经网络做视觉检测。他举高铁接触网悬挂为例：检测车经过时，每根支撑柱正面约25张、背面约25张，合计约50张；柱间距约30–50米，100公里便产生海量照片。他说现场仍大量依赖人眼比对，缺少能非常准确定位缺陷的AI。

另一个机会是随列车振动产生物理形变的装置：已有监测数据，可探索从历次变化预测后续趋势；这属于他提出的方向，没有给出已验收的预测系统。隧道顶部空鼓的例子同样区分现状与建议：他口述现场会在列车经过前人工检查处理，建议结合超声波或热探测与AI分析，但未提供具体设备、实施参数或安全验证。

数据孤岛部分打通后，预测仍可能做不成

他还讲到2023年承接武汉交通管理部门项目：预付款口述“三百”，单位未明确。客户部分打通数据孤岛，希望预测网约车等运营车辆未来交通拥堵，以便调度。其团队做了约一年半仍没有完成目标；上海浦东同期另一团队也做不到的说法是他的转述，没有独立项目材料。这个案例说明，数据能接入只是前提，不能因此承诺复杂时空预测一定成功，更不能把预付款当项目验收或利润。

专业小团队与三五人团队，准入条件仍未讲清

他举上海“儒/如慧”近音公司专做接触网检测，人数口述约二十至四十人，名称与规模待确认；认为企业小不代表无法接专业大客户订单。主持人进一步追问一两人、三五人团队如何从投标角度进入，发言中断，没有得到完整答案。

这位管理者也认为统计、生成式管理需求有限，问CFO或CTO即可获得进展，报表还可能鼓励把数据做漂亮。这是其管理立场，与民营企业问数客户的需求并不一致；两者服务的组织、权限与问题不同，不应以一方经验否定另一方。