项目讲不深，通常不是项目小而是证据链断了

“你这个 Agent 项目具体做了什么？”

很多人一开口就报技术栈：用了某个模型、接了向量库、做了工具调用。面试官再问“所以效果怎样”，回答就只剩“体验还不错”。问题通常不是项目规模小，而是中间缺了证据：为什么做、改了哪里、拿什么比较、结果有没有复现。

先给一个能复述的答案

项目深度来自一条完整证据链：业务问题和基线、关键决策与实现边界、实验和线上结果、失败样本与复盘。每个结论都要能指向代码、数据、trace、截图或监控，而不是只靠记忆里的形容词。项目越小，越要把边界和证据讲准确。

先写一页项目证据卡

面试前我会把项目压成一张卡，而不是背十分钟稿子：

场景：内部知识问答，用户要找到制度原文
基线：纯关键词检索，长问题 Recall@5 低，人工反复翻文档
动作：混合召回 + 版本过滤 + 片段引用 + 越权回归集
结果：Recall@5、引用覆盖率、P95、单位成功成本分别怎样变化
失败：旧版本规则和表格问题仍容易错，下一步怎么补

这张卡上的每个名词都要能展开。说“引用覆盖率提升”，就得说清分子是什么、样本怎么标、哪些回答算不覆盖。

用“前后对照”而不是“功能列表”

功能列表回答“做了什么”，前后对照回答“为什么有价值”。

每一行都包含一个决策、一个实现位置和一个验证结果。面试官如果继续追问，你可以沿着这一行往下讲，不会在不同细节之间跳来跳去。

结果要带口径

“准确率提升 15%”至少要补充四个信息：

1. 样本来自哪里，是否有训练集污染？
2. 指标的分母是什么，允许拒答吗？
3. 基线和实验只改了哪个变量？
4. 提升是否牺牲了延迟、成本或安全？

可以用一段实验记录表达：

dataset=v3 / n=800 / judge=rubric-02
baseline=keyword / treatment=hybrid+rereank
Recall@5: 0.71 -> 0.82
citation_coverage: 0.64 -> 0.86
P95: 420ms -> 468ms
结论：接受 48ms 延迟换取引用覆盖，继续观察长尾。

把自己的贡献落到动作上

“我负责 Agent”太宽。可以把贡献写成动词加对象：

• 把租户和文档版本写进检索过滤契约；
• 把工具超时分成可重试和未知副作用两类；
• 把失败样本分桶，新增一组长表格回归集；
• 把一次成功任务成本拆到模型、检索和工具；
• 把 trace 里的证据片段做成可回放记录。

这些动作能指向具体文件、接口、实验报告或监控面板，远比“参与了优化”更有可信度。

失败样本是项目深度的入口

不要只准备最好的 Demo。挑一个最能说明工程边界的失败样本：

现象：答案引用了已废止的制度版本
定位：召回正确，但版本过滤只在生成后做
修复：把 effective_at 和 tenant_id 前置到索引过滤
验证：旧版本对照集、跨租户集、线上回放
剩余风险：手工上传文档的生效时间仍可能填错

能说清失败发生在哪里、为什么发生、怎样证明修复有效，项目就不再是“调用模型的 Demo”。

把证据分成四层，避免只拿一张截图

项目证据可以按可信度和可复现性分四层：

1. 行为证据：输入、输出、引用、工具回执和用户反馈；
2. 运行证据：trace、日志、延迟、成本、错误率和版本；
3. 对照证据：固定数据集上的基线、实验变量和分桶结果；
4. 回归证据：失败样本、故障注入、上线门槛和复查记录。

截图适合说明界面，不能替代后三层。面试官问“这是不是偶然的”，就从行为证据往下补到对照和回归；如果当前只有体验反馈，直接说证据还不完整，并给出下一步怎么补。

线上和离线要互相喂样本

离线评测集不能只来自人工编写的标准题。线上脱敏 trace 经过失败归因后，要回流到数据集；离线发现的回归样本，也要在灰度看是否会真实发生。每次回流保留来源、标签人、版本和是否进入训练，避免数据污染。

线上 bad case -> 脱敏 -> 归因标签 -> 评测集 v4
评测回归 -> 灰度观察 -> trace 对照 -> 更新监控与门槛

这条链路是项目持续变深的关键：你不仅做了功能，还让系统从失败中获得下一轮验证材料。

讲不清数字时，先讲证据边界

如果没有可靠的样本数或基线，不要临时编一个百分比。可以这样回答：“当前只有 120 条人工抽检，方向上引用覆盖变好，但还不足以说明线上提升；我会先补齐版本化评测集，再在灰度窗口比较 P95、成本和失败分桶。”承认证据边界，比说一个无法追溯的精确数字更有可信度。

每个结论都用三句话固定口径

