# GTD




# Misc


## 名词解释ADR

> `grill-with-docs`：适合研发项目、已有代码库、需要沉淀术语和关键决策。它会一边追问，一边把稳定术语写进 `CONTEXT.md`，把难逆转的决策写成 ADR。

#名词解释 

这是一个非常专业的软件工程术语！。

---

### 📘 ADR 的定义与全称

ADR 是一个缩写（Acronym），它的全称是： Architecture Decision Record （架构决策记录）

#### 🔑 核心概念总结：

如果说代码是项目的“骨骼”（它展示了系统_是什么样子的_），那么 ADR 就是项目的“记忆和思考过程”（它解释了系统_为什么会变成这样_）。

---

### 🎯 ADR 的作用与价值 (Why do we need it?)

在大型、复杂的研发项目中，决策的累积是非常巨大的。一个看似简单的选择（比如使用 SQL 而不是 NoSQL）背后，可能牵涉到性能、成本、团队熟悉度、扩展性等数十个因素的权衡（Trade-offs）。

ADR 的核心价值在于：它将“临时的脑子里的想法”固化成了“永久的项目知识”。

当项目发生以下情况时，ADR 就变得至关重要了：

1. 新成员加入 (New Hires): 新人不需要从头问遍所有老员工：“为什么我们用 Kafka 而不是 RabbitMQ？” ADR 会直接告诉他们。
2. 需求变化 (Requirement Change): 当客户要求改变某个功能时，开发人员需要知道：这个旧的设计是基于什么限制做出来的？如果改了，会不会破坏其他地方的逻辑？ADR 提供了解答。
3. 技术评审 (Review/Audit): 当外部审计或内部进行技术审查时，ADR 可以证明“我们不是随便选了一个方案”，而是经过深思熟虑后，选择了最优解。

---

### 🧱 ADR 的结构和内容 (What does it contain?)

一个典型的 ADR 通常是一个简短的文档（Markdown 文件），但它必须包含特定的要素：

1. 标题 (Title): 简洁明了地概括决策。
    - _例：`ADR-005: Use PostgreSQL for Primary Database`_
2. 状态 (Status): 当前决策是“草案（Proposed）”、“接受（Accepted）”还是“已废弃（Superseded）”。
3. 背景/问题 (Context / Problem): 为什么需要做这个决定？存在什么痛点或不确定性？
    - _例：目前我们用内存缓存，但随着用户量增加，数据丢失风险很高。_
4. 决策选项 (Options Considered): 我们考虑了哪些方案？（如：Option A - MySQL；Option B - MongoDB；Option C - PostgreSQL）。
5. 选择的方案及理由 (Decision & Rationale): 最终选择了哪个方案，以及 为什么 选择它。这是最重要的一部分！
    - _例：我们选择 PostgreSQL，因为它提供了强大的事务支持（ACID），并且团队对它的熟练度最高，这比 MongoDB 的灵活性更适合我们的业务模型。_
6. 后果/影响 (Consequences): 这个决策带来的利弊是什么？（如：优点是数据一致性高；缺点是查询复杂时性能不如 NoSQL 灵活）。

---

### 🔗 在你的句子中的具体应用解析

> `grill-with-docs`... 把难逆转的决策写成 ADR。

在这个场景中，`grill-with-docs` 这个工具（它的功能是“提问+文档化”）做的事情是：

1. 它会通过提问（`grill`）来挖掘出项目中的一些关键选择。
2. 当这些选择被确定为 “难逆转的决策”（Hard-to-reverse decisions） 时，工具就会把这个信息打包成一个 ADR 文件。

#### 💡 举例说明：

假设你在和一个技术负责人聊项目，他回答了：“我们决定用微服务架构来拆分订单、支付和库存这三个模块。”

- 如果只写在 `CONTEXT.md` 中 (稳定术语)： 你可能只记录：“✅ _使用微服务架构_”。（这是一个事实）
- 如果写成 ADR： 你会详细记录：
    - 问题： 单体应用性能瓶颈日益严重，业务增长到一定规模无法支撑。
    - 决策： 拆分为订单、支付、库存三个微服务。
    - 理由 (Rationale)： 因为我们未来预计的交易量将达到百万级/天，需要独立扩展；而且这三个模块耦合度高，分别解耦可以降低风险。
    - 后果： 优点 是可伸缩性强；缺点 是增加了服务间通信的延迟和运维复杂度。

你看，ADR 不仅仅是一个标签，它是一份承载了项目智慧的完整历史文档！





## 名词解释

先对齐：本轮只解释两个概念：`npm UI 组件库` 和 `Tailwind 项目`


### `npm UI 组件库
#名词解释

`npm UI 组件库` 是指：通过 `npm` 安装到前端项目里的 UI 组件包。

比如：

```
npm install antd
npm install @mui/material
npm install mantine
```

安装后，你在代码里直接引用组件：

```
import { Button } from "antd"

export function Page() {
  return <Button>保存</Button>
}
```

这里的 `Button`、`Dialog`、`Table`、`Form` 就是别人库里封装好的 UI 组件。你主要通过参数、主题配置、CSS 覆盖来定制它。典型例子有 `Ant Design`、`MUI`、`Chakra UI`、`Mantine`。

### Tailwind 项目
#名词解释

`Tailwind 项目` 是指：项目主要用 `Tailwind CSS` 来写样式。

普通 CSS 可能这样写：

```
.button {
  padding: 8px 16px;
  border-radius: 6px;
  background: black;
  color: white;
}
```

Tailwind 写法通常是直接在元素上写工具类：

```
<button className="px-4 py-2 rounded-md bg-black text-white">
  保存
</button>
```

其中：

- `px-4` 表示左右内边距
- `py-2` 表示上下内边距
- `rounded-md` 表示中等圆角
- `bg-black` 表示黑色背景
- `text-white` 表示白色文字

所以，`Tailwind 项目` 不是一种特殊 App，而是一个使用 `Tailwind CSS` 作为主要样式方案的前端项目。

两者区别很简单：

`npm UI 组件库` 给你的是“现成组件”。

`Tailwind 项目` 说的是“这个项目怎么写样式”。

`shadcn/ui` 比较特别：它通常用在 Tailwind 项目里，但它不像传统 npm UI 组件库那样只让你 import 包里的组件，而是把组件源码复制进你的项目，让你自己拥有和修改。

# ddup
  - 


# MemoDaily
  -
- 01:49:14 视频中提到的AI工具hand-drawn-styles的GitHub地址是：https://github.com/threerocks/hand-drawn-styles