软件报价评估

> 基于 NESMA/IFPUG 功能点分析法（FPA），支持三种精度等级的计数方法，对软件项目报价进行专业审校。

项目结构

软件报价评估/
├── SKILL.md                        ← 本文件（技能完整定义 + 工作流）
└── references/
    ├── function-point-rules.md     ← IFPUG 详细计数规则、边界判定、疑难场景速查
    ├── pricing-benchmarks.md       ← CSBMK 生产率基准（人时/FP）、城市人月费率、调整因子、质量基准
    └── output-templates.md         ← 审校输出文件规范（Excel + Markdown 格式定义）

> 以上三个 references 文件是本技能的知识库，执行审校时必须参考对应文件中的规则和数据。

这个 Skill 做什么

接收开发商提供的"功能点预期建设表"，按用户选择的计数方法进行审校：

1. 功能点计数审校 — 检查功能点类型（ILF/EIF/EI/EO/EQ）判定是否正确、复杂度评级是否合理
2. 未调整功能点统计 — 计算 UFP，验证开发商的计数是否存在虚高或遗漏
3. 复用调整审校 — 检查复用类型判定和调整系数应用是否正确
4. 报价区间评估 — 基于行业基准数据，评估调整后功能点对应的合理报价区间

三种计数方法

> 核心原则：动手前必须先确定方法。不同方法对应不同的输入要求、审校深度和精度预期。未询问用户就直接开始审校是错误的。

方法对比

① 预估功能点法（Indicative FPA）

只统计数据功能：ILF（内部逻辑文件）和 EIF（外部接口文件）。

UFP = ILF 数量 × 35 + EIF 数量 × 15

• 不统计事务功能（EI/EO/EQ）
• 不对 ILF/EIF 做复杂度评级
• 固定权重隐含了"平均复杂度 + 配套事务功能"的统计推断
• 审校重点： ILF/EIF 的识别是否正确、是否有遗漏或重复计数
• 典型场景： 项目立项估算、招标前的预算框算、只有需求大纲没有详细规格的阶段

② 估算功能点法（Estimated FPA）

统计全部 5 类功能点，但复杂度默认为"中"，不要求逐项提供 DET/RET/FTR。

UFP = ILF(中)数量 × 10 + EIF(中)数量 × 7
    + EI(中)数量  × 4 + EO(中)数量  × 5 + EQ(中)数量 × 4

• 如果对某个功能点的复杂度有充分信心，可以上调为"高"或下调为"低"（但需注明理由）
• 审校重点： 类型判定是否正确、明显偏离中复杂度的功能点是否合理调整
• 典型场景： 需求已明确但未做详细数据建模、预算编制、报价初评

③ 详细功能点法（Detailed FPA）

统计全部 5 类功能点，逐项分析 DET/RET/FTR 并判定复杂度等级。这是 IFPUG 标准完整方法。

UFP = Σ (每类功能点 × 各自复杂度权重)

• 必须提供每个功能点的 DET/RET/FTR 计数依据
• 复杂度按矩阵查表确定（低/中/高）
• 审校重点： 全部维度——类型、DET/RET/FTR、复杂度评级、是否存在拆分/夸大
• 典型场景： 合同定价、结算审计、正式验收、争议仲裁

何时使用

适用场景：
- 审核软件外包/采购项目的功能点报价单
- 信息化项目造价第三方评估
- 招标前编制软件开发的预算参考
- 验收阶段核对开发商的计费依据是否合理
- 甲方信息化部门审核乙方报价

不适用场景：
- 纯硬件/基础设施采购报价
- SaaS 订阅费用的评估（非定制开发）
- 运维/运营服务的报价（非功能点计价的交付物）
- 敏捷开发按人天计价的报价审核

前置约定

标准依据

预估功能点法和估算功能点法以 NESMA 为准；详细功能点法以 IFPUG CPM 为准。定价环节统一以中国行业基准为主要参考。

数据来源

• 生产率基准：参考 references/pricing-benchmarks.md（CSBMK 官方数据，单位：人时/FP）
• 人月费率：参考 CSBMK 城市基准表（单位：万元/人月），详见 references/pricing-benchmarks.md § 二
• 调整因子：规模变更/应用类型/开发平台/团队背景，以 CSBMK 联盟标准为准
• 功能点计数规则：参考 references/function-point-rules.md

