想象你走进一家私房菜馆，大厨厨艺精湛，但你只说了一句“随便做点好吃的”。端上来的可能是麻辣水煮鱼——你说“家里人过寿，广东口味，要一道清蒸鲈鱼，少油少盐，摆盘精致”，端上来的就成了惊喜。AI 前端生成工具 V0 就是这位大厨：它会做一万道菜，但你必须告诉它做哪一道、怎么做。提示工程是“点菜的语言”，迭代优化是“试菜—反馈”的循环。这篇文章用七步方法论，带你学会角色设定、组件约束、风格描述、多轮修正、需求收敛、质量把控与复用沉淀，把一句“做个后台页面”变成结构清晰、可维护、可复用的漂亮代码。

岗位关联

V0 提示工程是 AI 前端落地的核心杠杆：能把“模糊想法”变成“一次生成、少走弯路”的可靠代码，帮你告别反复手写重来，是 AI 时代前端工程师必学的提效技能。

目录
  1. 可视化演示
  2. 角色设定技巧（思维导图分支 1）
  3. 组件约束方法（思维导图分支 2）
  4. 风格描述要点（思维导图分支 3）
  5. 多轮修正策略（思维导图分支 4）
  6. 需求收敛流程（思维导图分支 5）
  7. 代码质量把控（思维导图分支 6）
  8. 复用优化技巧（思维导图分支 7）
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示V0提示工程的多轮迭代优化过程：从模糊需求出发，通过角色设定、组件约束与风格描述逐步收敛为结构清晰的UI代码。支持迭代流水线与提示策略对比切换。

本节配有交互动效（进入视口后自动加载，约 3KB）。

V0提示工程迭代优化流程 模糊需求经多轮提示优化收敛为结构化代码 角色设定与组件约束提升代码质量 Q(k+1)=refine(Q(k),R(k)) 迭代优化提示质量

角色设定技巧（思维导图分支 1）

去私房菜馆，第一句话往往不是点菜，而是报家门——“我是广东人”“今晚给老人过寿”。大厨一听就懂了：粤菜、清淡、软烂。如果什么都不说，他只能用自己最拿手的川菜招呼你。V0 也一样，它默认自己是“通用前端助手”，而“通用”往往等于“平庸”。

角色设定，就是 prompt 里最前面的那几句“报家门”。它告诉 V0：你要以什么身份工作、为谁设计、在什么技术栈下产出。这几句话不直接画任何像素，却决定了 V0 后续所有判断的基准，就像报家门决定了后厨的整个备菜方向。

具体来写，角色设定包含四个要素：身份明确（“你是一位专注移动端体验的资深前端工程师”）、受众描述（“产品面向 50 岁以上用户，字号需偏大”）、技术栈指定（“基于 React 18 + TypeScript + Tailwind CSS 实现”）、语气引导（“代码注释用中文，命名克制”）。四者共同构成角色设定的完整闭环。

报家门报得越准，大厨端上的菜就越接近你心里那盘；角色设定写得越全，V0 产出的代码就越贴近你团队的水准线。

T=Rid×Raud×Rstack\displaystyle T = R_{\mathrm{id}} \times R_{\mathrm{aud}} \times R_{\mathrm{stack}}
需求传达率 T 等于角色明确度、受众清晰度、技术栈匹配度三项的乘积。乘法意味着每一项都不可或缺——任何一项为零，整体就为零。
  1. 角色明确度 R_id指“你是一位什么样的工程师”这句自我定位。定位越清晰，模型调用领域经验的路径越准确。
    Rid>0\displaystyle R_{\mathrm{id}} > 0
  2. 受众清晰度 R_aud指目标用户的描述。没有受众，就没有设计决策的准绳，字号、配色、交互全都失去依据。
    Raud=f(用户画像描述质量)\displaystyle R_{\mathrm{aud}} = f(\text{用户画像描述质量})
  3. 技术栈匹配度 R_stack指框架、语言、样式方案的指定，直接决定输出代码能否在当前工程里落地。
    Rstack=g(技术约束完整性)\displaystyle R_{\mathrm{stack}} = g(\text{技术约束完整性})
  4. 乘积关系三项相乘而非相加，意味着任何一项缺失，整体传达率都会归零，正如不知道“为谁做菜”，再好的手艺也会跑偏。

