企业官网建设流程全解析

1. 先别急着回答"有没有意义"，这个提问背后藏着一个度量理念误区

1.1 提问者真正焦虑的是什么

前几天在项目经理的小圈子里，有个人抛出一句话："AI自动生成代码了，度量功能点还有意义吗？"

我当场就愣了一下。不是因为问题有多难，而是这个问题措辞背后透露的焦虑特别真实：他可能刚刚看见了某个AI编程助手一口气生成了几百行代码，或者团队里有人用AI半天写完了一个原本要开发一星期的模块。于是脑子里自然冒出来一个疑问——既然代码都能自动写了，那我还统计功能点干什么？统计出来又有什么用？

这种反应很能理解。大多数人对功能点的第一印象，往往停留在"软件规模度量"这个标签上，而做软件的人一想到规模，本能地就会往代码行数上靠。代码行数最近被AI冲击得不像样子，那功能点自然就跟着躺枪了。

但这里有个很关键的混淆：功能点度量从来不走"看代码"这条路线。它真正围着转的，是用户能够感知到的那个功能本身，它和代码是两码事。代码可以自动生成一百种写法，但"用户要一个登录功能"这个事实，并不会因为AI生成代码而变成另一个功能。

我那位朋友真正的焦虑，不是"功能点还有没有用"，而是"项目还怎么估算、验收指标还怎么定、我的度量体系会不会一夜作废"。这三件事，恰恰是功能点最擅长回答的。所以与其急着否定它，不如先把功能点到底度量了什么这件事掰开揉碎看明白。

1.2 代码生成改变的只是实现手段，不是功能意图

我经常用一句话来说明功能点的视角：同一套系统，用Java写还是用Python写，用SSH框架还是微服务架构，写十万行还是五万行，功能点都应该是同一个数。因为用户看到的、用到的东西没有变。

AI自动生成代码做的事情，落在"实现手段"这一层。你告诉AI：帮我写一个用户管理的增删改查接口。它给你生成Controller、Service、Mapper一大套。这在传统开发里可能占掉两三天工作量，现在可能只需要半小时。但你回头看看需求文档，需求依然是"用户能够新增、修改、删除、查询用户信息"这四条业务事务，一条都没少，一条都没多。

理解了这一点，答案就清晰了大半：功能点变化的前提是需求变化、业务规模变化，而不是实现代码的载体变化。AI再能写代码，它没有权利替业务方决定"这个功能到底做不做""审批流程要几步"。需求层面的确认、业务规则的澄清、验收口径的锁定，依然要靠人去完成，而这些恰恰是功能点计数时最重要的输入。

换句话说，AI把"实现阶段"的效率推高了，但"需求规模"这件事仍然客观存在。功能点在AI时代不但没有失去意义，反而因为实现成本变得极其廉价，需求本身变成了唯一真正稀缺的资源。度量需求规模的功能点，在未来只会更值钱，而不是更不值钱。

2. 重温功能点分析：它衡量的从来不是"写了多少代码"

2.1 五类基础组件决定了计算对象

要把这件事说透，还是得回到功能点方法最原始的设定。这套方法诞生于上个世纪七十年代末，当时在大型计算机制造商工作的工程师发现，软件开发的生产率用代码行衡量非常不靠谱：同样的功能，低级语言写得长，高级语言写得短，怎么比都不公平。于是他设计出一套不依赖代码、直接看"用户可得功能"的计数框架。

这套框架把系统拆成五类东西来数：内部逻辑文件（ILF）、外部接口文件（EIF）、外部输入（EI）、外部输出（EO）、外部查询（EQ）。听起来很术语化，其实就是回答五个问题：系统内部要维护哪些数据？系统要引用外面哪些数据？用户往系统里输入了什么？系统给用户输出了什么，里面带没带加工逻辑？用户是不是只是查一下数据，没有触发任何计算？

