PM·D
PM-Design · 工程设计项目管理系统
PM-DESIGN / DESIGN DOC
文档编号 DPM-SPEC-001
版本 v0.1 · 2026-09-08 · 状态:已评审(结论见 §11)

总体方案设计
一套档案 + 一个大脑

多方协作的工程设计项目管理平台。AI 作为"全程在场者":从立项起,每个节点的数据、每份附件、每次审批、每笔资金流向,它都记得、看得懂、能关联。AI 负责记录、识别、校验、分发,审批权始终在人手里。本文档是第一期(财务模块)的总体设计,评审通过后进入开发。

第一期:财务模块 后续:进度 / 成果文件 / 人员 远期:物业与商业运营(数十年档案)
01

设计原则

  • 档案先于 AI:档案层不依赖任何 AI 存在。AI 全挂了,档案一个字节不少,审批照样走。
  • AI 做到"等人拍板"为止:AI 做记录、识别、计算、校验、汇总、预审;决策、盖章、对外正式文书由人完成。低风险自动放行本期不做。
  • 模型是耗材,系统是资产:大模型经"AI 网关"接入、可整体替换;系统寿命与模型寿命解耦。
  • 一切留痕:人的操作和 AI 的判断都进事件流水,随时可回溯"当时为什么批了这笔钱"。
02

总体架构:三层结构

回答"记忆和档案是一体还是延伸"——记忆是档案的延伸,且可随时从档案完整重建

① 档案层ARCHIVE · 唯一真相

业务数据库(项目、节点、发票、回款、审批)+ 文件库(合同/发票/回单扫描件原件)+ 事件流水(谁、何时、做了什么;AI 何时、判断了什么)。开放格式:MySQL + PDF/JPG 原件 + JSON,不绑定任何厂商。

↓ 生成 / 可重建
② 记忆层MEMORY · 档案的 AI 可读视图

项目摘要档案(AI 自动维护的近况综述)+ 语义索引(向量库,支撑"找那份渠道费合同"式检索)+ AI 预审结论(写回档案层成为新档案)。丢了可重建,不存在"AI 失忆"事故。

↓ 调用 / 可替换
③ 大脑层BRAIN · 无状态推理引擎

DeepSeek(可换)。模型 API 本身无记忆——每次 AI 工作时,系统从①②取出相关档案喂给它。换模型 = 换引擎,档案与索引纹丝不动。

一句话 档案是身体,记忆是索引,模型只是当前聘用的顾问。顾问可以换,身体和索引是自己的。

AI 网关(模型可替换的关键)

系统内所有 AI 调用收敛到一个内部接口层,对业务暴露的是能力而非某个模型:识别发票(图片)提取合同要素(文件)预审付款申请(项目ID)回答项目问题(项目ID, 问题)。接口背后接哪家模型是配置项;提示词与校验规则存在我们自己的代码库、版本化管理。

03

角色与账号体系

角色归属登录方式能做什么
项目负责人内部账号密码(后续可加企业微信)立项、维护付款节点、查看项目全程、处理待办
财务内部同上开票登记、回款登记、费用票核对、付款执行
审批人(管理层)内部同上支付费用审批;看到 AI 预审意见与全部依据后拍板
系统管理员内部同上账号、权限、管理费率等参数
承接方 / 供应商外部微信网页授权:点开微信里收到的链接 → 授权 → 自动建号只看自己的任务;按任务上传发票、合同,填写必填项

审批链可配置(2026-09-08 定):默认两级 财务负责人 → 总经理,可按项目加入项目负责人前置审批;金额分级规则后续可调。

外部协作的演进 原需求里的"10 分钟临时链接"升级为:任务链接带身份绑定,承接方首次微信授权后长期有效——链接即账号,不用反复发。前提:以公司主体申请微信开放平台/服务号(有认证费)。
04

财务流程(状态机)

每个项目是一条流程实例,当前停在哪个节点、缺什么材料,系统与 AI 都据此判断:

未通过审批 审批通过 项目立项 项目开票 需先开费用发票? 计划费用发票 提供费用发票及合同 项目回款 已开具费用发票? 计划费用发票 提供费用发票及合同 支付费用审批 支付费用(归档)

