质量、调试与性能

质量不是最后补一轮测试

AI 可以更快地产生代码，也会更快地放大错误。质量控制要贯穿需求、实现和交付，而不是在上线前临时检查。

调试顺序

1. 稳定复现：记录输入、环境、操作步骤和实际结果。
2. 缩小范围：找到第一个错误点，而不是围绕最后一个报错猜测。
3. 收集证据：查看日志、网络请求、状态和最小测试。
4. 验证假设：一次只改变一个变量。
5. 修复根因：避免只屏蔽报错或增加无依据重试。
6. 增加回归：让同类问题以后能被自动发现。

测试金字塔

层级	验证什么	常见方式
静态检查	格式、类型、明显错误和危险模式	格式化、类型检查、规则扫描
单元测试	函数和小模块的输入输出	正常、边界、异常用例
集成测试	模块、接口、数据库和外部服务协作	真实协议与可控测试数据
端到端测试	用户关键路径	浏览器或客户端真实操作
人工检查	视觉、文案、可理解性和高风险判断	多设备、无障碍、业务复核

没有一种测试可以代替全部层级。静态网站也需要构建、链接、资源、搜索、响应式和浏览器控制台检查。

AI 功能的额外评估

• 建立固定评估集，包含高频、长尾、对抗和高风险样本。
• 区分格式正确、事实正确、引用正确和业务可用。
• 同时记录失败率、拒答率、人工接管率、延迟和成本。
• 模型或提示词变化后重新跑同一评估集。
• 生成结果会影响真实动作时，增加权限、确认和回滚验证。

何时重构

先让行为被测试保护，再改善结构。适合重构的信号包括：重复逻辑不断增加、一个模块承担多个职责、修改小功能要触碰许多无关文件、命名无法表达业务含义、测试难以编写。

重构时保持外部行为不变。把“修 bug”“新增功能”“结构重写”拆成独立步骤，便于定位回归。

性能优化顺序

1. 先测量真实瓶颈，不凭感觉优化。
2. 优先减少不必要的请求、数据量和重复计算。
3. 再处理缓存、并发、索引、懒加载和资源压缩。
4. 在目标设备和真实网络条件复测。
5. 记录性能预算，防止后续反弹。

常用用户指标包括首屏可见时间、交互响应、请求错误率、长任务、页面体积和内存占用；服务端还应关注吞吐、尾延迟、资源使用和队列积压。

质量门禁

在交付前回答：能否从干净环境构建？核心路径是否真实执行？失败信息是否能指导恢复？是否有未解释的控制台错误？是否修改了无关行为？是否记录了不能证明或尚未覆盖的部分？