提示词技巧：用 “时间线” 引导大模型按步骤解决问题

一、引言：为什么需要 “时间线” 提示词？

1.1 开发者的常见痛点

很多开发者在使用大模型解决问题时，常会遇到两个问题：一是模型输出逻辑混乱，比如让写一份接口开发文档，结果模型先讲测试方法，再回头说接口定义；二是关键步骤缺失，比如让生成数据清洗流程，模型漏了 “异常值处理” 这一核心环节。

这些问题不是模型能力不足，而是提示词没有给模型明确的 “行动路径”。大模型默认会按自己的理解组织内容，而复杂任务需要分步骤推进，没有清晰的步骤引导，就容易出现逻辑断层或顺序错乱。

1.2 “时间线” 提示词的核心价值

用 “时间线” 设计提示词，能带来三个关键好处：

• 输出更有条理：模型会按时间线顺序输出内容，避免逻辑跳跃，比如写项目计划时，能严格按 “需求分析→方案设计→开发→测试” 的顺序推进。

• 步骤不遗漏：时间线会明确列出每个阶段的任务，模型不会忽略关键环节，比如数据处理时，能完整覆盖 “数据采集→清洗→转换→存储”。

• 结果更可控：开发者能通过时间线精准控制模型的输出范围，比如让模型只聚焦 “开发阶段” 的具体任务，不提前涉及上线部署内容。

二、“时间线” 提示词的基础：核心构成要素

2.1 必选要素：让时间线清晰可执行

设计 “时间线” 提示词，必须包含以下 4 个核心要素，缺一不可。

2.1.1 阶段名称

明确每个步骤的阶段标识，比如 “阶段 1：需求分析”“步骤 2：数据库设计”。阶段名称要简洁，让模型一眼能识别当前任务主题。

示例：“开发用户管理模块的时间线，包含 3 个阶段：阶段 1：接口设计、阶段 2：后端开发、阶段 3：前端联调”。

2.1.2 时间节点（可选但推荐）

给每个阶段添加时间节点，让时间线更具象，比如 “第 1-2 天：需求调研”“第 3 天：方案评审”。即使没有明确时间，也可以用 “前期”“中期”“后期” 划分。

示例：“项目上线前的准备时间线：前期（上线前 7 天）：功能测试、中期（上线前 3 天）：压力测试、后期（上线前 1 天）：环境检查”。

2.1.3 阶段任务

详细说明每个阶段要完成的具体任务，不能模糊。比如 “阶段 1：需求分析” 的任务要写清 “梳理用户核心诉求、明确功能边界、输出需求文档”。

反例：“阶段 1：做准备工作”（未说明具体准备内容，模型无法准确执行）。

正例：“阶段 1：准备工作，任务包括：1. 收集项目所需的 API 文档、2. 安装开发所需依赖（Node.js、MySQL）、3. 创建项目基础目录结构”。

2.1.4 输出要求

明确每个阶段需要输出的结果，比如 “阶段 1 输出：需求规格说明书”“阶段 2 输出：数据库表结构设计图”。输出要求越具体，模型的交付物越符合预期。

示例：“阶段 3：前端联调的输出要求：1. 完成 3 个页面（登录、列表、详情）的接口联调、2. 修复联调中发现的 5 个 BUG、3. 输出联调测试报告（包含测试用例和结果）”。

2.2 可选要素：提升时间线的精准度

根据任务复杂度，可额外添加以下要素，让时间线更完善。

2.2.1 依赖关系

说明阶段之间的依赖条件，比如 “阶段 2：后端开发，需依赖阶段 1 的接口设计文档完成后才能开始”。

示例：“时间线依赖关系：步骤 3 的‘数据入库’必须在步骤 2 的‘数据清洗’完成后执行，步骤 4 的‘报表生成’需等待步骤 3 完成”。

2.2.2 约束条件

明确每个阶段的限制要求，比如 “阶段 2：后端开发，需使用 Java 语言，基于 Spring Boot 框架”。

示例：“阶段 1：接口设计的约束条件：1. 接口格式为 RESTful、2. 响应数据格式为 JSON、3. 包含身份验证字段 token”。

三、“时间线” 提示词的设计步骤：从简单到复杂

3.1 步骤 1：拆解任务，划分阶段

首先要把复杂任务拆分成多个可执行的阶段，拆分原则是 “每个阶段只聚焦一个核心目标”。

示例：将 “开发一个待办事项 APP” 拆分为 5 个阶段：

1. 需求分析（明确功能和用户场景）

1. 技术选型（确定前后端框架、数据库）

1. 架构设计（接口、数据库、页面结构）

1. 开发实现（前后端编码、联调）

1. 测试上线（功能测试、部署上线）

拆分误区：不要把多个核心目标放在一个阶段，比如 “阶段 1：需求分析和技术选型”（两个目标混在一起，容易导致内容混乱）。

3.2 步骤 2：定义每个阶段的任务和输出

给每个阶段补充具体任务和输出物，任务要 “可操作”，输出物要 “可交付”。

示例：“待办事项 APP 开发时间线” 的阶段细节：

• 阶段 1：需求分析

任务：1. 调研同类 APP 核心功能、2. 确定本 APP 核心功能（添加、修改、删除待办）、3. 明确用户场景（个人使用、团队协作）

输出：需求文档（包含功能清单和用户场景描述）

• 阶段 2：技术选型

任务：1. 后端框架选择（对比 Spring Boot 和 Express）、2. 前端框架选择（对比 Vue 和 React）、3. 数据库选择（对比 MySQL 和 MongoDB）

输出：技术选型报告（包含选择理由和版本说明）

3.3 步骤 3：添加时间节点或依赖关系

根据任务紧急程度，添加时间节点；如果阶段之间有先后顺序，补充依赖关系。

示例：补充后的时间线：

1. 阶段 1：需求分析（时间：第 1 天，无依赖）

任务：...（同上）

输出：...（同上）

1. 阶段 2：技术选型（时间：第 2 天，依赖阶段 1 输出的需求文档）

任务：...（同上）

输出：...（同上）

1. 阶段 3：架构设计（时间：第 3-4 天，依赖阶段 2 的技术选型报告）

任务：...

输出：...

3.4 步骤 4：明确整体输出要求

最后说明整个时间线完成后，模型需要输出的整体内容，比如 “按时间线顺序，输出每个阶段的任务执行过程和最终交付物”。

示例：“整体输出要求：1. 按阶段顺序，依次描述每个阶段的任务执行步骤、2. 每个阶段末尾附上对应的输出物内容（如需求文档需包含具体功能清单）、3. 语言简洁，每个阶段的描述不超过 500 字”。

四、实战案例 1：简单任务 —— 用时间线生成数据清洗流程

4.1 需求分析

需要生成一份 “用户行为数据清洗” 的流程，数据包含用户 ID、行为类型、时间戳、设备型号，存在缺失值、重复数据和异常时间戳。