关键业务规则(硬性校验,AI 与系统双重把关)

  • 计划开票上限:开票前预开 → 计划总额 = 开票金额 ×(1 − 管理费率);回款后开 → 计划总额 = 到账金额 ×(1 − 管理费率)。实开累计不得超过计划总额。
  • 计划信息只读:提供费用发票时,计划里的开票公司、计划金额自动带入、不允许修改;实开金额自填但不能超计划。
  • 专票规则:是专用发票则必填税率,税额自动计算。
  • 到账比例可视化:付款比例 10% 但本次只到 8% 时,下次再到 2% 要能区分展示——付款申请页按"付款节点"累计到账,审核人一眼看到本次申请对应的是哪一段。
  • 审批回退:支付审批未通过 → 回到开票判断节点,保留全部历史记录,重走时不丢数据。
05

各节点:AI 做什么 / 人做什么

节点AI 做的人做的
项目立项读合同扫描件 → 预填项目名称、金额、客户、付款节点/比例;生成项目档案首页核对预填内容、确认立项;合同扫描件必传
项目开票读发票 → 预填号码/日期/金额/税率/税额;比对开票信息与立项付款节点是否吻合,不符标黄确认登记
◇ 需先开费用票?基于合同条款与历史项目给出建议(是/否 + 理由)拍板(判断类节点,AI 不决策)
计划费用发票按规则算出计划总额上限;按费用分类(生产成本/其他/渠道费)给出拆分建议确定由哪几家公司开、各开多少
提供费用发票及合同生成任务链接发给承接方;收到上传后 OCR 预填、校验是否超计划、专票税额复核;缺件自动催办承接方上传原件;内部确认接收
项目回款读银行回单 → 预填回款日期/金额/付款方;按付款节点累计到账比例并可视化确认到账
提交付款申请自动汇总全部费用票与合同(锁定不可改)、计算到账比例、标出与应付比例的差异;生成预审意见(合规/存疑点)负责人核对后提交
◇ 支付费用审批把预审意见、全部票据、资金流水摆在一屏;发现异常(超额、票号重复、税率缺失)置顶标红审批人拍板:通过 / 退回(填意见)
支付费用登记归档,项目财务档案闭环节点;更新项目摘要财务执行付款、录入凭证号
全程贯穿 任何时刻都可以问 AI:"这个项目到哪一步了?还差什么?哪笔钱没对上?"——AI 基于档案层回答,并给出可追溯的依据链接。AI 的每次预审、每条建议都落库存档。
06

数据模型(档案层 · 草案)

内容备注
users内部账号 + 外部微信账号(openid 绑定)角色字段区分权限
projects项目主档:名称、立项日期、负责人、合同金额、客户、设计单位、管理费率一个项目一条
payment_nodes付款节点:节点名、比例、金额立项时按合同录入
flow_instances流程状态:当前节点、各节点状态/时间/经办人状态机的持久化
invoices_out开票登记(设计费发票)关联付款节点
cost_invoice_plans计划费用票:供应商、类型、预计金额/日期、费用分类、计划总额上限只读带入后续节点
cost_invoices实收费用票:号码、金额、日期、是否专票、税率、税额、对应合同校验 ≤ 计划
receipts回款:日期、金额、付款方、对应付款节点累计到账比例来源
payment_requests付款申请:金额、账户信息、审批状态/意见提交时快照锁定票据
payouts支付记录:日期、金额、收款方、方式、凭证号
attachments文件库:原件路径、类型、归属节点、上传人、OCR 原文原件永不覆盖
tasks外部任务:发给承接方的上传任务、链接 token、状态微信消息入口
events事件流水:人/AI 的全部动作与判断只增不改,审计根基
ai_summaries / ai_reviews项目摘要、AI 预审结论记忆层,重建不影响档案

原则:业务表只增不改(更正走"红冲/作废"新记录),附件原件只增不删——这是几十年档案可信的根基。

07

页面清单

内部端(PC 为主)

  • 项目列表:状态、当前节点、待办、风险标记
  • 项目详情 = 一套档案:时间线 + 节点数据 + 附件 + 资金汇总 + AI 摘要
  • 节点办理页:每个节点的表单,AI 预填 + 人确认
  • 审批页:一屏看清申请金额、票据全集、到账比例、AI 预审意见,通过/退回
  • AI 问答栏:项目详情页常驻,可问全程任何问题
  • 系统管理:账号、管理费率、模型配置

外部承接方端(微信内,手机为主)

  • 微信授权登录(点开链接即登录)
  • 我的任务列表:待上传的发票/合同、截止时间
  • 任务办理页:拍照/上传附件,必填项表单(带 AI 预填确认)
  • 办理结果通知(微信服务通知)
