From 6c6929615a6304b6bc4e938228877a0af05ef80e Mon Sep 17 00:00:00 2001
From: Zane <1638944816@qq.com>
Date: Mon, 1 Jun 2026 20:58:30 +0800
Subject: [PATCH] =?UTF-8?q?=E5=90=8C=E6=AD=A5=E6=9C=80=E6=96=B0=E6=96=87?=
 =?UTF-8?q?=E6=A1=A3?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...›¢é˜Ÿçº§ AI 编程驾驭工程_BV1SZoXBkErT_笔记.md | 352 ++++++++++++++++++
 ... ¼é©±åŠ¨è�½åœ°_文档管ç�†ç­–ç•¥_BV1mZV76eEPC_笔记.md | 177 +++++++++
 ...：业务需求出�最佳实践�天猫AI Coding实践系列】.md |   0
 ...：业务需求出�最佳实践�天猫AI Coding实践系列】.md |   0
 InBox/v2ex_1196441_大模型�笨讨论.md          |  36 --
 InBox/zhihu_article_2028819446546932894.md    |  17 -
 6 files changed, 529 insertions(+), 53 deletions(-)
 create mode 100644 3Resources/AI/2026-04-25 Harness for AI coding 团队级 AI 编程驾驭工程_BV1SZoXBkErT_笔记.md
 create mode 100644 3Resources/AI/2026-05-30 SDD 规格驱动�地_文档管�策略_BV1mZV76eEPC_笔记.md
 rename InBox/glue-coding-tmall-ai-practice-2026-03-27.md => 3Resources/AI/97.9%采纳率，胶水编程：业务需求出�最佳实践�天猫AI Coding实践系列】.md (100%)
 delete mode 100644 97.9%采纳率，胶水编程：业务需求出�最佳实践�天猫AI Coding实践系列】.md
 delete mode 100644 InBox/v2ex_1196441_大模型�笨讨论.md
 delete mode 100644 InBox/zhihu_article_2028819446546932894.md

