1. 用不好 Copilot问题大多出在场景判断这一环Copilot 用得好不好跟会不会写提示词关系不大真正拉开差距的是三件事场景判断、模式选择、提示词模板。很多开发者把它当成一个会说话的命令行随手丢一句话就坐等结果运气好能跑通运气差要么改了一堆无关文件要么反复对话五轮还在原地打转。这不是提示词功力问题而是顺序搞反了正常人应该是先判断任务类型再选执行方式最后才考虑怎么开口。我把这条链拆成了三段场景 → 模式 → 模板照着走输出质量会稳定很多。这篇会把六个高频场景的识别清单、场景与模式的对应关系、五套能直接抄的提示词模板以及我实际踩过的坑一次整理出来。适合两类人一是已经在用 Copilot 但总觉得输出飘忽不定的开发者二是正准备把这套工具纳入日常流程、不想从学费开始交起的新手。1.1 一个典型的翻车现场先说个我身边真实发生过的事。某同学接手一个老项目需求是列表页性能不太好优化一下。他打开 Copilot切到可以自主执行多步修改的模式原样输入这句话。十分钟之后再看模型主动翻了五个相关文件调整了组件结构换了一套状态管理写法还把样式名和若干变量一并重命名。最后跑测试挂掉一片只能回滚。他后来自己定位问题发现瓶颈只是页面里一段被重复执行了上千次的数组过滤改一行就好。这个案例的问题不在模型在场景判断。性能优化这种模糊目标恰恰是最不应该丢给自主执行模式的活。模型眼里只有仓库索引和代码统计它不知道你的瓶颈到底在哪不知道你能接受多大的回归风险更不知道性能不好指的是首屏时间、交互卡顿还是内存占用。它只能做一件它最擅长的事按照它自己脑补的意图大范围地改。1.2 为什么我们总是不自觉地一句话问到底这不是技巧问题是搜索框训练出来的习惯。大家打开对话式界面潜意识还在用输入关键词 → 得到答案的模型恨不得一句话解决问题。但编程助手本质上是结对程序员不是搜索引擎。你跟真人结对时至少会把需求描述清楚、指出涉及的代码模块、说明验收条件对吧跟 AI 对话也是同一套规矩。所以我在带团队用 Copilot 时第一件事不是教提示词怎么写而是先立一个规矩动手之前先回答三个问题——我要交付的是什么产物这次改动影响多大范围我对自己要的结果到底有多确定这三个问题就是场景识别的核心线索也是后面所有模式选择的依据。1.3 场景识别的三条线索第一条看产物。任务最终要交付的是一段解释还是一段代码是修复一个 bug还是把结论摆出来这决定了它是理解类、编写类还是调试类。第二条看范围。改动的量级是一个函数、一个文件还是跨模块、跨页面范围越大对可控性的要求越高越不能上来就用完全自主模式。第三条看确定性。目标越明确比如把 A 接口从同步改成异步签名不变越适合直接进入执行模式目标越模糊比如优化页面性能越需要先用对话完成定位和方案设计把模糊目标收敛成明确任务再进入修改阶段。这三条线索在接下来的场景清单里会反复出现你可以直接用它们给任何任务做一次前置体检。2. 六类高频场景先别急着写提示词识别任务类型把日常任务按产物 范围 确定性三个维度我会分成六类理解类、新功能类、重构类、调试类、脚本命令类、文档类。这六类几乎覆盖了我日常 80% 的请求剩下的是混合类稍后单独说。2.1 六类场景速览表下面这张表是我自己长期用下来的场景识别清单可以直接照着比对。场景典型任务识别信号最容易踩的坑理解类解释代码、梳理调用链、评估改动风险需求里带着这段代码在干嘛看懂之前就急着让它改新功能类新增接口、函数、组件、模块有需求描述但手头还没有代码让自主执行一口气写完一个仓库重构类拆函数、迁移接口、统一写法逻辑不变但结构要变没有测试兜底就大范围改动调试类报错、偶发失败、性能退化有堆栈、有日志、有复现步骤只甩一句报错了不给日志脚本/命令类shell、正则、SQL、配置片段一次性任务跟主项目弱相关让它写教程而不是直接给脚本文档类注释、README、commit message、测试用例目标产物是文字干着干着让它顺手改代码理解类最好识别只要你的诉求是以这个东西是怎么工作的为什么会这样写开头的它就是理解类。新功能类刚好相反诉求是给我一个能完成 xxx 的东西。2.2 容易混淆的边界场景三类场景经常会混血判断错了就容易翻车。第一种是新功能与重构的混淆。新功能的目标清楚但实现方案不确定比如加一个带缓存的查询接口重构是结果确定但路径要探索比如把这段逻辑收敛到一个工具函数。前者我要多和模型讨论方案后者我则更关注测试和调用点。把重构当新功能来写模型会自由发挥接口设计把新功能当重构来改模型又会因为找不到原有调用点而卡壳。第二种是理解与调试的混淆。遇到一个偶发报错很多人会直接贴一句帮我看看为什么失败。这其实是先理解通读代码再调试定位竞态两步一步到位只会得到泛泛的猜测。我一般先切对话聊流程把代码的执行顺序和状态变化拎清楚再切到调试模板给日志让它基于事实收敛根因。第三种是文档类场景里藏了新功能需求。比如让模型补 README结果它顺手重构了目录结构因为认真负责的模型会觉得项目结构不清晰也该改。这类越界动作需要在提示词里明确划界。这也是为什么我一直强调模板里约束这一块必须有。2.3 混合场景怎么处理碰到复杂任务我的做法是拆成多个场景依次处理而不是让模型一口气完成。拿优化列表页性能来说我会先把它当理解类列出页面核心渲染链路让模型指出最可疑的瓶颈。然后再当调试类针对瓶颈贴日志做验证。最后才是重构类用明确的修改指令和测试兜底去改。每一步用一种模式不贪心。这也是为什么我前面说场景判断是整条链的第一步。这一步错了后面所有模式选择、提示词结构都是建立在错误地基上只会错上加错。3. 模式选择控制粒度和上下文范围才是判据场景判断完了接下来是选模式。目前主流 AI 编程助手的交互方式本质上就四类自动补全、对话、内联编辑、自主执行。不同产品叫法不太一样有的叫 Agent有的叫 Edit有的叫 Ask别被名字带偏。我判断该用哪个模式的依据只有两条轴一条是控制粒度一条是上下文范围。控制粒度指的是你对输出的每一步干预到什么程度。自动补全是逐字符的你盯着光标后面的每一个 token自主执行则是目标级的你把目标丢进去它在任务中途怎么做你几乎不干预。上下文范围指的是模型在生成时能看到多大面积的代码。自动补全通常只看光标附近几百行对话可以配合主动拖入多个文件而自主执行模式可以借助仓库索引导到整个代码库。3.1 四种模式的一句话定位自动补全适合那些你已经知道答案模样、只是懒得敲的场景样板代码、重复结构、固定模式的注释效率极高也是所有模式里最不挑提示词的。对话适合理解、设计、方案对比。它控制粒度适中上下文范围可以很大你能反复追问、摆出多个方案让它比较也可以让它帮你梳理一个陌生模块。内联编辑适合精准修改。把某一段代码圈出来告诉它只改这一段它返回的是针对圈选区域的补丁不会去动旁边的文件。修局部 bug、改单个函数我第一反应都是它。自主执行适合跨文件的机械重构比如批量迁移接口、统一调用方式、多文件替换。它的天花板最高失控风险也最高必须配合强约束使用。3.2 场景与模式对应表场景首选模式次选模式不推荐理解类对话内联编辑圈代码追问自主执行新功能类对话生成代码 → 内联编辑应用自动补全纯样板时自主执行范围太不可控重构类内联编辑 / 自主执行分步汇报对话先出计划自动补全调试类内联编辑针对报错片段对话分析日志自主执行脚本/命令类对话自动补全极短命令自主执行文档类对话自动补全注释场景自主执行规律很清晰判断越模糊、范围越大、越需要讨论的场景越靠对话回合判断越明确、范围越收敛、改动越机械的场景越适合内联编辑或自主执行。自动补全永远服务于最局部的需求。一句话总结越不确定越要多问越确定越可以放开手让它干。3.3 为什么一句话目标放给自主执行必然翻车自主执行模式本身没有业务判断力。它不知道性能优化对你来说到底要保哪个指标不知道这个模块在下个迭代就会被替换掉所以不值得大改也不知道你只改了风格但没改语义会带来多少回归。这些信息模型不会凭空知道只能靠提示词给清楚。所以我给自主执行模式设了一条规则目标、边界、验收标准三者缺一就不用它。目标不清晰先用对话收敛边界不清晰先圈定允许修改的文件清单验收标准不清晰先写清楚测试和不许越界的说法。只有三者齐了自主执行才从赌徒变成靠谱的执行者。这条规则我后面给出的重构类模板里会完整体现。4. 提示词模板五个信息块 五套直接抄用的模板模式选对了提示词就有章可循。我写提示词从来不只是说人话——你要做的是让模型在概率空间里更容易命中正确答案。我把自己的模板拆成五个信息块任务、上下文、约束、输出格式、验收标准。任务描述要说明做什么事越具体越好。上下文告诉模型它该基于什么材料回答可以是代码片段、日志、文件路径。约束划出禁区比如不要引入新依赖不要扩大范围。输出格式限定产品形态比如只给脚本不要教程。验收标准是最容易被忽略的一块它告诉模型什么算完成。很多人抱怨AI 总是改过头根因基本都是缺了验收标准——模型不知道什么时候停就会按它自己想象的终点干。下面五套模板按六类场景精简过每套都留了占位符。直接复制改字段就行用熟了自然会变成自己的话。4.1 理解类模板带着问题读代码帮我看懂下面这段 {{语言}} 代码它来自 {{模块/项目名}}。 背景这段代码最近出现过一次 {{具体故障}}我想评估改动它的风险。 【代码】 {{粘贴完整代码或给出文件路径和函数名}} 请输出 1. 整体职责两句话以内 2. 核心执行流程按调用顺序 3. 输入输出与副作用 4. 最可疑的风险点 不确定的地方请直接说不确定不要替我补全。带问题去读代码比泛泛地说解释一下精确得多。因为评估故障风险这个目的会把模型的注意力引向异常路径、错误处理和副作用而不是平均看待每一个函数。我在接手上一个人留下的核心模块时用得很频繁它能把半小时的通读压缩成几分钟的定向阅读。最后那句不确定就说不是客套是防幻觉护栏——模型在代码不完整的时候特别擅长脑补而脑补出来的结论往往就是下一次事故的起点。使用这个模板时我通常停留在对话模式先让它给整体结论再选中某个可疑函数用内联编辑追问细节。4.2 新功能类模板需求列清单验收写样例用 {{技术栈}} 写一个 {{功能}}。 需求 - 功能点1输入 {{样例A}}期望输出 {{样例B}} - 功能点2 约束 - 不要引入新的依赖如果必须引入请先列出理由 - 代码风格对齐项目里 {{现有模块/文件}} 的写法 - 只输出实现代码和最简调用示例不要解释思路 验收 - 满足上面的需求点1和需求点2 - 在 {{运行环境}} 下可正常编译/运行写新功能时我基本不用自主执行直接落地生产代码而是让对话模式给出方案和完整实现确认无误后再复制进编辑器或交给内联编辑应用。需求写成列表而不是散文是因为列表天然拒绝歧义每个需求点后面跟一句输入输出样例模型就不太可能把接口设计成其他形状。不要引入新依赖这类约束要放在需求之后而不是散在对话里因为模型对很晚出现的约束的遵守率明显更低。验收里写可正常编译/运行看起来像废话实际作用很大——它逼着模型把接口串起来给你完整可跑的代码块而不是一堆孤立函数。4.3 重构类模板给自主执行模式套上缰绳这是一个跨文件重构任务请使用自主执行模式完成。 目标把 {{函数/模块}} 从 A 改成 B保持对外行为不变。 只允许修改以下文件 {{文件清单}} 执行步骤 1. 先搜索所有引用点输出清单 2. 修改核心实现 3. 逐个调整引用点 4. 运行 {{测试命令}}直到全部通过 每完成一步先停下汇报结果经我确认后再继续下一步。 验收标准 - 原有对外接口签名不变 - 测试全部通过 - 不允许顺手做其他重构这套模板是我目前唯一敢把大改任务放给自主执行模式的情况。关键在于分步汇报这四个字它相当于把一个大黑盒执行拆成四次可控的小执行每完成一步你都有机会喊停。有一次我让模型重构一个内部工具集整个过程它改了六个文件但因为每步都停下汇报我在第二步就发现它的引用扫描漏了一个入口及时让它补上最后完全没出乱子。边界、步骤、节奏、验收四件事缺一不可。哪怕你觉得模板啰嗦也不要删掉每完成一步先停下这句它是整份模板的刹车片。4.4 调试类模板贴日志原文别自己下结论下面这个 {{测试/功能}} 会间歇性失败怀疑跟 {{并发/时序/缓存}} 有关。 复现频率{{大概每几次跑会出现一次}} 日志原文 {{粘贴原始日志不要转述}} 请输出 1. 根据日志还原出的执行顺序 2. 最可疑的根因按可能性从高到低排序 3. 最小修复方案不改变现有对外行为 4. 如何验证修复有效调试类提示词最容易翻车的地方是很多人怕模型看不懂日志先自己总结一遍我觉得像是缓存问题。你一旦给出结论模型大概率顺着你的结论找证据真正的根因反而被淹没。所以标准动作是贴日志原文不加任何二手转述。让模型按可能性从高到低排序而不是只给一个答案是因为偶发问题往往不是单点根因多轮收敛时需要候选清单做参照。修复环节我习惯切到内联编辑在报错函数上直接应用补丁比在对话里来回贴代码效率高得多。4.5 脚本/命令类模板短平快边界写死写一个 {{bash/Python/SQL}} 脚本用途是 {{用途}}。 运行环境{{操作系统/数据库版本}} 边界约束 - 输入目录不存在时报错退出退出码非 0 - 只处理 {{条件}} 的文件不要递归删除目录 - 出错时输出错误信息并立即停止 输出格式只输出脚本本身和一句功能说明不要教程。脚本类任务输出简单模板不需要写那么长但失败行为必须写死。默认情况下模型倾向于生成温和的代码——能跳过就跳过能继续就继续但脚本恰恰需要快速失败目录不存在要报错退出文件模式不匹配要返回非零错误信息要能直接定位。不写清楚边界它生成的版本一旦在凌晨批处理里静默跳过数据那才是真正的灾难。这类模板我在对话模式里用一般三十秒就能跑完一轮属于性价比最高的场景。5. 跑了几个版本之后才总结出的避坑清单模板有了不等于万事大吉。工具本身迭代很快以下五个坑是我在真实项目里踩过、或者看同事踩过之后总结出来最有普适性的几条。5.1 提示词不是越长越好注意力的带宽是有限的有一次我想让模型重构一个核心模块把整个文件 2000 多行代码全贴进了上下文结果它给出的方案东一榔头西一棒槌明显被无关逻辑干扰了。后来换成只贴关键的 30 行最小复现片段再补一句完整代码在 src/core/xxx.ts搜索函数名 xxx 就能找到效果立刻正常。长上下文不等于高信息密度。给上下文要像给简历——只放与本次任务直接相关的内容其余用路径和函数名做索引。模型确实能处理长上下文但它处理长上下文时的注意力会被稀释无关信息越多它越难抓住真问题。5.2 对话五轮无果换模式重开一局比继续追问有效有个偶发报错我在侧边栏跟模型来回聊了五轮它一直在分析可能的并发原因越聊越玄。后来我把报错所在的函数用内联编辑圈起来直接让它输出最小修复补丁一轮就对了。原因并不复杂前几轮的猜测已经污染了对话上下文模型会顺着错误的讨论继续编。内联编辑的上下文是干净的只有圈选代码和本次指令反而更容易抓到重点。所以我的规则是同一个问题在对话里追问超过三轮没有实质进展就换模式重开。5.3 自主执行一次跑完五步等于把风险攒到最后一刻第一次用自主执行模式时我让它一口气完成扫描调用点、改实现、改调用点、跑测试它一条龙跑完我也图省事没中断。结果它改到第三处时路径判断错了后面的测试全挂我再要从一堆改动里分辨哪里是它的笔误非常痛苦。现在凡是跨文件任务一律要求分步汇报每完成一步我确认一次。代价是多了二三十秒交互收益是整个流程完全可控。这个取舍非常值。5.4 验收标准比约束更重要不要扩大范围能挡住习惯性越界但对最终结果没有闭环。真正让模型知道到这里就算完的是验收标准。我后来观察过几次不加验收标准的输出发现模型默认有一套自己的完成定义它觉得注释没了是缺陷就顺手补注释觉得变量名不顺眼就顺手重命名。这些在它看来都是负责任在你看来全是噪音。写清验收比我反复强调不要改别的管用得多。5.5 用全仓库索引的自主模式前先自己过一遍代码边界自主执行模式可以借助仓库索引看到整个项目这对效率是好事但也要先想清楚一件事代码库里有没有不适合外传的敏感内容比如密钥、内部地址、客户数据。这跟信不信任模型没关系纯粹是使用边界的问题。我的习惯是需要动用全仓能力之前先在本地自查一遍要开放的范围把敏感内容剔除出任务区域。把好这个关卡比事后补救省心太多。6. 个人体会把三段式变成肌肉记忆这套流程现在对我已经是一种条件反射。接到任何任务我心里会快速过一遍这是理解、新功能、重构、调试、脚本还是文档我应该停在哪一层——先对话收敛还是直接内联编辑动手还是可以把完整计划交给自主执行模板里缺不缺上下文和验收标准整个过程大概二十秒但它把 Copilot 的输出从运气变成了及格线。最后分享一个具体的小技巧。我把上面五套模板存在编辑器里做成一组 snippet使用时复制改两个字段就行。遇到理解任务敲一个前缀呼出模板遇到重构任务复制那份带分步汇报的模板。与其每次琢磨怎么造句不如固定句式把精力留给真正需要人来做决策的部分——判断场景。工具会迭代模式名会变但这套场景 → 模式 → 模板的判断框架短期不会有变化。下次再打开 Copilot先别急着打字花二十秒判断一下场景你会发现很多之前的玄学问题其实都是顺序问题。 
长河君 · 2026/10/20 1:56:22 · 阅读 1.2k Copilot用不好？问题出在场景判断：场景→模式→模板三段式
1. 用不好 Copilot问题大多出在场景判断这一环Copilot 用得好不好跟会不会写提示词关系不大真正拉开差距的是三件事场景判断、模式选择、提示词模板。很多开发者把它当成一个会说话的命令行随手丢一句话就坐等结果运气好能跑通运气差要么改了一堆无关文件要么反复对话五轮还在原地打转。这不是提示词功力问题而是顺序搞反了正常人应该是先判断任务类型再选执行方式最后才考虑怎么开口。我把这条链拆成了三段场景 → 模式 → 模板照着走输出质量会稳定很多。这篇会把六个高频场景的识别清单、场景与模式的对应关系、五套能直接抄的提示词模板以及我实际踩过的坑一次整理出来。适合两类人一是已经在用 Copilot 但总觉得输出飘忽不定的开发者二是正准备把这套工具纳入日常流程、不想从学费开始交起的新手。1.1 一个典型的翻车现场先说个我身边真实发生过的事。某同学接手一个老项目需求是列表页性能不太好优化一下。他打开 Copilot切到可以自主执行多步修改的模式原样输入这句话。十分钟之后再看模型主动翻了五个相关文件调整了组件结构换了一套状态管理写法还把样式名和若干变量一并重命名。最后跑测试挂掉一片只能回滚。他后来自己定位问题发现瓶颈只是页面里一段被重复执行了上千次的数组过滤改一行就好。这个案例的问题不在模型在场景判断。性能优化这种模糊目标恰恰是最不应该丢给自主执行模式的活。模型眼里只有仓库索引和代码统计它不知道你的瓶颈到底在哪不知道你能接受多大的回归风险更不知道性能不好指的是首屏时间、交互卡顿还是内存占用。它只能做一件它最擅长的事按照它自己脑补的意图大范围地改。1.2 为什么我们总是不自觉地一句话问到底这不是技巧问题是搜索框训练出来的习惯。大家打开对话式界面潜意识还在用输入关键词 → 得到答案的模型恨不得一句话解决问题。但编程助手本质上是结对程序员不是搜索引擎。你跟真人结对时至少会把需求描述清楚、指出涉及的代码模块、说明验收条件对吧跟 AI 对话也是同一套规矩。所以我在带团队用 Copilot 时第一件事不是教提示词怎么写而是先立一个规矩动手之前先回答三个问题——我要交付的是什么产物这次改动影响多大范围我对自己要的结果到底有多确定这三个问题就是场景识别的核心线索也是后面所有模式选择的依据。1.3 场景识别的三条线索第一条看产物。任务最终要交付的是一段解释还是一段代码是修复一个 bug还是把结论摆出来这决定了它是理解类、编写类还是调试类。第二条看范围。改动的量级是一个函数、一个文件还是跨模块、跨页面范围越大对可控性的要求越高越不能上来就用完全自主模式。第三条看确定性。目标越明确比如把 A 接口从同步改成异步签名不变越适合直接进入执行模式目标越模糊比如优化页面性能越需要先用对话完成定位和方案设计把模糊目标收敛成明确任务再进入修改阶段。这三条线索在接下来的场景清单里会反复出现你可以直接用它们给任何任务做一次前置体检。2. 六类高频场景先别急着写提示词识别任务类型把日常任务按产物 范围 确定性三个维度我会分成六类理解类、新功能类、重构类、调试类、脚本命令类、文档类。这六类几乎覆盖了我日常 80% 的请求剩下的是混合类稍后单独说。2.1 六类场景速览表下面这张表是我自己长期用下来的场景识别清单可以直接照着比对。场景典型任务识别信号最容易踩的坑理解类解释代码、梳理调用链、评估改动风险需求里带着这段代码在干嘛看懂之前就急着让它改新功能类新增接口、函数、组件、模块有需求描述但手头还没有代码让自主执行一口气写完一个仓库重构类拆函数、迁移接口、统一写法逻辑不变但结构要变没有测试兜底就大范围改动调试类报错、偶发失败、性能退化有堆栈、有日志、有复现步骤只甩一句报错了不给日志脚本/命令类shell、正则、SQL、配置片段一次性任务跟主项目弱相关让它写教程而不是直接给脚本文档类注释、README、commit message、测试用例目标产物是文字干着干着让它顺手改代码理解类最好识别只要你的诉求是以这个东西是怎么工作的为什么会这样写开头的它就是理解类。新功能类刚好相反诉求是给我一个能完成 xxx 的东西。2.2 容易混淆的边界场景三类场景经常会混血判断错了就容易翻车。第一种是新功能与重构的混淆。新功能的目标清楚但实现方案不确定比如加一个带缓存的查询接口重构是结果确定但路径要探索比如把这段逻辑收敛到一个工具函数。前者我要多和模型讨论方案后者我则更关注测试和调用点。把重构当新功能来写模型会自由发挥接口设计把新功能当重构来改模型又会因为找不到原有调用点而卡壳。第二种是理解与调试的混淆。遇到一个偶发报错很多人会直接贴一句帮我看看为什么失败。这其实是先理解通读代码再调试定位竞态两步一步到位只会得到泛泛的猜测。我一般先切对话聊流程把代码的执行顺序和状态变化拎清楚再切到调试模板给日志让它基于事实收敛根因。第三种是文档类场景里藏了新功能需求。比如让模型补 README结果它顺手重构了目录结构因为认真负责的模型会觉得项目结构不清晰也该改。这类越界动作需要在提示词里明确划界。这也是为什么我一直强调模板里约束这一块必须有。2.3 混合场景怎么处理碰到复杂任务我的做法是拆成多个场景依次处理而不是让模型一口气完成。拿优化列表页性能来说我会先把它当理解类列出页面核心渲染链路让模型指出最可疑的瓶颈。然后再当调试类针对瓶颈贴日志做验证。最后才是重构类用明确的修改指令和测试兜底去改。每一步用一种模式不贪心。这也是为什么我前面说场景判断是整条链的第一步。这一步错了后面所有模式选择、提示词结构都是建立在错误地基上只会错上加错。3. 模式选择控制粒度和上下文范围才是判据场景判断完了接下来是选模式。目前主流 AI 编程助手的交互方式本质上就四类自动补全、对话、内联编辑、自主执行。不同产品叫法不太一样有的叫 Agent有的叫 Edit有的叫 Ask别被名字带偏。我判断该用哪个模式的依据只有两条轴一条是控制粒度一条是上下文范围。控制粒度指的是你对输出的每一步干预到什么程度。自动补全是逐字符的你盯着光标后面的每一个 token自主执行则是目标级的你把目标丢进去它在任务中途怎么做你几乎不干预。上下文范围指的是模型在生成时能看到多大面积的代码。自动补全通常只看光标附近几百行对话可以配合主动拖入多个文件而自主执行模式可以借助仓库索引导到整个代码库。3.1 四种模式的一句话定位自动补全适合那些你已经知道答案模样、只是懒得敲的场景样板代码、重复结构、固定模式的注释效率极高也是所有模式里最不挑提示词的。对话适合理解、设计、方案对比。它控制粒度适中上下文范围可以很大你能反复追问、摆出多个方案让它比较也可以让它帮你梳理一个陌生模块。内联编辑适合精准修改。把某一段代码圈出来告诉它只改这一段它返回的是针对圈选区域的补丁不会去动旁边的文件。修局部 bug、改单个函数我第一反应都是它。自主执行适合跨文件的机械重构比如批量迁移接口、统一调用方式、多文件替换。它的天花板最高失控风险也最高必须配合强约束使用。3.2 场景与模式对应表场景首选模式次选模式不推荐理解类对话内联编辑圈代码追问自主执行新功能类对话生成代码 → 内联编辑应用自动补全纯样板时自主执行范围太不可控重构类内联编辑 / 自主执行分步汇报对话先出计划自动补全调试类内联编辑针对报错片段对话分析日志自主执行脚本/命令类对话自动补全极短命令自主执行文档类对话自动补全注释场景自主执行规律很清晰判断越模糊、范围越大、越需要讨论的场景越靠对话回合判断越明确、范围越收敛、改动越机械的场景越适合内联编辑或自主执行。自动补全永远服务于最局部的需求。一句话总结越不确定越要多问越确定越可以放开手让它干。3.3 为什么一句话目标放给自主执行必然翻车自主执行模式本身没有业务判断力。它不知道性能优化对你来说到底要保哪个指标不知道这个模块在下个迭代就会被替换掉所以不值得大改也不知道你只改了风格但没改语义会带来多少回归。这些信息模型不会凭空知道只能靠提示词给清楚。所以我给自主执行模式设了一条规则目标、边界、验收标准三者缺一就不用它。目标不清晰先用对话收敛边界不清晰先圈定允许修改的文件清单验收标准不清晰先写清楚测试和不许越界的说法。只有三者齐了自主执行才从赌徒变成靠谱的执行者。这条规则我后面给出的重构类模板里会完整体现。4. 提示词模板五个信息块 五套直接抄用的模板模式选对了提示词就有章可循。我写提示词从来不只是说人话——你要做的是让模型在概率空间里更容易命中正确答案。我把自己的模板拆成五个信息块任务、上下文、约束、输出格式、验收标准。任务描述要说明做什么事越具体越好。上下文告诉模型它该基于什么材料回答可以是代码片段、日志、文件路径。约束划出禁区比如不要引入新依赖不要扩大范围。输出格式限定产品形态比如只给脚本不要教程。验收标准是最容易被忽略的一块它告诉模型什么算完成。很多人抱怨AI 总是改过头根因基本都是缺了验收标准——模型不知道什么时候停就会按它自己想象的终点干。下面五套模板按六类场景精简过每套都留了占位符。直接复制改字段就行用熟了自然会变成自己的话。4.1 理解类模板带着问题读代码帮我看懂下面这段 {{语言}} 代码它来自 {{模块/项目名}}。 背景这段代码最近出现过一次 {{具体故障}}我想评估改动它的风险。 【代码】 {{粘贴完整代码或给出文件路径和函数名}} 请输出 1. 整体职责两句话以内 2. 核心执行流程按调用顺序 3. 输入输出与副作用 4. 最可疑的风险点 不确定的地方请直接说不确定不要替我补全。带问题去读代码比泛泛地说解释一下精确得多。因为评估故障风险这个目的会把模型的注意力引向异常路径、错误处理和副作用而不是平均看待每一个函数。我在接手上一个人留下的核心模块时用得很频繁它能把半小时的通读压缩成几分钟的定向阅读。最后那句不确定就说不是客套是防幻觉护栏——模型在代码不完整的时候特别擅长脑补而脑补出来的结论往往就是下一次事故的起点。使用这个模板时我通常停留在对话模式先让它给整体结论再选中某个可疑函数用内联编辑追问细节。4.2 新功能类模板需求列清单验收写样例用 {{技术栈}} 写一个 {{功能}}。 需求 - 功能点1输入 {{样例A}}期望输出 {{样例B}} - 功能点2 约束 - 不要引入新的依赖如果必须引入请先列出理由 - 代码风格对齐项目里 {{现有模块/文件}} 的写法 - 只输出实现代码和最简调用示例不要解释思路 验收 - 满足上面的需求点1和需求点2 - 在 {{运行环境}} 下可正常编译/运行写新功能时我基本不用自主执行直接落地生产代码而是让对话模式给出方案和完整实现确认无误后再复制进编辑器或交给内联编辑应用。需求写成列表而不是散文是因为列表天然拒绝歧义每个需求点后面跟一句输入输出样例模型就不太可能把接口设计成其他形状。不要引入新依赖这类约束要放在需求之后而不是散在对话里因为模型对很晚出现的约束的遵守率明显更低。验收里写可正常编译/运行看起来像废话实际作用很大——它逼着模型把接口串起来给你完整可跑的代码块而不是一堆孤立函数。4.3 重构类模板给自主执行模式套上缰绳这是一个跨文件重构任务请使用自主执行模式完成。 目标把 {{函数/模块}} 从 A 改成 B保持对外行为不变。 只允许修改以下文件 {{文件清单}} 执行步骤 1. 先搜索所有引用点输出清单 2. 修改核心实现 3. 逐个调整引用点 4. 运行 {{测试命令}}直到全部通过 每完成一步先停下汇报结果经我确认后再继续下一步。 验收标准 - 原有对外接口签名不变 - 测试全部通过 - 不允许顺手做其他重构这套模板是我目前唯一敢把大改任务放给自主执行模式的情况。关键在于分步汇报这四个字它相当于把一个大黑盒执行拆成四次可控的小执行每完成一步你都有机会喊停。有一次我让模型重构一个内部工具集整个过程它改了六个文件但因为每步都停下汇报我在第二步就发现它的引用扫描漏了一个入口及时让它补上最后完全没出乱子。边界、步骤、节奏、验收四件事缺一不可。哪怕你觉得模板啰嗦也不要删掉每完成一步先停下这句它是整份模板的刹车片。4.4 调试类模板贴日志原文别自己下结论下面这个 {{测试/功能}} 会间歇性失败怀疑跟 {{并发/时序/缓存}} 有关。 复现频率{{大概每几次跑会出现一次}} 日志原文 {{粘贴原始日志不要转述}} 请输出 1. 根据日志还原出的执行顺序 2. 最可疑的根因按可能性从高到低排序 3. 最小修复方案不改变现有对外行为 4. 如何验证修复有效调试类提示词最容易翻车的地方是很多人怕模型看不懂日志先自己总结一遍我觉得像是缓存问题。你一旦给出结论模型大概率顺着你的结论找证据真正的根因反而被淹没。所以标准动作是贴日志原文不加任何二手转述。让模型按可能性从高到低排序而不是只给一个答案是因为偶发问题往往不是单点根因多轮收敛时需要候选清单做参照。修复环节我习惯切到内联编辑在报错函数上直接应用补丁比在对话里来回贴代码效率高得多。4.5 脚本/命令类模板短平快边界写死写一个 {{bash/Python/SQL}} 脚本用途是 {{用途}}。 运行环境{{操作系统/数据库版本}} 边界约束 - 输入目录不存在时报错退出退出码非 0 - 只处理 {{条件}} 的文件不要递归删除目录 - 出错时输出错误信息并立即停止 输出格式只输出脚本本身和一句功能说明不要教程。脚本类任务输出简单模板不需要写那么长但失败行为必须写死。默认情况下模型倾向于生成温和的代码——能跳过就跳过能继续就继续但脚本恰恰需要快速失败目录不存在要报错退出文件模式不匹配要返回非零错误信息要能直接定位。不写清楚边界它生成的版本一旦在凌晨批处理里静默跳过数据那才是真正的灾难。这类模板我在对话模式里用一般三十秒就能跑完一轮属于性价比最高的场景。5. 跑了几个版本之后才总结出的避坑清单模板有了不等于万事大吉。工具本身迭代很快以下五个坑是我在真实项目里踩过、或者看同事踩过之后总结出来最有普适性的几条。5.1 提示词不是越长越好注意力的带宽是有限的有一次我想让模型重构一个核心模块把整个文件 2000 多行代码全贴进了上下文结果它给出的方案东一榔头西一棒槌明显被无关逻辑干扰了。后来换成只贴关键的 30 行最小复现片段再补一句完整代码在 src/core/xxx.ts搜索函数名 xxx 就能找到效果立刻正常。长上下文不等于高信息密度。给上下文要像给简历——只放与本次任务直接相关的内容其余用路径和函数名做索引。模型确实能处理长上下文但它处理长上下文时的注意力会被稀释无关信息越多它越难抓住真问题。5.2 对话五轮无果换模式重开一局比继续追问有效有个偶发报错我在侧边栏跟模型来回聊了五轮它一直在分析可能的并发原因越聊越玄。后来我把报错所在的函数用内联编辑圈起来直接让它输出最小修复补丁一轮就对了。原因并不复杂前几轮的猜测已经污染了对话上下文模型会顺着错误的讨论继续编。内联编辑的上下文是干净的只有圈选代码和本次指令反而更容易抓到重点。所以我的规则是同一个问题在对话里追问超过三轮没有实质进展就换模式重开。5.3 自主执行一次跑完五步等于把风险攒到最后一刻第一次用自主执行模式时我让它一口气完成扫描调用点、改实现、改调用点、跑测试它一条龙跑完我也图省事没中断。结果它改到第三处时路径判断错了后面的测试全挂我再要从一堆改动里分辨哪里是它的笔误非常痛苦。现在凡是跨文件任务一律要求分步汇报每完成一步我确认一次。代价是多了二三十秒交互收益是整个流程完全可控。这个取舍非常值。5.4 验收标准比约束更重要不要扩大范围能挡住习惯性越界但对最终结果没有闭环。真正让模型知道到这里就算完的是验收标准。我后来观察过几次不加验收标准的输出发现模型默认有一套自己的完成定义它觉得注释没了是缺陷就顺手补注释觉得变量名不顺眼就顺手重命名。这些在它看来都是负责任在你看来全是噪音。写清验收比我反复强调不要改别的管用得多。5.5 用全仓库索引的自主模式前先自己过一遍代码边界自主执行模式可以借助仓库索引看到整个项目这对效率是好事但也要先想清楚一件事代码库里有没有不适合外传的敏感内容比如密钥、内部地址、客户数据。这跟信不信任模型没关系纯粹是使用边界的问题。我的习惯是需要动用全仓能力之前先在本地自查一遍要开放的范围把敏感内容剔除出任务区域。把好这个关卡比事后补救省心太多。6. 个人体会把三段式变成肌肉记忆这套流程现在对我已经是一种条件反射。接到任何任务我心里会快速过一遍这是理解、新功能、重构、调试、脚本还是文档我应该停在哪一层——先对话收敛还是直接内联编辑动手还是可以把完整计划交给自主执行模板里缺不缺上下文和验收标准整个过程大概二十秒但它把 Copilot 的输出从运气变成了及格线。最后分享一个具体的小技巧。我把上面五套模板存在编辑器里做成一组 snippet使用时复制改两个字段就行。遇到理解任务敲一个前缀呼出模板遇到重构任务复制那份带分步汇报的模板。与其每次琢磨怎么造句不如固定句式把精力留给真正需要人来做决策的部分——判断场景。工具会迭代模式名会变但这套场景 → 模式 → 模板的判断框架短期不会有变化。下次再打开 Copilot先别急着打字花二十秒判断一下场景你会发现很多之前的玄学问题其实都是顺序问题。