举个例子。一个订单系统，"新增订单"是一个外部输入，"导出月度销售报表"是一个外部输出，因为它要对数据做了汇总计算，而"查询订单详情"如果只是原样把数据拿出来显示，就是外部查询。"客户数据存在系统里并持续维护"就对应一个内部逻辑文件，而"对接外部快递运费接口"则对应一个外部接口文件。

这五类组件都有各自的权重点数，加总之后乘以一个技术调整因子，就得到标准的功能点数量。整个过程从头到尾没看一眼代码。代码生成器输出十行还是一千行，对这个数字毫无影响。

2.2 调整因子这个争议源，反而揭示了度量的本质

讲到技术调整因子，很多实际做功能点的人都会有同感：这一块是争议最多的。它的本意是把系统的技术复杂度也考虑进去，比如系统涉及分布式数据处理、高并发、复杂性能要求，就加一点分，让最后的功能点数更能反映开发难度。

但正因为引入了这个主观调整项，功能点变得可以被操纵。同样一个登录功能，你在技术特性表里把性能项打高一点，分数就上去了。有人说它是功能点方法最鸡肋的部分，甚至很多团队干脆只用"未调整功能点"，也就是光数五类组件那一部分，不碰调整因子。

这个争议恰恰说明了一件事：功能点真正稳定、可信的部分，是它以业务功能规模为核心的原始计数；而需要人为判断的地方越少，度量就越客观。AI时代更是如此。代码生成速度再快，也不能替你去定义"这个查询算EQ还是EO"，更不能替你决定"这个文件是ILF还是EIF"。这些判断依赖的是对需求的理解，而不是编码能力。

所以我的结论是：功能点不是一套完美无缺的度量工具，它有关卡、有争议、有统计误差，但它的度量对象是需求功能，这一点在AI出现后没有变。变的是"实现同样功能所需投入的编码劳动"，这是另一个维度的问题。

3. AI代码生成真正会冲击的，是那些依赖代码行的度量指标

3.1 千行代码和功能点：一对天然不可比的指标

AI普及之后，最不值钱的指标是什么？我第一个投票给"千行代码"。

理由很简单。传统开发里，代码行数和开发工作量勉强算正相关：写得越多，说明你干得越久。可AI不一样，它可以在你输入一句话之后，输出一堆防御性逻辑、异常处理、注释模板，也可能因为你的框架封装得比较好，输出极简的几行调用。这两种情况下代码行数差好几倍，但功能一样。

甚至团队内部会出现一种诡异的局面：一个老手用AI生成了三百行代码，一个新手用AI生成了一千行代码，俩人实现同一个功能。按照行数统计，新手反而显得更有生产力。这不叫度量，这叫失真。

功能点从一开始就和代码行数是完全不同的物种。它不看产出多少行，只看产出了多少"用户功能"。同一个登录功能，AI生成一万行和生成一百行，在功能点上都是同样的外部输入，计数一致。这种对实现方式的无敏感性，让功能点成了少数几个在AI冲击下仍然可以跨项目、跨时间比较的指标。

我见过一些团队用行数来衡量AI的提效幅度，结果报告上写得天花乱坠，仔细一看全是空行和注释，完全无法复现。后来改成功能点对比，同规模功能模块在AI辅助前后的生产函数变化，才终于能对上账。

3.2 AI让代码量失真，"人月生产率"该如何重新解读

大家常说的"人均功能点/月""功能点/人月"，这个生产率的分子是功能点，分母是人月。AI对这两个部分的影响方向完全不同。

分子端，功能点几乎不受影响，因为需求规模不会因为AI出现就自动缩水。分母端，人月受到的影响就大了：实现阶段的工作量被显著压缩，过去一个功能点可能需要一整个开发日，现在可能只需要几小时。于是"功能点/人月"这个数值会被AI拉得很高。团队里的指标曲线突然变得很漂亮，但这并不代表团队突然变成了超级团队，只是说明编码环节的产能上限被抬高了。

