AI 知识题库

要点大模型是「问一句答一句」，Agent 是拿到目标后自己拆步骤、调工具、看返回再决定下一步；差别在有没有循环和行动权。

口述我在哈泰克做的查数助手就是最小 Agent：它自己判断查工单还是查库存、调 MES 8302 的只读接口、查不到就换条件再查；普通问答不会自己去调接口。

要点模型、系统提示词、工具清单、会话记忆、循环控制五块，工程上还要加权限校验和调用日志。

口述我拆 LeanMES 那个助手时就是这五块，工具只挂了 4 个（工单查询、库存查询、SOP 检索、报工统计），权限在代码里卡，每次调用写日志，不然出问题查不到是哪一步。

要点Workflow 步骤写死在代码或 Dify 画布；Tools 是被调用的接口；Agent 是模型自己决定下一步调谁。

口述知识库那条链路是 Workflow，检索→重排→生成顺序我定死；MES 8302 的查询接口是 Tool；只有查数助手让它自己选工具。三者区别就是谁做决策。

要点ReAct 边想边做、Plan-and-Execute 先出计划再执行、Reflection 做完自查、多 Agent 分工；核心区别是控制权在代码还是在模型。

口述我在 Dify 里跑的是固定工作流加一轮答案校验，没上全自动规划；查数助手是简化版 ReAct。工作流能回滚、能审计，制造业场景我优先它。

要点Thought→Action→Observation 循环，模型输出「想什么、调哪个工具、传什么参数」，代码执行后把结果塞回上下文再问下一步。

口述我手搓过最小版：给模型 3 个工具，它先输出要查工单，我把 MES 返回的 JSON 回填，它再决定要不要查库存。坑在死循环和工具选错，所以加了最大 6 步。

要点步骤固定、要审计的用 Plan 或工作流；探索型查数用 ReAct；输出质量要求高的加一轮 Reflection。

口述知识库问答我加了 Reflection——生成后检查有没有出处，没有就改成「没查到」；排产建议这种多步任务如果要做，我会先 Plan 再执行，不让它边想边改。

要点按交付物和依赖拆，每步有明确输入输出，能单独重跑。

口述我把「查这个月异常工单」拆成取工单、按工序聚合、对比 SOP 三步；第二步口径错了只重跑第二步，不用把 MES 数据再拉一遍。

要点短期放上下文，长期落库；写入要筛选，读取要按项目/设备检索。

口述LeanMES 助手的多轮只在一次会话里有效，关掉就清；长期只存「这个车间常用哪张报表」这种偏好，按工号存，不存聊天原文。

要点短期按轮次，长期按「一条可复用的事实」，比如某个设备的报警处理结论。

口述我存的是「3 号线贴片机报 E204 先查吸嘴真空」这种一条一条的结论，按设备号索引；没做向量化长期记忆，这块只到能对话的程度。

要点多个角色各有工具和职责，由编排器分派和汇总。

口述我理解是一个查 MES、一个查库存、一个写结论；我只在 Dify 里做过两个节点的原型，没上过生产级 Multi-Agent，不敢说做过。

要点单 Agent 简单可控；多 Agent 适合职责差异大、可并行的任务，但状态传递和冲突处理成本高。

口述LeanMES 的场景用单 Agent 就够，工具 4 个、流程清楚；多 Agent 我评估过，光「谁负责最后拍板」就说不清，所以没上。

要点滚动摘要、按重要性淘汰、结构化抽取关键约束、分段检索。

口述我压缩时先保「当前查的是哪张工单、时间范围、已排除的条件」，过程对话只留一行；约束丢了，后面查出来的数就是错的。

要点工具少、流程清楚时手搓循环加日志就够；框架适合快速验证，但多一层抽象，排查成本高。

口述查数助手我就用一个 while 循环加 4 个函数，出问题直接看日志；Dify 那套可视化适合业务自己改流程，但线上排查要翻执行记录，反而慢。

要点给目标、给约束、给工具清单，让它先列步骤再执行，计划可人工确认。

口述我会要求它先输出「第一步查工单、第二步查库存、第三步汇总」，我确认后再跑；规划靠提示词加两个示例，不神秘。

要点生成后按清单自查：有没有出处、有没有答非所问、有没有超权限，不满足就重试或转人工。

口述知识库答案我会让它回填引用段落，没有引用就重写一次；还是不行就直接说「文档里没有」，不硬编。

要点先定角色边界和交接格式，再定切换触发条件，最后定失败回退。

口述我在 LeanMES 查数助手里只做单 Agent，交接就是把手里的工单号和已查表名写成 JSON 传给下一步；多 Agent 的动态切换没做过，只能讲触发条件怎么定。

要点分四层放：系统规则、任务信息、检索结果、最近历史；重要约束放最前，检索内容标出处。

口述LeanMES 助手的提示词第一节就是「只读，不许生成 SQL 写操作」；检索到的 SOP 放中间并带文档名和版本，历史只留最近 3 轮。

要点状态外置成 JSON（当前目标、已完成、待确认），每轮校验目标有没有漂移，中断从快照恢复。

口述我把「工单号、时间范围、已查过的表」存成 JSON，不靠模型自己记；用户换了个工单号，我就把后面的步骤重置。

要点任务成功率、步骤正确率、工具调用准确率、人工接管率、时延和单任务成本。

口述我攒了 40 多个真实查数问题做评测集，人工判对错；知识库那块没做严格埋点，只能给体感，不敢报百分比。

要点设最大步数、同工具同参数去重、工具返回要明确成功/失败、上下文别丢关键约束。

口述查数助手我设了 6 步上限，同一工具同一参数调两次就停，直接回「没查到，请补充工单号」；不设上限它会在两个表之间来回查。

要点按步打点，分开看模型耗时、工具 RT、检索耗时，再看是不是上下文太长。

口述我在每一步记开始和结束时间，发现慢的是 MES 8302 那个接口，不是模型；后来加了 30 秒缓存，重复查询直接返回。

要点超时熔断、任务幂等、写操作加版本号或锁，失败要有降级路径。

口述多 Agent 并发我没做过；单 Agent 里对 MES 的读请求允许重试，写报工必须带工单版本号，版本对不上就让人刷新重来。

要点模型容易把「计划」当「已执行」，完成状态必须由工具返回确认。

口述我的规则是工具没返回 success 就不许说「已处理」；查不到就说查不到，不许编一个工单号。

要点只读账号、限行数、字段白名单、SQL 语法和权限校验、结果能回到原 SQL。

口述MES 8302 我只开了查询权限的账号，默认 limit 200 行；生成的 SQL 先过一遍关键字黑名单，出现 update/delete 直接拒绝。

要点包在模型外面的运行框架：工具注册、循环控制、权限、日志、评测。

口述我手搓的那个查数循环就是最小 Harness：4 个工具注册成函数、最多 6 步、每次调用写一行日志，模型只负责选工具。

要点工具层、编排层、记忆层、权限层、观测层、评测层，先把工具和权限做扎实。

口述我的顺序是工具→权限→日志→循环→评测；没有日志和回放的 Harness 上线就是黑盒，出了问题只能重启。

要点从失败案例改提示词、补工具、加示例，人工审核后再生效。

口述我不做自动改自己那套；每周把查错的 case 拉出来，人工改提示词或补一条同义词，再跑一遍那 40 题评测集。

要点写操作、涉及钱和权限、对外发送、低置信度、不可逆动作都必须确认。

口述我的线是「读自动、写确认」；排产只出建议不改工单，报工数据只读不写，对外内容必须人过一遍。

要点按模型窗口和任务类型定，底线是关键约束不丢，用固定评测集验证。

口述我没有统一阈值，一般到窗口六七成就开始摘要；压完跑一遍那 40 题，掉准确率就调回去。

要点采样随机性、工具返回变化、上下文顺序、外部系统状态变化。

口述温度、MES 里新产生的工单、检索回来的段落顺序都会影响结果；要稳定就降温度、固定返回格式、把关键步骤写成工作流。

要点先检索资料再让模型基于资料回答，链路是清洗→切分→Embedding→入库→检索→重排→拼上下文→生成。

口述我们内部知识库就是这条链路，文档是设备 SOP、工艺文件和 IT 运维手册，存在 Qdrant 里，生成用 DeepSeek。

要点知识不在模型参数里、会过期、需要出处、数据不能拿去训练。

口述哈泰克的设备 SOP 一改版，微调跟不上；RAG 把新文档重新入库就能用，答案还能点回原文那一段。

要点RAG 是开卷，更新快、可溯源；微调是背题，适合固定风格和输出格式。

