AI 能替你写代码，但不能替你建立编程基本功

AI 可以把需求描述迅速变成代码，却不能替开发者形成判断代码是否正确的能力。真正的编程基本功，不是背下多少语法，也不是坚持逐字符手写，而是能把模糊需求拆成明确约束，理解数据和控制流，定位故障，评估安全与维护成本，并用可重复的证据证明实现符合预期。AI 适合承担生成、检索和机械修改；需求澄清、方案取舍、结果验收与事故接管仍必须由人负责。

这一区分在 AI 编程中尤其重要。自然语言生成代码降低了实现门槛，也让原型迭代更快，但“代码已经出现”不等于“问题已经解决”。生成结果可能可以运行，却遗漏异常路径；可能通过几个示例，却在并发、权限或边界输入下失败；也可能为了完成局部任务，引入跨文件改动和难以察觉的技术债。开发者若无法读懂这些变化，就只能继续把错误信息交给模型碰运气，失去对系统的控制。

基本功的核心是建立可迁移的心智模型

语法知识会随语言和框架变化，心智模型却能跨工具迁移。看到一段程序时，开发者应当能回答：输入从哪里来，经过哪些状态变化，输出写到哪里；失败如何传播；资源由谁创建和释放；模块之间依赖什么契约；哪些操作可以重试，哪些操作会产生不可逆副作用。只有这些问题被说清楚，代码审查才不是凭感觉点头。

以一个“创建订单”的接口为例，表面任务只是接收参数并写入数据库，实际还包含身份验证、价格计算、库存竞争、事务边界、幂等、防重复支付和审计记录。AI 很容易生成一条顺畅的成功路径，但开发者必须主动追问：两次相同请求会怎样，扣库存成功而支付记录失败会怎样，客户端超时后重试会怎样。发现这些约束并决定处理策略，才是工程能力的主体。

因此，衡量自己是否掌握某项技术，不应看能否让 AI 生成相关代码，而应看能否在没有模型提示的情况下画出关键流程、解释重要取舍、预测故障模式，并设计验证手段。命令可以临时查询，API 可以随时翻阅，但如果连分支、提交、镜像、进程、事务或异步任务的基本关系都不清楚，工具输出越多，误操作的范围往往越大。

AI 最容易掩盖的四类能力缺口

代码阅读与执行推演

生成代码看起来结构完整，会诱使人只检查命名和格式。有效的阅读需要沿真实执行路径推演：条件是否互斥，循环是否终止，空值是否可能到达，异常是否被吞掉，状态是否在错误时被部分更新。对于陌生代码，可以先手工选择一个正常输入和两个边界输入，逐步记录变量与副作用，再运行测试验证推演。推演与实际不一致的地方，正是需要补齐的理解。

调试与根因定位

把报错全文交给模型并反复改提示，不等于调试。调试的基本过程是先稳定复现，再缩小范围，然后提出可证伪的假设，最后用日志、断点、最小用例或二分修改验证。每次实验只改变一个关键条件，并记录预期与观察结果。模型可以帮助列出假设，但哪条证据支持哪种解释，必须由开发者判断。

测试与验收设计

AI 常会根据现有实现生成测试，这可能把实现错误原样固化。测试首先应从需求和不变量出发。例如功能的不变量不是“函数返回成功”，而是资金总额守恒、同一请求不会重复扣款、失败事务不留下半完成状态。先写下不变量，再设计正常、边界、异常和恢复场景，最后才让 AI 补充测试代码，能显著降低自证循环。

安全与维护判断

能运行的代码可能硬编码凭据、拼接查询、放宽权限，或在日志中泄露敏感数据。它也可能制造重复抽象、隐式耦合和大范围修改，让后续变更越来越昂贵。静态分析、依赖扫描和持续集成能发现一部分问题，但工具报告同样需要人理解影响范围、判断优先级并选择修复方式。自动检查是护栏，不是责任转移。

把 AI 放进受控的开发闭环

一个可靠的协作顺序是“先定义，再生成，后验证”。生成前先写清目标、非目标、接口契约、数据约束和验收条件。任务应切成可以独立检查的小步，避免一次要求模型重写整个模块。每一步完成后查看差异，确认改动只覆盖预期文件，运行相关检查，并解释为什么结果可信。

提示中可以要求模型说明假设、列出风险和提供备选方案，但不要把说明当作事实。尤其是库版本、配置字段和安全行为，需要以当前项目依赖、正式文档和实际运行结果为准。模型声称“测试通过”也不构成证据；只有本地或持续集成环境确实执行并留下结果，才算完成验证。

