用途：在编写或修改代码之前，先确定能给出黑白结论的测量方法并执行，只根据测量结果做判断。用于调查缺陷原因、比较性能与行为、开始写新功能，以及即将凭"大概"下结论的场合。核心目标：让每个判断都基于任何人都能复现的根据。
测量位置：作为判断依据的测量在生产环境进行；无法在生产测量时，搭建代码、配置、基础设施、数据规模与形态、外部服务均与生产一致的预发布环境。本地或测试环境的测量仅用于确认测量机制可用，因数据规模与外部服务不同，可能得出与生产相反的结论。
主要步骤：提出一个由事实决定答案的问题；列出所有可能假设；在测量前为每个假设写明测量对象及采用值、舍弃值；建立复现手段与观测点，用结果已知的输入确认能正确测量；一次只变一个条件测量，时间与性能多次测量并看离散度；保留条件、命令与原始结果；按第三步标准判断，与预期不符时怀疑假设；变更后用同一机制重测确认效果。若假设均未确定，则增加测量对象回到第三步；无法测量时不凭猜测推进，向用户说明缺少什么。
新功能：先写能验证验收条件的测试或脚本，确认其失败后再实现。未测量的主张须写明是推测；作为变更依据的测量要把条件、命令与结果写进提交信息。出现不利结果时如实报告并重审假设。
排查缺陷：不做消除症状的修改，而要修根因，原因明确前不写修复。读完错误信息与堆栈；建立可稳定复现的步骤；查看近期变更（差异、提交、依赖、配置、环境差异）；对跨层处理（CI→构建→签名、API→服务→DB 等）在各层边界记录进出值，先定位损坏的层；追溯非法值的调用来源并在源头修复；寻找同类实现并列出全部差异。修复先写失败测试，只做一处修改，不夹带顺手改进；修三次仍不行就怀疑设计并找用户商量。
性能优化：让对象可用 span 测量并取优化前值；针对测量出的瓶颈逐个改进；用相同条件重测确认变好，否则回到第二步换假设；同时测量是否拖慢别处。
测量内容（基于 masseater/typescript-template 结构的仓库，其他仓库按同角色替换）：服务器信号用 Effect API 发出并由 Cloudflare Workers Observability 收集；Effect.withSpan 由 apps/web/src/pages/home/api/tracing.server.ts 映射到 Workers 追踪，Effect.log* 进入 Workers Logs，D1 与 fetch 调用由 Cloudflare 自动生成 span；指标用 Workers 的请求数、错误数、CPU 时间、时长；观测配置与采样率在 apps/web/alchemy.run.ts 的 observability 中。
采集工具：生产日志、追踪、指标通过 .mcp.json 的 cloudflare-observability MCP 服务器查询，其他 Cloudflare API 用 cloudflare-api MCP 服务器调用，两者使用 Alchemy 配置文件的凭据；查看已部署 Worker 日志流时在 apps/web 执行 vp exec alchemy logs --tail。Effect 日志与浏览器 console 也会出现在 vp run dev 终端。浏览器用 vp dlx @playwright/cli 操作，通过 console、requests、snapshot 观测；云环境在 .playwright/cli.config.json 的 launchOptions.executablePath 中写入 /opt/pw-browsers 的 Chromium。若 alchemy dev 因 CredentialsUnavailable 停止，则在测试与日志可测范围内推进，并向用户说明未能测量画面。
限制：日志与追踪只保留请求的一部分作为样本，测量期间需提高采样率、结束后恢复，并在判断时附上样本数量是否充足。缺失事实（如费用、平台适用性等）资料未提供。