第三章：第一次会话：从目标到可审阅的变更集

3.1 先把任务写成“工程工单”

第一次会话建议你固定一个模板，把 AI 的行为约束到可交付的路径上：

目标：……
约束：……
验收：……

示例（可直接复制）：

目标：修复用户列表页搜索框输入后无响应的问题。
约束：不要改接口协议；不要引入新依赖；只改前端 src/ 目录。
验收：
1) 给出最小复现步骤
2) 定位根因（文件/函数/调用链）
3) 修复后运行：npm test、npm run lint
4) 输出可审阅的 diff，并解释风险点与回滚方式

3.2 先“调查”，再“修改”

为了避免跑偏，建议你明确要求：

先不要改代码。
请先定位入口与证据：相关路由/组件/请求函数在哪里，给出你认为的根因证据。
然后再给最小修复方案（改动范围与风险点）。

这一步的价值是：把修复从“猜测式编辑”拉回“证据驱动”。

3.3 小步改动：一次只解决一个主题

第一次实战推荐你刻意拆小：

• 第一轮只修复核心问题（最小可用）
• 第二轮补测试与边界条件
• 第三轮再做重构清理（可选）

拆小的好处是：每一步都能审阅、能回滚、能定位。

3.4 关键节点：把“审阅”变成默认路径

无论你用的是 Chat、Composer 还是行内修改，关键节点都要做同一件事：

• 先看变更（diff）
• 再跑验证（tests/lint/build）
• 最后才合入（commit/PR）

你可以明确要求 Cursor：

每次完成一轮修改，请先给我变更摘要与 diff，我审阅通过后再继续下一轮。

3.5 本章小结

你已经有了一个稳定的首次会话模板：

• 用“目标/约束/验收”把任务工程化
• 先调查再修改，基于证据定位
• 小步交付，关键节点先审阅 diff
• 用测试与 lint 把正确性变成可验证

下一章我们进入稳定性核心：上下文管理——如何选文件、怎么减少跑偏、怎么让 Cursor 真的“看过你的代码”。