linong

AI 应用面试百题精讲（上）：大模型 · Python · Prompt


面试笔记
AI 面试 大模型 Python Prompt FastAPI

每题结构：答（面试可说的口径）+ Review（纠偏、补强、追问点）。Review 里的坑往往比标准话术更值得先记。

系列导航

一、大模型与 AI 应用基础

Q1. 什么是大语言模型？它和传统机器学习模型最大的区别是什么？

答： 大语言模型本质上是参数规模很大、基于海量语料预训练出来的生成式模型，核心能力是根据上下文预测下一个最合理的 token。它和传统机器学习模型最大的区别在于，传统模型通常针对单一任务训练，比如分类、回归、推荐，而大语言模型先做通用预训练，再通过提示词、检索、工具调用或微调去适配很多任务，所以泛化能力更强，迁移成本更低。

Review： 别停在定义。加分：提 Scaling Law、通用预训练后再适配任务；并说清「生成式概率模型 ≠ 知识库」，方便接到幻觉与 RAG。

Q2. 为什么 Transformer 会成为大模型的主流架构？

答： 核心原因是 Transformer 用自注意力机制替代了 RNN 的时序递归，训练时可以高度并行，更适合在大规模 GPU 集群上扩展。它还能直接建模长距离依赖，不像 RNN 那样容易出现长期依赖衰减问题。再加上结构统一、可扩展到文本、图像、语音、多模态，所以它成了大模型时代最主流的底层架构。

Review： 并行训练与长距离依赖是核心。可补：主流生成模型多为 Decoder-only；标准 Attention 仍是 O(n²)（与 Q3 呼应），长上下文靠稀疏/线性注意力、窗口与工程优化。

Q3. Self-Attention 相比 RNN 和 CNN 的优势是什么？

答： Self-Attention 的优势主要有三个。第一，它可以直接看到整个序列，建模远距离依赖更自然；第二，它可以并行计算，不像 RNN 必须一步一步处理；第三，它会根据当前输入动态分配不同位置的重要性，表达能力更强。它的主要代价是序列长度很长时计算和显存开销会明显上升，因为标准注意力复杂度接近 O(n²)。

Review： 答三点优势时，务必主动提代价：O(n²) 算力与显存；对比 CNN 提「全局依赖」即可，不必深挖卷积核细节。

Q4. 预训练、SFT、RLHF、DPO 分别是什么？

答： 预训练是在海量通用语料上学习语言规律和世界知识，让模型先具备基础理解与生成能力。SFT 就是监督微调，用高质量问答或指令数据把模型往特定风格和任务方向拉齐。RLHF 是先训练奖励模型，再通过强化学习让模型输出更符合人类偏好。DPO 可以理解为不显式做强化学习、直接用偏好对比数据优化策略，工程实现更简单，最近在很多场景里比 RLHF 更常见。

Review： 四段能串起来。补一句：DPO 更省事不等于处处更强，偏好数据质量决定上限；工业里还有 RLAIF、拒绝采样等变体。

Q5. temperature、top_p、max_tokens 这些参数分别控制什么？

答： temperature 控制随机性，越低越稳定，越高越发散； top_p 是核采样，表示只从累计概率达到某个阈值的一小部分候选 token 里采样； max_tokens 控制本次最多生成多少内容。面试里可以直接说，temperature 影响创造性和确定性，top_p 影响采样范围，max_tokens 影响输出长度和成本，这三个参数通常需要结合具体业务一起调。

Review： 实践里 temperature 与 top_p 作用重叠，通常主调一个；max_tokens 同时影响成本与截断，别只当「写长一点」。

Q6. 大模型为什么会出现幻觉？怎么缓解？

答： 幻觉的根本原因是模型本质上是在做概率生成，不是真正去数据库里查事实，所以当训练知识不完整、上下文不充分、提示词不清晰时，它就可能生成看起来很像真的错误答案。缓解方式通常有几类：第一，用 RAG 提供外部知识；第二，限制输出格式并要求引用来源；第三，降低温度，减少发散；第四，对高风险场景增加规则校验、人审和工具验证。我的理解是，幻觉无法完全消灭，只能通过系统设计把风险降下来。

Review： 「无法根除、只能缓解」要站稳。工具校验与引用溯源往往比单纯降温度有效；检索文档本身也可能带错事实。

Q7. 什么是上下文窗口？什么是 KV Cache？

