Free Preview
先试读：AI写代码到底靠不靠谱
• 一极说："我给它一个想法，它就能生成一个完整的应用。"——这是过度乐观。
• 另一极说："AI 写的代码根本不能用，一跑就崩。"——这是过度悲观。
这篇能解决什么问题
- 把一句模糊需求改成 AI 能执行、你能验收的任务卡。
- 知道执行前要先检查哪些文件、风险点和验证命令。
- 避免 AI 顺手改无关内容，最后只交付可审、可回退的改动。
付费后能看到哪些内容
- AI 写代码现在到底到了什么水平
- 为什么会有这种反差
- 它现在真的做得到位的几类任务
- 它依然表现很烂的几类任务
可以先照着试的一句话
这是我要改的功能：___。请先阅读项目结构，列出会动哪些文件、风险点和验证命令；等我确认范围后，再开始做最小改动。
试读到这里先判断是否对你的任务有用；完整文章会继续展开步骤、案例、模板和避坑细节。
AI 写代码现在到底到了什么水平
两极观点都不对。先建立一个准确的基线。
关于"AI 能不能写代码"，舆论一直很两极：
• 一极说："我给它一个想法，它就能生成一个完整的应用。"——这是过度乐观。
• 另一极说："AI 写的代码根本不能用，一跑就崩。"——这是过度悲观。
真实情况夹在中间，但不是折中——是"有些任务它已经明显比一个 middle 级工程师做得好，有些任务它还不如一个实习生"。
为什么会有这种反差
AI 写代码的表现，和任务本身的"形状"高度相关。同样叫"写代码"，不同任务对它来说难度差十倍以上：
• 改一段已有代码里的 bug，只要错误在局部——它经常一次就修对。
• 从零写一个完整的小工具，逻辑有明确输入输出——它能生成可跑的成品。
• 在一个十万行代码的老项目里，新加一个功能又不破坏既有逻辑——它会犯各种愚蠢的错误。
同一个模型，在这三种场景下的表现可以天差地别。所以"AI 写代码靠不靠谱"这个问题本身就没法笼统回答。正确的问题是：我要做的这类任务，AI 在上面的水位线在哪。
一个任务对 AI 来说有多容易，大致看三件事：上下文有多复杂 / 输入输出有没有清晰边界 / 正确标准是不是显性的。
上下文简单、边界清楚、对错一眼能看出——AI 大概率做得不错。
上下文复杂、边界模糊、对错要跑通才知道——AI 容易踩坑。
它现在真的做得到位的几类任务
这些任务交给它，省出的时间非常可观。别再手工写了。
新开一个项目的骨架、写一个 CRUD 的前后端、配 TypeScript / ESLint / Prettier、生成单元测试的模板——这类"知道该怎么写、只是写起来繁琐"的任务，它几乎是一次到位。
手工写要半小时的活，现在三条 prompt 就能搞定。这是 AI 写代码里价值最稳定、收益最直接的场景。
写一个"扫描目录里所有 csv 文件、按某个字段聚合、导出成一个新表"的 Python 脚本、一个"批量重命名图片"的 shell 脚本、一个"从 API 拉数据存到 Excel"的任务——这些"边界明确、一次性使用"的任务，AI 现在做得非常好。
特别适合你手头有一次性问题、懒得自己写脚本的场景。五分钟能完成的事，以前可能要查半小时文档。
你把报错信息贴给它，附上相关的几段代码，让它定位问题——它经常能一次说到点子上，偶尔还会指出你没注意到的隐藏问题。
前提是：错误信息要贴全，要贴的代码上下文要给够。糊糊地说"这段不 work"它也只能猜。
给它一段陌生的代码，让它解释"这段做的是什么"、"为什么这样设计"、"有什么潜在问题"——解释质量很高，非常适合阅读一个新项目或者接手别人的代码。
让它给重构建议也不错——它指出的问题大多数确实有道理。但是否采纳要自己判断，不要全盘照改。
给它一个函数，让它写单元测试——它会把正常 / 边界 / 异常情况都覆盖一遍。比大多数人自己写的测试更全。
这是 AI 写代码里一个被低估的高价值场景。尤其是你已经有主干代码、想补一层测试保护时。
上面五类共同的特点是：任务边界清楚 / 正确标准显性 / 不需要理解太大的上下文。这是 AI 写代码的"舒适区"。
它依然表现很烂的几类任务
这些任务硬交给它，大概率浪费时间——有时候还会比手动做更慢。
一个已经跑了好几年、几万行代码、各种隐性约定的老项目，让它"加一个功能但不能破坏既有逻辑"——它经常会违反项目原有的命名规范、调用不存在的函数、或者重新发明轮子。
不是它笨，是这种任务需要对"整个项目的隐性惯例"有全局理解，这超出它当前的能力边界。
"这个功能用微服务还是单体？"、"数据库选 PostgreSQL 还是 MongoDB？"——它能给出"听起来很合理"的答案，但这些答案本质上是"教科书式的平均解"，很可能不适合你的具体情况。
架构决策需要对团队规模、业务复杂度、长期演进、运维能力做综合判断——这些东西它并不知道。
"这个 SQL 为什么慢？"、"这个循环该怎么优化？"——它给的答案经常是"理论正确、实际无效"的。因为性能问题高度依赖具体数据分布、硬件、调度，它靠纯文本推测判断不出真实瓶颈。
该用 profiler 的场景，就别指望 AI 凭空告诉你答案。
某个库刚发布的 v3 版本，AI 的知识还停在 v2——它会自信地给你 v2 的写法，编译报错的时候你自己去找。
遇到新版本框架、不熟的库、冷门的 SDK——先自己扫一遍官方文档，再让它帮你写。或者让它联网查最新文档再写。
订单结算、权限校验、计费规则——这些地方一行代码错就是直接事故。AI 写的版本通常"看起来"合理，但细节可能和你的业务规则对不上。
这类代码可以用 AI 起初稿，但必须自己一行一行审，而且要跑真实用例测。不是不能让它写，是不能让它说了算。
强项都有"明确边界 + 显性标准"；弱项都涉及"隐性上下文 + 模糊判断"。AI 在显性任务上已经超越中级工程师，但在需要"对整体系统有感觉"的任务上还差得远。
这不是你用错了工具，是这一代 AI 的结构性能力边界。清楚边界本身就是最大的用工具能力。
"看起来对、其实错"的四种失败模式
这些错误最危险——不是崩给你看，而是安静地跑，让你以为它对了。
1. 调用不存在的函数
它可能"编造"一个库里不存在的函数名——名字看起来非常合理。你直接跑会报错；你以为对了就直接提交会出事。
2. 过时 API 混写
同一段代码里一半是新版写法、一半是旧版写法。前端领域最常见——React / Vue / TypeScript 版本切换时尤其明显。
3. 边界条件偷懒
主逻辑对了，空值、异常、零长度、超大输入这些边界情况它往往只覆盖一部分。测不到的时候不知道，线上遇到就崩。
4. 静默吞异常
它经常用 try/catch 包起来、然后什么都不做。表面上"代码跑得很稳"，实际上把错误藏起来了。这类问题最坑。
5. 硬编码"看起来合理的"值
"它生成的代码里写的是 1000，但我需要的是 1024"——它会用"通用默认值"，而不是你业务需要的值。
6. 删掉看不懂的既有代码
改一个函数时，它可能把"看起来无关"的前两行注释 / 日志 / 异常处理顺手删了。这些"附属物"往往是有原因的。
怎么防住这些"安静错误"
一些习惯能大幅减少这类问题：
• 永远跑一遍再提交。AI 说"这样就行了"不等于真的行。
• 对边界条件主动测。传空、传 0、传超长、传特殊字符——一次测完。
• 大改动要看 diff，不要看结果。看它到底动了什么、删了什么，而不是看"跑起来是不是对的"。
• 关键业务逻辑要自己读一遍。就算它写得"看起来对"，也要走读一遍，确认和你脑子里的规则一致。
• 让它自己复述一遍。写完让它总结"这段代码的关键逻辑是什么、边界怎么处理、可能有什么风险"——它的自述经常能暴露它自己没想周全的地方。
AI 写代码的收益不在"替你写"——在"替你写八成，剩下两成你审核"。如果你把全部责任都推给它，它就会把你坑；如果你把它当一个产出快但需要审的初级开发看，它会变成一个非常顺手的合作者。
从"它写得怎么样"变成"我审得怎么样"——这是"会用 AI 写代码"和"被 AI 骗着写代码"的真正分水岭。
- AI 写代码不能笼统判断——看任务的"形状"：边界明确的强，隐性上下文多的弱
- 强项：样板代码 / 脚本 / 局部修 bug / 代码解释 / 写测试
- 弱项：老项目大改动 / 架构选型 / 真正的性能优化 / 最新 API / 核心业务逻辑
- 六种"安静错误"：编造函数 / 过时 API / 边界偷懒 / 吞异常 / 硬编码 / 误删既有代码
- 提高收益的关键不在让它写更多，而在你审得更细——AI 是快初级开发，不是高级工程师
Let AI write. You stay responsible.