工作流

Step 0 · 选择计数方法（必须最先执行）

> [注意] 强制规则：在获取任何材料之前，必须先让用户选择计数方法。 不要假设用户知道三种方法的区别——展示对比表并给出推荐。

0.1 展示方法选择

向用户展示以下选项并附上推荐：

请选择功能点计数方法：

① 预估功能点法 — 仅统计数据实体（ILF/EIF），固定权重，精度 ±50%
   → 适合：项目早期/立项估算/只有需求大纲

② 估算功能点法 — 统计全部 5 类功能点，复杂度默认"中"，精度 ±25-35%
   → 适合：需求已明确/预算编制/报价初评

③ 详细功能点法 — 逐项分析 DET/RET/FTR，精确判定复杂度，精度 ±10%
   → 适合：合同定价/结算审计/正式验收

0.2 推荐逻辑

根据用户描述的项目情况给出推荐：

0.3 确认方法后获取输入

根据选定方法，要求对应的输入材料：

① 预估功能点法所需材料：
- 功能模块列表，每个模块下列出数据实体（表/文件）
- 标注哪些是本系统维护的（ILF）、哪些是引用外部系统的（EIF）
- 项目类型和技术栈（用于后续报价评估）

② 估算功能点法所需材料：
- 功能点清单，至少包含：功能模块、功能点名称、功能点类型（ILF/EIF/EI/EO/EQ）、功能描述
- 如有复杂度判定，需注明理由
- 项目类型、技术栈、复用策略

③ 详细功能点法所需材料：
- 完整的功能点预期建设表，包含：功能模块、功能点名称、功能点类型、功能描述、DET 数量、RET/FTR 数量、复杂度判定
- 建议同时提供数据模型（ER 图/表结构）和功能规格说明
- 项目类型、技术栈、复用策略

如果用户只给了截图或 PDF： 请用户提供可编辑格式（Excel/CSV），或逐项转写确认后再开始。

以下 Step 1-6 的具体执行方式取决于 Step 0 选定的方法。

Step 1 · 功能点类型审校

逐项检查每个功能点，从以下三个维度进行审校。审校深度因方法而异。

1.0 功能点计数项资格审查（三种方法通用，优先执行）

在判定类型之前，先确认该项目是否属于 NESMA/IFPUG 定义的功能点计数项。以下内容不计入功能点：

审校判定逻辑：
- 该条目是否为用户（业务人员）可识别和描述的？→ 否 → 非功能计数项
- 该条目是否改变/维护了系统内的业务数据？→ 否 → 可能不是功能点
- 该条目是否独立可交付的业务功能（非技术实现步骤）？→ 否 → 可能过度拆分

1.1 五类功能点判定规则（三种方法通用）

1.2 各方法的审校重点（逐项覆盖三个维度）

维度一：表述审校 — 检查功能点名称和描述是否准确：
- 名称是否与描述一致（名称说"查询"但描述写"新增"）
- 描述是否能清晰反映功能（过于笼统如"数据处理"、"系统管理"）
- 是否存在"挂羊头卖狗肉"：名称是业务功能、描述实际是技术任务

维度二：类型审校 — 检查功能点类型判定是否正确：
- 对照 §1.1 五类判定规则逐项核实
- 特别注意 EI/EQ/EO 误判（最常见的错误类型）

维度三：资格审查 — 检查是否属于功能点计数项：
- 对照 §1.0 排除清单逐项筛查
- 确认是用户可识别的业务功能
- 确认不是技术实现细节的过度拆分

① 预估功能点法 — 仅审校 ILF/EIF，但需全维度覆盖：

• [表述] ILF/EIF 的名称/描述是否准确
• [类型] ILF 识别是否正确（用户可识别 + 本系统维护 + 持久化）
• [类型] EIF 识别是否正确（用户可识别 + 仅引用不维护 + 外部系统维护）
• [资格] 是否存在非功能计数项误计入 ILF/EIF
• [资格] 是否存在遗漏的数据实体
• [资格] 是否存在重复计数（同一实体的主表/子表/历史表分开计）

② 估算功能点法 — 审校全部 5 类，全维度覆盖：

