你是如何让非工程师团队成员在生产环境中编辑提示词的?
摘要
作者讨论了在受监管领域中允许领域专家对AI代理的生产提示进行编辑所面临的挑战,并分享了一种使用带有GitHub后端的提示编辑器进行版本控制的解决方案。
我为法律和临床工作流程构建垂直代理。同一个协调问题一直困扰着我:领域专家(律师、临床医生)是唯一真正知道提示词应该写什么的人,但我是唯一可以发布代码的人。我尝试过的方法:1. 将提示词迁移到托管平台(Langfuse / PromptLayer / 自制管理面板)。效果还行,直到你意识到提示词现在与调用它的代码解耦了,而且他们的编辑和你的部署在赛跑。2. 让他们在Google Docs中编辑提示词,然后我把他们的编辑复制到代码库中。可行,但在协调和版本控制上仍然混乱。3. 给他们一个GitHub账户,但他们用不好git。很好奇其他人采用了什么方案,尤其是那些在受监管领域发布代理的人,在那里领域专家必须签署每个提示词变更。我最后构建了一个库,它在应用内挂载了一个提示编辑器,并使用GitHub作为后端,这样提示词可以保留在git上,领域专家可以提出PR而不需要知道PR是什么。如果能帮到大家我很乐意分享链接,但主要还是想听听大家的有效做法。
相似文章
如何阻止编码代理接触生产数据?
讨论防止AI编码代理意外修改生产数据库的策略,主张使用只读访问、沙盒环境和审批关口,而不是仅仅依赖提示。
@ghumare64: https://x.com/ghumare64/status/2052825541057626258
一个X帖子认为生产级AI代理需要运维支撑框架(运维手册、权限、日志、回滚、验证),而不仅仅是更好的提示词。作者引用了DevOps演进历程,指出提示词提供建议而运维手册提供控制,代理系统需要平台工程解决方案来实现权限、状态管理、验证、可观测性和回滚能力。
提示词基础
OpenAI Academy 关于提示词基础的指南,教导用户如何编写清晰、有效的提示词,通过诸如明确具体、添加背景、指定输出格式以及分解复杂任务等技巧,从 ChatGPT 获得更好的回复。
提示工程能减少AI的谄媚行为吗?还是说这主要是模型行为问题?
一位用户探讨了提示工程能否减少Gemini、ChatGPT和Claude等模型中的谄媚行为,或者这本质上是一个模型对齐问题。讨论涉及不同模型在处理分歧和客观批评时的差异。
你们在生产环境中如何处理代理的不可逆操作?我放弃了提示词,构建了一个外部风险门控。
作者描述了一个为生产环境AI代理构建的外部动作前风险门控,用于防止发送错误消息或删除数据等不可逆操作,并分享了一个真实案例,其中该门控阻止了一次不合规的短信活动。