Question 1

财报 PDF 如何自动提取表格？

Accepted Answer

这类需求的难点不在"识别文字"，而在"还原结构"。滚水科技在做 OCR 和文档处理类 AI 项目时，会专门处理跨页表、合并单元格、脚注、币种单位、年份列、附注编号这些"看起来不起眼但抽错就一片错"的细节，最终输出能直接接入业务的结构化数据。

实际落地一般会按这几步推进：

版面 + 表格区域识别：先把页面切分成正文、表格、图、脚注等区域，再单独把表格定位出来。复杂排版下，这一步直接决定后面能不能抽对。
结构还原：处理合并单元格、跨页续表、表头层级、空白列、注释挂角等情况。我们一般会让模型给出多版候选结构，再由后处理规则挑出最合理的一版。
字段标准化：把"营业收入"和"营业总收入"、"亿元"和"千元"、"2023 年"和"本期"这类同义不同写法的字段统一口径，避免后续分析时口径混乱。
业务校验：把合计、占比、同比环比这类公式拿来做反向校验，发现疑似抽错的行立即标黄给人工复审。
输出形态：可以直接出 Excel、CSV、入数据库，也可以经接口推送到客户已有的 BI 或分析系统里。

工程上，我们会建议客户准备 20–50 份典型样本（覆盖不同年份、不同行业、不同排版），让我们先跑一轮基线测试，把准确率、误抽率、漏抽率量化出来。这样在签合同前，双方对"目前能做到什么程度、需要多少投入达到目标"就已经有共识，避免做完了才发现效果不达标。

这种"先做小样本基线、再决定投入规模"的方式，是滚水科技在多个 AI 与 OCR 项目里都验证过的做法，能把首期风险压到很低。

Question 2

大模型算力成本怎么估算与优化？订阅API还是自建？

Accepted Answer

算力成本由调用量、模型规模、上下文长度、并发要求和 SLA 共同决定。订阅 API 起步省心，规模化后费用容易飘；自建或租 GPU 单价更可控，但要承担运维和工程成本。滚水科技的建议是先用真实业务量做几周压测，把账单拆细，再决定走哪条路，不要在没有数据的时候做选型。

成本估算可以从这几个维度入手：

日均调用量：日活、每用户对话数、每次对话平均轮次、每轮的 prompt + response token 量。这四个数乘起来就是日均 token 量，再乘以模型单价，就是基础 API 费。
上下文长度：长上下文（10K+ token）会让单次调用费翻倍甚至数倍。知识库问答类系统要算上 RAG 召回片段的开销，而不只是用户问话本身。
峰值并发：客服类、导购类、营销类应用峰谷差异大，按峰值买算力会很贵，按均值买又会爆。需要做异步队列、缓存、分级模型路由。
附加成本：embedding、rerank、向量库、监控、日志、人工标注、多模型路由都不便宜，做预算时要单独列。

订阅 API 适合：调用量不大、试错期、对模型最新能力依赖大的场景；自建或私有化适合：调用量稳定、数据敏感、对成本曲线可预测要求高、有运维团队的场景。两者其实不是互斥的，很多客户最终走的是混合方案——把高频简单任务路由到小模型或本地模型，把疑难任务走旗舰 API。

优化常见的手段包括：缩短上下文（只塞真正相关的片段）、做 prompt 缓存、做语义缓存（同义问题直接命中历史答案）、用小模型预筛大模型生成、用流式输出降低用户等待感、压低 temperature 减少重试。这些组合下来，单次成本通常能从初版砍掉 40%–70%。

滚水科技在做 AI 项目时，会先帮客户跑一两周影子流量，把真实业务量的成本曲线测出来，再给出"订阅 / 混合 / 私有化"的对比方案。这样选型有数据支撑，签合同前双方对账单就有共识，避免后期为成本扯皮。

Question 3

电池行业 AI 智能助手怎么做？

Accepted Answer

电池行业的 AI 助手不适合一上来做"全能客服"，更适合先从高价值的知识场景切入。结合滚水科技在 BMS 电池智能管家、新能源智能充换电、无人机智能充换电等电池相关项目的实际经验，我们一般会先把内部资料做结构化、再以检索增强问答的方式快速跑起来。

落地路径上，我们通常推荐这样几步：

从知识密集场景起步：售后故障辅助判断、BMS 文档检索、测试报告查询、工艺资料问答、内部培训，这些都是"问题集中、答案有据、风险可控"的场景，更适合作为第一阶段切入。
打通数据来源：把分散在 PDF、Word、Wiki、群聊里的标准、手册、测试报告、历史案例做统一治理，标好版本、生效日期、适用产品系列，避免出现"几份文档对不上"的情况。
接入业务系统：让 AI 助手能查到 BMS 告警、电池 SOH、循环次数等运行数据，把"问知识"和"问数据"放在同一个入口，业务用起来更顺。
结合权限与人工兜底：销售、售后、工艺、生产看到的范围不同，权限要先在系统层划清；模型把握不大的问答走人工复核，再把人工答复回灌到知识库。

我们的经验是：电池行业里"安全相关、追溯相关"的问题特别多，模型不能只看"答得像不像"，必须给得出引用、给得出版本号、给得出条款来源。一旦答案可追溯，团队才敢真正把 AI 助手放到日常工作里用。

前期客户需要配合的内容一般包括：现行内部资料、典型问答样本、相关业务系统接口或导出数据、岗位权限划分，以及一两位熟悉业务的同事帮忙在试点期校对答案。资料齐了之后，我们一般在四到六周内可以交付一个小范围可用版本，让团队先在熟悉的场景里跑起来，再逐步往核心业务延伸。

Question 4

订单 OCR 识别系统怎么开发？

Accepted Answer

订单 OCR 系统真正有价值的地方不只是"识别准不准"，而是"识别 + 校验 + 入库"的完整链路。滚水科技做这类项目通常会先打通上传入口、OCR 引擎、字段抽取、规则校验、异常复核、自动入库这几环，让人只处理异常订单，而不是从头到尾盯着 AI 看。

完整开发思路一般包含几个模块：

上传入口：图片、PDF、Word 都要支持，微信文件、企业微信文件、邮件附件最好都能直接转过来。客户最常见的场景是"业务员把客户发来的订单截图丢进群里"，所以我们一般会做企业微信/钉钉机器人，群里 @ 一下就自动入库。
OCR 与版面分析：单纯 OCR 只能拿到文字位置，订单还要识别表头、表格、产品明细、合计行的结构。我们一般用通用 OCR + 版面分析模型 + 业务字段抽取（LLM 或规则）三层来组合，根据客户订单模板的差异调参。
字段抽取与映射：把识别出来的产品名、规格、数量、单价匹配到客户主数据。这一步最容易出问题——客户写"小瓶可乐 12 罐"，系统里叫"可口可乐 330ml 听装"，要靠模糊匹配 + 历史映射表 + 业务规则一起兜底。每错一次都要能让运营手工纠正，下次自动学会。
规则校验：数量是否在客户常规订单范围、价格是否符合合同价、合计是否一致、客户是否有信用额度、库存是否足够。这层做得细，后端业务系统的脏数据会少很多。
异常复核界面：识别结果和原图并列展示，运营点几下就能改字段、加规则、确认入库。绝大多数 OCR 项目最后效果好不好，就看这个界面顺不顺手。
自动入库与回执：校验通过的订单自动写 ERP/进销存/订单系统，并把回执（订单号、预计发货时间）回传给业务员或客户。

落地节奏上，我们建议先选三到五个出货量大的客户做样本，把他们的订单模板和品类映射跑顺，再逐步扩到全量客户。一上来就想"识别所有客户所有格式"，反而很难收敛。滚水科技在 AI 落地和企业管理系统这块都有积累，订单 OCR 通常会和现有 ERP、WMS 一起规划，把"识别"做成整个订单链路里的一段，而不是孤立的工具。

Question 5

高保密要求的长文档处理如何用 AI 落地？

Accepted Answer

这类场景的核心从来不是单纯追求速度，而是要在效率、准确性和保密性之间找到平衡。滚水科技在做企业级 AI 项目时，会优先考虑私有化部署、最小权限、可追溯日志、人工复核等关键控制点，确保敏感文件始终留在客户可控范围内。

通常我们会从几个方向同时切入：

部署形态：默认私有化或专属云部署，模型与数据全程不出客户网络；如果客户希望走云端混合，也会用接口隔离、字段脱敏、临时密钥等方式控制范围。
能力拆解：把文档比对、条款检索、术语一致性、格式校验、表格抽取、信息摘要、风险提示拆成独立模块，每个模块独立评估准确率与误报率，方便业务侧逐步信任。
权限与审计：到模块级、文件级、字段级三层权限，每一次问答与导出都留可追溯的日志，方便后续做内部审计与合规复核。
人工复核入口：模型把握不大的输出会强制走人工复核，并把人工修正过的结果回灌到知识库，让系统越用越稳。

实际落地经验上，我们一般建议客户先选两三个"高频但风险可控"的场景试点，例如内部文档差异比对、引用一致性核查、关键指标抽取，等团队建立了信心、流程也跑顺了，再扩展到更核心的业务节点。这样既能让效率提升尽快显现，也能避免一开始就把模型放到高风险位置。

前期客户需要配合的内容主要是：典型文档样本（可脱敏）、现行的内部审阅规则、岗位权限划分、对接接口人，以及保密协议与数据使用边界的明确约定。资料齐了之后，滚水科技通常在三到四周内可以交付一个小范围 Demo，让团队先评估效果，再决定下一步要不要扩大投入。

Question 6

工厂库存管理系统如何接入 AI 预测？

Accepted Answer

库存 AI 预测能不能用得稳，前提是历史数据先站得住。出入库、订单、采购周期、安全库存这些数据如果质量不行，模型再好也只是输出漂亮的错误。我们一般建议从"AI 给建议、人工拍板"开始，先做辅助决策，跑稳了再扩大自动化范围。

落地一般会按这几步走：

数据盘点：先把现有 WMS / ERP 里的出入库流水、订单历史、采购到货周期、季节性波动、促销活动记录、停产/换型事件这些数据拉出来，看连续性、完整性、字段标准化程度。这一步往往要花两到四周，但跳过它后面预测准确率会全程吃苦头。
场景拆分：库存 AI 预测不是一个模型搞定所有 SKU。快周转、慢周转、季节品、新品、长尾品，预测方法完全不同。我们一般按"SKU 周转特征"做聚类，分组训练或分组用不同算法。
辅助决策上线：模型输出"建议补货量、建议补货时点、异常波动告警"，让采购或仓管同事在他熟悉的工作台里直接看到建议，可以一键采纳或修改。这个阶段不要让 AI 直接下采购单，先用 8–12 周积累人工反馈。
效果回看与迭代：每周看准确率、缺货次数、积压金额、人工调整比例的变化。准确率稳定后，再选若干"风险可控、规则清晰"的 SKU 走自动补货。
逐步扩范围：从一个仓、一类品逐步往外铺。一开始就铺全工厂的项目，往往跑不下去。

技术选型上没必要追新模型。常见的 ARIMA、Prophet、XGBoost、LightGBM 在大部分场景都够用；只有当数据量大、特征复杂、有明显非线性时再考虑深度学习。我们更看重的是特征工程做得好不好——把采购前置期、批次起订量、安全库存策略、订单波动、节假日、营销活动这些业务因素显式加进模型，效果会比换大模型来得明显。

滚水科技在智慧赋能-工厂管理数字化等项目里跑过完整的"业务数据采集 + 系统集成 + AI 辅助决策"链路，习惯先把数据通道理顺，再让 AI 在上面发挥。客户配合提供历史业务数据导出、现行库存策略文档、WMS/ERP 的对接方式或导出接口，一般八到十二周可以交付一版能在小范围试跑的预测系统。

Question 7

工作流型 AI 智能体是什么？和普通聊天机器人有什么区别？

Accepted Answer

普通聊天机器人更像"会回答的客服"，工作流型智能体更像"能按步骤办事的员工"。前者只管聊得通顺，后者要把"检索 → 校验 → 调工具 → 生成结果 → 兜底转人工"这些关键节点固化成可配置流程，每一步都能追溯、可观测、可单独调整。

两者的差别用一个具体例子最容易理解。假设要做一个"电商售前导购"。

普通聊天机器人的做法：把商品资料喂给模型，让它根据用户问题自由回答。优点是写得快、改得快；缺点是没办法保证它只聊商品、不报错价、不夸大功效、不漏库存校验，更别说让它真去下单。

工作流型智能体的做法：

用户发问 → 先做意图识别（咨询商品？询价？下单？售后？）
命中"商品咨询" → 调商品检索工具拉真实数据
检查库存接口 → 没货走"缺货话术"分支
调推荐工具 → 结合用户画像出 3 个候选
由模型负责把数据组织成自然语言话术
用户表达购买意向 → 走"下单工具"调起加购或支付流程
任何一步失败 → 转人工，并留全链路日志

每一步都是显式节点，每个节点的输入输出、调用工具、失败兜底都能单独配置和监控。这样系统就具备了三个普通聊天机器人没有的能力：

可控：能在系统层强制约束模型，比如"只能聊本店商品、不能承诺到货时间、价格必须取自接口"。
可验收：每个节点的成功率、调用耗时、失败原因都能看到，问题能定位到具体环节，而不是"模型答不好"。
可迭代：哪一步效果差就改哪一步，不用每次都从头调整 prompt。

适合用工作流型智能体的场景，一般是"要办事、不只是聊"的——客服转工单、订单处理、内部审批引导、设备故障辅助判断、营销线索分级等。纯闲聊或开放问答用普通聊天机器人就够了。滚水科技在做企业类 AI 项目时，绝大多数会走工作流编排，因为客户最终要的是"可上线、可验收的系统"，而不是一个 Demo。

Question 8

你们目前做过哪些智能体或 AI 助手应用方向？

Accepted Answer

滚水科技不卖固定模板的智能体产品，更多是按客户业务场景定制落地。从过往项目分布看，做得比较多的方向包括知识库问答、内部业务助手、专业资料处理、IoT 设备结合的智能助手、以及面向 C 端的 AI 应用。每个方向背后都有真实跑过的客户案例可以参考。

按类型大致可以分成几块：

企业知识库 / 内部问答助手：把企业内部的标准、手册、操作流程、过往问答整理成 RAG 知识库，员工在企微、钉钉、飞书或 Web 入口里直接问。重点在引用回链、版本管理、权限隔离。
专业长文档处理助手：处理体量大、术语严、口径要求严的资料，能力包括结构化抽取、版本比对、术语一致性检查、表格抽取等。我们在全语通等项目里跑过多语言术语对齐和质量校验。
设备 / IoT 结合的智能助手：让 AI 助手能查 BMS 状态、SOH、循环次数、运行告警等设备数据。BMS 电池智能管家、新能源智能充换电等项目里我们都做过这类"AI + 设备数据"的方案。
行业垂直 Agent：根据具体行业的工作流，把 AI 嵌进特定业务环节。例如 AI 智能招聘系统把简历解析、初筛、人岗匹配做成完整流水线。
C 端 AI 产品：教育、社交、电商方向的智能体应用。全语通是一个用 AI 做中文学习的完整 C 端产品，从内容生成、对话引导到学习进度追踪都涉及。
OCR 与文档自动化：订单识别、发票识别、PDF 表格抽取、扫描件结构化、招投标资料处理等。

