1. 先把复用这件事想清楚我发现一个很有意思的现象同样是天天用 AI 编程的人效率能差出三到五倍。差在哪不是谁更会写提示词而是谁把提示词和配套的流程真正变成了能复用的工作流。今天这篇我直接分享三个我自己已经在用、而且可以立刻搬到团队里用的 AI 编程工作流每个都带具体的文件结构、配置思路和踩坑记录你照着搭就行。这里说的工作流不是某个按钮也不是某一个单独的提示词而是一条完整的链路输入什么、经过哪些判断节点、产出什么、出问题怎么兜底。只有把这条链路固定下来才谈得上复用。不然你今天写的提示词明天就忘这个项目跑通的方案换到那个项目又要重新调效率自然上不去。这篇文章适合三类人日常用 AI 写代码的个人开发者想推动团队统一 AI 编程规范的组长或架构师以及正在折腾 Coze、Dify 这类工作流平台、想把沉淀下来的方案固化成模板的人。三个工作流都由浅入深前两个拿来就能用第三个涉及一点平台搭建我会把关键参数和设计思路都讲透。先说清楚一个底层认知工作流能不能复用不取决于你用的工具多高级而取决于你是否把判断逻辑和具体内容拆开了。凡是写死的部分都不可复用凡是参数化的部分都能复用。这个原则贯穿今天三个方案的全部设计建议你先记住这句话后面每个案例都会反复用到它。2. 工作流一AI 编程提示词统一管理与批量复用2.1 为什么提示词要当代码管而不是当聊天记录存大部分人的提示词管理方式是这样的写在聊天记录里或者散落在十几个 Markdown 文件里甚至就存在微信收藏里。结果就是提示词版本混乱同一个任务有七八种写法团队里每个人调出来的效果完全不一样。我自己最早也这样直到连续几次因为提示词不一致导致输出质量翻车才下定决心改造。我的方案很简单把提示词当成代码来管理。所有提示词进 Git 仓库用统一的目录结构组织用变量代替硬编码内容配上版本历史和变更说明。这样带来的直接好处有三个团队所有人都能拿到同一套标准每次优化都能看到改了什么、为什么改新项目接入时直接复制目录五分钟完成初始化。这套思路本质上和代码重构是同一件事。提示词也是资产它需要命名空间、需要模块化、需要回归测试。你写代码的时候不会把函数全堆在 main 函数里那提示词凭什么全堆在聊天框里2.2 具体目录结构与配置写法我实际在用的目录结构长这样ai-workflows/ ├── roles/ # 角色类提示词 │ ├── senior_engineer.md # 资深工程师视角 │ ├── code_reviewer.md # 代码审查视角 │ └── traffic_guard.md # 安全审查视角 ├── tasks/ # 任务类提示词 │ ├── generate_api.md │ ├── refactor_function.md │ └── write_unit_test.md ├── templates/ # 带变量的通用模板 │ └── code_generation.md ├── context/ # 项目上下文 │ ├── project_tech_stack.md │ └── coding_standards.md └── rules/ ├── output_format.md └── constraints.md每次在 IDE 里开始新任务时我只做三步第一根据任务类型选择tasks下的基础提示词第二用当前项目的context文件覆盖里面的变量第三如果需要额外约束把rules里的规则追加进去。模板文件长这样核心是变量占位符# 任务描述 请根据以下需求生成代码 ## 功能需求 {{feature_description}} ## 技术栈 {{tech_stack}} ## 约束条件 - 必须遵循 {{coding_standard}} 编码规范 - 输出格式必须是 {{output_format}} - 不允许使用 {{blocked_libraries}} 中的依赖 ## 输出要求 代码块关键逻辑说明控制在合理篇幅。这里面{{...}}就是变量。换项目时只改变量不改逻辑结构。等积累多了你甚至可以给每个角色配上一个咒语开头比如senior_engineer.md开头固定是请以资深后端工程师的视角从架构合理性、边界条件、异常处理三个维度……这样输出的第一句话就定了调。2.3 集成到 IDE 和团队协作这套目录搭好后我会把它设置为 IDE 的规则文件目录。以 Cursor 为例直接把ai-workflows目录放到工程根目录然后在.cursor/rules里引用用 Continue 的话在config.yaml里配置多个角色模板按快捷键即可切换。核心思路是让 AI 客户端自己读到这些规则而不是每次手动粘贴。团队协作时这套目录放在 git 仓库里天然支持代码评审。谁改了提示词diff 里一清二楚谁加了一个新任务模板合并请求里就能看到。我见过更细的做法就是在 CI 里加一个提示词烟雾测试每次变更跑一遍标准输入比较输出稳定性避免某次改动让整体效果退化。一个容易被忽略的点不同 IDE 的规则文件路径和优先级不同复制到新项目时容易漏。建议在仓库根目录放一个README.md写清楚挂载步骤和常用命令新成员加入时照着做就行。这一步听起来啰嗦但能省掉后面大量沟通成本。3. 工作流二简历筛选自动化——一个能立刻跑起来的完整范例3.1 把筛简历变成 AI 编程任务的思路简历筛选是很多技术负责人最头疼的重复劳动。几十份甚至上百份简历每份都要读、要对比、要判断既费眼又费时间。而且人看简历有个毛病看多了会疲劳前后标准会漂移。AI 做这件事的优势在于标准稳定、速度极快还能把每个评分理由写出来方便你复核。实现这个工作流的路径有两条。一条是用 Python 脚本直接调模型 API适合有编程基础、希望完全掌控流程的人另一条是在 Coze 这类平台上拖节点搭出来适合不打算写代码、但想快速验证效果的人。两条路的核心逻辑完全一样都是解析简历文本、按维度打分、输出结构化报告、人工复核。我建议第一次先用脚本跑通整个流程因为脚本逻辑透明、方便调试跑通了再拆到平台上。下面重点讲脚本实现方案。3.2 分维度打分的提示词设计与输出结构简历筛选不能只给一句合适或不合适那样既无法解释也难追溯。我的做法是拆维度每个维度单独打分最后汇总。实际使用的维度如下表所示评分维度权重评估内容举例硬性技能匹配40%是否掌握岗位要求的技术栈如 Java、Python、K8s项目经验相关度30%过往项目与当前岗位领域是否接近担任何种角色稳定性信号15%每段工作平均年限、跳槽频率、职业路径是否连贯沟通表达10%简历描述是否逻辑清晰、有量化结果意识风险信号5%是否存在明显的表述矛盾、模糊时间线、疑似编造每个维度都要求 AI 输出 0-10 分的评分、一句结论、和关键证据摘录。最后的权重汇总由代码计算不让模型做算术因为模型的加权计算容易出错。这一步很关键让 AI 只做判断不做计算。评分提示词的核心部分长这样你是资深技术面试官请基于以下简历内容评分。 硬性技能匹配度评估投递岗位JD与简历技能重叠程度。 输出格式严格JSON { tech_match: {score: 0-10, evidence: ..., conclusion: ...}, project_relevance: {score: 0-10, evidence: ..., conclusion: ...}, stability: {score: 0-10, evidence: ..., conclusion: ...} } 简历内容 {{resume_text}}这里必须规定 JSON 输出格式而且要写清楚每一个字段的含义。不约束格式AI 输出的东西千奇百怪后面解析就崩了。这也是整个工作流里我最强调的一点结构化输出是所有可复用工作流的基石。3.3 批量处理与人工复核机制简历是一批一批来的批量处理时我会把多份简历逐条送入脚本脚本依次调用模型、收取 JSON 结果、计算加权总分、写入一个大的 CSV 文件。CSV 里每一行是一份简历列是各维度得分和证据摘录末尾加一列推荐级别高/中/低。然后开启人工复核我只看 CSV 里总分排名前 x% 的简历以及风险信号分数极低的简历。AI 初筛把我的阅读范围从 100 份压缩到 15 份效率提升非常明显。这里有个必须强调的坑AI 的评分永远不能替代最后的人工面试决定尤其是候选人预期管理和决策责任这两个方面AI 帮不了你。把它当成阅读助理而不是决策者你会用得安心很多。成本方面一份 300-500 字的简历摘要主流模型的调用成本几乎可以忽略即便每天筛 100 份费用也就在几块钱量级比起你一个小时的阅读时间这笔账怎么算都划算。实测下来用低价的轻量模型就够完成初筛只有特别边缘的案例才需要升级到高能力模型复评。4. 工作流三PR 代码审查与超大上下文应对4.1 代码审查工作流的三大痛点第三个工作流是 PR 代码审查也是我日常用量最大的场景之一。它的难点和其他两个完全不同。对着一个几百行的 diff人眼容易漏让 AI 一次读完超长 diff又容易超长上下文限制或者后半部分注意力衰减、错误率上升。我踩过几次坑后总结出的三大痛点一是大型 diff 分分钟突破上下文窗口报错或者输出质量急剧下降二是审查负面问题严重——AI 对文件前部的意见详细到后部就开始偷懒三是审查结果格式不统一有用的和没用的混在一起。这三个痛点指向同一个解法把大 diff 拆成小块逐块审查再把各块的结论汇总。核心思想类似并行计算里的分治策略每个块都是独立的子问题块与块之间不发生上下文污染最后合并结果。4.2 分块策略与超长上下文的应对方案分块策略直接决定审查质量。我试过按文件分、按函数分、按行数阈值分综合下来效果最好的是混合策略文件数量不超过 5 个且每个文件 diff 小于 200 行时整份丢给模型一次审查文件数量较多时按文件切分每个文件独立审查单个文件 diff 超过 400 行时再按函数或逻辑块切分切完的块仍超过窗口限制时启用摘要压缩。摘要压缩的具体做法首先把超大 diff 块摘要成变更文件列表 每文件的改动意图概述再把意图概述作为上下文、配合逐块 diff 进行细节审查。这相当于给模型提供了一个目录让它带着全局认知逐页查细节而不会因为细节过多丢掉主线。如果你用的是 Coze 或 Dify 这类平台上述逻辑可以用节点组实现处理步骤类似解析 diff、判断长度、分流到直接审查或分块-汇总分支、最后拼装输出。若使用 Dify尤其要注意上下文超长报错往往不是模型能力不够而是编排时把太多临时数据塞进了对话记录合理的做法是在每个分支输出前主动裁剪历史消息。4.3 接入 CI 与建立审查意见的闭环审查工作流真正发挥威力是接进 CI/CD 流程的时候。我建议的做法是PR 创建时触发一个工作流任务检出分支、拉取和主干的 diff、调用上面的分块审查脚本、把审查意见以评论形式发回 PR。这样每个 PR 都有 AI 的第一轮意见作者在提交代码时就收到反馈而不是等到人工 review 时才聊。GitHub Actions 里触发代码如下所示name: ai-review on: pull_request: types: [opened, synchronize] jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 with: fetch-depth: 0 - name: Run AI review run: | git diff origin/main...HEAD diff.txt python review.py --diff diff.txt --output review.md env: LLM_API_KEY: ${{ secrets.LLM_API_KEY }} - name: Post comment uses: actions/github-scriptv6 with: script: | // 读取 review.md 并创建 PR 评论审查意见的输出格式我会固定用严重级别 文件/行号 问题描述 修改建议四段。这四段缺一不可级别决定处理优先级行号方便定位描述避免空话建议让作者直接能抄。每次审查跑完我会把意见汇总统计到一个小面板里看看哪些类型的问题出现频率最高反过来推动团队改进代码规范。这里有一个认知转变AI 审查不是替代人工 reviewer而是把人工精力从找低级错误挪到讨论架构和设计上。低级问题 AI 负责拦住高级问题人工负责深聊两者搭配才是健康节奏。5. 常见问题与排查技巧实录5.1 输出不稳定与上下文超长优先查哪里我自己一路搭下来踩得最多的坑集中在四个地方这里直接列成速查表给你现象常见原因排查方向输出时好时坏提示词里存在歧义或变量替换后内容矛盾检查模板变量是否完全替换是否有隐藏的历史对话扰动经常报上下文超长工作流把中间结果反复塞进对话记录修剪历史消息只保留最近一轮上下文必要时候用摘要代替原文批量跑一半就停下来触及模型调用频率限制或单次请求超时加入重试逻辑设置指数退避控制并发数审查意见越来越敷衍单个 diff 块过大注意力衰减缩小切块阈值优先按函数边界切其中上下文超长这个坑平台型工作流里尤其容易踩。很多人在 Dify 里搭流程时习惯把每个节点的输出都累积到对话变量里造成翻倍扩张。我的经验是每个节点输出要立即结构化落盘下一步只读取字段而非整个历史文本这样上下文保持可控成本也降下来了。5.2 工具选型对比脚本、Coze、Dify、n8n 怎么选接触工作流平台一段时间后不少人会纠结选哪个。我按自己的使用场景做个尽可能实在的对比方案适合场景成本门槛局限Python 脚本直调 API想完全掌控逻辑、已有代码基础仅 API 费用中需要自己维护运行环境Coze不想写代码、快速搭 BOT、内置插件多平台有免费额度低复杂分支逻辑受平台限制Dify要知识库 工作流一体、想要开源可控可自托管中高并发编排仍要调优n8n已有自动化体系、需要对接大量外部系统自托管免费中高偏向集成而非 AI 原生我给团队的建议是如果只是做一个内部小工具先上脚本或 Coze 验证效果如果明确要把 AI 流程和现有业务系统深度绑定再考虑 Dify 或 n8n。而复用这件事脚本用 Git 记录、平台用模板分享都能做到只是颗粒度不同。5.3 几个让工作流真正用起来的补充技巧最后分享几个让工作流真正可持续的小方法。第一把新发现的经验立刻固化成模板。每当我发现哪个提示词改一版效果明显变好我会立刻更新仓库里对应的模板文件并加一行变更说明。这个习惯坚持半年你的模板库会变成一笔很大的资产。第二单位时间内只优化一个变量。不要同时改模板结构和模型参数那样你根本不知道是哪个改动起的作用。一次只动一个对比输出再决定保留还是回滚。第三为工作流设计失败逃生口。比如简历筛选中如果 AI 对某份简历输出的 JSON 解析失败不要让它静默通过而是放进一个待人工处理的列表。这类兜底逻辑不复杂但有没有它决定了工作流在大批量场景下是稳定还是三天两头出问题。第四注意控制输入质量。简历内容如果是 PDF 扫描件务必先做 OCR代码 diff 如果夹带大量格式变更先用工具过滤掉这些前处理虽然不起眼但能大幅提升下游效果。写在最后按我个人的体验AI 编程工作流这件事真正难的从来不是某个提示词写得多漂亮而是把一套流程固定下来、让它能反复用、用在不同项目里还依然稳定。今天这三个工作流从提示词管理到简历筛选再到 PR 审查覆盖了不同复杂度的需求但底层思路一致先拆逻辑再固化成模板最后加上兜底。你不需要一次全上挑一个最困扰你的场景先落地跑通之后再复制到其他场景效果会超出你预期。如果你自己搭的过程中遇到了什么奇怪的问题或者你有一套更好的分块策略欢迎来交流。这些工作流离完美还很远但每迭代一次它就更皮实一点也更像你的第二大脑。