# 怎样把自己的任务写成可检查的能力需求？

观察模块2026-10-19.observations.2；整理2026-10-15；状态active
把记忆、组合、数学与信息处理需求展开，让工具选择和验收更具体。
现今方法解释，实际工作比例未知；来源待复核/撤回时暂停采用。

## 用任务需求替代一个总分
ADeLe用需求维度描述任务，尝试解释/预测已有测试表现。对你的工作，需求画像可以先说明输入是否完整、是否要多步组合、是否需要数学推导及怎样核验；这是一种整理方法，不是已校准的职业评分。
[ADeLe需求维度与能力画像](https://arxiv.org/html/2503.06378v2)

## 研究具体检查了什么
这项研究问：把一个任务的需求写清楚，能否帮助判断模型会成功还是失败？作者在已有题集内、换一类任务、换一个benchmark（题集）时分别检验；越换到外部题集，越需要自己的验证。

理解指标的人工构造例：预测器能否让成功样本的得分排在失败样本前面，是区分能力；若给出的成功概率很高、实际却经常失败，还要检查概率是否校准。AUROC用于前者，ECE用于后者。这些指标不能直接选定你的工作工具。

核对研究数字：Demand/RF是文中的需求特征预测器，RF为随机森林。其加权AUROC在题集内、跨任务、跨题集分别为0.839、0.810、0.747；它们是预测判别指标，不是83.9%等工作通过率。详细数字属于2025-03-16预印本v2；Nature2026记录仅核书目，不互换结果。
[ADeLe需求维度与能力画像](https://arxiv.org/html/2503.06378v2)

## 一份可读的工作需求例
人工构造的财报计算需求：两份报告、相同财年/币种/口径、两个取数出处、一条增长率公式、程序复算、人的引用对账。若报告口径不同，就无法靠计算能力补救输入。这个例子用于帮助选择验收，不是执行AI任务后获得的能力画像分。


## 从画像回到交付
把每个重要需求对应到输入、一个交付物和独立接收门槛。优先验证最可能导致失败的环节；语义责任、系统权限和现场动作另行处理。未取得验证就保留未知，不把需求维度数量换成工作自动化比例。


## 带回工作
- 列最关键的输入/推导/核验需求
- 把需求变成逐项交付与接收门槛
- 记录实际结果，再修订分工
- [F01交接与验收](/changes?task=F01)
- [M01交接与验收](/changes?task=M01)
- [C03交接与验收](/changes?task=C03)
- [AIME2025：限定数学题的答案成绩](/research?view=capability&series=aime-answers )
- [复杂代码任务：FrontierCode组件分](/research?view=capability&series=epoch-code )

## 原文、版本与定位
- [ADeLe需求维度与能力画像](https://arxiv.org/html/2503.06378v2)；版本作者预印本v2；正式Nature2026只核书目；首次公开2025-03-16；收集未单独记录；实际阅读2026-10-15；状态active；Tables3–5，PDF零基P17/P18/P19，印刷页18/19/20；Table11与模态限制；用任务需求维度解释/预测已测试结果；包含外部题集检验；AUROC与ECE是预测器指标，不是工作成功率；本段详细条件属于预印本，不能套正式版；许可公开预印本有限解释；不复制全文或任务库