[长文手敲] 擦桥的产品——AI文旅（其一） — cloudwide @ linux.do

情景再现

领导：小白啊，最近有x州有一个文旅项目，你去和客户对接一下，顺便维持一下客户的关系。这个客户是一个新客户，而且要做AI的产品，你去收集一下需求，然后给个内部评估的成本价，最后最好是驻场开发一下。

我：

x总你看要不先把上次差旅报销和补贴发了。

领导：小白，你要懂得奉献，你还年轻，要知道做事业是要牺牲一下小我来成就大我······

我：

那么经过嘚啵嘚，脚打屁股头颠倒的长途二等座之后，也是到了x州。

客户A：诶呀，欢迎欢迎，我们x州钟灵毓秀，山川大好，以后得多来多看。

我：x主任您客气了，我这次主要就是收集一下咱们AI文旅的一些需求。

客户A：

（你小汁）

来，小白，你看我们这里其实需求挺多的，总得需要慢慢来，你来吃饭没有，咱先去吃个饭。

我：~~走！~~

我一心热爱工作，x主任您找个人来和我对接就行了。

客户A：彳亍，那你在这里等会儿。

···

快速的等待ing——

此时一阵不明意义的鼓点响起，可惜这里没有大排档椅子

欧呦，原来是~~关中王来了~~B工来了。

客户B：你就是小白吧，你好你好。

我：B工你好，咱们今天下午从哪里开始呢？

客户B：今天下午要开个会，你也来一起参加，听一下领导对这个事情说明。

我：好好好。

···

拿起小本本参加会议。

不知名的领导A：在x州地方大力推行文旅兴业的政策下，我们要深入贯彻落实有关决策部署，紧紧围绕文旅产业高质量发展这一主线，立足本地资源禀赋和产业基础，进一步整合区域文化资源、旅游资源和特色产业资源，持续完善基础设施建设，优化公共服务供给，丰富文旅产品业态，提升品牌传播效能，切实把资源优势转化为产业优势、发展优势和竞争优势。

要坚持规划引领、项目带动、业态融合和市场运作相结合，深入挖掘地方历史文化、民俗文化、生态文化和特色文化内涵，积极推动文化、旅游、商业、农业、体育等产业协同发展，着力打造一批具有地方辨识度、市场吸引力和持续运营能力的文旅项目。

同时，我们要强化部门协同，健全工作机制，优化营商环境，加大招商引资和项目服务力度，推动重点任务落地落实，不断提升文旅产业对经济增长、就业带动和乡村振兴的支撑作用，为X州经济社会高质量发展注入新的动力。

（~~没错我就是恶意水字数~~）

···

来，小B（客户B），给大家讲讲你对我们这个项目的看法。

客户B：在我看来，AI文旅这件事，核心仍然是资源、内容、服务和运营，人工智能真正能够发挥作用的地方，是把过去散落在各部门、各景区、各平台的数据连接起来，让管理更精细，让服务更主动，让文旅资源更容易被游客看见、理解和消费。

当前不少地方的文旅信息化已经具备一定基础。景区有票务系统，交通部门有客流数据，公安和应急部门有安全监测数据，市场监管部门有商户信息，各类网络平台上还有游客评价、搜索热度和消费反馈。但这些数据往往各在各的系统里，像是几个部门分别守着几口井，井里都有水，却没有形成一张能够统一调度的水网。AI文旅要做的第一步，就是把这些基础数据治理好、标准统一好、权限划分好。

···

我：（叽里咕噜的在讲什么东西）

客户B：所以我们需要做一个既能统筹协调各个地方的数据，又能管理本地的文旅资源，并且以AI驱动的文旅系统。

我：（听君一席话，浪费两小时）

···

会议结束，我拉住B工。

我：B工，我觉得咱们还有些小细节需要再讨论讨论。

客户B：你有哪些不太懂的地方？

我：咱们的数据是从公安和市监那边拿吗，还是怎么搞？

客户B：从Excel导入，到时候会同步给你。

我：那我先设计一版效果图，然后再商量具体的内容。

客户B：那辛苦你了小白。

抽象的开头

开始动手了，既然我们的GPT这么强大，那我肯定不要自己动手。

图来！

哇咔咔，效果看起来还是不错的嘛。

那么我们接下来就是来确定一下技术栈，想快速一点的开发肯定得是上Python了，要用什么框架吗？

NONONO

直接用下面这一套