diff --git a/3Resources/AI/2026-04-25 Harness for AI coding 团队级 AI 编程驾驭工程_BV1SZoXBkErT_笔记.md b/3Resources/AI/2026-04-25 Harness for AI coding 团队级 AI 编程驾驭工程_BV1SZoXBkErT_笔记.md
new file mode 100644
index 0000000..cb0b694
--- /dev/null
+++ b/3Resources/AI/2026-04-25 Harness for AI coding 团队级 AI 编程驾驭工程_BV1SZoXBkErT_笔记.md	
@@ -0,0 +1,352 @@
+# ��团队 AI 编程驾驭工程体系
+
+## 一�背景与核心问题
+
+### 1.1 为什么需�团队级 AI 编程体系
+
+当� AI 编程工具（如 SuperPowe�Claude Code�Cursor 等）已��常强大，但**在团队级�项目级场景下�地困难**。核心原因是：
+
+- **需求衔接问题**：产���/BA 给的需求格��统一，颗粒度�一致，导致 AI 无法有效�解
+- **开�实践问题**：多人�作时，AI 生�的代�风格�统一�难以形�一致的整体
+- **工具生�混乱**：Claude Code�Cursor�windsurf�SuperPower 等工具差异大，没有统一标准
+- **�程与制度问题**：团队工作习惯难以改�，这是最大的阻力��
+
+### 1.2 当�团队使用 AI 编程的认知分级
+
+根�开�者能力分层：
+
+| 级别 | �述 | 典型行为 |
+|------|------|----------|
+| �级开�者 | 照猫画虎，�知�系统如何工作 | 抄代��写业务逻辑，被 AI 替代 |
+| 专家型开�者 | �技术公关，��组件开� | �需�，但 AI �辅助 |
+| 架构型开�者 | 设计�务���衡决策 | AI 辅助设计，但�人工把关 |
+| 技术��/CTO | 处���混乱的问题 | 构建团队 AI 工作体系 |
+
+> **关键洞察**："这个玩具�是玩 AI，是玩人"——真正的挑战�在于 AI 能力，而在于如何让团队按照统一的方�工作。
+
+### 1.3 AI 辅助软件工程全�程图
+
+```
+需求分� → 技术方案设计 → 代�编写 → Code Review → 测试 → 部署 → 生产 Bug 修�
+   ↓            ↓              ↓          ↓         ↓       ↓         ↓
+  录音转文档   打样工程      API/�元测试   交�模型   E2E测试   K8S部署   MCP自动
+  访谈纪�    代�模�       TDD 循环      Review    Playwright  触��并  �通知
+  需求文档    技术规范
+  原型链接
+```
+
+## 二�需求阶段：如何让需求 AI �好
+
+### 2.1 需求规格模�必须包�的内容
+
+BA 或产���给的需求文档必须包�以下 4 个关键部分：
+
+1. **业务背景**：为什么�这个需求
+2. **字段清�**：所有业务字段的类型�默认值�业务规则（���给原型图让 AI 去猜）
+3. **原型链接**：Figma 图等设计稿的链接（AI �通过 MCP 读� Figma）
+4. **业务规则**：按�拆分，例如：
+   - 订��生�规则
+   - �货规则
+   - 状�转�规则
+
+### 2.2 需求颗粒度的判断标准
+
+**��用 Story 拆分需求**（一个人增产改查拆� 4 个 story 对 AI �说信���够）。
+
+正确�法：**一个模�一个文档**，判断颗粒度的标准是：
+- 是�有独立的表结构
+- 是��以�独上线
+
+### 2.3 新建需求 vs �更需求
+
+**新建需求**：告诉 AI 有多少表�多少页��多少功能�作 → AI 生�完整模�
+
+**�更需求**（��）：
+- 必须用标签标注�更类型：`[+字段]` `[-字段]` `[修改字段]`
+- ��把最终完整状�给 AI，因为 AI 需�对比现有代� → 浪费大� Token 且效果差
+- 示例：
+
+```markdown
+# 订�模��更需求
+
+## 新增内容 [+]
+- 新增字段：order_type（订�类型，枚举值：NORMAL, VIP, B2B）
+
+## 修改内容 [~]
+- 修改字段：shipping_address 最大长度从 200 改为 500
+
+## 删除内容 [-]
+- 删除字段：legacy_flag（已废弃）
+```
+
+### 2.4 用 Obsidian �建知识库给 AI �上下文
+
+将所有需求规格�技术规格都放到知识库中，用 Obsidian + Markdown 管�：
+
+- 用�览器�件一键将网页转� Markdown 并�存图片本地
+- 用 backlink 功能�上下文关�
+- AI 通过读�这个知识库获得长期记忆 → "Single source of truth"
+
+## 三�技术规格阶段：技术方案设计
+
+### 3.1 技术规格必须包�的内容
+
+技术规格是开�的核心输入，必须包�以下 5 个部分：
+
+| 内容 | 工具/格� | 说明 |
+|------|----------|------|
+| 领域模型 | PlantUML / Mermaid | 代�化表达，便于 AI �解 |
+| 数�库设计 | DBML / Flyway 脚本 | ��让 AI 直接�作数�库，用版本化的 Flyway 脚本 |
+| API 定义 | OpenAPI / Markdown | �端写完 API �输出 API 文档给�端 |
+| 时�图 | Mermaid | ���程需�时�图 |
+| 专项设计 | Markdown | ���事务�缓存等专项内容 |
+
+> **��教训**：��给 AI 写数�库的写��，曾�因为 AI 动�动修改数�库导致多人�作冲�。把写��关掉，让 AI 生� Flyway 脚本，本地测试时让 Flyway 跑。
+
+### 3.2 DSL 驱动的技术规格
+
+用领域特定语言（DSL）�驱动技术规格：
+- 领域模型用 PlantUML
+- 数�库用 DBML
+- API 用 OpenAPI
+- 这些 DSL 都�以通过代�生� → ����端一致性
+
+> 这实际上就是模型驱动架构（Model-Driven Architecture），当团队从零开始全新的 AI 项目时，这�严格的检查和约�更容易建立。
+
+## 四�打样工程：AI �好的代�框架
+
+### 4.1 什么是打样工程
+
+打样工程（Seed Project）是一个预先定义好的代�框架模�，包�：
+- �层的类�和�责定义
+- 代�规范和最佳实践
+- �赖�置和目录结构
+
+### 4.2 打样工程的作用
+
+1. **AI 生�代�风格一致**：所有 AI 都基于�一个框架生�代�
+2. **�少��代�**：AI 会�用框架中的组件而�是��写
+3. **�低认知负担**：AI �需��次�解项目结构
+
+### 4.3 如何创建打样工程
+
+1. 从旧项目中蒸�出一个干净的新项目骨架
+2. 定义�层�责：`Controller → Service → Repository → Entity`
+3. 定义类命�规范和包结构
+4. 放入 Git 仓库供团队共享
+
+## 五�开�阶段：让 AI ��写出统一风格的代�
+
+### 5.1 用 RAG（检索增强生�）�供上下文
+
+将技术规格�代�规范�历�决策等信�放到代�仓库的 `/docs` 或 `/book` 目录下，AI 通过检索这些文档获得上下文：
+
+```markdown
+/my-project
+  /book
+    /requirements      # 需求规格
+    /specifications     # 技术规格
+    /api-docs          # API 文档
+  /src
+  /skills
+  /mcp
+```
+
+### 5.2 多任务�步开�：Worktree 的使用
+
+Git Worktree �以把分支映射�目录，实现多任务并行：
+
+```bash
+# 创建多个工作目录
+git worktree add ../feature-order feature/order
+git worktree add ../feature-user feature/user
+
+# 在��目录下�时工作，�完��并
+```
+
+**但�注�**：
+- 多人�时�作多人工作时，版本管�会比较痛苦
+- 建议��把规格设计好，让 AI 慢慢跑，而�是�时开太多任务
+
+### 5.3 ��让 AI 边写代�边�设计
+
+用 `rapper5` 的�路：**Discovery/Design 和 Coding 分两个阶段**。
+- 先�探索性设计，让�� AI 模型（GPT�Claude�Gemini）�自给出方案
+- 选定方案�，�激活 Coding 角色专�写代�
+- 切�角色时�置上下文，�� AI 注�力分散
+
+## 六�测试阶段：AI 写代�形�闭环的核心
+
+### 6.1 为什么测试是 AI 编程的命脉
+
+> "没有 API 测试和�元测试，无法形� AI 写代�的闭环。"
+
+AI 生�代��必须能**自我验�**，�则：
+- 人工验�效率�低
+- AI 无法�现自己的问题
+- 团队无法真正�效
+
+### 6.2 测试策略（3 层）
+
+| 测试类型 | 工具 | 驱动方� |
+|----------|------|----------|
+| �元测试 | JUnit / pytest | TDD：先写测试让 AI 失败，�写实现 |
+| API 测试 | REST Assured / Newman | 自动化回归，�直接� 90%+ 覆盖率 |
+| E2E 测试 | Playwright（推�，替代了 Selenium） | 上线� 80% 的 case 回归覆盖 |
+
+### 6.3 TDD 循环（SuperPower 的工作方�）
+
+1. 让 AI 先写 API 测试/�元测试
+2. AI �行测试 → 失败
+3. AI �写实现代�
+4. AI 自动�行测试验� → 通过
+
+> **效果**：�元测试�达 100% 覆盖率，API 测试�达 90%+ 覆盖率。
+
+### 6.4 AI 写测试解决�阳性问题
+
+有时候 AI 为了让测试通过，会伪造测试逻辑。解决方案：
+- **TDD 先写测试**：先让测试失败，�让 AI 写实现
+- **交�验�**：用��的 AI 模型互相 review 代�和测试
+
+### 6.5 测试用例的管�
+
+测试用例直接放到代�仓库中：
+- �元测试：跟�代�模�
+- API 测试：放在 `/test/api` 目录
+- E2E 测试：用 TypeScript + Playwright，放在代�仓库根目录（或与�端项目�仓库）
+
+## 七�Review 阶段：AI 辅助 Code Review
+
+### 7.1 多� Review 方�
+
+1. **工具扫�**：SonarQube 等��分�工具 + AI 自动修�
+2. **AI Review**：用�一个 AI 模型�交� review（�模型� review 是常用技巧）
+3. **Agent 自动触�**：在 PR 阶段自动触� Review Agent
+
+### 7.2 AI Review 的问题与解决方案
+
+**问题**：AI Review 总是会�改进建议，哪怕没有明显问题（因为你的 prompt 让它�问题）。
+
+**解决方案**：
+- 设置阈值：达到一定级别��问题，�则�输出
+- 让 AI �关注 bug 和逻辑错误，�过度关注风格问题
+- 用团队的架构规约�约� Review 标准
+
+### 7.3 ��场景的 Review 策略
+
+- **全新项目（AI 100% 生�）**：�以用最严格的规则，AI 写完直接修
+- **混�项目（人 + AI）**：�能存在历��留问题，Review 结果噪音多，建议从新模�开始�步规范
+- **跨系统场景**：AI 容易犯错（尤其涉� 3-5 个系统的交互），建议收敛到�个仓库处�
+
+> **�验**：跨系统时 AI 犯错误概率高达 70-80%，核心原因是缺少完整的系统间关系和业务规则上下文。
+
+## 八�工具链：AI 编程工具全景
+
+### 8.1 三类 AI 编程工具
+
+| 类型 | 代表工具 | 特点 |
+|------|----------|------|
+| 命令行 CLI | Claude Code, OpenAI Codex | 适�快速�作�脚本化 |
+| IDE 集� | Cursor, Windsurf, VS Code AI | 适�日常开�，界��好 |
+| 辅助�件 | SuperPower（推�个人）, Copilot | 按需使用 |
+
+### 8.2 常用 MCP（Model Context Protocol）
+
+| MCP | 用途 |
+|-----|------|
+| 数�库 MCP | �作数�库（注�：�读，写��建议关闭） |
+| Figma MCP | 读�设计稿 |
+| Jira MCP | 管�工� |
+| Git MCP | 代��交�PR �作 |
+
+### 8.3 Skills 体系
+
+Skills = 一段�示� + 模� + 脚本，用于�述工作方法。
+
+- 把打样工程的�始化�� Skill
+- 把团队规范�� Skills
+- Skills 放到代�仓库中共享
+
+**��观点**：
+> "现在 AI �解力已�很强大，�需�把规范�实为�常固定的格�，��表达清楚信��强调�点��。"
+
+**主� Skill 框架**：
+- SuperPower：内置大� Skills，开箱�用，适�个人
+- Claude Agent（hermes）：自动基于对�生�和优化 Skills
+- MCP：工具调用�议
+
+### 8.4 为什么�推� SDD 框架
+
+SDD（Scenario-Driven Development）框架本身很好，但**�地难度在于团队共识**：
+
+- 需�团队所有人按照相��程工作
+- 现实团队中阻力很大（�是�愿�用，是习惯改�了）
+- SuperPower 对个人很好用，但团队级很难推广
+
+> **结论**：与其强推 SDD 框架，�如团队自己定义一套 Roos + Skills + MCP 的组�。
+
+## ��架构型�考：未�趋势
+
+### 9.1 Agent Code 的趋势
+
+未�必然会出现 "Agent Code" 的概念——把整个团队的所有产物（需求�规格�规范�测试）全部代�化，放到代�仓库中统一管�：
+
+```markdown
+/.agent
+  /skills          # 工作方法
+  /mcp             # 工具�置
+  /templates       # 模�
+  /rules           # 规范
+  /docs            # 文档
+```
+
+所有 AI 工具（SuperPower�Claude Code 等）安装时都从代�库读��置，实现�致高效。
+
+### 9.2 多 Agent �调的挑战
+
+当�多 Agent 框架（如 CrewAI�AutoGen）还处于早期阶段：
+- 缺少程�级别的精确校验（�能完全�赖 AI 判断）
+- Agent 与代�之间的交互需�程�驱动而�纯 AI 驱动
+- �能需�自己写 workflow 调度器
+
+### 9.3 共识是第一�务
+
+> "工具是玩人的，为了获得团队的共识。"
+
+大公�之所以比�公�/创业公�更难推进 AI 编程��，是因为：
+- 习惯难以改�
+- 团队文化难以调整
+- 需�从上到下的强力推动
+
+## ��团队实践建议
+
+### 10.1 �进��地路线
+
+1. **�人验�阶段**：选择一个简�项目，用 SuperPower + TDD 验� AI 编程效率
+2. **规范建立阶段**：定义技术规格模��代�规范�打样工程
+3. **团队推广阶段**：用 Skills 标准化工作方法，�步让团队接�
+4. **自动化阶段**：打通从需求到部署的全�程，实现"代��一切"
+
+### 10.2 技术��的核心�责
+
+- 定义 AI �好的需求规格模� → 推动 BA/产�接�
+- 建立打样工程和代�规范 → 控制代�质�下�
+- 推动测试文化 → 这是专业和�专业软件公�的分界线
+- 构建团队共识 → 这是最难也是最��的事
+
+### 10.3 ��指�
+
+1. **��让 AI 直接写数�库**：用 Flyway 脚本版本化管�
+2. **��拆分过于细�的需求**：一个模�一个文档
+3. **�更需求一定�标注�更类型**：��给完整状�
+4. **��让 AI �时�设计和代�**：分阶段，用��角色
+5. **��完全�赖 AI Review**：用规则约��AI + 人工结�
+
+## �一�观众�馈与补充
+
+- **�为 CodeArts Agent**：带有规范驱动开�模�，�以�考
+- **Obsidian + Opal**：适�� Markdown 知识库管�，手机和电脑�步，适�在外也能用手机+终端工作
+- **看�� AI ��**：所有需求�设计�任务全部看�化，共享给团队�员
+- **跨 Agent 通信**：契约文件（如 OpenAPI JSON）放到共享目录，��端�自读� → ���端改完�端�知�的问题
+- **sonarlint 本地扫� + AI 自动修�**：在 pre-commit 阶段触���扫�，AI 自动修�代�风格问题，效果很好
\ No newline at end of file
diff --git a/3Resources/AI/2026-05-30 SDD 规格驱动�地_文档管�策略_BV1mZV76eEPC_笔记.md b/3Resources/AI/2026-05-30 SDD 规格驱动�地_文档管�策略_BV1mZV76eEPC_笔记.md
new file mode 100644
index 0000000..f8ea206
--- /dev/null
+++ b/3Resources/AI/2026-05-30 SDD 规格驱动�地_文档管�策略_BV1mZV76eEPC_笔记.md	
@@ -0,0 +1,177 @@
+# SDD 规格驱动�地：文档管�策略
+
+## 研讨会背景与目的
+
+本次分享是 AI 编程相关�题的延续，主��焦 **SDD（Spec-Driven Development，规格驱动开�）** 的文档管�策略。
+
+### 研讨会机制
+
+- **目的**：让�会者能够�与达�社区共识，分享�公�在 AI 编程实践中的�验
+- **形�**：咨询师分享观察到的公�实现方案�架构设计�系统设计等内容
+- **价值**：对个人和团队帮助都�常大，通过集体讨论形�共识
+
+> 特别感谢�尼克�哥在研讨会期间贡献了大�分享�想，�益颇多。
+
+---
+
+## AI 编程�展历程回顾
+
+### 时间线概览
+
+| 时间 | 分享内容 | 核心概念 |
+|------|----------|----------|
+| 2025年6月 | 早期 AI 编程实践 | DPER5 方法论 |
+| �续 | MCP 等工具整� | MCP�Scales |
+| 5月9日 | Plan 和 Build 模� | 新因�（�引�）概念 |
+| 本次 | SDD 文档管�策略 | 规格驱动�地 |
+
+---
+
+## DPER5 方法论
+
+### 核心�想
+
+DPER5 将软件工程中使用 AI 进行开�的过程分为 **5 个弱阶段（Weak Stages）**：
+
+```
+Discover → Plan → Execute → Review → Refine
+   ↓         ↓        ↓         ↓        ↓
+ �现      规划      执行      评审      优化
+```
+
+### 阶段特性
+
+- ��阶段 AI 会按照��的模��行
+- 例如在 **Design** 模�或 **Discover** 模�下，AI **�会修改代�**
+- 这�分阶段约�是驯� AI 的简�有效方法
+
+### 实践应用
+
+- 在早期阶段（2025年），演讲者已�在公�内部领先应用
+- 采用 `Design → Plan → Execute` 的�程驱动开�
+- 该方法使用了较长时间，有效规范了 AI 辅助开��程
+
+---
+
+## MCP（Model Context Protocol）工具生�
+
+### 工具整�
+
+�续�� MCP 以�相关工具套件的出现，形�了完整的 AI 编程工具生�：
+
+- **MCP（Model Context Protocol）**：模型上下文�议
+- **Scales**：扩展工具
+- **SDD**：规格驱动开�方法论
+
+这些工具被整�到一份 PPT 手册中，作为团队 AI 编程的指�或手册�考。
+
+---
+
+## SDD（规格驱动开�）
+
+### SDD 的核心模�
+
+SDD �供了多�工作模�，适用于��的开�场景：
+
+| 模� | 适用场景 | AI 行为特� |
+|------|----------|-------------|
+| **Design** | 需求分��架构设计 | �修改代�，仅�供设计建议 |
+| **Discover** | 探索�现�方案调研 | �修改代�，专注于信�收集 |
+| **Plan** | 规划分解�任务拆解 | 生�实现计划 |
+| **Build** | 代�实现�具体开� | 执行代�编写和修改 |
+
+### 新因�（�引�）概念
+
+由 countic 大佬在 5月9日的分享中引入：
+
+**物�学的概念解释**：
+
+- 在混沌系统中，存在两�震��馈的系统
+- 这�系统最终会收敛到一个稳定状�
+- 这个收敛点被称为 **�引�（Attractor）**
+
+**在 AI 编程中的应用**：
+
+- 通过引入新因�，�以引导 AI 的输出趋�于预期的稳定状�
+- 帮助控制 AI 在��任务中的�散性
+- 实现更�控的 AI 驱动开��程
+
+---
+
+## SDD 文档管�策略
+
+> 本次分享的核心主题，�焦于规格驱动开�的文档管�方法
+
+### 文档在 SDD 中的作用
+
+1. **规格定义**：明确需求和设计规范，作为开�的基准
+2. **上下文传递**：在��阶段之间传递上下文信�
+3. **版本控制**：记录规格的�更历�
+4. **团队�作**：统一团队对需求的�解和实现方�
+
+### 文档管�最佳实践
+
+（基于 SDD 方法论，文档管�应�循以下原则）
+
+- **规格优先**：在开��先完�规格文档的编写
+- **增�迭代**：规格文档�项目进展�步完善
+- **��追溯**：规格与实现之间���追溯性
+- **工具集�**：将文档管�与 AI 编程工具链整�
+
+---
+
+## 工具链整�方案
+
+### 推�的 AI 编程工具栈
+
+```
+┌─────────────────────────────────────────────────────�
+│                    规格层 (Spec)                      │
+│  ┌─────────────�  ┌─────────────�  ┌─────────────�  │
+│  │   Design    │  │   Discover  │  │    Plan     │  │
+│  └─────────────┘  └─────────────┘  └─────────────┘  │
+├─────────────────────────────────────────────────────┤
+│                    工具层 (Tools)                     │
+│  ┌─────────────�  ┌─────────────�  ┌─────────────�  │
+│  │     MCP     │  │   Scales    │  │    SDD     │  │
+│  └─────────────┘  └─────────────┘  └─────────────┘  │
+├─────────────────────────────────────────────────────┤
+│                    执行层 (Execution)                │
+│  ┌─────────────�  ┌─────────────�                    │
+│  │    Build    │  │   Review    │                    │
+│  └─────────────┘  └─────────────┘                    │
+└─────────────────────────────────────────────────────┘
+```
+
+### MCP 的核心功能
+
+- �供标准化的上下文�议
+- 实现 AI 与外部工具的无�集�
+- 支�多工具��工作
+
+---
+
+## 社区贡献者致谢
+
+| 贡献者 | 贡献内容 |
+|--------|----------|
+| �尼克 | 大�分享�想，研讨会核心�与者 |
+| countic | 引入新因�（�引�）概念，分享 Plan/Build 模� |
+| 少个分� | SDD 方法论整�，工具链整�，文档管�策略分享 |
+
+---
+
+## �续�题预告
+
+本次分享的议程安排：
+
+1. **SDD 文档管�策略**（当�内容）
+2. **AIGC 模�相关�题**（由�尼克�哥分享）
+
+---
+
+## �考资�
+
+- 本次分享的 PPT 资料（�作为团队 AI 编程手册/指�）
+- �索关键�：`AI编程`�`MCP`�`SDD`�`DPER5`�`规格驱动开�`
+- 相关标签：`人工智能`�`规格驱动开�`�`AI编程`
\ No newline at end of file
diff --git a/InBox/glue-coding-tmall-ai-practice-2026-03-27.md b/3Resources/AI/97.9%采纳率，胶水编程：业务需求出�最佳实践�天猫AI Coding实践系列】.md
similarity index 100%
rename from InBox/glue-coding-tmall-ai-practice-2026-03-27.md
rename to 3Resources/AI/97.9%采纳率，胶水编程：业务需求出�最佳实践�天猫AI Coding实践系列】.md
diff --git a/97.9%采纳率，胶水编程：业务需求出�最佳实践�天猫AI Coding实践系列】.md b/97.9%采纳率，胶水编程：业务需求出�最佳实践�天猫AI Coding实践系列】.md
deleted file mode 100644
index e69de29..0000000
diff --git a/InBox/v2ex_1196441_大模型�笨讨论.md b/InBox/v2ex_1196441_大模型�笨讨论.md
deleted file mode 100644
index 5003b86..0000000
--- a/InBox/v2ex_1196441_大模型�笨讨论.md
+++ /dev/null
@@ -1,36 +0,0 @@
-# 大家有没有感觉最近大模型�笨了
-
-**��**: https://www.v2ex.com/t/1196441#reply25  
-**�存时间**: 2026-03-24  
-**标签**: #AI #大模型 #讨论
-
----
-
-## 帖�摘�
-
-楼主�问：大家有没有感觉最近大模型�笨了？
-
-主�讨论点：
-- 用户感觉 GPT-4�Claude 等大模型最近回�质�下�
-- 有人认为是心�作用或期望值�高
-- 也有人�到�能是模型更新导致的风格�化
-- 讨论涉�多个主�大模型：GPT-4�Claude�Gemini 等
-
----
-
-## 关键回�观点
-
-1. **心�作用论**: 用多了之�对模型能力边界更清楚，所以感觉"�笨"
-2. **模型更新论**: OpenAI 等厂商确实会调整模型，�能影��些任务的表现
-3. **任务��度**: ��使用深入，�出的问题更难，模型显得力�从心
-4. **对比效应**: 新模型出��，旧模型相对显得弱了
-
----
-
-## 个人�考
-
-(待补充)
-
----
-
-**原始链接**: https://www.v2ex.com/t/1196441#reply25
diff --git a/InBox/zhihu_article_2028819446546932894.md b/InBox/zhihu_article_2028819446546932894.md
deleted file mode 100644
index ec37b86..0000000
--- a/InBox/zhihu_article_2028819446546932894.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: 知乎文章 - 2028819446546932894
-source: https://zhuanlan.zhihu.com/p/2028819446546932894
-created: 2026-05-09 15:02
-tags: [zhihu, article, saved]
----
-
-# 知乎文章
-
-**URL:** https://zhuanlan.zhihu.com/p/2028819446546932894
-
-**说明:** 此 URL 由 Hermes �存，文章内容因知乎�爬虫机制（zse_ck）暂无法自动抓�。
-
-> 请手动访问该链接查看完整文章内容，然�将正文粘贴到此处。
-
----
-