• [表述] 逐一确认每个功能点的名称和描述是否准确
• [类型] 检查全部 5 类功能点的类型判定
• [类型] 重点识别明显的类型误判（如把 EQ 标为 EO、把 EQ 标为 EI）
• [资格] 识别非功能计数项（技术任务、非功能需求标记为功能点）
• [资格] 不要求逐项确认 DET/RET，但要识别异常（如一个 EI 声称 30+ 输入字段）

③ 详细功能点法 — 逐项严格审校，全维度覆盖：

• [表述] 对每个功能点名称与描述的一致性逐项核实
• [类型] 对照 IFPUG 规则逐项检查，包括边界情况（详见 references/function-point-rules.md）
• [资格] 确认每个条目均为合法的功能点计数项
• [资格] 每个判定存疑的功能点输出具体理由和 NESMA/IFPUG 规则引用

1.3 审校输出格式

对每个功能点，按问题性质标注严重等级。每个条目可能同时存在多个问题，必须穷举所有发现的问题，不得只列一条：

[严重等级] [序号] [模块名] - [功能点名称] ([维度标签])
   原判定: [开发商判定的类型 / 原始描述 / 原填权重值]
   问题1: [具体问题描述]
   问题2: [具体问题描述]
   ...
   审校结论: [正确类型 / 正确表述 / 正确权重 / 剔除]
   理由: [NESMA/IFPUG 规则引用]

问题穷举示例：

[严重-非功能计数项] [12] [患者服务] - 消息队列配置 ([资格][表述][类型])
   原判定: ILF / 固定权重 35
   问题1: [资格] 属于技术架构组件，不是用户可识别的业务功能，不应计入功能点
   问题2: [表述] 名称为技术术语，无法对应到业务功能
   问题3: [类型] 错误判定为 ILF，实际不适用任何功能点类型
   审校结论: 从功能点清单中剔除，UFP 计为 0，不参与 AFP 计算
   理由: NESMA 功能点计数前提——必须为用户可识别的业务功能；技术架构组件不计入

严重等级完整分类：

维度标签： [表述] [类型] [资格] — 标注该问题属于哪个维度，允许一个条目标注多个维度。

Step 2 · 复杂度审校

2.1 ① 预估功能点法 — 跳过复杂度审校

预估功能点法使用固定权重（ILF=35, EIF=15），不评估复杂度。

直接进入 Step 3 汇总。

2.2 ② 估算功能点法 — 默认中复杂度，审校调整项

核心规则：所有功能点默认"中"复杂度。 仅当开发商对某些功能点标为"高"或"低"时，才需审校调整是否合理。

上调/下调复杂度必须同时满足：
- 数据功能（ILF/EIF）：上调需 DET 数量多（≥20）或 RET 数量多（≥3）；下调需 DET 数量少（≤5）且 RET 数量少（=1）
- 事务功能（EI/EO/EQ）：上调需涉及多个 ILF（FTR ≥2）或输入/输出字段多（DET ≥5）；下调需 FTR ≤1 且 DET ≤4

常见问题：
- 无依据地全面上调复杂度（如所有 ILF 标"高"）
- 仅凭"感觉复杂"上调/下调，没有 DET/RET/FTR 支撑

2.3 ③ 详细功能点法 — 逐项 DET/RET/FTR 分析

对每个功能点检查其复杂度评级是否合理。

ILF/EIF 复杂度矩阵：

EI 复杂度矩阵：

EO/EQ 复杂度矩阵：

复杂度 → 功能点换算表：

常见虚高手段：
- 拆分文件：把一个 ILF 拆成多个"子表"分别计数
- 夸大 DET：把外键、时间戳、状态字段在不同 ILF 中重复计入
- 混淆 FTR：把同一个 ILF 的多次引用算作多个 FTR
- 输出升级：把简单的导出查询（3-5 FP）按复杂报表（6-7 FP）计

Step 3 · 未调整功能点汇总

> 严重条目排除规则：审校等级为"严重"的条目，UFP 计为 0，不参与 UFP 和 AFP 的计算。 这些条目存在根本性缺陷（非功能点、类型完全错误、非本系统），不应贡献任何功能点数值。"建议"等级的条目保留原权重参与计算，仅作为提示标注。

3.1 各方法 UFP 计算

① 预估功能点法：

UFP = ILF 数量 × 35 + EIF 数量 × 15

② 估算功能点法：