问题是，项目的总工作量从来不只是编码。需求梳理、原型确认、测试用例设计、跨系统联调、上线运维，这些环节AI目前只能部分辅助，仍然需要人来盯。很多团队看到编码快了，就以为整个项目能快多少倍，排期一压缩，最后在需求澄清和测试阶段爆雷。这种偏差在传统人月估算时期就有，AI只是让它更明显。

所以重新解读生产率时，我建议把功能点生产率拆开看：编码阶段的生产率、测试阶段的生产率、需求阶段的生产率，分别度量。AI真正提升的是编码阶段的部分，如果你笼统地用一个总分去衡量，等于把所有功劳都归给了AI，反而掩盖了需求阶段仍然存在的瓶颈，下次启动项目时排期自然又要翻车。

4. 我实际验证过的三种功能点落地场景，在AI时代照样可行

4.1 外包结算：把功能点写进合同能防住AI加料

我参与过的某跨平台系统项目，当初和外包团队谈的就是按功能点结算。合同里约定，每个功能点单价固定，根据需求规格说明书计数出的功能点总量来算总价。那时候为了磨合这个条款，双方开了好几轮会，核心争议都在口径上：什么算一个功能点，需求变了怎么追加费用。

AI出现之后，外包团队反而高兴了，因为编码成本大幅下降，同一个功能点到手的工作量低了很多，利润率上去了。但发包方也不傻，他们第一件事就是问：能不能把条款改成按代码行结算？幸好当时的合同还是按功能点签的，不然这一波真的会被AI撑爆。你想，如果按行数算，外包方完全可以让AI生成大量冗余代码来赚外快，审计起来还特别困难，因为每一行看着都像是有用的。

按功能点结算就稳得多。功能点锚定的是需求规格，需求没变，功能点数就不会变，外包方多生成几千行代码也拿不到更多钱。项目进行中需求必须要变更，那就走变更流程，先补需求，再补功能点计数，最后补费用。这套在AI时代反而是更坚固的合同设计，因为代码行数已经完全不能代表工作量了。

4.2 需求蔓延控制：原型生成变快后，功能点成了刹车片

还有一个我印象很深的场景。某模拟项目X做内部管理系统，早期业务方在原型阶段特别兴奋，因为AI辅助下界面和交互原型几乎是实时生成，今天看一个样，明天又改一版，呈现出"什么都能加"的错觉。于是需求像滚雪球一样膨胀，开发团队苦不堪言，工期一拖再拖。

后来我建议把功能点计数当成需求变更的刹车片。每轮业务方提出新需求，先不急着让开发做，而是由BA把需求翻译成功能点增量：涉及新建哪些ILF，增加哪些EI，哪些EO，然后报一个预估的功能点增量。业务方一看增量太大、预算消耗太快，就开始自己学会取舍了。

这个过程很有意思。AI让原型的物理构建成本逼近于零，业务方的心理预期就跟着膨胀，以为真实开发也这么便宜。功能点在这个时候发挥作用，本质上是在提醒大家：原型可以秒出，但业务规则能不能闭环、数据要不要存储、关联系统要不要改动，这些问题带来的复杂度并没有消失。功能点成了需求方和开发方之间讲"真实成本"的共同语言。

4.3 内部基准校准：用功能点测算AI带来的真实提效幅度

最后一个场景是关于团队自己的。我们曾需要向管理层汇报AI工具落地后的提效情况，当时最怕的就是拍脑袋说"提升了百分之三十"这种话。为了给结论找支撑，我们把过去半年与AI结合开发的功能模块全部补做了功能点计数，和未采用AI的同期历史模块做对比。

做法其实不复杂：先把每个功能模块按五类组件基数计数，算出未调整功能点，再统计实际投入的人日，计算出人均功能点/人日。半年下来数据比较有说服力——那些规则清晰、接口简单的CRUD型功能，提效非常显著，人均产出翻了一倍都不止；而涉及复杂业务规则、大量状态流转的功能，提效幅度小得多，因为大量时间耗在需求确认和逻辑校正上，编码反而不是瓶颈。

