AI自动生成代码后，功能点度量如何调整与落地？

1. 当AI开始写代码，功能点度量到底慌不慌？

1.1 一个让我重新思考度量体系的具体场景

AI自动生成代码这件事，现在基本不用争论“能不能”，团队里真正的问题是：既然代码都是AI写的，我们每个月还在数功能点，这数字还有意义吗？

这个疑问不是我臆想出来的。上个月团队做迭代复盘，后端负责人晒出一组数据：同一个需求，过去要两三个人写三天，现在让AI生成接口和业务逻辑，半天就出来了。但端到端交付时间只缩短了20%，剩下的大量时间花在联调、修边界条件、给AI补提示词上。更有意思的是，我们原先用“代码行数/人天”和“功能点/人天”两个指标看研发产能，AI介入后，代码行数暴涨，功能点却几乎没变。于是有同事提出：干脆别度量功能点了，直接看AI生成了多少代码不就行了？

我当时的反应是：千万别。代码行数是“生产材料消耗量”，功能点才是“交付了多少业务能力”。AI把生产材料的价格打下来了，不代表我们不需要知道项目到底交付了什么。这篇文章我就把自己这段时间的踩坑和思考完整写出来，希望能给同样在调整研发度量的团队一些参考。

1.2 功能点度量的本质：数的是“价值”，不是“代码”

很多人一听到功能点，第一反应是“国际功能点用户组的那套复杂规则”。确实，IFPUG、NESMA、COSMIC这些标准各有各的计数方法，但核心思想是一致的：从用户视角，按“能感知到的业务功能”来衡量软件规模，不看用了多少行代码、什么编程语言、什么框架。

举个生活化的例子。一家餐厅要评估自己的经营规模，可以看“每天采购多少斤食材”，也可以看“菜单上有多少道菜”。AI自动生成代码相当于把后厨改造成了自动化流水线，食材消耗量（代码行）变得又便宜又快速，但客人能点的菜式数量（功能点）并不会因为后厨自动化而凭空增加。功能点度量的是后者——用户能使用的功能数量，是业务层面的规模尺度。

所以我一直认为，功能点度量最大的优势就是“技术无关性”。它天然屏蔽了实现方式的干扰，AI把代码写得再快、再多，也不影响你数用户故事、业务对象、事务操作。这个特性在AI时代不仅没过时，反而变得更加珍贵，因为它帮我们守住了一个稳定可比的度量口径。

1.3 AI为何让代码行数彻底失效

在传统开发里，代码行数和功能点之间有一定的相关性，虽然不精确，但至少可以粗略参考。AI自动生成代码以后，代码行数彻底失真了。

失真来自三个维度。第一是“膨胀效应”，AI很擅长生成样板代码、冗余函数、重复的判空逻辑，一个功能可能生成比人写多一倍的代码；第二是“压缩效应”，AI又可以把复杂的业务逻辑浓缩成很短的调用链，甚至用一两个高级API搞定，行数反而比人写的少；第三是“噪声效应”，如果让AI生成测试、脚本、配置、文档，这些代码根本不属于用户功能，却会被计入总行数。

用代码行数衡量AI时代的研发产能，就像用“厨师切了多少刀”来衡量一家餐厅交付了多少菜品，AI厨师的刀法又快又乱，切一万刀可能只出一道菜，也可能一道菜没用上。功能点度量不看刀法，只看端上桌的菜。

2. AI生成代码对功能点度量的真实冲击

2.1 需求拆解被AI影响，功能点边界变模糊了

虽说功能点度量的基本原理没变，但AI自动生成代码确实给实际操作带来了新冲击，最明显的就是功能点边界变得模糊了。

过去，需求由产品经理撰写，边界相对人工可控，一个“用户查询订单”通常清晰对应一个外部查询或外部输出。现在很多团队开始用AI辅助生成需求描述、用户故事、验收标准，AI写出来的需求颗粒度不一致——有时候一个功能被拆成三十条细碎的验收点，有时候一段话洋洋洒洒把三个独立功能混在一起。需求边界一模糊，功能点计数的一致性就受影响，两个人看同一份AI生成的需求，可能数出完全不同的功能点数量。

