AI

什么是 Loop Engineering Loop Engineering 是 2026 年上半年在 AI Agent 圈子里逐渐流行的说法。它的核心思路是：与其由人逐步编写 Prompt、检查结果、再发出下一条指令，不如先设计一个自动循环系统，明确目标、检查方式和停止条件，让 Agent 按照「感知 → 行动 → 观察 → 再决策」的过程反复迭代，直到任务达到可验证的完成状态。 每个 Agent 本质上都运行在某种循环中。Loop Engineering 关注的是有意识地设计这个循环，包括：Agent 每轮能看到什么、可以执行什么操作、如何取得反馈、谁负责判断完成，以及什么情况下必须停止。 这个模式可以追溯到 ReAct（Reason + Act）范式：模型推理后采取行动，再根据环境返回的观察结果继续推理。Loop Engineering 将这种「推理—行动—观察—重复」的过程扩展为可控制、可验收的工程流程。 与 Prompt Engineering 的区别 维度 Prompt Engineering Loop Engineering 人的工作 编写当前这一步的指令 设计目标、反馈、验证和停止条件 执行方式 通常是一次或少量交互 自动进行多轮迭代 完成判断 人或执行任务的模型临场判断 预先定义的检查器或验收条件 适用场景 问答、生成单个结果、短任务 自动代码生成、软件维护、多步骤自主任务 两者不是替代关系。清晰的 Prompt 仍然是循环中每一步的输入；Loop Engineering 解决的是如何让这些步骤持续运行，并在正确的时机停下来。 一个循环需要哪些部分 一个可用的 Loop 通常包含以下要素： 目标：最终需要达到的状态，而不只是要执行的动作。 行动范围：Agent 可以读取、修改和执行哪些内容。 反馈：测试、构建、CI、部署状态或其他环境输出。 完成条件：可以重复执行并得到明确结果的验收检查。 状态：跨轮次保存的需求、进度、失败摘要和已完成事项。 停止条件：成功、达到最大轮次、超时或遇到不可恢复错误。 完成条件应尽量由测试退出码、构建结果、文件状态等客观信号表达，而不是让 Agent 根据自己的回答判断「应该已经完成」。这也是 Harness Engineering 能为 Loop 提供的关键能力：Loop 决定继续还是停止，Harness 提供可重复的验收信号。 ...

从 Prompt 到 Graph AI 驱动开发大致走过几条主线：Prompt Engineering 解决「怎么说清楚」；Context Engineering（含 RAG）解决「给模型看什么」；Loop Engineering 解决「让 Agent 自我修正」——给一个任务，改代码、跑测试，失败了再继续修。 复杂业务里，单 Agent 的 Prompt Loop 很快会顶到天花板。Graph Engineering（图工程）把流程拆成有向图：节点专职分工，边负责确定性控制流，AI 只承担局部推理与代码生成。下面按「为什么需要 → 怎么划职责 → 怎么落地」写一版可落地的骨架。 不想额外起 Python 主控、只在 Claude Code 里管多阶段任务时，见 Graph Engineering：纯 Claude Code 实现。 为什么需要 Graph Engineering Loop Engineering 在「单任务、短轮次」时很好用。一旦任务变长、角色变多，常见会撞上三类问题。 上下文污染（Context Pollution） 循环次数上去后，会话里堆满历史报错、半成品 diff、无效尝试。模型要在噪声里找有效信号，表现会越来越差：重复改同一处、忽略刚写过的约束、或「修 A 弄坏 B」。根因往往不是模型突然变笨，而是上下文被污染了。 缺乏确定性控制（Nondeterminism） 若下一步完全由 LLM 在 Context 里自行决定，容易陷入死循环：同一失败路径反复尝试，或越改越散。控制流（何时重试、何时换策略、何时中止）若也交给模型，系统就缺少可预期的停机条件。 职责模糊 让同一个 Agent 同时做架构规划、写前后端、跑单测、做 Code Review，等于把多种能力边界揉进一次长会话。结果常常是：规划被实现细节冲淡，实现被 review 口径扯偏，测试结论又被前序噪声干扰。 Graph Engineering 的应对方式很直接：用有向图把复杂流程解耦为专职节点（Nodes）；把控制流交还给确定性的代码（Edges）；只把局部推理与代码生成交给 AI。 Graph Engineering 在说什么 可以把它看成三层分工： ...

