Template
优化协作流程和自动化机制 v0.2.0
重大改进： 1. LINGJING_PROMPTS.md 从"五步法"优化为分级流程体系 - 快速流程（< 1小时小改动） - 标准流程（半天～1天常规功能） - 完整流程（2～5天复杂功能） - 新增：Bug 修复流程、代码重构流程 - 新增：自动化辅助 Prompts（文档同步、测试补齐、快速审查） - 新增：流程选择矩阵 + 10 条使用技巧 2. 新增 Claude Code 自动化配置 - .claude/instructions.md: 项目级自定义指令，自动加载质量标准 - .claude/commands/context.md: /context 命令快速加载项目上下文 - .claude/commands/update-docs.md: /update-docs 命令自动更新文档 3. 强化核心理念 - 验收驱动：先定义验收标准，再实现 - 工具化：明确使用 TodoWrite、Edit、Write 等工具 - 文档自动化：完成任务时自动更新 CHANGELOG 和 README - 质量门槛：每个 Demo 都对照 QUALITY_GATE 检查 改进原因： - 原五步法过于繁重，对小功能不友好 - 需要更好结合 Claude Code 的工具和能力 - 需要自动化文档更新，减少手动维护负担 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
This commit is contained in:
Claude
@@ -0,0 +1,14 @@
|
||||
---
|
||||
description: 加载项目上下文（质量标准、协作规范、项目概览）
|
||||
---
|
||||
|
||||
请先读取以下文件，了解项目的开发标准和流程：
|
||||
|
||||
1. 阅读 `QUALITY_GATE.md` - 质量门槛标准
|
||||
2. 阅读 `LINGJING_PROMPTS.md` - 协作 Prompt 套件
|
||||
3. 阅读 `docs/OVERVIEW.md` 或 `docs/OVERVIEW.template.md` - 项目概览
|
||||
|
||||
然后简要总结：
|
||||
- 本项目的质量要求
|
||||
- 适用的开发流程
|
||||
- 当前项目的核心目标
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
description: 根据最近的改动更新 CHANGELOG.md 和 README.md
|
||||
---
|
||||
|
||||
请执行以下步骤：
|
||||
|
||||
1. 检查最近的 git 改动（git diff 或 git log）
|
||||
2. 分析改动的性质（新功能/修复/优化/重构）
|
||||
3. 更新 `CHANGELOG.md`：
|
||||
- 在最新版本下添加一条记录
|
||||
- 格式：简洁描述改动内容 + 影响范围（不超过 3 行）
|
||||
4. 如果涉及新功能或使用方式变更，更新 `README.md`：
|
||||
- 在适当的章节添加说明
|
||||
- 保持简洁，提供示例代码或命令
|
||||
5. 总结更新内容
|
||||
@@ -0,0 +1,43 @@
|
||||
# 灵境万象项目开发指令
|
||||
|
||||
## 项目上下文自动加载
|
||||
|
||||
在开始任何开发任务前，请先阅读以下文件了解项目标准：
|
||||
|
||||
1. **质量标准**：`QUALITY_GATE.md` - 所有交付必须满足的最小质量门槛
|
||||
2. **协作规范**：`LINGJING_PROMPTS.md` - 标准化的开发流程和 Prompt 套件
|
||||
3. **项目概览**：`docs/OVERVIEW.md` 或 `docs/OVERVIEW.template.md` - 项目目标和范围
|
||||
|
||||
## 开发流程要求
|
||||
|
||||
### 功能开发
|
||||
- 遵循"一周一 Demo"节奏
|
||||
- 使用 TodoWrite 工具跟踪任务进度
|
||||
- 每个功能必须包含自动化测试
|
||||
- 完成后更新 CHANGELOG.md 和相关文档
|
||||
|
||||
### 质量检查
|
||||
在完成任何功能后，对照 QUALITY_GATE.md 检查：
|
||||
- [ ] Code: 代码质量、模块划分、无 Lint 错误
|
||||
- [ ] Test: 至少有 1 个自动化测试覆盖核心路径
|
||||
- [ ] Demo: 有可运行的演示场景
|
||||
- [ ] Docs: 更新 README.md 和 CHANGELOG.md
|
||||
|
||||
### 文档更新规则
|
||||
**必须自动更新的文件：**
|
||||
1. `CHANGELOG.md` - 每次功能完成后追加记录
|
||||
2. `README.md` - 如果涉及新功能或使用方式变更
|
||||
3. `docs/OVERVIEW.md` - 如果项目目标或能力发生变化
|
||||
|
||||
**更新时机：**
|
||||
- 在标记任务为 completed 之前
|
||||
- 使用 Edit 工具直接更新，不要只是建议更新
|
||||
|
||||
## Prompt 套件使用
|
||||
|
||||
根据任务类型，参考 `LINGJING_PROMPTS.md` 中的对应 Prompt：
|
||||
- 新功能开发 → 功能开发流程
|
||||
- 代码重构 → 重构 Prompt
|
||||
- Bug 修复 → 测试补齐 Prompt
|
||||
- CI 问题 → CI 排查 Prompt
|
||||
- 项目规划 → Demo 驱动 Prompt
|
||||
@@ -4,6 +4,27 @@
|
||||
- 每次重要变更记录一次
|
||||
- 简洁说明"做了什么 + 为什么做"
|
||||
|
||||
## [0.2.0] - 2025-12-10
|
||||
|
||||
### 新增
|
||||
- `.claude/instructions.md`: 项目级 Claude 自定义指令,自动加载质量标准和协作规范
|
||||
- `.claude/commands/context.md`: `/context` 命令,快速加载项目上下文
|
||||
- `.claude/commands/update-docs.md`: `/update-docs` 命令,自动更新文档
|
||||
|
||||
### 优化
|
||||
- **LINGJING_PROMPTS.md 重大优化**:
|
||||
- 从单一"五步法"改为分级流程（快速/标准/完整）
|
||||
- 新增 Bug 修复流程、代码重构流程
|
||||
- 新增自动化辅助 Prompts（文档同步、测试补齐、代码审查）
|
||||
- 新增流程选择矩阵和使用技巧章节
|
||||
- 强化验收驱动、工具化、文档自动化理念
|
||||
|
||||
### 改进原因
|
||||
- 原五步法过于繁重,不适合小功能开发
|
||||
- 缺少 Bug 修复和重构的专用流程
|
||||
- 需要更好地结合 Claude Code 工具（TodoWrite、Edit 等）
|
||||
- 需要强化文档自动更新机制
|
||||
|
||||
## [0.1.0] - 初始化模板
|
||||
- 新增 backend-fastapi 示例
|
||||
- 新增 frontend-vue3-dashboard 示例
|
||||
|
||||
+394
-117
@@ -1,160 +1,437 @@
|
||||
# LINGJING_PROMPTS.md
|
||||
灵境万象 · 一人研发协作 Prompt 套件
|
||||
|
||||
---
|
||||
|
||||
## 1. 功能开发五步法 Prompt
|
||||
|
||||
### 1.1 Step1:需求重述 + 验收标准
|
||||
|
||||
> 角色:你是本项目的协同开发工程师。
|
||||
> 目标:我们采用「一周一 Demo」节奏推进项目。
|
||||
>
|
||||
> 我会提供:
|
||||
> 1)项目 OVERVIEW
|
||||
> 2)QUALITY_GATE
|
||||
> 3)本周 Demo 目标
|
||||
> 4)本次要做的一个小功能描述
|
||||
>
|
||||
> 请你先完成两件事:
|
||||
> - 用 3～5 条 bullet 重述需求
|
||||
> - 为这个小功能写出 3～6 条"验收标准"(Given-When-Then 格式)
|
||||
**核心理念：验收驱动 + 质量门槛 + 自动化文档**
|
||||
|
||||
---
|
||||
|
||||
### 1.2 Step2:技术设计 Prompt
|
||||
## 使用指南
|
||||
|
||||
> 基于上一步的需求与验收标准,请你设计实现方案,要求:
|
||||
> - 列出需要修改 / 新增的文件路径
|
||||
> - 对每个文件说明职责(1～2 句话)
|
||||
> - 给出关键数据结构 / 接口的定义草图(伪代码)
|
||||
> - 明确哪些部分是本次迭代必须实现的,哪些可以下次再做(标记为 M1 / M2)
|
||||
### 流程选择矩阵
|
||||
|
||||
| 任务类型 | 预估时间 | 使用流程 | 关键点 |
|
||||
|---------|---------|---------|--------|
|
||||
| 小改动（UI调整、配置修改） | < 1小时 | 快速流程 | 直接实现 + 验证 |
|
||||
| 标准功能（新接口、新组件） | 半天～1天 | 标准流程 | 验收标准 + 测试 |
|
||||
| 复杂功能（新模块、架构变更） | 2～5天 | 完整流程 | 技术设计 + 分阶段 |
|
||||
| Bug修复 | 不定 | 修复流程 | 定位 + 测试 + 回归 |
|
||||
| 代码重构 | 半天～2天 | 重构流程 | 渐进式 + 保持功能 |
|
||||
|
||||
---
|
||||
|
||||
### 1.3 Step3:按文件输出代码 Prompt
|
||||
## 1. 快速开发流程（适用于小改动）
|
||||
|
||||
> 现在按照你刚刚的设计,从「一个文件」开始实现代码:
|
||||
> - 每次只输出一个文件的完整内容
|
||||
> - 使用代码块标明文件路径,例如:```python # backend-fastapi/app/api.py```
|
||||
> - 不要修改未在设计中出现的文件
|
||||
>
|
||||
> 输出后,请简单说明:
|
||||
> - 这个文件解决了哪些验收标准中的点?
|
||||
> - 还剩哪些验收点未覆盖?
|
||||
**适用场景：** UI调整、文案修改、简单配置、单文件小改动
|
||||
|
||||
### Prompt 模板
|
||||
|
||||
```
|
||||
【快速开发】
|
||||
需求：[简述要做什么]
|
||||
|
||||
请按以下步骤执行：
|
||||
1. 定义 2～3 条验收标准（简洁明确）
|
||||
2. 使用 TodoWrite 创建任务列表
|
||||
3. 直接实现改动（使用 Edit/Write 工具）
|
||||
4. 验证改动是否满足验收标准
|
||||
5. 更新 CHANGELOG.md（追加一条简短记录）
|
||||
```
|
||||
|
||||
### 示例
|
||||
|
||||
```
|
||||
【快速开发】
|
||||
需求：在 Dashboard 头部添加一个"导出"按钮
|
||||
|
||||
请按快速流程执行：
|
||||
- 验收标准：按钮出现在右上角、点击后触发导出事件、样式与现有按钮一致
|
||||
- 实现后更新 CHANGELOG
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 1.4 Step4:测试生成 Prompt
|
||||
## 2. 标准开发流程（适用于常规功能）
|
||||
|
||||
> 请为刚刚的改动生成自动化测试:
|
||||
> - 使用项目现有测试框架(pytest / jest 等)
|
||||
> - 放在 tests 目录中合适的位置
|
||||
> - 至少覆盖 1 个 Happy Path 和 1 个边界情况
|
||||
>
|
||||
> 输出格式:
|
||||
> - 测试文件完整内容
|
||||
> - 如何运行测试的命令(例如 pytest tests/test_xxx.py)
|
||||
**适用场景：** 新API接口、新Vue组件、新数据模型、中等复杂度功能
|
||||
|
||||
### Prompt 模板
|
||||
|
||||
```
|
||||
【标准开发】
|
||||
项目背景：[贴 OVERVIEW 或简述项目目标]
|
||||
本周 Demo 目标：[本周要达成的可演示目标]
|
||||
本次任务：[具体要实现的功能]
|
||||
|
||||
请遵循以下流程：
|
||||
|
||||
## Step 1: 需求澄清 + 验收标准
|
||||
- 用 3～5 条 bullet 重述需求（确保理解一致）
|
||||
- 定义 3～6 条验收标准（Given-When-Then 格式）
|
||||
- 识别关键约束和边界条件
|
||||
|
||||
## Step 2: 任务分解
|
||||
- 使用 TodoWrite 创建任务列表
|
||||
- 每个任务对应 1～2 个文件的改动
|
||||
- 标记任务优先级（P0/P1/P2）
|
||||
|
||||
## Step 3: 逐个实现
|
||||
- 按 TodoWrite 中的任务顺序逐个实现
|
||||
- 每完成一个任务：
|
||||
* 使用 Read/Edit/Write 工具直接修改代码
|
||||
* 标记对应的 todo 为 completed
|
||||
* 说明解决了哪些验收标准
|
||||
|
||||
## Step 4: 测试覆盖
|
||||
- 为核心逻辑添加自动化测试（至少覆盖 Happy Path）
|
||||
- 使用项目现有测试框架（pytest/jest）
|
||||
- 运行测试确保通过
|
||||
|
||||
## Step 5: 质量检查 + 文档更新
|
||||
- 对照 QUALITY_GATE.md 检查：Code/Test/Demo/Docs
|
||||
- 自动更新 CHANGELOG.md（追加变更记录）
|
||||
- 如有必要，更新 README.md 或 docs/OVERVIEW.md
|
||||
```
|
||||
|
||||
### 示例
|
||||
|
||||
```
|
||||
【标准开发】
|
||||
项目背景：疲劳检测 Dashboard，用于实时监控驾驶员疲劳状态
|
||||
本周 Demo 目标：展示实时告警列表和疲劳度趋势图
|
||||
本次任务：实现后端告警列表 API（/api/alerts）
|
||||
|
||||
请遵循标准流程：
|
||||
- 返回最近 50 条告警记录
|
||||
- 支持按时间倒序排列
|
||||
- 包含告警级别、时间戳、驾驶员ID
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 1.5 Step5:质量检查 + 文档同步 Prompt
|
||||
## 3. 完整开发流程（适用于复杂功能）
|
||||
|
||||
> 根据项目中的 `QUALITY_GATE.md`,帮我检查这次改动是否满足质量标准:
|
||||
> - 对 Code / Test / Demo / Docs 分别打 ✅ 或 ⚠
|
||||
> - 如果有 ⚠,请给出最小修改建议
|
||||
>
|
||||
> 然后:
|
||||
> - 生成一段可以追加到 CHANGELOG 的记录(不超过 5 行)
|
||||
> - 生成可以追加到 OVERVIEW 或 README 的更新说明(不超过 10 行)
|
||||
**适用场景：** 新模块、架构变更、多文件联动、需要分阶段实现的功能
|
||||
|
||||
### Prompt 模板
|
||||
|
||||
```
|
||||
【完整开发】
|
||||
项目背景：[贴 OVERVIEW]
|
||||
质量要求：[贴 QUALITY_GATE 关键点]
|
||||
本次任务：[复杂功能描述]
|
||||
|
||||
请遵循完整流程：
|
||||
|
||||
## Phase 1: 技术设计
|
||||
- 分析需求，列出核心验收标准（5～10 条）
|
||||
- 设计方案：
|
||||
* 列出需要新增/修改的文件及职责
|
||||
* 给出关键数据结构和接口定义（伪代码）
|
||||
* 识别技术风险和依赖
|
||||
- 分阶段规划：
|
||||
* M1（本周 Demo 必须）：最小可用功能
|
||||
* M2（下周）：增强功能
|
||||
* M3（可选）：优化和扩展
|
||||
|
||||
## Phase 2: M1 实现
|
||||
- 使用 TodoWrite 创建 M1 任务列表
|
||||
- 逐个实现，每个任务：
|
||||
* 实现代码
|
||||
* 添加测试
|
||||
* 标记 completed
|
||||
- M1 完成后进行集成测试
|
||||
|
||||
## Phase 3: Demo 验证
|
||||
- 运行 Demo 场景，验证核心流程
|
||||
- 录屏或截图记录 Demo 效果
|
||||
- 收集反馈，调整 M2 计划
|
||||
|
||||
## Phase 4: 文档与交付
|
||||
- 更新 docs/OVERVIEW.md（如有架构变更）
|
||||
- 更新 README.md（如有使用方式变更）
|
||||
- 更新 CHANGELOG.md
|
||||
- 记录重要决策到 docs/DECISION_LOG.md
|
||||
```
|
||||
|
||||
### 示例
|
||||
|
||||
```
|
||||
【完整开发】
|
||||
项目背景：AI OA 系统，集成企业微信和 LLM
|
||||
质量要求：必须有端到端测试、API 文档、可演示场景
|
||||
本次任务：实现"智能审批助手"模块
|
||||
|
||||
- M1：用户发起审批 → LLM 分析 → 返回建议
|
||||
- M2：审批历史记录和统计
|
||||
- M3：多轮对话优化建议
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. 重构与代码审查 Prompt
|
||||
## 4. Bug 修复流程
|
||||
|
||||
> 这是某个模块的现有代码(贴代码)。
|
||||
> 项目目标:……
|
||||
>
|
||||
> 请你作为「高内聚、低耦合」的架构顾问,从以下几个方面审查:
|
||||
> 1)模块边界是否清晰?
|
||||
> 2)是否过度耦合?
|
||||
> 3)是否有明显的重复代码或坏味道?
|
||||
> 4)给出一个"渐进重构计划",拆成 2～3 个小步骤(每步可在半天内完成)。
|
||||
>
|
||||
> 最后,请生成:
|
||||
> - 每一步的修改目标
|
||||
> - 每一步完成后可以立刻获得的"局部好处"
|
||||
**适用场景：** Bug 修复、问题排查、异常处理
|
||||
|
||||
### Prompt 模板
|
||||
|
||||
```
|
||||
【Bug 修复】
|
||||
问题描述：[描述 Bug 现象]
|
||||
复现步骤：[如何触发这个 Bug]
|
||||
预期行为：[应该是什么样的]
|
||||
|
||||
请按以下流程修复：
|
||||
|
||||
## Step 1: 问题定位
|
||||
- 分析可能的原因（列出 2～3 个假设）
|
||||
- 使用 Read/Grep 工具查找相关代码
|
||||
- 定位问题根源
|
||||
|
||||
## Step 2: 修复方案
|
||||
- 提出最小修复方案（只改必要的部分）
|
||||
- 说明为什么这个方案是合理的
|
||||
- 识别潜在的副作用
|
||||
|
||||
## Step 3: 实现修复
|
||||
- 使用 Edit 工具修改代码
|
||||
- 添加或更新测试（确保 Bug 不再复现）
|
||||
- 运行测试验证修复
|
||||
|
||||
## Step 4: 回归验证
|
||||
- 检查是否引入新问题
|
||||
- 验证相关功能仍然正常
|
||||
- 更新 CHANGELOG.md
|
||||
```
|
||||
|
||||
### 示例
|
||||
|
||||
```
|
||||
【Bug 修复】
|
||||
问题：Dashboard 告警列表在数据为空时显示"undefined"
|
||||
复现：清空所有告警数据，刷新页面
|
||||
预期：应显示"暂无告警数据"占位文本
|
||||
|
||||
请按修复流程处理。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. 测试补齐 Prompt
|
||||
## 5. 代码重构流程
|
||||
|
||||
> 这是某个模块/接口的代码(贴代码)。
|
||||
> 这是项目的 QUALITY_GATE(贴摘要)。
|
||||
>
|
||||
> 请你设计本模块的自动化测试方案:
|
||||
> - 列出重要的测试场景(用中文描述)
|
||||
> - 标记哪些是「必须的」(MUST),哪些是「可选的」(NICE)
|
||||
>
|
||||
> 然后为 MUST 场景生成一个测试文件:
|
||||
> - 使用 pytest / jest 等项目现有框架
|
||||
> - 确保能在本地运行通过
|
||||
> - 在代码块顶部标明文件路径
|
||||
**适用场景：** 优化代码结构、消除重复、提升可维护性
|
||||
|
||||
### Prompt 模板
|
||||
|
||||
```
|
||||
【代码重构】
|
||||
目标代码：[贴代码或文件路径]
|
||||
重构目标：[想达到什么效果]
|
||||
|
||||
请作为架构顾问，按以下步骤进行：
|
||||
|
||||
## Step 1: 代码审查
|
||||
从以下角度分析：
|
||||
- 模块边界是否清晰？
|
||||
- 是否有过度耦合？
|
||||
- 是否有重复代码或坏味道？
|
||||
- 命名和注释是否清晰？
|
||||
|
||||
## Step 2: 渐进重构计划
|
||||
拆分为 2～3 个小步骤（每步半天内完成）：
|
||||
- 步骤 1：[改什么] → [获得什么好处]
|
||||
- 步骤 2：[改什么] → [获得什么好处]
|
||||
- 步骤 3（可选）：[改什么] → [获得什么好处]
|
||||
|
||||
## Step 3: 逐步实施
|
||||
- 每步重构后运行测试确保功能不变
|
||||
- 每步完成后提交一次 commit
|
||||
- 保持小步快跑，随时可回滚
|
||||
|
||||
## Step 4: 验证与文档
|
||||
- 确认所有测试通过
|
||||
- 更新相关注释和文档
|
||||
- 记录重构决策到 DECISION_LOG.md
|
||||
```
|
||||
|
||||
### 示例
|
||||
|
||||
```
|
||||
【代码重构】
|
||||
目标代码：backend-fastapi/app/api.py（150行，包含3个接口）
|
||||
重构目标：拆分为独立的路由模块，提升可维护性
|
||||
|
||||
请按重构流程执行。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. 文档生成 Prompt
|
||||
## 6. CI / 构建问题排查
|
||||
|
||||
> 这是本次迭代的改动说明(贴任务 / commit 摘要)。
|
||||
> 这是项目 OVERVIEW(贴)。
|
||||
>
|
||||
> 请帮我生成:
|
||||
> - 1 段可以追加到 CHANGELOG 的文字(不超过 5 行)
|
||||
> - 1 段可以追加到 README 的"功能介绍"小节(不超过 8 行)
|
||||
> - 1 段可以写到周报里的"本周进展"(不超过 10 行,偏业务视角)
|
||||
**适用场景：** CI 失败、构建错误、测试失败
|
||||
|
||||
### Prompt 模板
|
||||
|
||||
```
|
||||
【CI 问题排查】
|
||||
失败日志：[贴日志关键部分]
|
||||
项目结构：[简述项目技术栈]
|
||||
|
||||
请帮我排查：
|
||||
1. 判断失败的直接原因
|
||||
2. 归类问题类型（依赖/测试/配置/环境/脚本）
|
||||
3. 给出最小修复方案（只改必要文件）
|
||||
4. 如涉及脚本或 YAML，生成修复后的代码片段
|
||||
|
||||
修复后更新 CHANGELOG.md 记录问题和解决方案。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. CI / 构建问题排查 Prompt
|
||||
## 7. Demo 驱动开发
|
||||
|
||||
> 这是 CI 的失败日志(贴日志)。
|
||||
> 项目结构如:……
|
||||
>
|
||||
> 请你:
|
||||
> 1)判断失败的直接原因是什么?
|
||||
> 2)属于哪一类问题(依赖 / 测试 / 配置 / 环境 / 脚本)?
|
||||
> 3)给出「最小修复方案」:只修改必要的文件,说明会改什么。
|
||||
> 4)如果修复中涉及到脚本或 YAML,请生成对应片段,并标明文件路径。
|
||||
**适用场景：** 周计划制定、Demo 目标设定
|
||||
|
||||
### Prompt 模板
|
||||
|
||||
```
|
||||
【Demo 驱动】
|
||||
项目概览：[贴 OVERVIEW 或简述]
|
||||
本周方向：[想完成的大致内容]
|
||||
|
||||
请帮我压缩为「可在 3～5 天完成的 Demo 目标」：
|
||||
|
||||
## 输出要求：
|
||||
1. 用 1 句话描述 Demo 用户故事（谁在什么场景下做什么）
|
||||
2. 列出 3～5 个必须完成的技术任务（P0）
|
||||
3. 列出 1～2 个可延后的任务（P1，标记为 NEXT）
|
||||
4. 生成 Plane 可用的任务列表（每个任务包含标题 + 2 行描述）
|
||||
|
||||
## Demo 验收标准：
|
||||
- 有可运行的端到端流程
|
||||
- 可录屏演示（1～2 分钟）
|
||||
- 满足 QUALITY_GATE 的最小标准
|
||||
```
|
||||
|
||||
### 示例
|
||||
|
||||
```
|
||||
【Demo 驱动】
|
||||
项目：疲劳检测 Dashboard
|
||||
本周方向：展示实时监控和历史数据分析
|
||||
|
||||
请生成本周 Demo 计划。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. Demo 驱动 Prompt
|
||||
## 8. 项目收尾决策
|
||||
|
||||
> 我们采用「一周一 Demo」节奏。
|
||||
> 这是当前项目概览(贴 OVERVIEW 摘要)。
|
||||
> 这是本周想完成的大致方向:……
|
||||
>
|
||||
> 请你帮我压缩成一个「可在 3～5 天内完成的 Demo 目标」:
|
||||
> - 用 1 句话描述 Demo 用户故事
|
||||
> - 列出 3～5 个必须完成的技术任务
|
||||
> - 列出 1～2 个可以延后到下周的任务(标记为 NEXT)
|
||||
>
|
||||
> 然后生成一个 Plane 可用的任务列表(标题 + 简短描述)。
|
||||
**适用场景：** 项目阶段性评估、是否继续投入的决策
|
||||
|
||||
### Prompt 模板
|
||||
|
||||
```
|
||||
【项目收尾决策】
|
||||
项目状态：[贴 OVERVIEW + 最近周志]
|
||||
当前困惑：是否应该收尾/暂停/继续？
|
||||
|
||||
请从以下角度分析：
|
||||
- 功能完成度（对比最初目标）
|
||||
- Demo 完整度（是否有可展示的价值）
|
||||
- 未来收益 vs 继续投入成本
|
||||
|
||||
## 输出建议：
|
||||
**决策：** 收尾 / 暂停 / 继续
|
||||
|
||||
**如果收尾：**
|
||||
- 收尾 Checklist（文档完善、代码归档、经验总结）
|
||||
|
||||
**如果暂停：**
|
||||
- 需要记录哪些信息方便未来重启
|
||||
- 暂停的触发条件（什么情况下重启）
|
||||
|
||||
**如果继续：**
|
||||
- 下一个 Demo 目标是什么
|
||||
- 需要调整的方向
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. 项目收尾 Prompt
|
||||
## 9. 自动化辅助 Prompts
|
||||
|
||||
> 这是项目当前状态(贴 OVERVIEW + 最近周志摘要)。
|
||||
> 我想判断:这个项目是否应该「收尾 / 暂停 / 继续加强」?
|
||||
>
|
||||
> 请你从以下角度分析:
|
||||
> - 功能完成度
|
||||
> - Demo 完整度
|
||||
> - 未来收益 vs 继续投入的成本
|
||||
>
|
||||
> 最后,帮我生成:
|
||||
> - 一个建议决策(收尾 / 暂停 / 继续)
|
||||
> - 如果收尾:收尾 checklist
|
||||
> - 如果暂停:需要记录哪些信息方便未来重启
|
||||
> - 如果继续:下一个 Demo 目标是什么
|
||||
### 9.1 自动更新文档
|
||||
|
||||
```
|
||||
【文档同步】
|
||||
请根据最近的改动（git diff 或我提供的摘要）：
|
||||
1. 更新 CHANGELOG.md（追加 1 条记录，不超过 5 行）
|
||||
2. 如有必要，更新 README.md 的相关章节（不超过 10 行）
|
||||
3. 如有架构决策，记录到 docs/DECISION_LOG.md
|
||||
```
|
||||
|
||||
### 9.2 测试补齐
|
||||
|
||||
```
|
||||
【测试补齐】
|
||||
目标代码：[贴代码或文件路径]
|
||||
质量要求：[贴 QUALITY_GATE 摘要]
|
||||
|
||||
请设计测试方案：
|
||||
1. 列出重要测试场景（中文描述）
|
||||
2. 标记 MUST（必须）和 NICE（可选）场景
|
||||
3. 为 MUST 场景生成测试代码
|
||||
4. 说明如何运行测试
|
||||
```
|
||||
|
||||
### 9.3 快速代码审查
|
||||
|
||||
```
|
||||
【快速审查】
|
||||
请审查以下代码，重点关注：
|
||||
- 安全漏洞（XSS、SQL注入、命令注入等）
|
||||
- 性能问题（N+1查询、内存泄漏等）
|
||||
- 明显的 Bug（空指针、类型错误等）
|
||||
- 代码规范问题
|
||||
|
||||
给出 3～5 条最重要的改进建议。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 10. 使用技巧
|
||||
|
||||
### 技巧 1：善用 TodoWrite
|
||||
|
||||
在任何多步骤任务中，第一步就创建 Todo 列表：
|
||||
- 帮助跟踪进度
|
||||
- 防止遗漏关键步骤
|
||||
- 给用户清晰的进度可见性
|
||||
|
||||
### 技巧 2：验收标准先行
|
||||
|
||||
在开始实现前，明确 2～6 条验收标准：
|
||||
- 用 Given-When-Then 格式
|
||||
- 具体、可验证、可测试
|
||||
- 覆盖核心路径和关键边界
|
||||
|
||||
### 技巧 3：小步提交
|
||||
|
||||
每完成一个小功能就提交：
|
||||
- 便于回滚
|
||||
- 便于 Code Review
|
||||
- 便于追溯问题
|
||||
|
||||
### 技巧 4：文档自动化
|
||||
|
||||
不要等到最后才写文档：
|
||||
- 完成功能的同时更新 CHANGELOG
|
||||
- 重要决策立即记录到 DECISION_LOG
|
||||
- README 随功能同步更新
|
||||
|
||||
### 技巧 5：质量门槛检查
|
||||
|
||||
每个 Demo 交付前，对照 QUALITY_GATE 检查：
|
||||
- Code：模块清晰、无 Lint 错误
|
||||
- Test：至少 1 个自动化测试
|
||||
- Demo：可录屏演示
|
||||
- Docs：README + CHANGELOG 更新
|
||||
|
||||
Reference in New Issue
Block a user