口述我们线上没做微调；工艺文件三个月一改，微调一次成本高还容易过时，RAG 加一份文档就能用。

要点按语义单元切，SOP 按步骤、工艺按工序、表格单独结构化，不按固定字数硬切。

口述第一版按 500 字切，把一个报警处理步骤切成两半，召回出来的答案缺前半段；后来按标题和步骤切，表格走结构化才准。

要点按结构切、块间留重叠、给每块补章节标题、检索子块拼父块。

口述我给每个 chunk 前面加上「设备型号 + 章节名」，相邻块重叠 50 字；命中子块时把父块一起拼进上下文。

要点把文本映射成向量，用余弦距离衡量语义相近；用真实问题集看召回，不只看榜单。

口述我对比过两三种中文 Embedding，最后跟着 Qdrant 这套用；评估就是拿 40 个真实问题看正确答案有没有进 Top-5。

要点稀疏（BM25/TF-IDF）看字面，稠密（BGE、OpenAI、DeepSeek）看语义，现在常用混合。

口述原理我清楚，实际只在知识库里对比过两三种中文模型；判断标准是那 40 个设备问题里正确答案有没有进 Top-5，没做算法级研究。

要点存向量和 payload，支持相似度检索和元数据过滤。

口述我们选 Qdrant，看中它单机部署简单、按部门/设备类型做 payload 过滤方便；没做大范围横评。

要点Qdrant；量级是内部文档，不是海量；瓶颈在切分和召回质量，不在库本身。

口述文档量大概几千个 chunk，Qdrant 单机完全够，没遇到性能瓶颈；真正难的是文档本身脏、口径不统一。

要点Query 改写→混合检索→重排→拼上下文→生成→带出处返回。

口述用户问「这个报警怎么处理」，先补全设备型号，再走向量加 BM25 两路，取 Top-8 重排后拼进提示词，要求只基于材料答。

要点向量看语义能召回同义表达，关键词对型号、料号、编号更准。

口述设备型号、工单号这种必须靠关键词；师傅口语化描述靠向量。所以我们做的是混合检索，两路分数加权。

要点补全指代、拆多问题、加同义词和领域词，目的是让检索能命中。

口述车间问「这个报警怎么处理」，不改写连是哪台设备都不知道；我先让他选设备或补型号，再检索。

要点向量、关键词、结构化查询并行，再合并重排。

口述我们至少走向量加 BM25 两路；问「上月有多少工单超期」这种，直接走 MES 8302 的 SQL，不走向量。

要点切分、元数据过滤、混合检索、重排、Query 改写、父子块，按性价比排。

口述我先做切分和元数据，再加混合检索和重排；这几步做完，大部分设备问答就够了，再往上投入产出比不高。

要点多跳、GraphRAG、Agentic RAG、自适应检索。

口述原理能讲；生产上知识库只用到混合检索加重排，GraphRAG 和 Agentic RAG 没落地过，不敢说做过。

要点需要多跳关系、实体关联、路径查询时用；纯语义相似不需要。

口述比如「这台设备故障影响了哪些工单、哪些客户」，要顺着 BOM 和工单关系走；我们没上图数据库，这块只到能对话。

要点只基于检索内容回答、必须带出处、无召回就转人工、低置信度不硬答。

口述我们的规则是「材料里没有就说没有」，答案必须带文档名和段落；这条比换模型有效。

要点离线看 Top-K 召回和答案正确率，线上看提问量、转人工率、bad case 数。

口述我们有 40 多题的人工标注集，每周过一遍答错的；严格的使用率和自助解决率没统计，不敢给数字。

要点文档源定时同步、增量入库、版本和失效标记、更新后回归测试。

口述目前偏手工，SOP 改版后重新入库一次；自动同步和版本管理没做完，这块是下一步要补的。

要点不是模型，是文档质量、切分和让一线愿意用。

口述最难的是文档本身脏、口径不统一；技术链路两周能搭起来，难的是让师傅信、愿意点开出处。

要点先定优先级（最新正式版 > 部门文件 > 历史资料），冲突时把两份都列出来让人确认。

口述工艺文件有两个版本时，我不让模型自己裁决，答案里同时列出来并标生效日期，让工艺员确认。

要点成本、延迟、无关信息干扰、权限过滤、知识更新。

口述窗口再大也不能把全公司文档塞进去；而且 MES 的工单数据有权限，RAG 能在检索层就按部门过滤。

要点问题边界清楚用 RAG；要多步找、跨文件比对用 Agent。

口述日常设备问答用 RAG，稳定便宜；要「把这个月异常工单和 SOP 对一遍」这种多步任务，才值得上 Agent。

要点把工具描述成 JSON Schema，模型输出「调哪个、传什么参数」，代码执行后回填结果。

口述模型不真的执行，只生成调用意图；执行和权限都在我们代码里，MES 8302 那个接口就是这么接的。

要点预训练见过调用格式，再用指令微调强化，靠 schema 约束输出。

口述本质是模式匹配；所以我给 MES 8302 的查询接口写描述时，会把「只查不改」「时间格式」和反例都写进去，参数还做类型校验。

要点步骤不固定、要跨多个系统查、能容错重试的适合；强合规、零容错、结果无法验证的不适合。

口述查工单、找 SOP、整理会议待办适合；改工单、动库存、对外发消息不适合全自动。我排产只出建议，不改工单。

要点一次做完的比例、人工接管次数、单次耗时、下周还有没有人用。

口述我看四件事：查工单能不能一次查对、要人补几次车间或时间条件、比翻 MES 菜单快多少、下周还有没有人打开。

要点读操作可自动，写操作要确认；低风险自动，高风险留人。

口述查 MES 工单和库存放开；报工、改工单状态、对外发消息必须有人点确认。

要点先做高频、边界清楚、能单独验收的一段。

口述我先切「查数出结论」这段，不碰执行；LeanMES 里先把工单查询跑稳，再接报工统计。

要点先只读、给依据、可撤销、从小权限开始。

口述先让它查、给出处，不替人做决定；师傅发现它查得准，再放开建议，最后才谈执行。

要点垂直场景边界清楚、数据可控、容易验收；通用看起来大，落地难。

口述我选垂直。制造业里排产、设备、仓储口径都不一样，通用 Agent 答不准也担不了责。

要点V1 只读问答带出处，V2 多步查数和建议，V3 有限执行加人工确认。

口述V1 只做 LeanMES 工单查询带出处，V2 接库存和报工统计，V3 才谈生成建议；每版留一个能关掉的开关。

要点够用就好，5–8 个；给多了选择困难、参数混淆、延迟上升。

口述LeanMES 助手只挂 4 个工具：工单查询、库存查询、SOP 检索、报工统计；工具一多，模型就开始选错。

要点写清用途、输入输出、边界和反例，参数用 schema 约束。

口述我给 MES 8302 的查询工具写描述时，明确写「只读，不生成写操作」「时间参数 yyyy-MM-dd」，还给了两个正例一个反例。

要点每步幂等、失败可重试、超过次数降级转人工。

口述查 MES 是读，可以重试；改报工状态是写，必须先查工单当前状态再决定；重试三次不行就回「请人工处理」。

要点流程固定的交给代码，步骤不确定的才交给模型。

口述LeanMES 的查数流程我写死在代码里，模型只填工单号和时间；让它自由拆解，出了问题没法审计。

要点工具接入标准化，跨系统协作成本下降，但权限和治理更重要。

口述我给 LeanMES 助手接工具时，就是把工单查询、库存查询各写成带 schema 的接口；协议解决怎么接，谁能调哪些车间还得在 Casdoor 权限里卡。

要点存目标、约束、结论、偏好；不存一次性过程、敏感信息、能从系统实时查到的数据。

口述我存「这个车间常用哪张报表」；不存聊天原文和密码。工单状态每次从 MES 现查，避免记错。

要点结构化摘要，保留目标、约束、已完成、待确认，过程细节丢弃。

口述压缩时先保「查的是哪张工单、时间范围、已排除条件」，过程只留一行；约束丢了后面全错。

要点记忆可见、可编辑、可删除，关键偏好二次确认。

口述我会把记住的「常用车间」展示出来让人改；不把猜测当事实长期存。

要点状态以业务系统为准，会话只做缓存，关键节点重新拉取。

口述工单状态不能信模型记的，每次从 MES 8302 查；会话记忆只是上下文，不是数据源。

要点单轮只看一句话答得好不好；Agent 要看多步路径、工具调用和最终任务完成。

口述Agent 第一步错后面全错，所以要按完整任务评；我那 40 题评测集就是按「能不能查到正确工单」判的。