这篇写什么 Graph Engineering 的完整落地通常是：Python + LangGraph 当指挥官，Claude Code 当执行者，pytest 一类命令当 quality gate。有时不想额外起一个 Python 主控进程，只想在 Claude Code 里把一段有依赖关系的多阶段任务当图来管。 本文只写这条路径：控制流、节点隔离、跨节点状态都尽量落在 Claude Code 自带能力或手工骨架上，不接 LangGraph。图工程「为什么需要」以及三层分工的完整论述见母文；这里默认读者已经接受「用有向图拆专职节点、把控制流从 Prompt 里抽出来」这一目标。 能落地到两种深度，选哪种取决于要不要付节点隔离和显式状态的成本。 轻量方案：任务队列当 DAG DAG（Directed Acyclic Graph，有向无环图）说的是：节点之间有方向（A 依赖完成后才能做 B），但不能成环（不能出现 A → B → A，否则永远等不到起点）。任务列表里的「阻塞 / 被阻塞」关系正好就是这种结构——依赖边把阶段串成可调度的顺序，而不是随便挑一个未完成任务开干。 Claude Code 自带的任务系统（创建 / 更新 / 列出任务）可以把每个阶段建成一个节点，用「阻塞 / 被阻塞」关系显式建边，状态走 pending → in_progress → completed；某个节点的依赖没完成前，它不会出现在「可执行」列表里，相当于用依赖门控替代了「下一步该做什么」的临时判断。 执行仍然发生在同一个会话、同一段上下文里：Agent 顺着依赖关系挑下一个已解锁的节点，直接实现，完成后回写状态，再挑下一个。没有节点隔离，也没有单独的图执行器在跑——图的推进是模型手动读状态、手动调用更新接口完成的，不是由代码在每一步自动求值条件边。跨节点的「状态」也不是一个结构化的 state 对象，只是任务列表里的标题 / 描述 / 状态字段，加上还留在同一段对话历史里的实现细节。 适合依赖关系不复杂、能在一次会话内跑完、不需要严格隔离上下文的多阶段任务——比如按一份规格文档的实现顺序逐节点推进。 示意如下： Claude Code 单会话 +------------------------------------------+ | Task list (DAG) | | A ──► B ──► C | | pending / in_progress / completed | +------------------------------------------+ | | 同一对话上下文里依次执行 v 实现 → 回写任务状态 → 挑下一个已解锁节点 重量方案：子代理 + 独立工作树 + 显式状态文件 如果需要的是真正的节点隔离，通常要在 Claude Code 里手工搭三件东西： ...

最近在给一个需求做报价——一个多语言文档批量 QA 校验工具，需求分析花了好几轮问答才敲定范围，接下来要报价的时候，我在想一个问题：这活基本是 AI 辅助写完的，按传统的人天/人月去算，好像已经不太对了。 问题：人天为什么在 AI 辅助场景下失灵 人天报价能成立，前提是"1 人天 ≈ 一定量的产出"这个换算关系大致稳定。AI 辅助开发把这个关系打破了： 产出和投入的人天数脱钩。同样的功能，AI 辅助下可能几小时就写完测试都带上了，人天数骤降，但功能本身的价值（能不能用、值多少钱）并没有跟着降。继续按人天报价，要么报太低把自己的溢价空间搭进去，要么硬凑人天数撑报价，两边都别扭。 计时计费本身有激励错位。如果按小时/人天计费，乙方反而有动机把项目拖久一点——多算的工时里，有多少是"AI 生成代码但按人类费率计费"，这跟"用 AI 提效"的初衷是反的。这个问题不是我一个人瞎想的，查了一圈资料，行业里已经在明确讨论这一点（见文末参考链接）。 顺带想到的：按 token 成本定价，行不行 报价的时候，我最初想的是一个"看起来很公平"的方案：按这次任务实际花的 token 成本 × 一个系数，再加上需求分析、架构、管理费这些固定项。想清楚之后放弃了，原因： token 成本和交付价值脱节。这次需求如果全靠 AI 辅助实现，token 花费可能就几十到一百多美元，但业务价值（省下的人工审校时间、给客户的报价空间）可能是这个数字的几十倍。按 token 成本定价会严重低估真正值钱的部分——需求澄清、边界判断、架构决策、验收测试，这些环节 token 消耗很少，但最耗专业判断。 和计时计费一样的激励错位。按 token 成本加成收费，等于鼓励自己多跑几轮、多重试、多探索——消耗越多赚得越多，这跟"用 AI 提高效率、把省下来的时间还给客户"的初衷正好相反。 不可审计、不稳定。token 单价随模型和厂商定价经常变，客户也很难验证实际花了多少 token，容易从"怎么定价"变成"信任问题"。 token 成本定价比较适用的场景，是那种极度机械、高重复量、判断空间很小的活（批量格式转换），成本约等于工作量。判断空间大的定制开发不属于这一类。 常见的软件项目报价模式 整理下来，常见的几种模式： | 模式 | 说明 | 适合场景 | |—————————–|————————————– –|————————–| | 固定价（Fixed price） | 范围定死后报一口价，风险在乙方 | 需求已经问清楚、边界明确的项目 | | 人天/人月（Time & Materials） | 按实际投入时间 × 日费率结算，风险在甲方 | 需求会持续演进、探索性强的项目 | | 里程碑付款 | 固定价拆成几个阶段验收付款 | 周期较长、双方都想控风险的项目 | | 价值定价（Value-based） | 按项目给客户带来的业务价值定价，不看成本 | 能算清 ROI 的项目 | | 结果导向（Outcome-based） | 只在结果达成时收费（比如按处理成功的记录数） | 高度可量化、重复度高的流程 | | 订阅/维护费 | 功能上线后按月收运维/迭代费 | 长期合作、持续迭代的项目 | ...