面试讲指标时，可以按“事实—解释—边界”三句话：

事实：qa-v3 的 Recall@5 从 0.71 提到 0.82，P95 增加 48ms。
解释：主要增益来自编号问题的混合召回，引用覆盖也同步提升。
边界：表格问题和线上长尾样本还不足，不能把这个结果外推到所有任务。

这套说法既不会只报一个漂亮数字，也不会因为有局限就完全不讲结果。面试官继续追问时，直接沿三句话中的某一项展开即可。

个人贡献要有自己的证据包

团队项目结束前，我会把个人贡献整理成一个小包：负责的接口或模块、一次关键决策、一个失败样本、实验命令、前后指标和复盘链接。贡献包不等于把团队代码复制一份，而是让别人能看见你做过什么判断、留下什么产物。

如果某项工作只有口头讨论，没有代码或记录，就如实标注为协作输入，不把它包装成独立完成。诚实的边界说明比夸大的“全程负责”更能经得住细节追问。

证据包也要做版本和反事实对照

项目证据不是一组永远不变的截图。每次关键改动都给证据包一个版本，并写出“如果不做这个改动，会发生什么”：

evidence_pack: search-v4
baseline: hybrid-search-v3
change: add tenant + policy_version filter
counterfactual: old cache can return another tenant's title
observed: cross-tenant fixture 0/240, P95 +18ms
rollback: feature_flag=search_v3

反事实不一定要真的把旧版本在线上打开，可以用固定回放集或故障注入模拟；关键是把“改动带来的收益”与“同时付出的代价”分开。没有反事实时，很容易把项目原有的基础能力误算成自己的增量。

个人贡献还可以拆成三类：

• 决定了什么：选择了哪个边界、指标或实验，而不是只执行任务；
• 改变了什么：哪个失败率、延迟、成本或人工步骤因此变化；
• 留下了什么：接口、回归集、监控、文档或可交接的开关。

把项目证据包做成交接单元

项目讲深不只为了面试，也为了让别人能接手。一个可交接的证据包至少包含以下结构：

evidence-pack-v4/
├── README.md          # 场景、结论、边界与一键入口
├── manifest.yaml      # 数据、模型、Prompt、工具和代码版本
├── baseline/          # 基线命令、输出摘要与失败分桶
├── treatment/         # 实验命令、trace 与指标结果
├── cases/             # 脱敏 bad case、归因和回归断言
├── decision-log.md    # 关键取舍、反事实和剩余风险
└── rollback.md        # 开关、触发条件和恢复负责人

README 的第一屏只写三件事：这次改变了什么、证据在哪里、什么情况下不能外推。命令若依赖外部服务，就标出 live-required，同时提供 fixture 或 dry-run；不要把“在我电脑上能跑”当成交接标准。每次版本只新增一个主要变量，旧包保留只读链接，才能比较增量而不是覆盖历史。

四个常见坑

把组件数量当作项目规模

十个组件没有一个可验证的约束，仍然只是拼装。先讲一条完整链路，再补组件。

指标没有基线和样本

没有基线的提升无法判断，没有样本的准确率无法复核。至少保留版本、样本数和分桶方式。

只讲成功，不讲代价

延迟、成本、复杂度和维护负担都是结果的一部分。承认代价反而让取舍更可信。

把团队结果说成个人结果

明确自己负责的接口、实验和决策，同时说明依赖了谁的模型、数据或基础设施。

L1 / L2 / L3 分层追问

L1： 你的项目难点是什么？

先说一个业务失败现象，再说负责的边界、关键改动、验证指标和剩余风险，不从技术栈开场。

L2： 这个指标可信么？

说明数据集版本、样本规模、基线、唯一变量、评测规则和代价；如果不确定，直接说当前证据还不足。

L3： 如果重做，最先改什么？

选择一条能减少后续返工的边界，比如版本过滤、状态持久化或回归集治理，并解释当时为什么没先做。

L1： 项目证据最少要有哪些？

至少有业务问题、基线、关键改动、一个失败样本和可复查结果；结果最好能指向 trace、数据集或运行记录。

L1： 为什么截图不能当完整证据？

截图只能说明某次行为，无法证明版本、样本、成本、长尾和回归；还需要运行、对照和回归证据。

L2： 如何建立一个可信的基线？

固定数据集版本、评测规则、模型和工具边界，记录样本数、分桶和唯一变量；没有这些，前后对照不可解释。

L2： 线上 bad case 怎样进入评测集？

先脱敏，再做失败归因和标签复核，记录来源与版本，放入对应分桶并设回归门槛，不能直接把用户原文丢进数据集。

L2： 指标提升但用户体验变差怎么办？

把成功率、引用、P95、成本、拒答和人工接管一起看；如果硬门槛或关键体验回归，就保留旧路径并继续拆分任务类型。