要点0.95 的十次方约 60%，整体成功率明显下降，要减步数、加校验和回退。

口述十步都 95%，整体只剩六成；所以我把查数流程压到三步，每步都校验工单号和时间范围，错了能退回上一步。

要点从真实任务抽，覆盖正常、边界、失败，标注期望步骤和结果。

口述我从 MES 历史工单里抽真实问题，按车间分类，再加「工单号不存在」「时间范围跨年」这种边界样例。

要点看 Trace，逐步回放检索、工具返回、模型决策和上下文。

口述我会在 LeanMES 助手每一步记输入输出，先看哪一步开始偏：是 MES 没查到、参数传错，还是模型选错工具。

要点工具结果为准，关键动作二次校验，无结果就说没有。

口述Agent 会「假装做完了」；我要求 MES 接口返回 success 才允许说已处理，查不到就说查不到。

要点算单任务 token × 调用次数，合并重复调用，能用小模型就换小模型。

口述LeanMES 查数助手二十次调用里，先看有多少是重复查同一张工单表；我把固定步骤写成工作流，模型只做意图识别，调用次数能砍一半。

要点流式输出、并行工具、缓存、小模型、先给中间结果。

口述先把能并行的并行，再上流式让用户看到进展；查 MES 超过 5 秒就先回「正在查工单」。

要点分类、抽取、改写、格式化用小模型；推理和最终生成用大模型。

口述意图识别和工单号抽取我用便宜模型，只有最后总结用大模型，成本能降不少。

要点限流、队列、缓存、降级、按部门配额。

口述先限流和排队，再考虑扩容；高并发时只保工单查询，报表生成和知识库问答降级。

要点按坐席、按任务、按用量，看客户能不能算清账。

口述制造业客户更容易接受按坐席或按年，一个坐席一年多少钱这里要你自己补一个真实值；按 token 他们算不清。

要点首次任务要简单、可成功，给示例和兜底。

口述第一次一定给他一个能成的任务，比如查一条已知工单；失败一次，很多人就不再用第二次。

要点产品方、使用方、数据方分责；写操作必须有人确认，日志可追溯。

口述只要动了 MES 里的工单或报工数据，就必须有人确认和留痕；全自动出错责任说不清，所以我不做全自动写。

要点涉及资金、权限、对外承诺、不可逆操作，一律不做或必须人工。

口述我的黑名单很明确：不改工单、不动库存、不对外发消息、不替人签字；其余可以谈。

要点必须留谁、什么时候、调了什么、结果如何；写操作要能撤销。

口述没有留痕就不能上线；MES 里的写操作要能查到哪张工单、哪个字段、谁点的确认，还要能撤回。

要点多半是人力不够、数据太散、报表太慢，或者老板要一个交代。

口述客户嘴上说要 AI，聊下去通常是「这批单据没人录」「查个数要等两天」；先接业务动作，再谈技术。

要点痛点是否高频、数据是否可得、有没有人拍板、能不能验收。

口述我看四点：痛不痛、T100 和 MES 里数据有没有、谁签字、怎么算成功；四个缺一个，项目大概率烂尾。

要点拍板的人决定做不做，一线决定用不用，方案要同时满足。

口述老板要的是报表能自动出，班组长要的是少填两张单；我先保证报表口径对，再把 AI 入口放到报工页面。

要点第一期做能验收的窄场景，第二期扩，第三期才做平台。

口述我会把第一期压到三个月能出结果，比如先把报工查询做出来；一上来做平台，预算和耐心都撑不住。

要点去现场、跟班、问动作不问概念、要真实单据。

口述我不问「你想不想要 AI」，我看他一天填哪些表、等谁签字、在哪卡住，再让他拿一张真实工单走一遍。

要点签约、回款、交付验收、续约、标杆复制。

口述ToB 不能只看功能上线，要看验收和续约；LeanMES 这种项目，一个车间用起来、能复制到第二个车间，才算成。

要点窄场景、真数据、预先定验收口径、两周内出结果。

口述POC 只做一个最痛的场景，用客户真实 MES 数据跑，开始前就写清「什么算通过」，不然做完各说各话。

要点场景太大、数据没准备好、验收标准模糊、没有业务方参与。

口述最常见是范围太大和没人配合；我见过 POC 做三个月，最后发现数据在 T100 里、客户没给接口权限。

要点先做数据体检，清洗和映射单独算工作量，关键字段人工兜底。

口述我会先从 T100 抽 100 条物料主数据看脏到什么程度；能清的清，清不了的加人工确认。

要点通用能力进产品，客户特有流程做配置或插件，一次性需求不进主干。

口述只有哈泰克要的字段走配置，不进 LeanMES 标准版；第二个客户也能用，才进产品。

要点技术方案讲清边界和验收，商务方案讲清分期和风险，别过度承诺。

口述技术方案我会明确「不做什么」，比如不改 T100 主数据；商务上给分期和退出机制。

要点从主数据和账号权限开始，再做单据和接口。

口述先把物料、客户、供应商、库位从 T100 对齐，再接 Casdoor 单点登录，最后才是工单和库存接口；顺序反了会一直返工。

要点三个都是必答，ToB 没有权限和审计过不了验收。

口述我们做 Casdoor 统一认证，4471 个账号、12 个应用接进来，就是为了账号和权限统一；审计日志在制造业是硬要求，出了问题要能查到人。

要点里程碑、周例会、关键路径、变更冻结、甲方对接人。

口述我在 LeanMES 和 IWMS 项目里就是拆里程碑、盯关键路径；需求变更必须走确认，不然六个月一定拖。

要点产品、交付、业务方都有责任；使用率要写进验收。

口述只交系统不管使用，肯定没人用；我会把入口放进 LeanMES 报工页面，培训到班组长能自己查。

要点先跑基线对比，看是模型换小了、检索数据没同步，还是硬件和网络问题。

口述私有化环境先用同一套 40 题评测集跑一遍，和云端对比；很多是知识库文档没同步过去，不是模型不行。

要点省的人天 × 频次 × 人数，加上减少的差错和停机，假设要写出来。

口述我会和客户一起填假设：每次省多久（这里要你自己补一个真实值）、一天几次、多少人用；口径要让客户认。

要点拆到具体动作和人天，区分人力、物料、停机、质量损失。

口述30% 要拆到具体动作，比如报工录入从几张单减到几张；拆不出来，说明客户自己也没想清楚。

要点用过程指标替代：查询次数、处理时长、转人工率、使用人数。

口述算不出钱的时候，就看 LeanMES 里这类查询有没有人用、处理时长少了多少、来回问的次数少了多少。

要点没解决核心问题、使用率低、换人后没人推、价值说不清。

口述续约低通常不是功能少，是没人用；上线时热闹，三个月后班组长还是回到 Excel，续约时就没话说。

要点嵌进日常流程、沉淀数据、形成习惯、迁移成本高。

口述让它在员工每天必用的 MES 入口里，数据越积越多，换掉就丢历史；靠锁功能留不住客户。

要点项目制按人天/模块，标准化产品按年/坐席，按效果要有验收口径。

口述LeanMES 这种定制项目按人天最稳；标准产品按年订阅；按效果收费我只在指标能第三方验证时接受。

要点可以接对赌，但必须写清指标、口径、数据条件和责任边界。

口述指标能定义、数据我能控制，就敢接；客户 T100 数据一塌糊涂还要保效果，我不接。

要点大单保交付，小单走标准化和自助，别用大单团队做小单。

口述小单必须产品化、模板化，不然实施 LeanMES 的人力成本会把毛利吃光；大单才配专属实施。

要点看量、看行业、看是否影响主线，贴牌要收授权和服务费。

口述量足够大、不冲击自有品牌才做；贴牌不是改个 logo，MES 的升级和支持责任要写清。

要点需求分级、配置化、复用组件、定制单独报价。

口述先把定制需求分类，能配置的不写代码；真要改 LeanMES 主表的，单独报价。

要点统一入口、分级评估、定期排期、公开状态。

口述所有需求进一个池子，按价值和成本分级，季度排一次；车间直接在群里提，永远做不完。

要点售前管方案、产品管边界、交付管落地、销售管商务，关键节点拉齐。

口述最容易出问题的是售前过度承诺；重大方案必须产品和交付签字，比如承诺对接 T100 的字段范围。

要点听客户问题，不听单一角色；销售看机会，交付看成本，产品做取舍。

口述销售说的是下一个单子，交付说的是 LeanMES 这个坑；我把两边都收进来，按复用价值排。

