vercel-optimize - scoring

第 4 步 — 评分和报告此参考涵盖建议起草后发生的一切质量底线、影响框架、排序顺序、面向客户的报告模板和行动手册选择矩阵。目录质量底线和修剪规则影响框架 — 量级规则impactLabel模式排序顺序和平台建议上限面向客户的报告模板行动手册选择矩阵质量底线和修剪规则规则值原因丢弃quality.overall 0.55的建议硬性截止2026 年 5 月审计从 0.4 提高低分建议对信任的侵蚀超过帮助。0.55 匹配 Poor/Fair 等级边界低于此的建议是Poor不应发布。发现修剪上限输入的 30%当 LLM 质量评分有噪音时防止修剪器清空报告平台建议上限3账户级建议Fluid、Bot Protection、Speed Insights只为前三个留出空间速赢定义effort low 且 priority 40呈现用户可以在单个 PR 中发布的修复节省下限仅内部排名相当于 $5/月低于此即使是高档影响也转化为可忽略的量级影响框架 — 量级规则性能精确。使用观测数字。示例“将 /api/products p95 从 850ms 降低到约 250-400ms基于类似的缓存路由缓存命中率将从 0% 提升到约 60%。”性能数字来自signals.json.metrics.*——它们是观测的不是外推的。引用确切的路由 指标值。美元成本绝不精确。通过lib/impact-magnitude.mjs的impactMagnitude({currentCost, impactTier})使用量级分桶估算减少美元量级面向客户措辞 $5negligible“按当前流量成本影响很小”$5 – $50small“按当前流量每月低至几十美元”$50 – $500medium“按当前流量每月数百美元”$500 – $5,000large“按当前流量每月低至数千美元” $5,000very-large“按当前流量每月数千美元以上”减少量计算为currentCost × fraction其中fraction {high: 0.4, medium: 0.2, low: 0.1}[impactTier]。该分数刻意保守——我们宁愿少承诺也不愿误导。可折扣与不可折扣 SKU当项目使用 Flex Commit 且报告针对合同消耗进行节省框架时在措辞前先细分支出。现场原则2026 年 5 月Flex 折扣滑块仅适用于 SKU 的一个子集。可折扣滑块适用不可折扣原始费率SeatsBuild CPU MinutesEdge RequestsFluid Active CPUFast Data TransferFluid Provisioned MemoryFast Origin TransferRaw Flex top-upImage OptimizationISR Reads / WritesObservability Events针对不可折扣 SKU 的建议绝不应将节省框定为合同的百分比只框定为绝对量级。相反可折扣 SKU 的建议可以在量级措辞中呈现适用于合同消耗。为什么用量级流量会变化。今天精确的边缘请求减少 20%在下个季度毫无意义。定价会变化。Vercel 的计费费率会变动精确的美元预测会腐烂。用户很聪明。他们宁愿看到有真实指标支撑的每月数百美元也不愿看到挥手背后的$340/月。$-strip清理器在输出时强制执行这一点。任何滑入面向客户字段的$N字面量在渲染前都会被替换为计费成本。impactLabel模式typeImpactLabel{// 精确性能建议performance?:string;// 量级成本建议costMagnitude?:negligible|small|medium|large|very-large;costPhrase?:string;billingDimension?:string;// Edge Requests | Function Duration | ...fractionReduced?:number;// 0.2 ~20% — 仅内部不渲染};成本建议渲染costPhrase。性能建议渲染performance。可靠性建议将影响框定为观测的错误/超时减少例如基于当前流量将 5xx 率从 0.4% 降至 0.1%。当建议跨越多个分桶时——例如一个同时减少成本和延迟的缓存修复——渲染两行。排序顺序和平台建议上限内部排序键不渲染priority currentDimensionCost × fractionReduced × confidence。客户看到的建议列表按此优先级排序。平台建议部分上限为 3按相同方式排序。面向客户的报告模板代理将此渲染为第 4 步的最终输出。结构是固定的内容来自合并的信号 已验证的建议 第 2 步的gated[]列表。# Vercel 优化报告 — {projectName} **技术栈**{framework}{frameworkVersion} | {router} | {orm} **计划**{plan.plan}{plan.reason} **周期**{usage.period.from} → {usage.period.to} **可观测性**{observability status} ## 成本分解 | 服务 | 用量 | 计费成本 | |---|---|---| | 来自 usage.services 的非零行按 billedCost 降序排序 | 总计计费{usage.totals.billedCost}我们渲染精确的当前成本——只是不预测未来的精确节省 以向客户显示的相同美分精度省略表格中的零成本服务行。如果每行的计费成本为 $0.00 但 effectiveCost / 美元 pricingQuantity 非零说明在包含的信用额度或配额之后净计费成本为 $0.00并改为显示有效用量成本表。如果计费和有效成本都为 $0.00用简洁的说明替换表格vercel usage 返回了计费负载但报告的服务成本在该窗口内都是 $0.00。 如果 vercel usage 被查询但不可用成本分解被替换为当这些指标存在时来自 metrics.fnGbHrByRoute metrics.fnCpuMsByRoute metrics.fdtByRoute 的可观测性派生成本排名。这些不直接换算为美元——它们显示*哪些路由消耗计费单位*以便用户知道先攻击什么。如果 usageError 是 NOT_COLLECTED_OBSERVABILITY_BLOCKED 或另一个 NOT_COLLECTED_* 值说明用量未被收集不要将其描述为计费计划或 Costs 功能发现。 根据实际收集状态渲染可观测性状态 - 当 observabilityPlusUsabletrue 时Observability Plus 已启用 — 包含逐路由指标。 - 当 Observability Plus 阻碍在计费/扫描器收集之前停止了运行逐路由指标不可用 — 审计在指标支撑的路由排名之前暂停。 - 当用户接受了受限审计且计费/扫描器信号已被收集逐路由指标不可用 — 基于计费 扫描器发现的分析。 - 当用户接受了受限审计但计费用量被查询且不可用逐路由指标不可用 — 基于扫描器发现的受限分析。 - 当框架支持在 Observability Plus 检查之前停止了运行未检查 — 审计在不支持框架的预检处暂停。 - 仅用于已知 Observability Plus 为 false 且存在计费/扫描器信号的遗留/受限报告未启用 — 基于计费 扫描器发现的分析。 ## 最高影响的建议 对每个高优先级建议按顺序 1. **{路由或文件}** — {o11ySignal} 1. **{可读候选标签}** — {可读指标标签} - **要做什么**{rec.what} - **影响**{impactLabel.performance ?? impactLabel.costPhrase} - **工作量**{rec.effort} - **引用**{rec.citations} ## 建议 ### 高影响 | # | 分桶 | 做什么 | 影响 | 工作量 | 引用 | |---|---|---|---|---|---| ### 中影响 ### 低影响 ## 平台建议 来自门控的账户级建议上限 3 ## 调查中的观察 来自核对或调查的非建议发现部署回退、路由错误风暴、指标不匹配以及其他不应成为推测性性能建议的真实信号。 观察不得包含实现级操作。如果建议的操作说要启用、添加、包裹、应用、移动、配置、挑战、拒绝或以其它方式更改代码或项目设置渲染器必须将其扣留直到它通过可应用建议的证据标准。客户可见的观察可以要求更窄的证据收集检查日志、比较部署、检查头或确认可缓存性。 ## 已调查不建议更改 被检查但未产生受支持建议的候选。使用平实的原因不要在面向客户文案中使用abstain。 | 候选 | 为何没有建议发布 | |---|---| | /docs 上的慢路由 | 详细指标不支持代码变更 | ## 本次运行未调查 此部分赢得用户的信任。对我们考虑过但未采取行动的每个指标信号按候选类型和原因分组 | 候选类型 | 为何未调查 | 目标 | 计数 | |---|---|---|---:| | 低缓存命中率路由 | hitRate 0.65 高于阈值 | /api/orders | 1 | | 慢路由 | 留给更大的运行 | /api/docsbr/api/learn | 2 | ## 优势 项目做得好的地方——缓存对 X/Y/Z 路由是健康的Fluid Compute 已启用等 ## 数据缺口 我们无法测量的内容——Observability Plus 禁用意味着没有逐路由延迟等当底层指标返回空行时要指出的常见数据缺口。如果指标查询失败okfalse说明该指标对代码不可用不要将失败的查询转换为无测量或未使用的声明。Core Web Vitals 为空。Speed Insights 指标在 14 天窗口内未返回测量值。cwv_poor门控保持休眠不对 LCP/INP/CLS 做任何声明。ISR 为空。项目不使用增量静态再生成。isr_overrevalidation门控保持休眠。中间件为空。没有middleware.ts或匹配器排除了所有观测流量。middleware_heavy门控保持休眠。图像转换量为空。窗口内没有next/image使用或没有提供图像。BotID 检查为空。BotID 被禁用——参见platform_bot_protection建议了解该开关。冷启动数据接近零。Fluid Compute 可能已启用或项目的流量模式保持热实例可用cold_start门控评估数据但不发出候选。本次运行未调查部分至关重要。它直接来自门控产生的gate.json。它告诉用户我们考虑了一切我们不只是挑了容易的目标。行动手册选择矩阵推荐器根据项目的stack.applicationProfile从框架 依赖推断和最高计费维度选择 0-2 个行动手册。应用画像可能的主要维度应用行动手册ai-applicationAI SDK、AI Gateway、Sandbox 使用AI Gateway、Sandbox Active Compute、Function Durationplaybooks/ai-application.mdecommerceStripe、Shopify、购物车组件Edge Requests、Function Durationplaybooks/ecommerce.mdsaas认证、仪表盘、多租户Function Duration、Bandwidthplaybooks/saas.mdapi-service主要是 API 路由无 UIFunction Duration、Edge Requestsplaybooks/api-service.mdcontent-site博客、文档、主要是静态Edge Requests、Image Optimizationplaybooks/content-site.mdmarketing落地页、A/B 测试Edge Requests、ISR Readsplaybooks/marketing.mdinferPlaybook()首先检查ai-application——AI 密集的 SaaS 或 AI 商务应用共享 AI 行动手册的计费形态AI Gateway 主导和陷阱而不是仪表盘或购物车结账模式。行动手册塑造建议的措辞和顺序。它们绝不编造声明——每条建议仍必须追溯到已验证的发现。