前阵子一个做医疗信息化的朋友找我说他们医院想搞AI开发让医生用上智能问答但病案、影像报告和患者主诉这些数据一条都不能出内网。他原话是我不要Demo我要一个能落地的方案。这两年被问过太多次类似的问题答案已经越来越清晰企业级AI开发不是比谁的模型参数大而是看能不能把数据和模型都锁在自己家里同时让业务同学也能参与开发。把企业数据留在内网把AI开发门槛降到最低——这两句话放在一起才是大多数传统企业真正需要的AI落地路径。这篇文章就来聊聊我在这类项目里沉淀下来的方法包括一套四阶十二步的落地框架、提示词驱动开发的实操模板、老旧内网环境的避坑经验以及几种高频场景的选型参考。适合正在做企业内部AI应用、准备建设私有化智能体或者刚接触企业AI开发的团队阅读。1. 企业AI开发卡在内网到底卡在了哪里很多人以为企业不用云端大模型是因为“网络不行”但在实际项目中大部分情况是“不敢”和“不能”。这两个字背后是合规、物理隔离和工程能力三重问题叠在一起。1.1 不是不想用AI是数据出不去AI应用落地最依赖的原料就是数据。企业内部的知识库、项目文档、客户信息、财务报表这些数据既是AI最有价值的学习材料也是合规要求最严格的敏感资产。过去两年的监管环境变化很明显个人信息保护、数据分类分级、行业审计这些要求压下来直接把“把数据传到第三方大模型平台”这条路堵死了。还有一类单位是物理隔离。很多政企、医疗、军工配套单位内网和外网之间根本不通想调云端API都调不了。项目数据只能在内网流转外网模型能力再强跟你也没关系。更隐蔽的一点是商业秘密问题。即使数据可以出网员工在prompt里问的内容本身就是高价值情报——“我们今年Q3的客诉集中在哪个产品线”“这个投标方案的弱点是什么”这些话一旦进了外部API的日志就脱离了企业控制。所以越是大企业越会把“数据不出内网”当成硬性红线。1.2 内网做AI开发难点不在模型在工程配套开源模型不缺缺的是能把它在企业里跑起来的那一整套工程能力。模型文件下载下来只是第一步后面跟着推理服务、向量数据库、API接口、前端界面、Agent编排、账号权限全是活。内网的开发环境往往没有外网。pip装不了包npm拉不了依赖docker pull直接超时。我在一个客户现场遇到过最典型的场景一台Windows Server 2016的服务器8G内存无GPU要跑AI应用。这种环境连新版Docker Desktop都装不上更别提什么高性能推理了。还有团队协作问题。AI项目的真正使用者往往是业务部门他们不懂Python、不懂部署但他们手里有需求、有文档、有业务判断力。工程团队懂技术但不懂业务两边语言不通项目就容易卡在需求理解上。这也是我后来一直强调提示词驱动和可视化编排的原因——必须把业务同学能参与的部分尽量往前抬。1.3 先给一条完整落地路径内网AI开发的整体链路其实不复杂复杂的是每一环都有细节。大致是这样模型选型 → 私有化推理部署 → 知识库构建 → 应用开发问答/Agent/代码助手 → 上线治理。每一环都对应不同的技术选型和坑。下面我用一套“四阶十二步”的方法来拆解这是我在多个项目里反复用、不断修正后沉淀下来的框架。2. 四阶十二步一套适合内网环境的AI应用落地框架这套四阶十二步不是我拍脑袋想的而是从几次“什么都想干结果什么都干不成”的项目里反推出来的。核心思路很简单每一步都有明确产出做完一步再进下一步不要跳。2.1 阶段一底座准备——先把“能跑模型”这件事搞定第一步是盘点硬件。先搞清楚你手里有什么有没有GPU显存多大内存多少磁盘剩余空间够不够。模型参数量和显存的对应关系大致可以参考7B模型做4-bit量化大概需要6到8G显存14B大概要12到16G32B跑到比较舒服的状态需要24G以上。没有GPU也不是不能做纯CPU跑7B模型可以出结果但响应会很慢适合内部试用不适合生产并发。第二步是选模型。中文场景下我优先推荐看开源社区的几大楼系通义千问Qwen系列、DeepSeek系列、ChatGLM系列。如果场景偏代码生成Qwen的Coder系列表现很能打如果偏通用对话和文档总结Qwen和DeepSeek的基础模型都够用。千万别一上来就追求最贵的最大模型内网项目先跑通再换强模型这个顺序不能反。第三步是部署推理服务。单机试玩用Ollama一条命令就能把模型跑起来API也简单。生产环境并发高的话用vLLM吞吐量明显好但配置复杂一些。内网环境没有外网模型文件可以用移动硬盘拷贝进去Docker镜像就在有外网的机器上docker save再到内网docker load。2.2 阶段二知识入库——让模型能回答“你公司的业务”第四步是文档清洗。企业里的文档质量参差不齐PDF有扫描件Word里有页眉页脚PPT里的文字可能要单独抽取。先建一个统一的知识库目录把所有源文档转为纯文本去掉与内容无关的重复信息。不要小看这一步脏数据进向量库后面检索出来的结果一定让你头疼。第五步是切分与向量化。文档切分有讲究按固定字数硬切容易把一个完整知识点切碎我一般会结合标题层级和段落结构来切每个片段控制在500到800字左右。切完用Embedding模型转成向量中文场景推荐bge系列效果稳定。向量数据库可以用Milvus也可以用pgvector甚至可以先用Elasticsearch顶上关键看团队熟悉哪个。第六步是检索链路调优。这一步很多人忽略。默认的top-k、相似度阈值不一定适合你的业务文档需要拿真实问题反复测。常见做法是“关键词检索向量检索”混合召回把两路结果融合排序对专业术语和模糊语义的效果都更好。这一步要花时间它直接决定RAG应用的回答质量。2.3 阶段三应用开发——用提示词和低代码平台组装业务第七步是需求拆解。接到业务需求后先别急着写代码把需求转换成“角色任务输入输出”的结构。比如“你是一个合同审核助手用户输入合同文本你输出风险条款清单和修改建议”这就是一个可以被AI理解和执行的原子需求。第八步是提示词工程。系统提示词要写得具体包含角色、目标、约束、输出格式。再给两三个少样本示例让模型照着示例的格式输出。这一步不需要编程能力业务同学完全可以参与这是降低AI开发门槛非常关键的一个环节。第九步是应用编排。进入开发阶段推荐用Dify、FastGPT这类支持私有化部署的开源平台把模型、知识库、工作流用可视化的方式串起来。这样做的好处是后续改流程不用改代码业务同学也能上手。如果企业系统是Java或Python技术栈也可以通过这些平台暴露出来的API对接业务系统。2.4 阶段四上线与治理——内网应用同样要讲安全第十步是访问控制。内网AI应用不能做一个“裸奔”的独立系统要对接企业的统一身份认证比如LDAP或OAuth按角色控制谁能用哪个Agent、谁能看哪些知识库。医疗、金融场景尤其要注意患者信息和客户数据不能对所有员工开放。第十一步是日志与审计。所有AI问答请求、生成内容、用户反馈都要留痕。建议加上敏感词过滤和越权检测发现异常要能追溯到人。业务体感上这是“多加了一层保险”但对合规审计来说这是必需品。第十二步是评估与迭代。上线不等于结束。要把业务使用中的badcase收集起来定期分析是知识库缺内容、切分不合理、还是提示词有歧义然后针对性调整。AI应用是典型的“跑起来容易做好需要持续投入”这个预期要提前给业务方讲清楚。2.5 四阶十二步全景表阶段步骤核心任务主要产出底座准备1-3硬件盘点、模型选型、推理部署可调用的大模型API知识入库4-6文档清洗、切分向量化、检索调优可检索的企业知识库应用开发7-9需求拆解、提示词工程、应用编排可演示的AI应用上线治理10-12访问控制、日志审计、评估迭代可长期运营的AI服务3. 从一份需求文档到能跑的AI应用提示词驱动开发实操四阶十二步讲的是框架这一章讲的是框架里“应用开发”这一环具体怎么下手。我用的核心方法就一招提示词驱动开发。这不是什么新概念但在内网AI项目里极其好用因为业务同学手里最不缺的就是需求文档和会议纪要。3.1 为什么需求文档是低门槛开发的起点很多人觉得让AI开发应用必须懂编程其实不是。我见过不少内部项目是这么跑起来的业务部门有明确需求写了一份需求分析文档工程团队把文档喂给大模型让大模型一步步输出技术方案、数据表设计、接口定义、代码实现。AI的能力边界在扩大“把需求文档变成可执行任务”这件事现在的开源大模型已经做得相当好了。关键是要用对方式。不是一句“帮我开发一个系统”就能成的那样生成的代码基本没法用。正确做法是把任务拆细让AI逐步输出每个步骤都检查、纠偏。这也是为什么我强调提示词模板要结构清晰——模板本身就是给AI看的“需求说明书”。3.2 直接可以抄的提示词模板下面这个模板是我在内部项目里常用的它把AI定位成“架构师开发工程师”并要求它分阶段输出避免一次性生成大量不可控的代码。你是一位有10年经验的企业级AI应用架构师和全栈开发工程师。 我在一个内网环境中开发一个企业知识问答应用技术栈不限但服务必须私有化部署。 请严格按照以下步骤输出每完成一步后等待我的确认再进入下一步 第一步根据需求输出技术方案包括架构图说明、关键组件选型及理由。 第二步输出数据模型设计包括核心表结构和字段说明。 第三步输出后端API接口设计包括接口路径、入参、出参。 第四步输出关键代码实现尽量给出可直接运行的代码块。 第五步输出测试用例和上线检查清单。 我的需求是 [在这里粘贴你的需求分析文档]用这个模板有几个注意点一一定要让它“每完成一步后等待确认”否则它会一口气把所有内容倒出来根本看不过来二需求文档贴进去之前先删掉敏感数据和内部代号三AI生成的代码不要直接上生产至少要有工程经验的人过一遍。3.3 一个内部知识问答Agent从0到1的拆解前几天我帮朋友跑通了一个最小版本的企业制度问答Agent场景很简单员工问“年假怎么休”“报销流程是什么”Agent从制度文档里检索答案并给出来源。前后只用了几天时间没有写一行业务代码全靠开源平台配置。具体流程先收集公司的制度类文档包括员工手册、差旅管理制度、报销流程说明转成文本后做了清洗和切分再用Embedding模型向量化最后在Dify里挂了私有化部署的Qwen模型。前端就用了Dify自带的页面配上公司logo就发给业务部门试用了。这个过程中真正花时间的不是模型而是制度文档的整理和问题测试。文档里同样的报销规定在三个文件里写过三遍措辞还不一致如果不先做去重和归一化Agent就经常抽风。这件事给我提了个醒AI开发门槛降低之后业务知识整理反而成了核心工作。3.4 降低门槛的现实建议顺着这个案例多说几句。想真正把AI开发门槛降下来我建议团队做三件事。第一别让业务同学写代码让他们“写文档点配置”。把常用的Agent模板做成可视化配置项业务同学只需要选择数据源、填写提示词、设置回答风格剩下的交给平台。第二平台化的价值要自己搭一遍才知道。用Dify、FastGPT这类开源平台先跑通一个小项目你才会理解为什么流程编排比堆功能重要。那些动不动就规划几十个Agent的项目十有八九会烂尾。从一两个高价值场景开始跑出正向反馈再逐步扩展。第三重视反馈闭环。AI应用要在真实使用中被批评才能真正变好。上线后一定要有badcase收集入口让用户能一键反馈“回答不对”然后运营人员定期处理。没有这个闭环应用就会停留在“能演示但不敢用”的状态。4. 内网部署避坑老服务器、离线依赖与隔离权限框架和方法都讲完了这一章专门讲“现场翻车”的环节。内网AI开发和互联网环境最大的区别在于你没有试错的自由。每踩一个坑恢复成本都可能要按天算。4.1 Windows Server 2016老环境装Docker先调整预期热搜词里有一条“医院内网服务器Windows Server 2016标准版安装docker”看到这个我很有共鸣。不少行业客户的核心服务器就是Windows Server 2016系统旧、权限卡得死、网上最新的安装教程根本不适用。我的建议是遇到这种环境先别硬刚Docker。新版Docker Desktop对系统版本和虚拟化支持要求很高Server 2016上装最新版本很容易失败。更稳的路线有三条第一装一台Linux虚拟机Docker跑在虚拟机里第二如果虚拟化被禁就用原生Python进程部署推理服务不用容器第三用Windows上能跑的精简版容器引擎但前提是你对踩坑有充分心理准备。实测下来很多内网项目的瓶颈根本不是容器化而是硬件资源。小模型用Ollama直接跑进程丢一个systemd服务或计划任务守护完全够用。容器化是锦上添花不是落地的前提。4.2 离线环境下的依赖与镜像搬运内网开发最耗时间的一个环节是“搬运”。pip装不了包npm拉不了依赖模型权重下载到一半断网这些都是日常工作。离线安装Python依赖我建议在有外网的机器上执行pip download把需要的包和依赖全部下载到本地目录然后连同安装包一起拷进内网。内网机器上安装时使用--no-index --find-links指向本地目录可以避免它尝试访问外网。Docker镜像更简单有外网机器上docker save -o打成tar包内网里docker load -i恢复。模型权重也是一样拷文件比在线下载可靠得多。这里有个教训所有搬运进内网的文件一定要记录版本号和校验值。模型文件动辄几个G传输过程中损坏了很难发现跑起来报错都不知道是哪一步的问题。我习惯在搬运前用sha256sum生成一个校验清单进内网后逐一核对看起来很麻烦但能省掉后面两倍的排查时间。4.3 内网共享、性能和GPU分配上的特殊坑内网“共享文件特别卡”这个问题也被问过很多次。排查下来通常不是带宽问题而是三个原因叠加杀毒软件实时扫描每一个文件请求小文件太多导致握手开销放大以及SMB协议配置没有针对内网环境调优。如果你的知识库文档就放在共享盘上建议让AI应用先同步到本地或对象存储再读取别让模型推理链路频繁访问共享文件。GPU资源在内网环境里通常是稀缺的。几个部门共用一个GPU服务器的时候一定要把推理服务统一收敛加一个队列或配额机制避免某个团队的一次批量任务把显存打满导致所有在线应用一起卡死。我在项目里常用的方案是在线推理用vLLM跑一个带并发控制的API服务离线的批量任务放到低优先级队列。模型加载本身也是性能杀手。一个7B模型冷启动加载到显存可能要几十秒如果服务频繁重启用户体验会很差。建议配置模型的常驻和预加载同时给推理服务做健康检查确保物理机重启后模型能自动恢复。4.4 安全边界数据留在内网不等于裸奔数据留在内网只是第一步内网服务的安全边界同样要守住。永远不要为了让外部合作伙伴访问方便就把内网AI服务暴露到公网。这类操作会直接突破企业安全策略属于绝对不能在项目里做的事情。对内要遵守账号权限最小化原则。AI应用涉及的知识库往往包括敏感内容不能对全员无差别开放。对接企业统一身份体系按部门、角色、密级做细粒度访问控制。AI问答产生的日志要留够留存周期便于出现数据泄露时回溯。还有一层容易被忽略AI生成内容本身也要做合规把控。敏感词过滤、涉密信息检测、人工复核闭环这些要在应用设计时就留好接口。医疗、金融、政务类场景AI的回答建议明确标注“仅供参考”关键决策必须有人工审核环节。内网AI不是法外之地反而是合规要求最严格的试验场。5. 内网AI开发的三种高频落地场景与选型参考讲完方法和坑最后给几个可以直接对号入座的场景参考。这些场景都有一个共通点能很快展现出业务价值而且数据敏感度天然适合留在内网。5.1 企业私有知识库问答RAG这是内网AI落地最经典、最容易出成绩的场景。把规章制度、产品文档、客户案例、历史方案整理成知识库员工通过对话式问答获取信息回答附上出处。架构上就是“大模型向量库检索增强”。入门工具组合Ollama或vLLM跑模型bge做EmbeddingMilvus或pgvector存向量Dify或FastGPT做应用编排。这套组合完全可以在内网离线运行数据链路清晰扩展性也好。最难的地方不是技术而是知识库的持续维护一定要安排专人负责文档更新和质量审核。5.2 内部代码助手与研发提效很多研发团队想用AI辅助写代码但又不敢把代码库发给外部服务。内网部署一个私有代码助手是完全可行的路径把代码仓库的关键模块、技术规范、历史提交记录整理后向量化让模型基于项目上下文生成代码。这对需求分析、代码审查、自动化测试都能提效。要注意的是代码类场景对模型的代码能力要求很高建议选代码增强版模型比如专门优化的Coder系列。另外生成代码的安全审查不能省AI补全的代码可能有依赖漏洞或业务逻辑错误必须走原有代码评审流程不能因为“AI生成”就降低标准。5.3 文档草拟与数据报表Agent最后一个高频场景是文档和报表生成。企业里有大量周报、会议纪要、检查报告、数据说明需要写这些事情重复度高、格式固定非常适合用Agent来辅助。固定一个报告模板让AI根据数据源自动填充内容生成初稿后人再修改确认效率能提升一大截。这类场景的关键不是大模型有多聪明而是业务模板和数据链路要标准化。把数据仓库或Excel数据源接入Agent定义好字段映射和输出格式AI负责组织和润色文字。上线后建议保留人工复核步骤数据准确性问题宁可多一道检查也不要让错误报表直接发出去。场景核心输入输出关键组件推荐入门工具知识库问答制度、文档、FAQ带来源的回答向量库RAGDifyOllamaMilvus代码助手私有代码仓库补全/解释/审查代码模型仓库索引Qwen-CodervLLM报表Agent业务数据/模板草拟报告/报表说明数据对接模板解析FastGPT自定义API我个人在实际落地中的体会是真正卡住项目的往往不是模型效果而是数据准备和权限协同这两件“不性感”的活。模型选错了可以换数据不干净再强的模型也白搭。所以如果你想在企业里推动这件事我建议先从一两个业务价值明确、数据质量还不错的场景切入用四阶十二步里的最小闭环跑通拿到业务部门真实反馈后再横向扩展。内网AI开发的门槛没有想象中那么高但需要你有耐心去处理那些很琐碎却很要命的工程细节。
前阵子一个做医疗信息化的朋友找我说他们医院想搞AI开发让医生用上智能问答但病案、影像报告和患者主诉这些数据一条都不能出内网。他原话是我不要Demo我要一个能落地的方案。这两年被问过太多次类似的问题答案已经越来越清晰企业级AI开发不是比谁的模型参数大而是看能不能把数据和模型都锁在自己家里同时让业务同学也能参与开发。把企业数据留在内网把AI开发门槛降到最低——这两句话放在一起才是大多数传统企业真正需要的AI落地路径。这篇文章就来聊聊我在这类项目里沉淀下来的方法包括一套四阶十二步的落地框架、提示词驱动开发的实操模板、老旧内网环境的避坑经验以及几种高频场景的选型参考。适合正在做企业内部AI应用、准备建设私有化智能体或者刚接触企业AI开发的团队阅读。1. 企业AI开发卡在内网到底卡在了哪里很多人以为企业不用云端大模型是因为“网络不行”但在实际项目中大部分情况是“不敢”和“不能”。这两个字背后是合规、物理隔离和工程能力三重问题叠在一起。1.1 不是不想用AI是数据出不去AI应用落地最依赖的原料就是数据。企业内部的知识库、项目文档、客户信息、财务报表这些数据既是AI最有价值的学习材料也是合规要求最严格的敏感资产。过去两年的监管环境变化很明显个人信息保护、数据分类分级、行业审计这些要求压下来直接把“把数据传到第三方大模型平台”这条路堵死了。还有一类单位是物理隔离。很多政企、医疗、军工配套单位内网和外网之间根本不通想调云端API都调不了。项目数据只能在内网流转外网模型能力再强跟你也没关系。更隐蔽的一点是商业秘密问题。即使数据可以出网员工在prompt里问的内容本身就是高价值情报——“我们今年Q3的客诉集中在哪个产品线”“这个投标方案的弱点是什么”这些话一旦进了外部API的日志就脱离了企业控制。所以越是大企业越会把“数据不出内网”当成硬性红线。1.2 内网做AI开发难点不在模型在工程配套开源模型不缺缺的是能把它在企业里跑起来的那一整套工程能力。模型文件下载下来只是第一步后面跟着推理服务、向量数据库、API接口、前端界面、Agent编排、账号权限全是活。内网的开发环境往往没有外网。pip装不了包npm拉不了依赖docker pull直接超时。我在一个客户现场遇到过最典型的场景一台Windows Server 2016的服务器8G内存无GPU要跑AI应用。这种环境连新版Docker Desktop都装不上更别提什么高性能推理了。还有团队协作问题。AI项目的真正使用者往往是业务部门他们不懂Python、不懂部署但他们手里有需求、有文档、有业务判断力。工程团队懂技术但不懂业务两边语言不通项目就容易卡在需求理解上。这也是我后来一直强调提示词驱动和可视化编排的原因——必须把业务同学能参与的部分尽量往前抬。1.3 先给一条完整落地路径内网AI开发的整体链路其实不复杂复杂的是每一环都有细节。大致是这样模型选型 → 私有化推理部署 → 知识库构建 → 应用开发问答/Agent/代码助手 → 上线治理。每一环都对应不同的技术选型和坑。下面我用一套“四阶十二步”的方法来拆解这是我在多个项目里反复用、不断修正后沉淀下来的框架。2. 四阶十二步一套适合内网环境的AI应用落地框架这套四阶十二步不是我拍脑袋想的而是从几次“什么都想干结果什么都干不成”的项目里反推出来的。核心思路很简单每一步都有明确产出做完一步再进下一步不要跳。2.1 阶段一底座准备——先把“能跑模型”这件事搞定第一步是盘点硬件。先搞清楚你手里有什么有没有GPU显存多大内存多少磁盘剩余空间够不够。模型参数量和显存的对应关系大致可以参考7B模型做4-bit量化大概需要6到8G显存14B大概要12到16G32B跑到比较舒服的状态需要24G以上。没有GPU也不是不能做纯CPU跑7B模型可以出结果但响应会很慢适合内部试用不适合生产并发。第二步是选模型。中文场景下我优先推荐看开源社区的几大楼系通义千问Qwen系列、DeepSeek系列、ChatGLM系列。如果场景偏代码生成Qwen的Coder系列表现很能打如果偏通用对话和文档总结Qwen和DeepSeek的基础模型都够用。千万别一上来就追求最贵的最大模型内网项目先跑通再换强模型这个顺序不能反。第三步是部署推理服务。单机试玩用Ollama一条命令就能把模型跑起来API也简单。生产环境并发高的话用vLLM吞吐量明显好但配置复杂一些。内网环境没有外网模型文件可以用移动硬盘拷贝进去Docker镜像就在有外网的机器上docker save再到内网docker load。2.2 阶段二知识入库——让模型能回答“你公司的业务”第四步是文档清洗。企业里的文档质量参差不齐PDF有扫描件Word里有页眉页脚PPT里的文字可能要单独抽取。先建一个统一的知识库目录把所有源文档转为纯文本去掉与内容无关的重复信息。不要小看这一步脏数据进向量库后面检索出来的结果一定让你头疼。第五步是切分与向量化。文档切分有讲究按固定字数硬切容易把一个完整知识点切碎我一般会结合标题层级和段落结构来切每个片段控制在500到800字左右。切完用Embedding模型转成向量中文场景推荐bge系列效果稳定。向量数据库可以用Milvus也可以用pgvector甚至可以先用Elasticsearch顶上关键看团队熟悉哪个。第六步是检索链路调优。这一步很多人忽略。默认的top-k、相似度阈值不一定适合你的业务文档需要拿真实问题反复测。常见做法是“关键词检索向量检索”混合召回把两路结果融合排序对专业术语和模糊语义的效果都更好。这一步要花时间它直接决定RAG应用的回答质量。2.3 阶段三应用开发——用提示词和低代码平台组装业务第七步是需求拆解。接到业务需求后先别急着写代码把需求转换成“角色任务输入输出”的结构。比如“你是一个合同审核助手用户输入合同文本你输出风险条款清单和修改建议”这就是一个可以被AI理解和执行的原子需求。第八步是提示词工程。系统提示词要写得具体包含角色、目标、约束、输出格式。再给两三个少样本示例让模型照着示例的格式输出。这一步不需要编程能力业务同学完全可以参与这是降低AI开发门槛非常关键的一个环节。第九步是应用编排。进入开发阶段推荐用Dify、FastGPT这类支持私有化部署的开源平台把模型、知识库、工作流用可视化的方式串起来。这样做的好处是后续改流程不用改代码业务同学也能上手。如果企业系统是Java或Python技术栈也可以通过这些平台暴露出来的API对接业务系统。2.4 阶段四上线与治理——内网应用同样要讲安全第十步是访问控制。内网AI应用不能做一个“裸奔”的独立系统要对接企业的统一身份认证比如LDAP或OAuth按角色控制谁能用哪个Agent、谁能看哪些知识库。医疗、金融场景尤其要注意患者信息和客户数据不能对所有员工开放。第十一步是日志与审计。所有AI问答请求、生成内容、用户反馈都要留痕。建议加上敏感词过滤和越权检测发现异常要能追溯到人。业务体感上这是“多加了一层保险”但对合规审计来说这是必需品。第十二步是评估与迭代。上线不等于结束。要把业务使用中的badcase收集起来定期分析是知识库缺内容、切分不合理、还是提示词有歧义然后针对性调整。AI应用是典型的“跑起来容易做好需要持续投入”这个预期要提前给业务方讲清楚。2.5 四阶十二步全景表阶段步骤核心任务主要产出底座准备1-3硬件盘点、模型选型、推理部署可调用的大模型API知识入库4-6文档清洗、切分向量化、检索调优可检索的企业知识库应用开发7-9需求拆解、提示词工程、应用编排可演示的AI应用上线治理10-12访问控制、日志审计、评估迭代可长期运营的AI服务3. 从一份需求文档到能跑的AI应用提示词驱动开发实操四阶十二步讲的是框架这一章讲的是框架里“应用开发”这一环具体怎么下手。我用的核心方法就一招提示词驱动开发。这不是什么新概念但在内网AI项目里极其好用因为业务同学手里最不缺的就是需求文档和会议纪要。3.1 为什么需求文档是低门槛开发的起点很多人觉得让AI开发应用必须懂编程其实不是。我见过不少内部项目是这么跑起来的业务部门有明确需求写了一份需求分析文档工程团队把文档喂给大模型让大模型一步步输出技术方案、数据表设计、接口定义、代码实现。AI的能力边界在扩大“把需求文档变成可执行任务”这件事现在的开源大模型已经做得相当好了。关键是要用对方式。不是一句“帮我开发一个系统”就能成的那样生成的代码基本没法用。正确做法是把任务拆细让AI逐步输出每个步骤都检查、纠偏。这也是为什么我强调提示词模板要结构清晰——模板本身就是给AI看的“需求说明书”。3.2 直接可以抄的提示词模板下面这个模板是我在内部项目里常用的它把AI定位成“架构师开发工程师”并要求它分阶段输出避免一次性生成大量不可控的代码。你是一位有10年经验的企业级AI应用架构师和全栈开发工程师。 我在一个内网环境中开发一个企业知识问答应用技术栈不限但服务必须私有化部署。 请严格按照以下步骤输出每完成一步后等待我的确认再进入下一步 第一步根据需求输出技术方案包括架构图说明、关键组件选型及理由。 第二步输出数据模型设计包括核心表结构和字段说明。 第三步输出后端API接口设计包括接口路径、入参、出参。 第四步输出关键代码实现尽量给出可直接运行的代码块。 第五步输出测试用例和上线检查清单。 我的需求是 [在这里粘贴你的需求分析文档]用这个模板有几个注意点一一定要让它“每完成一步后等待确认”否则它会一口气把所有内容倒出来根本看不过来二需求文档贴进去之前先删掉敏感数据和内部代号三AI生成的代码不要直接上生产至少要有工程经验的人过一遍。3.3 一个内部知识问答Agent从0到1的拆解前几天我帮朋友跑通了一个最小版本的企业制度问答Agent场景很简单员工问“年假怎么休”“报销流程是什么”Agent从制度文档里检索答案并给出来源。前后只用了几天时间没有写一行业务代码全靠开源平台配置。具体流程先收集公司的制度类文档包括员工手册、差旅管理制度、报销流程说明转成文本后做了清洗和切分再用Embedding模型向量化最后在Dify里挂了私有化部署的Qwen模型。前端就用了Dify自带的页面配上公司logo就发给业务部门试用了。这个过程中真正花时间的不是模型而是制度文档的整理和问题测试。文档里同样的报销规定在三个文件里写过三遍措辞还不一致如果不先做去重和归一化Agent就经常抽风。这件事给我提了个醒AI开发门槛降低之后业务知识整理反而成了核心工作。3.4 降低门槛的现实建议顺着这个案例多说几句。想真正把AI开发门槛降下来我建议团队做三件事。第一别让业务同学写代码让他们“写文档点配置”。把常用的Agent模板做成可视化配置项业务同学只需要选择数据源、填写提示词、设置回答风格剩下的交给平台。第二平台化的价值要自己搭一遍才知道。用Dify、FastGPT这类开源平台先跑通一个小项目你才会理解为什么流程编排比堆功能重要。那些动不动就规划几十个Agent的项目十有八九会烂尾。从一两个高价值场景开始跑出正向反馈再逐步扩展。第三重视反馈闭环。AI应用要在真实使用中被批评才能真正变好。上线后一定要有badcase收集入口让用户能一键反馈“回答不对”然后运营人员定期处理。没有这个闭环应用就会停留在“能演示但不敢用”的状态。4. 内网部署避坑老服务器、离线依赖与隔离权限框架和方法都讲完了这一章专门讲“现场翻车”的环节。内网AI开发和互联网环境最大的区别在于你没有试错的自由。每踩一个坑恢复成本都可能要按天算。4.1 Windows Server 2016老环境装Docker先调整预期热搜词里有一条“医院内网服务器Windows Server 2016标准版安装docker”看到这个我很有共鸣。不少行业客户的核心服务器就是Windows Server 2016系统旧、权限卡得死、网上最新的安装教程根本不适用。我的建议是遇到这种环境先别硬刚Docker。新版Docker Desktop对系统版本和虚拟化支持要求很高Server 2016上装最新版本很容易失败。更稳的路线有三条第一装一台Linux虚拟机Docker跑在虚拟机里第二如果虚拟化被禁就用原生Python进程部署推理服务不用容器第三用Windows上能跑的精简版容器引擎但前提是你对踩坑有充分心理准备。实测下来很多内网项目的瓶颈根本不是容器化而是硬件资源。小模型用Ollama直接跑进程丢一个systemd服务或计划任务守护完全够用。容器化是锦上添花不是落地的前提。4.2 离线环境下的依赖与镜像搬运内网开发最耗时间的一个环节是“搬运”。pip装不了包npm拉不了依赖模型权重下载到一半断网这些都是日常工作。离线安装Python依赖我建议在有外网的机器上执行pip download把需要的包和依赖全部下载到本地目录然后连同安装包一起拷进内网。内网机器上安装时使用--no-index --find-links指向本地目录可以避免它尝试访问外网。Docker镜像更简单有外网机器上docker save -o打成tar包内网里docker load -i恢复。模型权重也是一样拷文件比在线下载可靠得多。这里有个教训所有搬运进内网的文件一定要记录版本号和校验值。模型文件动辄几个G传输过程中损坏了很难发现跑起来报错都不知道是哪一步的问题。我习惯在搬运前用sha256sum生成一个校验清单进内网后逐一核对看起来很麻烦但能省掉后面两倍的排查时间。4.3 内网共享、性能和GPU分配上的特殊坑内网“共享文件特别卡”这个问题也被问过很多次。排查下来通常不是带宽问题而是三个原因叠加杀毒软件实时扫描每一个文件请求小文件太多导致握手开销放大以及SMB协议配置没有针对内网环境调优。如果你的知识库文档就放在共享盘上建议让AI应用先同步到本地或对象存储再读取别让模型推理链路频繁访问共享文件。GPU资源在内网环境里通常是稀缺的。几个部门共用一个GPU服务器的时候一定要把推理服务统一收敛加一个队列或配额机制避免某个团队的一次批量任务把显存打满导致所有在线应用一起卡死。我在项目里常用的方案是在线推理用vLLM跑一个带并发控制的API服务离线的批量任务放到低优先级队列。模型加载本身也是性能杀手。一个7B模型冷启动加载到显存可能要几十秒如果服务频繁重启用户体验会很差。建议配置模型的常驻和预加载同时给推理服务做健康检查确保物理机重启后模型能自动恢复。4.4 安全边界数据留在内网不等于裸奔数据留在内网只是第一步内网服务的安全边界同样要守住。永远不要为了让外部合作伙伴访问方便就把内网AI服务暴露到公网。这类操作会直接突破企业安全策略属于绝对不能在项目里做的事情。对内要遵守账号权限最小化原则。AI应用涉及的知识库往往包括敏感内容不能对全员无差别开放。对接企业统一身份体系按部门、角色、密级做细粒度访问控制。AI问答产生的日志要留够留存周期便于出现数据泄露时回溯。还有一层容易被忽略AI生成内容本身也要做合规把控。敏感词过滤、涉密信息检测、人工复核闭环这些要在应用设计时就留好接口。医疗、金融、政务类场景AI的回答建议明确标注“仅供参考”关键决策必须有人工审核环节。内网AI不是法外之地反而是合规要求最严格的试验场。5. 内网AI开发的三种高频落地场景与选型参考讲完方法和坑最后给几个可以直接对号入座的场景参考。这些场景都有一个共通点能很快展现出业务价值而且数据敏感度天然适合留在内网。5.1 企业私有知识库问答RAG这是内网AI落地最经典、最容易出成绩的场景。把规章制度、产品文档、客户案例、历史方案整理成知识库员工通过对话式问答获取信息回答附上出处。架构上就是“大模型向量库检索增强”。入门工具组合Ollama或vLLM跑模型bge做EmbeddingMilvus或pgvector存向量Dify或FastGPT做应用编排。这套组合完全可以在内网离线运行数据链路清晰扩展性也好。最难的地方不是技术而是知识库的持续维护一定要安排专人负责文档更新和质量审核。5.2 内部代码助手与研发提效很多研发团队想用AI辅助写代码但又不敢把代码库发给外部服务。内网部署一个私有代码助手是完全可行的路径把代码仓库的关键模块、技术规范、历史提交记录整理后向量化让模型基于项目上下文生成代码。这对需求分析、代码审查、自动化测试都能提效。要注意的是代码类场景对模型的代码能力要求很高建议选代码增强版模型比如专门优化的Coder系列。另外生成代码的安全审查不能省AI补全的代码可能有依赖漏洞或业务逻辑错误必须走原有代码评审流程不能因为“AI生成”就降低标准。5.3 文档草拟与数据报表Agent最后一个高频场景是文档和报表生成。企业里有大量周报、会议纪要、检查报告、数据说明需要写这些事情重复度高、格式固定非常适合用Agent来辅助。固定一个报告模板让AI根据数据源自动填充内容生成初稿后人再修改确认效率能提升一大截。这类场景的关键不是大模型有多聪明而是业务模板和数据链路要标准化。把数据仓库或Excel数据源接入Agent定义好字段映射和输出格式AI负责组织和润色文字。上线后建议保留人工复核步骤数据准确性问题宁可多一道检查也不要让错误报表直接发出去。场景核心输入输出关键组件推荐入门工具知识库问答制度、文档、FAQ带来源的回答向量库RAGDifyOllamaMilvus代码助手私有代码仓库补全/解释/审查代码模型仓库索引Qwen-CodervLLM报表Agent业务数据/模板草拟报告/报表说明数据对接模板解析FastGPT自定义API我个人在实际落地中的体会是真正卡住项目的往往不是模型效果而是数据准备和权限协同这两件“不性感”的活。模型选错了可以换数据不干净再强的模型也白搭。所以如果你想在企业里推动这件事我建议先从一两个业务价值明确、数据质量还不错的场景切入用四阶十二步里的最小闭环跑通拿到业务部门真实反馈后再横向扩展。内网AI开发的门槛没有想象中那么高但需要你有耐心去处理那些很琐碎却很要命的工程细节。