组件约束方法（思维导图分支 2）

点菜不只要说“清蒸鲈鱼”，还要说“一斤二两的鲈鱼，配葱丝姜丝，蒸八分钟”。主菜、配菜、汤的结构定了，后厨才不会手忙脚乱。V0 面对“做个后台页面”这种话，就像听到“随便”，只能按一个平淡的模板糊弄过去。

组件约束，是告诉 V0 页面由哪些模块构成、每个模块的职责和关系。它把“页面”这个抽象概念拆成一道道可落地的“菜”，让模型不用猜“后台到底有什么”。

写组件约束时看四个维度：组件粒度（拆到可独立复用的最小单元，如“订单卡片”“状态徽章”）、布局结构（栅格列数、间距、对齐）、数据绑定（每个组件显示哪些字段，如订单号、金额、状态）、交互行为（点击跳转、悬停提示、加载骨架、空状态插画）。

菜单结构越明确，后厨出菜越稳；组件约束越具体，V0 的输出越接近可用的“成品盘”。

Q=w1G+w2L+w3D+w4I,∑i=14wi=1\displaystyle Q = w_1 G + w_2 L + w_3 D + w_4 I, \qquad \sum_{i=1}^{4} w_i = 1
组件质量 Q 是粒度、布局、数据、交互四项的加权平均。权重代表你对某个维度的重视程度，但四项总和必须为 1。
  1. 组件粒度 G组件拆得越细，越容易独立复用和局部修正，它是质量的基础分。
    G=可复用组件数组件总数\displaystyle G = \frac{\text{可复用组件数}}{\text{组件总数}}
  2. 布局结构 L描述栅格、间距与对齐方式，决定页面是否规整、信息是否清晰。
    L=符合布局约束的区域数总区域数\displaystyle L = \frac{\text{符合布局约束的区域数}}{\text{总区域数}}
  3. 数据绑定 D组件与数据字段的对应关系越明确，生成的代码越不需要二次改数据流。
    D=1−未绑定字段数总字段数\displaystyle D = 1 - \frac{\text{未绑定字段数}}{\text{总字段数}}
  4. 权重和约束四个权重之和为 1，你可以根据场景调权——比如后台系统更重视数据绑定，营销页更重视布局结构。

风格描述要点（思维导图分支 3）

同一道清蒸鲈鱼，米其林餐厅和街边大排档的摆盘天差地别。口味也有清淡与咸鲜之分。大厨需要知道你的“味觉偏好”，V0 则需要知道你的视觉偏好——这就是风格描述存在的意义。

风格描述是 prompt 的“调味层”，解决“好不好看、统不统一”的问题。没有它，V0 可能给你生成一版蓝色商务风，下一版又变成紫色渐变科技风，同一套页面像两个设计师各做一半。

写风格描述时，聚焦四类信息：视觉关键词（极简、圆润、科技感、温暖）、参考风格（“类似 Linear 的暗色质感”“接近 Notion 的留白风格”）、色彩规范（直接给色值：主色 #818CF8、辅色、成功色、警示色）、排版细节（字号层级、字重、行高、圆角半径）。

把口味描述清楚，每桌菜才都像同一家店出的；把风格描述清楚，每个页面才像同一个设计师做的。

M=∑i=1nwisi,0≤si≤1,∑i=1nwi=1\displaystyle M = \sum_{i=1}^{n} w_i s_i, \qquad 0 \le s_i \le 1, \quad \sum_{i=1}^{n} w_i = 1
风格匹配度 M 是所有风格描述项落实程度的加权和。每条描述 s_i 越接近 1，说明 V0 越忠实地还原了你的视觉要求。
  1. 每条风格项的落实度 s_i例如“圆角 8px”这条描述，如果 V0 全部卡片都用了 8px 圆角，则 s_i = 1。
    si=符合该描述的元素数相关元素总数\displaystyle s_i = \frac{\text{符合该描述的元素数}}{\text{相关元素总数}}
  2. 权重 w_i重要描述给更高权重，比如品牌主色权重高、辅助装饰权重低。
    0≤wi≤1,∑i=1nwi=1\displaystyle 0 \le w_i \le 1, \quad \sum_{i=1}^{n} w_i = 1
  3. 求和把每条描述的落实度乘上权重再累加，得到一个 0 到 1 之间的总体匹配分。
    M∈[0,1]\displaystyle M \in [0, 1]