别问为什么，问就是之前写文档的时候用过的技术栈，能复制的东西就不要自己写

接下来我们看看架构，首先可以肯定的是一定要接入AI，至于到时候是做成客服还是做成Agent效果另说，那么就是传统的架构拼上AI、GIS相关的东西就行，什么网关、rabbit就往里面造就完事了。

非常好的架构图，~~使我的滨州发光旋转~~。

好了，这个做项目呢就有点像是命题作文，不同的命题其实都有相似的套路和解法。

基本工作准备完毕，来，我们继续去battle，拿一个不同业务流程的完整技术方案出来。

你过来呀！

客户B：哎呦，小白你怎么还在工作，我都要下班了

我：哦哦哦，没什么事情，我来问一点事情，你看这是我给你设计的原型图，B工你看怎么样

客户B：设计的不错，但是我还想增加一点东西···

我：今天不聊~~腿的事~~这些细节问题，咱们先确定核心的几块业务，然后我回去给你出几套技术方案

客户B：那我简单给你说一下，主要就是几个点，首先是平台中所有景区、景点、酒店、民宿、餐饮、非遗、文物、旅游线路、活动和公共服务设施啥的，都需要在这一业务线中形成统一档案和唯一编码，并且还得和现在的管理编码兼容。这个到时候通过数据包导入，得兼容一下。

然后是将静态资源档案转化为可持续管理的对象，比如嘞，我们上传的一些附件、图片等等都要做管理滴~并且我们的运营状态也能实时同步显示，主要面向文旅主管部门、县区管理人员和景区运营单位看的，这一部分呢先做一版，后面我们再给你修改。

我们这次还加了一个平台应将客流、交通和停车作为一条协同业务线的需求，这就是会上提到的统一协作（有有吗？可能是听睡着了），数据暂时从Excel导入来测试，这个后面都发给你。

还需要增加一条风险预警，差不多就是客流、交通这些全部都做进去。

还得要一个统一的服务平台给游客使用，这个就用微信小程序吧（嘶——）

还有····

我：好的好的好的（不要再有了），耽误你时间了B工。（说的这都是啥这是，这么多东西就给这么一点钱，还是先做再签，~~抓紧跑路吧~~）

（还得挣窝囊费，还是再忍忍吧）

短暂整理一下

主要的核心业务线大概就是管理景区的一些数据、运营状态、管理交通，后面还会有微信小程序啥的。

不过这个项目还好，现在已经是对接到可以说话的领导了，其他人可能插手的情况比较少。

那么先来决定一下我们的一期工程大概都要做点什么，首先是基本的框架要搭起来，然后就是做一个登录系统、权限控制、部门管理等基本的内容，然后就是主要的最重要的还是管理景区的资产和运营状态、驾驶舱的内容以及gis显示啥的，这个肯定是一期要做的事情。

然后就是一些大概率实现不了的东西就是交通管理啥的，暂时只放一个占位符，不进行任何开发。

那么最后做的就是风险预警、工单处理、小程序，小程序可以放在一期，风险预警做一个基础的框架，工单处理也是只做基础的框架，可以完成基本的功能即可，剩下的和AI相关的就放在二期里面。Agent开发通常都是需要基于一个比较成熟完善的系统来说的，现在这个还是处于搭框架的阶段。

中间边迭代边演示。

需求确认和范围管理

简单整理成为表格如下所示

第一个完整的业务，文旅资源建档与发布

管理员登录
→ 创建或导入文旅资源
→ 系统校验统一编码
→ 补充图片、附件和地图位置
→ 提交审核
→ 审核人员通过
→ 正式发布
→ 驾驶舱和地图同步展示

第二个业务，景区运营状态维护与驾驶舱联动

景区运营人员更新开放状态
→ 填写变更原因和生效时间
→ 提交状态
→ 系统记录操作日志
→ 驾驶舱更新景区状态
→ 地图图层改变状态颜色
→ 游客端读取最新开放信息

第三个业务，基础风险预警与处置

导入景区客流数据
→ 系统计算景区承载率
→ 达到规则阈值
→ 自动生成预警
→ 推送至待办中心
→ 管理人员签收
→ 填写处置结果
→ 关闭预警
→ 驾驶舱更新预警数量

然后我们根据业务的内容，将一期系统拆成七个模块：

1. 系统管理

• 用户管理
• 角色管理
• 部门管理
• 菜单管理
• 字典管理
• 登录日志
• 操作日志
• 数据权限

