“不是说，现在都 AI coding？他居然还在手搓，真不容易。”当学生用“非遗”形容手敲代码时，玩笑背后其实是开发方式正在改变。拥有百万粉丝的编程讲师李游谈到的 AI 冲击，不只是代码生成速度变快，更触及一个现实问题：当模型能迅速产出函数、测试和配置，学习编程还有没有必要从基础语法练起？
答案不是在“全部手写”和“全部交给 AI”之间二选一。对开发者更有价值的能力，正在从单纯输入代码，转向定义问题、约束实现、验证结果和承担工程责任。
AI 缩短的是输入时间，不是判断链条
传统编程教学常把注意力放在语法、API 和算法实现上。AI Coding 可以快速补全这些内容，也能根据自然语言生成项目骨架。于是，逐字符敲出循环、数据类或 CRUD 接口，看起来不再稀缺。
但一段代码从“能够生成”到“可以上线”，中间仍有一条完整的判断链：
- 需求是否明确，边界条件是否完整；
- 依赖和 API 是否真实存在，版本是否匹配；
- 并发、异常、权限和数据一致性是否得到处理；
- 测试是否验证了业务行为，而不只是覆盖正常路径；
- 代码失败时，团队能否定位、修复并解释原因。
AI 可以参与每一个环节，却不能自动替开发者确认业务事实。尤其是来源摘要没有涉及具体工具、模型或准确率，因此不能把这场变化简单归结为某款产品已经取代了程序员。更准确的说法是：代码生成的门槛下降了，验收代码的门槛反而提高了。
“手搓”仍然重要，但训练目标要变
手敲代码的价值不在于证明打字速度，而在于建立可用于审查 AI 输出的心智模型。开发者至少需要看懂控制流、数据结构、类型、异常传播、数据库事务和网络请求，否则很难发现一段“读起来很顺”的错误实现。
教学方式也可以随之调整。与其要求学生反复背诵框架样板，不如把练习拆成三个层次：
- 无 AI 完成小规模核心逻辑：确认学习者理解循环、分支、函数边界和复杂度。
- 使用 AI 扩展实现：让模型补测试、文档或适配层，同时要求学习者说明提示词中的约束。
- 审查并破坏 AI 代码：主动构造空输入、重复数据、超大数据和异常依赖，观察实现在哪里失效。
这种训练并不排斥手写，也不把手写本身当作目标。能独立写出几十行关键逻辑，是为了在自动生成几百行代码后仍然保有判断力。
可以这样实践：让 AI 写候选实现，人来定义验收标准
下面是一个可以直接运行的小练习。假设我们需要统计订单金额，并拒绝非法数据。先由人写测试和接口约束，再让 AI 生成或修改实现。
将下面内容保存为 order_total.py：
from decimal import Decimal, InvalidOperation
def calculate_total(items: list[dict]) -> Decimal:
"""Calculate an order total from items containing price and quantity."""
total = Decimal("0")
for index, item in enumerate(items):
try:
price = Decimal(str(item["price"]))
quantity = int(item["quantity"])
except (KeyError, TypeError, ValueError, InvalidOperation) as exc:
raise ValueError(f"invalid item at index {index}") from exc
if price < 0 or quantity < 0:
raise ValueError(f"negative value at index {index}")
total += price * quantity
return total.quantize(Decimal("0.01"))
再保存测试文件 test_order_total.py：
import unittest
from decimal import Decimal
from order_total import calculate_total
class CalculateTotalTests(unittest.TestCase):
def test_calculates_total_without_float_error(self):
items = [
{"price": "0.10", "quantity": 3},
{"price": "19.99", "quantity": 2},
]
self.assertEqual(calculate_total(items), Decimal("40.28"))
def test_empty_order_is_zero(self):
self.assertEqual(calculate_total([]), Decimal("0.00"))
def test_rejects_negative_quantity(self):
with self.assertRaisesRegex(ValueError, "negative value"):
calculate_total([{"price": "10.00", "quantity": -1}])
def test_rejects_missing_fields(self):
with self.assertRaisesRegex(ValueError, "invalid item"):
calculate_total([{"price": "10.00"}])
if __name__ == "__main__":
unittest.main()
运行命令：
python -m unittest -v
接下来可以把候选实现交给 AI 审查，但提示词不要只写“帮我优化”。可以明确角色、边界和输出格式：
你是一名负责支付系统代码审查的 Python 工程师。
请审查 calculate_total，但不要改变它的公开函数签名。
约束：
1. 金额计算必须使用 Decimal，不能转为 float。
2. 负数价格和数量必须被拒绝。
3. 指出 bool 作为 quantity 输入时是否会被意外接受。
4. 补充至少 4 个失败路径测试。
5. 先列风险，再给出最小补丁，最后解释每项修改。
这里最关键的部分不是模型能否写出补丁，而是开发者提前定义了金额精度、输入范围、兼容性和交付格式。比如 Python 中 bool 是 int 的子类，当前实现会把 True 接受为数量 1。如果没有领域约束和针对性测试，这类问题很容易藏在一段表面正确的代码里。
把 AI 纳入工程流程，而不是只放进编辑器
团队采用 AI Coding 时，可以建立一条简单但明确的边界：
- 生成代码必须通过与人工代码相同的格式化、静态检查和测试流程；
- 涉及认证、支付、权限、加密和数据库迁移的改动必须人工审查；
- 提示词中不要粘贴密钥、用户隐私或未经授权的内部代码；
- 依赖、函数和配置项需要查阅官方文档，不能因为模型语气确定就默认存在；
- 提交记录应说明行为变化和验证方法，而不是只写“AI 生成”。
对个人开发者来说，也可以保留一块“无 AI 训练区”：定期手写解析器、小型数据结构、并发控制或故障排查脚本。目的不是拒绝工具，而是确保在模型不可用、输出错误或上下文不足时，自己仍能继续推进工作。
真正需要保留的是代码主权
“手敲代码成了非遗”是一个生动的课堂观察，但手写代码消失与否并不是最重要的问题。键盘输入量可能继续下降，阅读、建模、验证和调试的比重则会增加。
采用 AI Coding 时，可以用四个问题检查自己是否仍掌握主动权：我能否说清需求边界？我能否解释生成代码？我是否验证了失败路径？出现事故时，我能否在没有同一段提示词的情况下修复它？
四个问题都能回答，AI 就是生产力工具；如果只能得到“它看起来能跑”，那么节省下来的输入时间，很可能会在排错和返工阶段加倍偿还。