在 AI 辅助开发逐渐成为常态的今天，一个问题开始浮现：人类与 AI 协作完成软件的过程中，人类到底在做什么？如果我们把这个过程类比为”编程”，那么这种新形态下的”源代码”是什么？它是否也应该具备传统源代码的某些基本属性？

要回答这个问题，不妨回顾一下编程抽象层级的演进。

编程抽象的演进

在没有编译器之前，人类直接手写机器码。每一行指令都对应 CPU 的实际操作，没有任何抽象层。后来有了汇编语言，人类用助记符替代二进制，编译器负责把汇编翻译成机器码。这是编程抽象的第一次飞跃。

随后出现了 C、C++ 等中高级语言。人类写出更接近自然思维的源代码，编译器承担了生成和优化目标代码的繁重工作。对于 Python 这类脚本语言，解释器/编译器同样在底层完成了大量的苦活累活，让人类可以更专注于表达意图而非操作细节。

这一演进有一个共同点：不论是编译执行还是解释执行，C、C++、Python 等中高级语言的源代码是可以被检视、验证、分析和评价的。代码可以被阅读（readable），可以被编译器或静态分析工具检查（verifiable），可以被版本控制系统追踪变更（traceable），也可以被人评判好坏——这就是我们常说的 code smelling（代码味道）。好的代码让人读起来舒服，坏代码则”闻”起来不对。

AI 时代的”新编程”

到了 AI 时代，人类写给 AI 的东西——需求描述、设计规范、上下文信息、约束条件——构成了一种更高抽象层面的”编程”。

这种”编程”的输入包括但不限于：

  • 需求和目标描述：告诉 AI 要完成什么，而不是怎么做
  • 工作规范和概要设计：界定范围、架构约束、接口约定
  • 参考资料和上下文：提供已有代码、文档、API 说明，让 AI 理解当前工程环境
  • 工具脚本和自动化流程：定义编译、测试、部署等环节的规则
  • 检查验证标准和工具：规定什么算”做对了”，如何自动化验证
  • 其他”驾驭工程”所需的组件：编码规范、命名约定、错误处理策略等

本质上，人类从”写实现”转向了”写规格”。传统编程是人与编译器的对话，新形态的编程是人与 AI 的对话——但对话的载体依然是文本、规范、约束条件，这些构成了新的”源代码”。

“源代码”应该被检视、验证、分析和评价

既然这种 AI 时代的”编程输入”扮演着与传统源代码类似的角色，它就应当遵循类似的工程原则：可检视（inspectable）、可验证（verifiable）、可分析（analyzable）、可评价（evaluable）。

可检视：需求文档、设计规范、prompt 模板等应当像代码一样纳入版本管理，而非散落在聊天记录或临时文档里。团队成员应该能够看到”我们给 AI 下达了什么指令”，以便审查和理解系统的行为来源。

可验证：我们如何确认 AI 产出的代码确实符合输入中的约束？这需要可自动执行的验证机制——单元测试、集成测试、静态检查规则等。传统编程中，”源代码的正确性”需要测试来保证；AI 辅助编程中，这个需求只会更强。

可分析：当系统出现问题时，除了排查运行时代码，还需要回溯到”我们当初是怎么描述需求的”。如果需求描述有歧义、约束条件缺失或上下文信息过期，那就需要追溯和修正——这本质上就是 debug。

可评价：传统代码有 code smelling 之说——一段代码写得是否清晰、是否易维护、是否存在设计缺陷，有经验的工程师读一遍就能形成判断。同样的道理，我们写给 AI 的 prompt、需求文档、设计规范，也应该经得起同行审视：描述是否准确？约束是否完备？上下文是否恰当？这种评价能力，是团队集体工程经验的体现，也是新型”编程”质量持续提升的基础。

目前，AI 辅助开发的实践已经有很多探索（如 prompt engineering、RAG、agent workflow 等），但把这些”写给 AI 的东西”当成一等公民来管理——像管理源代码一样管理它们——还远未成为共识。这恰恰是工程化 AI 辅助开发落地的关键一步。

结语

编程抽象层级的每一次跃升，都伴随着新工具、新方法论和新工程实践的出现。编译器让我们从机器码中解放，高级语言让我们专注于逻辑而非内存管理，而 AI 时代的”新编程”要求我们重新思考”源代码”的边界：它不仅包括传统意义上的 .cpp 或 .py 文件，也包括我们发给 AI 的每一个需求描述、每一条设计规范、每一份上下文材料。

把这些也当作源代码来对待——纳入版本管理、建立验证机制、支持追溯分析、接受同行评价——是通往可靠、可维护的 AI 辅助软件工程的必经之路。