UFP = ILF(中)数量 × 10 + ILF(上调为高)数量 × 15 + ILF(下调为低)数量 × 7
    + EIF(中)数量 × 7  + EIF(上调为高)数量 × 10 + EIF(下调为低)数量 × 5
    + EI(中)数量  × 4  + EI(上调为高)数量  × 6  + EI(下调为低)数量  × 3
    + EO(中)数量  × 5  + EO(上调为高)数量  × 7  + EO(下调为低)数量  × 4
    + EQ(中)数量  × 4  + EQ(上调为高)数量  × 6  + EQ(下调为低)数量  × 3

③ 详细功能点法：

UFP = Σ (每类功能点 × 各自复杂度权重)

3.2 UFP 汇总表

| 类型 | 开发商原计 | 审校后 | 差异 | 说明 |
|------|-----------|--------|------|------|
| ILF | XX | XX | -Δ | |
| EIF | XX | XX | -Δ | |
| EI  | XX | XX | -Δ | (预估功能点法不统计) |
| EO  | XX | XX | -Δ | (预估功能点法不统计) |
| EQ  | XX | XX | -Δ | (预估功能点法不统计) |
| 严重条目剔除 | — | -Δ_severe | — | 严重条目 UFP=0，从合计中排除 |
| UFP 合计 | N_total | N'_total | -Δ_total | 审校后 ≤ 原计 |

> 计算规则： 审校后 UFP = Σ(非严重条目的审校后权重) + Σ(严重条目的 0)。严重条目（含"严重-非功能计数项""严重-类型错误""严重-表述错误""严重-非本系统"）无论开发商原计多少，审校后 UFP 均计为 0。

3.3 差异分析

审校后 UFP 必然 ≤ 原计 UFP。偏差幅度反映虚高程度：

> 注意：审校后 UFP 不应大于原计 UFP。若出现审校后 > 原计的情况，说明审校过程中错误地新增了功能点，需回退核查。

Step 4 · 复用调整审校

> 三种方法均需要进行复用调整审校，逻辑一致。

4.1 复用类型与调整系数

4.2 审校要点

• 检查每个标记为"复用"的功能是否确实有可复用的基线代码
• 验证复用比例估算是否合理
• 检查是否存在"假复用"（声称复用但实际上需要重写）
• 纯配置/参数化工作不应计入功能点

4.3 复用系数的审校约束

> 核心原则：复用系数以开发商申报为准，审校方不做任何调整建议。

> 总结：复用系数审校 = 只读不写。 开发商说多少就是多少，审校方不调高也不调低。

4.4 AFP 约束规则

> 审校后 AFP 必须小于或等于开发商原记 AFP。

审校后 AFP = Σ (审校后每个功能点的 UFP × 复用系数)
原记 AFP = Σ (开发商原计每个功能点的 UFP × 复用系数)
审校后 AFP ≤ 原记 AFP（强制约束）

原因：UFP 审校只做减法（剔除无效项、纠正虚高），复用系数不主动下调。两者叠加的结果必然是 AFP 只减不增。若出现审校后 AFP > 原记 AFP，说明审校过程中存在错误（错误新增了功能点或错误调高了复用系数），需回退核查。

Step 5 · 报价合理性评估

> 三种方法通用。预估功能点法和估算功能点法的 UFP 隐含了统计推断，报价评估时应使用更宽的范围区间。

5.1 生产率基准

根据项目特征选取对应的 CSBMK 生产率基准（详见 references/pricing-benchmarks.md）。数据版本：CSBMK®-202510。

全行业（P10/P25/P50/P75/P90 完整分位）：

分行业（CSBMK®-202510 首次公布分行业 P10/P90 完整分位）：

> 单位：人时 / 功能点。数值越低 = 效率越高。全行业 P50 趋势：6.96(2023) → 6.83(2024) → 6.72(2025)。无法确定行业时默认使用全行业数据。

5.2 报价计算公式（CSBMK 标准公式）

调整后工作量（人时）= AFP × 生产率（人时/FP）
                     × 规模变更因子(SF)
                     × 应用类型调整因子(AT, 默认 1.0)
                     × 开发平台调整因子(DL, 默认 1.0)
                     × 开发团队背景调整因子(DT, 默认 1.0)

