AI Coding了大半年，我从执行者变成了决策者

先交代一下背景。我是一名有八年后端经验的开发者，去年年初开始系统性地把AI Coding工具接入日常工作流。半年多下来，我发现一个很有意思的变化：我亲手写的代码越来越少，但产出反而越来越高；我的职位没变，干的活却彻底变了——从一个接需求、写接口、改Bug的执行者，变成了拆需求、定方案、审代码、做取舍的决策者。

这半年我最大的体会是：AI Coding真正改变的不只是“写代码的速度”，而是整个职业角色的重定义。以前我花70%的时间在“怎么实现”上，现在这70%被压缩到了20%，剩下的时间全部被“做什么、为什么做、不做会怎样”这类决策问题占据了。这篇文章想把这半年里的真实经历、方法、踩过的坑，以及我对“AI Coding工程师到底算什么工种”这个热门问题的思考，完整地分享出来。

1. 先说结论：AI Coding到底改变了什么

1.1 它压缩的不是编码时间，而是“从想法到代码”的翻译成本

很多人以为AI Coding的价值是“打字更快”，这个理解太表面了。真实的开发流程里，编码只是最后一步。前面还有需求澄清、方案选型、接口设计、数据建模、边界确认——这些才是真正吃时间的环节。AI Coding工具真正变革的，是“想法到代码”这一段的翻译成本。

以前我要把一个业务逻辑变成代码，需要先在脑子里过一遍技术方案，再一行一行把方案翻译成语法。这个翻译过程极其耗时，而且充满琐碎的重复劳动。现在我把方案讲清楚，AI直接输出完整实现，我只需要检查它是否忠实于我的意图。翻译成本趋近于零，省下来的时间自然就流向了更高层次的决策。

我用过一个很直观的类比：以前的程序员是翻译官，把业务语言翻译成机器语言；现在的程序员是主编，负责定选题、定基调、审核成稿，具体的遣词造句交给AI去处理。翻译官的价值体现在语言转换的准确性上，主编的价值体现在判断力和审美上。

1.2 角色的转变不是一蹴而就的，它分三个阶段

先说清楚，我不是一开始就能从执行者跳到决策者的。这半年我经历了三个清晰的阶段。

第一阶段是“工具尝鲜期”。这个阶段AI对我来说就是个高级自动补全，写个循环、生成个DTO、补个单元测试，速度和体验确实比手敲好，但对工作流没有任何结构性影响，角色的重心还在写代码上。

第二阶段是“信任建立期”。这个阶段我开始让它写完整的函数、模块，甚至一整个接口。刚开始非常痛苦——它输出的代码质量不稳定，逻辑漏洞防不胜防。我每天要做大量的Review，甚至觉得“让它写还不如我自己写”。但坚持下来之后，我开始摸清它的脾气：在什么场景下可靠，什么场景下需要注意，什么时候需要给足上下文，什么时候需要多轮对话纠偏。这也是我现在反复跟团队强调的——AI Coding不是装个插件就完事，你需要一段时间的磨合，建立自己的信任边界。

第三阶段是“决策主导期”。到这个阶段，AI已经能稳定完成我交托的模块级任务。我开始把更多的精力投向需求源头：这个需求到底要不要做？这个方案选A还是选B？这个复杂度值不值得引入？代码的坏味道在哪个层面需要重构？我的角色重心彻底从“怎么写”转移到了“做什么、为什么做、值不值得做”。

1.3 为什么说这是一次“能力迁移”而不是“能力退化”

这也是我最想澄清的一点。有些人觉得：“你都不写代码了，岂不是能力退化了？”恰恰相反。不写代码的前提是你拥有了更强的代码判断力。就像一份报纸的主编不一定每一个标点都自己敲，但他比任何一个编辑都更知道什么内容有价值、什么表达有风险。

我的能力迁移体现在三个维度。

第一，代码能力从“会写”变成了“会判断”。我能快速识别一段AI生成的代码是否有边界漏洞、是否过度设计、是否符合团队规范、是否埋下了技术债。这种审查能力比手写能力更值钱，因为AI生成的代码天然带有各种隐蔽问题——缺少输入校验、异常处理不完整、状态管理混乱——没有经验的人根本看不出来。

