[T.17] 团队项目：Beta 阶段项目展示

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[T.17] 团队项目：Beta 阶段项目展示
我在这个课程的目标是	学习软件工程的基础知识，和团队成员们实践各种软件工程的方法与流程，开发一个让我们值得骄傲的项目
这个作业在哪个具体方面帮助我实现目标	Beta 阶段项目展示

项目与团队亮点

团队成员与分工简介

任务分工清晰且针对性强：每个成员的任务都与其专长或职责匹配，确保了各项工作的高效完成。例如，吴佳峻独立负责需求分析及MCP协议支持探索，充分利用了其在需求分析与协议支持方面的技术优势。

团队成员合作：整体架构设计、流程构想及后端组件对接等任务都需要团队协同完成，确保了系统的各个部分能够顺畅对接。

前后端分工明确：前端开发由叶佩霖、林宇浩、熊晓焜等人共同完成，涉及到响应式设计和适配，后端部分由钟芳梽、陈叙传等负责，确保了系统前后端的平衡。

核心模块任务独立负责：如钟芳梽负责Qdrant和向量库模块，陈叙传负责LLM模块，确保了这些关键功能的独立性和稳定性。

1.范兴堃

• 参与任务：
  • 选题（调研与可行性分析）
  • 整体架构设计（协同完成）
  • 工具调研：（协助执行）
  • 流程构想（主责）
  • 数据库设计（主责）

2.吴佳峻

• 参与任务：
  • 选题及需求分析（独立）
  • 整体架构（协同完成）
  • MCP协议支持探索（独立）
  • 工具调研：（主责执行）
  • 流程构想（协同执行）

3.叶佩霖

• 参与任务：
  • 选题（调研）
  • 前端适配（响应式设计）
  • 学习 React 和 Reactflow 前端架构（主要负责人）
  • 搭建RAGnarok前端（主要负责人）

4.林宇浩

• 参与任务：
  • 选题（调研）
  • 前端适配（响应式开发）
  • 文件切分（新增，独立负责）
  • 后端组件对接（协作执行）

5.熊晓焜

• 参与任务：
  • 选题（调研）
  • 前端适配（开发协同）
  • embedding（优化和联调）
  • 后端组件对接（协作执行）

6.钟芳梽

• 参与任务：
  • 选题（调研）
  • 向量库+Retrieve 模块（独立负责）
  • Qdrant（框架搭建与功能完善）
  • 后端组件对接（协作执行）

7.陈叙传

• 参与任务：
  • 选题（调研）
  • 用户提问 + LLM 模块（独立完成）
  • 后端组件对接（协作执行）
  • 优化 LLM 异步调用性能

项目管理

1. 任务管理工具

• 飞书多维表格：记录和跟踪所有任务的信息，包括任务标题、描述、执行人、开始与截止日期、预估工时、实际进展、依赖关系等。

2. 任务分解方法

• WBS（工作分解结构）方法：项目目标首先被拆解为高层次的任务，再根据任务的重要性和复杂性进一步细化为具体的、独立的、短时的子任务。
• 任务粒度控制：通过拆解任务为短时、可执行的小任务，可以确保每个子任务能够在短时间内完成，降低任务的复杂度与不确定性。

3. 进度记录与跟踪

• 飞书多维表格进度更新：所有任务及子任务的进度信息都记录在飞书多维表格中，包括任务描述、负责人、实际完成情况、任务进展等。
• 定期进度更新：团队定期进行进度更新（如每日或每周），通过飞书进行共享，形成动态的任务进度图表。这有助于团队及时了解各自任务的完成情况，保持整体协调。

4. 动态调整机制

• 实时反馈与调整：项目经理（PM）根据团队成员的反馈、开发过程中的实际情况对任务的预估工时、依赖关系以及任务分配进行动态调整。

典型用户场景与软件满足方式

本项目RAGnarok面向B端企业用户和C端个人用户两大核心用户群体，针对其实际使用需求和目标，系统在功能、架构和使用体验等方面做了明确设计，以满足典型应用场景下的业务与个人智能问答需求。

一、B端企业用户典型场景

1. 应用背景

企业IT部门或业务团队希望构建专属的智能问答系统，用于客服支持、知识管理、内部知识库问答、员工培训等场景，需保障数据安全、知识隔离、系统集成能力。

2. 典型用户画像

• 企业IT经理、架构师、系统管理员
• 对接平台的第三方服务集成商
• 企业知识库维护人员