提交前可使用一份短清单：需求中的每项行为是否有对应实现；新增输入是否经过校验；错误是否以一致方式返回；敏感信息是否可能进入代码或日志；新增依赖是否必要；测试是否覆盖失败路径；回滚方式是否明确；自己能否用几句话解释主要数据流。任何一项无法确认，都应暂停合并并继续调查。

目标：为重复请求提供幂等处理
约束：同一业务键只能产生一次状态变更
验证：连续发送两次相同请求，记录响应与数据库变化
异常：第一次执行在写入后超时，再次请求仍返回同一结果
审查：确认唯一约束、事务边界和冲突处理位于同一逻辑链

这种写法比“帮我实现幂等”更有效，因为它把可验证的工程约束交给模型，也迫使开发者提前理解问题。AI 生成的是候选实现，测试、日志和审查提供证据，开发者依据证据作出决定。

用刻意练习保留独立接管能力

训练基本功不必排斥 AI，也不必把所有生产代码改为手写。更可行的方法是保留一块明确的练习区：选择规模有限但包含真实约束的项目，定期完成从设计、编码到测试和发布的完整闭环。练习时限制 AI 直接生成核心逻辑，可以用它解释概念、提出反例或审查完成后的实现。重点不是追求低效率，而是确保关键思考确实发生在自己脑中。

适合练习的项目应当具有输入输出、持久化、错误恢复和可观测性，而不只是一次性算法。一个小型任务队列、命令行记账工具或带权限的 API 都可以。先写最小设计，明确数据结构与失败策略；再逐步实现，每完成一段就写测试；出现故障时保留调试记录；最后复盘哪些判断依赖了猜测，哪些有证据支持。

还可以安排固定的“无生成时段”。在这段时间里独立完成一个小功能或修复一个缺陷，允许查文档，但不让 AI 直接给出代码。结束后再让模型审查，并逐条判断建议是否成立。这样既能暴露知识盲区，也能训练对 AI 输出说“不”的能力。对已有经验的开发者，练习重点可转向事故演练、性能分析和陌生模块接管。

学习效果应按能力而非代码行数评估。可以每周检查四件事：能否从现象构造最小复现，能否在阅读后讲清调用链，能否为需求写出边界与不变量，能否在工具不可用时完成基本的版本控制、构建和回滚。某项持续依赖模型，就针对它设计一次小练习，而不是继续增加提示词复杂度。

新手和资深开发者应采用不同边界

新手缺少参照系，很难识别貌似合理的错误，因此更应控制生成范围。学习新概念时，先自己写出最小实现并预测结果，再让 AI 提供反馈；遇到错误先阅读堆栈和定位触发条件，形成一个假设后再提问。不要直接接受大段跨文件修改，也不要在无法解释代码时把它加入作品或生产系统。

资深开发者可以把更多机械工作交给 AI，但需要强化架构约束和质量门禁。任务描述中应包含现有模式、兼容要求、性能预算和禁止改动区域；审查时关注模型是否扩大了作用域、复制了已有能力或改变了隐含契约。复杂重构应分阶段提交，使每一步都能测试和回滚，避免把理解成本推迟到故障发生之后。

团队还应明确责任归属。AI 不能成为评审记录中的责任主体。谁批准变更，谁就需要理解风险和验证证据。对于权限、支付、隐私数据和基础设施等高风险区域，应提高人工复核强度，并采用自动扫描、双人评审和分阶段发布等措施。速度收益只有在缺陷成本可控时才是真正的生产力。

判断是否可以放心使用 AI 生成结果

可以用三个问题做最终判断。第一，离开当前对话后，是否仍能解释实现的关键路径和失败方式；第二，是否有独立于生成代码的验收标准，以及真实执行得到的验证证据；第三，如果上线后异常，是否知道从日志、指标、提交和数据状态中的哪一处开始排查。只要其中一个问题无法肯定回答，就说明理解或验证还没有完成。

AI 编程的价值在于缩短从意图到候选实现的距离，而不是取消软件工程。越是容易快速生成大量代码，越需要扎实的阅读、调试、测试、安全和系统设计能力来过滤结果。基本功也不是对旧式开发习惯的怀念，它是开发者在工具失误、环境受限和复杂故障中仍能接管系统的保障。把 AI 当作高效助手，同时持续练习独立判断，才能让速度增长而不让控制力流失。