【自学AI】05 该不该往项目里加AI功能？一文帮你搞懂

模式一：文本理解#

给 AI 一段文字，让它读懂，然后给你一个结论。

比如：

• 这封邮件是垃圾邮件吗？
• 这条评论是好评还是差评？
• 这份简历的候选人是初级还是高级工程师？

AI 在这里扮演的角色，就是一个阅读理解机器。

为什么要用 AI 来读简历，而不是写几条规则？因为简历这东西，格式千奇百怪。有人按时间线写，有人按项目写，有人喜欢堆关键词，有人喜欢讲故事。传统的关键词匹配，碰到”主导了团队完成了一个高并发系统的重构”这种句子，根本不知道这人会不会 Java。

大模型不一样，它能理解上下文，能从一段话里推断出候选人的技术深度和经验层次。

但有个坑要记住：输入质量很关键。简历写得一塌糊涂，AI 也没辙。 垃圾进，垃圾出——这条定律对 AI 同样成立。

模式二：内容生成#

这次不是”读懂”，而是”创造”。

比如：

• 根据职位描述，生成 10 道面试题
• 根据候选人的回答，生成一段评价反馈
• 根据一篇论文摘要，生成 500 字总结

还是拿面试题举例——生成一道好题，AI 需要：

1. 理解这个职位真正考察什么（不只是字面意思）
2. 根据候选人背景调整难度
3. 设计题目梯度，从热身到深入
4. 避免重复，覆盖不同知识点

这些事情，让一个人来做也得花不少时间。AI 能做到，是因为它在训练时见过海量的面试题、技术文档、教学材料，学到了”什么样的题是好题”。

这里有个著名的坑：幻觉（Hallucination）。

AI 有时候会一本正经地生成错误内容。让它写一道关于 HTTP 协议的题，它可能会问你”请解释 HTTP 的 XYZ 特性”——但 HTTP 根本没有 XYZ 这个特性，它是编的。

不是 AI 故意骗你。它的工作原理是”预测最可能的下一个词”，不是”思考事实”。

所以，生成的内容一定要有人审核，尤其是涉及技术细节的部分。这不是不信任 AI，这是工程常识。

模式三：对话推理#

这是最复杂的一种。不是一问一答，而是多轮交互，AI 根据上下文动态调整。

放到面试系统里，就是 AI 面试官的核心逻辑：

• AI 问一道题
• 候选人回答
• AI 根据这个回答判断水平，决定下一题问什么
• 答得好，问更难的；答得一般，换个角度再问

这模仿的是一个真实面试官的思考过程。好的面试官不会照着题单一道道念，而是根据对方的回答随时调整。

这个模式的坑是：容易跑题。

候选人可能突然问”你们公司氛围怎么样？“，没有约束的 AI 可能就顺着聊了，面试变成了聊天。

解决方法是在 System Message 里加护栏：

1
你是一个技术面试官，只讨论和面试相关的内容。
2
如果候选人问无关问题，礼貌拒绝，把话题引回面试。

给 AI 一个清晰的角色定义，它就不会乱跑。

这个道理，学这个项目的时候深有体会——Agent 跑偏，往往不是模型的问题，是你没把边界说清楚。

简历分析 → 模式一（文本理解）#

用户上传简历，系统提取关键信息：技术栈、工作年限、项目经验、大概的级别。

典型的文本理解任务。简历格式再乱，AI 也能读懂。

生成面试题 → 模式二（内容生成）#

根据简历和职位要求，生成一套有梯度的面试题。

比如候选人有秒杀系统经验，职位是后端架构师，AI 生成的题目大概是这样的：

1
第一轮（热身）：
2
1. 介绍一下你做过最复杂的项目
3
2. 遇到过什么性能瓶颈？怎么解决的？
4

5
第二轮（深入）：
6
3. 如何设计一个支持 10 万并发的秒杀系统？
7
4. 数据库和缓存层面怎么优化？
8

9
第三轮（系统设计）：
10
5. 分布式事务怎么处理？
11
6. 网络分区时，如何保证数据一致性？

这不是模板填空，是真正的内容生成。AI 理解了候选人背景，才能出这样有针对性的题。

评估答案 → 模式一 + 推理#

候选人回答了”如何设计秒杀系统”，系统评估这个答案的质量。

AI 要做的事情：

• 理解候选人说了什么
• 判断他是否抓住了核心（比如 Redis 原子操作防超卖）
• 识别遗漏了什么（比如缓存预热、一致性问题）
• 给出评分和反馈

有个主观性问题值得注意：同一个答案，不同面试官可能给出不同分数。AI 也一样，Prompt 不同，评分可能差两三分。所以单题评分只是参考，最终要看多题的综合表现。

生成追问 → 模式三（对话推理）#

根据候选人的回答质量，动态决定下一题问什么。

• 答得好 → 深入追问：“你提到了缓存一致性，具体怎么保证？”
• 答得一般 → 换个角度：“为什么要用 Redis？直接用内存 Map 不行吗？”

每个候选人的面试路径都不一样，这就是对话推理的价值所在。

综合评估报告 → 模式二（内容生成）#

面试结束，系统根据几十轮问答，生成一份完整的评估报告：总分、各维度分析、优缺点、录取建议。

这是 AI 的强项——给它一堆原始数据，让它提炼、总结、组织成可读的报告。

场景一：需要 100% 准确的关键功能#

用户登录验证，绝对不能用 AI。

登录验证只有两种结果：对或错。没有”差不多对”这种情况。

AI 有固有的不确定性，哪怕错误率只有 0.1%，放到 1000 万用户上，就是 1 万次认证失败。不可接受。

正确做法是用确定性的密码验证算法（比如 bcrypt），有数学保证，实现正确就是 100% 准确。

场景二：涉及法律、财务、医疗的决策#

银行放贷、医疗诊断、法律判决——AI 可以辅助，但不能是最终决策者。

原因有两个：

1. AI 的决策有时候不可解释，法律责任没法落实
2. 训练数据里可能有偏见，AI 会无意识地继承这些偏见

合理的流程是：AI 做初步评估 → 人工审核 → 人来做最终决定。

场景三：对延迟极度敏感的场景#

游戏里玩家按下按钮，需要在 16 毫秒内响应。调用 AI API 通常要几秒。慢了几百倍，根本不可能用。

实时逻辑用传统算法，AI 只用在不需要实时响应的部分。

场景四：一行代码能解决的事#

判断用户是不是成年人：

1
return "成年人" if age >= 18 else "未成年人"

这种事情，上 AI 是过度设计。

简单的事情用简单的方法，不要为了用 AI 而用 AI。

学这个项目的时候，有个地方就犯了这个错——想用 AI 来做一件其实两行代码就能搞定的事。结果绕了一大圈，还不如直接写逻辑来得干净。