★ FEATURED ARTICLE 前段时间我在Coze平台上搭建一个病理研读Agent折腾了整整两个星期。最早跟大多数人一样上来就是写提示词角色设定、语气要求、回答模板写满好几大段试了几个样例感觉不错结果一换输入就露馅有的报告能正确解析有的报告直接开始“自由发挥”。后来我彻底换了一条路用Spec-driven的方式来重做——先把规格写清楚再动手配置平台。做完之后的感受非常明显Agent的每个决策都有了依据出问题能定位到具体环节团队其他人接手也完全不用靠猜。这篇文章就完整记录这次实践如何用Spec-driven模式在Coze上落地一个“专家级”病理研读Agent覆盖思路拆解、Spec文档怎么写、平台配置细节、评测方法和踩坑记录。适合正在用Coze或其他Agent平台做复杂应用、觉得提示词方案不够稳的人也适合那些刚接触Agent开发、想建立一套规范方法论的朋友。1. 为什么我放弃“提示词堆砌”改用Spec-driven开发Agent1.1 提示词野路子的三个死穴先说一个大家心照不宣的现状现在开发Agent大部分人的第一步都是在System Prompt里疯狂堆描述。“你是一个病理学专家”“请以专业、严谨、通俗易懂的方式回答”“必须注意……”“不能出现……”——这些话说得越多模型反而越不知道哪个是重点。我在第一版里写了近两千字的提示词结果测试下来出现了三个非常典型的问题。第一行为不可预期。同样一份报告换个说法提问输出结构完全不一样上一版明明已经修正过的错误改了一个无关的措辞之后又复现了。第二无法定位问题。输出烂的时候你根本说不清是哪句话、哪个环节、哪段知识引发的错误因为整个判断逻辑全部黑盒地塞在提示词里。第三迭代成本极高。我今天告诉它“遇到原位癌要特别说明”明天告诉它“别把肿瘤分级和分期混在一起”提示词越来越长互相矛盾的地方也就越来越多。这个体感我相信很多搭过Agent的人都有不是不想做好而是传统方式压根不具备工程化管理的可能。真正让我决定转变思路的是处理一个“乳腺导管原位癌”报告样例时模型用“癌”字关联了全套浸润性癌的解释给用户造成了严重误导。那一刻我意识到在医疗相关场景里这种不可控是不可接受的。1.2 Spec-driven到底是什么先定规格再谈实现Spec-driven的中文叫法有很多规格驱动、契约优先、先定义后实现。核心思想一句话写代码之前先用文档把“系统应该有什么行为、什么输入、什么输出、什么边界”完整确定下来然后再进入实现环节。它不是测试驱动开发那种“先写测试再写实现”的下游手段而是更上游的一层约束。用盖房子类比最清楚。传统提示词开发像是请了个施工队口头说一句“给我盖个好看的三层小楼”工人自由发挥有的窗户朝南有的窗户朝北。Spec-driven则是先花时间画完整套施工图哪里是承重墙、哪里走水电、层高多少、采光要求多少全部白纸黑字定下来。施工队只需要照着图纸干最后验收拿图纸对一遍就知道合不合格。这套方法论迁移到Agent开发上有两层含义。一层是面向文档的Agent的角色定位、输入契约、处理流程、输出格式、知识边界、风险兜底、验收标准全部预先写成一份规格说明书。另一层是面向实现的系统提示词、工作流节点、知识库配置、评测集全部以这份规格说明书为唯一依据去落地。我在Coze里做完后的体会是Spec文档写得好系统提示词只是它的一个投影Spec文档写得差提示词写得再漂亮都是无根之木。1.3 为什么病理研读这个场景最适合Spec-driven坦白说不是所有Agent都需要上Spec-driven做个写文案、做翻译的助手自由发挥一点反而有惊喜。但病理研读这个场景几乎是Spec-driven的完美适配对象。病理报告是高结构化的医学文档它包含送检材料、大体所见、镜下所见、病理诊断、免疫组化、分子检测等固定字段。研读的本质动作是从这些字段里抽取关键信息、映射到通俗表达、按风险等级给出下一步引导。这种强流程、强边界、强风险约束的场景如果是完全让模型自由发挥隐患非常大。另一个原因是病理领域的容错率极低。一个术语解释错误、一个“可能转移”的过度推断、一个风险等级的误判都可能对用户产生实质性影响。这就要求Agent的行为可以被审计、被测试、被约束。Spec-driven天然满足这个需求每一类输出都能在规格书里找到对应条款每个错误都能追溯到规格设计的缺失或实现与规格的偏差。还有一个很实际的原因医疗相关Agent的发布和用户信任门槛都高。拿着提示词去对接病患或者医疗团队对方第一句话一定是“你的判断依据是什么”。如果你的回答是“模型觉得”这项目基本就黄了。而Spec-driven模式下你能拿出完整的逻辑链条和处理规则沟通效率和信任度完全是两个量级。2. Spec文档编写如何把“专家级”翻译成可执行的规格2.1 一份Agent规格书必须包含的七个板块我在动手配置Coze之前先花了两天时间写了整份规格文档。这份文档后来成了所有开发、测试、迭代的唯一依据。我把一份可复用的Agent规格书拆成七个板块每个板块解决一个维度的问题。第一个板块是角色与使命回答“这个Agent是谁”。病理研读Agent的角色定位是“病理报告辅助研读助手”使命是帮助非专业人士理解报告中的关键信息、解释专业术语、提示下一步就医路径。这里有一个很严谨的自我认知它不是诊断系统不是医生的替代品。第二个板块是输入契约回答“它接受什么”。我定义的输入包括完整的病理报告文本、报告片段、用户针对报告的提问经过平台的文件解析能力还可以接收报告图片。不接受影像原图、不接受无上下文的闲聊式提问——至少主体功能不做这层支持。第三个板块是处理流程回答“它怎么干活”。这个Agent的标准处理链路是六步走文本清洗、关键信息抽取、术语映射、结构化解读、风险分级、生成回答。每一步由谁实现是提示词约束、工作流节点还是知识库检索在这个板块里都要明确分工。第四个板块是输出契约回答“它怎么说人话”。输出必须包含一句话结论、关键术语逐项解释、下一步建议、免责声明四个部分。结论不超过三句话术语解释每条控制在两句到三句。整体语气通俗、严谨、克制禁止夸大、禁止渲染焦虑。第五个板块是知识边界回答“它不能碰什么”。不进行最终诊断、不推荐具体治疗方案、不评价主治医生的建议、不解释超出知识库范围的罕见病。如果报告中有无法识别的术语必须承认知识库覆盖不足而不是硬编一个解释。第六个板块是风险兜底回答“出问题怎么办”。检测到报告信息不完整、关键字段缺失、术语无法映射等情况必须主动声明“当前信息不足”并建议用户携带完整资料咨询主治医生。任何情况下都不许替用户做“严不严重”的主观判断。第七个板块是验收标准回答“怎样算做完了”。我把验收指标具体量化了核心信息抽取准确率不低于95%术语解释准确率不低于90%风险场景触发率100%幻觉断言数必须为0。这些数字不是拍脑袋而是根据20条评测用例跑分得出的合理目标。2.2 病理研读场景的特殊规格设计通用板块之外这个场景有三处属于它自己的特殊设计我觉得是整个项目里最值得写下来的部分。第一处是“四档风险分级机制”。我在规格书里定义了四个响应等级第一档对应良性病变或炎症常规解读即可第二档对应低度恶性潜能或原位癌在解释之外要明确建议专科就诊第三档对应浸润性恶性肿瘤完整解析的同时必须用醒目方式提示用户尽快就诊第四档对应罕见、复杂或报告不明确的情况一律建议携带完整材料线下咨询。这个分级不是让模型凭感觉判断而是通过原文中的关键字段和关键词来触发避免所有报告都得到同一个模板化的答案。第二处是“术语映射表的建立”。病理报告中的核心术语如“浸润性导管癌”“原位癌”“高级别上皮内瘤变”“Ki-67增殖指数”“HER2状态”等我要求Agent先执行严格的术语映射再生成通俗解释。比如“HER2(3)”映射到通俗表达时要说清楚这是“HER2蛋白强阳性可能需要考虑抗HER2靶向治疗”但不展开、不越界。为了让映射稳定我在知识库里专门维护了一份术语对照词典。第三处是“信息脱敏与风险标注”。规格书要求Agent在解析报告时自动跳过患者姓名、住院号等个人身份信息同时规定凡是在回答中出现参考知识库之外的推断必须标注为“基于公开医学资料的通用解释不构成对本报告的个人诊断”。这两种设计都是让Agent从“敢说话”变成“会说话”的关键约束。2.3 我的Spec骨架模板可直接复制整个Spec文档我精简成一个可以直接套用的骨架模板放在下面。它的形式介于伪代码和提示词之间既可以作为System Prompt的底稿也可以直接翻译成工作流节点的配置说明。# Agent规格说明书 ## 1. 角色 你是病理报告辅助研读助手。你的使命帮助用户理解病理报告中的关键信息、解释专业术语、提示就医路径。 你不是医生不进行诊断不代替医疗建议。 ## 2. 输入契约 可接受 - 完整病理报告文本 - 报告片段 - 针对报告的提问 处理方式先识别报告中与病理相关的结构化字段再进入流程。 ## 3. 处理流程 step1 文本清洗去除姓名、住院号等身份信息 step2 抽取字段送检材料/大体所见/镜下所见/病理诊断/免疫组化/分子检测 step3 术语映射从术语词典匹配解释 step4 结构化解读生成结论逐项解释 step5 风险分级按关键词触发A/B/C/D级响应 step6 输出回答按输出契约组织语言 ## 4. 输出契约 结构 - 一句话结论 - 关键术语解释每条不超过3句 - 下一步建议 - 免责声明 禁止夸大、恐吓、未提及信息推断、具体治疗方案推荐 ## 5. 知识边界 - 不做最终诊断 - 不评价医生建议 - 不解释超出知识库范围的罕见病 - 检测到未知术语必须声明信息不足 ## 6. 风险兜底 - 报告不完整 → 主动声明建议补齐 - 字段缺失 → 只解读现有字段 - 无法判断严重程度 → 不做判断建议咨询医生 ## 7. 验收标准 - 信息抽取准确率 95% - 术语解释准确率 90% - 风险场景触发率 100% - 幻觉断言 0这个骨架看起来简单但每一项落进Coze的配置里都有具体对应关系。下一节我就讲这部分实操。3. 在Coze平台上一步步落地3.1 先盘点平台能力再决定哪层用工作流、哪层用提示词Coze这个平台的组件不少我刚上手的时候也犯过一直在“人设与回复逻辑”面板里写大作文的错误。实际上一个严肃的Agent应用应该用尽平台的各种能力而不是把所有逻辑都压在提示词一个出口上。盘点下来我对这个平台组件做了一个分工系统提示词只承载“角色、输出格式、风格约束、边界声明”这些纯文本性的规则工作流承载“信息抽取→术语映射→风险分级→回答生成”这个多节点流程知识库承载术语解释和病理学基础知识变量和记忆承载用户会话中的上下文插件能力则用来处理报告图片的OCR转文字。这个分工的核心判断依据是凡是“顺序固定、可被规则描述”的逻辑尽量下沉到工作流里去做凡是“语义理解、语言生成”的部分才留给大模型去发挥。这样即使模型的回复再飘前端的抽取结果和风险分级仍然是被工作流节点牢牢控制住的。实际上很多Agent项目行为失控原因不是模型不好而是你让模型干了太多它不该干的活。模型适合做总结、解释、改写不适合做需要严格步骤和多路条件判断的流程控制——哪怕是现在很聪明的模型也一样。3.2 从空应用开始全局提示词怎么贴合Spec我在Coze里新建了一个Bot第一步没急着搭工作流而是先把全局设置里最核心的“人设与回复逻辑”按照Spec文档重新组织结构。这里有个我特别想强调的经验提示词不建议全用自然语言段落来写最好用结构化指令把Spec里的关键条款拆成编号清单。以我最终的全局提示词为例整体分成了六个指令块。第一个指令块定义角色“你是病理报告辅助研读助手。你不是医生不进行诊断不替代医疗建议。”第二块定义输入处理原则“接到用户输入后先判断是否为病理报告相关内容不属于本范围的内容一律拒绝回答并引导用户上传报告。”第三块定义输出结构“必须按四段式输出分别是核心结论、术语解释、下一步建议、免责声明。”第四块定义术语处理规则“解释术语前必须检索知识库禁止基于模型记忆自行解释。”第五块定义风险响应等级“当报告原文出现以下关键词时按对应等级触发提示语。”第六块定义边界与兜底“不确定的内容必须明说宁可告诉用户信息不足也不能推测。”这种编号清单式的提示词在执行效果上明显优于大段文学性描述。原因也很简单模型对结构化的指令解析更稳定条与条之间不容易发生语义稀释或覆盖。另外后续如果你需要做A/B测试改一条指令就能测不需要重写整段话。3.3 工作流编排把诊断流程拆成节点全局提示词解决了“说话方式”问题但流程控制还得靠工作流。这个Agent的工作流我拆成了六个节点开始节点接收用户输入并把输入传给下游。第一个处理节点是内容识别输出一个判断标签病理报告、报告片段、其他内容。如果是“其他内容”直接走到一个兜底节点返回拒绝话术不进入后续流程。这个设计看起来简单但它直接避免了很多无意义的计算和潜在风险——用户发一句“你好”Agent不应该调一遍诊断链路。第二个节点是文本抽取。这个节点我很早就踩过一个坑一开始让它“提取报告中的关键信息”结果大模型节点自由发挥输出了一堆格式化但不可预期的JSON。后来我换了一种做法在提示词里给出一个严格的字段模板并要求节点只输出固定的JSON结构不做任何解释和补充。这样一来后续节点解析JSON就完全稳定了。第三个节点是术语映射。这个节点直接检索知识库输入是从上一节点抽取出来的诊断结论和免疫组化字段输出是对应的通俗解释。它是整个Agent的“知识担当”能不能解释清楚Ki-67、ER、HER2这类指标就看知识库建设得怎么样了。第四个节点是风险分级。我用的是规则判断而非模型判断通过关键词匹配来决策比如“原位癌”“低度恶性”“高级别上皮内瘤变”触发B级“浸润性”“转移”“恶性肿瘤”触发C级原文不完整或出现未收录术语触发D级。为什么用规则因为模型判断在敏感场景里存在随机性而风险分级属于那种必须做到100%稳定的功能规则是最可靠的实现方式。第五个节点是回答生成。这个节点接收抽取结果、术语解释、风险等级三个输入然后按输出契约生成最终回答。第六个节点就是结束节点把结果返回给用户。整条链路跑下来我最大的体会是工作流把Agent从“凭感觉回答”变成了“流水线生产”。每一级都有明确输入输出出了问题直接在对应节点上排查和修改不用再把整个系统提示词翻个底朝天。3.4 知识库建设与检索参数调优知识库是整个Agent专业度的大半条命。我的知识库分了三个集合第一是《病理学基础术语词典》覆盖组织学、细胞学、免疫组化常见指标的通俗解释大约收了两百多条核心术语第二是《常见肿瘤病理诊断摘要》针对乳腺癌、肺癌、消化道肿瘤等高频病种整理了病理诊断常见句式和对应解读第三是《报告结构与解读规范》用来帮助模型理解一份完整病理报告应该包含哪几个部分。文档导入后分段处理是有讲究的。术语词典我按“一条术语一段”导入每段控制在60字以内保证精确检索疾病摘要按主题分块每块控制在500字以内避免大段文本稀释语义。在知识库的检索设置里我把结果条数设为3到5条相似度阈值设在一个相对保守的水平宁可检索不到也不让无关内容混进来。实际用下来有一个容易被忽视的点Coze的知识库检索结果是有权重的调高“知识库优先”会让Agent更倾向于引用检索到的内容但也会让它变得过于死板——哪怕用户只问一句“这个报告总体怎么样”它也会强行引用知识库段落而不是直接回答。后来我折中了一下把知识库权重调成中等让模型在“有依据的回答”和“自然的对话体验”之间取一个平衡。4. 测试与验收凭什么说它达到了“专家级”4.1 我设计的评测集与评分维度搞了这么多配置怎么说服自己这个Agent真的达到了“专家级”我给自己定了一条规矩没有测试数据就不能算做完。我建了一个病理研读评测集总共20条测试用例分布在四个类别里。第一类10条是完整病理报告文本用来测全流程解析能力。第二类5条是报告片段加用户提问比如只给“镜下所见”这段话问“这说明什么”测的是Agent在信息不完整时能否把已有内容说清楚。第三类3条是干扰输入比如用户上传了血常规报告或者干脆发一句无关的话测的是Agent能不能守边界。第四类2条是包含未知术语或明显信息缺失的报告测风险兜底能力。评分维度我设了四个信息抽取准确率看字段抽得对不对术语解释正确率看解释是否和知识库一致输出格式合规率看四段式结构是否整齐、长度要不要超标风险边界合规率看有没有出现越界断言比如直接说“你这是癌症晚期”这种类型的话。4.2 三轮迭代中的真实翻车案例评测集不是摆设我拿它跑出了三轮实实在在的迭代记录每一轮都有翻车案例也有对应的修复方案。第一轮翻车最严重的就是术语解释环节。模型把“高级别上皮内瘤变”解释成“癌前病变很快就会发展成癌症”这个说法在医学上是粗糙且容易引起恐慌的。问题出在术语映射节点只做了模糊的语义匹配没有和知识库精确对齐。解决方案是给知识库里的每一条术语增加“严禁使用表达”字段比如这一条明确写入“禁止使用‘很快会变癌’等时间性预测表述”。加了这层约束之后测试集里同类问题全部消失。第二轮翻车发生在知识库检索命中上。我调低了相似度阈值后发现Agent偶尔会拿“食管癌”的知识来解释“胃癌”的术语因为两篇文档都含有“腺癌”这个共同词检索时混淆了。后来我在知识库中给每个病种增加了“适用部位限定”的排除性描述并在术语映射节点的提示词里强调“必须检查术语与报告中的解剖部位一致不一致时不要引用”。第三轮翻车是格式合规。有个用例输出里直接略过了“下一步建议”段落原因是用户输入太长模型在生成时发生了截断。我在回答生成节点的配置里把最大输出长度调大同时把“四段式结构缺一不可”写进了生成提示词的最前面并把“下一步建议”压缩成标准话术框架。这样即使内容再长结构也不会丢。4.3 验收通过的最低标准三轮迭代之后我的评测集跑出了这样一组数据核心信息抽取准确率从第一轮的82%提升到96%术语解释正确率从78%提升到92%输出格式合规率达到100%风险边界合规率保持100%幻觉断言数量归零。也就是说我把第四条验收标准的红线定为“风险边界合规率必须100%”任何一条测试用例出现越界断言都不算通过。这个标准对我自己来说很苛刻但恰恰是这种苛刻让这个Agent敢被叫“专家级”。专家级不是指它比医生更懂病理而是指它的行为方式像一个训练有素的助手该说的话一句不少说不该说的话一个字都不多讲遇到自己不懂的会主动承认。5. 常见问题与排查技巧实录5.1 知识库命中率上不去怎么排查这是我在Coze上最常见的故障。排查顺序应该从知识库本身开始先看分词是否合理如果文档段落太长会让检索精度下降建议按语义切割再看相似度阈值阈值过高会导致什么都检索不到适当下调到0.3到0.4之间观察。第三看结果条数设置的条数太少可能漏掉正确内容设置太多又可能混入噪声我一般取3到5条。最后看文档标题和正文首句如果标题里没有关键词信息检索时容易匹配失败建议给文档加一个能概括主题的标题和首句摘要。5.2 模型输出发散、出现“过度诊断”“过度诊断”是我给这类问题起的黑话指模型自行推断出了报告原文没有的信息。比如报告只写了“符合腺瘤样增生”模型却加了一句话“需警惕恶变可能”。这类问题几乎都出在回答生成环节。解决办法有三层第一层在抽取节点强制只提取原文存在的字段第二层在生成提示词里加硬性约束“未出现在原文中的诊断信息一律禁止出现”第三层在风险分级节点里加规则凡是原文不包含“恶性”“癌”“浸润”等词生成节点就统一按A/B级话术走不允许人为拔高。5.3 输出格式经常和Spec对不齐格式不对齐的根子往往不在生成节点而在输入截断或上下文污染。一个前一轮对话中出现的报告片段可能混进下一轮的生成上下文里导致结构混乱。我的做法是每一轮处理都从工作流重新抽取信息不依赖上下文记忆同时在回答生成节点的提示词开头明确给出本次回答必须使用的字段数据并声明“忽略一切与本次输入无关的上下文”。如果在评测集里发现某条用例格式不对先看是不是输入文本超出模型最大输入长度必要时在文本清洗节点加截断逻辑。5.4 工作流节点执行不稳定时的排查路径工作流偶尔会失败日志里报的错往往不那么直白。我自己总结了一套排查路径先确认是不是上游返回的JSON结构变了比如抽取节点多返回了一个字段或漏掉了一个键Coze的大模型节点偶尔会出现JSON带前后缀文字的情况给了解析器麻烦。处理办法是给抽取节点加“只输出JSON不要输出任何解释和前后缀”的强约束并在下游解析前增加一个清洗步骤。其次再检查有没有节点超时超长报告文本会拖慢大模型节点的响应可以在文本清洗节点把内容压缩到关键字段再往下送大幅降低超时概率。最后的经验之谈这套项目做完之后我最大的改变是对Agent开发的整体认知。过去我总觉得Agent的能力上限取决于模型选得好不好、提示词写得妙不妙现在我认为真正决定一个Agent能走多远的是前面那份规格书写得细不细。Spec文档里多写一行“遇到未知术语要明说”Agent在线上就少给用户制造一个恐慌。工作流里多拆一个节点后面排查问题时就多一条清晰的线索。知识库里多收一条精准的术语对照模型就少一次靠记忆瞎编的机会。这些事看起来不酷不像是“造一个专家级Agent”该有的样子但恰恰是它们堆出了专业感和可靠性。如果你想在Coze上做类似的垂直领域Agent我的建议是从一份Spec文档开始哪怕很简单也先把角色、输入输出、流程、边界写清楚再打开平台配置界面。相信我你不会后悔这个顺序的。
阅读完成 · 觉得有帮助？