答： 上下文窗口指模型单次推理时能看到的最大 token 范围，窗口越大，模型一次能参考的信息就越多，但成本和时延通常也会更高。KV Cache 是生成阶段的一种加速机制，模型在前面 token 上算出来的 Key 和 Value 会缓存起来，后续生成新 token 时不用重复计算整段上下文，所以能显著降低解码时延。简单说，上下文窗口解决「能看多长」，KV Cache 解决「生成时怎么算得更快」。

Review： 区分「能看多长」与「解码怎么更快」。加分：KV Cache 随上下文与并发线性涨显存，是推理瓶颈；长窗口不等于该把整库塞进 prompt。

Q8. Embedding 和 Rerank 的区别是什么？

答： Embedding 主要解决召回问题，它把文本映射成向量，通过向量相似度快速找出一批「可能相关」的候选内容。Rerank 主要解决精排问题，它会把用户问题和候选文档一起再判断一遍，给出更精细的相关性排序。实际系统里通常是 Embedding 先做粗召回，保证速度，再用 Rerank 做精排，保证准确率。

Review： 粗召回 vs 精排即可。补：Rerank 多用 cross-encoder，贵，所以只打 TopK；chunk 差时 Rerank 也救不了。

Q9. 量化、蒸馏、LoRA 分别适合什么场景？

答： 量化是把模型权重从高精度改成低精度，主要目的是降低显存占用和推理成本，适合部署优化。蒸馏是让小模型学习大模型的能力，目标是做更轻量的替代方案，适合边缘端或高并发场景。LoRA 是一种参数高效微调方法，不改动全量参数，只训练少量增量参数，适合在有限算力下做领域定制。三者的关注点分别是部署压缩、模型缩小和低成本微调。

Review： 三分法够用。量化常配 GPTQ/AWQ；LoRA 要能说训哪些层、rank 怎么选；蒸馏更常见是「大模型产数据训小模型」。

Q10. 做知识型问答时，什么时候选微调，什么时候选 RAG？

答： 如果问题主要是知识更新快、需要可追溯、需要引用企业内部文档，我会优先选 RAG，因为更新知识不需要重新训练模型，成本更低，也更容易做权限控制。如果问题主要是输出风格、领域术语、固定流程、工具选择习惯需要长期稳定下来，我会考虑微调。很多真实项目里不是二选一，而是先用微调把模型行为调顺，再用 RAG 解决知识实时性问题。

Review： 关键不是二选一：行为/口吻可用微调，事实/权限/更新用 RAG；多数生产是组合拳。

Q11. Tokenizer 为什么重要？

答： 因为模型真正处理的不是字符也不是单词，而是 token。Tokenizer 会直接影响上下文长度、计费成本、分块策略以及中英文混合场景下的表现。同一段文本用不同 tokenizer 切出来的 token 数可能差很多，所以在做成本评估、长文本切分、截断策略时，必须先理解 tokenizer 的行为。

Review： 常被忽视却直接影响账单与截断。中英混合、代码、表格的 token 膨胀要会举例；分块策略应跟同一 tokenizer 对齐。

Q12. 一个典型 AI 应用系统的整体架构一般是什么样的？

答： 通常会分成几层：最上层是前端或业务入口；中间是应用编排层，负责提示词、会话状态、工具调用、权限控制和结果后处理；下面是知识与工具层，包括向量库、数据库、搜索引擎、业务 API；再下面是模型层，可以接公有云模型也可以接私有模型；旁边还要有日志、监控、缓存、鉴权、评测和成本统计。面试里我一般会强调，AI 应用不是只接一个模型 API，而是一个完整的工程系统。

Review： 强调完整系统。面试官更想听你负责过哪一层：编排、检索、工具治理，还是评测/成本。

二、Python 与 AI 开发工程能力

Q13. 为什么 Python 在 AI 开发里这么常见？

答： 因为 Python 生态非常成熟，PyTorch、Transformers、FastAPI、LangChain、数据处理和科学计算工具链都很完善，很多新模型和新论文也是先给 Python 版本。它的语法也足够简单，适合快速验证想法，所以在模型训练、推理服务、RAG 和智能体原型阶段，Python 的开发效率通常很高。

Review： 生态与效率是事实。补短板：GIL、部署形态、类型系统；以及「原型 Python、企业接入 Java」的常见分工。

Q14. Python 做 AI 应用时常见的技术栈有哪些？

