程序员与AI协作的一年反思：正确的心态比工具选择更重要 • halo 的技术博客

用AI辅助编程一年多了。从最初的Copilot，到后来的Claude Code，再到各种本地模型，我几乎尝试了所有主流方案。

但我发现一个有趣的现象：用同样工具的人，效果差异巨大。有人用它一天完成一周的工作，有人用它三小时写了一个Bot后就再也没打开过。

这个差异不在工具本身，而在使用工具的方式和心态。这篇文章是我的反思，也是一年来踩坑的总结。

第一个误区：把AI当作搜索引擎#

这是最常见的错误，也是效果最差的使用方式。

“帮我查一下这个错误怎么解决”、“告诉我Python怎么连接MySQL”、“React的useEffect怎么用”——这些都是搜索引擎的用法，AI确实能回答，但效率往往不如直接搜索。

为什么？因为AI给出的答案可能过时（知识截止日期问题）、可能不准确（幻觉问题）、可能不适合你的具体场景（缺乏上下文）。花时间判断AI答案的正确性，不如直接找一个高质量的Stack Overflow回答来得快。

把AI当搜索引擎用的人，往往会得出”AI编程不好用”的结论，然后放弃。这是一个认知陷阱。

正确的心态：AI不是搜索引擎，它是思维伙伴。它的价值不在于回答事实性问题，而在于帮你分析和解决复杂问题。

第二个误区：完全依赖AI，失去独立思考#

和第一个误区相反的另一端：过度依赖AI，丧失自己的判断力。

具体表现：

AI说什么就做什么，不验证就执行
不理解AI生成的代码，只管复制粘贴
遇到问题第一反应是问AI，而不是自己思考
代码报错了，让AI修，自己完全看不懂改了什么

这种用法的危害是隐性的但严重的。短期看效率确实提高了，但长期看你的技术能力在退化。你在用AI扩展你的能力边界，但如果不理解AI在做什么，你就失去了对能力的真正掌握。

一个具体的信号：如果你让AI生成的代码，在AI不帮你debug的情况下你完全无法独立解决问题，这就是一个警告。AI是你的放大器，不是你的替代品。

正确的心态：AI帮你做执行层的工作，你保持在思考层。理解AI在做什么，比单纯使用AI更重要。

第三个误区：追求完美Prompt而不是理解问题#

Prompt工程师”这个概念火了一阵，很多人花大量时间研究如何写出完美Prompt。这条路走偏了。

真实工作中的问题是：搞清楚需要问什么，比知道怎么问重要100倍。

比如”优化这个查询”这个Prompt，可以优化5种完全不同的写法，具体哪种对，取决于你对问题的理解深度。你理解得越清楚，问出来的问题就越精准，AI的帮助就越大。

而一个模糊的问题，比如”让这个系统更快”，AI能给出一个不错的大方向，但具体怎么实现，还是需要你自己有足够的技术判断力。

正确的心态：投资问题理解力，而不是Prompt技巧。好的问题 > 好的Prompt。

一年摸索出来的协作模式#

架构设计阶段：人为主，AI为辅#

架构设计是最需要人类判断力的环节。技术选型、模块划分、接口设计……这些决策会影响整个项目的生命周期，而且往往没有标准答案。

我在这阶段的用法是：先自己想清楚，画架构图，然后让AI帮我Review，指出我没想到的问题点。

# 我会给AI这样的上下文：
"我的系统需要：1. 支持每天100万次API调用 2. 需要持久化数据 3. 需要实时监控
目前想用FastAPI + PostgreSQL + Redis。帮我review一下这个架构选择有什么潜在问题。"

python

AI在架构层面的建议通常有价值，因为它能快速列举出很多你没考虑到的边界情况（比如：100万次调用的流量峰值如何处理？数据库连接池配置？），但最终的权衡决策必须由人来做。

代码实现阶段：AI为主，人为辅#

一旦架构确定，进入具体的代码实现阶段，AI就是主力了。

我现在的习惯是：把大任务拆成小任务（每个任务不超过100行代码），然后让AI逐个实现。实现完一个，测试一个，没问题再继续下一个。