我们的特点是同时做系统和 AI，不是只挂一个聊天接口就交付。客户往往需要把 AI 跟现有 ERP、CRM、IoT、订单系统对接，这正是我们擅长的部分。如果你有具体方向想了解更多细节或看完整 Demo，可以告诉我们场景，我们再挑相关案例展开聊。

Question 9

企业 AI 智能助手怎么做？

Accepted Answer

企业 AI 助手不是把 ChatGPT 套个企业皮就能用的。我们一般会先帮客户挑一两个高频且容错率较高的场景做试点，把资料治理、检索增强、权限边界、人工兜底跑顺，再考虑扩展到更核心的业务里。

企业里能做 AI 助手的场景其实很多：内部知识问答、政策解读、销售辅助话术、客户支持初筛、合规文档检索、运营操作引导、IT 报修、HR 答疑。但不是每个都适合一上来就做。我们的判断标准很简单：

问题集中：每天大量重复问的事，AI 才有收益空间。
答案有据：背后有清晰的文档、流程或数据可以引用，模型不需要"自由发挥"。
错答可控：万一答错了，影响在可接受范围内，不会引发合规或业务事故。

满足这三点的场景，是 AI 助手最容易"上线即可用"的地方。

技术上，我们一般这样搭：

把内部资料按文档类型做结构化清洗，标好版本号、生效日期、适用范围；
用检索增强（RAG）让模型必须基于命中的内容回答，每个答案都带出处；
把权限分层做在系统层，不依赖提示词；
接到客户已有的入口里（企微、钉钉、飞书、Web 工作台、小程序），让员工不用换工具；
留好日志和反馈机制，把人工修正过的答案持续灌回知识库。

滚水科技在 BMS 电池智能管家、AI 智能招聘系统等项目里都用过这套思路。我们的经验是，第一期把范围做小一点，让客户内部团队真切感受到"AI 答得准、有依据、用起来顺手"，后面再扩展才有底气；反过来，第一期就铺得太宽，最后往往哪个场景都没跑顺，团队对 AI 也会失去信心。

Question 10

企业 AI Agent 系统落地需要哪些模块？

Accepted Answer

一套能在生产里跑稳的企业 Agent 系统，至少要包含模型层、知识层、工具层、编排层、对话层、监控运维层这六块。各家方案细节不同，但少了哪一块都会在上线后吃苦头。滚水科技的做法是先按这套骨架画清楚边界，再决定每块自研、复用开源还是接第三方。

各模块大致负责的事情：

模型层：选型（开源/闭源、规模、推理成本）、私有化部署或 API 调用、Embedding 模型、多模型路由。这一层主要关心成本和上下游适配，没必要追新。
知识层：把企业内部资料做结构化、做向量化、做版本管理，支持检索增强（RAG）。这一层往往最难，但对答案质量影响最大。
工具层：Agent 实际调用的能力，比如查订单、查库存、发邮件、生成报表。每个工具要写清楚输入输出、权限、失败处理，不能让模型乱调。
编排层：决定一次对话该走哪几步、串哪些工具、什么时候转人工。复杂场景里我们会用工作流型编排，简单场景用对话型就够了。
对话层：上下文管理、意图识别、人格设定、敏感词过滤，以及前端 UI（Web、小程序、企微/钉钉/飞书机器人）。
监控运维层：对话日志、token 消耗、错误率、工具调用成功率、用户反馈，配合定期巡检。一旦缺这一层，问题出现时根本定位不到。

实际项目里，最容易被低估的是知识层和监控运维层。前者决定 AI 答得有没有用，后者决定 AI 上线后能不能持续好用。滚水科技在做项目时，会把这两块当一等公民来设计，不让它们变成"上线后再补"的事项。

至于客户该投多大规模，要看场景：内部知识助手类的，一般中等规模的服务器加 API 调用就够；面向外部、并发高的客户类，需要更细的服务编排和缓存策略。我们会先按"小而完整"的原则把骨架搭起来，让客户先看见整套系统跑起来的样子，再决定哪部分加大投入。

Question 11

企业如何用 AI OCR 自动识别订单和录入系统？

Accepted Answer

AI OCR 要真正省人，关键不在"识别这一刻"，而在订单从入口到落库的整条链路是否打通。滚水科技在做这类项目时，会把订单获取、字段抽取、业务校验、回写 ERP/CRM 拆成独立环节，每一步都留可观测点，让识别不准的地方能被快速发现、被人工兜底，而不是让一份错单直接污染下游系统。

一套能在生产里跑稳的订单 OCR 系统，一般包含：

多入口接单：微信对话截图、客户邮件附件、传真扫描件、PDF、Excel、电商后台导出，每种来源的图像质量和版式都不一样，分类要在第一步就分清楚。
字段抽取：客户名称、品名规格、数量、单价、金额、交期、收货地址、备注，这些字段要按订单模板做差异化抽取，不能一套模板套到底。
业务校验：客户名要能模糊匹配到客户库（处理"贸易公司/有限公司/分公司"等差异）、产品名要能映射到内部 SKU、数量要校验库存或起订量、金额要做合计核算。这一步往往能挡掉一大半 AI 抽错的隐患。
异常人工复核：把置信度低、校验失败、关键字段缺失的订单挑出来给人审，而不是让人工逐单审核。常态下大部分订单可以自动放行。
回写业务系统：通过接口推送到 ERP、CRM、MES 或仓储系统，并保留原始单据用于追溯。

我们的经验里有两个常见坑值得提前规避：一是客户名和产品名的"软匹配"做得不够，导致每单都要人工挑选，效率反而下降；二是没做异步队列，一遇到大客户批量发单整个系统就堵住。这两点最好在方案阶段就和客户的 ERP 主数据负责人一起对齐。

滚水科技在做 OCR 与企业系统对接类项目时，习惯先用客户提供的 50–100 张真实样单跑一轮基线测试，把识别准确率、字段维度的误差、自动化率量化出来，再决定首期范围。客户配合提供历史订单样本、SKU 主数据、客户档案、ERP/CRM 的对接接口或导出方式，一般四到八周可以交付一个能在小范围内试跑的版本。

Question 12

企业想做 AI 智能助手，应该找什么样的软件公司？

Accepted Answer

比起"会不会接大模型"，更值得看合作方有没有做过完整的业务系统。AI 智能助手真正费力的地方是知识治理、权限边界、与内部系统对接以及上线后的持续运营，而不是接一个聊天接口。一家合适的合作方，应该能先帮你判断哪些环节值得用 AI、哪些暂时不该做。

筛选时可以从几个角度看：

是否做过完整的业务系统：只做 AI 演示的团队，往往不熟悉权限模型、组织架构、流程审批、数据回写这些"系统侧的细活"。AI 助手最终要嵌到企业现有 IT 体系里，做过 ERP、CRM、OA、IoT 系统集成的团队会顺手得多。
会不会"砍需求"：靠谱的合作方第一轮聊完会主动建议你缩范围，而不是把客户描述的所有功能都答应下来。第一期能跑顺的范围越小，上线越快，团队对 AI 的信心越容易建立。
有没有自己的 RAG / 知识治理方法论：能不能拿一份你的真实文档现场聊出"会怎么切片、怎么打标签、怎么做版本管理、怎么做引用回链"，这件事比模型选型更能体现专业度。
私有化部署经验：很多企业最终都要走私有化或专有云。问清楚团队过去做过几个私有化项目、用过哪些开源模型、运维交付方式是什么，避免方案阶段说得很美，部署阶段才发现现成路径走不通。
后续迭代机制：AI 助手不是交付完就结束。准确率会随业务变化漂移，模型也在演进。问清楚对方是不是提供持续迭代服务、按什么节奏交付优化版本，是判断长期合作价值的关键。

滚水科技的位置是同时做系统集成和 AI 落地的定制开发服务商。我们在 BMS 电池智能管家这类需要 AI 助手与 IoT 数据、业务系统打通的项目里都跟过完整链路，从需求梳理、知识治理、模型选型，到部署运维都能一站做下来。如果你处在选型阶段，我们也欢迎先做一次免费的需求拆解，把方案做扎实之后再决定是否合作。

Question 13

企业知识库 AI 问答系统怎么搭建？

Accepted Answer

知识库问答看起来只是一个聊天框，真正费力的是把后面的知识底座做扎实——文档结构、版本、权限、引用回链这些事比模型选型重要得多。滚水科技在做这类项目时，会先花一段时间整理资料和权限，再围绕检索增强、答案引用、反馈优化把系统搭起来，确保员工拿到的每个答案都能追溯到原文。

一套能长期用起来的企业知识库问答，一般包含这几块：

文档治理：把分散在 Word、PDF、Wiki、群聊、扫描件里的资料清洗成段落级数据，标好版本号、生效日期、所属业务线。文档治理通常占首期 40% 以上的工作量，跳过它，所有"答得不准"的问题都会回来找。
检索层：向量检索 + 关键词检索混合召回，复杂场景里再加一层 rerank。我们不会盲目追新模型，更看重对客户文档类型（合同、规范、技术手册）召回是否稳定。
回答层：让大模型必须基于召回内容回答，每个答案带"出自哪份文档、第几节、版本号、生效日期"。这件事是企业知识库和通用聊天机器人最关键的差别——没有引用，员工就不敢用。
权限分层：哪些资料销售能看、哪些只给研发、哪些限本部门，要在系统层划分清楚，不能靠提示词去约束模型。
反馈闭环：员工点踩、修正、补充的内容回流到知识库，准确率随使用时间提升。

我们的经验是，第一期范围越克制越好。挑一两个高频、容错率较高的场景先跑——比如内部 IT 报修、HR 政策答疑、产品资料检索——把"答得有据、有出处"这件事做扎实，再扩展到核心业务。一开始就铺整个公司，往往各场景都跑不顺。

部署方式上，根据敏感度可以走云端 SaaS、专有云或私有化部署。滚水科技在 AI 智能招聘系统等项目里两种部署模式都做过，会根据客户的数据合规要求和运维能力做取舍。客户前期需要配合提供现行内部文档、过往问答记录、组织和岗位权限划分，以及一两位熟悉业务的同事帮忙在试点期校对答案。

Question 14

如果要做 AI 知识库或企业 AI 助手，前期需要准备什么资料？

Accepted Answer

这类项目第一版能不能跑顺，多半取决于资料准备得齐不齐。我们一般会让客户提前准备四类内容：知识内容本身、使用场景信息、权限边界、效果评估样本。资料越完整，第一版的准确率越稳，后续迭代成本越低。

具体清单大致是这样：

1. 知识内容

内部制度、政策、SOP、操作手册
产品资料、技术参数、规格书、报价规则
常见问答记录（客服日志、IT 报修历史、HR 答疑）
历史项目复盘、典型案例、内部 Wiki
行业标准、规范、外部权威资料（如果需要纳入）

资料形式不限：Word、PDF、Excel、扫描件、网页、Confluence、群聊导出都可以接，但越规整后续效果越稳。如果有版本号、生效日期、所属业务线的标注，最好一并附上。

2. 场景信息

系统主要面向哪些角色（销售？工程师？一线员工？外部客户？）
要解决什么具体问题（提效？合规检查？培训？答疑？）
嵌在哪个入口里（企微/钉钉/飞书机器人？Web 工作台？小程序？）
期望的响应速度、并发量、上线时间

3. 权限边界

哪些资料只给特定角色看（财务、研发、销售、外部合作方）
哪些资料涉及合规、商密，不能进 RAG 库
哪些字段答复时要脱敏

权限要在系统层划清，不能依赖提示词约束。提前梳理这些，能避免后续返工。

4. 效果样本

20–50 个高频问题及对应标准答案
一批"模型容易答错的边角问题"作为压力测试
一两位熟悉业务的同事，在试点期做答案核对

资料分散没关系，我们经常遇到客户文档散在不同部门。如果不方便自己梳理，滚水科技也可以先派一位 PM 上门做半天到一天的梳理工作坊，把适合纳入知识库的内容范围圈定下来，再分阶段往里灌资料。这种"先圈范围、再上系统"的做法比一次性把所有文档塞进去要稳得多。

Question 15

我要做一个 AI Agent 应用，但我不确定目前的 AI 能否达到我想要的效果。

Accepted Answer

有这种担心其实是好事。AI 项目跑不顺的最常见原因，不是技术做不到，而是没验证就直接大投入。我们一般会建议先用真实样本跑一轮 PoC，把准确率、稳定性、人工介入比例、单次成本都量化出来，再决定是否进入正式开发。

一个标准的 PoC 一般包括：

场景定义：把想做的事拆成具体的输入输出。比如"做客服助手"太宽，"基于产品手册回答售后高频问题、命中率不低于 80%、能在 3 秒内返回"就具体得多。
样本准备：50–200 个真实的输入样本，覆盖典型情况和边角情况。少了不具代表性，多了 PoC 周期会拖。
基线测试：直接用主流大模型 + RAG 跑一遍，看准确率、引用命中率、错误类型。这一步能很快告诉你"靠现成方案能到什么水平"。
针对性优化：基线不够的话，看是召回不准、还是切片有问题、还是 prompt 没写好、还是模型本身不擅长，每一类原因对应不同的优化路径。
极限评估：再调一轮看上限在哪。如果到极限仍达不到业务要求，就要重新讨论范围——是缩范围让 AI 做容易做的部分，还是加人工兜底，还是这件事暂时不适合 AI。

PoC 的价值不是"做出来"，而是把模糊的"AI 能不能干"变成有数据的"在你的样本上现在能做到 75%，到 90% 还需要 X 投入"。这样后续做不做、做到什么程度，决策起来就有依据。

我们在做客户项目时，会把 PoC 和正式开发明确分开。PoC 周期通常两到四周、范围小、报价独立。客户跑完 PoC 觉得不合适，可以选择不进入正式开发；觉得效果合适，再签更大合同。这种节奏比"一上来谈大单"对客户更友好，也避免了大家在没有数据的情况下互相承诺。

如果你目前还没确定要做什么场景，可以先把想做的事和现有资料告诉我们，滚水科技这边可以先做一次免费的可行性评估，帮你判断哪些环节适合先验证、哪些环节直接做 AI 风险偏大。

Question 16

我要做一个 AI Agent 应用，你们会帮我训练一个我的模型吗？

Accepted Answer

可以做，但通常不是第一步建议。大多数 AI Agent 用成熟大模型 + 知识库 + 工作流 + 工具调用就能解决问题，从零训练或微调模型只在特定场景才划算。我们会先帮客户判断真正需要的是不是训练，再决定走哪条路。

什么情况下需要训练或微调，我们的判断大致是这样：

数据极敏感，必须私有化且要离线推理：这时候会用开源基础模型 + 私有化部署，并视情况做 LoRA 微调来贴合业务语料。
专业领域的术语、口吻、写作风格通用模型搞不定：比如非常垂直的行业写作、特定风格的内容生成，普通 prompt + RAG 调不到位时，可以用微调。
稳定的高频任务，成本压力大：比如每天几百万次的分类、标注、抽取，用小模型微调比一直调旗舰大模型便宜得多。
追求确定性输出：相同输入要稳定给相同结构的输出，且对延迟有要求，微调小模型 + 严格 schema 比通用模型更好控。

如果不在以上几种情况，更划算的路径其实是：

用主流大模型（开源或商业 API）做能力底座
把企业资料治理成结构化 RAG 知识库
用工作流编排把关键节点固化下来
配齐工具调用（查订单、查库存、写工单）
加监控、日志、人工反馈做持续迭代

