在智能体系统逐渐走向复杂化之后，许多团队都会意识到一个问题：系统行为发生变化，却很难追溯原因。模型版本没有变，核心代码没有改，工具接口依然正常，但输出结果却悄然偏移。最终排查下来，往往是某一段 Prompt 被“顺手优化”过。
这类问题的出现，标志着一个事实：Prompt 已经不再是附属配置，而是一种实质性的“行为代码”。它会引入逻辑分支、隐含假设和系统性风险，却长期游离在工程治理体系之外。
在这样的背景下，“像 Review 代码一样 Review Prompt”，不再是一种理想化的工程洁癖，而是一种被现实反复教育之后形成的必要流程。
一、从“文本配置”到“行为定义”的转变
在智能体系统的早期阶段，Prompt往往被当作一种高层描述，用于引导模型理解角色、目标和风格。这种使用方式下，Prompt 的变更风险相对有限，因为系统的核心行为仍由确定性代码主导。
但当智能体开始承担更复杂的任务，例如多工具协同、长链路规划、角色分工和自我反思时，Prompt 的性质发生了根本变化。它不再只是“告诉模型怎么说话”，而是在事实上定义了系统的决策边界、错误处理方式和优先级定义。
在这种状态下，Prompt的任何细微改动，都可能改变智能体在关键节点上的判断逻辑。大多数团队仍然沿用“改了就上线，看看效果”的方式对待它。这并不是因为工程师不严谨，而是因为 Prompt 长期缺乏一种被普遍认可的工程化视角。
二、Prompt Diff：并非形式上的对齐，而是语义上的审计
当团队尝试将Prompt纳入评审流程时，最初往往会遇到一种错觉：既然Prompt也是文本，那用Git Diff看差异不就行了？你很快会发现，这种方式只能解决“有没有改”，却无法回答“改动意味着什么”。
Prompt的问题在于