这个”小任务拆分”的习惯很重要。我见过很多人试图让AI”帮我写一个用户认证模块”，结果AI生成200行代码，完全无法验证正确性，也看不懂。小任务拆分让每一步都在人的理解范围内。

# 典型的任务拆分：
# Task 1: 实现数据库连接配置（30行）
# Task 2: 实现User模型和基本CRUD（80行）
# Task 3: 实现JWT token生成和验证（50行）
# Task 4: 实现登录API endpoint（40行）
# Task 5: 写这三个API的单元测试（60行）

python

调试阶段：人机协同#

调试是AI编程最体现价值，也最体现陷阱的环节。

AI的强项是：根据错误信息给出可能的解决方向；帮你阅读长代码找到潜在bug；生成测试用例验证修复。

AI的弱项是：涉及多系统交互的复杂bug（它看不到全局）；与特定运行环境相关的bug；边界情况导致的bug。

我的策略：先让AI分析Bug可能的原因，形成一个排查列表，然后逐个验证。AI给出的第一个答案往往是错的，但排查列表很有价值。

# 我会给AI这样的调试Prompt：
"这个函数在测试环境正常，生产环境报错：TimeoutError: [Errno 110] Connection timed out。
函数功能：调用第三方支付API。测试环境和生产环境的区别是：测试环境是内网，生产环境走公网。
请列出最可能的5个原因，按概率排序。"

python

Code Review阶段：AI做第一轮，人做第二轮#

代码写完之后，让AI做第一轮Review是极好的。它不会累，不会赶时间，会仔细看完每一行。

# AI Review的Prompt模板：
"请review以下代码，关注：1. 安全性问题 2. 性能问题 3. 可维护性问题
注意这是Python代码，使用了FastAPI框架。"
# 然后粘贴代码

python

AI能发现的问题：明显的逻辑错误、缺少错误处理、潜在的死循环、安全漏洞（SQL注入、XSS等）、命名不规范。

AI发现不了的问题：业务逻辑是否符合需求（这个只有人知道）、代码是否与系统其他部分兼容、是否符合团队的编码规范（除非你给它规范文档）。

一个核心原则：保持”最后一公里”的能力#

这一年下来，我最核心的体会是：无论AI多么强大，你必须保持不靠AI也能解决问题的能力。

这不是说每次都要手动写代码，而是说：当AI不可用时（网络问题、API限制、工具故障），你能退回到手动模式继续工作。

具体来说，我保持这几个”不依赖AI”的能力：

能独立阅读和理解陌生代码 —— 即使AI能解释给你听
能手动排查常见Bug —— 至少知道去哪里找日志、如何读Stack Trace
能写出基本正确的代码 —— 不依赖AI也能实现简单功能
能评估AI输出质量 —— 知道什么时候AI在说废话

这些能力不是为了”防AI失业”，而是为了让你在与AI协作时保持判断力和主导权。

工具选择的反思#

最后说说工具选择。一年下来我的工具栈：

主力：Claude（API）+ Claude Code（复杂项目）
补充：Copilot（简单补全）、LM Studio（无网场景）
放弃：其他各种AI编程工具（用了一圈觉得没有明显优势）

但工具不是最重要的。重要的是你知道什么时候用什么工具，以及你用它的时候在做什么。

Claude Code适合做需要多步协作的复杂任务，因为它能记住上下文，保持跨文件的修改一致性。Copilot适合做简单重复的代码补全，它的延迟最低，交互成本最小。LM Studio在没有网络或者处理隐私敏感内容时用。

这种分层不是一成不变的，会随着工具能力的演进而调整。保持开放心态，但不要追新——每换一次工具都有学习成本，要确保收益大于成本。

Developers collaborating on code

Team working together in modern office

写在最后#

AI编程工具这一年经历了爆炸式发展，但底层逻辑没有变：工具放大能力，但替代不了能力。

正确的心态是：把AI当作一个极度勤快但需要管理的助手。它可以帮你做很多事情，但最终负责的人是你。

保持学习的习惯，保持对技术的好奇心，保持独立思考的能力。在这个基础上，用AI把你的能力放大10倍——这才是AI编程的正确打开方式。