要点项目复盘出通用模块，抽象成配置项，写进标准版和交付手册。

口述每做完一个项目，我会问「哪些下个项目还能用」；Casdoor 那套登录对接就是从第二个项目开始复用的。

要点看目标场景的任务分布，不追榜单，优先补高频短板。

口述我没在模型厂定过基座边界；从企业客户侧看，我会先看客户实际在问什么，哪类任务掉得多就补哪类。哈泰克这边掉得最多的是长文档和表格问答。

要点预训练贵且慢，后训练见效快，推理扩展适合复杂任务但成本高。

口述这三条我没实操过；从企业侧看，先用后训练和推理侧把知识库答准，预训练是模型厂的事。

要点看是否解决现有 workflow 的卡点，不看演示效果。

口述制造业里长文档和工具调用是真需求，我们知识库就卡在 20 页以上的工艺文件；多模态要看有没有质检看图场景。

要点固定评测集 + 灰度 + 回滚，关键场景单独回归。

口述我做过最接近的是模型切换：换 DeepSeek 新版本前，先跑那 40 题评测集，掉了就切回去；没有评测集，升级就是赌。

要点先用自己的评测集测真实差距，再决定降价、补能力还是换叙事。

口述先拿那 40 题评测集跑一遍，看差距在设备问答还是表格问答；只是榜单强、我们场景没差别，就不跟。

要点公开榜单有污染、和真实场景脱节，要自建场景集。

口述榜单只能看大概水平；我做的是从 MES 和知识库真实问题里抽 40 题，人工标答案，按车间分。

要点多人盲评打分 + 偏好对比 + 一致性校验。

口述主观能力只能成对比较加多人评分；我在知识库答案上试过，三个人按「有没有出处、有没有答非所问」打分。

要点去重、时间切分、私有保留集、异常高分排查。

口述如果某个模型在知识库评测集上异常高，先怀疑那 40 题被训练见过；用新工单数据做保留集最可靠。

要点先看输入、上下文、提示词和检索，再谈模型。

口述我遇到的多半是用法问题：没给设备型号、没给时间范围、问题本身模糊；先复现，再判断是不是模型。

要点业务方和产品共同定，依据是场景容错度和评测结果。

口述红线不能由算法单方面定；涉及对外输出和钱的场景要高，内部查 SOP 可以低一点。

要点知识常变、要溯源用 RAG；风格和固定格式用微调。

口述我们的设备文档一直变，肯定选 RAG；只有输出格式和话术要稳定时，才考虑微调。

要点先用真实日志筛样本，再小规模标注，优先高价值场景。

口述标注很贵，我会先用知识库里答错的 case 筛样本再让人标；不追求量大，追求覆盖关键错误。

要点能用，但要混真实数据、做多样性控制、人工抽检。

口述纯合成数据会让模型越来越像自己；知识库这块我没做过合成训练，只到能讲风险。

要点看场景和后果；高风险场景安全优先，低风险场景保有用。

口述涉及人身、财务、合规的安全优先；内部查 SOP 这种别过度拦截，不然师傅不用。

要点缓存、路由小模型、压缩上下文、批量、蒸馏，按投入产出排。

口述先做缓存和上下文压缩，再把意图识别换小模型；知识库问答里这两步见效最快。

要点按 token 透明但客户算不清，按席位好卖，按结果难验收。

口述企业客户更容易接受席位或年包；token 计价适合开发者；按结果要能第三方验证。

要点额度按账号+IP+设备限制，关键能力单独计费，异常行为风控。

口述免费额度要给得能跑通一个 Demo，比如查 20 次工单；但不能无限刷，注册和风控要跟上。

要点先找成本最高的场景做试点，用数据说话再推广。

口述我会先挑调用量最大的功能做缓存和小模型分流，比如工单查询，算出省了多少钱再推其他团队。

要点看规模、看能否标准化、看交付和升级成本。

口述制造业客户数据敏感，私有化单子大且能复制就接；一单一定制还要长期维护的，宁可不接。

要点存量客户要稳定，新客户要能力，用版本隔离不破坏兼容。

口述我会保老版本稳定，新能力开新版本；直接改字段，接 MES 的开发者跑一次就流失了。

要点低门槛文档、可跑示例、稳定 SDK、按量计费、社区支持。

口述第一次接入要能在半小时跑通；文档和示例比模型参数更能留住人。

要点能力边界、训练数据概况、评测结果、已知风险、适用和不适用场景。

口述模型卡要写清不能做什么，比如不保证工艺参数；企业客户最关心这个。

要点看商业模式和生态目标，开源小模型换生态，闭源大模型保收入。

口述一般小参数开源、旗舰闭源；知识库我们是调 DeepSeek 接口，开源策略这个取舍我没实操过。

要点看 5% 落在哪个能力、能不能带来场景突破，全量发布的回归和沟通成本很高。

口述如果提升的是设备问答这种关键任务，值得；只是平均分涨 5%，先灰度，不急着全量。

要点讲清市场窗口、差异化、投入产出和不成的话损失什么。

口述不能用「别人都在做」论证；要说明这笔钱买的是什么能力。我在企业侧没做过十亿级论证。

要点按公司阶段目标排，不按部门嗓门，公开优先级和取舍。

口述在 LeanMES 和 IWMS 之间排期时，先定这一年最重要的一件事，资源跟着它走；都想要，最后都做不好。

要点通用能力进主线，定制走项目或插件，不让单客户绑架路线。

口述大客户可以加配置，但不能改 LeanMES 主干；改主干，后面每个客户都要维护。

要点能力有明确优势、开发者增长、收入结构健康、关键场景站住。

口述我会看三个数：有多少场景非你不可、开发者有没有留存、收入是不是靠少数大客户。

要点看问题是否规则固定、数据量、容错度、可解释要求。

口述规则清楚、要稳定的用传统模型或代码；语义模糊、长尾多的用大模型。AI 视觉检测这种要可解释的，我不会只上大模型。

要点召回加语义向量，排序加特征和重排，Query 改写用模型。

口述搜索这块我只到能对话的程度；知识库的做法是保留关键词召回，加向量召回，再用模型做改写和重排。

要点质检、单据识别、设备看图、培训视频。

口述制造业最先能落地的是视觉质检和单据 OCR；我们做过 AI 视觉检测，知道难点在样本和误检率，不在模型。

要点看问题定义、数据来源、评测口径、失败兜底、上线成本。

口述我不看模型多新，先问「AI 视觉检测怎么算成功、漏检了怎么办」；没有评测和兜底的方案，我不会让它上线。

要点看瓶颈在数据、模型还是场景定义，先做误差分析。

口述视觉检测卡住时，先看是样本不够还是漏检类型没定义；如果是场景本身不适合，换规则或换工位。

要点定义上分层、采样和加权、长尾单独评估、必要时收窄场景。

口述我不会让视觉检测团队只追平均准确率；划伤、脏污这些长尾类别要单独看，做不好就先限定工位。

要点标注规范、双人复核、抽检、Kappa 一致性。

口述视觉检测标注先写清「什么算划伤」，再让两个人标同一批看一致性；一致性低，说明标准本身有问题。

要点收集行为与结果、清洗去噪、人工确认、版本管理。

口述知识库里师傅点了「没用」不等于错，要看他最后有没有改用别的答案；我一般先用 bad case 做样本。

要点规则、专家经验、公开数据、小样本 Prompt。

口述先用规则和老师傅经验跑起来，再逐步收数据；没有数据还想一步到位，基本不现实。

要点严格按时间切分，特征只能用在预测时点之前的数据。

口述视觉检测离线效果好、上线就崩，多半是训练时用了质检后的结果；我会检查每个特征的时间戳。

要点和业务目标绑定，兼顾长期价值，避免只看点击。

口述制造业内部没有推荐场景，我看的是 LeanMES 里查询任务完成率和复用率，不是点击。

要点先保相关性底线，再做多样性，按场景调权重。

口述知识库检索不相关的东西再多样也没用；我会先卡相关性阈值，再在合格结果里做多样性。

要点先看瓶颈在哪，多数场景召回不足比排序不准更致命。

口述知识库如果召回里根本没有那份 SOP，精排再好也没用；我会先补 Query 改写和召回。

要点能做原型，生产上受延迟、成本和稳定性限制。

口述我了解但不熟；知识库现在只用检索加生成，LLM4Rec 更适合做推荐解释，不建议替掉现有链路。

要点控制相似内容比例、引入探索、给用户可控开关。

口述内部工具不存在信息茧房；如果做内容产品，要有探索位，但别为了指标硬塞。

要点类别固定、数据够就微调；类别常变、样本少就 Prompt。

