说实话前两年我写AI编程工作流v1.0的时候思路特别简单遇到需求就问ChatGPT它给一段我贴一段跑不通就再问一遍。当时自我感觉良好觉得效率翻了三倍直到接了一个中型的内部系统重构才彻底意识到这条路走不通——代码库根本串不起来AI写的模块和现有结构完全不兼容上下文一长它就开始胡编API光排查一个“看起来对但跑不起来”的问题就花了我一个下午。那次之后我花了整整三周时间复盘把踩坑记录一条条列出来又重新搭了一套从需求分析、技术选型、代码生成、代码审查到测试运维全流程覆盖的AI辅助开发体系也就是现在你想看到的这套v2.0。这套流程适合谁不管你是独立开发者、三五人的小团队还是公司里需要带实习生的技术负责人只要你的日常工作里包含“写业务代码”和“改别人的烂代码”这篇文章都值得你完整读一遍。它解决的核心问题不是“怎么让AI帮你多写几行代码”而是“怎么让AI稳定地产出能直接合入生产环境的代码”顺便把v1.0时代那些“AI写得爽、人改得想死”的副作用一起解决掉。说实话如果你现在还在用“单轮对话复制粘贴”的方式用AI写代码那看完这文章你会发现自己以前纯粹是在给AI当测试员。1. 内容整体设计与思路拆解v2.0比v1.0改了什么1.1 v1.0时代的三宗罪没有流程等于给AI交学费先说个扎心的事实大多数人用AI编程的第一阶段其实是在给AI“打工”。我说三宗罪你自己对照一下中了几条。第一宗罪是没有上下文管理。v1.0的时候我想当然地认为只要我把整个项目的核心代码都复制到对话框里AI就能理解全局。结果呢500行代码贴进去AI确实“理解”了但回复质量直线下降每次只给一个碎片化的解决方案后面还得我一句一句追问。更崩溃的是当代码超过对话上下文窗口AI会突然“失忆”开始一本正经地编造一个根本不存在的函数。第二宗罪是跳过验证环节。AI生成的代码看起来天衣无缝函数名规范、注释齐全、风格统一但一跑就报错。我统计过v1.0时期的数据AI生成的代码一次跑通率不足30%大部分问题出在用了不存在的API、遗漏了边界条件、或者和现有代码库的依赖版本冲突。这其实不怪AI怪我把“代码生成”当成了“软件开发”中间跳过了设计、评审、测试这些关键环节。第三宗罪是迷信“大而全”的提示词。网上流行那种几千字的“超级提示词”宣称能让AI化身十年架构师。我不否认它们有点用但实际执行下来大提示词带来的问题比它解决的还多AI容易过度设计给一个增删改查它能给你整出微服务架构代码生成速度也慢而且一旦里面某个约束和实际项目冲突整个输出质量悬崖式下降你还很难定位是哪句话出了问题。1.2 v2.0的四条设计原则把小作坊变成标准化产线v2.0的核心思路是把我从v1.0里总结出来的教训变成一套可复用、可复制、甚至可培训新人的流程。它建立在四条设计原则之上这四条原则每一个都是从具体失败案例里倒推出来的。首先是“上下文即代码”。v2.0不再依赖单次对话里的“超长输入”而是建立一个持久化、模块化的项目上下文库把业务规则、数据库结构、API约定、编码规范拆成独立文档每次需要AI做什么就只喂它相关的上下文。这和给新同事发入职手册是一个道理——你不能指望他靠看完整套代码库才能干活你得给他接口文档和工时规范。其次是“小步快跑壁垒推进”。v1.0我喜欢让AI一次性生成整个模块上百行代码后来发现这是个灾难。v2.0把任务拆碎到最小可交付单元一次对话只搞定一个功能点、一个函数、一个组件。每完成一步就人工验证一步确认没问题再进入下一步。就像盖房子地基都没灌混凝土呢就别急着让AI把三楼图纸画出来。再次是“三明治验证回流”。AI输出代码之后不是直接复制粘贴而是经过“代码评审-自动测试-静态检查”三关验证才会被采纳验证过程中发现的问题和经验再作为新的上下文反馈给AI。这本质上是一种人在环路的强化学习让AI在同一套代码库上越用越顺手。最后是“人机权限清晰”。AI负责从想法到草稿的快速转换人负责所有“最终拍板”。数据库表结构设计、公共接口契约、安全方案选型、依赖引入这些必须人来做决定不能听AI的。我见过一个新手朋友完全听AI的随便引入了一个冷门库做日期处理最后这个库半年没人维护出了安全公告没人修那就是给自己埋雷。1.3 端到端的全流程一图看懂v2.0跑起来的样子整个v2.0流程分六个阶段需求澄清、技术设计、任务分解、编码实现、质量验证、集成部署。这不是跳过了“传统开发”的流程而是每个阶段都引入了AI作为加速器同时又保留了人类的决策权。需求澄清阶段AI扮演的是“需求追问器”帮我把一句话的产品想法拆成一个一个的疑问点逼着产品经理把“做个用户系统”说清楚是“手机号注册还是邮箱注册需不需要第三方登录”。技术设计阶段AI当“方案顾问”给我列出三种可能的技术方案、各自优缺点、对应的时间成本但我来拍板选哪种。任务分解阶段AI充当“项目助理”把大需求拆成可并行推进的小任务并标注依赖关系。编码实现阶段AI是“主力码农”但必须严格遵守上下文库里的规范。质量验证阶段AI是“测试工程师”负责写单测、做边界条件分析、模拟异常输入。集成部署阶段AI又变身“运维助手”帮我写Dockerfile、配置CI/CD、生成监控告警规则。一套走下来我的直观感受是人花在“思考和决策”上的时间增加了但花在“写代码和找bug”上的时间大幅下降。总工时大概只有v1.0时代的60%但代码质量和可维护性是完全不可同日而语的。2. 工具选型解析2025年AI编程工具梯队与组合拳2.1 “最厉害三个软件”到底花落谁家商业工具阵营网上天天有人问“AI编程最厉害三个软件”每次评论区都能吵起来。我自己的观点是2025年这个时间点讨论“最厉害”已经意义不大了因为头部工具的能力差距在快速缩小真正拉开体验差距的是“和你的项目结构、团队习惯是否匹配”。不过既然大家爱看我就还是按“综合体验”和“文档热度”把三个有代表性的工具列出来。第一档是Cursor。它强在极致的上下文感知和跨文件编辑能力尤其是它的Tab补全确实有种“读心术”的感觉你写好函数名它就能把整个函数体续出来准确率惊人。我用它处理前端页面和中等规模后端逻辑体验非常顺滑。但它的价格不便宜而且高度依赖云端模型公司网络策略严格的时候就不太好用。第二档是GitHub Copilot。老牌选手胜在生态完善和VS Code、JetBrains全家桶集成得最好企业级代码库的索引能力很强对大型仓库的理解比较靠谱。它很多时候不出风头但胜在稳定不太会给你拿出一个莫名其妙的方案。第三档是字节跳动的Trae或者腾讯云新出的C知道之类的国产助手。它们在中文语义理解、对国内开发环境的适配上有天然优势简单来说就是“说人话就能干活”对中小团队快速上手很友好。C知道还集成了多模型管理和代码库知识库问答用起来是省心的。对于“DeepSeek的API和C知道哪个好用”这个问题我的结论很明确这俩根本不是一个赛道。DeepSeek的API是在“卖模型算力”适合有技术能力、想自建工具链、对数据隐私有要求的团队用C知道是“开箱即用的成品”你不需要关心模型怎么调度、上下文怎么管理打开界面就能聊代码。如果你是个追求零配置、马上出成果的独立开发者选C知道或Copilot这类成品工具如果你有明确的自定义需求、想深度定制AI行为、或者要接自有知识库那DeepSeek API加开源客户端是性价比更高的路。我自己现在是Cursor加自建API网关混着用——常规任务走Cursor任务量大的批量重构走本地脚本调API。2.2 开源与API自由组装给动手党的省钱方案如果你不想充值Cursor这种订阅制工具或者和我一样有“既要便宜又要可控”的强迫症那可以走“开源客户端大模型API”的自由组装路线。这条路的核心是客户端软件免费、模型按token付费一个月几十块钱就能跑得不错。几个可以组合的开源客户端我先点名Continue、Cline、Roo Code、Aider。前端开发党可以选Continue它作为一个插件嵌在VS Code里可以自由切换模型提供商。喜欢Agent模式、希望AI自己迭代修改文件的那就Cline或它的分支Roo CodeRoo Code支持自定义流程阶段能把“分析-计划-实施-测试”拆开控制这个对需要审计AI行为的团队特别友好。另外还有一个Aider是纯命令行的适合那些日常工作和命令行深度绑定的人它最大的优势是天生和git集成每次修改都会自动生成commit出问题随时revert安全感拉满。API服务商这边DeepSeek的API算是性价比之王V3和R1模型在日常编码的多个基准测试里表现不错关键是价格便宜得很支持长上下文。Qwen-Coder、Kimi-Latest、智谱的GLM-Coding也是可以随时切换的备选。我自己搭过一套把DeepSeek当主力Qwen-Coder当备胎遇到DeepSeek反复给不出好方案的时候我会强制切到备胎重跑一遍经常有意外惊喜。2.3 AI编程工具之外的隐形队友git worktree的妙用可能很多人没有留意到但git worktree其实是我整个AI编程工作流里最离不开的“隐形队友”。简单说它允许你在同一台电脑上、同一个仓库里同时开出多个工作目录每个目录对应不同的分支互不干扰。有了它我可以同时让AI在分支A上修bug、在分支B上做新功能、在分支C上跑实验性重构三个工作目录并行推进不需要反复stash和切换分支。对AI编程来说worktree带来的价值是几何级的。你想想如果你只有一个工作目录AI改到一半你想让它换个任务就得先处理半成品代码一来一回时间和心智成本都极高。有了worktree我只需要新建一个目录告诉AI“这个目录专门做登录模块重构”它怎么折腾都在那个隔离环境里不污染主线代码。后面我会专门用一节来讲这个主题因为“用AI同时干三份活”真的是v2.0提效最猛的一招。3. 核心场景实操流程从一句话需求到可合并的代码3.1 不要直接写代码先把一句话需求翻译成任务书很多AI编程翻车根源不在写代码那一环而在需求描述那一环。你直接说“帮我写一个用户注册功能”AI给你的大概率是一个能跑但到处都是洞的玩具代码缺邮箱验证、缺密码强度限制、缺防暴力破解措施。这不是AI蠢是你没告诉它需求的定义。我现在的做法是给AI任务书模板逼自己在动手前把需求彻底想清楚。这个任务书包含六个部分背景描述为什么做这个、功能清单具体要哪些、边界约束绝对不能做什么、验收标准怎么算做完、技术约束指定语言、框架、数据结构、开放问题拿不准的地方让AI给建议。一份合格的任务书应该是你把它拿给你的同事看他不需要你解释任何一句话就能直接开工的程度。写任务书这个动作表面上是在给AI下指令实际上是在逼自己思考。有一次我需要写一个Excel导入导出的功能一开始心想这还不简单结果任务书写到“边界约束”那一栏突然发现忘了定义“如果单元格里有公式怎么办、合并单元格怎么处理、超过10万行大文件怎么处理”。这些问题要是在写代码时候才被AI发现来回沟通的成本就是几倍。所以我把这个阶段叫“磨刀不误砍柴工”再急也省不得。3.2 让AI当顾问做技术设计一题多解人类拍板任务书定稿之后不要急着让AI写代码。哪怕是一个很小的功能你也要走一遍“技术设计评审”环节。我的做法是让AI独立给出至少两套方案并要求它按照“实现思路、改动范围、性能表现、维护成本、风险点”五个维度做对比分析。打个比方我要做一个消息通知系统如果只听第一版方案那就是简单粗暴轮询数据库部署简单但对数据库压力很大用户多了必出问题。但如果你强制AI输出另外两个方案它会给出基于Redis订阅发布的方案和基于WebSocket长连接的方案你一眼就能看出哪套方案更适合当前规模也更容易预测未来哪套方案会先遇到瓶颈。这个环节里我的原则是AI是顾问决策必须自己做。原因很简单AI在技术选型上有一个隐性偏好——它会倾向于选择它训练数据里最常见的方案而不是最适合你项目的方案。最常见的方案未必错但如果你的项目有特殊约束比如部署环境没有外网、团队没人熟悉某个语言、客户要求国产化那AI的“常见推荐”就是无效推荐。你必须在方案评审时把这些约束作为筛选条件主动提出来。3.3 任务分解与优先级排布让AI充当项目助理设计评审通过后下一个关键动作是把大需求分解成若干个可独立开发、可独立验证的子任务。这一步我的效率工具是“AI作为项目助理”给它一段需求说明它会输出一个任务拆分清单每个任务包含输入、输出、依赖关系和预估工作量。但请注意任务拆分你不能直接拿AI的结果去用。AI拆任务有一个通病它倾向于把工作拆成“功能模块”而不是“可验证的步骤”。比如“用户注册”这个功能AI可能会拆成“前端表单”、“后端接口”、“数据库表”但是按这个维度拆你会发现三个task之间依赖非常强没法并行开发也没法单独交付。我自己的经验是让AI先拆一版然后我按照“端到端切片”原则重排把“保存用户数据到数据库”作为一个垂直切片它自己就包含了后端接口、数据库操作、简单前端调用这个小功能能独立测试这才是一个合格的任务单元。任务排好优先级之后有个小技巧值得分享把“探索型任务”和“确定性任务”分开。探索型任务是那种“我不确定能不能实现需要先验证”的任务比如集成一个冷门SDK确定性任务是“我明确知道怎么做只需要执行”的任务。AI代理在处理这两种任务时的表现差距很大探索型任务容易陷入乱试和死循环所以我通常让AI先集中处理确定性任务而探索型任务我抽时间做初步技术预研后再交给AI去完成执行部分。这个分法帮我节省了大量调试时间。3.4 编码阶段的核心细节Prompt工程是伪命题上下文工程才是真功夫到了编码阶段大多数人都以为“提示词写得好”是效率关键。我曾经也这么想直到我对比了自己写的“精心设计的万金油提示词”和“简单直白的提示词”在同一任务上的表现发现效果几乎没有差别——因为真正影响输出质量的不是你提示词里的形容词而是你喂给模型的上下文内容。提示词工程在AI编程里的形态正在被上下文工程取代。什么叫上下文工程就是你在让AI写代码之前主动构建好它需要知道的信息集合。我现在把上下文分成三类。第一类是代码库上下文项目的目录结构、技术栈说明、现有代码风格、关键模块的接口定义。第二类是业务上下文流程规则、权限模型、涉及的外部系统。第三类是约束上下文代码规范、测试要求、边界条件。这三类信息AI掌握得越准确输出就越贴合实际而你的提示词只需要一句话“请按照上述上下文实现xxx功能。”我自己维护一个项目根目录下的上下文文档里面分门别类地存放这些信息。每次开新会话时先让AI读取相关文档片段再给它具体任务。这个习惯让我的AI交互质量有了质的提升而且新同事接手项目时这些文档同时也是极好的项目说明一举两得。当任务复杂到单个会话搞不定时我会用“分阶段提示词模板”。举个例子第一阶段提示词是“读取docs/context.md并列出你对这个功能的理解和实现计划”第二阶段是“按照你刚才的计划实现核心模块并在代码中预留测试接口”第三阶段是“为这个模块补充单元测试覆盖正常流程、异常流程、边界条件”。每个阶段都以AI的输出为下一阶段的输入形成一个有节奏、可控制的流水线这比一次丢一个巨大任务稳妥得多。3.5 验证与重构环节AI写代码人负责“不信任”老读者知道我一直强调一个观点AI生成的代码默认是有bug的直到你证明了它没有bug。这不是不信任AI而是你必须有这个心理预设才能建立正确的验证流程。一套完整的验证流程通常分四层。第一层是自动化测试。让AI写代码时同时让它写单元测试用例。这里有个技巧不要让AI既写实现又写测试那样它会自我包庇测试用例会下意识避开实现的缺陷。正确做法是让AI写完实现后你人工检查一遍再让它写测试或者换一个模型写测试。第二层是静态检查和lint规则。ESLint、Pylint、Checkstyle这些工具可以用最快的速度帮AI代码纠出低级错误比如未定义变量、未使用的import、格式不一致。不要觉得这些工具鸡肋AI生成代码在格式层面的一致性恰恰是最容易出问题的虽然不影响功能但影响后续维护。第三层是人工代码评审。我会重点检查几个AI最容易翻车的点错误处理逻辑是否合理还是只是吞掉了异常、边界条件是否遗漏空数组、负数、超长字符串、敏感信息是否泄露API key、密码有没有被硬编码、是否引入了不必要的新依赖。第四层是集成验证。把AI生成的代码合入主干分支之前必须跑一遍全套回归测试因为你改动的模块可能会影响其他模块。如果你觉得这套流程听起来很麻烦那我给你一个心理预期一次完整的验证流程大概占整个任务时间的30%到40%。也就是说AI帮你节省的时间有一部分必须投入到更严格的验证上。这正是v2.0最核心的理念之一——AI提高的是你的产出质量天花板而不是“写代码”这件事本身的速度。想通这一点你对AI编程的预期管理就健康了。4. git worktree实战让AI在同一时间干三份活4.1 为什么“多开工作目录”是AI协作的隐藏神器上一节说完整流程现在我要重点展开一个工具技巧也就是前面提到过的git worktree。在传统开发模式下它只是一个偶尔用一下的效率工具但在AI编程流程里它直接改变了人和AI的协作模式。它的原理很简单一般的git仓库默认只有一个工作目录你切换分支时git会把工作目录里的内容替换成对应分支的内容。而git worktree允许你为同一个仓库关联多个工作目录每个目录对应不同的分支可以同时存在、同时操作它们共享同一个.git仓库的历史和对象数据库。这个能力对AI编程有多重要我举一个真实场景。周五下午我同时面临三件事线上有个紧急bug要修、下周要交付的新功能还差两个模块、有个技术债务想顺手重构。v1.0时代我肯定一个一个来生怕切换分支把半成品代码搞丢了。v2.0时代我只需要开三个worktree分别对应fix-urgent-bug、feature-payment、refactor-auth三个分支然后让AI在三个目录里并行开工每个目录里都有一个独立的AI会话。它们各自改各自的commit也互不干扰我只需要在每个会话的关键节点介入检查和验证效率至少翻了两倍。4.2 一步步实操创建worktree并在其中运行AI编程操作步骤如下环境是Git 2.5及以上版本这个要求基本没有不满足的了。第一步在项目根目录创建一个新分支并关联新工作目录命令是git worktree add ../project-login feature-login。这个命令会创建一个../project-login目录并把feature-login分支检出到这个目录。如果分支不存在加上-b参数直接创建比如git worktree add -b feature-login ../project-login HEAD从当前提交切出新分支。第二步在新工作目录中做AI编程。打开你熟悉的编辑器或终端把当前目录切到../project-login在这个独立的目录里启动AI编程客户端。此时AI的所有操作创建文件、修改代码、git提交都限定在这个目录和这个分支范围内。你可以在主工作目录里继续做自己的事情完全不会被打扰。第三步开发和验证完成后合并回主分支。在../project-login目录里把代码提交并推送远程分支之后回到主工作目录或任何一个worktree目录执行git merge feature-login把功能合入主干。如果出现冲突git会正常提示冲突文件解决方式和普通合并没有任何区别。补充一个在AI编程中特别好用的进阶技巧你可以为AI的每个任务预建一个worktree目录然后把项目上下文中和该任务相关的部分复制进去AI生成的代码、产生的调试信息、临时文件全部留在那个目录里。任务完成合并回主线后直接删除整个worktree目录干净利落不留技术债。4.3 多开协作的冲突排查与事项注意用worktree并行开发最大的坑来自“共享的本地依赖”和“环境配置”。比如你的项目依赖通过npm install安装那么每个worktree目录都需要单独执行一次安装如果你使用的是占用磁盘很大的依赖比如Python的venv、node_modules多开几个目录磁盘占用会迅速膨胀。这是个简单的物理问题没什么好办法只能规划好机器磁盘容量。另一个坑是“修改了共享配置但忘了提交”比如项目根目录下的.env文件你可能在修复bug的worktree里改了数据库连接字符串但新功能的worktree里还在用旧的配置这时候跑出来的结果会非常诡异。我的经验是统一使用环境变量管理或者在项目里加入一个启动脚本自动检测配置差异把这件事交给程序而不是人脑。还有一个经历值得写出来。有一次我在三个worktree里同时让AI改同一组公共工具函数结果新功能分支和重构分支各自都对那组函数做了修改合并的时候冲突那叫一个惨烈花了将近半天才处理干净。从那以后我给自己立了一个规矩如果多个并行任务会修改同一个公共模块就必须让两个AI会话“知道彼此的存在”我的做法是在项目上下文文档里加一个互斥标注写明“当前已有会话在修改xxx模块新任务如涉及该模块必须先合并前者”。这个流程问题不解决多开worktree的好事就会变成大型灾难现场。5. 常见问题与排查技巧实录5.1 从“AI胡言乱语”到“遇到死循环”问题速查表我把过去一年里遇到的各种AI编程问题整理成一问题速查表按“症状-原因-解法”三列排列方便你遇到问题的时候快速对照按图索骥。症状根本原因解决方法AI开始调用不存在的API或变量对话上下文丢失或污染检查上下文长度开新会话并重新提供核心上下文用grep验证API是否真的存在于依赖库中AI反复生成相同错误代码陷入死循环任务目标不明确或上下文信息矛盾停下游说重构任务书删除过时上下文换一个模型重试往往能跳出死循环生成的代码能运行但性能极差缺少性能约束上下文在任务书“约束”栏补充性能要求要求AI先给出复杂度分析再写代码代码风格和项目现有风格严重不一致没有提供项目风格指南组织一份风格指南放入上下文库强制AI遵守不满足就退回AI主动引入冷门依赖库缺少“禁止新增依赖”的约束在任务书里明确“只能使用已有的依赖清单”若确需新依赖必须经过人工审批测试用例质量极差总是通过测试用例和实现由同一会话生成产生“自我包庇”换一个模型或新会话写测试或用AI生成变异测试来检验测试用例质量大文件改到一半上下文不足任务粒度过大要求AI分步提交代码分步输出开启上下文压缩功能或切换更大上下文模型合并worktree时冲突过多多个分支改动同一模块拆分任务时减少公共模块改动预先在上下文文档中标记互斥模块表格里每一条都是我或者和我交流的朋友们实打实踩过的坑。这里我选几个最经典的展开说一下排查思路。5.2 现场还原一AI“一本正经地胡说八道”怎么识破有一次我让AI给一个数据清洗模块增加去重功能它在代码里引用了一个叫deduplicate_records的函数我从头到尾扫了一遍代码库压根没有这个函数。AI完全是凭着语言模型对“去重”这个语义的联想编造了一个看起来合理但实际不存在的接口。这种“幻觉”在AI编程里防不胜防尤其是这个函数名取得实在太顺口了很容易让人在review时下意识跳过。对这种问题的排查思路不能靠肉眼盯着AI代码才能发现我那套流程里有一个专门的“API验证”步骤。每次AI引用一个“不常见”的函数或方法我都会让它在回复里附带出处也就是“这个函数来自哪个模块、哪个文件”。如果AI给不出出处就基本默认它瞎编的。更稳妥的办法是直接在依赖目录或源码目录里grep这个函数名一秒就能确认是否存在。长期这么干会逼着AI在生成代码时更倾向于使用你已经封装好的公共方法因为规则变成“必须给出出处”之后它编造的代价就变得很高了。5.3 现场还原二AI陷入“改一个bug引出三个新bug”的循环使用AI代理模式比如Cline、Roo Code开启自动执行的时候最容易遇到的现象是AI像一个无限循环的debug机器改完A错误、跑测试发现B错误改完B错误、又碰出C错误如此往复甚至可能永远不停下来。我统计过AI代理连续执行超过10步任务时陷入这种循环的概率会急剧上升白白消耗大量token。我自己总结了一套“防死循环三板斧”。第一板斧是限制迭代次数大多数AI代理工具都支持设置最大执行步数我在交给AI一个任务时会明确设置一个步数阈值比如最多8步超标就强制暂停由人来介入判断。第二板斧是巧妙利用checkpoint要求AI每完成一个子任务就创建一个git commit或打一个tag这样即使后面改崩了也能随时回到稳定版本重新开始而不是从头再来。第三板斧是异常兜底在上下文文档里写明“如果连续两次修复后测试仍然失败请停止自动修复输出当前问题的完整日志和你的假设等待人工处理”。这几个字的价值极大它相当于给AI装了一个“认输按钮”省下的token和心智成本无法计算。5.4 安全与合规意识AI生成代码的隐藏刺客最后必须认真聊聊安全问题。AI生成的代码表面上功能正常但在安全审计视角下经常有漏洞而这个领域恰恰是最不能依赖AI自动修复的。我见过最典型的例子是一个朋友用AI生成了一套带登录功能的web应用AI生成的session处理逻辑非常自然——用户登录后把用户ID存在cookie里表面上功能正常。实际上这是典型的“可预测身份标识”漏洞攻击者只需要改一下cookie里的数字就能冒充任意用户登录。AI之所以会这么写是因为它的训练数据里大量存在这类教学性质的小demoesay代码教会了它“怎么写”但没有教会它“生产环境不能这么写”。所以在AI编程工作流里建议至少把“身份认证”“支付逻辑”“权限控制”“密钥管理”划为人类专属领域不强求AI独立完成AI可以辅助生成初稿但最终代码必须经过有安全经验的工程师逐行review并且接上自动化安全扫描工具。另外把“是否硬编码了密钥”“是否使用了弱哈希算法”“是否正确设置了HttpOnly属性”这三条写进人工代码审查的检查清单里。一次排查成本几张换来的可能是避免一次规模很大的安全事故这个账怎么算都划算。6. 最后聊几句我的实操体会写了这么多最后再分享一点我自己的真实感受。v2.0这套流程跑通之后我最明显的变化不是“代码写得更快”而是“做需求的时候更从容了”。以前接到一个任务第一反应是焦虑——这个功能要多久能写出来、会不会有隐藏问题、能不能在deadline前交付。现在AI承担了大部分“从想到写”的执行工作我只需要把精力放在“这件事到底要解决什么问题、怎么设计才合理、怎么验证才算完成”上焦虑自然就少了。如果你打算从今天开始改造自己的AI编程工作流我的建议是不要一下子全盘套用。先挑一个小的、不影响线上业务的功能模块把“任务书-上下文库-代码生成-验证四层-合并主线”这套完整流程走一遍亲身体验一下每个环节的耗时和效果再逐步推广到更多任务。罗马不是一天建成的v2.0这套流程也是我踩了无数次坑、改了好多轮才稳定下来的。最后说几个我一直坚持的底层习惯每天工作结束前把当天和AI交互里那些好用的提示词、踩过的坑、解决过的问题整理进自己的上下文库或笔记系统这是AI时代属于你自己的“经验复利”遇到特别复杂的任务主动把任务拆成几个小会话去喂AI而不是开一个巨长的对话硬撑对AI生成代码里每一行你不理解的逻辑都抱有“这是bug直到证明不是bug”的态度。做到这几条你的AI编程体验会有质的提升至少不会再出现“AI写得爽、人改得想死”的尴尬局面了。
