docs/interview-prep.md

面试准备指南 — Codev / Claude Code 架构知识体系

适用场景: 系统设计面试、技术深挖面试、架构师/高级工程师面试 目标: 覆盖 AI CLI 代理的核心设计决策、权衡、以及可以引申到通用分布式系统的知识点

---

1. 项目概述 (30-second pitch)

Codev 是什么?

Codev 是从 Anthropic Claude Code fork 出来的 AI CLI 代理 (Agentic Coding Assistant)，运行在终端中，核心能力是理解自然语言开发指令并自动执行多步骤编码任务。

三个核心差异化:

1. 多 Provider 支持 — 不锁定 Anthropic API，可接入 OpenAI、NVIDIA NIM、opencode、vLLM 等第三方 LLM Provider
2. VRM 桌面伴侣 (Friend) — 带 3D 虚拟角色 (VRM 模型)、情感表情、语音对话能力的同进程桌宠系统
3. 语音对话 — 实时语音输入 (WASM VAD) + STT/TTS，支持端到端语音编程交互

一句话概括:

"一个带 3D 桌宠的 AI 编程助手 CLI"

---

2. 核心架构问答 (Q&A format)

---

Q: 解释 Agent Loop (代理主循环) 的工作原理

Agent Loop 是整个系统的核心, 实现在 src/agent/agent-loop.ts, 约 88 行核心逻辑, 是一个 async generator。

5 阶段循环:

[Pre-model Shaping] → [Model Invocation] → [Tool Execution] → [Stop Hooks] → [Continuation Decision]
                                                                                    │
                                                                              ┌─────┘
                                                                              ▼
                                                                        回到 [Pre-model Shaping]

1. Pre-model Shaping — 处理 Hook, 注入系统提示词, 计算预算, 决定是否触发压缩 (compact)
2. Model Invocation — 调用 LLM, 处理 API 错误和重试逻辑
3. Tool Execution — 执行 LLM 返回的工具调用, 收集结果
4. Stop Hooks — 处理 Stop 状态 (token 耗尽、tool_use、end_turn、max_tokens)
5. Continuation Decision — 决定是否继续循环

关键数字:

• queryLoop() 核心逻辑 ~88 行
• 周边基础设施 (工具注册、权限检查、压缩管道、预算跟踪等) 构成 98.4% 的代码量
• 仅 1.6% 是 AI 决策逻辑 (LLM 调用)

关键特征:

• 追加式状态 (Append-only JSONL) — 所有消息追加到消息列表, 永不修改历史, 保证可恢复性
• 恢复机制 (Resilience) — max_output_tokens 耗尽时自动重试 3 次, token 限额从 8K 自动升级到 64K
• 预算跟踪 (Budget Tracking) — 每次迭代跟踪输入/输出 token, 超出预算时触发 Reactive Compact

---

Q: 描述权限系统的 7 种模式和防御纵深

7 种权限模式 (安全光谱从严格到宽松):

模式	行为	适用场景
default	每次工具调用都询问用户	默认/安全模式
acceptEdits	自动批准编辑类工具, 其余询问	开发日常
plan	仅允许读操作, 拒绝写操作	探索/设计阶段
auto	ML 分类器自动决策	有经验的开发者
bypassPermissions	完全绕过权限检查	调试/开发
dontAsk	静默拒绝所有非白名单工具	受限环境
bubble	权限检查冒泡到父进程	CI/CD 集成

4 层防御纵深:

Layer 1: Pre-filtering (Deny Rules)
  → 在权限系统外先做 deny 规则匹配, 如 `--dangerously-skip-permissions`
    会直接跳过某些工具的白名单检查

Layer 2: Hooks
  → 用户自定义 hook, 在权限检查前后注入逻辑
  → 可实现自定义审批流程 (如通知 Slack)

Layer 3: Rule Evaluation
  → 工具级别的 allow/deny 规则
  → 基于工具名称、参数、文件路径的正则匹配

