这篇想写给三类人。

第一类，是正在用 AI 写代码、但不想只停留在“工具好不好用”的编程同学。

第二类，是积极学习、正在从编程者走向项目负责人、技术负责人、数字化管理者的同学。

第三类，是老板、IT 负责人和数字化负责人。

因为 AI 编程工具进公司以后，它就不只是一个技术问题。

它会变成效率问题、权限问题、数据问题和管理问题。

昨晚看到卡兹克写 LongCat，他把这件事放进“国产 AI 两个万亿”的背景里看。

一个万亿，是 LongCat-2.0 这种万亿级参数模型。

从公开资料看，LongCat-2.0 面向 coding 和 agentic task，强调长上下文、工具调用、多步推理和复杂指令执行。

简单说，AI 写代码这件事还会继续加速。

另一个万亿，是国产算力公司在资本市场冲上万亿市值。

这两个消息放在一起，再叠加最近 Claude 被频繁讨论的封号问题，确实有一种时代感。

它提醒我们的不是“又多了一个模型”。

而是：

企业能选择的模型和算力供给，正在变多。

过去很多人用 Claude、GPT、Cursor、Codex，潜意识里都觉得“最好的东西在外面”。

一旦遇到封号、限流、涨价、合规审查，业务就容易卡住。

现在 LongCat 这类模型起来以后，企业很自然会产生一个新想法：

那我们是不是也该把 AI 编程、AI Agent 更快放进公司？

我赞成试。

但我更想提醒的是：

模型供给越丰富，企业越不能只问“哪个模型最强”。

因为 AI 编程工具一旦进公司，它碰到的不是单纯的聊天窗口，而是代码库、配置文件、终端、密钥、接口、数据库和外部服务。

这两天另一个值得警惕的消息，是 Claude Code 又被安全研究人员盯上了。

有研究演示，一个看起来很干净的 GitHub 仓库，也可能通过说明文档、初始化脚本、依赖配置等方式，引导 AI 编程助手一步步执行隐藏动作，最后把开发者电脑里的密钥、会话和代码暴露出去。

所以我把 LongCat 和 Claude Code 放在一起看。

我的第一反应不是：

AI 写代码到底强不强？

而是：

公司准备让 AI 写代码之前，到底有没有先管住权限？

别把 LongCat 只当成模型新闻

卡兹克那篇文章给我的启发是：

LongCat 这个热点，表面上是模型新闻，背后是供给变化。

模型供给变多，算力路线变多，企业做 AI 的选择也会变多。

这当然是好事。

但站在企业管理者的角度，我更关心下一步：

当模型选择变多、成本可能下降、工具更容易接入以后，公司内部会不会更快出现一堆“个人先用起来”的 AI 编程工具？

这个阶段最容易失控。

不是因为员工不负责任。

而是因为工具太好用了，大家会先把效率跑起来，再回头补规则。

而企业最怕的，就是规则永远慢半拍。

所以这篇文章，我不准备讨论 LongCat 能不能替代 Claude，也不讨论哪个模型代码能力第一。

我只讨论一个更落地的问题：

公司开始让 AI 写代码之前，权限边界怎么定。

很多公司看 AI 编程工具，第一反应是效率。

能不能快点写脚本？

能不能帮我改 bug？

能不能自动生成接口？

能不能把测试补上？

这些当然重要。

但 AI 编程工具和普通聊天机器人不一样。

聊天机器人多数只是回答问题。

AI 编程工具可能会读代码仓库，打开配置文件，调用终端，安装依赖，运行脚本，访问外部服务，甚至接触数据库连接串、API Key、云账号和 CI/CD 凭证。

这就不是“一个更聪明的实习生”。

它更像一个拿到键盘、代码库和部分系统权限的数字化员工。

所以企业真正要担心的，不只是它写错几行代码。

写错代码还能 review。

真正麻烦的是三件事：

它能看到不该看的东西。

它能执行不该执行的命令。

它能把不该带出去的信息带出去。

我把这三件事，拆成三类权限。

第一类：读权限

先说它能看什么。

很多人让 AI 写代码时，习惯把整个项目丢进去。

这样确实方便。

但公司代码库里往往不只有代码。

里面可能有配置文件、接口文档、日志样本、客户字段、测试账号、部署说明、内部域名，甚至有人把密钥和连接串写在了不该写的地方。