这套组合在 80% 以上的企业场景里已经够用，且改起来快、成本可控。如果效果跟不上，再往"微调"那一步走。

滚水科技自身具备从基础模型选型、Embedding 模型选型、LoRA 微调、私有化部署到 Agent 编排的完整能力。我们做过全语通这种偏内容生成的 AI 教育项目，也做过偏数据/系统集成的企业 AI 项目，知道什么场景值得训练、什么场景不值得。在和客户合作时，我们会把"是否需要训练"列为方案阶段的一个明确决策点，而不是默认走训练路线——因为多花的钱不一定换得到更好的效果。

Question 17

现在很多项目都在讲 AI，如何判断是真正有价值，还是只是概念包装？

Accepted Answer

判断一个 AI 项目值不值得做，不看模型名字够不够新，而看它有没有放到真正能受益的环节。我们一般会先问三件事：现在这个环节人工是不是确实费力、数据基础够不够、不用 AI 业务能不能跑——三个答案都偏向"需要 AI"，再考虑投入。

具体可以从几个角度区分"真有价值的 AI"和"贴标签的 AI"：

看是否解决具体痛点：靠谱项目会描述清楚"原来这件事每天要花 X 小时、错率 Y%，AI 介入后预计省到 Z"。讲不清楚省了什么、提升了什么的，多半是概念包装。
看数据是否够支撑：AI 吃数据。如果客户内部连这件事的历史数据都没积累，或者数据散到根本拉不出来，那这个项目大概率第一步就走不动。
看是否能小步验证：真有价值的场景一定能拆成 2–4 周的 PoC 去验。如果一开口就要做"全平台 AI 化"且不愿意拆 PoC，多半是项目主导方对自己也没底。
看交付物是不是 AI 之外也有意义：很多"AI 项目"剥掉 AI 那层，剩下的数据治理、流程梳理、系统对接本身就有价值。如果剥掉 AI 项目就归零，说明 AI 是包装。
看团队角色：真做 AI 落地的团队会同时配 PM、业务专家、算法、工程、运维。如果对方只来个销售加几张 PPT，连具体技术选型都答不上来，要警惕。

更适合优先落地的方向，一般是规则相对清晰、人工已经在做、错答可控的场景——重复答疑、初步分类、辅助校对、流程提效、报表生成、文档抽取这些。要做"全自动决策"或"代替专家做关键判断"的，多半还没到时候。

滚水科技在做客户咨询时，会主动帮客户排掉看起来很性感但其实落不了地的需求。我们更愿意做"先做小、做实、跑稳，再放量"的项目，而不是签下来一个大单后做不出效果。这种做法短期看少签了点合同，但长期客户的复购和口碑都好得多。如果你手上有个 AI 想法不确定该不该投，可以先聊聊，我们直说"哪段值得投、哪段先别碰"。

Question 18

行业标准类 AI 问答系统怎么搭建？

Accepted Answer

这类问答系统对"对答如流"没什么兴趣，对"说得出依据"非常苛刻。滚水科技在做企业知识库类 AI 项目时，会把标准文档先做结构化整理和版本管理，再围绕条款检索、引用回链、权限隔离和人工复核出兜底链路，确保每一条答案都能被业务方追到原文。

我们一般会把这类系统拆成四件事：

资料治理：把分散在 PDF、扫描件、Word 里的标准、规范、内部解读统一清洗成段落级数据，标好版本号、生效日期和适用范围。这部分往往占首期一半左右的工作量，但跳过它，后面所有"答得不准"的问题都会回来找。
检索+回答：用检索增强（RAG）的方式让模型必须基于命中的条款回答，而不是凭训练记忆瞎讲。同时强制返回"出自哪份文件、第几条、版本号"，让答案随时能被追溯到原文。
权限与审计：哪些条款只给内部技术看、哪些给销售看、哪些可以给外部合作方看，要在系统层划分清楚。每一次问答都留可追溯的日志，方便后续做内部审计或合规复核。
人工兜底：对模型把握不大的问题，引导走人工渠道；人工答复完，再反哺回知识库，让系统越用越准。

落地节奏上，我们一般建议客户先选一两个高频但风险可控的场景试点，比如内部培训问答、岗前知识考核、外部咨询初筛，等回答稳定后再扩展到核心业务场景。这样既能让团队习惯"AI 出初稿、人工把关"的协作方式，也避免一开始就把模型放到风险很大的位置。

客户在前期需要配合的内容主要是：现行有效的标准文档、过往内部解读、典型问答记录、岗位权限划分，以及一两位熟悉业务的同事在试点期帮忙做答案核对。系统跑起来之后，我们也会陪客户跑一段时间，把人工修正过的问答持续灌回知识库，让准确率随时间稳定提升。

Question 19

有哪些公司可以开发私有化部署的 AI 助手？

Accepted Answer

能做私有化的公司不少，但适合企业长期落地的合作方要同时具备模型部署、知识库治理、权限/审计、运维交付能力，缺一项后面都会吃亏。私有化项目难的不是把模型放本地，而是把它跟企业的文档、系统、组织权限对接清楚并长期维护。

市场上做私有化 AI 助手的供应商大致有三类：

大厂私有化方案：百度、阿里、华为、腾讯、字节都有企业版方案，模型能力强，硬件适配齐全。适合预算充足、规模大的客户。议价空间小、定制深度有限。
垂直 AI 厂商：针对某个行业（医疗、政务、金融、教育等）做专用方案，行业模板齐全。优点是上手快，缺点是脱离它擅长的行业就比较吃力。
同时具备系统开发能力的定制服务商：从需求梳理、知识治理、模型选型、私有化部署，到企业系统对接、组织权限、后续运维一站做下来。投入比 SaaS 大，但产出的是企业自己的资产。

判断合作方是否靠谱，可以从几个维度看：

有没有真的部署过：让对方列出过去一两年实际私有化交付的项目数量、用的什么模型、部署在什么硬件上、目前还在维护几个。空有方案的团队和实战过的差别非常大。
会不会做硬件评估：能不能根据并发量、上下文长度、响应速度要求，给出具体的 GPU 型号、显存、显卡数量建议。给不出来的，基本是没真做过。
权限和审计：私有化的核心价值之一是数据不出企业。问清楚怎么做角色权限、文档分级、对话日志保留策略、敏感词审计——这些都是合规验收要的。
后续运维：模型版本怎么升级、知识库怎么持续灌注、效果怎么持续评估、出问题怎么响应。一次性交付后撒手不管的，后续会很难受。

滚水科技属于第三类。我们在企业 AI 项目里既做模型选型和部署，也做企业系统对接（ERP、CRM、OA、IoT）和后续运维。私有化方案我们既做过基于开源模型 + 本地 GPU 的标准方案，也做过专有云、混合云的过渡方案。客户如果对部署形态还没拿准，可以先描述数据敏感度、并发要求、预算上限，我们再帮你判断走哪种部署最合适。

Question 20

纸质分拣单或手写单据，如何用 OCR 自动汇总？能替代 RFID 吗？

Accepted Answer

纸质分拣单和手写单据用 OCR 自动汇总完全可行，思路是"拍照/扫描 → OCR 识别 → 字段校验 → 异常人工复核 → 写入系统"，能省下大量手工录入。但要不要替代 RFID 是两回事——OCR 解决"事后汇总"，RFID 解决"实时追踪"，两者用途不同，多数场景下更合适的是配合使用而不是替代。

OCR 自动汇总的落地步骤大致是这样：

采集入口：现场用手机拍、扫描枪扫，或在分拣台架一个固定相机。手写单据建议设计带格点或浅色背景的标准表单，识别准确率能上一个台阶。
识别引擎：印刷字段用通用 OCR 就行；手写部分（数量、签名、备注）通常用专门的手写识别模型，必要时按字段微调。我们的经验是，手写数字识别率能做到 95% 以上，手写中文复杂字会差一些，需要靠后续校验补。
字段校验：识别出来之后立刻按业务规则校验——数量是否在合理区间、商品编码是否在主数据里、合计是否等于明细求和、日期是否符合当天。校验通不过的单据直接进异常池。
人工复核：异常单据推到一个简洁的复核界面，操作员看到原图和识别结果并列，改字段就能保存。这一步是 OCR 项目能不能落地的关键，不要追求 100% 全自动。
写入系统：通过后自动写 ERP、WMS、订单系统或导出 Excel。整个流程留痕，便于事后追溯。

回到"能不能替代 RFID"的问题：RFID 强在"批量、非接触、实时"，进出库门一刷一秒钟几十件，OCR 做不到这种效率。但 RFID 需要给每件商品贴标签，单件耗材成本高、对金属和液体敏感、设备前期投入也大。如果你们的场景是少量、低频、单据集中处理（比如车间日报、退货分拣单、跨厂区交接单），OCR 反而是更轻的方案；如果场景是大批量、高频、需要实时盘点的仓储和物流，RFID 仍然不可替代。

实际项目里我们也见过两者结合的：大宗物流走 RFID，零星补单和异常单据走 OCR 兜底。滚水科技在工厂数字化和物联网项目里做过这类组合方案，可以先从你们最痛的环节切入，跑顺一个再扩展。

Question 21

中小企业做 AI Agent 系统，有哪些服务商可以选？

Accepted Answer

市场上做 AI Agent 的供应商大致分四类：大厂平台、SaaS 工具型、垂直行业方案商、定制开发服务商。中小企业要选哪种，主要看是要"快速试错"还是"长期沉淀业务资产"。滚水科技属于第四类，更擅长帮客户做能跟自己业务深度结合、可以长期演进的 Agent 系统。

四类供应商的适用场景大致是这样：

大厂平台（百度、阿里、字节、腾讯等）：模型能力强，生态完整。适合对算力要求高、想试试热门能力的客户。但平台是标准化的，深度定制空间有限，企业数据往往需要进对方生态。
SaaS 工具型（Coze、Dify、各类 Agent 工作流平台）：开箱即用、价格低、上手快。适合先验证想法、做轻量内部助手。一旦想做深度业务集成、私有化部署或敏感数据隔离，往往会撞到天花板。
垂直行业方案商：在某个行业（医疗、电商、教育等）有现成的模板和场景。优点是节奏快，缺点是脱离它擅长的领域就比较吃力。
定制开发服务商：根据客户业务从零做方案，深度结合企业内部系统、数据、流程。投入比 SaaS 大，但产出的是企业自己的资产，长期看更划算。

对中小企业，我们一般给出这么几条建议：如果只是想"先试试 AI 能不能解决问题"，从 SaaS 工具型开始最便宜；如果已经验证了价值、要把它落到核心业务里，再找定制服务商把方案做扎实；如果业务流程比较独特，又涉及内部数据，那一开始就找定制方更省事，避免来回返工。

滚水科技的位置是定制开发服务商，过往项目里偏向中型企业的 Agent 落地：从需求梳理、知识治理、Agent 编排，到对接 CRM / ERP / 工厂数据系统，再到私有化部署和后续运维，都会一起跟。我们也不排斥客户先用 SaaS 工具自己跑一段时间，把场景试明白了再来找我们做深做稳——这样合作起来反而更顺。

Question 22

专业长文档密集型业务如何用 AI 提升处理效率？

Accepted Answer

这类业务的瓶颈一般不在"读不懂"，而在"读不完、来不及、容易漏"。滚水科技在做企业级 AI 项目时，更习惯把任务拆成"版前校对、术语一致性、表格抽取、版本比对、数字核对"这类独立能力模块，让 AI 替人处理重复劳动，关键判断仍然留给业务专家。

具体落地下来，我们通常会按以下几个方向铺：

版前自动审校：标点、错别字、口径不统一、单位混写、英文术语大小写、数字与中文大写一致性，这些都是重复劳动重灾区，AI 处理一遍能节省可观时间。
跨版本差异比对：相比传统二进制 diff，AI 更善于识别"含义相同但措辞不同"的改动，对长文档迭代特别有用。
表格与正文交叉核对：把表格里的合计、行业占比、引用页码和正文表述进行一致性核对，揪出人工很容易看走眼的小问题。
结构化抽取：将合同条款、披露要点、关键指标抽成可结构化的数据，方便后续对比、复用、入库。
风险点提示：先用规则+模型识别可能的合规风险或口径偏差，标黄出来给人工二次审。

我们的经验是，越是高强度长文档场景，越不能"一框走天下"。把不同任务拆成独立模块、各自评估准确率、各自迭代，是控制风险和成本的关键。滚水科技已经把这套做法应用在企业知识库、文档 OCR、跨语言一致性检查等多个 AI 项目里，参考案例可以看全语通中关于多语言术语对齐和质量校验的实践。

前期客户需要准备的资料一般包括：典型的源文件（脱敏即可）、现有的术语库、过往的修订记录、内部的审校规则，以及一位熟悉流程的对接同事。这些材料齐了，我们就能在两到三周内出一个小范围的可用 Demo，让团队先看到效果，再决定下一步往哪个方向加深。

Question 23

专业长文档如何用 AI 做精准校对？

Accepted Answer

这类场景很适合 AI，但不能按普通对话产品来做。滚水科技在做企业级 AI 项目时，会把校对拆成术语一致性、数据前后文一致性、目录与页码核对、表格与正文交叉验证、格式异常识别、版本差异比对等独立模块，让 AI 把容易漏看的问题先筛出来，再交给专业人员做最终判断。

我们一般会按以下几个维度配置校对能力：

术语与口径一致性：检查同一概念在全文是否统一表述、大小写是否一致、缩写是否在首次出现处定义，避免出现同一名词多种写法。
数字、单位、币种：核对数字在正文、表格、附注三处是否一致，单位与币种是否漏写或写错。这类错误最难靠肉眼避免。
目录、页码、引用：自动比对目录与正文标题、章节编号、图表编号、跨章节引用，看是否对得上。
表格与正文交叉：把表格中的数字、总计、占比与正文表述做核对，识别表里说一回事、文里说另一回事的情况。
版本差异比对：相比纯 diff 工具，AI 更适合识别"措辞不同但含义未变"或"措辞接近但口径已变"的改动，能为审阅人节省大量时间。

工程上，我们会把每个模块的准确率、召回率、误报率独立追踪，逐步迭代。一开始不会追求一步到位，而是先解决最痛的两三类问题，把人工审阅时间砍下来后，再扩展能力范围。这种思路在我们做过的 AI 项目里效果比较稳定，比如全语通就是用类似拆分模块的方式做多语言学习内容的质量校验。

客户前期需要准备的资料一般包括：典型的待校对文件（可脱敏）、现有的术语表、过往修订记录、内部审校规则，以及对接的业务接口人。资料齐了之后，我们一般在两到三周内就能出第一版可用 Demo，让团队先看到效果再决定下一步往哪深入。

Question 24

做一个 AI 导购或智能客服，客户需要提供哪些资料和接口？

Accepted Answer

AI 导购或智能客服从 Demo 到上线，差距通常不在模型能力，而在产品资料、业务规则、订单和售后接口是否齐全。资料越规整，第一版上线越快、效果越稳。滚水科技在做这类项目时，会和客户一起列出资料清单和接口对接列表，确认完再启动开发，避免做到一半才发现关键数据拿不到。

资料类（先把这些备齐）