2. 文旅资源中心

• 景区管理
• 景点管理
• 酒店和民宿
• 非遗和文物
• 餐饮资源
• 旅游线路
• 公共服务设施
• 图片和附件管理
• Excel导入

首期重点实现景区、景点和公共服务设施，其他资源暂时先沿用统一模型或提供基础页面。

3. 景区运营中心

• 景区开放状态
• 开放时间
• 承载量
• 门票和预约信息
• 设施状态
• 运营数据填报
• 状态变更记录

4. GIS地图中心

• 景区点位
• 景区边界
• 公共设施点位
• 图层控制
• 地图查询
• 地图选点
• 地图资源展示

5. 驾驶舱

• 文旅资源总览
• 景区运营状态
• 客流趋势
• 热门景区排行
• 地图态势
• 预警统计
• 数据更新时间

6. 风险预警

• 预警规则
• 预警记录
• 预警详情
• 预警签收
• 处置记录
• 预警关闭

7. 工单和游客服务

• 工单列表
• 工单创建
• 工单分派
• 处理记录
• 基础游客端
• 景区查询
• 地图浏览
• 开放状态查询

然后简单说明一下模块之间的关系：

系统管理提供权限
文旅资源提供基础档案
景区运营维护动态状态
GIS负责空间展示
预警读取运营和客流数据
驾驶舱汇总全部业务
游客端读取已发布内容

数据来源

一期项目的数据来源

客户提供Excel数据包
后台人工录入
系统内模拟数据
地图边界和点位文件

Excel导入流程

下载模板
→ 填写数据
→ 上传文件
→ 字段校验
→ 数据预览
→ 错误提示
→ 重复数据处理
→ 确认导入
→ 生成导入报告

必须有的能力：

• 必填字段检查
• 数据类型检查
• 枚举值检查
• 统一编码检查
• 重复资源检查
• 行政区匹配
• 经纬度合法性检查
• 错误行下载
• 导入结果统计

客户发过来的数据是不能直接使用的，得挑选出来合适的字段使用，或者是我们进行预处理之后再导入系统，比如下面这个需要存入系统的字段，其他的字段都是不太必要的，后面需要的再加，或者是客户需要了再加。

数据库与原型

必须要做的原型

1. 登录页
2. 后台总览
3. 文旅资源列表
4. 资源编辑页
5. Excel导入弹窗
6. 景区运营状态页面
7. 地图资源页面
8. 预警列表
9. 预警详情
10. 工单列表
11. 驾驶舱

核心的数据实体主要包含

用户
部门
角色
权限

文旅资源
景区
景点
资源附件
资源图片
资源分类

景区运营状态
运营状态记录
客流数据
停车数据

预警规则
预警事件
预警处置记录

工单
工单处理记录

地图图层
地图要素
数据导入任务
操作审计

一些关键的关系设计

一个景区属于一个行政区域
一个景区包含多个景点
一个景区包含多个附件和图片
一个景区拥有多条运营状态记录
一个景区对应多条客流数据
一条预警规则可以生成多个预警事件
一个预警事件包含多条处置记录
一个工单可以经历多次流转

核心接口设计

POST /auth/login
GET  /users/me

GET  /tourism-resources
POST /tourism-resources
POST /tourism-resources/import
POST /tourism-resources/{id}/submit
POST /tourism-resources/{id}/approve

GET  /scenic-areas
PATCH /scenic-areas/{id}/operation-status

GET  /dashboard/overview
GET  /dashboard/map-status

GET  /alerts
POST /alerts/{id}/accept
POST /alerts/{id}/handle
POST /alerts/{id}/close

GET  /tickets
POST /tickets
POST /tickets/{id}/process

一期迭代

迭代一，基础工程

• 前后端工程初始化
• 登录
• 用户和权限
• 部门和角色
• 基础布局
• 数据库迁移
• 日志和异常处理

迭代二，资源管理

• 景区资源模型
• 资源增删改查
• 分类和字典
• 图片和附件
• Excel导入
• 审核发布

迭代三，运营与GIS

• 景区运营状态
• 承载量
• 地图选点
• 景区边界
• POI展示
• 图层控制

迭代四，驾驶舱

• 综合指标
• 地图态势
• 客流趋势
• 景区排行
• 运营状态
• 数据快照

迭代五，预警和工单