答： 如果是模型和数据层，常见的是 PyTorch、Transformers、NumPy、Pandas。做 Web 服务常见的是FastAPI、Uvicorn、Pydantic。做异步任务和队列常见的是 Celery、Redis、RabbitMQ。做 RAG 可能会配合FAISS、Milvus、Qdrant、pgvector。做评测和实验管理时，也会用到 Weights & Biases、MLflow 或一些自定义埋点系统。

Review： 清单之外，近年可补：LangGraph/工作流引擎、MCP、vLLM/推理网关、评测里的 LLM-as-judge。

Q15. Python 的 GIL 对 AI 服务有什么影响？

答： GIL 的意思是同一个 Python 进程里，同一时刻只能有一个线程执行 Python 字节码，所以对 CPU 密集型任务，多线程并不能真正并行，收益有限。但对 I/O 密集型任务，比如调用外部模型 API、访问数据库、等待网络响应，多线程和异步仍然有价值。实际项目里，如果是 CPU 密集型预处理，我更倾向于多进程、C 扩展或者把重计算下沉到模型服务侧。

Review： 按 I/O vs CPU 分流。补：NumPy/PyTorch 等原生库常释放 GIL；Python 3.13+ 有 free-threaded 实验，但生产仍多受 GIL 约束。

Q16. asyncio 在 AI 应用里适合解决什么问题？

答： 它更适合处理高并发 I/O 场景，比如同时调用多个外部接口、并发召回多个知识源、做流式输出、管理大量网络连接。它不适合拿来硬做 CPU 重任务，因为那类问题瓶颈不在 I/O。我的经验是，智能体系统里经常会出现很多「等待外部工具返回」的阶段，这种时候 asyncio 会比纯同步代码更高效。

Review： 适合 Agent 多工具等待。陷阱：在 async 里跑同步阻塞会拖死事件循环（见 Q17/Q18）。

Q17. 为什么很多 Python AI 服务喜欢用 FastAPI？

答： 因为 FastAPI 天然支持类型标注、异步接口和自动生成 OpenAPI 文档，写接口快，和 Pydantic 配合后请求校验、响应约束都比较顺手。对于 AI 服务这种迭代快、接口多、经常需要定义结构化入参出参的场景，它的开发体验通常比传统框架更好。

Review： 类型 + 异步 + OpenAPI 是卖点。补：性能来自 ASGI/Starlette；async def 里写同步 I/O 是常见事故。

Q18. 在 Python 项目里，多线程、多进程、协程该怎么选？

答： 如果主要是网络 I/O，比如调模型 API、查数据库、调搜索接口，我会优先考虑协程；如果需要利用多核做 CPU 密集型计算，我会选多进程；如果只是兼容一些阻塞库或者做轻量并发，我会考虑线程。面试里最好不要绝对化地说哪种方式更好，而是强调要看瓶颈到底在 CPU、I/O 还是工程复杂度。

Review： 按瓶颈选型。可补：GPU 推理常另进程/服务；线程适合包一层阻塞 SDK。

Q19. Python AI 服务调用外部模型接口时，超时、重试、降级一般怎么设计？

答： 我通常会先分清楚哪些错误可重试，哪些错误不可重试，比如网络抖动、临时 5xx 可以重试，参数错误就不该重试。然后会设置合理的连接超时和读取超时，避免请求长期挂死；重试要加退避和上限，避免雪崩；再往上要有降级策略，比如切备用模型、切简化回答模式，或者直接返回兜底提示。核心思想不是「尽量重试」，而是「让系统在失败时仍然可控」。

Review： 「失败可控」比「拼命重试」更成熟。补：区分超时/限流/内容过滤错误；幂等与预算熔断（钱和 token）。

Q20. Pydantic 在 AI 应用里有什么价值？

答： 它最大的价值是把原本很容易失控的 JSON 输入输出结构化、类型化。比如工具调用参数、模型结构化输出、知识检索返回格式，都可以先定义 Schema，再统一校验，这样可以减少脏数据流入下游系统。对智能体项目来说，Pydantic 不只是参数校验工具，本质上也是让系统边界更清晰的一层约束。

Review： 工具参数与结构化输出的边界约束——很实用。补：配合模型侧 structured output / JSON schema，校验失败要有重试或兜底。

Q21. 什么是批处理推理？什么时候值得做 Batch？

答： 批处理推理就是把多个请求合并成一批一起送进模型，目的是提高吞吐和硬件利用率。它通常适合离线任务、高并发相似请求或者对实时性没那么敏感的场景。如果是严格低延迟的在线对话，Batch 做得太大反而会拉高单请求时延，所以要在吞吐和响应时间之间找平衡。