3. 典型用户场景

场景：某大型企业搭建内部智能问答助手，支持员工在内部系统中提问业务流程、制度政策、技术文档。

用户操作流程：

• 企业通过RAGnarok部署私有化实例，上传结构化/非结构化文档至私有知识库。
• 使用模块化Pipeline配置：文档检索 → 智能排序 → LLM问答生成。
• 系统通过MCP协议对接企业已有系统（如OA或CRM）以获取动态信息。
• IT管理员设定访问权限，多租户模式保障不同部门数据隔离。

4. 软件满足方式

功能模块	满足点说明
私有化部署 & 多租户架构	确保企业数据安全，支持不同部门独立使用与管理知识库
MCP接口协议	统一数据上下文结构，简化与企业现有系统的集成工作
流水线（Pipeline）编排	企业可自定义问答流程，灵活适应业务场景变化
权限与审计管理	提供用户权限分级与操作日志，满足企业合规要求
运维监控 & 调试工具	保障系统稳定运行，支持快速故障定位与性能调优

5. 效果

• 快速构建面向员工或客户的问答系统，缩短部署周期
• 强化内部知识共享与工作效率
• 降低技术集成与维护成本，提高系统安全性和稳定性

二、C端普通用户典型场景

1. 应用背景

个人用户希望借助RAG技术便捷获取知识答案，例如进行日常知识查询、学习辅助、工作参考等，追求高效、准确、无需技术门槛的使用体验。

2. 典型用户画像

• 学生、自由职业者、知识工作者、AI兴趣爱好者
• 对LLM技术感兴趣但无开发能力的用户

3. 典型用户场景

场景：用户希望快速查询某个专业术语、撰写资料或整理文献摘要，通过RAGnarok平台完成这一过程。

用户操作流程：

• 用户注册并创建个人知识库，上传PDF、网页、笔记等内容。
• 在界面中输入问题，系统使用内置Pipeline完成检索增强问答。
• 系统提供回答结果，并列出参考文档与出处。
• 用户收藏、反馈或分享回答结果，形成个性化历史记录。

4. 软件满足方式

功能模块	满足点说明
开箱即用的可视化界面	无需编码，即可上传文档、提问并获取回答
智能问答 + 引用文档呈现	保证答案可追溯，提高信任度与实用性
个性化知识库	用户可构建属于自己的语义库，提升问答的相关性
查询历史与推荐机制	根据用户行为进行答案推荐与内容优化
简洁交互体验	Web端面向C端设计的界面与流程

5. 效果

• 快速获得准确、上下文相关的答案，无需自行查阅文档
• 可持续构建个人知识体系，助力学习与工作
• 用户体验友好，无需任何技术背景即可使用

RAGnarok 的杀手级功能与差异化亮点

（对比 Dify / Haystack / RAGFlow 等主流竞品）

维度	RAGnarok 核心能力	竞品现状	差异化价值
RAG 逻辑细分（100%）	Pipeline 颗粒级可编排- 检索 → 过滤 → Rerank → LLM → 后处理… 块级拖拽- 串并行、条件分支、循环、断点调试	• Dify：可视化流程但节点种类有限、不可并行• Haystack：需写 Python 脚本• RAGFlow：主流程固定	像“搭积木”一样自定义任意深度的 RAG & Agent；复杂业务链路不再受限
高级检索（0%）	- 混合搜（向量 + BM25）- 可插拔 Cross‑Encoder Rerank- 跨库调度与去重	• Dify：主打跨库，单库精准度一般• Haystack：需自行配置 Rerank• RAGFlow：高精度但慢	在保留跨库广度的同时给出专业级精准度，满足金融 / 法律等高要求场景
知识库多租户 & 安全（50%）	- 公私库 + 租户隔离- 条目级权限 & 字段加密	多数竞品仅简单分库或需企业版	企业可放心私有化部署；同一实例服务多业务线 SaaS 化无障碍
实时可观测性（50%）	全链路调试仪表盘- 中间结果逐步展示- WebSocket 秒级推送- 断点运行 / 参数热调	大多仅日志或简单 Console	开发者 DX 大幅提升，定位“幻觉”、检索不准等问题只需几分钟
开发者友好（80%）	- Python SDK + 细粒度子模块- MIT / Apache‑2.0 友好开源- Docker 一键起	• Dify：License 对商业有约束• Haystack：代码型，上手门槛高	既“开箱即用”，又能拆成库嵌入现有系统，商业化不背包袱
扩展方式（50%）	MCP + 自定义组件双轨- 插件即服务- 支持把本地脚本包装成 MCP 工具	竞品多依赖内建接口	未来新模型 / 新数据库不改核心，只加一个组件即可热插拔
权限管理(80%)	支持租户或者用户可以对知识库进行授权管理，对于其他用户可以进行授权：read、write、admin等	Dify 暂不支持的授权特性	可以控制特定用户是否可用上传、训练、批量导入等敏感功能

