1. 为什么命令行AI助手值得单独整理一份速查手册
很多人第一次接触命令行形态的AI编程助手时，都会经历一个相似的阶段：打开终端，输入一句自然语言，看着它开始读文件、改代码、跑测试，觉得挺神奇。但用不了几天，问题就来了——每次都要重新想怎么表达、怎么让它只改一个文件、怎么在它跑偏的时候及时打断、怎么把上一次的上下文接上。工具本身很强，但使用它的"手感"始终停留在碰运气阶段。
我自己最开始也是这样。前两周基本靠记忆和试错，同一个操作每次敲法都不一样，效率忽高忽低。直到有一次在做一个跨平台的小工具重构，涉及十几个文件的批量调整，我连续三次因为指令表述不清导致它改错了范围，回滚了两次才意识到：问题不在工具，而在我没有把高频操作沉淀成一套稳定的指令习惯。
这份速查手册就是那次教训之后的产物。它整理的是命令行AI编程助手里最常用的一批指令、快捷键和工作流组合，覆盖从会话启动、上下文管理、文件操作、代码修改到任务收尾的完整链路。适合两类人：一是刚上手、还在摸索怎么"说话"的新用户；二是已经用了一段时间、但操作方式比较随意、想系统化提升效率的老用户。不管你用的是哪一款命令行AI助手，底层的交互逻辑是相通的，这套整理都能直接参考。
需要说明的是，不同工具的具体命令词会有差异，但指令的语义类别和工作流的组织方式是高度一致的。我会在讲每个操作时说明它的意图和适用场景，你对照自己工具的实际命令替换即可。
2. 会话生命周期管理：从启动到收尾的完整指令链
2.1 启动阶段的三种进入方式与选择逻辑
命令行AI助手的启动方式直接决定了你后续能做什么。常见的进入方式有三类，各有明确的适用边界。
第一类是交互式会话模式，直接在项目根目录下启动，工具会加载当前目录作为工作区。这种方式适合探索性任务，比如"帮我看看这个模块的结构""这个报错可能出在哪"。它的优势是上下文连续，你可以像聊天一样逐步深入；劣势是每次启动都要重新建立对项目的理解，如果项目很大，前期加载会消耗一些时间。
第二类是单次指令模式，把一条指令直接作为参数传入，执行完就退出。适合脚本化场景，比如在CI流程里做一次代码检查，或者在git hook里做提交前的格式校验。这种模式不适合需要多轮交互的复杂任务，因为每次调用都是独立的，没有上下文记忆。
第三类是恢复模式，从上次中断的会话继续。这个在调试长任务时特别有用——比如你让助手重构一个模块，改到一半发现需要先确认某个接口的定义，这时候退出查资料，回来用恢复指令接着上次的进度继续，不用重新描述背景。
我个人的习惯是：探索用交互式，自动化用单次，长任务用恢复。三者切换的成本很低，但用对了能省不少重复描述的时间。
2.2 上下文窗口的查看、清理与压缩策略
上下文窗口是命令行AI助手里最容易被忽视、也最影响效果的一个概念。简单说，它就是助手能"记住"的对话和文件内容的总量。窗口满了之后，早期的内容会被挤出去，导致助手"忘记"你之前说过的约束条件。
查看当前上下文占用情况是第一个要养成的习惯。大多数工具都提供了查看token用量或上下文百分比的指令，通常在会话状态栏或者通过特定命令触发。我一般会在做大型重构前先看一眼，如果已经用了七八成，就先清理再开始，避免改到一半上下文溢出。
清理上下文有两个层次。轻量清理是移除最近几轮无关的对话，保留项目结构和关键约束；重量级清理是重置整个会话，只保留工作区状态。前者适合对话跑偏但项目理解还在的情况，后者适合彻底换任务方向时使用。
压缩是另一个实用功能。当上下文接近上限但你又不想丢失信息时，可以让工具把之前的对话和文件摘要成更短的版本。这个操作的本质是用信息密度换空间——细节会损失，但核心约束和决策记录能保留下来。我在处理超过两小时的长任务时，会在中途主动压缩一次，把前面的探索过程浓缩掉，给后面的实操留出空间。
注意：压缩不是无损的。压缩前最好把关键约束（比如"不要改数据库schema""保持现有API签名不变"）用显式指令再强调一遍，避免压缩后被稀释。
2.3 会话中断、恢复与状态保持的实操细节
中断会话有两种方式：正常退出和强制打断。正常退出会保存当前状态，下次可以用恢复指令接上；强制打断（通常是快捷键）会立即停止当前操作，但状态保存取决于工具实现，有些工具会丢失未提交的修改。
我的经验是：在让助手执行高风险操作（比如批量删除、大规模重命名）之前，先手动提交一次代码。这样即使中断后状态丢失，也能从git恢复。这个习惯看起来多余，但我至少遇到过三次因为中断导致工作区状态混乱、最后靠git reset救回来的情况。
恢复会话时，工具通常会重新加载工作区，但对话历史可能只保留摘要。这时候第一件事应该是用一句话确认当前任务目标，比如"我们之前在重构用户模块的校验逻辑，现在继续"。这句话的作用是帮助手快速对齐，避免它基于不完整的记忆做出错误判断。
状态保持还有一个技巧：把关键决策写进项目里的一个临时文件（比如TASK_NOTES.md），而不是只留在对话里。这样即使会话完全重置，助手也能通过读这个文件恢复上下文。这个做法在多人协作或者跨天任务里特别有用。
3. 高频操作指令的分类拆解与使用场景
3.1 文件读写类指令：精确控制助手的"视野范围"
命令行AI助手默认会读取工作区里的文件，但"默认读取"和"精确控制读取范围"是两回事。前者容易让助手在不相关的文件上浪费注意力，后者能让它聚焦在你真正关心的代码上。
指定文件读取是最基础的指令。当你只想让助手看某一个文件时，直接给出路径，它会只加载这个文件的内容。这在调试单个函数时很高效，因为上下文里没有噪音，助手的判断会更准。
目录级读取适合需要理解模块结构的场景。比如你想让助手分析整个services目录的依赖关系，就指定这个目录，它会递归读取并建立结构认知。但要注意，目录太大时上下文消耗很快，我一般会配合排除规则，把测试文件、生成文件、依赖目录排除掉。
排除规则的写法各工具不同，但逻辑一致：用通配符或显式列表告诉助手"这些不要看"。常见的排除对象包括node_modules、dist、build、*.min.js、*.lock等。这个操作看起来简单，但能显著提升助手对核心代码的理解质量——因为它不会被压缩后的第三方代码干扰。
写入和修改类指令需要更谨慎。我习惯先用"只读模式"让助手给出修改方案，确认无误后再让它实际写入。直接让助手改文件的风险在于，它可能改了你没预期的地方。分两步走虽然多一轮交互，但回滚成本低得多。
3.2 代码搜索与定位类指令：比grep更懂语义的查找方式
传统的代码搜索靠正则和关键词，命令行AI助手的搜索能力在此基础上多了语义理解这一层。这意味着你可以用自然语言描述你要找的东西，而不必精确记得变量名或函数名。
比如你想找"处理用户登录超时的逻辑"，直接这样描述，助手会在代码库里定位相关函数，即使这些函数的名字里没有"timeout"或"login"这样的关键词。这个能力在接手陌生代码库时特别有价值——你不需要先花半天时间建立符号索引，直接问就行。
跨文件引用查找是另一个高频操作。当你修改一个接口签名时，需要知道哪些地方调用了它。传统做法是用IDE的"查找引用"，命令行助手的优势在于它能同时给出调用上下文和修改建议，而不只是列出位置。
历史变更追溯也值得单独提。你可以让助手查看某个文件的git历史，然后解释"这个函数为什么在三个月前被改成现在这样"。它会结合commit message和diff内容给出推断。这个功能在排查回归bug时很好用，能快速定位到引入问题的变更。
实操心得：搜索类指令的效果高度依赖你描述的精确度。"找一下登录相关的代码"和"找一下用户登录时校验token有效期的函数，它应该在auth模块里"得到的结果质量差距很大。多花十秒把需求说清楚，能省后面几分钟的筛选时间。
3.3 代码修改与重构类指令：如何让助手改得准、改得少
让AI改代码最大的风险不是改错，而是改多了。你只想改一个函数的返回值类型，它顺手把整个文件的命名风格也统一了，导致diff里混入大量无关变更，review起来很痛苦。
控制修改范围的核心是显式约束。在指令里明确说"只修改这个函数""不要动其他文件""保持现有代码风格不变"，能大幅降低意外变更的概率。我通常会把约束写成清单形式，比如：
- 只改
calculateTotal函数 - 不改函数签名
- 不引入新的依赖
- 保持现有的错误处理方式
分步重构比一次性大改更可控。比如要把一个类拆成两个，我会让助手先做第一步：提取出新的类，但保持原类不变，只是内部委托。确认这步没问题后，再做第二步：把调用方切换到新类。每步都有独立的diff可以review，出问题也容易定位。
重构前的快照是另一个保险措施。在让助手做大规模修改前，我会先创建一个git分支或者stash，这样即使改崩了也能一键恢复。这个习惯的成本几乎为零，但救场的价值极高。
3.4 测试与验证类指令：让助手自己证明改对了
让助手改完代码后直接说"改好了"是不够的。你需要让它自己验证。最常见的做法是让它运行相关测试，然后根据测试结果判断修改是否成功。
定向测试比全量测试更高效。如果你改的是用户模块，就让助手只跑用户模块的测试，而不是整个测试套件。这样反馈快，而且失败信息更聚焦。
测试失败后的自动修复是一个进阶用法。当测试失败时，助手可以读取失败信息，定位问题，然后尝试修复。这个循环可以自动进行多轮，直到测试通过或者达到重试上限。我在处理边界条件较多的逻辑时经常用这个方式，比手动一轮轮调试快很多。
静态检查是测试之外的补充。让助手在修改后运行lint或类型检查，能捕获一些测试覆盖不到的格式和类型问题。特别是TypeScript项目，类型检查能在编译前就发现大部分接口不匹配的问题。
注意：自动修复循环要设上限。我一般设3到5轮，超过就停下来人工介入。无限循环不仅浪费时间，还可能让助手在错误的方向上越走越远。
4. 快捷键与交互效率：减少手部移动的实战配置
4.1 打断、确认与回滚的快捷键组合
命令行AI助手在生成内容时，最常用的操作是打断。当它开始往错误方向生成时，快速打断能避免浪费时间和上下文。大多数工具用Ctrl+C或Esc来中断当前生成，具体取决于实现。我的习惯是手指常驻在Esc附近，一旦发现生成内容偏离预期就立即打断。
确认操作的快捷键通常用于接受助手的修改建议。有些工具用Enter确认，有些用Tab或y。这个操作频率极高，值得花几分钟熟悉自己工具的键位，形成肌肉记忆。
回滚是打断的补充。如果助手已经改错了文件，你需要快速撤销。命令行环境下，Ctrl+Z不一定有效（取决于工具是否接管了终端），更可靠的方式是用git命令回滚，或者用工具内置的undo指令。我一般会在让助手做批量修改前先commit，这样回滚就是一条git checkout的事。
4.2 多行输入、历史调用与自动补全的用法
多行输入在写复杂指令时很有用。命令行默认是单行回车执行，但你可以用特定快捷键（常见的是Ctrl+J或Shift+Enter）插入换行而不执行。这样就能把一段包含多个约束的指令一次性写完再提交，避免分多次说导致信息碎片化。
历史调用是提升重复操作效率的关键。大多数命令行环境支持用上下箭头翻阅历史指令，但AI助手的历史往往更长、更复杂。有些工具提供了搜索历史的功能，可以按关键词过滤。我经常用这个来复用之前写好的复杂指令模板，只改几个参数就行。
自动补全在文件路径和命令名上特别有用。当你输入文件路径时，按Tab能补全，减少拼写错误。有些工具还支持对指令关键词的补全，比如输入/re就提示/refactor、/review等。这个功能能显著降低记忆负担。
4.3 终端复用与分屏：把助手嵌进现有工作流
命令行AI助手最大的优势是它能和你的现有终端工作流无缝结合。我常用的布局是分屏：左边是编辑器和git状态，右边是AI助手会话。这样改完代码能立即看到diff，助手需要确认时也能快速切换。
终端复用工具（如tmux或screen）能让助手会话在后台保持，即使你关闭了终端窗口。这在跑长任务时很有用——你启动一个重构任务，然后切去做别的事，过一会儿回来查看进度。不过要注意，后台会话的上下文管理需要更谨慎，因为你看不到实时输出，出问题时发现得晚。
管道组合是另一个提效点。你可以把git diff的输出直接管道给助手，让它review变更；或者把测试输出管道给它，让它分析失败原因。这种组合方式把AI助手变成了终端工具链里的一个环节，而不是一个独立的聊天窗口。
5. 高效工作流的组合模式与场景化实践
5.1 探索型任务：从陌生代码库到可操作认知
接手一个陌生代码库时，最高效的方式不是从头读文件，而是让助手带你走一遍。我的标准流程是这样的：
第一步，让助手读取项目根目录的README和配置文件（package.json、pyproject.toml等），给出项目的技术栈、入口文件和主要模块的概览。这一步的目的是建立地图，不需要细节。
第二步，指定一个核心模块，让助手解释它的职责、依赖关系和对外接口。这一步开始深入，但仍然停留在结构层面。
第三步，挑一个具体的功能点，让助手追踪它的完整调用链，从入口到数据存储。这一步会涉及具体代码，但范围可控。
第四步，基于前三步的认知，提出一个具体的修改需求，让助手给出方案。这时候你已经有了足够的背景来判断方案是否合理。
这个流程走下来大概十几分钟，比盲目读代码快得多，而且认知是结构化的，不容易遗漏关键模块。
5.2 修改型任务：小步提交与增量验证的节奏控制
修改型任务的核心原则是小步走、勤验证。我见过太多人让助手一次性改十几个文件，然后面对一个巨大的diff不知道从哪看起。
我的节奏是这样的：每次只让助手改一个逻辑单元（一个函数、一个类、一个模块），改完立即跑相关测试，通过后再进行下一个。这样每个diff都很小，review成本低，出问题也容易定位。
增量验证的关键是测试要跟得上。如果项目测试覆盖好，直接跑测试就行；如果测试覆盖差，我会让助手在修改后写一个针对性的验证脚本，确认行为符合预期。这个脚本不一定要进代码库，但要有，用来证明修改是对的。
提交粒度也值得注意。我习惯每个逻辑单元改完就commit一次，commit message写清楚改了什么、为什么改。这样即使后面发现方向错了，也能精确回滚到某个点，而不是全部推倒重来。
5.3 调试型任务：让助手参与排查而非只给答案
调试时，很多人习惯直接问助手"这个报错怎么解决"。这样得到的是通用答案，不一定贴合你的具体情况。更好的方式是让助手参与排查过程。
我会先把报错信息、相关代码和复现步骤给助手，然后让它提出排查假设，而不是直接给解决方案。比如"根据这个报错，可能的原因有哪些？按可能性排序"。然后我逐个验证这些假设，把结果反馈给助手，让它缩小范围。
这个过程的优势在于：即使最后没找到根因，你也对系统有了更深的理解。而且助手在排查过程中会读取更多相关代码，它的判断会越来越准。直接要答案看起来快，但往往治标不治本。
二分定位是一个特别适合和助手配合的调试技巧。当你不确定问题出在哪个环节时，让助手在关键路径上插入日志或断言，然后逐步缩小范围。助手能快速生成这些临时代码，你负责运行和反馈，配合起来效率很高。
5.4 收尾型任务：清理、文档与提交信息的自动化
任务做完后的收尾工作往往被忽视，但它直接影响代码库的长期健康。我习惯让助手在收尾阶段做三件事：
清理临时产物。调试过程中产生的日志、注释掉的代码、临时的测试文件，让助手识别并清理掉。这个操作要谨慎，最好让助手先列出要删除的内容，确认后再执行。
补充文档。如果修改涉及对外接口或配置变更，让助手更新相关的README或注释。文档不需要长篇大论，但关键变更点要记录清楚。
生成提交信息。让助手根据本次变更的diff生成commit message，通常比手写的更完整。我会在这个基础上调整，确保信息准确且符合团队规范。
这三件事加起来大概几分钟，但能避免很多"改完就忘"导致的问题。特别是提交信息，好的commit message在几个月后排查问题时价值极高。
6. 常见误用与避坑经验
6.1 指令过于笼统导致的返工
最常见的误用是指令太笼统。"帮我优化一下这个函数"——优化什么？性能、可读性、还是错误处理？助手只能猜，猜错了就得返工。
我的做法是把笼统需求拆成具体约束。不说"优化"，而说"把这个函数的时间复杂度从O(n²)降到O(n)"；不说"改好看点"，而说"把这个函数的嵌套if改成早返回风格"。约束越具体，一次做对的概率越高。
还有一个相关问题是一次提太多需求。"帮我重构这个模块，加上错误处理，补充测试，顺便更新文档"——这种指令助手往往只能做好其中一两项。拆成多次交互，每次聚焦一个目标，整体效率反而更高。
6.2 上下文污染与信息过载的处理
上下文污染是指无关信息占据了窗口，导致助手对核心任务的注意力下降。常见的污染源包括：早期探索阶段的试错对话、被排除但又没完全排除的文件内容、重复的报错信息。
处理方式是定期清理。我一般每完成一个子任务就清理一次，把已解决的讨论移除，只保留当前任务相关的上下文。如果工具支持标记重要信息，把关键约束标记出来，清理时就不会误删。
信息过载是另一个极端——给助手太多文件，它反而抓不住重点。我的经验是：单次任务涉及的文件不超过十个，超过就拆成多个子任务。文件越多，助手越容易在细节上迷失，给出的方案也越泛。
6.3 过度依赖自动修改的风险控制
自动修改很爽，但风险也实在。我踩过的坑包括：助手把测试文件里的mock数据也改了、把配置文件里的环境变量名改了、把注释里的示例代码改了。这些改动单独看都"合理"，但合在一起就是灾难。
控制风险的核心是修改前审查、修改后验证。修改前让助手列出计划改动的文件清单和每个文件的改动摘要，确认范围无误；修改后跑测试和lint，确认没有引入回归。这两步看起来繁琐，但比事后回滚省时间。
还有一个技巧是限制助手的写入权限。有些工具支持只读模式或者需要确认才写入的模式，在处理不熟悉的代码库时，我会先开只读模式，确认助手的理解正确后再放开写入。
6.4 会话过长导致的性能与准确率下降
会话不是越长越好。超过一定长度后，助手的响应会变慢，而且因为上下文里积累了太多历史信息，它的判断反而会变得保守或混乱。我的经验是：单个会话不超过两小时，或者不超过完成三个子任务。
超过这个限度就开新会话，把必要的上下文（项目结构、关键约束、当前进度）用一段话总结后带入新会话。这个总结花不了一分钟，但能让新会话的起点很干净，效率比硬撑着用旧会话高得多。
如果任务确实需要长会话，就用前面提到的压缩功能，定期把历史对话浓缩。压缩后助手可能会丢失一些细节记忆，所以关键约束要重新强调一遍。
7. 把速查手册变成肌肉记忆的练习方法
整理这份手册的过程中，我最大的体会是：指令的价值不在于知道，而在于形成条件反射。知道有"压缩上下文"这个功能，和每次上下文快满时下意识地去压缩，是两回事。
我的练习方法是场景绑定。把每个指令和一个具体场景挂钩，比如"看到上下文占用超过70%就压缩""开始批量修改前先commit""测试失败先让助手分析而不是自己猜"。这样在场景出现时，对应的操作会自动触发，不需要临时想。
另一个方法是每周复盘。回顾这一周用助手的会话，找出哪些操作是重复的、哪些是低效的，然后把它们固化成指令模板或者快捷键。这个习惯坚持一个月，操作效率会有明显提升。
最后说一个反直觉的点：不要追求把所有功能都用上。命令行AI助手的指令很多，但真正高频的就是那十几个。把这十几个练到不用想就能敲出来，比记住所有冷门指令有用得多。剩下的功能，需要的时候查一下就行，没必要提前背。
我在实际使用中慢慢发现，效率的提升往往不来自学会了新指令，而来自把已知指令用得更准、更稳。少返工一次，省下的时间比多学十个技巧还多。
 与 browser.ajax 双方案详解)
