先说下我个人的AI Coding历程2024年接触AI IDE当时热门的是Cursor、Windsurf和开源的Cline但是基本无法独立完成项目当时IDE连终端都无法操作后续Windsurf率先支持操作终端开始初见端倪2025年初Trae发布前期免费于是上手开发了一个做监控视频筛选的工具体验下来已经可以独立完成项目但是成果未能达到预期就搁置了后续上传到Github做个纪念video_check2025年9月Qoder发布并赠送免费额度这时写了一个协同反馈项目Instareact场景用于视频工作室内部视频预审记录反馈最终完成了0-1的发布上线后续由于服务器资源有限便下线了服务这次完全走通从 需求-设计-开发-部署 的全套流程这段时间有个别人维护的项目无人打理开始尝试历史项目转为AI Coding的交付实践2025年10月受限于Qoder成果频繁修改以及免费等待时间较长便放弃恰逢Trae会员特价便充值会员才算是正式开始接盘上述项目Trae的活跃热力图-2025年2025年11月Trae下线Claude模型我就开始逐月付费使用Cursor效果也很好基本上1个需求迭代2-4次基本达到要求2026年3月由于自己还有Gemini会员便使用了1个月的Antigravity由于Pro额度较少主要用Flash模型效果欠佳1个需求有时要改6-10次尤其是对于历史项目经常连带影响正常功能2026年4月重新续费用Cursor并开发了一款基于禅道数据的管理看板ZenBoard解决团队管理可视化的问题目前还在优化仅实现了数据同步下一步梳理具体的团队数据如何呈现。去年接手的项目也在这个过程中完成了用户和权限体系重构并增加了若干新功能。当然包括前面的这些工作都是我在下班或者周末做的。毫不谦虚的说我应该是公司最早一批将AI IDE投入实际项目开发并做持续交付的在这个过程中见证了工具的发展和大模型能力的进步。通过多个项目的磨练我自己也总结了一套方法首先需要将需求以结构化的方式说明尤其需要将历史的关联影响也说清楚否则很容易影响历史功能。但是每次开发新功能时无法避免无法同时描述历史的需求点导致一个小功能的修改也需要做主流程回归测试才放心其次提交需求后需要提醒AI生成开发计划才能进行到具体的开发任务。原因和上一条一样需要约束和监管AI的动作避免失控最后在进入开发阶段需要避免一次完成过多任务否则过长上下文会导致质量下降虽然今年IDE都上线了自动化上下文压缩但是过长对话的影响还是存在基本上一个项目到这里就能满足功能可用而对于面向用户的项目前端部分往往就比较头疼AI IDE不存在还原度一说我认为主要是前端元素太多了AI无法准确的匹配到修改的位置导致简单的边距还不如人工修改来的快。前端部分的方案我一般用两种方式1直接找其他工具生成前端demo页面包含CSS样式让IDE直接复刻优势是样式能较快复制劣势是人工微调工作大2将一套设计风格由多模态大模型整理为 设计风格.md后续页面要求其参考风格文档开发优势是不需要人工调整基本可用劣势是如果企业有规范往往是无法彻底遵守只能听由AI发挥了到这里基本就把我个人目前使用 AI IDE 的方法基本梳理清楚了到这里其实基本都是我个人在做单体项目开发除了前面的执行方法我个人总结几条核心守则1能用付费就不用免费大模型最好用厂商的旗舰2能文字说清楚就不要丢图片3资料及时存档文件Git及时提交对于单体工程我已经轻车熟路了所以去年到今年年初的团队内分享会我们有一半的主题都是AI相关就是为了能将团队内的AI氛围浓度提高。而对于协同式的项目工程我一直比较担忧早期我曾尝试过前后端分离开发后端输出规范接口文档前端依据需求文档结合接口文档做开发从0-1的初期还可以勉强运行但是一旦代码量上来或者是对历史项目改造就出现两端问题频发且定位问题困难有时前后端项目各自的AI还会扯皮。最后我只好把前后端项目放在一个Workspace中相当于合并为一个大项目才正常。也是因为这段经历我对于AI Coding在跨部门、跨项目、跨服务的协同开发一直有很大的担忧首先跨部门的文档规范需要明确这点似乎还能解决基本就是接口描述文档不过公司内部这部分依旧是缺乏规范执行的其次对于跨项目和跨服务的开发由于缺少对历史项目的资料进行AI Coding时不可避免会对历史工程变更这就必须增加团队review成本和测试回归成本代码或许可以编译通过但是业务逻辑的隐形风险只能增加成本排雷再者甚至对于单纯的前端工作而言由于公司一般都有独特的公用组件和规范AI缺乏这方面的知识必然不会刻意遵守和使用这就需要公司或团队需要将相关组件和规范整理为标准文档在项目中要求AI务必参考这其实也是网上很多组织在实践协同AI Coding时强调的需要有统一的rules和sill库一项由CodeRabbit在2025年发布的、针对470个开源拉取请求PR的对比研究得出了令人震惊的结论与人类开发者编写的PR相比AI生成的代码修改所引入的问题平均高出1.7倍。更为致命的是这些问题并非简单的拼写错误而是严重偏向于重大或关键级别的缺陷其中逻辑相关错误的发生概率更是暴增了125%即2.25倍。此外斯坦福大学和Veracode的大规模行业安全评估均证实使用AI助手的开发者更容易产生过度自信从而编写出存在大量已知安全漏洞如SQL注入或跨站脚本攻击的不安全代码。来源1来源2当然这些担忧并不是阻碍公司落地AI Coding而是提醒我们需要在推进前做好准备工作就好似给到AI需要有规范的提示词那么推进AI Coding我们也应该摸索出一套独属于自己的规范以下来自AI个人整理后部署 AI 网关与数据脱敏企业级 AI 网关来集中管理所有的模型访问请求自动拦截或脱敏专有源代码、API 密钥等商业机密强制执行规划预设让 AI 大量生成核心业务功能之前要求开发者先利用 AI 完善历史代码库的 README 文档、增加注释并建立基准单元测试重构代码审查机制需要制定专门针对 AI 代码的审查指南重点排查其生成的逻辑悖论、不安全的依赖引入以及跨组件接口的错误调用高阶提示词与 AI 交互培训将 AI 工具的使用视为一门需要系统学习的高级技能。企业应重点培训开发者掌握“元提示”将指令深埋于上下文、“提示链”将复杂问题拆解递进推理以及上下文文件如建立统一的AGENTS.md的管理技巧。关注交付质量而非单纯产量坚决避免使用“生成的代码行数”这种虚假繁荣的指标。应系统化监测 AI 工具的采用率、AI 生成模块的缺陷率Bug Rates、代码审查PR周期的耗时变化以及系统的最终线上稳定性。最后我还是重申下我的观点目前AI Coding工具对团队的影响更多是提升效率而非替代人力。可以先在团队内推行观察效率提升后再决定是否需要调整人员配置而不是一上来就冲着减人去做。