上一份工作在一家外企。公司近期裁员，我的 last day 是 2026 年 4 月 24 日。公司给了数月赔偿，算是接下来一段时间的生活缓冲。 公司曾宣布全球裁员约 4000 人；大连这一轮是老板加员工、整个项目分批裁，我认识的就有 20 多人；其它组、其它部门也有裁员，具体人数不详。 裁员之后，我计划着继续或者回归远程工作这条路线。四年前就想找一个远程职位，但当时有朋友推荐，进了本地的这家外企；公司推行混合办公，每周有 N 天可以在家远程，也算一定程度体验过远程工作。 最近偶尔有朋友推荐大连本地职位，我也投了几家——理想的 offer 还没落定。 一个问题 早上跑完步，在回家的路上，想到一个问题： 裁员之后，下一个理想的 offer 还没落定——我是不是应该趁这段缓冲期，测试一下：我自己加上 AI，能不能创造出一些价值（赚到钱）？ 不一定默认回到「找工作 / 打工」这种状态。 为什么叫 Exploration 回到家，我打开 TickTick（一个待办应用），新建了一个"倒数日"——从 last day 起，记录这段日子过去了多少天。 给这个"倒数日"取名时，直觉想填「失业」——字面上没错，指的就是「裁员到下一个 offer 之间」这段日子；但是看起来有点奇怪：它只描述 失去什么，不描述 要做什么。 后来选了 Exploration。每天打开 TickTick，能看到日期的累加；这个词中性一些，也更贴近我接下来想做的事——不是停在「没了什么」，而是试着看看「我 + AI」能做出什么。 实验要回答什么问题 我能不能在真实场景里创造价值？（不只是写 demo，而是有人愿意用、能省时间、能复用。） 这种价值能不能部分转化成收入？（工具、咨询、小产品、开源项目的可持续性等。） 若答案偏 yes，是否足够支撑日常开销？ 如果几个月后数据不好看，再去找工作也不迟。 已有的小实践 帮一位朋友开发了一个文档格式和内容的批量校验工具——过去同类文档的人工核对要花几小时，现在批量跑一遍只要几秒，后续项目也可以复用。 这事说明： 几小时级别的投入，可以节省别人未来 N 个小时的时间； 场景是真实的、可交付的，不是玩具； AI 在这里是搭档，负责生成和迭代，我负责需求、验收和边界。 这是这段探索里第一个可以写进笔记的点。 接下来的方向 缓冲期有限，我会按「可演示、可复用、能记账」来排优先级，而不是散点学技术。 贴近真实需求、容易形成复用 继续找真实需求里规则清晰、重复劳动多的环节（校验、一致性检查、格式处理等），做类似「几小时 → 几秒」、可复用的小工具。 自己的长期项目 开源项目：ENX 等 —— 在 runway 内推进到能讲清「对谁有什么用」。 若干私有仓库里的想法 —— 验证能否形成稳定用法，或小规模地「创造价值」。 每周复盘 这周创造了什么？（钱、省下的时间、可演示的功能、开源进展都算，但要写实。） 哪件事离「可重复」最近？ 下周只押注一件事是什么？ 和「找工作」之间的关系 若这几个月能证明「自己 + AI」可以持续交付价值，甚至覆盖一部分生活成本，就多一条值得走的路线；若证明不了，履历和作品集也会更清晰，回去职场同样是加分项。 ...

