docs: 更新 AI 助手开发指南中的环境依赖说明
This commit is contained in:
1 parent
6eb9a2d2e9
commit
0132b3e991
1 file changed
+3
-40
+3
-40
@@ -29,44 +29,7 @@ placeholder="+ 添加{$page.data.aliases?.tag || '标签'}..."
|
||||
- 适用范围包括但不限于:标题、标签页签、按钮文案、占位符(placeholder)、提示语(title / aria-label)、空状态、确认弹窗等所有用户可见文本。
|
||||
- 后台设置项在 `src/routes/admin/settings/+page.server.ts` 中以 `alias.<key>` 形式保存,默认值需同步维护。
|
||||
|
||||
## 核心原则
|
||||
## 环境依赖
|
||||
|
||||
1. **渐进式开发优于大爆炸式开发**:小步提交,每次都能编译通过和测试通过。
|
||||
2. **从现有代码学习优于重新发明**:先研究和规划,再开始实现。
|
||||
3. **务实而非教条**:适应项目实际情况。
|
||||
4. **明确意图优于聪明代码**:选择简单明了的解决方案,不使用聪明技巧。
|
||||
5. **保持简单**:不要过度设计,避免过早抽象;如果需要额外解释,说明设计已经太复杂。
|
||||
6. **单一职责**:每个函数/类只承担一项职责。
|
||||
7. **控制复杂度**:注意圈复杂度,代码尽可能复用。
|
||||
8. **遵循 RESTful 原则**:涉及 API 的地方要遵循 RESTful 设计。
|
||||
9. **使用中文**:始终使用中文回复,代码注释也一律使用中文。
|
||||
|
||||
## 新需求流程
|
||||
|
||||
1. **首次沟通不急于编码**:当用户提出新需求时,先进行方案讨论。
|
||||
2. **使用 ASCII 图表**:必要时绘制多个方案对比图,让用户选择最佳方案。
|
||||
3. **用户确认后再开发**:只有用户明确确认方案后,才开始具体的开发工作。
|
||||
|
||||
## 实施过程
|
||||
|
||||
1. **理解现有模式**:研究代码库中的 3 个相似功能/组件。
|
||||
2. **识别通用模式**:找出项目约定和模式。
|
||||
3. **遵循现有规范**:使用相同的库/工具,遵循现有测试模式。
|
||||
4. **分阶段实现**:将复杂工作分解为 3-5 个阶段。
|
||||
|
||||
## 卡住时(关键规则)
|
||||
|
||||
最多尝试 3 次后必须停止:
|
||||
|
||||
1. 记录失败内容(尝试了什么、具体错误、失败原因)。
|
||||
2. 研究替代方案(找 2-3 个类似实现)。
|
||||
3. 质疑基本假设(抽象层次对吗?能分解成更小问题吗?)。
|
||||
4. 尝试不同角度(不同库/框架?不同架构模式?移除抽象?)。
|
||||
|
||||
## 决策框架优先级
|
||||
|
||||
1. **可测试性**:是否容易测试?
|
||||
2. **可读性**:6 个月后还能理解吗?
|
||||
3. **一致性**:是否符合项目模式?
|
||||
4. **简洁性**:是否是最简单的可行方案?
|
||||
5. **可逆性**:后续修改的难度?
|
||||
- 使用最新的 Svelte 5 语法
|
||||
- 使用最新的 SvelteKit 规范
|
||||
Reference in new issue
Block a user