刚换工作那阵子，我接手一个老项目，组里几个新人每天光写接口文档就耗掉半天。那种感觉就像带了一把好剑却不会招式，天天在砍空气。后来我用AI Coding工具把整个流程重新捋了一遍，从代码补全到测试生成，从老系统重构到架构梳理，效率提升是实打实的。这篇文章想把我在一线折腾出来的经验完整记录下来，讲清楚AI编程这条路上，哪些工具值得信任、哪些环节必须人来兜底，以及七种真正改变干活方式的“武器”到底怎么用。
很多人以为AI Coding就是拿个大模型对话框让它“写个登录功能”，然后复制粘贴。这是误解。真正落地的AI编程，是一个由七种能力构成的完整工作流：补全、对话、审查、调试、测试、重构、架构。七种武器，各管一段，合起来才是一套可复用、可控的编程方法论。
1. 先搞清楚AI Coding这件事的边界
把AI Coding工具当成一个刚入职、学习能力极强但缺乏常识的新同事，许多判断就好做了。它能帮你写常见代码、查资料、处理重复劳动，但你不能把整个系统的安全、稳定、技术方向全部甩给它。它不能代替你对业务的理解，也不能替你回答“这个功能到底该不该做”。
我在实际使用中总结了三句话，基本可以避免绝大多数“AI翻车”事故：
- AI生成代码是对现有模式的概率复现，不是逻辑推导。它的目标是“看起来对”，不是“真的对”。
- AI在局部问题上非常可靠，在跨模块、长上下文、复杂状态流转的问题上，可靠性断崖式下降。
- 越具体、越有约束的任务，AI完成度越高。越开放、越依赖业务判断的任务，它越容易一本正经地胡说八道。
理解这三点，再看下面七种武器，就不会盲目崇拜，也不会因噎废食。
2. 七种武器全景：从自动补全到架构守门员
先说总览。这个框架不是我凭空想出来的，是我在几个不同类型的项目——一个纯前端可视化大屏、一个Java微服务集群、一个Python数据处理工具库——里反复调整后沉淀下来的。
| 编号 | 武器 | 定位 | 核心价值 | 我的主要使用场景 |
|---|---|---|---|---|
| 一 | 代码补全 | 贴身侍卫 | 减少打字量，保持状态流 | IDE内日常写码、写测试样板 |
| 二 | 对话生成 | 军师参谋 | 方案讨论、任务拆解、模板生成 | 新模块设计、算法选型、代码解释 |
| 三 | 代码审查 | 御史台 | 静态扫描、风格纠偏、安全隐患初筛 | PR/MR阶段、提交前自检 |
| 四 | 调试助手 | 侦探 | 缩小故障范围、生成探针、解释堆栈 | 线上问题排查、疑难Bug复现 |
| 五 | 测试生成 | 工匠 | 单元用例、边界条件、回归基线 | 存量代码补测试、新功能TDD辅助 |
| 六 | 重构辅助 | 清道夫 | 重命名、拆分、清理冗余、模式提取 | 技术债清理、代码结构整理 |
| 七 | 架构梳理 | 老参谋 | 生成文档、梳理依赖、识别坏味道 | 新人入职说明、系统重构前摸底 |
这七种武器不是独立存在的。补全是对抗“手速瓶颈”的，对话解决“从哪下手”的困惑，审查拦住“看起来能跑但迟早出事”的烂代码，调试缩短“瞎猜问题”的时间，测试兜住“改坏了没人发现”的风险，重构把混乱重新理顺，架构工具则让团队对系统本身形成统一共识。每一环缺了，其他环节的压力就会变大。
3. 武器一：代码补全——最贴身、最容易被低估
3.1 它到底在做什么
第一次用代码补全功能的人，通常只感受到“快”。打个for循环，敲两三个字母，整行就出来了。但用久了会发现，真正省时间的不是那些模板代码，而是上下文延续。比如你在定义一个类，敲完成员变量，补全工具会预测出getter/setter模式、构造器参数顺序，甚至根据你上一个函数的风格，继续用同样的命名风格填充下一个相似方法。
这一点看着不起眼，实际影响巨大。写代码最打断心流的，不是思路卡壳，而是反复在“想下一步”和“打字”之间切换。补全工具把打字时间压缩到极低，大脑只需专注于逻辑本身。
3.2 不同项目的正确姿势
补全工具的表现和项目类型强相关。我一个实际体会是：
- 在Java/Python这类生态成熟、常见代码模式多的项目里，补全准确率极高。尤其在Spring Boot的service/repository层，基本是“你起个头，它帮你写完”。
- 在偏门语言、老旧框架、自定义注解多的项目里，补全准确率会下降。这时候不能硬靠它，要给它喂示例。我的做法是：先在文件里写一个完整的模板方法，让工具“看到”这个项目的风格，后面的预测会显著改善。
- 前端项目里，CSS类名、状态变量名这种短词补全用得最勤，但补全工具对“视觉结果是否正确”是无知的。写样式时我基本只信自己肉眼验证。
3.3 一些容易忽略的坑
补全工具有个隐性问题：它会把“常见但不恰当”的代码带进你的项目。比如某个API已经废弃，但历史上大量代码是这么用的，补全模型训练时就记住了这个模式，于是一遍遍给你生成旧的调用方式。
我的应对办法是：每季度做一次“补全建议轨迹审视”。拿一周的代码提交记录抽查，看看哪些是补全推荐的、哪些被我接受、哪些被我改了。如果发现某种错误模式反复被补全，就说明项目的代码风格指南没被模型充分学进去，需要补充规范注释，或者调整工具配置。
提示：别忽视“补全但你完全看不懂”的代码。一旦出现这种情况，务必逐行搞懂再接受。补全工具的最佳状态是“帮你省时间”，不是“替你做判断”。
4. 武器二：对话生成——从“写代码”到“讨论代码”
4.1 为什么它是军师而非写手
把对话AI当成写代码的终极工具，是很多人失望的根源。你让它“写一个秒杀系统”，它给你吐一个玩具Demo；你让它“写一个订单模块”，它给你一个CRUD壳子。这能跑吗？能。能用吗？一般不能。
但如果你换一种用法，把它当成可以随时闲聊的技术顾问，价值立刻翻倍。我最常用的方式是在设计阶段：
我：我要为现有的用户积分系统增加一个“积分过期”机制。当前积分表有user_id、total_points、expire_at三个字段，现有代码里有一个定时任务每天跑一次，用的是xxl-job。我想在不影响现有接口的情况下处理过期逻辑。你有没有建议？这个提问方式和“帮我写积分过期功能”完全不同。前者给了上下文，让AI可以围绕现有设计出主意，比如建议用状态字段还是删除记录、扫描索引怎么建、和历史消费记录怎么联动。后者只能给你一段泛泛的代码。
4.2 一套好用的“军师提问模板”
我给自己定了一个对话模板，基本能保证每次都能得到高质量回复：
- 背景：项目是什么语言、什么框架、当前模块在解决什么问题。
- 约束：不能用什么（比如不能改数据库表结构）、必须遵守什么（比如走统一返回体）。
- 现有材料：贴出关键代码、报错信息、配置内容。
- 模糊点：明确告诉它，哪些是我自己都没想好的点，哪些是希望它帮我判断的。
例如：
背景：一个Python数据处理项目，用pandas处理每日流水，输出汇总表。 约束：不能引入额外存储，内存控制在8G以内，结果要兼容旧接口。 现有材料：以下是现有函数的伪代码，核心瓶颈在merge部分。 模糊点：我不确定是改用chunk处理还是优化merge条件，想听你的分析。这样提问，AI给出的往往不是一段代码，而是一整套考虑方案，包括原因、代码示例、潜在风险。这个过程本质上是在逼我们把问题想清楚，AI就像一个思维体操陪练。
4.3 对话AI最容易踩的雷
- 回答来源幻觉：它会编造“官方文档说了”，并给你一个根本不存在的函数签名。应对办法只有一个：凡是遇到不熟悉的API，回到官方文档确认。
- 上下文漂移：对话超过很多轮之后，早期说过的约束会被遗忘。我的做法是每过几轮就“复述一次关键约束”，让它重新关注重点。
- 在代码解释上，它极容易“将错就错”。你贴了一段有Bug的代码问它“这是干什么的”，它会忽略Bug，顺着代码思路解释。要主动加一句“请顺带指出哪些地方可能有问题”，它才会切换成挑刺模式。
5. 武器三：代码审查——把御史台请进CI流水线
5.1 AI审查不是“银弹”，但能拦住80%的低级问题
每年都有人在社区吐槽“AI审查报告噪音太多，没用”。但我实际用下来，把AI审查安插在合适的位置，回报率非常高。我自己的经验是把它分成两档：
- 提交前自检（本地）：在commit之前，把带改动的diff丢给AI，让它找问题。重点是低级错误、遗漏的分支、明显坏味道。
- MR管线审查（服务端）：每次Merge Request自动触发，审查整个diff并输出报告。我通常再搭配一条prompt，要求它“只报确定性高的问题，不要建议你也不确定是否通用的方案”。
这样做之后，能从MR阶段拦掉很多“低级但致命”的坑。举个实际例子，有次同事改一个配置项，改完忘记同步另一个环境的配置，AI审查在diff里发现了两处配置变更数量不一致，提示“生产环境和预发布环境配置不对称”，避免了一次线上返工。这种检查靠人来盯很容易漏，规则写的严格又容易误报，AI反而最适合。
5.2 如何设计“AI审查指令”
直接把整个项目丢给AI让它“全面审查”，是低效的。经验是给AI限定具体的审查角度，例如：
你现在是高级代码审查员。请针对以下满足特定要求的代码，给出审查意见： - 安全：是否存在注入、硬编码密钥、危险的反序列化方式 - 并发：是否存在共享状态修改、线程安全问题 - 健壮性：是否存在可能的空指针/数组越界 - 简洁性：是否存在重复代码、过度设计 请注意：只报告你确定的问题，对于只是风格偏好或不确定的建议，不要列出来。这个指令比“帮我看看代码哪里不对”强很多。还有一个细节：把“分层审查”作为习惯。第一次先审查整体结构，第二次聚焦某个文件，第三次聚焦某个具体函数。大而全的审查很容易变成“每个点都提一句，但每个点都不痛不痒”。
5.3 审查结果怎么验收
AI审查会输出一批问题，但接不接受，必须人来定。我的原则是：
- 接受：问题描述具体、有明确代码行号、修复建议可直接落地。
- 存疑：问题描述抽象、推荐方案和项目现状不匹配。
- 拒绝：没有解释、只丢给你一段重写代码。
有一次AI审查对一段异步任务处理代码给出“建议改用消息队列”，理由是该场景可能出现任务堆积。但我们团队在这个项目里就是刻意不用消息队列的，因为部署环境不支持。这种建议就是没有结合业务实际的“通用答案”，不能采纳。
提示：AI审查报告不要直接发给开发者当“罪行清单”。我通常让AI输出一份Markdown格式的建议，我整理后去掉误报，再转给同事参考。这样既保留了一个互相监督的氛围，也不会因为AI产生人际摩擦。
6. 武器四：调试助手——从“猜Bug”到“最小化实验”
6.1 调试的核心瓶颈是信息不足
人调试Bug，最大的痛苦不是不会修，而是不知道问题到底出在哪一段。传统排查方式需要打日志、加断点、构造复现条件，全部依赖经验去猜。AI调试工具的真正价值，是帮你快速扩大信息量。
遇到一个难复现的线上问题，我的流程是：
- 把完整调用链（入口参数、中间处理、异常堆栈）贴给AI，让它用文字描述整个数据流。
- 请AI列出“哪些环节最容易出错”，让它按照可能性排序。
- 对最可疑的位置，让AI生成一个“临时探针代码”——专门用来打印中间状态的日志代码。
换句话说，AI帮我把原来写日志的功夫提前了，并且经常能指出我思维盲区里的嫌疑点。
6.2 有效描述Bug的三步法
向AI描述Bug时，最忌讳只说“程序崩溃了”。我用的方法是：
- 给现象：在什么输入下、什么动作触发、什么报错。
- 给预期：我期待它行为是什么样。
- 给怀疑：我目前最怀疑哪个文件哪个函数。
举例：
我的服务在接收一个包含大量嵌套JSON的请求时，偶尔返回500。 预期是所有合法JSON都能解析成功并返回200。 目前怀疑是反序列化时对null字段处理有问题。相关代码在service/parse.py第120行附近。 请帮我分析可能的边界条件，并且给出可以验证的日志位点。这样AI就可以直接干活，而不是先跟你猜来猜去。
6.3 调试中要守住的一条底线
AI调试最可怕的一点，是“看起来每一步都对了但方向全错”。它有时的解释听上去很有逻辑，但拿实际数据一验证，完全是另一个故事。所以我给自己定了一条规矩：AI给的分析让我产生一个具体假设时，我一定要想办法用日志、断点或数据去验证这个假设，再决定是否按它的方向排查。不验证的AI建议，通通当参考意见，不当诊断结论。
7. 武器五：测试生成——把AI变成测试工匠
7.1 为什么测试是AI最容易出成果的领域
我自己给AI写了两年测试代码以后，最大的感受是：测试代码是整个软件工程里，AI最擅长的区域之一。因为测试代码的模式非常固定——准备输入，调用目标函数，断言输出。而目标函数的行为往往能从代码本身读到，少有模棱两可的业务逻辑。
我在一个Python工具库项目中，让AI把几百个函数的单元测试全部补齐了，覆盖率达到86%。核心做法就是：
请为以下函数生成单元测试用例。要求： - 使用pytest风格，使用fixture提供数据 - 覆盖正常输入、边界值（空列表、None、极大极小值）、异常输入 - 不mock被测函数本身，但可以mock外部依赖 - 测试命名遵循test_<函数名>_<场景>然后我把目标函数粘贴给它。生成之后，人工检查一遍测试断言是否正确，再跑一遍看是否是绿的。这个过程中，AI还能反问：这个函数在参数为None时有没有定义行为？如果没有，这恰恰暴露了代码的隐性假设。
7.2 别只盯着覆盖率数字
覆盖率是一个参考指标，不是护身符。我用AI生成测试之后发现一个问题：它会倾向于生成很多“执行到了但没验证结果”的测试，代码覆盖率好看，但断言很弱，等于白测。
现在我要求AI生成测试时，必须有“三个有效断言”：
- 正常场景断言：返回值是否符合预期。
- 异常场景断言：抛没抛异常、异常类型是否正确。
- 副作用断言：如果函数改了状态或调用了外部服务，这些行为是否发生。
没有这三种断言的AI测试，我会要求它重做。本质上，AI生成测试的价值是提高测试的“信息量”，不是制造一堆自嗨的绿色勾。
7.3 给老系统补测试的顺序
老系统代码耦合重、依赖多，AI补测试容易陷入“依赖地狱”。我的补测顺序是：
先挑纯函数和无副作用模块补。这类代码不依赖数据库、不依赖网络，AI生成和验证都很快。再补工具类、静态方法。最后才补带依赖的Service层，并且用依赖注入或Mock隔离。
先易后难的好处是，做前面那些模块时，AI会逐渐熟悉项目的代码风格和测试习惯，后面它生成的质量会更高。这一点和我与人协作时的经验有些相似，先做小任务磨合，再上大任务。
8. 武器六：重构辅助——处理技术债的清道夫
8.1 AI重新设计“旧代码”：不是重写，是演进
很多人对AI重构抱有幻想：丢一个老模块进去，让它翻译成新框架、新语言，直接搞定。我试过这样的方案，结果在依赖关系、隐藏逻辑、外部集成三处连续翻车，后来再也不敢做“大爆炸式重写”。
我现在的重构哲学是“小步重构，AI辅助每一步”。AI在重构里最擅长的既不是翻译也不是重写，而是下面这几种小而清晰的操作：
- 重命名：把含义不清的变量、函数改成有业务意义的命名，且保持所有引用同步修改。
- 函数拆分：把一个几百行的“上帝函数”拆成几个小函数，AI可以提出拆分方案并生成骨架。
- 重复代码提取：在项目里找出结构相同的代码块，生成抽取公共方法后的diff。
- 注释清理：删除那些“什么也没说”的废话注释，同时保留有用的业务背景说明。
拿“函数拆分”举例。有一个处理订单状态的函数有三百行，逻辑绕来绕去。我直接把整个函数贴给AI，附上指令：
这是一个包含订单状态流转的函数。请识别其中可以独立成函数的部分，给出拆分建议。 要求：不改变外部行为，只拆结构。每个新函数都要有明确的职责描述和参数说明。AI会给出一个结构映射：哪些代码属于“计算折扣”可以整体拎出去，哪些代码属于“记录日志”可以抽象成方法调用，哪些属于核心状态流转逻辑需要保留在主函数中。我拿到方案后，会先review一遍再动手改，改完跑全部存量测试。每次改动控制在可以快速回滚的粒度。这样就算某一轮AI方案有偏差，也能及时发现和回退。
8.2 重构不是“AI说了算”
最需要提醒的一点是：AI对“商业逻辑不可改变”的理解很弱。它可能在重构中悄悄改变一个边界条件的判断顺序，导致行为变化。因此我给自己定了一条硬规矩：所有AI重构建议，绝不直接应用，必须先diff review，并且必须通过测试套件验证。
另外，AI重构不能替你判断哪些代码“值得重构”。有些代码虽然丑，但是稳定、测试覆盖高、改动频率极低，重构它带来的风险远大于收益。这个决策必须由人来判断。AI能当清道夫，不能当项目经理。
9. 武器七：架构梳理——让老参谋写“系统说明书”
9.1 为什么团队比AI更需要架构文档
我待过的几个团队，都有同一个现象：系统越来越复杂之后，真正能把整体架构说清楚的人越来越少。新人入职靠问、靠猜、靠读代码，效率极低。这时AI架构梳理工具就能派上用场，它可以快速从代码仓库里提取模块划分、依赖关系、关键调用路径，并生成结构文档。
我常用它来做四类架构文档：
- 系统模块总览图（文字版）：每个模块职责、边界、对外提供的接口。
- 依赖关系说明书：哪些模块依赖哪些模块，哪些是循环依赖或反向依赖。
- 核心链路时序：一次用户请求从入口到落库经过哪些关键类和函数。
- 技术债务清单：识别代码中重复模式、超大函数、循环依赖、缺少接口封装的地方。
这类文档的价值不在于“好看”，而在于团队有了统一共识。我们组有个新来的同学，就是用AI生成的系统模块总览图，加上代码仓库里几个关键入口文件，一周内就基本搞清了整体流程。
9.2 怎么让AI输出可用的架构文档
我不直接把整个仓库丢给AI让它“写架构文档”，那样输出基本是空话。我会做一次“信息引导”：
- 让AI扫描项目结构，列出主要目录和顶层模块。
- 挑出每个模块下一个代表性的入口文件（如Controller、Service、Main函数），贴给AI。
- 给出业务场景描述：“我们的系统是一个订单处理平台，包含用户端、商家端、后台管理，核心链路是商品查询到订单创建再到库存扣减。”
- 让AI结合入口代码和业务描述，生成模块清单和职责说明。
这样生成出来的架构文档，既有代码层面的实际依据，又有业务层面的场景坐标，不是泛泛的“模块化设计”废话。
9.3 警惕“顺滑的谎言”
架构梳理的过程中，AI会把一些推测信息写得非常肯定。比如它可能说“资金模块通过消息队列与订单模块解耦”，但代码里根本没有消息队列，只是有一个定时任务。它看到的可能只是一些变量名，然后联想出这个结论。
因此，我为AI生成的架构文档增加了一道确认流程：每条关键结论必须附上“证据”字段，标注出它是从哪个文件哪一行推导出来的。没有证据支撑的结论，保留为“待人工确认”。同时，让一个熟悉系统的人通读一遍文档，找出明显失真的地方。AI能做初稿，但注释“哪些是真，哪些是猜”的工作，永远不能省。
10. 七种武器组合拳：一条完整的新功能开发流水线
单独讲七种武器，容易变成“工具说明书”。把组合方式讲清楚，才有操作价值。我以“为一个订单系统增加批量导出功能”为例，展示我怎么用这套流水线：
10.1 需求阶段（武器二：对话生成）
我先不写代码，而是把需求背景、现有订单表结构、导出的格式要求、权限控制、性能约束，全部贴给AI，让它给我一份任务拆解和实现方案。它会建议分三步走：先实现数据查询，再做文件写入，最后接权限和异步任务。
这个过程我获得最大的价值不是任务列表，而是它发现了几个我没想清楚的问题：比如导出的数据量上限、文件命名冲突、超时处理。这些是大需求里最容易遗漏的暗礁。
10.2 实现阶段（武器一：代码补全 + 武器二：对话生成）
在写代码时，我打开补全工具，让它辅助完成常规CRUD和文件写入逻辑。遇到不确定的接口或设计模式时，再切到对话窗口，用具体的代码上下文提问。
比如我需要为一个大数据量查询做分批处理，AI给了一个基于游标的分页思路，我再结合项目的既有工具类落地。这里可以说的是，AI的准确率取决于我对问题描述的清晰度。描述越贴近实际代码，它的输出越可复用。
10.3 提交前（武器三：代码审查）
写完代码，我先把diff丢给AI做一轮自检。它发现我漏了对Excel导出的超大行数做样式深拷贝的边界处理，还提醒文件流关闭要用try-with-resources。这些都是真实发生的问题，不是凑数的建议。
10.4 测试阶段（武器五：测试生成）
然后让AI生成导出功能的单元测试。它构建了包含特殊字符、空数据、超大数字的测试样例。有几个断言偏差是我人工修正的，但整体覆盖很扎实。接着把边界测试接入现有测试套件，跑完是绿的。
10.5 重构与架构固化（武器六 + 武器七）
功能上线后，我用重构辅助工具把导出逻辑从Controller里抽出来，独立成service，顺手清理掉几段重复的查询条件拼接代码。改成清爽的结构后，用AI更新一遍相关模块的接口文档，让新同事之后接手时不会一头雾水。整套动作下来，从需求到上线，实际耗时大约是过去的一半多一点。
11. 按项目类型选武器：不要全都要，要匹配
七种武器听起来很全，但真在一个小项目里全铺开，反而变成负担。我依据自己待过的几类团队，给一个粗线条的选型推荐。
| 项目类型 | 建议重点武器 | 理由 |
|---|---|---|
| 个人项目/原型 | 代码补全 + 对话生成 | 人少流程轻，最关键的是快速实现和方案讨论 |
| 小团队产品 | 补全 + 审查 + 对话 | 代码互相看，审查能防低级问题，对话做设计 |
| 中大型微服务 | 审查 + 测试 + 重构 + 架构 | 变更风险高，自动化验证和文档共识是刚需 |
| 遗留系统维护 | 调试 + 重构 + 架构 | 核心痛点是“搞不懂现有系统”和“不敢改” |
我在一个小型前端项目里几乎只用补全和对话，效率和体验都很好。但在一个交易类后端项目里，如果缺少AI审查和测试生成，我就睡不踏实。武器没有高低之分，只有是否合手的问题。
12. 使用AI Coding时的常见故障与应急手册
用AI Coding时间久了，总会遇到一些典型的“翻车现场”。我整理了最频繁的五种，按频率排序，每条都附上排查思路。
12.1 AI生成的代码与项目风格脱节
症状：生成代码能跑，但命名风格、错误处理方式、日志格式和项目里其他代码明显不像一个人的作品。
排查思路：这是上下文不足的典型表现。孤立地贴一段需求AI当然按“大众习惯”写。解决方式是提供项目里某个类似功能模块的完整代码，让AI模仿风格。我做过一个实验：在prompt里附上一段项目里已有的service层代码，AI生成的新代码风格立刻贴合了许多。
12.2 上下文太短，回答逐渐失忆
症状：对话刚开始时效果很好，聊了十分钟后它开始忽略早期约束，甚至给出与之前回答相矛盾的方案。
排查思路：对话模型都有上下文窗口限制。长对话里，旧信息会被裁剪或遗忘。我的处理方式是“分段式对话”：每完成一个小任务，就重开一个新对话，并把必要的前置结论浓缩成一段话粘贴进去。宁可在新对话里重新描述一次，也不要让一个对话无限拉长。
12.3 用AI越久，代码库越“膨胀”
症状：团队大量使用AI生成代码后，仓库里出现很多功能类似但写法各异的工具函数、模块，代码量变多但实际业务功能没等比增长。
排查思路：这是缺少统一抽象和审查约束的副作用。AI每次都在“生成一次性代码”，很少主动考虑复用。解决办法：把“是否存在已有实现”作为AI生成前的必答问题，并要求审查环节增加“重复代码检测”的提示词。同时划定边界：AI生成是新代码的起点，不是终点，合入前必须经过人工的重构审查。
12.4 AI把“猜测”包装成“事实”
症状：AI在解释某个第三方库或内部模块时说得头头是道，但文档或源码里根本没有这个能力。它只是在模拟“一个能回答这个问题的专家”该有的口吻。
排查思路：对一切不可验证的陈述保持怀疑，并且给AI加权限限制。凡是涉及具体API名、版本号、配置项的解释，我把它当作索引，之后必须去官方文档或源码二次核对。用过几次以后，能建立一个直觉，清楚地知道哪些内容“AI可以负责”，哪些内容“AI只是替你省去搜索的功夫”。
12.5 生成测试太多“无效断言”
症状：AI生成的测试跑起来全绿，但把某段实现改成明显错误后，测试依然全绿。这类测试没有起到保护行为的作用，反而让人产生虚假安全感。
排查思路：有效性比覆盖量更关键。抽查案例时，我每次拿到AI生成的测试，会手动破坏一两个被测试函数的实现，确认测试真的会红。如果断言太弱，就补强断言。这一招可以筛掉绝大多数“装饰性测试”。
13. 安全底线：哪些场景坚决不能让AI过度介入
AI Coding在提高效率的同时，也需要划定安全边界。我在使用中给自己立了四条底线：
- 加密逻辑、密钥管理、鉴权核心模块：AI可以帮助生成草稿，但最终实现必须由有经验的人逐行review，并且不允许直接使用AI从网上学习的“最佳实践”模式，除非有官方安全文档背书。这类代码一旦出问题，代价可能是全局性的。
- AI审查结果不能直接合入MR：无论AI给出什么建议，都要由人来确认是否修改、如何修改。AI没有业务责任，判断责任永远在人。
- 涉及用户敏感数据转换的代码，绝对不交给AI闭眼生成：即使AI生成的代码能跑通，也得人工确认脱敏、日志、保留期限等逻辑是否真实满足合规要求。
- 导出、批量操作、定时任务这类“影响面广”的代码，AI生成的版本必须额外增加“影响范围说明”和“回滚方案”，经评审后再上线。
这些底线与其说是AI能力的限制，不如说是我们团队对软件工程责任的坚持。AI是工具，可以为效率加分，但不能为决策背锅。
14. AI Coding的未来演进与个人判断
聊AI Coding，免不了被问到“这东西以后会变成什么样”。有人担心程序员失业，有人觉得AI会统治代码库。我自己的观察相对朴素：
在可见的未来，AI Coding工具会让“会写代码”的门槛进一步降低，但不会让“会写正确代码”的门槛降低。写业务代码、拼网页、搭CRUD，这些任务的单位成本会急速下降。但判断系统的稳定性、设计合理的数据模型、权衡技术选型、在业务和成本之间取舍，这些依然是高价值的人类工作。
一个明显趋势是：AI从“提示之后的被动执行者”转向“主动参与开发过程的协作者”。补全会自动识别风格偏好，审查会提前发现设计矛盾，测试会主动建议覆盖缺口。工具的发展方向是更深度地嵌入开发者的工作流，做“贴身管家”，而不是一个偶尔打开的问答窗口。
我最近观察到另一个变化：团队里新人在AI辅助下上手速度加快，但“代码理解深度”反而容易变得浅。他们可以快速拼出一个能跑的模块，但一旦系统报错或需要调优，就不知道从哪下手。这提醒我们，AI Coding时代的基本功，不再是语法和框架API的记忆，而是抽象能力、系统思维、以及“在不确定性中做判断”的能力。
所以我的态度是：积极拥抱AI Coding，但永远加强自己对系统的理解。工具越强大，使用者越要有扎实的地基。
15. 实操心法最后几条
最后分享几个我在实践中特别受用的细节，算是七种武器之外的“配件”：
第一，给AI设“人设”和“权限”。我会在每次重要对话开头告诉它“你是项目里的高级工程师，只负责方案分析，不负责最终决策”。这句话对回答质量的影响很奇妙——当它被限定为“参谋”角色时，输出会更克制，更少出现越界打包票的情况。
第二，保留一份自己的“AI经验库”。把好用的指令模板、踩坑记录、验证方法存到一个笔记里。这和代码重构的道理一样，不要每次从零开始和AI磨合，而是沉淀出一套可复用的“兵器谱”。有了这个库，换工具、换项目、带新人时，都能快速建立起一套相对成熟的协作方式。
第三，每隔一段时间让自己脱离AI，从零写一个功能。这不是矫情，而是保持“手感”。如果长期只review AI代码，自己对语法细节的敏感度会下降，随之而来的是“好像哪儿不对但说不出来”的模糊感。写一个功能，哪怕很简单，也能重新校准自己对代码的直觉。
AI Coding这条路，我还在持续探索中。眼下这七种武器不是终点，只是我现阶段比较顺手的一套打法。每接手一个新项目，我都会重新调配它们的比例，有的项目该用重剑就用重剑，有的项目一把匕首就够了。工具为项目服务，而不是反过来。
