AI 系统逻辑 · 学习手册

从一篇文章，彻底搞懂 AI 是怎么"搭起来"的

基于 APPSO《Opus 5 砍掉超 80% 系统提示词，我们用 AI 的方式也该变了》的系统性拆解。 不堆术语，先把骨架立住，再挂血肉；每个概念都映射到你自己的 vault 和 AI Page Strategy POC。

📄 拆解来源：APPSO（发现明日产品） · 2026-07-27 · 原文指向 Anthropic 工程师 Thariq 的 X 长文与官方博客《The new rules of context engineering for Claude 5 generation models》
一句话先记住（全文的 thesis） 这篇文章其实只讲了一件事：当模型越来越强，"控制权"从「往 prompt 里堆规则」转向「设计 AI 所在的工作环境」。 记住这一句，后面 6 个思路都是它的不同侧面。
0

读前词典：先把名词装进口袋

文章里冒出来的英文词，先用"人话 + 一个你肯定懂的类比"钉住。读到这里，每个名词都要能在脑子里唤起一个画面。

Model · 模型大脑 类比：一个读过海量资料的资深员工。它"聪明"但"看不见你桌上的东西"。 真正生成回答的那个核心。你用的 WorkBuddy、Claude、GPT 都是某个模型。
Context · 上下文它当前能看到的一切 类比：员工开工前，你摊在他桌上的全部材料（文件、规矩、例子）。 模型每次回答时，能"看到"的全部文字。装太多会乱、会互相打架。
Token最小阅读单位 类比：一页纸被切成的小块。中文约 1 个汉字≈1 token，英文约半个词。 模型按 token 计费和记忆；上下文有"容量上限"。
Prompt · 提示词你当场说的话 类比：你口头布置的任务。"帮我写个首页方案"。 用户每次输入的指令。和下面"系统提示词"是两回事。
System Prompt · 系统提示词产品出厂设定 类比：公司给这个岗位写的《岗位说明书》，普通员工改不了。 平台写死的底层规则。文章说 Claude Code 砍掉的就是这层的 80%。
CLAUDE.md项目说明 / README 类比：你接手一个项目时，前任留的《这个项目要注意什么》。 放在项目里的约定文件，只写"看文件结构看不出来的"特殊规则。
Skill · 技能按需打开的操作手册 类比：《某类任务的 SOP》，用到才翻出来看，不用一直摊桌上。 封装好的任务指南。我们之前用的 obsidian 技能就是一例。
References · 参考本次任务的附件 类比：这周做方案要参考的草图、竞品、规范文档。 用 @ 贴给 AI 的具体文件：原型、代码、测试、评分表。
Memory · 记忆跨会话的笔记 类比：员工自己记的便签，下次遇到类似活直接翻。 上一次对话学到的、这次还能用的信息。可手动也可自动。
Tool · 工具AI 能调用的外部能力 类比：员工手边的电脑、打印机、查资料权限。 读文件、跑命令、搜网页、发消息……模型通过"接口"来用它们。
Agent · 智能体能自主干多步活的 AI 类比：不是你一步步教，而是给目标，它自己选工具、反复试。 会"思考→调工具→看结果→再想"地循环，直到完成。
Rubric / Verifier验收清单 / 验收 AI 类比：打分表 + 专门挑刺的质检员。 写明"什么算做好"，甚至让另一个 AI 按表逐项验收。
1

AI 工作的一次"完整发生"是什么样的

别急着背概念。先看一遍：你发一句话，到拿到结果，中间到底发生了什么。下面用你的 POC 场景走一遍。

① 用户指令 "给 VANS 日本 首页推方案" ② 上下文组装 POC规则+设计系统 +历史案例 拼一起 ③ 模型思考 读上下文→推理 ④ 输出/调工具 出方案 or 渲染 预览图 ⑤ 验收 +记忆 验收结果 + 新信息 → 回流进 Memory，下次更顺
图 1 · 一次完整的 AI 工作流（用你的 AI Page Strategy POC 举例）
关键认知 你以为 AI 是"你问它答"。其实在②，系统已经把好几层材料偷偷拼好喂给它了——真正决定结果质量的，经常不是你那句话，而是②里拼了什么、怎么拼。这正是文章标题"上下文工程"的由来。
2

核心：上下文分层（文章的骨架）

这是整篇文章最重要的一张图。②"上下文组装"里，材料按"层级"来组织。先吃透这张图，后面 6 个思路直接挂上来。

① System prompt · 系统提示词 产品/模型出厂规则。普通用户不碰（≈ WorkBuddy 自带的系统指令） ② CLAUDE.md · 项目说明 项目级约定，保持简短，只写"看结构看不出来的" ③ Skills · 技能（按需打开） 某类任务的手册，用到才加载，别写太死 ④ References · 参考（本次任务） HTML 原型 / 代码 / 测试 / 评分表，用 @ 贴进来 ⑤ Memory · 记忆（跨会话） 上次学到的、这次还能用的；可手动也可自动 Assembled Context 组装好的上下文 = 上面几层拼起来 喂给 ③模型思考 ↑ 你真正能"设计"的就是这里
图 2 · 上下文分层模型（对应原文 img_06 核心结构图）

把你自己的 vault 映射进来（建议，可调整）

文章讲的是"给 AI 用的系统"，你的 Obsidian vault 本质也是一套"给 AI 用的协作系统"。按文章逻辑，可以这样对应：