AI 看得越多，能力越强。

但企业风险也越大。

我的建议是，第一批试点不要让 AI 直接读核心代码库。

先从三类低风险内容开始：

第一，非核心模块。

比如内部小工具、报表脚本、测试项目、历史工具库。

第二，脱敏后的代码片段。

只给它解决问题需要的上下文，不把整个项目一次性开放。

第三，公共规范和接口说明。

比如代码规范、命名规范、接口返回格式，而不是生产配置。

一句话：

AI 能看多少，不应该由员工随手决定，而应该由任务需要决定。

第二类：执行权限

再说它能做什么。

这次 Claude Code 安全事件里，最值得企业警惕的地方，不是某一条命令有多复杂。

而是 AI 编程助手很容易为了“帮你把项目跑起来”，主动执行下一步。

它看到 README 里写了初始化步骤，可能会照做。

它运行脚本报错，可能会继续找办法修。

它看到缺依赖，可能会安装。

它看到环境没配好，可能会帮你补。

这在正常项目里叫贴心。

在恶意仓库里，就可能变成风险入口。

所以企业要先定规则：

哪些命令 AI 可以建议，但不能自动执行？

哪些命令必须人工确认？

哪些命令永远不能让 AI 执行？

第一批试点时，我会允许 AI 做这些事：

解释代码。

生成测试。

提出修改建议。

生成补丁。

在隔离环境里跑普通测试。

但不会让它直接做这些事：

运行未知仓库的安装脚本。

修改生产配置。

执行数据库迁移。

推送代码到主分支。

操作云资源和线上环境。

如果一定要运行，也要放进沙箱环境。

不要让 AI 在员工自己的主力电脑、真实云账号、真实数据库连接环境里乱跑。

这不是不信任 AI。

这是正常的工程边界。

第三类：外联权限

最后是它能连到哪里。

这一点很多企业容易忽略。

AI 编程工具越来越不只是一个编辑器插件。

它可能会连 GitHub、包管理平台、云服务、数据库、MCP 工具、内部文档、IM 工具，甚至浏览器会话。

一旦外联权限放开，问题就变成：

它能不能访问外部仓库？

它能不能调用未知接口？

它能不能读取环境变量？

它能不能接触长期有效的密钥？

它能不能把本地文件发出去？

以前一个人点错命令，是人的问题。

现在 AI 可以帮人更快地点错。

所以外联权限至少要有三条底线。

第一，密钥隔离。

不要让 AI 工具接触长期有效的生产密钥。能用短期 token，就不要用长期凭证。

第二，网络白名单。

试点阶段，AI 工具能访问哪些外部服务，要有范围。

第三，日志可追踪。

AI 做过什么、读过什么、执行过什么、建议过什么，要能回头看。

没有日志，就没法复盘。

没有复盘，就不叫企业级试点。

先做一张权限表

如果公司问我，AI 编程工具到底能不能上？

我的答案不是不能上。

恰恰相反，我觉得一定要试。

LongCat、Claude Code、Cursor、Codex 这一类工具继续往前走，软件开发方式肯定会变。

但企业不能只问“买哪个工具”。

要先做一张权限表。

这张表不复杂。

但它能把一个模糊问题讲清楚：

AI 不是“能不能用”，而是“在什么边界里用”。

这张表做完，企业再谈 AI 编程提效，才不是裸奔。

一周怎么试

如果你们公司还没有系统管起来，我建议先跑一周小试点。

写在最后

AI 写代码会越来越强。

这件事不用怀疑。

LongCat 这类模型出来以后，企业会看到更多选择，成本和能力都会继续变化。

但 Claude Code 这类安全事件也在提醒我们：

AI 编程工具不是普通效率工具，它是带执行能力的数字化员工。

企业真正要补的，不是又买一个账号。

而是先回答三个问题：

它能看什么？

它能执行什么？

它能连到哪里？

这三个问题说不清楚，AI 写代码越强，企业风险越大。

如果你们公司已经有人在用 Claude Code、Cursor、Codex 或类似工具，我建议先别急着评价“好不好用”。

先问一句：

这些工具现在是个人自己随便用，还是已经纳入公司权限管理？

这个问题，比“写代码快 30%”更重要。