Review： 吞吐与延迟要一起谈。可提 continuous batching（如 vLLM）：动态组批，比静态大 batch 更适合在线。

Q22. Python AI 服务里常见的内存问题有哪些？

答： 比较常见的是大对象长期引用不释放、缓存无上限增长、异步任务堆积、日志把大文本全量打出来、以及 GPU 显存没有正确回收。还有一种常见问题是请求上下文里带了太多聊天历史和检索内容，导致单次请求对象特别大。处理这类问题时，我一般会先看对象生命周期、缓存策略、并发模型和监控数据，而不是先怀疑语言本身。

Review： 先看生命周期与缓存策略。补：流式场景下的缓冲堆积；embedding/检索缓存无界；不要把完整 prompt 打进热路径日志。

Q23. Python AI 项目怎么做环境和依赖管理更稳妥？

答： 我会尽量做到解释器版本固定、依赖版本固定、环境隔离、构建过程可复现。常见做法是用虚拟环境隔离项目依赖，再配合 requirements 或 pyproject 把版本锁住，生产环境通常会放进容器里统一交付。AI 项目尤其要注意 CUDA、PyTorch、驱动版本之间的兼容性，因为这类问题一旦漂移，线上和本地很容易不一致。

Review： 可复现交付是重点。AI 特有坑：CUDA/驱动/torch 版本矩阵；锁文件 + 容器镜像摘要比口头「装一下」可靠。

Q24. Python AI 服务上线后，最应该监控哪些指标？

答： 除了常规的 QPS、错误率、P95/P99 时延，我会重点看模型调用成功率、首 token 时延、总 token 数、单请求成本、检索命中率、工具调用成功率、队列堆积、缓存命中率和上下文长度分布。如果是智能体，还要看平均步数、异常终止率和人工接管率。因为 AI 应用的问题很多不体现在单一报错上，而是体现在质量、成本和时延一起漂移。

Review： 常规指标之外，智能体务必加：平均步数、工具失败率、人工接管率；质量漂移往往先于硬错误出现。

三、Java 与企业级 AI 应用集成

Q25. Java 在 AI 应用开发里的定位是什么？

答： 我的理解是，Python 更偏模型侧和快速实验，Java 更偏企业级应用侧和系统集成。很多公司原来的核心业务系统、权限体系、消息系统、网关、交易链路本来就是 Java 生态，所以真正把 AI 落到生产里时，Java 往往承担 API 网关、业务编排、权限控制、审计日志、流程接入和高并发服务治理这些职责。

Review： 双语言定位清楚。别说成「Java 不能做 AI」——很多公司 Java 就是生产主场。

Q26. Spring AI 和 LangChain4j 这类框架解决了什么问题？

答： 它们本质上是在 Java 生态里把「接模型、做提示词、接工具、接知识库、做结构化输出」这些通用能力封装起来，减少重复造轮子。Spring AI 更强调和 Spring 体系的整合，LangChain4j 更强调 Java 版本的 LLM编排能力。面试里可以直接说，这类框架的价值不是替你设计系统，而是把模型接入层标准化。

Review： 价值在标准化接入层。框架不替你做权限与评测；版本演进快，要能讲为何选/不选。

Q27. Java 服务调用大模型接口时，最需要注意什么？

答： 我最关注四件事：第一，连接池、超时和重试策略要合理；第二，流式输出要能稳定解析，不能把半包和断流当成正常结果；第三，要做好幂等和审计，尤其是会触发业务动作时；第四，要把模型错误和业务错误区分开。因为在企业系统里，调用模型不是「能返回文本就行」，而是要放进一个可治理、可观测、可回溯的服务链路里。

Review： 四点够用。流式半包、业务动作幂等，是最容易翻车的两处。

Q28. Java 里为什么很多 AI 服务会用异步或响应式方案？

答： 因为很多 AI 场景是高延迟 I/O，不是纯 CPU 计算，比如等模型响应、等检索结果、等外部工具返回。如果全用同步阻塞，请求线程会被长时间占住，高并发下资源浪费比较明显。用 CompletableFuture、WebClient 或 Reactor 这类方案，可以把等待外部依赖的时间更高效地管理起来，尤其适合流式输出和多路并发聚合。

Review： 高延迟 I/O 用异步合理。提醒：响应式不是银弹，排障更难；团队不熟时宁可清晰的线程池 + 超时。

