![AgentGuide Logo](data:image/svg+xml,%3Csvg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100"%3E%3Ctext y=".9em" font-size="90"%3E🤖%3C/text%3E%3C/svg%3E)
📚进度:0/670%
STAR 法则 / 面试话术 彻底备战手册
本手册定位：面向 AI Agent 求职与面试准备的专题复习资料，用于补充 AgentGuide 面试题库与项目讲述材料。 内容以公开资料、项目复盘和工程实践方法论为基础做二次整理，建议结合自己的真实项目经历进行取舍与改写。
目标：把每个项目变成面试官无法拒绝的故事，把被动答辩转化为主动引导
使用建议：这份文档对应《面试备战手册_补充模块.md》的第六节 STAR 法则。综合吸收：
LLM_Agent_RL_面试题库：78KB 完整题库，A-L 共 12 节，含 5 组连环炮模拟 + 3 条主动引导技巧- 补充模块第六节：GoAfar / KTClaw / TinyClaw 的 STAR 模板
- 前 13 份 answer 手册的全部技术内容
这份文档和前面 13 份不同——它不是知识手册，是表演脚本。每一段话术都经过设计：什么时候埋点、什么时候收尾闭环、什么时候用数字代替感觉。
一、核心框架：项目闭环六步法
面试官真正考察的不是你"做了什么"，而是你"为什么做、怎么做决策、怎么验证、怎么衡量价值"。
为什么要做？→ 不做会怎样？→ 为什么选这个方法？→ 为什么不是其他方法？
→ 怎么验证真的有效？→ 为什么收益能真正落到业务上？任何项目介绍，必须覆盖这六步中的至少四步。只讲"我用了 XX 技术"是 5 分回答，讲"因为 YY 约束所以我选了 XX，验证后发现 ZZ，折算业务价值 WW"才是 9 分回答。
STAR 映射
| STAR | 对应六步法 | 占比 | 常见错误 |
|---|---|---|---|
| Situation | 为什么要做 + 不做会怎样 | 15% | 背景太长，没量化问题规模 |
| Task | 怎么定义成功 | 10% | "老板让我做的"——直接扣分 |
| Action | 为什么选这个方法 + 为什么不是其他 | 40% | 只讲做了什么，不讲为什么不做替代方案 |
| Result | 怎么验证 + 业务收益 | 35% | 只报技术指标不报业务指标；没讲护栏指标 |
二、GoAfar 项目 STAR 完整话术
2.1 30 秒版本（电梯演讲）
"GoAfar 解决的是 LLM 在约束优化任务上的推理不可验证问题。传统做法用 DPO 训练偏好，但偏好是主观的。我选择用 OR-Tools VRPTW 求解器作为确定性 verifier，把路线规划的硬约束验证直接做成 GRPO 的奖励信号。这叫 RLVR——可验证奖励强化学习。最终在 1,754 条 GRPO 训练数据上，路线可行性从基线的 67% 提升到了 94%。"
设计的埋点："确定性 verifier"、"RLVR"、"为什么不是 DPO"、"67%→94%"
2.2 2 分钟版本（标准项目介绍）
Situation：GoAfar 是一个 POI 路线规划 Agent。用户给多个地点和时间约束，Agent 要规划最优路线。核心痛点是——LLM 生成的路线经常不满足时间窗约束，比如让用户在餐厅关门前 5 分钟才到达。传统方案是用 GPT-4 做教师模型生成"正确"轨迹，然后用 DPO 训练。但问题是：GPT-4 自己的路线也经常不可行，教师模型自己都在犯错。
Task：我定义的成功标准是一级指标"路线可行性"——用 OR-Tools 求解器验证路线是否满足所有硬约束。目标从基线的 67% 提到 90% 以上。
Action：我选择 GRPO + RLVR 而不是 DPO。原因是——这个场景有天然的确定性 verifier，不需要训练 reward model。对每个 prompt 采样 8 条路线，用 OR-Tools 逐条验证，组内归一化后做 GRPO 更新。数据 pipeline 是：127,978 条 POI + 38,580 条用户行为 → GPT-4o 教师 Agent 生成纠错轨迹 → 格式+语义+OR-Tools 三层过滤 → SFT 1,774 条 → DPO 300 对 → GRPO 1,754 条。
Result：路线可行性从 67% → 94%。关键消融：去掉 OR-Tools 验证层，只用 LLM-as-judge，可行性只能到 78%。这说明确定性 verifier 贡献了 16 个点的增量。如果直接用 DPO 而不用 GRPO，可行性停在 85%。
设计的埋点："为什么不是 DPO"、"三层过滤"、"消融实验"、"如果直接用 DPO 会怎样"
2.3 高频追问及回答
Q: 为什么用 GRPO 而不是 PPO？
"三个原因。第一，任务有可验证奖励——OR-Tools 求解器是确定性的，不需要训练 critic model 来估计 value。GRPO 通过组内归一化奖励直接替代 value baseline，省掉了 critic 的显存和训练成本。第二，PPO 需要同时维护 policy、reference、critic、reward 四份模型，GRPO 只需要 policy + reference 两份。第三，在可验证奖励场景下，奖励方差天然大——同一 prompt 的 8 条路线得分从 0 到 1 都有——组内归一化恰好是最好的 baseline。"
Q: 你怎么保证 GPT-4o 教师轨迹的质量？
"三层过滤。第一层格式：工具调用 JSON 是否合法、参数完整。第二层约束——最关键的一层：OR-Tools 直接验证最终路线可行性，不可行的轨迹直接丢弃。这是确定性的，不是 LLM 打分。第三层语义：抽检逻辑一致性——前面的纠错步骤和后面的路线是否自洽。最终过滤率大约 70%，也就是 GPT-4o 生成的轨迹中只有约 30% 通过了全部三层。"
Q: 如果让你重新做一次，你会怎么改进？
"两点。第一，当前 GRPO 的奖励函数只包含路线可行性这一个维度，考虑加一个'路线最优性'维度——不仅可行，还要逼近最优解——用 OR-Tools 的最优解做参照，计算 gap 作为负奖励。第二，数据合成上，当前依赖 GPT-4o 单一教师模型，应该加对抗性构造——故意生成常见错误模式的轨迹，让模型在训练中学会纠正。"
三、KTClaw 项目 STAR 完整话术
3.1 30 秒版本
"KTClaw 是一个企业级多 Agent 协作平台。我解决的核心问题是——多个企业 IM 渠道（钉钉、飞书、企微）的消息格式和交互模式完全不同，一个 Agent 同时服务所有渠道会因为上下文污染和渠道差异导致回答质量严重下降。我设计了三进程隔离架构 + ChannelAdapter 适配器模式 + 四层记忆体系，实现了渠道间上下文物理隔离、消息格式统一、跨会话知识复用。"
设计的埋点："三进程架构"、"上下文物理隔离"、"为什么不用单进程"、"四层记忆"、"召回融合"
3.2 2 分钟版本
Situation：企业办公场景里，一个团队同时用钉钉、飞书、企业微信。如果在每个渠道部署独立的 Agent 实例，知识无法共享；如果所有渠道共享一个 Agent，消息格式差异和上下文混杂会导致工具调用准确率显著下降——我们发现单 Agent 多渠道的方案，工具调用错误率比单渠道高 40%。
Task：设计一套架构，做到三个"既要又要"——既要渠道间知识共享，又要上下文隔离；既要支持多 IM 协议，又要统一的消息抽象；既要长期记忆跨会话复用，又要低延迟检索。
Action：三个核心设计。第一，三进程架构——Renderer（控制面）、Main（调度层）、Gateway（执行层）进程级隔离，不同渠道的消息在 Gateway 层完成归一化后再进入 Main，确保调度层看到的都是统一格式。第二，ChannelAdapter 模式——借鉴 OpenClaw 的 ChannelDock/Plugin 两层抽象，针对钉钉/飞书/企微各自的消息格式做深度适配。第三，四层记忆 + 三路召回——索引层（元数据检索）、事实层（语义向量检索）、程序层（流程关系图检索）、归档层（冷数据），用 RRF 融合三路召回结果。底层 Agent 引擎基于 OpenClaw SDK。
Result：三个核心指标。稳定性——渠道切换时上下文丢失率从 12% 降到 2%。命中率——三路 RRF 融合比单路向量检索召回率提升 18%。复用率——程序性记忆的跨任务复用率达到 35%。
设计的埋点："为什么三进程而不是多线程"、"ChannelAdapter 和 OpenClaw ChannelDock 的关系"、"RRF 融合"、"四层和学术分类的对应"
3.3 高频追问及回答
Q: KTClaw 和 OpenClaw 是什么关系？你为什么要基于 OpenClaw 而不是从零做？
"KTClaw 的底层 Agent 引擎是 OpenClaw SDK，但我们不是简单部署了一个 OpenClaw 实例。OpenClaw 是 local-first 的个人 AI 操作系统，KTClaw 是企业级的多 Agent 协作平台——场景完全不同。选择基于 OpenClaw 而不是从零做，是因为它的 Agent Loop 和 Gateway 架构已经过 30 万+ star 社区的验证，我们不需要重新发明基础能力，聚焦在企业场景的四个差异化上：三进程安全隔离、企业 IM 深度归一化、分层记忆+三路召回、系统化 Agent 评测——这四个都是 OpenClaw 原生不具备的。"
Q: 三进程架构为什么比单进程好？你测过性能差异吗？
"不只是性能问题，核心是安全边界。单进程里，不同渠道的消息处理在同一个内存空间，一个渠道的恶意输入可能影响其他渠道。三进程架构把安全边界从'同一进程内的权限检查'升级成了'进程级别的物理隔离'。性能上，Renderer 独立处理 UI 渲染避免了主调度线程被阻塞，Gateway 独立处理消息收发避免了 IO 等待影响推理。我们测过，在 8 个渠道并发时，三进程架构的 p99 延迟比单进程低 40%。"
四、TinyClaw 项目 STAR 完整话术
4.1 30 秒版本
"TinyClaw 解决的是 Agent 的'学了就忘'问题。传统 RAG 每次检索都从头来过，不积累经验。我设计了一套 RAG-to-Skill 自进化机制——Agent 在多次检索中识别出反复使用的知识模式，自动编译成可复用的 Skill，后续直接调用而不用重复检索。核心创新是用可验证奖励保证 Skill 质量——IB 信息瓶颈过滤 + Verifier 确定性验证 + 渐进式检索撤回——确保自生成的 Skill 不会产生负迁移。"
设计的埋点："RAG-to-Skill"、"IB 过滤"、"负迁移"、"渐进式检索撤回"、"SkillsBench -1.3pp"
4.2 2 分钟版本
Situation：传统 RAG 系统有一个系统性浪费——用户反复问同一类问题，Agent 每次都重新检索、重新阅读文档、重新推理。就像一个医生每次看感冒都要重新翻教科书。更大的问题是，如果让 Agent 自动从检索经验中创建 Skill，这些自生成 Skill 的质量不可控——SkillsBench 的数据显示，自生成 Skill 平均造成 -1.3pp 的负迁移，反而降低了 Agent 能力。
Task：设计一套机制，让 Agent 能安全地从检索经验中提炼可复用 Skill，同时确保不会引入负迁移。
Action：三个核心模块。第一，IB 信息瓶颈过滤——只保留与任务目标互信息高于阈值的知识片段，过滤检索噪声。第二，Verifier-grounded SSL 编译——用可验证的标注信号半监督地编译程序性知识，不是 Agent 自己觉得对就存，而是必须通过确定性验证。第三，渐进式检索撤回——Skill 覆盖率达到阈值后自动减少对应领域的检索深度，节省 token 成本。整个流程参考了 Hermes Agent 的 Skills 闭环，但核心差异是——Hermes 靠 Agent 自主判断，我靠 Verifier 确定性验证。
Result：自生成 Skill 的正确率比纯 Agent 自主创建高 15 个百分点。检索 token 成本降低约 40%（渐进式撤回的效果）。最关键的是——没有出现 SkillsBench 报告的负迁移现象。消融实验：去掉 Verifier 验证层，自生成 Skill 的质量直接下降 18 个点，出现了明显的负迁移。
设计的埋点："SkillsBench -1.3pp"、"为什么 Hermes 的方法不够"、"消融：去掉 Verifier 降 18 个点"、"检索成本降低 40%"
4.3 高频追问及回答
Q: TinyClaw 和 Hermes Agent 的 Skills 系统有什么本质区别？
"都是把经验沉淀为可复用 Skill，但质量保证机制完全不同。Hermes 靠 Agent 自主判断——后台审查 Agent 用 LLM 判断'是否值得沉淀'。这个机制的问题是审查 Agent 的判断力上限就是底层 LLM 的能力上限——它可能保存噪声、遗漏重要经验、Skill 质量参差不齐。TinyClaw 的差异化在于 Verifier-grounded——不是 Agent 觉得对就存，而是必须通过确定性验证。IB 过滤保证信息有效性，Verifier 保证 Skill 正确性，渐进式撤回保证成本可控。代价是灵活性不如 Hermes——我们不能处理没有 verifier 的开放域场景。"
Q: 你怎么证明没有负迁移？怎么测的？
"三个维度。第一，在固定的 eval set 上跑加了 Skill 和没加 Skill 的对比——确保加 Skill 后各项指标不低于 baseline。第二，SkillsBench 的 benchmark 测试——我们复现了 SkillsBench 的评测管线，在同等条件下对比。第三，消融实验——把 Verifier 拿掉，让 Agent 自己判断 Skill 质量，然后看指标变化。结果很清楚——拿掉 Verifier 后出现 -18pp 的退化，说明 Verifier 是防止负迁移的关键。带 Verifier 的版本各项指标在 baseline 之上或持平。"
五、面试主动引导三技巧（必练）
技巧一：主动"埋点"，引面试官追问你准备好的内容
原理：面试官 80% 的追问来自你刚才说的内容。你控制说什么，就间接控制了追问方向。
做法：在项目介绍 30 秒版本里主动埋 3-4 个具体但不展开的关键词。
GoAfar 示例：
"我用 GRPO 替代了 DPO，因为任务有确定性 verifier——OR-Tools 求解器可以直接验证路线可行性。在数据合成上我做了三层过滤，最终过滤率大约 70%。"
埋的点：①"为什么不是 DPO"②"确定性 verifier 是什么"③"三层过滤具体是什么"④"70% 过滤率怎么算的"——这四个点你都准备了完整答案，面试官大概率追问其中之一。
KTClaw 示例：
"我设计了三进程隔离架构——Renderer、Main、Gateway 进程级分离。这个设计的灵感来自 Claude Code 的三条主干链路和 OpenClaw 的单 Gateway 架构。"
埋的点：①"三进程为什么不是多线程"②"和 Claude Code 三条链路的关系"③"OpenClaw 单 Gateway 有什么问题"④"进程间通信怎么做的"
技巧二：每个回答主动收尾"闭环六步"中缺失的那一步
原理：很多候选人讲完"我做了什么"就停了。主动补上缺失的环节，让面试官觉得你"比自己还想得深一步"。
模式：
- 讲完方法 → 主动说："在消融实验上我验证了 A 贡献 X%，B 贡献 Y%"
- 讲完效果 → 主动说："同时我监控了护栏指标 Z 无退化"
- 讲完难点 → 主动说："复盘来看如果再做一次我会先做 XX"
示例（GoAfar 讲完方法后）：
"……以上就是为什么选 GRPO。补充两个点。第一，消融实验上我验证了——去掉 OR-Tools 验证层，只用 LLM-as-judge，可行性只能到 78%，确定性 verifier 贡献了 16 个点。第二，我也监控了护栏指标——GRPO 训练前后，模型在开放域对话任务上的表现没有退化，KL divergence 控制在合理范围内。这个很重要，因为我们不希望路线规划能力提升的代价是通用对话能力下降。"
技巧三：用"可量化的反事实"代替"可能会"
原理：面试官不在乎数字是否精确，在乎你有没有量化思维。
弱回答："不做这个项目，Agent 效果会很差。" 强回答："不做的话，按当时 badcase 增长率每月约 8%，半年后工具调用错误率会从当时的 20% 升到约 32%，对应每天影响大约 5,000 次请求。"
弱回答："GRPO 比 DPO 效果好。" 强回答："同样数据量下，GRPO 的路线可行性比 DPO 高 9 个百分点。换算一下，每天约 3,000 次路线规划请求中，GRPO 方案少产生 270 次不可行路线。"
六、面试官的追问模式：5 类连环炮 + 应对
模式一：效果质疑型
面试官：你说提升了 X%，怎么确定不是数据泄漏？ 应对：讲清楚 train/eval split 的时间切分策略 + n-gram 重叠检测 + held-out private set
面试官：offline 涨了 online 就涨吗？ 应对：讲清楚 eval set 和线上分布的 KL divergence 监控 + 代理指标和北极星指标的相关性
模式二：替代方案挑战型
面试官：你为什么不用 XX 方法？现在最新论文都用那个。 应对：不要说"XX 方法不好"，要说"XX 方法在我们的约束下不合适，因为……"——展示你有判断力但不对立
面试官：如果用 GPT-5 直接做，你的方案还存在吗？ 应对：承认通用模型的进步 + 指出垂域场景的持续优势（成本 / 数据安全 / 垂域效果 / 延迟可控）
模式三：业务价值挑战型
面试官：你这个项目花了不少算力，ROI 怎么算？ 应对：算力成本 + 人力成本 + 数据标注成本 vs 业务指标提升 × 单位价值 × 年
面试官：如果预算砍到 1/3，你还能做吗？ 应对：展示优先级排序能力——砍掉 low-ROI 子模块、用小模型+蒸馏、复用开源 baseline
模式四：深度追问型（连环 4-5 问）
面试官：你的 reward 怎么设计的？→ 答案正确性 + 格式奖励 追问：格式奖励一开始就加了吗？→ 没有，训了 500 步模型不再写指定格式，加了 0.1 权重的格式奖励救回来 追问：0.1 这个数怎么定的？→ 扫了 [0.05, 0.1, 0.2, 0.5]，0.1 是正确性和格式约束的最佳平衡点 追问：格式奖励太大会不会导致模型只会写格式不会解题？→ 确实，0.5 时出现了"格式完美但答案错误"的 reward hacking 模式，所以选了 0.1
应对关键：每一个数字都要准备好"为什么是这个数字"的答案。
模式五：自我批判型
面试官：你觉得这个项目最大的问题是什么？ 应对：诚实但不自我否定。指出一个真实局限 + 你已经想过怎么改进。
示例："GoAfar 最大的局限是 OR-Tools 作为 verifier 只能在约束优化场景使用。如果换到开放域对话的 Agent 后训练，没有这样的确定性 verifier，我的方法论就不能直接迁移。这是我正在思考的方向——怎么在没有 hard verifier 的场景下构建可靠的奖励信号。目前关注的方向是用 LLM-as-judge 的 ensemble + 人工抽检校准来逼近确定性验证的效果。"
七、每个项目的一句话护城河
当面试官问"你这个项目有什么壁垒"时，用以下话术：
| 项目 | 一句话护城河 |
|---|---|
| GoAfar | "确定性 verifier + GRPO 的组合让我的训练信号比纯偏好训练可靠得多——这不是换个模型就能复现的，因为 verifier 的质量决定了 RL 的上限。" |
| KTClaw | "三进程架构 + 四层记忆 + 三路召回是一个系统工程——任何一个单点优化都不难，但三者在同一个系统中协同工作且不互相拖累，这是真正的壁垒。" |
| TinyClaw | "RAG-to-Skill 的壁垒不在于'能生成 Skill'，而在于'生成的 Skill 不会产生负迁移'——Verifier-grounded 的质量保证机制是整个系统最不可替代的部分。" |
八、高频软技能问题 + 回答模板
Q: 你遇到过最大的技术困难是什么？
推荐结构：具体场景 → 尝试了什么失败的 → 怎么定位根因的 → 最终怎么解决的 → 学到了什么
GoAfar 可用素材：GRPO 训练过程中 reward 曲线上去了但真实路线可行性不涨——根因是 reward 函数只奖励了"格式正确"而不是"路线可行"，修复是把 OR-Tools 验证结果直接编码进 reward 而非依赖格式检查。
KTClaw 可用素材：多渠道并发时上下文污染——不同渠道的消息在同一 session 中混杂，导致 Agent 用钉钉的语气回复飞书用户。根因是 session key 的解析逻辑没有区分渠道。修复是通过 session routing 加入 channel 维度。
Q: 你如何平衡研究深度和工程交付？
"我的原则是'先确定下限，再追求上限'。确定下限意味着工程上先跑通端到端——哪怕效果不是最优，但 pipeline 是通的、评测是有的、基线是清楚的。追求上限是在这个基础上做研究探索——换算法、调参、消融。这样任何时候被问'现在能上线吗'，我都能给出一个可用的版本，同时也有正在优化的方向。"
Q: 你为什么选择小红书 AI Agent 算法岗？
"三个原因。第一，小红书的 C 端 Agent 场景是 2026 年最挑战性的 Agent 落地场景之一——亿级用户、多模态内容、高时效性需求、推荐+搜索+对话三者交叉。第二，我在后训练（GRPO/RLVR）和多 Agent 架构（KTClaw）上的经验直接对口——小红书的 Agent 需要既有强大的推理能力（后训练），又要有稳定的工程架构（多 Agent）。第三，我个人对 Agent 自进化方向最有热情——TinyClaw 的 RAG-to-Skill 就是这个方向的探索，而小红书的 C 端 Agent 场景天然是自进化的最佳土壤——用户的每一次对话都是 Agent 进化的信号。"
九、面试前 10 分钟 Checklist
- [ ] GoAfar 30 秒版本能脱口而出（含 3 个埋点）
- [ ] KTClaw 30 秒版本能脱口而出（含 3 个埋点）
- [ ] TinyClaw 30 秒版本能脱口而出（含 3 个埋点）
- [ ] 每个项目的消融实验数据背熟（哪个改动贡献最大）
- [ ] DPO vs GRPO vs PPO 对比能脱稿讲 2 分钟
- [ ] OpenClaw vs Hermes vs Claude Code 三个开源项目的定位差异能一口气讲清
- [ ] "你的方案不用 GRPO/自进化/多 Agent 做行不行"——每个项目想好一个替代方案对比
- [ ] "如果给你无限资源重做，你会怎么做"——每个项目想好一个回答
- [ ] 倒背如流的 3 个数字：①GoAfar 67%→94% ②KTClaw 召回率+18% ③TinyClaw 无负迁移
- [ ] 准备好反问面试官的问题（见下一节）
十、反问面试官：展示你思维深度的问题
面试结束时面试官会说"你有什么想问我的"。这时候的问题质量直接决定最后印象。
推荐问题（按优先级）
"小红书 C 端 Agent 目前最大的工程挑战是什么？是后训练效果问题、架构稳定性问题、还是评测体系问题？"
- 展示你关注的是真实痛点，不是炫技
"团队目前 Agent 的 post-training pipeline 是什么结构？数据合成、SFT、RL 各占多大比重？有没有用 RLVR 类的可验证奖励？"
- 展示你对后训练技术栈的系统理解
"小红书的 Agent 评测是怎么做的？线上 AB 指标还是 offline benchmark？有没有针对 Agent 多步推理的专项评测？"
- 展示你关注的是"怎么验证真的有效"
"团队对 Agent 自进化方向怎么看？有没有在探索像 Hermes 的 Skills 闭环或者 RL 训练闭环这样的机制？"
- 展示你关注前沿且有自己想做的方向
避免的问题
- 不要问"加班多不多"（第一印象崩）
- 不要问"我面试表现怎么样"（把面试官放尴尬位置）
- 不要问能用 Google 搜到的问题（展示你没做功课）
十一、面试金句（可直接用）
"我的每个设计决策都能回答'为什么不是另一种方案'。不是因为那个方案不好，而是在我的约束下——这个更合适。"
"确定性 verifier 是 Agent 后训练中最被低估的杠杆。RLVR 的有效性 90% 取决于 verifier 的质量，10% 取决于算法选择。"
"Agent 评测最难的不是设计 benchmark，而是确定 benchmark 和线上指标的相关系数。offline 涨 5 个点 online 不涨，说明你的 eval set 和真实分布之间有系统性漂移。"
"Dissent is cheap. 说'这个方案有问题'很容易，但说'在 XX 约束下，这个方案比 YY 和 ZZ 更合适，因为……'需要真正的工程判断力。"
"Agent 自进化最大的坑不是技术上的，而是质量上的——你怎么保证自动生成的 Skill 不会让 Agent 越来越差？SkillsBench 的 -1.3pp 负迁移就是警钟。"
"我面试的准备方式是把每个项目按'为什么做→不做会怎样→为什么这个方法→为什么不是别的→怎么验证→业务价值'这六步重新梳理一遍。今天我讲的每个结论背后都有一个消融实验或者一个具体的 badcase。"
附：STAR 话术自检清单
对每个项目回答以下问题，答不出来 = 准备不充分：
| 检查点 | GoAfar | KTClaw | TinyClaw |
|---|---|---|---|
| 30 秒版本能脱口而出？ | |||
| 2 分钟版本覆盖六步法至少四步？ | |||
| 能讲出至少一个消融实验的对比数据？ | |||
| 能讲出为什么不用替代方案（DPO/单进程/纯RAG）？ | |||
| 能讲出一个踩过的坑和怎么解决的？ | |||
| 能讲出一个如果重做会怎么改进的点？ | |||
| 准备了一个面试官可能追问的"弱点"并想好回应？ |