前端-远程-1个月

项目编号：【38400】
感谢你对这个⾃由职业项⽬的兴趣。附件是客户付款记录列表⻚⾯的产品需求⽂档（
PRD
），请你仔细
阅读，并告知我们你对开发周期和报价的预估。
有⼏点想提前说明：
1.
⻓期合作的可能性：如果你的代码质量好、沟通顺畅、开发过程顺利，我们⾮常欢迎进⼀步探讨⻓期
合作的可能，包括后续的新功能或更深⼊的项⽬参与。
2.
可以借助
AI
⼯具加速开发：我们理解，现在很多开发流程都可以通过
AI
辅助⼯具（⽐如
Copilot
、
Cursor
、
ChatGPT
）来提⾼效率，特别是像
i18n
⽂本⽣成、模板代码等部分。我们完全接受使⽤
AI
来
提升开发效率，但对应的报价也应该合理，反映出实际的投⼊⼯时。
3.
技术栈说明：项⽬使⽤的是
React + UmiJS + TypeScript
的前端技术，后端为
Node.js + Cloudflare
D1 SQL
数据库。开发需要遵循现有项⽬的架构和规范。
期待你的回复和报价，如有任何问题或对⽂档内容有不清楚的地⽅，欢迎随时提问。
产品需求⽂档：客户付款记录列表⻚⾯
介绍
/
概述
客户付款记录列表⻚⾯是⼀个将添加到现有应⽤程序中的新功能。此功能将为⽤户提供结构化表格格式
的付款历史记录综合视图。此功能解决了⽤户轻松访问和查看付款记录的需求，包括与发票关联的付款
和独⽴付款记录。该⻚⾯将通过弹出模态框提供详细查看功能，以增强⽤户体验。
重要说明：

这是对现有代码库的增强功能。开发者应该将此功能集成到当前应⽤程序架构中，⽽不是从
零开始构建。
⽬标：

创建⼀个直观、易访问的付款历史界⾯，允许⽤户快速查看付款记录并按需访问详细信息。
⽬标
1.
可访问性：

为⽤户提供轻松访问完整付款历史记录的能⼒
2.
清晰度：

以清晰、有组织的表格格式显示付款信息
3.
详情访问：

通过交互式模态框让⽤户查看全⾯的付款详情
4.
数据集成：

成功连接并显示发票和付款表的数据
5.
⼀致性：

遵循现有应⽤程序的表格功能和
UI/UX
模式
⽤户故事
1.
作为⽤户，我希望以表格格式查看我的付款历史记录，以便我可以快速浏览我的过往付款。
2.
作为⽤户，我希望⼀⽬了然地看到关键付款信息（发票号码、⾦额、状态），以便我可以识别特定
付款⽽⽆需打开详情。
3.
作为⽤户，我希望点击任何付款⾏的
"
查看详情
"
按钮，以便我可以看到该特定付款的全⾯信息。
4.
作为⽤户，我希望在详情视图中看到已完成付款的付款⽇期，以便我可以跟踪付款处理时间。
5.
作为⽤户，我希望在付款信息不可⽤时看到清晰的指示符（显示为
"-"
），以便我了解数据限制。
功能需求
表格显示需求
1.
系统必须以表格格式显示付款历史记录，包含以下列：
发票号码
⾦额
状态
查看详情（
CTA
按钮）
2.
当付款记录存在但没有对应发票时，系统必须为缺失的发票信息显示
"-"
。
3.
即使发票数据缺失，系统也必须显示所有可⽤的付款信息。
4.
表格必须遵循现有应⽤程序的分⻚、排序和筛选模式。
模态框详情需求
5.
当⽤户点击
"
查看详情
"
按钮时，系统必须显示弹出模态框。
6.
对于状态为
"
已付款
"
的付款，模态框必须显示付款⽇期。
7.
模态框必须显示所有可⽤的付款和发票信息。
8.
模态框必须优雅地处理缺失数据，为不可⽤字段显示
"-"
。
9.
模态框必须可通过标准交互模式关闭（关闭按钮、
ESC
键、点击外部区域）。
API
需求
10.
系统必须提供⼀个连接
invoices
和
payments
表的新
API
端点。
11.
即使没有对应发票存在，
API
也必须返回付款记录。
12.
即使没有对应付款存在，
API
也必须返回发票记录。
13. API
必须遵循现有应⽤程序的身份验证、授权和响应格式模式。
14. API
必须⽀持与应⽤程序中其他端点相同的筛选、排序和分⻚参数。
国际化需求
15.
系统必须使⽤
i18n
进⾏翻译⽀持。
16.
翻译内容将不会提供，开发者必须使⽤
AI
⼯具（如
Cursor
）来⽣成所需的翻译⽂本。
17.
所有⽤户界⾯⽂本必须通过
i18n
系统进⾏国际化处理，包括表格标题、按钮⽂本、模态框内容和错
误消息。
技术栈
前端
框架：
ReactJS
配合
UmiJS
语⾔：
TypeScript
架构：

遵循现有代码架构模式
后端
API
：
RESTful API
运⾏时：
Node.js
语⾔：
TypeScript
数据库：
Cloudflare D1 SQL
数据库
架构：

遵循现有代码架构模式
环境
当前：

开发环境和⽣产环境
即将添加：

预发布环境
开发流程
分⽀管理
1.
创建新分⽀时遵循以下约定：
功能分⽀：
feat/payment-listing
或
feat/payment-modal
错误修复分⽀：
fix/payment-display-issue
使⽤描述性的英⽂名称，保持简短但有意义
避免使⽤随意的名称如
"abc"
或
"test"
开发流程
2.
开发与测试：
在功能分⽀上完成开发
在本地环境进⾏充分测试
确保所有功能按照
PRD
规范正常⼯作
3.
提交拉取请求：
开发和⾃测完成后提交拉取请求
包含清晰的变更描述和测试情况
4.
沟通：
创建
PR
后在群聊中通知团队
包含
PR
链接和变更的简要描述
5.
代码审查：
PR
审查员将在
GitHub
上审查并评论
开发者负责跟进审查意⻅
处理所有反馈并根据需要重新请求审查
6.
部署与⽣产测试：
代码合并和部署后，将进⾏⽣产测试
在⽣产环境中发现的任何错误将在群聊中报告
错误修复遵循相同的⼯作流程