• 预警规则
• 预警生成
• 签收和处置
• 工单基础流转
• 待办中心

成本估算

内部成本 = 人员人天成本 + 差旅成本 + 服务器与模型成本（一般2g只考虑部署的时间成本） + 第三方服务成本 + 风险预留

按照一人月22天计算，然后可以大致估算出来开发时间和开发成本，我这里的计算数据就不展示出来了，大家可以自己估算一下。

风险预留也是一个大头，重点风险包括不限于：

• Excel数据质量不可控
• 小程序是否涉及认证主体和备案
• 地图服务是否有授权
• 客户临时增加字段
• 大屏指标没有真实来源
• AI二期边界不清晰
• 客户验收人员中途变化
• 交通数据长期无法提供

等等

关于需求变更

需求变更分为：

缺陷修复
原需求没有正确实现

需求优化
不改变主要工作量

新增需求
增加页面、流程、数据或接口

范围变更
影响排期、成本或架构

最重要的是范围变更，也是我们开发过程中经常遇见的，比如“小白你先把这个页面功能做了看看”“我觉得这个流程得改一改”等等，其实新增功能还是比较好预测的，主要是原有的业务变更。

交付范围

用户权限

• 用户能够正常登录和退出
• 不同角色显示不同菜单
• 县区用户不能查看其他区域受限数据
• 所有关键操作保留审计日志

文旅资源

• 支持景区资源新增、编辑、审核和发布
• 支持标准Excel模板导入
• 错误数据能够定位到具体行
• 资源能够绑定图片、附件和地图位置

景区运营

• 支持维护景区开放状态和承载量
• 状态变更能够记录历史
• 驾驶舱能够读取最新状态

GIS地图

• 能够展示景区和服务设施点位
• 能够根据区域和类型筛选
• 能够查看资源详情
• 能够定位到指定景区

驾驶舱

• 能够展示规定的核心指标
• 指标具有明确数据来源
• 地图和列表能够联动
• 页面在目标分辨率下正常显示

风险预警

• 能够配置基础阈值规则
• 测试数据满足条件时能够生成预警
• 预警能够签收、处置和关闭
• 全流程保留操作记录

工单

• 能够创建和分派工单
• 能够填写处理结果
• 能够查询处理记录
• 能够完成基本关闭流程

最后还要列出交付物：

源代码
数据库脚本
部署文件
接口文档
操作手册
管理员手册
测试报告
验收报告
培训材料
第三方依赖清单
账号权限清单
备份恢复说明
···

拆解需求到任务

那么一条合格的项目任务，需要同时满足以下条件：

1. 只有一个主要目标。
2. 只有一个直接责任人。
3. 能够独立判断完成或未完成。
4. 预计工作量原则上不超过两个工作日。
5. 明确前置依赖。
6. 明确交付物。
7. 明确验收标准。
8. 能够关联原始需求、页面、接口和测试用例。

例如，下面这条任务不合格。

完成景区管理模块

因为它并没有说明是做列表、表单、接口、数据库，还是导入、审核和权限这些内容。

所以拆解后应该变成：

创建景区资源数据库表
实现景区列表查询接口
实现景区分页查询页面
实现景区新增表单
实现景区新增接口
实现景区编辑接口
实现景区详情页面
实现景区删除权限校验
实现景区图片上传
实现景区附件关联
实现景区Excel导入模板
实现导入数据校验
实现导入错误报告下载

任务名称统一采用“动词＋业务对象＋明确结果”的格式。

推荐使用：

设计景区资源数据模型
实现景区列表查询接口
编写景区导入字段校验规则
配置景区编辑按钮权限
验证景区状态同步结果

不建议使用：

景区功能
处理地图
完善权限
优化接口
弄一下导入
其他相关工作

~~当然，你写日志可以这么搞~~

建立需求台账

拆解前，先建立需求台账。每一条客户需求都必须获得唯一编号，后续的原型、任务、接口、测试用例和验收项都与该编号关联。当然如果你使用禅道、jira、飞书、Teambition或者是其他的什么项目管理工具，就只需要专注于任务的拆解即可。

建议字段如下：

需求状态采用统一流程。

待收集
→ 待分析
→ 待确认
→ 已确认
→ 已拆解
→ 已冻结
→ 开发中
→ 已验收

未经确认的需求不能直接进入开发。开发如果听到说“这个应该很简单吧”，也不能顺手加进迭代里面去。

任务应该怎么写

