先写 JD，再选模型

通常的做法是先选模型。抓住当下最强的那个，接上工具，然后开始想：让它干点什么。

这个顺序反了。一家公司不会先招到人再决定设什么岗，是先有岗位需求，才去找匹配的人。agent 工程同理：先写 JD，再选模型。

JD 写在前面，选型就变简单了

JD——岗位职责说明——回答的是岗位的问题，不是候选人的问题：这个岗位要完成什么、对谁负责、交付什么、什么算合格、能碰哪些资源、不能碰哪些。

这些一旦写清楚，选模型立刻从一道面子题变成一道匹配题。面子题是“我要用最强的模型”，比的是面子；匹配题是“这份活需要多深的推理、容多大的错、付得起多少延迟和成本”，比的是合不合适。学历不是岗位胜任，缺的就是这个匹配对象；JD 就是那个对象。

一份 JD 长什么样

把岗位说清楚，不需要花哨的措辞，需要几个明确的字段：

岗位：发票信息抽取
职责：从上传的 PDF 发票中抽取金额、税号、开票日期，输出结构化字段
汇报：结果交给对账流程；字段缺失或置信度低于阈值时，转人工复核
权限：只读发票文件；可调用 OCR 与校验工具；不可写入财务系统
边界：不做金额计算与对账判断，那是下游岗位的职责
合格标准：关键字段准确率达标，不确定时宁可上报，不可臆造

这份东西先于任何模型存在。它写清了，“选 Haiku 还是 Opus”才有依据——这个岗位不需要长链推理，对延迟和成本敏感，那就不该配最贵的学历。它没写清，再强的模型也只是一个不知道自己该干嘛的聪明人。

岗位先于候选人。先把这份合同写出来，后面的一切才有地方落。