我们将如何定义软件工程能力?

- 第 304 件杂货 -

2026年，最火的一个词一定是“Vibe Coding”，直译成“氛围编程”（我也不知道为什么会是这一个词语）。反正，“Vibe Coding”已经从硅谷、AI社区、程序员圈子，流行的趋势一直蔓延到全世界的各行各业，几乎有手就都能手搓各种软件应用。

简单讲，从“有一个想法”到“做出一个产品”，只要通过自然语言跟AI进行对话沟通，便可以从零开始打造出符合自己需求的软件产品。这样，人人都可以成为软件产品的Builder，无需任何软件编程背景，无需学习任何编程语言的语法和训练。

这意味着：我们即将开始用“意图”而不是“代码”来定义软件工程能力了。

AI的进化迭代实在太快太快了，一大堆概念可能都还没来得及深入理解，马上又有新的一波“新词语”如雨后春笋般冒出来，诸如：Agent、RAG、Prompt、MCP、CLI、Skill……这不，前段时间特别火的OpenClaw龙虾的余温（全民养小龙虾）还没消退，马上，Harness Engineering的概念又要迎面袭来了。

Open AI推出Codex工具，同时，带出了一篇极具影响力的文章《Harness engineering: leveraging Codex in an agent-first world》（来源：https://openai.com/index/harness-engineering/）。Open AI的软件工程团队用了5个月的时间做了一个试验：从一个空的Git代码仓库开始构建，交付、部署、故障和修复的整个从零到一过程，最重要的一点是“没有一行代码是人工编写”。测试团队反复强调：在实践过程的每一行代码 ，从应用逻辑、测试、CI 配置、文档、可观察性到内部工具“全都是由 Codex 编写”。

Open AI这个试验刻意限制了软件工程团队的核心编程能力，调整了他们的主要工作内容：设计环境、明确意图和构建反馈回路，从而使 Codex Agent能够可靠地工作，并反馈哪些地方出了问题，哪些问题相互叠加，以及如何最大化利用我们唯一真正稀缺的资源：人类的时间和注意力。

历时5个月，从只有3名工程师的小团队开始，让Codex生产了一百万行代码，处理了应用逻辑、基础设施、工具、文档到内部开发者工具等所有工作内容。直至，交付的这个产品已在数百名内测用户那里投入使用，也包括每天都在使用的内测高级用户，整个过程：人类没有直接写过一行代码。

稍微扒一扒Open AI这个试验的过程，发现，核心，几乎全部是些用Markdown文件搭建起来的Skill架构。在这个试验过程，他们确实也走了很长的一段弯路，其中，发现并纠正了一个很重要的理念“不要搞大型的AGENTS.md⁠”，别给Codex一本厚厚的说明书，而应该给Codex一张地图。因为，巨大的指令文件会挤掉任务、代码和相关文档，这样会严重影响Agent错位约束条件，所以，最好的做法是只要定义一份简短的AGENTS.md（大约 100 行）被注入到情境中，主要用作地图，并指向其他地方更深层次的真实信息来源来指导和约束Agent干活，效果才是最好。

当下，确实，已经，开始出现需要工程师直面的一个非常现实的情况：写代码所需要花费的时间远比写那些让AI干活的Markdown文件时间要短得多了。我们跟AI对话的方式经历了Prompt Engineering、Context Engineering和Harness Engineering，也许，未来我们会将软件工程能力定义为：如何定义 spec、如何编排任务、如何做监督的能力……而不再是代码的编写能力。

接下来的一段时间，可能真的要认真研究一下这些跟软件工程能力相关的Skill和Harness的这些东西了。毕竟，在养虾驯马的时代，当人类开始用“自然语言”便可直接塑造数字世界，当软件工业从“手工编码”进入“意图生成”阶段，当代码向着“内容行业化”发展的时候，我们又要开始重新追问那个最古老的问题：你到底理解这个世界吗？

码字的乐趣，因为您“推荐”