项目任务建议划分为六类：

讨论
设计
开发
测试
缺陷
交付

其中，讨论和设计属于开发前置工作；开发负责产出功能；测试负责验证功能；缺陷（bug）负责修复已经确认的问题；交付负责部署、文档和验收。

一、讨论任务

讨论任务用于解决尚未明确的问题，目标是形成决定，不直接产出程序功能。

适用场景包括：

• 需求范围讨论
• 业务流程讨论
• 数据口径讨论
• 权限规则讨论
• 技术方案讨论
• 第三方接口讨论
• 验收标准讨论
• 需求变更评审

任务名称采用：

讨论 + 业务对象 + 待确定事项

例如：

讨论景区统一编码兼容方案
讨论景区运营状态流转规则
讨论客流预警阈值计算口径
讨论县区管理员数据权限范围
讨论Excel导入重复数据处理方式

讨论任务必须包含：

背景
待解决问题
参与人员
候选方案
需要作出的决定
计划完成时间

完成标准不能写成“已经开会”等，应该写成：

已经形成明确结论
已经记录未决事项
已经明确责任人
已经更新需求或设计文档
参与方已经确认会议结论

讨论任务的交付物通常是：

• 会议纪要
• 决策记录
• 需求确认单
• 方案评审结论
• 待办事项清单

没有形成结论的会议不算完成。

二、设计任务

设计任务用于将已经确认的需求转化为可以开发的方案。

设计任务可以继续划分为：

产品设计
交互设计
视觉设计
技术设计
数据设计
接口设计
测试设计
部署设计

任务名称采用：

设计 + 业务对象 + 具体成果

例如：

设计景区资源新增流程
设计景区资源列表页面
设计景区运营状态数据模型
设计Excel导入校验规则
设计客流预警规则接口
设计驾驶舱指标数据口径
设计生产环境部署拓扑

设计任务必须明确最终产物。

设计任务的完成标准包括：

设计成果已经输出
边界和异常场景已经说明
关联需求已经标记
相关开发人员已经评审
评审问题已经处理
设计结果已经进入版本管理

设计任务未完成前，不建议直接进入正式开发。

三、开发任务

开发任务用于实现一个可以验证的功能结果。

开发任务应按照前端、后端、数据、GIS、AI、运维等技术方向拆分，不能只写“开发景区管理模块”。

任务名称采用：

实现 + 业务对象 + 具体能力

例如：

实现景区资源分页查询接口
实现景区资源新增表单
实现景区图片上传功能
实现景区状态变更记录
实现Excel导入数据预览
实现驾驶舱地图点位图层
实现预警事件WebSocket推送

一个标准开发任务必须包含：

关联需求
关联设计
输入条件
实现范围
不包含范围
前置依赖
接口或数据结构
异常处理要求
权限要求
测试要求
完成标准

开发任务原则上控制在半天到两个人日以内（测试普遍稍微多一点时间，不过也是最多16h，bug和小任务可以控制在0.5~6h以内）。超过两个人日时，应继续拆分。

例如“实现景区Excel导入”应拆为：

实现Excel文件上传接口
实现模板版本校验
实现表头校验
实现必填字段校验
实现管理编码校验
实现重复数据检测
实现导入数据预览
实现错误报告下载
实现确认导入功能
实现导入批次记录

开发任务完成标准建议采用统一定义：

代码已经实现
代码已经自测
异常情况已经处理
权限校验已经实现
数据库迁移脚本已经提交
接口文档已经更新
单元测试已经通过
代码已经提交评审
评审问题已经修复
代码已经合并到目标分支

仅仅“代码写完了”不能算完成，需要进行测试，不过一般情况下覆盖不了所有的测试，而且团队人数少的情况下也没有人力进行测试。

四、测试任务

测试任务用于验证某一项需求、功能或业务流程是否符合设计和验收要求。

任务名称采用：

验证 + 业务对象 + 具体场景

例如：

验证景区资源新增流程
验证景区资源导入异常数据处理
验证县区管理员数据隔离
验证景区状态与驾驶舱联动
验证客流达到阈值后生成预警
验证WebSocket断线重连

测试任务可以分为：

单元测试
接口测试
功能测试
集成测试
权限测试
兼容性测试
性能测试
安全测试
回归测试
验收测试

每条测试任务必须包含：

测试对象
测试环境
前置条件
测试数据
执行步骤
预期结果
实际结果
关联需求
关联缺陷

