我最早其实有点抗拒“AI 编程工作流”这个说法总觉得又是新瓶装旧酒。但连续一个月被 GPT 写出来的“半成品代码”折磨之后我意识到问题不在大模型本身而在我的使用方式我把 AI 当成了单次问答工具而不是一整条生产链路。后来我花了两周时间把需求拆解、代码生成、执行验证、错误回填这几个环节用工作流串起来终于体会到什么叫“AI 编程”。这篇文章不聊虚的直接讲怎么从零搭一条能自动干活、能自动纠错的 AI 编程工作流适合写脚本、做小工具、处理数据类任务的开发者也适合想在公司内部铺 AI 辅助开发的团队参考。1. 单次问答式的 AI 编程为什么总在“快成功”时翻车1.1 你缺的不是提示词是反馈闭环很多人让 AI 写代码的惯用流程是把需求丢给模型拿到一段代码复制到项目里跑报错了再把错误信息粘贴回去让它改再跑再报错……循环几轮后要么改对了要么情绪崩溃。这个流程看起来有反馈但效率极低因为每一次“人肉中转”都在丢信息。你会发现模型经常忘记最开始的需求只盯着眼前的报错把本来是列表的返回值改成了字符串然后引发下一个错误。这类问题的根源不在提示词写得不够花哨而是整个链路里缺少自动化的反馈闭环。我自己试过把需求、代码、错误信息、期望结果全部拼在一段超长提示词里让模型一次修好效果很不稳定。模型确实能看到错误但它的注意力被分散了尤其当代码超过两百行时它可能改了 A 函数却忘了 B 调用点的参数变化。1.2 工作流把“写代码”拆成了可控制的环节真正让我改变思路的是把 AI 写代码这件事拆成独立环节需求理解、任务拆解、代码生成、代码执行、结果校验、错误修复。每个环节只做一件事输入输出都是明确的结构化数据。模型不再需要一口气承担所有责任它只需要在“代码生成”这个节点里根据上游给它的结构说明输出一段代码错误修复节点则只负责看错误信息注意力集中得多。这种做法的额外好处是“可观测”。单次问答时模型为什么给出这个答案你很难审查但工作流里每个节点的输入输出都留痕哪一步出了问题一目了然。比如代码执行节点返回了 exit_code1那问题一定出在代码运行阶段而不是模型没看懂需求。这个排查体验和你在 IDE 里调试程序完全不一样更像是站在流水线旁边监控效率。1.3 哪些任务适合先接入工作流不是所有编程任务都适合一上来就交给工作流。我自己列了个判断标准任务是否可以被结构化为“输入—处理—输出”。比如生成一次性数据处理脚本、批量重命名文件、自动生成 API 测试用例、修复 lint 错误、把一段伪代码翻译成 Python这些都是很好的接入场景。反过来底层架构设计、复杂业务规则梳理、跨模块重构这类高度依赖上下文和判断力的任务工作流做不了核心决策只能当副驾。我的建议是先从“25 行以内的小工具”开始。你很快能看到工作流的收益并且不会因为期望过高而失望。跑顺一个小场景后再慢慢把规模放大到需要调用多个文件、多个依赖的项目级任务。2. 工作流的技术选型模型、编排器、执行环境三方配合2.1 模型选择能力边界决定工作流上限搭建 AI 编程工作流的第一步其实是选一个“代码能力够用”的模型。这不是说所有模型都一样而是不同模型的代码生成质量、指令遵循能力、上下文利用效率差异很大。我个人的经验是选择模型时重点看三件事上下文窗口是否足够装下需求加错误信息、是否支持 OpenAI 兼容的 function calling、在代码生成基准上的实际表现是否稳定。我用过 DeepSeek、通义千问、GLM也测过一些海外模型。日常写 Python 小工具、shell 脚本、SQLDeepSeek 和 GLM 都够用性价比高如果涉及复杂的算法实现、多文件重构我更倾向于用上下文更长、思维链能力更强的模型。为了公平对比我同一个工作流里切换过多个模型结论是“能力强的模型可以省掉很多轮修复”长期算下来不亏。模型类型上下文表现代码生成稳定性成本倾向适合场景通用对话模型中中等低简单脚本、文案代码增强模型高较好中小工具、数据处理长上下文推理模型高强较高多文件任务、复杂逻辑2.2 编排工具对比Dify、n8n、扣子与代码方案确定模型之后第二步是选择编排工具。编排工具负责把“LLM 节点”“代码执行节点”“条件分支节点”这些积木连起来。目前我试过 Dify、n8n、扣子Coze也用过纯 Python 脚本自建编排给它们做个简单的横向对比工具上手难度代码执行能力模型接入灵活性最适合的场景Dify 社区版低内置 Python 沙箱可对接外部 API高支持多种模型构建 AI 应用、代码生成工作流n8n中通过 HTTP 节点或代码节点偏自动化高连接 GitHub、数据库、定时任务扣子低平台内受限代码节点能力有限中快速搭建对话型 Agent自写 Python 脚本高完全可控完全可控需要深度定制、长期维护我自己更倾向用 Dify 社区版作为主力原因很直接可视化拖拽节点对调试友好内置代码执行节点可以本地部署数据不出内网适合把生成代码的任务真正跑起来。n8n 我也留着主要做 GitHub 事件触发、定时拉取需求这类外部自动化如果你已经有 n8n 在跑流程完全可以在里面加一个 HTTP 节点调用模型 API不一定要切平台。2.3 让生成的代码“真正跑起来”沙箱与本地执行编排工具里最容易被低估的是“代码执行节点”。模型生成代码只是第一步它不能光停留在文本里必须在真实或仿真的环境里运行才能形成反馈闭环。Dify 的代码执行节点自带一个 Python 沙箱适合执行不依赖第三方库的简单逻辑。但这个沙箱有局限它不能读写本地文件系统也不能联网调外部 API一旦你的脚本涉及文件夹遍历、数据库连接就得把执行过程放到外部环境。我的做法是写一个本地执行器Dify 通过 HTTP 请求把模型生成的代码 POST 到一个本地服务服务在 Docker 容器里运行这段代码然后把标准输出、错误信息、退出码返回给工作流。下面是一个非常简化的示例用的是 FastAPIfrom fastapi import FastAPI, Request import subprocess app FastAPI() app.post(/run_code) async def run_code(req: Request): data await req.json() code data[code] with open(/tmp/user_code.py, w, encodingutf-8) as f: f.write(code) result subprocess.run( [python, /tmp/user_code.py], capture_outputTrue, textTrue, timeout30 ) return { stdout: result.stdout, stderr: result.stderr, exit_code: result.returncode }通过这种方式工作流就能获得真实的运行反馈。很多“AI 写代码不好用”的抱怨其实是因为模型生成的代码从未真正被执行过所有错误都是用户手动复制粘贴回去的。把执行能力接进来之后反馈闭环才算真正闭合。3. 手把手搭一个最小闭环需求到代码的自动生成工作流3.1 用 Dify 创建工作流的基本步骤我以 Dify 社区版为例带你过一遍最小闭环的搭建流程。第一步是部署 Dify官方文档提供的 docker compose 方式最简单一台 4C8G 的机器就能跑起来。部署完成后注册管理员账号在“设置—模型供应商”里填入你的模型 API Key我测试时用的是 DeepSeek接口兼容 OpenAI配置起来很顺。进入工作台后选择“工作流”再点“创建空白工作流”。Dify 会给你一个开始节点和一个结束节点中间可以自由添加 LLM 节点、代码执行节点、条件分支节点等。3.2 核心节点LLM 节点、代码执行节点、条件分支开始节点里我定义了一个输入变量requirement类型为“文本”它是整个工作流的入口也就是用户想要实现的功能描述。接着拖入一个 LLM 节点把它接到开始节点后面。这个 LLM 节点的系统提示词我写成了一段强约束指令要求模型只输出包含thought、code字段的 JSON具体模板见下一章。LLM 节点之后接一个“代码执行节点”。在 Dify 的代码编辑器里可以读取上游 LLM 节点的输出变量。我通常先加一步解析 JSON 的逻辑因为模型偶尔会把输出用 markdown 代码块包起来直接执行会报语法错误import json def main(llm_output: str) - dict: text llm_output.strip() if text.startswith(json): text text.strip() if text.startswith(json): text text[4:] data json.loads(text) return { code: data.get(code, ), thought: data.get(thought, ) }代码执行节点里我调用本地执行器接口跑这段code拿到stdout、stderr和exit_code。再往下接一个条件分支节点判断exit_code是否等于 0等于 0直接走到“成功”结束节点把结果返回给用户不等于 0就把错误信息带入下一个处理器。3.3 如何让工作流“自动跑一遍”并反馈错误Dify 社区版没有直观的 while 循环节点所以“自动纠错”能力需要多放几层节点来实现。我的最小闭环放了两个“LLM执行”链路第一个链路负责生成代码并执行如果失败第二个 LLM 节点会接收“原始需求 上一版代码 错误信息”作为输入要求它修复代码然后再经过一个代码执行节点。这样最多自动修一次如果还失败就直接进入人工结束节点。测试时我在开始节点输入了一个最简单的需求“写一个 Python 函数接收整数列表返回去重后的列表。”整个工作流跑完成功返回了 stdout。这个最小闭环的意义不在于解决多复杂的问题而是验证链路是通的需求能被理解代码能被生成代码能被真正运行成功后能拿到输出。4. 提示词模板怎么设计这是工作流的大脑4.1 一份可复用的代码生成提示词结构很多人用 AI 写代码时提示词只有一个“帮我写个爬虫”这当然不行。工作流场景下提示词必须高度结构化因为后续的代码执行节点依赖于模型的输出格式。我给你一份我反复调优过的模板你可以直接塞进 LLM 节点的系统提示词里你是一名资深 Python 工程师。请根据用户需求编写代码。 要求 1. 代码使用 Python 3.10不依赖未安装的第三方库。 2. 代码必须包含一个 main() 函数并在 if __name__ __main__ 中调用。 3. 输出格式必须严格遵循 JSON不要输出任何解释性文字。 4. JSON 结构如下 { thought: 简述你的实现思路, code: 完整代码使用 \n 换行 } 5. 如果需求不明确可以在 thought 中列出假设条件并按这些假设编码。这里强调“不依赖未安装的第三方库”是因为我们的执行环境不一定装了所有包。如果你把工作流接入一个有完整依赖的容器也可以改成“允许使用第三方库并在 requirement 中列出依赖清单”。但为了稳妥一开始最好约束在标准库范围内。4.2 把过往报错作为上下文回填当代码执行失败第二个 LLM 节点的输入就不能只是“请修复代码”这么简单。你需要把三段信息拼在一起原始需求、模型上次生成的代码、运行时的完整错误信息。拼接格式可以参考用户需求{requirement} 上一次生成的代码 {previous_code} 运行时报错 {error} 请根据报错信息修复代码并严格遵循系统提示词中的JSON输出格式。不要改变原有功能。注意不要把报错信息直接放在“用户”输入里而是放进系统提示词或独立字段中。模型对“错误信息”和“新任务”的区分能力有限如果混在一起它可能误解为要写一个错误处理程序。明确标注“上一次生成的代码”和“运行时报错”让模型知道这个上下文是用于修复的。4.3 输出格式约束与安全校验即使提示词里写了 JSON 输出模型偶尔还是会夹带 markdown 代码块、多余逗号甚至把stdout直接打出来。所以你必须在代码执行前做一层格式解析用正则把 JSON 提取出来再用json.loads校验import re, json def extract_json(text: str) - dict: match re.search(r\{.*\}, text, re.S) if not match: raise ValueError(No JSON found) try: return json.loads(match.group()) except json.JSONDecodeError: raise ValueError(Invalid JSON)安全校验也很重要。工作流会自动执行模型生成的代码意味着模型如果被提示词攻击可能输出os.system(rm -rf /)这类代码并被执行。所以我的本地执行器不是裸跑而是在 Docker 容器里限制权限只挂载临时目录。Dify 代码执行节点本身也是沙箱但不能把它当成绝对安全的环境外部执行器一定要加容器隔离和超时限制。5. 实战搭建一个“批量整理下载文件夹”生成工作流5.1 任务定义与拆解讲完方法论我们跑一个更贴近真实场景的例子“自动生成一个脚本把指定目录下的文件按扩展名移动到对应子文件夹支持命令行参数。”这个任务有一定复杂度但依然可以被工作流拆解。我把目标描述拆成三部分第一参数解析脚本要接受一个目录路径作为命令行参数第二遍历目录下的普通文件按扩展名归类第三创建对应扩展名的子文件夹并移动文件。工作流里的 LLM 节点会自动完成这个拆解但我建议你在开始节点里就把需求写清楚包括输入参数形式、文件处理规则、是否需要递归子目录。否则模型会默认不递归导致隐藏问题。5.2 节点配置实例在 Dify 工作流里我把开始节点的requirement变量设为上面那段需求描述。LLM 节点的系统提示词沿用第四章的模板然后在用户输入里只填{{requirement}}。代码执行节点拿到模型输出的 JSON 后解析出 code调用本地执行器。为了让执行器能验证脚本我特意构造了一个测试参数工作流里预设了一个临时目录的绝对路径调用代码时把参数传进去例如python /tmp/user_code.py /tmp/test_downloads本地执行器提前在这个目录下放几个测试文件report.pdf、photo.png、script.py。执行完脚本后我们再调用一个检查函数验证目录结构是否符合预期返回一个test_result字段。5.3 测试运行与结果分析我跑了一次完整流程模型生成的代码大体正确但第一版脚本里os.makedirs没有加exist_okTrue当对应扩展名文件夹已经存在时会抛异常。工作流捕获到 stderr 后第二个 LLM 节点把它修复成了带exist_okTrue的版本。修复后的代码类似这样import os import sys import shutil def main(): base_dir sys.argv[1] if not os.path.isdir(base_dir): print(目录不存在, filesys.stderr) return 1 for filename in os.listdir(base_dir): filepath os.path.join(base_dir, filename) if os.path.isfile(filepath): ext os.path.splitext(filename)[1].lstrip(.) if not ext: continue target_dir os.path.join(base_dir, ext) os.makedirs(target_dir, exist_okTrue) shutil.move(filepath, os.path.join(target_dir, filename)) return 0 if __name__ __main__: sys.exit(main())这次运行完全自动没有我手动改一行代码。你可能会说这段代码不算复杂但重要的是这条链路能在无人干预的情况下完成“生成—运行—发现错误—修复—再运行”的全过程这种自动化能力可以直接迁移到更复杂的任务上。6. 从工作流到 AI Agent加入任务规划与自动修正6.1 固定工作流与 Agent 模式的差异固定工作流的每一步都是提前画好的比如“生成代码—执行—修复—再执行”对流程稳定、可预测的任务非常高效。但真实开发任务经常没有固定路径你可能只是说“帮我把这个项目的 bug 找出来”AI 需要自己决定先读哪个文件、跑什么命令、根据结果决定下一步。这种动态规划能力就是 Agent 模式。在 Dify 里可以直接使用 Agent 节点给它绑定大模型和工具。工作流进入 Agent 节点后模型会根据任务目标自己选择工具调用顺序调用结果会重新作为上下文输入模型再决定下一步动作。这和固定工作流的最大区别是路径不预设反馈天然闭环。6.2 让 AI 自己决定调用哪些工具为了让 Agent 能真正“做编程”我给 Agent 配置了几个关键工具第一个是execute_python(code)用于运行任意 Python 代码第二个是read_file(path)用于读取项目文件第三个是write_file(path, content)用于写文件第四个是run_pytest(path)用于跑测试。模型在收到“看看这个项目的文件找到可以优化的地方并改掉”这类指令后会先调用read_file读取目录结构再定位具体文件生成优化方案调用execute_python验证语法最后通过run_pytest检查是否破坏已有功能。整个过程模型自己编排比固定工作流灵活得多。6.3 质量门禁人审、单测、CIAgent 再聪明也不能直接把代码合入主干必须给工作流加上质量门禁。我在 Agent 节点之后接了一个“人审”节点具体形式是 Dify 的“暂停”功能或消息通知Agent 生成代码并自测通过后流程暂停下来通过飞书或企业微信通知我审核。我确认代码逻辑没问题后再触发后续的“创建 PR”节点通过 GitHub API 自动提交到远端。即使加了自动化验证人也应该做最终审查。AI 生成的代码容易在边界条件上造假比如异常处理只覆盖了正常路径。把“人审”作为一个正式节点放进工作流不是拖慢进度而是给自动化加一道安全保险。让 AI 自己决定工具调用没问题让 AI 自己决定是否发布至少现阶段我不同意。7. 我在搭建过程中踩过的坑和最后一点建议7.1 上下文越长不代表越好初期我总喜欢把整个项目文件一股脑塞给模型希望它理解全貌后再写代码结果往往是输入 token 爆表、输出质量下降模型抓不住重点回复里全是正确的废话。后来我改成“只给相关文件的摘要”通过检索和依赖分析只把当前任务涉及的文件内容送进上下文效果立刻改善。工作流里的上下文管理核心不是越长越好而是把相关信息放到该放的位置。7.2 别把工作流做成单线程第一版工作流把一个完整任务的多个子模块串行执行效率很低。后来我在任务拆解节点后加了并行分支几个子任务同时走不同的 LLM 节点生成代码最后再汇合到一个合并节点。Python 的asyncio在本地并行执行时很好用Dify 也支持并行的分支设计。同步改异步之后同样一批任务耗时少了将近一半。7.3 成本与频率控制AI 编程工作流比单次问答更容易产生 token 消耗因为每一轮修复都要重新调用模型。我的应对策略有两个第一在工作流中设置最多 2 轮自动修复超过直接进入人工第二在提示词里明确要求“一次写好减少迭代”。成本控制本质上是个预期管理你要清楚每次运行大概会花多少钱可以在 Dify 的日志里看每个节点的 token 消耗定期复盘哪个环节最费。7.4 把 AI 当成副驾驶而不是自动驾驶以我自己的体会来说AI 编程工作流真正带来价值的地方不是让 AI 写 1000 行代码而是把“写—跑—错—改”的周期压缩到分钟级让我能把精力集中在需求定义、架构决策和代码审查上。你会发现自己更像一个产品经理和代码审查者而不是打字员。这种转变需要适应但一旦习惯了效率提升是很直观的。最后再分享一个我一直在用的技巧所有工作流节点都先小步调试再串联跑通千万别一口气搭一个十几个节点的复杂链路。每加一个节点跑一次测试出问题立刻定位这才是让 AI 编程工作流真正稳定的关键。