1. 内容整体设计与思路拆解1.1 为什么要搭一套“AI 编程工作流”先说一个我观察到的现象身边很多朋友用 AI 辅助编程状态基本是“打开 ChatGPT 或 Cursor贴一段报错信息复制返回的代码再黏回编辑器跑一下报错再贴回去……”循环往复效率确实有但远没到“工作流”的程度。真正让我觉得 AI 编程开始改变开发方式的是一次真实经历我给一个 Python 脚本加功能需求本身不复杂但牵扯到参数校验、异常处理、日志记录三个环节。我自己手写大概要半小时而用 AI 工具从拆解需求到生成可用代码前后不到十分钟。关键不在于“AI 写了多少代码”而在于我把整个任务拆成了几个节点让 AI 在各个环节分别介入而不是“一次生成一大坨”。这就是“AI 编程工作流”和“用 AI 写代码”的本质区别。前者是一个可复用、可掌控、可调试的生产流程后者只是“零散地求助”。从零搭建一套 AI 编程工作流核心要解决三件事明确 AI 在哪些环节介入——需求拆解、代码生成、代码审查、测试、提交信息生成等给 AI 提供足够的上下文——项目结构、代码风格、依赖关系、目标描述建立反馈回路——让 AI 生成的代码经过编译、测试、人工审查把问题再喂回给 AI。这套东西听起来有点“重”似乎只有大团队才需要。但实际恰恰相反个人开发者、独立项目、甚至学生做课程设计搭建一条轻量级的 AI 编程工作流的收益是最明显的。因为个人项目的上下文往往只在开发者脑子里而 AI 恰恰能帮你把这些“隐性知识”逐步显性化——通过文档、注释、测试用例、提示词模板沉淀下来。1.2 工作流的核心节点拆分先画一张“脑内地图”搭建工作流之前不要急着选工具。先把一个编程任务从开始到结束的所有环节列出来再标出 AI 可以在哪些环节介入。这是我目前常用的一套拆解维度参考了市面上 Cursor、GitHub Copilot、Dify 工作流等工具的常见做法也结合了自己踩坑后的调整阶段核心任务AI 介入程度典型工具需求拆解把模糊想法变成可执行的任务描述高ChatGPT、Claude、DeepSeek方案设计技术选型、模块划分、接口定义中高Cursor、Copilot Chat、Dify代码生成按模块生成代码片段或整个文件高Cursor、GitHub Copilot代码审查静态检查、逻辑漏洞、风格检查中Copilot Review、AI Code Review Agent测试生成单测、集成测试、边界用例中高Cursor pytest、Jest提交与文档生成 commit message、README、注释中AI 辅助提交工具我强调“脑内地图”是因为很多人一上来就追求“全自动”希望 AI 从需求直接生成整个项目。实际上至少在当前阶段这是不现实的也是最容易翻车的。我自己尝试过用 AI Agent 自动写一整个模块结果它自己给自己“发明”了一个不存在的 API最后排查浪费了两个小时。更稳妥的做法是**把任务拆成原子节点每个节点有明确输入输出AI 在节点内部发挥能力但节点的顺序和验收标准由人掌控。**这就是工作流的意义——它不是替代你思考而是把思考的每个环节都做得更快。1.3 为什么选“提示词 工具链 自动化脚本”三层结构我曾经试过只用一个工具比如纯 Cursor跑完整条链路。体验是单点很强但长链路非常别扭。Cursor 的聊天窗口很好用但你很难把“项目级别的上下文”一次性喂给它而且它的会话记忆经常断片。后来我改用“提示词 工具链 自动化脚本”三层结构才把整套流程稳定下来。提示词层把通用的任务写单测、写 commit message、做 Code Review固化成模板无论用的是 Cursor、Copilot 还是其他模型直接套模板就能获得稳定输出。工具链层编辑器用 Cursor 或 VS Code Copilot聊天模型用主流的 Claude 或 DeepSeek流程编排类任务用 Dify 或 n8n 这类工作流工具把多个 AI 调用串成自动化流水线。自动化脚本层用 Python 或 shell 脚本把重复动作脚本化比如自动收集项目结构、自动把生成的代码写入文件、自动跑测试并把结果返回给 AI。这样的结构好处很直接工具可以换提示词模板和脚本是沉淀下来的资产。今天用 Cursor明天换成其他编辑器工作流不会崩塌。这一点非常重要因为 AI 编程工具迭代太快了几乎每隔几个月就有新的“最佳实践”出现。如果你把工作流绑死在某个单一工具上等于把鸡蛋放进了快速漂移的篮子里。2. 核心细节解析与实操要点2.1 工具选型别盲目追新先看三个硬指标“工欲善其事必先利其器”这句话被说烂了但选工具确实有讲究。选型时我一般只看三个硬指标不看宣传口号。第一上下文管理能力。AI 编程工具最大的瓶颈是上下文窗口。一个中型项目可能有几百个文件模型不可能全部看完。好的工具应该支持“按需加载上下文”——比如只把当前文件、相关依赖文件、项目结构树喂给模型而不是一股脑全塞进去。这方面 Cursor 做得不错它的“Codebase”功能和符号索引可以精准召回相关代码GitHub Copilot 的“workspace”也在朝这个方向走。第二可被脚本化嵌入。工作流意味着 AI 不是孤立的聊天对象而是流水线上的一环。这就要求工具提供 API 或 CLI能被自动化脚本调用。比如 OpenAI 的 API、Anthropic 的 API或者本地部署模型都能通过代码调用从而嵌入到测试、构建、提交的流程里。纯 GUI 工具比如某些网页版 AI 编程助手在这个维度上几乎不可用只能手动复制粘贴。第三模型可替换性。我早期用某个国产模型效果一般后来换成 Claude 的 API效果立刻提升。如果工具把模型锁死迁移成本就很高。Cursor 支持切换不同模型n8n 和 Dify 天然支持多模型接入这类工具长期来看更值得投入。2.2 上下文工程决定 AI 输出质量的隐藏杠杆很多人抱怨 AI 生成的代码“答非所问”或“完全没有参考项目风格”根因基本都在上下文。我给 AI 喂上下文遵循“金字塔原则”从宏观到微观从稳定到易变。具体来说一份标准的项目上下文包包含以下内容项目根目录下的 README.md 或项目说明文档——让 AI 知道这个项目是做什么的项目的目录结构树——让 AI 知道文件组织方式避免“发明”不存在的路径当前任务的详细描述——包括需求背景、验收标准、约束条件比如“不要修改已有函数签名”“保持向后兼容”相关代码文件的完整内容或关键片段——让 AI 知道它要改动的代码长什么样项目的代码风格约定——缩进、命名、注释风格等。我在 Cursor 里实践时发现一条很实用的技巧是在项目根目录放一个 AGENTS.md 或 CLAUDE.md 文件内容是项目的全局约定比如“本项目使用 Python 3.11 FastAPI代码风格遵循 PEP8所有函数必须写 docstring”。Cursor 和 Claude Code 这类工具会自动加载这个文件把它作为全局上下文的一部分。这个文件相当于给 AI 一份“入职手册”效果立竿见影。有一次我花半小时写了一份 AGENTS.md之后 AI 生成代码的风格契合度和一次通过率显著提升省下的时间远超那半小时。2.3 提示词模板把“一次性对话”变“可复用资产”如果你每次都临时组织语言让 AI 干活那你的工作流等于没搭。我的做法是把常用任务固化成提示词模板放在项目目录下或个人的笔记库里。这里分享几个经过实际使用、调整后的模板大家可以直接“抄作业”但强烈建议按自己的项目特性改一版。第一个是“代码生成”模板。核心要素是角色设定、任务描述、约束条件、输出格式四个块。我的固定版本类似你是这个项目的资深开发者请根据以下需求完成代码编写。 任务{详细描述需求} 技术栈{项目技术栈} 参考文件{相关文件路径} 约束{编码规范、性能要求、兼容性要求} 输出请返回完整的代码块并在代码块外附上简短的实现说明包括关键设计决策和潜在风险。第二个是“Code Review”模板。这个模板我用的频率很高每次合入代码前都会跑一遍。核心是要求 AI 同时扮演“审查者”和“开发者”两个视角请对以下代码进行审查重点检查逻辑正确性是否存在边界条件遗漏、空值未处理、资源未释放等问题安全性是否存在注入、越权、敏感信息泄露等风险可维护性命名是否清晰、函数是否过长、职责是否单一性能是否存在不必要的循环、重复查询、内存泄漏 输出格式按“问题—位置—严重程度—修改建议”的表格形式输出。第三个是“单测生成”模板。这个模板的关键是让 AI 理解“被测函数的行为契约”而不是“看着函数瞎猜”。所以我会在需求描述里明确输入范围、预期行为、异常场景请为以下函数生成 pytest 单元测试。 函数签名与实现{代码} 预期行为{正常输入输出、边界值、异常输入} 覆盖率要求核心分支覆盖率需达到 80% 以上。 输出完整的测试代码并标注每个用例对应的测试场景。这三个模板基本覆盖了日常开发中 80% 的 AI 辅助场景。模板的意义在于它把不确定的对话变成了确定的输入输出协议AI 的输出质量和稳定性都会上一个台阶。3. 实操过程与核心环节实现3.1 实操环境准备一小时内搭轻量级工作流原型我先交代一下实操环境。我用的主力机器是一台 MacBook ProM1 Pro 芯片16GB 内存系统是 macOS代码主要涉及 Python 和 TypeScript。这套流程在 Windows WSL 下同样可行只是部分命令需要微调。第一步准备工具链。我装了 Cursor 作为主力编辑器同时安装了 Python 3.11、Node.js 18、Git 以及常用的 lint 工具ruff、eslint。这一层没什么特殊重点是第二步——配置 AI 辅助脚本。我写了一个 Python 脚本ai_task.py作用是向模型 API 发送请求并自动把返回结果写入指定文件。这样 AI 生成的代码可以直接落到项目里而不是复制粘贴到终端。脚本本身很简单核心逻辑就几行import os from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL) ) def ai_generate(system_prompt, user_prompt, output_fileNone): response client.chat.completions.create( modelos.getenv(LLM_MODEL, gpt-4o), messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt} ], temperature0.2 ) content response.choices[0].message.content if output_file: with open(output_file, w, encodingutf-8) as f: f.write(content) return content这个脚本的价值在于它为工作流提供了编程接口。我可以把 AI 调用嵌入到任何自动化流程里比如“修改了某个文件后自动让 AI 生成对应的单测”。脚本里的temperature设成 0.2因为编程场景需要尽可能确定性的输出温度太高容易“发散”。第三步配置 Git 钩子。我们在.git/hooks/pre-commit里加了一段逻辑提交前自动跑 lint 和测试如果没有通过就阻止提交。AI 的作用在这里是“自动修复”如果 lint 失败脚本会把错误信息发送给 AI让 AI 返回修复补丁。这个环节我强烈建议加上因为它让工作流有了“自动反馈”的闭环。3.2 端到端实战从需求描述到可用代码的全流程这一节我拿一个小任务走一遍完整流程。任务背景我给一个 FastAPI 项目加一个“用户注册”接口要求邮箱格式校验、密码强度校验、重复邮箱检查注册成功后返回 JWT Token。第一步我打开项目目录用脚本自动生成项目结构描述find . -type f -name *.py | head -30 tree -L 2 -I __pycache__|.git拿到结构后我把 AGENTS.md 内容和任务需求拼在一起调用ai_task.py生成初始代码。生成结果是一段完整的auth.py模块包含路由、校验逻辑、JWT 生成函数。整体可运行但有一个问题它“假设”项目里已经安装了python-jose实际上没有。这类“想当然的依赖”是 AI 生成代码最常见的坑。第二步把生成代码写入文件手动核对依赖。我检查了requirements.txt补上python-jose和passlib。这个过程不需要 AI 介入但很重要——AI 生成代码不能替代环境管理。依赖缺失用pip freeze对比项目现有依赖即可发现。第三步生成测试。我调用了“单测生成”模板把auth.py的完整代码发给 AI让它生成 pytest 测试。生成结果包含五个测试用例正常注册、邮箱格式错误、密码过短、重复邮箱、未授权访问。我跑了一下四个通过一个失败——重复邮箱的测试因为数据库 mock 配置不对没有真正触发唯一约束。这是 AI 生成测试的典型问题它理解了业务逻辑但不理解你的测试基建。解决办法是把项目里已有的测试配置文件比如conftest.py中的 fixture作为上下文补充给 AI再让它重新生成。第四步Code Review。我用 Review 模板把代码发给 AI结果发现它指出了两个有价值的问题一是 JWT 的exp过期时间写死了 30 分钟没有从配置读取二是密码哈希算法用的是 MD5因为我没在提示词里指定AI 默认选了一个存在安全隐患。我根据建议修改了代码并把这两条规则写进 AGENTS.md。以后再生成新模块AI 就会默认使用 BCrypt 和从配置读取过期时间。3.3 Dify 工作流把多步 AI 调用编排成自动化流水线如果只是个人开发前面的脚本方案已经够用。但一旦任务链条变长比如“收到一个需求 → 拆解 → 生成代码 → 评审 → 测试 → 文档”脚本会变得难以维护。这时候就轮到工作流引擎出场。我尝试过 Dify 和 n8n 两个主流工具。Dify 的优势是内置了 Prompt 编排、知识库和模型管理特别适合构建“以模型为中心”的流程n8n 的优势是连接器丰富能对接数据库、Slack、GitHub 等外部系统。搭建 AI 编程工作流我的推荐是核心用 Dify外围用 n8n 补自动化。举一个我在 Dify 里搭的“需求拆解助手”为例。它的输入是一条模糊需求比如“给用户中心加一个找回密码功能”输出是结构化的任务清单包含功能点拆解、涉及模块、接口定义、验收标准四部分。实现方式是在 Dify 里配置一个 LLM 节点系统提示词是“你是一名资深产品经理和架构师请将模糊需求拆解为可执行任务”用户提示词是输入的需求文本。再把输出连接到“代码生成”节点它会把任务清单转成 Python 代码。Dify 的“工作流”画布非常直观拖拽节点即可不需要写胶水代码。实际操作中我把 Dify 工作流输出接到 GitHub 的 Webhook 上当 Issue 被创建时Dify 自动跑一遍“需求拆解→代码生成→单测生成”生成的结果作为评论发布到 Issue 下面。这样团队其他人提需求时AI 能先给一个初版方案人再介入调整。这种“半自动”模式比全自动更实用因为 AI 生成的代码还是需要人来验收。4. 常见问题与排查技巧实录4.1 上下文丢失AI 忘记项目背景怎么拉回来这是长期使用 AI 编程工具最让人抓狂的问题。我在用 Cursor 时经常遇到上午还在正常生成项目代码下午新建一个对话AI 就“失忆”了连项目用的框架都答错。解决办法有几种按有效性排序把 AGENTS.md 文件放在项目根目录因为 Cursor 和 Claude Code 会自动加载它这是成本最低、效果最好的方案在每次大任务开始时主动把项目结构树和关键文件片段作为上下文塞进去代价是消耗 token但比 AI 乱猜强得多把提示词模板做成“自带上下文”的版本比如生成代码前自动附上“本项目技术栈Python 3.11 FastAPI SQLAlchemy”把关键背景写死在模板里。上下文丢失还有一个隐蔽场景AI 在长对话中自己“漂移”刚开始提到某个约定聊了十轮之后就忘了。我一般在每轮关键交互中刻意重复一次核心约束宁可啰嗦不让模型放飞。4.2 幻觉 API 与不存在的依赖AI 生成代码时“发明”不存在的函数、模块、API是最常见的问题。我之前遇到过一个经典案例AI 生成了一段调用from utils.helpers import data_to_tree的代码但项目里根本没有utils这个包。原因是它“推算”项目应该有这样一个工具模块然后就直接生成了调用。排查这类问题第一步是让 AI 提供“实现依赖”清单。我的提示词模板里明确要求“列出你生成代码所依赖的所有第三方库和项目内模块”。这样至少能提前暴露问题。第二步是本地验证跑一遍python -c import 所有依赖快速确认模块是否存在。第三步是配置 lint 和类型检查工具比如 mypy它们在静态分析阶段就能抓出一部分不存在的属性访问。还有一个更根本的解法给 AI 提供项目结构作为约束。如果 AI 能清楚地看到项目里没有utils模块它就不会凭空调用。这就是为什么我一直强调上下文工程是工作流的核心环节。4.3 提示词写不清AI 就“自由发挥”我试过很多次同一任务提示词写得好不好输出质量天差地别。最常见的反面教材是“帮我写一个用户登录功能”这种描述对 AI 来说信息量太少——是 Web 登录还是 API 登录用 Token 还是 Session密码怎么存要不要验证码AI 只能按照它在训练数据里最常见的“用户登录”模板来猜。我总结了一套“提示词好写”的方法核心是把需求写成验收标准的格式。比如请实现用户登录接口。验收标准输入邮箱和密码返回 JWT Token邮箱格式必须符合 RFC 5322 标准密码错误超过 5 次后账号锁定 30 分钟所有接口返回格式统一为 { “code”: int, “data”: object, “message”: str }。这种写法把 AI 的“自由发挥空间”压缩到最小输出结果就和预期更贴合。好的提示词不是“聊得更细”是“把需求讲得更像合同”。4.4 工作流跑“飞”了AI Agent 自动执行失控怎么办很多人搭完工作流后喜欢把权限全放开让 AI Agent 自动改文件、自动跑测试、自动提交代码。这个想法很危险。AI Agent 尽管能力在提升但对“意图”的理解仍然有限。有一次我让 Agent 自动修复一个 lint 错误它没有去修改原始代码而是直接在别的文件里加了一个忽略 lint 的配置问题确实“修”了但项目被埋了一个雷。我的建议是工作流里的人和机器要各管一段。AI 负责生成和修改代码块人负责审核和确认合入。自动化节奏最多到“AI 生成 diff → 人 review diff → 人工合并”这一步。真正的无人值守现阶段只适合用在低风险场景比如生成文档、生成 commit message、翻译注释。涉及核心业务逻辑千万不要全自动。4.5 把热词里的“异步编程、无限制聊天”等概念串进来从《全球热词网络》和您给出的热搜词里散落着“异步编程”“无限制 AI 聊天”“Dify 工作流”“AI Agent”等术语。这里顺便做个澄清和串联帮大家理解它们之间的关系。“异步编程”主要指 Python 的 async/await、Node.js 的 Promise/async 模式它本身就是编程技能的一部分和 AI 编程工作流是两个层面。AI 工作流的核心价值在于当你的业务代码涉及大量并发 I/O比如同时调用多个模型的 API异步编程就是让你工作流高效跑起来的基础能力。我在搭 Dify 工作流时有一步要同时向三个模型发起请求做比价用同步方式要串行等待几十秒改成 asyncio.gather 后总耗时直接压到最长单次请求的时间。这个细节在工作流编排时很值得留意。“无限制 AI 聊天”这类关键词本质上是人们对“对话式 AI 不被局限”的期待。但聚焦到编程场景我更推荐大家建立“有限制的生成”意识——AI 编程不是要它“无限制自由发挥”而是要它在约束下高质量输出。我在提示词模板里设置的各种约束条件技术栈、命名规范、接口格式就是在给 AI 画“安全区”。在这个区域内它越自由越好出了区域就该人接管。“AI Agent”则代表了下一阶段的形态不只是“问答”而是“执行”。GitHub Copilot 的 Agent 模式、Cursor 的 Agent 模式、以及 AutoGPT 类工具都能自主执行多步骤任务。但正如前面所说现阶段 Agent 的“自动”是有边界的。我建议把它用在“输出初稿”环节而不是“最终决定”环节。5. 常见问题速查表这部分我把实操中遇到的高频问题整理成一个速查表方便大家在工作流出问题时快速定位。这些内容来自我自己的排障经验也参考了社区里其他开发者的实践总结。问题现象根因分析快速排查步骤解决方案AI 生成代码风格和项目不一致缺少代码风格上下文检查 AGENTS.md 是否配置在 AGENTS.md 中写明缩进、命名、注释规范AI 生成了不存在的 API上下文里缺少项目结构检查提示词是否给出相关文件清单提供项目结构树和关键文件路径作为约束多次对话后 AI 遗忘需求上下文被对话历史冲淡检查对话轮数和 token 消耗每轮关键交互重复核心约束或者新开会话并重述完整上下文测试覆盖率远低于预期提示词里没写覆盖率要求检查单测模板是否包含覆盖率指标模板中明确“核心分支覆盖率不低于 80%”生成的代码依赖缺失AI 按训练数据推测依赖运行pip list对比 requirements.txt提示词中要求 AI 列出依赖清单人核对后安装工作流自动化过度导致错误提交自动化链路权限过大检查流程中是否有“人审”节点限制自动化到 diff 生成合入前由人审查AI 生成代码后项目构建变慢可能引入了不必要的重型依赖检查生成的 import 和依赖手动删除冗余依赖把常用依赖白名单写进 AGENTS.md这个表格看着简单但每条都是从实际事故里提炼的。比如“测试覆盖率”那条我早期用 AI 生成单测生成的用例看起来数量不少但核心逻辑分支基本没覆盖到。后来在提示词里直接加上覆盖率门槛AI 才会去认真构建边界用例。6. 从个人工作流到团队协作的扩展实践6.1 团队协作时的提示词与模板复用个人工作流跑顺了之后很自然的下一步是推广到团队。但这里有个坑团队和个人的工作习惯不同直接套用个人模板大概率会被成员抵制。我在一次小范围推广时收到的反馈是“模板太死板”“不适用于我的场景”后来我调整了策略才逐渐推广开。具体做法是把提示词模板改成“半成品”——提供基础结构允许成员按自己的项目类型修改。同时把 AGENTS.md 作为团队仓库的必交文件新成员入职后通过它快速了解项目约定。效果比我预想的好因为模板的“骨架”保证了输出稳定性“血肉”允许个人调整兼顾了两端。6.2 用 n8n 和 Dify 搭建团队级 AI 工作流如果团队已经有固定的研发流程比如 GitLab Flow 或 GitHub Flow可以把 AI 工作流“挂接”到现有流程上。我在一个中型项目里用 n8n 做了两件事自动生成 Pull Request 描述当开发者创建 PR 时n8n 监听 Webhook调用 LLM 读取 diff 和关联 Issue生成 PR 描述草稿方便维护者快速了解改动省去大量手动书写时间。自动生成 Changelog每次发布 tag 时n8n 收集该版本所有合并的 commit调用 AI 生成一份分类清晰的更新日志按“新增、修复、优化”分组。Dify 那边我搭了几个“内部助手”需求拆解助手、代码评审助手、测试用例生成助手团队成员通过内部网页访问不需要手搓 API。这个模式比每个成员自己开一个 Cursor 会话更好因为助手背后是统一的知识库和提示词模板输出质量稳定。6.3 工作流的持续迭代把“踩坑记录”变成“系统能力”我不主张工作流一次搭好就一劳永逸恰恰相反它的价值是靠持续迭代积累起来的。我的迭代方法是每遇到一个“AI 生成质量翻车”的案例就分析根因然后把应对策略回写进提示词模板或 AGENTS.md。长期积累下来日常工作流会越来越懂项目也越来越懂你的偏好。举个例子有一次 AI 生成的 Python 代码里对数据库连接没有做异常处理导致连接池耗尽。我把这条写进 AGENTS.md“所有数据库操作必须使用 try-except 包裹并在 finally 中释放连接。”之后生成的相关代码几乎不会再犯同类问题。这种“事故驱动”的迭代方式虽然听起来有点被动但效率极高因为每次迭代都有真实场景作为依据。7. 避坑指南三条最重要的实操教训写到这里我想最后放三条“血泪教训”。如果你只想记住上面篇幅中的三句话那就是这三条。第一AI 编程工作流不是让你少思考而是让你把思考分成更小的步骤并让每个步骤都被 AI 加速。真正的高效不是 AI 替你做了多少而是你通过流程设计让 AI 的每一次输出都在朝正确方向逼近。第二上下文是 AI 编程的“石油”但没有结构化的上下文量再多也白搭。一份结构清晰的 AGENTS.md比 10 万字的项目文档对 AI 更有效因为它能把“什么是重要的”直接告诉模型。第三自动化要留“人审”节点。AI 可以做初稿、做检查、做优化建议但“合入”和“决定”这两个动作现阶段一定得由人完成。不要为了追求“全自动”而省略安全阀否则你省下的时间会在后期的排障和返工里加倍还回来。我个人现在的工作节奏是早上打开 Cursor看一眼 AI 自动生成的 PR 描述快速过一遍单元测试结果再处理那几条 Code Review 提醒。这个流程不算炫酷但它稳定、可控、可持续。这也是我为什么建议每一位开发者都花点时间搭建自己的 AI 编程工作流——它带来的不是单次的“代码生成速度提升”而是整个研发节奏和思考方法的系统升级。最后再分享一个小技巧工欲善其事必先利其器但“器”的打磨是持续的过程。每当你觉得“AI 好像变笨了”很可能不是模型的问题而是你的语境或提示词没有跟上当前项目的状态。先检查 AGENTS.md 和提示词模板再考虑换模型——这比频繁切换工具要有效得多。