项目发布时的团队努力

在 RAGnarok-Beta阶段的发布过程中，团队成员通力协作，分别承担了技术保障与用户宣传反馈两个方向的关键任务。

• 技术发布保障方面： 多位成员针对部署过程中出现的问题展开联调与修复，包括：
  • 优化Retriever与向量库接口，解决性能问题；
  • 完善异步处理功能，尤其是LLM推理链，提高速度和稳定性；
  • 确保各模块联通，打通“文档上传 → 检索 → 生成回答”的完整链路。
• 用户宣传与反馈收集方面： 另一部分成员面向 B 端企业用户开展产品介绍与灰度试用邀请，同时也建立C端用户群邀请C端用户体验低代码流水线的搭建。收集实际使用反馈，整理成改进建议，推动产品进一步优化。
• 团队还特别关注UI设计的简洁性和直观性，使用户在无技术背景的情况下，也能快速上手并高效使用平台。

实际活跃用户数据如何

两个b端用户场景

MPA-agent

MPA-agent 是一款多功能智能代理系统，包含以下三个核心模块：

基础问答模块 自动回答企业内部或客户常见问题，提升客户支持和员工知识库查询效率。系统通过NLP技术从知识库中检索并生成准确答案，支持自学习和多场景适配。

教辅生成模块 为教育领域提供智能学习辅助功能，自动从教材中生成习题、复习资料和知识点总结，帮助学生和教育机构提升学习效率。支持个性化推荐和自动生成习题与解析。

论文评审模块 用于学术期刊或科研机构自动化评审论文，检测格式、语法、结构和引用规范。系统可提供自动化初步评审报告，辅助学术机构提升评审效率，确保论文质量。

优势：模块化设计，使得MPA-agent能灵活应对不同任务，提升工作效率。

考研英语出题

考研英语出题系统的目标是帮助考研学生在英语复习过程中进行模拟测试、题目解析和能力提升。这个系统通过RAGnarok的智能问答功能，可以为考研学生提供高效的学习体验，尤其在复习材料的查询和解析上。学生可以在系统中上传考研英语的历年真题或模拟题，并通过系统进行自动化的试题解析。

场景流程：

相应机构上传资料： 相应机构上传考研英语相关的文档，如历年真题、模拟题、阅读理解、作文题目等。

系统处理： 系统利用RAGnarok的模块化流水线，自动进行文档检索和内容提取，组织成可查询的知识库。

智能题库问答： 学生在系统中输入疑问，例如“这道阅读理解的答案解析是什么？”或者“作文的评分标准是什么？”系统会基于上传的资料生成准确的答案，并附带参考文献和出处。

个性化推荐： 系统会根据学生的历史查询和反馈，提供个性化的学习资料和模拟测试题目，帮助学生更好地备战考试。

系统特点：

• 个性化学习： 支持根据学生的学习进度和需要提供个性化的学习内容，提升备考效率。
• 高效的题目解析： 自动解析考研英语试题，详细说明每道题的解答过程及技巧，帮助学生理解和掌握英语考试的解题方法。
• 多种答疑模式： 除了问题答疑，系统还支持作业批改和成绩分析，辅助学生全面提升。
  下面是一个出题示例
  
  下面是使用情况

下面是系统的整体架构，每一个模块对应后端一个基础算子

整个系统我们在六个维度上与基线模型进行了对比，结果如下

软件工程质量

为了更客观地评估和证明团队的软件工程质量，可以从以下几个维度引入数据支撑：

1.接口规范统一

我们Beta阶段延续了Alpha阶段的良好习惯，继续使用Apifox来管理规范所有接口，使前后端对接工作效率显著提升，成功率极大提高。同时也更容易发现的bug所在位置，精准定位，高效解决。

2.模块测试

对新增加的功能，我们依旧通过单元测试来保证每个模块的功能独立且正确运行。

3.使用apifox进行压测，自动化测试，以及定时测试

