今天讲讲我们是怎么评估工作量的。
这事干过外包项目的都知道，是个老大难。评估多了，超出客户预期太多，会导致客户对我们公司的技术不信任。评估少了，原本承诺的上线日期达不成，同样会给客户的信任带来极大的损伤。
为什么会这样？根子在传统评估模式本身。评估人的经验不同，对功能点的复杂度判断就不同。同样一个"开发一个表单"的需求，新手估3天，老手估1天，到底信谁的？跨部门协作的时候，各方对工作量的理解都不在一个频道上。
这个问题困扰我们很久。后来想明白了，与其每次靠经验猜，不如让AI学我们的判断。我们根据自己的业务、产品代码库和历史项目经验，做了一套专门用于评估需求工作量的智能体。下面看一下它实际跑起来是什么样子。
第一步：上传PRD，智能体先做前提检查
图1
截图说明：PRD工时评估界面。客户上传了EAI外包需求确认-0506.md文档，智能体完成PRD解析后进入前提检查环节——问"开始评估前还需要确认以下必要前提：1、外采API的鉴权、签名、公钥、错误码……是否完整？"
这一步有两个动作很关键。Agent没有急着直接评估工时，先做了一步前提检查——文档里的字段是不是缺失、流程描述是不是清楚、有没有需要业务方先确认的口径。这一步相当于让Agent扮演产品经理的角色，先把需求吃透了再动手。
第二步：创建分析任务，拉取代码库
图2
截图说明：智能体创建了分析任务 ana_1786086570996_317e2a，正在按 gx-dev-plan 规则抽取平台、入口、字段和候选仓库，进入分析阶段。
前提检查通过后，Agent 创建一个分析任务，开始分析需求类型和源码范围。它会按照我们预设的规则（gx-dev-plan），抽取相关的平台模块、入口点、字段定义和候选代码仓。
为什么要做这一步？因为工作量评估的准确性，很大程度上取决于对代码现状的理解。光看PRD不看代码，估出来的一定是"理想人天"，不是"实际人天"。这一步也是Agent最值钱的地方。它能直接扫代码库，知道哪些模块已经有现成组件、哪些功能要新建、哪些是要改老逻辑的。这些信息光靠人力去翻，半天都不一定翻得完。
第三步：逐个功能拆解
这一步是重头戏，Agent对每个功能点单独做详细评估。这次需求里有3个功能。
功能1：凭证预览——从商品配置到单据iframe
截图说明：凭证预览链路图。从商品配置（Tab名最多4字、http/https地址、1组自定义参数）→ 模板与权限（按单据模板开启、人员/部门/角色、仅PC端展示）→ 单据预览（后端生成URL、动态Tab名称、iframe加载）。下方列出了源码依据（FlowVoucherPreviewResource 已校验）、拼接参数（corpid + datatype + fkey=DocCode + fvalue + staffId + customParam）和验收底线（失败不阻断单据主流程、禁止 javascript: 协议、iframe 响应头允许被嵌入）。预估7.0人天。
链路是商品配置→模板与权限→单据预览。Agent 给出7.0人天的评估。还列出了源码依据：FlowVoucherPreviewResource 校验 power、模板、可见范围并编码参数；Web 已有动态 Tab 与 iframe 组件。最有价值的是"验收底线"那栏。Agent 标出3条红线：失败不阻断单据主流程、禁止 javascript: 等危险协议、iframe 响应头允许被嵌入。这些都是我们工程师踩过的坑，提前列出来能省很多沟通成本。
功能2：EAI 私有化——去掉后端换 ticket
图3
截图说明：EAI 私有化改造图。现有链路：Web 请求 /extension/eaiweb，后端调用EAI 授权接口获取 ticket 后再返回，私有化网络下调用失败。目标链路：后端读取管理员配置地址，拼企业ID与员工ID，返回浏览器可访问URL，Web 新页签直接打开。下方给出了"配置→拼链→打开"的三步路径，并定位到当前代码证据 EAIWebConfigServiceImpl 仍向 /activity/ADM04003B POST 换 ticket，这一段正是必须替换的旧逻辑。预估2.0人天。
这个功能是私有化环境改造。改造重点是把跳转责任从后端拿回到浏览器。Agent 对比了现有链路和目标链路，还定位到了当前代码证据：EAIWebConfigServiceImpl 仍向 /activity/ADM04003B POST 换 ticket——这一段正是必须替换的旧逻辑。评估2.0人天。
功能3：EBOT——固定审批意见配置
图4
截图说明：EBOT 审批动作设置图。配置项包括"使用固定审批意见"开关和默认文案（已核验业务信息，同意流转），启用后 EBOT 执行动作时写入以上文案。下方三步走：保存配置（approvalOpinionEnabled + approvalOpinion）→ 执行动作（仅 agree / reject 读取固定意见）→ 兼容回退（未启用或空文案时走原默认逻辑）。源码依据是 OutboundMessageServiceImpl 已读取 EBOT rejectConfig 中的开关与文案，并通过 FeatBit 灰度。预估1.5人天。
审批动作的固定意见配置，只影响"同意单据"和"驳回单据"，未勾选时必须保持现有默认文案。评估1.5人天。Agent 还给出了源码确认：OutboundMessageServiceImpl 已读取 EBOT rejectConfig 中的开关与文案，并通过 FeatBit 灰度；其他 EBOT 动作边界仍需产品确认。
第四步：汇总报告——三档人天
图5
截图说明：EAI 外包需求研发评估报告。乐观人天 11.0、最可能人天 14.0、悲观人天 18.5。最可能工作量拆分：功能1 凭证预览 7.0d、功能2 EAI 入口 2.0d、功能3 EBOT 意见 1.5d、测试/评审/发布 3.5d。建议排期 8 天（前后端并行5天 + 联调回归2天 + 灰度观察1天）。关键风险：753 微插件仓缺失、EAI 参数契约待确认、iframe CSP/混合内容、EBOT 动作范围待确认。评估口径：单人熟悉 EKB 代码库，0.5 人天粒度，不含历史数据迁移，不含移动端。
最后 Agent 给出完整的评估报告。最有价值的是三档人天：乐观 11.0、最可能 14.0、悲观 18.5。给客户承诺上线日期用"最可能"那一档，留有合理 buffer。如果客户场景特殊，还有"乐观"和"悲观"两档可以参考。
工作量拆分也很细：功能1 凭证预览 7.0d、功能2 EAI 入口 2.0d、功能3 EBOT 意见 1.5d、测试/评审/发布 3.5d。建议排期8天，前后端并行5天 + 联调回归2天 + 灰度观察1天。还列出了4个关键风险：753 微插件仓缺失、EAI 参数契约待确认、iframe CSP/混合内容、EBOT 动作范围待确认。评估口径也写清楚了：单人熟悉 EKB 代码库，0.5 人天粒度，不含历史数据迁移，不含移动端。