更麻烦的是，AI自动生成代码时，往往会在实现层面自作主张增加“隐藏功能”。比如一个“上传文件”功能，AI顺手加上了格式校验、大小限制、进度条、文件预览，这些确实是用户可感知的能力，但需求文档里根本没写。按严格的功能点规则，这些算不算外部输出或外部查询？如果算，功能点数量会随AI的“发挥”而波动；如果不算，又觉得度量结果漏掉了真实交付。

我的处理思路是：以评审通过后的需求基线为准。AI生成的需求草稿和代码实现都只能作为辅助线索，功能点计数必须基于“产品与开发共同确认的需求范围”，不能跟着AI的临场发挥跑。

2.2 AI辅助需求拆解：从“人肉梳理”到“半自动拆分”

既然AI已经参与了需求生成，我们不妨顺势把功能点度量的前置工作也交给AI，但要做成“半自动”而不是“全自动”。

我现在的做法是，拿到一份需求描述后，先让大模型按功能点的基本规则做初步拆分，输出候选功能点清单。提示词大概是这样的：

请把下面的需求拆分为“用户可感知”的功能点，每个功能点说明用户角色、触发动作、期望结果，区分外部输入、外部输出、外部查询、内部逻辑文件，不要包含技术实现细节。

这个步骤能在几分钟内产出一份功能点草稿，效率比以前人工开会梳理高很多。但别急着把草稿当作最终结果，AI经常把“后端数据加密”当成内部逻辑文件，把“调用第三方接口”误认为外部输出，这些都需要人工复核。

我建议至少安排一名熟悉业务的人做终审，而且终审人最好是需求文档的作者或产品经理。AI负责把大部分机械归类工作做掉，人把判断力和业务上下文补上。这种“AI生成初稿+人工终审”的方式，才是当前阶段功能点度量最稳的落地路径。

2.3 生产率计算基准要重新校准

很多团队过去用“功能点/人天”来标定研发生产率，AI自动生成代码以后，这个公式必须重新校准，否则会得出一个虚高的数字，误导管理层做决策。

原因很简单：传统场景里，写代码是占比最大的工作量来源；AI介入后，纯编码成本大幅下降，但需求澄清、联调、测试、环境配置、缺陷修复、AI提示词调试这些环节的成本被顶了上来。如果你用“总功能点 / 纯编码时间”计算生产率，数字会吓人，但它反映的不是真实效率，因为编码只是整个交付链路上的一环。

我把公式改成“功能点 / 端到端交付时间（从需求确认到上线验收）”，并且要求时间记录里明确标注AI辅助的环节占比。这样算出来的生产率虽然比过去低，但更接近真实情况，也更容易看出瓶颈到底在哪里。比如有一次我们测出来某个迭代的生产率下降了，深挖发现是环境申请耗时比编码时间还长，功能点度量反而帮我们揪出了新瓶颈。

3. 我在实践里保留功能点度量的四种打法

3.1 把功能点作为“需求交付价值”的锚点，而不是人肉核算成本的工具

面对AI自动生成代码的冲击，我做的第一个调整不是换度量指标，而是重新给功能点定位。以前团队把功能点当作“估算人力成本”的输入，签合同、排工时都靠它。但AI让编码成本变得极不稳定，同一个功能点，提示词优化前后可能差出三倍工作量，再用它去精确估人天，必然失灵。

我现在把功能点当作“需求交付价值”的锚点，用来回答三个问题：这个迭代交付了多少类业务能力？需求范围是否被随意扩张？不同团队之间交付的规模有没有可比性？

定位变了之后，功能点不再是算钱的尺子，而是对齐需求和业务价值的参照系。这也符合AI时代敏捷管理的主流思路：与其纠结一个功能点成本多少，不如关心每一份功能点对应的业务结果是否达成。

3.2 用AI协助识别和归类功能点事务

第二个打法是让度量本身也享受AI红利，尤其是在识别和归类功能点事务时，不再靠人工逐条翻阅需求文档。

具体操作分为三步。第一步，把需求文档、用户故事、验收标准喂给大模型，让它提取候选功能点，并标注每条候选功能点属于EI（外部输入）、EO（外部输出）、EQ（外部查询）还是ILF/EIF（内部逻辑文件/外部接口文件）。第二步，让AI把候选功能点映射到业务模块，并给出可能重复的提示。第三步，人工对照原始需求做终审，重点检查被AI遗漏的隐含功能和被AI夸大的技术性功能。

