據 AlphaMoat 統計,截至 2026-09,財務數字化產品經理 累計下載 3,169 次、獲 13 個星標,在全部 5,078 個 AI 技能中排名第 3,600 位,在「專業領域」分類(465 個)中排名第 296 位。

累計安裝

222

累計下載

3169

星標

全站排名

#3,600

全站前 71% · 「專業領域」前 64%

平台	累計安裝	累計下載	星標	評論
SkillHub ↗	222	3169	13	—

各平台的計數口徑不同,統計時間不一致。

這個技能是做什麼的

把模糊的“財務數字化”需求收斂為可執行的場景方案，明確所需技術、預計投入、預計產出、上線時間與關鍵風險。需求先歸類為機會識別（輸出 3-5 個高價值場景）、單場景方案、多場景規劃（分階段路線圖）、BRD（面向業務決策層）或 PRD（面向產品/實施團隊）再決定交付深度。工作流為：把使用者原話轉成“現狀-痛點-目標-約束”四段式描述；參考 references/finance-digitalization-playbook.md 的場景庫（報銷與費控、發票與稅務協同、應付自動化、應收與回款管理、資金與現金預測、預算與經營分析、月結對賬關賬、電子會計檔案）選定場景；設計方案並輸出區間估算。估算顯式標註假設前提，至少拆出預計投入、預計產出與上線時間（PoC、一期上線、全面推廣三層），可用 scripts/estimate_finance_project.py 生成基線估算後結合客戶背景修正。預設交付 Word .docx（如 财务数字化方案-主题-YYYYMMDD.docx）。質量要求包括不寫“賦能”式空話、收益繫結可觀測指標（處理時長、FTE 節約、回款天數、月結週期、差錯率）、區分標準產品能力/需要整合/需要定製開發、金額預設 CNY 或人民幣，涉及大模型時補充資料安全、權限審計、模型幻覺與人工複核機制。

資料釋出於 2026-10-27

可以用來做什麼

財務數字化機會識別與 3-5 個高價值場景輸出
報銷、發票、應收、應付、預算、資金、月結對賬、電子檔案等單場景或多場景方案
BRD、PRD 與預設 Word 版方案文件交付

什麼時候用

使用者詢問財務數字化機會、財務中臺、業財一體化、財務 AI 或 RPA 應用時
使用者要求輸出具體場景方案或 BRD/PRD，尤其明確要求 Word 交付時

示例提示詞

以下是根據技能文件生成的示例,不代表實際執行結果。

幫我看看財務數字化有哪些機會

給我做一個應收回款數字化方案

輸出一版財務中臺 BRD，要 Word 版

月度資料趨勢

累計下載3169

星標13

2026-09 起統計方法調整:同名技能按作者分別統計,並覆蓋全部技能。圖中虛線為調整前的月份,與之後的資料不直接比較,也不計算跨越調整的增長。

月份	累計下載	環比	星標
2026-09	3169	—	13
2026-08	2345	—	13
2026-06	1195	+43.8%	8
2026-05	831	—	6
2026-03	247	—	-

SKILL.md 原文

以下是作者釋出的原始檔案,按純文字顯示,本站未做修改或稽核;其中的連結不可點選,命令請核實後再執行。抓取於 2026-10-23。

7.2 KB · SkillHub v1.0.0

---
name: finance-digitalization-product-manager
description: 为财务数字化机会识别、财务数智化方案设计、业财一体化场景规划，以及 BRD/PRD 编写提供标准方法。用于用户询问财务数字化机会、具体方案、报销、发票、应收、应付、预算、资金、税务、月结、对账、电子档案等场景改造，或要求输出 Word 版方案、BRD、PRD 时。
compatibility: Designed for WorkBuddy. Best when .docx document generation is available.
metadata:
  author: workbuddy
  version: "1.0.0"
---

# Finance Digitalization Product Manager

展開全部(共 178 行)

## Overview

提供面向中国企业财务场景的机会识别、方案设计、BRD、PRD 交付方法。将模糊的“财务数字化”需求收敛为可执行的场景方案，并明确所需技术、预计投入、预计产出、上线时间与关键风险。

## Trigger Conditions

在以下场景激活本技能：

- 用户询问财务数字化机会、财务数智化路线、财务共享、业财一体化、财务中台、财务 AI、RPA 在财务中的应用。
- 用户要求输出报销、费控、发票、税务、应收、应付、预算、资金、结账、对账、电子档案、管理报表等具体场景方案。
- 用户要求输出 BRD、PRD、业务方案书、产品方案书、路线图、实施建议书。
- 用户明确要求使用 Word 方式交付。

典型触发语句：

- “帮我看看财务数字化有哪些机会”
- “给我做一个应收回款数字化方案”
- “输出一版财务中台 BRD”
- “写成 Word 版 PRD”

## Request Classification

先将需求归类，再决定交付深度：

1. **机会识别**：输出 3-5 个高价值财务数字化场景，适合战略讨论或售前阶段。
2. **单场景方案**：围绕一个具体场景输出可落地方案，适合客户已明确痛点的情况。
3. **多场景规划**：输出分阶段建设路线图，适合年度规划或财务转型项目。
4. **BRD**：面向业务决策层，强调背景、目标、收益、范围、预算、风险与里程碑。
5. **PRD**：面向产品/实施团队，强调流程、功能、规则、数据、接口、权限与验收标准。