产品资料：SKU 清单、规格参数、卖点话术、价格策略、活动机制、适用人群、常见误解和禁用承诺。
FAQ 与历史对话：客服过往答得最多的 100–300 个高频问题、对应标准答案、过往真实对话样本（脱敏即可）。
业务规则：起订量、运费、优惠叠加、退换货政策、售后保修、人工转接条件。
品牌口径：哪些话能说、哪些不能说、需要的语气和风格、必须回避的竞品引用。

接口类（决定能不能"办事"）

商品库 / 库存接口：实时查询库存、SKU 库存状态、上下架变化。
订单接口：查询订单状态、物流信息、生成订单或加购物车。
用户与会员接口：识别老客户、查会员等级、查历史购买、做个性化推荐。
售后工单接口：能记录用户问题、转人工、生成工单、回写处理结果。
CRM / 营销系统：留资写回、跟进任务派单、营销节点触发。

实施节奏上，我们一般会建议先用"工作流编排"的方式把核心环节固化下来：检索商品 → 校验库存 → 给推荐 → 生成解释话术 → 引导下单或转人工。哪一步靠规则、哪一步靠模型、哪一步必须接外部系统，提前画清楚，避免上线后整体靠模型自由发挥而失控。

第一版范围上，我们倾向只覆盖 TOP 20% 高频问题和 TOP 商品，把闭环跑顺，再横向扩展长尾。这种节奏在滚水科技的电商和导购项目里跑下来最稳——一周内就能让客户看到效果，三到六周可以交付一个能放到真实流量里试跑的版本。

Question 25

AI 安防识别系统怎么开发？

Accepted Answer

AI 安防系统的难点不在识别准不准，而在误报怎么压下来、报警之后人怎么用。滚水科技做这类系统时，会先和客户对齐"识别什么、谁来响应、可接受多少误报"，再决定模型、相机点位、报警链路怎么搭，避免一上来就堆功能。

一套能上生产的安防识别系统，往往包含这几块：

前端采集：相机选型、点位规划、夜间补光、抗逆光，这些都是物理层面的事，做不好后面模型再强也救不回来。我们会先和客户的安防负责人一起到现场走一遍。
识别能力：常见场景包括人员入侵、车辆识别、明火/烟雾、未戴安全帽、危险区域闯入、人员聚集等。不同场景模型成熟度差别很大，能直接复用的就别从零训练。
事件管理：识别只是开始，更重要的是事件确认、推送通知、分级处置、签收记录。我们一般会把这块做成统一的事件中台，方便客户日后接入更多识别源。
回查与复盘：所有报警事件保留视频片段和识别截图，方便事后复盘；误报也要能一键标记，回流去优化阈值或重训模型。

关于落地节奏，我们的经验是：先把一两个高价值场景跑通（比如出入口管理或重点区域入侵），把误报率压到客户能接受的范围（通常每路每天个位数以内），再考虑横向铺更多识别能力。一开始就要"全场景上线"的项目，基本都会陷在调阈值的泥潭里。

部署方式上，根据数据敏感度有两种主流方案：边缘端推理 + 本地服务器存储，适合工厂、园区、对数据外发敏感的客户；云端集中分析则适合多分支、轻量化运维的客户。滚水科技在智慧赋能-工厂管理数字化这类项目里两种方案都做过，会根据客户的实际网络条件和 IT 运维能力来做取舍，不强推某一种架构。

Question 26

AI 客服系统和企业知识库系统有什么区别？

Accepted Answer

两者表面都"用 AI 回答问题"，但服务对象、对话目标、衡量指标完全不一样。AI 客服面向外部客户，看重转化、留资、工单收口；企业知识库面向内部员工，看重答案的准确性、可追溯和权限隔离。滚水科技在做项目方案时，会先确认这一层定位，再决定底层架构和投入重点。

AI 客服的几个特征：

用户是不可控的，提问随意、口语化、夹带情绪。系统要做意图识别、闲聊兜底、敏感词过滤。
对话目标偏业务结果：下单、留资、转人工、产品引导，而不是单纯"答对问题"。
衡量指标多是解决率、转人工率、转化率、平均对话轮次。
一般要接 CRM、订单、工单、营销系统。

企业知识库系统的几个特征：

用户是公司内部员工，提问相对专业、聚焦。
对话目标是给出有依据的答案，常常需要列出出处、版本号、生效日期。
衡量指标更看准确率、引用命中率、是否减少了员工跨部门追问。
必须有权限分层：哪些资料给哪些岗位看，要在系统层管住，不能靠提示词约束。

实际项目里，两者也经常组合出现：比如一个 To B 客户既想做对外的 AI 客服，也想做内部员工的产品知识助手。我们的做法是把底层知识治理（资料结构化、版本、权限）做成共享层，再让两个上层应用各自走自己的对话策略和业务集成。这样既复用了最难的部分，又不会让一边的需求扯到另一边。

如果客户内部对该做哪个还犹豫，滚水科技一般会建议从内部知识库先切入。原因很简单：内部场景容错性高、迭代节奏更可控，先把"AI 答得准、答得有出处"这件事做扎实，再把这套能力迁移到对外客服时，风险会小很多。

Question 27

AI 如何做中英文术语一致性检查？

Accepted Answer

中英文术语一致性检查的难点不在翻译模型有多强，而在有没有一份能持续维护的术语库。滚水科技在做这类项目时，会先把客户已有的双语对照、缩写、禁用译法、上下文限制整理成结构化术语表，再让 AI 在全文里做检索、比对和异常提示，结果都是建议项，最终拍板权留给人。

具体流程上，我们一般这样切：

术语库治理：把客户散落在 Excel、Word、过往译稿里的术语收上来，做归一、去重、加版本号，标清楚每条术语的适用范围（产品线、文档类型、客户口径）。
检测引擎：跑两轮，一轮是术语命中后的标准译法对比，一轮是同一术语在全文里的多种译法/缩写聚类，找出"前后不一致"的位置。AI 还会顺带做指代识别，避免简单做字面匹配。
结果呈现：每个问题点给出原文位置、当前译法、建议译法、置信度，以及"为什么这样建议"。这一点很关键——如果 AI 只是丢一份红黄标记，编辑会非常抵触。
闭环维护：审校确认过的修改回流到术语库，模型不擅长的领域术语由人补进去，避免每次重新跑都犯同样的错。

我们见过的两个常见误区：一是想让 AI 直接改全文，结果一改就出新错；二是把术语库当一次性交付物，半年后没人维护，准确率持续下滑。滚水科技的做法是把术语库当作一个长期产品来运营，配套提供管理后台、变更日志、责任人机制，让客户内部能自己维护下去。

落地节奏方面，对资料体量中等的客户，我们一般四到六周可以交付首版可用系统：包含术语库后台、单文档检查、批量检查、报告导出，以及一份初始术语库。客户配合的事情主要是提供历史译稿、已有术语 Excel、典型有问题的稿件作样本，以及一位熟悉业务的同事在试点期做答案审核。

Question 28

AI 文档自动化处理系统怎么做？

Accepted Answer

文档自动化不是"做一个 OCR"那么简单。要从文档进系统的那一刻开始，把分类、抽取、校验、分发、归档串成一条可监控的流水线。滚水科技做这类项目时，会先和客户一起画清楚目前人工处理一份文档的全流程，再决定哪几步交给 AI，哪几步保留人工兜底。

我们一般会把系统拆成五段：

接入与分类：邮件、扫码、上传、接口推送都可以是入口。文档先做类型识别（合同、发票、报表、申请单……），再走对应的处理流水线，避免一套模板套到底。
结构化抽取：根据文档类型抽出关键字段，OCR 识别文字、版面理解处理表格、模型补齐上下文。复杂文档我们会拆成"先抽，再后处理"，让规则引擎兜底解决格式异常。
业务校验：抽出的数据要跟现有系统对账，比如合同金额对得上报价单、发票抬头匹配客户库、申请单的字段满足审批规则。这一步往往能挡掉一大半 AI 抽错的隐患。
人工复核：把不确定的字段挑出来给人审，而不是让人审每一份文档。我们会按置信度、字段重要性、业务规则给文档打"放行/复核/打回"三档。
归档与回流：处理完的数据进业务系统，原始文档归档可检索，复核结果回流给模型做下一轮优化。

落地节奏上，建议先选一类高频、规则相对清晰的文档作为切入点（订单、入库单、报销发票都是不错的起点），把一条端到端的流水线跑通，再横向扩到其他文档类型。客户里跑得最稳的几个项目，第一期范围都比较克制。

工程上还有几个常见坑值得提前规避：扫描质量参差不齐时要做图像预处理；多公司主体场景下表头千差万别，模板不能写死；大批量场景要做异步队列和重试机制，否则一个高峰期能把整套系统拖垮。这些细节，滚水科技在过往多个 OCR/文档项目里都踩过，会在方案阶段提前给客户标出来。

Question 29

PDF 表格如何自动抽取成 Excel？

Accepted Answer

PDF 转 Excel 看起来简单，真正落地时最头痛的是合并单元格、跨页表、混排版面这些细节。滚水科技的做法是把"识别文字"和"还原结构"分成两步，再叠加业务校验，让最后导出的 Excel 拿来就能用，而不是还得人工再修一遍。

实际处理流程一般包含：

版面切分：先把页面上的正文、表格、图、脚注分开，避免脚注被当成表格的一行；
表格定位：在每一页里独立框出表格区域，处理无边框表、虚线表、深色背景等特殊样式；
结构还原：识别表头层级、合并单元格、跨页续表，把"视觉上的表"翻译回"行列结构"；
字段标准化：统一日期、金额、单位写法，避免"1,234.56" 和 "1 234.56" 被当成不同值；
校验与导出：用合计、子项加总、上下行一致性这类规则做反向校验，疑似抽错的行标红，再导出成 Excel 或推送到业务系统。

一个常见的误区是想找一个"全能"工具一次搞定所有 PDF。我们见到的真实情况是：电子版 PDF 和扫描 PDF 完全是两套技术路线；规则化排版（同一份模板反复出现）和自由排版（每份 PDF 都不一样），投入产出比也差很多。所以滚水科技在接需求时会先要 10–30 份样本，区分一下文档来源、版面规律、识别难度，再给方案。

工程上还有几个值得提醒的点：高并发批量处理时要做异步队列，避免一份大文件把整台机器吃满；扫描质量差的文档要做图像预处理；如果是要导回业务系统的数据，导出 Excel 只是中转格式，最好直接做接口对接，少一道人工搬数据的环节。

对资料体量大、需求长期化的客户，我们会把这类能力做成一个"文档处理中台"，统一接入不同来源、不同业务线的文档，新场景过来就是加一类模板配置，不需要每次都从零做一遍。

Question 30

你们的项目管理方式是什么？我是否能实时看到项目进度？

Accepted Answer

滚水科技的项目管理是透明的：每个项目都有 PM 牵头，按里程碑 + 周会 + 任务看板的方式推进，客户随时可以在项目管理系统里看到当前进度、待办、风险点和待客户确认的事项，不用等周报。

实际操作上分几个层面：

里程碑计划。立项时 PM 会和客户一起拆出里程碑，每个里程碑明确交付物、验收标准、起止时间。这是项目的"骨架"，所有后续动作都挂在里程碑上。
任务看板。每个里程碑下面拆成具体任务，分配到产品、UI、前端、后端、测试、运维各角色，任务状态（待开始 / 进行中 / 待验收 / 已完成 / 阻塞）实时更新。客户可以随时打开看板查看每个任务的进度和负责人，不需要等周报来回问。
每周例会。一般每周固定时间和客户开一次 30–45 分钟的同步会，过本周完成情况、下周计划、当前风险、需要客户配合的事项。会后 PM 出一份纪要发到群里，关键决策记录留档。
日常沟通群。会建一个企微/钉钉群，PM、产品、技术负责人和客户业务方都在群里，日常的小问题不用等周会，群里直接对齐。涉及范围或预算变更的重要决定，会单独发书面确认。
风险预警。PM 会主动维护一份风险清单，包括需求未确认、第三方接口未拿到、客户素材延迟、技术方案有不确定性等。任何风险都不藏着掖着，提前 1–2 周向客户预警，避免到 deadline 才暴露。

至于"能不能实时看到进度"——我们一般会给客户开放项目看板的只读权限，进度颗粒度细到每个任务卡片。客户也可以指定一位项目接口人和 PM 高频对接，这样信息流不会卡在某个环节。

我们做过的项目里，从智能飞镖赛事 App 这种多角色协同的产品，到 IoT 平台、工厂数字化这类周期长、参与方多的项目，都是按这套方式跑的。核心思路是：项目越透明，扯皮越少，问题暴露越早，整体节奏反而越快。

Question 31

你们会帮我运营产品吗？如果我做完没有用户来使用怎么办？

Accepted Answer

坦白说，滚水科技是一家产品技术团队，主业是设计、研发、上线和后续维护，不做日常的内容运营、投放和销售。但"做完没人用"这个担忧本身很合理，我们会在项目前期帮客户把这件事想清楚，避免做出一个没人来的产品。

我们一般会和客户在立项时就把这个问题摆到桌面上聊：

种子用户从哪里来？ 如果客户自己已经有线下门店、社群、企业客户、抖音/视频号粉丝、行业资源，那产品上线后导入流量这一步是顺的，我们就按这个方向做功能。如果完全没有冷启动渠道，光做一个 App 出来，再好的功能也不会自己产生用户，这时候我们会建议客户先把渠道、内容、合作资源准备好，再决定要不要立项。
首期产品要服务"哪几个具体的人"。 我们会让客户列出 5–10 个真实的潜在用户的名字和场景，而不是一个抽象的"宝妈群体""中小企业"。能列得出来，说明冷启动是有抓手的；列不出来，说明商业模式还没想清楚，再多功能也救不回来。
是否需要"先线下后线上"。 很多 O2O、企业服务、社区类的项目，靠纯线上推根本起不来。我们做过的宠物寄养小程序"萌住"就是一个典型例子，前期是靠线下门店和老客户口碑跑起来的，小程序只是把线下生意搬到线上更好管理，而不是反过来。

至于具体的运营动作——抖音内容、小红书种草、私域社群、SEO、地推、关键客户拜访——这些通常要由客户自己或专门的代运营公司来做，我们的角色是把产品体验、转化路径、数据埋点这些技术侧的事情做扎实，让运营人员有抓手去优化转化率。

如果客户确实在运营这块没有头绪，我们也可以基于公开的案例资料（比如智能飞镖赛事 App、全语通 AI 教育这类项目）介绍下别家是怎么冷启动的，但最终的运营执行还是要回到客户自己的团队。说到底，产品和运营是两条腿，缺一条都走不远，建议在立项前先确认自己这条腿够不够稳。

Question 32

你们如何保证项目不会延期？延期责任如何界定？

Accepted Answer

说实话，没有任何团队敢拍胸脯保证 100% 不延期。滚水科技的做法是把项目切成可验收的小阶段、提前暴露风险、双方在合同里把延期责任写清楚——是需求频繁变更、客户配合不到位，还是研发自身原因，分别怎么界定、怎么调整工期，事先就说明白，比事后扯皮强。

我们在控制工期上主要做这几件事：