背景 给 AI 编程助手写「项目级说明」，目前尚无统一行业标准——没有 RFC，也没有各家都认的固定文件名。2024 到 2026 年间的常见做法是：在仓库里放 markdown，让 agent 改代码前先读约束。 真正稳定的实践，往往不在某个目录名上，而在三件事： 入口清晰 — agent 知道先读哪个文件 约束可执行 — 语言、目录、测试命令等，少写空泛原则 规模匹配 — 小 demo 不必拆十几份 doc 常见组织方式 方式 典型路径 优点 缺点 根目录入口 AGENTS.md、CLAUDE.md 易发现，多工具能扫到 规则一多文件会很长 .ai/ 目录 .ai/instructions.md 可拆分，根目录干净 部分工具不会自动索引子目录 Cursor 专用 .cursor/rules/*.mdc 与 Cursor IDE 深度集成 绑定 Cursor，换工具需迁移 Copilot 专用 .github/copilot-instructions.md VS Code / Copilot 原生支持 绑定 GitHub Copilot 生态 与人类文档合并 CONTRIBUTING.md 内 AI 段 贡献指南一处维护 AI 规则与人工流程易混杂 没有「唯一正确」的目录名。.ai/ 是合理选项之一，不是法定标准。 ...

什么是 Spec-Driven Development Spec-Driven Development（SDD，规格驱动开发） 是一种 AI 辅助开发方法论：开发者在让 AI 写代码之前，先把需求、边界和验收标准写成结构化的规格说明（Spec），AI 再依据 Spec 生成、修改或引导实现。 Spec 可以是自然语言文档，也可以带接口签名、数据模型、约束条件等结构化片段。核心不是格式，而是 先定义「完成」长什么样，再让 AI 动手。 典型 Spec 会回答： 要做什么、不做什么 输入输出与接口契约 边界条件与错误处理 验收标准（怎样算通过） SDD 与 Vibe Coding 的关系 SDD 和 Vibe Coding 关联很强，但方向相反——它们描述的是同一条 AI 协作光谱的两端。 维度 Vibe Coding SDD 输入方式 口语化、即兴描述 结构化 Spec 意图传递 让 AI 猜 显式定义边界 可追溯性 低，依赖对话历史 高，Spec 可版本管理 适合场景 原型、探索、一次性脚本 功能迭代、协作、长期维护 出错模式 方向对但细节偏、隐性假设 前期写 Spec 有成本 Vibe Coding 指用自然、随意的语言驱动 AI 写代码，强调「跟着感觉走」——描述大概想要什么，让模型自行补全细节。Andrej Karpathy 在 2025 年推广了这个说法。它上手快，适合快速验证想法。 ...

MCP 是什么 MCP（Model Context Protocol，模型上下文协议）是一个开源标准协议，用于将 AI 应用与外部系统连接起来。 可以把 MCP 理解为 AI 应用的 USB-C 接口。就像 USB-C 为电子设备提供了标准化的连接方式，MCP 为 AI 应用与外部系统的连接提供了统一标准。 有了 MCP，Claude、ChatGPT 等 AI 应用可以连接到： 数据源：本地文件、数据库 工具：搜索引擎、计算器、代码执行环境 工作流：自定义 prompt 模板、业务系统 MCP 解决了什么问题 问题背景 在 MCP 出现之前，每个 AI 应用如果想连接外部工具或数据源，都需要为每种组合单独开发集成代码。这导致： 重复开发：A 工具想接 GitHub，B 工具也想接 GitHub，各自写一套 维护成本高：N 个 AI 应用 × M 个外部工具 = N×M 个集成要维护 互不兼容：为 Claude 写的插件不能直接用在 ChatGPT 上 MCP 的解决方案 MCP 引入了统一的 Client-Server 架构： MCP Server：外部工具/数据源的提供方，按照 MCP 协议暴露能力 MCP Client：AI 应用（如 Claude、VS Code Copilot），按照协议调用 Server 这样只需要： ...

Ollama 简介 Ollama 是一个开源的本地大语言模型运行工具，可以让你在本地轻松运行 Llama 2、Mistral、Qwen 等多种开源大语言模型。 安装 Ollama Linux 安装 # 使用官方安装脚本 curl -fsSL https://ollama.com/install.sh | sh 安装记录 (2025-11-14)： 安装版本：v0.12.11 安装位置：/usr/local/bin/ollama 服务配置：已创建 systemd 服务 ollama.service 默认监听：127.0.0.1:11434 GPU 支持：检测到 AMD GPU，安装了 ROCm 支持 用户组：创建了 ollama 用户，并加入 render 和 video 组 自动启动：服务已启用并自动运行 手动安装 # 下载二进制文件 curl -L https://ollama.com/download/ollama-linux-amd64 -o ollama chmod +x ollama sudo mv ollama /usr/local/bin/ 验证安装 # 检查版本 ollama --version # 输出: ollama version is 0.12.11 # 检查服务状态 systemctl status ollama # 测试 API 是否可用 curl http://127.0.0.1:11434/api/version # 输出: {"version":"0.12.11"} 基本使用 启动 Ollama 服务 # 启动服务 ollama serve 拉取模型 # 拉取 Llama 2 模型（7B 参数版本） ollama pull llama2 # 拉取 Mistral 模型 ollama pull mistral # 拉取 Qwen 模型 ollama pull qwen # 拉取 Phi 模型（推荐入门） ollama pull phi 本地已安装模型 (2025-11-14)： ...