1. 常见的问题1.1 你在 vibe coding 的实践是如何进行的1.2 场景题目 让你设计一个vibe coding 设计一个复杂的系统2. 面试专用2.1 TraceT target 目标需求需求分析R read 读懂已有的系统存量系统A Architect 解决方案设计任务拆解架构设计详细设计对应传统工程的 数据库、接口设计C cycle 循环代码单元测试E evicence 验收代码审核、整个系统的测试替换名称Goal、 Ayalysis/understand、Task、iterate2.2 Target 需求分析你是如何和agent 讨论需求的你是如何确定你的需求已经讨论清楚的2.2.1 捋清楚需求的方法论 clear面试官问 你是怎么捋清楚需求的有一个叫clear 的方法论c 代表上下文主要是一个背景、目标。limit 主要定义范围和边界examples 给大模型提供正面案例、反面案例以及边界案例。然后 acceptance 主要验收标准最后是Risk rules 强调 不能违背业务规则 和风险控制2.2.1.1 contextC context你 的需求的背景 以及说对应的目标问题agent 在交流成功中它理解的核心业务问题是什么2.2.1.2 limitlimit 定义范围和边界这一期要做什么不要做什么系统边界是什么面试强调我的limit主要强调 需求的范围和边界告诉agent 总结 这一次迭代要达成什么样的地步。2.2.1.3 examlpes正面案例 和反面案例 边界案例原本没有反面案例 边界案例 效果不好后面加入了 取得了效果线上回流线下在 vibe coding 中 不断收集该需求的案例补充给agent。提供案例给大模型然后大模型写案例。 看大模型写的对不对2.2.1.4 Acceptance在给定条件下当用户执行某些操作的时候 会发生什么(系统执行了什么动作内部状态会修改到什么状态)定义验收标准是可以观察的2.2.1.5 R rule risk规则和风险业务中必须遵守的规则风险控制识别出来实现的东西 要面对的风险2.2.2 你怎么确定你的agent 是捋清楚你的需求了简单需求 让agent 复述一下然后人为判定。如果是复杂需求输出文档太长需要重新考虑通用解答让Agent 一句话总结出你的目标让Agent 讲清楚本期的范围边界 做什么、不做什么 核心依赖关键名词、业务词汇 都有明确的解释业务流程完备Agent 有没有理解我提出的所有流程 ·也就是 给出的 和自己 想的是否完备正常流程、异常流程 考虑借鉴测试中的分支覆盖 功能不会丢·业务规则能够清晰表达·- 结构化表达 伪代码表达 、或者 给出案例说的对不对最直观的体现 agent给出流程图、验收规则直接转测试2.2.3 举一个你和多轮对话的例子第一轮 提供业务的背景和目标让Agent 复述。复述是否清晰第二轮 你要让agent 输出它的问题包括 隐含的假设、规则冲突、需要确认的问题、跟验收有关的问题让Agent 提问。第三轮 在Agent提问后 补充额外信息 、其他信息第四轮 你可以举一些例子 也可以让Agent 举一些例子第五轮 生成结构化的文档 生成所谓的specs-- 需求规格说明设计一个spec的格式模板spec 的格式模板有独到之处第六轮 让agent 找spec的漏洞2.3 Read agent 理解已有业务2.3.1 agent 理解系统 究竟理解什么东西?2.3.1.1 理解系统架构2.3.1.2. 理解和你这一次要做的事情的链路。判断相关链路的修改范围2.3.1.3. 相似实现 主要是具备参考价值比如说典型需求管理后台b端页面后台b端c端后台前端页面c端页面Agent 参考这个东西 基本上每次都能帮我把这三个地方都改好2.3.1.4. 工程规范除了读已有的文档还要自己总结文档代码风格2.3.1.4.1 你怎么确保 agent一定按照你的规范去研发呢事前强调事后检查 - 开发完后 用一个特定的skill 检查2.3.1.4.2 人写代码规范和agent 代码规范的区别当前主流是直接用 人的规范 去要求agent的规范agent 的规范可以很详细执行起来很琐碎。Agent 要防止 规范被过度执行/根本听不下来考虑执行时间、消耗资源2.3.1.5.树理系统上下文、项目上下文输出一些文档比如说 业务内容2.3.1.6 agent 区分事实和推测推测 结合代码 文档、说明 推测出一些内容。要注意推测的证据2.3.2. 怎么让Agent理解系统 mccqt5 步走 mccqt2.3.2.1. 建立系统地图 map m看目录结构、模块划分、服务职责、技术栈系统概览2.3.2.2 走一遍链路 chain核心链路 项目的核心相关链路 任务相关的链路也就是调用关系2.3.2.3 输出结论 并且绑定证据 conclusion事实还是推测都需要都证据。不能胡编乱造最好都能找到 设计的证据、代码证据结论事实推测未知agent 找我澄清2.3.2.4 反向提问验证 questionAgent觉得理解之后你可以向它提问你可以把这个东西 (提问的东西)做成一个列表每次新需求agent 理解完成后问它对不对 理解是否准确2.3.2.5 可以让agent 做一个假修改 try假设让你去实现一个xx 功能你会修改哪些地方。来判断agent 是否理解了。2.3.3. 你怎么判断agent 真 理解系统了能解释 业务链路能理解系统状态以及系统变迁的条件能预测修改的范围 Agent-VibeCoding
1. 常见的问题1.1 你在 vibe coding 的实践是如何进行的1.2 场景题目 让你设计一个vibe coding 设计一个复杂的系统2. 面试专用2.1 TraceT target 目标需求需求分析R read 读懂已有的系统存量系统A Architect 解决方案设计任务拆解架构设计详细设计对应传统工程的 数据库、接口设计C cycle 循环代码单元测试E evicence 验收代码审核、整个系统的测试替换名称Goal、 Ayalysis/understand、Task、iterate2.2 Target 需求分析你是如何和agent 讨论需求的你是如何确定你的需求已经讨论清楚的2.2.1 捋清楚需求的方法论 clear面试官问 你是怎么捋清楚需求的有一个叫clear 的方法论c 代表上下文主要是一个背景、目标。limit 主要定义范围和边界examples 给大模型提供正面案例、反面案例以及边界案例。然后 acceptance 主要验收标准最后是Risk rules 强调 不能违背业务规则 和风险控制2.2.1.1 contextC context你 的需求的背景 以及说对应的目标问题agent 在交流成功中它理解的核心业务问题是什么2.2.1.2 limitlimit 定义范围和边界这一期要做什么不要做什么系统边界是什么面试强调我的limit主要强调 需求的范围和边界告诉agent 总结 这一次迭代要达成什么样的地步。2.2.1.3 examlpes正面案例 和反面案例 边界案例原本没有反面案例 边界案例 效果不好后面加入了 取得了效果线上回流线下在 vibe coding 中 不断收集该需求的案例补充给agent。提供案例给大模型然后大模型写案例。 看大模型写的对不对2.2.1.4 Acceptance在给定条件下当用户执行某些操作的时候 会发生什么(系统执行了什么动作内部状态会修改到什么状态)定义验收标准是可以观察的2.2.1.5 R rule risk规则和风险业务中必须遵守的规则风险控制识别出来实现的东西 要面对的风险2.2.2 你怎么确定你的agent 是捋清楚你的需求了简单需求 让agent 复述一下然后人为判定。如果是复杂需求输出文档太长需要重新考虑通用解答让Agent 一句话总结出你的目标让Agent 讲清楚本期的范围边界 做什么、不做什么 核心依赖关键名词、业务词汇 都有明确的解释业务流程完备Agent 有没有理解我提出的所有流程 ·也就是 给出的 和自己 想的是否完备正常流程、异常流程 考虑借鉴测试中的分支覆盖 功能不会丢·业务规则能够清晰表达·- 结构化表达 伪代码表达 、或者 给出案例说的对不对最直观的体现 agent给出流程图、验收规则直接转测试2.2.3 举一个你和多轮对话的例子第一轮 提供业务的背景和目标让Agent 复述。复述是否清晰第二轮 你要让agent 输出它的问题包括 隐含的假设、规则冲突、需要确认的问题、跟验收有关的问题让Agent 提问。第三轮 在Agent提问后 补充额外信息 、其他信息第四轮 你可以举一些例子 也可以让Agent 举一些例子第五轮 生成结构化的文档 生成所谓的specs-- 需求规格说明设计一个spec的格式模板spec 的格式模板有独到之处第六轮 让agent 找spec的漏洞2.3 Read agent 理解已有业务2.3.1 agent 理解系统 究竟理解什么东西?2.3.1.1 理解系统架构2.3.1.2. 理解和你这一次要做的事情的链路。判断相关链路的修改范围2.3.1.3. 相似实现 主要是具备参考价值比如说典型需求管理后台b端页面后台b端c端后台前端页面c端页面Agent 参考这个东西 基本上每次都能帮我把这三个地方都改好2.3.1.4. 工程规范除了读已有的文档还要自己总结文档代码风格2.3.1.4.1 你怎么确保 agent一定按照你的规范去研发呢事前强调事后检查 - 开发完后 用一个特定的skill 检查2.3.1.4.2 人写代码规范和agent 代码规范的区别当前主流是直接用 人的规范 去要求agent的规范agent 的规范可以很详细执行起来很琐碎。Agent 要防止 规范被过度执行/根本听不下来考虑执行时间、消耗资源2.3.1.5.树理系统上下文、项目上下文输出一些文档比如说 业务内容2.3.1.6 agent 区分事实和推测推测 结合代码 文档、说明 推测出一些内容。要注意推测的证据2.3.2. 怎么让Agent理解系统 mccqt5 步走 mccqt2.3.2.1. 建立系统地图 map m看目录结构、模块划分、服务职责、技术栈系统概览2.3.2.2 走一遍链路 chain核心链路 项目的核心相关链路 任务相关的链路也就是调用关系2.3.2.3 输出结论 并且绑定证据 conclusion事实还是推测都需要都证据。不能胡编乱造最好都能找到 设计的证据、代码证据结论事实推测未知agent 找我澄清2.3.2.4 反向提问验证 questionAgent觉得理解之后你可以向它提问你可以把这个东西 (提问的东西)做成一个列表每次新需求agent 理解完成后问它对不对 理解是否准确2.3.2.5 可以让agent 做一个假修改 try假设让你去实现一个xx 功能你会修改哪些地方。来判断agent 是否理解了。2.3.3. 你怎么判断agent 真 理解系统了能解释 业务链路能理解系统状态以及系统变迁的条件能预测修改的范围