最近团队在做 FiT 的评测平台。我前两天自己也做了一个前端 demo，算是先把方向感跑了一下。
团队现在的状态很典型。大家开始用 AI Coding 了，但还谈不上精通。更关键的是，一到大项目协同开发，还是会自然退回过去那套方式：先把需求讨论清楚，再开始落地。
我当然不反对把需求说清楚。评测平台这种东西，如果需求没想清楚，后面会非常痛苦。什么叫一次评测，什么叫通过，样本从哪里来，人工复核怎么做，trace 要不要存，哪些数据不能出域，这些问题不可能靠写代码写出来。
但我不太认同的是，需求确认只能靠人坐在一起用嘴聊。
这件事让我有一个越来越明确的判断：AI-native 不是从编码开始的，而是从需求确认开始的。
以前的需求确认，是把话说给人听
过去做需求，核心对象是人。产品经理写 PRD，研发读 PRD，测试读用例，开会讨论，来回确认。文档当然重要，但它本质上是给人看的。
所以很多东西可以靠人的背景知识补齐。一个词没说清楚，大家心里大概知道；一个边界没写完整，研发会凭经验补；一个异常路径没列出来，测试可能会追问；一个指标口径没完全展开，业务同学也许会在会上解释。
这套方式在前 AI 时代能跑，是因为中间有大量人类默契在兜底。
但现在问题变了。AI 进来以后，需求不再只是给人看，还会被 Agent 拿去执行。它不会像一个老员工那样理解组织里的隐含语境。它看到“支持多模型对比”，就会自动选择一种实现解释。它看到“评测结果可解释”，也会自动猜一个展示方式。
最危险的是，AI 通常不会把自己的猜测标红。它会把猜测变成代码。
模糊需求不会因为 AI 变强而消失。它只会更快地被固化成一个看起来能跑的实现。
需求要从文档，变成上下文包
我现在更愿意把 AI 时代的需求理解成一个 context package。
它不只是“我要做什么”，还包括：为什么做，谁来用，什么不做，怎么算做对，哪些数据能用，哪些边界不能碰，失败了怎么办，历史上做过什么取舍，相关代码在哪，评测样本是什么。
传统 PRD 像说明书。它告诉人这个功能大概应该长什么样。AI-native 的需求更像施工包。它要让 Agent 能读、能问、能拆、能审、能验证。
所以我觉得，团队接下来不应该只问“需求讨论清楚了吗”。更应该问几个更硬的问题：
如果把这份需求直接交给一个 coding agent，它会不会问出关键问题？如果不会，是需求写得太清楚，还是它根本不知道哪些地方该问？
如果把这份需求交给另一个 reviewer agent，它能不能指出歧义、冲突、缺失的验收标准和权限风险？
如果实现做完了，我们能不能沿着需求追到样本、trace、grader、测试、PR 和上线 gate？
这些问题比“PRD 写完了吗”重要得多。
评测平台尤其不能从分数开始
做评测平台，很容易一上来就做成跑分工具。上传样本，选择模型，选择评估器，跑出结果，展示对比。
这当然是评测平台要有的能力，但它不是第一对象。
评测平台真正的第一对象，应该是 Eval Spec。也就是：这次评测到底服务哪个业务判断，什么失败最不能接受，样本怎么来，人工怎么判，哪些指标是硬门槛，哪些只是观察指标，谁有权批准发布。
如果没有这个东西，分数越精确，反而越危险。因为你会得到一个看起来非常科学的数字，但它背后的“什么叫好”可能根本没被定义清楚。
这也是为什么我觉得，评测平台和需求确认其实是一件事的两面。
需求确认负责定义“什么叫做对”。评测平台负责持续验证“现在有没有做到”。如果前者没有结构化，后者就会变成形式化。
让 AI 参与需求确认，可以很轻
这件事不需要一开始就做一套复杂系统。更现实的方式，是先把需求确认流程加上几个 AI gate。
第一个 gate 是歧义检测。让 AI 只做一件事：列出这份需求里所有可能被不同人解释成不同含义的词，并给出每种解释会带来的后果。
第二个 gate 是验收标准检查。不要让 AI 评“写得好不好”，而是让它问：这件事最后怎么验？谁验？失败怎么办？有没有样本？有没有数据口径？有没有不能越过的安全边界？
第三个 gate 是任务拆解检查。让 AI 判断这份需求能不能拆成可独立交付的任务，每个任务有没有明确输入、输出和 Done when。
第四个 gate 是反方 reviewer。让不同 Agent 分别从业务、评测科学、安全合规、工程交付四个角度挑刺。一个 Agent 容易顺着你说，多个反方 Agent 更容易制造必要的冲突。
这些都不复杂。它们不需要平台先做好，不需要流程先审批。只要有一份 Spec，就能跑起来。
前端 demo 不是浪费，是需求反应器
我做那个前端 demo，不是因为我想亲自把平台写完。我的角色也不是去替团队开发。
demo 的价值在于，它让需求从抽象话题变成一个可以反应的对象。
如果大家只讨论“评测报告页应该展示什么”，很容易各说各话。管理者脑子里可能是趋势和风险，算法同学脑子里可能是样本和 judge，平台研发脑子里可能是任务状态和 trace，业务同学脑子里可能是结论能不能拿去用。
但如果前面摆着一个页面，大家就会立刻变得具体：这里为什么先看总分？失败 case 为什么藏这么深？这个指标是谁定义的？这条 trace 能不能点开？如果涉及敏感数据，谁能看到？
这时候讨论才真正开始。
需求不是被聊清楚的。很多需求是被原型、样本、trace 和验收标准一起跑清楚的。
团队要练的不是工具熟练度，而是协作新肌肉
我对团队现在的判断是，不要急着追求“大家都很会用 AI Coding”。工具熟练度当然重要，但它不是第一瓶颈。
第一瓶颈是工作对象没有变。
如果需求还是靠会说清楚，背景还是靠人脑补齐，验收还是靠最后人工看一眼，测试还是靠研发自己想起来跑，PR 还是靠 reviewer 凭经验扫，那么 AI Coding 只是把旧流程加速了一遍。
旧流程越不稳定，AI 加速后越容易乱。
真正要练的是另一组肌肉：把需求写成 Agent 可执行的 Issue，把团队经验写进仓库级 instructions，把验收标准前置，把 trace 和人工审核变成平台对象，把 release gate 做成默认门槛。
这些事情听起来没有“用 AI 一天写完一个系统”那么刺激，但它们才是大项目协同的地基。
管理者在这里要管什么
这件事对我自己的提醒也很直接。
我不是开发人员，虽然平时也会写一点东西。真正落地当然要交给团队。但在 AI Coding 时代，管理者不能只做方向确认，然后等团队交付。
因为方向本身是否清楚，已经不再是一个纯沟通问题，而是一个系统设计问题。
管理者要做的，不是替团队写代码，而是定义三类标准：
第一，什么样的需求可以进入开发。第二，什么样的评测结果可以被信任。第三，什么样的 AI 产出可以进入主干或上线。
这三件事如果说不清楚，团队越努力，越可能只是更快地制造复杂度。
我会让团队先试一个 70 分流程
如果下周要推进，我不会要求团队立刻重构全部研发流程。我会先选一个中等复杂需求，跑一遍 70 分流程。
先让 AI 访谈 PM 和研发，生成一份 Spec。再让 AI 做歧义检测、验收标准检查、任务拆解检查和四个反方 reviewer。然后基于 Spec 生成两个低保真原型，让团队围绕原型走一次真实任务。分歧不在会上散聊，全部写回 Spec。
等 Spec 稳定后，再生成 tasks.md。每个 task 必须有 Done when。实现前，让 AI reviewer 检查 Spec、Design、Tasks 是否一致。实现后，跑最小 eval gate。失败 trace 进入审核队列，判断是修需求、修代码、修样本还是修 grader。
这听起来像多了很多步骤。但其实它是在把原来散落在会议、群聊、脑子和返工里的成本，提前显性化。
显性化之后，AI 才能真正参与。
最后的判断
AI 改变产研流程，不是从“代码谁来写”开始的，而是从“需求是什么形态”开始的。
如果需求仍然只是给人看的文档，AI 就只能是执行助手。如果需求变成可执行的上下文包，AI 才能成为需求分析师、原型师、反方 reviewer、测试设计者和协同开发者。
所以我现在对评测平台这件事的判断很清楚：平台要做，demo 要跑，需求也要对齐。但对齐方式必须变。
未来好的团队，不是最会开需求会的团队，而是最会把需求变成 AI 可参与、人类可验收、组织可追责资产的团队。
需求不是聊清楚的。至少不应该只是聊清楚的。
它应该被追问，被原型化，被评测，被反方审查，被 trace 反向修正。最后，它不是靠大家点头确认，而是靠一套系统持续证明：我们知道什么叫做对。