/ai%E5%BC%80%E5%8F%91%E4%BB%8E%E5%85%A5%E9%97%A8%E5%88%B0%E7%B2%BE%E9%80%9A/ Recent content in AI开发从入门到精通 on 老张开工了 Hugo zh-cn Wed, 29 Jul 2026 00:00:00 +0000 /posts/2026/07/ai-growth-path/ Wed, 29 Jul 2026 00:00:00 +0000 /posts/2026/07/ai-growth-path/ 30 篇走完了，写最后一篇不教技能而讲成长：你现在是什么角色、什么是 next level、未来一年要让哪些心态和动作升级。最后一篇是给你自己做年度复盘时用。 30.1 五个阶段——你处在哪一段 我把观察到的 AI 开发者划为五段： ┌─────────────────────────────────────────────────────────────┐ │ L1 Prompter —— 把 AI 当谷歌，单向 use │ │ L2 Pair Coder —— 用 IDE + L1/L2 偶尔协作,慢慢看 diff │ │ L3 Vibe Coder —— 完全反向: 描述意图 + 沉淀 skill + Agent loop│ │ L4 Harness Builder —— 自己搭/二开 harness / MCP / skill 库 │ │ L5 AI Engineer —— 设计团队 AI workflows + 治理 + 教学辐射 │ └─────────────────────────────────────────────────────────────┘ 每个阶段的 transition 大约需要 4-6 个月的连续练习。下面给五种"晋级题"。 /posts/2026/07/ai-ci-integration/ Mon, 27 Jul 2026 00:00:00 +0000 /posts/2026/07/ai-ci-integration/ 前 28 章你的 AI 工作都是"我自己在 OpenCode 里跑跑"。第 29 章把这一摊 x fail + AI action 流搬到 CI/CD pipeline 上：每个 PR 一来，就触发一组"AI 验证 + AI 改进建议 + 安全扫描"jobs，让 review 之前先帮 reviewer 把关。 29.1 任务范围 把 5 个 AI-augmented jobs 加到 .github/workflows/pr-review.yml： ┌─ on: pull_request │ ├─ Job 1: digest (1 min, $0.01) 摘要 + AI 一句话 review │ ├─ Job 2: sanity (2 min, $0.05) 安全 / 私有 / license 扫 │ ├─ Job 3: unit (10 min, $0) 跑测试 │ ├─ Job 4: skill-check (3 min, $0. /posts/2026/07/practice-graph-refactor/ Sat, 25 Jul 2026 00:00:00 +0000 /posts/2026/07/practice-graph-refactor/ 第四个实战最 hairy：用 Graph 工作流引导 Agent 重构一个多模块（≥30 文件、≥5000 行）的中型项目。这种任务单 ReAct loop 撑不下来——决定要做什么、做哪部分、什么时候跳、什么时候熔断，全靠 Graph。 28.1 任务定义 一个老 Python 项目： 30+ 文件，5000+ LOC 没有类型注解，没有 unit test 覆盖（5%） pyproject.toml 里没 ruff 三个 orchestrator 文件 (main, cli.py, web_server.py) 错综耦合 重构目标（一季）： 引入类型注解 + basedpyright 严格 单测覆盖率 70%+ 三 orchestrator 拆出公共 lib 28.2 为什么单 Agent Loop 不行 一次 Claude Code session 用 ReAct loop 跑： Step 1: 想想 - "拆 main 和 cli" 大致步骤 Step 2-30: 边读边改文件 30 个 → context soon 80k+ → 压缩 Step 31-50: 压缩了早期 notes, 起初约束忘 Step 51: refactor 30 文件已混乱,report "DONE but lots of TODO" Step 80-200: 又迭代一次,实际上模型忘了第 3 步的架构 budget 到,模型默认 "DONE", 实际未完成 80% Graph + Looper 优势：把项目拆成 30 个 node, 每个 node 限 scope, progressive cap, 不烧枚举上下文。 /posts/2026/07/practice-multi-agent/ Thu, 23 Jul 2026 00:00:00 +0000 /posts/2026/07/practice-multi-agent/ 第三个实战是把 13 章 Subagent 派发的理论变成一个可跑的多 Agent workflow：实情场景——“每周定期给团队新生 PR 做 triage / 分配 reviewer / 跑测试 brief”。 27.1 任务定义 每个周一早上 9 点，主 Agent 启动： 拉 open PRs（用 GitHub MCP） 按 PR 文件路径推理 owner（explore agent 5 个并行） 给每个 owner 生成 review brief（build agent, 5 个并行） 把 5 份 brief 拼成周报发给 Slack（slack MCP） 周一 9:00 Planner ─拉 PRs ──┐ │ 5 explore ─并行─→ owner map │ 5 build ─并行─→ review brief │ Slack send ─→ 单条最终消息 │ └ DONE 9:08 27. /posts/2026/07/practice-mcp-server/ Tue, 21 Jul 2026 00:00:00 +0000 /posts/2026/07/practice-mcp-server/ 第二个实战把第 15-19 章的 MCP 理论组装起来——开发一个能上生产的 mcp-internal-ops，让团队所有 Agent 都能查公司内部 dashboard、读 CI 历史、触发预部署。 26.1 任务边界 先限定范围，否则内部 MCP 容易变成"什么都包"。我们的 server 提供： Tool 名 作用 副作用 ops.query 查询内部 SQL dashboard (readonly) 无 ops.ci_runs 最近 10 次 CI 状态 无 ops.preflight 触发预部署 sandbox（不 prod） 有 ops.slo 90 天 SLO 指标 无 不提供： 写数据的接口 触发 prod 部署 任何跟客户数据 / 法规 / 安全相关的查询 写操作只有一个 preflight，且只在 sandbox。 26.2 技术选型 Python + uv 环境 + mcp[cli] httpx 调内部 dashboard API pydantic 校验 启动方式：stdio（harness 启子进程） 26. /posts/2026/07/practice-docs-skill/ Sun, 19 Jul 2026 00:00:00 +0000 /posts/2026/07/practice-docs-skill/ 进入实战篇。第一个练习是写一个让你团队所有项目共享的 docs-update Skill——专治"AI 帮我改完代码但文档没同步"。一个实战把第 20-24 章 Skill 五篇理论全部跑一遍。 25.1 任务定义 场景：AI 改了代码 → 你 review 通过 → 但 docs 没动 → 几天后用户文档跟现实不符。 目标 Skill：在每次代码改动 review 完成后，主动让 Agent 检查、必要时改 docs： 触发：commit / PR 阶段 不要触发：debug session、解释性问题 DONE：所有公开 API、命令行参数、配置文件均与现有 docs 一致 / 已提出 docs 改动建议 失败模式：找不到 docs/、docs 在另一个 repo、docs 仅图片形式 25.2 写 SKILL.md .opencode/skills/docs-update/SKILL.md： --- name: docs-update version: 0.1.0 description: | After code changes are staged or committed, check whether the related docs are still accurate. /posts/2026/07/skill-library/ Fri, 17 Jul 2026 00:00:00 +0000 /posts/2026/07/skill-library/ 你学会了写 Skill、测 Skill——但单兵作战的能量到此为止。Skill 的真正威力是5 人 / 50 人 / 500 人用同一份。本章讲怎么从单 skill → 团队 skill library → 跨团队 plugin 分发。 24.1 三类 Skill 库形式 ─────┬────────────────────┬───────────────────────────────────── 形式 │ 适用 │ 实现 ─────┼────────────────────┼───────────────────────────────────── monorepo │ 中小团队 │ 一个 git repo 包含所有 skill multi-repo │ 多部门 / 多产品线 │ 一个 skill 一个 repo, plugin manager 安装 hub+spoke │ 公司级 │ 内网 hub central, 各 repo 上传/同步 ─────┴────────────────────┴───────────────────────────────────── 24.2 Skill Monorepo: 适合起步 每个 skill 是一个文件夹，整个 repo 是 . /posts/2026/07/skill-testing/ Wed, 15 Jul 2026 00:00:00 +0000 /posts/2026/07/skill-testing/ Skill 写完不等于"做完"——它跟代码一样会被模型版本变化、用户工作流变化、新 harness 行为变化折腾。本章把 Skill 当成 software：有 unit test、有 regression、有 changelog，让它在 6 个月后还能用。 23.1 为什么 Skill 也需要测试 不要等你某天打开 OpenCode 发现某个 Skill 触发率从 70% 跌到 5%——Skill 的"准确度"会随模型版本而漂移，prompt 中某词语的 token 化变了，召回就崩。可追踪、可回归是关键。 23.2 三类测试 类型 名称 测试对象 1 Trigger test “在 X 输入下会被召回吗” 2 Behavior test “被召回后遵循 Skill 内的 flow 吗” 3 Regression test “上次行为跑得 OK，这次没变吗” 23.3 Trigger test：写 probe 集 Create tests/probes.toml： [[probe]] text = "给 lib/validators.py 加一个 is_alpha 函数" expect = "engaged" [[probe]] text = "为什么 Python 不需要类型? /posts/2026/07/first-skill/ Mon, 13 Jul 2026 00:00:00 +0000 /posts/2026/07/first-skill/ 理论 21 篇讲完了，本章从零写一个真实 Skill，让你看一遍从想法 → 写 SKILL.md → references 拆解 → 测试 → 装入 OpenCode → 上调用的全过程。我们要写的 Skill 叫 tdd-reminder：让主 Agent 在写新代码前先提示用户走 TDD。 22.1 Skill 想法从哪里来 三步法挖掘想法： 找你过去 7 天的 OpenCode session log grep 模式 “你忘了 / 你没做 / 应该先” rg "忘了\|应该\|未做\|先\|要是之前" .opencode/log/ | head -20 凡是出现 3 次以上的模式，就是候选 Skill 我自己日志里有一条：“每次写完 Python 函数才发现没写测试，又往回加 test_test_xxx，凑合跑”——这就是 tdd-reminder 要解决的：让 Agent 在写实现代码前主动说一句"咱们先写 test 行吗"。 22.2 拆解 Skill 行为需求 维度 spec Trigger 主 Agent 即将写 Python / TS / Go / Rust 代码,且函数 / class 存在 不要触发 1）用户问解释性问题 2）改一行小 bug 3）已有现成测试 行为 提醒想先写 unit test；提供一次 brainstorm 机会,而非强制 DONE 用户明确说 “不用 test” 或 用户已提供 test 或 单元 test 跑通 失败模式 1）用户说"快点别叨叨" → 跳过加 [tdd-reminder skipped] 自报\n2）该语言无 pytest 等价物 → 改用最简化 shell test 22. /posts/2026/07/skill-design/ Sat, 11 Jul 2026 00:00:00 +0000 /posts/2026/07/skill-design/ Skill 不是一个 prompt 模板，这两件事看着一样、实则差别巨大。模板只描述"这样说话"；Skill 描述"在某个场景下，我承诺我会有什么行为"。差别让它从一次性 evolves 成可被信任的复用单元。本章拆出 7 条设计原则。 21.1 原则 1：Trigger 必须可机器判别 Skill 写得再好，靠"模型自己看着办" 何时启用，迟早翻车。 # ❌ 模糊 Trigger: 用户在创造性工作时启用 # ✅ 显式 Trigger: - starts_with_any: ["我要加", "我需要实现", "开一个新", "新增功能"] - or_intent: [create_feature, modify_behavior, add_capability] - not_when: [reading, explaining, debugging] 判别三种实现量化（参考 superpowers 的 trigger 语法）： 关键字模糊匹配：含 “实现” / “重构” / “新增” 意图分类：模型先做一次轻量分类决定 intent 元 hook：harness 在 before_user_msg / before_response 等时机注入 OpenCode 偏重 1+3 组合：BM25 关键字加权 + 用户显式 slash command。 /posts/2026/07/skill-concept/ Thu, 09 Jul 2026 00:00:00 +0000 /posts/2026/07/skill-concept/ 前 19 章学的 ReAct、loop、Graph、MCP——这些都是"通用基础设施"。但你自己干一段时间活后，会沉淀出只对你 / 你团队有意义的经验：commit 写法、code review 风格、部署节奏、文档模板。Skill 就是把这些沉淀变成"可加载单元"。这一篇把 Skill 是什么、不同 harness 的差异、生态发展讲透。 20.1 什么是 Skill Skill = 一个文件夹，里面有 SKILL.md 和可能的 references，可被 harness 自动加载，达到"在某场景出现时就调度某种行为"的效果。 my-skill/ ├── SKILL.md ← 主体: trigger + 描述 + 流程 └── references/ ← 可选 references ├── patterns.md └── antipatterns.md 更精确地说，Skill 包含三要素： 要素 作用 例 Trigger 在什么场景被激活 before_any_response / 用户说"review" Content 一个 SKILL.md 系统提示,讲解该怎么干 “评审一定要看 diff 不要看好译码” References 给主 Agent 按需打开的子文件 “patterns.md / anti-cases.md” Skill 不是 plugin——它不一定要带可执行代码。SKILL. /posts/2026/07/mcp-ecosystem/ Tue, 07 Jul 2026 00:00:00 +0000 /posts/2026/07/mcp-ecosystem/ 到 2026 年中，MCP 已经不是孤本协议——OpenAI、Google 都相继发布了兼容或类似方案，社区出现了网关、注册中心、SDK 翻译器。本章把生态、竞争与未来一年的趋势快速过一遍——选型时不被新闻带歪、写代码时知道边界在哪。 19.1 同类协议与兼容 协议 / 标准 出身 跟 MCP 关系 现状 MCP Anthropic 2024-11 基线 OpenAI / Cursor / Continue / LangChain 等主流支持 OpenAI Tool Spec OpenAI function calling 兼容可桥接 老 API 默认；新 Responses API 也能扩 MCP Google A2A Google 2025 Agent-to-Agent；与 MCP 互补 主打 agent 之间通信，工具发现仍走 MCP AGNTCY / LF AgentSkills Linux Foundation 早期 多大厂合作，偏运行时 LangGraph Tools LangChain 库内 Adapter 在 graph 里把 MCP 当 node 用 实用结论：MCP 已经是工具发现的事实标准；A2A 是 Agent 互操作的事，更往上一层。 /posts/2026/07/mcp-advanced/ Sun, 05 Jul 2026 00:00:00 +0000 /posts/2026/07/mcp-advanced/ 上一章我们以 Tool 为核心写了第一个 MCP server。MCP 还有两件大杀器没用上：Resources 让 Agent 主动拉数据；Prompts 把常见对话模板做成快捷指令。再深一层，还能让 server 反过来调模型——sampling。本章打完 MCP 的完整能力包。 18.1 三原语职责回顾 Tool 模型决定调用 / 有副作用 类比"实习生执行命令" Resource 客户端按需读取 / 无副作用 类比"调用 卡片盒" Prompt 用户主动选择的快捷方式 类比"slash command / 应用菜单" Sampling server 反过来调 LLM 类比"反向 function-call" 理解这四件事的发起方向是关键。混用 = bug；分开 = 协议清晰。 18.2 Resources 实战：把"工单列表"做成可拉数据 18.2.1 何时 Resources > Tools 判据 Resources 适合 Tools 适合 调用方 harness 周期性拉、缓存 模型按需 invoke 副作用 无 有 数据形态 静态文档 / 列表 / 配置 函数调用结果 大小 中等（KB-MB） 小（KB 以内为佳） 举几个常见 Resource 设计： /posts/2026/07/mcp-server-dev/ Fri, 03 Jul 2026 00:00:00 +0000 /posts/2026/07/mcp-server-dev/ 读完生态速览，你大概发现 30% 的需求是现成 server 满足不了的——尤其是自家业务 API和团队内部数据。本章手把手写一个：把公司内部 admin API 暴露成 MCP，让所有 harness 都能调用。 17.1 任务范围 做一个 MCP server 叫 mcp-tickets，让 Agent 能： 列出内部工单系统里的 ticket（按状态） 取一条 ticket 详情 给 ticket 加一条 internal comment 只读为主，写操作需要确认 我们用 Python 写（生态成熟，团队好上手）；TypeScript 版结构近似，章末给一行对比。 17.2 起手装环境 uv init mcp-tickets cd mcp-tickets uv add "mcp[cli]" uv add httpx pydantic mcp[cli] 是官方 Python SDK，含 stdio server 与 cli 工具。httpx 是要调内部 API，pydantic 做参数校验。 17.3 项目骨架 mcp-tickets/ ├── pyproject.toml ├── src/ │ └── mcp_tickets/ │ ├── __init__. /posts/2026/07/mcp-servers/ Wed, 01 Jul 2026 00:00:00 +0000 /posts/2026/07/mcp-servers/ 写自己的 MCP server 前先看——2026 年的生态已经很丰富，许多场景套个现成的就能跑。本章把高频 server 速览一遍，让你的"自写冲动"用在真正缺的环节。 16.1 三类速览 ┌───────────────────────────────────────────────────────────┐ │ 类别 │ 代表 server │ ├───────────────────────────────────────────────────────────┤ │ 系统与工程 │ filesystem / git / github / brave-search│ │ 数据与知识 │ postgres / sqlite / context7 / notion │ │ 业务与平台 │ slack / linear / jira / gdrive │ └───────────────────────────────────────────────────────────┘ 16.2 系统与工程类 filesystem (官方) 提供 read_file / write_file / list_directory / search_files 谁需要：让 Agent 改本地文件，但 harness 已自带 Edit/Write——重合度大。若 harness 已有，可省 git (官方) git status / log / diff / commit 包装 重点：MCP 化的 git 比裸 bash git 有结构化输出，便于 Agent 解析冲突 github (official) 暴露 issue / PR / repo 操作 用例：让你在 Cursor 里直接 “create PR for this branch”，而不切回浏览器 注意权限：用 fine-grained PAT，scope 限定到所需 repo brave-search / exa / tavily-search 给 Agent “实时网络搜索” 能力。pretrain 之外的"互联网" 用法差异：brave 偏 web、exa 偏语义、tavily 偏 LLM-friendly 16. /posts/2026/06/mcp-protocol/ Mon, 29 Jun 2026 00:00:00 +0000 /posts/2026/06/mcp-protocol/ 到这里，你已经能让 Agent 在自己的进程里跑工具了。但工具是"私"的——你写一个 bash tool，只有你的 Agent 能用。让任何 Agent 都能用同一份"工具集"，需要的是协议。Anthropic 在 2024 年底发布了 Model Context Protocol（MCP），2026 年中已成了 de-facto 标准。本章把 MCP 的协议机制讲透。 15.1 MCP 要解决的问题 Pre-MCP 混乱： Cursor 自己定义一套 tool spec，跟 Claude Code 不同 Claude Code 自己一套，跟 LangChain 不同 你给团队写个内部 API agent 工具，要实现 3-5 遍 Post-MCP： ┌───────────┐ ┌──────────────┐ │ MCP Client │ ─── MCP ────→ │ MCP Server │ │ (任何 Agent)│ │ (工具实现者) │ └───────────┘ └──────────────┘ 客户端只问："你能干啥？" → 服务端回答一组标准 schema 客户端说："调用 foo 工具" → 服务端返回结果 MCP = “USB-C 接口” for AI Tools。一个 server 实现一次，Any Client 都能用。 /posts/2026/06/agent-observability/ Sat, 27 Jun 2026 00:00:00 +0000 /posts/2026/06/agent-observability/ 传统软件的 bug 多在"代码逻辑出错了"——你能读 stack trace。Agent 的 bug 多在"模型决策出错了"——stack trace 给你的是一句它怎么想的，而不是它怎么错的。本章讲怎么把 Agent 这种黑盒变白盒，让你和 Agent 一起 debug。 14.1 Agent bug 的四种错误形态 错误形态 现象 典型解法 根因层 ───────────────────────────────────────────────────────── Prompt bug 模型理解任务错误 改 prompt + 例 Prompt Tool bug tool 拖了 water fix tool 实现 Tool Loop bug 卡 / 自我提前终 调预算/校验 Loop Context bug 信息被误信 / 没看见 压缩/重排 Context 这四层 bug 出错的修法是完全不同的，混在一起 = 接 debug。要建立"先分类 → 后修"反射: 先问错在哪层。 14.2 三种必须的工件 任何 Agent harness，至少要留下三种工件，否则 debug = 玩猜: /posts/2026/06/subagent-delegation/ Thu, 25 Jun 2026 00:00:00 +0000 /posts/2026/06/subagent-delegation/ 要让 Agent 干大工程，单 loop 是不够的。这一章讲如何把"长任务"，拆给多个 subagent 并行执行；讲怎么避免"群里每个 agent 都在重复劳动"的灾难。这是后面第 28 章：实战多 Agent 系统 的方法论基础。 13.1 Subagent 是什么 Subagent 是 harness 内部又开出来的一个 Agent，它本身的 LLM 调用是独立的，自己去拿工具、自己做 ReAct、自己结束。能并行 = 能在一台机器上同时让 3 个 Agent 都在工作。 主 Agent (Build / Sisyphus) │ ├─ task → explore "找叫 lock 的所有文件" ├─ task → explore "find all TODO 与 FIXME" └─ task → librarian "查 anthropic Messages API 当前最大 token" │ 并行 (.await asyncio.gather) │ 合并 sub-agent 的最终输出 → 给主 Agent 主 Agent 与 subagent 的差别只有一点： /posts/2026/06/agent-harness/ Tue, 23 Jun 2026 00:00:00 +0000 /posts/2026/06/agent-harness/ 到目前为止，我们都是徒手实现 Agent 的循环。但真实的"Agent 工具"——Claude Code / Codex / OpenCode——是把 30 行的 ReAct 拆成几万行，里面装着计划、记忆、skill、子 agent、可观测性、权限。本章把这些"上层建筑"通称叫 Harness，让你从工具使用者升级到工具理解者。 12.1 Harness 是什么 Harness 这一词来自骑马——给马套上挽具，让人能驾驭马的能力，但不替代马。Agent Harness 同义：把 LLM 的"思考与产码"能力放到一个可控制的执行壳里，加 UI、加权限、加 memory、加 tool registry，但不替代 LLM 在循环中的主角身份。 ┌────────────────────────────────────────────────────────────────┐ │ USER (intent) │ ├────────────────────────────────────────────────────────────────┤ │ Harness Layer │ │ ┌───────────┐ ┌─────────────┐ ┌───────────┐ ┌──────────────┐ │ │ │ UI / CLI │ │ Permission │ │ Memory │ │ Skill Loader │ │ │ └───────────┘ └─────────────┘ └───────────┘ └──────────────┘ │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ Agent Loop (ReAct) │ │ │ │ Thought → Action → Observation → . /posts/2026/06/agent-graph/ Sun, 21 Jun 2026 00:00:00 +0000 /posts/2026/06/agent-graph/ 单一 ReAct 循环是 Agent 的"单核"——但很多真实任务天然就是图（DAG），而不是直线。本章把 Agent 从"循环"扩展到"有向图"，让你能把分支、并行、汇合、回退写到系统里，而不是让模型现编。 11.1 为什么单 Loop 不够 让 AI 做一个"自检 + 修复一束文件"的任务，在单 loop 里跑大概是这样： thinking: 看 5 个文件 (生成 list) ↓ tool: read 文件 1 ↓ thinking: 文件 1 没问题 ↓ tool: read 文件 2 ↓ thinking: 文件 2 有 lint 错 ↓ tool: edit 文件 2 ↓ ...重复 5 轮，每次都让"thinking"来做路由决策 问题：你反复让模型决定"下一步该看哪一支"，但其实流程是确定的：每个文件都看一遍、有问题就修。这把"决策权"浪费在了不必要的地方，还让模型容易漏一两个文件。 这是 Graph 工作流要解决的事：把"必然要做的形状"画成 DAG，模型只做每个节点的"实质推理"，流程通过图去接管。 11.2 Graph Agent 的三件套 ┌─────────────────────────────────────────────────────┐ │ Node : 一个 f(input) -> output 的小 Agent │ │ Edge : 节点之间的连接，可以是固定的 │ │ 也可以是 condition 提供的分支选择 ──┘ │ │ State : 在所有节点之间流动的共享字典 │ └─────────────────────────────────────────────────────┘ 11. /posts/2026/06/agent-loop/ Fri, 19 Jun 2026 00:00:00 +0000 /posts/2026/06/agent-loop/ 上一章的 ReAct 是个心智模型，代码不长。本章把 ReAct 真正做成"长跑循环"——加入预算、反思、终止、错误恢复，让它能扛 30 分钟级别任务而不会"撒手就跑飞"。 10.1 最小 Loop 的三处不完美 把上一章那 30 行 loop 真正跑长跑，它会失败在哪？ 现象 根因 需要加什么 token 烧到天亮 没有预算 max_tool_calls / max_tokens 模型反复试同一个错 没有"反思" 失败后回看 trace，让模型给假设 任务没完就被模型自己说终了 缺乏 “DONE validation” 终止前问"DONE"三问 一遇工具 exception 就直接 crash 没有异常通道 tool errors 当 message 喂回 Agent 跟上下文对话头尾都说不止 缺乏沉淀 在循环里维护 state.json 10.2 一个稍微长一点的最小 Agent Loop from dataclasses import dataclass, field @dataclass class AgentState: history: list = field(default_factory=list) tool_calls: int = 0 max_tool_calls: int = 20 failures: list = field(default_factory=list) def step(state: AgentState, user_msg: str) -> tuple[str, AgentState]: if state. /posts/2026/06/agent-concept/ Wed, 17 Jun 2026 00:00:00 +0000 /posts/2026/06/agent-concept/ 前 8 篇我们都在解决"如何让模型答得好"这个问题。第 9 篇开始换主角：从 “答” 到 “做"。一个能用 bash 改文件、能跑 test、能在 test 跑红时改代码再跑的 AI——这就是 Agent。本章把"Agent 是什么"和"它和 chat 的真实区别"讲透。 9.1 Chatbot vs Agent：从被动到主动 Chatbot ┌────────────────────────────────┐ （被动回答） │ user msg → model → 回答 → 结束 │ └────────────────────────────────┘ Agent ┌────────────────────────────────┐ （主动执行 + 循环） │ user msg → model → 工具调用 → │ │ 工具输出 → model → 又一个工具调用 → │ │ ... → 最终回答 → 结束 │ └────────────────────────────────┘ 核心区别：能不能在"思考 → 行动 → 观察 → 再思考"的循环里待足够久。Agent 的"待"不是时长，是这个 agent 里有几次转弯、能不能纠错。 /posts/2026/06/ai-dev-env-setup/ Mon, 15 Jun 2026 00:00:00 +0000 /posts/2026/06/ai-dev-env-setup/ 工欲善其事必先利其器。本章搭建一个可工作 + 可沉淀的环境：从 L1 补全到 L3 Agent harness，从单一工具到多工具协作，附带一份让你能直接照抄的"五文件起手配置"。 8.1 起手目标 本章结束，你应有： 一个能跑 Claude Code / OpenCode 的终端 一个支持 OpenAI / Anthropic 互换的 model 后端配置 一份 AGENTS.md / CLAUDE.md / OPENCODE.md (按你选择的工具) 一份 .opencode/skills/ 或 .claude/skills/ 目录（即使空着） 一份 SECURITY.md 兜底 一个本地运行的开发日记脚本：记录你今天回到了哪些 prompt 8.2 选 L1：先架 IDE 这层 选项 A：VS Code + Copilot / Continue # 安装 VS Code（如未） winget install Microsoft.VisualStudioCode # Windows brew install --cask visual-studio-code # macOS # 装 GitHub Copilot 扩展 → 登录 → 默认开启 Tab 补全 # 或 安装 Continue（开源替代） → 配置自托管后端 优点：稳、所有 AI 协作出现兼容性的起点 缺点：还是要靠你切换工具 /posts/2026/06/ai-safety/ Sat, 13 Jun 2026 00:00:00 +0000 /posts/2026/06/ai-safety/ 2026 年已经出现过好几起"AI 帮倒忙"的标志性事故：把密钥 push 到 GitHub、给生产库连上错误的 migration、把内部 API token 写进开源 Skill 包……大多数事故根因不是模型"变坏了"，而是遵守的边界没说清。本章把 AI 编程里你必须画的几条红线讲清——你不对自己的代码负责，没人会替你负责。 7.1 AI 编程的四类风险 ┌──────────────────────────────────────────────────────────────────┐ │ 风险 | 描述 | 触发场景 │ ├──────────────────────────────────────────────────────────────────┤ │ 泄密 | 把 secret / 内部数据 / PI 写入产出 | 复制粘贴上下文 │ │ 漏洞 | 生成的代码 0day / 加固被错解 | 不做 review │ │ 幻觉 | 引用不存在的 API / 包装不存在的方法 | 不验证 │ │ 责任 | "AI 说这样写没问题"，结果违反合规 | 出事甩锅 │ └──────────────────────────────────────────────────────────────────┘ 7.2 泄密：最容易踩、最不该踩 7. /posts/2026/06/vibe-coding/ Thu, 11 Jun 2026 00:00:00 +0000 /posts/2026/06/vibe-coding/ “Vibe Coding"这个词最早由 Andrej Karpathy 在 2024 年初抛出，他对它的定义其实带点自嘲： “我大部分时候就在大写英文、调高音量、感觉对了就按 Enter。” 五年后我们回头看，K老师的玩笑是有认真内核的——大规模 AI 协作确实改变了我们和代码之间的"心智带宽分配”。本章不会变成玄学，而是把"vibe"翻译成可以练习的几条节奏律。 6.1 Vibe = 心智带宽的重新分配 传统编程心智： ┌──── 写代码（70%）/ 设计（20%）/ 调试（10%）────┐ AI 协作心智： ┌── 描述（30%）/ 评审（40%）/ 抽象沉淀（30%）──┐ 观测到的几点 2026 年版现实： 写：从"逐字敲" → “一次性给整段样板” 读：从"看自己代码" → “看模型生成的别扭写法，比对自己的预期” 沉：从"知道在脑子里" → “写进 .md，下次再被模型看见” 这个第三件事最反直觉：你以前懂得多就好；现在写得下才算数。 6.2 五条节奏律 6.2.1 节奏律一：Quick Loop 比单次 hit 重要 ❌ 一次让 AI 写完整功能 → 拿来用 → bug 满天飞 ✅ 一次一个微功能 → 让它跑 → review → 下一节 把每一段都做成"30 秒内能看到结果"的大小。Claude Code 的 Plan / Subagent 都在强化这个 30s-to-result 节奏。 /posts/2026/06/ai-tools-landscape/ Tue, 09 Jun 2026 00:00:00 +0000 /posts/2026/06/ai-tools-landscape/ AI 编程工具在 2025 年下半年开始大规模爆发，到 2026 年已经分成清晰的三层。本章不教你怎么按按钮，而是把每一层的"擅长点 + 短板"讲清——选型时，工具之间的差异远小于你想象，关键是把对的事用对工具做。 5.1 三层工具栈 ┌──────────────────────────────────────────────────┐ │ L3 · Agent Harness │ │ Claude Code / Codex CLI / OpenCode / Cursor Agent│ │ 能跑命令、改多文件、自循环执行任务 │ ├──────────────────────────────────────────────────┤ │ L2 · AI IDE / 工作区 │ │ Cursor / Windsurf / Copilot Workspace │ │ 带 chat + 多文件编辑、引用当前工程 │ ├──────────────────────────────────────────────────┤ │ L1 · In-Editor 补全 │ │ GitHub Copilot / Tab / Codeium │ │ 单行/小片段补全 │ └──────────────────────────────────────────────────┘ 三层不是"高级 = 顶级"——L1 仍然在 2026 年的日常编码里是高频出现的，因为它快。三层是协作而非替代。 /posts/2026/06/context-engineering/ Sun, 07 Jun 2026 00:00:00 +0000 /posts/2026/06/context-engineering/ 如果说 prompt 工程是"怎么说话"，上下文工程就是"让模型能看到什么"。这是 2025–2026 年 AI 工程师的核心能力——因为模型能力本身已经够强，前 80% 的产出差距来自上下文喂得对不对。 4.1 三种获取"知识"的方式 模型要"知道事情"，只有三条路： ┌─────────────────────────────────────────────────────────────┐ │ 1. Pretrain ：训练时就背在脑子里了 │ │ 2. Context ：你这次对话贴进来，模型看到了 │ │ 3. Tool Call ：模型调用工具（搜索、读文件、grep）拿到结果 │ └─────────────────────────────────────────────────────────────┘ 三者构成一个预算三角：pretrain 是免费的但有时效与范围；context 是最贵但最准确；tool call 介于两者之间，但要模型"会调用"。 关键洞察：所有"AI 编程工具"——Cursor、Claude Code、Copilot Workspace、OpenCode——做的核心事都是这三种方式的自动调度。 4.2 RAG：检索增强生成 RAG 解决一个矛盾：你想让模型回答某个文档里的事，但塞全文进 context 太贵太脏。做法是先检索 → 拿到相关片段 → 把片段塞进 context。 # RAG 的极简伪代码 def answer(query: str, knowledge_base: list[str]) -> str: # 1. 把知识库切成 chunk 并预计算 embedding chunks = [chunk for doc in knowledge_base for chunk in split(doc, size=512)] chunk_embeddings = embed(chunks) # 2. /posts/2026/06/prompt-engineering/ Fri, 05 Jun 2026 00:00:00 +0000 /posts/2026/06/prompt-engineering/ Prompt 工程不是"魔法咒语学"。它是一种把任务讲清楚的能力——本质和你跟同事讲需求时讲得清楚不清楚没差别，只不过对面这个"同事"在某些维度更敏感（对结构、对示例、对上下文），在另一些维度更迟钝（不会自己反问、对领域黑话毫无知觉）。本章让你不是去背 100 句"完美 prompt 模板"，而是建立一套底层心法。 3.1 一个反直觉：把模型当实习生，而不是当神 坏 prompt：写一个爬虫 好 prompt： 目标：爬取 https://example.com 上分页列表的标题。 输入：起始 URL（list 页第 1 页）。 输出：写入 items.jsonl，每行一个 {url, title}。 约束：使用 httpx + selectolax，遵守 robots.txt，限速 1 req/s。 错误处理：403 跳过该页，其他状态码重试 3 次。 差别不在字数，而在让模型知道边界。模型是个"特别想被使用的实习生"——你给的信息越具体，它越不会瞎发挥。 3.2 五元素清单 每次写 prompt 默念一遍： 元素 作用 常被漏掉导致 目标（Goal） 一句话说清产出是什么 跑题、答非所问 输入（Input） 模型能拿到什么数据 自己编数据幻觉 输出（Output） 形式、格式、字段名 你要 csv 它给你 md 约束（Constraints） 不能做什么、用什么库 库不一致、风格漂移 示例（Examples） 1-2 条"输入→输出"样板 边界情况误判 后两个最容易被偷懒省掉，也是新手与熟手 prompt 之间最大的差距来源。 3.3 三种情境，三种写法 3.3.1 一次性任务（最常见） 任务：把下面 SQL 解释给非技术同事听。 SQL: EXPLAIN ANALYZE SELECT region, sum(revenue) FROM orders WHERE created_at > '2026-01-01' GROUP BY region; 输出要求： - 一句话主旨 - 三到五条要点 - 最后一句给一个最关键的"为什么慢"的提醒 - 不超过 150 字 要点：明确形式 + 字数上限 + 受众。能压字数比讲道理有用。 /posts/2026/06/llm-fundamentals/ Wed, 03 Jun 2026 00:00:00 +0000 /posts/2026/06/llm-fundamentals/ 你不需要在 2026 年亲手写一个 Transformer，但你需要知道它"葫芦里卖的什么药"。AI 协作之所以常常翻车，根源往往是把模型当成"懂你心思的人"——而它实际只是在玩一个非常精彩的语言接龙游戏。本章把 LLM 的几个底层概念讲清楚，让你以后每一句 prompt 都有底。 2.1 LLM 在干什么 一句话：给定上文，预测下一个 token。 Input: "今天天气" Model: → 预测概率分布 {"真":0.21, "不":0.18, "挺":0.10, ...} Output: 选一个 → "真" Loop: "今天天气真" → 再预测下一个 token ... 仅此而已。模型不做"思考"，它输出一段看起来像思考的字符序列。理解这一点非常重要——所有的"魔法"都来自这个朴素的循环。 2.2 Transformer 与注意力 Transformer 是当前主流 LLM 的骨架，核心是 self-attention：让序列中每个 token 与其他所有 token 算一组相似度权重，再用权重做加权平均。 # 自注意力的最简示意（省略缩放、归一化、多头等细节） import torch import torch.nn.functional as F def attention(Q, K, V): # Q, K, V: (seq_len, d_k) scores = Q @ K.T # (seq_len, seq_len) 谁和谁相关 weights = F. /posts/2026/06/ai-course/ Mon, 01 Jun 2026 00:00:00 +0000 /posts/2026/06/ai-course/ 2026 年是开发者的"AI 元年"。Copilot、Cursor、Claude Code、Codex、OpenCode 这些工具，已经把"写代码"这件事从一项孤军奋战的手工活，变成了一场人机协作的对话游戏。从单文件补全到多 Agent 编排，从 prompt 工程到 MCP 协议，从 vibe coding 到 skill 沉淀——AI 开发不再是一个噱头，它是新一代工程师必须掌握的基础能力。 本系列从零基础出发，系统拆解 AI 开发的完整知识图谱： 底层认知：大语言模型如何工作，能力与边界在哪里，上下文窗口与 token 是什么 协作心法：Prompt 工程与上下文工程，Vibe Coding 的理念与节奏 自动化体系：Agent / Loop / Graph / Harness / Subagent 五个关键概念如何串成自治开发流水线 能力扩展：MCP 协议如何让模型连接世界，Skill 如何把一次性经验沉淀为可复用的能力包 实战淬炼：6 个由浅入深的实战案例，从重构遗留项目到搭建多 Agent 工作流，从开发 MCP server 到发布 Skill 库 无论你之前是完全没接触过 AI 工具的程序员，还是已经写了半年 Copilot 想迈向更高阶用法的开发者，都能在这个系列中找到清晰的进阶路线。 课程大纲 第一篇 · 基础认知篇 AI 开发时代导论：从工具到伙伴 大语言模型原理与实践 Prompt 工程入门：与 LLM 有效沟通 上下文工程：RAG 与长上下文 主流 AI 编程工具全景 Vibe Coding 理念与心法 安全与责任：AI 编程的边界 开发环境搭建：从 IDE 到 Agent CLI 第二篇 · Agent 与自治篇 Agent 概念：从助手到自治 Loop 机制：自循环任务执行 Graph 工作流：多节点编排 Harness 框架：OpenCode 与 superpowers 任务委派：Subagent 与并行执行 Agent 调试与可观测性 第三篇 · MCP 篇 MCP 协议详解 常用 MCP server 实践 MCP server 开发实战 进阶 MCP：传输、资源、提示 MCP 生态与未来 第四篇 · Skill 篇 Skill 概念：能力封装的艺术 Skill 设计原则与最佳实践 编写第一个 Skill Skill 测试与迭代 Skill 库管理与发布 第五篇 · 实战篇 实战一：用 AI 重构遗留项目 实战二：构建知识库 MCP server 实战三：开发团队 Skill 库 实战四：搭建多 Agent 协作系统 实战五：AI 测试与 CI 集成 终章：AI 开发者的成长路径 本系列文章以 2026 年中期的主流工具栈 为基准：Claude Code / Codex / OpenCode / Cursor / GitHub Copilot 等。AI 工具迭代极快，本文中的具体产品界面、命令行参数可能随版本演进——以"原理 + 心法"为主线，把"工具 + 命令"当作示例。 /posts/2026/06/ai-intro/ Mon, 01 Jun 2026 00:00:00 +0000 /posts/2026/06/ai-intro/ 欢迎来到《AI 开发从入门到精通》系列的第一篇。如果你打开这篇文章，说明你已经感受到 AI 正在改变写代码这件事——但你可能还没有清晰的方法论，不知道该从哪里开始、走到哪里去。本系列就是为解决这个问题而生的。 1.1 三个时代，三种程序员 把时间拉远看，软件开发的"主旋律"大约每十年换一次： 时代 主旋律 程序员的核心动作 1990s–2010s 语言与框架 学语法、背 API、写样板代码 2010s–2020s 云与 DevOps 学容器、写 CI、配 YAML 2023–当下 AI 协作 描述意图、审阅产码、抽离模式 第三行的"程序员"不再是逐字逐句敲代码的书记员，而更像一个产品经理 + 评审员 + 架构师的混合体。你描述意图，AI 给出第一稿；你做评审，AI 改第二稿；你做架构决策，AI 负责蜜糖细节。这种模式有人叫"AI 辅助开发"，Andrej Karpathy 在 2024 年给它起了个更带感的中性名字——Vibe Coding：跟着感觉走，让模型把感觉变代码。 1.2 为什么现在必须学 三条硬证据： 生产力差距是非线性的。 一个熟练的 AI 协作者，与一个不熟练的同侪相比，大量 1–3 天的小任务会变成几小时。半年累计下来是数量级别的产出差。 代码本身正在被重构。 Markdown / TOML 正在变得和 TypeScript / Rust 同样重要——因为 AI 工具的"配置"（Skill、prompt、AGENTS.md）本身就是产品形态之一。 AI 工具的开发是双向赋能的。 你不仅在用 AI，还会用 AI 去构建更强大的 AI 工具（Skill、MCP server、Agent harness）。从这个角度看，“用 AI 写代码"和"开发 AI 工具"不是两件事，是同一件事的两个阶段。 1.