Q29. AI 应用里的 Java 线程池应该怎么配？

答： 一般不能照搬普通 CRUD 服务的线程池配置，因为 AI 请求通常更慢、外部依赖更多、结果体积更大。我会先区分 CPU 任务和 I/O 任务，再按调用链路拆线程池，比如检索池、工具池、回调池分开，避免一个慢依赖把整个系统拖死。同时一定要有队列上限、拒绝策略和监控，不然高峰期很容易把内存和下游一起打爆。

Review： 隔离慢依赖是关键。队列有界 + 拒绝策略必须说；否则一次模型抖动打爆整站。

Q30. Java 做 RAG 系统时，通常怎么接向量数据库？

答： 常见做法是把文档切分、向量化、入库这部分做成离线或准实时索引流程，在线查询时由 Java 服务接收问题，做改写、检索、重排和上下文拼装，然后再把结果送给模型。向量数据库本身只是检索层的一部分，真正决定效果的其实是分块、Embedding、过滤条件、重排和上下文组装策略。

Review： 效果在分块/改写/重排，不在库牌子——这句很加分。Java 侧常做在线编排，索引流水线可 Python。

Q31. 如果团队同时有 Java 和 Python， AI 项目怎么分工更合理？

答： 我一般会建议让 Python 负责模型实验、数据清洗、评测脚本、训练微调、原型验证；让 Java 负责企业服务接入、业务编排、权限审计、稳定性治理和正式 API。这样分工的好处是两边都发挥各自优势，既能快速试错，也能稳妥上线。真正成熟的团队通常不是二选一，而是双语言协同。

Review： 分工清晰即可。补接口契约：OpenAPI、评测集归属、谁对线上质量负责。

Q32. Java AI 服务做流式输出时， SSE 和 WebSocket 怎么选？

答： 如果主要是服务端单向往前端持续推送模型生成内容，SSE 通常更轻量，开发和代理层支持也更简单；如果需要真正双向实时通信，比如边说边打断、前端持续上报状态、多人协作会话，WebSocket 更合适。大多数「聊天式 AI 输出」场景其实用 SSE 就够了。

Review： 多数聊天用 SSE 足够。要打断、双向状态再用 WebSocket；还要考虑网关/代理对 SSE 的缓冲与超时。

Q33. 当外部模型服务不稳定时， Java 侧常见的治理手段有哪些？

答： 常见的手段包括超时控制、限流、熔断、隔离、重试、降级和缓存。比如用 Resilience4j 这类组件做熔断和限流，把不同模型供应商隔离到不同资源池里，高风险接口启用备用模型。面试里我会强调一点，AI服务的稳定性不只是模型本身的稳定，而是你对外部不确定性的治理能力。

Review： 清单之外，强调供应商隔离与降级（换模型/简答/人工），稳定性是工程能力不是模型运气。

Q34. Java 做 AI 应用的优势和短板分别是什么？

答： 优势是工程体系成熟，适合复杂业务接入、权限控制、事务边界、监控治理和大型团队协作；短板是新模型、新框架、新论文能力更新通常慢于 Python 生态，很多首发工具也优先支持 Python。所以我会把Java 看成生产集成主场，把 Python 看成模型创新主场。

Review： 优缺点都要说。可落一句：你更擅长哪侧，以及跨语言边界怎么定。

四、Prompt 工程与上下文管理

Q35. 什么是 Prompt Engineering？它解决的核心问题是什么？

答： Prompt Engineering 本质上是在不改模型参数的前提下，通过更好的任务描述、上下文组织、示例提供和输出约束，让模型更稳定地完成任务。它解决的不是「让模型突然变聪明」，而是让模型在当前能力范围内更少跑偏、更贴近业务目标。

Review： 核心是少跑偏，不是变聪明。生产里 Prompt 是带版本的业务逻辑，不是文案游戏。

Q36. System Prompt、User Prompt、Tool Prompt 的职责分别是什么？

答： System Prompt 主要定义模型的长期规则、角色边界和行为约束，相当于高优先级策略。User Prompt 是用户这一轮真正提出的任务。Tool Prompt 或工具描述则是告诉模型某个工具能干什么、输入输出是什么、什么时候该调用。简单说，System 负责原则，User 负责目标，Tool 负责能力边界。

Review： System / User / Tool 三分。Tool 描述质量直接决定误调用率，值得单独迭代。

Q37. 怎么设计一个更稳定的提示词？

