> 本文为「全栈 AI 开发手记」第 01 篇。文中的企业知识助手等案例用于说明问题，不代表某个已经交付的项目。

前段时间看到一句话，大意是：现在做 AI 应用，接个模型接口，半天就能做出一个聊天机器人。这话没错。你可以很快做出一个页面，让用户输入问题，模型返回答案。再加上流式输出、历史记录，一个看起来像模像样的 AI 产品就出现了。但如果有人问你：

“公司内部文件很多，能不能让员工直接向 AI 提问？”

你做出来之后，对方又问：

“为什么它引用的是去年的制度？”

“为什么财务部的文件，其他部门也能搜到？”

“为什么有时候它说没有资料，有时候又编出一条规定？”

“我们修改了文档，多久才能在系统里生效？”

到了这里，你会发现，接入模型只是开始。你要面对的，是如何把 AI 变成一个有人愿意用、出了问题能排查、用久了还能维护的产品。而这，可能就是全栈 AI 应用开发工程师最真实的工作内容。

## 连接需求到上线的各个环节

传统开发岗位往往分工明确。前端负责页面和交互，后端负责接口和业务逻辑，算法工程师负责模型，产品经理负责需求。但在一些团队，尤其是小团队里，全栈 AI 应用开发工程师可能需要参与整条链路：

-   和业务人员聊清楚他们到底想解决什么问题；
    
-   做出可使用的页面和交互；
    
-   开发后端接口、数据库和权限系统；
    
-   接入模型、知识库或外部工具；
    
-   观察 AI 的回答质量，收集错误并持续优化；
    
-   部署上线，处理成本、速度和稳定性问题。
    

听起来像是什么都要会。这里的“全栈”要求你理解各环节如何连接，至少能把一个需求从“想法”推进到“有人能用”，不必在每个领域都成为专家。比如做一个内部知识助手，你不一定要自己训练大模型，但你需要知道：文件从哪里来、如何更新、谁有权限看、模型回答时依据了什么，以及用户觉得答案不对时该怎么办。你的工作重心，会从“完成一个开发任务”，逐渐转向“让整个功能跑通”。

## 把“智能”拆成可执行的业务任务

“帮我们做一个智能客服。”

这句话听起来很清楚，但真正动手前，还有很多问题：

-   它只负责回答问题，还是也要处理退款？
    
-   它能不能查看用户订单？
    
-   不确定答案时，是继续回答，还是转人工？
    
-   用户问到没有写进知识库的政策，怎么办？
    
-   如果它给错了补偿承诺，谁来处理？
    

这些问题里，有些需要技术解决，有些需要业务方做决定。如果一开始只盯着模型，开发很容易变成这样：

> 模型答得不好，改提示词。  
> 还是不好，换模型。  
> 换了模型还不好，上知识库。  
> 知识库效果不稳定，再加 Agent。

忙了一圈才发现，真正的问题是：业务规则本身就没有统一。所以你需要练习的一项能力，是把“做得智能一点”翻译成具体任务：

> 用户遇到什么问题？  
> 系统要读取哪些信息？  
> 期望输出什么结果？  
> 出错后由谁接手？

当这些问题清楚了，你才知道 AI 应该做什么，以及哪些地方需要明确的程序规则。

## 先理清资料、版本和权限

很多人第一次做企业 AI 应用时，都会遇到一个落差：模型看起来什么都懂，为什么一问公司的具体业务就开始胡说？原因其实很简单：它不天然拥有你公司的最新制度、内部文档、客户记录和业务背景。于是你会接触到一个高频概念：RAG，也就是检索增强生成。可以把它理解成一个过程：用户提问后，系统先从相关资料中查找内容，再把找到的资料交给模型，让它结合资料回答。听起来并不复杂，但做起来很容易遇到现实问题：

-   PDF 解析出来，表格乱了；
    
-   一份制度有多个版本，系统找到了旧版；
    
-   文档切得太碎，关键条件丢失；
    
-   搜索结果看似相关，其实没有回答用户的问题；
    
-   用户没有权限查看的资料，被错误地送进了上下文；
    
-   文档更新了，知识库却没有同步。
    

这时你会慢慢意识到：知识库效果同时取决于模型、数据整理、检索和权限管理。有时候，花半天把文档来源和版本整理清楚，比反复修改提示词更有效。当然，RAG 也不是万能的。如果用户问的是实时库存，系统可能更需要查询业务数据库；如果问题涉及计算，可能需要调用确定性的计算程序。该用什么，要看任务本身。