里程碑拆分。一个 3–6 个月的项目，我们一般会拆成 4–8 个里程碑，每个里程碑都有可演示、可验收的交付物，而不是把整个项目压到最后一周交。任何一个里程碑出现偏差，我们都会在周会上提前 1–2 周预警，而不是拖到 deadline 前一天通知客户延期。
周报和实时进度。我们用项目管理系统跟踪每个任务的状态，PM 每周会出一份进度报告，包括本周完成什么、下周计划做什么、有哪些风险需要客户配合解决。客户随时可以问到当前进度，不需要等周报。
需求冻结机制。每个里程碑启动前会有一次需求确认，确认之后这一期的范围就锁定了，新的想法记录到下一期。这是控制延期最关键的一件事——很多项目延期的根本原因是"边做边加"，不是研发慢。

关于延期责任，我们的合同条款一般会区分这几种情况：

客户原因：需求变更超过约定范围、关键决策延迟、第三方接口/资质/素材未按时提供、验收响应超时。这种情况工期顺延，不视为研发延期。
研发原因：在需求和配合都正常的前提下，因为我们自身的开发或测试问题导致里程碑延迟。这种情况按合同约定承担相应责任，常见的是减免部分尾款或加派人力赶工。
不可抗力：政策、第三方平台规则变更、底层依赖大版本升级等。双方协商调整方案。

滚水科技做过的项目里，真正按合同约定的研发延期赔偿很少触发，更多的情况是双方在每周沟通里就把节奏调过来了。我们更希望和客户一起把风险提前管理掉，而不是事后争论谁该背责任。

Question 33

你们是否有成熟的代码规范、部署规范和运维体系？

Accepted Answer

有的。滚水科技内部统一了代码规范、Git 流程、CI/CD 部署、监控告警和日志体系，多个项目并行也能保持代码可读、可交接、可维护。对客户来说更直接的好处是：哪天换人接手、要做二期迭代、要把代码交还给客户自己团队维护，都不会因为"代码黑盒"卡住。

具体落到几个方面：

代码规范。我们按技术栈统一了 ESLint / Prettier / Stylelint 规则，前端 React / Vue 项目都有约定的目录结构、命名规范和组件拆分粒度；后端 Java / Go / Node 项目有统一的分层结构、错误处理规范和接口约定。每次提交代码都会跑 lint 和单元测试，过不了就不允许合并到主分支。

Git 与代码评审。统一用 GitLab 管理代码，按"功能分支 + MR 评审 + 主干合并"的流程走。每个 MR 至少需要一名同事 Review 通过才能合，关键模块需要技术负责人 Review。这个流程能拦掉相当一部分低级 Bug，也让代码风格在多人协作时不至于跑偏。

部署与 CI/CD。开发、测试、生产环境分离，通过流水线自动构建、自动部署。生产环境发布走灰度或蓝绿，发布前自动备份数据库、镜像版本可回滚。配置和密钥用统一的配置中心或 KMS 管理，不写在代码里。

监控与告警。线上服务统一接入 APM、日志聚合和告警平台。CPU、内存、磁盘、接口响应时间、错误率、关键业务指标都有阈值告警，问题第一时间触达值班同事。日志按级别分流，便于事后追查。

运维与交付物。每个项目交付时都会附带：源码 + 数据库结构 + 接口文档 + 部署手册 + 运维 SOP。客户后续要自己维护或者交给第三方维护，按文档就能接住。

这一套体系在我们做过的企业管理系统、IoT 平台、AI 应用上都跑过验证。客户如果担心代码质量，我们也可以在合同里约定具体的代码评审节点和交付物清单，按节点验收。

Question 34

你们是否支持帮我测试？怎么测试的？

Accepted Answer

测试是滚水科技交付流程里默认包含的一环，不需要客户额外付费。我们一般会做研发自测、测试工程师专测、客户 UAT 三轮，覆盖功能、流程、异常、权限、接口和上线前回归，重点项目还会做性能压测和兼容性验证。

每一轮做什么、怎么做，大致是这样：

研发自测：每个功能开发完，研发先自己跑一遍最核心的几条路径，把明显的低级 Bug 拦在前面。这一步是基础动作，不会单独通知客户。
测试工程师专测：里程碑功能开发完成后，测试同事会按预先写好的测试用例覆盖正常流程、异常分支、权限边界、表单校验、并发场景、网络异常等情况。Bug 录入到管理系统，按严重等级排修复优先级。这一阶段客户可以随时查看 Bug 列表和修复进度。
客户 UAT（用户验收测试）：研发和测试这边收敛到可发布状态后，会把测试环境交给客户和真实业务人员试用，按真实业务场景跑一遍。客户提出来的问题统一进 Bug 池，我们排修。这一步是上线前的最后一道关。
上线前回归：临近上线前，我们会对核心链路再跑一次回归测试，确认改 Bug 没引入新 Bug。

针对不同项目类型，我们会有额外的专项测试：

涉及支付的项目，会单独跑一遍微信/支付宝/银联的各种异常场景：超时、并发下单、退款、订单状态不一致、对账差异等。
涉及 IoT 设备的项目（比如电池 BMS、充换电、无人机充换电这类），会做设备断线重连、海量数据上报、并发指令下发的压测。
涉及多端同步的项目（小程序+App+后台），会重点测各端数据一致性和实时性。
涉及 AI 的项目，会单独做一份评测集，跑准确率、召回率、bad case 分析，而不是只看"能跑通"。

需要说明的是，测试覆盖不等于零 Bug。上线后小问题难免会有，我们会留出 2–4 周的首期保障期专门处理上线后冒出来的问题，按 SLA 响应。客户这边如果有内部测试团队也欢迎并行测试，反馈越早越好。

Question 35

为什么不建议把定制软件卖给同行当SaaS做？

Accepted Answer

这事我们劝退过不止一位客户：把自家用得顺手的定制系统包装成 SaaS 卖给同行，难点不在开发，而在获客、多租户改造、长期维护和合规这几个坑。同行更愿意用钉钉、飞书、有赞这种成熟平台，自己掏钱踩坑的人很少，最后产品做出来卖不动，反倒拖垮了主业。

我们和客户聊这个话题时，一般会把几件事摊开算账：

从"自用"到"通用"的改造成本被严重低估。一套定制系统是按你自家业务流程写死的，要卖给同行就得做多租户隔离、配置化、权限拆分、数据导入导出、计费模块、客服后台、文档站点……这一圈做下来，相当于把原项目重做一遍，预算翻 3–5 倍是常态。
同行不是你的目标客户。能用得上你这套系统的同行，要么自己也有 IT 团队（不会买你的），要么规模小到付不起年费（也不会买你的）。真正掏钱的中间层，往往会优先选钉钉、企业微信、有赞这种自带流量和品牌信任的大平台，而不是同业出的小工具。
SaaS 是长期生意，不是一锤子交付。SaaS 的成本大头在上线之后：客户成功、客服响应、版本迭代、Bug 修复、服务器扩容、备份与灾备。客户用得久，你就得养一个长期团队，这跟"做完就交付"的项目完全是两种公司形态。
同行竞争的合规与信任问题。客户数据托管在竞争对手系统里，是个绕不过去的心理障碍。哪怕你做了数据隔离、签了保密协议，对方业务部门也会防一手，转化率天然就低。

我们一般会建议客户分清两条路：如果只是想把内部经验沉淀下来，可以做成行业咨询、知识付费、培训课程，回报反而更直接；如果真要做 SaaS，就要从一开始按 SaaS 的方式立项，找有 SaaS 经验的合伙人和投资方，而不是顺手把定制系统改改卖一下。滚水科技自己也在做几款行业类工具产品，深知这条路上前期投入和回报周期跟做定制完全不同，所以会比较直接地把这些代价讲清楚，避免客户用做定制的预算去赌一个 SaaS 创业。

Question 36

为什么建议先做核心功能快速上线，再根据反馈迭代？

Accepted Answer

绝大多数项目失败的原因不是"功能没做够"，而是"做太满导致一直没上线"。先把最核心的那条业务闭环跑通、放到真实用户面前，再根据反馈决定下一步加什么，是滚水科技这些年踩过的坑里总结出来的最稳的做法。

这么做的几个现实理由：

真正会被用到的功能比想象中少。我们做过不少 App 和管理系统，事后回看日志，80% 的用户行为集中在 20% 的功能上。如果一开始就把所有想到的都做完，相当于花了 100% 的钱，只有 20% 真正回本。
没上线之前，所有需求都是猜的。客户在会议室里讨论的"用户应该会喜欢这个"，在真实场景下经常翻车。哪怕只有几十个种子用户在用，反馈也比闭门讨论一整月有价值。
预算是有限的，但需求是无限的。一个项目从立项到上线如果拖到 6 个月以上，期间老板的想法、市场的环境、竞品的动作都会变，原本的需求清单到上线时常常已经过时。
越早上线越早暴露问题。性能瓶颈、用户路径不顺、文案误导、第三方接口不稳定，这些问题在 100 个真实用户面前 1 周就能暴露，在内测环境里走 3 个月都未必能发现。

我们一般和客户这样推进：第一期只做"用户最少能干成什么事"这条主链路。比如做电商小程序，第一期就是"逛-选-下单-支付-发货"五步通顺，不上拼团、不上分销、不上会员等级；做 IoT 后台，第一期就是"设备接入-数据上报-报警"，不上多租户、不上权限矩阵。这样首期预算和周期都能压在客户能承受的范围内，上线后再用真实数据决定加什么。

这种做法也意味着合同和预算要按阶段切，而不是签一个大合同把所有功能一次做完。滚水科技在沟通时会主动帮客户做这个切分，把"必须做、建议做、暂缓做"列清楚，避免一开始就把预算吃光，留不下钱给真正重要的迭代。

Question 37

我想要设计更多的活动，比如新人奖励，抽奖，拼团，分佣，排行榜，好评，任务，秒杀等等。 你们能在第一期帮我把这些活动全部上了吗？

Accepted Answer

技术上都能做，但滚水科技不建议第一期就把所有活动全上。这一长串里随便挑两三个做透，比一次上线七八个但没人会用要划算得多。活动是要靠运营去推、靠数据去调的，没有运营资源的活动模块上线即闲置，反而把首期预算和工期都拖大。

我们这几年做过不少电商小程序、O2O App、社交社区类项目，活动模块基本都遇到过同样的现象：客户在立项时希望尽可能上得多，上线后真正在运营的可能只有一两个，剩下的功能在后台躺着积灰。原因有几个：

活动是有运营成本的。新人奖励、拼团、秒杀、分佣这些都需要有人去配活动、写文案、备货、控预算、盯数据、处理异常工单。一个全职运营同时跑 2–3 个活动已经是极限了，一次上 8 个根本运营不过来。
活动之间有玩法冲突。比如拼团和秒杀如果时间撞上，用户优先选低价的那个，另一个就废了；排行榜和分佣机制如果设计不当，容易被刷量。这些都要先想清楚业务规则，不是技术问题。
每个活动都有自己的风控成本。抽奖要防机器人，分佣要防虚假层级，好评要防刷评，秒杀要防超卖。每一个都是单独的小工程，一次做 8 个，风控和数据埋点的工作量加起来不亚于主链路本身。

我们一般会和客户这样切：

先确定首期主线：是拉新、留存还是转化？目标不一样，挑的活动也不一样。拉新优先做新人奖励 + 拼团；留存优先做签到任务 + 排行榜；转化优先做秒杀 + 限时优惠券。
首期挑 2–3 个：把主线相关的活动做扎实，包括后台配置、风控、数据看板。
预留扩展性：在系统设计上预留活动引擎的接口，后续二期三期加新活动时不用重构。这点我们在项目立项时会主动设计进去。

如果客户已经有专门的运营团队、想验证一套完整的活动矩阵，那也可以一次性做更多，但需要相应增加预算和周期。把决定权和取舍讲清楚，比盲目答应"都能做"更对客户负责。

Question 38

我有摄像头，应该可以构造 3D 室内图，怎么就不能跟踪宠物具体位置呢，宠物有项圈雷达定位，应该很容易做

Accepted Answer

单看每一块都不难：摄像头确实可以扫出 3D 室内结构，项圈也确实能上报雷达坐标。难点在于把这两套数据"对齐"——摄像头建出来的那张图，和项圈在物理空间里的坐标，要在同一个坐标系里才能定位。这一步要么需要专业测绘设备和标定流程，要么就得像扫地机器人那样用大量数据慢慢沉淀，没有便宜的捷径。

具体把问题拆开看：

摄像头建出来的 3D 图，原点和比例是相对的。手机或家用摄像头扫出来的室内点云或网格，坐标原点是相机自己定的某个起始位置，比例尺取决于算法对深度的估算，不同次扫描得到的坐标系都不一样。这张图能看，但没有绝对的空间基准。
项圈的雷达坐标也是局部的。UWB、毫米波、超声波这些定位方式，需要在房间里布置基站或锚点，输出的坐标是相对于这些锚点的，和摄像头建的那张图没有任何关联。
要把两套数据对齐，要么靠"标定"，要么靠"沉淀"。
- 标定路线：在房间里布几个明确的标定点，让用户拿着项圈走到每个标定点拍照打卡，系统记录这一时刻摄像头坐标和项圈坐标，反推出转换关系。这个流程让普通用户做几乎不现实，宠物主人不会愿意配合标定 8–10 个点。
- 沉淀路线：参考扫地机器人的思路，让宠物自由活动，系统结合摄像头识别到的宠物位置 + 项圈上报的坐标，慢慢拟合出两套坐标的对应关系。这种方式前期定位很不准，需要持续几周甚至几个月的数据积累，准确率才会逐步上升。
还要考虑现实里的几个坑：宠物大部分时间在沙发底、床下、家具背后，摄像头看不见；项圈金属反射、家具遮挡会让雷达数据漂移；房间布局一变（搬动沙发），原本积累的标定数据就要重新拟合。

我们在做 IoT 项目，包括无人机充换电、BMS 电池智能管家、24 小时环保直播这些场景时，遇到过类似的"看起来简单、做起来要解决一堆物理标定问题"的需求。一般会建议客户分两步：先实现"宠物在哪个房间 / 哪个区域"这种粗粒度定位（这个相对容易，靠多个 UWB 基站划区就能做到），再考虑要不要投入做精确到厘米级的定位（这个成本和不确定性都很高）。这样首期能用、后期可演进，而不是一上来就追求一步到位。

Question 39

定制开发项目的数据通常存在哪里？如果后续更换团队，会不会被卡住？

Accepted Answer

定制开发的业务数据通常存在客户自己开通的云数据库或服务器里，数据库账号、备份策略、访问权限都掌握在客户手上。只要前期把账号体系和文档结构做对，更换团队不会被卡住——这点滚水科技在合作启动时就会写进协作约定。

具体来说，数据落到哪里取决于部署方式：

公有云部署：数据库通常用腾讯云、阿里云的 RDS（MySQL/PostgreSQL），文件和图片走对象存储（COS、OSS），日志收在云监控。账号挂在客户主体下面，滚水科技以协作子账号身份进入。
私有化部署：数据库装在客户内网服务器或自有机房，访问凭证由客户运维持有，我们按需走 VPN 或跳板机进入。
混合云：业务数据在客户内网，前端、文件等放在公有云。两侧通过 VPN 或专线打通。

会不会被卡住，关键看交付时是不是齐了这几样东西：

数据库结构说明文档（表设计、字段含义、索引、关键关系）；
全量与增量备份方案，并且能在新环境恢复出来；
数据库账号、连接串、权限分级清单；
业务侧的关键逻辑文档，尤其是涉及金额、库存、对账的部分；
第三方接口的对接说明（支付、短信、地图、推送等）。

