我从去年秋招入职到现在一直在琢磨一件事AI 到底该怎么真正融入日常开发而不是偶尔拿来补个注释、写个测试就算完事。如果你也是刚入行不久手头正好有一堆 AI 工具却总感觉它们“有用但不够关键”那这篇东西应该能给你一些参考。我把自己这一年在厂里摸出来的 AI Coding 工作流完整梳理了一遍从需求分析到代码评审每个环节怎么接、怎么用、怎么防坑都写清楚。内容不追求炫技主打一个“拿来就能用”。这篇文章适合刚工作的校招生、独立开发者也适合你参考前提是你不想让 AI 只当一个“高级补全插件”而是想让它真正进入你的开发管线。我会先讲整体思路再按开发阶段逐段拆解最后把踩过的坑和排查策略一并奉上。1. 内容整体设计与思路拆解1.1 为什么校招生的第一年最适合搭建 AI 工作流刚进大厂的前半年每个人都有个共同困境CRUD 写得飞快但业务上下文几乎为零代码规范要靠导师逐行挑遇到陌生系统时翻代码翻到怀疑人生。这个阶段其实恰恰是搭建 AI 工作流的最好时机因为你的开发任务边界清晰、规模适中、反馈链路短AI 的错误也有导师兜底不会造成严重事故。很多有经验的工程师反而很难把 AI 接入完整流程因为他们过去十年形成的肌肉记忆太牢固遇到问题第一反应是去翻文档而不是去问 AI。但校招生没有这种路径依赖上手就是 AI 原生工作方式。我见过一些组里的前辈用 AI 只用来写正则和改 JSON 格式但校招生反而在需求澄清、代码解释、测试生成、故障排查这些环节全面铺开提升是全方位的。核心思路很简单把 AI 不是当成一个工具而是当成开发流程里的一个“角色”。它负责信息收集、初步方案、重复劳动、代码预审你负责决策、审查、把控质量和最终交付。人和 AI 各管一段而不是人写一段 AI 改一段。1.2 工作流的核心四层结构上下文、提示词、反馈回路、工具链我给自己定义的四层结构到现在还在用可以概括成一张表层级作用对应环节上下文层把业务背景、代码仓库、接口文档、技术规范喂给 AI需求分析、代码解释提示词层用结构化 Prompt 控制 AI 输出格式和质量方案设计、代码生成反馈回路层通过单测、静态检查、评审意见反向修正 AI 输出编码、测试、评审工具链层把 AI 接入 IDE、终端、CI 流程形成自动化闭环全流程我特别想强调上下文层。大多数人说“AI 写的代码不靠谱”问题不在模型在于你只丢给它一个孤立需求。它不知道你项目的 Maven 坐标不知道你们的异常处理规范不知道数据库里这张表到底有没有唯一索引。它写出来的一定是“通用正确”的代码而不是“你的项目里正确”的代码。我现在的做法是把常用上下文沉淀成固定片段。比如团队代码规范摘要、典型接口的入参出参示例、常见表结构、错误码定义。每次让 AI 干活之前先把相关片段贴进对话里。看起来每次多花了两分钟但省去的是改代码来回折腾的二十分钟。1.3 哪些环节应该接入 AI哪些环节应该坚守人工我踩过最大的坑是过度信任 AI尤其是在方案设计这个环节。AI 能从网上学来一堆“流行架构”但它不知道你们部门的 KPI、不知道 infra 团队能提供什么能力、不知道隔壁组正在重构服务。所以方案设计我从来不让 AI 出完整方案只让它列可选项和权衡点。真正适合 AI 全面接管的是这几类信息检索和代码解释、样本代码与脚手架生成、单元测试和边界条件补充、日志和报错信息解读、重复性重构。这些任务有一个共同特点有清晰的对错标准或模板不需要大量业务判断。需要人工深度参与的环节是架构选型、性能优化策略、线上问题定级、有安全影响的代码审查。不是说 AI 不能帮忙而是最终决策必须有人的判断兜底。我对自己的要求是AI 可以快速给出十个方案但我必须理解每个方案为什么行得通、为什么行不通。2. 开发全流程中的 AI 接入实操要点2.1 需求分析阶段用 AI 拆分“人话需求”和“技术任务”需求阶段最容易犯的错是拿到 PRD 就开始写代码写到一半发现字段含义理解偏了。我现在拿到需求后的第一件事是把 PRD 丢到一个固定的“需求拆解 Prompt”里让它按这个格式输出业务目标、用户场景、涉及系统、数据字段、接口变更、异常边界。AI 不需要懂业务才能做这件事它只需要做一件事把 PRD 里有歧义的点全部标出来。这一步的价值不是让 AI 替我做需求分析而是逼我把模糊问题前置。举个例子前阵子一个需求里写“用户可查看历史订单”AI 会追问历史订单的时间范围是多久分页大小多少是否需要筛选状态。这些问题我平时可能写到一半才会想起来现在通过 AI 的提问清单在需求评审前就主动对齐了。我还发现一个特别好用的策略把 AI 当成一个“杠精”来用。需求评审前我会专门让 AI 用产品经理的口吻刁难这个需求列出十个“你为什么做这个功能”的问题。这不是找茬而是在开发前把所有不确定性消灭掉。毕竟代码写错了可以改需求理解错了返工成本是最高的。2.2 技术设计阶段让 AI 输出方案选项而不是最终结论进入设计阶段后我的核心原则是“AI 列选项我来做减法”。具体操作是我会给 AI 一段精简需求描述、系统现状、约束条件让它输出 3 个候选技术方案每个方案必须包含“优点、缺点、演进成本、不适用场景”四个维度。我要求输出四个维度是有原因的。很多 AI 只会吹捧自己给出的方案你要是不加约束它会把最简单的单体方案包装成“高扩展性架构”实际上就是套话。加了“不适用场景”这个约束后AI 会被迫思考反面因素输出质量明显提升。等 AI 列出选项后我会结合三样东西做决策团队的维护能力、现有系统的技术栈匹配度、上一个项目踩过的坑。这几样东西 AI 都不知道所以它不能替我做决定。但它能在决策后帮一个很大的忙就是“反向审查”我的选择我把选定的方案和理由发给它让它找出方案里的潜在风险点。这一步对校招生极其有用因为你的经验不足以预见一些问题AI 虽然不能完全补位但至少能帮你多几个思考维度。2.3 编码阶段从“让 AI 写函数”升级为“和 AI 结对编程”编码阶段很多人的用法是让 AI 直接写一个函数或一个类然后复制进工程。这当然能用但距离真正的“结对编程”还差很远。我现在总结出来的更稳定流程是三步走。第一步先写接口定义和核心数据结构。我从来不让 AI 自由发挥类结构而是抢先定义好方法签名、入参出参、异常声明。这一步相当于给 AI 画好边界。我从无数实践中得到一个教训你不做这道题AI 就会替你做然后大概率做出一个你不在意的设计后面改起来极为痛苦。第二步让 AI 在边界内补全实现。我给它的提示词模板大概是这样的你是本项目团队的一名高级开发工程师项目使用 Java 17 Spring Boot 3.x请实现下面的接口约束条件是不能改变签名、不能引入新的外部依赖、需要补充完整的参数校验和日志。最后记得说明你的实现思路和潜在风险。这个模板里每一项约束都在消除 AI 的自由发挥空间。第三步——我发现校招生特别容易漏掉——是 AI 写完代码后立刻让它生成测试。不是简单的“给这个类写测试”而是“根据这个接口的入参边界列出 10 个测试用例包括正常流、异常流、边界值然后逐个用 Mock 的方式实现”。这样做的好处是强制 AI 重新审视自己写的代码很多边缘问题在生成测试时会暴露出来。除了编码本身代码解释也是一个被低估的场景。入职初期接手老项目我会直接让 AI 按“数据流向”“状态流转”“异常处理链”三个视角去解读源码。这不是看个不停是让它先给你讲一遍你再进代码里验证读代码效率能提升一倍。2.4 测试阶段AI 生成测试用例的思路与边界大厂的研发流程里单测覆盖率是有红线的。以前写测试最痛苦的补充分支覆盖打到哪个分支少了会在覆盖率卡点被驳回。而 AI 生成测试用例的水平我认为已经很能打了尤其是基础的 Context 构建、Mock 行为和断言部分。它的潜力不只是体现在“写大量测试代码”上更多是体现在“测试思路补全”上。我的做法是写完一个实现后先自己列 5 个主路径的用例然后用 AI 生成反例空指针、参数越界、并发冲突、超时场景、极端值。这些反例是我脑子里下意识会回避的部分AI 没有心理负担反而更愿意挑战代码。不过注意一个边界凡是涉及事务回滚、资金计算、权限校验的测试我不会完全信任 AI 生成的断言。每次都必须人工核对预期值。这些场景一旦断言写错测试就是“假绿”比你测试失败更可怕因为你会误以为功能是好的。2.5 代码评审阶段把 AI 当成“第三个 Reviewer”代码评审是大厂工程文化里最重的环节。我自己的 MR 在提交给同事之前一定会先用 AI 做一轮预审。因为很多时候同事指出的问题不是逻辑错误而是规范性问题命名不清晰、日志级别不统一、魔法数字没有定义成常量、异常被吞掉。我的预审提示词会附上团队的编码规范摘要然后要求 AI 按三个级别输出问题P0 是逻辑正确性问题P1 是潜在性能和并发问题P2 是规范与可维护性问题。输出时每条问题必须带上代码行号和修改建议方便我对照修改。这个环节最需要注意的一点AI 也会误报。我用它预审时它经常提出一些“其实不改也完全没问题”的建议比如“建议把 if 换成 switch”这种无意义优化。我的原则是P0 和 P1 逐条人工复核确有问题才改P2 选择性采纳不为了消除 AI 报的问题而改动代码。代码评审最终是人的决策AI 的价值在于把明显的问题用低成本的代价先暴露出来。2.6 部署排障阶段AI 在定位故障上的效率提升部署和排障通常是校招生最慌的环节。因为系统一挂你连日志在哪找都不一定清楚。我现在的做法是遇到一个陌生报错先把堆栈和上下文信息丢给 AI问三件事这个报错最可能的三个根因是什么、每个根因对应还需要查哪些信息、如果是数据库或网络相关的报错有没有常用的命令可以进一步确认。这不是让 AI 背答案而是让 AI 帮我建立排查路径。以前你拿到一个 OOM 日志只能跑去问导师现在 AI 会告诉你先查堆转储文件定位大对象再结合 GC 日志看是哪个区域满了。这个排查路径的价值远大于 AI 直接告诉你答案。安全性提醒线上操作必须谨慎。AI 给出来的 Linux 命令、数据库变更 SQL、配置修改在非生产环境先试一遍而且高危操作必须有同事确认。这个不是我保守是我确实见过有人照着 AI 给的一条命令在生产库上跑了 DELETE 操作的人脸上那种表情我这辈子忘不了。3. 我的完整工作流落地实录与工具选型3.1 整套工作流实际跑起来的“路线图”下面这条路线图是我现在日常开发里实际在用的不是纸上谈兵。我大概描述一下每个环节里 AI 介入的位置和形态需求评审前用 AI 做 PRD 疑问清单输出内容作为评审输入设计阶段用 AI 生成候选方案对比和“选型风险检查”编码阶段用辅助 AI 编程工具在 IDE 里完成代码生成与解释测试阶段用 AI 批量生成单测代码与边界用例MR 提交前把 AI 预审结果和人工自查结果合在一起检查线上故障时用 AI 做日志摘要和排查建议每个环节的 AI 输出我都要求“留痕”。不是说要写什么文档而是把关键 Prompt 和 AI 输出贴在需求文档的评论里这样导师和同事能追溯你的决策依据。这个习惯在校招期间尤其加分因为大家会看到一个“懂方法”的新人而不是只会点鼠标的工具人。3.2 我日常工作流里的四件套搭配和运行逻辑工具层面我整理了一个四件套覆盖了完整链路。首先是用 AI IDE 插件。我选了一个支持本地代码索引和多文件上下文的插件用起来顺手。它的关键价值不在于自动补全那点效率而在于“整个仓库的语义检索”。让它解释一个方法的调用链比我自己在 IDE 里跳来跳去快非常多。其次是命令行助手。终端操作和 Git 操作我经常用它帮我解释一段晦涩的构建报错把一长串的 git 命令整理成可执行脚本或者直接帮我写一个快速处理日志的 awk 命令。这类一次性命令不值得背但每次查又浪费时间交给 AI 刚刚好。第三是个文档沉淀工具我把日常积累的上下文片段存在里面按月维护。你可能会觉得这是负担但实测下来你只要看一个东西当你需要向 AI 描述项目背景的时候如果不假思索就能粘贴出来说明你的上下文沉淀已经到位了。第四是项目里的自动化工作流。营地里经常有重复性的环境准备任务比如初始化配置、生成代码骨架我会把一些常用的操作固化成半自动脚本让 AI 在里面当“执行者”。减少人为失误的同时也把更多时间留给真正需要动脑的设计和排查。3.3 实测数据接入工作流前后的效率账和心理账我做了一组粗糙但真实的对比测试。同样一个中等规模的 CRUD 需求包含两个表、一个导出功能、五个接口。不接入 AI 工作流时从读代码到写完自测大概需要两天半接入工作流后压缩到一个半工作日。这个提升不是因为我代码写得快而在于我把阅读理解的时间大幅压缩了。还有一个更直观的对比过去接到一个陌生模块的维护需求我要花至少半天去读代码、梳理调用链、找到改动点。现在用 AI 做代码解释和流程梳理两个小时就能完成一轮比较完整的走读。省下来的时间可以提前进入编码和自测环节这个积累在绩效评价时是能看到的。心理账同样重要。说实话校招第一年最容易崩溃的时刻不是业务难而是“不知道去哪查、问同事又不好意思”。有 AI 在中间做缓冲后很多小问题我能在不打扰别人的前提下自己搞定。说句私心话这种“自主解决”的正反馈帮我顺利过了试用期也让我更愿意继续完善自己的工作流。3.4 我自己常用的几个提示词模板直接复制可用分享几个我磨合了很久的提示词模板不保证适用所有场景但值得一试。第一个是“需求拆解模板”你是一名资深业务分析师请根据下面的需求描述输出业务目标、用户场景、涉及系统、数据字段、接口变更、异常边界针对信息不明确的地方用问题列表逐条追问。第二个是“代码审查模板”你是本项目团队的一名高级代码审查者请审查以下代码。按 P0 逻辑正确性、P1 潜在性能与并发问题、P2 规范与可维护性三级输出问题每条问题给出代码行号、原因说明、修改建议没有问题的维度请明确写“无”。第三个是“单测生成模板”请根据下面的接口实现生成单元测试用例。要求覆盖正常流、异常流、边界值、空值场景使用 Mock 隔离外部依赖每个用例注明场景名称和预期结果先列出用例清单再逐段给出代码。用好模板的关键是你要理解每个约束背后的意图。比如“每项输出必须注明实现思路”不是为了看它废话是让 AI 被迫解释自己的代码这样你能快速判断它是不是在瞎编。4. 常见问题与排查技巧实录4.1 AI 一本正经地“胡说八道”怎么发现并纠正所有用 AI 写代码的人都会遇到幻觉问题是怎么用低成本发现。我现在的检查习惯是拿到 AI 输出后先看它的 API 调用部分再去仓库里实际查一下那个方法存不存在、参数对不对。这个动作只需要两分钟能把幻觉控制在很小的范围内。第二个手段是强制 AI 给依据。我写提示词时如果涉及项目内的类名、配置项、依赖坐标我都会加一句“如果引用了现有代码请标注出处”。要求 AI 在输出带上文件路径很多幻觉代码会在这个环节自己露出马脚因为它根本给不出来源。第三个手段是实战验证AI 生成的代码如果不确定我不会直接跑完整逻辑而是先写一个最小验证用例。它能编译能过测试才说明这段代码在这个工程里是成立的。这也是为什么我一直强调测试要人机协作因为 AI 写的代码如果没有快速验证通道风险真的不好控制。4.2 AI 生成的代码风格和团队规范冲突今年我遇到过一个特别典型的问题AI 生成的代码功能正确但代码风格和团队规范差很多。比如团队要求所有数据库访问必须走统一的 DAO 封装AI 却直接写了一个 JdbcTemplate 操作团队要求接口返回统一包装对象AI 有时候会返回裸数据。这种问题单纯靠“在提示词里说一句遵守规范”是解决不了多少的。我的办法是把团队规范摘要直接做成上下文片段在需要 AI 生成代码时固定拼在提示词前面。这个摘要不需要很长挑最关键的十几条就行了比如分层约束、禁止在 Controller 里写业务逻辑、异常必须抛出业务异常码、日志必须包含 traceId。实测下来规范类问题的出现频率大幅下降。当然也有一类冲突没法靠提示词解决架构层面约束。比如团队约定用事件驱动但 AI 不理解现有消息 Topic 体系仍然生成同步调用代码。这种问题我会直接手动改掉然后把这个场景加入上下文片段里避免下次再犯。4.3 上下文太长被“截断”关键信息丢了怎么办用 AI 处理大型代码库时最烦的问题就是上下文长度不够等你在对话里把大量代码贴进去它反而把最开始的业务目标给忘了。我现在处理长上下文有三条具体策略你可以直接参考。第一把任务化整为零。我不会让 AI 一口气分析一个完整流程而是拆成输入阶段、处理阶段、输出阶段每个阶段单独对话。这样每个对话的上下文都很精简AI 不容易迷路。第二用“摘要接力”的方式先让 AI 总结一段代码的行为用一小段自然语言描述它的输入输出然后把摘要作为下一轮对话的输入。这个方法适合跨文件分析效率高且不丢关键信息。第三把核心信息前置。我会把业务目标、关键约束、不可变更项放在提示词的开头代码放在后面。因为 AI 对上下文头部的注意力通常更强这样即使后面内容被截断它也不会忘记最重要的要求。别小看这个顺序调整它在我实测中对输出质量的改善非常明显。4.4 代码评审中 AI 和人工的分工到底怎么划这是团队里经常聊的一个问题既然 AI 都能预审代码了人工评审还有意义吗我的答案是AI 的评审价值集中在规范性、常见缺陷和边界提示人工评审的价值在于业务正确性和长期可维护性。两者不是替代关系而是接力关系。我自己在 MR 里会把 AI 预审结果作为附件并标注哪些问题我已经改了哪些问题我认为在现有场景下不需处理。这样人工评审的人可以快速把注意力放到真正重要的部分。实际效果是同事给我的评审意见从一堆“命名可以更好”变成“这个缓存策略在这种场景下可能有问题值得商榷”沟通质量提升了一个量级。需要注意不要让 AI 预审变成流程负担。如果它每次都给你报几十条无效建议你会本能地忽略它这个工具就废了。所以我会花时间调教它哪些建议总是误报就直接写进负向提示词里“不要提以下类型的建议”。这个调校动作能让 AI 越用越顺手而不是越用越烦。4.5 一句话避坑清单如果这一整篇你只想记几句话那我贴在下面永远不要让 AI 在没有项目上下文的情况下直接生成核心业务代码。任何 AI 给的命令和 SQL先在不重要环境验证高危操作必须人肉复核。接口签名一定要人为先定不要交给 AI 自由发挥。生成代码后至少追问一组边界条件和异常场景的测试用例。提示词里明确“禁用项”比罗列一堆“应该做”更能控制 AI 输出质量。依赖名称、配置项、类名必须让 AI 给出出处避免幻觉引用。人工评审永远保留对 P0 和架构问题的最终决策权。5. 给同龄人的一些进阶思考5.1 从“很会用工具”到“会设计流水线”我知道很多人关注 AI Coding最初的动机都是“提升编码速度”这是个很真实也很合理的目标。但我想说的是如果你校招进了互联网公司真正拉开差距的不是敲键盘速度而是把工具落成流程的能力。三五个 AI 技巧没用一整套工作流才有价值。所谓“设计流水线”不是写一堆自动化脚本而是你在每个环节都清楚三个问题AI 在这个环节输出的产物是什么、我判断它的标准是什么、如果它错了怎么回退和修复。这三个问题能回答清楚AI 就不再是分散的“点”而是你开发流程里的稳定“链”。我刚入职时带我的师兄说过一句话工具不重要你用工具的思维才重要。当时很不服气觉得他不懂新工具现在回头看他说的其实是大多数人在第一年犯的错误——学了一堆快捷键却没有把工具沉淀到自己的做事流程里。5.2 未来半年我打算继续完善的方向最后说说我自己接下来的打算也算给你一个扩展的思路。我目前在折腾的是两件事一是把常用的 AI 工作流沉淀成团队可复用的模板让新人来了不用自己从零摸索二是尝试把 AI 从“被动响应”升级到“主动提醒”比如在本地提交代码时自动检查是否漏了单测或者在部署前自动做配置比对。我没有把它当成一个“项目”去做而是当成每天工作方式的自然演化。因为 AI 这个领域变化太快了你重金打磨的一个流程可能三个月后就有更好的替代品。与其追求“完美方案”不如保持“低成本试错高频迭代”的状态更可持续。这套工作流说到底就一句话让 AI 处理确定性高的劳动把人的精力留给判断和创新。我这一年最大的体会是AI 没有让我失业它让我有更多时间去思考真正值钱的问题也让我这种没经验的新人能站到更高的起点上开始自己的技术生涯。 
长河君 · 2026/10/8 3:50:05 · 阅读 1.2k AI Coding工作流实战：从需求到评审的完整接入指南
我从去年秋招入职到现在一直在琢磨一件事AI 到底该怎么真正融入日常开发而不是偶尔拿来补个注释、写个测试就算完事。如果你也是刚入行不久手头正好有一堆 AI 工具却总感觉它们“有用但不够关键”那这篇东西应该能给你一些参考。我把自己这一年在厂里摸出来的 AI Coding 工作流完整梳理了一遍从需求分析到代码评审每个环节怎么接、怎么用、怎么防坑都写清楚。内容不追求炫技主打一个“拿来就能用”。这篇文章适合刚工作的校招生、独立开发者也适合你参考前提是你不想让 AI 只当一个“高级补全插件”而是想让它真正进入你的开发管线。我会先讲整体思路再按开发阶段逐段拆解最后把踩过的坑和排查策略一并奉上。1. 内容整体设计与思路拆解1.1 为什么校招生的第一年最适合搭建 AI 工作流刚进大厂的前半年每个人都有个共同困境CRUD 写得飞快但业务上下文几乎为零代码规范要靠导师逐行挑遇到陌生系统时翻代码翻到怀疑人生。这个阶段其实恰恰是搭建 AI 工作流的最好时机因为你的开发任务边界清晰、规模适中、反馈链路短AI 的错误也有导师兜底不会造成严重事故。很多有经验的工程师反而很难把 AI 接入完整流程因为他们过去十年形成的肌肉记忆太牢固遇到问题第一反应是去翻文档而不是去问 AI。但校招生没有这种路径依赖上手就是 AI 原生工作方式。我见过一些组里的前辈用 AI 只用来写正则和改 JSON 格式但校招生反而在需求澄清、代码解释、测试生成、故障排查这些环节全面铺开提升是全方位的。核心思路很简单把 AI 不是当成一个工具而是当成开发流程里的一个“角色”。它负责信息收集、初步方案、重复劳动、代码预审你负责决策、审查、把控质量和最终交付。人和 AI 各管一段而不是人写一段 AI 改一段。1.2 工作流的核心四层结构上下文、提示词、反馈回路、工具链我给自己定义的四层结构到现在还在用可以概括成一张表层级作用对应环节上下文层把业务背景、代码仓库、接口文档、技术规范喂给 AI需求分析、代码解释提示词层用结构化 Prompt 控制 AI 输出格式和质量方案设计、代码生成反馈回路层通过单测、静态检查、评审意见反向修正 AI 输出编码、测试、评审工具链层把 AI 接入 IDE、终端、CI 流程形成自动化闭环全流程我特别想强调上下文层。大多数人说“AI 写的代码不靠谱”问题不在模型在于你只丢给它一个孤立需求。它不知道你项目的 Maven 坐标不知道你们的异常处理规范不知道数据库里这张表到底有没有唯一索引。它写出来的一定是“通用正确”的代码而不是“你的项目里正确”的代码。我现在的做法是把常用上下文沉淀成固定片段。比如团队代码规范摘要、典型接口的入参出参示例、常见表结构、错误码定义。每次让 AI 干活之前先把相关片段贴进对话里。看起来每次多花了两分钟但省去的是改代码来回折腾的二十分钟。1.3 哪些环节应该接入 AI哪些环节应该坚守人工我踩过最大的坑是过度信任 AI尤其是在方案设计这个环节。AI 能从网上学来一堆“流行架构”但它不知道你们部门的 KPI、不知道 infra 团队能提供什么能力、不知道隔壁组正在重构服务。所以方案设计我从来不让 AI 出完整方案只让它列可选项和权衡点。真正适合 AI 全面接管的是这几类信息检索和代码解释、样本代码与脚手架生成、单元测试和边界条件补充、日志和报错信息解读、重复性重构。这些任务有一个共同特点有清晰的对错标准或模板不需要大量业务判断。需要人工深度参与的环节是架构选型、性能优化策略、线上问题定级、有安全影响的代码审查。不是说 AI 不能帮忙而是最终决策必须有人的判断兜底。我对自己的要求是AI 可以快速给出十个方案但我必须理解每个方案为什么行得通、为什么行不通。2. 开发全流程中的 AI 接入实操要点2.1 需求分析阶段用 AI 拆分“人话需求”和“技术任务”需求阶段最容易犯的错是拿到 PRD 就开始写代码写到一半发现字段含义理解偏了。我现在拿到需求后的第一件事是把 PRD 丢到一个固定的“需求拆解 Prompt”里让它按这个格式输出业务目标、用户场景、涉及系统、数据字段、接口变更、异常边界。AI 不需要懂业务才能做这件事它只需要做一件事把 PRD 里有歧义的点全部标出来。这一步的价值不是让 AI 替我做需求分析而是逼我把模糊问题前置。举个例子前阵子一个需求里写“用户可查看历史订单”AI 会追问历史订单的时间范围是多久分页大小多少是否需要筛选状态。这些问题我平时可能写到一半才会想起来现在通过 AI 的提问清单在需求评审前就主动对齐了。我还发现一个特别好用的策略把 AI 当成一个“杠精”来用。需求评审前我会专门让 AI 用产品经理的口吻刁难这个需求列出十个“你为什么做这个功能”的问题。这不是找茬而是在开发前把所有不确定性消灭掉。毕竟代码写错了可以改需求理解错了返工成本是最高的。2.2 技术设计阶段让 AI 输出方案选项而不是最终结论进入设计阶段后我的核心原则是“AI 列选项我来做减法”。具体操作是我会给 AI 一段精简需求描述、系统现状、约束条件让它输出 3 个候选技术方案每个方案必须包含“优点、缺点、演进成本、不适用场景”四个维度。我要求输出四个维度是有原因的。很多 AI 只会吹捧自己给出的方案你要是不加约束它会把最简单的单体方案包装成“高扩展性架构”实际上就是套话。加了“不适用场景”这个约束后AI 会被迫思考反面因素输出质量明显提升。等 AI 列出选项后我会结合三样东西做决策团队的维护能力、现有系统的技术栈匹配度、上一个项目踩过的坑。这几样东西 AI 都不知道所以它不能替我做决定。但它能在决策后帮一个很大的忙就是“反向审查”我的选择我把选定的方案和理由发给它让它找出方案里的潜在风险点。这一步对校招生极其有用因为你的经验不足以预见一些问题AI 虽然不能完全补位但至少能帮你多几个思考维度。2.3 编码阶段从“让 AI 写函数”升级为“和 AI 结对编程”编码阶段很多人的用法是让 AI 直接写一个函数或一个类然后复制进工程。这当然能用但距离真正的“结对编程”还差很远。我现在总结出来的更稳定流程是三步走。第一步先写接口定义和核心数据结构。我从来不让 AI 自由发挥类结构而是抢先定义好方法签名、入参出参、异常声明。这一步相当于给 AI 画好边界。我从无数实践中得到一个教训你不做这道题AI 就会替你做然后大概率做出一个你不在意的设计后面改起来极为痛苦。第二步让 AI 在边界内补全实现。我给它的提示词模板大概是这样的你是本项目团队的一名高级开发工程师项目使用 Java 17 Spring Boot 3.x请实现下面的接口约束条件是不能改变签名、不能引入新的外部依赖、需要补充完整的参数校验和日志。最后记得说明你的实现思路和潜在风险。这个模板里每一项约束都在消除 AI 的自由发挥空间。第三步——我发现校招生特别容易漏掉——是 AI 写完代码后立刻让它生成测试。不是简单的“给这个类写测试”而是“根据这个接口的入参边界列出 10 个测试用例包括正常流、异常流、边界值然后逐个用 Mock 的方式实现”。这样做的好处是强制 AI 重新审视自己写的代码很多边缘问题在生成测试时会暴露出来。除了编码本身代码解释也是一个被低估的场景。入职初期接手老项目我会直接让 AI 按“数据流向”“状态流转”“异常处理链”三个视角去解读源码。这不是看个不停是让它先给你讲一遍你再进代码里验证读代码效率能提升一倍。2.4 测试阶段AI 生成测试用例的思路与边界大厂的研发流程里单测覆盖率是有红线的。以前写测试最痛苦的补充分支覆盖打到哪个分支少了会在覆盖率卡点被驳回。而 AI 生成测试用例的水平我认为已经很能打了尤其是基础的 Context 构建、Mock 行为和断言部分。它的潜力不只是体现在“写大量测试代码”上更多是体现在“测试思路补全”上。我的做法是写完一个实现后先自己列 5 个主路径的用例然后用 AI 生成反例空指针、参数越界、并发冲突、超时场景、极端值。这些反例是我脑子里下意识会回避的部分AI 没有心理负担反而更愿意挑战代码。不过注意一个边界凡是涉及事务回滚、资金计算、权限校验的测试我不会完全信任 AI 生成的断言。每次都必须人工核对预期值。这些场景一旦断言写错测试就是“假绿”比你测试失败更可怕因为你会误以为功能是好的。2.5 代码评审阶段把 AI 当成“第三个 Reviewer”代码评审是大厂工程文化里最重的环节。我自己的 MR 在提交给同事之前一定会先用 AI 做一轮预审。因为很多时候同事指出的问题不是逻辑错误而是规范性问题命名不清晰、日志级别不统一、魔法数字没有定义成常量、异常被吞掉。我的预审提示词会附上团队的编码规范摘要然后要求 AI 按三个级别输出问题P0 是逻辑正确性问题P1 是潜在性能和并发问题P2 是规范与可维护性问题。输出时每条问题必须带上代码行号和修改建议方便我对照修改。这个环节最需要注意的一点AI 也会误报。我用它预审时它经常提出一些“其实不改也完全没问题”的建议比如“建议把 if 换成 switch”这种无意义优化。我的原则是P0 和 P1 逐条人工复核确有问题才改P2 选择性采纳不为了消除 AI 报的问题而改动代码。代码评审最终是人的决策AI 的价值在于把明显的问题用低成本的代价先暴露出来。2.6 部署排障阶段AI 在定位故障上的效率提升部署和排障通常是校招生最慌的环节。因为系统一挂你连日志在哪找都不一定清楚。我现在的做法是遇到一个陌生报错先把堆栈和上下文信息丢给 AI问三件事这个报错最可能的三个根因是什么、每个根因对应还需要查哪些信息、如果是数据库或网络相关的报错有没有常用的命令可以进一步确认。这不是让 AI 背答案而是让 AI 帮我建立排查路径。以前你拿到一个 OOM 日志只能跑去问导师现在 AI 会告诉你先查堆转储文件定位大对象再结合 GC 日志看是哪个区域满了。这个排查路径的价值远大于 AI 直接告诉你答案。安全性提醒线上操作必须谨慎。AI 给出来的 Linux 命令、数据库变更 SQL、配置修改在非生产环境先试一遍而且高危操作必须有同事确认。这个不是我保守是我确实见过有人照着 AI 给的一条命令在生产库上跑了 DELETE 操作的人脸上那种表情我这辈子忘不了。3. 我的完整工作流落地实录与工具选型3.1 整套工作流实际跑起来的“路线图”下面这条路线图是我现在日常开发里实际在用的不是纸上谈兵。我大概描述一下每个环节里 AI 介入的位置和形态需求评审前用 AI 做 PRD 疑问清单输出内容作为评审输入设计阶段用 AI 生成候选方案对比和“选型风险检查”编码阶段用辅助 AI 编程工具在 IDE 里完成代码生成与解释测试阶段用 AI 批量生成单测代码与边界用例MR 提交前把 AI 预审结果和人工自查结果合在一起检查线上故障时用 AI 做日志摘要和排查建议每个环节的 AI 输出我都要求“留痕”。不是说要写什么文档而是把关键 Prompt 和 AI 输出贴在需求文档的评论里这样导师和同事能追溯你的决策依据。这个习惯在校招期间尤其加分因为大家会看到一个“懂方法”的新人而不是只会点鼠标的工具人。3.2 我日常工作流里的四件套搭配和运行逻辑工具层面我整理了一个四件套覆盖了完整链路。首先是用 AI IDE 插件。我选了一个支持本地代码索引和多文件上下文的插件用起来顺手。它的关键价值不在于自动补全那点效率而在于“整个仓库的语义检索”。让它解释一个方法的调用链比我自己在 IDE 里跳来跳去快非常多。其次是命令行助手。终端操作和 Git 操作我经常用它帮我解释一段晦涩的构建报错把一长串的 git 命令整理成可执行脚本或者直接帮我写一个快速处理日志的 awk 命令。这类一次性命令不值得背但每次查又浪费时间交给 AI 刚刚好。第三是个文档沉淀工具我把日常积累的上下文片段存在里面按月维护。你可能会觉得这是负担但实测下来你只要看一个东西当你需要向 AI 描述项目背景的时候如果不假思索就能粘贴出来说明你的上下文沉淀已经到位了。第四是项目里的自动化工作流。营地里经常有重复性的环境准备任务比如初始化配置、生成代码骨架我会把一些常用的操作固化成半自动脚本让 AI 在里面当“执行者”。减少人为失误的同时也把更多时间留给真正需要动脑的设计和排查。3.3 实测数据接入工作流前后的效率账和心理账我做了一组粗糙但真实的对比测试。同样一个中等规模的 CRUD 需求包含两个表、一个导出功能、五个接口。不接入 AI 工作流时从读代码到写完自测大概需要两天半接入工作流后压缩到一个半工作日。这个提升不是因为我代码写得快而在于我把阅读理解的时间大幅压缩了。还有一个更直观的对比过去接到一个陌生模块的维护需求我要花至少半天去读代码、梳理调用链、找到改动点。现在用 AI 做代码解释和流程梳理两个小时就能完成一轮比较完整的走读。省下来的时间可以提前进入编码和自测环节这个积累在绩效评价时是能看到的。心理账同样重要。说实话校招第一年最容易崩溃的时刻不是业务难而是“不知道去哪查、问同事又不好意思”。有 AI 在中间做缓冲后很多小问题我能在不打扰别人的前提下自己搞定。说句私心话这种“自主解决”的正反馈帮我顺利过了试用期也让我更愿意继续完善自己的工作流。3.4 我自己常用的几个提示词模板直接复制可用分享几个我磨合了很久的提示词模板不保证适用所有场景但值得一试。第一个是“需求拆解模板”你是一名资深业务分析师请根据下面的需求描述输出业务目标、用户场景、涉及系统、数据字段、接口变更、异常边界针对信息不明确的地方用问题列表逐条追问。第二个是“代码审查模板”你是本项目团队的一名高级代码审查者请审查以下代码。按 P0 逻辑正确性、P1 潜在性能与并发问题、P2 规范与可维护性三级输出问题每条问题给出代码行号、原因说明、修改建议没有问题的维度请明确写“无”。第三个是“单测生成模板”请根据下面的接口实现生成单元测试用例。要求覆盖正常流、异常流、边界值、空值场景使用 Mock 隔离外部依赖每个用例注明场景名称和预期结果先列出用例清单再逐段给出代码。用好模板的关键是你要理解每个约束背后的意图。比如“每项输出必须注明实现思路”不是为了看它废话是让 AI 被迫解释自己的代码这样你能快速判断它是不是在瞎编。4. 常见问题与排查技巧实录4.1 AI 一本正经地“胡说八道”怎么发现并纠正所有用 AI 写代码的人都会遇到幻觉问题是怎么用低成本发现。我现在的检查习惯是拿到 AI 输出后先看它的 API 调用部分再去仓库里实际查一下那个方法存不存在、参数对不对。这个动作只需要两分钟能把幻觉控制在很小的范围内。第二个手段是强制 AI 给依据。我写提示词时如果涉及项目内的类名、配置项、依赖坐标我都会加一句“如果引用了现有代码请标注出处”。要求 AI 在输出带上文件路径很多幻觉代码会在这个环节自己露出马脚因为它根本给不出来源。第三个手段是实战验证AI 生成的代码如果不确定我不会直接跑完整逻辑而是先写一个最小验证用例。它能编译能过测试才说明这段代码在这个工程里是成立的。这也是为什么我一直强调测试要人机协作因为 AI 写的代码如果没有快速验证通道风险真的不好控制。4.2 AI 生成的代码风格和团队规范冲突今年我遇到过一个特别典型的问题AI 生成的代码功能正确但代码风格和团队规范差很多。比如团队要求所有数据库访问必须走统一的 DAO 封装AI 却直接写了一个 JdbcTemplate 操作团队要求接口返回统一包装对象AI 有时候会返回裸数据。这种问题单纯靠“在提示词里说一句遵守规范”是解决不了多少的。我的办法是把团队规范摘要直接做成上下文片段在需要 AI 生成代码时固定拼在提示词前面。这个摘要不需要很长挑最关键的十几条就行了比如分层约束、禁止在 Controller 里写业务逻辑、异常必须抛出业务异常码、日志必须包含 traceId。实测下来规范类问题的出现频率大幅下降。当然也有一类冲突没法靠提示词解决架构层面约束。比如团队约定用事件驱动但 AI 不理解现有消息 Topic 体系仍然生成同步调用代码。这种问题我会直接手动改掉然后把这个场景加入上下文片段里避免下次再犯。4.3 上下文太长被“截断”关键信息丢了怎么办用 AI 处理大型代码库时最烦的问题就是上下文长度不够等你在对话里把大量代码贴进去它反而把最开始的业务目标给忘了。我现在处理长上下文有三条具体策略你可以直接参考。第一把任务化整为零。我不会让 AI 一口气分析一个完整流程而是拆成输入阶段、处理阶段、输出阶段每个阶段单独对话。这样每个对话的上下文都很精简AI 不容易迷路。第二用“摘要接力”的方式先让 AI 总结一段代码的行为用一小段自然语言描述它的输入输出然后把摘要作为下一轮对话的输入。这个方法适合跨文件分析效率高且不丢关键信息。第三把核心信息前置。我会把业务目标、关键约束、不可变更项放在提示词的开头代码放在后面。因为 AI 对上下文头部的注意力通常更强这样即使后面内容被截断它也不会忘记最重要的要求。别小看这个顺序调整它在我实测中对输出质量的改善非常明显。4.4 代码评审中 AI 和人工的分工到底怎么划这是团队里经常聊的一个问题既然 AI 都能预审代码了人工评审还有意义吗我的答案是AI 的评审价值集中在规范性、常见缺陷和边界提示人工评审的价值在于业务正确性和长期可维护性。两者不是替代关系而是接力关系。我自己在 MR 里会把 AI 预审结果作为附件并标注哪些问题我已经改了哪些问题我认为在现有场景下不需处理。这样人工评审的人可以快速把注意力放到真正重要的部分。实际效果是同事给我的评审意见从一堆“命名可以更好”变成“这个缓存策略在这种场景下可能有问题值得商榷”沟通质量提升了一个量级。需要注意不要让 AI 预审变成流程负担。如果它每次都给你报几十条无效建议你会本能地忽略它这个工具就废了。所以我会花时间调教它哪些建议总是误报就直接写进负向提示词里“不要提以下类型的建议”。这个调校动作能让 AI 越用越顺手而不是越用越烦。4.5 一句话避坑清单如果这一整篇你只想记几句话那我贴在下面永远不要让 AI 在没有项目上下文的情况下直接生成核心业务代码。任何 AI 给的命令和 SQL先在不重要环境验证高危操作必须人肉复核。接口签名一定要人为先定不要交给 AI 自由发挥。生成代码后至少追问一组边界条件和异常场景的测试用例。提示词里明确“禁用项”比罗列一堆“应该做”更能控制 AI 输出质量。依赖名称、配置项、类名必须让 AI 给出出处避免幻觉引用。人工评审永远保留对 P0 和架构问题的最终决策权。5. 给同龄人的一些进阶思考5.1 从“很会用工具”到“会设计流水线”我知道很多人关注 AI Coding最初的动机都是“提升编码速度”这是个很真实也很合理的目标。但我想说的是如果你校招进了互联网公司真正拉开差距的不是敲键盘速度而是把工具落成流程的能力。三五个 AI 技巧没用一整套工作流才有价值。所谓“设计流水线”不是写一堆自动化脚本而是你在每个环节都清楚三个问题AI 在这个环节输出的产物是什么、我判断它的标准是什么、如果它错了怎么回退和修复。这三个问题能回答清楚AI 就不再是分散的“点”而是你开发流程里的稳定“链”。我刚入职时带我的师兄说过一句话工具不重要你用工具的思维才重要。当时很不服气觉得他不懂新工具现在回头看他说的其实是大多数人在第一年犯的错误——学了一堆快捷键却没有把工具沉淀到自己的做事流程里。5.2 未来半年我打算继续完善的方向最后说说我自己接下来的打算也算给你一个扩展的思路。我目前在折腾的是两件事一是把常用的 AI 工作流沉淀成团队可复用的模板让新人来了不用自己从零摸索二是尝试把 AI 从“被动响应”升级到“主动提醒”比如在本地提交代码时自动检查是否漏了单测或者在部署前自动做配置比对。我没有把它当成一个“项目”去做而是当成每天工作方式的自然演化。因为 AI 这个领域变化太快了你重金打磨的一个流程可能三个月后就有更好的替代品。与其追求“完美方案”不如保持“低成本试错高频迭代”的状态更可持续。这套工作流说到底就一句话让 AI 处理确定性高的劳动把人的精力留给判断和创新。我这一年最大的体会是AI 没有让我失业它让我有更多时间去思考真正值钱的问题也让我这种没经验的新人能站到更高的起点上开始自己的技术生涯。