这套内部基准库的妙处在于，它把"AI提效多少"从玄学变成了可追踪的指标。新功能上线前，用功能点预估规模和难度，再参照基准库里的分场景生产率数据，排期就比过去准得多。而且基准库会随着AI工具的迭代持续刷新，每一个新的功能点都在校准这个团队的"新常态生产率"。

5. 面向AI辅助开发的功能点计数实操要点

5.1 把需求拆成可计数的最小业务事务

AI辅助开发的最大特点是"需求到原型的距离极短"，这意味着功能点计数的第一步必须前置到需求描述阶段，别等代码落地了才去补数。实际操作中，我习惯把需求描述改造成一种可以被直接翻译成功能点的事务清单：每个用户故事拆成"动作+数据对象+业务规则"三件套。

举个例子。"用户通过手机号注册"就是一个外部输入，触发条件是用户提交手机号和验证码，数据对象是用户账号，业务规则包括手机号格式校验、验证码有效期检查、重复注册拦截。把这个写清楚，计数的人一眼就能判断这是EI，数据存进内部逻辑文件，对应一个ILF。要是需求里加了一句"注册成功后给用户发送欢迎短信"，那就多了一个外部输出，因为它是系统对外发出的、带业务规则的输出。

这个拆法的好处是，AI在编码时也喜欢这种结构化的描述，它生成代码的成功率和正确率都比直接扔一段口语化需求高得多。功能点结构化和AI提示词工程在这里意外地同频了。很多团队在推AI开发的时候抱怨效果不稳定，我推荐先检查一下需求描述是不是足够结构化，如果需求本身就是一团浆糊，那无论是人写代码还是AI写代码，结果都是灾难。

5.2 计数时点与双人复核机制

功能点计数最怕两件事：太早和太晚。太早，需求还在频繁变动，你数的每个功能点都是空中楼阁；太晚，代码已经写完了，计数变成事后统计，失去预估意义。我目前采用的时间点有两个：需求基线冻结时做一次基准计数，每个迭代结束前做一次增量校正。

基准计数的作用是锁住项目启动时的规模基线，用来回答"这个项目大概多少功能点，预算够不够"。增量校正的作用是记录需求变更带来的功能点漂移，用来控制范围蔓延。两次计数之间，凡是发生需求变更，都要走单独的变更计数流程，避免所有变更堆到最后一次性处理。

复核机制方面，我强烈建议双人独立计数。找两个熟悉功能点方法的人背靠背数同一份需求文档，然后对比结果。如果两个人的未调整功能点差异超过百分之十，就拉上需求负责人一起讨论争议点。这个机制听起来慢，实际执行下来非常省事，因为大部分需求并不复杂，争议集中在少数几个边界模糊的对象上，把那一两个点对清楚，整体计数就成立了。

5.3 三个高发计数争议的处理经验

做功能点计数必然碰到一堆模棱两可的案例，AI时代这些争议只会更多，因为AI生成代码时根本不会关心你的计数口径。这里分享三个我经常遇到的争议类型。

第一个是报表类的EO和EQ之争。判断标准其实很固定：输出数据是不是经过加工、计算、汇总的。如果有按时间聚合的累计值、有同比环比，那就是外部输出，权重重，因为逻辑更重。如果只是按筛选条件把明细数据原样列出来，没有任何派生运算，那就是外部查询，权重轻。AI项目里这个判断尤其重要，因为AI特别擅长把简单查询写得很花哨，很容易诱导你提高权重。

第二个是CRUD操作的拆分问题。一个"用户管理"页面同时提供增、删、改、查，到底算几个功能点？正确的做法是看业务事务的独立性。每次新增要校验手机号唯一性，每次删除要检查是否有关联订单，这些如果都是独立触发的业务操作，就应该拆成一个EI、一个EO、一个EQ来分别计数。不要把整个实体当成一个功能点，否则规模的区分度就没了。