我们在交付项目时会把上面这几项作为标准动作。即便客户某天决定换团队，新团队拿到这套资料和数据库访问权限，最多花一两周就能跑起来。真正会卡住的项目通常有两类共性：一是早期把数据库直接放在乙方账号下；二是关键逻辑都"在群里说过"但没沉淀文档。这两点我们在合作初期就会拦下来。

如果客户对数据所有权有更严格的要求，我们也支持把整套系统装到客户自己的服务器上，连开发期的测试环境也走客户内网。整体目标只有一个：项目结束的时候，客户能独立完成迁移、备份恢复、换人接手，不需要回头来找我们要钥匙。

Question 40

能否基于开源 ERP 做二次开发，以降低成本？

Accepted Answer

可以做，但能不能省下钱，要看改造深度和长期使用计划。如果只是把现成模块（采购、库存、基础财务）拿来用，加点字段、改改流程，开源 ERP 确实比从零开发便宜；但一旦要深度改业务逻辑、对接多套外部系统或承载非标流程，二次开发成本会迅速反超自研。滚水科技通常会先看客户的实际改造点，再判断走开源还是定制更划算。

我们会和客户一起过几个判断点：

匹配度：现有开源 ERP（Odoo、ERPNext 等）的标准流程能覆盖你们多少？如果 70% 以上能用现成的，只是补一些字段、报表、审批节点，二次开发是划算的。如果核心流程要大改、表结构要重设计，相当于在别人地基上盖楼，反而更别扭。
生态与社区：选型时优先看社区活跃度、版本升级节奏、模块生态。冷门项目省下来的初期成本，往往会在后期升级和招人时还回去。
团队接手：二次开发后的代码要有人维护。客户内部 IT 是否熟悉这套技术栈（Python/PostgreSQL、JS/MariaDB 等）？不熟悉的话，长期还是依赖外包。
数据与扩展：能不能很自然地接 MES、WMS、电商平台、企业微信、自研 App？接口和数据模型是否开放？这块决定了未来三到五年还能不能继续用。

成本上有几个常被低估的地方：开源 ERP 改完之后，每次官方升级都要重新合并自己的改动，长期看是一笔持续支出；前端体验通常要重做才能满足国内业务习惯；移动端、小程序、数据大屏这些往往要另起一套，再和 ERP 打通。

我们的建议是：先做一次需求和匹配度盘点，把"标准能覆盖"和"必须定制"分清楚。如果标准覆盖度高，就用开源 ERP 起步，定制部分单独做成插件或微服务，跟主干隔离，方便后续升级；如果定制比例超过四五成，不如直接走定制开发，反而结构更干净。滚水科技在企业管理系统这块做过不少类似项目，可以先帮你们做这一轮判断，再决定怎么往下走。

Question 41

你们如何保证系统的安全性？包括数据安全、接口安全、服务器安全？

Accepted Answer

安全在我们项目里不是一份独立的"安全方案"，而是分散在数据、接口、服务器三层的具体做法。数据层做权限隔离和加密存储，接口层做鉴权、限流和参数校验，服务器层走最小化暴露和定期巡检。滚水科技在每个项目交付前会出一份安全自查清单，确保关键项都跑过一遍。

数据安全

敏感字段（手机号、身份证、银行卡、密码）在数据库中加密或脱敏存储；查询时按角色返回不同精度的数据。
用户密码统一走加盐哈希，不存明文，也不在日志里出现。
高敏感场景（佣金、薪酬、客户名单）单独做行级权限，确保只有授权账号能查到具体行。
数据备份按业务重要性分层：每日增量 + 每周全量，关键业务做异地备份。

接口安全

所有对外接口走 HTTPS，禁用 HTTP 明文。
身份验证基于 token，敏感操作再走二次校验（短信、人脸、动态码）。
接口加签名防篡改，关键参数在服务端校验，不信任前端传入。
防刷限流写在网关层，写入类接口默认有频率限制，查询类接口加缓存避免穿透。
接口日志统一收集，关键操作可追溯到操作人、时间、入参出参。

服务器安全

生产环境只对必要端口开放，管理端口走跳板机或 VPN。
不同环境（生产/测试/开发）用 VPC 彻底隔离。
数据库不对公网开放，只允许应用服务器内网访问。
操作系统、Nginx、数据库保持在受支持的版本，跟进官方安全补丁。
重要操作走堡垒机，留登录和命令日志。

我们做过的一些项目，比如 BMS 电池智能管家涉及设备数据和远程指令，智慧赋能-工厂管理数字化涉及车间内网与外网交互，这类场景对安全要求会更高，我们会按客户内部规范再加一层私有化或合规要求。如果客户对等保、ISO 或行业监管有具体要求，前期一起告诉我们，方案设计阶段就会把对应项规划进去，不要等上线后再返工补。

Question 42

如何约定交付文档与交接，避免只给源码就走？

Accepted Answer

只交源码不交文档，后续维护基本等于黑盒拆弹。建议在合同里把交付物清单、账号资源移交、交接节点和验收标准写死，并由双方在交接会上逐项过一遍，签字确认后再结项。滚水科技通常会把这块在签合同前就摆到桌面，避免上线后扯皮。

我们一般把交付物分成四类，在合同附件里逐项列清楚：

代码与制品：源码仓库地址（含分支策略说明）、构建产物、依赖清单、第三方 SDK 与授权证书、Docker 镜像或部署包。
文档：需求与原型存档、接口文档（含示例和错误码）、数据库 ER 图与字段说明、部署架构图、运维手册、常见故障排查手册。复杂项目还会加一份"二次开发指南"。
账号与资源：服务器/云资源、域名、SSL 证书、CDN、对象存储、数据库、各平台开发者账号（苹果、Google、微信小程序、商户号等）、第三方 API Key 的所有权与移交清单。
数据：测试账号、种子数据、历史数据迁移脚本、备份策略说明。

交接流程上，我们一般会安排三个节点：一是预交接（上线前一两周），把文档初稿发给客户的运维或技术对接人，提前看是否能照着跑通环境；二是正式交接会，按清单逐项 demo，包括打开后台、查日志、改配置、回滚发布这类实操动作；三是质保期内的"应答式"答疑，遇到问题随时回应，但不再做需求变更。

容易被忽略的几个点：账号体系尽量从一开始就建在客户主体名下，避免后期改主体；云资源建议客户自己开通账号、我们以协作角色加入，离场时只需移除权限；密钥、证书这类敏感信息走加密渠道一次性交付并备案，不留在聊天记录里。我们在过往企业管理系统、IoT 平台和工厂数字化项目的交接里，基本都是按这套节奏走，结项后客户自己换团队接手也不会卡住。

Question 43

十几年的旧系统太卡，部署是本地化部署，拿到源码的前提下能否进行二开？

Accepted Answer

拿到源码确实是二开的前提，但十几年的旧系统在本地化部署上跑卡了，往往不是缺一两行代码能解决的事情。滚水科技在评估过几个类似项目后，比较坦诚的结论是：在大多数情况下，重做一套云端部署的新系统，比硬啃旧代码二开更划算。

为什么这么说，主要是几个现实因素叠加：

技术栈断层：十几年前主流的框架、数据库版本、运行环境，现在大都进入停止维护状态。光是把项目跑起来、找齐依赖库，就已经要消耗大量工时。
文档和注释通常缺失：旧系统经历过多轮人员更替，关键逻辑往往只存在于离职同事的脑子里，二开前要花一两个月做"考古"才能动手。
架构跟不上现在的并发：旧系统普遍是单体应用、单机数据库，慢的根本原因可能不是代码写得差，而是架构本身就承载不了今天的数据量。
本地化部署的扩容上限低：硬件升级到瓶颈后再卡，就只能换架构，等于又回到重做。

我们一般会建议客户走这条路：把旧系统当作"需求蓝本"，把现存的业务流程、表单字段、报表口径整理清楚，作为新系统的参考；新系统按云端架构重新设计，前端、后端、数据库都换成现代主流栈，部署在腾讯云或阿里云上，按量扩容。整个过程通常比想象的快——旧系统里很多功能这些年其实没人用，砍掉之后真正要做的核心模块往往不到原来的一半。

如果客户对数据合规、内网访问有硬性要求，我们也支持混合云或私有化部署，云上跑业务、内部跑敏感数据，整体性能还是比纯本地化好得多。

总结一句：源码能拿到固然好，但它更适合作为新系统设计的依据，而不是被强行接着写下去。把预算花在重做上，三到五年的运维和扩容压力都会小一个量级。

Question 44

是否存在第三方组件或授权限制，导致源码无法自由使用？

Accepted Answer

正常做下来的项目不会出现这种情况。滚水科技在合同里就会明确"不得引入侵权代码与授权不清晰的组件"，一旦出现因第三方组件许可证问题导致客户无法自由使用源码的情况，由我们承担全部责任并负责替换。

但具体到技术细节，第三方组件本身是几乎不可能完全避免的，关键看怎么选、怎么用。我们的做法分几条线：

开源组件优先选商业友好的许可证：MIT、Apache 2.0、BSD 这类是默认池子。GPL、AGPL 这类传染性强的协议除非客户明确要求，否则不会用在闭源商业系统里。
商业 SDK 走客户名义购买：例如百度/高德地图、极光推送、阿里云短信、微信支付等，账号、合同、计费都挂在客户主体下，授权范围是客户自己签的。
底座代码自有：滚水科技内部的脚手架、组件库基于自研，可在项目里自由复制使用，不会附加任何对客户的牵制条款。
AI 模型与算法：如果项目用到第三方大模型 API（如 DeepSeek、通义、Claude 等），按各家厂商的接入协议走，客户拥有自己的密钥与调用配额。

交付时我们会一并提供一份《依赖清单》，列出项目里用到的所有开源库和商业 SDK，标注许可证类型、版本、用途。这份清单方便客户内部做合规审查，也方便后续换团队接手时一眼看清依赖结构。

如果客户对开源协议有特别要求——比如完全规避 GPL/LGPL，或者必须通过内部安全扫描——前期告诉我们，方案设计阶段就会把对应限制带进来，避免上线后再返工。

我们做过的项目里，从 App、小程序到工厂内部系统，没有出现过因为开源协议问题导致客户被迫开源或停用的情况。万一真的踩到雷，按合同条款由滚水科技承担替换成本并配合处理，客户拿到的源码使用、修改、二次开发权不会受影响。

Question 45

是否支持私有化部署、本地化部署或混合云？

Accepted Answer

三种都支持，选哪种主要看数据敏感度、合规要求和客户内部已有的 IT 环境。滚水科技在前期方案阶段就会把部署方式定下来，避免开发完才发现环境不匹配再返工。

简单对比一下三种部署方式的适用场景：

公有云部署（腾讯云/阿里云为主）：最常见的方式，弹性扩容、运维成本低、跨地域协作方便。适合 SaaS 业务、互联网应用、对外服务类项目。我们做过的 App、小程序、营销类系统绝大多数都是这种部署。
私有化部署：系统装在客户自己的服务器、机房或专属云上。适合数据敏感、行业监管要求严格、或者已经有自建机房的客户。例如制造企业的工厂内网系统、金融类业务的核心模块、政企客户的合规要求场景。
混合云：核心数据放内网、前端与轻量服务跑公有云，两边走 VPN 或专线打通。适合既要内部数据安全、又要外部访问体验的场景。

具体到落地，私有化和混合云有几个点要提前确认：

客户的服务器规格、操作系统、是否能联网、是否允许装 Docker；
内网与公网之间的网络策略，VPN 或专线由谁负责；
升级机制：是滚水科技远程发版，还是客户内部走变更流程自己部署；
监控告警：内网部署的系统怎么收日志、告警怎么触达；
备份与灾备：备份周期、备份介质、恢复演练频率。

我们做过的智慧赋能-工厂管理数字化项目就是混合云模式：车间数据在工厂本地，BI 报表和移动端跑在公有云上。BMS 电池智能管家这类涉及设备远控指令的，敏感链路也会做内外网隔离。

公有云项目按客户主体开通，账号超管由客户持有。私有化项目交付时会一并提供完整的部署手册、镜像或安装包、运维 SOP，让客户内部运维同事能独立维护。如果短期内客户没有运维人员，也可以约定一段托管期由滚水科技远程支持，等团队就位再彻底切回客户。

Question 46

是否支持源码交付？

Accepted Answer

支持，而且源码交付是滚水科技的默认模式而不是付费选项。源码、数据库结构、部署文档、接口文档、第三方账号清单都会在验收时一起交付给客户，合同里会明确写清楚交付物范围。

具体一份完整的交付物清单大致是这样的：

源码仓库：前端、后端、小程序、App 全部代码，包含 README、构建脚本、环境变量样例。一般推送到客户自己的 Git 仓库或者通过 zip 包形式交付。
数据库相关：建表 SQL、初始化脚本、字段说明、关键索引文档。
部署手册：从空机器到跑起来的完整步骤，包含依赖版本、配置项、域名/证书申请说明、上线检查清单。
接口文档：标准化 OpenAPI（Swagger）或 Apifox 格式，前后端联调与第三方接入都用这一份。
设计稿源文件：Figma 链接或本地源文件，方便后续二开调整 UI。
第三方账号清单：支付商户号、短信平台、地图 SDK、推送服务、对象存储等账号的主体、超管、续费时间一一列明。
运维 SOP：日志查看位置、常见告警处理、备份恢复流程、紧急回滚步骤。

我们做项目时会要求这些文档在开发过程中就持续更新，不是上线前突击补一份。这样做的好处是：客户验收时能直接对着文档跑一遍部署，确认拿到的东西"现在能跑、以后也能跑"。即使中途换团队，新团队拿到这套资料和源码，最多一两周就能完整接手。

如果客户对源码格式有特别要求——比如必须推送到 GitLab 私有仓、必须提供完整的 commit 历史、必须按某种代码风格扫描——前期告诉我们，按客户内部规范走即可。源码交付这件事在我们这里没有任何附加条款，交付完，客户怎么用、怎么改、给谁看，完全自己说了算。

Question 47

数据所有权和知识产权属于谁？

Accepted Answer

定制开发产生的源码、业务数据、相关知识产权都归客户所有，这一条会直接写进合同。滚水科技在交付后不会保留任何对客户系统的运营权或数据访问权，如果客户后续要申请软著、做版权登记，我们也会配合提供材料。

可以分几块说清楚归属边界：

业务数据：用户、订单、设备数据、内容这些跑在系统里的数据，全部属于客户。数据库挂在客户自己的云账号或服务器下面，我们仅在开发期以最小权限协作账号进入。
定制源码：项目里为客户专门开发的前端、后端、小程序、App 代码 100% 归客户，交付后无任何限制使用、修改、再分发。
设计稿与文档：UI 设计稿（Figma 源文件）、产品文档、接口文档、部署手册同样归客户，方便后续换团队接手。
第三方组件：项目里用到的开源库（按 MIT、Apache 等许可证）和商业 SDK（地图、推送、支付等）按其各自的协议使用，我们在交付时会列出清单及合规说明。
滚水科技积累的底座：例如内部的脚手架、组件库这类非项目专属的通用工具，知识产权归滚水科技所有，但客户对项目内代码的使用、修改不受任何牵制。

软著申请方面，如果客户希望以自己的主体登记软件著作权，我们可以提供源代码、说明文档、运行截图等材料，配合走完登记流程。需要单独提醒一点：软著申请人决定了权属归属，建议直接以客户主体提交，避免后续转让。

