代码质量与测试

Q：如何解决大模型 API 服务的响应延迟问题？

来源：字节 Agent 实习一面 【小红书数据库智能化二面追问：产品层面的等待体验优化】【小舒一面追问：异步调用与线程阻塞】

新手答：“用更快的模型。”

高手答：

API 服务延迟分两部分：首 token 延迟（TTFT） 和生成吞吐（TPS），优化思路不同。

1. 流式输出（Streaming）——最直接的体感优化：

• 不等全部生成完再返回，逐 token 流式输出。用户感知延迟从“等 10 秒”变成“0.5 秒就开始看到内容”
• SSE（Server-Sent Events）或 WebSocket 实现

2. 模型层面：

• 模型分级调度：简单请求（分类、提取）用小模型（7B/14B），复杂请求（推理、创作）用大模型。80% 的请求可以用小模型处理，延迟降 5-10 倍
• 量化部署：INT4/INT8 量化减少计算量和显存占用，推理速度提升 2-3 倍
• 推测解码：小模型快速生成草稿，大模型批量验证，整体速度提升 2-3 倍

3. 服务架构层面：

• KV Cache 复用：多轮对话中，前几轮的 KV Cache 不需要重算，缓存后复用，TTFT 大幅缩短
• Prefix Caching：共享相同 System Prompt 的请求复用前缀计算结果
• 连续批处理：vLLM/SGLang 的 continuous batching，请求到达即处理，不等凑满一批
• 负载均衡：多实例部署 + 按当前负载智能路由，避免单实例过载

4. 缓存层面：

• 语义缓存：对高频相似请求做语义匹配，命中缓存直接返回，不调模型。适合 FAQ 类场景
• 工具结果缓存：Agent 场景中，工具返回值（天气、股价等）设 TTL 缓存，避免重复调用

5. 产品交互层面：

• 尽早通过 SSE 返回首个可见事件，把“正在检索、已找到 N 条证据、正在生成”作为结构化进度，而不是伪造模型思考过程
• 长任务提供取消、超时后后台继续和结果通知，让用户能在方向错误时尽早终止，减少无效 token 消耗
• 产品层优化不降低真实总耗时，但能降低无反馈等待；必须和后端 TTFT、P95/P99 指标分开评估

6. 调用与任务执行模型：

• 不要让 Web 请求线程用同步 SDK 阻塞等待几十秒的 LLM 调用。在线短请求使用异步客户端、连接池和有界并发，避免请求量上升后线程、连接和内存一起耗尽
• 长任务进入队列或 Job 系统，请求先返回 task_id，结果通过 SSE 推送或轮询获取；生成过程与客户端连接解耦
• 为整条请求和每个模型/工具步骤设置 deadline、超时、取消传播和有限重试，并用幂等键避免重试造成重复副作用

async 不会缩短单次模型推理时间，它解决的是等待期间不占住请求线程，从而保住并发吞吐和取消能力。真正的总耗时仍要靠模型、上下文、并行路径和缓存优化。

差距在哪：新手只想到换模型。高手从流式输出、模型分级、服务架构、缓存、产品交互和任务执行六个层面做了系统优化，且区分了 TTFT、TPS、并发吞吐与用户感知等待。面试官考的是你对大模型服务工程化的理解——延迟优化不只是“模型更快”，而是一个全栈工程问题。

---

Q：AI Coding 产品怎么测试？从 Demo 到生产可交付还差什么？

来源：蚂蚁集团智能体与大模型应用二面

新手答：“写几个 case 测一下就行。”

高手答：

AI Coding 产品的测试和传统软件测试有本质区别——输出是概率性的，同样的输入不一定得到同样的输出，所以不能只靠“写几个 case 通过了就行”。

测试方法论：

1. 构造评估集，不是测几个 case：

• 设计覆盖不同代码复杂度（纯函数 / 有依赖 / 异步 / 并发）和任务类型（生成 / 修复 / 重构 / 解释）的评估集
• 每个 case 要有明确的验收标准：不是“看起来对”，而是能编译、能通过测试、符合代码规范
• 评估集要包含边界和对抗 case：超长文件、语法错误的输入、故意误导的 Prompt

2. 评估维度不只是“对不对”：

维度	指标	说明
正确性	Pass@K、编译通过率	K 次生成中至少一次正确的概率
一致性	同一输入多次生成的方差	输出是否稳定
安全性	有无注入漏洞、敏感信息泄露	生成的代码是否安全
效率	Token 消耗、端到端延迟	成本和速度

从 Demo 到生产可交付，还差什么：