这套流程我跑了两个月，最大的好处是效率提升明显，一个两百多页的需求文档，过去人工清点要两天，现在半天能完成初筛。但要提醒一句，AI对功能点规则的把握远不如专业人员稳定，尤其在边界判断上，所以终审环节不能省。我们团队配了一个熟悉IFPUG规则的研发作为“度量守门人”，效果比完全依赖AI好得多。

3.3 让度量数据反哺AI提示词和代码审查

度量功能点不应该只是算完就躺在表格里，我希望它反过来指导AI更好地写代码。这是我最近特别看重的一个方向，也是功能点度量在AI时代的新价值。

具体场景是这样的：我们把一段项目里的历史代码和对应的功能点数据喂给AI编程工具，让它学习“某个功能点类型通常涉及哪些用户场景、边界条件、异常处理”，然后让AI生成代码时参考这些上下文。结果发现，AI生成的代码在未登录、权限不足、参数异常等边界情况上的处理明显更完整，因为这些都被关联到了具体功能点的验收标准里。

另一个更简单的用法是：根据功能点缺陷率排序，把缺陷率高发功能点对应的代码块列为代码审查的优先对象。比如我们发现“外部输入类”功能点最容易出现SQL注入和数据校验漏洞，就告诉AI在生成这类代码时必须包含参数化查询和强校验逻辑。这样度量数据不再只是事后统计，而是变成了改进AI生成质量的前置输入。

3.4 建立“AI辅助生产率”的动态基线

AI的能力每隔几个月就会上一个台阶，所以基于静态基准的生产率指标注定很快失效。我提出一个“动态基线”的方式，核心思路是：不追求一个永恒不变的正常值，而是一次又一次地刷新当前AI辅助下的基准值，用于观察趋势。

实施起来很简单，每次迭代或每月统计一次功能点交付速率，并记录四个关键变量：AI工具版本、提示词模板版本、需求复杂度评估、团队对AI工具的熟练度。当这几个变量变化时，基线就应当随之重新设定。比如我们首次统计时“功能点/人天”是1.8，后来换了更强的AI模型并更新了提示词模板，第二次统计跳到2.4，但这不一定代表团队效率提升，因为需求复杂度可能变低了。只有把变量记录下来，才能做出靠谱的解读。

动态基线的价值不在数字本身，而在它逼着团队持续追问：最近的变化是因为AI变强了，还是因为我们在度量规则上偷偷放水了？只要这个问题还在被认真讨论，度量体系就是健康的。

4. 实操中会遇到哪些坑？我的排查经验

4.1 边界不清：AI生成的CRUD逻辑算几个功能点？

AI自动生成代码最常见的就是CRUD——增删改查。很多初学功能点度量的同事会犯一个典型错误：用户故事写着“管理用户”，AI一顿操作生成了列表页、新增页、编辑页、删除确认弹窗、接口和数据库表，结果拍脑袋说“这不就是一个功能点吗？”

严格按IFPUG规则，“管理用户”至少包含四个不同的外部事务：创建用户（外部输入）、修改用户（外部输入）、删除用户（外部输入）、查询用户列表（外部查询或外部输出）。更精细地说，修改和删除还可能涉及不同的数据元素和校验逻辑，需要根据实际交互进一步拆分。AI把它一次性生成出来，恰恰说明它“省事”地把多个用户可感知功能打包了，功能点计数不能跟着打包走。

我的建议是给团队做一张“最小可计数事务”对照表，遇到AI生成的代码模块，先问一句：用户是否能在界面上发起一个独立操作并收到单独结果？如果能，就对应一个独立功能点。这样基本能把边界纠纷压到最低。

4.2 重复计数：一个功能被AI拆成多个小任务

AI编程工具有一个习惯——为了生成代码方便，会拆出大量服务层方法、工具函数、数据模型类。如果度量人员不坚定“用户视角”，很容易把同一个业务能力重复计数。

我给团队定过一条硬规则：AI生成的内部代码模块、方法、中间对象，一律不作为功能点计数的依据。即便AI生成了三十个Java类，只要它们共同支撑“用户查询订单”这一个界面操作，功能点仍然只算一个“外部查询”。否则就会出现功能点数量被AI内部设计结构带偏的荒唐结果。