4.2 原始提示词（反面案例）

“帮我写一份用户行为数据的清洗流程，要完整一点。”

问题分析：

1. 没有拆分阶段，模型可能会混乱输出（比如先处理重复数据，再回头补缺失值）。

1. 未说明数据特点（如缺失值、异常时间戳），模型无法针对性设计步骤。

1. 未提输出要求，模型可能只给简单列表，没有具体操作方法。

4.3 优化后的 “时间线” 提示词（正面案例）

“请按以下时间线，生成用户行为数据的清洗流程，数据特点：包含用户 ID、行为类型、时间戳、设备型号，存在缺失值（约 5%）、重复数据（约 3%）、异常时间戳（超出 2024 年范围）。

时间线包含 4 个阶段，每个阶段需明确任务和输出：

1. 阶段 1：数据检查（无依赖）

任务：1. 查看数据总行数和列数、2. 检查每列的数据类型（如用户 ID 为字符串、时间戳为日期类型）、3. 统计缺失值比例和重复数据比例

输出：数据检查报告（包含数据基本信息、缺失值和重复数据统计结果）

1. 阶段 2：缺失值处理（依赖阶段 1 的检查报告）

任务：1. 针对用户 ID 缺失：删除对应行（因用户 ID 为核心标识，无法补全）、2. 针对设备型号缺失：用 “未知设备” 填充、3. 验证处理后的数据缺失值比例（需降至 0%）

输出：缺失值处理后的数据集（附处理前后的缺失值对比表）

1. 阶段 3：重复数据处理（依赖阶段 2 的数据集）

任务：1. 按 “用户 ID + 行为类型 + 时间戳” 组合判断重复数据、2. 删除完全重复的行、3. 统计删除的重复数据行数

输出：去重后的数据集（附重复数据删除统计）

1. 阶段 4：异常时间戳处理（依赖阶段 3 的数据集）

任务：1. 筛选出时间戳超出 2024 年的异常数据、2. 删除异常数据行（因时间戳错误无法修正）、3. 验证处理后的数据时间范围（确保均在 2024 年）

输出：最终清洗后的数据集（附数据清洗整体报告，包含各阶段处理结果汇总）

整体输出要求：1. 按阶段顺序描述，每个阶段先写任务执行步骤，再写输出结果、2. 步骤中需包含具体操作方法（如 “按某组合判断重复数据”）、3. 不添加额外的数据分析内容，只聚焦清洗流程。”

4.4 模型输出结果及解析

阶段 1：数据检查

任务执行步骤：

1. 加载用户行为数据集，使用 Python 的 pandas 库查看数据基本信息：通过df.shape获取数据总行数为 10000 行、4 列（用户 ID、行为类型、时间戳、设备型号）；通过df.dtypes确认数据类型：用户 ID（object）、行为类型（object）、时间戳（object，需后续转为 datetime 类型）、设备型号（object）。

1. 统计缺失值：使用df.isnull().sum()计算每列缺失值，结果为：用户 ID 缺失 500 行（5%）、行为类型无缺失、时间戳无缺失、设备型号缺失 500 行（5%）；使用df.duplicated().sum()统计重复数据为 300 行（3%）。

1. 将时间戳转为 datetime 类型（df['时间戳'] = pd.to_datetime(df['时间戳'], errors='coerce')），发现有 200 行无法转换（后续确认是超出 2024 年的异常值）。

输出：数据检查报告

项目	结果
数据规模	10000 行 × 4 列
数据类型	用户 ID（object）、行为类型（object）、时间戳（datetime，转换后）、设备型号（object）
缺失值统计	用户 ID：500 行（5%）、设备型号：500 行（5%）
重复数据统计	300 行（3%）
异常时间戳统计	200 行（无法转为 2024 年日期）

阶段 2：缺失值处理

任务执行步骤：

1. 处理用户 ID 缺失：因用户 ID 是核心标识，无法通过其他字段补全，使用df = df.dropna(subset=['用户ID'])删除 500 行缺失数据，处理后数据剩余 9500 行。

1. 处理设备型号缺失：使用df['设备型号'] = df['设备型号'].fillna('未知设备')填充缺失值，填充后设备型号列无缺失。

1. 验证缺失值：使用df.isnull().sum()检查，所有列缺失值均为 0，符合要求。

输出：缺失值处理后的数据集（9500 行）及对比表

列名	处理前缺失值	处理后缺失值	处理方式
用户 ID	500 行	0 行	删除缺失行
设备型号	500 行	0 行	填充 “未知设备”

阶段 3：重复数据处理

任务执行步骤：

1. 定义重复判断标准：按 “用户 ID + 行为类型 + 时间戳” 组合，若这三列值完全相同，则判定为重复数据。

1. 删除重复数据：使用df = df.drop_duplicates(subset=['用户ID', '行为类型', '时间戳'])，删除 300 行重复数据，处理后数据剩余 9200 行。

1. 统计结果：本次共删除重复数据 300 行，占处理前数据（9500 行）的 3.16%。

输出：去重后的数据集（9200 行）及统计

项目	结果
处理前数据量	9500 行
删除重复数据量	300 行
处理后数据量	9200 行
重复数据占比	3.16%

阶段 4：异常时间戳处理

任务执行步骤：

1. 筛选异常时间戳：定义 2024 年时间范围为 “2024-01-01 00:00:00” 至 “2024-12-31 23:59:59”，使用df = df[(df['时间戳'] >= '2024-01-01') & (df['时间戳'] <= '2024-12-31')]筛选，删除 200 行异常数据。

1. 验证时间范围：使用df['时间戳'].min()和df['时间戳'].max()确认，处理后数据时间范围为 “2024-01-02 08:30:00” 至 “2024-12-30 19:45:00”，均在 2024 年范围内。

输出：最终清洗后的数据集（9000 行）及整体报告

数据清洗整体报告

阶段	处理内容	处理前数据量	处理后数据量	处理效果
数据检查	统计缺失值、重复数据、异常值	-	10000 行	明确数据问题分布
缺失值处理	删除用户 ID 缺失行、填充设备型号	10000 行	9500 行	缺失值降至 0%
重复数据处理	按组合条件删除重复行	9500 行	9200 行	去除 300 行重复数据
异常时间戳处理	删除超出 2024 年的数据	9200 行	9000 行	时间范围符合要求

解析：优化后的提示词通过时间线明确了阶段顺序和任务要求，模型输出的流程逻辑清晰，每个阶段都有具体操作步骤和可交付的结果，没有出现步骤遗漏或顺序混乱的问题，完全符合数据清洗的实际工作流程。

五、实战案例 2：中等任务 —— 用时间线设计 API 开发流程

5.1 需求分析

需要设计 “用户登录 API” 的开发流程，要求包含接口定义、后端实现、测试验证三个核心环节，技术栈为 Node.js（Express 框架）、MySQL 数据库。

5.2 优化后的 “时间线” 提示词

