前阵子一个做医疗信息化的朋友找我，说他们医院想搞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到16G，32B跑到比较舒服的状态需要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做Embedding，Milvus或pgvector存向量，Dify或FastGPT做应用编排。这套组合完全可以在内网离线运行，数据链路清晰，扩展性也好。最难的地方不是技术，而是知识库的持续维护，一定要安排专人负责文档更新和质量审核。
5.2 内部代码助手与研发提效
很多研发团队想用AI辅助写代码，但又不敢把代码库发给外部服务。内网部署一个私有代码助手是完全可行的路径：把代码仓库的关键模块、技术规范、历史提交记录整理后向量化，让模型基于项目上下文生成代码。这对需求分析、代码审查、自动化测试都能提效。
要注意的是，代码类场景对模型的代码能力要求很高，建议选代码增强版模型，比如专门优化的Coder系列。另外，生成代码的安全审查不能省，AI补全的代码可能有依赖漏洞或业务逻辑错误，必须走原有代码评审流程，不能因为“AI生成”就降低标准。
5.3 文档草拟与数据报表Agent
最后一个高频场景是文档和报表生成。企业里有大量周报、会议纪要、检查报告、数据说明需要写，这些事情重复度高、格式固定，非常适合用Agent来辅助。固定一个报告模板，让AI根据数据源自动填充内容，生成初稿后人再修改确认，效率能提升一大截。
这类场景的关键不是大模型有多聪明，而是业务模板和数据链路要标准化。把数据仓库或Excel数据源接入Agent，定义好字段映射和输出格式，AI负责组织和润色文字。上线后建议保留人工复核步骤，数据准确性问题宁可多一道检查，也不要让错误报表直接发出去。
| 场景 | 核心输入 | 输出 | 关键组件 | 推荐入门工具 |
|---|---|---|---|---|
| 知识库问答 | 制度、文档、FAQ | 带来源的回答 | 向量库+RAG | Dify+Ollama+Milvus |
| 代码助手 | 私有代码仓库 | 补全/解释/审查 | 代码模型+仓库索引 | Qwen-Coder+vLLM |
| 报表Agent | 业务数据/模板 | 草拟报告/报表说明 | 数据对接+模板解析 | FastGPT+自定义API |
我个人在实际落地中的体会是：真正卡住项目的往往不是模型效果，而是数据准备和权限协同这两件“不性感”的活。模型选错了可以换，数据不干净再强的模型也白搭。所以如果你想在企业里推动这件事，我建议先从一两个业务价值明确、数据质量还不错的场景切入，用四阶十二步里的最小闭环跑通，拿到业务部门真实反馈后再横向扩展。内网AI开发的门槛没有想象中那么高，但需要你有耐心去处理那些很琐碎却很要命的工程细节。