口述不良原因分类我先用 Prompt 在 LeanMES 历史工单上验证，稳定后再考虑微调；一上来微调标注成本太高。

要点准确率、召回率、误检率、漏检率、人工复核成本。

口述质检不能只看准确率，漏检和误检的代价不一样；我们做 AI 视觉检测，验收是按业务能接受的漏检率来定。

要点图文对齐向量、元数据过滤、混合检索、结果可解释。

口述我的思路是图片和文字都做 embedding，再用设备、工单号做过滤；这块我没落地过。

要点拾音、ASR、NLU、生成、TTS 分段预算，端到端控制在可接受范围。

口述语音我没做过；按知识库问答的经验，ASR 和生成是大头，超过两三秒师傅就急，只能讲预算思路。

要点看数据分布、特征一致性、评测口径、线上延迟和交互。

口述先确认知识库离线评测和线上用的是不是同一批文档；很多是离线用了新 SOP，线上还没入库。

要点按基线、最小可检测提升、显著性算，覆盖完整业务周期。

口述样本量不够就别下结论；LeanMES 有白班夜班，至少跑满一个完整班次周期。

要点数据漂移、用户行为变化、上游数据变了，要监控和定期重训。

口述知识库效果衰减，先看是不是工艺文件改版了没重新入库，再看模型版本有没有换；衰减是常态。

要点自动评测做回归和覆盖，人工评测做主观质量和边界。

口述40 题评测集自动跑量，人工抽检看答案有没有出处；只信自动分数，很容易自嗨。

要点按用户/租户分流、分阶段放量、监控红线、随时回滚。

口述先内部再小客户再全量；每阶段看错误率和投诉，红线一到就回滚。

要点数据、工程化、成本、稳定性、用户体验。

口述论文证明可行，产品要证明可用；知识库中间差的是脏 SOP、检索延迟、答错兜底和师傅培训。

要点先算清收益，再做分层和降级，找一个小场景证明。

口述我会先在设备报警问答这个小场景跑，算出省了多少次打电话，再谈全量；财务只认这个。

要点先问清是数据不够、指标达不到还是成本太高，再改问题定义。

口述很多时候不是做不了，是「按你这个标准做不了」；把「必须全自动改工单」拆成「只给建议」，就能做。

要点换成时间、差错、人力、停机这些业务语言。

口述不说准确率 92%，说「原来要人工看 100 张，现在只看 10 张」；业务只认这个。

要点把 AUC 换成混淆矩阵和业务代价，给出阈值选择。

口述视觉检测我会问「漏检一个和误报一个，哪个更贵」，然后按业务代价定阈值，而不是丢一个 AUC 给质检。

要点先做离业务最近、能马上被用的，多数企业先做推理/Agent。

口述制造业没有自己的训练需求，先做推理和知识库问答更实际；训练平台投入大，没算法团队就是摆设。

要点看公司有没有算法团队，没有就先服务业务开发。

口述我们这种甲方信息中心，第一批用户一定是 LeanMES、IWMS 的业务开发和实施，不是算法工程师。

要点接入团队数、调用量、复用次数、节省的人天和重复建设。

口述平台价值要能算「少了几个重复对接 T100 的项目、省了多少人天」；只讲技术先进，老板不会买。

要点看数据能不能出域、用量、团队能力，小规模优先采购。

口述工艺参数敏感、调用量大才自建；否则采购更划算。我们内部是混合：敏感数据本地，普通问答用云。

要点做薄做标准接口，厚在治理和体验，不替业务做场景。

口述平台管接入、权限、监控、计费，不管具体业务逻辑；什么都做，最后变成外包团队。

要点看排队、空闲、碎片、任务规格、数据加载。

口述先看是不是卡在等数据、任务太小占整卡、还是分配了没用；知识库我们用的是云 API，没管过 GPU 集群。

要点按优先级和配额，关键任务可抢占，普通任务排队。

口述原则是先保知识库线上推理，再保实验；没有配额，谁嗓门大谁拿卡。

要点P50/P95 等待时长、超时率、按优先级分组。

口述只看平均会骗人，要看 P95 和高优任务的等待；普通任务等久一点可以接受。

要点预留实例、预热、模型缓存、按预测流量提前扩。

口述冷启动主要是加载模型慢；知识库这种常用模型常驻，突发流量靠排队兜底。

要点算子兼容、模型转换、性能评测、回滚英伟达。

口述产品上要提供国产卡适配清单和性能对比，不能只说「支持」；知识库跑不动要能切回云 API。

要点打包、版本、部署、灰度、监控、回滚。

口述上线不是传个模型文件；知识库换模型要有版本、灰度和回滚，不然出问题只能停服。

要点版本不可变、按流量灰度、指标红线、一键回滚。

口述每次发布留旧版本，先 5% 流量，指标掉了立刻切回；这套和普通系统发布是一个道理。

要点吞吐、延迟、显卡兼容、社区活跃度、运维成本。

口述我了解概念但没做过压测选型；知识库现在是直接调 DeepSeek 接口，没到自建推理框架这一步。

要点数据、权限、配额隔离，敏感场景物理隔离。

口述至少逻辑隔离加配额，涉及客户数据要物理隔离；混在一起，出一次泄漏就是大事。

要点要，但先做版本和评测，不要做花哨的编辑器。

口述知识库那套提示词我按版本存在 Dify 里，改完先跑 40 题评测集；没有评测，改一个字都不知道好坏。

要点输入分布、检索命中、工具错误率、模型版本变更、延迟。

口述平台要先告诉你是哪个环节变了：检索没命中、MES 接口报错，还是模型换了版本；只报「效果差」没法排查。

要点分层打点：网关、队列、推理、工具，对比同期版本。

口述先看是排队久了还是推理久了；知识库这边把检索耗时和生成耗时分开记，才定位得到。

要点每加一个 9，冗余和人力成本指数上升，按业务影响定。

口述内部查 SOP 99.9% 够用；涉及生产控制的才值得追 99.99%；我没算过具体差价。

要点复盘、监控告警、预案、演练、责任到人。

口述事故后不能只写报告；要补监控和回滚预案，还要拿一条工单演练一次，不然下次还是一样。

要点先限流保命，再弹性扩容，按业务优先级放行。

口述瞬间加机器来不及，先限流和排队；同时保工单查询，非核心的报表生成降级。

要点先问为什么绕：不好用、太慢、审批烦，把平台做成他们愿意用的。

口述靠行政命令禁止没用；把接入 LeanMES 数据做简单、资源给足，业务开发自然会回来。

要点找种子团队、砍复杂流程、做迁移支持、用数据证明省事。

口述先服务一个愿意用的车间，把它跑成样板；平台没人用，通常是入口门槛太高。

要点首次接入时长、文档完成率、工单量、留存、NPS。

口述我最看「业务开发第一次把 LeanMES 数据接进助手要多久」；超过半天，他就不想用了。

要点按用量、按配额、按项目，公开账单，设预算上限。

口述不摊成本，大家就无限用；我会按部门调用量和卡时出账单，超预算要审批。

要点季度对齐、场景驱动、公开优先级、留应急通道。

口述路线图不能技术自嗨；每季度拿 LeanMES、IWMS 的真实场景过一遍，急事留一个口子。

要点数据分级、来源登记、使用审批、血缘可追。

口述至少要能回答「这个模型用了哪些车间的数据、谁批的」；没有血缘，出了事说不清。

要点私有化部署、本地推理、数据脱敏、日志不外传。

口述数据不出域就只能本地部署，模型可以定期更新；涉及工艺参数的云端方案直接排除。

要点算；要脱敏、加密、限权、设保留期。

口述Prompt 里经常带客户名、料号甚至身份证；日志必须脱敏和限权，不能谁都能查。

要点资产登记、下载审批、水印、访问日志。

口述权重是核心资产，要像代码一样管；私有化交付时谁能下载、什么时候下载，都要留记录。

要点看交付场景和替代成本，商拍图、营销图最容易付费。

口述我没做过 AIGC 产品；从企业侧看，最先付费的是能省外包费的图，比如商品图和海报。我做过最接近的是用现成工具给内部培训做封面图。

要点能直接交付或只差少量修改，不同场景标准不同。

口述可用不是「好看」，是「改两下就能发」；要人工大改，就还是玩具。我做过最接近的是用生成图做内部培训封面。

要点专业用户付费意愿高、容忍度高；普通用户量大但要求简单。

口述先服务专业用户，能收到钱也能拿到真实反馈。我做过最接近的是给内部 IT 运维手册配图，改两版才能用，知道专业用户的修改成本在尺寸和文字上。