“请按以下时间线，设计用户登录 API 的开发流程，技术栈：Node.js（Express）、MySQL，API 功能：用户输入用户名和密码，验证通过后返回 token。

时间线包含 3 个阶段，每个阶段需明确任务、依赖关系和输出：

1. 阶段 1：接口定义（无依赖）

任务：1. 确定 API 请求方式（POST）和路径（/api/user/login）、2. 定义请求参数（body 参数：username（字符串，必填）、password（字符串，必填））、3. 定义响应格式（成功：code=200，data={token}；失败：code=400，msg = 错误信息）、4. 定义错误码（如 1001：用户名不存在，1002：密码错误）

输出：API 接口文档（包含请求方式、路径、参数、响应格式、错误码说明）

2. 阶段 2：后端实现（依赖阶段 1 的接口文档）

任务：1. 创建 MySQL 用户表（字段：id、username、password（加密存储）、create_time）、2. 搭建 Express 项目（初始化项目、安装依赖：express、mysql2、jsonwebtoken、bcrypt）、3. 编写接口逻辑（接收请求参数、查询数据库验证用户名、用 bcrypt 比对密码、生成 JWT token 返回）、4. 处理异常（用户名不存在、密码错误时返回对应错误码）

输出：1. MySQL 用户表 SQL 脚本、2. 完整的接口代码（含路由、业务逻辑、数据库连接）、3. 项目依赖清单（package.json）

3. 阶段 3：测试验证（依赖阶段 2 的接口代码）

任务：1. 准备测试数据（在 MySQL 中插入测试用户，username=test，password=123456（加密后存储））、2. 使用 Postman 测试接口（测试成功场景：输入正确用户名密码，获取 token；测试失败场景：用户名不存在、密码错误，验证错误码）、3. 检查 token 有效性（解析 token，确认包含用户名等关键信息）、4. 记录测试结果，修复发现的问题（如密码比对逻辑错误）

输出：1. 测试用例文档（含测试场景、输入、预期输出）、2. 测试结果报告（含成功 / 失败案例截图说明）、3. 修复后的最终接口代码

整体输出要求：1. 每个阶段按 “任务执行步骤→输出物详情” 的格式描述、2. 代码需添加关键注释（如数据库连接配置、token 生成逻辑）、3. 明确每个阶段的依赖条件，确保流程可衔接。”

5.3 模型输出结果及解析

阶段 1：接口定义

任务执行步骤：

1. 确定 API 基础信息：请求方式为 POST（因需传递敏感密码信息，POST 比 GET 更安全），接口路径定义为/api/user/login，符合 RESTful 接口规范。

1. 定义请求参数：采用 JSON 格式传递 body 参数，必填项为username（字符串，长度 1-20 位，用于标识用户）和password（字符串，长度 6-20 位，用户登录密码），参数需做非空校验。

1. 设计响应格式：

• • 成功响应（HTTP 状态码 200）：{"code":200,"msg":"登录成功","data":{"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...","expireTime":"2024-12-31 23:59:59"}}

• • 失败响应（HTTP 状态码 400）：{"code":400,"msg":"登录失败","errorCode":1001,"errorMsg":"用户名不存在"}

1. 定义错误码：1001（用户名不存在）、1002（密码错误）、1003（参数缺失，如未传 username），每个错误码对应唯一错误信息，便于前端定位问题。

输出：API 接口文档

用户登录 API 接口文档

1. 基础信息

• 请求方式：POST

• 接口路径：/api/user/login

• 接口描述：用户输入用户名和密码，验证通过后返回 JWT token

• Content-Type：application/json

2. 请求参数（Body）

参数名	类型	是否必填	长度限制	说明
username	string	是	1-20 位	用户登录名
password	string	是	6-20 位	用户登录密码

3. 响应格式

3.1 成功响应（200 OK）

{

"code": 200,

"msg": "登录成功",

"data": {

"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...", // JWT token，有效期24小时

"expireTime": "2024-12-31 23:59:59" // token过期时间

}

}

3.2 失败响应（400 Bad Request）

// 用户名不存在

{

"code": 400,

"msg": "登录失败",

"errorCode": 1001,

"errorMsg": "用户名不存在"

}

// 密码错误

{

"code": 400,

"msg": "登录失败",

"errorCode": 1002,

"errorMsg": "密码错误"

}

// 参数缺失

{

"code": 400,

"msg": "登录失败",

"errorCode": 1003,

"errorMsg": "用户名或密码不能为空"

}

4. 错误码说明

错误码	错误信息	解决方案
1001	用户名不存在	检查用户名是否输入正确
1002	密码错误	重新输入正确密码
1003	用户名或密码不能为空	确保 username 和 password 均已传递

阶段 2：后端实现

任务执行步骤：

1. 创建 MySQL 用户表：

• • 设计表结构：id（主键，自增）、username（唯一，非空）、password（非空，存储 bcrypt 加密后的密码）、create_time（默认当前时间）。

• • 编写 SQL 脚本：CREATE TABLE users (id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(20) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP);

1. 搭建 Express 项目：

• • 初始化项目：执行npm init -y生成 package.json，执行npm install express mysql2 jsonwebtoken bcrypt cors安装依赖（cors 用于解决跨域问题）。

• • 创建项目结构：新建 src 目录，包含 config（数据库配置）、routes（路由）、services（业务逻辑）、app.js（入口文件）。

1. 编写核心代码：

• • 数据库配置（src/config/db.js）：配置 MySQL 连接信息（host、user、password、database），使用 mysql2 创建连接池。

• • 业务逻辑（src/services/userService.js）：编写login方法，接收 username 和 password，查询 users 表，用 bcrypt.compare 比对密码，验证通过则生成 token。

• • 路由（src/routes/userRoutes.js）：定义 POST /api/user/login 路由，接收请求参数，调用 userService.login，返回响应结果（成功返回 token，失败返回错误码）。

• • 入口文件（src/app.js）：引入 express、cors，配置中间件，挂载路由，启动服务（监听 3000 端口）。

1. 异常处理：在路由中添加参数校验，若 username 或 password 为空，返回 1003 错误；在 service 中，若查询不到用户，返回 1001 错误，密码比对失败返回 1002 错误。

输出：

1. MySQL 用户表 SQL 脚本

-- 用户表创建脚本

