问题引入
Prompt 到底是不是程序？
这个问题表面上看起来是哲学性的，其实本质上是一个工程判断。
在我看来，Prompt 目前只是「近似程序」，具备了程序的一些特征，比如输入输出、可组合性、执行效果等，但距离真正意义上的「工程级程序」还有一段路。
换句话说，现在的 Prompt 可以跑，但跑不稳、难以复用、无法调试，更无法支撑大规模系统构建。如果这些基础能力无法建立，Karpathy 所说的 Software 3.0 就只是一个被无限消费的愿景，而不是可落地的范式。
结构与工程生态设想
在我设想的结构生态中，「Prompt 即结构单元」，意味着它必须像函数一样可封装、像模块一样可调用、像协议一样可组合。
如果没有工程基础支撑这一点，Prompt 终将沦为「偶尔有效的魔法语句」——看似灵活，实则脆弱。
Prompt 面临的关键问题
-
1. 输出不稳定
Prompt 是概率性的文本指令，哪怕 temperature 设为 0，模型依然会因 采样策略、上下文微扰 甚至 硬件差异 产生不同输出。
这种不可复现性让回归测试、持续集成等传统软件工程方法难以成立，开发者在面对“模型抽风”时毫无定位依据。 -
2. 缺乏语法与类型系统
Prompt 使用自然语言表达逻辑，天然存在歧义，缺少明确的语义边界。一句话在不同上下文中可能被模型解读为完全不同的指令，这使得调试变得异常痛苦。
当一个 Prompt 包含多个任务、条件判断或输出格式要求时，其调试成本远远高于写一个等价的 Python 函数。 -
3. 安全问题
Prompt 的拼接机制意味着用户输入很容易侵入系统指令上下文，造成 Prompt Injection 或 Jailbreak。
这种攻击手段就像 SQL 注入 重现于 AI 世界，而当前主流框架大多没有提供 参数绑定、信任域分隔 等机制，只能靠开发者手动构建沙箱与防火墙，增加了巨大工程负担。 -
4. 缺乏标准化评估机制
Prompt 的好坏目前无法通过统一指标衡量，多依赖人工观察和主观判断。这种情况严重制约了 Prompt 的版本管理、自动优化和团队协作，使得整个开发过程无法形成工程闭环。
-
5. 可解释性问题
Prompt 的“执行路径”深藏于数十亿参数的黑箱之中，开发者几乎无法追踪某个词或某段文字如何影响最终输出。
我们无法像调试代码那样逐步追踪行为路径，只能靠试错和猜测。这种缺乏因果性的开发体验，注定无法承担高风险或高稳定性要求的系统任务。
工程瓶颈总结
Prompt as Program 目前面临五大关键瓶颈：输出不稳定、缺乏语义约束、难以评估、安全脆弱、解释困难。
如果这些基础能力无法建立，Prompt 就永远无法承担「系统编程」的职责，只能是小工具层级的技巧堆叠。
展望与个人方向
尽管如此，我还是要押宝，提前用工程标准设计我的语言协议与结构生态。
我看好的方向，是将 Prompt 转化为一种结构化语言，通过 Prompt 编译优化 与形式化表达能力，建立起一套真正可组合、可调度、可运行的结构语言系统。这叫为自己的认知买单。
目前关注 Prompt 编译优化 DSPy、SAMMO 和 Prompt 形式化语言。