ARTICLE · 1301709
如何使用 AI 编码助手,又不丧失工程能力?
AI 可以帮你修改代码、修复 Bug、优化性能，但测试通过不等于系统正确，任务完成也不等于你真正理解了问题。如何在提高编码效率的同时，保留自己的调试能力、技术判断力和工程经验？这篇文章从真实开发场景出发，给出一套可以直接使用的协作方法。
AGENT INFRASTRUCTURE LAB · 工程实践
如何使用 AI 编码助手，又不丧失工程能力？
AI 正在改变软件开发的方式。但当 AI 替你完成越来越多的工作，你是否仍然理解代码、判断方案，并能够独立定位问题？
我们正在成为更优秀的工程师，还是仅仅变得更擅长让 AI 替我们完成工作？
想象一下。
你让一个 AI 编码代理修复一个 Bug。它检查代码，修改了四个文件，补充了一个测试，然后告诉你：问题已修复，测试全部通过。
你看了一眼代码，感觉没有问题。测试也通过了，于是合并了代码。
几天后，一个新的 Bug 出现了。这一次，你发现自己并没有完全理解之前的修复方案，也不清楚为什么需要修改那四个文件。
原本节省的 30 分钟，最后可能变成两个小时的额外调试时间。
真正的风险，不是使用 AI，而是不理解就接受。
当 AI 替你完成任务时，你是否仍然理解问题、判断方案，并能够验证结果？目标不是拒绝 AI，而是在提高效率的同时，保留并持续提升自己的工程能力。
01 先调查问题，不要急着让 AI 修复
假设你正在开发一个 API，突然发现部分请求开始返回 500 错误。
你的第一反应可能是直接告诉 AI：「找到错误并修复它。」
AI 检查代码，发现一个可能为空的变量，添加了空值检查，然后告诉你问题已经解决。本地测试也正常了。
但这并不意味着它找到了真正的原因。实际问题可能是数据库连接超时、上游服务返回了异常数据，或者最近的一次部署改变了请求格式。
AI 可能只是修复了表面症状，而没有找到根因。
第一步：暂时禁止修改代码。
可以这样要求 AI：
调查这个 API 返回 500 错误的原因。暂时不要修改任何文件。请追踪相关请求流程，检查已有的日志和错误处理，列出最可能的三种原因，并分别说明支持这些判断的证据，以及下一步应该检查什么。
第二步：质疑它的判断。
如果 AI 认为问题出在数据库连接上，继续追问：
有哪些证据支持这个判断？是否存在其他原因也会产生相同的现象？如果这个假设成立，我们应该在日志或监控数据中看到什么？
AI 给出的解释可能很合理，但合理不等于正确。
第三步：用实际证据验证根因。
检查日志、重现错误、分析相关代码，或者运行必要的诊断查询。如果现有信息不足，就继续收集证据，而不是把推测当成结论。
对于生产环境故障、间歇性错误，以及涉及多个服务的问题，这种方法尤其重要。不要因为 AI 能快速生成补丁，就让它跳过调查过程。
02 不仅要问改了什么，还要问为什么
假设你正在优化一个返回用户最近订单的 API。接口可以正常工作，但响应速度很慢。你让 AI 优化性能，它决定引入 Redis 缓存。
响应速度确实提高了，但新的问题也随之出现：
—订单更新后，缓存中的旧数据什么时候失效？
—如果 Redis 不可用，接口还能正常工作吗？
—缓存是否真的必要，还是原本的数据库查询就存在效率问题？
AI 可能解决了性能问题，却同时引入了一致性风险和运维成本。
因此，不要只看最终结果，还要理解它为什么选择这条路径。
你可以要求 AI：「解释为什么选择当前方案，而不是其他方案。请比较可能的替代方案、各自的优缺点，以及在什么情况下应该选择不同的实现。」
在这个例子中，可以比较优化数据库查询、添加索引、减少不必要的 API 调用，以及引入缓存。
如果数据库查询本身效率低下，缓存可能只是掩盖了问题。如果数据频繁变化，缓存失效机制又可能引入额外的复杂性。
理解方案，比接受方案更重要。
你不必直接否定 AI 的建议，但需要知道为什么这个方案适合当前系统，以及它会带来什么代价。涉及新依赖、公共 API、数据库结构或并发处理时，尤其如此。
03 不要只听 AI 说测试通过，要看证据
AI 编码代理经常会给出这样一句话：「问题已修复，所有测试均通过。」
但这句话究竟说明了什么？它可能只运行了原有的单元测试。原有测试可能根本没有覆盖这个 Bug，也可能没有针对预期行为增加新的测试。
来看一个更重要的例子。
假设支付服务偶尔会在请求重试时，对同一笔订单重复扣款。AI 增加了一段判断逻辑，阻止重复处理，然后告诉你测试通过了。
你能直接发布吗？至少还需要回答几个问题：
—最初的故障能否被重现？
—有没有一个回归测试，能够在修复之前复现问题，并在修复之后通过？
—两个相同的请求同时到达时，会发生什么？
—支付已经成功，但客户端因为响应超时再次发起请求时，会发生什么？
—如果请求被分发到不同的应用实例，方案是否仍然有效？
仅仅使用进程内的标志，可能只能阻止单个实例中的重复处理。当请求到达不同实例时，这种方法可能失效。
可靠的支付幂等性设计通常需要结合幂等性密钥、持久化状态、数据库约束和并发控制等机制，具体方案取决于系统架构。
你可以要求 AI：「请确定原始故障模式，并增加能够重现该问题的回归测试。运行相关测试，说明这些测试验证了什么、没有验证什么，以及还有哪些重要场景尚未覆盖。」
测试通过，不等于系统一定正确。
测试只能为特定行为提供证据，而证据的价值取决于测试实际覆盖了什么。
04 实施之前，先让 AI 挑战你的设计
有时，提出解决方案的人不是 AI，而是你自己。
例如，你发现某个后台任务拖慢了 API，于是决定引入消息队列，把任务从请求处理流程中移出去。
你让 AI 实现这个方案。它很快就生成了队列配置、生产者、消费者、重试逻辑和相关辅助代码。
但一开始就需要消息队列吗？更简单的后台任务机制能否解决问题？是否需要保证消息处理顺序？如果消费者重复处理同一条消息，会发生什么？又该如何监控失败的任务？
AI 擅长执行你的要求，但这并不意味着你的要求就是最合适的解决方案。
在实施之前，可以先问它：
我正在考虑引入消息队列，将这项工作从请求处理流程中移出。暂时不要实施。请评估这个设计，比较更简单的替代方案，并分析可能的故障模式、运维成本，以及什么情况下才值得采用消息队列。
这种方法同样适用于系统设计、数据库迁移和性能优化。当你已经确信某个方案正确时，反而更容易忽略其他选择。
把 AI 当作帮助你思考和检验设计的伙伴，而不仅仅是执行任务的工具。
05 审查实际代码差异，不要只看摘要
假设你让 AI 为某个 API 增加分页功能。它修改了六个文件，最后给出一份摘要：「已添加基于页码和每页数量的分页支持。」
看起来很简单，但真正重要的问题可能藏在代码差异中。
—页码为负数时会发生什么？
—每页数量有没有上限？
—面对大型数据集，查询是否仍然高效？
—排序是否稳定、具有确定性？
—修改是否影响现有 API 客户端？
如果分页查询缺少稳定的排序条件，当数据发生变化时，就可能出现记录重复或遗漏。如果没有限制每页数量，客户端可能请求一个过大的结果集，导致数据库和服务承受不必要的压力。
因此，不要只看它声称自己完成了什么，还要检查实际实现。
你可以要求 AI：「请审查本次代码差异，检查正确性问题、边界情况、性能风险和向后兼容性。对于每个发现的问题，请指出相关代码，并解释可能产生的影响。」
然后，自己再核实这些判断。对于重要修改，还可以请另一位工程师独立审查。独立审查有助于发现遗漏，但也不能保证代码一定正确。
代码摘要告诉你 AI 声称做了什么；代码差异才让你有机会判断它实际上做得怎么样。
重要修改仍需结合相关测试、静态检查和实际运行结果进行验证。
06 让 AI 帮助你调试，而不是替你完成全部调试
调试不仅是完成任务的过程，也是理解代码库、系统行为和故障机制的过程。
如果 AI 每次都直接从错误信息跳到补丁，你可能解决了眼前的问题，却没有理解问题为什么发生。
假设某个后台任务在生产环境中偶尔失败，但在本地环境中始终正常。
先提出自己的假设。可能是任务依赖了本地环境才存在的文件，也可能是任务超时，或者多个任务正在竞争同一个资源。
你的假设不必一开始就正确。重要的是先形成一个可以检验的判断，然后让 AI 帮你挑战它：
我怀疑任务失败是因为超时。请结合代码和日志，分析有哪些证据支持这一判断，还可能有哪些其他原因，以及可以通过什么最小实验区分这些原因。
接下来，检查日志，对比成功与失败的运行记录，尝试重现问题，或者增加有针对性的监控信息。最后，根据证据更新自己的判断。
经验丰富的工程师通常就是这样调试的：提出假设、设计实验、排除可能性，再逐步缩小问题范围。
AI 可以帮助你发现尚未考虑的可能性，但最终应该由证据决定你接受哪种解释。不要让第一个看似合理的答案，直接成为最终诊断。
07 不要把你需要学习的部分也交给 AI
使用 AI 完成任务，与使用 AI 培养能力，是两件不同的事情。
假设你正在学习数据库索引。你让 AI 优化一个执行缓慢的查询。它添加了一个索引，查询速度随之提高。
任务完成了。但你是否理解索引为什么有效？如果换一个代码库，你还能否识别类似的问题？
你可以继续追问：
请解释这个查询为什么慢，以及为什么建议的索引能够提高性能。添加索引前后，查询执行计划可能有什么变化？在哪些情况下，这个索引可能帮助有限，或者反而增加写入成本？
然后，实际查看查询执行计划，对比修改前后的结果。你也可以把这种方法用于学习不熟悉的代码、并发问题、内存泄漏、网络故障或系统设计。
你不可能理解每项工作的所有实现细节。但当你正在培养某项技能时，不要让 AI 把最值得学习的部分也隐藏起来。
让它解释关键决策，尝试预测结果，再通过实验检验自己的判断。有时，也可以先独立分析问题的一部分，再请 AI 帮助你。目标不是拒绝帮助，而是确保自己在获得帮助之后，比之前更有能力。
08 根据风险决定你需要介入多深
如果每次使用 AI，你都反复追问为什么选择这个方案、还有哪些替代方案、失败了怎么办，那么你也可能花费大量时间讨论，而不是解决问题。
并不是每项任务都值得进行完整的架构评审。关键在于根据风险决定投入多少精力。
简单、可逆的修改
检查代码差异，运行相关测试。
一般业务功能
理解实现方案，验证主要边界情况。
系统设计、数据库迁移
比较替代方案，评估兼容性与故障风险。
支付、安全敏感代码、生产故障
深入调查根因，验证关键故障模式，必要时进行独立审查。
在发布重要修改之前，至少确认四件事：你理解关键设计决策；方案针对真实问题；相关测试提供了合理证据；主要风险和权衡已经得到考虑。
最后，你应该能够解释这次修改，并承担发布它的责任。目标不是获得绝对确定性，而是在合理的时间内，作出有充分依据的决定。
09 与 AI 协作时，记住这五个问题
对于下一次非简单的编码任务，可以按照以下流程工作：先明确问题，再让 AI 调查；在实施前质疑方案；分阶段修改；通过测试和代码审查验证结果；最后复盘关键决策。
如果只能记住五个问题，我会选择以下这些。
为什么？
有哪些证据能够解释问题的根因？
还有什么？
是否存在更简单、更合适的替代方案？
可能出现什么问题？
我们是否遗漏了重要的边界情况和故障模式？
我们如何知道方案有效？
哪些测试和实际证据支持这个结论？它们还有哪些局限？
我能解释这次修改吗？
我是否理解了关键决策，并能够承担发布这次修改的责任？
这五个问题不必在每次编码时机械地逐一提问。它们更像一份检查清单，提醒你在重要的决策节点保持主动判断。
最后
工程师不需要证明自己可以完全脱离 AI 工作。
拒绝使用 AI，并不会自动让你成为更优秀的工程师。但不加判断地接受 AI 生成的一切，也不会。
真正的优势，在于把 AI 的执行效率，与工程师理解系统、评估方案、调试故障和作出技术决策的能力结合起来。
让 AI 帮助你探索问题、挑战假设、处理重复性的工作。但对于重要的技术决策，请继续保持主动参与。
让 AI 提高你的编码效率，但不要让它替代你的工程判断力。
我们真正需要培养的，不是一个不需要 AI 的工程师，而是一个知道什么时候可以信任 AI、什么时候应该质疑它，以及如何验证其工作成果的工程师。
Agent Infrastructure Lab｜关注 AI、金融科技与工程基础设施的交汇点。