第二，业务能力从“接需求”变成了“解问题”。以前产品经理给我扔一个需求文档，我基本照单全收，最多问两三个细节。现在我会反向提问：这个需求要解决什么根本问题？有没有更简单的实现路径？边界条件是什么？不做会有什么影响？这些问题问出来，需求本身的颗粒度和质量都会显著提升。

第三，沟通能力从“汇报进度”变成了“对齐方案”。以前我跟产品、测试、运营的沟通都是围绕进度和交付，现在的沟通围绕方案和取舍。讨论的话题完全不一样，话语权也不一样了。

2. 我的AI Coding工作流是怎么搭起来的

2.1 工具选型：我最终留下了这三板斧

这半年我试用过相当多的AI Coding工具，最后沉淀下来稳定使用的是三款：GitHub Copilot、Claude和ChatGPT。各有各的用途，分工明确。

GitHub Copilot是我日常写代码时的辅助。在有明确上下文的情况下，它的代码补全准确率很高，尤其擅长生成样板代码、单元测试、简单的CRUD接口。它最大的优势是和IDE配合得最自然，不像聊天工具需要拷贝粘贴，直接在编辑器里内联建议，写起来非常流畅。但它不擅长解决复杂问题——没有足够上下文时，补出来的东西会偏“平均水准”，甚至有时候很蠢。它对代码库的整体理解有限，只能根据当前文件和光标位置做推断。

Claude是我做复杂任务的主力。它的上下文理解能力非常强，能同时处理大段的代码和需求描述，在重构、跨文件修改、方案设计这些任务上表现非常好。尤其是Claude Artifacts功能，能同步生成和展示修改前后的完整代码文件，交互体验非常适合做模块级任务。Claude还有一个优势是它会在回答中解释“为什么”，非常有助于我做方案评审。

ChatGPT我主要用来做一些发散性的技术调研、方案对比和知识梳理。比如我要在两种缓存策略之间做选择，或者想了解某个框架某个版本升级的兼容性问题，跟它聊一圈，基本能把选项全都摆出来。它的长回答能力非常适合做“结构化的知识扫描”。

2.2 工作流的核心：把任务拆到AI能稳定完成的颗粒度

工具选好了，怎么协作才是关键。我总结了AI Coding场景下任务拆解的“三问原则”：这个任务是否独立？上下文是否完整？验收标准是否明确？

很多人在AI Coding上受挫，就是因为拿一个模糊的大任务直接丢给AI——“帮我写一个用户中心”——然后AI输出一堆模板代码，根本没法用。正确做法是把这个大任务拆成若干个独立的、上下文完整的、边界明确的小任务。

举个例子，用户中心这个功能，我会这样拆：

• 第一层：用户注册、登录、个人信息、密码找回四个模块
• 第二层：登录模块再拆为接口设计、数据模型、JWT签发、登录日志四部分
• 第三层：每个部分给出明确的输入、输出、异常条件和编码规范

拆完以后，每个小任务交给AI去实现，它的成功率非常高。而我作为决策者的价值，恰恰体现在这个拆解过程中——我知道怎么拆才是合理的，每个任务的验收标准是什么，模块之间的接口如何定义。这本质上就是一种架构设计能力。

2.3 实操示范：一个登录接口的AI协作全流程

拿一个最典型的任务来说：写一个登录接口。以前我拿到这个需求，会直接开始写，Controller、Service、Mapper、Token工具类，一套流程下来大概一小时。现在我的流程完全变了。

第一步，我先把需求讲清楚，要求AI生成接口设计。我给出的提示词是这样的：“请为我设计一个登录接口的完整技术方案，要求：使用Spring Boot 3 + JWT，提供用户名密码登录和短信验证码登录两种方式，需要包含接口定义、参数校验规则、异常码设计、安全性考虑（防暴力破解、Token有效期与刷新策略），请以表格形式输出对比方案。”

这一步我做的事是“定方向”。AI给了我至少三套方案供我选择，包括纯JWT方案、JWT+Redis黑名单方案、OAuth2方案。我快速评估了一下团队现状——短期内没有第三方登录需求，Redis已有现成基础设施——直接选了JWT+Redis的方案，并补充了一点自定义约束。这就是决策。

