面试备战：PRD2Code

AI PRD2Code Spec Driven Development 研发效率 笔记 面试

面试备战：PRD2Code

核心定位：PRD2Code 不是简单的「PRD 直接生成代码」，而是一套以 spec 为中间契约、以 checklist 和 eval 为质量抓手的研发提效流程。

速记摘要

  • 设计哲学：把缺陷拦截点尽量左移，让问题在写代码前暴露。
  • 核心中间层：spec 是人能 review、AI 能执行的契约。
  • 关键难点：AI 审查如何降噪、代码库上下文如何注入、PRD 变化如何增量处理、模型升级如何不退化。
  • 面试表达重点：少讲「AI 很聪明」，多讲约束、评估、工程闭环和边界。

面试追问地图

追问方向一句话回答重点关键词
AI 审查是否靠谱不让 AI 自由发挥，而是用结构化 checklist 做逐项核对。checklist、闭合式核对、信噪比
现有项目上下文从哪来靠检索和相关模块上下文注入，不是把整个代码库塞进去。RAG、模块圈定、上下文窗口
PRD 一直变化怎么办spec 支持局部更新，只重跑受影响部分。增量更新、影响范围、模块粒度
为什么要 specspec 是人机对齐的中间契约，把缺陷左移。review、契约、缺陷左移
效果如何度量用同类历史项目作基线，并统计返工成本。基线、返工率、合入代码占比
为什么不用现成框架通用框架解决流程编排，但领域 checklist、代码库冲突检测和团队规约需要自研沉淀。build-vs-buy、控制力、场景特异性
模型升级如何保证更好没有评估集就没有迭代，升级必须跑 eval 和灰度。eval、A/B、数据飞轮

高频追问

Q1：AI 审查 PRD 找漏洞，凭什么靠谱？会不会全是噪音？

一句话回答：不让 AI 自由发挥，而是给它结构化 checklist，让它做「对照清单逐条核对」，不是凭感觉挑刺。

展开表达：

  • checklist 沉淀团队踩过的坑，例如异常态、边界态、空数据、权限、埋点、兜底文案、多端差异。
  • AI 的任务从开放式找茬，收敛成闭合式核对。
  • 这样做的价值是让信噪比可控，而不是完全依赖模型能力。

面试陷阱：不要说「AI 很聪明能发现问题」。面试官真正关心的是你如何约束模型、降低噪音、保证可复用。

Q2：「与现有项目冲突」的上下文从哪来？

一句话回答：靠检索和相关模块上下文注入，不是把整个代码库塞进模型。

展开表达：

  • 先根据 PRD 涉及的业务域，圈定可能相关的模块。
  • 检索现有接口、数据结构、路由、组件约定和历史实现。
  • 将高相关上下文注入模型，让它做冲突比对。
  • 真正难点在检索精度和上下文窗口之间的平衡。

面试陷阱：这是工程硬问题。能讲清检索策略就能拉开差距；如果现阶段还没完全自动化，可以诚实表达为「当前基于模块手动圈定范围，正在向自动检索演进」。

Q3：流程看起来像线性瀑布，PRD 一直在变怎么办？

一句话回答：spec 支持局部更新，不是每次改需求都全链路重跑。

展开表达：

  • PRD 变更会映射到对应的 spec 片段。
  • 只重跑受影响的 spec、任务拆分和代码生成环节。
  • 增量粒度可以先按模块或功能点切分，后续再细化到接口、页面、组件级。

面试陷阱：这是最容易暴露「只做了 demo」的问题。至少要准备一个可落地的增量方案，例如按 spec 模块粒度做影响范围分析。

Q4：为什么必须有 spec 这一层？直接 PRD 到 Code 不行吗？

一句话回答：spec 是人能 review、AI 能执行的中间契约，把缺陷拦截点左移到最便宜的阶段。

展开表达：

  • 直接 PRD 到 Code 是黑盒，人很难在编码前纠偏。
  • 有了 spec，需求、边界、接口、状态和验收标准会被显式化。
  • 人可以在 spec 阶段 review，AI 也可以按明确契约执行。
  • 错误越早发现，修复成本越低。

面试陷阱：重点不是「spec 看起来更规范」，而是「缺陷左移」和「人机对齐」的工程价值。

Q5：效果怎么度量？周期缩短 30%、AI 代码占 40% 怎么算？