4.质量控制严格

我们Beta阶段的所有代码都按照课程组要求，通过Pull Request审核机制，确保每次合并前经过至少两人进行code review，提升代码质量与一致性。

5.自动化测评流程引入

提高代码质量和功能可靠性，我们在 Beta 阶段引入了自动化测评流程。在每次 Pull Request 提交后，自动执行测试脚本，确保核心模块在不同场景下均能正常运行。结合持续集成（CI）工具，实现了“提交即测”的机制，提升了开发效率与系统稳定性。

6.uv锁定依赖

我们继续使用uv，提高项目的依赖管理和协作开发的工程质量，通过 uv.lock文件使得每位团队成员、CI/CD 服务器都使用完全一致的依赖版本，避免版本不一致的问题。

7.架构设计清晰，模块划分合理

项目采用模块化流水线架构，具备高度可组合性和扩展性，支持企业用户和个人用户的多样化需求，体现了良好的高内聚、低耦合理念。

demo演示

用户/租户登录与注册


用户主页

租户下管理的用户

知识库



知识库权限管理


pipeline agent

项目与团队总结

项目管理

团队成员的简介和个人博客地址

成员	介绍	个人博客地址
吴佳峻	"你是项目的PM兼测试人员，负责捍卫cxc,fxk,lyh,xxk,ypl,zfz的头发"	https://www.cnblogs.com/wuyu666888
熊晓焜	"你是一个后端开发工程师，喜欢古典乐和足球，希望写出有序且优雅的项目"	https://www.cnblogs.com/CrisXxk
叶佩霖	"你是一个前端开发工程师，想要捍卫银河中的美"	https://www.cnblogs.com/Idrila
林宇浩	"你是一个前端开发工程师，喜欢北冰洋，还是一名羽毛球爱好者"	https://www.cnblogs.com/7111-lyh
范兴堃	"你是项目的PM兼测试人员，热爱滑雪"	https://www.cnblogs.com/Poseidon-fan
钟芳梽	"你是一个后端开发工程师，永远对新的技术保持热忱，希望能在这次合作中学习到更多的新技能"	https://www.cnblogs.com/Wednesday-zfz
陈叙传	"你是一个后端开发工程师，热衷于一切释放生产力的新技术，喜欢构建自动化工作流，你期待在团队中与前端工程师、PM等其他团队成员合作，共同创造出有价值的项目"	https://www.cnblogs.com/cxccxc

团队角色与贡献

名字	角色	团队贡献分	具体的、可衡量的、可验证的贡献
范兴堃	架构与数据库设计	51.19	负责数据库结构设计，主导核心流程构想，参与架构方案制定与优化，设计demo
吴佳峻	PM & 技术骨干 & 工具集成	50.67	主导工具选型与集成，参与各模块的联调保证项目正确运行，实现核心协议接入功能
叶佩霖	前端核心开发	50.68	搭建前端架构，完成主要页面设计与组件开发，实现响应式布局
林宇浩	文件处理与前端协作	49.63	开发文件切分模块，参与后端联调、权限管理的后端实现
熊晓焜	embedding、前端支持与博客管理	50.66	开发embedding模块，参与前端开发、权限管理的前端实现、博客整理与发布
钟芳梽	检索模块开发	50.15	开发 Retrieve 模块、搭建 Qdrant 环境、参与后端联调、为服务器配置代理
陈叙传	问答与模型调用	47.02	独立完成问答模块开发，丰富了后端大模型相关的组件类型

项目管理

1.任务管理工具优化

我们继续使用飞书文档为主要管理工具，相较于Alpha阶段，我们更加注重子任务的优先级以及子任务之间的依赖关系，避免出现了Alpha阶段的”等待卡点”问题，使得整个工作流程更加协同。

2.实时跟进和动态调整

PM会定期跟进整个项目的进度，并根据项目开发的实际情况进行动态调整。相较于Alpha阶段，Beta阶段我们团队更加集中于线下开发，更加有利于项目进度的跟进。

分工协作

1.职责明确：成员按照模块分工，每人主责一部分，如向量库、文档切分、LLM调用、MCP接入等，责任边界清晰。

2.前端重点加强：由于Alpha阶前端工作并未按时达标完成，所以我们在Bete阶段对于前端的投入更多，派遣了更多的团队成员前往前端进行协同开发以及前后端交接工作。