L3： 个人贡献如何从团队结果中分离？

按自己负责的接口、实验变量和决策记录说明增量，同时标注模型、数据和基础设施等外部贡献，不把全局提升全部归给自己。

L3： 项目还没有线上流量，怎样证明深度？

用真实脱敏任务集、故障注入、离线回放和成本估算建立证据，并明确哪些结论尚未经过真实流量验证。

L5： 如果项目仓库不能在面试现场完整运行，证据链怎么保持可信？

准备一个脱敏的 evidence-pack：固定 manifest、基线与实验命令，附关键 trace、失败样本、断言和回滚说明；外部依赖用 fixture 或明确标成 live-required。现场先展示可复查的结果和边界，再说明哪些状态需要真实服务验证。

L1： 面试讲指标最稳的结构是什么？

先报事实，再解释增益来自哪里，最后说样本和任务边界；不要只给一个没有分母的百分比。

L2： 个人贡献证据包应该放什么？

负责的接口、关键决策、实验命令、失败样本、前后指标和复盘链接；让别人能复现判断，而不是只看到代码行数。

L2： 只有人工体验反馈，没有离线数据怎么办？

说明当前证据不足，先把反馈脱敏成分桶样本，再补基线、评测规则和回放；不要用“大家觉得更好”替代指标。

L3： 结果不提升时项目还值得讲吗？

可以讲清排除过的假设、减少的风险、建立的回放与回归能力，以及尚未解决的边界；工程价值不只由最终分数决定。

L4： 你怎么证明提升来自自己的改动，而不是模型或流量变化？

固定模型、数据集、工具权限和流量切片，只改变一个变量；保留旧版本回放、版本指纹和对照结果。无法隔离时就明确只能说相关性，不能把全局提升归因给自己。

L4： 项目证据包里最容易被忽略的是什么？

通常是代价和回滚：延迟、token、人工接管、缓存失效和失败后的恢复路径。只保留成功截图，会让评审无法判断是否值得上线。

L5： 团队没有统一埋点，怎样补出可用证据？

先从请求 ID、版本、关键状态和工具回执建立最小闭环，离线抽取脱敏样本做对照；把估算与实测分开，逐步补齐成本和长尾指标，不等所有埋点完美后才开始复盘。

L5： 什么时候应该承认项目结论不可外推？

当样本只覆盖单一租户、单一模型、短期流量或没有线上验证时，明确适用范围和未验证假设；下一步给出需要的样本、灰度窗口和复查门槛。

L3： 如何处理团队数据不能公开的问题？

用脱敏统计、区间、分桶和可复查命令说明口径，隐藏业务机密但不隐藏指标定义和实验变量。

把个人贡献写成一条可核对的证据链

项目介绍最容易卡在“这个系统是我们做的，我主要负责其中一部分”。这句话没有错，但面试官听完仍不知道你做了什么、改变了什么、结果是不是你能解释的。与其把功能列表再念一遍，不如给每个关键结论挂上一条贡献链：动作、版本、指标、样本和复盘人必须能互相对上。

可以用一张轻量的贡献台账固定口径：

contribution_id: c_014
claim: 检索过滤降低了越权召回
my_action:
  - 增加 tenant_acl pre-filter
  - 补充 120 条跨租户对抗样本
change_ref: commit:7a91c2e
baseline:
  unauthorized_recall: 4.2%
after:
  unauthorized_recall: 0.3%
  answer_success: -0.6%
evidence:
  replay_set: acl-redteam-v2
  dashboard: trace://eval/2026-08-18
tradeoff: 召回略降，关键租户边界更稳定
reviewer: security-owner

这张台账同时承认收益和代价：如果只写“越权下降”，面试官追问召回损失时就会重新失去主动权。change_ref 让代码动作可查，replay_set 让指标不是口头数字，reviewer 则避免把团队共同结果说成个人独立完成。项目越复杂，越需要这种小而硬的证据单元。

讲述时按“我发现什么—我改了什么—数据怎样变化—还牺牲了什么”四句走，听众能快速判断你的边界，也更容易继续追问到架构细节。证据不是把所有日志都塞进简历，而是让一个结论沿着链路走得通。

L5：如果指标提升来自多项改动，怎么证明是自己的贡献？

我不会把相关性直接说成因果。会补做时间切片、逐项开关或反事实回放，至少给出“这一项改动在固定样本上带来的增量”和置信范围；如果无法拆分，就诚实说明团队贡献，并把自己负责的设计、实现和验证证据单独列出。

贡献链还要标出“不可归因”

当一个项目同时改了模型、检索和工具权限，最终成功率上涨并不能自动归因给某一个人。证据包里应把无法拆分的部分明确标成 unknown，并保存能继续验证的开关：