## Minimum Context

优先收集以下信息；若信息缺失，明确写出假设后继续推进，不因信息不全而卡住：

- 行业、公司规模、组织形态（集团 / 单体 / 多子公司 / 海内外）
- 当前核心痛点（效率、合规、数据质量、资金占用、经营分析、税务风险等）
- 现有系统格局（ERP、OA、费控、CRM、资金系统、BI、档案系统等）
- 目标范围（单流程、跨流程、平台化）
- 数据与接口可用性
- 合规与安全要求
- 期望上线窗口与预算约束

## Core Workflow

### 1. 定义业务问题

将用户原话转成“现状 - 痛点 - 目标 - 约束”四段式描述，避免直接堆概念。

### 2. 选定场景

优先参考 `references/finance-digitalization-playbook.md` 中的场景库与估算带宽：

- 报销与费控
- 发票与税务协同
- 应付自动化
- 应收与回款管理
- 资金与现金预测
- 预算与经营分析
- 月结、对账与关账
- 电子会计档案

若用户仅问“有哪些机会”，优先输出 3-5 个最相关场景，并说明排序理由。

### 3. 设计方案

每个场景至少覆盖以下内容：

- 具体业务场景与适用边界
- 当前痛点与目标指标
- 方案设计（流程、规则、数据、组织协同）
- 所需技术（工作流、规则引擎、OCR、RPA、API 集成、数据中台、BI、AI 等）
- 关键依赖与风险

### 4. 输出估算

所有方案默认给出区间估算，避免伪精确数字。估算必须显式标注假设前提，并至少拆出：

- **预计投入**：软件许可/订阅、实施服务、集成开发、数据治理、培训与推广、运维
- **预计产出**：人效提升、处理时长缩短、错误率下降、回款加快、资金占用降低、合规风险下降、管理透明度提升
- **上线时间**：PoC、一期上线、全面推广三个层次，必要时给出里程碑

需要快速获得首版估算时，可运行：

`scripts/estimate_finance_project.py`

该脚本用于生成财务数字化项目的基线投入/周期/团队建议，再结合客户背景进行修正。

## Default Deliverable Rules

默认交付为 Word 文档；除非用户明确要求只要聊天结论，否则生成 `.docx` 交付件。若环境支持 Word 文档能力，直接生成 `.docx`；若暂时无法直接产出 Word，先按 Word 结构整理内容，再转换为 `.docx`。

文档结构优先参考：

- `references/word-delivery-templates.md` 中的“方案文档模板”
- `references/word-delivery-templates.md` 中的“BRD 模板”
- `references/word-delivery-templates.md` 中的“PRD 模板”

文档命名建议：

- `财务数字化方案-主题-YYYYMMDD.docx`
- `BRD-主题-YYYYMMDD.docx`
- `PRD-主题-YYYYMMDD.docx`

## Output Requirements for Opportunity and Solution Documents

普通方案文档必须至少包含以下章节：

1. 项目背景与关键假设
2. 目标业务场景
3. 方案设计
4. 所需技术
5. 预计投入
6. 预计产出
7. 上线时间与实施节奏
8. 风险、依赖与建议下一步

当用户询问“机会”而不是“方案”时，仍需把机会写成具体场景，不要只给抽象方向词。

## BRD Rules

当用户要求 BRD 时，聚焦业务价值与决策信息，至少包含：

- 背景与现状
- 业务目标与 KPI
- 项目范围与边界
- 目标流程与角色变化
- 收益假设与 ROI 逻辑
- 预算与资源建议
- 实施阶段与里程碑
- 风险、依赖、待确认事项

避免把 BRD 写成功能列表堆砌；重点放在“为什么做、做什么、值不值得做”。

## PRD Rules

当用户要求 PRD 时，聚焦落地实现，至少包含：

- 产品目标与成功标准
- 用户角色与使用场景
- 业务流程与页面/节点流程
- 功能清单与优先级
- 关键规则、字段、状态机
- 集成接口与数据要求
- 权限、安全、审计、性能要求
- 验收标准、上线策略、迁移与培训要求

避免只写高层概念；必须给出能够进入设计/开发/实施阶段的颗粒度。

## Quality Bar

遵循以下质量要求：

- 优先给出行业可落地表达，不写“赋能、提升效率”这类空话而不解释机制。
- 所有估算都给范围，并写明决定范围变化的关键因素。
- 所有收益都尽量绑定可观测指标，如处理时长、FTE 节约、回款天数、月结周期、差错率。
- 明确区分“标准产品能力”“需要集成”“需要定制开发”三类工作。
- 在中国企业环境下，金额默认使用 `CNY` 或“人民币”。
- 涉及大模型或 AI 时，补充数据安全、权限审计、模型幻觉与人工复核机制。

## References

按需加载以下资源：

- `references/finance-digitalization-playbook.md`：场景库、估算带宽、产出测算口径
- `references/word-delivery-templates.md`：方案文档、BRD、PRD 的 Word 结构模板
- `scripts/estimate_finance_project.py`：快速生成项目基线估算