新手推荐路径摘要在 AI 辅助开发工具快速普及的今天新手面对最多的困惑往往不是工具够不够强而是我该从哪一步开始用。本文提出一条经过实践验证的三阶段学习路径先从 Ask问答式交互起步熟悉工具的脾气再用 Plan计划模式把控复杂任务的节奏最后信任 Agent智能体去执行落地。文章会结合可运行的代码示例逐层拆解每个阶段的目标、典型用法、常见坑点与过渡信号帮助新手用最低的试错成本建立起对 AI 编程工具的正确认知。引言很多新手第一次打开 AI 编程工具时会直接丢一句帮我写一个完整的电商后端然后对着生成的一大坨代码发愣——不知道对不对、不敢改、更不敢上线。问题不在工具而在使用顺序。AI 编程工具的能力大致可以拆成三层Ask 层你问它答。它像一个随时在线的资深同事负责解释、答疑、给片段。Plan 层你给目标它拆步骤。它像一位项目经理负责把模糊需求变成可执行的清单。Agent 层你给任务它自己读代码、改文件、跑测试。它像一个能独立干活的工程师。这三层不是越往后越好而是有先后依赖的。跳过 Ask 直接上 Agent你既看不懂它改了什么也无法判断它对不对跳过 Plan 直接上 Agent复杂任务会跑偏且难以纠偏。本文按这条推荐路径展开每一节都配有可直接运行的示例。一、为什么新手必须从 Ask 起步1.1 Ask 阶段的真正目标Ask 阶段的核心不是让 AI 帮我写代码而是建立三个认知认知一模型的能力边界。它擅长什么样板代码、正则、SQL、解释报错不擅长什么涉及时效性的库版本、你公司内部约定。认知二提问的质量决定回答的质量。模糊问题得到模糊答案这是新手最容易踩的坑。认知三如何验证答案。AI 给的代码不一定对你需要有能力跑一遍、读一遍、判断一遍。1.2 一个对比示例模糊提问 vs 结构化提问假设你想实现防抖函数。新手常见的提问是帮我写个防抖得到的答案可能是一个最简版本没有取消功能、没有this绑定、没有立即执行选项。而结构化提问用 TypeScript 实现一个 debounce 函数要求1支持立即执行选项immediate2返回函数上挂一个cancel方法3正确处理this指向4给出使用示例和单元测试。得到的代码质量完全不同。下面是一个符合上述要求的完整实现// debounce.tsexportinterfaceDebouncedFunctionTextends(...args:any[])any{(this:ThisParameterTypeT,...args:ParametersT):void;cancel():void;}exportfunctiondebounceTextends(...args:any[])any(fn:T,wait:number,immediatefalse):DebouncedFunctionT{lettimer:ReturnTypetypeofsetTimeout|nullnull;constdebouncedfunction(this:ThisParameterTypeT,...args:ParametersT){constcontextthis;constlater(){timernull;if(!immediate)fn.apply(context,args);};constcallNowimmediatetimernull;// 每次调用都重置计时器if(timer!null)clearTimeout(timer);timersetTimeout(later,wait);// immediate 模式下首次调用立即执行if(callNow)fn.apply(context,args);}asDebouncedFunctionT;debounced.cancel(){if(timer!null){clearTimeout(timer);timernull;}};returndebounced;}配套的单元测试使用 Vitest可直接运行// debounce.test.tsimport{describe,it,expect,vi,beforeEach,afterEach}fromvitest;import{debounce}from./debounce;describe(debounce,(){beforeEach(()vi.useFakeTimers());afterEach(()vi.useRealTimers());it(延迟执行多次调用只执行最后一次,(){constfnvi.fn();constddebounce(fn,100);d();d();d();expect(fn).not.toHaveBeenCalled();vi.advanceTimersByTime(100);expect(fn).toHaveBeenCalledTimes(1);});it(immediate 模式下首次立即执行,(){constfnvi.fn();constddebounce(fn,100,true);d();expect(fn).toHaveBeenCalledTimes(1);d();expect(fn).toHaveBeenCalledTimes(1);// 窗口期内不重复执行});it(cancel 能取消待执行的调用,(){constfnvi.fn();constddebounce(fn,100);d();d.cancel();vi.advanceTimersByTime(200);expect(fn).not.toHaveBeenCalled();});});1.3 Ask 阶段的练习方法建议每天做三件事拿真实报错去问而不是自己猜。把完整堆栈贴进去问这个报错的原因是什么、怎么修、为什么。要求解释而非只给答案。追问为什么这样写、“有没有别的写法”这是积累判断力的关键。手动验证每个答案。跑一遍、改一个边界条件看它会不会挂。这一步不能省。1.4 何时可以进入下一阶段当你发现自己能预判 AI 大概会怎么答、并且能一眼看出答案里的问题时Ask 阶段就基本毕业了。此时你会自然产生新需求“这个功能涉及五六个文件一句句问太累了”——这就是进入 Plan 阶段的信号。二、Plan 阶段用计划把控复杂任务2.1 什么算复杂任务一个经验判据如果任务的完成需要改动超过 3 个文件或者需要你先想清楚步骤才能动手就属于复杂任务。典型场景包括重构一个模块、给现有系统加一个横切功能如日志、鉴权、迁移一个库的版本。这类任务的失败模式高度一致——方向错了越努力越糟。Plan 阶段的价值就是在动手前把方向对齐。2.2 Plan 的产出物一份可执行的任务清单好的计划不是一段散文而是可勾选、可验证、有依赖顺序的清单。以给 Express 应用加上请求级日志与耗时统计为例一份合格的计划长这样## 任务为 Express 应用添加请求日志与耗时统计 ### 前置调研 - [ ] 确认现有中间件注册顺序app.ts 第 20-40 行 - [ ] 确认日志库选型项目已依赖 winston复用而非新增 ### 实施步骤 - [ ] 1. 新建 src/middleware/requestLogger.ts - [ ] 2. 在 app.ts 中于路由注册之前挂载该中间件 - [ ] 3. 为每个请求生成 requestId使用 crypto.randomUUID - [ ] 4. 记录 method / path / status / duration - [ ] 5. 将 requestId 透传到响应头 X-Request-Id ### 验证 - [ ] 单元测试中间件对 200 与 500 响应均能正确记录 - [ ] 手动验证curl 一次接口检查日志字段完整2.3 计划对应的实现代码下面是与上述计划对应的完整可运行实现// src/middleware/requestLogger.tsimport{Request,Response,NextFunction}fromexpress;import{randomUUID}fromcrypto;importwinstonfromwinston;constloggerwinston.createLogger({level:info,format:winston.format.json(),transports:[newwinston.transports.Console()],});exportfunctionrequestLogger(req:Request,res:Response,next:NextFunction){constrequestIdrandomUUID();conststartprocess.hrtime.bigint();// 透传到响应头便于前端排查res.setHeader(X-Request-Id,requestId);// 响应结束时统一记录保证能拿到最终 statusres.on(finish,(){constdurationMsNumber(process.hrtime.bigint()-start)/1e6;logger.info(request,{requestId,method:req.method,path:req.originalUrl,status:res.statusCode,durationMs:Number(durationMs.toFixed(2)),});});next();}// src/app.tsimportexpressfromexpress;import{requestLogger}from./middleware/requestLogger;constappexpress();// 关键日志中间件必须在路由之前注册否则路由内的响应不会被统计app.use(requestLogger);app.get(/health,(_req,res)res.json({ok:true}));app.get(/boom,(){thrownewError(intentional error);});app.listen(3000,()console.log(listening on :3000));2.4 Plan 阶段的三条纪律先调研再列步骤。让 AI 先读相关文件、输出现状理解你确认无误后再让它出计划。计划要能被人读懂。如果计划里出现优化一下相关逻辑这种模糊表述打回去重写。一个步骤一个验证点。没有验证方式的步骤等于没有步骤。2.5 何时可以进入下一阶段当你发现计划本身已经足够清晰、剩下的只是按部就班敲代码并且你已经能信任 AI 在这个清晰边界内自主执行时就可以进入 Agent 阶段了。注意信任的是边界清晰的执行不是无脑放手。三、Agent 阶段在清晰边界内信任执行3.1 Agent 与 Ask/Plan 的本质区别Ask 是你说一句它答一句Plan 是它给你清单你确认Agent 是它自己读文件、改文件、跑测试、根据结果调整。Agent 的能力来自工具调用循环读 → 想 → 改 → 跑 → 看结果 → 再改。这也意味着 Agent 的风险点在于它会真的修改你的文件。所以进入 Agent 阶段的前提是边界已经由 Plan 阶段界定清楚。3.2 一个 Agent 任务的最小示例假设 Plan 阶段已经确认要在utils/下新增一个retry.ts实现带指数退避的异步重试并配套测试不改动其他文件。给 Agent 的任务描述应该长这样任务边界只允许在 src/utils/ 目录下新增文件不得修改其他目录。 目标实现 retry(fn, options) 异步重试工具。 要求 - 参数fn 为返回 Promise 的函数options 含 retries、baseDelay、maxDelay、shouldRetry - 指数退避第 n 次重试等待 min(baseDelay * 2^n, maxDelay) - shouldRetry(err, attempt) 返回 false 时立即抛出 - 配套单元测试覆盖成功、重试后成功、耗尽重试、shouldRetry 拦截四种情况 完成标准npm test 全绿且 git diff 只显示 src/utils/ 下的新增文件。Agent 产出的实现大致如下// src/utils/retry.tsexportinterfaceRetryOptions{retries?:number;baseDelay?:number;maxDelay?:number;shouldRetry?:(err:unknown,attempt:number)boolean;}constsleep(ms:number)newPromise((r)setTimeout(r,ms));exportasyncfunctionretryT(fn:()PromiseT,options:RetryOptions{}):PromiseT{const{retries3,baseDelay100,maxDelay5000,shouldRetry()true,}options;letlastErr:unknown;for(letattempt0;attemptretries;attempt){try{returnawaitfn();}catch(err){lastErrerr;// 最后一次尝试失败或调用方明确不重试直接抛出if(attemptretries||!shouldRetry(err,attempt))throwerr;constdelayMath.min(baseDelay*2**attempt,maxDelay);awaitsleep(delay);}}// 理论上不可达仅为类型收窄throwlastErr;}配套测试// src/utils/retry.test.tsimport{describe,it,expect,vi}fromvitest;import{retry}from./retry;describe(retry,(){it(首次成功直接返回,async(){constfnvi.fn().mockResolvedValue(ok);awaitexpect(retry(fn,{baseDelay:1})).resolves.toBe(ok);expect(fn).toHaveBeenCalledTimes(1);});it(失败后重试成功,async(){constfnvi.fn().mockRejectedValueOnce(newError(fail)).mockResolvedValue(ok);awaitexpect(retry(fn,{baseDelay:1})).resolves.toBe(ok);expect(fn).toHaveBeenCalledTimes(2);});it(耗尽重试后抛出最后的错误,async(){constfnvi.fn().mockRejectedValue(newError(always));awaitexpect(retry(fn,{retries:2,baseDelay:1})).rejects.toThrow(always);expect(fn).toHaveBeenCalledTimes(3);// 1 次初始 2 次重试});it(shouldRetry 返回 false 时立即抛出,async(){constfnvi.fn().mockRejectedValue(newError(fatal));awaitexpect(retry(fn,{baseDelay:1,shouldRetry:()false})).rejects.toThrow(fatal);expect(fn).toHaveBeenCalledTimes(1);});});3.3 如何信任而不失控信任 Agent 的正确姿势是用可验证的完成标准兜底而不是用人盯人的方式。具体做法给任务写死边界如只允许改 src/utils/Agent 越界时你能从 diff 里一眼看出。给完成标准写死验证方式如npm test 全绿让 Agent 自己跑、自己看结果、自己修。事后 review diff 而非 review 过程。过程交给 Agent结果由你验收。小步提交。每个 Agent 任务对应一个 commit出问题能一键回滚。3.4 Agent 阶段的典型坑边界不清导致误改没写只改某目录Agent 顺手重构了无关文件。→ 任务描述里显式写边界。完成标准模糊只写实现功能Agent 可能不写测试就宣布完成。→ 完成标准必须可执行、可验证。一次给太大任务把 Plan 阶段整份清单丢给 Agent。→ 拆成单个步骤逐个交给 Agent。四、三阶段如何平滑衔接三个阶段不是割裂的而是一条能力递进链。下面这张对照表帮你判断自己处在哪、下一步该练什么阶段你的角色AI 的角色核心产出毕业信号Ask提问者答疑同事可验证的代码片段/解释能预判并挑出答案的问题Plan决策者项目经理可勾选的任务清单计划清晰到只剩敲代码Agent验收者执行工程师通过验证的改动能用边界标准兜住自主执行衔接的关键动作是每个阶段都留下可复用的资产Ask 阶段留下的是一批好问题模板Plan 阶段留下的是一份份任务清单Agent 阶段留下的是一串小步 commit。这些资产会让你在下一阶段起步时不是从零开始。五、常见误区与纠正误区一跳过 Ask 直接上 Agent。纠正你无法验收你看不懂的东西。先花一周在 Ask 阶段把工具脾气摸熟。误区二Plan 阶段写伪计划。纠正计划里每一步都要有验证方式。优化性能不是步骤把列表接口的 N1 查询改为批量查询并用 EXPLAIN 确认走了索引才是。误区三Agent 阶段全程盯着。纠正盯着过程说明你还不信任边界。把精力放在写清边界和完成标准上过程放手。误区四三个阶段只用一种。纠正真实工作中三者是混用的。遇到陌生报错回到 Ask接到大需求先 Plan边界清晰后交 Agent。总结新手使用 AI 编程工具最稳妥的路径是Ask → Plan → Agent的递进Ask 起步目的是建立对模型能力边界、提问质量、答案验证的三重认知产出可验证的代码片段Plan 居中目的是把复杂任务的模糊需求转成可勾选、可验证、有依赖顺序的任务清单在动手前对齐方向Agent 收尾目的是在清晰边界与可执行完成标准的兜底下信任 AI 自主执行并只验收结果。
新手推荐路径摘要在 AI 辅助开发工具快速普及的今天新手面对最多的困惑往往不是工具够不够强而是我该从哪一步开始用。本文提出一条经过实践验证的三阶段学习路径先从 Ask问答式交互起步熟悉工具的脾气再用 Plan计划模式把控复杂任务的节奏最后信任 Agent智能体去执行落地。文章会结合可运行的代码示例逐层拆解每个阶段的目标、典型用法、常见坑点与过渡信号帮助新手用最低的试错成本建立起对 AI 编程工具的正确认知。引言很多新手第一次打开 AI 编程工具时会直接丢一句帮我写一个完整的电商后端然后对着生成的一大坨代码发愣——不知道对不对、不敢改、更不敢上线。问题不在工具而在使用顺序。AI 编程工具的能力大致可以拆成三层Ask 层你问它答。它像一个随时在线的资深同事负责解释、答疑、给片段。Plan 层你给目标它拆步骤。它像一位项目经理负责把模糊需求变成可执行的清单。Agent 层你给任务它自己读代码、改文件、跑测试。它像一个能独立干活的工程师。这三层不是越往后越好而是有先后依赖的。跳过 Ask 直接上 Agent你既看不懂它改了什么也无法判断它对不对跳过 Plan 直接上 Agent复杂任务会跑偏且难以纠偏。本文按这条推荐路径展开每一节都配有可直接运行的示例。一、为什么新手必须从 Ask 起步1.1 Ask 阶段的真正目标Ask 阶段的核心不是让 AI 帮我写代码而是建立三个认知认知一模型的能力边界。它擅长什么样板代码、正则、SQL、解释报错不擅长什么涉及时效性的库版本、你公司内部约定。认知二提问的质量决定回答的质量。模糊问题得到模糊答案这是新手最容易踩的坑。认知三如何验证答案。AI 给的代码不一定对你需要有能力跑一遍、读一遍、判断一遍。1.2 一个对比示例模糊提问 vs 结构化提问假设你想实现防抖函数。新手常见的提问是帮我写个防抖得到的答案可能是一个最简版本没有取消功能、没有this绑定、没有立即执行选项。而结构化提问用 TypeScript 实现一个 debounce 函数要求1支持立即执行选项immediate2返回函数上挂一个cancel方法3正确处理this指向4给出使用示例和单元测试。得到的代码质量完全不同。下面是一个符合上述要求的完整实现// debounce.tsexportinterfaceDebouncedFunctionTextends(...args:any[])any{(this:ThisParameterTypeT,...args:ParametersT):void;cancel():void;}exportfunctiondebounceTextends(...args:any[])any(fn:T,wait:number,immediatefalse):DebouncedFunctionT{lettimer:ReturnTypetypeofsetTimeout|nullnull;constdebouncedfunction(this:ThisParameterTypeT,...args:ParametersT){constcontextthis;constlater(){timernull;if(!immediate)fn.apply(context,args);};constcallNowimmediatetimernull;// 每次调用都重置计时器if(timer!null)clearTimeout(timer);timersetTimeout(later,wait);// immediate 模式下首次调用立即执行if(callNow)fn.apply(context,args);}asDebouncedFunctionT;debounced.cancel(){if(timer!null){clearTimeout(timer);timernull;}};returndebounced;}配套的单元测试使用 Vitest可直接运行// debounce.test.tsimport{describe,it,expect,vi,beforeEach,afterEach}fromvitest;import{debounce}from./debounce;describe(debounce,(){beforeEach(()vi.useFakeTimers());afterEach(()vi.useRealTimers());it(延迟执行多次调用只执行最后一次,(){constfnvi.fn();constddebounce(fn,100);d();d();d();expect(fn).not.toHaveBeenCalled();vi.advanceTimersByTime(100);expect(fn).toHaveBeenCalledTimes(1);});it(immediate 模式下首次立即执行,(){constfnvi.fn();constddebounce(fn,100,true);d();expect(fn).toHaveBeenCalledTimes(1);d();expect(fn).toHaveBeenCalledTimes(1);// 窗口期内不重复执行});it(cancel 能取消待执行的调用,(){constfnvi.fn();constddebounce(fn,100);d();d.cancel();vi.advanceTimersByTime(200);expect(fn).not.toHaveBeenCalled();});});1.3 Ask 阶段的练习方法建议每天做三件事拿真实报错去问而不是自己猜。把完整堆栈贴进去问这个报错的原因是什么、怎么修、为什么。要求解释而非只给答案。追问为什么这样写、“有没有别的写法”这是积累判断力的关键。手动验证每个答案。跑一遍、改一个边界条件看它会不会挂。这一步不能省。1.4 何时可以进入下一阶段当你发现自己能预判 AI 大概会怎么答、并且能一眼看出答案里的问题时Ask 阶段就基本毕业了。此时你会自然产生新需求“这个功能涉及五六个文件一句句问太累了”——这就是进入 Plan 阶段的信号。二、Plan 阶段用计划把控复杂任务2.1 什么算复杂任务一个经验判据如果任务的完成需要改动超过 3 个文件或者需要你先想清楚步骤才能动手就属于复杂任务。典型场景包括重构一个模块、给现有系统加一个横切功能如日志、鉴权、迁移一个库的版本。这类任务的失败模式高度一致——方向错了越努力越糟。Plan 阶段的价值就是在动手前把方向对齐。2.2 Plan 的产出物一份可执行的任务清单好的计划不是一段散文而是可勾选、可验证、有依赖顺序的清单。以给 Express 应用加上请求级日志与耗时统计为例一份合格的计划长这样## 任务为 Express 应用添加请求日志与耗时统计 ### 前置调研 - [ ] 确认现有中间件注册顺序app.ts 第 20-40 行 - [ ] 确认日志库选型项目已依赖 winston复用而非新增 ### 实施步骤 - [ ] 1. 新建 src/middleware/requestLogger.ts - [ ] 2. 在 app.ts 中于路由注册之前挂载该中间件 - [ ] 3. 为每个请求生成 requestId使用 crypto.randomUUID - [ ] 4. 记录 method / path / status / duration - [ ] 5. 将 requestId 透传到响应头 X-Request-Id ### 验证 - [ ] 单元测试中间件对 200 与 500 响应均能正确记录 - [ ] 手动验证curl 一次接口检查日志字段完整2.3 计划对应的实现代码下面是与上述计划对应的完整可运行实现// src/middleware/requestLogger.tsimport{Request,Response,NextFunction}fromexpress;import{randomUUID}fromcrypto;importwinstonfromwinston;constloggerwinston.createLogger({level:info,format:winston.format.json(),transports:[newwinston.transports.Console()],});exportfunctionrequestLogger(req:Request,res:Response,next:NextFunction){constrequestIdrandomUUID();conststartprocess.hrtime.bigint();// 透传到响应头便于前端排查res.setHeader(X-Request-Id,requestId);// 响应结束时统一记录保证能拿到最终 statusres.on(finish,(){constdurationMsNumber(process.hrtime.bigint()-start)/1e6;logger.info(request,{requestId,method:req.method,path:req.originalUrl,status:res.statusCode,durationMs:Number(durationMs.toFixed(2)),});});next();}// src/app.tsimportexpressfromexpress;import{requestLogger}from./middleware/requestLogger;constappexpress();// 关键日志中间件必须在路由之前注册否则路由内的响应不会被统计app.use(requestLogger);app.get(/health,(_req,res)res.json({ok:true}));app.get(/boom,(){thrownewError(intentional error);});app.listen(3000,()console.log(listening on :3000));2.4 Plan 阶段的三条纪律先调研再列步骤。让 AI 先读相关文件、输出现状理解你确认无误后再让它出计划。计划要能被人读懂。如果计划里出现优化一下相关逻辑这种模糊表述打回去重写。一个步骤一个验证点。没有验证方式的步骤等于没有步骤。2.5 何时可以进入下一阶段当你发现计划本身已经足够清晰、剩下的只是按部就班敲代码并且你已经能信任 AI 在这个清晰边界内自主执行时就可以进入 Agent 阶段了。注意信任的是边界清晰的执行不是无脑放手。三、Agent 阶段在清晰边界内信任执行3.1 Agent 与 Ask/Plan 的本质区别Ask 是你说一句它答一句Plan 是它给你清单你确认Agent 是它自己读文件、改文件、跑测试、根据结果调整。Agent 的能力来自工具调用循环读 → 想 → 改 → 跑 → 看结果 → 再改。这也意味着 Agent 的风险点在于它会真的修改你的文件。所以进入 Agent 阶段的前提是边界已经由 Plan 阶段界定清楚。3.2 一个 Agent 任务的最小示例假设 Plan 阶段已经确认要在utils/下新增一个retry.ts实现带指数退避的异步重试并配套测试不改动其他文件。给 Agent 的任务描述应该长这样任务边界只允许在 src/utils/ 目录下新增文件不得修改其他目录。 目标实现 retry(fn, options) 异步重试工具。 要求 - 参数fn 为返回 Promise 的函数options 含 retries、baseDelay、maxDelay、shouldRetry - 指数退避第 n 次重试等待 min(baseDelay * 2^n, maxDelay) - shouldRetry(err, attempt) 返回 false 时立即抛出 - 配套单元测试覆盖成功、重试后成功、耗尽重试、shouldRetry 拦截四种情况 完成标准npm test 全绿且 git diff 只显示 src/utils/ 下的新增文件。Agent 产出的实现大致如下// src/utils/retry.tsexportinterfaceRetryOptions{retries?:number;baseDelay?:number;maxDelay?:number;shouldRetry?:(err:unknown,attempt:number)boolean;}constsleep(ms:number)newPromise((r)setTimeout(r,ms));exportasyncfunctionretryT(fn:()PromiseT,options:RetryOptions{}):PromiseT{const{retries3,baseDelay100,maxDelay5000,shouldRetry()true,}options;letlastErr:unknown;for(letattempt0;attemptretries;attempt){try{returnawaitfn();}catch(err){lastErrerr;// 最后一次尝试失败或调用方明确不重试直接抛出if(attemptretries||!shouldRetry(err,attempt))throwerr;constdelayMath.min(baseDelay*2**attempt,maxDelay);awaitsleep(delay);}}// 理论上不可达仅为类型收窄throwlastErr;}配套测试// src/utils/retry.test.tsimport{describe,it,expect,vi}fromvitest;import{retry}from./retry;describe(retry,(){it(首次成功直接返回,async(){constfnvi.fn().mockResolvedValue(ok);awaitexpect(retry(fn,{baseDelay:1})).resolves.toBe(ok);expect(fn).toHaveBeenCalledTimes(1);});it(失败后重试成功,async(){constfnvi.fn().mockRejectedValueOnce(newError(fail)).mockResolvedValue(ok);awaitexpect(retry(fn,{baseDelay:1})).resolves.toBe(ok);expect(fn).toHaveBeenCalledTimes(2);});it(耗尽重试后抛出最后的错误,async(){constfnvi.fn().mockRejectedValue(newError(always));awaitexpect(retry(fn,{retries:2,baseDelay:1})).rejects.toThrow(always);expect(fn).toHaveBeenCalledTimes(3);// 1 次初始 2 次重试});it(shouldRetry 返回 false 时立即抛出,async(){constfnvi.fn().mockRejectedValue(newError(fatal));awaitexpect(retry(fn,{baseDelay:1,shouldRetry:()false})).rejects.toThrow(fatal);expect(fn).toHaveBeenCalledTimes(1);});});3.3 如何信任而不失控信任 Agent 的正确姿势是用可验证的完成标准兜底而不是用人盯人的方式。具体做法给任务写死边界如只允许改 src/utils/Agent 越界时你能从 diff 里一眼看出。给完成标准写死验证方式如npm test 全绿让 Agent 自己跑、自己看结果、自己修。事后 review diff 而非 review 过程。过程交给 Agent结果由你验收。小步提交。每个 Agent 任务对应一个 commit出问题能一键回滚。3.4 Agent 阶段的典型坑边界不清导致误改没写只改某目录Agent 顺手重构了无关文件。→ 任务描述里显式写边界。完成标准模糊只写实现功能Agent 可能不写测试就宣布完成。→ 完成标准必须可执行、可验证。一次给太大任务把 Plan 阶段整份清单丢给 Agent。→ 拆成单个步骤逐个交给 Agent。四、三阶段如何平滑衔接三个阶段不是割裂的而是一条能力递进链。下面这张对照表帮你判断自己处在哪、下一步该练什么阶段你的角色AI 的角色核心产出毕业信号Ask提问者答疑同事可验证的代码片段/解释能预判并挑出答案的问题Plan决策者项目经理可勾选的任务清单计划清晰到只剩敲代码Agent验收者执行工程师通过验证的改动能用边界标准兜住自主执行衔接的关键动作是每个阶段都留下可复用的资产Ask 阶段留下的是一批好问题模板Plan 阶段留下的是一份份任务清单Agent 阶段留下的是一串小步 commit。这些资产会让你在下一阶段起步时不是从零开始。五、常见误区与纠正误区一跳过 Ask 直接上 Agent。纠正你无法验收你看不懂的东西。先花一周在 Ask 阶段把工具脾气摸熟。误区二Plan 阶段写伪计划。纠正计划里每一步都要有验证方式。优化性能不是步骤把列表接口的 N1 查询改为批量查询并用 EXPLAIN 确认走了索引才是。误区三Agent 阶段全程盯着。纠正盯着过程说明你还不信任边界。把精力放在写清边界和完成标准上过程放手。误区四三个阶段只用一种。纠正真实工作中三者是混用的。遇到陌生报错回到 Ask接到大需求先 Plan边界清晰后交 Agent。总结新手使用 AI 编程工具最稳妥的路径是Ask → Plan → Agent的递进Ask 起步目的是建立对模型能力边界、提问质量、答案验证的三重认知产出可验证的代码片段Plan 居中目的是把复杂任务的模糊需求转成可勾选、可验证、有依赖顺序的任务清单在动手前对齐方向Agent 收尾目的是在清晰边界与可执行完成标准的兜底下信任 AI 自主执行并只验收结果。
