1. 从“魔法咒语”到“工程实践”AI编程助手的高效协作心法如果你和我一样从ChatGPT刚出来那会儿就开始折腾AI写代码大概也经历过几个阶段一开始觉得这玩意儿真神随便说两句就能出代码后来发现它经常胡编乱造得花更多时间调试再到最近终于摸索出一套能让AI真正成为靠谱“数字实习生”的工作流。这个过程让我明白用好AI编程助手关键不是找到什么“万能咒语”而是建立一套系统化的协作方法。最近在GitHub上看到一个叫“Awesome AI Coding Techniques”的项目它把各路开发者的实战经验整理成了按开发阶段划分的技术清单。我仔细研究了一下发现里面很多做法和我这两年踩坑总结出来的经验不谋而合。这篇文章我就结合自己的实际体验聊聊怎么把这些技巧落地到日常开发中让你和AI的协作效率提升一个档次。2. 项目规划与需求分析打好地基才能盖高楼2.1 创建项目的“AI使用说明书”我刚开始用Claude Code时每次都要重复交代项目背景“这是个React TypeScript项目用Vite构建测试用Jest代码风格遵循Airbnb规范……”说得嘴皮子都磨破了。后来发现几乎所有主流AI编程工具都支持一种叫“记忆文件”的机制——就是在项目根目录放个特定文件AI会自动读取里面的内容作为上下文。Claude Code用的是CLAUDE.mdCursor认AGENTS.mdCodex CLI也支持AGENTS.md。这个文件就是项目的“AI使用说明书”应该包含这些内容核心命令npm run dev启动开发服务器npm test跑测试npm run build打包技术栈说明前端用React 18 TypeScript 5状态管理用ZustandUI库是Ant Design代码规范函数用驼峰命名组件用PascalCase常量全大写项目结构src/components/放通用组件src/hooks/放自定义Hooksrc/utils/放工具函数常见坑点“别手动改/generated/目录下的文件”、“修改环境变量后要重启服务”我现在的做法是新项目一创建就先跑/init命令Claude Code支持让它自动分析项目结构生成基础版CLAUDE.md然后我再手动补充那些只有我才知道的“潜规则”。比如某个第三方库的特定版本有bug或者某个API的响应结构比较特殊这些信息写进去后AI后续生成代码时就能避开这些雷区。注意记忆文件要随着项目演进不断更新。我每遇到一个需要反复向AI解释的问题就立刻把它加到CLAUDE.md里。时间长了这个文件就成了项目的“集体智慧”沉淀。2.2 先规划再动手避免盲目编码早期我经常犯的错误是直接对AI说“给我写个用户登录功能”结果它生成了一堆乱七八糟的代码。后来学乖了现在我会强制自己先进入“规划模式”。在Claude Code里按ShiftTab在Cursor里点“Plan”开关让AI先别急着写代码而是列出实现方案。我会要求它至少包含这几个部分步骤分解分几步实现每步做什么涉及文件需要修改或创建哪些文件风险评估可能遇到什么问题怎么规避快速验证写完后怎么快速测试是否工作比如最近要加个文件上传功能AI给的规划是1. 前端创建Upload组件处理文件选择、预览、上传进度 2. 后端新增/upload接口处理multipart/form-data 3. 存储配置AWS S3客户端生成预签名URL 4. 数据库记录文件元信息文件名、大小、存储路径 5. 测试前端组件测试 后端接口测试 风险大文件上传可能超时需要分片上传方案 验证上传小图片检查是否能正确返回URL并显示这个规划我看了觉得没问题才让它开始写代码。如果规划有问题就在规划阶段迭代修改比代码写了一半再推倒重来省事多了。2.3 选择“无聊”但稳定的技术栈Simon Willison有句话我特别认同“在项目的独特卖点上创新在其他所有事情上坚持使用经过验证的解决方案。”用AI编程时这个原则更重要。AI的训练数据有截止日期它对2021年之后出现的新库、新框架了解有限。如果你非要用最新潮的框架就得花大量时间给AI“补课”——把文档、示例代码喂给它。所以我现在的技术选型策略是前端React TypeScript而不是Svelte或SolidJSUI库Ant Design或Material-UI而不是Radix UI或Chakra UI v2构建工具ViteWebpack也行但Vite社区示例更多测试Jest React Testing Library而不是Vitest Playwright不是说新东西不好而是用AI协作时选择那些在训练数据里出现频率高的技术能显著降低沟通成本。AI对React组件的写法了如指掌但可能没见过Svelte的$:语法糖。2.4 写详细的需求规格哪怕用聊天的方式我发现AI对函数签名特别敏感。与其说“写个下载文件的函数”不如这样async def download_file( url: str, save_path: Path, max_size_mb: float 10.0, timeout_seconds: int 30 ) - bool: 从指定URL下载文件到本地路径 Args: url: 文件URL save_path: 保存路径 max_size_mb: 最大文件大小MB超限则取消下载 timeout_seconds: 超时时间 Returns: bool: 下载是否成功 Raises: ValueError: URL无效或文件过大 TimeoutError: 下载超时 IOError: 保存文件失败 把输入输出、异常情况、参数说明都写清楚AI生成代码的准确率能提高好几倍。这就像给实习生布置任务说得越模糊结果越可能跑偏说得越具体越容易拿到想要的东西。3. 界面设计与原型开发从想法到可运行的原型3.1 快速原型验证可行性我有个习惯任何新功能、新项目先用AI快速搭个能跑的原型。不用考虑代码质量不用考虑架构优雅只要验证核心功能是否可行。上周我想做个简单的数据可视化面板需求是从API拉取数据用图表展示支持筛选和导出。我对Claude说“用React Recharts快速搭个数据看板原型包含折线图、柱状图和筛选控件用mock数据就行。”5分钟后一个能跑的页面就出来了。虽然样式简陋数据是硬编码的但至少证明了技术方案可行。有了这个原型我就能评估Recharts是否满足需求确认数据流转逻辑是否合理给产品经理看效果收集反馈基于原型迭代完善原型开发阶段我甚至会故意用一些“偷懒”的写法比如把逻辑全写在一个组件里、用内联样式。因为我知道这只是验证阶段后面会重写。AI特别擅长这种“快速出活”的任务。3.2 截图对比视觉设计的迭代利器做UI开发时我最头疼的就是和AI描述“我想要什么样的界面”。文字描述总有歧义你说“卡片阴影柔和一点”AI可能理解成不同的效果。后来发现Claude Code和Codex都支持直接拖拽图片到聊天窗口。现在我的工作流变成这样用Figma或甚至纸笔画个草图截图拖到AI聊天窗口“照着这个设计实现”AI生成代码我运行看看效果如果不满意把实际效果截图再拖进去“这里间距再大点按钮颜色改成蓝色”重复直到满意这种“截图-生成-对比-调整”的循环比纯文字沟通高效太多。有时候我连设计稿都没有就直接说“做个类似GitHub个人主页的布局”然后AI生成后我截图标注“头像放左边仓库列表放右边这里加个分页器”。3.3 ASCII线框图布局设计的低成本验证在写CSS之前我经常让AI先用ASCII字符画个线框图。比如--------------------------------------- | Header | --------------------------------------- | Sidebar | | | | Main Content | | | | | ----------------------------- | | Footer | --------------------------------------别看这图简陋它能帮我快速确认几个关键问题整体布局是否合理各个区域的相对大小响应式设计时的折叠顺序确认布局没问题后再让AI写具体的CSS代码。这比直接写CSS发现布局不对再返工要省事。3.4 “让它更漂亮”简单粗暴的UI优化AI生成的UI第一版往往比较“工程师审美”——功能齐全但不够美观。我的经验是不用自己费劲描述怎么改直接说“让这个界面更优雅/更现代/更专业”就行。有次AI生成了一个数据表格样式很基础。我说“让这个表格看起来更专业像管理后台那种。”AI就加了斑马纹、悬停效果、表头固定、操作按钮组。我又说“再优雅一点。”它调整了颜色搭配、圆角大小、字体层次。这招对按钮、表单、卡片这类组件特别有效。AI对“美观”的理解可能和设计师不一样但通常比程序员自己调出来的要强。4. 编码实现从“打字员”到“架构师”的角色转变4.1 核心逻辑自己写重复劳动交给AI我现在把自己定位成“架构师代码审查员”而不是“打字员”。核心的、复杂的、容易出错的逻辑一定自己写比如业务规则校验安全相关的逻辑认证、授权、数据脱敏性能关键路径的算法第三方集成的适配层剩下的“体力活”交给AI数据模型的CRUD操作API接口的胶水代码组件的事件处理函数工具函数的实现比如最近做支付功能我自己写了支付状态机、异常处理、重试逻辑然后让AI生成数据库迁移脚本API路由定义前端表单验证单元测试用例这样分工既能保证关键代码的质量又能大幅提升开发速度。4.2 把AI当“数字实习生”指令要具体带过实习生的都知道布置任务越具体结果越符合预期。对AI也一样。不好的指令“实现用户注册功能”好的指令在src/components/auth/RegisterForm.tsx创建一个注册表单组件要求 1. 包含邮箱、密码、确认密码字段 2. 密码要求至少8位包含大小写字母和数字 3. 实时验证邮箱格式、密码强度、两次密码是否一致 4. 提交时调用/api/register接口用axios 5. 错误处理显示后端返回的错误信息 6. 成功后的跳转逻辑 使用Ant Design的Form组件样式参考我们现有的LoginForm组件更进阶的做法是我先把函数签名和类型定义写好interface RegisterFormData { email: string; password: string; confirmPassword: string; } interface RegisterFormProps { onSuccess?: () void; redirectTo?: string; } const RegisterForm: React.FCRegisterFormProps ({ onSuccess, redirectTo /dashboard }) { // 让AI实现这个组件 }然后把这段代码扔给AI“基于这个接口定义实现完整的注册表单逻辑。”AI就像个听话的实习生按我设计好的接口去填充实现。4.3 保持代码简单到“愚蠢”Armin Ronacher有句话很精辟“在智能体语境下简单代码的表现远超复杂代码。”我深有体会。早期我为了让代码“优雅”用了很多设计模式、高阶函数、元编程技巧。结果AI要么看不懂要么乱改一气。后来我刻意写“笨”代码用if-else代替策略模式除非真的需要用显式参数传递代替依赖注入容器用普通函数代替类除非有明确的状态避免继承多用组合比如之前有个数据过滤功能我本来想用责任链模式。后来改成// 笨但清晰的版本 function filterData(data, filters) { let result data; if (filters.status) { result result.filter(item item.status filters.status); } if (filters.dateRange) { result result.filter(item item.date filters.dateRange.start item.date filters.dateRange.end ); } if (filters.keyword) { result result.filter(item item.name.includes(filters.keyword) || item.description.includes(filters.keyword) ); } return result; }这种代码AI维护起来毫无压力。我说“加个按价格过滤”它就知道在if语句后面再加一段。如果用了设计模式AI可能把整个模式都改坏了。4.4 用现有代码“喂”出上下文AI的上下文理解能力有限特别是对于项目特有的模式、约定、工具函数。我的做法是开始一个新任务时先把相关的现有代码贴进去。比如要写一个新的API控制器我会先贴几个现有的控制器// 这是UserController注意它的错误处理方式和响应格式 Controller(users) export class UserController { Get() async findAll(Query() query: UserQueryDto) { try { const users await this.userService.findAll(query); return { success: true, data: users }; } catch (error) { logger.error(Failed to fetch users, error); return { success: false, message: 查询失败 }; } } } // 这是ProductController注意它的参数验证装饰器 Controller(products) export class ProductController { Post() UsePipes(new ValidationPipe()) async create(Body() createProductDto: CreateProductDto) { // ... } } // 现在请按照类似的风格写一个OrderControllerAI看到这些例子后就能模仿同样的错误处理模式同样的响应格式同样的日志记录方式同样的装饰器用法这比单纯说“按我们项目的规范写”有效得多。4.5 对新库要“手把手”教有时候不得不用一些比较新或者比较冷门的库AI的训练数据里可能没有。这时候就需要“喂”文档和示例。比如最近用到了一个比较新的状态管理库ZustandAI一开始生成的代码有问题。我就把官方文档的关键部分贴进去Zustand基本用法 1. 创建storeconst useStore create((set) ({ count: 0, increment: () set((state) ({ count: state.count 1 })) })) 2. 在组件中使用const count useStore(state state.count) 3. 更新状态useStore.getState().increment() 4. 异步操作在set函数中处理 我们的项目约定 - store文件放在src/stores/目录下 - 每个store导出useXxxStore命名的hook - 复杂逻辑用slice模式组织然后再让AI写代码它就能按照正确的方式使用了。虽然多了一步“教学”的成本但总比自己从头研究文档然后手写代码要快。5. 调试与测试建立可靠的反馈循环5.1 当AI卡住时及时切换思路AI不是万能的有时候会在一个错误思路上死磕。我的经验法则是如果AI连续3次尝试都解决不了同一个问题就该我介入了。最近遇到个bug用户上传的Excel文件解析后数据错位。AI先是怀疑编码问题尝试了UTF-8、GBK、Latin-1各种编码然后怀疑是换行符问题尝试了不同系统的换行符处理最后甚至怀疑是Excel版本问题。我看了它的调试过程发现它一直在“解析”这个环节打转。但我注意到错误数据有规律总是每隔5行错一位。我手动检查了原始文件发现文件里确实有隐藏的特殊字符。我告诉AI“不是解析问题是数据清洗问题。先过滤掉ASCII码小于32的控制字符再解析。”AI这才恍然大悟很快写出了正确的清洗逻辑。这个经验告诉我AI擅长在给定方向上深度探索但不擅长跳出框架思考。当它卡住时需要人类提供新的视角。5.2 为AI设计可调试的系统Armin Ronacher提到一个很重要的点日志对AI调试至关重要。我现在的代码里到处都是debug日志特别是关键决策点记录为什么选择这个分支外部调用记录请求参数和响应结果状态变化记录重要状态的前后值错误上下文记录错误发生时的完整上下文而且我专门为AI设计了一个“调试模式”。在.env里设置DEBUG_MODEtrue时发送的邮件不会真的发出去而是打印到控制台第三方API调用会被mock返回预设的响应数据库操作会被记录但不实际执行敏感信息会被脱敏显示这样AI就能在一个安全的环境里“跑通”整个流程看到每个步骤的输出更容易定位问题。5.3 让AI自己测试和修复Claude Code有个很好的功能可以配置成自动运行测试。我的工作流是这样的AI生成或修改代码自动运行相关测试如果测试失败AI查看失败信息AI尝试修复回到步骤2直到所有测试通过或达到最大重试次数配置方法是在CLAUDE.md里加上testing: command: npm test -- --testPathPattern auto_retry: true max_attempts: 3这样AI就能自己建立“修改-测试-修复”的循环。我只需要在最终审查时看看它改了什么不用手动运行测试、复制错误信息、让AI修复、再运行测试……5.4 用“子智能体”交叉验证有些复杂问题一个AI可能考虑不周。Anthropic建议的做法是用多个AI或者让一个AI扮演多个角色。我的实践是主AI负责写代码清空上下文或者开个新会话审查AI负责找问题“从安全角度审查这段代码”、“从性能角度分析这个实现”再把代码和审查意见一起给第三个AI整合AI负责根据意见修改代码比如最近写一个支付回调接口主AI的实现看起来没问题。但审查AI指出“这里没有验证签名可能被伪造请求。”整合AI就加上了签名验证逻辑。虽然多花了一点时间但避免了潜在的安全漏洞。对于关键代码这种“多智能体评审”是值得的。6. 代码审查与重构质量把关的最后防线6.1 像审查PR一样审查AI代码我对待AI生成的代码和对待同事的Pull Request一样严格。每次AI提交修改我都会逐行审查不只是看功能还要看代码风格、潜在bug、性能问题运行测试确保现有测试通过新功能有测试覆盖手动测试实际跑一下点点按钮输点边界值安全扫描检查是否有SQL注入、XSS等安全问题审查时我发现AI有几个常见问题过度抽象简单功能用了复杂的设计模式遗漏边界情况比如空数组、null值、超长字符串硬编码把配置值直接写在代码里重复代码相似的逻辑没有提取成函数我的审查评论通常长这样// 这里应该用const而不是let因为这个变量不会重新赋值 // 考虑添加输入验证防止SQL注入 // 这个函数太长了超过50行建议拆分成几个小函数 // 这里没有错误处理如果API调用失败会崩溃然后让AI根据评论修改。就像指导实习生一样指出问题给出改进方向但不直接替它改。6.2 让AI审查自己的代码这招听起来有点奇怪但实际效果很好。AI写代码时可能有些“盲点”但让它换一个角度审查自己的代码往往能发现问题。我的流程是AI写完代码后我让它“现在你是一个资深代码审查员用最严格的标准审查这段代码找出所有潜在问题。”AI会列出问题缺少错误处理、变量命名不清晰、没有注释、性能问题等我让它“根据你刚才的审查意见重构这段代码。”AI生成改进版有时候我还会指定具体的审查角度“从安全角度审查这段用户输入处理代码”“从性能角度分析这个数据库查询”“从可维护性角度评价这个组件设计”这种“自我审查”能发现很多第一遍写代码时忽略的问题。6.3 一定要亲自读代码Chris Dzombak说得对“无论代码是怎么产生的最终对它负责的是你。”AI生成的代码可能有各种问题逻辑错误算法实现有bug安全漏洞没有验证输入没有处理权限性能问题用了低效的数据结构或算法可维护性问题代码难以理解难以修改我见过AI生成的“优化”代码把O(n)的算法“优化”成了O(n²)。也见过它为了处理一个边界情况引入了更复杂的bug。所以我的原则是没读过的代码不提交没测试的功能不发布。无论AI写得有多快我都要花时间理解它写了什么。这不仅是技术负责也是职业操守。6.4 仔细检查完整的diff“氛围编码”vibe coding有个危险AI可能在你不知情的情况下修改了其他文件。比如你让它“给这个函数加个参数”它可能顺便“优化”了同一个文件里的其他函数。我吃过一次亏。让AI修改一个工具函数它确实加了参数但也“顺手”把函数里的错误处理逻辑改了从返回null改成了抛出异常。这个改动影响了十几个调用处但我没仔细看diff直接提交了结果线上报错。现在我的流程是AI生成修改后先看diff总览改了哪些文件对每个文件展开看具体改动特别关注是否修改了不相关的代码是否引入了新的依赖是否改变了接口约定是否删除了重要代码Claude Code的diff视图做得不错能高亮显示新增、删除、修改的行。我养成了习惯不看diff不点“接受”。6.5 不满意就一直改AI不会烦和人类同事合作时你让人家改太多次人家可能会不高兴。但AI不会你可以让它一直改到满意为止。我的常用指令“这个函数太长了拆分成几个小函数”“用更语义化的变量名”“加上详细的注释解释这个算法的原理”“优化性能这里的时间复杂度太高了”“加上单元测试覆盖边界情况”“用更现代的语言特性重写”有时候一个函数我能让AI重写五六次每次都有改进。从最基础的实现到加上错误处理到优化性能到加上日志到完善测试。AI就像个不知疲倦的助手只要你明确告诉它怎么改它就会一直改下去。6.6 在diff里直接编辑有时候AI的修改方向是对的但细节需要调整。与其让它重写不如我自己在diff里直接改。比如AI生成了这样的代码function calculateTotal(items) { return items.reduce((sum, item) sum item.price, 0); }我觉得应该处理一下item.price可能不是数字的情况就在diff里直接改成function calculateTotal(items) { return items.reduce((sum, item) { const price Number(item.price) || 0; return sum price; }, 0); }然后点“接受”。这样既利用了AI的基础实现又加上了我需要的健壮性检查。对于小的调整直接编辑比用语言描述更高效。特别是样式调整、字符串格式、简单的逻辑修正自己改可能就几秒钟让AI改还得等它生成、再审查。7. 跨阶段通用技巧提升整体协作效率7.1 根据任务切换AI的输出风格Claude Code支持不同的输出风格我根据当前任务灵活切换默认模式日常编码简洁直接解释模式学习新技术时让AI多解释为什么这么写教学模式带新人或自己学习时让AI留出TODO让我自己填空比如学一个新的图形库时我用教学模式// TODO(用户): 这里需要初始化画布上下文 const ctx canvas.getContext(2d); // TODO(用户): 设置绘制样式 ctx.fillStyle #FF0000; // 绘制一个矩形 ctx.fillRect(10, 10, 100, 100); // 从(10,10)开始宽100高100AI不仅生成代码还加了注释告诉我该做什么、为什么。我填完TODO后对代码的理解更深了。还可以创建自定义风格。我在~/.claude/output-styles/下创建了一个code-review.mdname: Code Review description: 严格的代码审查风格 instructions: | 你是一个严格的代码审查员。对每段代码 1. 指出潜在问题安全、性能、可维护性 2. 提出具体的改进建议 3. 解释为什么这么改更好 4. 如果问题严重建议重写 语气要专业但直接不用客气。需要审查代码时就切换到这种风格。7.2 任务间清空上下文AI的上下文窗口有限而且旧对话可能干扰新任务。我的习惯是完成一个任务后马上/clear清空上下文。特别是切换项目时避免A项目的代码影响B项目的理解切换任务类型时从写前端组件切换到写后端API时遇到困难问题时清空上下文从头开始思考长时间会话后上下文可能已经混乱清空后重新开始清空上下文就像重启电脑能解决很多奇怪的问题。有时候AI表现不正常不是它“笨”了而是上下文太乱。清空一下往往就恢复正常了。7.3 根据对话风格选择工具不同的AI工具有不同的“性格”我根据心情和任务选择Claude Code像合作愉快的同事会承认错误“你说得对我忽略了那个边界情况”会主动解释思路“我这么写是因为……”比较有创意能提出不同的解决方案适合探索性、创造性的工作Codex CLI像高效的机器人直接给出答案不多废话严格按指令执行不自由发挥会坚持自己的观点不容易被带偏适合明确的、重复性的任务Cursor介于两者之间比较平衡既有创造性又有纪律性对项目上下文理解较好适合日常开发工作我个人的使用习惯头脑风暴、探索方案用Claude Code写模板代码、重复劳动用Codex CLI日常功能开发用Cursor没有哪个工具是完美的关键是知道每个工具擅长什么在合适的场景用合适的工具。7.4 根据任务选择模型和推理模式Claude Code让我可以在任务开始时选择两个杠杆模型和推理模式。模型选择快速模型日常编辑、简单重构、写文档长上下文模型分析大型代码库、处理多个文件强视觉模型UI设计、图表生成、截图分析推理模式标准模式大多数任务扩展思考模式复杂问题、架构设计、模糊需求比如要设计一个新模块的架构我会切到长上下文模型让它能读取整个项目的相关文件开启扩展思考模式让它深入思考各种方案的利弊让它先出3个设计方案我选一个基于选中的方案出详细实现计划等具体实现时再切回快速模型提高响应速度。这种“按需配置”的思路能让AI的能力最大化发挥。8. 实战案例用这套方法开发一个完整功能最近我用这套方法开发了一个“数据导出”功能分享一下具体过程。8.1 需求分析与规划需求用户可以选择数据导出为Excel或CSV支持后台异步处理大文件分片下载。我先在Claude Code里进入规划模式请为数据导出功能制定实现计划要求 1. 前端选择数据、选择格式、触发导出、显示进度 2. 后端接收请求、生成文件、存储到对象存储、提供下载 3. 异步处理大文件需要后台生成提供任务状态查询 4. 安全性权限验证、防刷、文件类型限制 5. 列出需要创建/修改的文件评估风险给出验证方案AI给出了详细计划我调整了其中几点对象存储用MinIO而不是S3我们内网环境前端进度显示用WebSocket推送而不是轮询增加导出历史记录功能8.2 创建记忆文件在项目根目录更新CLAUDE.md增加导出相关的内容## 数据导出功能规范 ### 前端 - 导出组件路径src/components/export/ExportButton.tsx - 使用antd的Button、Modal、Progress、Table组件 - WebSocket连接ws://localhost:3000/ws/export-progress - 文件下载使用window.open避免阻塞 ### 后端 - 控制器路径src/modules/export/export.controller.ts - 服务路径src/modules/export/export.service.ts - 文件存储MinIO bucket名为exports - 异步处理使用Bull队列Redis做broker - 文件保留7天自动清理 ### 安全要求 - 导出前验证用户权限 - 单用户并发导出限制3个 - 单文件大小限制100MB - 支持的文件格式xlsx, csv8.3 分步实现第一步后端基础框架我自己写了核心的服务类定义接口interface ExportTask { id: string; userId: number; format: xlsx | csv; filters: Recordstring, any; status: pending | processing | completed | failed; fileUrl?: string; error?: string; createdAt: Date; } interface ExportService { createTask(userId: number, format: string, filters: any): Promisestring; getTaskStatus(taskId: string): PromiseExportTask; generateFile(task: ExportTask): Promisevoid; }然后让AI实现具体的生成逻辑、队列处理、MinIO上传等“体力活”。第二步前端组件我设计了组件接口interface ExportButtonProps { dataSource: any[]; availableFormats: Arrayxlsx | csv; onExportStart?: () void; onExportComplete?: (fileUrl: string) void; onError?: (error: Error) void; }让AI实现具体的UI和交互逻辑。不满意就让它重做“进度条样式不好看参考Ant Design的Progress组件重新设计”、“错误提示不够明显用Notification组件”。第三步测试我写了几个关键的测试用例describe(ExportService, () { it(应该验证用户权限, async () {}); it(应该限制并发任务数, async () {}); it(大文件应该分片处理, async () {}); });让AI补充具体的测试实现然后运行测试根据失败信息让它修复。8.4 调试与优化开发过程中遇到几个问题问题1生成大Excel文件时内存溢出 AI一开始用了一个全量加载的库我让它换成流式处理的库。它尝试了3个不同的库最后找到了一个合适的。问题2WebSocket连接不稳定 我让AI在连接断开时自动重连并加了指数退避策略。问题3进度显示不准确 我让AI在服务端计算总数据量分片处理时更新进度通过WebSocket推送给前端。每个问题都是AI尝试解决 → 我审查方案 → 让它调整 → 测试验证 → 最终定稿。8.5 代码审查与重构功能完成后我让AI用“代码审查”风格检查自己的代码发现了几个问题缺少输入验证用户可能传入恶意数据错误处理不完整某些异常情况没处理日志记录不足出了问题难排查部分代码重复可以提取公共函数根据审查意见AI重构了代码。我又手动检查了diff确认没有引入新问题。8.6 最终效果整个功能开发用了2天其中我自己写代码约4小时核心逻辑、接口设计、关键测试AI写代码约6小时具体实现、重复性工作沟通和审查约2小时规划、指导、审查如果没有AI估计要3-4天。更重要的是代码质量比我一个人赶工写出来的要高因为有多次审查和重构。9. 常见问题与避坑指南9.1 AI生成的代码有安全隐患怎么办这是我最担心的问题。我的应对策略输入验证必须自己写AI知道要验证输入但可能漏掉某些边界情况。所有用户输入的处理逻辑我都自己写或者至少仔细审查。敏感操作必须加权限检查删除数据、修改配置、访问敏感信息等操作我手动加上权限验证不让AI碰。依赖库要审查AI可能引入有安全漏洞的库。我用npm audit或类似工具扫描只允许使用经过审查的库。定期安全扫描用SAST工具扫描AI生成的代码特别是新加的功能。9.2 AI不理解业务逻辑怎么办这是AI的短板。我的做法创建业务术语表在CLAUDE.md里加一个业务术语章节解释领域概念## 业务术语 - 用户等级1普通2VIP3SVIP - 订单状态pending待支付paid已支付shipped已发货completed已完成cancelled已取消 - 优惠券类型percentage百分比折扣fixed固定金额shipping免运费提供业务逻辑示例把典型的业务逻辑代码贴给AI看让它模仿// 计算订单价格的业务逻辑 function calculateOrderPrice(order, user) { // 1. 计算商品总价 // 2. 应用会员折扣 // 3. 应用优惠券 // 4. 计算运费 // 5. 四舍五入到分 }复杂逻辑分步指导对于特别复杂的业务逻辑我拆成小步骤一步步指导AI第一步验证用户是否有购买资格 第二步检查库存是否充足 第三步计算基础价格 第四步应用促销规则 第五步生成订单记录9.3 AI写的代码性能不好怎么办AI为了“能工作”可能选择简单的实现而不是高效的实现。明确性能要求告诉AI性能要求// 这个函数会被频繁调用需要O(1)时间复杂度 // 数据量可能达到百万级需要注意内存使用 // 响应时间要求100ms提供性能测试用例让AI写完代码后再让它写性能测试// 测试万次调用的耗时 console.time(performance); for (let i 0; i 10000; i) { processData(largeDataset); } console.timeEnd(performance);手动优化关键路径对于性能关键的代码比如渲染循环、大数据处理我手动优化或者至少仔细审查AI的实现。9.4 如何保持代码风格一致不同AI、不同会话可能生成不同风格的代码。用ESLint/Prettier强制规范配置好代码检查工具让AI在生成代码后自动格式化。在记忆文件里定义代码风格## 代码风格 - 使用2空格缩进 - 字符串用单引号 - 函数和类之间空一行 - 导出用named export不用default export - 类型定义放在顶部定期统一重构每周用AI做一次代码风格统一检查src/目录下所有TypeScript文件确保 1. 导入语句按第三方、内部、类型分组 2. 接口名以I开头类型名以T开头 3. React组件用函数式组件不用类组件 4. 错误处理用try-catch不用.catch()9.5 团队如何协作使用AI一个人用AI容易团队协作就有挑战了。制定团队规范我们团队有这些约定所有AI生成的代码必须经过人工审查才能合并每个PR要注明哪些是AI生成的哪些是人工写的公共的CLAUDE.md要维护每个人都可以补充发现好的AI使用技巧要在团队内分享统一工具和配置全团队用同样的AI工具、同样的配置、同样的插件。避免“你的AI这么聪明我的AI这么笨”的情况。定期分享会每周分享AI使用心得发现了什么好用的技巧遇到了什么坑怎么解决的有什么功能希望AI实现代码审查时特别关注审查AI生成的代码时我们特别关注是否遵循了项目规范是否有隐藏的bug是否过度复杂是否有更好的实现方式10. 我的个人工作流总结经过两年的实践我现在的AI编程工作流已经比较稳定了早上开始工作打开项目运行/init确保CLAUDE.md是最新的看任务列表决定哪些自己写哪些交给AI对于AI任务先写详细的需求描述开发新功能规划阶段让AI出方案我审查调整设计阶段我写核心接口和类型定义实现阶段AI写具体实现我写关键算法测试阶段AI写测试用例我写边界测试审查阶段AI自我审查我最终审查日常维护小修改直接让AI改我审查diff重构我指定重构规则AI执行Bug修复AI分析日志提出修复方案我选择文档AI根据代码生成文档草稿我润色结束工作前运行所有测试确保AI的修改没破坏现有功能提交代码写清晰的commit message清空AI上下文准备第二天的工作这套工作流让我从“写代码”中解放出来更多时间花在“设计代码”和“审查代码”上。代码质量反而提高了因为AI不会累可以反复修改直到完美我不会因为赶进度而妥协代码质量。AI编程助手不是替代程序员的工具而是放大程序员能力的工具。用得好的话它能让你从繁琐的重复劳动中解脱出来专注于更有创造性的设计工作。用得不好它可能让你产出低质量、不安全的代码。关键是要建立正确的工作模式你是架构师和审查员AI是执行者。你负责思考“做什么”和“为什么”AI负责“怎么做”。你设定质量标准AI负责达到标准。你把握方向AI提供动力。这样协作才能既享受AI的效率又保证代码的质量。