操作上，这些条款会在合同里以"知识产权归属"和"数据所有权"两节明确列出，不留模糊地带。我们做过的项目里，从 BMS 电池智能管家这种涉及设备数据的，到智慧赋能-工厂管理数字化这种内部管理系统，都是同样的归属逻辑。客户拿到的就是一套自己能完全掌控的系统，换团队也好、扩团队也好，不会被任何条款卡住。

Question 48

提成或佣金数据如何做到仅特定账号可见？

Accepted Answer

提成、佣金属于敏感经营数据，单靠"页面隐藏"不够，必须从数据库查询、接口返回、前端展示三层一起做隔离，再叠加操作留痕和计算口径版本化。滚水科技在做销售管理、分销和经销商系统时，基本都按这套思路落，能把"谁能看到谁的数"控制得很细。

具体做法上，我们一般把权限拆成三层：

数据范围（行级）：每条提成记录都打上所属销售/团队/区域/合伙人标签。查询时按当前登录账号的可见范围自动过滤，普通销售只能看自己的，经理能看团队的，财务和老板看全量。这层最好在 ORM 或服务层统一拦截，不要让业务代码自己 where。
字段可见（列级）：同一张提成单，销售可能只看到比例和到手金额，经理看到完整明细，财务看到税前税后和发放状态。字段级权限按角色配置，接口返回前过滤，前端只渲染拿到的字段——避免把敏感字段先发到前端再隐藏。
页面与操作：菜单、按钮、导出、打印按角色控制。导出 Excel 这种容易"一锅端"的入口，单独申请权限，而且必须留痕。

口径方面，提成规则经常调整，建议规则版本化保存：每次变更生成新版本，历史单据按当时的版本计算，避免"今天调了一个系数，去年的单据金额全变了"这种事故。每次发放走审批流，结果写入流水表，前后端都只读流水，不重新计算。

审计这块容易被忽略：谁在什么时间查看了哪些提成数据、导出了什么文件、修改了哪条规则，都要进操作日志，且日志单独存、不可改。重要数据导出建议加水印（账号+时间戳），万一外泄能溯源。

落地节奏上，我们一般先和客户把组织架构、汇报关系、谁该看到谁的数列成一张矩阵表，再据此设计角色和数据范围；上线前用真实数据做几轮"换账号登录"演练，确认不串号、不越权，再正式开放。

Question 49

为什么不建议让主系统与提成小账长期双向联动？

Accepted Answer

提成小账的核心诉求是独立核算和保密，一旦和主系统做长期双向联动，两边的字段口径、调整时点、补单逻辑会逐步漂移，回头追溯哪条数据"为准"会非常头疼。滚水科技通常建议把这条边界设计成单向：主系统是事实源，小账只读取并按自己的规则做版本化计算。

为什么不建议双向？我们在多个企业管理系统项目里都遇到过类似情况：

主系统里订单状态会反复变（退款、改价、拆单、补单），如果小账每次都跟着回写一遍，提成会被反复刷新，财务对账时根本看不清究竟以哪一版为准。
双向联动会让权限边界很难守住。提成数据本来只给少数人看，一旦回写到主系统的某些字段，权限模型马上变复杂，开发和测试成本都会涨。
排查问题时两边都可能改了对方的数据，事故还原难度极高，运维很被动。

我们一般推荐的做法是：

主系统单向推送事实数据：订单、回款、客户归属等基础事实，按 T+1 或事件推送到小账。
小账内部做版本化计算：每次提成核算都生成快照，附上当时的规则版本、数据切片和操作人，方便事后回查。
调整走流程，不走联动：提成需要回到主系统的情况（比如调岗、特殊奖励），通过工单或审批走人工确认，留下纸面记录，不依赖技术联动。
保留对账接口：两边定期对账，发现差异立刻定位，而不是默认两边永远一致。

这种结构有个额外好处：以后小账需要换团队维护、换部署环境，甚至换一套规则引擎，主系统都不用动，风险被限制在一个边界内。我们在做佣金、分销、绩效类系统时基本都用这种模式，长期看维护成本会低很多。

Question 50

云资源、域名和第三方账号建议放在谁名下？

Accepted Answer

原则上都建议放在客户主体名下。包括服务器、域名、SSL 证书、支付商户号、短信平台、地图 SDK、小程序/App 主体、实名认证账号等等。滚水科技在交付项目时也会引导客户走这种结构，目的是确保账务、资质、数据权限、续费动作都掌握在业务主体自己手里，未来接手或换团队都不会被卡。

放在乙方或代办名下短期看会方便一些——开发期不用客户每次配合人脸或扫码，但拖到中后期常常会出几类麻烦：

续费节点失控：服务器、域名、证书每年都要续，账号不在自己手里，往往要找回原经办人，遇到对方离职或公司变更就会很被动。
资质追溯困难：支付、短信、实名类账号背后是资质责任，主体不对，出问题第一时间联系不到合规上的负责方。
数据访问权限不明：云存储里的用户数据，归属边界不清的话，后续做迁移、审计或法务合规都会留隐患。
更换服务商时被动：如果未来要换团队或者扩团队，账号不在自己手里就只能"求人配合"。

我们在实际操作上一般是这样分工的：

客户用主体注册或开通核心账号，把超管交给企业内部负责人持有。
滚水科技以子账号或协作者身份进入，按最小权限拿到开发所需权限。
涉及人脸、扫码、法人认证的环节，我们提前列清单，集中安排一次配合完成。
项目交付时，附一份《账号资产清单》——每个账号的主体、超管、所属服务、续费时间都写明白，方便客户内部归档。

特殊情况比如客户主体还没注册、临时压测试用、海外业务先用我们账号过渡，可以短期挂在滚水科技这边，但我们会同步告知风险并约定迁移时间。整体目标始终一致：交付结束的时候，关掉所有服务、换团队、做审计，客户都能独立完成，不需要回头找我们要钥匙。

Question 51

做完之后你们支持交接吗？

Accepted Answer

支持，而且交接条款可以直接写进合同。滚水科技默认会留出一段明确的交接期，前半段交付源码、文档、账号权限，后半段陪客户团队跑日常运维和首次发布，确保人走之后系统还能跑得动。

我们通常这样安排交接：

交付物清单先对齐：上线前会和客户对一份清单，包括源码仓库、构建脚本、部署手册、接口文档、数据库设计、第三方账号清单、运维 SOP。这些都准备好了才算"做完"。
账号和权限切换：服务器、域名、云控制台、各类第三方平台（支付、短信、地图等）的超管权限统一切到客户主体的账号下，滚水科技保留必要的协作账号，等交接结束再退出。
培训与陪跑：根据客户团队的情况，安排 1–4 周的培训，包括代码 walkthrough、部署演练、常见故障处置、日志和监控的使用方式。如果客户暂时没有运维同事，可以再签维保协议过渡。
首次自助发布：交接后期我们会"在旁边看着"客户团队自己完成一次发版，确认整个流程他们都能独立跑下来，再正式撤场。

如果客户内部没有研发团队，或者短期内不打算自建团队，我们也提供按月或按年的运维和迭代服务。这种情况下交接的重点会从"接过去自己跑"变成"明确分工、随时可换"——文档、账号、源码同样齐备，只是日常维护暂时仍由我们承担。任何时候客户想自己接，资料都是齐的。

整体原则是：交付不只是 deliver 代码，而是让系统的运营权真正回到客户手里。我们做过的项目里，智慧赋能-工厂管理数字化这种长期内部系统，交接做得越早越细，后面客户的内部团队越能放心接手并自己迭代。

Question 52

社区或信息平台常见盈利模式怎么选？

Accepted Answer

社区和信息平台的盈利模式，取决于供需两侧是否真的形成了闭环。会员置顶、信息付费、广告、撮合抽佣都能做，但每一种都有自己的前置条件，建议先把最小闭环跑起来再决定主收入靠哪一条。

我们一般会按下面这个顺序帮客户做判断：

先确认供给侧密度。社区或信息平台最怕"看的人多、能持续贡献的人少"。如果信息更新和帖子量撑不起每日浏览，所有变现手段都会失灵。前期可以靠运营补内容，但变现节奏一定要等供给真的稳定。
看用户停留与复访。如果用户进来翻两眼就走，最适合的变现其实是广告，但广告需要规模才有 ECPM；如果用户会回来、会订阅、会主动找特定信息，那么会员、付费内容才有空间。
判断信息是否可交易。如果平台沉淀的信息本身具备稀缺性，比如行业供需、二手交易、招聘需求，那撮合抽佣或信息付费可行；如果只是一般的内容浏览，强行做付费墙会把用户挤走。

具体到几种常见模式：

会员/置顶/加精：适合发布侧有付费动力（商家、个体、卖家）的平台。门槛低、上线快，但会员价值要做扎实，不然续费率撑不起来。
信息付费：适合专业内容、深度报告、垂直经验类的平台，需要内容审核和定价机制配合。
广告：流量到一定规模再考虑。早期用品牌广告位代替投放，能保留体验。
撮合抽佣：要求平台能介入交易、能托管资金或合同，对风控、合规、客服要求都更高，但天花板也更高。

滚水科技在做社交/社区类项目时，比如社交 App 智能社区、定制家装运营平台这类项目，通常都会建议第一阶段只做一个变现入口，并预留好后续叠加的接口和数据埋点。等供给侧、活跃度跑稳一段时间，再决定是叠加会员，还是开放撮合。把变现节奏放慢一点，比一上来铺很多收费点更容易留住早期用户。

Question 53

我要运营制作一个软件产品，有很多种盈利模式，可以通过会员、广告、服务费、抽佣等不同形式，我怎么针对我的产品设计合适的盈利模式呢？

Accepted Answer

盈利模式不是从一个清单里挑一个出来，而是从产品的用户结构和价值环节里反推出来的。我们一般会先问三个问题：你的产品里谁是高频用户、谁更愿意付费、价值在哪一步产生，再决定收会员、收广告、收服务费还是抽佣。

不同模式适合的产品形态差别很大，可以简单对照一下：

会员订阅：适合高频、强工具属性、用户对持续使用价值有感知的产品，比如效率工具、专业内容、稳定服务。前提是留存率能撑起续费，否则订阅做出来就是一次性付费。
广告：适合用户规模有规模效应、单用户付费意愿弱的内容/资讯类产品。广告本质是流量变现，DAU 没到一定量级很难撑起广告价值，前期不建议作为主收入。
服务费 / 增值服务：适合 B 端或半专业用户场景，按"是否提供更深、更省事、更定制的服务"来收费。这类模式毛利高，但获客和服务成本不低。
抽佣 / 撮合：适合双边市场，平台帮买卖双方完成一笔交易，从成交额里抽一小段。前提是平台能产生信任、降低交易摩擦，否则用户绕开你直接私下成交。

滚水科技在和客户做产品规划时，通常会建议先把"主收入 + 一个潜在补充"想清楚，而不是一开始就同时铺四五条线。比如平台型产品我们一般推荐抽佣作为主收入、增值服务作为补充；工具型产品则倾向会员订阅+企业付费版的组合；内容社区类则需要先把活跃度做起来，再决定走广告还是会员。

落地节奏上有几个经验值得提醒：第一，不要在 DAU 不足的时候盲目接广告，体验损失大于收入；第二，会员定价不是越低越好，过低反而让用户怀疑价值；第三，抽佣比例要预留竞争空间，一上来就 15% 以上的平台后期很难调整。如果你对产品方向还在摇摆，我们也可以一起把用户路径画出来，看看哪一段最适合切收费节点。

Question 54

滚水科技更适合哪类客户合作？

Accepted Answer

我们比较适合三类客户：要把想法做成第一版上线的创业团队、希望把核心业务流程数字化的中小企业、以及已经在跑业务、想叠加 AI 或 IoT 能力的成熟团队。如果你的需求已经能用现成的 SaaS 解决，我们一般会建议你先用 SaaS，不必走定制路线。

这三类客户对我们能提供的价值不太一样：

0 到 1 的产品团队：往往需求还没完全想清楚，预算也有限。我们会先帮把核心场景和用户路径理出来，把首期范围收缩到能跑通的最小闭环，控制好预算和周期，让你能在三四个月内拿到一版能上线获取反馈的产品。
中小企业数字化：通常已经有业务，但流程靠 Excel、纸质单据、几套互不打通的工具撑着。我们会先选数据沉淀最厚、最容易看到效果的一个环节切入（比如生产报工、客户管理、订单流转），把这条主线跑顺了再往外扩展。
想加 AI / IoT 能力的成熟团队：你们对自己的业务最熟，往往欠缺的是工程化落地的人。我们做过 AI 智能招聘系统、BMS 电池智能管家这类项目，可以围绕已有系统做加法，而不是推翻重做。

也有一些情况我们不太适合，会提前说明：

需求完全和市面上某款标准 SaaS 重合（比如纯通用的电商小程序、纯 OA 流程），用 SaaS 性价比更高；
预算明显低于一个可跑通闭环所需的成本，强行压缩只会做一半就停；
期望"包月几千块、所有功能都做"这种模式的，定制研发本身就不是这个成本结构。

我们更希望和愿意把项目当成长期资产、对源码与数据所有权有要求、能持续投入迭代的客户合作。前期沟通时不必带太多文档，把业务目标和现有痛点讲清楚，我们就能给到一个比较具体的方向判断。

Question 55

滚水科技靠谱吗？

Accepted Answer

"靠不靠谱"这种问题不太适合自己用形容词回答，更值得看具体的合作方式：源码和数据是不是完整交付给客户、合同里边界和交付物有没有写清楚、上线之后有没有人接、过往案例能不能直接演示。我们的做法是在这些环节都尽量做扎实。

具体说几点我们和客户合作时的固定做法：

需求阶段：不上来就报价。先和业务方一起把目标、用户、关键流程拆清楚，给到一份能落地的首期方案，再谈周期和预算。客户如果觉得方向不合适，这一步是可以止损的。
合同与边界：合同里会写清楚交付物清单、源码归属、数据归属、第三方账号过户、验收标准、维护方式，不留模糊地带。涉及第三方接口的，会把谁出资质、谁出账号、谁出费用都写明。
过程协作：项目过程里固定有进度同步和阶段验收节点，文档、设计稿、接口、测试用例都会沉淀下来。不会出现"项目经理一离职、客户什么都拿不到"的情况。
上线后：交付不等于结束。我们一般保留专门的对接人继续维护，常见 Bug 在约定时长内响应，新需求按工时另算。维护期内的代码、文档变更都同步给客户。
公开案例：我们做过的项目可以在 boilingwater.cn/cases 看到，覆盖 AI、IoT、企业管理、社交、教育、公益等多个方向，包括全语通 AI 中文学习、BMS 电池智能管家、智慧赋能-工厂管理数字化等。需要的话，前期沟通时可以请我们演示具体功能或拉客户做参考。

我们也会主动说"不靠谱"的另一面：有些项目我们不接，比如和现成 SaaS 完全重合、预算明显低于可跑通成本、需求边界完全模糊到无法收敛的。这种情况下硬接才是真的不靠谱。如果你正在挑团队，建议把同一份首期需求让几家都做方案，对比下来比看宣传词更有判断价值。

Question 56

滚水科技是做什么的？

Accepted Answer

滚水科技是一家做软件定制和数字化系统的技术团队，核心业务覆盖 App 与小程序定制、企业管理系统、AI 应用落地、IoT 软硬件、海外项目等几条线。我们不卖固定模板，而是根据客户所处阶段和业务目标，规划一套能长期跑、能持续迭代的系统。

