构建阶段工具：Jira+GitHub+CI评估集回归+预览环境

📋 Jira任务管理

用途：管理项目任务——任务分解、分配、跟踪、统计，确保项目进度可控、每个人知道做什么。

使用方法：① 项目启动时，把项目分解成史诗（Epic）→故事（Story）→任务（Task），每个任务有明确的描述、负责人、截止日期、优先级；② 用看板（Kanban）管理任务状态——待办/进行中/待评审/已完成，一目了然；③ 每天站会更新任务状态，遇到阻塞及时上报；④ 每周统计任务完成率、延期率，发现进度问题及时调整；⑤ 项目结束时，Jira记录是项目复盘的重要输入——哪些任务延期了、为什么、怎么改进。

替代工具：如果客户不用Jira，可以用飞书项目、Teambition、Trello、Notion等——工具不重要，重要的是任务分解、分配、跟踪的管理方法。

💻 GitHub代码管理

用途：管理代码版本——代码提交、分支管理、代码评审、版本发布，确保代码质量可控、版本可追溯。

最佳实践：① 分支策略：main（生产）、develop（开发）、feature/xxx（功能分支）、hotfix/xxx（热修复分支），功能开发完合入develop，测试通过后合入main；② 提交规范：每次提交有明确的信息（做了什么、为什么），不要"更新代码""fix"这种模糊的提交信息；③ 代码评审（PR Review）：代码合入前，至少一个人评审——检查代码质量、有没有bug、符不符合规范；④ 版本标签：每次发布打标签（v1.0.0、v1.1.0），版本可追溯，出问题可以回滚；⑤ 文档：README、部署文档、API文档，跟代码一起管理。

价值：① 代码版本可控，不会"改了代码找不到原来的版本"；② 代码评审提升质量，减少bug；③ 多人协作不冲突——分支管理确保多人同时开发不互相影响；④ 版本可追溯、可回滚——出了问题能快速定位和恢复。

🔄 CI评估集回归

用途：每次代码变更（改prompt、换模型、调参数、改逻辑）后，自动运行评估集，测试AI效果有没有变化——确保改代码不会"改好A坏了B"，效果可量化、可追溯。

什么是评估集：一批有代表性的测试用例（输入+期望输出），覆盖常见场景、边界场景、异常场景。评估集要跟业务专家一起准备，确保有代表性和准确性。评估集大小：简单项目100-500条，复杂项目500-2000条。

CI（持续集成）：每次代码提交到GitHub，自动触发CI流水线——运行评估集，计算准确率、召回率、响应时间等指标，跟基线（上一个版本的指标）对比。如果指标下降超过阈值（比如准确率下降>2%），CI失败，阻止代码合入，需要开发人员检查原因。

价值：① 确保改代码不影响效果——以前改prompt可能"改好了这个场景，坏了那个场景"，有了评估集回归，每次改动都能看到整体效果变化；② 效果可量化、可追溯——每个版本的效果指标都有记录，能看到效果是提升还是下降；③ 自动化，不用人工测试——以前改完代码要人工测半天，现在CI自动跑，几分钟出结果；④ 阻止质量下降——CI失败阻止合入，确保不会把效果变差的代码合入生产。

关键：评估集质量决定了CI的价值——评估集没有代表性、覆盖不全，CI通过了也不代表效果好。要花时间准备高质量的评估集，跟业务专家一起确认，定期更新（新场景、新问题加入评估集）。

👀 预览环境

用途：给客户提供一个可以随时查看项目进度、体验最新功能、给反馈的环境——不是等项目做完了才给客户看，是开发过程中随时可看，客户有参与感，问题早发现。

实现：① 用Docker/Kubernetes部署预览环境，跟生产环境隔离；② 每次代码合入develop分支，自动部署到预览环境（CI/CD）；③ 预览环境有独立的域名/地址，客户可以随时访问；④ 预览环境用测试数据（脱敏后的真实数据或模拟数据），不用生产数据；⑤ 有反馈入口——客户在预览环境中发现问题，可以直接提交反馈（截图+描述），自动创建Jira任务。

价值：① 客户有参与感——不是"FDE在黑盒里做，客户等结果"，是客户随时能看进度、体验功能、给反馈，客户有掌控感；② 问题早发现——客户在预览环境中发现问题，及时反馈，开发阶段就修复，不要等上线了才发现；③ 减少需求变更——客户随时看进度，需求理解偏差早发现、早纠正，不要等做完了才说"这不是我要的"；④ 提升客户满意度——透明、开放、客户参与，客户满意度高，后续合作顺。

注意：预览环境要跟客户说明"这是开发中的版本，不是最终版本，可能有bug、功能不完整"——不要让客户以为预览环境就是最终版本，期望管理很重要。