多轮修正策略（思维导图分支 4）

第一口鱼入口，你发现咸了。聪明的客人不会说“重做一桌”，而是说“这道菜少放半勺盐，其他菜先别动”。大厨一听就懂，五分钟端回来一盘恰到好处的鱼。多轮修正，就是“试菜—回锅”的循环。

V0 一次生成的代码极少完美，真正的高手靠的是第二轮、第三轮的精准反馈。第一版是原型，不是终稿——你用反馈引导它，就像用筷子引导大厨调整咸淡。

多轮修正有四个标准动作：问题定位（“导航栏在高亮态下文字对比度不足”）、增量修改（一次只改一个点）、保留有效（“其余部分保持不变”）、回归测试（改完后检查是否破坏其他区域）。

试菜不是重做，是让大厨每次都只多走半步；迭代不是推翻，是让 V0 每次都只改一点点，把误差一步步逼近零。

En=E0n+1\displaystyle E_n = \frac{E_0}{n + 1}
偏差衰减公式：假设每轮修正都能精准消除当前的主要偏差，那么第 n 轮后的偏差 E_n 会按 (n+1) 分之一递减——这正是“迭代越多越接近目标”的数学直觉。
  1. 初始偏差 E_0第一版代码与目标之间的差距，差距越大需要修正的轮次越多。
    E0=首版与目标的差距\displaystyle E_0 = \text{首版与目标的差距}
  2. 轮次 n每完成一轮“反馈—修改”，n 就增加 1。
    n∈{0,1,2,… }\displaystyle n \in \{0, 1, 2, \dots\}
  3. 衰减关系偏差与轮次成反比，第 1 轮后剩一半，第 3 轮后剩四分之一。前提是每轮都精准定位最大问题——这正是“一次只改一个点”策略的价值。
    E1=E02,E3=E04\displaystyle E_1 = \frac{E_0}{2}, \quad E_3 = \frac{E_0}{4}

需求收敛流程（思维导图分支 5）

“随便吃点”是永远做不出好菜的。真正会吃的人会一步步把想法收拢：今天想吃鱼 → 清蒸 → 鲈鱼 → 葱丝姜丝 → 配一盅冬瓜汤。收敛，是从模糊到清晰的必经之路。你给 V0 的需求越收敛，它生成的代码越接近成品。

需求收敛，是把“做个官网”这种抽象目标，变成一份 V0 可以直接执行的“菜单”。它发生在写 prompt 之前，决定了你交给 V0 的起点有多清晰。

收敛分四步：目标拆解（把“个人主页”拆成导航、英雄区、作品集、联系表单）、优先级排序（MVP 只做核心三块，其余标注“后续版本”）、验收标准（“375px 宽度下无横向滚动”“首屏加载小于 2 秒”）、迭代循环（每轮交付后对照验收标准复查，不达标就进入下一轮修正）。

菜单定了，后厨才能有条不紊；需求收敛了，V0 才能一次生成更接近成品的代码，而不是反复浪费时间和 token 试错。

D=1−UT\displaystyle D = 1 - \frac{U}{T}
需求清晰度 D 等于 1 减去“未决事项占比”。待办清单里未决项 U 越少，总需求项 T 越明确，D 就越接近 1——需求越收敛，V0 越不容易跑题。
  1. 总需求项 T把所有想表达的需求列成清单，比如导航、英雄区、联系表单各算一项。
    T=需求清单总项数\displaystyle T = \text{需求清单总项数}
  2. 未决事项 U尚未确定方案的需求，比如“联系表单用什么字段还没定”，每项都算未决。
    U=未决需求项数\displaystyle U = \text{未决需求项数}
  3. 占比与补集U/T 是未决比例，1 减去它得到“已决比例”，也就是需求清晰度。
    U≤T,D∈[0,1]\displaystyle U \le T, \quad D \in [0, 1]

代码质量把控（思维导图分支 6）