文章里的层干什么你 vault 里的对应注意事项
System prompt模型/产品的出厂行为你不直接写；≈ WorkBuddy / 平台自带的系统指令这层你一般动不了，也别去动
CLAUDE.md项目级约定，保持简短AI-START-HERE.md + VAULT-RULES.md（写前必读、固定 frontmatter）只写"看文件结构看不出来的"；目录本身不必抄一遍
Skills可复用、按需打开的手册你写的各种 Skill.md；以及 20 Knowledge/ 里被提升的复用知识太长就拆；规则别写死
References本次任务附件用 @ 引用的文件：90 Assets/ 素材、具体设计稿、已写好的代码/原型优先给"代码形态"（HTML/原型），比截图准
Memory跨会话记忆30 Memory/（如 Q3 主题规划）+ WorkBuddy 自动/手动记忆自动记忆兴起后，手动 # 可少写
注意 这个映射是我的建议，不是要你改 vault。你那套编号结构（01 Daily / 10 Projects / 20 Knowledge…）是"信息分类"，和文章的"上下文层级"是两套维度——分类是"存哪"，层级是"AI 干活时怎么读"。别混为一谈。
3

为什么要"删掉 80% 系统提示词"

理解了分层，就能看懂"删 80%"的动机。旧模型弱，得靠规则防它犯傻；新模型强了，那些规则反而变成累赘——还会互相打架。

System prompt "适当给代码补注释" （出厂规则） 某个 Skill "不要添加注释" （省 token 的规矩） 用户指令 "照原代码风格补" （你当场说的） Assembled Context（组装后的上下文） 三句话互相矛盾 → 模型懵了：到底听谁的？ → 占用上下文、增加决策成本、还容易错 新模型强了：这些"防呆规则"它自己会判断 → 可以删
图 3 · 过度约束与上下文冲突（对应原文 img_02 冲突图）
一句话 旧规则是"为弱模型补窟窿"而写的。模型升级后，这些窟窿没了，规则却还常驻——占地方、还制造冲突。砍掉它们，性能没损失（文章实测过）。
4

六个新思路（文章的骨架上的 6 根肋骨）

每条都是"旧做法 → 新做法"。记住：它们全是模块 0 那句 thesis 的侧面——把"规则"交还给模型的判断力，人去设计环境。

模型变强 人更"精明" 1 信判断力 2 设计接口 3 按需加载 4 简化说明 5 自动记忆 6 丰富参考
图 4 · 六个思路总览（对应原文 img_12）
思路 1

给规则 → 信判断力

旧：写死"完成后必须验证""不要加注释"防它出错。
新：一句"按周围代码风格工作"就好。模型自己知道何时注释、何时删。

思路 2

给示例 → 设计接口

旧：演示几次教它用工具，反而限死范围。
新：在接口里定义状态（pending / in_progress / completed），它自己判断怎么调。（图 5）

思路 3

全塞 → 按需加载

旧：代码审查/验收说明每次都塞进上下文。
新：做成 Skill，用到才开；工具说明也用 ToolSearch 按需取。（图 6）

思路 4

重复 → 简化说明

旧：同一条要求 system prompt 写一遍、工具说明再写一遍。
新：只留一份在工具说明里，不重复。（图 7）

思路 5

手动记忆 → 自动记忆

旧：按 # 手动存进 CLAUDE.md。
新：模型自动保存相关的工作/用户信息，下次接着用。（图 8）

思路 6

只给规格 → 丰富参考

旧：计划只写 Markdown。
新：直接给 HTML 原型/代码/测试/Rubric，甚至让验收 AI 按表打分。（图 9）

代表性配图重制

旧 · 给示例（限死范围） 演示 1：创建任务 A 演示 2：标记 A 进行中 演示 3：完成 A → 它只会做"演示过的"，换种用法就懵 新 · 设计接口（给状态，让它判断） 工具接口定义 3 个状态： pending · in_progress · completed 规则：同一时间只处理一项 → 它自己决定怎么调，不限死 →
图 5 · 思路 2 重制（对应原文 img_04）
旧 · 全塞（每次都读无关说明） 上下文里永远带着： · 代码审查说明 · 验收验证说明 → 普通任务用不上也占着 新 · 渐进加载（progressive disclosure） 需要时再开 Skill： · 要审代码 → 开 code review · 要验收 → 开 verification → 用 ToolSearch 找工具说明 →
图 6 · 思路 3 重制（对应原文 img_13）
5

把视角拉远：文章真正在讲什么

六个思路之上，是一段更大的演进。看清这条线，你就不再被具体技巧牵着走。

提示词工程 把一句话写到一百分 上下文工程 把多层材料拼对 接口 / 环境设计 搭好工作台，让 AI 自己判断 你的角色：使唤实习生 → 给资深工程师搭工作台的总监
图 7 · 三阶段演进（文章的"拉远视角"）
对你（非开发）的含义 你不必去学"怎么写完美 prompt"。你的价值在更上游：把项目的特殊规定讲清（CLAUDE.md）、把团队知识沉淀好（Skills/Knowledge）、把验收标准定义明（Rubric）——也就是"设计 AI 的工作环境"。这正是你做 AI Page Strategy POC 时本来就在做的事。
6

落到你自己：给 vault / Skills 做一次"瘦身体检"

看懂了就用在自己身上。下面这份 Checklist，拿你现有的 AI-START-HERE.md、VAULT-RULES.md、各种 Skill.md 逐条过一遍。可勾选。

提醒 不是所有 Skill 都该删。文章说"过去半年写的 Skills 不会全白写"——那些提醒旧模型'别忘了这一步'的内容该重查；那些承载团队真知识的，反而该保留并提升进 20 Knowledge。删的是"补窟窿的规则"，不是"真知识"。
7

延伸阅读与动手实验

延伸阅读（按可信度排序）

动手实验（把看懂变成会用）

毕业标准 学完后，拿一张纸只看图 2（分层模型），你能讲出：每一层是什么、文章对每层做了什么改动、以及你自己的 vault 分别对应哪一层。能做到，这篇就算真懂了。