大模型是新时代的编译器
- 自然语言 Natural Language → 编译到 compiles to → 编程语言 Programming Language → 编译到 compiles to → 二进制码 Binary Code
- 大模型正在实现思想空间 (Idea Space) 到数码空间 (Digital Space) 的“自动映射”。
对个人能力要求的转变
随着 AI 的工程能力越来越强，人的工作会更多地处于 Idea Space，怎么想、想得怎么样、怎么表达会比技术能力更加重要。一个应用，就是从 Idea Space 中的一个结构到 Digital Space 的投影，而这个投影的过程正在被大模型所自动化。假设这个投影过程是可预测、可复现的，那么在思维空间中的操作本身就是唯一的生产过程。清晰、严谨、细致的产品需求文档成为了真正的“项目源代码”（Source Code），而程序代码更像是 AI 编译器自动生成的“中间代码”（Intermediate Representation）。
创业中的反思：开源项目与“反编译”的陷阱
创业过程中犯了一个错误，即到处寻找和研究开源项目代码，以期作为产品代码的基石，借助 AI 进行修改实现自己想要的特性。我想这些项目经历了上千次的提交，数年的开发和维护，如果能直接利用自然再好不过。
然而从我上述的观点看，将他人的代码库直接作为项目基础却是得不偿失的。因为随着大模型的快速发展，我们应该假定从想法到代码的编译过程是越来越自动化的。然而要深度利用别人的代码库，我要做的额外工作是从代码到思想的“反编译”，换句话说就是在高层面上理解他们的代码。长时间积累出的工作成果并不必然是对我有价值的，相反对我可能是“技术债”。在代码清洁程度上来说，很难比得过从清晰的产品需求文档和项目计划书从零开始生成出来的代码。
交互设计：人机交流范式的重要性与中间抽象层
话说回来，大模型对自然语言的编译目前当然不是全自动的。人与 AI 的“交流范式”的设计在目前重要性不亚于产品设计本身。必须要 Specific，泛泛而谈最多只能做出平均水平的成果。大模型本身既然由整个互联网上的数据训练而来，必然是很一般化的，缺乏针对我们特定需求的特异性。我们需要一个中间的抽象层，也就是基于自己项目背景的“领域特定语言“（Domain Specific Language DSL）。Paul Graham 说过，高级软件工程师会在开发过程中实现自己的 DSL。今天所谓的上下文工程 (context engineering) 包括提示词工程 (prompt) 实际上都是在设计 DSL。比如说，现在我要Cursor跟我以类似团队会议的形式交互，互相提出开放的问题，将有价值的认识记入会议笔记，延迟做出最终的具体决定，而不是一上来就基于不清晰、不确定的要求开始写代码。
未来展望：从 DSL 到“协议的协议”
- 可预测的映射 (结构化提示词)：但是如果要真正实现自然语言编程，我想从自然语言到编程语言的映射也应该具有可预测性与可重复性。如何实现？可以定义从自然语言到编程语言的“函数”，然后作为“工具”给 AI Agent 调用。大体来说，就是用户与大模型进行了多轮互动之后，得到一个相对满意的结果，于是用户希望能够定义一个结构性的函数或模板，在将来能够一句话调用，而不是重复相同的迭代过程。
- 项目专属的临时协议：这个结构化的自然语言-编程语言 DSL，我想这个在上下文工程 (Context Engineering) 中会是很有用的。它比自然语言的语法更加清晰、准确，但比编程语言更加灵活、概括。它不会是一个通用的框架，而是基于项目而专门构建的“临时协议”。
- 元协议 (Meta-Protocol)：AI 本身又会被用于帮助用户构建此协议。所以会有一个“协议的协议”，比如一套问答机制，来逐步构建出在本项目中人类开发者与智能体的交互范式。希望这个元协议本身的语言能足够通用，可以直接编码在 Cursor 之类的 AI 编辑器中。类比现在，元协议就是 ”User Rules”，项目协议就是 “Project Rules”。
终极愿景：思维即工作
未来最理想的发展前景是，DSL 层已经发展成熟，如同今日的 LLVM，任何人都可以纯粹在思维空间和自然语言空间中进行工作，结果就能自动映射为状态良好的软件。然而人们依旧需要学习如何思考、如何表达，这项技能就是具有永恒价值的“写作”。