1. 为什么“能立刻复用”比“功能强大”更重要我见过太多人收藏了几百个AI编程工具从代码补全到全自动Agent硬盘里塞满了各种教程和配置文件结果日常写代码时还是一个Tab一个Tab地敲。问题不在于工具不够强而在于那些工作流要么配置太复杂要么跟自己的实际开发习惯拧着来用两次就放弃了。“能立刻复用”这四个字是我筛选工作流的唯一标准。一个工作流如果不能在五分钟内跑通、不能在我最常用的编辑器里直接触发、不能在我换一个项目之后还能原样搬过去那它就不值得留在我的工具箱里。下面这三个工作流是我过去大半年里反复迭代、砍掉所有花哨功能之后留下来的覆盖了代码生成、代码审查、上下文管理三个最高频的场景。每一个都可以在十分钟内配好第二天上班就能直接用。这篇文章适合谁看如果你已经在用AI辅助编程但感觉效率提升不明显或者每次都要重新写一遍提示词、重新贴一遍上下文那这三个工作流就是为你准备的。如果你还没开始用AI编程工具也没关系我会把每个环节的原理和操作都拆开讲你照着做就行。提示下面所有工作流都不依赖特定付费工具我用的是VS Code加几个免费插件以及一个本地运行的轻量级模型。你换成自己习惯的编辑器或模型逻辑完全一样。2. 工作流一三行注释生成可运行代码块2.1 这个工作流解决什么问题日常开发中最频繁的操作是什么不是写复杂算法而是写那些“我知道怎么写但懒得敲”的代码——比如一个日期格式化函数、一个数组去重、一个简单的HTTP请求封装。这些代码单次写起来不超过两分钟但一天下来累积起来消耗的注意力和时间非常可观。传统做法是去搜索引擎找或者从旧项目里复制。但搜索引擎的结果往往带着一堆无关代码复制过来还要删删改改。这个工作流的核心思路是用三行注释描述清楚输入、输出和边界条件让AI直接生成可以粘贴运行的代码块。2.2 为什么是“三行注释”而不是“详细描述”我试过写一大段自然语言描述也试过用结构化的JSON格式最后发现三行注释是性价比最高的。原因有三个第一三行注释强制我思考清楚函数的输入是什么、输出是什么、异常情况怎么处理。很多时候我写代码卡住不是因为不会写而是因为没想清楚边界条件。三行注释写完思路自然就清晰了。第二三行注释的格式足够简单不需要记忆复杂的模板。我用的格式就是# 输入一个包含重复元素的整数列表 # 输出去重后的列表保持原有顺序 # 边界空列表返回空列表非列表输入抛出TypeError第三这个格式对AI模型非常友好。实测下来用三行注释生成的代码一次通过率比用大段描述高出不少。因为注释里的关键词直接对应了代码结构模型不需要猜测我的意图。2.3 具体操作步骤第一步配置编辑器快捷键在VS Code里我设置了一个快捷键CtrlShiftG触发一个自定义命令。这个命令做两件事读取当前选中的注释文本调用本地模型API把生成的代码插入到注释下方。配置文件在.vscode/settings.json里核心配置如下{ aiWorkflow.commentToCode: { trigger: ctrlshiftg, model: local-code-model, maxTokens: 512, temperature: 0.2 } }温度参数设为0.2是因为代码生成需要确定性不需要创意。maxTokens设为512足够生成一个完整函数又不会让模型跑偏去写无关内容。第二步写好三行注释这里有个关键技巧输入和输出要具体到数据类型边界条件要写清楚异常处理方式。比如“输入一个字符串”就不如“输入一个UTF-8编码的字符串长度不超过1000字符”来得明确。我整理了一个注释模板覆盖了最常见的几种场景场景类型第一行输入第二行输出第三行边界数据处理输入一个包含N个对象的数组输出按某字段分组后的Map边界空数组返回空Map字符串操作输入一个可能包含空格的字符串输出去除首尾空格并转为小写边界null输入返回空字符串网络请求输入一个URL和超时时间输出Promise解析后的JSON对象边界超时抛出TimeoutError文件操作输入文件路径和编码格式输出文件内容的字符串边界文件不存在抛出FileNotFoundError第三步生成后立即验证AI生成的代码不能直接信任这是铁律。我的做法是生成后先扫一眼逻辑然后立刻写一个最小测试用例跑一遍。比如生成一个去重函数我就写assert dedupe([1,2,2,3]) [1,2,3]跑通了再粘贴到项目里。注意不要跳过验证步骤。我踩过的坑是有一次生成一个日期格式化函数AI用了某个特定库的方法但我的项目里没装那个库直接报错。后来我养成了习惯生成代码后先看import语句确认依赖都在项目里。2.4 实操心得与避坑指南心得一注释里不要写“请生成”之类的客套话。模型不需要你请它直接给输入输出边界就行。我试过写“请帮我生成一个函数”结果模型有时候会回复“好的以下是生成的代码”把这句话也插到编辑器里了。心得二复杂逻辑拆成多个三行注释。如果一个函数超过30行说明它做了太多事情。我会把它拆成两到三个小函数每个函数用一组三行注释生成最后手动组装。这样生成的代码质量更高也更容易测试。心得三把常用的三行注释存成代码片段。VS Code的snippet功能可以让你输入ai-func就自动展开成三行注释模板省去每次手打的麻烦。我存了五六个常用模板覆盖数组操作、字符串处理、日期计算等场景。常见问题排查问题现象可能原因解决方法生成的代码有语法错误注释描述有歧义检查输入输出类型是否明确代码逻辑正确但风格不符模型不知道项目规范在注释后加一行# 风格使用ES6箭头函数生成速度慢模型太大或网络延迟换用更小的本地模型或减少maxTokens插入位置不对快捷键冲突检查编辑器快捷键绑定换一个不冲突的组合3. 工作流二让AI先“读”再“写”的代码审查流水线3.1 为什么需要专门的审查工作流代码生成只是第一步生成出来的代码能不能用、有没有隐藏问题才是决定效率的关键。我见过很多人让AI生成代码后直接提交结果在CI环节被打回来修修补补的时间比手写还长。这个工作流的核心思路是在代码提交之前让AI扮演审查者角色按照固定的检查清单过一遍。跟工作流一不同这里不是让AI写新代码而是让它读已有代码并给出修改建议。3.2 审查清单的设计逻辑审查清单不能太长太长AI会漏看也不能太短太短起不到作用。我最终定下来的是五个维度每个维度对应一个具体的检查问题边界条件输入为空、输入为极值、输入类型错误时代码会怎样资源泄漏打开的文件、网络连接、数据库会话是否在所有路径上都正确关闭并发安全如果多个请求同时执行这段代码有没有共享状态被意外修改错误处理异常是否被捕获捕获后是记录日志还是静默吞掉可读性变量命名是否清晰函数是否超过50行嵌套是否超过3层这五个维度覆盖了日常开发中80%的bug来源。我把它写成一个Markdown文件放在项目根目录的.ai-review.md里每次审查时让AI读取这个文件作为检查依据。3.3 操作流程与配置第一步准备审查提示词提示词的结构是角色设定 审查清单 待审查代码 输出格式要求。我用的模板如下你是一个资深代码审查者。请按照以下清单审查代码 1. 边界条件检查空输入、极值、类型错误 2. 资源泄漏检查文件、连接、会话的关闭 3. 并发安全检查共享状态修改 4. 错误处理检查异常捕获和日志记录 5. 可读性检查命名、函数长度、嵌套深度 对于每个问题输出 - 问题位置行号 - 问题描述 - 严重程度高/中/低 - 修改建议 待审查代码 python 这里粘贴代码**第二步集成到Git钩子** 手动复制粘贴太麻烦我把它集成到了Git的pre-commit钩子里。每次git commit时钩子自动读取暂存区的代码调用AI审查如果有“高”严重程度的问题直接阻止提交。 钩子脚本的核心逻辑 bash #!/bin/bash # .git/hooks/pre-commit STAGED_FILES$(git diff --cached --name-only --diff-filterACM | grep \.py$) for FILE in $STAGED_FILES; do CODE$(git show :$FILE) RESULT$(curl -s -X POST http://localhost:8080/review \ -H Content-Type: application/json \ -d {\code\: \$CODE\, \checklist\: \$(cat .ai-review.md)\}) HIGH_ISSUES$(echo $RESULT | grep -c severity: high) if [ $HIGH_ISSUES -gt 0 ]; then echo 发现 $HIGH_ISSUES 个高严重程度问题提交被阻止 echo $RESULT exit 1 fi done第三步处理审查结果AI审查的结果不能全信但也不能不看。我的做法是高严重程度的问题必须处理中等的看情况低等的忽略。处理完之后在提交信息里加一行Reviewed-by: AI方便以后追溯。3.4 实测效果与调优经验这个工作流我用了三个月拦截了大概二十多个问题其中真正有意义的占一半左右。比较典型的几个一个文件读取函数在异常路径上没有关闭文件句柄AI标为“高”一个缓存更新逻辑在多线程环境下可能读到旧值AI标为“高”一个字符串拼接在循环里用了导致性能问题AI标为“中”调优方面我做了两件事一是把审查清单从最初的十二条精简到五条减少了误报二是给每个维度加了“忽略规则”比如“如果项目已经用了全局异常处理器错误处理维度可以放宽”。提示AI审查不能替代人工审查但可以作为第一道过滤网。我的习惯是AI审完自己再审一遍重点看AI标为“高”但我觉得不是问题的那些往往能发现AI的盲区也能加深自己对代码的理解。常见问题速查问题原因解决误报太多清单太细或太泛精简清单加忽略规则漏报严重问题模型能力不足换更大的模型或增加清单条目审查速度慢每次全量审查只审查变更部分用diff代替全文件钩子阻止正常提交阈值设置过低只阻止“高”严重程度或加白名单4. 工作流三跨会话的上下文管理方案4.1 上下文丢失是AI编程最大的痛点用AI编程最让人抓狂的事情是什么不是生成错误代码而是每次新开一个对话AI就完全忘了之前聊过什么。你花了半小时跟它解释项目结构、技术栈、命名规范关掉窗口再打开一切归零。这个工作流解决的就是这个问题。核心思路是把项目上下文写成一个结构化的文件每次对话开始时自动加载。这样不管换多少个会话AI都能立刻进入状态。4.2 上下文文件的结构设计上下文文件不能太大太大模型处理不了也不能太小太小信息不够。我最终定下来的结构是四个部分第一部分项目概览。用三到五句话说明项目是做什么的、技术栈是什么、代码风格有什么特殊要求。这部分控制在200字以内。第二部分目录结构。只列关键目录和文件不需要完整树形图。比如src/ api/ # 接口层使用FastAPI services/ # 业务逻辑纯函数为主 models/ # 数据模型使用Pydantic tests/ # 测试文件与src结构对应第三部分常用模式。列出项目里反复出现的代码模式比如“所有API返回统一用ResponseWrapper包装”、“数据库操作必须通过Repository层”。这部分是让AI生成代码时保持一致性的关键。第四部分当前任务。每次开始新任务时更新说明这次要做什么、涉及哪些文件、有什么特殊要求。4.3 自动化加载的实现手动复制粘贴上下文文件太麻烦我写了一个简单的脚本在VS Code里一键把上下文文件内容插入到当前对话中。脚本逻辑import os CONTEXT_FILE .ai-context.md def load_context(): if not os.path.exists(CONTEXT_FILE): return 上下文文件不存在 with open(CONTEXT_FILE, r, encodingutf-8) as f: content f.read() # 截断过长的内容保留前2000字符 if len(content) 2000: content content[:2000] \n...内容过长已截断 return content def update_task(task_description): with open(CONTEXT_FILE, r, encodingutf-8) as f: lines f.readlines() # 找到“当前任务”部分并替换 for i, line in enumerate(lines): if line.startswith(## 当前任务): lines[i1] task_description \n break with open(CONTEXT_FILE, w, encodingutf-8) as f: f.writelines(lines)在VS Code里我绑定了一个快捷键CtrlShiftC触发这个脚本把上下文内容复制到剪贴板然后我直接粘贴到对话窗口就行。4.4 维护上下文的经验技巧技巧一上下文文件要跟着代码一起提交。我把它放在项目根目录跟README.md平级每次代码有重大变更时同步更新。这样团队里其他人也能用同一份上下文。技巧二用注释标记需要AI特别注意的地方。比如在“常用模式”部分我会写!-- 重要所有日期字段必须用ISO 8601格式 --AI读到这个注释时会格外注意。技巧三定期清理过期内容。项目迭代快三个月前的上下文可能已经不准了。我每个月花十分钟过一遍上下文文件删掉过时的模式补充新的约定。技巧四为不同任务准备不同的上下文变体。比如写前端组件时我加载的上下文侧重UI规范写后端接口时加载的上下文侧重数据模型。我建了一个.ai-context/目录里面放多个上下文文件按需切换。注意上下文文件不要包含敏感信息比如数据库密码、API密钥。我见过有人把.env文件内容贴进去结果AI在生成代码时把密钥硬编码进去了。上下文文件只放结构性和规范性的内容。常见问题排查问题原因解决AI还是记不住上下文太长被截断精简到2000字以内只留关键信息生成的代码风格不一致常用模式描述不具体给出正例和反例比如“用snake_case不用camelCase”上下文文件过期没有定期维护设日历提醒每月更新一次切换任务时忘记换上下文手动操作容易忘把上下文切换集成到项目打开脚本里5. 三个工作流如何组合使用单独用任何一个工作流都能提升效率但真正的威力在于组合。我日常的开发节奏是这样的早上到工位打开项目上下文文件自动加载。接到一个新需求先用工作流一的三行注释生成核心函数跑通测试。然后把生成的代码交给工作流二审查修掉高严重程度的问题。下午继续开发时如果换了任务更新上下文文件的“当前任务”部分继续用工作流一生成新代码。三个工作流共享同一个上下文文件所以AI在不同环节看到的信息是一致的。这带来的好处是生成的代码风格统一审查时不会因为风格问题产生误报跨会话切换时不需要重新解释项目背景。我统计过用这套组合之前一个中等复杂度的功能模块平均需要四到五小时用之后同样的模块大概两到三小时就能完成而且代码质量更稳定因为审查环节拦截了大部分低级错误。提示不要试图一次性把三个工作流都配到完美。我的建议是先配工作流一用一周熟悉节奏然后加工作流二再跑一周最后加工作流三。每加一个观察一周确认不会拖慢开发速度再继续。这套东西说到底就是一句话把重复的解释和检查工作交给AI把创造性的思考和决策留给自己。工具是死的工作流是活的你可以根据自己的习惯随意调整参数和步骤。我分享的这些配置和脚本你直接抄过去用就行遇到问题再改。