08

技术选型与部署

选型理由
前端Vue 3 + Vite(内部端);轻量 H5(外部微信端)成熟、好维护;外部端要轻,秒开
后端Node.js(Express/Nest)+ PM2与服务器现有惯例一致(PM2 守护、nginx 反代)
数据库MySQL 8开放、通用、好备份;财务数据要硬事务
文件库服务器本地目录 + 定期备份(可后迁 COS 对象存储)原件只增不删
AI 大脑DeepSeek 官方 API(走 AI 网关,可换)国内模型,理解/推理/预审意见
票据 OCR待你拍板(候选:腾讯云票据 OCR / 阿里 / 百度)准确率是第一优先,见 §11
语义索引向量库(pgvector / Qdrant,可重建)支撑 AI 检索档案

部署(按团队惯例)

  • 服务器:119.91.48.31(office-jump),nginx + PM2 + certbot
  • 后端端口:3020 起(3000–3019 已占用,用前 ss -tln 确认)
  • 域名:需新子域名(如 pm-design.cyapps.tech)→ DNSPod 单独加 A 记录 → nginx server 块 → certbot 证书
  • 代码:本地 ~/kimiproject/PM-Design/,rsync 推送 /var/www/PM-Design/
09

数十年稳定性设计

  1. 格式开放:MySQL + PDF/JPG 原件 + JSON,任何厂商消失都能读。
  2. AI 网关抽象:换模型改配置,业务代码不动;提示词与规则在自己的代码库、版本化。
  3. 结论落库:历史预审意见、审批依据永久可查,换模型不影响追溯。
  4. 索引可重建:向量模型换了就从档案重建索引,原始档案不动。
  5. 只增不改:业务记录与附件只增不删,更正走红冲。
  6. 备份纪律:数据库每日备份 + 文件库定期异地副本(纳入运维手册)。
10

分期路线图

阶段内容产出
M1 财务骨架账号体系、项目立项、流程状态机、节点表单、附件库、事件流水、时间线档案页不用 AI 也能手工跑通财务全流程
M2 AI 进场AI 网关 + DeepSeek;发票/回单/合同 OCR 预填;规则校验;项目摘要;AI 问答"一个大脑"上线
M3 外部协作微信授权登录、任务链接、承接方端、催办通知多方协作闭环
M4 预审深化付款申请 AI 预审、异常检测(票号重复/超额/税率缺失)、审批页一屏汇总审批人"一眼能批"
远期进度/成果文件/人员模块;物业与商业运营阶段项目全生命周期

顺序逻辑:先把"档案"立住(M1),再让"大脑"进场(M2 起)。AI 依赖档案存在,反过来不行。

11

待你拍板的事项

#事项选项 / 说明结论(2026-09-08)
1OCR 选型候选:腾讯云票据 OCR(同生态、按次计费、发票字段结构化准确率高)/ 阿里云票据识别 / 百度。建议:先拿你们真实发票、回单各 10 张做三家对比测试,用准确率数据说话。同意。M2 启动时执行三家实测对比。
2管理费率全公司统一一个值?还是每个项目单独设定?(影响计划总额公式)按项目单独设定,立项时录入该项目管理费率。
3审批层级支付审批是单级(一个人批)还是按金额分级(如 ≥50 万两人批)?至少两级:财务负责人 + 总经理,可能加项目负责人。审批链做成可配置,后续可调。
4微信开放平台M3 需要公司主体申请服务号/开放平台(认证费约 300 元/年)。现在开始申请不亏。认证服务号即可,微信不审核项目内容。待确认:cyapps.tech 是否已 ICP 备案(微信回调域名强制要求)。
5系统名称与域名项目名已定 PM-Design。子域名建议 pm-design.cyapps.tech,确认后即可配 DNS。已定并上线:pm-design.cyapps.tech(2026-09-08)。
6DeepSeek API KeyM2 需要,DeepSeek 官方开放平台充值按量计费,先小额即可。M2 启动时由你提供 Key。
输入自动保存到服务器,写完在对话里跟我说一声即可;也可以点复制手动发我
下一步 你确认本方案(或对 §11 逐项给结论)→ 我出 M1 详细设计(数据库建表 SQL + 接口清单 + 页面原型 HTML)→ 评审通过即开工写代码。
DPM-SPEC-001 · 总体方案设计 v0.1 本地档案:~/kimiproject/PM-Design/docs/ 2026-09-08