AI 编程助手改变了什么，没改变什么

先给一个观察：用得好的人，效率提升集中在「样板代码」和「不熟的领域」，而不是核心业务逻辑。这一点决定了它的边界。

一、它确实改变了的三件事

1. 起手速度

从零写一个脚本、一个 CRUD 接口、一段正则，过去要查文档，现在描述清楚就行。省下的时间不是「打字」，是「组织语法」。

2. 陌生语言与框架的上手

不熟的生态里，它能给出可运行的起点，再对照文档改。这对跨栈工作是实质帮助。

3. 重复性重构

批量改名、提取函数、转换写法，这类机械工作的成本降了一个量级。

二、它没有改变的三件事

1. 需求判断

「这个功能该不该做」「这个边界条件该怎么处理」——这类判断依赖对业务和用户的理解，模型不在那个上下文里。

2. 架构决策

拆不拆服务、数据放哪、状态怎么管，这些决定的代价在两三年后显现。模型能给你几个方案，但不知道你的团队能力、运维现状、未来规划。

3. 责任

出了线上事故，负责的是人。这条决定了「人必须读懂自己提交的每一行代码」，而读懂的效率提升远小于生成的效率提升。

三、一个新的风险：看起来对的错代码

最危险的不是明显的错误，而是语法正确、逻辑合理、但在边界条件下出错的代码。它比手写错误更难发现，因为读起来「很顺」。

应对三条：

• 关键路径必须手写或逐行审：涉及金额、权限、数据删除的部分；
• 测试先行：先写测试用例再让它生成实现，能挡住大部分静默错误；
• 禁止直接粘贴到生产：任何生成代码都要过一遍 review 和 lint。

四、效率提升的真实分布

很多团队感觉「买了工具但没提速」，原因往往是使用集中在最后三行。

五、对内容与文档的影响

同样的逻辑适用于写作：模型能快速产出草稿，但「写什么」「给谁看」「判断对不对」仍然要人。批量生成的低质内容会拖累站点质量，这一点在搜索算法里已有明确体现（见 SEO 还能做吗）。

六、给个人的建议

1. 把它当加速器，不当替代品：你的判断力是稀缺资源；
2. 练习写清楚需求：描述得越准，产出越可用——这项能力本身也在升值；
3. 保持手写能力：需要深度改动时，手写比改生成代码快；
4. 用它学新东西，别用它跳过理解。

团队层面的知识沉淀，见 技术债 与 远程协作的账。

相关阅读

• 技术债：为什么团队明知故犯
• 远程协作工具的真实成本
• SEO 还能做吗：搜索流量结构的变化
• 从「增长黑客」到「内容资产」