docs: consolidate getting started references

2026-08-16 12:28:06 +00:00 · 2026-05-02 05:56:44 +08:00
parent f57ccc2f9d
commit 7bf3b782f2
25 changed files with 244 additions and 456 deletions
@@ -17,6 +17,30 @@
 | AI 忘记之前的对话 | 上下文丢失 | 重新提供关键信息，或用 memory bank |
 | AI 改了不该改的代码 | 指令不明确 | 明确说"只改 xxx，不要动其他文件" |
 | AI 生成的代码风格不一致 | 没有规范 | 提供代码规范或示例代码 |
+| 闭门造车后发现已有成熟方案 | 开发前没有充分查资料 | 先调研官方能力、成熟开源方案和主流实践，再决定是否自研 |
+
+</details>
+
+<details open>
+<summary><strong>🧭 工程决策相关</strong></summary>
+
+### 先查资料，再写代码
+
+一个高频教训是：花很长时间闭门造车，最后才发现已有更成熟、更稳定、更低维护成本的开源方案或官方能力。
+
+建议把开发前的时间分配改成：
+
+> 10 分开发，7 分查资料、对齐目标、比较方案。
+
+执行前至少问清楚：
+
+1. 这件事是什么？
+2. 为什么要做？
+3. 现有成熟方案怎么做？
+4. 当前方案是不是最合适、最稳定、最省维护成本？
+5. 是否符合 [拼好码](../concepts/拼好码.md) 的复用优先原则？
+
+可用工具：搜索引擎、官方文档、GitHub、Perplexity、AI 网页版问答。

 </details>

@@ -1,7 +0,0 @@
-# 血的教训
-
-## 执行之前
-
-> 关于闭门造车后发现有更好的开源方案的教训
-
-10分开发，7分找资料，开发之前一定一定一定要先找全部需要的资料和 ai 充分讨论对齐，时刻谨记主要次要的几个探问维度，是什么？为什么？怎么做？是最合适/优秀的方案吗？工具：perplexity