1. 从校招入职到把 AI 塞进整条开发链路刚入职那阵子我最大的感受不是“代码写不出来”而是“写代码之外的事情太多了”。需求评审、拉分支、写单测、改 CI、补文档、Review 别人的 PR、处理线上告警一天下来真正敲键盘的时间可能不到三小时。作为一个校招生我特别怕自己显得“慢”于是开始琢磨一件事能不能把 AI 从“一个帮我补全函数的玩具”变成真正嵌进我整条开发流程里的协作者。这个项目就是我在入职前三个月里一点点搭起来的AI Coding 工作流。核心目标很朴素让 AI 参与从需求理解、方案设计、编码、测试、Code Review 到文档沉淀的每一个环节而不是只在 IDE 里当个高级自动补全。用到的核心工具包括Codex 这类命令行 Coding Agent、IDE 内置的 AI 助手、以及我自己写的一些胶水脚本。整套流程跑下来我个人的体感是重复性劳动的耗时大概砍掉了四成更重要的是我不用再在“上下文切换”上浪费大量精力。这篇文章适合几类人看刚入行的校招生、想系统化用 AI 提效的中级工程师、以及团队里想推动 AI 工具落地但不知道从哪下手的人。我会把整套工作流拆开讲清楚——为什么这么设计、每一步具体怎么操作、踩过哪些坑、哪些地方 AI 其实帮不上忙。你不需要有很深的 AI 背景只要会基本的 Git 和命令行就能照着复现。先说清楚一个前提AI Coding 不是“让 AI 替你写代码”而是“让 AI 承担那些你不想重复做、但又必须做的环节”。这个定位想明白了后面的所有设计才有意义。2. 整体设计思路为什么是“工作流”而不是“工具”2.1 单点工具的天花板在哪里我一开始的用法和大多数人一样在 IDE 里装个 AI 插件写代码时让它补全遇到报错就贴给它问。用了两周之后我发现一个问题——这种用法把 AI 困在了“当前文件”里。它不知道我这个需求从哪来、不知道项目的整体架构、不知道我们团队的代码规范甚至不知道我上一个小时刚改过哪个模块。每次对话都像重新认识一个人上下文全靠我手动喂。更麻烦的是单点工具解决不了“流程断点”。比如我写完一个函数要切到终端跑测试测试挂了再切回来改改完再切到 Git 提交提交信息还得自己想。这些切换本身不费脑但极其消耗注意力和时间。AI 插件再强它也只能管住 IDE 那一小块屏幕。所以我得出的第一个结论是AI 的价值不在于单次生成的质量而在于它能不能覆盖流程的连续性。一个能记住上下文、能跨文件操作、能调用命令行的 Agent比十个只会补全的插件更有用。2.2 把开发流程拆成“AI 可介入的节点”我把自己一天的工作拆成了几个固定节点然后逐个判断 AI 能不能介入、以什么方式介入流程节点AI 介入方式介入程度需求理解把需求文档丢给 Agent让它输出技术方案草稿高方案设计Agent 生成多个方案对比我做决策中编码实现IDE 内联补全 Agent 跨文件修改高单元测试Agent 根据函数签名生成测试用例高Code ReviewAgent 先做一轮静态检查我再人工过中提交与文档Agent 生成 commit message 和变更说明高线上排查贴日志给 Agent 做初步归因低这张表是我整个工作流的骨架。你会发现越是结构化、越是重复的环节AI 介入程度越高越是需要判断和权衡的环节AI 只做辅助。这个原则很重要因为它决定了你不会把关键决策交给一个会“一本正经胡说八道”的模型。2.3 为什么选命令行 Agent 作为核心市面上 AI 编程工具大致分三类IDE 插件、网页对话、命令行 Agent。我最后把命令行 Agent也就是 Codex 这类工具作为核心原因有三个。第一命令行 Agent 能操作文件系统和执行命令。这意味着它可以自己读项目结构、自己跑测试、自己看报错形成一个闭环。IDE 插件通常只能在你打开的文件里活动视野太窄。第二命令行天然适合脚本化和自动化。我可以写一个 shell 脚本把“拉分支、生成代码、跑测试、提交”串成一条命令Agent 作为其中一环被调用。这种可组合性是网页对话做不到的。第三命令行 Agent 的上下文管理更可控。我可以明确告诉它“只读这几个文件”“参考这个规范文档”而不是让它把整个项目都塞进上下文里烧 token。当然IDE 插件我也没扔。内联补全这种高频、低延迟的场景还是 IDE 插件体验最好。命令行 Agent 负责“重活”IDE 插件负责“顺手活”两者分工明确。2.4 一个容易被忽略的设计上下文分层整套工作流里我觉得最有价值的设计是上下文分层。我把喂给 AI 的信息分成三层项目层技术栈、目录结构、代码规范、常用命令。这部分相对稳定我写成一个AGENTS.md放在仓库根目录Agent 每次启动自动读取。任务层当前需求文档、相关 issue、涉及模块的说明。这部分每个任务不同我在启动 Agent 时手动指定。会话层当前对话里的临时信息、报错、我的补充说明。这部分随对话滚动。分层的意义在于避免上下文污染。如果我把所有信息一股脑塞进去模型很容易抓不住重点还会因为 token 超限被截断。分层之后项目层的规范是“长期记忆”任务层是“工作记忆”会话层是“短期记忆”各司其职。提示AGENTS.md这个文件名不是随便起的很多命令行 Agent 会默认读取根目录下的这个文件作为项目级指令。你可以在里面写清楚“本项目用 pnpm 不用 npm”“提交信息用中文”“测试命令是 xxx”能省掉大量重复解释。3. 核心环节拆解每个节点具体怎么落地3.1 需求理解让 AI 先读一遍再开口以前我拿到需求文档习惯直接开始想“这个功能怎么实现”。现在我多了一步把需求文档原文丢给 Agent让它先输出一份“我理解的需求”和“我不确定的地方”。这一步的价值在于暴露歧义。AI 读文档时会把它认为模糊的地方列出来比如“这里说的‘用户’是指登录用户还是所有访客”“这个超时时间有没有默认值”。这些问题往往也是我自己会忽略的。拿着这份清单去和产品对齐比我自己闷头猜要靠谱得多。具体操作上我会用这样的提示词结构# 伪代码示意实际用你所用 Agent 的调用方式 agent run --context ./docs/requirement.md \ --prompt 请阅读这份需求文档输出 1. 你理解的功能目标三句话以内 2. 涉及的核心模块和数据流 3. 你认为存在歧义或缺失的信息逐条列出 4. 你建议的技术方案草稿包含关键取舍注意最后一条“包含关键取舍”。如果只让它给方案它会给你一个看起来很完美的答案要求它说明取舍它才会把“为什么不用另一种方案”讲出来这对做决策很有帮助。3.2 方案设计让 AI 当“陪练”而不是“决策者”方案设计阶段我的用法是让 AI 生成 2 到 3 个候选方案然后我自己做对比。这里有个心得不要问“哪个方案最好”而要问“这几个方案分别在什么场景下更优”。举个例子我之前做一个数据同步功能AI 给了三个方案定时全量同步、基于 binlog 的增量同步、双写。如果我只问“哪个好”它大概率会推荐增量同步因为听起来最“高级”。但我追问“如果团队没有维护 binlog 的经验哪个方案的上手成本最低”它就会老老实实分析全量同步的运维简单性。同一个问题换个问法得到的答案质量完全不同。这个阶段我还会让 AI 帮我做一件事列出每个方案的“失败模式”。也就是“这个方案在什么情况下会出问题”。这比让它列优点有用得多因为优点往往是显而易见的而失败模式才是真正决定方案能不能落地的因素。3.3 编码实现跨文件修改才是刚需编码阶段我分成两种场景。小改动用 IDE 内联补全比如补一个函数体、写一个 if 分支这种场景要求低延迟插件最合适。大改动用命令行 Agent比如“给这个模块加一个缓存层涉及三个文件”这种跨文件的活儿插件干不了。跨文件修改的关键是让 Agent 先规划再动手。我通常会让它先输出一份“修改计划”要改哪些文件、每个文件改什么、改动之间有没有依赖顺序。确认计划没问题后再让它执行。这样做的好处是如果计划本身有问题我在它动手之前就能拦住而不是等它改完一堆文件再回滚。还有一个细节让 Agent 每次只改一个逻辑单元。比如“先加缓存读取逻辑跑通测试再加缓存失效逻辑”。一次性让它改太多出了问题很难定位是哪一步引入的。这其实和人类写代码的习惯是一样的——小步提交快速验证。3.4 单元测试AI 最被低估的用武之地如果说有一个环节 AI 的投入产出比最高那一定是写单元测试。原因很简单测试代码结构高度重复、逻辑相对独立、对“创意”要求低正好是 AI 的强项。我的做法是写完一个函数后直接把函数签名和实现丢给 Agent让它生成测试用例。提示词里我会明确要求覆盖几类情况正常输入、边界值、异常输入、以及“我认为最容易出 bug 的分支”。最后这一类需要我自己判断但 AI 能帮我把前几类快速铺满。实测下来AI 生成的测试用例大概有七成可以直接用剩下三成需要我调整断言或补充 mock。即便如此写测试的时间也从原来的“占开发时间一半”降到了“占两成左右”。而且有个额外好处为了让 AI 能生成测试我会不自觉地把函数写得更纯粹、依赖更少这反过来提升了代码质量。注意AI 生成的测试有个通病——它倾向于测试“实现”而不是“行为”。比如你函数内部用了某个工具类它可能会去 mock 那个工具类并断言调用次数。这种测试很脆弱一旦重构就挂。我的做法是手动把这类断言改成对输入输出的断言只关心“给定输入得到什么输出”。3.5 Code ReviewAI 先过一遍我再过一遍Code Review 这个环节我的定位是让 AI 做“第一遍粗筛”。具体来说提交 PR 之前我会让 Agent 对 diff 做一次检查重点看几类问题明显的逻辑错误、未处理的异常、硬编码的魔法数字、以及和项目规范不符的地方。这一步能帮我挡掉不少低级问题让我在人工 Review 时能聚焦在架构和设计层面。但我要强调AI 的 Review 绝对不能替代人工 Review。它看不出“这个设计是不是符合业务长期演进方向”也看不出“这段代码和隔壁模块的职责是不是重叠了”。这些需要人来判断。我一般会这样组织提示词agent run --diff HEAD~1 \ --prompt 请 review 这次改动按以下优先级输出问题 1. 可能导致运行时错误的逻辑问题最高优先级 2. 未处理的边界情况和异常 3. 与项目规范不符的地方参考 AGENTS.md 4. 可读性建议最低优先级 每条问题请给出文件行号和具体修改建议。按优先级输出这个要求很关键否则 AI 会把“变量命名不够优雅”和“空指针风险”并列摆出来你还得自己排序。3.6 提交与文档把重复劳动彻底交出去Commit message 和变更说明是我最不想动脑的部分。现在的做法是让 Agent 读 diff生成符合团队规范的 commit message。我们团队用 Conventional Commits所以我会在提示词里明确格式要求并让它把“为什么改”写清楚而不只是“改了什么”。文档这块我会让 Agent 根据代码变更自动更新对应的接口文档或 README。这里有个技巧让 Agent 只更新“受影响的部分”而不是重写整个文档。否则它很容易把原来写得好好的段落改得面目全非。我会明确告诉它“只修改和本次变更相关的章节其他内容保持原样”。4. 实操全流程从拉分支到合并的完整记录4.1 环境准备与工具配置先把基础环境说清楚。我的主力环境是 macOS但流程在 Linux 和 Windows 上都能跑差异主要在路径和 shell 语法。核心工具就三样一个命令行 Agent、一个 IDE、以及 Git。命令行 Agent 的安装方式各家不同但配置逻辑是相通的。核心是配置文件通常放在用户目录下用来设置模型、API 地址、默认参数等。我踩过的第一个坑就是配置文件格式写错导致 Agent 启动时报“无法加载配置”。后来发现是某个字段的缩进用了 tab 而不是空格这种问题排查起来很费时间。配置好之后第一件事是在项目根目录建一个AGENTS.md。我的模板大概长这样# 项目 AI 协作规范 ## 技术栈 - 语言TypeScript 5.x - 框架React 18 Vite - 包管理pnpm禁止使用 npm/yarn - 测试Vitest ## 常用命令 - 安装依赖pnpm install - 启动开发pnpm dev - 跑测试pnpm test - 类型检查pnpm typecheck ## 代码规范 - 组件用函数式禁止 class 组件 - 状态管理优先用 hooks复杂场景用 zustand - 提交信息用 Conventional Commits 格式 - 所有导出函数必须有 JSDoc 注释 ## 禁止事项 - 禁止直接修改 node_modules - 禁止在代码里硬编码 API 地址 - 禁止提交 console.log这份文件看起来简单但它能省掉大量重复沟通。Agent 每次启动读到它就知道该用什么命令、该守什么规矩。4.2 一个完整任务的执行记录我拿之前做的一个真实任务举例给用户列表页加一个“按注册时间筛选”的功能。下面是完整流程。第一步需求理解。我把需求文档丢给 Agent它输出的歧义点里有一条我没想到“注册时间筛选是精确到天还是精确到秒”我去问产品确认是精确到天。这个细节如果没提前问后面返工是必然的。第二步方案设计。Agent 给了两个方案前端筛选和后端筛选。我追问“如果用户量到十万级哪个方案更合适”它分析后建议后端筛选配合分页。这个判断和我的想法一致于是定下来。第三步编码。我让 Agent 先输出修改计划改后端接口加时间参数、改前端筛选组件、改 API 调用层。确认后让它逐个执行。每改完一个文件我就跑一次类型检查确保没有引入错误。第四步测试。让 Agent 根据新的接口函数生成测试用例覆盖了“不传时间”“传开始时间”“传结束时间”“传非法时间”四种情况。其中“传非法时间”的用例它一开始没写是我补充要求的。第五步Review。提交前让 Agent 过了一遍 diff它指出我在前端组件里硬编码了一个日期格式字符串建议抽成常量。这个建议很合理我采纳了。第六步提交。让 Agent 生成 commit message格式是feat(user-list): add registration time filter正文里说明了后端接口变更和前端交互调整。整个任务从开始到提交大概用了两个半小时其中我真正“写代码”的时间不到四十分钟其余时间花在需求确认、方案决策和 Review 上。这个时间分配我觉得是健康的——AI 承担了执行我承担了判断。4.3 参数选择与关键配置说明有几个配置项值得单独说因为它们直接影响使用体验。上下文窗口大小。这个参数决定了 Agent 一次能“看到”多少内容。设太小它读不完项目结构设太大响应变慢且容易抓不住重点。我的经验值是日常任务用中等窗口涉及大范围重构时临时调大。不要一直开最大那样反而降低效率。温度参数。这个参数控制输出的随机性。写代码时我调低让它输出更确定的结果做方案头脑风暴时我调高让它给出更多样的思路。同一个工具不同场景用不同参数效果差别很大。超时时间。命令行 Agent 执行复杂任务时可能跑很久默认超时经常不够。我会把它调到足够长避免任务跑到一半被中断。但也要注意如果某个任务异常地慢可能是提示词有问题导致它在原地打转这时候要主动中断检查。自动执行开关。有些 Agent 支持“自动执行命令”也就是它生成的 shell 命令不用确认直接跑。这个功能很危险我建议默认关闭只在明确知道要跑什么的时候临时开启。我踩过一次坑Agent 生成了一个rm命令幸好我开了确认否则后果不堪设想。5. 常见问题与排查技巧实录5.1 Agent 连不上或响应异常这是最常见的问题表现是 Agent 启动后一直转圈或者报连接错误。排查思路按顺序来现象可能原因排查方法启动即报配置错误配置文件格式问题检查缩进、引号、字段名拼写能启动但请求超时网络或服务端问题先用简单请求测试连通性响应到一半中断上下文超限减少喂入的文件数量报模型不支持模型名写错或权限不足核对配置里的模型标识我遇到最多的是配置文件问题。有一次我把某个布尔值写成了字符串trueAgent 一直报“配置无效”查了半小时才发现。建议配置改完后先用一个最简单的请求验证别直接上复杂任务。5.2 AI 生成的代码“看起来对但跑不通”这个问题很典型。AI 生成的代码往往语法正确、逻辑自洽但就是跑不起来。常见原因有几个依赖的库版本不对。它可能用了某个库的新 API但你项目里装的是旧版本。假设了不存在的工具函数。它会“幻觉”出一些看起来合理的函数名。忽略了项目的特殊约定。比如你项目里所有网络请求都要走统一的封装它直接用了原生 fetch。我的应对方法是生成后先跑类型检查和测试不要直接信。类型检查能抓出大部分幻觉函数测试能抓出逻辑问题。另外在AGENTS.md里写清楚项目的特殊约定能显著减少这类问题。5.3 上下文丢失导致“答非所问”长对话里Agent 经常会忘记前面说过的内容。这不是它“笨”而是上下文窗口的物理限制。我的应对策略是主动做上下文管理每完成一个逻辑单元就开一个新会话把必要的背景重新喂一遍。把重要的约定写进AGENTS.md而不是依赖对话记忆。如果发现它开始答非所问不要试图“纠正”直接重开会话更快。提示与其在一个长会话里反复拉扯不如把任务拆小每个小任务一个干净会话。这看起来麻烦实际效率更高。5.4 独家避坑技巧汇总几条我踩坑换来的经验直接给结论第一永远不要让 Agent 直接操作生产环境。任何涉及部署、数据库变更的操作都要在本地或测试环境验证后再手动执行。第二给 Agent 的提示词里明确“不要做什么”。比如“不要修改测试文件”“不要动配置文件”比只说“要做什么”更有效。第三定期检查 Agent 生成的 commit message。它有时候会把不相关的改动也写进去或者把“修复”写成“新增”。提交前扫一眼能避免很多尴尬。第四保留人工兜底。无论流程多顺最后合并代码前我一定会自己完整看一遍 diff。AI 是助手责任在我。第五别在情绪上头时用 AI。赶进度的时候容易图快直接接受 AI 的输出不检查这时候最容易出问题。越是急越要按流程走。6. 这套工作流跑下来我的真实体会用了三个月最大的变化不是“写代码变快了”而是我对整个开发流程的掌控感变强了。以前很多环节是“凭感觉”在做现在因为要写提示词、要设计流程反而被迫把每个环节想清楚了。AI 像一面镜子你对流程的理解有多清晰它就能帮你多少你如果自己都是糊的它只会把混乱放大。另一个体会是AI Coding 的门槛不在工具而在“提问能力”。同样一个任务提示词写得好和写得差结果可能差出十倍。这个能力没法速成只能靠大量实践去磨。我现在的习惯是每次 Agent 输出不理想先反思是不是我的提示词有问题而不是急着换工具。最后说一个可能有点反直觉的观点AI 用得越好的人越不会把关键决策交给 AI。因为你知道它的边界在哪里知道它什么时候会“自信地犯错”。把它当成一个执行力很强但判断力有限的同事这个定位我觉得最准确。这套工作流我还在持续迭代最近在尝试把线上告警的初步归因也接进来让 Agent 读日志给出可能的原因。等跑顺了再单独写一篇。如果你也在搭自己的 AI 工作流建议从AGENTS.md和单元测试这两个点切入投入最小回报最直接。