工作量（人月）= 调整后工作量（人时）/ 174
开发费用（万元）= 工作量（人月）× 基准人月费率（万元/人月）
项目总报价（万元）= 开发费用 + 直接非人力成本

关键参数（CSBMK®-202510）：
- 生产率取 分行业 P50，无法确定行业时取全行业 P50 = 6.72 人时/FP
- 基准人月费率查 CSBMK 城市表（详见 references/pricing-benchmarks.md § 二）
- 城市默认规则： 若调用者未指定城市，默认使用 C 类城市均值 2.34 万元/人月
- 1 人月 = 21.75 天 = 174 小时

5.3 按方法调整评估区间

预估功能点法和估算功能点法的精度较低，报价评估应使用更宽的生产率范围。结论必须输出 P10 / P25 / P50 三档：

> P10 取值规则： CSBMK®-202510 首次公布分行业 P10，直接使用对应行业的官方 P10 值。无法确定行业时使用全行业 P10 = 2.20 人时/FP。

> 城市默认规则： 若调用者未指定项目所在城市，默认使用 C 类城市均值 2.34 万元/人月。C 类城市覆盖大多数省会城市（济南、长沙、合肥、重庆、武汉、昆明等），具有广泛代表性。
>
> 规模变更因子（SF）双口径输出规则：
> - 调用者明确说明了估算阶段 → 按对应阶段取 SF 值（早期 1.39 / 中期 1.21 / 晚期 1.10 / 交付后 1.00），输出单套报价
> - 调用者未提估算阶段 → 默认输出两套报价：
> - 口径一（含规模变更因子）： SF 取 1.39（估算早期最保守值），覆盖需求蔓延风险
> - 口径二（不含规模变更因子）： SF = 1.00，纯生产率驱动报价，反映交付标准
> - 两套报价均标注所采用的 SF 值及含义

> 三档计算公式：
> > 工作量 P10（人月）= AFP × 生产率(P10) × 规模因子 × AT × DL × DT / 174 > 工作量 P25（人月）= AFP × 生产率(P25) × 规模因子 × AT × DL × DT / 174 > 工作量 P50（人月）= AFP × 生产率(P50) × 规模因子 × AT × DL × DT / 174 > 开发费用（万元）= 工作量（人月）× 基准人月费率（万元/人月） >

5.4 输出报价评估报告

报价评估摘要

计数方法: ①指示 / ②预估 / ③详细

一、功能点审校
   - 开发商原计 UFP: XXX
   - 审校后 UFP: XXX
   - 偏差: ±XX (XX%)

二、复用调整
   - 调整后功能点（AFP）: XXX
   - 复用率: XX%

三、报价评估（CSBMK®-202510 基准，P10/P25/P50 三档）
   - 生产率来源: [行业名称]，CSBMK®-202510
   - 基准城市费率: X.XX 万元/人月（[城市]，若未指定则默认 C 类均值 2.34 万元/人月）
   - 规模变更因子(SF): [若调用者指定了估算阶段，输出单个 SF 值]
     [若调用者未指定，输出两套报价如下]

   | 分位 | 生产率(人时/FP) | 工作量(人月) | 开发费用(万元, SF=X.XX) | 开发费用(万元, SF=1.00) |
   |------|:-------------:|:----------:|:---------------------:|:---------------------:|
   | P10  | X.XX          | XXX        | XXX                   | XXX                   |
   | P25  | X.XX          | XXX        | XXX                   | XXX                   |
   | P50  | X.XX          | XXX        | XXX                   | XXX                   |

   说明：
   - SF=X.XX：含规模变更因子（估算早期/中期/晚期），考虑了需求蔓延风险
   - SF=1.00：不含规模变更因子，纯生产率驱动，反映实际交付工作量的基准估算

四、结论
   - 总体评价: 合理 / 偏高可接受 / 明显偏高建议核减
   - 建议谈判区间: P25–P50（SF=1.00 口径: XXX–XXX 万元）
   - 方法精度提示: [根据方法给出精度说明]
   - 主要风险点:
   - 建议核减项及金额:

Step 6 · 输出最终审校报告（两份文件）

> 审校完成后必须生成以下两份文件，详见 references/output-templates.md。

6.1 文件一：问题明细 Excel（审校问题明细表.xlsx）

使用 Python（openpyxl）生成，包含两个工作表：