答： 我一般会让提示词至少包含这几个部分：任务目标、输入背景、输出格式、边界条件、失败时怎么处理、以及必要的示例。能结构化就尽量结构化，能把模糊词换成可执行规则就尽量换掉。提示词稳定性的关键不是写得「华丽」，而是让模型少猜、多按规则执行。

Review： 结构化 + 可执行规则是关键。补：失败分支与拒答策略；把模糊形容词换成验收标准。

Q38. Few-shot 示例为什么有效？

答： 因为示例相当于给模型做了一个就地校准，让它更明确「这个任务到底要按什么风格和标准回答」。尤其是在标签不明显、格式要求强、边界容易歧义的任务里，Few-shot 往往比单纯增加一句解释更有效。它本质上是在上下文里给模型一个可模仿的目标分布。

Review： Few-shot 像就地校准。提醒：示例占 token、要维护；与 RAG 可互补，别堆十个无关例子。

Q39. 复杂任务里，为什么常说要让模型先分析再作答？

答： 因为很多复杂任务不是知识不会，而是一步出结果时容易遗漏约束。先分析再作答，相当于把问题拆成中间步骤，让模型在过程里对齐目标，准确率通常会更高。不过在线业务里我不一定要求它把完整思考过程都展示给用户，很多时候只需要系统内部用这个策略提高质量，最终对外仍然输出简洁答案。

Review： 内部推理、对外简洁——产品感好。也要说：对简单题强行分步会浪费时延与成本。

Q40. 什么是提示注入（Prompt Injection）？怎么防？

答： 提示注入就是用户输入或外部文档里夹带了「忽略之前规则」「泄露系统提示词」「去执行危险操作」这类恶意指令，试图覆盖系统原本的控制逻辑。防御方式包括分层隔离系统规则、对外部文档做可信度判断、对高风险动作做白名单和人工确认、不要让模型直接拥有无限工具权限。我的理解是，提示注入本质上是LLM 时代的输入安全问题，不能只靠一句「不要被攻击」来解决。

Review： 务必提间接注入：检索文档/网页也可藏指令。防御要工程化：权限、白名单、人审，不靠一句 system。

Q41. 怎样让模型稳定输出结构化 JSON？

答： 第一步是把字段、类型、是否必填定义清楚；第二步是尽量使用 Schema 约束或结构化输出接口，而不是只在自然语言里口头要求；第三步是在落库前做严格校验，发现不合法就重试或兜底。经验上看，越是需要进入下游系统的数据，越不能只相信模型「应该会按格式输出」。

Review： Schema + 校验 + 失败兜底。尽量用官方 structured output，少靠「请输出 JSON」口头约束。

Q42. 长对话场景下，怎么做上下文管理？

答： 我一般不会把全部历史无限累积，而是做分层处理：最近几轮保留原文，中期历史做摘要，长期事实抽成记忆，再结合业务状态做选择性拼接。因为上下文越长不一定越好，反而可能把噪声、旧约束和成本一起带上去。上下文管理的核心是保留「对当前任务真正有用的信息」。

Review： 分层记忆可用。补：摘要会丢约束；成本随上下文涨；「有用」要用业务状态筛选。

Q43. 提示词模板为什么要版本化管理？

答： 因为提示词一旦进入生产环境，本质上就是业务逻辑的一部分。没有版本管理的话，效果变好了还是变差了、线上问题是谁引入的、A/B 测试用的是哪版模板，都会说不清。成熟一点的团队通常会把提示词当配置甚至当代码管理，做到可回滚、可评测、可审计。

Review： Prompt = 业务逻辑，要可回滚。配套回归集，否则一次「优化」可能静默变差。

Q44. 为什么提示词工程不能替代系统工程？

答： 因为很多问题不是提示词能解决的，比如知识过期、权限控制、工具安全、结果校验、成本控制、可观测性、异常恢复。提示词只能优化模型在已有信息和能力下的表现，但不能凭空补齐外部知识和工程约束。真正稳定的 AI 应用，一定是提示词、检索、工具、规则和监控一起工作的结果。

Review： 别只吹提示词。答出权限、检索、监控、校验，才像完整系统。

下一篇见系列导航。若你只想先背高频题，优先：Q6/Q10/Q40/Q45–Q52/Q60/Q65/Q68/Q94/Q100。

下一篇见系列导航。若只想先抓高频：Q6 / Q10 / Q40 / Q45–Q52 / Q60 / Q65 / Q68 / Q94 / Q100。