大家好，我是陈哥。

最近 AI 圈又流行起来一个新词：Harness Engineering，给 AI 套上缰绳的约束系统。

前几天，Claude Code 源代码泄露这件事让大家对 Harness Engineering 的谈论达到了顶峰。昨天刚好和同事聊起来这件事，这次 51.2 万行代码因为一个打包配置失误就全部裸奔出去。

这看似是个偶然的安全事故，实际上却给了我们新的警示：我们传统的软件工程是绝对不能丢的。

先说说这次泄漏到底是怎么回事。这次纯粹是 Anthropic 公司自己在发布 npm 包的时候，把本该排除的 source map 文件给打包进去了。

这个文件一公开，任何人都能还原出完整的、没混淆的 TypeScript 代码，从前端界面、交互逻辑，到提示词工程、核心推理引擎，甚至没有发布的功能全暴露了。

更讽刺的是，这不是第一次，他们之前就犯过一模一样的错误。一个估值几百亿的 AI 明星公司，做出这么低级的失误，很多人觉得不可思议。

但在我看来，这恰恰是软件行业所有公司都可能遇到的情况。现在的大家太迷信 AI 了，反而把软件工程最基础、最核心的东西给丢了。

我说的传统的软件工程是什么？我认为是一套经过几十年、几代人验证过的能保障软件质量和安全的体系。

从需求分析、架构设计、代码规范、评审机制，到构建流程、测试验证、发布管控、安全审计，避免出现一些没必要的错误。

就拿这次的问题来说吧。在传统流程里，构建发布是有严格关卡的。代码提交后，谁能合并、合并前要不要评审、构建脚本谁写、谁审核、发布前有没有清单检查、有没有安全扫描、有没有二次校验，这些都是标准化动作。

可现在呢？很多企业为了快，把这些流程全砍了。大家觉得有 AI 帮忙，那些老流程都是累赘，拖慢效率。

开发人员把精力都放在怎么写好提示词、怎么让 AI 生成更多代码，却忽略了最基本的工程规范。再往深一层想，AI 能替代工程师写代码，但它能替代软件工程的核心吗？

AI 生成代码再快，它理解的是语法、是模式，不是业务本质，不是架构的权衡。

一个复杂系统，怎么拆模块、怎么定接口、怎么保证扩展性、怎么处理并发和容错，这些架构决策，靠的是工程师多年的经验、对业务的深刻理解，还有多方评审、反复推演。

AI 做不了这个，它只能在人定好的框架里填东西。

就像《大模型做从 0 到 1 的事，人做从 1 到 N 的事》一文所说的：

但是从 1 到 N，我们开始做精雕，就需要让大模型按照我们预期的方向输出结果，而这种控制就比较有挑战了。大模型的概率运行机制决定了它不会严格按照我们的预期输出结果。这也是为什么我们跟大模型进行多轮交互后，大模型很容易出现上下文错乱、记忆丢失、大模型开始降智等现象。

代码写出来只是第一步，后续还有更重要的质量保障，这些都要靠人来完成，靠人把问题堵在产品上线前。

这次 Claude Code 的事就是个活生生的例子。AI 再强，也补不了工程能力的短板。

我不反对 AI，恰恰相反，我支持所有人都拥抱 AI。我们团队现在也在用各种 AI 辅助工具，写代码、写用例、查问题，效率确实高很多。

但 AI 只是放大器，它能帮我们省力气、提速度，但决定一个软件稳不稳、安不安全、能不能长久走下去的，还是要靠程序员本身的能力。

一个合格的工程师是在 AI 帮你写完代码后，你能看懂、能判断、能优化、能守住质量和安全的底线。而一个好的团队是不管用什么工具，都能守住软件工程的底线，不让 51.2 万行代码因为一个配置失误就全网裸奔。

说句题外话，这次事件之后，肯定会有很多公司去抄 Claude Code 的架构、抄它的提示词逻辑。

对一个产品或者一个公司来说，这都不是重要的，想要真正能走得远的，一定是那些把 AI 工具和传统软件工程结合起来的团队。

所以，不管 AI 怎么发展，传统软件工程的核心永远不会过时，也永远不能被替代。

工具是可以变的，但扎实的基本功和严谨的工程思维是不变，这也是一个程序员、一个团队真正的底气。

把这些能力落地的一个重要载体就是 Harness Engineering 体系。下篇文章，我们再具体聊聊 Harness Engineering。