工作表 1「问题明细表」 — 逐项审校结果：

> 强制规则：必须逐条列出原始输入中的每一个功能点，按原顺序输出。审校通过的条目标记为"正确-确认正确"，同样占一行。禁止只输出有问题的条目，禁止跳过任何条目。

格式：严重行浅红底色、建议行浅黄底色、正确行浅绿底色。底部附汇总统计。

工作表 2「ILF_EIF_明细」 — 审校后确认的数据实体清单：

6.2 文件二：审校结论 Markdown（审校结论报告.md）

结构化 Markdown 报告，包含六个章节：

1. 审校概要 — 项目名称、审校日期、计数方法及精度、开发商 vs 审校后关键指标对比表
2. 问题分类统计 — 按严重等级汇总的问题数量（严重-非功能计数项 / 严重-类型错误 / 严重-表述错误 / 严重-非本系统 / 建议-表述不清 / 建议-类型存疑 / 建议-权重错误 / 正确-确认正确 / 重复项）
3. 核心问题详解 — 事务功能误标举例、非本系统内容、重复计数、非标权重
4. 审校后 ILF/EIF 清单 — 逐项数据实体、AFP、汇总
5. 报价区间评估 — 开发商报价推测 vs 审校后基准范围，必须输出 P10/P25/P50 三档（工作量、开发费用）。若调用者未指定城市，默认使用 C 类城市均值 2.34 万元/人月；若调用者未指定规模变更因子，同时输出含 SF 和不含 SF 两套报价
6. 结论与建议 — 总体评价（合理/偏高可接受/明显偏高）、P0/P1/P2 优先级措施表、方法精度提示

6.3 生成要点

• Excel 用 Python 脚本生成，Markdown 用 Write 工具写入
• 两份文件的数据必须一致，基于同一份审校结果
• 输出到项目目录（与用户提供的建设表同级）

边界情况处理

非功能需求

以下类型通常不计入功能点：
- 技术架构需求（如"支持分布式部署"、"采用微服务架构"）
- 纯非功能需求（如"响应时间<200ms"、"并发支持500用户"）
- UI/UX 美化需求（如"界面风格统一"）

这些应在报价的"其他费用"或工作量调整因子中体现。

敏捷迭代项目

• 按当前迭代范围计数，不要按"最终愿景"全量计数
• 注明"本期范围"，避免重复计费
• 重构工作量单独评估，不计入功能点

数据迁移

• 迁移程序的开发（EI/EO）→ 计入功能点
• 数据清洗/手工迁移 → 计入实施服务费，不计入功能点

COTS/平台二次开发

• 平台原生功能 → 不计入功能点
• 定制开发部分 → 按正常规则计数
• 配置工作 → 不计入功能点（除非配置逻辑复杂度达到开发级别）

资源文件

软件报价评估/
├── SKILL.md                        ← 你正在读
└── references/
    ├── function-point-rules.md     ← 详细 IFPUG 计数规则和边界判定
    ├── pricing-benchmarks.md       ← 中国软件行业生产率与报价基准数据
    └── output-templates.md         ← 审校输出文件规范（Excel + Markdown 模板）

三个 references 文件各司其职：
- function-point-rules.md — Step 1-2 执行时参考，包含 ILF/EIF/EI/EO/EQ 判定规则、DET/RET/FTR 计数规则、复杂度矩阵、边界场景速查（审计/日志/工作流/消息/文件/报表/批量处理）
- pricing-benchmarks.md — Step 5 执行时参考，包含 CSBMK 分行业生产率（人时/FP）、39 城人月费率（万元/人月）、规模变更因子、应用类型/开发平台/团队背景调整因子、质量基准、工作量分布
- output-templates.md — Step 6 执行时参考，包含 Excel（两个工作表列定义、样式规范）和 Markdown（六个章节结构）的详细模板

关键约束

> [注意] 以下约束适用于所有 Agent 产品，不限于 Claude Code。违反任一条均属设计错误。

强制规则

