AI 工程化 / Agent / Dify 高频追问
1. 你不是算法工程师，为什么能面 AI 后端？
推荐回答
因为 AI 后端不等于训练模型。 我的强项在于把 AI 能力服务化接到业务系统里，并把上下文、超时、重试、日志、降级、工作流和多服务联调治理好。 这部分其实很接近我过去做复杂业务系统落地的优势。
2. 你理解的 AI 工程化最核心是什么？
推荐回答
最核心不是把模型调通，而是把模型从 demo 变成可用服务：
- 契约清楚
- 调用稳定
- 输出可控
- 日志可查
- 版本可灰度
- 出问题能回滚
3. Agent 和普通 Prompt 调用最大区别是什么？
推荐回答
普通 Prompt 更像一次性调用，Agent 是一个带目标、步骤、工具和结果校验的工作流系统。 所以 Agent 真正难的不是“调模型”，而是上下文、工具和可控性。
4. 你为什么说 Agent 不是一个脚本？
推荐回答
因为真正的 Agent 至少要有：
- 目标
- 上下文
- 任务拆解
- 工具调用
- 结果验证
- 反馈修正
如果只是“调一次模型 + 调一个接口”，那更像脚本自动化，不太像 Agent。
5. Dify 适合什么，不适合什么？
推荐回答
Dify 很适合：
- 工作流原型
- Prompt 编排
- 知识问答
- Agent 原型
但它不适合替代复杂后端主系统。 强状态、强事务、深度定制的核心链路，最终还是要回到后端服务体系。
6. 你在研发流程里怎么用 AI？
推荐回答
我更常用在：
- 需求拆解
- 代码理解
- 测试点生成
- 文档整理
- 排错路径归纳
- 多服务联调清单生成
我不会把它当成自动写完整业务的工具，而是当成效率放大器。
7. 多服务需求里，AI 真正怎么帮到你？
推荐回答
它最有价值的地方是帮助我更快整理上下文和边界。 比如涉及多个服务时，我会先让 AI 或 Agent 帮我整理服务职责、接口契约、测试矩阵和风险点，这样联调时更容易统一认知。
8. RAG 真正难在哪里？
推荐回答
不是接一个向量库，而是：
- 知识切片
- 召回质量
- 重排
- 上下文控制
- 引用和幻觉治理
RAG 的问题更多是知识治理问题，不是简单模型问题。
9. 如果模型输出不稳定，你怎么处理？
推荐回答
我会从三层看：
- Prompt 和上下文是否稳定
- 模型调用层是否需要超时、重试、降级和缓存
- 结果层是否做格式校验和 badcase 回流
AI 服务不能只看“能不能返回”，还要看“返回得稳不稳、可不可控”。
10. 技术总监如果问“你是不是在蹭 AI 热点”，你怎么答？
推荐回答
我不会把自己讲成训练模型的人，也不会把 AI 当标签。 我更明确的是，我过去做复杂业务和多服务链路的经验，正好能迁移到 AI 能力的服务化接入、工作流编排和工程治理上。这块对后端其实是很自然的延伸，不是硬蹭。