1. 鉴权和权限控制：Demo 不需要考虑谁能用、能操作哪些文件。生产环境必须有用户身份验证和操作权限隔离
2. 错误恢复和回滚：Demo 出错了重来就行。生产环境需要操作日志、变更回滚（类似 git revert）、异常告警
3. 并发和多用户：Demo 是单用户。生产环境要支持多用户同时使用，状态隔离，资源限制
4. 监控和可观测性：生成质量监控、成本监控、异常检测、用户反馈收集——没有这些，线上问题完全是黑盒
5. 安全审计：AI 生成的代码可能引入安全漏洞，生产环境需要自动化安全扫描（SAST/DAST）
6. CI/CD 集成：生成的代码要能自动跑 lint、测试、构建，不能只靠人工 review

差距在哪：新手的“测几个 case”只是验证“能不能跑”。高手从评估集设计、多维度指标、生产化六大能力（鉴权、回滚、并发、监控、安全、CI/CD）展开。面试官考的不是“会不会测试”，而是你对“把 AI 能力做成产品”这件事的完整认知。

---

Q：什么是 SDD（Spec-Driven Development）？它和 Skills 有什么区别？

来源：蚂蚁集团智能体与大模型应用二面

新手答：“SDD 就是先写规格再写代码，Skills 是预定义能力。”

高手答：

SDD（Spec-Driven Development，规格驱动开发）是 AI Coding 领域的一种工作流方法——先让 AI 生成详细的技术规格说明（Spec），人工审核确认后，再让 AI 按照 Spec 生成代码。

SDD 的核心流程：

为什么要这么做：直接让 AI 写代码的问题是——需求理解错了，生成的代码再完美也没用。SDD 把“理解需求”和“写代码”拆开，在理解阶段就做人工确认，避免代码写完才发现方向错了。

SDD vs Skills 的对比：

维度	SDD	Skills
本质	开发工作流方法论	Agent 的可复用能力单元
解决的问题	“怎么让 AI 写出正确的代码”	“怎么让 Agent 处理特定类型的任务”
关注点	需求→规格→代码的转化质量	触发匹配→Prompt→工具→输出的执行流程
人工参与	核心环节（审核 Spec）	可选（配置后自动执行）
适用场景	代码生成、架构设计	任何 Agent 能力扩展
输出物	Spec 文档 + 代码	任务执行结果

两者的关系：不互斥，可以结合。一个“代码生成 Skill”可以内部采用 SDD 流程——Skill 定义了“什么时候触发、用什么工具”，SDD 定义了“触发后按什么步骤生成代码”。

Skills 是能力的封装方式，SDD 是代码生成的质量保障方法。前者回答“Agent 能做什么”，后者回答“怎么做得对”。

差距在哪：新手把两者简单对立。高手看到了它们在不同维度上的定位——SDD 是方法论层面的流程设计，Skills 是系统架构层面的能力封装，两者可以组合使用。面试官考的是你能不能区分“工作流方法”和“系统架构”这两个层次的抽象。

---

Q：如何保证 AI 代码生成的质量与掌控性？

来源：蚂蚁集团 Agent 开发一面

新手答：“生成后人工 review 一下。”

高手答：

人工 review 是最后一道线，但不能是唯一一道。保证质量和掌控性要在生成前、生成中、生成后三个阶段都做控制：

生成前——约束输入，减少出错空间：

1. 上下文精准投喂：给模型完整的类型定义、接口规范、相关测试用例，而不是只给一句需求描述。上下文越精确，生成质量越高
2. 项目规则注入：通过 CLAUDE.md / .cursorrules 定义编码规范（命名风格、错误处理模式、禁用的 API），让模型生成时就遵守项目约定
3. Spec 先行（SDD）：对复杂功能，先让 AI 生成技术规格说明，人工确认后再生成代码。在理解阶段就拦住方向性错误

生成中——约束输出，缩小自由度：

4. Structured Output：函数签名、返回类型、错误码这些关键接口用 schema 约束，不让模型自由发挥
5. 增量生成：不让模型一次生成 500 行。拆成小步——先生成函数骨架、再填充逻辑、再补异常处理，每步可验证
6. Diff 模式：修改已有代码时，要求模型输出精确的 diff 而非整文件重写，减少意外修改

生成后——验证结果，兜住底线：

7. 自动化门禁：生成的代码必须通过类型检查（TypeScript/mypy）、lint、现有测试套件。不过门禁不允许合入
8. AI 自验证：让模型同时生成代码和对应的测试用例，跑通测试才算完成。这不完美，但能抓住明显的逻辑错误
9. 安全扫描：自动检测常见漏洞模式（SQL 注入、XSS、硬编码密钥），AI 生成的代码更容易引入这类问题

掌控性的核心原则：生成的每一步都要有人类可审查的检查点。不是“生成完看一眼”，而是“每个阶段都有明确的验收标准”。

差距在哪：新手只有事后 review 一道防线。高手在生成前（约束输入）、生成中（约束输出）、生成后（自动验证）三个阶段构建了九道防线。面试官考的是你对 AI 代码生成的质量体系有没有工程化的设计。