需求分析与工作量评估
唯一必需输入是用户指定的需求文档。不要要求历史工作量表、团队配置表或其他额外材料作为输入。利用文档已有信息完成初评；缺失信息写成估算假设和待确认事项。遵循用户已给出的范围、岗位和输出格式。
交付的是给项目负责人和评审人阅读的中文报告。用几句话交代项目，明确回答“能不能做、难在哪里、需要多少工作量、怎么配人、多久交付”。默认生成 Word 和 Excel 明细；有 PDF 渲染能力时提供便于直接阅读的 PDF。
运行环境与首次使用
适用于支持本地 Skill、文件读写和命令执行的 Agent。首次使用时，定位当前安装目录，检查可用的 Python 3 解释器；下文的 python 按环境替换为 python3、py -3 或虚拟环境解释器，所有路径按实际位置填写并加引号。
读取 DOCX、TXT、Markdown 和生成 Word 仅需 Python 标准库。生成 Excel 需 openpyxl，生成 PDF 需 PyMuPDF；缺失时，在当前任务使用的 Python 环境中安装随附依赖：
python -m pip install -r "<skill目录>/requirements.txt"
仅需 Word 时可跳过依赖安装并使用 --docx-only。无法安装依赖时保留可生成的交付物并说明缺失格式。需求文档和生成结果放在用户的工作目录，不写入 Skill 安装目录。随附脚本在本地处理文件，不需要 SkillHub 登录、API Key 或额外模型服务。
报告写法
正文通常控制在 2～4 页，按项目规模调整，后附功能估算表。结构建议为：
- 项目概况与评估结论：3～5 句介绍建设内容，随后直接给出规模、主要投入和实施建议；用一张模块汇总表支撑判断。
- 实施难点与处理建议：挑出真正影响方案或投入的 3～6 个问题，写清“问题是什么、会影响什么、建议怎么做”。把规则冲突、接口缺失、技术难点讲具体，不罗列全部潜在风险。
- 人员配置与实施安排：岗位人数、对应工作量、阶段交付内容。文档规定的人员或周期与建议有差异时，用一句具体说明交代差额及原因。服务期影响投入时简要列出。
- 功能工作量附表：逐节点列各岗位人数、人天和节点工期。明确写“2 人、20 人天”，不要使用需要读者解码的“2/10”缩写。
先作判断，再给理由。写“授信额度释放时点需要统一，建议还款后恢复额度”，不要写“在规则未经确认前不能无条件承诺”。有证据的实现障碍直接说明；不要为减少防御性措辞而隐去真实问题。
正文以一套建议数值为主。范围、复用前提只在影响结论的位置集中交代一次。原文段落编号、逐项上下界、置信度、计算公式、容量矩阵、去重说明和工具校验过程保留在内部底稿；不逐项复制到报告。底稿中的结论先改写成自然语言，再进入正文。人天与人员总数从同一份测算数据汇总，不能为使报告简短而改变数值。
读取需求
完整读取正文、表格、附录和影响范围的图示，记录章节和可定位的原文。不要只根据目录、标题或关键词估算。
DOCX、TXT、Markdown 可使用随附脚本，输出全文、段落索引和表格结构：
python "<skill目录>/scripts/extract_requirements.py" "<需求文档>" --out "<工作目录>/source"
DOCX 的 P0001 等编号是提取定位，不是原文页码。表格中的合并单元格结合结构解释；查看提取的相关图片。脚本不执行 OCR，不解析嵌入附件；发现这些内容时用可用工具补读，读不到的部分明确标记，不能宣称完整覆盖。其他格式使用可用读取工具；无法读取关键部分时，先评估可读范围并说明限制。
区分文档明确要求、合理推断和待确认假设。排期、角色人数、服务期、响应时限可能藏在非功能章节或表格中，必须纳入分析。
分析与估算
读 估算方法，完成以下工作：
- 按“一级模块—二级能力—三级功能—可验收节点”拆分。共用的权限、导出、支付、接口、部署等只计一次；总览、详细描述和里程碑的同一要求建立关联，不重复累加。
- 底稿记录原文依据、困难原因、影响功能和处理方式，可采用“可实现 / 有条件可实现 / 需求待澄清 / 当前条件下不可实现”。报告将其写成具体业务判断；普通可开发功能无需重复说明可行性。
- 每个节点给出后端、算法/数据、前端、测试、产品的低值/基准/高值人天、参与人数、节点工作日和估算依据。需要时增加管理/架构、设计、运维/安全等角色。无工作填 0，无法估算填
null并注明范围，不能用 0 代替未知。 - 普通统计、公式计价、阈值预警和定时任务通常由后端实现；仅有“智能”字样不足以分配算法工程师。确有数据工程或机器学习工作时分清职责与数据前提。
- 明确熟练度、复用程度、接口数量、端数量、测试范围、有效投入率等假设。持续定制需求使用有限批次或单次增量估算，不能隐含无限包干。
- 提供角色汇总、共享团队建议、阶段依赖及工期。人数、人天、工作日和日历周期分开；节点人数来自共享团队，不能直接相加当作总团队人数。检查每阶段岗位容量与关键依赖，不能用总人天除以总人数直接承诺交付日。
- 文档约定的最低团队或驻场周期独立呈现。开发净工作量、全职驻场投入、试运行和维保分别说明，不能用净工作量替代采购的人力要求。
生成交付物
按照 报告数据格式 保存分析 JSON。先填写面向读者的 report 内容，再生成报告；底稿字段不会直接灌入正文。脚本负责校验和加总，不替代需求判断：
python "<skill目录>/scripts/build_report.py" "<评估数据.json>" --out "<输出目录>"
Python 标准库即可生成 Word；Excel 需 openpyxl。安装了 PyMuPDF 时生成同内容的 PDF。--docx-only 仅生成 Word；依赖缺失保留已生成文件。
交付前先通读正文：第一页能否看懂结论，难点是否具体，是否重复讲限制，表格是否能直接比较。再核对范围覆盖、去重、加总和人员工期。检查提示先处理，剩余的实质问题用简短业务语言写进报告。渲染并检查有条件查看的交付物，尤其跨页、表头、字号和长表；不把未查看的格式称为已检查。
最终优先给出可直接阅读的报告链接，简要说明主要判断与建议。示例项目仅验证 Skill，不作为未来项目的隐含范围、规模或数值基准。
