AI 编程搭子：它不是替代你，而是放大你的判断
AI 编程工具已经从新鲜玩具变成日常工具。现在再问“要不要用 AI 写代码”，就像很多年前问“要不要用搜索引擎查文档”一样，答案基本已经显而易见。真正值得讨论的是：怎么用，边界在哪里，哪些事情必须由人来判断。
我越来越把 AI 当成编程搭子，而不是自动驾驶。它可以很快读代码、找模式、生成草稿、解释报错、补测试、改文档。但它不知道项目真正的业务压力，也不知道某个看似普通的改动背后有没有历史包袱。
它擅长执行和联想，人必须负责方向和验收。
最适合交给 AI 的工作
AI 在几类任务上特别有效：
- 搜索代码结构，快速总结模块职责。
- 根据既有模式补相似代码。
- 写 README、迁移说明、变更摘要。
- 生成测试用例草稿。
- 排查 lint、类型错误、构建失败。
这些任务共同特点是：上下文明确、目标可验证、重复性较高。AI 可以把初稿速度拉得很快，人再进行审查和取舍。
真正危险的是把模糊需求直接丢给 AI，然后不验证就合并。它会写出看起来很顺的代码，也会在不熟悉业务约束时做出很自信的错误假设。
好的提示词来自好的工程直觉
很多人以为 AI 效果差是因为提示词不够玄学。其实更常见的原因是任务没被拆清楚。你让它“优化一下项目”，它很可能会乱动；你让它“把导航数据从页面抽到 JSON，并保持脚本共用同一份数据源，最后跑 lint/build”，结果就会稳定很多。
提示词的本质是工程任务描述。边界越清楚，验收标准越明确，AI 越容易给出可用结果。
这也意味着 AI 没有让工程能力变得不重要，反而让工程判断更重要。你要知道什么能改、什么不能改、什么必须测试、什么只是风格问题。
人负责最后一公里
AI 写出来的代码不能天然信任。至少要做几件事：
- 看 diff，确认没有无关改动。
- 跑测试、lint、build。
- 检查边界输入和错误路径。
- 判断是否符合项目已有风格。
- 确认安全和依赖风险。
这最后一公里很关键。AI 可以跑得很快，但它不会替你承担生产事故。工程师的价值正在从“亲手敲每一行”转向“定义目标、审查结果、维护系统一致性”。
和 AI 一起工作会改变节奏
以前做一个小功能，很多时间花在查文档、找文件、复制模式、修格式。现在这些摩擦被压低了，人会更快进入决策层：这个功能应不应该做？边界怎么定？上线后怎么观察？未来怎么维护？
这是一件好事。重复劳动少一点，判断就能多一点。AI 不是替代你成为工程师，而是逼你更像工程师。
真正的核心能力不会消失：理解业务、理解系统、理解用户、理解复杂度。AI 能放大这些能力，也会放大混乱。如果你知道自己在做什么，它会很强；如果你不知道，它只会更快地把不知道变成代码。