第二步，我要求AI按选定方案生成完整代码。我把设计文档、接口契约、数据库表结构都作为上下文丢给它，然后要求它一次性地产出Controller、Service、Mapper、实体类、配置类。这个过程我只需要盯着它的输出质量，随时纠偏。

第三步，也是最关键的一步，做代码审查。我并不是把代码拿过来就信，而是会逐行过一遍。重点检查三件事：输入参数是否做了校验？数据库操作是否有事务边界？Token的生成与校验是否正确？这本来是我最耗时的环节，但现在AI生成的代码基础质量够高，我只需要做关键路径的确认，比手写时代的速度快了不止一倍。

整个流程下来，我实际动手打字不超过50行。但这一小时的产出质量，比过去我手写两小时的质量还要高。

3. 从执行者到决策者：我的决策力是如何练出来的

3.1 决策力不是天生的，是Review练出来的

有人问我：“你哪里来的底气做决策？不怕拍脑袋吗？”说实话，我现在的很多决策判断力，恰恰是AI逼出来的。以前我写代码，写完就完了，很少回头审视“这个方案还有没有更好的”。跟AI协作之后，每天被迫看大量的AI生成代码，看得多了，天然就形成了一套判断标准。

我Review AI代码时会过六道关：边界条件是否完整、异常路径是否覆盖、性能是否可接受、安全是否有漏洞、可维护性是否合格、是否符合团队规范。这六道关每一个都需要调用过去的经验做判断。Review得多了，哪些方案会出问题、哪些设计是合理的，我的直觉体系就建立起来了。

编程很有意思，越是写得多，越容易陷入舒适区；越是被迫看别人（或AI）的代码，越能打开视野。我以前觉得自己代码写得不错，看多了AI的风格之后，反而发现自己以前的很多习惯其实不够好。比如事务的粒度问题、缓存穿透的隐患、状态机的可扩展性——这些问题的敏感度，都是通过大量Review炼出来的。

3.2 决策的执行逻辑：从“最优解”到“够好就行”

除了技术判断力的提升，我觉得还有一个很关键的心态转变——我开始接受“够好就行”的工程哲学。

以前做技术方案，总想找一个最优解。每个模块都想着要做到极致，性能、可扩展性、优雅程度缺一不可。结果就是过度设计泛滥，开发周期拉长。跟AI协作之后，我开始接受一种新的节奏：在决策时，明确“以下哪个方案在当前约束下最合适”，而不是“哪个方案理论最优”。

我把决策的考量维度整理成了一个简单的优先级框架：

第一，业务价值优先。我问自己，这个功能上线后用户能感知到什么？如果感知不到，技术再漂亮，需求本身可能就值得重新审视。

第二，时间成本约束。AI时代做一样东西的技术门槛大幅降低，真正稀缺的是“决定做什么”的能力。一个方案如果实现成本高且收益不明显，直接PASS掉，不要恋战。

第三，技术债可控。选型时我优先考虑团队已有的技术栈和熟悉的模式。引入新框架、新概念，必须有明确的当前收益，否则一律不做。

这三个维度的思考，本质上已经不是一个写代码的执行者的思考方式了，而是一个对结果负责的决策者的思考方式。

3.3 建立“代码判断力”最快的方法：每天做一轮AI代码Review

如果你也想像我一样完成角色转变，我建议你从每天做一轮AI代码Review开始。不需要多庞大的工程，就找一个日常功能——一个接口、一个工具类、一段业务逻辑——让AI生成，然后你自己逐行审查。

我给你一个专用的审查清单，照着用就行：

• 输入是否有校验？恶意输入能否造成注入或越权？
• 数据操作是否有事务？并发场景下是否会出现脏读或覆盖？
• 异常是否被正确捕获和处理？还是偷偷被吞掉了？
• 代码是否过度设计？有没有为了“看起来高级”写的无效抽象？
• 是否有重复逻辑？是否可以抽取为公共方法或配置？
• 性能是否合理？有没有循环内的数据库查询或N+1问题？
• 命名和结构是否清晰？新同学接手能不能看懂？