测试任务的完成标准包括：

计划用例已经执行
测试结果已经记录
发现的问题已经创建缺陷
阻塞性问题已经处理
回归测试已经通过
测试报告已经更新

测试发现问题后，不直接修改原开发任务，而应创建独立缺陷任务。

五、缺陷任务

缺陷任务用于记录实际结果与已确认需求、设计或验收标准之间的偏差。

任务名称采用：

修复 + 发生位置 + 问题表现

例如：

修复景区列表区域筛选无效问题
修复Excel导入重复编码未提示问题
修复县区用户能够查看全州数据问题
修复驾驶舱断线后数据不更新问题
修复预警关闭后统计数量未刷新问题

缺陷任务必须包含：

问题描述
发现环境
复现步骤
预期结果
实际结果
影响范围
严重等级
优先级
截图或日志
初步原因
关联版本
关联需求

严重等级建议统一为：

缺陷处理流程：

新建
→ 已确认
→ 修复中
→ 待验证
→ 已关闭

特殊状态包括：

无法复现
重复缺陷
设计如此
延期处理
拒绝修复
重新打开

缺陷关闭标准：

根因已经明确
修复代码已经合并
原问题已经验证通过
关联场景已经回归
没有引入新的问题
缺陷原因和处理结果已经记录

六、交付任务

交付任务用于将开发完成的功能部署到目标环境，并形成客户能够接收和使用的成果。

任务名称采用：

部署、编写、整理、执行 + 交付对象

例如：

部署一期系统至验收环境
执行生产数据库初始化
编写后台管理员操作手册
整理一期接口文档
执行客户系统培训
整理一期验收材料
执行数据库备份恢复演练

交付任务主要包括：

环境部署
配置初始化
数据迁移
发布验证
操作文档
部署文档
测试报告
培训
验收
备份恢复
源代码移交

交付完成标准包括：

目标环境部署成功
系统健康检查通过
数据库迁移执行成功
核心业务冒烟测试通过
配置和账号完成移交
操作文档已经提供
客户培训已经完成
遗留问题已经登记
交付记录已经签字确认

任务之间的标准关系

一个功能从提出到交付，通常按照以下链路推进：

讨论任务
→ 设计任务
→ 开发任务
→ 测试任务
→ 缺陷任务
→ 回归测试
→ 交付任务

例如“景区运营状态管理”可以拆成：

讨论景区运营状态范围
讨论运营状态转换规则

设计景区状态业务流程
设计景区状态数据库结构
设计景区状态变更页面
设计景区状态接口

实现景区状态查询接口
实现景区状态变更接口
实现状态变更记录
实现后台状态变更表单
实现驾驶舱状态同步

验证景区状态正常变更
验证非法状态转换被拦截
验证县区用户数据权限
验证驾驶舱状态实时更新

修复定时状态未按时生效问题
修复状态更新后地图颜色未变化问题

部署景区状态功能至验收环境
整理景区状态操作说明

不要把任务类型和任务状态混在一起

“开发”“测试”“缺陷”是任务类型。

“待处理”“进行中”“已完成”是任务状态。

推荐任务类型：

讨论
设计
开发
测试
缺陷
交付
文档
运维

推荐任务状态：

待澄清
待处理
进行中
待评审
待联调
待测试
待验收
已完成
已阻塞
已取消

例如：

任务类型：设计
任务状态：待评审

任务类型：开发
任务状态：进行中

任务类型：缺陷
任务状态：待验证

这样才能统计：

• 本周完成了多少开发任务
• 当前有多少设计任务未评审
• 测试阶段发现了多少缺陷
• 缺陷平均修复时间是多少
• 哪类任务最容易阻塞项目

统一任务模板

每条任务至少包含以下字段：

任务编号
任务类型
任务名称
所属项目
所属迭代
关联需求
任务描述
输入条件
输出结果
不包含范围
前置依赖
负责人
协作人
预计人天
计划开始时间
计划结束时间
完成标准
验收人
当前状态
风险说明
相关文档
相关接口
相关页面
相关测试用例

任务描述模板可以统一为：

背景
为什么需要执行该任务。

目标
完成后要解决什么问题。

范围
本任务需要完成哪些内容。

非范围
本任务明确不处理哪些内容。

输入
执行任务所需的需求、设计、数据或接口。

输出
完成后必须提交哪些代码、页面、文档或结果。