contribution_attribution: ca_20260820_21
claim: "租户过滤降低越权召回"
change_set:
  - acl_prefilter
  - cache_key_tenant
  - model_route_v4
ablation:
  acl_prefilter_only: -3.7pp unauthorized
  cache_key_tenant_only: -0.8pp unauthorized
  combined: -4.2pp unauthorized
confounders:
  - traffic_mix_changed
  - judge_version_changed
status: partial_attribution
next_check:
  fixed_snapshot_replay: required
  owner: security-owner

这样讲不但更可信，也能说明下一步怎么补证据。把团队共同结果诚实分层，比把所有提升都写成“我做的”更经得起追问。

L5：什么时候必须说“这项提升无法单独归因”？

当数据、模型、流量或多项代码同时变化，且没有固定快照或消融结果时就必须说明。可以给出相关性和团队贡献，但不能把未经隔离的全局变化写成个人因果；下一步用固定样本和单变量回放补齐证据。

证据包还要有一张“数字口径卡”

面试中最容易被追问的不是“你用了什么框架”，而是“这个 12% 是怎么来的”。把数字口径单独列成一张卡：分子、分母、样本切片、时间窗口、基线版本和是否包含人工接管都写清楚。数字暂时不完整时，卡片也可以明确标记 partial，避免把方向性观察说成线上结论。

metric_card: mc_20260820_08
metric: citation_support_rate
definition: "被授权证据直接支持的 claim / 全部可判定 claim"
baseline: {version: v4, value: 0.74, n_claims: 420}
candidate: {version: v5, value: 0.86, n_claims: 410}
slice: "high_risk_support_tickets"
window: "2026-08-12..2026-08-19"
excluded: [manual_override, missing_trace]
confidence: partial
next_step: "replay_missing_trace_before_external_claim"

这张卡不只是为了答面试题，也方便团队复盘：如果候选版本只在排除人工接管后变好，就必须把这部分边界说出来；如果分母因数据清洗变化，前后数字就不能直接相减。把“知道什么”和“不知道什么”一起写在证据包里，反而比一个过于精确但无法追溯的百分比更有说服力。

L5：什么时候应该主动说“这个数字还不能外推”？

当样本只来自单一租户、人工抽检、短时间窗口，或基线和候选没有锁住同一版本元组时，就只能说明局部观察。可以给出当前方向和下一步验证方法，但不能把局部结果包装成全量线上收益。

证据包还要能在“最小环境”里重放

有 commit、截图和一串指标，不等于别人能复核你的结论。项目交接时我会把证据压缩成一个最小可复现包：固定输入切片、配置与依赖摘要、运行命令、预期断言、输出 artifact 和责任人。包里不放生产密钥，外部服务用冻结 fixture 或 dry-run 替代；如果缺少关键依赖，就明确标为 partial，不要把“理论上可以复现”写成已验证。

minimal_repro_pack: mrp_20260820_93
claim: tenant_filter_reduces_unauthorized_recall
inputs:
  replay_set: acl-redteam-v2
  snapshot: kb-2026-08-18
runtime:
  commit: 7a91c2e
  lockfile_sha256: sha256:...
  command: "python eval.py --config configs/acl.yaml"
fixtures:
  tools: fixture://crm-v3
  llm: recorded://router-v4
assertions:
  unauthorized_recall: "<= 0.5%"
  answer_success: ">= 0.80"
status: runnable_offline
owner: security-owner

L5：为什么“给出 Git commit”还不够？

commit 只能定位代码，不能保证数据快照、依赖、模型路由、工具回执和评测器相同。最小复现包要把这些外部状态显式化；无法冻结的部分就写清楚边界和替代 fixture。

60 秒面试回答

我讲项目时会先给业务问题和原方案的失败现象，再说明自己负责的具体边界。然后用一条前后对照讲关键改动，比如把检索前的租户和版本过滤补上，把引用片段写进答案契约。结果不会只报一个成功率，而会同时给数据集、基线、延迟、成本和安全回归。最后补一个失败样本和剩余风险，让面试官看到这不是组件清单，而是一条有证据、有取舍、能复盘的工程链路。

交付前检查清单

• 有一句话业务问题和可观察失败现象
• 有基线、数据集版本和指标口径
• 每项个人贡献能落到动作和产物
• 关键改动有前后对照和代价
• 准备一个真实失败样本与修复证据
• 明确尚未解决的边界和下一步

相关阅读

• 项目里的指标怎么来的？别只报一个漂亮数字
• 项目被追问‘你做的和框架有什么区别’，怎样讲出自己的贡献
• 离线评测 95 分，线上为什么还是翻车？
• 同一个 Agent 实验，怎样才能复现？

资料来源

• AgentAlpha《Agent 岗面试宝典 v3》（未公开讲义）
• ARIS in AI Offer：项目叙事、证据卡与结果归因结构