AI 能做什么：先判断需求，再选路线

开始学 AI 应用开发时，最容易被问住的问题不是"用哪个模型"，而是"这个需求到底适不适合用 AI"。

模型能写、能总结、能回答问题，也能调用工具做一些事。但它不是数据库、不是规则引擎，也不是一个会自动理解你公司业务边界的员工。把这件事想清楚，后面学 Prompt、RAG、Agent 或微调时会省很多力气。

这页先不追模型名。模型选型放在 主流模型厂商与 API 里讲。这里关心的是另一件事：你手里的需求应该走哪条技术路线。

先看任务形状

我会先把需求拆成几个很朴素的问题。

用户要的是一段可以修改的草稿，还是一个必须正确的结果？

模型需要只理解用户当前输入，还是必须查公司文档、数据库和历史记录？

它只负责生成内容，还是要替用户点击按钮、调用接口、修改系统状态？

出错以后是重新生成一次就行，还是会造成钱、权限、合规、用户信任上的损失？

这几个问题比"AI 能不能做"更有用。AI 通常不是能和不能的问题，而是能做到什么程度、需要哪些工程约束、是否值得付出这些成本。

AI 比较擅长的事

语义理解

LLM 很擅长把自然语言里的意图、对象和约束读出来。

比如用户输入：

帮我找一下上个月所有金额超过 5000 的报销单，按部门汇总。

模型可以识别出时间范围是"上个月"，筛选条件是"金额超过 5000"，聚合维度是"部门"。如果后面接一个查询工具，它就可以把这句话转成结构化参数。

这类能力适合做：

• 意图识别
• 文本分类
• 信息抽取
• 自然语言转结构化查询
• 工单、邮件、客服记录的自动分流

开发时不要只让模型"理解一下"。更稳定的做法是让它输出 JSON，再由程序校验字段。后面学 Structured Output 时会专门处理这个问题。

文本生成和改写

写草稿、改语气、翻译、压缩长文、生成说明文档，是目前最容易落地的能力。

这类任务的特点是结果有弹性。一个摘要少写了一句话，可以人工补；一段文案语气不合适，可以让模型再改。它不要求唯一正确答案。

如果你做的是内容工作台、运营助手、客服话术辅助、代码注释生成，通常可以先从直接调用 API 开始，不急着上 RAG 或 Agent。

代码辅助

AI 写代码的体验很强，但它更像一个速度很快的搭档，不像一个可以独立交付系统的工程师。

它擅长：

• 补全函数和样板代码
• 解释陌生代码
• 根据错误信息给出排查方向
• 写单元测试草稿
• 把一段逻辑改成另一种写法

它不稳定的地方也很明显：跨很多文件的业务约束、历史兼容逻辑、权限边界、性能细节，模型很容易漏。用 AI 写代码时，真正有价值的能力是会给上下文、会拆任务、会审查 diff。对应路线在 Vibe Coding 里。

基于上下文回答问题

如果把正确资料放进上下文，模型可以回答得很好。这里的重点是"正确资料"。

比如让它根据一份接口文档回答"这个字段什么时候为空"，通常比让它凭记忆回答靠谱得多。企业知识库、产品手册问答、合同条款检索、代码仓库问答，都是这个思路。

上下文短的时候，直接把文档片段塞进 Prompt 就可以。文档多了以后，需要先检索，再把相关片段交给模型，这就是 RAG。

多步推理和任务规划

现在的模型已经能处理一些多步问题，比如拆解需求、比较方案、给出排查顺序、根据约束写计划。配合 CoT 或 ReAct 思路，还能在中间调用工具，看结果后再决定下一步。

但多步不等于无限步。让模型一次性做十几个连续动作，中间没有检查点，失败率会上升。Agent 能做事，也会把风险放大。它适合有边界、有工具、有回滚或确认机制的任务，不适合直接接管关键系统。

AI 不擅长的事

精确计算

LLM 是语言模型，不是计算器。

你让它估算、解释公式、生成计算代码，通常没问题。你让它直接心算一串财务数字，再把结果写进报表，就不靠谱。

正确做法是让模型调用确定性工具：数据库、Python、Excel、计费服务、规则引擎。模型负责理解用户意图和组织流程，数字由程序算。

实时事实

模型本身不知道调用时刻的新闻、库存、价格、汇率、订单状态。就算它说得很像真的，也不代表是真的。

需要实时信息时，要接搜索、数据库或业务 API。模型输出前还应该带来源或可核查记录。没有检索层的"实时问答"，在生产环境里很危险。

强一致逻辑

审批流、权限判断、税费计算、风控规则，这些场景通常不该交给模型直接决定。

模型可以帮你解释规则、生成候选判断、整理证据，但最终结论最好由规则系统或人工确认。尤其是有合规责任的场景，"模型觉得可以"不是审计依据。

原生长期记忆

模型每次调用看到的是本次请求里的上下文。它不会天然记住用户上周说过什么，也不会自动维护业务状态。

如果产品需要记忆，要自己设计存储：用户画像、会话摘要、向量检索、偏好设置、操作日志。把所有历史消息一直塞进上下文，成本会涨，效果也会变差。

低容错的不可逆操作

删除数据、发送正式邮件、转账、改权限、发布线上配置，这些动作不适合让模型直接执行。

如果确实要做，至少要有权限隔离、参数预览、人工确认、审计日志和失败回滚。Agent 工具列表里不应该随手放一个"执行任意 SQL"。

从需求到技术路线

下面这个判断顺序更接近真实项目里的选择。