1. Step 0 不可跳过： 执行任何审校之前必须先让用户选择计数方法（指示/预估/详细），不允许跳过或自行假设方法。即使用户已提供完整数据，仍需先确认方法再开工。
2. 三种方法不可混淆： 不能对同一个项目混合使用不同方法的计数规则。例如：不能用指示法的固定权重（ILF=35）搭配详细法的复杂度判定（查 DET/RET 矩阵）。
3. Step 6 强制输出： 每次审校完成后必须生成两份文件——审校问题明细表.xlsx 和 审校结论报告.md，两份文件的数据必须一致。
4. CSBMK 数据完整性： pricing-benchmarks.md 中的所有生产率、人月费率、调整因子必须与 CSBMK 官方报告严格一致，禁止自行编造数值。
   - 生产率单位：人时/FP（不是人天/FP）
   - 人月费率单位：万元/人月（不是元/人天）
   - 数据版本号格式：CSBMK®-YYYYMM（如 CSBMK®-202510）
   - 每年 CSBMK 报告发布后（通常 10 月）需同步更新
5. UFP/AFP 单向下行约束： 审校后的 UFP 必须 ≤ 开发商原计 UFP，审校后的 AFP 必须 ≤ 开发商原记 AFP。审校只做减法（剔除无效项、纠正虚高），不做加法（不新增开发商标申报的功能点，不主动下调复用系数）。若出现审校后 > 原计，说明审校过程存在错误，必须回退核查。
6. 不得随意调整复用系数： 复用系数以开发商申报为准，审校方不做任何调整建议——不调高（不将"复用"改为"全新开发"），也不调低（不将"全新开发"改为"复用"）。复用判定依赖对开发商代码资产和历史项目的了解，审校方不具备此信息。唯一例外：同一功能点在不同位置出现矛盾的复用标注时，提示用户澄清。
7. 问题明细表必须逐条全覆盖： 审校问题明细表必须按原始输入顺序，逐条列出每一个功能点。审校通过的条目标记为"正确-确认正确"，同样占一行。禁止只输出有问题的条目，禁止跳过任何条目。 正确的条目也是审校结论的一部分，不能省略。
8. 问题描述穷举 + 严重条目排除： 每个条目的问题描述必须穷举所有发现的问题（类型错误、资格审查、表述不清、权重错误等逐一列出），禁止只写一条。审校等级为"严重"的条目（严重-非功能计数项/严重-类型错误/严重-表述错误/严重-非本系统），UFP 计为 0，不参与 UFP 和 AFP 的计算。"建议"等级条目保留原权重计算。

工作流设计原则

• 每个 Step 有明确的输入、输出和边界条件
• 三种方法的差异贯穿 Step 1-5，修改任一方法的行为时必须同步检查另两种方法是否受影响
• 对模糊场景给出"速查/口诀"式的快速判定标准
• 使用表格和清单格式便于逐项对照执行
• 标记 [严重][建议][正确] 表示严重程度，让审核结论可量化

联动修改提示

修改以下内容时必须同步检查关联文件：

语言约定

• SKILL.md 和所有 references 文档使用中文编写
• 技术术语保持英文大写：ILF、EIF、EI、EO、EQ、DET、RET、FTR、UFP、AFP、FP
• 代码/命令示例为中文注释 + 英文代码
• 审校结论标记：[严重] 必须修正 / [建议] 建议修正 / [正确] 确认正确

测试验证

Skill 没有自动化测试框架，按以下步骤手工验证：

1. 准备一个典型的功能点预期建设表（Excel 或 Markdown 表格）
2. 启动 Skill，验证 Step 0 是否强制要求选择方法（不能跳过）
3. 对三种方法分别测试：
   - ① 预估功能点法：验证是否仅审校 ILF/EIF、是否使用固定权重 35/15
   - ② 估算功能点法：验证是否默认中复杂度、是否正确处理调整项
   - ③ 详细功能点法：验证是否逐项检查 DET/RET/FTR 和复杂度矩阵
4. 边界情况测试：故意提供有问题的表格（虚高计数、类型错误、复杂度误判），验证审校能否检出
5. 输出验证：确认 审校问题明细表.xlsx 和 审校结论报告.md 两份文件均已生成，且数据一致

参考来源

• NESMA Function Point Analysis Guidelines（指示/预估/详细三种方法定义）
• IFPUG Counting Practices Manual (CPM) 4.3+
• GB/T 42449-2023《软件工程 功能点度量》
• SJ/T 11463-2013《软件研发成本度量规范》
• 中国软件基准数据库（CSBMK）年度报告
• 北京/上海/广州信息化项目造价审核指南