依赖
开始前需要完成哪些任务。

完成标准
满足哪些可验证条件后可以关闭任务。

核心写法示例

一条任务必须回答六个问题：

为什么做
具体做什么
明确不做什么
依赖什么
产出什么
如何证明已经完成

例如：

任务名称
实现景区资源Excel表头校验

为什么做
防止客户上传错误模板后进入后续导入流程。

具体做什么
读取上传文件第一行表头，对照当前模板版本校验必填列、
列名和重复列。

明确不做什么
本任务不校验具体数据行，也不写入正式业务数据。

依赖什么
标准导入模板和字段字典已经确认。

产出什么
表头校验服务、错误码、接口响应和单元测试。

如何证明完成
正确模板校验通过；缺列、错列和重复列能够返回明确错误；
相关自动化测试全部通过。

基础平台与工程底座任务拆解

阶段目标

本阶段目标是建立后续业务开发所依赖的公共底座，使系统达到以下状态：

1. 前后端工程能够在本地、测试环境独立启动。
2. 管理后台能够完成登录、退出和身份恢复。
3. 用户、部门、角色、权限具备基础数据结构。
4. 前端具备路由守卫、按钮权限和统一请求能力。
5. 后端具备认证鉴权、异常处理、日志记录和数据库迁移能力。
6. PostgreSQL、Redis、RabbitMQ和对象存储可以通过容器启动。
7. OpenAPI可以生成前端接口类型。
8. 核心流程具备自动化测试。
9. 项目可以通过CI完成检查、测试和构建。
10. 测试环境可以重复部署，并具备基本回滚能力。

本阶段完成后，后续业务模块只需要按照既定规范增加领域模块，不需要重复建设登录、权限、异常处理、日志、部署和测试框架等。

阶段范围

本阶段包含

项目仓库和目录结构
前端基础工程
后端基础工程
数据库和缓存连接
登录认证
用户、部门、角色和权限基础模型
路由权限和按钮权限
统一请求和响应
统一异常处理
结构化日志
操作审计基础能力
OpenAPI接口生成
Docker开发环境
CI基础流水线
自动化测试基础框架
部署和开发文档

本阶段明确不包含

景区资源管理
景点、酒店、民宿和非遗管理
Excel业务数据导入
GIS地图业务
驾驶舱真实指标
风险预警业务
工单业务
游客端小程序
AI知识库
智能问答
数字导游
交通停车业务

这些内容进入后续迭代。本阶段可以预留目录和接口空间，但不能把业务开发混入基础底座。

任务分类

本阶段任务分为六类：

讨论任务
设计任务
开发任务
测试任务
缺陷任务
交付任务

讨论任务

讨论任务的目标是形成明确决定。只开会、不形成结论不能关闭任务。

讨论任务统一完成条件

已经形成书面结论
未决问题已经单独登记
结论已经明确责任人
相关文档已经更新
关键参与方已经确认
···

设计任务

1. 总体工程设计

1. 前端基础设计

1. 后端基础设计

1. 身份与权限设计

1. 测试与部署设计

设计任务和退出条件

设计文档已经完成
关键边界已经明确
异常场景已经覆盖
开发和测试人员已经评审
评审问题已经处理
最终版本已经进入版本管理

开发任务

1. 仓库和工程初始化

1. 前端基础工程

1. 前端公共能力

1. 后端基础工程

1. 用户、部门、角色和权限模型

1. 登录认证开发

1. 前端登录与权限

1. 基础管理页面

本阶段只实现能够验证权限底座的最小页面。

1. 基础设施和部署开发

1. CI基础流水线

测试任务

1. 工程基础测试

1. 登录认证测试

1. 接口和异常测试

1. 自动化和端到端测试

缺陷任务

1. 缺陷管理基础任务

1. 实际缺陷任务命名规则

修复 + 发生位置 + 问题表现

例如：

修复登录页面错误密码无提示问题
修复刷新Token后用户状态丢失问题
修复县区角色可以访问管理员路由问题
修复数据库迁移在空库执行失败问题
修复Docker环境后端健康检查异常问题

3. 缺陷处理任务链

每个缺陷应形成以下子任务或状态：

确认问题
→ 定位根因
→ 实施修复
→ 补充自动化测试
→ 执行原场景验证
→ 执行关联场景回归
→ 记录修复结果
→ 关闭缺陷

交付和文档任务

推荐执行顺序

1.范围和方案固定下来