一道菜好吃还不够，好餐厅会把菜谱标准化，换一个厨师也能做出九成的味道。V0 生成的代码要可靠可维护，也需要“标准菜谱”级的质量底线。否则它生成的东西短期能跑，三个月后自己和同事都改不动。

质量把控，是验收 V0 输出时的四道关卡。语法正确只是及格线，真正决定代码命运的，是这四关过不过得去。

四关分别是：可读命名（点击提交按钮的处理函数叫 handleSubmit，而不是 fn2）、结构清晰（组件拆分合理、无无谓嵌套、无 500 行大组件）、注释完整（复杂逻辑配注释，说明“为什么这么做”）、防御编程（空数组、空对象、加载失败都有兜底 UI，不白屏）。

菜谱能复现才是好菜谱，代码能维护才是好代码。把好四关，你的项目才经得起三个月后的自己回看。

M=R+S+C+D4\displaystyle M = \frac{R + S + C + D}{4}
可维护性 M 是可读命名、结构清晰、注释完整、防御编程四项的算术平均。任何一项拖后腿，整体维护体验都会被拉低。
  1. 可读性 R变量与函数命名是否语义化，读代码像读句子一样顺畅。
    R=语义化命名占比1\displaystyle R = \frac{\text{语义化命名占比}}{1}
  2. 结构性 S组件层次是否清晰、依赖方向是否单一。
    S=合格拆分的组件数组件总数\displaystyle S = \frac{\text{合格拆分的组件数}}{\text{组件总数}}
  3. 注释完整度 C关键逻辑是否有注释解释意图。
    C=关键逻辑带注释处关键逻辑总数\displaystyle C = \frac{\text{关键逻辑带注释处}}{\text{关键逻辑总数}}
  4. 防御性 D异常路径有无兜底处理。
    D=有兜底的边界场景数边界场景总数\displaystyle D = \frac{\text{有兜底的边界场景数}}{\text{边界场景总数}}

复用优化技巧（思维导图分支 7）

好餐厅都有一个“配方库”，热卖菜式的工艺卡保存在册，新店开张直接照做。你为 V0 辛苦调教出来的提示词和组件，也应该变成这样的配方库——否则每道菜都从零研发，每次对话都从零开始。

复用优化，是把一次性的成功变成长期资产。它的核心思想是：让你调教过的 prompt 和代码，在下一个项目里继续发光。

具体做法有四条：组件抽取（把通用卡片、空状态、加载骨架从页面里剥出来独立成组件）、参数配置（用 props 配置替代写死，一个组件适配多种场景）、模板沉淀（把验证过的高质量 prompt 存成团队模板）、文档记录（在模板旁标注适用场景、典型坑位和版本变更）。

配方库越厚，新菜出得越快；复用率越高，下一个页面就从“请 V0 吃饭聊天”变成“翻出模板直接改”，省下的都是实实在在的时间。

Rreuse=CreuseCtotal\displaystyle R_{\text{reuse}} = \frac{C_{\text{reuse}}}{C_{\text{total}}}
组件复用率 R 是“被复用的组件数”占“组件总数”的比例。复用率越高，新页面的开发成本越低——这正是配方库的价值。
  1. 复用组件数 C_reuse已被两个以上页面使用的组件数量，比如被复用的订单卡片、状态徽章。
    Creuse=被复用的组件数\displaystyle C_{\text{reuse}} = \text{被复用的组件数}
  2. 组件总数 C_total整个项目里沉淀下来的全部组件数量。
    Ctotal=组件总数\displaystyle C_{\text{total}} = \text{组件总数}
  3. 比例关系复用率越接近 1，说明组件资产越健康，新需求主要在“组装”而非“新写”。
    0≤Rreuse≤1\displaystyle 0 \le R_{\text{reuse}} \le 1

AI 应用场景

SaaS 后台管理界面快速搭建

阶段：前端代码生成

解决的问题：传统方式从零手写一个订单管理后台需要 2~3 天，且视觉难以统一。程序员把大量时间花在重复的表格、表单、弹窗上，而不是业务逻辑本身。用 V0 + 角色设定 + 组件约束，首次生成时间压缩到小时级。

