这两年AI编码工具确实给开发效率带来了很大提升。写脚本更快了补测试更轻松了搭原型更顺手了连很多文档工作都被大幅压缩。笔者自己在持续使用GPT-5.4 和 Claude一段时间后也真切感受到了这种效率红利。与此同时随着使用越来越深入笔者也开始经常在架构师论坛和技术社区里围绕 AI开发的安全性、保密性、稳定性、可控性等问题与多位大厂架构师持续交流。讨论得越多、实践得越久我越认同一个判断小项目、低敏项目、单人维护项目AI基本没有大问题但一旦进入多人协作、长期演进、涉及核心资产和生产责任的项目AI如果没有边界、规范和审计就很容易从“效率工具”变成“失控放大器”。很多人讨论 AI还停留在“能不能更快把功能做出来”这个层面。但架构师的关注点从来不只是“能不能开发出来”而是“这个系统能不能长期、安全、可控地活下去”。对架构师而言安全性、保密性、可用性、可靠性、稳定性、可扩展性、可治理性永远排在“先把功能跑起来”前面。AI 当然能用但如果用法不对前期越快后期越危险。阿里巴巴对18个AI编码代理在100个真实代码库上进行了测试每个代码库的测试时间长达233天。结果惨败。事实证明通过一次测试很容易。但要让代码在八个月内保持稳定运行而不出现任何问题这才是人工智能的真正弱点最近发现一个巨牛的人工智能学习网站里面的内容一点都不枯燥把 AI知识讲得通俗易懂还特别风趣幽默不管是想入门的小白还是想补基础的朋友都超适合,可以点击去学习一、安全性和保密性问题这不是建议而是红线在所有 AI 开发风险里安全性和保密性必须排在第一位而且要说得足够重。很多人有一个很危险的误区以为自己只是发了一段代码、一个报错、一份配置没有什么大不了。真正的问题不在于单次发送了什么而在于长期、连续、碎片化地把项目上下文喂给模型之后模型会逐步拼出整个系统的关键轮廓。对企业来说完整代码仓一旦被暴露泄露出去的可能不仅是实现细节更是产品壁垒。核心推荐算法、风控规则、任务编排方式、数据校验逻辑、用户画像模型、供应链定价策略都可能通过代码和配置被还原。对政府和国央企来说风险更高。因为很多系统的敏感性并不体现在“代码是否复杂”而体现在权限体系、业务流转、组织流程、网络边界和安全策略。一份接口文档可能暴露部门间的数据流转方式一份配置文件可能暴露中间件、注册中心和环境划分方式一份数据样本可能暴露真实字段规则、业务状态机甚至审计链路。这些内容如果被完整送到境外模型服务性质就完全不同了。公开案例已经足够说明问题。2023 年三星出现员工将源代码和内部资料输入 ChatGPT 的事件随后企业迅速收紧政策。苹果曾限制内部使用 ChatGPT 和 GitHub CopilotJPMorgan、Verizon 也曾对员工使用外部生成式 AI 进行限制。它们不是“不懂 AI”恰恰相反正是因为太懂风险所以才会第一时间踩刹车。大公司如此中小公司更不能掉以轻心。很多创业团队和小外包团队为了省时间最容易把生产报错、客户样本数据、数据库结构、支付回调字段、权限接口约定整段发给模型。表面看是“快了半小时”实际上是在把最值钱的知识资产一点点送出去。所以第一条结论必须明确不可能也不应该把本地完整项目完整发送给 AI 一次更不能让 AI 对整个仓库自行搜索后再把全量上下文发往外部云端。 对企业、政府、国央企项目而言这不是优化建议而是最基本的安全红线。二、可控性问题AI 能写代码但不保证沿着同一条主线写代码AI 的第二个大问题是可控性。很多团队一开始觉得它特别好用因为它几乎总能给出一个“像样的答案”。问题在于软件工程不是一次性答题而是持续演进。今天这个功能让 GPT 写明天另一个功能让 Claude 写后天换个人、换个 prompt、换个模型出来的往往就不是同一种思路。小项目里这种差异未必致命最多只是风格不统一。但一旦进入多人协作和长期维护这种不可控就会迅速累积成结构性问题。比如今天用户认证模块被 AI 按一种方式抽象明天订单模块又被另一种方式封装今天日志体系是统一埋点明天 AI 为了“快速修复”绕过了标准组件今天缓存策略写在服务层后天 AI 又把同类逻辑塞回控制层。每一处改动看起来都“能跑”但整个系统却在慢慢失去主线。大公司里这种问题会体现为标准失效。一个平台团队规定了统一网关、统一鉴权、统一日志可不同小组如果都依赖不同 AI 工具自由生成实现最终还是会出现“同一件事七八种写法”。小公司里这个问题更直接。往往是两三个人轮流用不同模型改同一个项目短期内速度惊人三个月后却发现没人敢重构因为没人说得清哪一段是基于什么上下文、什么假设写出来的。AI 最容易制造的错觉就是“它很聪明所以它会自然走向正确结构”。但现实恰恰相反AI 会优先给出局部最像答案的东西却不会天然替你维护全局一致性。 如果没有架构约束、目录约束、分层约束和评审约束AI 写得越多系统越容易偏航。三、稳定性问题一次跑通很容易长期不塌才是真难点很多团队在使用 AI 后会产生一种错觉代码生成出来了测试也过了于是觉得这件事已经“解决了”。事实上一次运行成功和长期稳定可维护是两回事。AI 当前最大的短板之一不在于它写不出功能而在于它很难持续、稳定地维护一个长期演进的系统。2026 年 3 月 4 日公开的论文《SWE-CI》给了这个问题一个很有力的提醒。这项研究由中山大学与阿里巴巴集团研究者提出测试并不是看模型能不能“一次修好一个问题”而是看它在真实代码库的连续维护过程中能否不破坏原有功能。论文包含 100 个真实代码库任务平均跨越 233 天、71 次连续提交。围绕这项研究的公开解读普遍提炼出一个结论很多模型短期表现可以但一旦进入长期维护回归问题会不断累积。这恰恰说明AI 的强项更像是“阶段性产出”而不是“长期守住系统稳定”。公开事件中也有类似信号。2025 年Replit 相关 AI 代理事故引发广泛关注外界讨论的焦点不是“它能不能写代码”而是它在自动执行过程中触碰了不该触碰的生产数据并且没有可靠地守住边界。大公司里稳定性问题通常表现为发布后隐性回归增加测试负担变重修一个点带出另一个点小公司里稳定性问题更像“今天这版能跑明天一改就炸改到最后谁也不敢上线”。所以必须承认一个现实通过一次测试很容易但让代码在八个月甚至更长时间内稳定运行、不出现结构性回归这才是 AI 在工程维护中的真正弱点。 如果团队只看眼前速度不看长期稳定最终一定会被后续维护成本反噬。四、多人协同问题AI 不会自动形成共识只会放大已有混乱多人协作是 AI 使用中另一个极容易被低估的问题。单人项目里一个人用一个模型逻辑链条还算完整一旦多人同时参与每个人的提示方式、理解方式、审美方式、风险意识都不同AI 产物就会迅速变得碎片化。例如大厂里一个中台项目往往涉及多个团队协作。如果没有统一约束A 团队用一种方式设计接口B 团队用另一种方式补错误码C 团队再用第三种方式写权限校验最后系统表面上是同一套服务内部却是多种工程哲学混杂。小公司则常常出现更典型的情况前端一个人用 GPT后端一个人用 Claude测试再根据另一个模型生成用例结果每个人都“效率大增”但整个项目的术语、命名、分层、异常策略完全对不上。AI 不会帮团队自动统一语言也不会帮组织自动沉淀规范。它只会把现有组织的问题放大。如果组织本身没有主线、没有规范、没有清晰边界那么 AI 带来的不是协同而是加速分裂。今天大家都觉得自己省了时间半年后你会发现真正消耗掉的是跨人理解成本、代码整合成本和历史追溯成本。五、责任问题出了事背锅的永远不是模型而是使用它的人和组织AI 的最后一个核心问题是责任性问题。很多人习惯性地把 AI 看成一个“很会写东西的助手”于是潜意识里会觉得如果哪里出了问题那大概率是“模型不靠谱”。但在真实世界里责任从来不会落到模型身上而只会落到人和组织身上。Air Canada 的聊天机器人曾给用户提供错误信息最终承担责任的是航空公司而不是机器人。美国纽约律师因为使用 ChatGPT 生成虚假判例并提交法庭最终被处罚的是律师和律所而不是模型供应商。这两个案例其实已经把逻辑说透了AI 可以参与生成但不能替代责任主体。放到软件工程里道理完全一样。一个金融系统因为 AI 生成的边界判断错误导致风险控制失效责任在公司一个政务系统因为 AI 补出的权限逻辑存在漏洞导致数据越权责任在建设方一个国央企生产系统因为 AI 生成的调度策略存在隐蔽缺陷引发事故责任不可能推给“大模型理解错了”。如果组织在使用 AI 时没有审查、没有审批、没有留痕、没有回滚机制那么出问题只是时间问题。真正可行的解决方案不是拒绝 AI而是把 AI 放进治理框架*说了这么多并不是要否定 AI。恰恰相反AI 仍然是这个时代非常有价值的生产力工具。关键不在于“用不用”而在于“怎么用”。第一必须先划红线再谈提效。完整仓库、核心算法、生产配置、真实数据样本、内网拓扑、证书密钥、关键接口文档原则上不能直接交给外部尤其是境外模型。能私有化尽量私有化能本地化尽量本地化至少也要做到最小必要暴露。第二必须先定主线再让 AI 参与。架构、分层、目录结构、依赖边界、异常机制、日志规范、权限策略必须由人先定好。AI 可以在明确边界内补代码、补测试、补文档但不能代替架构师决定整个系统怎么长。第三必须把 AI 关进规则里。什么目录能改什么操作不能做生成代码要过哪些测试要经过谁评审要不要灰度要不要回滚预案都应该制度化、工具化而不是靠个人自觉。提示词模板、技能固化、代码扫描、单测门禁、Secrets 扫描、审计留痕一个都不能少。第四多人协作必须有总线。团队可以用不同 AI但不能没有统一技术主线。谁负责公共能力谁负责基础设施谁负责业务模块什么能改什么不能随便动要足够清晰。AI 只能加速统一路线不能替代统一路线。第五核心模块必须人能看懂、敢负责。凡是涉及鉴权、账务、风控、调度、审计、加解密、事务一致性、消息可靠性等关键部分负责人必须能讲清楚逻辑必须能解释为什么这么设计也必须能承担最终责任。AI 写出来的内容如果人自己都没有真正理解就绝不能轻易上生产。归根到底AI 最适合做的是加速器而不是方向盘。它可以帮助我们更快写代码、更快补测试、更快搭原型但它不能替代架构治理不能替代安全边界不能替代责任承担。尤其对企业、政府、国央企本身或者其项目来说面对国外大模型更要保持基本的安全敬畏。你送出去的看似是一些上下文真正送出去的可能是多年沉淀下来的核心算法、业务规则、工程方法和组织知识。所以真正清醒地使用 AI不是把判断权交给 AI而是把 AI 纳入人的判断体系不是让 AI 决定工程而是让工程决定 AI 如何被使用。小项目、低敏项目、单人维护项目AI 完全可以大胆用但一旦进入多人协作、长期演进、涉及核心资产和生产责任的场景就必须先有边界、再有规范、再有审计、再谈效率。否则今天它帮你提速明天它就可能把整个系统拖进不可控的泥潭。未来真正有竞争力的团队不是“最会让 AI 写代码”的团队而是“最会给 AI 设边界、定规则、做治理”的团队。谁能做到这一点谁才能真正享受到 AI 的红利而不是被 AI 反过来绑架。