Claude Code源代码泄露，Harness Engineering是救星吗

大家好，我是陈哥。

最近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。