这七个问题过一遍，你对一段代码的价值判断能力就建立起来了。坚持做两周，你会发现整个人的思维方式已经变了：你看到一段代码，脑子里自动浮现的已经不是“这段代码怎么写的”，而是“这代码值不值得存在、可不可以更好”。

4. 这半年踩过的坑：AI Coding的五个致命误区

4.1 误区一：不加约束就直接开干

我见过太多人用AI Coding的方式是——把需求一句话丢给AI，然后让它输出完整功能。这种用法在简单场景下好像能跑通，但稍微复杂一点就会翻车。问题出在上下文缺失上：AI不知道你的项目结构、既有约定、依赖版本、团队规范，它输出的代码是“平均水准的代码”，而不是“适合你项目的代码”。

我现在的做法是：每次交托任务之前，先把约束喂够。包括技术栈版本、项目目录结构、相关既有代码、编码规范约定、验收标准。这就像给外包公司写需求文档，文档越完善，交付质量越高。不加约束让AI自由发挥，本质上是在浪费它的能力。

提示：喂上下文的时候，宁多勿少。AI编码的上下文窗口很宽，多给出的信息它自动会忽略无关的，但少给的信息它只能靠猜。

4.2 误区二：对AI生成的代码不做严格审查

这个坑最隐蔽。AI生成的代码有一个特点：表面看起来特别“正常”，格式规范、命名合理、结构完整，但仔细看就会发现逻辑上的漏洞——没有判空、没有鉴权、缓存没设过期时间、异常被吞掉、事务边界错位。这些问题的共同点是：它们不会在编译期报错，只会在运行时爆炸。

我曾经让AI写一个文件上传接口。代码非常漂亮，Controller、Service、存储逻辑一气呵成，大小限制、类型校验、异常处理都有。但我Review的时候发现，它把文件保存路径拼接用了字符串直接拼，存在路径穿越风险；同时删除临时文件的逻辑放在finally块里的位置有误，可能导致文件句柄未关闭。这类问题不Review是绝对发现不了的。

所以我给自己立了一个规矩：AI可以写，但我必须审。而且审查标准跟审查同事代码的标准一模一样，绝不双标。你想想，如果同事提交一段你完全没看过的代码合入主干，你敢直接上线吗？对AI更要保持这个警惕。

4.3 误区三：把技术债全甩给AI填坑

这个误区特别容易发生在团队引入AI Coding的初期。大家觉得“有了AI，代码写得快，技术债自然就还得快了”。但实际操作下来恰恰相反——AI确实在填坑，但它同时也在挖新的坑。

AI生成的每一行代码都是基于你给它的上下文推断的，它没有长期记忆，不会像人一样记得“上次这个模块有个历史包袱”。所以它会很自然地用当前的模式重新实现一遍，这个实现和已有的系统往往有风格冲突或逻辑不一致。每生成一个新功能，就可能在系统里多留下一段与既有代码格格不入的“新债务”。

我个人的经验是：重构类的任务，AI能帮上大忙，但前提是我已经画好了目标架构图，知道要往哪个方向重构。AI是执行重构的工人，不是决定重构方向的设计师。

4.4 误区四：忽略Prompt本身的工程质量

AI Coding时代，Prompt就是你跟AI沟通的接口。很多人把Prompt当聊天，想到什么说什么，上下文不完整，约束不明确，期望不清晰。AI输出的东西自然基本都是“另一种风格的废话”。

打好一个任务型Prompt，我建议遵循四个步骤：角色设定、背景信息、任务描述、验收标准。角色设定告诉AI它应该以什么身份思考（是资深Java后端，还是运维专家）；背景信息提供必要的上下文（项目类型、技术栈、业务约束）；任务描述明确要求AI做什么（生成代码、设计接口、还是找Bug）；验收标准告诉它什么算完成（代码可编译、覆盖边界、符合规范）。

我还发现一个通用技巧：让AI先给出方案再写代码，效果比直接让它写代码好很多。因为当AI先输出方案时，它会强迫自己做一次思考，这个思考过程会让最终代码的质量明显上升。哪怕它的方案跟我预想的不同，我也能提前介入纠正方向，而不是等代码写完才发现方向错了。

4.5 误区五：以为AI Coding工程师就是人工智能工程师

