artifact: add FPA analysis outputs through round 6

analysis/personas/accountant.md

@@ -0,0 +1,46 @@
+---
+artifact_type: persona
+slug: accountant
+round: 1
+status: draft
+project: maxcpa
+title: Accountant
+---
+
+# 会计师
+
+## 核心目标
+
+把通过邀请进入的潜在客户转化为正式服务案件，收齐完整资料，在截止日前推进工作，并以清晰归档和更少重复催促完成每一个案件。
+
+## 与其他 Persona 的关键区别
+
+- 相比 `Firm Owner`，这个 Persona 处理的是自己被分配到的客户和案件执行，而不是整个事务所的经营总览。
+- 相比 `Client`，这个 Persona 负责核验信息、确认报价、审核上传资料、推进案件状态，并发起签字流程。
+- 这个 Persona 是服务流程中的主要人工操作者，与 AI 协同工作，而不是只做监督。
+
+## 权限边界
+
+- 可以查看和管理分配给自己的客户与案件。
+- 可以审核新的受邀注册客户，并在正式建档前确认客户接待信息。
+- 可以查看 AI 对客户填写信息和上传资料的初步审核结果。
+- 可以调整报价参考、发送最终报价、催补缺件、更新案件状态，并发起签字。
+- 可以查看与自己工作相关的客户服务历史、客户画像信号和介绍来源。
+- 当案件需要直接介入时，可以在系统自动提醒之外发起人工提醒。
+
+## 不可见页面或能力
+
+- 默认不能访问面向 `Firm Owner` 的事务所级财务总览或全会计师生产力视图。
+- 默认不负责控制全局自动化策略、老板级升级收件箱或全局流失管理视图。
+- 不会把邀请码注册页面作为自己的后台操作界面；他们是触发和跟踪这条流程的人，而不是注册动作的执行者。
+
+## 重要约束与假设
+
+- brief 把时间压力和缺件追踪定义为核心痛点，因此这个 Persona 高度依赖截止日可见性和自动收资支持。
+- AI 在这里明确是辅助性的：系统负责起草、识别和提醒，但建档、报价和资料齐全性的最终确认仍由会计师完成。
+- 这个 Persona 需要端到端案件时间线，因为 brief 反复强调“知道每个案件卡在哪里”。
+- 这个 Persona 很可能需要快速访问历史服务记录和客户偏好，以减少重复询问并避免沟通失误。
+
+## 相关文档
+
+- Story Map: `../story-maps/accountant.md`