3.高效协作机制：在Beta阶段，团队依旧通过微信、飞书、飞书会议及线下组会等多种沟通方式，实现了高效的信息同步与问题快速响应。

相较于Alpha阶段

相较于 Alpha 阶段，Beta 阶段我们更加注重前端开发工作，认识到只有构建良好的前端架构，才能有效呈现和释放后端系统的功能价值。与此同时，团队组织了更多频次的线下组会，增强了协同开发效率。面对面沟通不仅加快了问题的解决，也促进了成员之间的理解与配合，从而显著推动了项目整体进展。

经验教训

在本阶段实践中，团队深刻体会到线下组会的重要性：相比线上交流，面对面讨论更易聚焦核心问题、统一思路，尤其在系统集成和复杂问题处理时效果显著。同时，关键模块的对接工作由两人协作结对编程，大幅提升了对对接效率。

沟通对接

1.沟通工具和方式

使用飞书群聊和微信作为主要即时沟通工具，进行日常交流、技术问题讨论和任务协调；对于跨模块问题或讨论需要详细记录的主题，采用飞书会议或者线下会议的方式，提高沟通效率。

2.模块对接

各功能模块之间的对接以接口文档为标准，同时使用Apifox来实现接口的统一管理与测试。同时在github上面通过PR进行沟通和对接。

3.沟通记录留存方式

在沟通工具上有相关内容，同时飞书文档记录团队成员的任务分工管理以及完成情况与关键讨论点。

平衡时间/质量/资源

为了在有限时间内保障交付质量，团队采用了明确分工、敏捷迭代、重点优先的策略进行平衡：

• 时间方面：通过WBS方法将任务细化为可控的短周期目标，结合飞书多维表格实时追踪进度，确保每阶段目标清晰可控。
• 质量方面：关键模块引入单元测试与流水线测试，所有代码经 PR 审核后合并，确保功能稳定与代码规范。
• 资源方面：根据任务优先级灵活分配人力，复杂模块采用结对编程，减少沟通成本、提升开发效率。

同时，通过定期线下组会与在线同步机制保持团队协同，确保任务在时间、质量与资源三者之间取得良性平衡，实现Beta阶段如期交付目标。

用户场景

典型用户场景

• 企业通过RAGnarok部署私有化实例，上传结构化/非结构化文档至私有知识库。
• 使用模块化Pipeline配置：文档检索 → 智能排序 → LLM问答生成。
• IT管理员设定访问权限，多租户模式保障不同部门数据隔离。

发布功能（发布文档）：

• 完成多租户私有化部署能力
• 实现核心模块的流水线编排（文档检索、排序、LLM问答）
• 前端完成响应式设计
• 权限控制功能上线
• 用户界面支持文档上传、问题输入、回答展示与历史记录

用户真实使用过程与评价

• 使用过程：
  • 企业用户通过私有化实例上传内部文档，配置多租户权限，使用Pipeline进行智能问答。
  • 个人用户通过网页界面上传资料，输入问题获得相关答案，并收藏查询历史。
• 用户评价：
  • B端用户： “系统部署方便，流程灵活，集成我们的OA系统后大幅提升了员工自助查询效率。”
  • C端用户： “界面简洁，问答准确度高，帮助我快速找到所需资料，极大节省了学习时间。”
  • 也收到关于部分细节优化的建议，团队已纳入后续迭代计划。

用户日活

用户日活（目标 / 实际）

• MPA-Agent（系300 人）：80 ／ 65 人·日
• 考研英语（556 人）：200 ／ 150 人·日
• C 端桌面试用（30 人）：50 ／ 25 人·日

发布推广

• 校园线下宣讲 × 2，演示扫码注册
• 系内微信群、飞书分享短视频与使用指南
• 课程作业内嵌评测（数据库原理）
• 考研群定向邀请试用
• 技术公众号软文

日活未达标原因

• 宣讲后续跟进不足
• 首次 Pipeline 配置门槛影响体验
• MPA-Agent 刚需场景有限
• C 端试用周期偏短

其他“有用”指标

• 调用次数：MPA-Agent 150 次/日，考研 200 次/日
• 次日留存：40% ／ 55%
• 会话时长：≈ 2.5 分钟
• 注册→首用转化：85% ／ 92%

功能改进反馈

支持自定义停用词列表

完形填空高频词自动标注

主要 Bug

• 中文 PDF 编码异常（已预料，优化字符集）
• 高并发超时 504（已预料，重试+限流）
• 桌面端 UI 卡顿（未预料，加强端侧性能测试）

