AI 应用全貌：先理解工作，再决定学什么

1. AI 应用工程师交付什么

完整链路通常是：发现问题 → 理解现有流程 → 确定成功标准 → 验证技术方案 → 开发 → 评测 → 试用 → 上线维护。

模型只是链路中的一个组件。很多工作仍然是需求分析、接口、数据、权限、交互、测试和运行维护。

不少学习者能跑教程却无法接住项目，是因为教程替他们完成了需求界定、数据准备和环境配置。真实工作要求自己处理这些不确定性。

2. 按任务认识应用类型

类型	典型任务	常见组成	主要难点
生成与编辑	文案、报告、回复草稿	模型 + 模板 + 编辑界面	事实、风格、重复生成的一致性
提取与分类	工单分类、材料字段提取	模型 + 格式校验 + 业务规则	漏提、歧义、格式正确但内容错误
知识查询	产品说明、项目资料查询	检索 + 模型 + 引用	资料质量、检索、更新、权限
流程辅助	材料整理、审核辅助	固定流程 + 模型步骤 + 人工处理	异常分支、责任归属、系统集成
任务执行	查询系统、调查问题、执行操作	Agent + 工具 + 状态管理	错误累积、授权、执行恢复
AI Coding	实现功能、修复缺陷、审查代码	模型 + 代码上下文 + 开发工具	正确理解需求、验证、维护

同一个产品可以组合多种类型。不要把“带聊天框”当成 AI 产品的定义：后台分类、自动提取和编辑器中的补全同样属于 AI 应用。

3. 四个概念各负责什么

概念	主要职责	不应误解为
RAG	检索外部资料，给生成提供依据	自动保证事实正确
Workflow	按预定规则组织步骤和分支	必须让模型决定每一步
Agent	在边界内让模型根据结果选择下一步行动	能无条件自主完成所有任务
AI Coding	用 AI 辅助或执行软件开发任务	生成代码就等于完成交付

例子：客服消息分类 → 检索说明书 → 生成回复草稿 → 人工发送，是 Workflow，其中使用了 RAG。即使没有自主规划，也可以解决问题。

这些概念不是升级阶梯。能用稳定的固定流程解决问题时，不必为了练习而增加自主 Agent。

4. 怎样判断一个需求值得做

先问清楚七件事：

1. 谁在什么时候遇到问题？
2. 当前怎样完成，频率和耗时是多少？
3. 输入数据从哪里来，有没有使用权限？
4. 怎样判断输出正确，错误代价是什么？
5. 结果要进入哪个系统，由谁使用或审核？
6. 规则或普通搜索是否已经足够？
7. 什么结果能让用户愿意持续使用？

企业付费理由可能是减少重复劳动、缩短等待、增加可处理任务量、减少遗漏，或让知识更容易使用。这些是待验证的价值假设，不能只凭演示推断。

一个简单核算框架：

净收益 ≈ 实际节省的人工与返工成本 + 新增价值 − 模型和基础设施费用 − 人工复核成本 − 维护成本。

各项应避免重复计数。若 AI 生成很快，但检查修正比原来更费时，就没有实现节省时间的目标。

5. 常见落地路径

1. 需求探索：访谈用户，收集真实输入，明确边界和现状基准。
2. 可行性验证：用少量样例检验核心假设，允许手动处理非关键步骤。
3. 最小产品：接通用户操作到结果交付的完整链路。
4. 受控试用：在少量用户、明确权限和可恢复的范围内验证。
5. 上线运营：监控效果、费用和故障，持续处理反馈。

每一步都可以得出“暂不继续”的结论。例如资料缺失、效果提升不明显、复核成本过高时，应该修正方案，不应仅因已经写了代码而继续投入。

6. 你的工作切入点

• 前端：输入约束、流式结果、引用、编辑、取消、失败恢复、历史任务。
• Node.js：模型接入、服务端校验、上下文拼接、工具接口、持久化。
• 数据：文档导入、版本、检索、访问控制。
• 质量：测试样例、错误分类、回归评测和运行日志。
• 产品判断：何时使用 AI、哪些结果需人工确认、如何验证价值。

实际分工取决于团队和岗位。本路线不以未经核实的招聘数量、薪资或“最热门岗位”为依据。

7. 第一项练习：产品拆解卡

选择六个具体功能，覆盖至少四种应用类型。每张卡记录：用户、当前流程、AI 承担的步骤、所需数据与接口、可能失败的地方、人工处理方式、价值指标。

验收：能够解释两个看起来都像聊天机器人的应用，为什么实际需要不同的数据、流程和评测方式。