平时是如何使用 AI 的

一句话先讲清楚

我平时把 AI 当成高频协作的工程搭档，不是把需求直接扔给它让它盲写，而是让它参与项目理解、方案规划、代码初稿、bug 定位、重构迁移和测试补全，但最后的上下文提供、方案取舍、结果验收还是由我负责。

1 分钟版本

我平时用 AI，核心不是把它当搜索框，也不是当外包程序员，而是当一个协作效率很高的工程搭档。

第一类场景是学习和理解项目。面对新代码库或者陌生模块时，我会先让 AI 帮我梳理目录结构、核心链路和关键对象，快速建立全局地图，但我不会把它输出的内容直接当事实，最后还是会回到代码和实际运行结果验证。

第二类是做新功能。我一般会先让 AI 只输出变更计划，比如改哪些文件、会影响哪些边界、预期 diff 大概长什么样，计划确认之后再让它写实现。这样能避免一上来就生成很多看起来很勤奋、实际上跑偏的代码。

第三类是 bugfix 和重构。我会给它错误日志、最小复现和上下文，让它先列定位假说、验证步骤和最小改动方案；如果是迁移或重构，我更倾向让它先做小范围试跑、看 diff、再分批推进，而不是一次性大改。

我现在比较稳定的原则有两个。第一，AI 更适合边界清晰、可验证、重复性高的任务。第二，人还是要负责上下文、验收和风险兜底，因为 AI 放大的主要是产能，但真正稀缺的还是判断力和治理能力。

如果面试官追问“你觉得用 AI 最关键的是什么”

我觉得最关键的不是 prompt 技巧，而是能不能把上下文讲清楚。很多团队用 AI 效果一般，不是模型不够强，而是业务知识散在口头沟通、文档和代码碎片里，没有被整理成 AI 能稳定理解的上下文。上下文越稳定，AI 的命中率就越高。

如果面试官追问“什么时候不用 AI 直接写”

如果是技术债特别重、上下文很混乱的老项目，我不会直接让 AI 上来实现需求。更稳妥的做法是先让它帮我梳理坑点、依赖关系和风险边界，我自己补充判断后，再决定怎么改。否则它很容易把原来的混乱放大。

如果面试官追问“怎么避免 AI 幻觉或者低质量结果”

我的做法是把验证前置。比如先让它出计划，再让它实现；实现后要求它自检失败场景、边界条件和测试用例；最后我会结合编译、测试、diff 和实际运行结果做验收。也就是说，我会信任它提高效率，但不会跳过验证。

如果面试官追问“模型或工具怎么选”

我一般按任务类型选。架构设计、大重构这种质量敏感任务会用强模型；批量生成测试、样例这类成本敏感任务会用便宜一点的模型；读日志、写小脚本、做摘要这种速度敏感任务会用更快的模型。核心不是追单一最强模型，而是按质量、成本和速度做匹配。

最后一句收口

所以如果一句话总结，我平时使用 AI 的方式不是把它当替代工程师，而是把它放进我的开发工作流里，负责加速理解、规划、实现和验证，而我自己负责上下文、取舍和最终质量。