## 接口成功之后，还要评估答案

传统程序里，接口报错、页面白屏，通常比较容易判断“出问题了”。AI 应用则不同。模型可能正常返回了一大段流畅的文字，接口状态也是成功，但答案恰好是错的。更麻烦的是，它今天答对了，明天换一种问法，可能又答错了。因此，你需要学会做一件以前容易被忽略的事：建立评估方法。以知识助手为例，可以先收集一批真实问题：

-   能不能找到正确资料？
    
-   回答有没有引用依据？
    
-   资料不足时，它会不会明确说不知道？
    
-   对不同部门的用户，是否遵守各自权限？
    
-   面对过期文件和互相冲突的资料，会怎么处理？
    

这些问题不需要一开始就做成复杂的平台。哪怕先整理成一个小型测试集，每次修改提示词、检索方式或模型后重新跑一遍，也能帮助你发现：这次改动究竟是整体变好了，还是只修好了演示时那一个问题。

多位 AI 应用实践者在 [《What We’ve Learned From A Year of Building with LLMs》](https://eugeneyan.com/writing/llm-lessons/ "《What We’ve Learned From A Year of Building with LLMs》") 中也强调了从真实使用中收集问题、将其转化为评估样本的重要性。评估 AI 应用的质量，需要看它在一批真实任务里的表现。

## 检查 AI 生成的代码与业务结果

选择这个方向后，你大概率也会大量使用 AI 辅助开发。让它生成页面、解释代码、排查报错、补充接口，甚至协助完成一部分完整功能，确实能提高效率。但你也会遇到另一面：它可能写出了看起来能运行的代码，却忽略了权限；也可能为了解决一个问题引入了不必要的依赖；还可能信心满满地告诉你“已经完成”，但实际业务流程只跑通了一半。所以，AI 让你少写一部分代码，并不意味着你可以不理解系统。相反，你需要更清楚地判断：

-   它改了什么，为什么这样改？
    
-   有没有影响原来的功能？
    
-   接口返回成功，数据是否真的保存了？
    
-   关键业务流程有没有实际验证？
    
-   出现异常时，用户看到的是什么？
    

以前，你可能用大量时间写代码；现在，你可能会用更多时间描述任务、检查结果和验证行为。生成代码越来越快，判断代码是否解决了问题，依然是工程师的责任。

## 根据问题选择工作流与 Agent

做 AI 应用，你很难绕开这些词：大模型、Prompt、RAG、Agent、MCP、工作流、工具调用、上下文、评估、多模态……每隔一段时间，又会有新的框架、新的模型、新的实践冒出来。刚入行时很容易焦虑：是不是每一个都要学？是不是不用最新框架，项目就落后了？我的建议是，先把概念放回实际问题里。用户需要查询公司制度，你可能需要检索和引用。用户需要从订单系统读取数据，你可能需要工具调用和权限控制。

用户需要系统自主拆解不确定的复杂任务，你才需要进一步考虑 Agent。如果流程本来就明确，例如“读取文件、提取字段、人工确认、保存”，固定工作流可能已经够用。

Anthropic 在 [《Building Effective AI Agents》](https://www.anthropic.com/research/building-effective-agents "《Building Effective AI Agents》") 中也提出过类似经验：先从简单方案开始，根据实际效果决定是否增加复杂度，因为更自主的系统通常也会带来额外的成本和延迟。技术选型要看它是否让问题更容易解决。

## 让用户能够持续使用

一个功能在你电脑上运行，和让几十个、几百个用户持续使用，是两回事。你会开始关心：

-   一次请求调用了多少次模型？
    
-   上传一份长文档，要花多少钱、等多久？
    
-   用户一直追问，对话上下文会不会越来越长？
    
-   模型服务超时了，用户该看到什么？
    
-   某个模型效果更好，但成本更高，值不值得？
    
-   高峰期同时有很多人使用，系统会不会卡住？
    

这些问题没有统一答案。一个内部试用工具，可能先保证功能可用就足够；一个要面向大量客户的产品，则需要更认真地考虑限流、监控、重试、成本和服务稳定性。你也会发现，用户通常不会因为“这是 AI”就接受漫长等待。他们更关心的是：我能不能顺利把这件事做完。

## 理解业务，说明产品边界

如果你做的是销售助手，你需要理解销售人员每天如何跟进客户。如果你做的是合同分析，你需要知道哪些字段值得关注、什么情况必须由专业人员复核。如果你做的是内部知识库，你需要知道员工最常问什么，以及错误答案可能造成什么影响。你不需要第一天就成为行业专家，但你得愿意和真正使用系统的人坐下来，弄明白他们的工作。同时，也要敢于说清楚边界。比如：

“这个功能可以先帮你整理合同要点，但关键条款仍需要人工审核。”

“系统可以根据现有资料回答，但资料没更新时，答案也可能过期。”

“这个操作会修改业务数据，我们先让 AI 给出建议，由用户确认后再执行。”

边界说清楚，不会让产品显得不智能，反而更容易建立信任。

## 如果现在开始，应该怎么学？

不建议一上来就列出几十门课程，然后陷入漫长的准备。更实际的方法，是选一个你自己能理解的场景，做出一个完整的小项目。比如：做一个带资料来源的个人知识助手。第一步，先做出基本应用：用户可以上传文档、提问、查看回答。第二步，让它能从文档中检索内容，并展示答案参考了哪些资料。第三步，加入几个真实情况：文档更新、查不到答案、上传失败、重复文件。

第四步，找一些问题来测试，记录哪些答对了、哪些答错了，以及错在检索还是生成。第五步，再考虑用户登录、权限、部署、响应速度和费用。做完之后，你可以试着回答这些问题：

> 这个应用解决了什么问题？  
> 一次请求经过了哪些步骤？  
> 你遇到过什么错误，是怎么定位的？  
> 你如何判断修改之后效果变好了？  
> 如果有更多人使用，下一步最需要改进什么？

能把这些讲清楚，通常比在简历上堆一长串技术名词更有说服力。如果你本来是前端工程师，可以重点补后端、数据库和部署；如果你本来做后端，可以重点补用户交互和 AI 应用的评估方法。起点不同，补的课也不必完全一样。

## 从一个完整的小项目开始

全栈 AI 应用开发的范围很宽：上午可能在和业务人员讨论流程，下午排查接口，最后发现答案错误的根源是一份过期文档。模型、代码与数据都只是产品的一部分。刚开始不必同时追上所有框架。先选一个能理解的场景，把上传、检索、回答、异常处理和部署连起来，再让真实用户试用。能说明哪里做到了、哪里会失败、下一步根据什么改，比只展示一次流畅回答更有说服力。

## 参考阅读

-   [What We’ve Learned From A Year of Building with LLMs](https://eugeneyan.com/writing/llm-lessons/ "What We’ve Learned From A Year of Building with LLMs")：多位实践者总结的 LLM 产品开发经验。
    
-   [Building Effective AI Agents](https://www.anthropic.com/research/building-effective-agents "Building Effective AI Agents")：关于工作流、Agent 和复杂度取舍的实践建议。
    
-   [Building LLM Applications for Production](https://huyenchip.com/2023/04/11/llm-engineering.html "Building LLM Applications for Production")：关于大模型应用进入生产环境的工程挑战。文章发表于 2023 年，涉及具体模型和服务的描述需结合现状判断。
    

---

## 在我的网站继续阅读

本文同步自我的个人网站：[阅读文章原文](https://liangyanghao.cn/insights/fullstack-ai-from-demo-to-product "阅读文章原文")。

更多 AI 入门课程、开发手记与项目复盘，欢迎访问：[梁养浩的 AI 入门课](https://liangyanghao.cn/ "梁养浩的 AI 入门课")。

本文为「全栈 AI 开发手记」第 01 篇。文中的企业知识助手等案例用于说明问题，不代表某个已经交付的项目。 前段时间看到一句话，大意是：现在做 AI 应用，接个模型接口，半天就能做出一个聊天机器人。这话没错。你可以很快做出一个页面，让用户输入问题，模型返回答案。再加上流式输出、历史记录，一个看起来像模像样的 AI 产品就出现了。但如果有人问你： “公司内部文件很多，能不能让员工直接向 AI 提问

从聊天演示到可用产品：全栈 AI 开发要补上哪些环节

人工智能

架构设计

职业发展

本文深入解析全栈AI应用开发的核心要点，从需求梳理、RAG知识库构建到权限管理与系统评估，揭示企业级AI落地的真实挑战与解决方案，适合希望掌握AI工程化全流程的开发者参考。

聊天机器人

大模型应用

数据库

AI Agent

Agent

让每一个 Agent，都跑在云上

lexiang

timatrix

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

从聊天演示到可用产品：全栈 AI 开发要补上哪些环节-腾讯云开发者社区-腾讯云

从聊天演示到可用产品：全栈 AI 开发要补上哪些环节

从聊天演示到可用产品：全栈 AI 开发要补上哪些环节

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