错误诊断:把报错直接给 Cascade
最简单的调试方式:把错误信息(无论是终端输出、浏览器控制台、还是运行日志)直接粘贴到 Cascade 的输入框,配合相关文件引用:
// 标准错误诊断 Prompt 模板
运行 npm run build 时出现以下错误,请帮我修复:
[错误信息粘贴在这里]
相关文件:@src/components/DataTable.tsx
项目:React 18 + TypeScript 5.3 + Vite 5
请先解释错误原因,再给出修复方案。
终端错误自动感知
Windsurf 的一个独特功能是:Cascade 可以"订阅"终端输出,当你运行命令出错时,它会主动弹出"我注意到终端有错误,要我帮你修复吗?"的提示。
终端错误感知工作流:
你运行:npm test
↓
[终端输出错误]
FAIL src/utils/__tests__/format.test.ts
● formatDate › should format ISO string correctly
Expected: "2025-01-15"
Received: "2025-1-15"
↓
Cascade 面板自动弹出:
"检测到测试失败(1 个测试未通过)
错误位于 src/utils/__tests__/format.test.ts:23
要我查看并修复 formatDate 函数吗?"
↓
你点击"是" → Cascade 自动读取相关文件 → 修复 → 重新运行测试
要启用这个功能,确保 Settings → Cascade → "Terminal Error Detection" 已开启(默认开启)。
实战:调试 TypeScript 类型错误
TypeScript 类型错误有时候非常晦涩,以下是一个典型案例的完整调试流程:
// 错误代码
interface ApiResponse<T> {
data: T;
error: string | null;
timestamp: number;
}
async function fetchUser(id: string) {
const response = await fetch(`/api/users/${id}`);
return response.json() as ApiResponse<User>;
}
const user = await fetchUser("123");
// TS 错误:
// Type 'ApiResponse<User>' is not assignable to type 'User'
// Property 'name' is missing in type 'ApiResponse<User>'
console.log(user.name); // ← 错误行
// 给 Cascade 的 Prompt:
@src/api/users.ts 中 fetchUser 函数有 TypeScript 类型错误:
Type 'ApiResponse<User>' is not assignable to type 'User'
Property 'name' is missing in type 'ApiResponse<User>'
调用方代码是:
const user = await fetchUser("123");
console.log(user.name);
我期望 user 就是 User 类型,可以直接访问 .name 属性。
请解释为什么出现这个错误,并给出最佳修复方式。
Cascade 会解释:fetchUser 返回的是 ApiResponse<User>(包含 data、error、timestamp),而不是 User。正确用法是 user.data.name,或者修改 fetchUser 直接返回 data 字段。
日志分析:让 AI 找出规律
对于生产环境的复杂日志,Cascade 可以帮你从大量日志中找到异常模式:
以下是我们服务昨天下午 3-4 点的错误日志(响应时间突然变慢)。
请分析:
1. 主要错误类型和频率
2. 错误开始出现的具体时间点
3. 可能的根本原因
4. 建议排查方向
[粘贴日志内容,建议不超过 200 行]
服务:Node.js + PostgreSQL + Redis
基础设施:AWS ECS,该时间段无部署
堆栈追踪解读
复杂的异常堆栈(特别是涉及框架内部的调用栈)对开发者很不友好。Cascade 能快速定位关键信息:
// 将完整堆栈追踪粘贴给 Cascade:
UnhandledPromiseRejectionWarning: Error: ECONNRESET
at TLSSocket.onConnectEnd (_tls_wrap.js:1495:19)
at Object.onceWrapper (events.js:422:26)
at TLSSocket.emit (events.js:327:22)
at endReadableNT (_stream_readable.js:1221:12)
at processTicksAndRejections (internal/process/task_queues.js:84:21)
这个错误在高并发下偶发,请告诉我:
1. 这个堆栈说明了什么问题
2. ECONNRESET 通常的触发场景
3. 如何在我的 Node.js HTTP 客户端代码中修复
测试驱动修复:先写测试,再让 Cascade 修复
这是一种非常有效的调试范式,特别适合复现偶发 bug:
- 描述 bug 的触发条件和期望行为,让 Cascade 先写一个能重现 bug 的测试(测试应该失败)。
- 运行测试,确认测试确实失败(如果测试通过说明 bug 描述有误)。
- 对 Cascade 说:"测试已经失败了,请修复实现代码,直到测试通过。"
- Cascade 自动修复并运行测试,如果还失败则继续迭代,直到通过。
// 步骤 1:描述 bug,让 Cascade 写测试
@src/utils/currency.ts 中的 formatCurrency 函数有一个 bug:
当金额超过 1000 时,千位分隔符显示不正确。
例如:formatCurrency(1234.56) 返回 "1234.56" 而不是 "1,234.56"
请先为这个 bug 写一个测试(使用 Jest),
测试用例要能重现这个问题(运行应该失败)。
// 步骤 3(确认测试失败后):
好,测试已经失败了(我已运行并截图确认)。
现在请修复 formatCurrency 函数的实现,
直到刚才写的测试通过。修复后运行 npm test 确认。
调试效率最大化技巧
在向 Cascade 报告错误时,提供上下文越具体,修复越准确。建议的信息清单:① 完整错误信息和堆栈 ② 触发条件(什么操作导致) ③ 期望行为 ④ 实际行为 ⑤ 环境信息(Node 版本、OS、依赖版本) ⑥ 相关代码文件路径。
本章小结
Cascade 的调试核心是:直接提供错误信息(不要描述,直接粘贴)+ 引用相关文件 + 说明期望行为。终端错误自动感知功能能让 Cascade 主动介入修复,无需手动触发。测试驱动修复是最可靠的调试范式——先固化 bug 的可重现测试,再修复,杜绝"修了又出现"的情况。