第三个是外部接口文件与外部输入的区别。对接第三方系统，比如外部登录、外部支付，如果系统只是引用外部系统的数据（比如拿钉钉用户ID来识别身份），对应的就是外部接口文件和一个外部输入。但如果外部接口返回的数据还需要本地进一步加工、存储，那就涉及到内部逻辑文件的增加，计数就要叠加。这个争议的根源在于很多人分不清"数据是别人维护还是自己维护"，抓住这个根本，争议基本能平息。

6. 如果功能点也会退化，我们还能度量什么

6.1 规模度量的本质是找到一个需求锚点

把功能点放到AI时代这个大背景去审视，我最大的体会是：功能点退不退化的关键，不在于它精确不精确，也不在于它是不是官方标准，而在于它能不能继续充当"需求锚点"。

什么叫做需求锚点？就是一个需求对象在变成代码之前，先有一个稳定、可比较、可讨论的尺寸编号。业务方说"我要增加一个审核功能"，开发方一听就知道里面大概有几个EI、一个EO、对应ILF变更，对工作量有初步感觉，对排期有共同认知。这个编号不依赖任何具体的代码实现，因此AI把代码层搅得天翻地覆，它依然能立在需求层提供参照坐标。

更值得注意的是，一个项目里除了功能点这种"规模锚点"，还有工时、成本、质量这些维度。AI看起来把工时维度打乱了，让原来靠经验估计的工作量不再可靠，但这恰恰意味着一个更稳定的规模锚点变得更加重要。你只有先知道"这个模块有20个功能点"，才能在AI生成代码后回头验证"哦原来这个规模原本需要两周，现在只用四天"，从而动态校准团队的产能基线。

如果有一天功能点真的退化了，那也一定是因为出现了更好的需求锚点，比如更贴近业务流程对象的数据流图谱，或者能够直接度量业务规则复杂度的规则点数。但无论换成什么，它锚定的都仍然是需求规模，而不是代码实现，这一点不会变。

6.2 未来更可能的度量组合形态

关于度量体系接下来会长成什么样，我不打算画大饼，只说几种我看到的真实倾向。

一是"功能点+数据对象复杂度"的组合。AI能快速生成CRUD代码，但数据关系复杂时仍然会翻车。把数据对象之间的关联基数、继承层次、状态流转复杂度也纳入规模度量，会比单纯的功能点更有解释力，尤其适合中后台系统。

二是"功能点+业务规则数"的组合。一个功能处理多少条业务规则，决定它的真实难度。功能点可以覆盖"有多少个功能"，但覆盖不了"每个功能里藏了多少条规则"。AI时代编码边际成本趋近于零，业务规则识别、形式化表达的成本却越来越高，把规则数纳入度量维度，比单看功能点更能反映实际工作量。

三是"规模点+资产复用度"的组合。AI生成的代码越来越像内部公共资产库的一个组合过程，功能点衡量的是"用户侧看得见的功能产出"，但一个团队如果复用了大量已有模块，性能产出和成本投入会明显优于从零开发。把复用度作为调节因子，能让度量更贴近真实工程效率。

不管哪种组合，核心逻辑都没变：度量的对象应该是需求与业务复杂度，而非代码产量。只要人还要为软件付费、还要评估软件项目的投入产出，这个逻辑就不会过时，功能点作为最具共识的需求锚点，也就还有它自己的位置。

我在自己带的项目里，现在依然会做功能点计数，只是它不再单独存在，而是和规则清单、数据关系复杂度放一起看。AI到底有没有帮这个团队提效，不再靠感觉，而是看同样的功能点数下面人日和缺陷数怎么变化。这个组合用了两个迭代之后，排期估算的偏差率从百分之三十往下降了不少。对我来说，这就是功能点在AI时代最好的存在方式——它退到后台，却仍然是那根让所有估算不至于跑偏的锚链。