CREATE TABLE users (

id INT AUTO_INCREMENT PRIMARY KEY,

username VARCHAR(20) NOT NULL UNIQUE COMMENT '用户登录名',

password VARCHAR(100) NOT NULL COMMENT 'bcrypt加密后的密码',

create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间'

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

-- 插入测试数据（password：123456，加密后为$2b$10$...）

INSERT INTO users (username, password)

VALUES ('test', '$2b$10$EixZaYb05a2W728x49z5bu8G9G7h8F6j7K6L5M4N3O2P1Q0R9S8T7U6V5W4X3Y2Z1');

1. 核心接口代码（示例：src/services/userService.js）

const db = require('../config/db');

const bcrypt = require('bcrypt');

const jwt = require('jsonwebtoken');

// JWT密钥（实际项目中应放在环境变量）

const JWT_SECRET = 'your_jwt_secret_key';

// token有效期（24小时）

const JWT_EXPIRES_IN = '24h';

/**

* 用户登录业务逻辑

* @param {string} username - 用户名

* @param {string} password - 密码

* @returns {Promise<Object>} - 登录结果（含token或错误信息）

*/

const login = async (username, password) => {

try {

// 1. 查询用户

const [rows] = await db.query('SELECT id, username, password FROM users WHERE username = ?', [username]);

if (rows.length === 0) {

// 用户名不存在

return { success: false, errorCode: 1001, errorMsg: '用户名不存在' };

}

const user = rows[0];

// 2. 比对密码（bcrypt比对加密后的密码）

const isPasswordValid = await bcrypt.compare(password, user.password);

if (!isPasswordValid) {

// 密码错误

return { success: false, errorCode: 1002, errorMsg: '密码错误' };

}

// 3. 生成JWT token（包含用户id和username）

const token = jwt.sign(

{ id: user.id, username: user.username },

JWT_SECRET,

{ expiresIn: JWT_EXPIRES_IN }

);

// 4. 计算token过期时间

const expireTime = new Date(Date.now() + 24 * 60 * 60 * 1000).toISOString().slice(0, 19).replace('T', ' ');

// 登录成功

return { success: true, data: { token, expireTime } };

} catch (error) {

console.error('登录失败：', error);

return { success: false, errorCode: 500, errorMsg: '服务器内部错误' };

}

};

module.exports = { login };

1. 项目依赖清单（package.json 片段）

{

"name": "user-login-api",

"version": "1.0.0",

"dependencies": {

"bcrypt": "^5.1.1",

"cors": "^2.8.5",

"express": "^4.18.2",

"jsonwebtoken": "^9.0.2",

"mysql2": "^3.6.5"

},

"scripts": {

"start": "node src/app.js"

}

}

阶段 3：测试验证

任务执行步骤：

1. 准备测试环境：

• • 执行 MySQL 用户表 SQL 脚本，创建 users 表并插入测试用户（username=test，password=123456）。

• • 启动 Express 服务：执行npm start，服务运行在http://localhost:3000。

1. 设计测试用例：

• • 用例 1：成功登录（输入正确 username=test，password=123456）。

• • 用例 2：用户名不存在（输入 username=nonexist，password=123456）。

• • 用例 3：密码错误（输入 username=test，password=wrongpass）。

• • 用例 4：参数缺失（只传 username，不传 password）。

1. 使用 Postman 执行测试：

• • 配置请求：POST http://localhost:3000/api/user/login，Body 选 raw-JSON，填写参数。

• • 执行用例 1：返回 code=200，data 包含 token，解析 token 确认包含 id 和 username。

• • 执行用例 2：返回 code=400，errorCode=1001，errorMsg = 用户名不存在。

• • 执行用例 3：返回 code=400，errorCode=1002，errorMsg = 密码错误。

• • 执行用例 4：返回 code=400，errorCode=1003，errorMsg = 用户名或密码不能为空。

1. 修复问题：测试中发现 “密码比对逻辑中，bcrypt 版本兼容问题导致比对失败”，升级 bcrypt 至最新版本（5.1.1）后修复，重新执行用例 3，测试通过。

输出：

1. 测试用例文档

用户登录 API 测试用例

测试环境

• 接口地址：http://localhost:3000/api/user/login

• 测试工具：Postman

• 测试数据：用户 test（password=123456）

测试用例清单

用例 ID	测试场景	输入参数（JSON）	预期输出	测试结果
TC001	成功登录	{"username":"test","password":"123456"}	code=200，返回 token 和 expireTime	通过
TC002	用户名不存在	{"username":"nonexist","password":"123456"}	code=400，errorCode=1001，提示用户名不存在	通过
TC003	密码错误	{"username":"test","password":"wrongpass"}	code=400，errorCode=1002，提示密码错误	通过（修复后）
TC004	参数缺失（无 password）	{"username":"test"}	code=400，errorCode=1003，提示参数不能为空	通过

1. 测试结果报告（含截图说明）

• 截图 1（TC001 成功登录）：Postman 响应界面，显示 code=200，data 包含 token，expireTime 为 24 小时后时间。

• 截图 2（TC002 用户名不存在）：响应显示 errorCode=1001，errorMsg = 用户名不存在。

• 截图 3（TC003 密码错误修复前）：响应显示 errorCode=500（bcrypt 版本问题），修复后显示 errorCode=1002。

• 截图 4（TC004 参数缺失）：响应显示 errorCode=1003，提示用户名或密码不能为空。

1. 修复后的最终接口代码（src/services/userService.js，仅修改依赖引入）

// 修复bcrypt引入路径（若有必要）

const bcrypt = require('bcrypt');

// 其他代码不变...

解析：通过时间线划分 “接口定义→后端实现→测试验证” 三个阶段，模型输出的开发流程完全贴合实际开发顺序，每个阶段的任务和输出物都可直接落地。依赖关系的明确（如后端实现依赖接口文档）确保了流程的连贯性，测试阶段的问题修复也体现了真实开发中的迭代过程。

六、实战案例 3：复杂任务 —— 用时间线规划小型项目开发

6.1 需求分析

需要规划 “小型电商商品管理系统” 的开发流程，系统包含商品列表、添加商品、编辑商品、删除商品 4 个功能，技术栈为 Vue3（前端）、Spring Boot（后端）、MySQL（数据库），开发周期为 10 天，团队含 2 名前端、2 名后端、1 名测试。

6.2 优化后的 “时间线” 提示词

“请按以下时间线，规划小型电商商品管理系统的开发流程，技术栈：Vue3（Vite）、Spring Boot 3.x、MySQL 8.0，功能：商品列表（分页查询）、添加商品（表单提交）、编辑商品（回显 + 更新）、删除商品（单个删除 + 批量删除），开发周期 10 天，团队配置：2 前端、2 后端、1 测试。

时间线包含 5 个阶段，每个阶段需明确时间节点、任务分工、交付物、依赖关系：

1. 阶段 1：需求分析与方案设计（第 1 天，无依赖）

任务分工：

• • 产品：梳理功能清单，明确每个功能的交互逻辑（如商品列表需支持按名称搜索、按价格排序）

• • 前后端：共同评审功能，确定接口交互方式（RESTful）

• • 测试：根据功能清单编写测试点（如添加商品需校验 “商品名称非空”“价格为正数”）

交付物：1. 功能需求文档（含功能清单、交互流程图）、2. 接口文档初稿（含请求方式、参数、响应格式）、3. 测试点清单（按功能模块划分）

依赖关系：无（项目启动阶段，无需依赖其他阶段输出）

1. 阶段 2：架构设计与环境搭建（第 2 天，依赖阶段 1 的需求文档）

任务分工：

• • 后端 1：设计 MySQL 数据库表（商品表：id、name、price、stock、create_time、update_time），编写 SQL 脚本；搭建 Spring Boot 项目（配置 application.yml、引入依赖：spring-boot-starter-web、spring-boot-starter-data-jpa、mysql-connector-java）

• • 后端 2：设计项目包结构（controller、service、repository、entity、dto），定义全局异常处理类和统一响应格式

• • 前端 1：搭建 Vue3 项目（使用 Vite 初始化，安装依赖：vue-router、axios、element-plus、pinia），设计路由结构（/goods/list、/goods/add、/goods/edit）

• • 前端 2：设计组件结构（GoodsList.vue、GoodsForm.vue、CommonTable.vue），配置 axios 请求拦截器（处理 token、统一错误提示）

交付物：1. MySQL 商品表 SQL 脚本、2. 后端项目初始化代码（含配置文件、包结构）、3. 前端项目初始化代码（含路由、组件结构、axios 配置）

依赖关系：需阶段 1 的功能需求文档确认数据字段（如商品表需包含 price、stock 字段）

1. 阶段 3：核心功能开发（第 3-7 天，共 5 天，依赖阶段 2 的架构设计）

任务分工（按功能模块并行开发）：

• • 商品列表功能（第 3-4 天）：

• • • 后端：编写 GoodsController 的 list 接口（支持分页参数 pageNum、pageSize，搜索参数 name），Service 层实现分页查询逻辑，Repository 层调用 JPA 实现数据库操作

• • • 前端：开发 GoodsList.vue 组件（渲染表格、实现分页控件、搜索框功能，调用后端 list 接口加载数据）

• • 添加 / 编辑商品功能（第 5-6 天）：

• • • 后端：编写 GoodsController 的 add 接口（POST，接收商品信息）和 update 接口（PUT，接收商品 ID 和更新信息），Service 层实现数据校验（name 非空、price>0、stock≥0）和保存逻辑

• • • 前端：开发 GoodsForm.vue 组件（表单布局、字段校验、提交按钮，新增时调用 add 接口，编辑时调用 update 接口并回显数据）

• • 删除商品功能（第 7 天）：

• • • 后端：编写 GoodsController 的 delete 接口（DELETE，支持单个 ID 删除）和 batchDelete 接口（DELETE，接收 ID 数组，支持批量删除）

• • • 前端：在 GoodsList.vue 中添加删除按钮（单个删除）和批量选择框（批量删除），调用对应接口，删除后刷新列表

• • 测试：同步跟进开发进度，每天针对已完成功能编写测试用例（如商品列表分页测试、添加商品字段校验测试）

交付物：1. 后端完整接口代码（含 Controller、Service、Repository）、2. 前端完整组件代码（含列表、表单、删除功能）、3. 每日测试用例（按功能模块整理）

依赖关系：需阶段 2 的项目环境（后端能正常连接数据库，前端能正常调用接口）

1. 阶段 4：联调与问题修复（第 8-9 天，共 2 天，依赖阶段 3 的核心功能代码）

任务分工：

• • 前后端联调：

• • • 后端：提供接口测试地址，协助前端定位接口调用问题（如参数格式错误、响应码异常），修复 Service 层数据校验逻辑漏洞（如未处理 stock 为负数的情况）

• • • 前端：调试所有功能的接口调用（如分页参数传递错误、编辑时未传商品 ID），修复 UI 显示问题（如表格列对齐、表单提交按钮禁用逻辑）

• • 测试：执行完整测试用例（覆盖所有功能场景，如添加商品时 name 为空、price 为 0 的错误提示，批量删除选择多个商品），记录 BUG 并提交给开发人员

• • 开发：修复测试发现的 BUG（如后端批量删除接口未处理 ID 数组为空的情况，前端搜索框输入中文后接口无响应）

交付物：1. 联调报告（记录联调中发现的问题及解决方案）、2. BUG 修复清单（含 BUG 描述、修复人、修复时间）、3. 测试通过的功能版本（前后端代码）

依赖关系：需阶段 3 的核心功能代码可运行（如后端接口能返回正确数据，前端组件能渲染页面）

1. 阶段 5：验收测试与部署（第 10 天，依赖阶段 4 的 BUG 修复版本）

任务分工：

• • 测试：执行最终验收测试（按完整业务流程测试，如 “进入列表→添加商品→编辑商品→删除商品”），生成验收测试报告（含测试通过率、剩余未修复 BUG）

• • 后端：打包 Spring Boot 项目为 JAR 包，配置服务器数据库（执行 SQL 脚本创建表，插入测试数据），部署 JAR 包并启动服务

• • 前端：打包 Vue 项目为 dist 文件夹，将 dist 文件部署到 Nginx 服务器，配置 Nginx 反向代理指向后端接口地址

• • 产品：确认所有功能符合需求文档（如商品列表支持搜索、删除有确认提示）

交付物：1. 验收测试报告（测试通过率需达到 100%）、2. 后端 JAR 包和数据库脚本、3. 前端 dist 文件夹和 Nginx 配置文件、4. 部署文档（含服务器地址、启动命令、访问地址）

依赖关系：需阶段 4 的 BUG 修复版本（所有关键 BUG 已修复，不影响核心功能使用）

整体输出要求：1. 每个阶段按 “时间节点→任务分工→交付物→依赖关系” 的格式描述、2. 任务分工需明确到具体角色（如后端 1、前端 2）和具体操作（如编写 XX 接口、开发 XX 组件）、3. 交付物需可落地（如代码需包含关键逻辑，文档需包含具体内容）、4. 明确各阶段之间的依赖，避免流程断层。”

6.3 模型输出结果及解析

阶段 1：需求分析与方案设计（第 1 天）

任务分工执行细节：

1. 产品梳理功能清单：

• • 商品列表：支持分页（每页 10 条数据）、按商品名称模糊搜索、按价格升序 / 降序排序，表格显示字段：ID、商品名称、价格、库存、创建时间。

• • 添加商品：表单包含商品名称（必填）、价格（必填，需 > 0）、库存（必填，需≥0），提交后跳回列表并刷新数据。

• • 编辑商品：点击列表 “编辑” 按钮，跳转至表单页面，回显当前商品信息，修改后提交更新。

• • 删除商品：支持单个删除（点击 “删除” 按钮，弹出确认提示）和批量删除（勾选多个商品，点击 “批量删除” 按钮）。

• • 绘制交互流程图：用 Visio 绘制 “用户进入列表→搜索商品→添加商品→编辑商品→删除商品” 的完整流程，标注每个步骤的触发条件（如点击 “添加” 按钮跳转表单）。

1. 前后端评审接口交互：

• • 确认所有接口采用 RESTful 风格：列表（GET /api/goods）、添加（POST /api/goods）、编辑（PUT /api/goods/{id}）、单个删除（DELETE /api/goods/{id}）、批量删除（DELETE /api/goods/batch）。

• • 定义分页查询参数：pageNum（默认 1）、pageSize（默认 10）、name（搜索关键词，非必填）；统一响应格式：{"code":200,"msg":"成功","data":{...}}，错误响应：{"code":400,"msg":"参数错误","error":"价格必须大于0"}。

1. 测试编写测试点：

• • 商品列表：测试分页（第 1 页显示 10 条，点击第 2 页加载下 10 条）、搜索（输入 “手机” 显示名称含 “手机” 的商品）、排序（点击价格列，数据按升序 / 降序排列）。

• • 添加商品：测试必填项（不填名称提交，提示 “商品名称不能为空”）、价格校验（输入 0 或负数，提示 “价格必须大于 0”）、库存校验（输入负数，提示 “库存不能小于 0”）。

• • 编辑商品：测试回显（进入编辑页，名称、价格、库存显示当前商品数据）、更新（修改价格后提交，列表中对应商品价格更新）。

• • 删除商品：测试单个删除（删除后列表中该商品消失）、批量删除（勾选 3 个商品删除，列表中对应 3 个商品消失）、确认提示（点击删除后弹出 “确定要删除吗？” 提示）。

交付物：

1. 功能需求文档（核心内容）：

• • 1.1 项目概述：小型电商商品管理系统，用于管理商品信息（添加、编辑、删除、查询）。

• • 1.2 功能清单：含商品列表、添加商品、编辑商品、删除商品 4 个模块，每个模块的详细功能描述（如列表支持分页和搜索）。

• • 1.3 交互流程图：附 Visio 导出的 PNG 图片，标注每个步骤的触发动作和跳转关系。

• • 1.4 数据字段说明：商品信息包含 ID（唯一标识）、name（商品名称）、price（价格，保留 2 位小数）、stock（库存）、create_time（创建时间）、update_time（更新时间）。

1. 接口文档初稿：

• • 2.1 商品列表接口（GET /api/goods）：

• • • 参数：pageNum（int，可选，默认 1）、pageSize（int，可选，默认 10）、name（string，可选，搜索关键词）。

• • • 成功响应：{"code":200,"msg":"成功","data":{"total":100,"list":[{"id":1,"name":"手机","price":2999.00,"stock":50,"create_time":"2024-09-01 10:00:00"},...],"pageNum":1,"pageSize":10}}。

• • 2.2 其他接口（添加、编辑、删除）：暂定义请求方式和核心参数，待后续细化。

1. 测试点清单（按模块划分）：

• • 商品列表模块（5 个测试点）、添加商品模块（4 个测试点）、编辑商品模块（3 个测试点）、删除商品模块（3 个测试点），每个测试点含 “测试场景”“预期结果”（如测试场景：添加商品时价格输入 0，预期结果：提示 “价格必须大于 0”）。

阶段 2：架构设计与环境搭建（第 2 天）

任务分工执行细节：

1. 后端 1 设计数据库与搭建项目：

• • 编写商品表 SQL 脚本：

CREATE TABLE goods (

id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT '商品ID',

name VARCHAR(100) NOT NULL COMMENT '商品名称',

price DECIMAL(10,2) NOT NULL COMMENT '商品价格（保留2位小数）',

stock INT NOT NULL DEFAULT 0 COMMENT '商品库存',

create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',

update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',

CONSTRAINT ck_goods_price CHECK (price > 0),

CONSTRAINT ck_goods_stock CHECK (stock >= 0)

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品表';

• • 搭建 Spring Boot 项目：

• • • 用 Spring Initializr 生成项目，选择依赖：Spring Web、Spring Data JPA、MySQL Driver、Lombok（简化代码）。

• • • 配置 application.yml：

spring:

datasource:

url: jdbc:mysql://localhost:3306/ecommerce?useSSL=false&serverTimezone=UTC

username: root

password: 123456

driver-class-name: com.mysql.cj.jdbc.Driver

jpa:

hibernate:

ddl-auto: update # 自动更新表结构（开发环境）

show-sql: true # 打印SQL语句

properties:

hibernate:

format_sql: true # 格式化SQL

server:

port: 8080 # 后端服务端口

1. 后端 2 设计包结构与统一响应：

• • 包结构：com.ecommerce.goods → controller（GoodsController）、service（GoodsService、impl/GoodsServiceImpl）、repository（GoodsRepository）、entity（GoodsEntity）、dto（GoodsDTO、PageDTO）、exception（GlobalExceptionHandler、BusinessException）、common（Result、CodeEnum）。

• • 统一响应 Result 类：

package com.ecommerce.goods.common;

import lombok.AllArgsConstructor;

import lombok.Data;

import lombok.NoArgsConstructor;

@Data

@NoArgsConstructor

@AllArgsConstructor

public class Result<T> {

private Integer code; // 状态码：200成功，400错误

private String msg; // 提示信息

private T data; // 响应数据

// 成功响应（带数据）

public static <T> Result<T> success(T data) {

return new Result<>(CodeEnum.SUCCESS.getCode(), CodeEnum.SUCCESS.getMsg(), data);

}

// 错误响应（带错误信息）

public static <T> Result<T> error(Integer code, String msg) {

return new Result<>(code, msg, null);

}

}

• • 全局异常处理类：捕获 BusinessException（业务异常），返回错误响应（如价格小于 0 时抛出异常，返回 code=400，msg=“价格必须大于 0”）。

1. 前端 1 搭建 Vue 项目与路由：

• • 用 Vite 初始化项目：执行npm create vite@latest goods-management -- --template vue，安装依赖：npm install vue-router@4 axios element-plus @element-plus/icons-vue pinia。

• • 配置路由（src/router/index.js）：

import { createRouter, createWebHistory } from 'vue-router';

import GoodsList from '../views/GoodsList.vue';

import GoodsForm from '../views/GoodsForm.vue';

const routes = [

{ path: '/', redirect: '/goods/list' },

{ path: '/goods/list', name: 'GoodsList', component: GoodsList },

{ path: '/goods/add', name: 'GoodsAdd', component: GoodsForm },

{ path: '/goods/edit/:id', name: 'GoodsEdit', component: GoodsForm } // 编辑路由，带ID参数

];

const router = createRouter({

history: createWebHistory(),

routes

});

export default router;

1. 前端 2 设计组件与 axios 配置：

• • 组件结构：src/views（GoodsList.vue、GoodsForm.vue）、src/components（CommonTable.vue，可复用表格组件）、src/api（goodsApi.js，封装接口调用）。

• • axios 配置（src/utils/request.js）：

import axios from 'axios';

import { ElMessage } from 'element-plus';

// 创建axios实例

const request = axios.create({

baseURL: 'http://localhost:8080/api', // 后端接口基础路径

timeout: 5000

});

// 请求拦截器：添加token（若有）

request.interceptors.request.use(

(config) => {

// 开发阶段暂不处理token，后续可添加localStorage.getItem('token')

return config;

},

(error) => {

return Promise.reject(error);

}

);

// 响应拦截器：统一错误处理

request.interceptors.response.use(

(response) => {

return response.data; // 直接返回响应体中的data

},

(error) => {

ElMessage.error(error.response?.data?.msg || '请求失败，请重试');

return Promise.reject(error);

}

);

export default request;

交付物：

1. MySQL 商品表 SQL 脚本（含字段约束，如 price>0、stock≥0）。

1. 后端项目初始化代码：含 application.yml 配置、包结构、Result 类、GlobalExceptionHandler 类，可直接运行（需本地 MySQL 创建 ecommerce 数据库）。

1. 前端项目初始化代码：含路由配置、axios 拦截器、组件结构，运行npm run dev可看到空白路由页面。

阶段 3-5 核心功能开发、联调修复、验收部署（关键输出摘要）

• 阶段 3 核心交付物：后端 GoodsController 完整代码（含 list、add、update、delete、

  batchDelete 接口实现）、前端 GoodsList.vue 和 GoodsForm.vue 完整代码（含表格渲染、表单校验、删除逻辑）、每日测试用例（如第 3 天商品列表分页测试用例，含 “pageNum=1 时显示 10 条数据”“pageNum=2 时显示第 11-20 条数据” 等场景）。

• 阶段 4 核心交付物：联调报告（记录 “前端分页参数 pageNum 传递为字符串类型，后端无法识别” 等问题，解决方案为 “前端将 pageNum 转为数字类型后传递”）、BUG 修复清单（如 “后端批量删除接口未处理 ID 数组为空，修复后返回 code=400 提示‘请选择要删除的商品’”）、测试通过的前后端代码（所有功能接口调用正常，UI 显示无异常）。
• 阶段 5 核心交付物：验收测试报告（测试用例共 15 条，通过率 100%，无未修复 BUG）、后端 goods-management-1.0.jar 包、前端 dist 文件夹、Nginx 配置文件（含反向代理配置：location /api/ { proxy_pass http://localhost:8080/api/; }）、部署文档（服务器地址：192.168.1.100，后端启动命令：java -jar goods-management-1.0.jar，前端访问地址：http://192.168.1.100:80）。

• 解析：通过时间线将 10 天的项目开发拆分为 5 个阶段，每个阶段明确任务分工、交付物和依赖关系，模型输出的内容完全贴合实际项目开发流程。并行开发（如阶段 3 按功能模块分工）和同步测试的设计，符合小型团队的高效协作模式，交付物可直接用于项目落地，避免了 “纸上谈兵”。

  七、“时间线” 提示词的优化技巧：让模型输出更精准

  7.1 按任务复杂度调整阶段颗粒度

  阶段拆分的粗细要根据任务复杂度决定，避免 “过粗” 或 “过细”。

  7.1.1 简单任务：阶段可合并

  简单任务（如数据清洗、单接口开发）无需拆分为多个阶段，可将 “任务执行→结果验证” 合并为 1-2 个阶段。

  示例：“生成 Python 数据去重脚本的时间线（1 个阶段）：阶段 1：任务（1. 读取 CSV 文件、2. 按‘用户 ID’列去重、3. 保存为新 CSV 文件）、输出（去重后的 CSV 文件和去重统计报告）”。

  7.1.2 复杂任务：阶段需细分

  复杂任务（如项目开发、系统部署）要拆分为多个细粒度阶段，每个阶段聚焦单一目标。

  反例：“项目开发时间线（1 个阶段）：阶段 1：完成需求分析、开发、测试、部署”（阶段过粗，模型无法明确各环节顺序和任务）。

  正例：“项目开发时间线（4 个阶段）：阶段 1：需求分析、阶段 2：开发实现、阶段 3：测试验证、阶段 4：部署上线”（每个阶段目标单一，逻辑清晰）。

  7.2 明确阶段间的依赖关系

  清晰的依赖关系能避免模型 “跳过前置步骤”，确保流程连贯。

  7.2.1 强依赖：必须前置阶段完成

  若阶段 B 必须在阶段 A 完成后才能开始，需明确标注 “阶段 B 依赖阶段 A 的输出”。

  示例：“阶段 2：接口开发，依赖阶段 1 的接口文档（需根据文档定义的参数和响应格式编写代码）”。

  7.2.2 弱依赖：可并行推进

  若阶段 B 只需阶段 A 的部分输出，或可与阶段 A 并行推进，需标注 “阶段 B 可与阶段 A 并行，依赖阶段 A 的 XX 输出”。

  示例：“阶段 3：前端页面开发，可与阶段 2 的后端接口开发并行，仅依赖阶段 1 的接口文档（明确页面需调用的接口路径）”。

  7.3 加入 “约束条件”：减少模型自由发挥

  在时间线中添加约束条件，能限制模型的输出范围，避免偏离需求。

  7.3.1 技术栈约束

  明确任务需使用的技术栈，避免模型使用其他工具或框架。

  示例：“阶段 2：后端开发，约束条件（1. 使用 Java 语言、Spring Boot 3.x 框架、2. 数据库操作使用 MyBatis、3. 不使用 NoSQL 数据库）”。

  7.3.2 输出格式约束

  规定交付物的格式，确保输出结果可直接使用。

  示例：“阶段 1：需求分析，输出约束（1. 功能需求文档使用 Markdown 格式、2. 包含‘功能清单’‘交互流程图’‘数据字段说明’三个章节、3. 流程图使用 Mermaid 语法绘制）”。

  7.3.3 质量标准约束

  明确输出结果的质量要求，避免模型生成 “低质量内容”。

  示例：“阶段 3：测试用例编写，质量约束（1. 每个功能至少包含 3 个测试场景、2. 覆盖正常场景和异常场景、3. 测试用例需包含‘输入’‘预期输出’‘实际输出’三列）”。

  7.4 使用 “示例引导”：降低模型理解成本

  对复杂阶段，提供简单示例，让模型明确 “该做什么”“怎么做”。

  7.4.1 任务示例

  若阶段任务较复杂，可给出任务执行的简单示例，引导模型按示例逻辑推进。

  示例：“阶段 1：数据统计，任务（1. 统计各商品的销量总和、2. 按销量降序排序、3. 输出 Top10 商品），任务示例（以‘商品 A’为例：销量总和 = 1 月销量 + 2 月销量 = 100+150=250）”。

  7.4.2 输出示例

  若交付物格式较特殊，可给出输出示例，让模型按示例格式生成结果。

  示例：“阶段 2：生成测试报告，输出（测试用例表格），输出示例：

  用例 ID	测试场景	输入	预期输出
  TC001	商品名称为空	name=''	提示‘名称不能为空’
  TC002	商品价格为 0	price=0	提示‘价格必须大于 0’

  八、“时间线” 提示词的避坑指南：避免常见错误

  8.1 避免 “阶段目标模糊”

  8.1.1 错误表现

  阶段名称或任务描述模糊，如 “阶段 1：做准备工作”“阶段 2：处理数据”，未说明具体内容。

  8.1.2 后果

  模型无法明确阶段目标，输出内容偏离需求，如 “准备工作” 可能被理解为 “安装软件” 或 “收集资料”，导致流程混乱。

  8.1.3 解决方案

  每个阶段的名称和任务要 “具体到可操作”，示例：“阶段 1：准备工作，任务（1. 安装 Python 3.9、2. 安装 pandas 库、3. 下载数据集）”。

  8.2 避免 “阶段顺序混乱”

  8.2.1 错误表现

  阶段顺序不符合实际逻辑，如 “阶段 1：开发实现、阶段 2：需求分析”（先开发后分析，违背正常流程）。

  8.2.2 后果

  模型按错误顺序输出内容，如先生成代码，再回头补需求文档，导致代码与需求脱节。

  8.2.3 解决方案

  按 “时间先后” 或 “逻辑顺序” 排列阶段，示例：“阶段 1：需求分析、阶段 2：开发实现、阶段 3：测试验证”（符合 “先明确需求，再开发，最后验证” 的逻辑）。

  8.3 避免 “交付物不可落地”

  8.3.1 错误表现

  交付物描述模糊，如 “阶段 1：输出需求文档”“阶段 2：输出代码”，未说明文档内容或代码功能。

  8.3.2 后果

  模型生成的交付物无法实际使用，如需求文档只有标题没有具体内容，代码无法运行。

  8.3.3 解决方案

  交付物需 “可描述、可验证”，示例：“阶段 1：输出需求文档（包含‘功能清单’‘交互流程图’‘数据字段说明’三个章节，总字数不少于 500 字）、阶段 2：输出登录接口代码（包含参数校验、数据库查询、token 生成逻辑，可直接运行）”。

  8.4 避免 “忽略异常场景”

  8.4.1 错误表现

  只关注正常流程，未考虑异常场景，如 “数据清洗时间线” 只包含 “去重→筛选”，未考虑 “数据格式错误” 的处理。

  8.4.2 后果

  模型输出的流程不完整，无法应对实际中的异常情况，如遇到格式错误的数据时，脚本会报错中断。

  8.4.3 解决方案

  在时间线中添加 “异常处理阶段” 或在任务中包含异常处理要求，示例：“阶段 2：数据清洗，任务（1. 去重、2. 筛选、3. 处理格式错误数据（如日期格式错误的行标记为‘异常数据’，单独保存））”。

  九、工具辅助：提升 “时间线” 提示词的编写效率

  9.1 提示词模板：快速生成基础框架

  使用现成的模板，只需填充任务细节，就能快速生成 “时间线” 提示词，避免重复编写。

  9.1.1 通用模板

  请按以下时间线，完成【任务名称】，技术栈：【技术栈列表】，需求：【核心需求描述】。

  时间线包含【N】个阶段，每个阶段需明确时间节点、任务、交付物、依赖关系：

  1. 阶段1：【阶段名称】（【时间节点】，【依赖关系】）

  任务：1. 【具体任务1】、2. 【具体任务2】、3. 【具体任务3】

  交付物：1. 【交付物1】、2. 【交付物2】

  依赖关系：【依赖的前置阶段及输出】

  2. 阶段2：【阶段名称】（【时间节点】，【依赖关系】）

  任务：1. 【具体任务1】、2. 【具体任务2】

  交付物：1. 【交付物1】

  依赖关系：【依赖的前置阶段及输出】

  ...

  N. 阶段N：【阶段名称】（【时间节点】，【依赖关系】）

  任务：1. 【具体任务1】

  交付物：1. 【交付物1】、2. 【交付物2】、3. 【交付物3】

  依赖关系：【依赖的前置阶段及输出】

  整体输出要求：1. 每个阶段按“任务→交付物→依赖关系”格式描述、2. 任务需可操作、3. 交付物需可落地。

  9.1.2 项目开发专用模板

  请按以下时间线，规划【项目名称】的开发流程，开发周期：【X天/周】，团队配置：【角色及人数】，技术栈：【技术栈列表】，核心功能：【功能清单】。

  时间线包含【N】个阶段：

  1. 阶段1：需求分析（第【X】天，无依赖）

  任务分工：

  - 【角色1】：【具体任务】

  - 【角色2】：【具体任务】

  交付物：1. 【需求文档】、2. 【接口文档初稿】

  依赖关系：无

  2. 阶段2：架构设计（第【X】天，依赖阶段1的需求文档）

  任务分工：

  - 【角色1】：【具体任务】

  - 【角色2】：【具体任务】

  交付物：1. 【数据库设计图】、2. 【项目包结构】

  依赖关系：需阶段1的需求文档确认数据字段

  ...

  N. 阶段N：部署上线（第【X】天，依赖阶段N-1的测试通过版本）

  任务分工：

  - 【角色1】：【具体任务】

  - 【角色2】：【具体任务】

  交付物：1. 【部署包】、2. 【部署文档】

  依赖关系：需阶段N-1的测试通过版本（所有BUG已修复）

  整体输出要求：1. 任务分工明确到角色、2. 交付物包含具体内容、3. 明确阶段依赖关系。

  9.2 在线工具：辅助阶段拆分与格式整理

  9.2.1 阶段拆分工具：XMind（思维导图）

  使用 XMind 将任务拆分为多个阶段，用思维导图展示阶段顺序和依赖关系，再将内容转化为提示词。

  示例：在 XMind 中创建 “项目开发” 主节点，下分子节点 “需求分析”“开发实现”“测试验证”“部署上线”，每个子节点添加 “任务”“交付物” 子项，整理后直接复制到提示词中。

  9.2.2 格式整理工具：Markdown 编辑器（如 Typora）

  用 Markdown 编辑器整理提示词格式，使用列表、标题等元素让时间线更清晰，避免模型因格式混乱误解需求。

  示例：用 “## 阶段 1：需求分析” 作为标题，“- 任务：1. XXX” 作为列表项，编辑完成后复制到 AI 对话窗口。

  9.3 模型反馈：迭代优化提示词

  生成第一次输出后，根据模型的表现迭代优化提示词，逐步提升输出质量。

  9.3.1 若模型遗漏阶段任务

  补充 “阶段任务细节”，示例：“阶段 2：接口开发，补充任务（3. 编写接口测试用例，验证接口参数校验逻辑）”。

  9.3.2 若模型输出格式错误

  添加 “输出格式约束”，示例：“阶段 1：输出需求文档，补充格式约束（文档需使用 Markdown 格式，章节标题用 ## 标识，正文用中文，不使用英文缩写）”。

  9.3.3 若模型忽略依赖关系

  强化 “依赖标注”，示例：“阶段 3：测试验证，修改依赖关系（必须依赖阶段 2 的接口开发完成，且接口能正常返回数据，否则无法进行测试）”。