AI coding 已不再是一个可选项，它是你必须掌握的新技能 ———— 致每一个软件开发者
你可能也彷徨在这个路口
这半年，只要你和研发同学聊过 AI，八成会听到几种很熟悉的话：
- “AI 写代码已经很强了，不学就掉队。”
- “先别激动，它很多时候也就是个会写样例的聊天框。”
- “复杂项目它根本搞不定，学了也未必用得上。”
- “我现在已经很忙了，再学一套新工具，图什么？”
我对这几句话都不陌生，因为我自己也在这几个想法之间来回横跳过。
所以这篇文章不打算喊口号，也不准备拿“新时代已经到来”这种句式吓人。我的目标很简单：把这件事讲清楚，看看 AI coding 到底是在制造焦虑，还是已经开始改变研发这份工作的默认打法。
我为什么开始认真看这件事
我判断一个工具值不值得花时间，不看它宣传得多热闹，只看一件事：它能不能进入真实工程现场，而不是只会在PPT中夸夸其谈。
我在 2026 年 4 月 29 日又翻了一遍 OpenCode 官方文档。现在官方文档里已经单列了 CLI、Web、IDE、Models、MCP servers、Agent Skills 等页面，CLI 文档里也能看到 run 这类非交互式入口。这个信号很直接：
AI coding 已经不只是“帮你续两行代码”，而是在变成能进入研发流程的工具形态。
这和前几年那种“帮我写个函数”“帮我解释一段报错”的体验，不是一回事。
它到底变了什么
如果把这几年的变化粗暴一点总结，我觉得大概经历了四步：
- 补全阶段
它帮你续写、补样板，主要省手。 - 问答阶段
它帮你解释概念、分析报错、整理思路，主要省搜索时间。 - Agent 阶段
它开始能读仓库、改文件、跑命令、串步骤，已经不只是聊天。 - 工程化协作阶段
它开始进入规则、权限、MCP、Skill、验证这些边界里，离“真实干活”更近了一步。
前两个阶段更像“写代码辅助器”，后两个阶段更像“研发副驾驶”。它不会替你签线上事故复盘，也不会替你为错误拍板，但它已经能把不少原来只能人肉搬运的脏活累活先扫一遍。
我的体验
我之前也一直在体验AI，但因各种原因并没有深度使用。
25年上半年之前，我的感受是AI 编程还是纯辅助；尝试过让AI写一个桌面应用，折腾了两周达到基本可用状态，过程比较艰辛曲折（怎么形容呢，就像教刚学完谭浩强老师的c代码编程课的学生上项目一样）；整体感触是，这玩意太费劲了，还不如自己写。25年下半年，AI 编程大模型进入高速迭代，能力实打实的提升；用cursor + ops4 对应用进行了迭代，该笔记应用已成为我自己的重要日常工具了。26年AI工具已经真正开始改变我的工作方式了：
第一，很多任务的默认起手式已经变了。以前是自己翻仓库、自己拆任务、自己找入口；现在更高效的做法，往往是先让 AI 帮你读代码、列风险、给初稿，再由你定边界、做 review、补验证。代码不一定全让它写，但上下文整理这件事，已经有人能帮你分担了。
第二，复杂项目里最贵的本来就不是敲代码。真正吞时间的，通常是找入口、理调用链、判断影响面、补验证、兜回归。写那几行 if 只是最后的体力活，前面的理解成本才是大头。AI coding 真正开始有价值，恰好是在这些地方。
第三，工具已经从展示能力走到配置能力。像 OpenCode 这类工具，已经在官方文档里明确提供模型接入、规则约束、权限控制、MCP 扩展、非交互式运行这些能力。换句话说，它不是在证明“我能写一段代码”，而是在认真回答“我怎么进工程现场，不跑偏”。
所以我现在更愿意把它看成一种新的协作习惯。
AI会替代程序员么？
关于“AI 会不会替代程序员”这个问题，我自己的判断一直比较朴素：
它会优先替代那些低价值、重复性强、结果又相对可验证的研发劳动； 但真正创造性的内容，AI还不具备可替代性
在某次内部会议上，领导谈及AI 是否会替代程序员时说：AI 不会取代程序员，但AI会取代不会使用AI的程序员！
我觉得这个说法还是是比较中肯的。
比如这些事，AI就很适合先顶上去：
- 先把陌生仓库的目录、入口和关键链路梳理出来
- 为一个边界清楚的小改动先打一版可 review 初稿
- 批量补日志、补测试、补样板、补类型
- 帮你先缩小报错排查范围，别一上来就满仓库乱翻
但短期内，别指望它替你做这些决定：
- 需求到底该怎么定义
- 哪条边界绝对不能碰
- 线上风险该不该现在就冒
- 哪个方案更符合团队长期维护成本
可以这样定位AI coding：
**AI 更像一个干活很快、但还得有人带的搭子。你要是把它当神仙，它会 give sb a lesson ：“没有人能随随便便成功，AI也不行”；但如果今天你对它爱搭不理，明天还真可能被弃之如敝履（是你，不是它）**。
哪些任务适合它
我现在看一个任务适不适合先让 AI 试一脚，基本只看三件事：
- 目标是不是足够清楚
- 影响面是不是相对可控
- 结果是不是方便验证
这三个条件越齐，越适合上手。反过来，任务再小，只要目标飘着、边界糊着、结果也没法验，那也一样会翻车。
比较适合新手起步的，通常是这些场景：
- 仓库理解
让它梳理模块关系、解释启动入口、追踪某个接口调用链。 - 低风险小改动
比如补一个字段映射、补一个空值判断、改一个明确文案。 - 重复劳动
比如统一配置格式、补测试样板、批量替换老写法。 - 先分析后执行
先让它列风险、列改动点、列验证步骤，你再决定让不让它动手。
不太建议一上来就这么玩：
- 需求还没说清楚，就让它直接开写
- 高风险核心链路，想靠一把梭解决
- 改完不看 diff、不跑验证，只相信它“看起来像对的”
- 一句“你看着优化一下”，默认它会懂你心里的边界
其中最后一种尤其危险。工程语境里，“你看着优化一下”常常可以翻译成：“请自由发挥，并顺便制造一点不可控的扩散”。
我见过最容易翻车的 3 种姿势
高能预警： 不要“奴役AI”，自己爽快“摸鱼”；如果一定要这么干，一定记得选中午。懂的都懂......
1. 把 AI 当万能代工厂
需求没说清楚，边界没给，验收标准没有，最后还想直接上线。这不是在提效，这是在把不确定性外包给未来的自己。
2. 只看它写得快，不看它改得对不对
AI 最麻烦的地方不是明显报错，而是 它经常看起来很像对的。所以哪怕只是一个小改动，也最好固定做几件事：看 diff、看影响面、跑最基本验证、看异常分支。后面的课程里，我们会专门讲怎么 review 它写出来的代码。
3. 还没提效，先把权限给满了
如果你把敏感配置、核心数据、无限制命令权限一股脑都交出去，问题就不再是“工具好不好用”，而是“你是不是准备把事故写进周报里”。
AI coding 的边界意识，和提效能力一样重要。
这个系列准备讲点啥
这个开篇算是忽悠... 呃，不对，讲完了。后面的内容会按这条线展开：
- 先跑通环境
把工具装起来，把模型接起来，把权限边界设起来。 - 再完成第一次闭环
真正做一次读码、改码、验证，而不是只停留在聊天界面。 - 再讲方法和工程化
把上下文工程、任务拆解、项目实战、OpenSpec 协作这些内容串起来。 - 最后补治理和沉淀
把 review、验证、安全、权限、Skill、MCP、团队复用这些后劲更大的内容补齐。
so，这个系列教程，没准备教你背一堆“高分 prompt”（主要原因也是没有准备），而是想建立一套 能在真实研发环境里持续复用的协作方法（不管行不行，flag先立起来）。
写在最后
程序员这行一直都在学新语言，换新工具，但不是每次换工具都会顺手改工作方式。AI coding 比较特别的地方就在这儿：
它动的不再是一个命令、一个工具、一个流程，而是开发人员的工作方式。
所以这篇文章如果只想让你带走一句话，那我希望是这一句。