完成任务：

DISC-001至DISC-018
DES-001至DES-OPS-006

输出：

阶段范围
认证方案
权限方案
工程结构
数据库设计
部署设计
测试方案

退出条件：

• 关键方案完成评审。
• 不存在阻塞开发的未决问题。
• 阶段边界已经确认。

2.工程骨架可运行

完成任务：

DEV-BASE
DEV-FE-001至019
DEV-BE-001至027
DEV-OPS-001至012

输出：

• 前端可以启动。
• 后端可以启动。
• 数据库和Redis可以连接。
• Docker环境可以启动。
• 健康检查可用。

3.登录和权限闭环

完成任务：

DEV-IAM
DEV-AUTH
DEV-FEAUTH
DEV-ADM

输出：

管理员可以初始化
用户可以登录和退出
身份可以刷新和恢复
菜单和路由受权限控制
基础组织和权限数据可以查询
登录和关键操作可以审计

4.质量和交付基线

完成任务：

DEV-CI
TST全部任务
BUG-MGT
DOC全部任务

输出：

• 自动化检查进入CI。
• 核心认证流程有自动化测试。
• 测试环境部署成功。
• 文档和版本完成归档。

关键路径

本阶段关键路径为：

范围确认
→ 工程架构设计
→ 仓库初始化
→ 后端数据库连接
→ IAM数据模型
→ 登录认证接口
→ 前端登录接入
→ 路由和按钮权限
→ 自动化测试
→ Docker部署
→ 阶段验收

以下任务一旦延期，会直接影响整个阶段：

DISC-005 身份认证方案
DES-IAM-001至014 权限设计
DEV-BE-006 数据库连接
DEV-IAM-007 IAM迁移
DEV-AUTH-006 登录接口
DEV-FEAUTH-003 登录接入
DEV-FEAUTH-008 路由守卫
DEV-OPS-008 Docker Compose
DEV-CI-010 后端自动化测试
TST-AUTO-008 登录E2E测试

阶段工作量参考

以下为基础估算。

推荐人员配置：

产品或项目负责人 1人
前端开发 1人
后端开发 1人
测试 0.5至1人
运维支持 0.25至0.5人

任务准入标准

一条开发任务进入“待开发”前，必须满足：

关联需求已经确认
相关设计已经评审
输入和输出已经明确
接口或数据结构已经明确
前置依赖已经完成
权限要求已经说明
异常场景已经说明
完成标准可以验证

任务完成标准

开发任务只有同时满足以下条件才能标记为完成：

代码已经实现
本地自测已经完成
异常场景已经处理
权限校验已经实现
数据库迁移已经提交
接口文档已经更新
自动化测试已经补充
代码评审已经通过
评审问题已经修复
代码已经合并
测试环境验证已经通过

不过一般情况下人比较少都是本地测测没啥大问题就直接过了，只有大厂里面才会弄得非常详细。

阶段退出标准

第一期第一步只有满足以下条件才能结束：

1. 前后端项目可以在新环境独立启动。
2. Docker Compose可以启动全部基础依赖。
3. 数据库可以从空库完成迁移。
4. 超级管理员可以通过脚本初始化。
5. 管理员可以正常登录、刷新身份和退出。
6. 无权限用户无法进入受限路由。
7. 前端按钮权限和菜单权限正常生效。
8. 后端接口完成独立权限校验。
9. 登录日志和基础操作审计能够查询。
10. OpenAPI可以生成前端接口类型。
11. CI可以完成格式、类型、测试和构建检查。
12. 登录主流程E2E测试通过。
13. 测试环境部署成功。
14. 数据库备份和恢复至少完成一次演练。
15. 阻塞级和严重级缺陷已经关闭。
16. 阶段文档已经完成。
17. 已创建基础版本标签。
18. 内部评审确认可以进入景区资源业务开发。

写在最后

已经燃尽了佬友们，写一期要掏空脑子中基本所有的梗，下一期随缘更新，~~要去刷半年小破站、xhh、dy、xhs、贴吧来努力学习烂梗~~，所有的需求我都尽量按时间完成，不会超时（maybe），后面会更新一个开源库来同步代码。

有的佬友问为什么最近水的少了，文章也不更了，主要是调岗了换了房子，之前是在总公司，平薪调到子公司了，远离了某位，换了房子主要是虽然子公司还在本地但是位置离了老远，正好之前的房子也到期了就顺势搬家了。