“这个提示词昨天还能用，今天再跑一遍就行。”很多人对AI工具的使用，就停在这句话上。写代码、查资料、转数据、生成文档、排查问题，AI已经嵌进了日常流程。它最大的价值在于：把“我想做某件事”变成“机器能执行的任务”，中间那层实现成本被大幅压低了。
用自然语言描述目标，补上上下文和约束，让模型自己找路径，不行就改指令、补信息，直到得到一个稳定可用的提示词。对于只做一次的任务，这比专门设计一套软件要省事得多。哪怕任务复杂，边做边探索，也能把实现决策往后拖，等真正理解问题之后再定。
但同一件事要做第二遍、第三遍的时候，情况就变了。
重复执行，是一个被忽略的信号
最自然的反应是复用提示词。既然昨天跑通了，今天再跑一次；下周还要同样结果，那就再跑一次。时间一长，这个提示词就成了工作流的一部分，没人再去问：让AI模型来执行这个任务，还是不是最优解？
这里需要区分两件事：用AI去“发现”一个流程，和用AI去“执行”一个流程。
第一次执行提示词，本质是探索性的。你知道想要什么，但不确定怎么到达，AI帮你补上这段空白——理解意图、建议步骤、适应那些你事先没完全形式化的信息。第二次执行已经不太一样了，通常会根据第一次的结果改进提示词，把约束说清楚，把预期输出定义得更精确。再多跑几次，你可能会发现：同样的操作序列在反复出现。
到这一步，性质已经变了。你不再是在发现怎么解决问题，而是已经描述出了一个流程。
所以“可重复性”可以当作一个判断信号。并不存在一个魔法数字，说跑到第几次就该把提示词变成代码，但可以有一个简单的心理模型：
- 第一次，解决问题；
- 第二次，验证方法；
- 从第三次开始，至少该问一句——我们还在解决一个AI问题，还是已经发现了一个软件流程？
如果输入是已知的，预期输出是已知的，中间大部分步骤是可预测的，那再反复让模型去解释这些指令，可能已经没有必要了。
把AI从运行时挪到构建时
另一个有用的区分是：AI在运行时，还是AI在构建时。
设想一个提示词，让AI代理收集一批文件、检查结构、抽取信息、转成JSON、校验结果、再存到某个地方。在最初几轮迭代里，让代理跑完整个工作流非常方便，因为这时候我们还在发现正确的工作流到底是什么。
可一旦流程稳定下来，其中大部分操作可能根本不需要智能。读文件、校验schema、转换数据、调用API、写出文件，这些都是确定性操作，传统软件已经可靠地做了几十年。
与其继续让AI执行这个流程，不如让AI实现这个流程。经过多轮打磨的提示词，本身已经是一份相当不错的规格说明，写清了软件该做什么。用这份规格去生成脚本、命令行工具或一个小应用，验证实现，之后就让机器直接执行。
架构会从“输入→提示词→AI→解释→执行→输出”反复循环，变成：需求→提示词→AI→实现→验证，然后落到一个脚本上，之后就是输入到输出的直接映射。AI并没有从开发过程中消失，它可能在理解问题、创造方案上起了关键作用。变的是：智能的成本在什么时候支付。不是每次流程运行都付一遍，而是在设计和实现流程时付一次，之后尽量依赖确定性执行。
直接的好处是token消耗更低、基础设施成本可能更低。但成本不是最有意思的部分。确定性实现还更快、更容易测试、更容易观测，更重要的是更可预测。
确定性内核，智能边缘
当然，真实工作流很少完全确定。一个流程可能有十个步骤，其中九个完全可预测，只有一个需要理解语义、处理歧义，或者基于难以写成传统规则的信息做判断。
这时候讨论才真正有意思起来，因为选择不再是“用AI”或“不用AI”。可以开始想的是：智能应该放在流程的哪个位置。比如一个收集文档、校验结构、抽取元数据、套用一组已知业务规则的工作流，哪些环节交给确定性代码，哪些环节留给模型，是可以被设计出来的。
热门跟贴