AI 学习笔记（一）：认知校准

1. 核心思维转变

传统软件工程中，逻辑是确定性的：状态A触发事件A，条件B执行分支B，所有行为都在程序中预设。但 LLM 本质上是在 token 空间做概率采样，这带来了本质差异：

• 非确定性：相同输入可能产生不同输出，无法保证"跑一百次结果一样"
• 幻觉（Hallucination）：模型可能生成看似合理但事实性错误的内容
• 边界模糊：对边界情况的行为难以预测，不像传统程序可以穷举分支

结论：不能再用"写完测试就放心上线"的思路对待 AI 模块，必须建立新的工程防线。

2. 工程应对策略

接入 LLM 的项目，模型输出必须经过多层校验才能进入后续流程。以 AI 英语学习系统为例：

| 校验层 | 目的 | 具体手段 | |--------|------|----------| | 输出格式校验 | 确保结构可用 | JSON Schema 校验、字段完整性检查 | | 内容安全审查 | 过滤有害内容 | 安全分类模型、敏感词过滤、合规检查 | | 业务边界校验 | 防止超出任务范围 | 关键词/意图检测、话题偏离判断 | | 质量评估 | 保证回答质量 | 参考答案相似度打分、语法正确性检查 | | 兜底机制 | 应对失败情况 | 重试策略、降级回复、人工审核兜底 |

原则：模型输出在未经验证之前，应视为不可信数据，与处理外部用户输入的安全态度一致。

3. 如何开发 AI 应用

AI 应用开发需要工程师与 AI 能力协同，而非传统的前后端分工模式：

3.1 角色认知

• 工程师需要理解模型的运行逻辑（token 机制、上下文窗口、采样参数），将业务需求转化为模型能理解的 Prompt 和工作流
• 架构设计需要考虑不确定性：哪里需要校验？哪里需要兜底？哪里需要人工介入？

3.2 开发流程

1. 需求拆解 — 明确哪些环节由模型处理，哪些由规则引擎处理，划分确定性边界
2. Prompt 设计与迭代 — 将业务逻辑转化为结构化 Prompt，建立评测数据集，量化评估效果
3. 防护层建设 — 在模型输入前后建立校验、过滤、兜底机制
4. 监控与反馈 — 上线后持续监控模型输出质量，收集 bad case 驱动迭代
5. 文档化 — 将 Prompt 版本、评测结果、边界情况记录为可维护的工程文档

3.3 关键思维

把模型当作一个能力很强但不可预测的外部服务来设计架构——就像你会为第三方 API 做超时处理、降级策略和数据校验一样，模型也需要同等级别的工程防护。