这两年，AI 编码工具确实给开发效率带来了很大提升。写脚本更快了，补测试更轻松了，搭原型更顺手了，连很多文档工作都被大幅压缩。笔者自己在持续使用主流大模型一段时间后，也真切感受到了这种效率红利。与此同时，随着使用越来越深入，笔者也开始经常在架构师论坛和技术社区里，围绕 AI 开发的安全性、保密性、稳定性、可控性等问题，与多位大厂架构师持续交流。讨论得越多、实践得越久，我越认同一个判断：小项目、低敏项目、单人维护项目，AI 基本没有大问题；但一旦进入多人协作、长期演进、涉及核心资产和生产责任的项目，AI 如果没有边界、规范和审计，就很容易从'效率工具'变成'失控放大器'。
很多人讨论 AI，还停留在'能不能更快把功能做出来'这个层面。但架构师的关注点从来不只是'能不能开发出来'，而是'这个系统能不能长期、安全、可控地活下去'。对架构师而言，安全性、保密性、可用性、可靠性、稳定性、可扩展性、可治理性，永远排在'先把功能跑起来'前面。AI 当然能用，但如果用法不对，前期越快，后期越危险。
阿里巴巴对 18 个 AI 编码代理在 100 个真实代码库上进行了测试，每个代码库的测试时间长达 233 天。结果惨败。事实证明，通过一次测试很容易。但要让代码在八个月内保持稳定运行而不出现任何问题，这才是人工智能的真正弱点。
一、安全性和保密性问题：这不是建议，而是红线
在所有 AI 开发风险里，安全性和保密性必须排在第一位，而且要说得足够重。很多人有一个很危险的误区：以为自己只是发了一段代码、一个报错、一份配置，没有什么大不了。真正的问题不在于单次发送了什么，而在于长期、连续、碎片化地把项目上下文喂给模型之后，模型会逐步拼出整个系统的关键轮廓。
对企业来说，完整代码仓一旦被暴露，泄露出去的可能不仅是实现细节，更是产品壁垒。核心推荐算法、风控规则、任务编排方式、数据校验逻辑、用户画像模型、供应链定价策略，都可能通过代码和配置被还原。对政府和国央企来说，风险更高。因为很多系统的敏感性并不体现在'代码是否复杂'，而体现在权限体系、业务流转、组织流程、网络边界和安全策略。一份接口文档，可能暴露部门间的数据流转方式；一份配置文件，可能暴露中间件、注册中心和环境划分方式；一份数据样本，可能暴露真实字段规则、业务状态机甚至审计链路。这些内容如果被完整送到境外模型服务，性质就完全不同了。
公开案例已经足够说明问题。2023 年，三星出现员工将源代码和内部资料输入 ChatGPT 的事件，随后企业迅速收紧政策。苹果曾限制内部使用 ChatGPT 和 GitHub Copilot，JPMorgan、Verizon 也曾对员工使用外部生成式 AI 进行限制。它们不是'不懂 AI'，恰恰相反，正是因为太懂风险，所以才会第一时间踩刹车。大公司如此，中小公司更不能掉以轻心。很多创业团队和小外包团队为了省时间，最容易把生产报错、客户样本数据、数据库结构、支付回调字段、权限接口约定整段发给模型。表面看是'快了半小时'，实际上是在把最值钱的知识资产一点点送出去。
所以第一条结论必须明确：不可能也不应该把本地完整项目完整发送给 AI 一次，更不能让 AI 对整个仓库自行搜索后再把全量上下文发往外部云端。对企业、政府、国央企项目而言，这不是优化建议，而是最基本的安全红线。
二、可控性问题：AI 能写代码，但不保证沿着同一条主线写代码
AI 的第二个大问题，是可控性。很多团队一开始觉得它特别好用，因为它几乎总能给出一个'像样的答案'。问题在于，软件工程不是一次性答题，而是持续演进。今天这个功能让 GPT 写，明天另一个功能让 Claude 写，后天换个人、换个 prompt、换个模型，出来的往往就不是同一种思路。
小项目里，这种差异未必致命，最多只是风格不统一。但一旦进入多人协作和长期维护，这种不可控就会迅速累积成结构性问题。比如，今天用户认证模块被 AI 按一种方式抽象，明天订单模块又被另一种方式封装；今天日志体系是统一埋点，明天 AI 为了'快速修复'绕过了标准组件；今天缓存策略写在服务层，后天 AI 又把同类逻辑塞回控制层。每一处改动看起来都'能跑'，但整个系统却在慢慢失去主线。
大公司里，这种问题会体现为标准失效。一个平台团队规定了统一网关、统一鉴权、统一日志，可不同小组如果都依赖不同 AI 工具自由生成实现，最终还是会出现'同一件事七八种写法'。小公司里，这个问题更直接。往往是两三个人轮流用不同模型改同一个项目，短期内速度惊人，三个月后却发现没人敢重构，因为没人说得清哪一段是基于什么上下文、什么假设写出来的。
AI 最容易制造的错觉，就是'它很聪明，所以它会自然走向正确结构'。但现实恰恰相反：AI 会优先给出局部最像答案的东西，却不会天然替你维护全局一致性。如果没有架构约束、目录约束、分层约束和评审约束，AI 写得越多，系统越容易偏航。
三、稳定性问题：一次跑通很容易，长期不塌才是真难点
很多团队在使用 AI 后会产生一种错觉：代码生成出来了，测试也过了，于是觉得这件事已经'解决了'。事实上，一次运行成功，和长期稳定可维护，是两回事。AI 当前最大的短板之一，不在于它写不出功能，而在于它很难持续、稳定地维护一个长期演进的系统。
近期公开的论文《SWE-CI》给了这个问题一个很有力的提醒。这项研究由中山大学与阿里巴巴集团研究者提出，测试并不是看模型能不能'一次修好一个问题'，而是看它在真实代码库的连续维护过程中，能否不破坏原有功能。论文包含 100 个真实代码库任务，平均跨越 233 天、71 次连续提交。围绕这项研究的公开解读普遍提炼出一个结论：很多模型短期表现可以，但一旦进入长期维护，回归问题会不断累积。这恰恰说明，AI 的强项更像是'阶段性产出'，而不是'长期守住系统稳定'。
公开事件中也有类似信号。2025 年，Replit 相关 AI 代理事故引发广泛关注，外界讨论的焦点不是'它能不能写代码'，而是它在自动执行过程中触碰了不该触碰的生产数据，并且没有可靠地守住边界。大公司里，稳定性问题通常表现为发布后隐性回归增加，测试负担变重，修一个点带出另一个点；小公司里，稳定性问题更像'今天这版能跑，明天一改就炸，改到最后谁也不敢上线'。