要点单点需求做工具，多角色协作做平台，先工具后平台。

口述先把一个高频动作做顺，再谈平台；我们知识库就是先做问答工具，没一上来做平台。

要点看决策成本，探索期多张，定稿期单张精修。

口述我会先给四张让用户选方向，选定后进精修；我给培训做封面时也是先出四张，全程抽卡用户会烦。

要点拆成主体、风格、构图、比例、参考图，能点选就不让用户打字。

口述用户说不清是正常的；我用现成工具时最烦只有一个输入框，得反复描述「要什么风格、多大尺寸」。

要点参考定风格、重绘改局部、姿态控构图，按创作顺序排。

口述我的理解是先定参考和构图，再局部改；我给内部培训图固定过模板和参考图，顺序乱了就得重来。

要点角色参考、固定种子、风格 LoRA、项目级资产。

口述一致性主要靠参考图和固定配置；同一套培训封面要求同一风格，我就是靠固定模板和参考图，不靠每次重写描述。

要点专业用户要，普通用户不要，用预设和高级模式分层。

口述默认藏起来，给「风格/场景」选项；内部工具给同事用时我就藏了 Prompt，只留几个风格按钮。

要点编辑要保真、可撤销；生成要探索、可筛选。

口述编辑是改已有资产，必须不破坏原图；我改过生成图上的字，字号和位置一动，整张就要重排。

要点批量出图、历史复用、参数预设、失败不扣额度。

口述抽卡不可怕，可怕的是每次重写提示词；我出培训封面时反复抽，最后把能用的配置存下来复用。

要点模板、批量导入、自动排版、人工抽检。

口述我没做过电商图流水线；做过最接近的是批量给 12 个应用做培训封面，只能靠模板加表格名单，一张张生成不叫流水线。

要点可用率、修改次数、采纳率、人工评分。

口述我会看「生成十张有几张能直接放进培训材料」；这比主观好看更实在。

要点保留旧版本、灰度切换、风格预设、提前公告。

口述升级不能一刀切，老用户要能留在旧模型；我自己用工具时就遇到过模型更新后风格变了，只能重新调。

要点项目空间、标签、版本、权限、二次编辑。

口述生成完就丢是浪费；我把用过的封面按部门存文件夹，下次改个字就能再用。

要点分档：快速草稿 + 高质量精修，让用户选。

口述先给低清快速版定方向，满意再出高清；我做培训封面就是这样，一上来等两分钟早走了。

要点按平台协议和当地法律，避免「保证原创」「版权归你」这类绝对话。

口述这块我只到能对话的程度；内部培训图我会避开真人肖像和客户 logo，不替法律做承诺。

要点数据来源审查、授权记录、侵权投诉通道、可追溯。

口述知识库文档我们要求正式发布版、来源可追；AIGC 训练数据这块我没碰过，只能讲授权链风险。

要点事前拦截 + 事后抽检，高风险场景双重。

口述知识库问答我要求答案带出处，等于事后可查；AIGC 内容审核我没做过，只能讲事前拦截加事后抽检。

要点实名、授权验证、水印、检测、禁止公众人物。

口述这块我只到能对话；哈泰克内部培训明确不许用真人换脸和拟声，这条是红线。

要点分个人/商用、明确范围、第三方素材单独授权、留免责边界。

口述内部使用我只用能商用授权的工具，发票和授权书留存；授权要写清能用到哪。

要点跟做一遍、看素材和返工点，不问「你想要什么功能」。

口述我跟过公司美工做一版宣传图，改了四轮；真实返工点在文案和尺寸，不在生成那一步。

要点插件、导入导出、图层和素材格式，别逼用户换工具。

口述我们用 Figma，生成图只能导出 PNG 再贴，工作流是断的；能进图层才有用。

要点项目空间、版本历史、评论审批、权限。

口述12 个应用的培训材料靠共享盘加版本号，没有审批就会拿错版；B 端一定要有版本和审批。

要点C 端要简单好玩，B 端要可控、协作、合规。

口述内部培训算 B 端，要求能审计、能追到谁改的；C 端我没做过，只能讲差异。

要点低频按张，高频订阅，团队按席位。

口述偶尔用的接受按张，天天用的愿意订阅；团队客户按席位更好卖，一张多少钱这里要你自己补一个真实值。

要点够跑通一次完整体验，不够长期白嫖。

口述免费额度要让用户做出一个能看的结果；我用免费额度试工具，能出两张可用图就够判断。

要点分层定价、缓存、小模型草稿、限流、企业包。

口述我没做过 AIGC 产品；做知识库时算过调用成本，草稿用便宜模型、终稿才用贵的。按张收费同样要分档，一张多少钱这里要你自己补一个真实值。

要点有没有人重复用、能不能进工作流、愿不愿意付钱。

口述看第二周还有没有人用；我给培训做封面那阵过了就没再开，说明它只是工具，不是日常。

要点高频、重复、规则模糊、信息分散的环节，错了代价可控。

口述MES 里填不良原因、查 SOP、对单据最值得做；涉及工艺参数和排产执行，我只做建议不做决定。

要点看有没有人现在就用土办法解决，有就真，没有就伪。

口述车间已经在用微信群问、用 Excel 记，那就是真需求；只是老板觉得酷，基本没人用。

要点看能不能更省步骤、更准、和系统数据打通，否则别做。

口述如果他用现成工具已经解决，我不会硬做；除非能少切一个 App、直接用 MES 里的数据。

要点谁的动作变了、谁要复核、出错了谁兜底，先小范围试点。

口述改 LeanMES 报工页面之前，我会先标出变了的三步：谁填、谁复核、出错谁兜底；影响面说不清就先小范围试。

要点先雪中送炭，解决最痛的；但锦上添花更容易做 Demo。

口述我会先做报工异常提醒这种天天用的，而不是给老板做一个大屏问答 Demo；送炭的活才能留住人。

要点入口前置、默认可用、不增加步骤，找种子用户带。

口述AI 按钮放在角落没人点；我的做法是嵌进他本来就要做的动作里，比如填报工时自动带出不良原因建议。

要点可编辑、可撤回、给依据、明确置信度。

口述AI 给的不良原因只是草稿，班组长能改能撤回；错的代价低他才敢用，一次错就罚钱没人用。

要点要，尤其是对外内容和高风险建议，内部辅助也要标。

口述必须标；LeanMES 里的建议要显示「AI 生成」，师傅知道才会复核。

要点保留旧入口、渐进引导、可切换、别一次改完。

口述老班组长习惯了原来的报工表单；我保留原按钮，旁边加 AI 建议，让他自己切。

要点高频辅助放主流程，探索型放侧边，别打断主任务。

口述报工时的建议放主流程，SOP 问答放侧边；主流程弹大窗口会打断干活。

要点省的时间 × 频次 × 人数，减去调用和运维成本。

口述我会先算每次填不良原因省几分钟（这里要你自己补一个真实值）、一天多少单，再对比调用成本。

要点同一批任务前后对比，控制任务类型和人员，说清样本。

口述30% 要有基线；我是拿同类接口改造前后对比，小样本体感，不敢说是严格实验。

要点先看采纳率，再看留存，NPS 是补充。

口述LeanMES 里建议出来了，有多少班组长真的点了采纳；没人采纳，留存都是假的。

要点先看曝光和使用率，再看使用后的效果。

口述先看 LeanMES 里这个功能有没有曝光；没人用就改入口，用了没效果才回头改提示词。

要点预先定假设、指标、样本和停止条件，留对照组。

口述上线前写清「两周内 LeanMES 里采纳率低于多少就判失败」；不然怎么说都有理。

要点看数据敏感度、用量、团队能力、迭代速度。

口述内部知识库我选 API + 本地向量库（Dify + Qdrant + DeepSeek），快且够用；数据不能出域才考虑本地开源模型。

要点小模型分流、缓存、压缩上下文、减少调用次数。

口述先砍不必要的调用，再把不良原因分类换小模型；还不行就只在高频工单上开。

要点看场景容错和竞争窗口，能兜底就先上，不能就等。

口述辅助填原因可以先上，边用边改；涉及改工单状态，效果不够就不上。

要点本地部署开源模型、内网向量库、脱敏，接受效果略降。

口述工艺数据不出内网，就只能本地部署开源模型；知识库这套云端方案直接排除。

要点结构化输出、校验、重试、模板兜底、人工确认。

口述我要求它按固定字段输出 LeanMES 的不良原因代码，代码校验不过就重试；再不行给模板。

