客户找上门时，给你的从来不是「需求」，是「症状」。
「我们质检漏检率太高了。」「月底对账要熬三个通宵。」「客服根本招不到人，老客户都在流失。」 这些话听起来已经很具体了，但对一个要落地的 AI 系统来说，它们近乎于没说。 同一句「漏检率高」，背后可能是三个完全不同的任务：是检测模型本身不准？是产线节拍太快、根本没留出拍清照片的时间？还是质检标准在不同班组之间就不一致，连「什么算缺陷」都没对齐？
这三种情况，要交付的东西天差地别——第一种要做视觉模型，第二种要改的是产线工程，第三种要先做的是一套标准对齐的流程。 如果在第一步把问题认错，后面投入再多算力、调再好的模型，都是在精确地解决一个错误的问题。 这就是为什么我们把「识别与定义」放在三段式的最前面，并且亲自下场做，而不是甩给客户「你先把需求文档写清楚」。
客户能描述痛，但说不清病。把「痛」翻译成「病因 + 处方」，是我们这一步的全部工作。
01 · 元 Agent 在这一步做什么不是问需求，是做诊断
我们带进现场的，不是一份调研问卷，而是一个元 Agent 加上技术合伙人的专家访谈。它要在几次对话里完成三件事：
- 任务形态诊断——这件事到底是「分类判断」「多步流程」「检索问答」还是「需要长期记忆的决策」？任务形态决定了一切，搞错了，后面的框架选型必错。
- 框架选型——是该用一步到位的 ReAct，还是先规划后执行的 Plan-and-Execute，还是带自我反思的 Reflexion？不同任务形态对应不同的 agent 架构，这是公开知识里学不到、只能靠做过几十个领域沉淀出来的判断。
- 数据采集与标注方案——要让它跑起来，需要哪些数据、从哪个系统里取、由谁来标、标成什么样。很多项目不是模型不行，是压根没人想清楚训练和评测的数据从哪来。
02 · 为什么这步决定后面不跑偏定义错一寸，交付偏一丈
这一步的产出不是一份 PPT，是一份可执行的 Agent 设计方案：明确的任务边界、选定的框架、画好的数据管道草图、以及一条所有人都认可的「怎样算成功」的验收线。 这条验收线尤其关键——AI 项目最容易烂尾的原因，是做到一半发现甲乙双方对「做成什么样」的理解根本不一样。我们坚持在第一段就把它钉死。
说白了：这一步是把模糊的经营难题，收敛成一道有标准答案的工程题。题出对了，后面两段才有意义。