一句话回答：用同类历史项目作为明确基线，并且把返工成本算进去。

展开表达：

  • 周期缩短：比较从需求确认到可交付的端到端时间。
  • AI 代码占比：AI 生成且最终合入的代码行 / 新增代码行。
  • 质量保障：配套 review、测试、返工率和人工修改率统计。
  • 避免只统计生成量，而忽略后续修复成本。

面试陷阱：一定会被追问统计口径和返工。需要准备「AI 代码返工率 / 人工修改率」这类质量指标，否则 40% 的数字容易被怀疑注水。

为什么不用 OpenSpec / Superpowers 这类现成框架？

临场先确认面试官具体指的是哪个框架。OpenSpec、Superpowers、spec-kit、Kiro 的定位不完全一样，避免答错对象后被追问细节。

一句话回答：现成框架解决的是通用流程编排，而真正的壁垒在它给不了的地方：领域 checklist、自有代码库冲突检测、团队研发规范。

四点论证

  1. 场景特异性
    通用框架通常面向通用研发流程。我们最难、最有价值的部分，是贴合客户端 Flutter / Native 混合架构、历史包袱和团队规约，这些需要结合业务自研沉淀。

  2. 集成成本与控制力
    把现成框架接入现有 PRD 系统、代码库、CI、review 流程，改造成本不一定低。每个节点的 prompt、checklist、产物格式和校验规则都需要可控、可调试、可优化。

  3. 可演进性
    团队需要根据真实反馈高频迭代流程节点和清单。自研可以完全掌控演进节奏，而外部框架会受制于版本、抽象边界和设计取向。

  4. 理性借鉴，不排斥复用
    不是为了造轮子而造轮子。spec-driven 的理念本身就值得借鉴，我们吸收的是思想，在工程实现上做贴合自身场景的取舍，底层组件仍然可以复用。

面试姿态：不要贬低开源框架。更稳的表达是：「我评估过这些方案，清楚它们的边界，所以做了理性的 build-vs-buy 决策。」

流程如何持续迭代？模型升级后如何保证更好？

一句话回答：没有评估集就没有迭代。有 eval 才有底气说升级后是变好，而不是凭感觉判断。

迭代体系

  1. 评估集 / 回归基准
    建立标注样本，例如「PRD -> 期望发现的漏洞 / 期望的 spec / 期望的代码」。每次改 prompt 或换模型，都跑同一套 eval。

  2. 关键指标
    关注漏洞召回率、误报率、spec 完整度、代码可用率、返工率和人工修改率。

  3. Prompt / 流程与模型解耦
    模型应该可插拔。换模型后要重跑 eval 调参，同时警惕旧 prompt 对旧模型的 workaround 变成新模型的负担。

  4. A/B 与灰度
    模型升级不一刀切，在真实流程里灰度对比新老模型的产出质量和人工返工率。

  5. 数据飞轮
    将 PM 澄清记录、人工 review 改动、返工 badcase 沉淀下来，反哺 checklist 和 eval 集。

  6. 分层抽象，降低模型依赖
    审查靠 checklist，拆分靠模板，产物靠 schema 校验。任务越结构化，对单一模型能力的依赖越低。

  7. 输出契约稳定
    保持产物格式、schema 校验和人工卡点稳定。底层模型可以变化，但对下游的接口不应频繁变化。

面试陷阱：大概率会被追问「eval 集怎么标、多大、谁标」。可以回答：初期人工标几十到上百条典型 case 作为种子集，优先覆盖高频和高风险场景，后续用线上 badcase 持续扩充。

电梯陈述

PRD2Code 的设计哲学是把缺陷拦截点尽量左移，spec 是人机对齐的契约。难点不在流程图，而在三件事：怎么让 AI 审查不产生噪音，靠 checklist 约束；怎么把现有代码库上下文喂给它，靠检索注入；以及怎么支持增量和模型迭代，靠 spec 粒度拆分和 eval 基准。

临场 Checklist

  • 先讲工程约束，再讲模型能力。
  • 强调 spec 的价值是「人能 review、AI 能执行」。
  • 提前准备增量更新方案，避免被认为只是 demo。
  • 指标必须包含返工率和人工修改率。
  • 谈现成框架时保持理性 build-vs-buy 姿态。
  • 谈模型升级时先说 eval，再说 A/B、灰度和数据飞轮。