要点先解决他的痛点、不增加负担、让他看到结果。

口述别一上来讲平台，先帮 LeanMES 把报工查询这个活干掉；他尝到甜头才会接。

要点按业务价值排，先做能复用的，拒绝一次性需求。

口述两个人只能做通用能力，不做单车间定制；排期公开，谁急谁找老板。

要点先找共同目标、走正式数据接口、明确责任，必要时上升到老板。

口述数据打不通多半是责任问题；我会先把口径和责任人定下来，再谈接口。

要点上线前记录人工处理时长、错误率、处理量，同一口径对比。

口述上线前先测一周 LeanMES 人工填原因的时长和错误率，再上 AI，同一口径对比。

要点产品负责指标，业务负责反馈，算法负责模型，要有人固定看 bad case。

口述上线不是结束；我定每周看一次 LeanMES 的 bad case，不然三个月后就没人管。

要点拆成场景清单、优先级、试点、模板，不搞一次性大工程。

口述全面 AI 化不是每个系统加聊天框；我先选报工、查 SOP、对单据三个高频场景做样板。

要点+AI 是给现有流程加能力，AI Native 是流程围绕模型重新设计。

口述MES 加个问答是 +AI；如果从开工单开始就由模型理解意图、自动编排，那才是 Native。

要点高风险仍要人确认，低风险会变成自动触发。

口述查工单、提醒这类会变成自动；改工单状态和排产执行，按钮还会在，只是点的人变了。

要点统一入口、统一数据、统一评测，不为每个部门做一个。

口述每个车间一个助手最后没人维护；我做统一入口，场景做成配置。

要点高频吗、规则模糊吗、错了能兜底吗、数据够吗、不用 AI 能不能做。

口述五个问题有一个答不上来就不上；LeanMES 里很多需求用下拉框和校验就能解决。

要点Native 是流程围绕模型重写，加对话框只是给旧产品开个口子。

口述对话框是入口，不是 Native；LeanMES 查数助手能自己选表和工具，才算摸到一点边。

要点从功能菜单变成任务编排，要有澄清、预览、确认。

口述结构会从「菜单-表单」变成「说目标-看方案-确认」；LeanMES 里查工单就是先说工单号再看结果。

要点低风险、高频、边界清楚的场景可行，复杂业务仍需要界面。

口述查数、提醒可以没有界面；排产、质检这种要看清细节，界面还得在。

要点数据、流程、协作、权限；如果只剩空壳，说明产品没价值。

口述LeanMES 去掉问答，工单、报工、库存这些表和流程还在跑；AI 只是上面一层，不是产品本身。

要点一个真实任务闭环：输入意图→执行→可检查结果。

口述不是聊天框，是能完成一件真事；哪怕只做「查一个工单并给出处」。

要点先猜一个合理默认，再给少量选项确认，别一次问十个问题。

口述用户说不清查什么，我先按「本车间、本周」给默认，再问一个工单号；追问太多他直接关。

要点给候选、给依据、可编辑、可重来，标出不确定的地方。

口述查数结果要能点回 MES 原始工单和 SQL；只给一个数，班组长不敢用。

要点识别变更点，回滚相关步骤，保留已确认部分。

口述用户换了工单号，我只重跑查询那一步，不把整段对话推翻；状态存 JSON。

要点高风险、不可逆、信息缺失关键项时问，低风险可先猜再让改。

口述涉及单据和对外内容必须问；查资料这种先猜，错了再改。

要点统一意图层和任务层，入口只是采集方式。

口述不管从钉钉还是 LeanMES 进，最后都归到同一个查数任务模型；各做一套维护不动。

要点给可成功的替代任务、明确原因、人工兜底。

口述第一次查不到，要马上给一个能查到的例子，比如用已知工单演示；不然他不试第二次。

要点给出处、给计算过程、给对比，允许复核。

口述查数必须能点回 SQL 和原始单据；只给一个数，业务不敢用。

要点没有进入日常流程、价值不稳定、替代方案更顺手。

口述留存差不是模型差，是没进日常流程；LeanMES 里用完一次查询，下次他还是翻菜单。

要点看期望管理，稳定解决小问题会依赖，过度承诺会失望。

口述定位成查数助手，他会越来越依赖；宣传成能替他排产，第二次就失望。

要点直接承认、说明原因、给补救、说清下次怎么避免。

口述不要说「模型有时会这样」；要说清是工单号错了还是 MES 没同步，怎么补。

要点使用产生反馈，反馈改模型和产品，产品再带来使用。

口述飞轮的前提是反馈能回收；LeanMES 里班组长改了 AI 给的不良原因，这个改动要能存下来，下一版提示词才有的改。

要点规则、专家经验、公开数据、少量真实样本。

口述先用老师傅的规则跑，再拿真实问题补；等数据齐了再上线，永远上不了。

要点分类、定位是数据/模型/交互问题、排优先级、回归验证。

口述反馈不能只登记；要分到是 MES 数据、提示词还是入口问题，改完用同一批工单验证。

要点到「减少重复输入」为止，过度个性化会让用户不安。

口述记住他的常用车间、常用报表就够；记住太多私人信息，反而吓人。

要点最小必要、可见可控、本地优先、明确授权。

口述个性化只用他的常用车间和报表，不碰工资和身份证；默认收集一切迟早出事。

要点指标可定义、可验证、可控变量时才可行。

口述省工时、降差错可以按结果；效果受客户数据影响太大，就不好按结果。

要点分层定价、缓存、小模型、额度限制、企业包。

口述成本线性涨，定价要分档；LeanMES 这种重度用户必须有更高档位，不然越用越亏。

要点场景化 Demo、免费试用、口碑、渠道。

口述靠一句话说清解决什么，比如「报工查数不用再翻五个菜单」；Demo 要用真工单。

要点会，所以要限额度、限能力、防风控。

口述免费额度按账号和设备限制；不限，几天就被薅光。

要点抽象模型层、版本灰度、评测回归、保留旧版。

口述产品不能绑死 DeepSeek 一个版本；要有切换层，升级前先跑那 40 题评测集。

要点先做单点工具，再做复用能力，最后做平台和生态。

口述LeanMES 查数助手没人天天用，就别谈平台；先把一个车间用起来。

要点跟踪能力边界，提前设计场景，但不把路线押在未发布的能力上。

口述模型进步会打开新场景，但路线不能等它；先做现在能查的工单和库存，留好扩展点。

要点用评测集把「能做/不能做」变成可验证的边界，共同定验收。

口述不要争论感觉，拿 50 个真实 case 跑一遍，边界就清楚了。

要点任务完成、留存、付费、单位成本，分阶段定。

口述早期看有没有人重复查，中期看车间留存，后期看省了多少人天。

要点产品、算法、工程、数据、设计，小团队闭环。

口述最小配置是产品加一个能写后端的全栈；没有懂 MES 数据的人，飞轮转不起来。

要点跟一条完整业务链、认全主数据、找三个老师傅。

口述我会跟一张订单从接单到出货走一遍，把工单、物料、工序、质检弄清楚；再找计划、车间、仓库各一个老师傅问到底。

要点去现场看等待、返工、找人和重复录入，用数据验证频次。

口述痛点不是访谈出来的，是跟班看出来的；我会记录一个班组长一天被打断多少次。

要点不能，缺企业数据和口径，只能做通用表达。

口述通用模型不知道你们的料号、工序和良率口径；必须接 T100 和 MES 的数据和知识库。

要点数据散在多个系统、口径不统一、历史数据脏。

口述制造业的壁垒不是没数据，是数据在 T100、MES、WMS 里对不上；谁能把口径统一，谁就有优势。

要点先辅助，高风险环节不替代；替代的是重复动作，不是责任。

口述在 LeanMES 现场我说的是帮班组长少查一次工单，不是替代他；真要动人，先说清动的是重复动作，责任还在人。

要点按后果分级：提示、建议、需确认、禁止自动。

口述涉及安全、工艺参数、对外承诺的，只提示不决策；普通查询可以直接答。

要点版本化、来源标注、定期复核、失效下线。

口述工艺文件一改，知识库要跟着更新；答案带版本和出处，过期内容自动标记。

要点访谈、案例化、规则化、评测验证。

口述把老师傅的判断拆成条件和动作，先做规则，再用案例验证；直接让模型学，学不会。

要点术语表、同义词、查询改写、few-shot。

口述先把车间黑话整理成词表，检索和提示词都用；不建词表，模型永远答偏。

要点人工标注集的答案正确率、引用准确率、专家复核通过率。

口述我会用工艺员盲评的通过率，而不是模型自评；知识库答案要能点回 SOP 原文。