这个要单独拿出来说说，因为它是这段时间的热搜词之一，也是很多人的困惑点。我从自己半年的实践经验来看，AI Coding工程师跟人工智能工程师是两码事。

人工智能工程师的核心工作是训练和优化模型，涉及机器学习、深度学习、数据处理、模型调优，工作对象是“模型本身”。AI Coding工程师的核心工作是利用AI工具来提升软件开发效率和质量，工作对象是“软件交付”。两者对技术栈的要求、工作内容、产出物完全不同。

但这并不代表AI Coding工程师就“低人一等”。恰恰相反，它能落地，能直接产生业务价值。我的判断是：未来2-3年会有大量AI Coding工程师岗位出现，它们不是人工智能工程师的替代品，而是一种新的复合型岗位，核心要求是“懂业务 + 懂架构 + 懂AI工具的边界”。某大厂近期也在招聘里专门划分出“AI Coding工程师”方向，要求都是五年以上研发经验、精通具体语言生态、同时对AI工具链有深入实践。这说明行业已经逐渐认可这是个独立的工种，而不是一个噱头。

我自己对这个问题的回答是：AI Coding工程师属不属于人工智能工程师不重要，重要的是你的能力结构值不值钱。如果你的价值体现在“会写代码”，那确实会被AI冲击；如果体现在“会用AI做好软件”，那这个岗位才刚起步，天花板还很高。

5. 给想转型的开发者的实操建议

5.1 别急着换工具，先换工作方式

看了很多网上的“AirCoding工具测评”，我发现一个普遍误区：大家总以为搞AI Coding的第一步是选一个好工具，其实不是。第一步应该是改变自己的工作方式——把一个任务拆成“设计 → 实现 → 审查”三个环节，并强制自己在不同环节扮演不同角色。

设计阶段，你来主导，AI做顾问；实现阶段，AI主导，你定边界；审查阶段，你主导，AI做辅助。这个流程走顺了，用什么工具都能出效果；流程走不顺，换再多工具也是白搭。

5.2 搭建一个属于自己的“提示词库”

打了半年交道，我最大的心得之一是：和AI协作，靠谱的产出80%来自靠谱的提示词。这些靠谱的提示词是可以沉淀的，不要每次都即兴发挥。

我会把自己常用的、效果好的提示词分门别类保存下来，有些是按任务类型分的（写接口、重构、写测试、查Bug、生成文档），有些是按行业场景分的（电商订单流程、内容社区、支付对账）。每段提示词里都有固定的框架：角色、背景、约束、验收标准。用的时候复制下来，填充具体的业务描述即可。

给新手一个建议：如果你刚开始用AI Coding工具，可以先从模仿别人的优秀Prompt开始。注意不是照搬，而是理解它为什么这样写，然后改造出自己的版本。用一段时间之后，你会形成自己的风格和套路，到那时候，你就是真正的AI Coding老手了。

5.3 保持代码基本功：决策者也要能随时下场写代码

最后一点踩过坑之后才悟出来的经验：千万不能因为AI写得好，就荒废了自己的基本功。

我见过有些同学用AI Coding一段时间后手生得厉害，审代码审不出问题，谈方案谈不出深度。这就是“长期不下场”的后果。作为决策者，如果你对代码细节的敏感度消失了，你的决策质量就一定会下降——你会很容易被AI生成的漂亮代码表面迷惑，完全看不到背后的坑。

所以我的要求是：每周至少手写两到三个有难度的函数或模块，保持手感；每个月选一个核心模块，手动走一遍完整的实现和重构流程。手写不是因为AI做不到，而是为了让自己保持对代码的敏锐度。一个对实现没有切身感知的决策者，做出的决策大概率是悬浮的、不落地的。

这半年走下来，我最深刻的感受是：AI Coding不是来抢饭碗的，它是来把人推到更高一层去思考问题的。那些只能写写增删改查、跟着需求文档走的人，确实会被替代；但那些能定义什么是“对的代码”、什么是“值得做的需求”的人，在手握AI这个超级执行者之后，价值只会越来越大。这两年，我建议所有写代码的朋友，别只盯着“怎么写得快”，多想想“该做什么”——这才是在AI时代真正值钱的能力。