夜雨聆风
最近一年，我一直用 AI Coding 做开发。
被问得最多的问题，不是模型怎么选。
也不是提示词怎么写。
而是一个更朴素的问题：
我们公司已经有业务系统了，AI 到底怎么接进去？
很多人第一反应，是在页面右下角加一个聊天框。
这只说对了一半。
聊天框只是入口。
真正有价值的接入，是让 AI 带着业务系统里的上下文工作。
它要知道你正在看哪份课件，调用哪套知识库，受哪些权限约束，最后把答案送回原来的业务页面。
如果只是把一个通用问答窗口塞进系统里，热闹归热闹，很难进入真实流程。
一、先别急着写代码，先分清两条路
企业接入 AI，第一步不是选模型，而是决定你要借平台，还是自己搭一层轻量架构。
主流做法大概有两种。
第一种，是依托成熟的第三方智能体平台。
你先在平台里配置智能体。
比如设置角色、知识库、工具、流程和回复规则。
部署完成后，平台一般会提供 API 地址、访问密钥或 API Key。
自己的业务系统可以先搭一层交互外壳，再按权限和日志要求补后端代理。
这个外壳可以是独立对话框。
也可以是页面内嵌窗口、右侧助手、审批页里的小浮层。
它的核心工作，是把问题发给平台，再把回答展示回来。
第二种，是自主搭建轻量化 AI 架构。
这条路不依赖外部智能体平台。
你要自己完成模型调用、系统提示词、工具调用、知识库检索、日志记录和异常处理。
听起来更重，但入门场景并不一定复杂。
如果只做一个课件 Wiki 问答助手，可以先从一个小闭环开始。
图1：先判断接入路线，再决定技术投入。
二、第三方平台适合先验证入口
如果你还没有验证业务场景，不要一开始就造完整 Agent 底座。
第三方平台的好处，是省掉底层编排。
你可以先把智能体配置出来。
再用业务系统去调用它。
这类方案特别适合三个场景。
第一，内部想快速验证一个 AI 助手入口。
比如客服知识库问答、制度问答、产品手册问答。
第二，团队里暂时没有后端 AI 工程能力。
第三，业务更关心能不能先跑起来，而不是一开始就深度改造系统架构。
但这里有一个底线。
密钥不能暴露在前端。
业务系统最好由后端创建一个代理接口。
前端只把问题发给自己的后端。
后端再带着访问密钥或 API Key 去调用第三方平台。
这样可以控制权限，也方便记录日志。
否则，一旦密钥被放进网页代码，后面的问题就不是 AI 能不能回答，而是系统会不会被滥用。
三、自主搭建时，先做一个 Wiki 问答助手
自主架构的入门案例，不要选“全公司万能助手”，先选一个边界清楚的知识库问答。
我更建议从课件页面的 Wiki 问答助手开始。
它的定位很纯粹。
用户正在看课件。
页面里有一个问答入口。
用户输入问题。
系统只围绕这套课件对应的 Wiki 知识库回答。
这就是一个非常适合入门的 RAG 场景。
RAG 可以理解成“先检索，再回答”。
模型不是凭空发挥。
它先去知识库里找相关内容。
再把找到的内容放进系统提示词。
最后结合用户问题生成答案。
整个链路可以拆成五步。
用户提问。
系统检索 Wiki。
召回相关片段。
把片段拼进 Prompt。
模型生成回答并返回前端。
图2：Wiki 问答助手的核心不是聊天，而是“检索内容片段后再回答”。
四、技术选型不要贪多：LangChain 加 Chroma 就够入门
入门方案最怕堆组件，组件越多，新手越不知道哪里坏了。
这套课件 Wiki 问答助手，我会选两个轻量组件。
一个是 LangChain。
一个是 Chroma。
LangChain 负责把链路串起来。
文档加载、文本切分、检索、Prompt 拼接、模型调用，这些能力都能在它的生态里找到对应模块。
对 AI Coding 来说，这也很友好。
因为框架的结构清楚，AI 更容易按标准写出可调试的代码。
Chroma 负责存储 Wiki 文本片段的向量。
它是开源向量数据库，支持 embedding 存储、向量检索、元数据过滤，也可以本地运行或自托管。
对入门项目来说，这个特点很关键。
入门阶段，不必先搭一套复杂数据库服务。
如果进入生产环境，再补服务化部署、权限隔离、备份、监控和限流。
可以先在单机环境里跑通知识库检索。
等业务量真的起来，再考虑更完整的部署方案。
这里要克制一点。
不要一上来就把多 Agent、长期记忆、复杂工具市场全做进去。
先让一个问题能被检索、能被引用、能被回答。
这才是入门阶段最重要的胜利。
图3：LangChain 管链路，Chroma 管向量知识库，业务系统管入口和权限。
五、把系统拆成五层，开发就不吓人
AI 架构看起来复杂，是因为很多人把入口、知识库、检索和模型调用混在一起讲。
真正做项目时，要把它拆开。
第一层，是交互层。
它在课件页面里提供一个轻量对话窗口。
只负责接收问题和展示答案。
不要在前端写复杂业务逻辑。
第二层，是知识库预处理层。
它负责加载课件、Wiki、讲义、FAQ。
再把内容切分成标准片段。
每个片段都要保留来源。
比如来自哪门课、哪一章、哪一页。
第三层，是检索链路层。
用户一提问，系统就把问题转成向量。
再去 Chroma 里找最相关的片段。
第四层，是 Prompt 拼接层。
这里要把系统提示词、召回片段、用户问题放在一起。
也要写清楚边界。
如果资料里找不到答案，就不要硬编。
第五层，是大模型调用层。
它把完整指令发给模型。
拿到结果后，再返回给课件页面。
这样拆完以后，你会发现这不是一个神秘系统。
它就是一条可调试的数据流。
图4：五层拆开后，每一层都能单独开发、单独测试。
六、真正上手时，只盯一个最小闭环
新手做 AI 系统，最容易卡在“我还没准备好完整平台”。
其实你只需要先跑通一个最小闭环。
第一步，准备一批课件或 Wiki 文档。
不要一开始就导入全公司资料。
先选一门课、一套手册、一个流程。
第二步，用文本切分工具把内容拆成片段。
片段不要太长。
也不要切得太碎。
第三步，给每个片段生成 embedding。
再写入 Chroma。
第四步，在后端写一个查询接口。
比如 /api/wiki-chat。
前端把用户问题发过去。
第五步，后端先检索，再拼 Prompt，再调模型。
第六步，把回答和引用来源一起返回。
第七步，让真实用户在课件页面里试用。
看它答错在哪里。
再回头调整切分方式、召回数量和提示词。
这就是 AI Coding 最适合发力的地方。
你不必手写每一段样板代码。
但你要会把任务拆清楚。
让 AI Coding 一次只生成一个小模块。
先生成文档导入。
再生成检索接口。
再生成前端对话窗口。
每一步都能运行，再进入下一步。
七、真正要小心的是边界，不是模型
AI 助手进入业务系统以后，最重要的不是回答更像人，而是行为更可控。
至少要设五条边界。
第一，权限边界。
用户只能问自己有权访问的资料。
第二，密钥边界。
API Key 只放在服务端。
第三，知识边界。
检索不到内容时，要明确说资料不足。
第四，日志边界。
问题、召回片段、模型回答、错误信息都要留痕。
第五，人工边界。
涉及制度解释、合规判断、合同建议、财务结论时，要提示人工复核。
这一步很多人会嫌麻烦。
但企业 AI 和个人 AI 最大的差别就在这里。
个人工具可以追求爽感。
业务系统必须追求可解释、可回溯、可暂停。
八、马上开始干，可以这样落地
AI 嵌入业务系统，不是一次“大上平台”，而是从一个受控页面跑通一条可复用链路。
如果你是第一次做，我建议明天就选一个真实页面。
不要选首页。
不要选门户。
选一个用户每天真的会打开的页面。
比如课件详情页、制度查询页、项目复盘页、合同评审页、流程文件页。
然后问四个问题。
这个页面里，用户最常问什么？
答案应该来自哪里？
系统能拿到哪些上下文？
什么情况必须让人工确认？
这四个问题答清楚以后，再决定技术路线。
如果只是验证入口，先用第三方智能体平台。
如果需要控制 Prompt、Skill、工具调用和知识库检索，就做一套轻量自主架构。
不要一开始就追求“万能智能体”。
先做一个能回答课件问题的 Wiki 助手。
让它能检索。
让它能引用来源。
让它能说“不知道”。
让它能在原业务页面里完成一次真实服务。
跑通以后，你得到的就不只是一个问答框。
你会得到一套可迁移的方法。
下次换成合同助手、流程助手、项目助手，本质上还是同一条链路：业务入口、知识上下文、Prompt 边界、模型调用、结果回传、日志审计。
这才是 AI Coding 真正降低门槛的地方。
它不是替你想清楚业务。
它是让你把已经想清楚的业务闭环，更快变成可运行的软件。
资料核查：本文技术判断参考了 LangChain 官方概览、LangChain RAG 教程、Chroma 官方文档 与 Chroma GitHub 仓库，用于核对 RAG、向量检索、本地或自托管运行和开源许可等基础表述。
