AI Coding 笔试拿 offer 的三个心法

《核心观点》

先搞懂 AI Coding 到底在考什么。很多人以为 AI Coding 就是「用 AI 写代码」，实际面试官考察三件事：第一，你能不能准确描述问题，也就是把模糊需求变成 AI 能理解的精确指令（Prompt Engineering）；第二，你能不能判断 AI 写的代码对不对（Code Review）；第三，你能不能在 AI 出错时快速修正，知道什么时候该信任它、什么时候该推翻重来。想清这三层，就已经超过大部分候选人。

技巧一：用「伪代码 + 注释」引导 AI。不要直接甩一句「帮我写个 RAG 系统」，那样输出的东西你自己都看不懂。正确做法是先写伪代码框架，例如 # 1. 文档加载 -> 2. 文本分割(chunk_size=500) -> 3. 向量化(Embedding) -> 4. 检索(FAISS) -> 5. 大模型生成回答，让 AI 按这个骨架填实现。这样输出结构清晰、每步能单独定位问题，面试官看到的也是你的系统设计思维，而不是代码量。

技巧二：让 AI 自测，你当裁判。写完代码后让 AI 自己生成测试用例和边界 case，你的角色从「写代码」变成「review 代码」——判断逻辑是否合理、有没有遗漏边界情况。这一招在面试里特别好用，因为面试官真正想看的是你的思考过程，而不是手撕代码的速度。

技巧三：准备三个万能代码模板，面试时直接套用再按题微调，能省一半以上思考时间。模板 A「RAG 管道」：文档加载 → 文本分割 → 向量化 → 检索 → 大模型生成；模板 B「Agent 工作流」：感知 → 规划 → 工具调用 → 执行 → 反思；模板 C「评估框架」：准确性 → 时效性 → 成本 → 用户体验 → 安全性。

三个千万别踩的坑。坑一是完全依赖 AI 不自己思考，面试官追问细节时会直接露馅；坑二是复制粘贴不理解的代码，被问「这行为什么这么写」就答不上来；坑三是忽视边界情况和异常处理——AI 生成的代码大多不处理边界，这恰好是你加分的机会。

一句话收尾：AI Coding 的本质不是「会不会写代码」，而是「会不会用 AI 写好代码」。

---

《参考解析》

伪代码先行到底解决了什么问题：直接把需求丢给模型，等于把「需求澄清」和「方案设计」两步都外包出去了，模型只能猜你的意图，输出看似完整但边界模糊、模块耦合，出了问题也无法定位是哪一步错了。先把流程拆成 5 个左右带序号的步骤（每步写清输入、输出和关键约束），相当于给模型一份接口契约：它只需要填实现，你保留了架构决策权。实操上加两条：一是给每步标注技术选型和关键参数（chunk_size=500、overlap=50、向量库用 FAISS、Top-K 检索多少条），参数不同结果差异很大，写出来才可控；二是要求模型「按步骤分段输出，每段附一句用途说明」，这样 review 时能按段核对，也方便把某一段单独重写而不推翻全部。

让 AI 自测的正确姿势：很多人只会说「帮我写测试」，拿回来的用例全在测理想路径。有效的做法是先让模型列出当前实现依赖的关键假设（输入非空、字段必填、数据已排序、网络不会失败），然后针对每条假设设计用例：正常输入、空输入、极值（最大/最小/超长）、重复数据、状态切换（从成功切到失败再切回）、以及并发或乱序。每条用例都要能回答「它在验证什么假设」，跑完必须实际比对输出而不是看模型的口头结论。在笔试里还可以用对拍——写一个朴素暴力解法生成大量随机小规模输入，与主实现比对输出，几十行代码就能提供很强的正确性证据，性价比极高。这一步同时喂满了评分里最重的「产出校验」项。

RAG 管道模板的要点：这条管道每一步都有坑，面试时能点出来就是加分。文档加载要说明支持哪些格式与解析方式（PDF 要处理扫描件与多栏排版）；文本分割不能只按固定长度切，最好按语义或标题层级切，并设置重叠避免答案被切断，同时给每个 chunk 保留来源元数据（文档 id、页码、标题路径）以便引用；向量化要说清是否本地模型、维度与归一化、批量与限流；检索环节是重点——纯向量检索对精确匹配（编号、专有名词）不敏感，实践中常用「向量 + BM25 混合检索 + RRF 融合」，再用 cross-encoder 或 LLM 做重排（rerank）提升前几条的准确率；生成环节要把检索到的片段拼进提示词，明确要求「只依据给定资料回答，资料中没有就说不知道」并要求标注引用来源。工程上还要补索引更新策略（增量与全量重建）与多租户的权限过滤（检索前按用户可见范围过滤，不能检索后再删）。

Agent 工作流模板的要点：感知 → 规划 → 工具调用 → 执行 → 反思这条链，答题时关键是讲清控制流与失败处理。感知负责把用户输入和上下文归一化（意图识别、参数抽取、缺失信息澄清）；规划把任务拆成步骤或显式生成计划（ReAct、Plan-and-Execute 的差别在于后者先出完整计划再执行）；工具调用要说清工具描述怎么写（名称、用途、参数 schema、什么时候不该调用）、参数校验与超时重试、以及幂等与危险操作确认；执行阶段维护状态机或消息历史，处理多步依赖与并行；反思阶段根据执行结果判断是否需要重规划，并记录轨迹用于评测。最容易漏的是边界：工具报错怎么降级、循环多少轮强制终止、上下文超长时怎么裁剪（保留最近的 + 关键的，而不是简单截断头部）、以及成本与延迟预算。

评估框架模板的要点：准确性要分层——检索层看召回率与命中率，生成层看事实一致性（有没有编造）、引用正确率和任务完成率；时效性看数据新鲜度与增量更新延迟；成本要拆成 token 成本、向量存储与检索成本、以及重排模型成本，并给出每千次调用的估算；用户体验包括首字节延迟、流式输出、引用可点击、以及不确定时如何表达；安全性覆盖提示注入（检索到的文档里可能藏指令，必须当作数据而不是指令）、越权检索（不能靠提示词约束，要在检索层做权限过滤）、敏感信息与内容合规。落地时建议先建一个 50~200 条的人工标注小集做回归，每次改提示词或换模型都跑一遍，否则优化全靠感觉。

面试里被追问时怎么答：AI Coding 面试的追问几乎都落在「你为什么这么写」和「这里出错会怎样」两类。准备方式是给自己写一份「决策日志」：每个关键选择（为什么用这个分块大小、为什么用混合检索、为什么加这层缓存）记下一句理由和一个替代方案；每个模块想清楚两三个失效场景和对应兜底。被问到没做过的部分，直接说「这部分我了解的做法是 X，权衡是 Y，但我没有在生产里验证过」比现编更安全——面试官见过太多编造的细节，坦诚加合理的推理反而加分。