具体案例：在 V0 中写入“你是一位移动优先的中后台专家，用户是运营人员。生成订单列表页，包含顶部导航、筛选栏、订单卡片、分页器，订单状态用绿色/红色徽章表示”。一次生成后，再通过两轮修正补上空状态插画和加载骨架。

设计稿到代码的落地衔接

阶段：提示工程

解决的问题：设计与开发交接时，视觉规范大量丢失——色值靠人肉对比、圆角靠经验猜测。把 Figma 里的色值、圆角、字号写进风格描述，相当于把设计稿的“口味”原封不动地告诉大厨。

具体案例：团队把品牌色 #818CF8、圆角 8px、字号层级整理成一段标准风格描述，复制进每个 V0 对话的开头。生成结果与设计稿的一致性显著提升，返工次数从平均 5 次降到 1 次。

团队提示词配方库沉淀

阶段：维护迭代、知识管理

解决的问题：每次和 V0 对话都从零开始，质量和风格飘忽不定。把经过验证的高复用 prompt 沉淀成团队“配方库”，让新人也能照方抓药。

具体案例：前端小组维护一份 V0 提示词手册，包含角色模板、组件清单、风格段落和 10 个踩坑案例。新成员照着手册写 prompt，第一次生成的质量就达到团队平均水平，Code Review 修改量下降 40%。

Python 演示

python52 行
# -*- coding: utf-8 -*-"""V0 提示词模板与多轮迭代工具"""  class V0Prompt:    """把角色、受众、技术栈、组件约束组装成结构化提示词"""     def __init__(self, role, audience, stack, style):        self.role = role        self.audience = audience        self.stack = stack        self.style = style        self.components = []        self.history = []     def add_component(self, name, detail=""):        """追加一个组件约束，detail 描述布局与数据绑定"""        self.components.append({"name": name, "detail": detail})     def build(self):        """拼装最终提示词，返回可直接发给 V0 的文本"""        lines = [            "你是一位" + self.role + "。",            "目标用户：" + self.audience + "。",            "技术栈：" + self.stack + "。",            "视觉风格：" + self.style + "。",            "页面组件约束：",        ]        for comp in self.components:            lines.append("- " + comp["name"] + "：" + comp["detail"])        return "\n".join(lines)     def revise(self, feedback):        """记录一条反馈，并生成带反馈的下一轮提示词"""        self.history.append(feedback)        return self.build() + "\n\n【上一轮反馈】\n" + feedback  if __name__ == "__main__":    prompt = V0Prompt(        "资深前端工程师",        "50 岁以上中老年用户",        "React 18 + TypeScript + Tailwind",        "大字号、低对比度、圆角卡片、温和蓝色",    )    prompt.add_component("顶部导航", "横排展示首页/订单/设置，字号 18px")    prompt.add_component("订单卡片", "展示订单号、金额、状态徽章，支持点击")    prompt.add_component("空状态", "无订单时显示插画与引导按钮")    print("===== 第 1 轮提示词 =====")    print(prompt.build())    print("===== 第 2 轮修正 =====")    print(prompt.revise("卡片间距再大一些，空状态插画换成暖色系"))
目的：用 Python 结构化管理 V0 提示词——先按角色设定、受众、技术栈、风格组装第一轮提示词，再通过反馈追加多轮修正，完整演示“结构化拼装 + 迭代优化”的工作流。
  1. self.components = []用列表保存组件约束，按添加顺序生成“页面组件约束”段落，对应正文中的组件约束方法。
  2. lines.append("- " + comp["name"] + "：" + comp["detail"])把每个组件约束渲染成列表项，让 V0 能逐条识别，避免长段落里信息被淹没。
  3. return "\n".join(lines)用换行拼装最终文本。角色、受众、技术栈、风格各占一行，正是正文强调的“结构化短句”策略。
  4. prompt.revise("卡片间距再大一些，空状态插画换成暖色系")调用修正方法，在下一轮提示词末尾追加“上一轮反馈”，模拟多轮修正策略中的增量修改。
  5. if __name__ == "__main__":提供可执行入口，直接运行即可看到第 1 轮与第 2 轮提示词的对比输出。

常见误区

误区“我写两千字的详细需求，V0 一定比一百字的生成得更好。我要把所有细节都塞进去。”

