这几个月我把自己手头的十几个项目全部过了一遍 AI 化改造从最简单的脚本工具到带状态机的 PLC 逻辑模拟再到带数据库的小型业务系统踩的坑比前几年加起来都多。最大的感受是AI 编程根本不是什么“写得一手好提示词”的技术而是一整套从需求到落地、从生成到验证、从单次操作到持续迭代的闭环工作流。很多人拿着 Cursor 或 Copilot 用了一周就放弃说“AI 生成的代码压根不能跑”。我一开始也这样后来把流程重新捋了一遍把每一步该谁干、该怎么干、用什么工具、出什么问题怎么救全部固化下来才真正进入“能用 AI 交付完整功能”的状态。这套东西我整理成了 v1.0又经过一个多月的实战打磨迭代到了今天的 v2.0。这篇我就把 v2.0 完整工作流拆开讲工具怎么选、需求怎么拆、提示词怎么设计、生成之后怎么验证、踩坑怎么排查以及新手从零开始到底怎么走第一步。顺便把最近搜索热度很高的几个点——ai 编程工具对比、ai agent 与 PLC 编程、扣子发送邮件工作流、git worktree 配合 AI 编程这些——一并串进流程里讲明白。这篇文章很长但全部是实操出来的经验不是概念科普你可以直接对照着搭自己的流程。1. 为什么 v1.0 失败了AI 编程不是一个“写代码”问题先讲个真实的翻车经历。我 v1.0 的思路特别朴素需求写进对话框 → AI 生成代码 → 粘贴进项目 → 运行 → 报错再粘贴回去。遇到简单的小工具比如一个 JSON 转 CSV 的命令行脚本这套流程没问题五分钟搞定。但一旦碰到真正的业务代码——有数据库、有权限、有状态转换、要和旧模块对接——立刻崩盘。崩盘的点基本固定在这几个地方AI 不理解项目的既有约定生成的命名风格和项目里完全不是一个体系AI 对业务需求的理解停留在“字面意思”别说隐藏需求连显式的边界条件都会漏AI 生成的代码经常依赖并不存在的第三方库或者用了项目里根本没有的配置项最致命的AI 会一本正经地写出一段结构完整、但逻辑完全是幻觉的代码编译能过功能不对。这些问题在 v1.0 里全是靠人肉兜底解决的。我一度怀疑是工具不行把 Cursor、Copilot、通义灵码、DeepSeek API 全换了一遍发现区别没想象中大。后来我想明白一件事问题不在 AI 工具而在我的工作流是“让 AI 写代码”而不是“让 AI 参与一个工程项目的交付”。代码只是整个链条的下游产物。真正决定代码质量的是上游的需求拆解、上下文组织、约束定义以及下游的验证、反馈、迭代。v1.0 完全跳过了这些把 AI 当成一个“超级粘贴板”当然只能做出玩具。v2.0 的核心变化就是把 AI 编程从“对话框操作”改造成了一条标准化的工程流水线。每个环节都有明确的输入、输出和校验标准。AI 不再是直接写代码的那个人而是流水线上一个非常高效、但也需要被管理的工位。2. 工具选型2025 年最能打的 AI 编程组合怎么配很多人在第一步“选工具”就卡住了。网上讨论度最高的三个软件——GitHub Copilot、Cursor、通义灵码——到底有什么区别DeepSeek 的 API 和 C 知道CSDN 的智能问答产品这类问答型 AI 哪个更适合编程我全部实际用过一段时间直接给结论。2.1 四个主流工具的定位差异先说结论它们根本不是同一类东西放在一起比“哪个好用”是伪命题。工具类型最适合的场景我的实际体感GitHub CopilotIDE 内联补全边写边补单行/小块代码联想补全准、侵入小但对“整页生成”帮助有限CursorAI 原生编辑器大段生成、跨文件重构、对话式改代码上下文窗口大适合“给它一个文件改另一个文件”通义灵码中文场景优先的 AI 编程助手国内团队协作、中文注释/文档生成中文理解好和本地化框架配合顺畅DeepSeek API模型能力输出API接入自己的工具链、批量处理、私有化工作流推理能力在线成本极低适合二次封装你自己的场景应该这样选如果大量时间在写业务 CRUD身边同事也用 GitHub 生态优先 Copilot它对“下一个字符该是什么”的预测能力还是第一梯队。如果经常要改别人的老代码、重构大文件、跨文件理解逻辑上 Cursor。它的“对话 全文上下文 直接改文件”模式比 Copilot 的补全范式高了整整一个维度。如果项目中文文档多、团队习惯中文沟通或者要批量生成注释、单元测试模板、接口文档通义灵码更省心。如果你想搭一套自动化流水线或者把 AI 能力接进内部平台DeepSeek API 是目前性价比非常高的底座。我自己就用它的 API 做了一套“自动 PR 评审机器人”成本可以忽略不计。至于 C 知道这类问答型 AI它们定位是“编程知识问答”适合查某个函数怎么用、某个报错是什么意思不适合直接参与代码生成。真正干活的时候我不会把它放进工作流。2.2 AI 编程智能体工具新一代的“自动干活”选手传统 AI 编程助手是一问一答你推一步它走一步。AI 编程智能体AI Agent不一样你给它一个任务它能自己读代码、定位问题、写代码、跑测试、根据报错修改甚至循环若干轮直到测试通过。我在实际项目里体验过的智能体类工具主要集中在两类开源全能型比如 OpenHands原 OpenDevin、AutoGPT 这类给一个大任务它会自己拆解、自己执行。这类工具对“任务边界清晰”的中小型功能很好用但任务太大太模糊时容易跑偏需要你频繁介入纠正。垂直场景型比如专注于自动修 Bug 的、专注于自动写测试的、专注于做代码评审的。这类工具目标窄反而在单一环节上比全能型可靠得多。社区里像 oh-my-pi 这类偏个人开发者的智能体项目也值得留意它们通常把模型、工具链、prompt 模板都做了整合开箱即用适合不想从零搭智能体的朋友。我自己的分工是大而全的功能开发用 Cursor 这一层做主力小而专的重复劳动比如“给所有 controller 层补参数校验”交给智能体自动化。两者不冲突反而互补。2.3 别把工具当成流程的全部最后提醒一句工具只占工作流的一小部分。我见过不少人工具换了一轮又一轮最后发现 COPILOT 和 CURSOR 的差距远不如“有没有把需求拆清楚”的差距大。所以下面这部分才是 v2.0 的真正重点。3. AI 编程工作流 v2.0 总览一条从需求到上线的标准流水线先把 v2.0 的整体结构画出来这里不给架构图直接列环节需求拆解 → 上下文准备 → 方案设计 → 小步生成 → 自动验证 → 人工评审 → 集成 → 复盘沉淀每个环节都有明确的负责人和产出物。注意我在这个流程里特意区分了“AI 做什么”和“人做什么”这是 v2.0 和 v1.0 最大的区别。3.1 八环节各自的输入输出环节负责人输入输出核心目标需求拆解人一句话业务需求用户故事 验收标准把模糊变清晰上下文准备人 AI项目结构、技术栈、代码规范一份 AI 可读的项目说明让 AI 不“失忆”方案设计人主导、AI 辅助需求 上下文技术方案 任务拆解先想后做小步生成AI 主导、人监督单个任务 示例代码一段可运行的代码降低单次复杂度自动验证AI 工具代码测试报告让错误提前暴露人工评审人代码 测试结果评审意见守住质量底线集成人 AI评审通过的分支合入主干解决冲突、保证兼容复盘沉淀人 AI本次过程记录文档、模板、规则更新让下次更顺这个流程看起来很重但对一个正经一点的项目来说每一步都是必须的。差别只是传统模式下这些步骤全要人肉执行v2.0 模式下 AI 把“生成 → 验证 → 修改”这个循环自动化了人集中精力在“拆需求”和“做决策”这两件 AI 短期替代不了的事上。3.2 v2.0 的核心原则小步快跑一次只让 AI 做一件事这句话听上去很普通但它是我踩了最多坑之后总结出来的第一条铁律。v1.0 的时候我经常给 AI 一大段话“帮我写一个用户管理系统包含注册、登录、资料修改、头像上传、找回密码……”结果 AI 输出一个 800 行的巨型文件看着很全实际没有一个功能能直接用——因为每个功能都依赖若干我根本没让它定义的数据结构、组件和接口。v2.0 的处理方式完全反过来一次只给 AI 一个非常小的任务小到“给这个函数增加参数校验”“写一个工具函数把时间戳转成指定格式”这种级别。单个任务生成完后立刻验证、立刻确认、立刻进入下一个任务。看起来来回切换很慢实际上整体效率高得多因为返工率指数级下降。这个原则解释了很多搜索热度很高的问题“从零开始能用的 AI 编程到底怎么开始”答案不是你一上来就让它写整个系统而是先把系统拆成几十个小任务再一个接一个地让 AI 完成。拆任务的颗粒度决定了你驾驭 AI 的上限。4. 需求拆解与上下文准备决定 AI 输出质量的上游环节很多朋友跑来问我“我的提示词写得很详细了为什么 AI 还是写不对”我反问一句“你告诉它你们项目用的是 Python 3.12、依赖管理用 uv、服务框架是 FastAPI、数据库访问统一走 SQLAlchemy 2.0 的 async 模式吗你告诉它你们的异常处理统一抛 BizException、错误码规范是四位数字吗”大多数人沉默了。AI 没写对大概率不是它笨而是它根本不知道你的世界长什么样。4.1 需求拆解的正确姿势从一句话到用户故事一条合格的需求至少要拆出用户故事 验收标准。我拿“做一个用户注册功能”举例AI 直接写出来的东西和经过拆解后写出来的东西完全是两个质量等级。项目直接用一句话需求的 AI 结果拆解后的需求输入注册字段AI 随便定一套手机号 密码 昵称手机号作为登录账号校验规则AI 随便写几个手机号正则、密码至少 8 位含数字和字母、昵称 2-12 字符唯一性AI 常常忽略手机号在 users 表必须唯一冲突时报错码 1002密码存储AI 有时用明文必须用 bcrypt 哈希密码字段长度 60成功/失败响应AI 随便返回统一返回 { code, message, data } 结构重复请求AI 基本不管同一手机号 5 秒内重复提交返回“操作太频繁”看到了吧验收标准才是 AI 真正需要的需求。每一句验收标准都会直接转化为代码里的判断分支你给得越细AI 生成的代码就越接近能直接用的状态。实操中我习惯把需求拆成“用户故事”格式直接作为后续提示词的一部分作为【角色】我希望【操作】以便【价值】。验收标准【条件1】 时系统应【行为1】【条件2】 时系统应【行为2】。4.2 上下文准备给 AI 建一份“项目认知档案”AI 编程最大的软肋是“记忆”太短。每次对话它都要重新理解你的项目如果每次都要靠人肉在提示词里补充背景效率太低。v2.0 的做法是在项目根目录维护一份AI_CONTEXT.md把 AI 理解这个项目需要的信息全部写进去。每次开新对话或者切换工具先把这份文档喂给 AI让它“快速上手”。我的AI_CONTEXT.md一般包含这些内容# 项目基本盘 - 语言/版本Python 3.12 - 框架FastAPI SQLAlchemy 2.0 (async) - 依赖管理uv - 目录结构app/ (核心代码) / tests/ (测试) / scripts/ (脚本) # 编码规范 - 类型标注所有函数必须写参数类型和返回类型 - 异常业务异常统一抛 BizException错误码 4 位数字注册模块从 1000 开始 - 数据库Model 统一继承 BaseCRUD 走 repository 层不直接写 session # 关键约定 - 时间统一存 UTC返回前端时转本地时区 - 所有接口响应格式{ code: 0, message: ok, data: ... } - 新增依赖必须先在 pyproject.toml 里声明 # 常用命令 - 启动开发服务: uv run uvicorn app.main:app --reload - 跑全部测试: uv run pytest - 代码格式化: uv run ruff format .有了这份档案AI 生成的代码在架构匹配度上会大幅提升。我自己的体感是同一份需求喂了档案之后的 AI 输出可直接用的比例至少翻了一倍。如果你用的是 Cursor 这类工具可以把这份文档路径写进项目设置里让它启动时自动读取如果你用的是 DeepSeek API 自建流程那就把文档内容拼进 system prompt。4.3 把“技术方案设计”环节补进来这里有个很多人会偷懒的环节需求拆完了直接就让 AI 写代码。我建议中间加一道“方案设计”的闸门。具体操作是喂给 AI 需求 上下文让它先输出一份技术方案——涉及哪些文件、每个文件做什么、数据模型怎么设计、接口怎么定义、需要新增哪些依赖、风险点在哪里。人类花十分钟看一遍确认或修改然后才让 AI 动手写。这一步能拦下大量方向性错误。比如 AI 可能会为一个小功能引入全套缓存框架方案评审时你一眼就能看出来让它改掉——而不是等代码写完了再翻工。5. 提示词工程决定 AI 编程输出上限的 20%虽说不只是提示词的功劳但提示词依然是 AI 编程里投入产出比最高的环节。同样一个任务提示词写得烂和写得好效果差异可以到“完全不能用”和“微调就能上线”。网上搜“ai 编程提示词怎么写”的人很多我直接把实战模板给出来。5.1 万能五要素提示词模板我自己在用的提示词模板长期迭代下来稳定在五个要素【角色】你是一名精通 XXX 技术栈的资深工程师熟悉本项目的编码规范。 【任务】实现 / 修改 / 重构以下功能具体描述任务越细越好。 【约束】 - 遵循 AI_CONTEXT.md 中的项目规范 - 不引入未声明的第三方依赖 - 不改动与本任务无关的文件 - 异常处理统一走 BizException 【输入输出】 - 输入描述输入数据来源与格式 - 输出期望返回内容与格式如“返回 { code, message, data }”结构 【验收标准】 - 完成哪些功能点 - 通过哪些测试场景 - 运行哪些命令可验证举一个真实例子。我要 AI 给一个 Python 函数增加手机号参数校验提示词是这样写的【角色】你是本项目 Python 后端工程师严格遵守 AI_CONTEXT.md 规范。 【任务】在 app/services/user_service.py 的 register() 函数中增加手机号参数校验规则。 【约束】 - 手机号规则1 开头第二位 3-9共 11 位数字 - 校验失败时抛 BizException错误码 1001提示“手机号格式不正确” - 不修改其他函数不依赖新增库 - 在函数入口处插入校验逻辑 【输入输出】 - 输入register(phone: str, password: str, nickname: str) - 输出校验通过则继续执行原逻辑失败则抛异常 【验收标准】 - 输入 13800138000 应通过 - 输入 12345 应抛 1001 - 输入 23800138000 应抛 1001这种提示词写下来大概花两分钟但 AI 返回的结果基本就是能直接用的。对比一下只写“帮我加个手机号验证”返工率天差地别。5.2 处理“AI 上下文不够”的应对策略很多工具把上下文窗口越做越大但实际使用时塞太多无效内容反而会让模型困惑。我的经验是给 AI 的上下文宁少勿滥但关键信息一条不能少。“少”是指不需要把整个项目的代码全部贴进去“不少”是指项目规范、任务涉及的文件的现有代码、关键接口签名这三类信息必须给足。一个非常实用的技巧把大任务拆成小任务后每次只把“当前任务涉及的那个文件的相关片段”贴给 AI而不是整个文件。比如要改user_service.py的注册逻辑就把里面的register()函数完整贴出来再贴一下调用它的地方让 AI 知道入参从哪来。上下文精准输出才精准。5.3 反幻觉提示词给 AI 戴上“紧箍咒”AI 生成代码出现幻觉的三大重灾区虚构 API、虚构依赖包、虚构函数行为。对付幻觉最有效的方式是在提示词里明确写“禁止”【重要限制】 - 只允许使用以下库fastapi, sqlalchemy, pydantic, bcrypt。如果需要其他库先向我确认。 - 禁止调用你不确定是否存在的函数不确定时先查文档或代码库。 - 禁止编造配置项项目配置文件里不存在的配置一律不得引用。 - 生成代码后自查一遍每个方法是否在现有代码中真实存在。在实际项目中这条限制让“AI 写出一个不存在的方法然后到处调用”的翻车频率降低了七八成。6. 核心实操从生成到验证把小任务做成可用代码提示词准备好了任务也拆好了接下来是整个流程里最刺激的部分让 AI 真正产出可用代码。6.1 小步生成怎么选“第一个小任务”一个项目的第一个 AI 任务我建议从“不影响整体运行的工具函数”开始比如日期格式化、字符串处理、数据结构转换。这类任务边界清晰没有太多外部依赖AI 几乎不会出错能帮你在项目里建立第一次“正向反馈”。后面再逐步推进到“添加接口”“修改服务层”“重构模块”这种复杂度更高的任务。我自己最常用的小步节奏是列出任务清单按依赖关系排序先把纯工具类任务丢给 AI 做掉跑通验证再做数据模型跑迁移和模型层单测再做 repository 层跑增删改查测试然后做 service 层业务逻辑跑业务单测最后做接口层跑接口联调测试。每一层都是下一层的“上下文”每一层都验证通过了再往上走这样 AI 在前面产生的代码会变成后面任务里的可靠参考整个链条越走越稳。6.2 自动验证AI 生成的代码必须过三道关卡AI 生成代码之后不要急着往项目里贴。先过这三道验证第一道静态检查。运行 lint、类型检查、格式化检查。这一类问题 AI 最容易犯也最好修。把报错直接贴回给 AI让它按报错修改通常一轮就能过。第二道单元测试。这一步是最关键的。如果项目里还没有测试框架就先用 AI 搭一个最小测试骨架。写业务代码时同时让 AI 写针对性的单测。比如上个“手机号校验”的例子让 AI 生成函数的同时把测试用例一起写了。bash # 示例跑注册相关测试 uv run pytest tests/test_user_service.py -k phone -v**第三道人工代码走查。** 不要全信测试。测试只能证明覆盖到的场景是对的覆盖不到的地方全靠 AI 自由发挥。人最少要看一下有没有硬编码、有没有在错误层级做校验、异常信息是否对用户友好、有没有明显性能问题。 ### 6.3 用“报错回填”完成闭环 很多人不知道AI 编程真正的“王牌玩法”是**把编译错误、测试失败输出、运行时堆栈直接贴回给 AI让它根据报错修改代码。** 这个闭环是 AI 编程工作流里最爽的一段。你完全不需要自己分析报错只需要把报错文本原样丢回去加一句“请根据报错修复代码”AI 会自己定位、自己修复、甚至自己补测试。 举例那个 phone 校验的测试挂了报错如下贴报错全文请修复 user_service.py 中 register 的逻辑确保测试通过。实际跑下来**大部分“AI 生成的代码有 Bug”都能在这一步解决**而且解决速度比人肉 Debug 快得多。 ### 6.4 版本管理与多任务并行git worktree 的正确用法 项目大了以后AI 编程会带来一个新的甜蜜烦恼任务拆分细了并行度高了git 分支不知道该不该频繁切换。切吧来回 checkout 浪费时间不切吧多个任务同时改同一份代码改着改着就乱了。 这里强烈推荐 git worktree 这个自带但常被忽略的工具。它的作用是**一个仓库可以同时检出多个工作目录每个目录对应一个分支互不干扰。** 我的用法是这样# 在项目根目录给文档梳理任务开一个独立工作区 git worktree add ../myproject-docs -b feat/docs-refactor # 给用户模块改造任务开另一个工作区 git worktree add ../myproject-user -b feat/user-module # 两个工作区可以同时用不同的 AI 会话改代码改完分别提交、分别 PR这个方案对 AI 编程尤其友好。因为 AI 对话有上下文依赖你在 A 工作区生成的代码和讨论记录都在 A 分支上切到 B 工作区时对话历史完全不影响。A、B 两个 AI 会话各干各的最后各自提交交由人工统一集成。 我自己试过同时开三个 worktree 配三个 AI 会话一个改后端 API一个改前端页面一个写自动化测试互不踩脚效率直接翻倍。 ## 7. 场景实战AI 编程在三个热门方向的具体落地 光看流程还是有点抽象这节拿三个近期搜索热度很高的方向演示同一个工作流怎么具体落地AI Agent 与 PLC 编程、扣子发送邮件工作流、从零开始的 AI 编程学习路径。 ### 7.1 AI Agent 与 PLC 编程跨界到底怎么玩 “AI agent 与 PLC 编程”这个话题最近热度不低很多人好奇AI 能不能直接写 PLC 程序 直接回答**能但工作方式和写 Web 代码差别很大。** PLC 编程背后是 IEC 61131-3 标准主流语言包括梯形图LD、结构化文本ST、功能块图FBD等。AI 在对结构化文本 ST 的生成能力上已经可以达到相当可用的水平因为 ST 和高级语言的语法结构相似AI 训练语料里也有大量案例。 拿我实际做过的一个模拟项目来说需求是“实现一个电机启动/停止的带互锁逻辑控制”。套用 v2.0 流程 - 需求拆解电机只能在急停未触发且门关闭时才能启动两个接触器必须互锁不能同时吸合 - 上下文准备告诉 AI 目标 PLC 品牌与软件比如西门子 TIA Portal 或三菱 GX WorksST 语言版本 - 提示词、生成、验证让 AI 生成 ST 函数块然后人工在仿真环境里验证互锁逻辑和边界条件。 AI 生成的核心逻辑长这样示意// 电机控制功能块示意 IF NOT e_stop AND door_closed AND start_button AND NOT overload THEN contactor_a : TRUE; contactor_b : FALSE; ELSIF stop_button OR overload OR e_stop THEN contactor_a : FALSE; contactor_b : FALSE; END_IF;生成的代码可能不是完美可下载到 PLC 的但**作为逻辑设计的起点、作为评审材料、作为文档初稿价值非常大**。而且 AI 还能辅助检查互锁逻辑有没有漏洞相当于多了一个“不要钱的老工程师”帮你走查。 这才是 AI Agent 和 PLC 编程结合的正确姿势**不是让 AI 直接替换专业工控人员的判断而是让 AI 把重复的逻辑编写、规则校验、文档输出全部自动化人集中精力做安全设计和现场调试。** ### 7.2 扣子Coze发送邮件工作流非程序员怎么用 AI 编排流程 “扣子发送邮件工作流程怎么写”也是搜索热点。扣子这类低代码/Agent 编排平台本质上是把 AI 能力封装成了可以拖拽的节点非常适合不做传统编程的人实现自动化。 实操上在扣子工作流里搭一条“触发后发送邮件”的流程核心节点就四步 1. **触发节点**定义什么时候开工比如“收到新表单提交”“定时触发”“对话中用户请求发邮件” 2. **内容处理节点**让大模型把触发事件里的原始数据整理成邮件正文这里可以给提示词模板比如“将收到的订单信息整理成一封礼貌的确认邮件包含订单号、商品、金额、预计送达时间” 3. **邮件节点**配置发件邮箱、收件人、主题、正文邮件服务一般通过平台集成的邮箱 API 或者 SMTP 完成 4. **结束节点**返回发送结果成功或失败信息可以传给后续节点做通知。 这里 AI 承担的核心工作其实是“把非结构化输入整理成结构化内容”和“帮你把流程整体编排建议写出来”。你让 AI 建议“这个流程应该怎么设计”它给出的完整步骤经常比你自己想得还细。 ### 7.3 从零开始能用的 AI 编程新手的“最小可用路径” 很多人问“我以前没写过代码能不能靠 AI 编程直接做工具”我的回答是能但你要接受一个前提——**至少你得能看懂 AI 生成的代码在干什么不然出了错你连描述都写不准。** 非程序员高效使用 AI 编程的最小路径是 1. **选一个足够小、足够真实的需求**。不要“做个电商系统”要“把文件夹里的 Excel 合并成一个” 2. **用自然语言把需求描述给 AI**让它生成一个 Python 脚本Python 是新手用 AI 编程最友好的语言 3. **让 AI 一步步解释代码**不要跳着看每一行都要问清楚为什么 4. **让 AI 帮你运行和调试**把报错原样贴回去问“怎么办” 5. **在 AI 的建议下改需求**逐步迭代直到能跑 6. **把最终脚本备份好并让 AI 帮你写一段使用说明**。 有个朋友完全零编程基础就靠这套流程一个月内给自己做了一堆办公自动化小工具批量重命名、会议纪要整理、周报自动生成。她的经验是**不用先学完语法再开工而是在做一个又一个真实小工具的过程中边用边理解 AI 给的代码效率比啃教程高十倍。** ## 8. 常见问题与排查技巧实录 最后整理一份避坑清单这些问题全是实战里反复出现的每一条都是拿时间换来的经验。 ### 8.1 高频问题速查表 | 问题现象 | 根因 | 排查思路与解法 | |---|---|---| | AI 生成的代码风格和项目完全不一致 | 上下文缺失 | 检查 AI_CONTEXT.md 是否存在、是否喂给了 AI把规范写进提示词约束 | | 代码编译通过但运行就崩 | 逻辑幻觉 | 把运行堆栈原样贴回 AI要求定位并修复必要时要自己打断点 | | AI 引用了不存在的库/方法 | 模型幻觉 | 提示词里写明“禁止未知依赖”发现后让 AI 全局搜索替代方案 | | 改一处代码AI 连带改了其他文件 | 任务边界不清晰 | 提示词里写死“只允许修改 xxx 文件”改完了 git diff 确认 | | AI 生成了代码但没写测试 | 验收标准没写 | 在提示词里加上“必须同时生成对应单元测试” | | 对话一长AI 开始“发癫” | 上下文污染 | 新开会话重新喂 AI_CONTEXT.md 和相关文件片段 | | 报错相同但每次修复都不同 | 随机采样 | 提示词里带上前一次修复尝试要求“基于上一次代码继续修” | | 任务太大AI 输出一堆半成品 | 拆分不够 | 拆小任务每个任务只做一件事验证通过再继续 | | 在多个分支间切换AI 上下文错乱 | 分支切换导致上下文冲突 | 用 git worktree 为每个任务开独立工作区 | | 完全没有编程经验看着代码就懵 | 基础常识缺乏 | 先让 AI 逐行解释配合官方文档速查选小型自动化脚本练手 | ### 8.2 一个真实的“AI Debug 救场”案例 讲一个印象最深的排错经历。有一次写一个数据导入功能AI 生成的代码能跑通小样本但一旦灌入真实文件就开始丢数据。我第一反应是人肉查逻辑后来换了个思路把样本数据和完整跑出来的异常日志一起丢给 AI并附上一句话“数据文件格式见附件请分析丢弃原因修复导入逻辑并补一个覆盖该场景的测试。” AI 分析了十几秒直接定位到问题代码里用了 CSV 的默认解析方式而真实文件里有带换行符的字段导致解析错位。它给出的修复方案是改用 csv.reader 并设置 strictFalse还顺手补了针对性的测试用例。从发现问题到提交修复整个过程不到二十分钟。 这个案例给我的启发是**AI Debug 能力的重点不是“让 AI 闭嘴写代码”而是“把正确的信息喂给它”。** 报错日志、输入样例、期望输出、现有代码这四样给齐了AI 的排错能力远超大多数人想象。 ### 8.3 三条独家避坑心得 **第一条永远不要让 AI 在没有“任务边界”的情况下直接开写。** 核心代码、数据库模型、支付流程这类关键代码AI 可以参与编写但最终评审权必须留给人。AI 生成的内容是“草稿级资产”不是“成品”。 **第二条对话历史的纪律性很重要。** 一个会话就做一个任务。任务结束、验证通过后立刻把这个会话封存或者归档新开一个会话做下一个任务。AI 的上下文是有限的资源省着用用到刀刃上。 **第三条迭代你的 AI_CONTEXT.md 和提示词模板。** 每次出现“AI 反复犯同一个错”的情况就把对应的新规则加进去。我自己的 AI_CONTEXT.md 已经迭代了几十个版本现在 AI 在我项目里的表现比第一次用的时候高了不止一个档次。 ## 9. AI 编程工作流后续还能怎么扩展 说完了 v2.0 的完整流程我还想聊聊这套东西接下来还能怎么玩。毕竟工具和模型迭代速度太快工作流阶段性地必须跟着进化。 我目前正在试的方向有两个。第一个是把“复盘沉淀”环节自动化每次项目做完让 AI 根据 git log 和 PR 描述自动生成一份“本次迭代的经验与教训”再自动把值得固化的规则合并进 AI_CONTEXT.md。这样整个系统的自我迭代能力就起来了。第二个是把“人工评审”环节做得更智能目前 AI 已经在辅助我做代码评审了我给它的指令是“只挑真正的逻辑问题噪音问题不要提”经过几轮调教它现在提的意见已经像是一位老同事在把关了。 我个人在实际操作中的体会是**AI 编程工作流的本质是把程序员从“什么都亲自干”变成“定义标准和做关键决策”。** 你花越多的精力在流程、规范、上下文和验证上AI 就越可靠你在这些环节偷懒AI 就越会给你制造惊喜不过是坏的那种惊喜。v2.0 这套流程我至少还会用两三年期间大概率会迭代出 v3.0、v4.0。但核心的那句话不会变AI 是工作流里最勤奋的一个成员但它不是替你思考的那个人。
