说实话用 AI 编程最核心的一件事不是提示词写得多花哨而是把“AI 编程工作流”这条链路理顺。同样是让 AI 写代码有人一个下午能交付一个能跑的功能模块有人折腾三天还在原地打转差别基本不在模型而在流程。我这一年把 AI 编程从“聊天玩具”真正用成生产力靠的就是沉淀出三套可以反复复用的工作流单点功能开发、项目级多智能体协作、存量代码审查与重构。它们覆盖了我日常差不多 80% 的编码场景不管是自己写工具脚本还是帮团队搭 Dify 工作流、Coze 工作流这类偏业务侧的自动化背后的脑回路完全一样。下面我把它们逐个拆开能直接抄的提示词模板和步骤都会给到位你可以理解为这是一份“AI 辅助开发的 SOP”。1. 先搞清边界不是所有代码任务都适合同一个流程我见过很多人失败是因为拿“写一个完整项目”这种需求直接对着 AI 开火结果上下文越聊越长代码越改越散最后干脆推倒重来。问题不是模型不够强而是没分清任务类型硬套了错误的流程。1.1 三类高频任务分别对应三种协作模式我日常接触到的 AI 编程任务基本可以分成三类各自的协作方式完全不同任务类型典型表现对应的 AI 协作模式单点功能开发写一个脚本、一个函数、一个 SQL解决某个明确小问题需求澄清 生成 运行反馈的闭环项目级开发涉及多个文件、数据库、接口设计比如一个带前端的 Web 服务多智能体编排角色各管一摊存量代码维护改别人留下的老代码、补测试、做重构不能破坏现有功能审查先行测试兜底小步重构为什么要区分因为 AI 模型的上下文窗口是有限的。单文件小任务你让 AI 一次性生成然后立刻跑起来效率最高项目级任务如果指望一个会话从头写到尾后面需求一多前面早就忘了细节就会出现“后改的代码和前面的 API 对不上”这种让人崩溃的问题存量代码改造核心约束是不能改坏行为所以必须先把“行为”用测试固化下来再让 AI 动手。1.2 AI 编程翻车通常断在工作流中间举个很常见的例子。你让 AI“写一个待办事项应用”它咔咔给你生成一个大概几百行的 Demo看起来什么都齐全。但你一运行发现数据库表没建、依赖没装、端口被占用于是你把报错丢给它它改了一处另一处又崩。几次往返之后它自己也开始糊涂甚至开始改前面已经正确的代码。这个现象背后的原因一句话模型是在概率空间里生成合理文本而不是在逻辑空间里严格推导程序。它对“当前上下文”负责不对“整个项目”负责。所以你的流程必须把大问题切成小问题每一步都有明确的输入输出让 AI 始终在一个有限范围内工作。理解了这一点再来看那三套工作流你会觉得顺理成章。2. 工作流一需求澄清到反馈修订的“单点开发闭环”这是使用频率最高的一套流程适合“写个脚本处理一堆文件”“算个数据”“调个接口”这类目标清晰的小任务。核心就三步把需求讲清楚生成后先跑通报错时给足上下文。2.1 把一句话需求写成“角色 任务 约束”的提示词大多数人让 AI 写代码是这么说的“帮我写一个批量重命名文件的程序。”这个需求丢出去AI 能给你写出八种不同方向的代码因为“重命名”的规则、文件类型、操作系统、是否需要确认、是否要处理冲突它全都不知道。所以第一步不是让 AI 写代码而是逼自己把需求写完整。我常用的模板是你是一名资深 Python 工程师。请帮我完成以下脚本 任务扫描指定目录下所有 .md 文件读取每个文件中的第一个一级标题# 开头 如果一级标题存在则将文件名重命名为“标题.md”并保留原文件所在目录不变。 输入待处理目录路径 输出逐个打印重命名前后的文件名 约束 1. 文件名包含非法字符/ \ : * ? |时自动替换为下划线 2. 如果目标文件名已存在则保留原文件名不覆盖 3. 使用 pathlib 实现不依赖第三方库你看角色、任务、输入、输出、约束全齐了。拿这个提示词去跑生成出来的代码基本八九不离十。这个方法可以套用到任何小需求上本质是让 AI 在一个“封闭问题”里作答而不是在开放式问题里猜你的心思。2.2 生成之后别急着复制先让 AI 解释关键逻辑哪怕提示词写得很清晰我也建议你在拿到代码之后加一句“解释一下这个脚本的关键逻辑特别是冲突处理那块是怎么判断的。”这一句看起来多余但价值很大。AI 一旦开始解释自己的代码就等于在执行一次逻辑自检很多生成时埋下的“错误假设”会在这个环节暴露出来。比如上面这个重命名脚本AI 可能会默认只处理当前目录不递归子目录或者在编码上没考虑中文文件名。你听完解释就会发现“等一下我要的是递归扫描。”还有一个小技巧如果脚本涉及文件覆盖、删除、网络请求这类高危操作一定让 AI 先把“安全检查点”列出来确认无误后再真正运行。脚本类任务出问题往往不是逻辑多难而是边界情况没想过比如目标文件名已存在、路径不存在、没有读权限。AI 不是想不到而是你如果不在提示词里强调它会默认忽略。2.3 报错反馈的正确姿势把现场信息一次性给齐代码跑起来之后报错是最常见的卡点。我见过很多人往对话窗口里丢一句“运行报错了”然后就没了。AI 没有上下文只能盲猜。正确做法是提供一个结构化的报错反馈。我的习惯是运行你刚才生成的代码后出现以下报错请分析并修复。 操作环境Windows 11 / Python 3.11 / 在 PyCharm 终端运行 报错信息 完整贴入 Traceback不要截断 输入文件示例文件名是“读书笔记AI 工作流.md”包含一级标题“# 如何搭建 AI 编程工作流”关键在于两点一是完整贴报错Traceback 能精确指出哪一行、哪个类型、什么原因二是给一个最小的可复现输入让 AI 能理解触发条件。很多所谓的 AI 写代码“越修越坏”其实都是因为反馈信息太稀碎AI 每一轮都在重新猜现场。这一步循环两三轮之后单点任务基本就可以收工了。别贪多功能跑通、边界处理过一遍就够了。3. 工作流二多智能体编排的“项目级开发流”到了多文件项目比如带数据库的 Web API、前后端联动的小系统一套点对点的对话流程就不够用了。这时候我会把一个项目拆给多个“AI 角色”分担每个角色一个独立会话按固定的交付物顺序协作。3.1 为什么项目级任务必须拆成多个 Agent直接跟一个 AI 说“帮我写一个记账系统”它大概率会给你一个“看起来完整、实则没法二次开发”的大杂烩。因为项目里的每个环节——数据结构、业务逻辑、接口设计、异常处理——都有自己的上下文混在一起聊后面的内容会把前面的细节“冲淡”。打个比方一个五十层的项目你需要的是一个能记住每一层图纸的协作团队而不是一个记忆力有限但什么都要插手的包工头。多智能体编排的核心思路就是让每个会话只负责一个局部通过结构化产物把上下文传递下去。这不是玄学是上下文隔离。如果不想用 Dify、Coze 这类现成的 AI 工作流平台也可以用最原始的方式手动开四个对话分别扮演不同角色。如果你在 Dify 或 Coze 里搭过工作流你会发现本质是一回事——每个节点就是一个小模型上一个节点的 output 是下一个节点的 input。3.2 四类角色每人只干一件专业事我常用的项目级角色划分是架构师、数据模型师、接口开发者、测试验证者。每个角色都有固定的输入输出角色输入输出架构师 Agent产品需求描述技术方案文档含模块划分、接口清单、依赖选择数据模型 Agent架构师的模块划分数据表结构或 Pydantic 模型定义接口实现 Agent数据模型 接口清单具体实现代码按照约定路径交付测试验证 Agent完整代码 运行环境信息测试用例、验证报告、修复建议每个角色的提示词开头我都固定写清楚“你是项目的 XX 角色本次输入是上游交付物请只聚焦于你的职责范围不要修改其他模块的设计。”3.3 一个实战案例用四角色流程写记账 API我来用一个极简的“记账 API”拆解整个过程。假设需求是记录每笔支出的分类、金额、时间支持按月份查询总支出。第一步架构师 Agent 会给出这样的方案FastAPI 提供 REST 接口SQLite 存储Pydantic 做数据校验模块划分是models.py、schemas.py、routers.py、database.py。第二步数据模型 Agent 根据上面的方案输出这样的数据定义# models.py from sqlalchemy import Column, Integer, String, Float, DateTime from sqlalchemy.ext.declarative import declarative_base from datetime import datetime Base declarative_base() class Expense(Base): __tablename__ expenses id Column(Integer, primary_keyTrue, indexTrue) category Column(String(50), nullableFalse) amount Column(Float, nullableFalse) note Column(String(200), default) created_at Column(DateTime, defaultdatetime.now)# schemas.py from pydantic import BaseModel from datetime import datetime class ExpenseCreate(BaseModel): category: str amount: float note: str class ExpenseOut(BaseModel): id: int category: str amount: float note: str created_at: datetime class Config: from_attributes True第三步接口实现 Agent 拿到上面的文件继续实现 router把“创建消费”“按月统计”这两个接口写出来。这时候因为数据模型已经定死接口层不太容易跑偏。第四步测试验证 Agent 会读完整套代码给出测试用例并实际运行一轮接口调用把报错反馈给接口实现 Agent 去修。整个过程不需要几个 Agent 互相“理解”只需要它们认同一份接口契约。这就是我常说的多智能体协作交接的是文档不是对话。3.4 接口契约怎么定才能让不同 Agent 不“鸡同鸭讲”最容易出的问题是上游输出和下游输入对不上。比如架构师说“用 FastAPI”数据模型 Agent 却给你生成 Django 的 Model。要避免这个问题我会在第一个会话里花一点时间把最基本的约束固定下来然后把这个约束原封不动带到每个 Agent 的提示词里。提示词里我通常要求建筑构师 Agent 输出一段“技术决策摘要”固定包含编程语言、Web 框架、ORM、目录结构、外部依赖清单。然后后面的角色提示词直接粘贴这段摘要后面再也没出现“帮我想想用什么框架”这种填空式对话。如果你用 Coze 或 Dify 这类工作流平台搭思路是一样的把上游节点的输出字段作为下游节点的输入变量每个节点只处理自己关心的字段不把整个项目上下文全塞进去。4. 工作流三给存量代码“做体检”的审查与重构流前面两套流程更多是从零写新代码。但在真实工作里接触更多其实是别人留下的老代码需求是“帮我看看哪里有问题”“帮我重构一下这个模块”。这种任务最难的地方不是写代码而是不能把原本能跑的东西改坏。所以我每次动手前都会把“测试”和“审查”提到最前面。4.1 先补测试再动手让 AI 根据函数签名生成边界用例很多开发者自己写测试都觉得麻烦但面对存量代码测试不是为了好看而是给重构买保险。我会让 AI 先干一件非常具体的事阅读我提供的 module.py找出其中所有公开函数。请为每个函数生成 pytest 测试用例 要求覆盖以下场景正常输入、空输入、边界值None、空字符串、0、负数、超大数字、 异常输入。测试代码中不得修改原模块的实现逻辑。把代码贴进去之后我会先跑一轮测试。这一步不一定要求全绿但能暴露很多隐藏问题。比如某个函数隐含地认为入参字符串非空、某个函数在除零时会崩——这些信息比代码本身更值钱它们是后续重构时要重点保护的“行为特征”。4.2 把代码评审变成 AI 可执行的 ChecklistAI 代码审查要有效不能只说“帮我看看代码质量”而是要给它一张明确的核查表。我常用的审查维度如下请按以下维度审查这段代码每个维度给出具体位置和修改建议 1. 硬编码是否有不该写死的路径、端口、密钥 2. 异常处理是否有可能抛出但没有捕获的异常 3. 资源释放文件、网络连接、数据库连接是否都正确关闭 4. 类型安全参数和返回值是否有明确的类型标注 5. 可读性是否有命名不清、函数过长、重复代码 6. 性能风险是否有明显低效的循环或重复查询审查结果我要求它以表格形式输出位置、问题等级、问题描述、修改建议。这样拆出来的结果可以直接当 backlog 用。说实话AI 在找“变量命名不清”“缺少异常处理”这类问题上的表现比大多数不加checklist 的职责描述都要靠谱。4.3 重构的落地方式一次只动一个结构让测试全程护航老代码的重构最忌讳“推倒重写”。我的做法是把重构拆成若干个“原子操作”每个操作完成之后立刻跑一遍测试。比如一个 200 行的函数里面既有数据解析又有业务计算又有写文件。我会先让 AI 基于“保持行为一致”的大前提给出一个拆分方案请将这个函数按单一职责拆分成 3 个小函数并给出每个函数的功能说明、输入输出签名。 注意拆分后的代码必须保持功能完全一致暂不修改任何业务逻辑。请先输出拆分方案 不要急着生成完整代码。拿到方案后我确认拆分合理再让它一步步生成每个函数生成一个函数就跑一次测试。很多时候 AI 在拆分时会不自觉“顺手优化”掉一些看起来多余的逻辑比如把某个防御性判断删掉。测试的作用就是在这里兜底——它能让这些隐性行为变化立刻暴露出来。4.4 审查流里的一个隐藏收益顺手补文档存量代码还有一个通病就是没注释、没文档。审查完一轮后我会追加一个很简单的指令请为每个公开函数生成 docstring说明功能、参数、返回值、异常并使用项目现有的注释风格。有了 docstring后面再让 AI 改这部分代码它自己读上下文都轻松很多。相当于用一次低成本操作把老代码的“可 AI 维护性”也养起来了。5. 把这三套工作流沉淀成你自己的“模板仓库”流程和方法论如果没有固化成模板过两周就丢了。这一步是把前面所有经验变成“资产”的关键也顺便解决“编程学习记录”“AI 编程提示词”这类长期积累的问题。5.1 按任务类型建立提示词模板仓库我建议在本地建一个纯文本仓库比如用 Obsidian 或者直接放 GitHub 私有仓库把常用的提示词按类型归档。我自己的目录大概是这样的ai-coding-templates/ ├── single-feature/ │ ├── script-generation.md │ ├── error-feedback.md │ └── sql-generation.md ├── project-collaboration/ │ ├── architect-agent.md │ ├──>