特色功能

1. 模块化 RAG 流水线，支持插件式功能组合

• 每个核心步骤均模块化封装。
• 用户可以自由替换、增减、调整模块顺序，例如使用不同的嵌入模型或召回策略，构建个性化问答逻辑。
• 支持企业定制开发与快速扩展，极大提高适应不同业务场景的能力。

竞品差异：

• 像 Dify 等系统更注重“快速上手”和“易用性”，但其流水线结构封闭，难以拆解和定制，无法适配多样复杂需求。

2. 多租户隔离 + 私有化部署能力

• 支持企业级多租户部署，每个租户数据、模型、流程完全隔离。
• 用户数据本地存储，符合企业隐私合规要求。
• 支持内部局域网运行，零外部依赖，确保敏感信息安全。

竞品差异：

• 例如 LangChain Hub / Flowise / Dify 在多租户与权限隔离方面支持不足，难以在严苛的政企场景部署。

3. 精细化授权与权限控制机制

• 支持从用户组 → 功能模块 → 数据文档 的多级权限授权。
• 可视化管理授权策略，便于中大型团队管理。

竞品差异：

• Dify 等支持较为简单的角色控制，不具备复杂的组织结构适配能力。

4.面向 B 端的二次开发支持

• 提供完整的 SDK 和接口规范，开发者可快速封装自定义组件并无缝接入流水线。
• 插件化组件模板降低开发成本，按需扩展各类业务能力。 竞品差异：
• RAGFlow 和多数竞品的二次开发文档不完善，组件周期较长且难以深度定制。

5.原子化后端能力组件

• 后端不依赖 LlamaIndex、LangChain 等大框架，所有能力拆分为独立的原子组件（检索、向量化、排序、LLM 调用等），可按需组合部署。
• 降低框架升级风险，提升系统稳定性与可维护性。 竞品差异：
• RAGFlow 等仍耦合于特定框架，组件间边界模糊，灵活性和可维护性较弱。

原因分析

我们之所以能够实现竞品未覆盖的杀手级功能，主要得益于明确面向企业级用户的定位，在架构设计之初就考虑了模块化、权限管理、多租户隔离等复杂需求；而多数竞品如 Dify 更偏向个人或中小团队使用，出于目标用户、开发成本和复杂度控制等因素，通常不会优先实现这些功能。我们的团队在系统架构、工程实践和协同效率方面具备较强能力，能够高效落地这些高复杂度的差异化功能，体现出项目在企业级应用场景中的独特价值。

软件工程质量评估

1.文档与代码规范

• 文档完备：飞书文档库中维护了需求规格、架构设计、API 接口说明、部署与运维手册、开发者指南等。
• 代码规范：前端采用 ESLint + Prettier 统一风格，后端遵循 PEP8（Python）/GoFmt（Golang），并在 CI 中自动校验。
• 注释与示例：核心模块函数均有完整注释，示例项目和流程图帮助新成员快速理解。

2.新成员上手体验

• “零障碍”部署：仓库根目录提供 README.md（中英双语）和 CONTRIBUTING.md，包含环境依赖、Docker Compose 一键启动脚本及常见问题解答。

3.单元测试与覆盖率

• 测试用例：共计 50 条单元测试（后端 30 条，前端 20 条），覆盖核心检索、向量化、LLM 调用、Pipeline 逻辑等。
• 覆盖率：整体分支覆盖率 ≈ 82%，关键组件（向量库、LLM 模块）覆盖率 > 90%。
• 自动化校验：每次 PR 都触发测试，未通过则禁止合并。

4.CI/CD 实践

• 工具链：基于 GitHub Actions／飞书流水线，自动完成代码格式检查、单元测试、镜像构建与推送。
• 多环境部署：staging 与 production 分支分别对应不同集群，合并即触发灰度发布与回滚策略。
• 理由：提升反馈速度、减少人为失误，确保质量和交付一致性。

5.经验与教训

• 提早完善文档：Beta 阶段早期文档不足导致前后端交接踩坑，后续补齐文档显著提升上手效率。
• 严格代码审查：统一风格和注释要求，有效降低了后期维护成本。
• 测试驱动开发：尽早纳入单元测试能快速发现设计缺陷，避免线上故障。
• 模块化与原子化：将功能拆分为小组件，利于多团队并行开发与解耦；文档也按组件维护，查找更便捷。