正解提示词越长，关键约束越容易被稀释，模型的注意力被无关细节分散。有效提示词是“结构化短句”：角色、约束、风格、验收各占一行，每行一个明确指令。就像点菜，说“清蒸鲈鱼，少油少盐”比背一整本菜单有用——大厨记不住那么多，V0 也一样。

为何常见：大家习惯把“认真”等同于“写得长”，但大模型对开头的角色句和末尾的验收句最敏感，中间淹没的细节往往被忽略。

误区“如果第一版不满意，说明 V0 不行，换个工具试试。好工具应该一次到位。”

正解第一版只是原型，迭代才是正常流程。精准指出“某组件某属性的问题”，保留其余有效部分，两三轮后质量会明显收敛，而且偏差按轮次递减。就像试菜，让大厨微调比换一家餐厅成本低得多——换工具意味着丢失所有上下文。

为何常见：人对“工具应该一次到位”有天然期待，加上演示视频都是剪辑过的顺利过程，掩盖了真实工作中多轮打磨的常态。

误区“风格描述写点形容词就够了，功能逻辑才重要。什么极简、高级都是虚的。”

正解风格描述里藏着大量可用性细节：字号层级影响可读性，色彩对比影响操作识别，间距影响信息密度。“极简”两个字会让 V0 自动降低装饰、加大留白，这本身就是设计决策。忽视风格描述，代价是页面功能齐全但没人愿意用。

为何常见：视觉往往被当成附属品，人们习惯先保证功能再谈美观，却忘了界面任何一处呈现都属于用户体验需求。

误区“AI 生成的代码比我手写的更可靠，语法对、结构工整，不用太仔细审查。”

正解V0 会生成看起来合理但边界处理粗糙的代码——空数据、无权限、异常路径都可能缺。必须在可读命名、结构清晰、注释完整、防御编程四关上人工把关。就像大厨的菜也要过品控检查才能端上桌，生成代码必须经过审查才能进生产环境。

为何常见：生成结果语法正确、结构工整，看起来“很专业”，容易让人放松警惕；而边界问题的暴露往往要等上线后用户触发。

误区“写'你是一位资深前端工程师'这句话没什么用，删掉也不影响结果。这是给 AI 的礼貌用语。”

正解角色设定会显著改变模型的推理风格和调用知识的方式。同一需求，“资深工程师”身份下更倾向输出工程化结构，“UI 设计师”身份下更注重视觉层次和间距。它是引导模型“从哪个经验库取答案”的开关——就像告诉大厨“这是寿宴”，他才会调用寿宴那套经验。

为何常见：这行字不产生可见输出，作用隐蔽，容易被当成套话；但它的影响贯穿整段生成结果的每一个决策。

面试题

Q1. 在 V0 提示工程中，以下哪项是“角色设定”的核心作用？

单选题 · easy

  • A.让模型切换到特定领域专家的视角← 正确答案
  • B.缩短代码长度减少生成耗时
  • C.提高代码运行时的执行效率
  • D.自动生成对应的单元测试用例

答案：A。角色设定本质上是给模型装上一个“专业视角”，让它从对应领域专家的经验库中提取知识。B、C 缩短代码、提高运行效率都不是角色设定能直接保证的；D 属于测试环节，超出角色设定范畴。就像报完“广东人、老人过寿”，大厨自然换上了粤菜的思路。

Q2. 以下哪条描述属于“组件约束”？

单选题 · easy

  • A.页面使用蓝色作为主色调
  • B.包含顶部导航和统计卡片区← 正确答案
  • C.所有注释统一使用中文编写
  • D.产品面向年轻的数码爱好者

答案：B。组件约束描述页面由哪些模块构成。B 明确列出了顶部导航、统计卡片两个组件模块。A 属于风格描述，C 属于代码质量与语气引导，D 属于受众描述，都不是组件层面的约束。

Q3. 多轮修正时，最应该遵循的做法是？

单选题 · mid

  • A.推翻整页重写所有视觉布局
  • B.一次提出多项颠覆性大改动
  • C.定位具体问题并做增量修改← 正确答案
  • D.放弃当前工具换用另一款

