去年我在带一个智能客服大模型改造项目时一开始完全是用管传统软件项目的老办法拆需求、定接口、分模块、两周一个迭代。结果第一个Sprint还没结束团队里的提示工程师就来找我“交流”了——他说我给的验收标准根本没法验收我说“你按规定的输出格式返回不就完了吗”他半天没说话最后憋出一句“就算格式全对内容也可能是错的。”那一刻我才真正意识到用管理普通软件项目的思路去管理提示工程是走不通的。这篇内容不是讲怎么写提示词而是讲一个更现实的问题当你的团队在以大模型为底座、以提示词为主要产物的轨道上跑敏捷开发时Scrum这套老工具到底该怎么用。适合正在带AI应用团队、做技术中台、或者准备往大模型应用方向转型的架构师和技术管理者。我会结合自己做客服问答类产品落地的经历把Sprint怎么设计、用户故事怎么拆、Definition of Done怎么定、架构师要交付出什么一条条讲清楚。1. 管理提示项目和管普通软件项目根本不是一回事先说结论提示工程项目的管理难点不在于“技术复杂度”有多高而在于它跟传统软件工程几乎共享了同一套名词却在本质逻辑上完全相反你不把这层底下的东西想明白后面所有流程设计都会悬浮在表面。1.1 产线不可见聊天框背后没有“编译报错”传统软件开发里代码写错了会有编译错误、单元测试失败、接口返回非预期状态码这些信号是自动的、即时的开发人员写完代码敲一下回车就能得到反馈。但提示工程项目不是这样你给模型写了一段系统提示词它不会告诉你“你这里语法不对”更不会告诉你“这个指令和那个指令逻辑冲突”它只会用一种非常流畅、非常自然的方式输出一个语义上可能完全跑偏的答案。这就相当于你带了个新员工他不懂的地方不会举手问你而是全程微笑着胡说八道你必须事后逐条翻他的工作记录才能发现问题。模型输出的概率性和不可捉摸性决定了提示工程项目的“质量检查点”无法放在构建期只能放在评估期。管理上如果还按“写代码—测代码—上线”的串行节奏推进那提示工程师的产出永远是一堆没有经过验证的字符串。1.2 需求会在对话里自己生长出来传统产品的需求再怎么变总归有边界。一个登录页就是登录页一个下单流程就是那几个步骤产品经理哪怕再发散功能路径也是可枚举的。但提示工程项目的需求边界是用户对话逼着长出来的你的机器人上线后用户会问出你想不到的问题会用完全不像需求文档里写的措辞来描述同一个业务场景甚至会把你的机器人当成真人来倾诉情绪。这些真实对话涌入之后产品经理会发现一个很尴尬的事实Sprint开始时定义好的“问答覆盖范围”只是一个当初的猜测。用户根本不管你规划了哪些场景他只会按自己的认知去提问。需求在这个意义上不是被定义的而是被“发现”的。管理上如果坚持传统项目里的范围锁定策略团队就会陷入永无休止的范围变更评审而实际发现评审讨论的速度远赶不上用户提出新问题的速度。1.3 评估靠人肉眼这个瓶颈绕不开传统软件项目里的“完成”标准是很硬的功能能不能跑通、接口返回对不对、并发能不能扛住每个都有客观指标。提示工程项目的核心产物是“回答质量”而质量是一个非常主观的概念。同一个答案业务专家觉得不够细致普通用户觉得太啰嗦客服主管可能觉得缺少安抚语气。目前最主流的评估方式还是人肉看结果拿一批测试问题跑一遍然后逐条打分、写评论、分类失败原因。现在虽然有“用大模型评大模型”的自动化方案但自动化评估本身就是一种带有偏差的手段不能完全替代人工判断。这意味着评估环节永远需要人力投入而且评估结果还会因为评估者的背景不同而打架。管理视角上这不是一个能通过“多招几个人”或“上个系统”就解决的问题而是要把人工评估当成一种稀缺资源来设计流程跟传统项目里管理测试工时是一个道理但粒度要细得多。1.4 每三个月技术栈就重新洗牌一次提示工程领域有个非常折腾人的特点基础模型一更新整个实践体系就可能被推翻。今天团队还在花大精力研究怎么靠提示词做结构化输出明天新模型原生支持JSON模式之前的复杂prompt技巧全成了历史遗留今天还在通过函数调用扩展能力明天工具调用成了模型标配今天用的模型上下文窗口是8K明天有人部署了一个128K窗口的模型很多靠“压缩上下文”换来的技巧立刻失去意义。这种快速变化给架构师带来的挑战是团队学东西的成本会快速贬值如果员工花三个月积累了一套特定模型下的提示词调优经验结果模型一升级这套经验可能一文不值。正因如此架构师在这个领域里的价值不是帮团队“学最新”而是帮团队区分哪些是会变的、哪些是底层的、值得长期投入的东西。项目类型传统软件项目提示工程项目错误反馈编译报错、接口报错、测试失败输出很流畅但内容不对要靠事后判断需求来源产品经理定义、流程驱动用户对话驱动需求边界模糊验收标准功能正确、性能达标回答质量主观评估依赖人工技术周期框架迭代相对平缓基础模型迭代会推翻已有实践核心产物代码、接口、数据库表结构提示词、上下文配置、评测集2. 把Scrum翻译给提示项目Sprint、Story、DoD怎么改Scrum的框架本身是抽象出来的理论上套到任何领域都能用但“能用”和“好用”之间差着一个翻译的过程。下面是我在实际项目中认为最有效的几个改动。2.1 Sprint周期从两周压到一周的取舍传统软件团队用两周一个Sprint是合理的因为一个功能从编码、联调、自测到提测周期太短了根本完不成。但提示工程项目的时间结构完全不同提示词的修改周期非常短上午改完一段指令下午就能跑一轮评估样例看大致效果真正耗时间的其实是在观察线上用户反馈和收集新失败案例这块的周期取决于流量和数据回流速度而不是开发速度。所以我把Sprint周期压到了一周周一定目标、周二到周四集中优化和评估、周五做评审和复盘。这样设计有两个好处一是强制团队接受“规划精度有限”的现实一周的计划哪怕全废了损失也可控二是每个Sprint都有机会吸纳上一周从线上收集到的新对话样本让迭代方向保持贴近真实用户。如果团队刚开始做提示工程节奏还不稳可以先按两周跑两三个Sprint但尽量往一周靠。2.2 用户故事不按功能拆按“能力场景”拆最开始我们习惯按传统方式拆用户故事——退换货一个、物流查询一个、订单修改一个拆完之后发现每个故事对应的就是一段提示词团队做着做着就变成了“改写文案”Sprint Review时拿不出任何有说服力的东西。后来我换了个拆法按“能力场景”拆一个故事描述一类用户和AI之间的完整交互能力而不是一个功能点。举几个当时客服项目里的故事示例“用户询问退换货政策时机器人给出清晰、合规、带售后链接的回答并主动确认用户是否理解。”“用户因为在App上反复操作失败而情绪激动时机器人能识别情绪先共情安抚再引导转人工。”“用户询问超出知识库范围的业务问题时机器人明确表示不知道并给出替代渠道而不是编造答案。”这样做的好处一眼就能看出来验收能跟业务指标挂钩比如“退换货场景一次解决率”而不再是把提示词交给产品看了一眼说“挺好”同时一个能力场景往往需要系统提示词、few-shot样例、知识库检索、工具调用多个模块配合完成正好是对全链路的端到端验证。2.3 提示项目的Definition of Done长什么样传统Scrum里的DoD一般是“代码合并、单测通过、Code Review完成、QA验收”这套标准搬到提示项目里基本没用。我团队后来执行的DoD包含五条每条都有可检查的证据已通过回归集评估核心指标达到目标线比如客服场景回答准确率不低于92%。新增场景的失败案例已逐条分析失败原因记录在文档里不能一句“模型不行”糊弄过去。提示词文件、上下文协议、模型版本三者已在版本库中完成对应记录。线上灰度方案已确认包括灰度比例、观察指标和回滚条件。没有引入明显偏离预期的新增风险比如回答态度突然变冷淡、幻觉率上升等。有同行问过“提示词评审算不算DoD的一环”我的答案是要但评审重点不是文字通顺不通顺而是有没有评估数据支撑。给一段新提示词做评审时团队需要回答的应该是“你跑了哪些测试集、相比上一版指标变化了多少”而不是“这句话读起来挺专业的”。2.4 故事点估算估的是不确定性和评估难度提示工程项目的估算特别容易失真原因是团队对“改一个提示词”的工作量判断太乐观了。后来我发现与其估“工时”不如估“不确定性和评估难度”如果这个场景能用一条简单的规则基座加一个固定回答模板覆盖点数就低如果涉及多轮对话、知识边界判断、情绪识别、多工具协作点数就高。估算的作用不是用来排工期而是逼着团队在Sprint Planning阶段就把最棘手的场景暴露出来。一个看起来很短的需求如果点数很高说明大家其实并不知道该怎么验证它这时候就应该把评估方案设计一并列入本Sprint的工作范围。3. 架构师在提示项目里的三个关键交付物缺一个后面都会失控在提示工程团队里架构师很容易被误解成“那个把所有技术细节都搞清楚的人”但我做了半年之后最大的体会是架构师的价值不在技术深度而在能不能搭出三个让团队长期运转不混乱的系统缺了任何一个项目后期都会失控。3.1 上下文协议让提示词不再是“散装字符串”我看过很多AI应用团队的代码最让人头大的一点就是提示词散放在项目各处——业务代码里拼接一段配置中心里塞一段数据库里写着一段模板文件里又有一份。结果就是想改一个标点符号都不知道改完会影响哪些地方。架构师第一个要治理的就是这层我称之为上下文协议本质上是把“模型收到的输入长什么样、模型输出的格式是什么”固定下来。一个相对规范的上下文协议至少包含四块系统提示角色、任务、风格、边界、用户输入原始问题、用户画像、会话历史摘要、工具输出检索结果、API返回、数据库查询结果、输出约束格式要求、字段定义、兜底逻辑。下面是一个简化的配置示例{ context_protocol: { system_prompt: { role: 智能客服助手, task: 解答用户关于退换货、物流、订单的问题, style: 简洁、友好、专业, boundaries: 不确定的信息必须说明禁止编造政策 }, user_input: { raw_query: 用户原始问题, user_info: 会员等级、历史订单数, history_summary: 最近两轮对话摘要 }, tool_output: [ {tool_name: knowledge_base_retrieval, result: 检索到的政策片段}, {tool_name: order_api, result: 订单状态数据} ], output_constraints: { response_format: 分段落回答关键信息加粗, required_fields: [direct_answer, actions, fallback_message] } } }这套协议的最大价值不是代码层面“整洁”而是让团队随时能回答三个问题当前模型到底收到了什么、输出是什么、和预期差了多少。出现线上问题时先按协议排查上下文再谈模型和提示词的问题这个排序能省下大量扯皮时间。3.2 评测基线与回归集没有它们就没有DoD前面提过提示工程项目的DoD必须可验证而验证的底座就是评测基线和回归集。这块在我的项目里属于架构师直接负责的基础设施而不是测试人员的附属工作。具体做法是从历史真实对话中抽样500到1000条数据覆盖每个能力场景每条数据里标注的不是“标准答案”而是“期望行为标签”比如正确回答、拒绝回答、转人工、道歉并追问细节评估指标拆成两类一类是客观指标包括格式合规率、关键词命中率、工具调用正确率另一类是主观指标包括准确性、完整性、语气得体度按1到5分打分。这里有一个特别重要的原则回归集不是一潭死水每次Sprint结束后要把线上新发现的失败案例补充进去但同时必须走评审流程不能让某个成员在心情好的时候悄悄往里面加一条“自己希望模型输出……”的样本否则回归集很快就会被污染团队开始迁就测试集而不是服务真实用户。3.3 版本管理与回滚模型、提示词、知识库三位一体提示工程项目里线上问题排查最大的噩梦就是版本对不上。某天发现线上回答质量下降你很难第一时间分清是提示词被人改了、模型被平台方悄悄升级了还是知识库里的内容过期了。所以架构师必须推行三位一体的版本管理提示词全部纳入git每一次变更走commit和merge request禁止绕过流程直接改线上配置。模型版本要记录至少包含模型名称、版本号、部署时间和对应接口地址。知识库要打快照尤其是在RAG场景下向量数据库里的文档集合到底加没加过内容、删没删过旧的必须有据可查。每次线上发布时写一条发布记录把模型版本、提示词版本、知识库快照三者对应起来。我见过不少团队以为“模型接的是同一个API配置没变怎么会变”结果一查是模型服务商做了静默升级前后两次调用的行为完全不一样。所以在接入层留一个模型版本锁定开关非常有用在未经回归集验证之前禁止生产环境悄悄切换到新版本。这个开关像保险丝平时不起眼出了事能救整个团队一命。4. 一个完整Sprint的运转实录从规划到复盘每一步都有产出物理论说了一堆我拿当时客服项目里“提升退换货场景一次解决率”这个目标完整还原一个Sprint是怎么运转的你可以把它当成一个可复用的样板。4.1 Sprint Planning输入、输出和当场完成的样板Sprint Planning开始前团队必须准备好三类输入上一轮的评测报告哪些指标降了、哪些失败了、线上用户反馈里的失败案例用户原话转写和分类、产品侧本周的业务目标。没有这三样东西规划会议就会变成头脑风暴。我们的Sprint目标定得很具体“把退换货场景一次解决率从78%提升到85%”。这个目标对应的用户故事只有两个一个是“用户询问退换货政策时能获得清晰合规且带链接的回答”另一个是“用户对退换货结果不满意时机器人能安抚并升级处理”。两个故事底下都明确写了评估方案用哪部分回归集数据、跑多少条、人工评还是机评、通过线是多少。评估方案的工作量在规划阶段就被当作正式任务排进Sprint不允许“跑个测评估计很快”这种话糊弄过去。4.2 执行期怎么分工提示工程师、评测员、架构师各干什么执行期最忌讳的是所有人都围着一块“调prompt”的石磨转。我们当时的角色分工是这样的提示工程师负责写不同变体的提示词改进few-shot样例但改完只提交到测试环境不直接碰线上配置。评测员负责跑回归集给结果打标签把失败案例按原因分类比如上下文缺失、指令冲突、模型知识不足、格式错误。评测员不参与改提示词保证评估的客观性。架构师负责盯上下文协议有没有被破坏、提示词变更有没有同步版本库、有没有阻塞在评审层面的设计问题。产品负责人准备真实的用户对话样本参与失败案例定性在“这个回答业务上到底算不算对”这类问题上给结论。特别要强调一点不要让提示工程师同时担任自己的评测员。人改到第十版提示的时候已经不可能客观判断效果了他会下意识地为自己的设计找理由。评测分离是我在这个项目里坚持得最正确的一件事。4.3 Review别只看演示要看评测报告和失败案例Sprint Review最容易犯的错是走形式产品经理问了一堆Demo问题机器人回答得很流畅所有人点头通过。有一次我们就这样被坑了演示用的样本是团队自己造的句句都在点子上结果上线后用户问法稍微歪一点通过率惨不忍睹。后来的Review我改成只看两类东西一是评测报告指标对比表要列出上一个Sprint和这个Sprint的差异二是失败案例清单逐条过一遍问“这个失败是已知风险还是意外新问题”。演示可以看但样本必须来自真实日志不允许团队手工构造“完美问题”来糊弄。Review会议上还有四连问是固定动作指标为什么变、失败案例是什么、三个版本模型、提示词、知识库对得上吗、上线前有没有遗留风险。4.4 Retrospective的提问清单照着开能挖出真问题复盘会最怕的就是“这周总体挺顺利大家继续加油”这种毫无信息量的收尾。我后来整理了一份固定的提问清单每次轮流过一遍这周被卡时间最长的一个环节是什么卡在流程、工具还是人的认知上评估结果出来后我们发现哪个之前的假设是错的有没有哪个决策在做的当下明显信息不足当时为什么没有停下来这周的失败案例里有多少是“其实早就能从历史数据里预判到”的下周哪个环节可以比这周少花一半时间怎么做这份清单的价值是它逼着团队从“做了什么”转向“我们的工作方式本身有没有问题”。跑了两三个Sprint之后团队复盘的质量会有肉眼可见的提升因为大家习惯性地开始找结构性问题而不是单点抱怨。5. 落地半年后踩过的六类坑望周知计划赶不上变化这个项目跑了半年踩过的坑比预想的多。每个坑出现的时候团队都觉得“是不是只有我们遇到这种问题”后来交流了一圈发现同行们其实都在同一个水坑里打转。这里把六类经典问题连同排查思路写出来。5.1 模型升级后提示词“凭空失效”根因在哪现象是上周五线上还一切正常周一早上客服主管来反馈机器人回答风格大变说话爱用“首先、其次、最后”的排比句式咨询效率肉眼可见地下降。我第一时间查了服务日志里的模型版本号发现模型部署平台在周末做了静默升级接口地址没变但底层模型行为变了。前期设计的提示词都是针对旧版本模型的输出习惯拟合出来的换到新模型上部分指令的约束力大幅衰减。排查链路就是先锁版本再跑回归集确认同一个提示词在新旧版本上的指标差异最后再做针对性调整。这个坑告诉我们模型升级是线上事故的高发源头必须有版本记录和回归验证。5.2 评测集过拟合团队把答案背了下来Sprint内指标一直在涨大家都很兴奋结果每次上灰度就被用户反馈打脸真实效果远不如评测数据好看。后来做了一次深度排查发现评测集里有近两成的case被团队反复看过、讨论过、针对性地调整过提示词相当于老师划了考试范围学生把题目答案背下来了但题目稍微变个问法就露馅。解决方式是把评测集分成三份调试集跑实验时随便看快速迭代用回归集每周固定跑看趋势盲测集每轮从线上新收集但平时锁起来不给团队看只在最终评审时拿出来验收。这个“作弊—反作弊”机制后来成了团队的标准配置。5.3 产品经理直接改提示词版本线彻底乱了有一次线上出现大量答非所问的情况查了半天最后在操作日志里发现产品经理为了临时应付一个用户反馈直接改了线上知识库里的提示词配置。他本意是好的但改完之后没有任何记录后续所有排查都在错误的方向上白费力气。这个问题的本质不是“该不该让产品改”而是“改完必须留痕”。我们的对策很简单线上配置锁定要改可以提交一个变更说明走轻量级审批就能发布全程不阻塞业务。既保证了灵活性又保住了可追溯性。5.4 需求方看演示很满意上线就翻车这是一个非常普遍的现象内部演示时找十个精心设计的问题每个都对答如流老板说“不错”结果灰度一开放用户真实问法一进来各种没见过的说法涌现通过率直接下滑十几个点。根源在于演示样本和真实分布严重脱节。我们的对策是上线前用真实日志数据做一次“复演”直接拿最近一周的用户提问去考模型看它在真实噪声下的表现所有决策都以这轮复演结果为准演示效果只作为参考。自那以后内部评审就再也没出现过“演示满意上线翻车”的脱节。5.5 为追求自动化而自动化的陷阱为了降低人工评估成本团队搭建了一套“用大模型评大模型”的自动化评估管道刚开始觉得效率飞升后来发现机评分数和人工深度评审的结果经常不一致机评偏向格式完整、语气规整的回答忽略了实质内容的准确性。后来我查了不少实践总结发现“模型当裁判”这个方案在趋势监测层面是可以用的比如用来跑回归集、预警指标异常但最终验收必须保留人工抽检而且要定期校准机评结果和人工结果的相关性。自动化是工具不是目标盲目追求自动化只会得到一个“看起来很先进但实际失灵”的评估体系。5.6 上下文窗口变大后的懒惰工程新一代模型把上下文窗口从几千tokens推到十几万甚至更多之后团队里出现了一种危险倾向不再精心设计检索和路由逻辑而是把能塞的知识全部倒进上下文里觉得“反正模型能看见”。结果是回答质量没有明显提升调用成本翻了好几倍响应延迟也上来了。后来我重新在团队里立了一条规矩上下文是资源不是垃圾桶。无论窗口多大都必须保留问题分类、前置检索和上下文预算只有跟当前问题强相关的信息才允许进入模型。窗口变大是给你减少工程复杂度的不是让你偷懒的。最后再分享一点个人感受带提示工程团队最累的地方不是技术难而是所有人都容易在“模型很聪明”和“模型很蠢”之间反复横跳导致流程设计也跟着情绪摇摆。架构师真正要做的是给团队提供一套像保险丝一样的机制——评估、版本、上下文协议让每个人的工作都能被验证、被追溯。想清楚这一层Scrum这个老框架在提示项目里不但不过时反而比很多花哨的新方法论可靠得多。