关于 donor-proposal-scoring
donor-proposal-scoring 是评估已完成提案的技能,依据资助方征集文件中的标准进行分析。它面向提案负责人,提供有证据支撑的评分、校准评估和优先修改清单。
主要功能
- 01逐项按标准评估提案
- 02引用证据及页码
- 03给出评分估计与区间
- 04对照资助方报告校准评分
- 05整理可执行的修改优先级
适用场景
- 01提交前审阅提案草稿
- 02依据过往资助方反馈评估重提交提案
- 03将内部评分与评估总结报告对照
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ gasserane/ personal-skills --skill donor-proposal-scoring安装后在 Claude Code 中输入/donor-proposal-scoring确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
references/rights-holder-coverage.mdword-export.mdworked-example-synthetic.md详细介绍
/donor-proposal-scoring — 根据捐助方评分表评估提案
只做一件事:评估一份已写好的提案,说明捐助方评审员会给它打多少分,以及原因。撰写提案请用 /proposal。评估供应商报价请用 procurement-offer-review。这是申请方视角,即从捐助方的角度审视自己的申请材料。
模式路由
- SCORE(默认)——征集文件和提案均已准备好;按评审标准逐项评估,提供分数、依据、评分区间和按优先级排列的修改清单。
- CALIBRATE——捐助方的评估总结报告(ESR)已送达,且已有此前的评分;对照两者,从差异中总结经验。
如果两个文件都已提供,而 Ane 未说明使用哪种模式,请用一行询问。绝不要把 CALIBRATE 材料带入 SCORE 输出:先阅读捐助方报告会破坏测试。
首先要确认的两件事
这是盲测还是实时咨询? 两者需要采用相反的阅读顺序。
- 盲测(已有 ESR,目的是检验评估方法):不要打开 ESR。不要为了“确认格式”而打开。先将评分写入磁盘,再进行对照。
- 实时咨询(提交或重新提交前正在修改提案):先阅读该捐助方此前的所有 ESR。捐助方评审的行文风格可以学习,这是提升准确度成本最低的办法。该捐助方赞扬了什么,总会要求什么,会主动提及哪些群体,又从未提及什么?然后再评分。
这是谁的提案? 如果申请方是 IPPF 或 Ane 自己的团队,这在一定程度上属于自我评估,独立性必然有限。请在输出开头的说明中直接说明,不要放在脚注里。搜索提案中是否出现 Ane 的名字,并说明她是否出现以及担任什么角色。评分应依据征集文件的措辞,而不是你对组织意图的了解。
通用规则——两种模式均适用
- 评审标准只取自征集文件,不得使用其他来源。 不得参考同一征集去年的要求、申请表说明或记忆。征集文件每年都可能变更措辞、权重和门槛,凭记忆沿用评审标准就等于捏造标准。如果缺少征集文件,请说明并停止;不要试图还原。
- 事实可靠性。 每项评分判断都要注明依据所在的提案章节或页码。每项评审标准都要注明征集文件的页码。无法定位的数据应报告为缺失项。绝不要估算预算项目、门槛或日期。
- 绝不捏造捐助方的想法。 输出应说明征集文件要求评什么,以及提案包含什么。如果推断出“评审员因此会扣分”,请明确标为推断。
- 一级工作简报。 面向管理层或提案负责人,而非评估专家。先讲结论,用通俗语言,缩写首次出现时写出全称,正文中不点名框架。引文统一放在末尾的
**Evidence base:**行中。 - 编辑保留。 如果目标文件已存在,务必遵循
mel_wiki/wiki/concepts/edit-preservation-protocol.md。Ane 一旦手动编辑过评分输出或其 Word 版本,生成器就已过时:应直接编辑她的文件,绝不要重新运行生成器来“刷新”。 - OneDrive。 在 git 文件夹中,写入和提交须在同一个区块内完成;在普通 OneDrive 文件夹中,写入后重新读取已更改的行,以确认修改已保存。
SCORE 模式
步骤 0:盲测规范
打开任何文件之前,先列出存放所提供文件的文件夹,并检查每个文件是否匹配 *ESR*、*evaluation*summary*、*evaluation*report*。如果其中有匹配文件,请在输出中指出文件名,说明不会打开,并建议在评分开始前将其移出本次运行范围。克制并不等于控制。读者无法验证一个位于范围内的文件是否确实未被阅读;在现场演示中,这个缺口正是测试与口头声明之间的全部差别。
第 1 步:提取评分表,并在评分前列出
阅读申报文件中的评审标准部分。在作出任何判断之前,先在输出中列出:
- 每项标准及其最高分
- 每项单项及格线和总及格线
- 申报文件规定的平分决胜顺序
- 每项标准涵盖的要素,使用申报文件原文,或引用原文、近似转述
- 达标意味着获得资助,还是仅意味着在名额上限内排名
这是必须遵守的顺序要求,原因并非官僚主义。评分很容易倒着进行:一旦总分看起来合适,各项标准的分数就会被调整到能凑出这个总分。首次评分前,先完整、公开地列出评分表,才能避免这种情况。这样也能发现申报文件将某项内容计入了你原本以为应归入其他标准的情况;这是常见且代价高昂的误读。
明确说明每项内容来自申报文件的哪一页。
第 2 步:先评估项目,再评估文件
按以下顺序分两轮进行。这一顺序是本技能中影响最大的一项指示。
A 轮:项目实质。 这个项目实际做什么、服务谁,设计是否经过充分推敲?
- 涵盖了哪些权利持有人和人群,哪些人群虽被提及却未获服务(第 3 步)。
- 声明采用的方法是否改变了设计,还是仅仅出现在设计中(第 4 步)。
- 谁负责实施每项机制,具备哪些能力;如果他们离开,会发生什么(第 5 步)。
- 从活动到变化的既定路径是否可信,衡量框架是否追踪其中任何环节。
- 可持续性方面的回答是否真正作答,还是只重述了与目标保持一致。
B 轮:文件机制。 内部一致性、算术、章节安排、清单的字面合规情况、缺失的附件、未说明的预算项目。
两轮都能发现真实问题。但资助方评审人员会关注 A 轮,而 A 轮才决定是否资助。B 轮的问题容易发现,看起来也很严谨;但在一次真实评估中,发现的问题大多都出在这里。请参阅校准记录:如果存在私人校准记录,请使用 ${WORK_FOLDER_ROOT}/agent-improvements/private-calibration/donor-proposal-scoring/cerv-2026-worked-example.md;否则使用合成记录 references/worked-example-synthetic.md。
提交前的平衡检查。 统计你的发现。如果超过一半属于 B 轮,你评估的是文件,而不是项目。回到 A 轮。这项检查只需 30 秒,却是本技能中收益最高的一步。
第 3 步:检查权利持有人覆盖情况
对每份提案都进行这项检查,无论申报文件是否提及这些群体。权利与平等领域的资助方通常将这些群体视为标准评估对象,而且有几类群体在评估表中设有专门的状态字段。
逐一检查每个群体:是否提及、是否明确说明所采用的方法、监测框架是否追踪、是否开展了有针对性的外展。某群体只在目标人群清单中出现,在其他地方全无体现,这应作为问题记录,而不能算作覆盖到位。
儿童与《联合国儿童权利公约》 · 青少年年龄段划分 · 残障人士 · 难民和移民 · 农村人群 · 罗姆人及其他少数族裔 · LGBTIQ 人群。
各群体的完整提示,以及通常涉及的评审标准,见 references/rights-holder-coverage.md。应在 A 轮评估时阅读,而不是留到最后检查。
儿童权利需要特别强调,因为它最常被遗漏,也最常被评分。它会出现在相关性评审中(是否引用《公约》,是否划分年龄段)、质量评审中(儿童权利是否纳入监测框架,合作伙伴是否都落实了保障措施,而非仅仅采纳),以及影响评审中(是否开展针对儿童的外展)。遗漏一次,通常就意味着三个方面都遗漏。
第 4 步:将视角实质性测试应用于提案
如果某个视角没有改变分析,那就和遗漏一样,属于失误。这条规则已经是我们评估自身写作时采用的标准。现在将它应用于正在审查的材料。
针对提案声明采用的每个视角——交叉性、性别转化、参与式、去殖民、权利本位、不造成伤害——找出它改变项目实际做法的句子。不要找只是提及它的句子,也不要找只是将它列为原则之一的句子。
按照捐助方自己的表述,测试问题是:提案是否说明了交叉身份如何影响获取机会,还是只说交叉性很重要?提案是否有证据表明自身处于性别连续谱的哪个位置,还是只称自己具有性别转化性?提案是否说明谁参与评估以及如何参与,还是只称评估具有参与性?
如果某个视角出现了,却没有改变任何内容,这就是一项发现,而且通常会影响相关评分标准下的得分,尤其是将性别视角或包容性列为评分要素的标准。如果某个视角确实改变了设计,就指出具体位置,因为这是值得维护的优势。
也要警惕相反的错误:仅因表述写得好,就照单全收地给予认可。如果需求评估没有分类数据,也没有证据表明曾征询相关社群的意见,那么即使交叉性承诺写得再好,也得不到分数。
第 5 步:测试由谁负责执行
针对每项主要机制——子拨款、评估、试点、宣传活动、能力建设工作流——提出三个问题:
- **由哪个具名岗位负责执行?**不是哪个组织,而是哪个职位。
- **具备什么能力?**人员配置是否与资金规模和时间安排相称。子拨款方案如果占用预算很大一部分,并且要在短时间内发放多笔资助,就需要明确列出人员配置。
- **应急方案是什么?**如果关键人员离职,会发生什么?
之所以要做这项测试,是因为评分过程可以逐项、详细地审查机制控制,却始终不问由谁负责执行,而捐助方恰恰会问这个问题。在其他方面都很强的提案中,缺少执行人员是典型漏洞;只有直接提出这个问题,才能发现它。
第 6 步:逐项评分
针对征集通知中的每项评分标准,按其原有顺序写明四项内容:
- 得分:注明满分,以及适用时的门槛结果。
- **得分依据。**列出提案中的证据,并注明章节或页码。如果精确措辞会影响判断,就引用关键原文。
- **如何才能获得更高分。**将每项不足分别列出,并明确说明。
- **需要修改的章节。**列出提案中的具体章节,让修改清单无需重新通读全文也能直接执行。
评分时要遵守两项原则:
**认定内容缺失前,先搜索整份文件。**评审人员会跨章节阅读,并会认可出现在任何位置的材料。写下“提案没有涉及 X”之前,先搜索整份申请材料,包括附件、政策文件和机构介绍。申请方通过其他位置所述的常设机构制度涵盖某项内容时,通常会被视为已涵盖。只要养成这一习惯,就能避免示例分析中最大的一类错误。
为每项发现标注置信度。高表示评审人员几乎肯定会同意。中表示论据站得住脚,但存在争议。低表示结论取决于评审人员对清单的字面解读程度。诸如“内容放错了章节”或“这里没有重申这项清单内容”之类的发现,默认属于低置信度,因为评审人员会整体判断合格申请方的表现。应如实说明这一点,而不是将这些发现排在最前面。
步骤 7:给出范围,而非单个数字
并列给出点估计和实际可行的范围,并说明范围下限代表什么。
专家评审员对同一份提案打分时,分数通常会相差 5 到 10 分。只给总分会造成虚假的精确感;在通过或不通过的决定中,虚假的精确感比不给数字更糟。如果某个门槛落在范围内,要明确说明低于门槛的下限意味着不通过。
排名比总分更重要。说明你认为哪项标准最强、哪项最弱,因为修订清单取决于这一判断,而这一判断也最容易出错。
步骤 8:分成两类,各自独立
列出两份清单,绝不要合并排名。合并后,零分事项就可能被排成首要修订项。
清单 A——计分评审结果。 会影响分数的事项。按可挽回分数与所需工作量排序。每行包括:提案章节、需要修改的内容、受影响的评审标准、预计分数、置信度,以及属于需要新证据还是改写工作。改写工作是提案负责人本周就能着手处理的事项。
清单 B——签署前及实施事项。 不影响分数但仍然重要的事项:准备资助申请前需要弥补的控制缺口、没有余量的上限、合规风险,以及日后会让审计人员困惑的算术问题。清楚标明这份清单,避免有人将其误读为失分清单。
按字面解读征集文件中的控制检查表,往往会产生看起来像清单 A 事项的清单 B 事项。在示例中,一组这类问题被排成首要评分修订项,但资助方认为相关章节符合要求。它们仍值得修正,但不影响分数。
步骤 9:说明哪些内容无法核实
文本提取会丢失信息。将这些内容列为需核对原件的事项,绝不要将其断言为已确认的问题:
- 有底色或颜色的时间表和甘特图网格
- 组织结构图、示意图,以及以图像形式提交的任何图表
- 提取后列对齐丢失的预算表
- 门户表格(A 部分)与叙述文本(B 部分)之间的交叉引用
- 征集文件要求评分、但你完全找不到的任何内容
对于每一项,说明如果疑虑属实,会造成什么影响。如果某项无法核实的问题一旦属实,其严重程度将超过清单中的所有修订项,就要明确写出这一点。
步骤 10:交付
先给出 BLUF:结论句,然后是支撑结论的关键理由。接着列出五项须知,再说明偏差和不确定性。然后依次给出对照表、各项标准评分、两份清单、未核实事项清单和证据依据。
写入文件,然后提供 Word 导出版本(见“输出”部分)。
CALIBRATE 模式
资助方的 ESR 已送达。这一模式的价值完全取决于诚实,而诚实很容易被破坏。
规则零
绝不修改原始分数。 两组分数都要原样展示。悄悄追溯调整会摧毁比较的唯一目的;而且这种做法尤其诱人,因为它会让结果看起来更好。严格按照先前发布的内容复现评分,并在标题中说明没有进行任何修改。
ESR 路径必须由用户提供,绝不能自行查找。 Ane 会指定文件。不要扫描文件夹来寻找,也不要打开因处理其他事项而注意到的候选文件。扫描文件夹会导致在 SCORE 运行期间读到 ESR。
结构
-
总分对照表。 列出评估标准、最高分、及格线、我的得分、供体得分、分差,以及双方得分占最高分的百分比。百分比很重要:一项满分 20 分的评估标准相差 3 分,与一项满分 40 分的评估标准相差 3 分,代表的是不同的问题。
-
每项评估标准各设一个小节,每节包含两张表和一段简短分析:
- 优点:每行都标注
[Donor]/[Mine]/[Both] - 改进建议:使用相同的标签
- 为何在此处存在差异:用文字说明供体看到了哪类我没看到的内容,以及我看到了哪些供体并不在意的内容
每行都要标注。没有标签的表格只是合并后的列表,会掩盖这项练习旨在发现的规律。
- 优点:每行都标注
-
双方意见一致之处。 基于相同文档独立得出的相同发现,最值得信赖。说明具体是哪些发现,以及它们分别归入了哪个类别。
-
坦率说明我错在哪里。 列出每项相互矛盾的发现、它被赋予的优先级,以及供体的原话评语。然后用一段话说明背后的机制:这些发现是凭空捏造的,还是文档中真实存在、但权重评估不当的特征?通常是后者。点明权重评估不当,比道歉更有用。
-
我完全遗漏的内容。 列出每项供体发现,说明它没有出现在评分中、归属哪个评估标准,以及为何会被遗漏。这一栏是整个部分的重点。“未予考虑”是可以接受的坦诚答案。对遗漏进行归类:如果 9 项中有 4 项集中在一个类别,就指出这是系统性盲点,并说明什么措施本可以发现这些遗漏。
-
校准结论。 制作一张表:
- 总分误差:分值及百分比
- 公布的分数区间是否包含真实值,以及真实值在区间中的位置
- 每项评估标准的偏差方向:偏宽松或偏严格,每项用一行说明
- 评估标准排序:正确还是错误——这比总分更重要,因为改进清单是根据排序制定的
- 通过或不通过的结论:正确还是错误
- 数量:相互矛盾的发现数、实质性遗漏领域数、独立确认的发现数
-
用一句话概括规律,然后说明这对方法的使用意味着什么:它适用于什么,不得用于什么,以及下一轮前需要改进什么。
校准的目的
分数预测不是交付成果,应明确指出这一点。若一种方法的分数偏差数分、存在相互矛盾的发现,且评估标准排序错误,它就不是预测工具。它的价值在于改进清单、相互印证的发现,以及对盲点的记录。应在输出中明确说明这一点,不要让读者误以为方法具有并不存在的精确度。
每次校准都应以说明下一轮要做哪些改动作为结尾。将这些改动反馈到此技能中。
输出
Markdown 是权威版本。 先将其写入存放源文件的文件夹,除非 Ane 指定其他位置。
- SCORE:
<call-or-programme-slug>-proposal-scoring.md - CALIBRATE:
<call-or-programme-slug>-scoring-vs-donor-comparison.md
两种情况下都要提供带 IPPF 品牌标识的 Word 导出文件,并根据文档形态选择构建工具。这两种形态需要不同的工具,使用错误的工具会导致文档排版拥挤:
- 叙述式评分 → 使用
ane_package.reporting.word_export中的write_word_report。内容包括 BLUF 要点、包含纯文本摘要和要点的章节、用于呈现评分的发现卡片、方法说明和术语表。 - 表格优先的校准 → 使用 python-docx,直接基于
_open_branded_base()构建。WordReport的发现卡片仅支持两列,而对比需要三到六列。
配方、准确的导入列表、品牌表格辅助工具和术语表模式见 references/word-export.md。品牌值来自 ane_package.reporting.brand.IPPF_FORMAT_TEMPLATE;硬编码颜色、字体或数字格式属于回归问题。
每个生成器的文档字符串都必须包含编辑保留过时风险警告,指出其生成的 .docx 文件,并指向 mel_wiki/wiki/concepts/edit-preservation-protocol.md。如果目标文件已存在,必须遵循该协议。
AI 披露。 两种输出都必须以披露声明收尾:注明所用模型;评分判断和建议在使用前需要人工核验;AI 不是作者,也不是信息来源。若进行盲评,需说明捐助方评估文件在本次任务范围内,但有意未打开,因为只有这种顺序才能使比较成为测试,而非重构。
说明盲评类型。 方法说明需明确写出以下其中一种:结构性盲评,即捐助方评估文件不在本次任务范围内;或克制式盲评,即文件在文件夹中,但未被打开。这两种说法的可信度并不相同。读者可以核实前者;后者则取决于操作人员的陈述,因此要明确称其为克制式盲评,不要让“盲评”一词被理解为更强的说法。
术语表。 面向非专业读者,所有术语都要提供释义:项目征集词汇(授予标准、门槛、项目征集说明、资助率、工作包、里程碑、交付成果、传播级别、子资助或 FSTP、荣誉声明)和 MEL 词汇(基线、指标、成果、产出、变革理论)。
与专家协作
不要重新实现专家已有的工作。在需要其判断力参与评分判断的环节调用专家:
proposal-architect— 授予标准映射、逻辑框架—预算—工作计划的一致性、捐助方合规性safeguarding-reviewer— 儿童保护、《联合国儿童权利公约》、避免造成伤害、在合作伙伴中落实保护措施intersectionality-analyst— 第 4 步的视角实质性检验,分析交互效应,而非平行分类细分srhr-indicator-designer— 指标质量、分类细分,以及测量框架是否追踪了提案承诺的成果
对于大型或高风险提案,与评分标准的评分并行,调用专家分别进行覆盖审查和视角检验。对于快速检查,可直接在当前流程中完成。
范围界定
- 撰写提案使用
/proposal。评审职权范围条款使用tor-procurement。评审收到的供应商报价使用procurement-offer-review。根据 IPPF 认证标准评估成员协会使用accreditation-desk-review。对完成的文本进行 QA 把关使用check-deliverable。 - 此技能不会提交任何内容,不会决定资金,也不会签署财务或法律立场。
- 此技能不会预测捐助方评分;任何看起来像预测的输出都夸大了其能力。它预测的是分数可能落在哪里,这是另一种更有用的说法。
**证据基础:**此方法所依据的校准记录(如果存在私有校准记录,则使用 ${WORK_FOLDER_ROOT}/agent-improvements/private-calibration/donor-proposal-scoring/cerv-2026-worked-example.md;否则使用合成记录 references/worked-example-synthetic.md)、references/rights-holder-coverage.md、references/word-export.md。