怎么像有开发团队一样去提需求、去建设 Agent？

先说一个我常碰到的场景：业务部门想要一个自动查舱的 Agent，找到技术同事，口头说了几句需求。技术同事说「行，我回头弄一下」。两周后 Agent 出来了，业务一看：查的港口不对、要的字段没有。又回头改，再等两周。

问题不在技术，在需求没有「提」出来。

一、给 AI 提需求，和给开发提需求是一回事

很多公司有开发团队，业务方早就学会了怎么跟他们打交道：写需求单、讲清楚要什么、评审、测试、上线，改需求走变更流程。

这套纪律花了多少年才建立起来。但到了 AI Agent 这儿，大家突然全忘了——觉得「跟 AI 说句话就行了」，于是又回到口头交代、随手乱改的老路。

其实建设 Agent 和给开发提需求，本质是一件事：变更纪律一样，只是执行者从人变成了 Agent。

业务方要做的，是把那套已经跑熟的需求流程，原样搬到 Agent 上：

• 写清需求单：这个 Agent 是谁、干什么、按什么规矩、哪些事绝对不能干
• 有人评审：改动不是自己说了算，让懂行的人过一遍
• 留底：每次改动都有记录，谁改的、改了什么、为什么改
• 能回滚：改坏了能退回上一版，而不是原地抓瞎

二、为什么这套流程不能省

有人觉得烦：一个 Agent 而已，改个提示词还要走流程？

等 Agent 真的接进业务你就明白了。一个自动给客户回邮件的 Agent，如果哪天提示词被人随手改了一句「回复可以更热情一点」，它可能就开始乱承诺船期。没有留底，你连「是谁改的、改成什么样了」都查不到。

这不是吓唬人。我见过太多「改坏了不知道找谁」的现场：Agent 昨天还好好的，今天突然开始胡说，所有人面面相觑，只能先把它停了再说。

如果每次改动都走了「需求单 → 评审 → 留底」的流程，这个场景根本不会发生：翻一下记录就知道是哪次改动引入的问题，回滚到上一版，十分钟解决。

三、一个货代场景，把这套流程走一遍

假设你们公司要做个「询价 Agent」，业务方想让它自动查运价、生成报价单。

按给开发提需求的流程，需求单大概是这样的：

1. 要什么：收到客户询价后，自动从运价表查匹配的舱位和价格，生成报价单草稿
2. 边界：只查已签约的运价，不承诺最终价格；查不到就明确说「需人工确认」，不许编
3. 评审：操作主管过一遍，确认字段、口径和边界没问题
4. 验收：拿 10 个真实询价试跑，看查得准不准、格式对不对
5. 留底：这套配置和提示词存档，之后每次改动都记录
6. 回滚：如果上线后客户反馈价格算错了，先回滚到上一版，再查是哪个改动出的问题

走完这一遍，你得到的不只是一个 Agent，还有一份随时能查、能改、能回退的「工程档案」。

四、没有开发团队的小公司怎么办

「我们公司没有开发团队，那这套流程还适用吗？」

适用，而且更要适用。没有开发团队，意味着出了问题没人兜底，Agent 一旦跑偏就是业务自己扛。这时候留底和回滚不是负担，是保命。

小公司不需要搭什么复杂的系统，只需要一个朴素的习惯：Agent 的任何改动，都按「提需求 → 记录 → 可回退」走。哪怕就是在共享文件夹里存一份改动说明，也比「改完就忘」强一百倍。

五、适用边界

这套方法假设你的 Agent 要接进真实业务、会被人依赖。如果只是自己做个临时小工具、明天就不用那种，确实不必走全套流程——但也建议至少留个备份。

我还没完全解决的问题是：怎么让「提需求」这件事本身也不费劲，别让业务方觉得流程比干活还重。目前的做法是尽量模板化，但离「顺手」还有距离。

继续读：生产环境稳定运行的 Agent，怎么通过 PR 把历史版本维护好？；搭一个 AI 员工，不用写代码；先给 Agent 定岗，见给 AI 定岗：先写岗位说明书。