阅读材料: 第10部分：项目重新规划

模块「第10部分：项目重新规划」中第 1 / 5 节课

您正在未登录状态下查看课程。请登录，以保存进度并参加测试。

来源

第10部分。项目重新规划

完成第一个功能后，你会想立即构建下一个。在SDD中，最好暂停一下。重新规划是一个更新项目文档的时刻，趁偏差还小的时候。代理写代码越快，定期回归项目规则就越重要。

重新规划回答以下问题：

上一阶段之后我们学到了什么；
是否需要更新技术栈；
路线图是否过时；
哪些检查应该成为强制性的；
是否有可重复的流程值得自动化。

Hello Hono之后的重新规划示例

完成第一个功能后，你可以了解到：

需要Vitest进行测试；
需要自适应设计作为项目规则；
需要CHANGELOG.md；
路线图过于分散，或者相反，过于粗略；
向Qwen Code请求功能规范的操作重复出现，适合做成技能。

创建一个分支：

git checkout -b replanning-after-hello-hono

请求：

/clear
阅读 @specs/mission.md、@specs/tech-stack.md、@specs/roadmap.md
以及已完成的Hello Hono功能规范。

我们正在执行重新规划阶段。
不要实现新的产品功能。
为以下内容提出修改建议：

1. Vitest测试策略；
2. 自适应设计作为产品的通用要求；
3. 维护变更日志；
4. 路线图中的阶段大小。

修改前，先列出建议的文件变更。

更新 `tech-stack.md`

添加测试策略：

## 测试

- Vitest测试路由、组件和数据库。
- `npm test` 应该运行 `vitest run`。
- 功能验证文件中必须列出强制性自动检查。

为界面添加约束：

## 界面

- HTML通过Hono JSX在服务器端渲染。
- 普通CSS，除非明确批准新的依赖项。
- 页面必须在移动端375px宽度和桌面端1280px宽度下正常工作。

更新旧规范

当项目规则改变时，旧的功能规范可能变得不完整。请Qwen Code：

更新现有功能规范以适应新的测试策略
和自适应设计要求。
暂时不要修改实现，除非更新的验证要求这样做。
修改前先展示简要摘要。

这很重要：规范历史应该解释实施时生效的是哪些规则。

变更日志作为沟通工具

CHANGELOG.md不仅对人有帮助。代理也可以将其作为项目的简要历史来阅读。

示例：

# 变更日志

## 2026-05-01

- 为SDD添加项目章程。
- 实现基础功能Hello Hono。
- 添加布局、静态CSS和严格的TypeScript检查。

请求：

创建或更新 @CHANGELOG.md。
使用带日期的标题。
基于Git历史和当前分支的变更。
为利益相关者写得简洁明了。

调整路线图中的阶段大小

糟糕的路线图：

## 阶段2：构建应用的所有功能

太宽泛。代理会做出太多变更，人工审查会很困难。

糟糕的路线图：

## 阶段2：添加一个CSS边距

太琐碎。开销大于价值。

好的路线图：

## 阶段2：代理与疾病

目标：添加基础领域模型和只读页面。

- [ ] 为代理和疾病添加SQLite架构。
- [ ] 添加初始虚构数据。
- [ ] 添加 /agents 和 /ailments 页面。
- [ ] 添加路由和组件测试。

编码步骤：将什么转化为规则

重新规划是将一次性观察转化为永久规则的时刻。如果不这样做，每个后续功能都会重复同样的错误，代理每次都得重新猜测。

编码是将观察记录为四种工件之一：

**QWEN.md中的规则。** 适用于涉及代理行为的观察："未经确认绝不更改tsconfig.json"，"写入前始终显示修改的文件列表"。
**tech-stack.md中的决策。** 适用于涉及长期技术选择的观察："所有测试使用Vitest"，"前期阶段不使用ORM"，"所有表都获得created_at"。
**validation.md中的模板。** 适用于涉及验证形式的观察："路由测试需验证200和404"，"迁移测试需通过重复运行验证幂等性"。
钩子、技能或请求。 适用于机械性重复出现的观察，自动化更简单（见第14和17部分）。

重新规划分支末尾编码步骤的简单请求：

基于Hello Hono功能的成果和已完成的重新规划，提出

QWEN.md、tech-stack.md、validation.md模板
以及钩子/技能集合的变更列表。对每个项目说明：
1. 导致此观察的现象；
2. 建议的规则或工件；
3. 将其放入哪个文件；
4. 为什么不应该只保留在聊天中。
暂时不要修改文件。

如果列表超过5-7项，不要试图一次性全部实施——选择两三个最常见的观察，记录下来，其余留到下次重新规划。

反馈飞轮：信号 → 更新什么

为了不让编码变成大型仪式，手边常备一个简短的"信号 → 更新什么"对应关系。方便将其想象为飞轮：每个来自最近功能的观察都会触发更新，降低下次出现同样问题的概率。

最近功能的信号	更新什么
代理两次重复同样的错误	`QWEN.md`中的新规则
代理找不到需要的文件或API	扩展`QWEN.md`中"开始时阅读什么"的列表
实现超出边界	重写"边界之外"部分和"不应更改的内容"块

列表不追求完整。它的目的是展示每个注意到的故障都有固定的记录反应位置。如果找不到位置，这是信号说明项目结构中缺少某个部分，值得创建。

重新规划提交

npm test
npm run typecheck
git add specs CHANGELOG.md package.json package-lock.json vitest.config.ts tests
git commit -m "Replan workflow after first feature"
git checkout main
git merge replanning-after-hello-hono
git branch -d replanning-after-hello-hono