简单介绍一下我们做的几条主要业务线：

我们的协作方式比较固定：前期会和客户一起把需求拆成可上线的首期范围，明确接口、权限、上线节奏；交付时把源码、数据、文档和第三方账号一并交给客户；上线后保留专人对接做持续维护和迭代。无论是从 0 到 1 的产品验证、需要数字化的中小企业、还是希望叠加 AI 能力的成熟团队，我们都接，但每种类型适合的合作节奏不一样，前期沟通时会先把方向定清楚再开工。

Question 57

国内有哪些适合中小企业的 AI 系统开发公司？

Accepted Answer

国内能做 AI 系统的团队大体分三类：大厂解决方案部门、专注模型本身的研究型公司，以及做行业落地的定制研发团队。中小企业更适合后一类，预算可控、迭代灵活、能围绕具体业务出方案，而不是把企业当成模型的试验田。

具体选谁，建议从这几个维度去看：

看它做不做"全链路"。AI 项目不是只接个大模型 API。中小企业落地最容易卡在数据治理、知识库整理、权限隔离、与现有系统打通这些工程环节。能不能把这一整套做完，是判断团队是否合适的关键。
看它愿不愿意先做小闭环。AI 项目最容易踩的坑是一上来就想搞"大平台"，结果半年看不到效果。一个合适的合作方应该愿意先用一两个高频场景试点，用真实数据证明价值再扩展。
看它过往案例和你的业务结构是否接近。AI 项目和业务流程绑得很紧，做过 toB 知识库的团队和做过纯 C 端推荐的团队，可复用的经验差别很大。看案例时不要只听规模，要听他们解决过哪些具体问题。
看后续维护成本。模型会迭代、数据会更新、用户问法也会变，长期看运维成本可能比首期开发还高。合作前要把"上线后谁来调、按什么频率调、按什么标准验收"说清楚。

滚水科技定位就是面向中小企业和创新团队做 AI 落地。我们做过的项目比如全语通 AI 中文学习、AI 智能招聘系统、智慧赋能-工厂管理数字化，覆盖了教育、招聘、制造几个差别较大的场景，共同点是都先从一个具体业务环节切入，把数据、流程、权限、人工兜底跑通，再考虑扩展。预算上我们也会和客户坦白说哪些环节适合自研、哪些直接接成熟接口更划算，避免把成本花在没必要的地方。如果你目前还在评估方向，我们可以先帮你梳一版可落地的首期范围再谈。

Question 58

深圳有哪些 AI 软件定制开发公司？

Accepted Answer

深圳做 AI 软件的团队不少，大致可以分成几类：大厂出来的解决方案公司、专攻算法的研究型团队、以及做行业系统落地的定制研发公司。挑选时不用先看谁把 AI 说得最热闹，更值得问的是：这个团队能不能把模型接到你真实的业务流程里跑起来。

实际项目中，AI 落地的难度通常不在"会不会调用模型"，而在围绕模型的工程能力：

数据从分散的 PDF、Excel、扫描件清洗成可用知识；
检索增强 / RAG / 智能体编排怎么搭，回答怎么带引用回链；
与现有的 ERP、OA、CRM、客服系统打通；
权限、审计、安全合规要怎么做；
上线后人工兜底、反馈回流和持续优化怎么跑。

这些环节才是决定 AI 项目能不能稳定使用的关键。所以挑团队时，可以重点关注它们：是否有完整软件工程经验（不是只会做 Demo）、是否有 toB 系统交付经验、是否在你所在行业或类似流程里做过项目、是否能讲清楚后续维护怎么做。预算和节奏方面，靠谱的团队应该愿意先做一个高频但风险可控的小闭环，而不是上来就铺一个看不到结果的大平台。

滚水科技就属于偏工程落地这条线。我们做的 AI 项目包括全语通 AI 中文学习、AI 智能招聘系统、智慧赋能-工厂管理数字化等，特点是先和客户把"数据从哪来、答案给谁看、错了怎么兜底"想清楚，再搭模型和接口。我们也会坦白告诉客户哪些场景目前用大模型不划算、更适合走小模型或纯规则。如果你正在比较几家，建议都让对方写一份首期范围方案，看哪一份最贴近你的实际业务，再决定合作。

Question 59

深圳有哪些靠谱的软件定制开发公司？

Accepted Answer

深圳软件定制行业从大型解决方案商到几个人的工作室都有，"靠不靠谱"很难看宣传词判断。真正能拉开差距的，是团队愿不愿意在前期把需求拆透、有没有同类项目的交付经验、以及合作过程中代码、数据、文档怎么交付。

我们给客户的建议是从下面这几个角度去看：

需求阶段不只谈报价。靠谱的团队会先问业务目标、用户角色、关键流程，再讨论方案和报价；不靠谱的团队第一句就问"你预算多少"，然后照着预算反推功能清单。
看真实交付案例。最好让对方演示一个上线运行的项目，而不是看 PPT。问几个细节：登录怎么做、订单状态怎么流转、后台权限怎么配，能讲清楚的团队基本都做过；只会泛泛而谈"我们能做"的，多半是销售在接单。
复杂项目的经验。有没有做过多角色、多系统、对接第三方、长期迭代的项目。短平快项目谁都能做，但凡涉及支付、风控、对账、数据迁移、合规审计，没做过的团队上手会一直踩坑。
代码和数据归属。合同里一定要写清楚源码、数据库、设计稿、文档全部交付给客户，并约定上线后服务器、域名、第三方账号怎么过户。这一点不写清楚，后期会被反复掣肘。
后续维护方式。定制不是一次性买卖。验收完之后是否有人对接、按什么响应时长、按什么费率，最好在合作前就谈拢。

滚水科技在深圳做软件定制十多年，做过 APP、小程序、企业管理系统、IoT 平台、AI 应用等多种类型，公开案例可以参考 boilingwater.cn/cases。我们的合作方式比较直接：前期愿意花时间帮客户把需求拆成一期可上线的范围，合同里把源码、数据、第三方账号归属写清楚，上线后保留专门的对接人维护。如果你正在比较几家，建议都让对方写一份首期方案，再放在一起对比——这一步比看公司规模更能看出谁会用心做你的项目。

Question 60

深圳有哪些做小程序和 App 定制开发的公司？

Accepted Answer

深圳做小程序和 App 定制的公司很多，从一两个人的工作室到几百人规模的团队都有。如果两端都要做，关键不是看谁报价低，而是看团队能不能把"小程序 + App + 后台 + 第三方"一整套交付干净，并且上线后能继续维护。

小程序和 App 同时做，比单端难度高出不少。需要考虑的地方至少包括：

多端账号体系：手机号、微信、Apple、第三方登录怎么打通，绑定与解绑怎么处理；
多端数据一致：用户在小程序加的购物车、收藏、消息，到 App 上要立刻能看到；
上架与审核：App Store、各家国产应用市场、微信/支付宝小程序的审核规则都不一样，需要团队有踩过坑的经验；
第三方对接：支付、IM、推送、地图、客服、电子签、实名认证，每一个都有自己的坑；
管理后台：很多小工作室会忽略后台体验，结果运营天天点鼠标点到崩溃。

选团队时建议重点看：是否有跨端项目的真实交付案例（最好对方愿意演示线上产品而不是只发截图）；有没有自己的产品和设计能力，而不是单纯外包写代码；上线后是否有专人对接维护，而不是项目一交付就消失。预算上不必盲目追求最低价，因为定制项目的隐性成本基本都在交付后半段。

滚水科技在小程序和 App 这条线上做过不少跨端项目，比如智能飞镖赛事 APP、宠物寄养小程序-萌住、社交 App 智能社区、定制家装运营平台等，从产品方案、UI、前后端、上架到后续运维都是一条龙交付的。我们偏向接长期演进型项目，会在合作前把账号、支付、风控、上架这些重点环节都给客户讲明白，让客户对周期和预算有合理预期。如果你目前只是有想法、还没确定首期范围，我们也可以先帮你做一版需求拆解，看看哪些功能放一期、哪些放二期更合理。

Question 61

订单流程系统如何设计内勤审核-到款确认-发货闭环？

Accepted Answer

把订单从"客户提交"到"审核、到款、发货"做成一台状态机，每一次状态流转都明确"谁能操作、要填什么、要上传什么附件、跳到下一个什么状态"。这样的设计能让业务有迹可循、对账有据可查，也容易在后续把异常流程（退款、改单、取消）加进来。

具体的状态设计可以这样：

待提交 → 待审核 → 待付款 → 已付款待发货 → 已发货 → 已收货 → 已完成
              ↓         ↓               ↓           ↓
            驳回      取消             部分发货    售后

每个状态对应一组明确的规则：

待审核 → 待付款：内勤检查客户资质、价格、库存，必填"审核备注"，可附上历史信用记录；如果是大单还要走主管二次确认
待付款 → 已付款待发货：到款确认必须上传"到款凭证"（银行回单截图或发票号），财务在后台核对账户流水，确认后状态自动跳转
已付款待发货 → 已发货：仓库填运单号、承运商，附"出库照片"（防止后期争议）；运单号会触发自动物流追踪
已发货 → 已收货：物流签收回调或客户手动确认，触发对账状态进入"待开票"

权限设计的关键点

业务员只能看自己负责的订单
内勤可以审核、改价（带审批）、催款
财务可以确认到款、开票、退款
仓库只能看到付款的订单
主管和老板看汇总

每个角色看到的"按钮"和"字段"是不同的：业务员看不到毛利，仓库看不到客户付款详情。这种细粒度权限要在系统里通过角色配置实现，而不是为每个公司单独写代码。

几个容易踩的坑

状态机要可追溯：每次状态变化都要记日志（谁、什么时间、从什么状态到什么状态、备注），否则后期扯皮没证据
回退要谨慎：允许哪些状态可以回退、回退要谁审批，这个规则一定要先定好
异常流程：退款、改单、取消怎么走，不要等出问题再想
金额对账：每个订单从下单到回款的金额变动（折扣、补差、退款）要能追溯

这套设计在我们做过的分销、B2B、家装运营类项目里都验证过，是订单管理系统的基础骨架。

Question 62

多家公司共用一套系统，但不同角色只能看自己的数据，应该怎么设计？

Accepted Answer

推荐"一套系统 + 多租户隔离 + 角色权限"的组合，而不是为每家公司各做一套。系统层面通过组织 ID（公司/分公司/部门）做数据范围隔离，角色权限再控制到模块、按钮、字段级，绝大多数场景都能覆盖。除非客户特别敏感、要求物理库分开，否则统一部署在运维和迭代上更划算。

具体设计上分两条线：

数据隔离

每张业务表都带 org_id（或者 tenant_id），所有查询自动加上这个过滤条件。系统从用户登录的那一刻起就锁定他能看见的组织范围：

普通员工只能看自己所属公司的数据
区域经理可以看名下的几个分公司
集团管理员可以跨公司，但通常会做"只读"或"汇总"模式

为防止越权，建议在框架层（比如 MyBatis 拦截器、ORM 中间件）统一注入数据范围条件，而不是依赖每个开发自己在 SQL 里加 where，否则总会有漏的地方。

权限控制

角色权限要做到三层：

模块/菜单级：决定能不能看到这个功能入口
操作级：在能看到的模块里，决定能不能新增、修改、删除、导出
字段级（可选）：敏感字段（比如客户手机号、毛利）只对特定角色显示

集团类客户的常见诉求是"我的人可以看你们公司的部分数据"，比如审计、合规、风控。这种跨公司读权限要单独建表维护，不要靠角色硬塞，否则维护人员会很痛苦。

我们在智慧园区管理系统这类项目里就遇到过几十家子公司共用一套后台的情况，做法基本就是上面这一套。客户最关心的"我看不到别人家的数据、领导能看到全集"是能做到的，前提是组织结构和角色矩阵在前期就梳理清楚。

Question 63

多省份多模板报表怎么自动生成与维护？

Accepted Answer

推荐"统一数据底表 + 模板引擎 + 字段映射"的三层方案。先把原始业务数据规范成一张通用宽表，再为每个省份/版本建立独立模板，由模板引擎按字段映射生成最终 Excel 或 PDF。这种方式既能避免改一个省的模板影响全局，又方便追溯历史版本。

具体落地我们一般这么拆：

数据汇总层：把分散在订单、客户、台账、第三方接口里的字段，按业务主题归到一张"统一总表"上。每个字段都有标准命名、单位、口径说明。这是后续所有报表的唯一数据源。
模板层：用 Excel 模板（带占位符）或 JimuReport、UReport 这类报表引擎管理。每个省份对应一个或多个模板，模板里只关心"哪个单元格填哪个字段"，不掺杂业务逻辑。
映射与生成层：模板和总表之间用一份"字段映射"配置连接。生成报表时引擎读模板、查总表、按映射填值、输出文件。
版本管理：每个模板都要有版本号，本月用的是 v3、上月是 v2 都要能查到。监管要求一旦变化，新增模板而不是覆盖老模板，老数据继续按原模板生成。

几个容易踩的坑也提前说一下：

口径不一致：同一个"销售额"在不同省份的定义可能不一样（是否含税、是否含返点）。这种差异要在总表里就拆成多个字段，不要在模板里临时算。
校验缺失：模板填值后要有一道自动校验——必填项是否齐全、合计是否对得上、关键字段是否在阈值内。出问题之前先告警，比交上去被打回来强。
谁来维护模板：新省份、新版本来了要能让业务/运营自己上传模板，而不是每次都改代码。模板配置后台的友好程度直接决定了维护成本。

整个方案首期一般集中精力把通用底表和一两个标杆省份跑通，后续每加一个省主要是模板配置工作，开发改动很少。

Question 64

后面我可能会想到很多新的功能，我可以加上去吗？

Accepted Answer

可以，而且我们也鼓励这种"边用边想"的过程。系统上线之后客户对自己业务的理解会越来越细，新增需求是必然的。我们一般会用"小迭代"的方式接住这些想法：把它们排进迭代池里，按业务优先级和实现成本分批上线，而不是一次性堆到下个版本里。

实际操作上，我们和客户的协作节奏大致是这样：

客户内部指定一位产品对接人，把日常想到的需求先收敛、写清楚（背景、要解决什么问题、谁会用到、判断是否成功的标准）。
滚水科技这边的 PM 每周或每两周和对接人过一次需求池，把新需求分成"立即做 / 下个迭代做 / 暂缓 / 不做"。
每个迭代周期固定一个上线窗口，避免高频上线带来的回归风险。

我们也会比较直接地告诉客户哪些需求建议先放一放：比如和首期目标关联度不大的、只有极少数用户会用的、需要重构关键模块的，这些通常会被建议挪到下一阶段，或者等数据量上来后再评估。

费用方面，比较小的调整（一两天能完成的）很多时候会包含在维护服务里，不另外计费；功能性新增按工作量评估，事先报价、确认后再开发。这种透明的方式避免了"加点东西又要谈一次合同"的反复，也让客户在加新功能时有比较清晰的预期。

举一个比较常见的情况：客户上线运营平台半年后想加积分商城、想做会员等级、想接企微社群。这三个一起做工作量太大，我们一般会建议先做会员等级（影响面最小、改动最少），跑两个月再做积分体系，再做企微社群。这种节奏既保护现有用户体验，也让新功能上线后有时间被真实使用、被验证。

提交需求，让我们为你的业务

常见问题