只是生成或改写内容

先走直接 API。

典型需求：

• 生成客服回复草稿
• 把会议纪要压缩成要点
• 把一段技术说明改成用户能读懂的版本
• 根据表单字段生成邮件
• 让代码助手解释一段函数

技术重点是 Prompt、上下文组织、Structured Output、流式输出和错误重试。这个阶段不要急着做复杂架构，先把输入输出跑通。

可以从 AI 应用开发 的基础部分开始，再看 流式输出与 SSE。

需要查私有资料

走 RAG。

典型需求：

• 问公司内部制度
• 问产品手册里的功能细节
• 问一批 PDF、合同、论文或代码文档
• 让客服助手回答只存在于知识库里的问题

RAG 难在检索、切分、排序、引用和评估，不只是"把文档喂给模型"。模型通常只负责最后组织回答。

如果答案必须能追溯来源，RAG 比直接微调更合适。微调可以改变模型风格，但不能可靠地把一批不断变化的知识塞进模型脑子里。

对应路线：RAG 原理、向量数据库、RAG 进阶优化。

需要调用工具或操作系统

看任务长度。短任务可以先做 Tool Calling，长任务再考虑 Agent。

典型需求：

• 根据自然语言查订单
• 调接口创建工单
• 根据用户描述生成 SQL，然后只读查询
• 让助手搜索资料、整理结果、生成报告
• 让编码 Agent 修改项目里的多个文件

如果任务可以一步完成，Tool Calling 就够了。模型把参数填好，程序调用工具，返回结果，再让模型组织回复。

如果任务需要"观察结果，再决定下一步"，才进入 Agent。这里真正要设计的是循环：模型计划动作，调用工具，读取反馈，继续决策。

这条路线要格外注意权限。建议先读 Agent 基础原理，再看 MCP 协议 和 多 Agent 协调。

输出格式固定，而且有大量样本

再考虑微调。

典型需求：

• 固定行业术语和写作风格
• 大量同类客服回复
• 某种稳定的分类标准
• 让小模型学会公司内部的输出格式

微调不是补知识的首选。它更适合让模型学会稳定风格、任务格式和判断边界。你需要准备样本、划分训练集和验证集，还要评估微调后有没有把别的能力弄差。

如果现在只有十几条样例，先别微调。Prompt 示例、规则校验和 RAG 往往更便宜。

对应章节：模型微调与定制化。

只是想让模型"更聪明"

先别急着换路线。

很多效果问题不是模型不够强，而是需求没有拆开，输入缺关键上下文，输出没有约束，或者根本没有评估标准。

在换更贵模型、做 RAG、做 Agent、做微调之前，先拿 20 到 50 条真实样例测试。把失败样例按原因分组：缺知识、格式错、推理错、工具参数错、业务规则没给清楚。分组之后，路线会清楚很多。

哪些场景不适合硬上 AI

精确财务计算

报销总额、税费、利息、账单扣款，不要让模型直接给最终数字。

可以让模型把自然语言需求转成查询条件，再由后端服务计算。结果返回后，模型可以解释"为什么是这个数字"，但不要让它自己算完就入账。

法律和合规结论

模型可以帮你整理条款、找风险点、生成问题清单。它不应该独立给出最终法律意见。

如果产品要面向用户输出合规判断，需要明确来源、置信度、人工复核流程和免责声明。更现实的做法是让 AI 做助理，不做裁判。

高权限自动化

自动删库、批量发邮件、修改权限、发布生产配置，这些都要谨慎。

你可以让 Agent 准备变更计划，列出将要执行的命令，甚至生成 pull request。但真正执行前，应该有人确认。对开发者工具来说，权限系统和审计日志不是锦上添花。

无法评估好坏的任务

如果你自己都不知道什么是好答案，AI 输出再流畅也没法判断。

这种情况先做评估标准。可以很粗糙：列 20 条真实输入，写下你希望的输出，标注哪些错误不能接受。没有这一步，后面调模型只是凭感觉。

一个实用判断表

需求特征	优先路线	先学什么
生成、改写、总结，结果可人工调整	直接 API	Prompt、Structured Output、流式输出
需要回答私有文档里的问题	RAG	文档切分、向量检索、引用来源、评估
需要查数据库或调用业务接口	Tool Calling	函数参数设计、权限控制、错误处理
需要多步执行并根据反馈调整	Agent	ReAct、工具循环、状态管理、审计
输出风格固定，有大量高质量样本	微调	数据集、训练验证、回归评估
要求 100% 确定、可审计、强规则	规则系统为主，AI 辅助	规则引擎、人工复核、日志

这个表不是为了把所有需求一次分完。它更像一个起点：先选最简单的可行路线，跑出样例，再决定要不要加复杂度。

读这条路线时怎么取舍

如果你是第一次做 AI 应用，我建议顺序是：

先用直接 API 做一个小功能。让它接收输入，返回结构化结果，接上流式输出和错误处理。

然后做一个小型 RAG。不要一开始就塞几千份文档，先用十几篇自己熟悉的资料，观察检索结果是不是靠谱。

再做工具调用。让模型查一个只读接口，比让它直接写数据库安全得多。

最后再碰 Agent 和微调。它们很有用，但更依赖工程边界。边界没想清楚时，做出来的东西看起来聪明，实际上难维护。

如果你主要想提升编码效率，从 Vibe Coding 路线 开始。如果你想把 AI 接进自己的产品，从 AI 应用开发路线 开始。模型怎么选，可以回到 主流模型厂商与 API。