要点数据本地化、留痕、人工复核、不得自动决策。

口述合规是底线；该留的操作记录、该人的确认一个不能省，不能让模型绕过改工单。

要点看是否人工确认、是否明确提示、是否有依据，产品要留痕。

口述只要是人确认后执行的，责任在人；产品要把依据和风险提示清楚，比如标出 SOP 版本。

要点最小必要、脱敏、权限、审计、不出域。

口述客户名、联系方式这类不进模型上下文；要查就查脱敏后的结果。

要点先确认适用法规、找法务和安全、按流程报备。

口述这块我没实操过；原则是先问法务再上线，比如 MES 数据出域这种先报备。

要点高风险场景必须能解释，低风险可弱化。

口述排产建议要能说清为什么这么排；只是查资料，给出来源就够。

要点抽象通用流程、做成配置、写实施手册、培养第二批。

口述做完一个客户，我会把定制的部分标出来，能复用的抽成模板；不能复用的不硬推。

要点先看流程是否合理，不合理的借机改，合理的改产品。

口述我不会一味迁就现状；先把 LeanMES 流程摊开，能标准化的标准化，不能的做配置。

要点找种子、减负、培训、让班组长带头。

口述一线抵触通常是多填了一步；先做到不增加操作，再谈改变习惯。

要点看数据敏感度、客户规模、运维能力。

口述制造业客户大多要私有化；SaaS 适合小客户和标准化场景。

要点上线前写清功能、数据、性能、使用率，双方签字。

口述验收标准必须在合同里，不在 PPT 里；我会把「报工查询准确率、响应时间」写成清单。

要点按业务价值定价，不按 token，客户算的是省了多少钱。

口述通用产品按用量，垂直产品按「替了几个统计员、少了多少停机」；LeanMES 的定价锚点不一样。

要点指标可验证、变量可控时可行，否则容易扯皮。

口述省工时可以按效果；良率受设备和物料影响，不能都算在 AI 头上。

要点核心标准化、外围配置化、定制单独收费。

口述每个客户都说自己特殊；我的线是主干不改，特殊需求做插件。

要点找行业集成商、给培训和分成、做认证。

口述垂直行业靠集成商比自己铺销售快；但要管好 IWMS、MES 的交付质量。

要点懂业务的产品、能落地的算法、懂集成的工程。

口述最缺的是既懂车间又能把需求翻译成 MES 字段的人；纯算法和纯销售都做不成。

要点尊重经验、给回报、共同定义问题、把经验产品化。

口述哈泰克的工艺员怕被替代，要让他参与定规则、看到自己的经验被用；只来抄，第二次就不理你。

要点流程和数据是壁垒，模型会商品化。

口述模型大家都能调，真正难的是把 LeanMES 流程跑通、把 T100 主数据攒干净。

要点抓不变的需求（效率、质量、成本），别绑单一品类。

口述行业会波动，但降本增效一直在；产品要能换场景，不死绑一个工艺。

要点痛点强度、付费能力、数据可得、竞争格局。

口述放到制造业，我会先看这个厂有没有 T100/MES 数据、谁付钱、痛点是不是每天都在发生；四个缺一个就不做。

要点细分场景、本地服务、深度集成、响应速度。

口述巨头做通用平台，你做它不愿进的车间；离现场近、能改字段就是优势。

要点高频、重复、要查很多资料、判断不复杂：计划、采购、仓储、客服、人事。

口述我会先做计划员和仓管，他们一天到晚在查数、对单、问人，最容易被帮到。

要点跟班、看系统日志、统计重复操作，不问「你想要什么 AI」。

口述我会跟半天班，记录他打开几次 LeanMES、问了几次人、填了几张单；高频动作自己会浮出来。

要点说明有真实需求，也说明有数据风险，堵不如疏。

口述我不会一刀切禁；先看他们用它写什么，再把高频场景做成接 LeanMES 数据的工具。

要点让他演示现在怎么做，拿真实单据走一遍，再翻译成需求。

口述业务说不清很正常，我让他用 LeanMES 演示一遍现在怎么查；看他卡在哪比问十句准。

要点通用能力采购，涉及内部数据和流程的自建或二次开发。

口述知识库、查数这种要接内部系统，得自建；通用写作、翻译直接买。

要点按频次、影响面、可复用性、业务负责人支持度排。

口述我会优先做多个车间都用得上的，比如报工查询，不做只服务一个人的。

要点多一步操作、入口太远、答不准、怕担责。

口述在 LeanMES 里，AI 入口如果不在报工页面、要多点两下才能进，班组长就不会用；所以我把它做成表单旁边的一个按钮。

要点需要，但标准是「少一步、少思考」，不是好看。

口述内部产品不用花哨，但必须比翻 LeanMES 菜单少一步；多一步推广就失败。

要点放进他已经在用的系统/IM，不新增 App，在动作发生的地方给建议。

口述车间用钉钉，我就把机器人放钉钉；让他再装一个 App，基本不会用。

要点先做最小闭环，快速上线，再迭代；内部场景容错相对高。

口述我先做一个能查工单的最小版本，两周内给车间用；做半年再上线，需求早变了。

要点种子用户→小范围→部门推广→全公司，每步有样板和数据。

口述先找一个愿意配合的班组长，把他的效果做出来，再拿去说服别人。

要点有准入、有责任人、有版本、有失效机制，宁少勿滥。

口述什么文档都往里塞，最后召回全是过期文件；我会先收高频、正式的文档。

要点检索前做权限过滤，按部门/角色打标签，不能先检索再判断。

口述权限要在检索层就过滤，不能把敏感段落交给模型再让它别说；模型靠不住。

要点版本号、生效日期、失效标记、定期清理，答案显示版本。

口述每份文档带生效日期，过期自动降权；答案里标版本，师傅能判断。

要点把问答、处理过程结构化成案例，有人审核后再入库。

口述老师傅在群里答过的问题，整理成问答对入库；不整理，人一走经验就没了。

要点脱敏后用，或本地部署，客户数据、工艺参数不出内网。

口述一般问答可以调外部模型，但要把敏感信息去掉；核心工艺数据必须本地。

要点用处理时长、频次、人数算，节省工时是估算，要说清假设。

口述我会记录同一类报工查询前后耗时；单次省多少分钟这里要你自己补一个真实值，省下来的工时是估算。

要点同类岗位/班组分组，同口径对比，控制任务类型。

口述找一个没用助手的班组做对照，跑一个月同口径对比；没有对照，数据说服不了人。

要点看使用后是否真的减少了动作或时间，防止「点着玩」。

口述要看它有没有替代原来的步骤；如果只是多点开一个聊天框，LeanMES 使用率高也是假的。

要点拆到人天、物料、停机、差错，逐项乘，假设要业务确认。

口述一千万不能拍脑袋，要拆成人天、呆滞物料、停机、差错；每一项多少钱这里要你自己补一个真实值。

要点内部提效看「有效使用率 + 节省工时」，不是调用量。

口述我会用「每周有多少班组长真的用它查完工单」，调用量可以刷，使用人数刷不了。

要点先做他的痛、让他看到结果、把责任变成共同指标，必要时找老板。

口述不配合通常是没看到好处；先帮他把最烦的报工查询干掉，再谈推广。

要点会，要明确「辅助不替代」，先减负不裁员。

口述在 LeanMES 推广时，一上来就说替代多少人，班组长不会配合；我会说清是帮他少加班，不是让他走。

要点培训、模板、种子用户、权限下放，让业务自己改提示词。

口述我会在每个车间找一个愿意学的人，手把手带他配一个查询场景；他学会后会带别人。

要点统一标准、分部做配置，不为一地改主干。

口述总部定 T100 主数据和口径，分部做局部配置；每个分部都定制，系统没法维护。

要点场景申报、数据合规评审、技术评估、试点验收。

口述不是谁想上就上；先报场景和数据来源，评审过了再给一个车间试点。

要点统一入口、统一账号权限、统一知识库和模型层。

口述每个部门一个机器人最后没人维护；我做统一入口，场景做成配置，账号统一走 Casdoor。

要点统一能力层 + 场景市场 + 数据闭环，业务自助。

口述理想状态是业务自己能在平台上配场景，信息中心管模型、数据和权限。

要点用业务语言：省了多少人天、少了多少差错、快了多少，给对比。

口述老板不关心模型，关心省了什么；我拿 LeanMES 报工查询的前后数据说话。

要点先做小场景证明，再谈平台；把投入分期，降低一次性风险。

口述算不清就先别要大预算；用一个车间的结果换下一步资源。