企业内部协同下的AI Coding思考
先说下我个人的AI Coding历程：
2024年接触AI IDE，当时热门的是Cursor、Windsurf和开源的Cline，但是基本无法独立完成项目，当时IDE连终端都无法操作，后续Windsurf率先支持操作终端，开始初见端倪；
2025年初，Trae发布，前期免费，于是上手开发了一个做监控视频筛选的工具，体验下来已经可以独立完成项目，但是成果未能达到预期就搁置了，后续上传到Github，做个纪念（video_check）；
2025年9月，Qoder发布并赠送免费额度，这时写了一个协同反馈项目（Instareact），场景用于视频工作室内部视频预审记录反馈，最终完成了0-1的发布上线，后续由于服务器资源有限便下线了服务，这次完全走通从 需求-设计-开发-部署 的全套流程；
这段时间，有个别人维护的项目无人打理，开始尝试历史项目转为AI Coding的交付实践；
2025年10月，受限于Qoder成果频繁修改，以及免费等待时间较长便放弃，恰逢Trae会员特价，便充值会员，才算是正式开始接盘上述项目；
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工具对团队的影响更多是提升效率，而非替代人力。可以先在团队内推行，观察效率提升后，再决定是否需要调整人员配置，而不是一上来就冲着减人去做。