Layer 4: Permission Handler
  → 最终决策层, 根据 mode 决定是否向用户显示提示

Auto Mode 的 ML 分类器:

• 两阶段分类: 先判断工具类别 (Read vs Action), 再决定自动批准/询问
• 官方报告的 FNR (假阴性率) 约 17% — 即 17% 本该自动批准的操作被错误地询问用户
• 渐进信任机制: 系统跟踪用户的 auto-approve rate, 从初期 ~20% 增长到熟练用户的 40%+

核心设计原则:

• Deny-first: 任何未明确允许的操作都被拒绝
• 渐进信任: 用户必须主动证明可靠性才能获得更多自主权

---

Q: 上下文压缩的 5 层管道是什么?

上下文窗口有限, 每次消息增长都需要压缩。压缩管道在 src/agent/compact.ts 实现。

5 层压缩管道 (按触发顺序):

Layer 1: Budget Reduction (预算削减)
  → 截断超出预算的历史消息
  → 优先丢弃旧消息, 保留最近的工具调用结果
  → 触发条件: 总 token 超过 budget

Layer 2: Snip (低价值裁剪)
  → 移除低价值消息
  → 判断标准: 工具输出是否为错误/空/重复
  → 保留工具调用本身但删除冗余输出

Layer 3: Micro-compact (微压缩)
  → 对单条消息做摘要
  → 使用 "Condense" 工具让 LLM 对长输出做一句话总结
  → 保留原始消息的语义但大幅缩减 token

Layer 4: Context Collapse (上下文折叠)
  → 折叠多轮交互
  → 将多轮 tool_use + tool_result 对合并为一段摘要
  → 保留最终状态但丢失中间过程

Layer 5: Auto-compact (自动摘要)
  → 完整语义摘要
  → 使用 LLM 对整个对话历史执行摘要
  → 最激进, 丢失信息最多, 但 token 节省最大

核心权衡:

Context Efficiency (节省 token, 降低成本, 减少超预算风险)
    vs
Transparency (丢失细节, LLM 可能遗忘关键上下文)

补充机制:

• Reactive Compact: 当 LLM 回复 max_tokens 截断时自动触发压缩重试
• JSONL 持久化: 压缩只影响发送给 LLM 的上下文, 原始 JSONL 日志完整保留

---

Q: 多 Provider 架构如何实现?

Codev 支持多种 LLM Provider, 架构分为两层:

Tier 1: Anthropic 原生通道

• 直接使用 Anthropic SDK
• 支持 Bedrock、Vertex AI、Foundry 三种部署方式
• 不需要协议转换, 性能最优

Tier 2: 第三方 Provider 通道

• 使用 Fetch Override 模式: 拦截 globalThis.fetch 方法
• 将 Anthropic Messages API 请求重写到目标 Provider 的 API 格式
• 协议转换: Anthropic Messages ↔ OpenAI Chat/Responses API

Fetch Override 的工作原理:

原始调用: client.messages.create({model, messages, tools})
    → SDK 内部调用 fetch("https://api.anthropic.com/v1/messages", body)
    → 被 override 拦截
    → 转换 body 格式 (Anthropic → OpenAI)
    → 发送到目标 Provider (如 https://api.openai.com/v1/chat/completions)
    → 转换 response 格式 (OpenAI → Anthropic)
    → 返回给 SDK

模型列表管理:

• modelStrings() 缓存所有可用模型
• Provider 切换后必须调用 clearModelStrings() 清除缓存
• 模型信息包括: Provider 名、模型 ID、上下文窗口、价格、速率限制

为什么用 Fetch Override 而不是独立 SDK?

1. 保持统一的 Anthropic Messages 接口, 不需要为每个 Provider 写独立适配
2. Fetch Override 是无侵入的: 所有依赖 Anthropic SDK 的代码无需修改
3. 对用户透明: 用户配置 Provider 后, 体验完全一致

---

Q: Friend VRM 系统为什么设计为同进程 + SSE?

Friend 是 Codev 的 3D 桌面伴侣系统, 使用 VRM 模型 (3D 虚拟角色), 具备表情、动作、语音对话能力。

架构选择:

同进程 (In-process)
  └── Agent 直接调用 messageQueueManager.enqueue()
  └── VRM 渲染在独立窗口 (WebKitGTK)
  └── SSE 从 Agent 进程推到 VRM 窗口

vs 微服务 (Microservices)
  └── 需要 IPC/进程间通信
  └── 额外的 HTTP Server 部署
  └── 开发、调试复杂度高

选择同进程的原因:

1. 不需要 IPC/进程间通信 — 直接调用 messageQueueManager.enqueue() 即可推送消息
2. 低延迟 — 同进程调用延迟 <1ms, IPC 至少 1-10ms
3. 简化部署 — 用户只需要启动一个二进制文件
4. 状态共享 — Agent 的上下文、配置、日志直接可访问

选择 SSE (Server-Sent Events) 而不是 WebSocket 的原因:

维度	SSE	WebSocket
通信方向	Server → Client 单向	双向
协议	HTTP (简单)	WS (复杂, 需要握手机制)
适用场景	LLM → VRM 广播 (推送表情/动作指令)	双向实时通信
浏览器支持	EventSource API	WebSocket API
自动重连	原生支持	需手动实现

• 核心原因: VRM 系统的主要通信模式是 Agent → VRM 的单向推送 (LLM 决定表情 → 推送到 VRM 渲染), 不存在 VRM → Agent 的实时控制需求, 因此 SSE 完全足够, 且比 WebSocket 更轻量

WASM VAD 的选择:

• 使用 Silero VAD 的 WASM 编译版本
• 原因: 避免 onnxruntime-node 在 Bun 运行时下的 segfault (Bun 的 napi 兼容性问题)
• WASM 运行在 WebView 沙箱中, 更稳定

服务端采音 (Server-side Audio Capture):

• 不依赖浏览器 getUserMedia API
• 避免 WebKitGTK 的权限弹窗问题
• 使用 PulseAudio/ALSA 直接在服务端录制麦克风

---

Q: Feature Flag 系统如何实现死代码消除?

Codev 使用编译时 Feature Flag 系统, 实现 #ifdef 风格的死代码消除。

实现位置: src/feature/feature.ts / feature() 函数

工作原理:

编译时: Bun build --define 注入常量值

if (feature("VOICE_MODE")) {
    // 注册语音工具
    registerVoiceTools();
} else {
    // 这段代码在编译时被消除
    // 不产生任何字节码
}

Bun 编译器的支持:

• Bun 的 feature() 函数在编译时做 if/ternary 位置的静态分析
• 当 feature 为 false 时, 整个分支被 DCE (Dead Code Elimination)
• 最终二进制中完全不包含被禁用的功能代码

编译标志:

• 命令行: --feature=VOICE_MODE (编译时启用)
• 环境变量: FEATURE_VOICE_MODE=1 (开发时启用)
• 两者效果等价

Feature 统计:

• 总共 48 个实验性 feature
• 默认仅 VOICE_MODE 启用
• 其他 feature 如: ANTHROPIC_BRAZIL, BYPASS_PERMISSIONS, ORGANIZATION_CODE, TOOLTIP 等

用户类型门控:

• USER_TYPE='ant' → Anthropic 内部员工, 解锁内部工具和功能
• USER_TYPE='external' → 外部用户, 仅暴露稳定的公共功能
• 在编译时通过 feature() 检查, 用户类型相关的内部代码完全不会出现在外部构建中

---

Q: 错误恢复策略有哪些?

一个多层级、渐进式的错误恢复系统:

1. max_output_tokens 恢复
   └── LLM 输出被截断 (max_tokens 耗尽)
   └── 自动升级 token 限额: 8K → 16K → 32K → 64K
   └── 最多重试 3 次, 之后不再尝试

2. 流式回退 (Streaming Fallback)
   └── SSE 流式连接中断
   └── 自动回退到非流式 (non-streaming) 模式
   └── 用户感知: 延迟增加但可用

3. Reactive Compact (响应式压缩)
   └── LLM 回复被 max_tokens 截断
   └── 触发自动压缩管道, 压缩上下文
   └── 然后重试请求

4. 工具执行重试
   └── 工具调用失败 (网络错误、文件权限等)
   └── 最多重试 3 次
   └── 指数退避 (100ms, 200ms, 400ms)

5. API Fallback Provider
   └── 当前 Provider 不可用 (429/5xx)
   └── 自动切换到下一个配置的 Provider
   └── 配置在 environment.json 中

核心原则: 3 次重试后不再尝试 — 避免无限重试的资源浪费和用户等待。

---

3. 系统设计面试题

---

设计一个 AI 编程助手的权限系统

需求分析:

• AI Agent 可以执行文件读写、命令执行、网络请求等敏感操作
• 用户需要控制 Agent 的能力范围
• 不同用户有不同的风险和信任水平
• 需要有审计和回溯能力

方案设计 (参考 Codev):

权限光谱: default → acceptEdits → plan → auto → bypassPermissions → dontAsk → bubble

防御纵深:
  Layer 1: Deny Rules (静态规则)
    └── 基于文件名/路径/工具名的正则匹配
    └── 如: 拒绝所有 /etc/shadow 的读写

  Layer 2: Permission Hooks (自定义逻辑)
    └── 用户可注入 $HOME/.claude/settings.json 中的钩子
    └── 如: 检查 git status 后才允许 git commit

  Layer 3: Mode-based Decision (模式决策)
    └── 根据当前 mode 决定审批流程
    └── auto mode 走 ML 分类器, default mode 询问用户

  Layer 4: ML Classifier (自动分类)
    └── 两阶段: Read vs Action
    └── 特征: 工具名、参数路径、文件类型、操作频率
    └── 输出: allow / ask / deny

  Layer 5: Execution Sandbox (执行沙箱)
    └── 工具执行在受限环境
    └── 不允许绕过操作系统权限

面试讨论要点:

1. 17% FNR 意味着什么? 每 6 个操作就有 1 个被错误询问用户, 累积使用会造成显著的摩擦。改进方向: 用户反馈闭环、个性化模型微调、规则叠加 ML 的混合系统。

2. 安全 vs 体验的平衡: 太严格的权限系统用户会绕过 (直接终端操作), 太宽松的系统有安全风险。渐进信任是核心思路。

3. 审计与追溯: 所有权限决策写 JSONL 日志, 支持后续分析。

---

设计一个实时语音聊天系统 (类似 Friend F2)

需求分析:

• 用户通过语音与 AI Agent 对话
• AI 回复也通过语音播放
• 需要低延迟 (实时感)
• 3D 虚拟角色根据对话内容做表情和动作

架构选择: 同进程 vs 微服务

方案 A: 同进程 (Codev 的选择)
  ┌─────────────────────────────┐
  │  Agent Process              │
  │  ┌──────┐  ┌──────────────┐ │
  │  │ LLM  │  │ Audio Engine │ │
  │  │ Call │→│ STT → VAD    │ │
  │  └──────┘  │ TTS → Mixer │ │
  │            └──────────────┘ │
  │  ┌────────────────────────┐ │
  │  │ VRM (3D Avatar)       │ │
  │  │ SSE ← Emotion Queue   │ │
  │  └────────────────────────┘ │
  └─────────────────────────────┘

方案 B: 微服务
  ┌─────────┐   ┌─────────┐   ┌─────────┐
  │  Agent  │──▶│  Audio  │──▶│   VRM   │
  │ Service │   │ Service │   │ Service │
  └─────────┘   └─────────┘   └─────────┘

VAD (Voice Activity Detection) 策略:

• Silero ML VAD (WASM): 深度学习模型, 准确率高, 能区分人声和环境噪音
• Energy-based VAD (备选): 基于音量的简单检测, 适合信噪比高的环境
• 回声消除: 播放 AI 回复时关闭 VAD/采音, 避免识别到 AI 自己的声音

静音策略:

• AI 处理期间: 全程阻断采音 (Press-to-mute)
• 用户说完后: VAD 检测到静音 → 触发 LLM 调用
• LLM 回复时: 音频输出独占, 不接收新输入

Provider 切换:

• STT: Whisper (本地) / Azure Speech / Google STT
• TTS: Piper TTS (本地) / ElevenLabs / Azure TTS
• 可热切换, 无需重启 Agent

面试追问:

1. 为什么不用 WebSocket 而是 SSE? — 因为 VRM 的主要通信是单向推送 (Agent → Avatar), SSE 更轻量, 原生支持自动重连。WebSocket 的额外开销 (握手机制、帧协议) 在单向场景下是过度设计。

2. 为什么不用 onnxruntime-node? — Bun 运行时对 napi 的兼容性问题, 导致 segfault。WASM 在 WebView 沙箱中运行更稳定。

---

设计多 Provider LLM 代理

需求分析:

• 支持多种 LLM Provider (Anthropic, OpenAI, NVIDIA, opencode, vLLM)
• 统一的接口, 对用户透明
• Provider 切换不影响 Agent 状态
• 优雅降级 (Provider 不可用时自动切换)

方案对比:

方案 A: Fetch Override (Codev 选型)
  优点:
    - 无侵入: 不修改 SDK, 不修改 Agent 核心逻辑
    - 统一接口: 所有代码只认识 Anthropic Messages 格式
    - 易于扩展: 新增 Provider 只需要写协议转换层
  缺点:
    - 依赖 fetch API 的完整性
    - 调试复杂 (请求经过转换层)
    - 无法利用 SDK 原生功能 (如 streaming 的细节)

方案 B: Proxy 模式
  优点:
    - 请求在中间层转换, 客户端 SDK 无需修改
    - 可以添加缓存、限流、日志
  缺点:
    - 需要额外部署 Proxy 服务
    - 增加网络延迟

协议转换 (Anthropic ↔ OpenAI):

Anthropic Messages → OpenAI Chat/Responses API

关键映射:
  system:          system_message
  messages:        messages (角色映射: assistant/assistant, user/user)
  tools:           tools (function calling 格式)
  tool_use:        tool_calls
  tool_result:     tool (function response)
  max_tokens:      max_tokens
  stop_sequences:  stop

OpenAI → Anthropic 逆映射同理

模型列表管理:

• modelStrings() 函数缓存所有可用模型的元数据
• 缓存包括: Provider、模型 ID、上下文窗口、价格信息
• Provider 切换时必须调用 clearModelStrings() 清除缓存
• 缓存预热: 启动时异步加载所有 Provider 的模型列表

面试追问:

1. 为什么用 Fetch Override 而不是独立 SDK? — 对现有代码的侵入最小化。所有依赖 Anthropic SDK 的代码 (包括第三方库) 无需任何修改即可支持新 Provider。

2. 如何处理 Provider 特有的能力? — 有些 Provider 不支持 tool use 或 streaming, Fetch Override 层需要做降级处理。

---

4. 架构权衡 (Trade-offs)

---

Safety vs. Autonomy (安全 vs 自主性)

安全优先                   自主性优先
  │                          │
  │                          │
  └── default ─ auto ─ bypassPermissions ──┐
                                           │
  更多权限提示              更少摩擦, 更多风险
  更安全                    更高效

• 37signals 二分法: 权限提示是摩擦, 但也是安全护栏
• Codev 的答案: 渐进信任 + 4 层防御 + ML 辅助
• 面试价值: 展示对安全架构和 UX 权衡的深度理解

---

Context Efficiency vs. Transparency (上下文效率 vs 透明度)

节省 token, 降低成本           保留完整上下文
  │                              │
  │                              │
  └── budget reduction ─ auto-compact ──┐
                                       │
  更便宜的调用                  LLM "记住" 更多细节
  更快响应                     更高质量的推理
  但可能丢失关键信息           但 token 成本更高

• Codev 的答案: 5 层压缩管道 + JSONL 持久化 + Append-only 日志
• 关键洞察: 压缩丢弃的是"发送给 LLM 的内容", 不是"系统记录的内容"
• 面试价值: 展示对 LLM 上下文窗口限制的实际工程理解

---

Simplicity vs. Extensibility (简单性 vs 可扩展性)

Agent Loop 简单 (~88 行)    扩展机制丰富
  │                              │
  │                              │
  └── MCP ─ Plugin ─ Skill ─ Hook ──┐
                                    │
  核心逻辑易于理解             4 种不同的扩展点
  但扩展需要理解多套机制       灵活但复杂度分散

• 4 种扩展机制:

  1. MCP (Model Context Protocol): 外部工具和资源, 标准化协议
  2. Plugin: 内部插件系统, 可注册新工具和事件监听
  3. Skill: 可组合的预定义工作流 (如 /review-pr, /commit)
  4. Hook: settings.json 配置, 在事件前后注入用户定义逻辑

• 面试价值: 展示对"保持核心简单, 外围可扩展"架构哲学的理解

---

同进程 vs 微服务 (Friend 系统的选择)

同进程                          微服务
  │                              │
  │                              │
  └── 低延迟 ─ 简单部署 ─ 状态共享 ──┐
                                    │
  适合单用户桌面应用           适合多租户/云端
  不需要分布式能力             但部署复杂
  开发效率高                   但调试困难

• Codev 的答案: 同进程, 因为这是一个单用户终端工具, 不是分布式系统
• 何时应该选微服务? 多用户 Web 服务、需要独立扩缩容、团队分工明确
• 面试价值: 展示架构选型不是技术炫耀, 而是根据实际场景做合理决策

---

5. 关键数据

指标	数值	说明
代码量	~512K 行 TypeScript	比 Claude Code 原始 fork 增加约 30%
文件数	~1,900	模块化程度高
测试	55 文件, ~22K 行	覆盖率低, 无 CI/CD
构建产物	192-202MB 编译二进制	包含 Bun runtime + JS bundle
JS Bundle	~20MB	除去 Bun runtime 后的纯 JS
Feature Flags	48 个实验性 feature	默认仅 VOICE_MODE 启用
权限模式	7 种	default → bubble
压缩管道	5 层	Budget Reduction → Auto-compact
扩展机制	4 种	MCP / Plugin / Skill / Hook
AI 工具	~60+	文件操作、Shell 执行、搜索等
Slash 命令	~75+	/commit, /review-pr, /clear 等
OpenTelemetry	~5K 行基础设施	OSS 构建中全部 stub
VAD 模型	WASM Silero VAD	在 WebView 沙箱中运行
3D 渲染	WebKitGTK + Three.js	VRM 模型渲染

---

6. 常见面试追问

"为什么不直接用 Vector DB 做记忆?"

答案: Memdir 文件系统优先, LLM 选择检索。

• Vector DB 引入额外的运维复杂度 (需要部署、索引、备份)
• 文件系统 (Memdir) 更简单、可审计、可编辑
• LLM 自己决定检索什么: 不是系统自动做 RAG, 而是通过 Read 工具让 LLM 按需读取 memdir 文件
• 适用场景: 单用户桌面工具, 不需要多租户的向量检索

"为什么 Agent Loop 这么短?"

答案: 确定性基础设施在周围, 不是在里面。

• 88 行核心循环只做"编排" (orchestration), 不做"实现"
• 工具注册、权限检查、压缩、预算跟踪等逻辑被拆到各自的模块
• 这是策略模式 (Strategy Pattern) 的体现: 主循环是稳定的骨架, 各个阶段的行为通过依赖注入可配置

"SSE 和 WebSocket 怎么选?"

答案: 看通信方向。

场景	推荐	原因
Server → Client 单向推送	SSE	更轻量, 原生重连, HTTP 友好
双向实时通信	WebSocket	全双工, 低延迟
浏览器 → Server 流式上传	WebSocket	SSE 只支持下行

Friend VRM 的场景是 Agent → Avatar 的单向广播, SSE 是最优解。如果未来需要 Avatar → Agent 的控制 (如用户点击 VRM 触发动作), 那才需要 WebSocket。

"为什么不用 onnxruntime-node?"

答案: Bun 的 napi 兼容性问题。

• onnxruntime-node 依赖 Node.js 的 napi (Native API), Bun 的实现在某些版本存在 segfault
• WASM 版本在 WebView 沙箱中运行, 稳定性更好
• 这不是架构决策, 是运行时兼容性的务实现实

"Compaction 丢失信息怎么办?"

答案: JSONL 持久化, append-only 日志。

• 压缩只影响"发送给 LLM 的上下文", 不影响"系统记录的数据"
• 所有原始消息追加到 JSONL 文件, 永不删除
• 如果 LLM 需要回看被压缩的内容, 可以通过 Read 工具读取 JSONL 日志
• 这也是为什么压缩管道有 5 层: 渐进式压缩, 先丢最不重要的, 最后才做语义摘要

"如何测试一个 AI Agent 系统?"

答案: 测试 AI Agent 的挑战和策略。

• 黄金数据集: 录制真实的 Agent 交互 (JSONL), 用作回归测试
• Tool 模拟: Mock 工具执行结果, 测试 LLM 的决策逻辑
• 快照测试: 对比压缩/权限决策的输出快照
• E2E 测试: 实际调用 LLM (成本高, 运行慢), 只在关键路径使用
• 当前状态: 55 个测试文件, ~22K 行, 但无 CI/CD — 这是需要改进的地方

"这个系统的最大弱点是什么?"

诚实回答 (面试加分项):

1. 测试覆盖不足 — 无 CI/CD, 55 个测试文件对 ~512K 行代码几乎不可靠
2. Monorepo 膨胀 — ~1,900 文件, 构建产物 200MB, 模块边界模糊
3. ML 分类器的 17% FNR — 虽然可以接受, 但累积使用会造成显著摩擦
4. 同进程限制扩展 — Friend 系统无法独立部署, 难以支持多实例
5. 依赖 Bun 生态 — Bun 的稳定性影响整个系统 (napi 问题, undici fetch 兼容性等)

---

附录: 面试应答策略

当被问到不熟悉的问题时

• "这个问题我没有直接经验, 但基于我对系统的理解, 我会这样分析..."
• STAR 法则: Situation → Task → Action → Result
• 始终展示架构思维: 不管多小的功能, 都能讨论 trade-off

描述项目的三种粒度

30 秒: "一个带 3D 桌宠的 AI 编程助手 CLI"
 2 分钟: "Codev 是从 Claude Code fork 的 AI CLI 代理,
          核心增强是多 Provider 支持和 VRM 桌面伴侣,
          采用同进程 + SSE 架构实现低延迟语音对话"
10 分钟: 深入 Agent Loop、权限系统、压缩管道、Friend 架构

把 Codev 经验映射到通用系统设计

Codev 概念	通用系统设计概念
Agent Loop	Event-driven orchestration
4 层防御纵深	Defense in depth
5 层压缩管道	Multi-stage data processing pipeline
Append-only JSONL	Event sourcing / Write-ahead log
Feature Flag 死代码消除	Compile-time configuration
Fetch Override	API Gateway / Proxy pattern
Provider 切换	Circuit breaker / Fallback
渐进信任	Zero-trust architecture (gradual)
同进程 Friend	Embedded system / Co-located deployment
SSE 推送	Publisher-Subscriber pattern (one-way)

---

最后更新: 2026-06-22 基于 Codev main branch (commit 835ff5a)