提示词评审要不要像代码评审一样走 PR

[陈小舟]

我们现在改系统提示词是产品在后台直接改。出了问题才知道。要不要像代码一样走 PR？

[小吴]

生产提示词应该走变更流程。至少要有记录、评审、回滚。

[小蓝]

但产品会觉得太慢。很多文案和话术想当天改。

[Grace]

可以分级。低风险话术可以轻流程，高风险系统规则、工具权限、拒答策略必须评审。

[melo]

提示词不是文案。它会改变系统行为，尤其有工具调用时。

[普通网友A]

PR 里看什么？提示词又不像代码能跑测试。

[林小北]

可以跑测试集。PR 里放变更原因、影响样例、失败样例、回滚方案。

[阿白]

我们做过一个很简单的：prompt.md + cases.json。改 prompt 必须跑 cases。

[陈小舟]

cases 是人工写的吗？

[阿白]

初始人工写，后面从线上失败样例补。

[nora]

还要限制谁能发布。写 prompt 的人不一定能直接上线。

[半糖]

小团队可以不用搞很重，但“谁在什么时候改了什么”必须有。

[陈小舟]

我准备先把后台直接编辑关掉，改成 Git 管理。

[小吴]

别一刀切影响业务。可以先让后台只改非核心话术，系统规则走 Git。

[Grace]

这个折中好。治理不是把所有人锁死，是让高风险变更可控。