为了避免重复计数，我让团队维护了一份“功能点清单字典”，每个功能点对应一个用户场景和验收条件，编号唯一。新增的功能点必须能在需求文档里找到明确依据，AI拆出来的那些任务一律归入内部设计，不进度量台账。实践证明，这份字典是防止AI时代度量失真最有效的防火墙。

4.3 质量维度：AI代码的功能点达标了，但缺陷也在同步增长

有一次迭代结束，功能点数量统计得很漂亮，比上期增长了不少，但业务方反馈问题不断。后来一查，才发现是我们对AI生成的代码过度信任，功能点一个不少，但代码里的并发问题、状态判断逻辑错误成倍增长。这说明一个道理：功能点度量只管“有没有交付”，不管“交付得好不好”。

所以我特别强调，在AI生成代码的背景下，功能点必须和质量指标搭配使用，单独看功能点一定会被骗。我在看板里固定展示以下一组指标，供大家参考：

这套组合拳的关键是，功能点是分母，质量跟效率都在它身上做文章。这样既保留了功能点度量的框架，又不会被AI生成的“高质量代码幻觉”带偏。

4.4 别让功能点成为KPI，否则AI也会“刷功能点”

最后一个坑是管理学层面的，我踩过一次之后引以为戒。有一段时间，管理层看到AI生成代码效率高，就把功能点数量和团队绩效挂钩。结果很快发现，团队开始引导AI“制造”功能点——把原本一个完整的操作硬拆成多个弹窗和确认步骤，或者在需求评审时有意增加无关紧要的交互逻辑，目的就是让数字好看。

这就是古德哈特定律的经典案例：当某个度量指标变成目标时，它就不再是一个好的度量指标。功能点本身没有问题，问题在于不该把它当作终极奖惩依据。功能点度量应该服务于范围控制、产能规划和趋势分析，而不是给个人或团队下硬性指标。

我的止损方案是：功能点数据只能用于团队级的回顾和改进，不进入个人绩效考核；同时每个季度抽三到五个功能点做人工复核，发现造假直接重算该迭代的全部数据。这一条建议强烈建议大家抄作业，不然AI自动生成代码的便利，反过来会把度量体系玩坏。

5. 我的结论：度量功能点依然有意义，但度量方式必须变

5.1 功能点度量并未过时，过时的是“手工清点”的度量方式

绕了一大圈，回到最初的问题：AI自动生成代码了，度量功能点还有意义吗？我的答案很明确：有，而且从某些角度看比过去更重要。

AI越强大，“代码实现”和“业务价值”之间的差距就越大。如果只看代码，你根本分辨不出哪些是用户真正需要的功能，哪些是AI为了完成任务顺手生成的技术细节。功能点度量始终站在用户可感知的维度上，它不会因为AI写代码的速度加快而失效，反而成了喧嚣的代码海洋里一个相对稳定的“业务能力坐标”。

过时的东西只有一个，就是过去那套“人工清点、手工填报、月度统计”的运作方式。AI时代的功能点度量必须借助AI来自动初筛、动态校准，从“手工盘点”升级为“人机协同度量”。这也是我在团队里力推的方向：让AI帮我们数功能，让人来把关业务判断。

5.2 给团队落地的三条可执行建议

如果你们的团队也在AI自动生成代码和功能点度量之间感到迷茫，我最后给出三条可以直接上手的建议。

第一，把功能点统计频率从月度改为迭代快照。AI交付节奏太快，月度数据往往滞后且难以定位问题，迭代结束当天统计功能点，配合该迭代的质量和效率数据，问题定位准确很多。

第二，建立“AI初筛+人工终审”的双人复核机制。每次迭代挑出数量较多的三到五个功能点，由两个不同角色分别人工复核，核对功能点是否都能对应到真实用户场景。成本不高，但能有效防止AI辅助度量时最常出现的边界漂移和重复计数。

第三，把功能点数据接进研发效能看板，和缺陷率、交付周期、业务指标放在一起展示。功能点不是孤立的数字，只有在和其他维度联动时才能发挥度量价值。离开了上下文的发挥，无论功能点还是代码行数，都是自欺欺人的游戏。

最后再分享一点我的切身体会：真正让你觉得功能点失去意义的，往往不是AI太强，而是你的度量体系太久没有升级。把度量当作需要持续迭代的产品来经营，AI就不是威胁，而是帮你把度量做得比以往任何时候都精确的杠杆。