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）暂无法自动抓取。 - -> 请手动访问该链接查看完整文章内容，然后将正文粘贴到此处。 - ---- -