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

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

第一次任务不要追求复杂，追求可控。用固定模板把 Trae 的行为约束到正确路径上：

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

示例（可直接复制）：

目标：修复登录页点击按钮后无响应的问题。
约束：不要新增依赖；不要改接口协议；只改 src/ 与 tests/。
验收：
1) 给出最小复现步骤
2) 根因定位到文件/函数/调用链
3) 修复后运行：<测试命令>、<lint/typecheck 命令>
4) 输出可审阅的变更（diff），并说明风险点与回滚方式

3.2 先“查证据”，再“动手改”

为了避免改错地方，建议你明确要求：

先不要改代码。
请先搜索并读相关文件，定位入口与证据链，然后给出最小修复方案。

证据链应该包含：

• 入口文件在哪里（页面/路由/Controller）
• 事件/调用链怎么走到失败点
• 失败的直接原因是什么（条件分支、空值、异常、超时）

3.3 小步交付：一次只解决一个主题

第一次任务的最佳策略是拆成 2-3 轮：

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

每一轮都应该产出可审阅的变更，并跑验证命令。

3.4 关键节点：先审阅，再继续

无论 Trae 给出多漂亮的解释，你都应该把审阅放在第一优先级：

请先输出变更摘要与 diff，我审阅通过后再继续下一步。

这会显著降低“改动扩散”和“引入隐蔽 bug”的概率。

3.5 本章小结

你已经拥有第一次任务的稳定打法：

• 目标/约束/验收把任务工程化
• 先证据后修改，避免改错地方
• 小步交付，关键节点先审阅 diff
• 跑测试与 lint/typecheck 把正确性变成可验证

下一章开始进入工具链：如何高效搜索与阅读代码，快速建立证据链。