标准答案
- 题目要有具体业务场景，例如表格筛选、权限菜单、灰度发布、监控接入或组件库迁移。
- 要明确约束条件，例如时间、团队规模、旧系统包袱、浏览器兼容、接口稳定性和上线风险。
- 要允许候选人提出方案、风险、验证方式和回滚计划，而不是只输出唯一代码答案。
- 评分重点应覆盖问题拆解、数据模型、状态边界、异常处理、测试验证、性能和可维护性。
- 开放题要避免过度发散，可以设置阶段目标和追问点，让回答保持可评估。
题目解析
真实工程能力很难靠一道语法题看出来。开放题更适合观察候选人如何澄清需求、识别风险、设计边界、安排验证，以及在不完美约束下做取舍。
好题目不是越大越好。比如“设计一个后台表格页”太泛，可以改成“在已有 Vue 项目里实现订单列表筛选、分页、URL 同步和权限按钮，要求支持回退和测试”。这样回答才有落点。
开放题也要有评价标准。否则面试会变成聊天，候选人说什么都像对。评分维度应提前定义，围绕工程结果而不是术语密度。
代码示例
开放题可以用场景、约束和观察点组织。
Text
scenario:
existing admin project needs an order table refactor
constraints:
old API, role permissions, URL sync, no full rewrite
ask:
design state model, component split, error handling, tests, rollout plan
observe:
tradeoffs, edge cases, verification, rollback常见误区
- 题目只有“实现一个复杂系统”，没有业务约束和评价标准。
- 只考候选人知道哪些工具名，不看如何落地和验证。
- 开放题没有收束点，候选人无法判断回答深度。