答案：C。多轮修正强调“精准定位 + 增量修改”，一次只动一个点，避免连锁破坏。A 全量重写成本高且容易丢掉已验证有效的部分；B 多项大改动难以归因，改坏了不知道是哪条反馈导致的；D 换工具是最后手段，不是日常策略。

Q4. 需求清晰度公式 D = 1 − U/T 中，U 代表什么？

单选题 · mid

  • A.未决事项的数量← 正确答案
  • B.目标用户的数量
  • C.页面组件的数量
  • D.已完成迭代轮数

答案：A。U 是 Undecided，即尚未确定方案的需求项数。需求收敛越彻底，未决项越少，D 越接近 1。B、C 涉及的是用户和组件维度，D 是迭代轮次，都不出现在这个公式里。

Q5. 风格描述的主要作用是什么？

单选题 · easy

  • A.让界面视觉风格保持一致← 正确答案
  • B.加快前端代码的编译速度
  • C.直接减少生成的代码行数
  • D.替代组件约束的页面结构

答案：A。风格描述统一字距、色彩、圆角、字号层级等视觉语言，让多轮生成的页面像同一个设计师做的。B、C 把风格描述的功能夸大到编译性能和代码量上；D 混淆了风格层与结构层，组件约束才是定义页面结构的。

Q6. 代码质量把控中，“防御编程”主要体现在哪个方面？

单选题 · hard

  • A.变量与函数命名具备清晰语义
  • B.对空值、加载态做兜底处理← 正确答案
  • C.为关键逻辑添加详细注释
  • D.拆分组件降低页面嵌套深度

答案：B。防御编程关注运行时健壮性，即空数组、空对象、加载失败、权限不足等异常路径都有兜底 UI，不白屏不报错。A 是可读命名，C 是注释完整，D 是结构清晰，它们分别对应质量把控的其他三道关卡。

Q7. 在需求传达率公式 T = R_id × R_aud × R_stack 中，如果受众描述完全缺失（R_aud = 0），会发生什么？

单选题 · extreme

  • A.T 归零导致模型只能靠猜测设计← 正确答案
  • B.T 不变因为平均值不受影响
  • C.T 减半因为缺一项还有两项
  • D.T 无法计算需要额外参数修正

答案：A。这是乘法模型——任何一项因子为零，整体结果就是零。受众缺失意味着模型失去“为谁设计”的准绳，字号、配色、交互全部失去依据。B 把它当成平均值，C 把它当成加减法，D 误加了不存在的修正参数。就像厨师不知道吃饭的人是谁，再好的技术也可能端出完全不对路的菜。

Q8. 一次完整的角色设定语句中，应该包含以下哪些内容？

多选题 · mid

  • A.告诉模型它扮演的专家身份← 正确答案
  • B.描述目标用户的特点和偏好← 正确答案
  • C.指定项目使用的技术栈← 正确答案
  • D.直接粘贴完整的组件代码

答案：ABC。角色设定包含身份、受众、技术栈、语气引导四要素，所以 A、B、C 正确。D 粘贴组件代码属于组件约束层的工作，且 V0 更希望你描述意图而非直接粘贴代码，那样反而限制了它的发挥空间。

Q9. 多轮修正策略的四个标准动作包括以下哪些？

多选题 · hard

  • A.定位到具体组件并指出问题← 正确答案
  • B.一次只修改一个最小问题点← 正确答案
  • C.保留已经验证有效的部分← 正确答案
  • D.推倒当前方案重新整体生成

答案：ABC。问题定位、增量修改、保留有效、回归测试是四个标准动作，所以 A、B、C 正确。D 推倒重来违反“增量迭代”的核心原则——偏差是按轮次递减的，推倒重来等于放弃已经收敛的进度，回到 E_0。

Q10. 需求收敛流程中，哪些动作属于“把模糊变清晰”的关键步骤？

多选题 · mid

  • A.把模糊目标拆成具体模块← 正确答案
  • B.按价值排出功能优先级← 正确答案
  • C.明确可验收的完成标准← 正确答案
  • D.直接要求模型一次生成

答案：ABC。需求收敛四步是目标拆解、优先级排序、验收标准、迭代循环，所以 A、B、C 正确。D 让模型直接生成是收敛完成之后才做的动作——需求没理清就生成，只会得到“随便做点好吃的”式的平庸结果。