# Alejandro Rioja — ZH > Alejandro Rioja — AI agent systems for founders. Plus posts on growth, marketing, sales, ops, and business from inside live P&Ls. Site: https://alejandrorioja.com/zh/ Author: Alejandro Rioja Language: zh --- ## 有人工监督的AI智能体：何时构建审批门控（何时不该构建） Source: https://alejandrorioja.com/zh/human-in-the-loop-ai-agents-when-to-build-an-approval-gate/ Published: 2026-07-23 Tags: AI Agents, Operations TL;DR: 当错误代价高昂、不可逆或面向客户时，审批门控才有意义——并且人工必须能够及时发现问题。当量太大无法审查、错误修复成本低，或者人们不读就批准时，门控毫无意义。我用四个问题来决策，我的30多个生产智能体大多没有任何审批门控。 ## 目录 _发布于2026年7月。_ **摘要：** 当错误代价高昂、不可逆或面向客户，且人工能够及时发现时，审批门控才有意义。当量太大无法审查、错误修复成本低，或人们不读就批准时，门控毫无意义。我用四个问题来决策，我的30多个生产智能体大多完全自动化运行。 **运营者笔记：** 我在两家企业运营智能体——一家咨询品牌和位于得克萨斯州普夫拉格维尔的匹克球馆Pickleland。最初我到处设置审批门控，因为感觉"安全"。几周内，我的Slack频道里塞满了没人读的通知，智能体在技术上受到监督但实际上无人看管。这比没有门控更糟：监督的幻觉而无监督的实质。本文解释我现在如何思考这个决策。 ## 人工监督门控到底是什么 最简单来说，审批门控是智能体工作流中的一个暂停点，人工必须在智能体继续之前进行确认。智能体起草一封邮件——人工在发送前审批。智能体标记一笔交易——人工在处理退款前审核。 门控可以是同步的（智能体阻塞直到有人批准）或异步的（智能体将操作加入队列，发送通知，人工按自己的节奏从仪表板或Slack消息中批准）。对于非时间敏感的事项，异步几乎总是更好的选择，因为同步门控会在队列中产生背压并破坏智能体的可靠性保证。 门控不是什么：重试循环、置信度阈值或回退到更简单的模型。这些是智能体内部的错误处理机制。审批门控是关于人类判断进入循环——有意为之，在特定点，有其原因。 ## 我提问的四个问题 在添加门控之前，我会过一遍四个问题。其中任何一个"是"都是考虑添加门控的信号。全部四个"是"意味着门控在结构上是必要的。 **1. 操作是否不可逆（或撤销成本高昂）？** 向10,000人发送邮件无法撤回。提交付款无法轻易召回。没有备份地删除数据库记录是永久的。不可逆性是支持门控的最强论据，因为智能体无法撤销其所做的事。 将其与以下情况对比：用一个类别标记一个入站查询。如果标签错了，你两次点击就能纠正。无需门控。 **2. 如果智能体出错，谁来买单？** 一个内部标签错误——我花几秒钟纠正。一封面向客户的邮件错误——客户为糟糕的体验付代价，我为信任损失付代价。一笔财务交易错误——我用真实的钱和可能的合规风险付代价。 只影响内部系统的智能体可以在没有门控的情况下容忍更多错误。接触客户或金钱的智能体需要赢得无人看管运行的权利。 **3. 人工真的能在问题变得重要之前发现错误吗？** 这是大多数人跳过的问题，也是消灭门控最多的问题。如果一个智能体每小时处理500个项目，你每个项目收到一条Slack通知，没有人会读完所有500条。你在制造警报疲劳，而非监督。 计算很简单：只有当人工能在可用时间窗口内切实审查被标记的项目时，门控才有价值。如果智能体量大且速度快，门控要么需要高度选择性（只标记边缘案例），要么应该被移除。 **4. 人工是否可靠地阅读智能体呈现的内容？** 如果你的审批队列满了而人们不读就批准，门控比没有门控更糟——它制造了有人工检查过工作的虚假信任。 ## 门控明显有意义的时候 以下是我总是添加门控的模式，无一例外： - **不可逆的外部通信** — 发给真实人的邮件、短信、社交媒体帖子。智能体起草；人工发送。根据量而定。 - **超过阈值的财务操作** — 任何移动资金的事情，如果超过我按上下文设置的最低金额，就设置门控。 - **智能体未曾见过的新模式** — 如果智能体的分类器将某事标记为"未知"或超出其训练分布，那就是强制升级。 - **合规敏感输出** — 任何涉及HIPAA、PCI、法律通知或受监管金融内容的事项都由人工审查。 ## 门控悄然扼杀产品的时候 以下是门控看似安全但悄然破坏采用的模式： - **大量且可逆的操作** — 如果能两次点击撤销，且每天发生200次，审查疲劳会占上风。 - **时间敏感的工作流** — 在30秒内响应客户询问的智能体不应有同步门控。 - **人工拥有的上下文少于智能体的任务** — 如果智能体读了50页上下文来做分类，而审阅者只得到一行摘要，审查就是走过场。 - **内部丰富化和标记** — 标记CRM记录、对费用分类、总结会议记录。风险不值得中断。 ## 我实际部署的三种门控模式 当门控有必要时，我从三种实现中选择： **1. 通过Slack/邮件的异步审批** 智能体完成草稿，在指定Slack频道发布带有提议操作和批准/拒绝按钮的消息，然后暂停。我使用Cloudflare Queues保存待处理的操作，以及一个单独的Worker在恢复前监听审批webhook。 适用于：邮件草稿、社交内容、重要CRM更新。 **2. 基于置信度的升级** 智能体对高置信度输出（比如，在结构化模式上≥0.85置信度）完全自动化运行，并将低置信度项目路由到人工队列。人工只看到模糊的边缘案例。 适用于：分类、路由、分类处理。 **3. 仪表板审查与批量批准** 智能体的所有输出都进入审查仪表板，而非每个项目设门控。人工批量审查——比如每天早上——并集体批准或纠正。 适用于：内容生成、报告起草、计划摘要。 ## 警报疲劳陷阱 你添加的每个门控都是对某人注意力的永久税收。风险不仅仅是一个门控被忽视——而是三个门控创造了一个嘈杂的Slack频道，让人们习惯性地忽略所有通知。 我建立的纪律：每个门控都有明确的负责人和明确的SLA。如果没有人在SLA内持续审查，门控就被移除并替换为审计追踪。我每月审计所有审批队列。 ## 与智能体可靠性的连接 门控是可靠性堆栈中的一层，而非整个堆栈。我的生产智能体完整可靠性堆栈： 1. **评估框架** — 在部署前确认正确输出。 2. **带模式验证的结构化输出** — 智能体输出被限制在类型化模式中。 3. **置信度阈值** — 低置信度输出进入人工审查。 4. **审计日志** — 智能体的每个操作都记录了输入、输出和模型调用元数据。 5. **人工审批门控** — 仅用于上述不够的操作。 门控是最后防线，而非第一道。如果你的智能体不可靠到需要在每个操作上设门控，根本问题是评估覆盖和提示设计，而非监督流程。 ## 我的经验法则 如果我不希望初级员工在没有先征询我意见的情况下这样做，智能体就需要一个门控。如果我会让初级员工毫不犹豫地去做，智能体应该无人看管地运行。 ## 常见问题 ### 如何处理需要审批但运行量大的智能体？ 改变架构：不要求每个项目批准——要求每个模式批准。让智能体运行，但让它呈现统计异常供人工审查。 ### 如果错误可能造成严重损害，但我无法承担完整的人工审查怎么办？ 这通常是还不该为那个操作部署智能体的信号。或者，使用置信度阈值让智能体只在高度确信时才行动，其他所有情况升级。如果你使用[Claude](/recommends/claude)作为模型层，Anthropic SDK的工具使用模式使得定义一个智能体在缺乏置信度时可以调用的"升级"工具变得简单。 --- ## Claude工具调用：我如何赋予AI智能体真实能力 Source: https://alejandrorioja.com/zh/claude-tool-use-production-agents/ Published: 2026-07-21 Tags: AI Agents, Claude TL;DR: Claude工具调用让您的智能体能够执行操作——而不仅仅是生成文本。您将工具定义为JSON模式，Claude决定何时调用它们，您的代码执行真实世界的操作。循环分三步：发送消息→接收tool_use块→执行并返回结果。我在Cloudflare Workers上超过15个生产智能体中部署了这一模式。故障点几乎从不在AI——而在于工具返回的模糊结果。 ## 目录 _2026年7月更新。_ **TL;DR：** Claude工具调用让您的智能体能够执行操作——而不仅仅是生成文本。您将工具定义为JSON模式，Claude决定何时调用它们，您的代码执行真实世界的操作。循环分三步：发送消息→接收tool_use块→执行并返回结果。我在Cloudflare Workers上超过15个生产智能体中部署了这一模式。故障点几乎从不在AI——而在于工具返回的模糊结果。 **[运营者视角]** 我在一个咨询品牌和Pickleland（得克萨斯州普拉格维尔的匹克球中心）之间运营着30多个生产AI智能体。其中大约一半使用工具调用——这是Claude API的功能，让模型能够调用您代码中定义的函数。以下是我在生产部署和迭代后总结的模式。 ## 为什么工具调用改变了智能体的能力 没有工具，智能体只能生成文本。这对摘要、起草和分类很有用——但这不是大多数业务自动化真正需要的。业务自动化需要查找信息、写入数据库、调用API、发送消息。 工具调用就是您给Claude这种访问权限的方式。您将一组工具定义为JSON模式。Claude读取模式，决定调用哪个工具以及使用什么参数，并返回一个结构化的`tool_use`内容块。您的代码执行实际函数。Claude获得结果并决定下一步做什么——包括调用另一个工具或生成最终文本响应。 关键点：**Claude决定何时以及是否调用工具。** 您定义能力。模型推理何时使用它们。 ## API流程如何工作 工具调用循环有三个步骤。根据模型发出的工具调用次数，您将经历这个循环一次或多次。 **第一步：发送带有已定义工具的消息** ```typescript const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 1024, tools: [ { name: "check_court_availability", description: "Check if a court is available at a given date, time, and duration", input_schema: { type: "object", properties: { date: { type: "string", description: "Date in YYYY-MM-DD format", }, time: { type: "string", description: "Start time in HH:MM format (24h)", }, duration_minutes: { type: "number", description: "Duration of the booking in minutes", }, }, required: ["date", "time", "duration_minutes"], }, }, ], messages: [ { role: "user", content: "Is a court available tomorrow at 2pm for 90 minutes?", }, ], }); ``` **第二步：检查Claude是否想调用工具** ```typescript if (response.stop_reason === "tool_use") { const toolUseBlock = response.content.find( (block): block is Anthropic.ToolUseBlock => block.type === "tool_use" ); if (!toolUseBlock) throw new Error("Expected tool_use block"); // Run your actual function const toolResult = await checkCourtAvailability( toolUseBlock.input as CourtAvailabilityInput ); // Step 3: Return the result to Claude const finalResponse = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 1024, tools: [ /* same tools as before */ ], messages: [ { role: "user", content: "Is a court available tomorrow at 2pm for 90 minutes?", }, { role: "assistant", content: response.content }, { role: "user", content: [ { type: "tool_result", tool_use_id: toolUseBlock.id, content: JSON.stringify(toolResult), }, ], }, ], }); // finalResponse.content now has the text answer } ``` 这就是完整的模式。每次工具调用三次API交互：定义工具→接收`tool_use`块→返回结果。 ## 真实示例：Pickleland可用性检查器 Pickleland是一个匹克球中心。我们在Facebook Messenger、评论区和聊天机器人上收到预订查询。问题几乎总是某种变体："周六下午3点你们开门吗？"或"我能为8人小组预订场地吗？" 可用性检查智能体使用工具调用实时查询真实的预订系统，而不是给出罐头式回答。 以下是完整的智能体——简化但忠实于生产环境： ```typescript // workers/availability-checker.ts import Anthropic from "@anthropic-ai/sdk"; const anthropic = new Anthropic(); const AVAILABILITY_TOOLS: Anthropic.Tool[] = [ { name: "check_availability", description: "Check court availability for a date, time, and group size. Returns available courts and their prices.", input_schema: { type: "object", properties: { date: { type: "string", description: "YYYY-MM-DD" }, start_time: { type: "string", description: "HH:MM (24h)" }, duration_minutes: { type: "number" }, players: { type: "number", description: "Number of players" }, }, required: ["date", "start_time", "duration_minutes"], }, }, { name: "get_pricing", description: "Get current pricing for court rentals and open play sessions", input_schema: { type: "object", properties: { session_type: { type: "string", enum: ["court_rental", "open_play", "clinics"], }, }, required: ["session_type"], }, }, ]; export async function handleInquiry( userMessage: string, env: Env ): Promise { const messages: Anthropic.MessageParam[] = [ { role: "user", content: userMessage }, ]; // Agentic loop — keep going until stop_reason is "end_turn" while (true) { const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 512, system: "You are the booking assistant for Pickleland, a pickleball facility in Pflugerville, TX. " + "Use the tools to look up real availability and pricing. Never make up availability or prices. " + "If the customer wants to book, direct them to pickleland.com/book.", tools: AVAILABILITY_TOOLS, messages, }); // Push the assistant's response into message history messages.push({ role: "assistant", content: response.content }); if (response.stop_reason === "end_turn") { const textBlock = response.content.find( (b): b is Anthropic.TextBlock => b.type === "text" ); return ( textBlock?.text ?? "I wasn't able to answer that — please call us directly." ); } if (response.stop_reason === "tool_use") { // Process ALL tool calls in this response (Claude can request multiple at once) const toolResults: Anthropic.ToolResultBlockParam[] = []; for (const block of response.content) { if (block.type !== "tool_use") continue; let result: unknown; switch (block.name) { case "check_availability": result = await checkAvailability( block.input as AvailabilityInput, env ); break; case "get_pricing": result = await getPricing(block.input as PricingInput, env); break; default: result = { error: `Unknown tool: ${block.name}` }; } toolResults.push({ type: "tool_result", tool_use_id: block.id, content: JSON.stringify(result), }); } // Return all tool results in a single user message messages.push({ role: "user", content: toolResults }); } } } ``` 这里有两点值得注意。 **智能体循环。** 我持续运行直到`stop_reason === "end_turn"`。Claude可能调用`check_availability`，决定还需要价格，调用`get_pricing`，然后产生最终答案——这是一条用户消息触发的三次API调用。循环无需任何特殊逻辑即可处理。 **每轮多次工具调用。** Claude可以在单个响应中返回多个`tool_use`块。我处理所有这些块，并在单个`user`消息中返回所有结果。如果逐一处理并单独返回，您会破坏对话流程并浪费令牌。 ## 真实示例：潜在客户研究智能体 我的咨询品牌使用研究智能体在与潜在客户交谈之前对其进行丰富分析。当有人填写联系表格时，智能体会研究其公司并提取我在通话前需要了解的信息。 该智能体的工具定义包括一个写入工具——这正是模式变得有趣的地方： ```typescript const RESEARCH_TOOLS: Anthropic.Tool[] = [ { name: "search_company", description: "Search for information about a company", input_schema: { type: "object", properties: { company_name: { type: "string" }, website: { type: "string", description: "Company website if known" }, }, required: ["company_name"], }, }, { name: "save_research", description: "Save the completed research summary to Airtable. Call this when all research is complete.", input_schema: { type: "object", properties: { company_summary: { type: "string" }, estimated_size: { type: "string", enum: ["1-10", "11-50", "51-200", "200+"], }, likely_use_case: { type: "string" }, priority: { type: "string", enum: ["high", "medium", "low"] }, notes: { type: "string" }, }, required: [ "company_summary", "estimated_size", "likely_use_case", "priority", ], }, }, ]; ``` `save_research`是我所说的**写入工具**——其目的不是获取信息，而是以结构化形式将Claude的输出提交到数据库。我使用这种模式，而不是尝试从文本响应中解析JSON。Claude知道研究何时完成，并使用正确类型的字段调用`save_research`。我从不编写解析器。 这是工具调用最简洁的应用：用您想要的确切模式定义一个"最终操作"工具，Claude将通过工具调用提供结构化输出。无需文本解析，无需正则表达式，无需对自由文本输出进行JSONSchema验证。 ## 一个工具还是多个 开始使用工具调用时，本能反应是构建一个做所有事情的巨型工具。请抵制这种冲动。小型、专注的工具更好，原因有三： 1. **Claude对小工具的推理更好。** 名为`get_court_status`的工具返回可用性，比名为`manage_facility`的工具（接受`mode`参数并在内部分支）更容易让模型处理。 2. **小工具更容易测试。** 每个工具都是TypeScript函数，您可以独立于LLM进行单元测试。您应该这样做——工具中的错误在实时对话中很难调试。 3. **Claude可以并行化小工具。** 如果两个工具不相互依赖，Claude可以在同一个响应中调用它们，您可以并行处理。这仅在工具真正独立时才有效。 例外情况：需要访问大量共享内部状态的工具。如果函数需要来自同一数据源的10个变量，一个具有更丰富模式的工具优于每个单独访问数据库的10个工具。 我的经验法则：每个不同的能力从一个工具开始。只有当您看到Claude在每个请求中都将它们一起调用时，才合并工具。 ## 成本影响 工具调用会增加令牌数量。每个工具定义都会进入系统提示上下文。每个`tool_use`和`tool_result`块都会在对话历史中消耗令牌。对于多轮智能体循环，这会迅速累积。 对于Pickleland可用性检查器，一次典型对话总共执行3-4次API调用（初始消息+1-2次工具调用+最终答案），每次处理600-900个令牌。按Haiku价格，每次查询费用不到$0.001。正如我在[AI智能体成本计算文章](/ai-agent-cost-math-when-haiku-beats-sonnet/)中解释的，Haiku可靠地处理定义明确的工具调用任务，对于相同的令牌量比Sonnet便宜10倍。 潜在客户研究智能体运行在Sonnet上，因为判断决策——优先处理潜在客户、评估契合度——需要比Haiku在开放性输入上可靠提供的更强推理能力。这个计算仍然有效，因为它运行不频繁（每周几次，而不是每天数千次）。模型选择遵循任务复杂性，而非个人偏好。 ## 没人谈论的故障点 我在生产工具调用中看到的最常见故障点不是Claude调用错误的工具。而是工具返回Claude无法清晰推理的内容。 如果您的工具返回包含40个字段的原始数据库对象，Claude会对哪些字段重要感到困惑。如果您的工具抛出异常（表现为Worker崩溃而不是工具结果），循环会静默中断。如果您的工具在表示"无结果"时返回`null`，Claude不知道是重试还是放弃。 工具结果的三条规则： **返回简洁、明确的结果。** `{ available: true, courts: ["Court 3", "Court 5"], price_per_hour: 20 }`——而不是完整的数据库行。 **在工具函数内捕获错误并将其作为结构化结果返回。** `{ error: "booking system timeout", retry: true }`——而不是导致Worker崩溃的抛出异常。 **明确表示"无结果"。** `{ available: false, next_available: "2026-07-23T14:00:00Z" }`——而不是没有上下文的`null`或空数组。 Claude对清晰信号的推理远好于对模糊返回值的推理。我在生产中调试工具调用所花的每一小时都是关于不清晰的结果，而不是模型的推理。 ## 运营者结语 工具调用是将Claude从文本生成器转变为运营者的功能。定义具有清晰输入模式的专注工具。在单个响应中处理所有`tool_use`块。运行智能体循环直到`stop_reason === "end_turn"`。从工具函数返回干净、简洁的结果——不要返回原始数据对象、抛出的异常或模糊的null。 模型处理推理。您的代码处理真实世界的操作。保持这两项工作明确分离，即使您添加工具，架构也保持可维护性。 如果您正在构建第一个工具调用智能体，请从上面的可用性检查器模式开始——一个工具，一个目的，一个智能体循环。先部署那个。然后添加第二个工具。 --- **相关文章：** [我用来运行30个以上生产智能体的技术栈](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) · [Haiku与Sonnet：智能体任务的成本计算](/ai-agent-cost-math-when-haiku-beats-sonnet/) · [事件触发与定时智能体：哪种模式适合哪种工作](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) **正在构建工具调用智能体并遇到困难？** [联系我](/contact/)——我为运营团队设计和构建生产智能体架构。 ## 常见问题 ### Claude工具调用适用于所有模型吗？ 是的——工具调用支持所有当前的Claude模型。[Claude](/recommends/claude) Haiku可靠地处理具有清晰模式的定义明确的工具，是高容量任务类型的最便宜选项。Sonnet更好地处理更模糊或开放式的工具调用决策。从Haiku开始；如果输出质量不足，则升级。 ### Claude工具调用与OpenAI函数调用有何区别？ 机制上完全相同。OpenAI创造了"function calling"；Anthropic称之为"tool use"。两者都是：您定义JSON模式，模型返回结构化调用，您的代码执行函数。API形式不同，但概念相同。 ### Claude能在单个响应中调用多个工具吗？ 可以。Claude可以在单个`assistant`响应中返回多个`tool_use`块。处理所有这些块，并在单个`user`消息中返回所有结果。请参阅上面Pickleland示例中的智能体循环模式——`response.content`上的`for`循环可以正确处理这个问题。 ### 每个智能体应该定义多少个工具？ 我每个智能体保持在8-10个工具以下。超过这个数量，我看到Claude偶尔在第一次尝试时选择错误的工具，这会在纠正循环中浪费令牌。如果您需要超过10个能力，请将智能体拆分为具有专业工具集的多个智能体，而不是构建一个知道一切的智能体。 ### 我应该使用工具调用获取结构化输出吗？ 是的——`save_research`写入工具模式比要求Claude在文本块中返回JSON然后解析它更简洁。定义一个具有您想要的确切模式的"最终操作"工具。Claude完成后将使用正确类型的字段调用它。无需解析器。 --- ## 2026 年，搜索引擎究竟如何评估内容质量 Source: https://alejandrorioja.com/zh/how-search-engines-evaluate-content-quality/ Published: 2026-07-20 Tags: SEO, GEO ## 目录 _2026 年 7 月发布。_ **TL;DR：** 搜索引擎和 AI 引擎都已经不再孤立地给单个页面打分。它们评估的是整个网站——对一个主题的覆盖深度、经得起审视的信任信号，以及数月累积而非一篇爆款文章带来的一致性。我运营着 384 篇英文文章，覆盖 13 种语言，每周跟踪自己是否在 ChatGPT、Perplexity 和 Google AI Overviews 中被引用。规律很一致：孤立的文章会停滞不前，成簇的文章会产生复利效应，而真正撬动引用率的信任信号，往往枯燥、结构化，且成本低廉。 **运营者视角：** 我不是在空谈内容质量的理论——我运营着这个网站的内容引擎，亲眼看着改动某个变量后引用率发生的变化。这篇文章完全建立在我在 alejandrorioja.com 上实际测量到的东西之上：真实的内容簇规模、一次真实的六周引用实验、真实的 schema 标记测试。这里没有任何关于算法"大概"如何运作的猜测。 ## "质量"早就不再是逐页的问题了 大多数人心里的默认模型仍然是：写一篇好文章，它就会排名靠前。这从来就不完全成立，而对于除了极窄的长尾词之外的任何东西，这种想法现在正在积极地误导人。 我在自己的网站上有一个直接的观察方式。我在少数几个真正的内容簇里持续发文——一个 29 篇文章的 AI 智能体与 Claude 内容簇，一个"X 是如何赚钱的"商业模式解析内容簇（已经有 20 篇，涵盖 Google、OpenAI、Anthropic、Uber、Salesforce 等），还有一个按标签数量计算是全站最大主题的大型 SEO/GEO 内容簇。一篇只在某个主题上写过一次的独立文章，其表现和一篇处在这些内容簇内的文章完全不同——即便那篇独立文章客观上写得更好。 处在内容簇里的文章获得更多引用、排名更稳定、在算法更新后恢复得更快。孤立的文章要么会有一次爆发，要么根本没有；而当它们没有爆发时，也没有周边的权威可以依靠。这正是常被包装成 [AI 主题权威策略](https://www.linkbuildinghq.com/blog/how-to-build-topical-authority-for-ai/) 的东西背后真正的机制——不是什么神秘的信任分数，而是一个朴素的事实：一个页面身处 28 个同主题页面之中，会给 Google 的爬虫和大语言模型的检索环节都提供更多可以相互印证的上下文。我特意写过 [这种结构的完整运作机制](/pillar-content/)——简单说，一个内容簇要生效，必须做到簇里的每篇文章都链接回支柱页，支柱页也链接回每一篇簇内文章，这样主题地图才是显式呈现的，而不是要靠爬虫自己去拼凑。 我在发布任何新文章之前会用的实用测试是：这篇文章是在扩展我已经拥有的一个内容簇，还是在另起一个孤立的话题？孤立文章并非不可以写——有些查询确实只需要一个页面就够了——但我心里清楚，一篇孤立文章只能单靠页面级别的信号去竞争，得不到内容簇天生自带的复利效应。 ## "有真实价值，而非填充内容"是一个可检验的说法，不是一种感觉 这条建议的通用版本是"增加深度和背景，不要重复到处都能找到的信息"。这话没错，但如果没有检验方法就毫无用处。 这是我在真实规模下使用的实际测试：我有 384 篇英文文章。每一篇都会被 [我专门为此搭建的一个代理](/how-to-translate-one-blog-post-into-13-languages-with-one-agent/) 翻译成另外 12 种语言。翻译很便宜——整整 341 篇文章的积压量，用 Haiku 调 API 也才花了大约 1.70 美元。写作则不然。如果我可以靠把同一个想法稍微改写十种不同的说法来充量，那个代理会让我像扩展翻译一样轻松地扩展这种重复。我没有这么做，因为重复的表述过不了那个真正的测试：这个页面回答的问题，是否是我网站上没有其他页面已经同样好或更好地回答过的？ 这才是比任何风格指南都更重要的过滤器。"填充内容"不是一个语气问题，而是一个冗余问题——一篇文章重复了邻近文章的内容，却没有增加新的角度、新的数字或新的例子。我在发布前的检查方式是问自己：这篇新文章会不会蚕食一篇已有文章的引用份额,而不是增加新的可被引用的内容面。如果我网站上的两篇文章能同样好地满足同一个查询，那么无论写得多好,其中一篇就是填充内容。 ## 我真正建立并测量过的信任信号 "可信度"是每一篇通用 SEO 文章里最含糊的词，通常后面跟着一份诸如"引用来源、展示专业性、保持准确"的清单，却没有任何办法验证这些是否真的推动了什么。 我实际执行的具体版本是：schema 标记，因为这是唯一一个 AI 引擎会机械地解析、而不是靠推断的信任信号。我在别处详细写过 [完整的实现方式](/schema-markup-for-geo/)，也深入讨论过 [哪些类型的 schema 真正物有所值](/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/)。简单说：带有真实署名作者和诚实的 `dateModified` 的 `Article`/`BlogPosting` 是作者身份的锚点；`FAQPage` 和 `HowTo` 是收益最高的类型，因为它们直接把一个已回答的问题或一个已结构化的流程交给模型，而不是让模型从散文中自己推断；`Person` 和 `Organization` schema 的存在,则是为了不让模型把我和另一个同名的人搞混。 这些对我来说都不是空泛的理论——它们是一个真实结果背后的具体干预措施。我把一套四部分的结构化叠加方案（TL;DR 板块、编号步骤、FAQ 板块、一手资料引用）应用到 41 篇已经在触发 Google AI Overviews 的支柱文章上，六周内把引用频率从 41 篇中的 4 篇提升到了 19 篇——[完整的六周测试记录在这里](/google-ai-overview-citation-case-study/)。这不是"加点信任信号然后祈祷"。这是我自己页面上一次经过测量的前后对比,而且文章本身也清楚地写明了限制条件：它只对那些已经拥有有机排名前 5 位这一权威基础的页面奏效。结构放大的是已经存在的信号,而不是凭空制造一个信号。 ## 一致性会产生复利,但"一致性"不等于持续更新 这里的通用说法通常是"新鲜度很重要,但不是每篇文章都需要更新",却没有附上任何实际的更新节奏。这是我的节奏。 大多数文章发布之后我不会再碰。我确实维护着一组滚动更新的支柱文章，在底层事实发生变化时——出了新模型、某个工具改了定价、某个数据过时了——每 6 到 12 个月更新一次。`dateModified` 只有在内容真的发生变化时才会改动；我测试过伪造这个字段,结果不奏效——引擎能识破一个没有实质性修改却被推后的日期，这也正是那次 AI Overview 案例研究得出的结论。 我真正每周关注的一致性信号,不是发布节奏，而是引用覆盖率：我每周都会把一份对业务至关重要的追踪查询清单跑一遍 ChatGPT、Perplexity 和 Google，并记录自己是否被引用——[方法论在这里](/how-to-measure-ai-search-traffic/)。引用覆盖率是一个领先指标——它先于推荐流量或品牌搜索的提升发生变化,所以这是能告诉我一个内容簇是否真的在随时间积累权威、还是原地不动的数字。一个发一次就沉寂下去的网站,不会在那次每周检查中获得第二次关注；一个持续扩展内容簇的网站会。 ## "网站级别"的评估到底一层一层地奖励什么 我跟踪的三个引擎并不会以完全相同的权重看待这些信号。这是我在决定把精力投在哪里时,脑子里一直记着的实用表格： | 质量层级 | 在实践中实际的样子 | 我在哪里测量过它 | | --- | --- | --- | | 主题深度 | 同一主题下 20-30+ 篇互相链接的文章，支柱页链接到每一篇簇内文章,反之亦然 | AI 智能体内容簇（29 篇）,"X 是如何赚钱的"内容簇（20 篇） | | 结构化可提取性 | TL;DR 板块、编号步骤、FAQ,贴合真实用户的表达方式 | 6 周内 AI Overview 引用从 4/41 提升到 19/41 | | 作者身份/信任 | 具名作者 + 准确的 `dateModified` + Person/Organization schema | 面向 GEO 的 schema 标记,schema 类型拆解 | | 长期一致性 | 每周跨引擎的引用跟踪，而非不断改写 | AI 搜索测量方法论 | 我在通用建议里最常看到的失败模式,是把这些当成一个未加区分的"质量"总分。它们不是一回事。一个页面可能在结构化可提取性上做得很好,却仍然输给一个主题深度更强的竞争对手。一个页面可能身处一个很深的内容簇里,却仍然在某次具体的引用竞争中,输给一个更新鲜、schema 做得更好的竞争对手。搞清楚对某个具体页面而言,真正的瓶颈是哪一层,才是大部分的工作所在。 ## 这套逻辑在哪里会失效——诚实的说明 比起过度推销这个模式,我更愿意指出它的局限： - **域名权威仍然是一道门槛。** 那次 AI Overview 干预只对已经拥有有机排名前 5 位的页面奏效。结构放大了已经存在的信号，并没有从一个毫无基础的冷页面上创造出权威。 - **各引擎奖励的东西会分化。** 把相同的 50 个头部关键词分别跑一遍 ChatGPT 和 Google,我发现被引用的来源只有大约 40% 是重合的——[完整拆解在这里](/chatgpt-search-vs-google-50-term-test/)。把"搜索引擎"当成一个单一目标来优化,本身就是错误的框架；你要优化的是好几个引擎,它们在基础层面上意见一致，在其余部分则会分道扬镳。 - **有些类目真的不需要内容簇。** 我表现最好的一批页面里,有几个就是真正的孤立文章。深度是一个杠杆,不是一个普适的要求——在查询空间根本支撑不起内容簇的地方硬要凑一个簇,只会产生整套框架本该避免的那种单薄、注水的内容。 ## 常见问题 ### 一篇优秀的单篇文章能否胜过一个平庸的内容簇？ 可以,前提是查询足够窄、竞争足够低。但对于任何有真实竞争的头部关键词,能长期保持排名的页面几乎总是有内容簇支撑的。我见过孤立文章冲高然后回落,而簇内文章不会这样。 ### 一个主题需要多少篇文章,才能算是一个真正的内容簇？ 没有一个硬性数字,但在我自己的数据里,效果大约在同一主题下 8-10 篇真正有区别的子主题文章时开始变得明显可见——足够让支柱页有意义地链接出去,也足够让每篇簇内文章都有一个具体的地方,可以把想深入了解的读者送过去。 ### schema 标记真的有必要吗,还是写得好就够了？ 写得好是必要条件,但对 AI 引擎的引用而言并不充分。引擎从 `FAQPage` 和 `HowTo` schema 中提取结构化事实,比单纯从散文中提取更可靠,因为 schema 去掉了推断这一步。我测量到,在此前没有 schema 的文章上加上它之后,引用率提升幅度在个位数到十几个百分点之间。 ### 应该多久更新一次旧内容,而不是发布新文章？ 我每 6 到 12 个月在某个真实事实发生变化时更新一次支柱文章,而且从不在没有实质性修改的情况下改动 `dateModified`。我大部分的内容预算都花在扩展内容簇的新文章上,而不是改写旧文章——新鲜度确实重要,但相比主题深度和结构,它并不是主导性的杠杆。 ### 最优先该修的、杠杆最大的一件事是什么？ 如果一个页面在有机排名上已经表现不错,却没有被 AI 引擎引用,那就加一个干净的 TL;DR 板块,直接回答头部查询。在我自己的六周测试里,这是迄今为止最大的单一杠杆——比 FAQ schema 更大,比一手资料引用更大,比编号步骤更大。 ## 总结 内容质量的评估已经从页面层面转移到了网站层面,而真正能撬动结果的网站级别信号是可测量的,不是玄学：可以数出来的内容簇深度、可以做 A/B 测试的结构化叠加方案、可以验证的 schema、以及一个可以每周跟踪的引用覆盖率数字。这些都不需要去猜算法"想要"什么。它需要在一个真实的主题结构内发布内容,给引擎一个干净、可提取的答案,而不是让它们自己去推断,并且足够频繁地检查结果,才能知道它是否奏效。我每周都在这个网站上执行这四项纪律,上面这些数字就是它们真正产生的结果——而不是某份通用指南声称它们应该产生的结果。 --- ## 2026年商业用途Claude与ChatGPT对比：一位运营者的真诚评价 Source: https://alejandrorioja.com/zh/claude-vs-chatgpt-for-business-2026/ Published: 2026-07-18 Tags: AI Agents, Productivity TL;DR: Claude在构建代理、长上下文工作、编码以及在生产环境中大规模运行的一切方面胜出。如果您的工作流程存在于聊天界面中，ChatGPT在消费者集成、语音模式和更广泛的插件生态系统方面胜出。如果您正在构建自动化工作流程或AI代理，Claude是更好的基础。如果您想要拥有更多第三方连接的强大聊天助手，ChatGPT更有优势。对于大多数商业建设者来说，真正的问题是：您是在与AI对话还是在用AI构建？答案决定了工具。 ## 目录 _2026年7月发布。_ **TL;DR:** Claude在构建代理、长上下文工作、编码以及在生产环境中大规模运行的一切方面胜出。如果您的工作流程存在于聊天界面中，ChatGPT在消费者集成、语音模式和更广泛的插件生态系统方面胜出。如果您正在构建自动化工作流程或AI代理，Claude是更好的基础。如果您想要拥有更多第三方连接的强大聊天助手，ChatGPT更有优势。对于大多数商业建设者来说，真正的问题是：您是在与AI对话还是在用AI构建？答案决定了工具。 **[运营者视角]** 我经营两家企业——一个咨询品牌和Pickleland，位于德克萨斯州普普拉格维尔的匹克球设施——有30多个AI代理在生产环境中处理社交媒体回复、活动推广、预订跟进、新闻通讯草稿等工作。我的整个代理技术栈都建立在[Claude](/recommends/claude)上。我也充分使用了ChatGPT，足以了解各自的失败之处。这不是基准测试评测，而是一位实践者的观点。 ## 真正重要的问题 大多数比较都在问"哪个模型更聪明？"这对于商业用途来说是错误的问题。 正确的问题是：**您在构建什么，它需要在规模上可靠地做什么？** 希望AI帮助起草文案的营销经理与构建自动化潜在客户资格认定流程的创始人有不同的要求。使用AI为会议做准备的个体创业者与构建每周处理500个客户请求的代理的运营者有不同的需求。对一方有利的工具往往对另一方是错误的。 这个框架决定了以下所有内容。 ## Claude胜出的地方 ### 1. 长上下文工作 Claude的原生上下文窗口——20万个令牌——能处理其他模型会崩溃的事情。我定期将完整的客户对话历史、完整的合同草稿或多文档研究摘要传给Claude，让它综合或交叉引用。它保持住了主线。竞争模型现在技术上支持长上下文，但在复杂任务上的实际性能下降仍然比Claude更差。 对于涉及阅读长文档、分析密集数据导出或在长工作流程中保持连贯性的商业任务，Claude具有真正的优势。 ### 2. 生产环境中的代理行为 当您将Claude作为代理运行时——调用工具、在循环中做决策、写入数据库、处理错误——根据我的经验，它比ChatGPT更一致地运行。它更可靠地遵循系统提示指令，生成更容易解析的结构化输出，并且当上下文变长时偏离任务的可能性更小。 这对代理来说极其重要。一个95%的时间与99%的时间遵循您的系统提示的模型听起来相似。每天500次调用，那就是每天需要检测和清理的25个偏差案例。 我写的关于[如何编写不会在生产中失败的AI代理系统提示](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/)的文章详细介绍了这一点，但简短版本是：Claude在系统提示级别的指令遵循是我测试过的最好的。 ### 3. 编码和技术工作 我几乎所有东西都用TypeScript在Cloudflare Workers上构建。Claude Code是我的日常开发工具——它真正有用，而不仅仅是"足够好"。对于架构问题、调试、重构和从头编写代理逻辑，Claude持续超越我在ChatGPT同类产品上使用的东西。 这不仅仅是Claude Code与ChatGPT Chat的比较。即使是通过API使用的原始Claude Opus 4.8，在相同任务上也比GPT-4o同类产品写出更干净的代码，幻觉导入更少。 ### 4. API上的开发者体验 如果您正在使用API构建——而不仅仅是聊天——2026年Claude的开发者体验更好。Anthropic SDK简洁，令牌计数端点对成本估算真正有用，提示缓存实现良好并在重复上下文中节省实际成本，错误处理可预测。 对于以编程方式构建代理的任何人来说，API质量差距很重要。它不大，但很一致。 ### 5. 复杂提示的指令忠实度 Claude处理带有多个条件的细致系统提示比ChatGPT更好。当我需要代理遵循一组规则——"如果评论是问题，执行X；如果是投诉，执行Y；如果提到竞争对手，标记以供人工审核"——Claude更一致地解析和应用这些分支。 对于简单提示，差异是微小的。对于嵌入系统提示中的复杂条件逻辑，Claude更可靠。 ## ChatGPT胜出的地方 ### 1. 消费者集成和插件 ChatGPT的插件生态系统和通过原生界面可用的工具范围更广。如果您的工作流程已经存在于具有原生ChatGPT集成的工具中——某些CRM、生产力应用、研究工具——并且您主要通过聊天界面工作，ChatGPT的开箱即用连接可以减少摩擦。 对于希望从聊天UI中完成所有事情而无需构建自定义集成的高级用户来说，这很重要。 ### 2. 语音模式 ChatGPT的高级语音模式真的很出色。对于移动使用、口头发展想法或开车时准备通话，这是我用过的最好的语音AI界面。Claude有语音输入，但截至2026年中期，没有什么能媲美GPT-4o的完整对话语音模式。 如果语音是您用例的主要界面，ChatGPT明显胜出。 ### 3. 图像生成（通过DALL-E） ChatGPT Plus在同一订阅中包含通过DALL-E的图像生成。Claude不能原生生成图像。如果您想要一个无需添加Midjourney或其他服务的文本和图像工作单一工具，ChatGPT有优势。 ### 4. 熟悉度和采用率 更多人使用过ChatGPT。如果您正在向没有任何AI经验的团队介绍AI工具，从ChatGPT开始摩擦更小——大多数人至少打开过一次。这不是能力优势，但入职速度是真正的运营因素。 ## 成本比较 这里事情变得微妙，也是大多数比较误导人的地方。 两个平台都有分层定价。在API层面： - **Claude Haiku 4.5**和**GPT-4o mini**是高容量简单任务的经济型工作马。它们在价格范围上具有可比性，选择主要由任务要求驱动。 - **Claude Sonnet/Opus**和**GPT-4o**是中高层级。Claude有[提示缓存](/prompt-caching-cut-your-claude-costs-without-switching-models/)，可显著降低重复上下文工作流程的成本——如果您的代理在调用之间重用相同的系统提示和上下文窗口，Claude的缓存价格可能比非缓存费率便宜50-80%。ChatGPT没有直接等效物。 - 在最顶层，Claude Fable 5和最新的GPT-4变体处于相同的基本成本范围，但令牌化器差异很重要——Fable 5有一个令牌化器，以与早期模型不同的方式计算令牌，因此参考令牌计数不能直接转换。 成本结论：**对于高调用量的生产代理，Claude的提示缓存使其在重用上下文的工作负载上实质上更便宜。** 对于新鲜上下文上的纯按调用付费，它们足够接近，应该由性能而非定价来驱动选择。 我用来评估这一点的框架在[AI代理成本数学文章](/ai-agent-cost-math-when-haiku-beats-sonnet/)中。 ## 决策矩阵 | 使用案例 | 获胜者 | |---|---| | 在生产中构建AI代理 | Claude | | 复杂编码和架构 | Claude | | 长上下文文档分析 | Claude | | 带插件集成的聊天助手 | ChatGPT | | 以语音为主要界面的工作流程 | ChatGPT | | 一个界面中的图像+文本 | ChatGPT | | 大规模API驱动自动化 | Claude | | 无AI经验的团队入职 | ChatGPT | | 生产中面向客户的代理 | Claude | | 高容量管道的成本效益 | Claude（含缓存） | ## 我的真实答案 我在生产中使用[Claude](/recommends/claude)处理所有事情。不是因为它赢得每个基准测试——它没有——而是因为： 1. 我的代理遵循系统提示指令的可靠性足够高，以至于我几乎不花时间清理幻觉或偏离任务的输出。 2. Cloudflare Workers + Claude API技术栈每月不到$100用于我的综合工作负载，而提示缓存将我最繁重的工作流程成本降低了一半以上。 3. Claude Code已成为我的主要编码界面，开发和生产都使用相同模型简化了思维模型。 4. 对于长上下文任务——读取PDF、跨文档综合、在多步骤工作流程中保持连贯性——Claude处理完整的200K窗口比我在其他地方经历的更好。 如果我领导一个需要AI辅助工具而不构建任何自定义基础设施的团队，我可能会让他们使用ChatGPT Plus——开箱即用的插件广度和语音模式在消费者层面确实有用。但对于构建事物而不仅仅是使用它们，Claude是正确的基础。 ## 常见问题 ### Claude比ChatGPT更聪明吗？ 两者都不是普遍意义上更聪明的。Claude在长上下文推理、遵循指令和编码方面更好。ChatGPT（GPT-4o）在涉及图像和语音的多模态任务方面更好。特定基准随每次模型发布而在它们之间来回切换。更有用的问题是哪个模型对您的特定任务更好。 ### 我可以同时使用Claude和ChatGPT吗？ 是的，对于某些工作流程您可能想这样做。Claude API和OpenAI API都很容易集成。一些团队将Claude用于代理后端，将ChatGPT用于带集成的面向用户的聊天界面。话虽如此，运行两个AI提供商会增加运营复杂性——凭据管理、成本跟踪、需要管理的行为差异。从一个开始。 ### 哪个更适合内容写作？ 根据我的经验，Claude。它产生听起来不那么通用的输出，在给出示例时更好地保持特定风格，并且更连贯地处理长篇内容。对于两者都能工作的短社交内容或电子邮件，差异很小。 ### Claude有免费层吗？ 是的——Claude.ai有带消息限制的免费层。[Claude Pro和Max订阅](/recommends/claude)取消限制并添加优先访问、文件上传和完整上下文窗口。ChatGPT同样有带使用限制GPT-4o访问的免费层。 ### 我应该从ChatGPT切换到Claude吗？ 如果您主要将AI用作聊天界面并且对ChatGPT满意，除非您有Claude处理得更好的特定需求，否则切换成本可能不值得。如果您正在构建自动化、代理或进行编码工作，我强烈建议尝试Claude——代理行为和开发者体验对生产工作负载有显著差异。 --- ## 如何打造产品化服务：我将专业知识转化为可扩展收入的框架 Source: https://alejandrorioja.com/zh/productized-service-how-to-package-your-expertise/ Published: 2026-07-16 Tags: Entrepreneurship, Marketing TL;DR: 产品化服务是一种固定范围、固定价格的服务，每次以相同方式交付。四个步骤：找到客户已经反复聘用你完成的工作，坚定地定义范围边界，根据结果价值（而非工时）定价，并在向下一位客户销售之前构建交付系统。大多数顾问跳过第四步，继续困于用时间换金钱的模式。这是真正创造规模的唯一步骤。 ## 目录 _2026年7月发布。_ **TL;DR：** 产品化服务是一种固定范围、固定价格的服务，每次以相同方式交付。四个步骤：找到客户已经反复聘用你完成的工作，坚定地定义范围边界，根据结果价值（而非工时）定价，并在向下一位客户销售之前构建交付系统。大多数顾问跳过第四步，继续困于用时间换金钱的模式。这是真正创造规模的唯一步骤。 **[运营者笔记]** 我花了多年时间做定制咨询项目——每个项目的范围不同、价格不同、交付方式不同。结果是一个需要我在每个项目上直接投入注意力的业务。产品化改变了这一切：将我最受欢迎的工作转化为具有明确可交付成果、固定价格和可重复交付手册的定义服务。以下是我建立这套系统的精确框架以及过程中犯的错误。 ## 什么是产品化服务 产品化服务不是保留金模式。不是订阅制。它是一个具有固定范围、固定价格且交付流程记录充分、每次都能以相同方式运行的明确、可重复的服务产品。 与定制咨询的对比：不再是"我们根据范围提供$X–Y的人工智能自动化策略"，而是销售"人工智能自动化路线图：5个工作流程的书面审计、优先构建建议和30分钟交付电话，价格$2500"。范围固定。价格固定。时间线固定。唯一的变量是客户是否说"是"。 与保留金的区别在于它是基于项目的。清晰的开始。清晰的结束。没有开放式的月度账单，没有范围蔓延，没有事后的"你能也看看这个吗？"对话。 让它可扩展的是：系统，而非产品。固定价格服务只是重新定价的定制工作。产品化服务背后有一个交付手册。 ## 第一步：找到客户已经聘用你完成的工作 最容易构建的产品化服务是你已经反复交付、但每次都当作定制工作处理的那种服务。 回顾你最近的10到15个客户或项目，寻找规律： - 哪个问题最常出现？ - 你最频繁地生产哪种可交付成果？ - 哪种类型的项目运行最顺畅，获得最好的客户反馈？ 对我来说，规律很清晰：客户一直在要求同样的东西——帮助梳理他们的流程、选择哪些要自动化，以及为构建选择合适的工具。我反复在做这件事，但每次的范围都不同。 这个规律就是你的起点。不是你认为市场需要的新服务。是你已经在做的事情。 一个过滤器：只产品化那些对所有客户来说输出基本相同的工作。如果每个客户收到的可交付成果完全不同，这项工作还不能被产品化——它仍然是真正的定制工作。这没关系；这只意味着定义工作需要先行。 ## 第二步：定义范围边界——并坚守它 这是大多数顾问失败的地方。他们对服务的定义模糊，让范围对解读保持开放，最终陷入与以前相同的范围蔓延对话。 产品化服务需要硬性范围边界。你在第一次销售通话之前，以书面形式定义什么包含在内、什么不包含在内。 人工智能自动化策略冲刺的范围定义示例： **包含：** - 60分钟结构化接收电话 - 最多5个工作流程的书面审计 - 附带工具建议的优先自动化路线图 - 前3名候选方案的构建与购买评估 - 30分钟交付演练电话 **不包含：** - 实施（构建代理程序或集成） - 交付后的修订 - 超过5个工作流程 - 协议自动化范围之外的工作 "不包含"列表与"包含"列表同样重要。当客户要求范围边界之外的内容时，你有两个选择：说明这超出了本服务的范围，或以自己的范围和价格创建附加服务。你不能做的是吸收它。 这一开始感觉不舒服。你习惯于说"是"来让客户满意。产品化要求你说"那是一个独立的项目"——并始终如一地坚持这一点。 ## 第三步：根据结果价值定价，而非工时 按小时计费与产品化服务不相容。一旦你开始根据自己的时间来计算，你就又把它变成了定制工作。 定价产品化服务的三个变量： 1. **客户不解决问题的成本。** 一个每月释放$4000运营效率的人工智能自动化路线图，对买家来说价值数千美元。你的8小时工作是错误的定价锚点。 2. **买家在可比成果上的花费。** 不是竞争对手的收费——而是客户实际在顾问、分散注意力的高管或部分解决问题的软件上花费多少钱以获得类似结果。这设定了你的上限。 3. **你的最低底线。** 考虑到交付时间、客户管理和间接费用，你需要从这个服务中赚取多少才值得你的关注？这设定了你的下限。 将价格定在该范围内。对于早期的产品化服务，从中间开始。随着你收集推荐和提高交付速度，向上限靠拢。 不要打折。如果有人负担不起这个服务，他们就不是这个服务的合适客户。你可以为不同细分市场构建价格更低的服务——但不要用临时折扣来稀释主要服务，否则你就回到了定制定价。 ## 第四步：在下一次销售之前构建交付系统 这一步决定你是有一个产品化服务，还是只有一个固定价格的项目。 第一次交付之后——在向下一位客户销售之前——做以下事情： 1. **按顺序记录每个步骤。** 不是模糊的提纲。要有足够详细的清单，让熟悉该领域的人能够从中执行80%的流程。我将这些保存在[Notion](/recommends/notion)中——每个工作流程步骤一页，附带模板、示例输出和用于复杂判断的决策树。 2. **识别哪些步骤花费的时间超出预期。** 每次第一次交付都比必要的慢。找到瓶颈并将其系统化：接收表单、可交付成果模板、预建框架。 3. **构建结构化的接收流程。** 在通话之前通过标准化表单获取客户信息，这是让交付可预测的关键。通话是用来澄清问题的，而不是收集信息的。 4. **创建可交付成果模板。** 每位客户收到相同的输出结构。内容会变；结构不变。这使交付快速，输出每次都显得一致和专业。 如果跳过这一步，直接销售给下一位客户，你仍然在做定制工作——只是给它一个固定价格。系统才是让它真正可扩展的东西。 ## 产品化真正释放了什么 主要好处不是更高的收入。而是更好的收入：可预测的需求、更快的交付、更少的谈判对话，以及对想要服务范围之外内容的客户说"不"的能力。 第二个好处：交付文档成为知识产权。你为产品化咨询服务构建的手册，大部分就是课程或培训项目的内容。我用人工智能自动化咨询做到了这一点——交付手册直接成为我的AI Agents for Beginners课程的课程骨架。 第三个好处：杠杆。有了有记录的系统，你可以培训他人执行部分交付工作——审计、研究、文件起草——而你专注于接收和交付电话。这是开始摆脱一对一时间换金钱模式的开端。 ## 我用于管理产品化服务的工具 **[Airtable](/recommends/airtable)** ——每个客户项目一行，跟踪状态、可交付成果链接和付款情况。从一个客户扩展到五十个客户，无需增加复杂性。 **[Notion](/recommends/notion)** ——交付手册和面向客户的工作空间。每位客户都获得一个基于模板的共享Notion工作空间，该模板经过多次重复交付的磨练。 **[ConvertKit](/recommends/convertkit)** ——等待列表管理和跟进序列。当服务满员时（固定范围工作的容量会很快填满），等待列表序列让热门潜在客户保持参与，直到下次开放。 ## 我见过的最常见错误 **在积累足够交付经验之前产品化。** 如果你还没做过这项工作3到5次，你还不了解真实范围。先作为定制工作交付。了解边界在哪里。然后再定义产品。 **保持范围模糊。** 范围不明确的产品化服务是固定价格的定制项目——这是两个世界最坏的结合。定义什么包含在内，定义什么不包含在内，写下来，并放在销售页面上。 **对范围外请求说"是"。** 当客户要求更多时，创建一个有自己范围和价格的附加服务。不要只是这一次就吸收它。 **跳过交付系统。** 第一次交付后你还没有完成。在销售第二个之前构建手册。系统才是产品的关键。 ## 常见问题 ### 我应该从多少个产品化服务开始？ 一个。构建它，交付它，完善系统，收集推荐，然后再考虑第二个。大多数同时推出两个的人，最终得到两个半建成的系统，两者都没有推荐案例。 ### 我在开始销售之前需要落地页吗？ 不需要。对于前5到10次销售，一页PDF或一封写得好的电子邮件就足够了。不要让建设网站成为你还没销售任何东西的原因。 ### 如果客户想要超出范围的内容怎么办？ 告诉他这是一个独立的项目。现场报价一个附加服务，或安排一次范围确认通话。不要将其吸收到当前项目中。坚守范围的纪律是让这个模式有效的关键。 ### 如何获得第一个客户？ 告诉10个了解你工作的人关于这项服务——与信任你或认识需要它的人的人进行温暖的对话。第一次销售几乎总是来自直接对话，而不是落地页。一旦你有了一个案例研究，[创始人主导的销售方法](/founder-led-sales-how-to-reach-decision-makers/)就开始扩展它。 ### 我可以将只做过一次的事情产品化吗？ 不可以。你还不了解真实范围。再作为定制工作交付两到三次，然后将你学到的内容正式化为产品。 --- **后续步骤：** 我的[AI Agents for Beginners课程](/course/)涵盖了使产品化交付可扩展的自动化系统。[协作项目](/cowork/)面向那些构建系统驱动业务并希望在结构化环境中完成它的运营者。 --- ## LinkedIn潜在客户开发策略：我如何不投广告就获得B2B客户 Source: https://alejandrorioja.com/zh/linkedin-lead-generation-strategy/ Published: 2026-07-14 Tags: Marketing, Growth, Entrepreneurship TL;DR: LinkedIn是B2B潜在客户开发中杠杆效应最高的免费渠道——前提是你将其视为信任引擎，而不是大规模冷联系工具。将你的个人资料优化成着陆页，围绕你专业知识的一个维度持续发布内容，并建立一个以价值为先导的简短联系序列。复利效应需要60至90天才能显现，之后几乎可以自动运转。付费广告是可选的，而清晰的个人资料和有用的内容动态则不是。 ## 目录 _发布于2026年7月。_ **TL;DR：** LinkedIn是B2B潜在客户开发中杠杆效应最高的免费渠道——前提是你将其视为信任引擎，而不是大规模冷联系工具。将你的个人资料优化成着陆页，围绕你专业知识的一个维度持续发布内容，并建立一个以价值为先导的简短联系序列。复利效应需要60至90天才能显现，之后几乎可以自动运转。付费广告是可选的，而清晰的个人资料和有用的内容动态则不是。 **运营者视角：** 我曾使用LinkedIn生成咨询询问、课程购买者和合作对话——全程没有投放任何广告。有效的方法不是技巧或工具，而是在你的买家已经聚集的领域里，以真正有用的姿态出现。这是我正在使用的精确手册，以及如果我今天从零开始会采用的执行顺序。 ## 为什么是2026年的LinkedIn LinkedIn的自然覆盖率比几乎其他所有平台都保持得更好。一个拥有几百名相关粉丝的人发布的内容，仍然可以触达数千名精准的专业人士——这在大多数其他渠道上都需要真金白银。算法持续奖励那些能产生收藏和分享的专业知识密集型内容，而不仅仅是点赞。 对于B2B而言，LinkedIn没有可信的替代品： - 决策者在这里的可触达性高于任何其他平台。 - 意图信号是专业的——人们处于"工作模式"，而不是漫无目的地刷屏。 - 评论或帖子会创建你思维的公开记录，潜在客户可以在数周或数月后找到。 - InMail和连接请求仍然是获客成本最低的触达机制之一。 需要注意的是：让LinkedIn有价值的同等开放性，也使其充斥着批量外联、通用的思想领袖帖子和伪装拙劣的推销。脱颖而出的门槛很低。大多数人只是没有达到。 ## 第一步：在发帖之前先修复你的个人资料 当潜在客户收到你的连接请求或偶然看到你写的帖子时，你的LinkedIn个人资料是他们首先阅读的内容。如果它没有立即说明你在帮助谁以及如何帮助，那么你所做的其他一切都会被削弱。 最重要的四个部分： 1. **标题** — 不是你的职位头衔。有效的公式：_[我做什么] 为 [谁] 以便他们能够 [结果]_。"我帮助B2B SaaS创始人在没有销售团队的情况下完成前10笔企业级销售"这样的标题是可搜索的、具体的，并且能立即自我筛选。 2. **背景图片** — 用它来强化同样的信息。带有你的细分领域或简短证明声明的清晰视觉效果胜过通用渐变背景。 3. **关于部分** — 用第一人称写作。两段简短内容：你做什么、为谁做，然后是一两个证明点（客户、结果、成就——真实的）。以明确的行动号召结尾："如果你正在尝试做X，请给我发DM。" 4. **精选部分** — 固定一两件事：一个潜在客户磁铁、你最好的帖子、一个案例研究、一个预约链接。这是大多数人留空的黄金版位。 测试：像陌生人一样阅读自己的个人资料。在10秒内，他们能知道你做什么、为谁做、接下来做什么吗？如果不能，继续修改。 ## 第二步：专注一个角度，持续发布 最常见的LinkedIn错误是随机发帖——周一发营销技巧，周三发励志语录，周五发产品推销。算法会忽视你，你的受众也会。 有效的方法是选择你专业知识的一个具体角度并占据它。每周从该角度发帖三到四次，坚持90天。在早期阶段，数量和一致性胜过灵感和精雕细琢。 ### 产生复利效应的内容组合 | 格式 | 用于 | 为什么有效 | | --- | --- | --- | | 短文本帖子（3–5行） | 反直觉观点、快速框架、近期工作的经验 | 高覆盖率、消费门槛低、能引发评论 | | 列表帖子 | 分步骤拆解、比较、工具 | 收藏和分享；算法偏爱 | | 故事帖子 | 我经历的具体情况、我的做法、结果如何 | 比任何其他格式更快建立信任 | | 长篇文章 | 深度指南、常青解释 | 被搜索引擎索引；长期将你定位为专家 | | 轮播（文档帖子） | 可视化框架、较长帖子的摘要 | 所有格式中收藏率最高 | 我使用的比例：70%短帖子和列表，20%故事，10%长文或轮播。长文帖子的覆盖率不高，但会在数月内在搜索和DM分享中积累。 ## 第三步：有意识地建立你的连接基础 在LinkedIn上发展正确的粉丝群与单纯追求数量增长是不同的。一千个恰好是你目标买家的粉丝，比一万个同行或随机旁观者更有价值。 我的定向标准： - 我所服务行业的决策者 - 收入规模与我合作范围匹配的公司创始人和运营者 - 现有客户和合作者的二度连接（最温暖的来源） - 与我领域的竞争对手或同行互动的人 我每天发送15至20个连接请求，每个都附有一行说明为什么建立联系的备注。不是推销——只是背景信息："看到你关于[话题]的评论，与我的工作相关——很高兴能建立联系。"这条备注能将接受率从约30%（通用）提升至约55–65%（具体）。备注最多两句话。 不要与所有人建立连接。充斥着不合格账户的膨胀连接列表实际上会伤害你——LinkedIn的算法会将你的帖子部分分发给你的连接，所以低质量的受众会压制你的覆盖率。 ## 第四步：安排你的外联序列——三次触达方法 一旦有人建立连接，目标不是立即推销。而是开始一段对话，这段对话随着时间推移可能会带来一次会议。那些将连接视为粘贴销售PPT许可证的人，会毒害之后的每一个接触点。 我使用的序列： **触达1（第1天，连接后24小时内）：** 发送一条简短、热情的欢迎消息。提及你为什么建立连接，并分享一个有用的资源——一篇帖子、一个框架、一篇文章——与他们分享的内容相关。不做请求。以陈述句结尾，而不是以问句结尾。 **触达2（第5–7天）：** 真诚地参与他们的一篇帖子——不只是点赞，而是一条真正为对话增添价值的深思熟虑的评论。这让你的名字在他们的动态中保持可见，而无需再次发送DM。 **触达3（第14–21天）：** 在DM中跟进，提出温和、具体的请求。一个明确且易于回答的问题，与你注意到的他们工作中的相关内容相关联。如果时机合适且痛点真实，会议就会在这里预约成功。如果不是，继续前进——账户已经变温，他们知道你的名字。 我一直看到的错误：跳过触达1和2，在有人建立连接的那一刻直接跳到行动号召信息。这不是潜在客户开发；这是一种声誉税。 ## 第五步：将对话转化为会议 DM中的良好对话需要一个通向日历邀请的清晰出口。当有人表现出真正的兴趣时——问了追进问题、直接提及了他们的问题，或者对你的解决方案有所回应——那就是你提出请求的时刻。 能促成转化的消息： > "听起来[他们说的具体事情]对你来说是真实存在的。我帮助过一些类似情况的公司——很乐意花20分钟介绍我们是如何处理的，不做推销，只是看看是否相关。[预约链接]——如果有用的话请选一个时间段。" 简短、低承诺、容易答应。预约链接消除了日程安排上的摩擦——正是这种摩擦扼杀了本应发生的一半会议。 ## 不该做的事情 会导致账户被忽视、被举报或被封禁的行为： 1. **没有背景信息的批量连接请求** — LinkedIn会限制你的账户，你的接受率会下降。 2. **先推销的DM** — 第一条消息不是介绍你的产品、定价或日历链接的地方。 3. **互助点赞群** — 虚假互动会膨胀虚荣指标并受到算法惩罚。 4. **每天发帖却没有观点** — 没有视角的数量就是噪音。每周一篇有真正洞见的帖子胜过每周七篇没有实质内容的"热门观点"。 5. **自动化外联** — LinkedIn的机器人检测变得更加积极。大规模的自动化连接工具和AI写作的DM序列会被标记。第四步中的序列每天只需约30分钟，其信噪比是任何工具都无法匹敌的。 ## 衡量真正重要的指标 应该忽略的虚荣指标：展示次数、个人资料访问量、粉丝数量。 能告诉你系统是否有效的数字： - **连接接受率** — 目标50%以上附带备注；如果低于30%，重写备注。 - **跟进消息的回复率** — 对于精准定向的列表，20–30%是健康的。 - **每月收到的主动DM** — 因为你的内容而主动联系你的人。逐月追踪。 - **每月从LinkedIn预约的通话** — 唯一与收入相关的数字。 我在一个简单的Notion表格中追踪这些数据。前90天的目标是仅从LinkedIn实现每周一条主动DM和每月一次预约通话。到第三个月，如果内容奏效，这些数字会在没有成比例增加努力的情况下上升。 ## 运营者的总结 LinkedIn在B2B潜在客户开发中之所以有效，是因为它是唯一一个自然覆盖率仍有分量、你的声誉会随时间公开积累的专业网络。机制很简单：一个能解释你在帮助谁的个人资料、能证明你知道自己在说什么的内容，以及一个以价值而非推销为先导的联系序列。持续执行90天，主动询问就会开始涌来。坚持一年，它就会成为你最可靠的合格对话来源之一——无需广告预算。 --- **相关：** [创始人主导的销售](/founder-led-sales-how-to-reach-decision-makers/) · [如何建立个人品牌](/how-to-build-a-personal-brand/) · [外联策略](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/) --- ## 我如何用 Claude 打造 Courtlines：一款俱乐部管理 SaaS Source: https://alejandrorioja.com/zh/how-i-built-courtlines-a-club-management-saas-with-claude/ Published: 2026-07-11 Tags: AI Agents, Case Study TL;DR: Courtlines 是面向球拍类运动俱乐部与场馆的操作系统——预订、会员、教练、销售终端和活动全都收进一个带自有品牌的系统里。我以单人运营者的身份、把 Claude 当作工程伙伴,一手把它做了出来。收获是:AI 不只是让我写代码更快,它改变了一个人能可信地交付并运营的产品规模。 ## 目录 _更新于 2026 年 7 月。_ **太长不看：** Courtlines 是面向球拍类运动俱乐部与场馆的操作系统——预订、会员、教练、销售终端和活动全都收进一个带自有品牌的系统里。我以单人运营者的身份、把 Claude 当作工程伙伴,一手把它做了出来。收获是:AI 不只是让我写代码更快,它改变了一个人能可信地交付并运营的产品规模。 **[运营者视角]** 我在一家咨询品牌和 Pickleland 之间运行着 30 多个生产环境的智能体——Pickleland 是我在德州奥斯汀都会区经营的一家匹克球场馆。真正经营一家场馆,让我切身体会到给我这类俱乐部用的软件到底有多糟——于是我把自己一直想要的软件做了出来。这就是 [Courtlines](https://courtlines.com) 的故事:它能做什么,以及依靠 Claude 如何让一个人做出了通常需要一整个团队才能做出的东西。 ## 为什么俱乐部需要的是操作系统,而不是一个 App 如果你从没经营过一家运动场馆,软件的难题是看不见的。从外面看,它就是「人们预订场地」。而从里面看,一家俱乐部是一门小而杂乱的生意,有十几个必须彼此对得上的活动部件。 一位会员预订一片场地。这条预订必须知道:他是不是在某个会员套餐里、有没有余额、这片场地是不是已经被某个训练班占用、有没有安排教练、前台有没有覆盖过价格。等他到场,有人在柜台结账买一罐球——这是销售终端。他给孩子报名参加青少年项目——这是活动与家庭账户。他买了 10 节课的课包——这是教练课包,带着自己一套向教练结算的逻辑。他推荐了一个朋友——这是会员招募漏斗。 大多数俱乐部靠三四个互不相通的工具、加一张电子表格、再加一个群聊来撑起这一切。预订系统不知道销售终端的事。销售终端不知道会员的事。到了月底,谁的账都对不上。 **Courtlines 就是对「要是这一切都是一个系统会怎样?」这个问题的答案。** 它不是一个功能硬拼上去的预订 App——它是一套单一的操作系统,日历、会员、收银台、教练结算和对外的活动页面,底层都是同一份数据。这就是整套主张,也是网站上的标语:面向俱乐部与场馆的操作系统。 ## Courtlines 到底能做什么 从宏观上看,[Courtlines](https://courtlines.com) 给一家俱乐部提供: - **一张可拖拽的场地网格图**,给前台用——每一条预订、每一个训练班、每一次占用都在一个屏幕上,管理员可以实时重新排布。 - **面向会员的预订与开放场次**,包括那些别扭却又不可或缺的边界情况:循环预订、候补名单、取消时限,以及余额。 - **会员与账单**——套餐、家庭账户、关联到家长的青少年/儿童登录,以及那套让收入不再悄悄流失的催缴机制。 - **教练管理**——课包、排课,以及向独立教练的自动结算。 - **销售终端**——给专业用品店和咖啡吧用的真正收银台,和其他一切绑定在同一份客户记录上。 - **活动与对外页面**——训练班、联赛和锦标赛,配有可供大众发现并报名的对外页面。 设计目标是让平台本身「消失」。俱乐部把自己的品牌放在最上层,对它的会员来说,它感觉起来就是「我们俱乐部的 App」,而不是「我们花钱用的某套 SaaS」。这是刻意与这一领域的现有玩家——CourtReserve、Skedda 之流——拉开对比:在他们那里,软件才是品牌,俱乐部只是个租户。 Pickleland 是 1 号租户。我没法躲在一个演示 demo 后面;这东西得真的去运营一家我个人要为之负责的场馆。这个约束是我用过的最棒的产品经理。你可以[在这里看看 Pickleland](https://pickleland.com)——它就是现实世界里的试验场,任何一个会员撞上的粗糙边角,都是我当天就能感受到的一个 bug。 ## 让我意外的那部分:如今一个运营者能交付什么 这是这个故事诚实的版本,也正是我写这篇文章、而不是悄悄上线的原因。 一套带账单、销售终端、基于角色的权限、教练结算和对外活动系统的多租户 SaaS,不是一个周末项目。放在十年前,这是一支拿到种子轮、五到八名工程师干上一年的活。这种规模,单人创始人通常会被人好心地劝去收窄到一个功能、然后去融资。 我是一个人做的,**把 Claude 当作我的核心工程伙伴。** 不是「我偶尔让 ChatGPT 给个代码片段」——我是说,这套系统里绝大部分代码是 Claude 写的,它依据的是由我掌控的规格说明和产品决策。我的工作从*敲实现代码*,转向了*决定什么才是对的*:数据模型该是什么样、一个角色被允许做什么、一个功能怎样才算「完成」,以及什么东西可以安全上线。 有意思的转变不在速度,尽管确实更快了。而在**规模**。AI 没有把我变成在同样大小的产品上效率翻倍的开发者。它改变了我能可信地构建、并且——同样重要的——独自*运营和维护*的产品规模。一套只由一个人类写出来的代码库,会在自身的重量下坍塌。而一套由 AI 伙伴掌握实现细节、我掌握架构与护栏的代码库,是一种真正不同的东西——这正是为什么如今一个单人运营者可以去追一个过去需要一整家公司才能追的品类。 我在这里刻意不公开我经营 Courtlines 的具体操作手册——那部分我视为竞争优势,我宁愿我的竞争对手继续相信这需要一支大团队。但如果你想详细看看我在一个真实项目上*如何*驾驭 Claude 的机制,我为一个小得多的作品把它全写了下来:一款我上架了应用商店的手机游戏。见[我如何用 Claude 打造 Quads,一款手机桌游](/how-i-built-quads-a-mobile-board-game-with-claude/)——同样的工作方式,毫无保留,所有招数都摆在桌面上。 ## 我不会妥协的几条原则 即便手册保密,还是有几条原则值得说出来,因为它们适用于任何用 AI 构建严肃软件的人: **危险的笔握在人类手里。** 有少数几类操作,一旦出错代价高昂、又难以挽回——改数据库结构、部署、任何涉及金钱或生产数据的动作。这些牢牢留在我手里。AI 可以提议,但它不能执行。把这条线画清楚,才使得在其他各处给 AI 大量放权是安全的。 **测试全绿是必要的,但不充分。** 一条通过了所有单元测试的预订流程,在真实浏览器里仍然可能明显是坏的。对一个带 UI 的产品来说,最重要的验证是一个人——或者一个受监督的流程——真的拿贴近现实的数据去点一遍。测试是一个防止事情变得更糟的坡度;它们不是某个功能能用的证明。这一课我是花了大代价学到的,它永久改变了我对「完成」的定义。 **规格说明才是真正的接口。** 撬动力不在巧妙的提示词——而在于持续维护清晰、当下有效的文档,写明系统是什么、每个部分该做什么。把这些保持精确所花的时间,会在未来每一次会话中成倍地回报你。如果你想要这条原则更深入的版本,它就是我在[如何写出不会在生产环境翻车的 AI 智能体系统提示词](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/)中描述的同一种纪律。 **做那个你必须与之朝夕相处的东西。** 我做过的最好的一个决定,就是让 Courtlines 去运营一家我自己拥有的场馆。做一个让人惊艳的 demo 很容易;可是,面对一套你自己的会员都指望着它的软件,你无处可躲。如果你在用 AI 构建,把它对准一个你个人切身感受到的问题——这份现实检验比任何测试套件都值钱。 ## 这与我在做的其他一切如何衔接 Courtlines 并不是孤立存在的。它是我正在打造的一个小型球拍运动生态的一部分:[The Court Scout](https://thecourtscout.com) 是一个经过核实的匹克球场地目录,做出来就是为了比那些和它竞争的抓取来的目录真正更准确,而 Pickleland 是那家旗舰场馆,所有东西都拿它来检验。目录帮球员找到场地;Courtlines 帮这些场地背后的俱乐部真正把生意运转起来。 贯穿这一切的连接组织,是同一套运营模型:一个被 AI 放大的单人运营者,掌管着比过去任何单人运营者能掌管的更大的地盘。Courtlines 是这套模型迄今最有野心的表达——一套完整的 SaaS 平台,放在几年前,我根本不会一个人去尝试。 如果你经营一家球拍运动俱乐部或场馆,厌倦了把四个工具拼在一起,那就去看看 [Courtlines](https://courtlines.com)。而如果你是一位构建者,好奇自己能把 AI 在一个真实产品上推到多远,这正是这篇文章的全部要点:比你以为的更远。 ## 常见问题 ### Courtlines 是什么？ Courtlines 是一套面向球拍类运动俱乐部与场馆的多租户操作系统——匹克球、网球、板网球等等。它把预订、会员、教练、销售终端和活动管理整合进一个带自有品牌的平台,让一家俱乐部从单一系统里运营整门生意,而不是靠四个互不相通的工具。你可以在 [courtlines.com](https://courtlines.com) 看到它。 ### Claude 真的写了大部分代码吗？ 是的。Claude 是我的核心工程伙伴,写了绝大部分实现代码,依据的是由我拥有并掌控的规格说明、架构和产品决策。数据结构、部署,以及对「完成」的定义握在我手里;AI 握着实现细节。正是这种分工,让一套这种规模的、单人打造的 SaaS 在维护上可持续。 ### 一个人真的能靠 AI 构建并运营这么大的一套 SaaS 吗？ 构建它如今确实可行——这才是让人意外的部分。更大的挑战在于运营和维护,因为一套大型代码库需要一个懂架构的人,哪怕细节是 AI 写的。关键在于保持清晰的规格说明,并在那少数几类高风险操作上守住底线——它们必须由人来负责。这样做,一个运营者可维护的地盘,比过去要大得多。 ### 为什么要自己做俱乐部软件,而不用 CourtReserve 或 Skedda？ 因为经营 Pickleland 让我清楚看到现有工具在哪里力不从心:预订系统、收银台和会员系统不共享同一份可信数据源,于是没有一样东西能干净地对上账。我想要一个系统,让这一切都是同一份底层数据,而且会员看到的是俱乐部的品牌——不是软件供应商的。这正是 Courtlines 要去弥合的缺口。 ### 我在哪里能学到你日常究竟怎么和 Claude 协作？ 出于竞争考虑,我把 Courtlines 的详细手册保密,但我在一个更小、完全公开的项目上记录了一模一样的工作方式——一款叫 Quads 的手机桌游。想看机制,读[我如何用 Claude 打造 Quads,一款手机桌游](/how-i-built-quads-a-mobile-board-game-with-claude/);想看我交付一切东西背后的投资回报思路,读[我如何判断一项自动化值不值得做](/ai-agent-roi-how-i-decide-whether-automation-worth-building/)。 --- ## 我如何用 Claude 打造 Quads——一款手机桌游:从 2 小时黑客松到应用商店 Source: https://alejandrorioja.com/zh/how-i-built-quads-a-mobile-board-game-with-claude/ Published: 2026-07-11 Tags: AI Agents TL;DR: Quads 是一款手机桌游——对经典抽象游戏 Quarto 的一次清爽演绎——它始于我和一位朋友在哥伦比亚的 2 小时黑客松,最后上架了应用商店。这是我如何用 Claude 构建的完全公开版本:并行的智能体 worktree、一个真正的(非 LLM)游戏 AI、离线优先的设计,以及那些让我付出时间代价的具体的坑。 ## 目录 _更新于 2026 年 7 月。_ **太长不看：** Quads 是一款手机桌游——对经典抽象游戏 Quarto 的一次清爽演绎——它始于我和一位朋友在哥伦比亚的 2 小时黑客松,最后上架了应用商店。这是我如何用 Claude 构建的完全公开版本:并行的智能体 worktree、一个真正的(非 LLM)游戏 AI、离线优先的设计,以及那些让我付出时间代价的具体的坑。 **[运营者视角]** 我在一家咨询品牌和 Pickleland 之间运行着 30 多个生产环境的智能体——Pickleland 是我在奥斯汀都会区的匹克球场馆。我构建的大多数东西都是严肃的商业软件,手册我都保密。Quads 恰恰相反——一个我可以从头到尾展示给你看的有趣副业。如果你想确切地看到我怎么和 Claude 协作、一点都不打磨掩饰,那就是这篇文章。你可以在 [playquads.com](https://playquads.com) 找到这款游戏。 ## 它始于哥伦比亚的一场 2 小时黑客松 它的起源随意得几乎有点难为情。我当时在哥伦比亚旅行,一位朋友和我给自己定了个 2 小时的黑客松:挑个小东西,用 AI 把它做出来,看看能走多远。我们选定了 Quarto——一款漂亮的小型抽象策略游戏,易学却出人意料地有深度。两个小时后,我们有了一个能玩的原型,而这个点子太好了,不该被丢在一台笔记本电脑里。 一个限时挑战开的头,最后变成了 iOS 和 Android 上一款真正上架的手机 App。这条弧线——*玩笑式原型到商店上架*——正是我认为这个项目值得一写的全部原因。「有趣的点子」和「陌生人能下载的东西」之间的距离已经坍塌,而 Quads 是一个清晰的案例,展示了它是怎么坍塌的。 先岔开说说名字。这款游戏是对 **Quarto** 的重新实现,而 Quarto 是 Gigamic 拥有的注册商标游戏。所以第一个非代码的决策,就是*不要*在任何客户能看到的地方管它叫 Quarto。它从 Quarto(玩法机制),经过几个过渡名字,变成了 **Quads**——一个我可以正当使用的名字。如果你在重新实现一款经典游戏,在你爱上某个名字之前,先把商标问题处理清楚。 ## Quads 到底是什么 给不熟悉的人:Quads 在一个 4×4 的棋盘上、用 16 枚各不相同的棋子来玩。每枚棋子都有四个二元属性——高或矮、深或浅、方或圆、实心或空心——这 16 枚棋子把每一种可能的组合恰好各覆盖一次。你通过凑成一条四枚棋子的线来取胜,这四枚棋子只要共享*任意一个*属性即可。 让它变得精妙的转折是:**你不能选自己要放的棋子。是你的对手把它递给你的。** 然后你再把对手要放的递给他。所以每一回合都是双重困境——你要在不给对手做局的前提下放下别人递给你的那枚棋子,同时挑一枚不会把胜局白送给对手的棋子递过去。它优雅,而且是真的难。 这款 App 提供四种玩法,全都完全离线:跨五个难度档次与电脑对战、在一台设备上轮流传玩、每日谜题,以及一种异步的「向朋友发起挑战」模式。无需账号、无需服务器、无需登录。这个离线优先的决策驱动了大量工程实现,也是单人构建之所以可行的一大原因。 ## 游戏逻辑:一整套规则从位运算里自然掉出来 这是我最喜欢的部分,因为它属于那种无论 AI 有没有参与都令人满足的东西。 16 枚棋子里的每一枚,只不过是一个从 0 到 15 的整数。四个二进制位里的每一位,就是一个属性。就这么简单——整套棋子就是 0–15 这些数字,因为四个位恰好给你 16 种组合。 于是判定胜负几乎变得不值一提。对任意一条四枚棋子的线,你维护两个累加器:在*每一枚*棋子里都为 `1` 的那些位,以及在*每一枚*棋子里都为 `0` 的那些位。如果走完四枚之后任一累加器非零,这些棋子就至少在一个属性上一致——那就是胜局。整套规则坍缩成了几个按位与运算。 因为这套逻辑是对整数的纯函数——没有框架、没有 UI、没有状态——它可以直接做单元测试,而且扩展起来轻而易举。Quads 甚至还提供一个自定义规则变体,让九个 2×2 的方块也算作取胜形状,这在同一个位运算技巧之上只是两行代码的增补。当你和一个 AI 伙伴把核心逻辑保持得这么干净,加一个功能就成了乐事,而不是风险。 ## AI 对手不是一个 LLM(而这才是对的选择) 这里有一个我很在意的教学时刻:**不是每一个「AI」都该是一个大语言模型。** Quads 的对手是纯粹的经典游戏 AI,它也理应如此。每一回合它做两个决策——把递给它的棋子放在哪里,以及把哪枚棋子递回去——而难度决定了它思考得有多用力: - **新手**基本上是随机走棋,还会把胜局白送给你。 - 中间档次加入了启发式规则:如果存在立即取胜的机会就抓住它,并避免递出一枚对手能借此取胜的棋子,优先选那枚为未来埋下最少威胁的棋子。 - **大师和特级大师**跑一套有界的 negamax 搜索——真正的博弈树搜索——但带一个硬性的**节点预算**,这样一步棋绝不会卡住手机的主线程。在游戏早期,完美搜索不可行,它会退回到快速的启发式规则;到了游戏后期,博弈树足够小,它就来真的搜索。 这里有两点值得偷师。第一,在这里,一个语言模型会*更差*——更慢、更贵、不确定、还打不过——远不如五十行 negamax。让工具匹配问题。第二,节点预算才是真正的工程:在一台移动设备上,「正确,但偶尔卡上四秒」是一个失败的功能。把搜索限定住,让一步棋始终很快,哪怕偶尔不是最优——这就是玩具和产品之间的区别。知道*什么时候*该动用一个 LLM,和我对每一项自动化所用的是同一种判断——这正是[我如何判断一个 AI 项目值不值得做](/ai-agent-roi-how-i-decide-whether-automation-worth-building/)的核心。 ## 我究竟怎么驾驭 Claude:在 worktree 里并行跑智能体 现在轮到我在更大的产品上保密、但在这里可以完全展示给你看的那部分。 我不是一次只用一个 Claude 会话来构建。我**并行跑好几个**,每一个都在它自己的 git worktree、自己的分支上。一个智能体加国际化,另一个搭建每日谜题系统,还有一个做色盲模式,又一个接上音效——每个都隔离在自己的工作副本里,这样它们没法互相破坏,而每一个在通过测试后再合并回来。Quads 的 git 历史是一整面墙的 `Merge branch 'worktree-agent-…'` 提交,从外面看,那套工作流就长这个样子。 worktree 之所以重要,原因很简单:并行的智能体去编辑同一个工作目录,会瞬间互相踩踏。给每一个一个隔离的检出,你就能真真切切地同时有四个功能在施工,然后像合并任何别的分支那样把它们合并进来。这是对我工作方式撬动力最大的单项改变——我从一次一个对话、一个功能,变成了一支小舰队。 如果你想要那些智能体所依据的提示词背后的纪律,它就是我在[如何写出不会在生产环境翻车的 AI 智能体系统提示词](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/)中描述的同一种:撬动力在于清晰、当下有效的规格,而不是巧妙的措辞。 ## 那个花了我一个小时的坑(这样它就不会花你一个小时了) 每个项目都会教给你一个又蠢又费钱的教训。在 Quads 上,这个教训是:**预览工具并不总是显示你以为它在显示的那个分支。** 当你在多个 worktree 里跑多个智能体、并预览它们的成果时,预览可能从一个*不同的*目录启动——不是你当前会话所在的那个——于是你截了 App 的图,一个改动都看不到,然后开始调试那些「缺失」的、其实从没缺失过的 UI。功能好好的;是预览指向了错误的检出。在我搞明白到底发生了什么之前,我为此白白搭进去了不少时间,后来我把它写进了项目自己的笔记里,好让未来的我(以及我交给这个仓库的任何智能体)在调试幻影 bug *之前*先检查一下预览目标。 与之相关的陷阱:定义那些预览的配置文件在并行会话之间是共享的,所以两个智能体同时编辑它,可能会悄无声息地覆盖掉彼此的条目。如果你打算跑一支舰队,就把共享配置当作一种被争用的资源来对待——它只会咬你一次,只要你把这个教训写下来,之后就再也不会了。 这个习惯——把每一个来之不易的坑都记进一个下一个会话会读到的持久文件里——是任何规模下用 AI 构建的沉默脊梁。上下文会在会话之间蒸发;写下来的教训不会。 ## 我引以为傲的那些离线优先的小技巧 因为 Quads 没有后端,有几个问题需要巧妙的、无服务器的解法: - **每日谜题**是根据本地的一年中第几天来确定性地选出来的,于是全世界每一位玩家都拿到同一道谜题,零服务器协调。(附赠教训:我上线之后,立刻修掉了那段日期运算里一个夏令时相关的差一错误。日期总是比看上去要难。) - **「向朋友发起挑战」**把一道谜题编码进一小段文本代码——类似 `QC1-01-03-3` 这样的东西——由一个校验和守护着,这样一个笔误就没法产生一个「有效但错误」的挑战。你的朋友把它输进自己那份 App 副本里,就能玩到一模一样的局面,完全离线。没有账号,没有匹配,没有服务器。 - **富链接预览**是我唯一确实用了一点点服务器代码的地方。当你分享一个挑战链接时,一个单独的 Cloudflare Pages Function 会为每段代码渲染出对应的 Open Graph 标签,好让链接在 iMessage 或 WhatsApp 里漂亮地展开。社交爬虫不跑 JavaScript,所以一个客户端渲染的预览会让每个链接看起来都一模一样——一个小小的函数就修好了这一点,而无需一个真正的后端。 这些一旦你看明白了都不难,但每一个都是这样一个地方:偷懒的答案是「起一个服务器和一个数据库」,而更好的答案是「做那个巧妙的离线方案」。完全避开后端,正是为什么一个人能交付并维护这个东西。 ## 从黑客松到商店上架 最后一段路——那个没人会跟你讲的、关于「2 小时项目」的部分——是介于「它在我手机上能跑」和「陌生人能下载它」之间的一切。一次横扫八种语言的国际化。绝不使用那个注册商标名字的商店文案。应用商店的构建工具、版本管理,以及那些让商店审核不把你打回来的平台特定权限清理。这一切毫不光鲜,却是很多副业项目悄然死去的地方。 用 Claude 来做,没有让清单变短,但它让每一项都便宜到了我真的能做完的程度。这才是 Quads 真正的故事:不是 AI 写了一款桌游——很多人都能做出个原型——而是它把*最后一公里*的成本降到了足够低,让一个黑客松玩笑变成了一个上架的产品。 如果你手里攥着一个一直没动手的小点子,那就是我全部的主张。先做那个 2 小时的版本。你会惊讶于终点线已经移得多近。而如果你想看看这套同样的工作方式往规模上能走多高,我把它一路推到了一整套多租户 SaaS——[我如何用 Claude 打造 Courtlines,一款俱乐部管理平台](/how-i-built-courtlines-a-club-management-saas-with-claude/)。 在 [playquads.com](https://playquads.com) 玩 Quads。 ## 常见问题 ### Quads 是什么？ Quads 是一款面向 iOS 和 Android 的手机桌游——对经典抽象策略游戏 Quarto 的一次清爽重构。你在一个 4×4 的棋盘上、用 16 枚各不相同的棋子来玩,而转折在于:是你的对手挑选你必须放下的那枚棋子。它免费畅玩,提供单人、轮流传玩、每日谜题和异步挑战等模式。在 [playquads.com](https://playquads.com) 找到它。 ### Claude 写了整款游戏吗？ Claude 写了绝大部分代码,依据的是由我拥有的设计和决策。我并行跑了好几个 Claude 会话,每一个都在它自己的 git worktree 里,构建不同的功能,再由我合并到一起。游戏逻辑、AI 对手、国际化、音效和谜题系统,大体上都是这样构建、并由我审阅的。 ### 游戏里的 AI 对手是由 LLM 驱动的吗？ 不是——而且是刻意的。这个对手用的是经典游戏 AI:较低难度用启发式规则,顶级档次用一套有界的 negamax 搜索,带一个硬性节点预算,这样一步棋绝不会卡住设备。对这个活来说,一个语言模型会更慢、更贵、也更弱。为问题选对 AI 的种类,比总是伸手去够那个最大的模型更重要。 ### Quads 花了多长时间才做出来？ 第一个能玩的原型出自我和一位朋友在哥伦比亚旅途中的一场 2 小时黑客松。把那个原型变成一款打磨过、可上架两大应用商店的 App——带国际化、一个真正的 AI 对手、离线挑战,以及商店合规——花的时间要长得多,但每一个单独的步骤在 AI 的帮助下都便宜到足以让这个项目真正抵达终点线。 ### 用 Claude 构建 Quads 最大的教训是什么？ 两点。第一,在隔离的 git worktree 里跑智能体,这样你就能并行构建好几个功能而不让它们互相踩踏。第二,把每一个坑都写进一个下一个会话会读到的持久文件里——上下文会在会话之间蒸发,但写下来的教训会复利累积。想看这套工作方式的更大图景,见[我如何用 Claude 打造 Courtlines](/how-i-built-courtlines-a-club-management-saas-with-claude/)。 --- ## 如何编写不会在生产环境中失败的AI智能体系统提示词 Source: https://alejandrorioja.com/zh/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/ Published: 2026-07-11 Tags: AI Agents TL;DR: 生产环境中的系统提示词包含五个层次：身份（智能体是谁以及不能做什么）、上下文（对环境的了解）、任务（逐步描述成功标准）、输出格式（最容易被忽视的层次）和边界情况（输入出错时如何处理）。大多数提示词失败是因为跳过了第4和第5层。先写输出格式——这会迫使你对真正想要的结果保持精确。 ## 目录 _2026年7月更新。_ **TL;DR:** 生产环境中的系统提示词包含五个层次：身份（智能体是谁以及不能做什么）、上下文（对环境的了解）、任务（逐步描述成功标准）、输出格式（最容易被忽视的层次）和边界情况（输入出错时如何处理）。大多数提示词失败是因为跳过了第4和第5层。先写输出格式——这会迫使你对真正想要的结果保持精确。 **[运营者视角]** 我在生产环境中为我的咨询品牌和Pickleland（德克萨斯州普夫卢格维尔的匹克球设施）运营着30多个AI智能体。我重写的系统提示词比我新写的还多——通常是因为第一版在测试中表现良好，然后在生产环境中悄然退化。这是我从中学到的关于编写持久提示词的经验。 ## 没有人承认的系统提示词问题 大多数智能体的系统提示词大约20分钟写完，在两三个示例上测试，然后永远不再触碰。模型上线。一段时间内运行良好。然后某些事情发生了变化——输入变得更混乱，模型被更新，出现了新的边界情况——智能体开始产生垃圾输出。悄无声息地。大规模地。 问题不在于原始提示词很糟糕。而是大多数提示词是为了演示"幸福路径"而写的。它们是为你构建智能体时想象的输入设计的，而不是为智能体实际会看到的完整输入分布设计的。 ## 生产系统提示词的五个层次 我将每个系统提示词分为五个层次来思考。它们不必按此顺序出现——但都必须存在。 ### 第1层：身份 身份告诉模型它是谁，以及它的操作约束是什么。这不是角色扮演——而是对这个智能体做什么和不做什么的功能性定义。 一个强大的身份层回答三个问题： - 这个智能体负责什么？ - 它明确**不**负责什么（应该升级或拒绝）？ - 它遵守什么标准？ 明确的"不在范围内"部分是大多数运营者跳过的内容。没有它，模型会试图在其职责范围之外提供帮助——这就是出问题的地方。 ### 第2层：上下文 上下文是智能体对其环境的了解，而这些信息不在用户消息中。这包括当前日期和时间（动态注入——永远不要相信模型内部的时间感）、来自外部系统的相关状态以及从任务描述中不明显的业务规则。 我审查的大多数智能体都缺乏上下文。不要假设。注入它。 ### 第3层：任务 任务层描述智能体逐步执行的操作。不是"帮助客户"——而是真实的决策流程。像流程图一样编写，而不是指令。流程图更健壮，因为它减少了模型在模糊情况下推断你想要什么的需求。 ### 第4层：输出格式 这是最容易被忽视的层次，也是最容易导致静默失败的层次。 如果不精确指定输出格式，模型会产生对人类读者看起来正确的输出，但对下游解析来说不够一致。先写输出格式。对于结构化输出，指定精确的模式。对于散文输出，指定结构、长度和语气约束——包括明确的反模式。 对于高风险智能体，我使用[Claude](/recommends/claude)的结构化输出与定义好的JSON模式。 ### 第5层：边界情况 边界情况层回答：当输入模糊、不完整、语言错误、带有敌意或明显错误时，智能体会做什么？为每种边界情况给模型一个明确的响应路径。 ## 我如何随时间维护系统提示词 生产系统提示词是一个活的文档： 1. **每周抽查。** 我对每个高风险智能体检查五到十个随机输出，与预期输出进行对比。 2. **模型更新后审查。** 每次基础模型版本变更时，我都会针对我的[评估框架](/how-i-measure-whether-an-ai-agent-is-actually-working/)中的完整黄金集运行智能体。 3. **边界情况日志。** 我保持一个持续的日志，记录智能体处理不当的输入。当三个或更多条目呈现出模式时，我添加一个明确的规则。 4. **提示词版本控制。** 每次重大更改都会在提示词文件顶部添加版本注释。 ## 常见问题 ### 生产系统提示词应该多长？ 足够长以覆盖全部五个层次。足够短以便在两分钟内读完并发现偏差。我的大多数智能体是200到600个单词。 ### 何时应该将复杂任务拆分为多个智能体而不是一个长提示词？ 当任务有两种或多种不同模式，需要不同的上下文、不同的输出格式或不同的错误处理时。请参阅[事件触发与定时调度智能体](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/)了解模式。 ### 在测试中有效的提示词在生产中失败的最常见原因是什么？ 测试输入不能代表生产分布。从真实的生产流量构建测试集，而不是从想象的输入构建。 ### 我如何知道何时更新提示词与更新代码？ 如果智能体产生了错误的输出格式，请更新提示词。如果智能体产生了正确的输出但下游系统无法使用它，请更新代码。如果智能体自信地产生了错误的事实，首先检查上下文层。 --- ## AI智能体ROI：我如何决定是否值得构建一个自动化 Source: https://alejandrorioja.com/zh/ai-agent-roi-how-i-decide-whether-automation-worth-building/ Published: 2026-07-09 Tags: AI Agents, Operations TL;DR: 在构建任何AI智能体之前，我会进行四部分ROI检查：量化人工成本、估算构建成本、预测运行成本，并添加维护税。结果是回收期。如果非战略性任务超过六个月，我就放弃。大多数智能体想法都无法通过这个测试——这正是重点。构建错误的自动化比什么都不构建更糟糕。 ## 目录 _2026年7月更新。_ **TL;DR：** 在构建任何AI智能体之前，我会进行四部分ROI检查：量化人工成本、估算构建成本、预测运行成本，并添加维护税。结果是回收期。如果非战略性任务超过六个月，我就放弃。大多数智能体想法都无法通过这个测试——这正是重点。构建错误的自动化比什么都不构建更糟糕。 **【运营者视角】** 我在生产环境中运行超过30个AI智能体，覆盖一个咨询品牌和Pickleland（德克萨斯州普夫卢格维尔的匹克球场馆）。我放弃的智能体至少和我启动的一样多。被放弃的不是坏想法——而是没有通过数学检验的好想法。这个框架是我在写任何智能体代码之前执行的。 ## 没有人首先问的问题 2026年，每个人都在问"我怎么自动化这个？"更好的问题是"我应该自动化这个吗，它什么时候能回本？" AI智能体不是免费的。构建需要时间，运行需要金钱，维护需要持续关注。如果自动化无法比手动替代方案更快地收回这些成本，你只是让运营更复杂、更昂贵——而不是更高效。 ## 第一步：量化手动基准 第一个数字是当前流程每年的全成本。 ``` 年手动成本 = (每次耗时 × 时薪 × 年频率) + 年错误成本 ``` **每次耗时**是某人实际花费的时钟时间——不是从头到尾的日历时间。 **时薪**是执行工作的人的全部成本。如果是你自己的时间，使用你的目标咨询或机会成本率，不要用零。 **年频率**是这项任务实际运行的次数。 **错误成本**是大多数人遗忘的因素。 来自Pickleland的真实案例：手动发送Facebook活动推广每周需要45分钟。按我的机会成本率，这是每周45美元或每年2340美元。这就是基准。 ## 第二步：诚实估算构建成本 构建成本几乎总是被低估。错误在于只计算编码时间，而忽略其他所有事情。 ``` 构建成本 = (开发小时 × 时薪) + 工具设置成本 + 测试和迭代小时 × 时薪 + 集成调试小时 × 时薪 ``` 对于Pickleland活动推广工具：我估计6小时构建、3小时测试和调优、2小时集成调试。按我的费率，这是990美元的构建成本。 ## 第三步：预测运行成本 ``` 年运行成本 = (年API调用次数 × 每次调用成本) + 年基础设施成本 + 人工审核小时 × 时薪 ``` **API调用**是Claude/LLM调用加上任何第三方API。根据实际token数量计算。 **基础设施**在Cloudflare Workers + Queues上，中等流量通常低于每月5美元。 **人工审核**是人们最常忘记的成本。 对于Pickleland推广工具：每年约1000次Claude API调用。人工审核约800美元/年。总运行成本：约810美元/年。 ## 第四步：应用维护税 这是每次智能体ROI计算中最被低估的因素。智能体会出故障。 我将构建成本的20%固定税率作为年维护税。 ``` 年维护成本 = 构建成本 × 维护率 ``` 对于Pickleland推广工具：990美元 × 20% = 198美元/年。 ## 回报公式 ``` 年净节省 = 年手动成本 − 年运行成本 − 年维护成本 回收月数 = (构建成本 ÷ 年净节省) × 12 ``` 对于Pickleland活动推广工具： - 手动成本：2340美元/年 - 运行成本：810美元/年 - 维护：198美元/年 - 年净节省：1332美元/年 - 构建成本：990美元 - **回收期：8.9个月** 这是临界值。我对非战略性自动化的门槛是六个月。 ## 我的回收期门槛 - **不足3个月：** 立即构建。这种情况很少见。 - **3-6个月：** 坚定的是。这些是能够复利的自动化。 - **6-12个月：** 如果战略重要则构建。否则放弃。 - **超过12个月：** 几乎总是放弃。 ## 何时不应该自动化 我看到团队犯的最昂贵的错误是自动化不稳定的流程。如果工作流程每隔几周就会变化，自动化会锁定当前有缺陷的版本。 在自动化之前，问问自己：这个流程是否已经稳定了至少三个月？ 第二个错误是自动化低频率但高风险的任务。第三：不要为了避免对话而自动化。 ## 运行这些自动化的智能体技术栈 我在生产中运行的大多数自动化都在Cloudflare Workers + Queues上，使用[Claude](/recommends/claude)作为LLM。基础设施成本真的很低。 ## 常见问题 ### 我应该为自己的时间使用什么时薪？ 使用你的机会成本——如果你把时间花在其他事情上你会获得或创造什么。不要使用零。 ### 在构建任何东西之前，我如何估算Claude API成本？ 使用Claude的token计数端点，输入真实输入的代表性样本和目标模型。 ### 什么算作"战略性"自动化？ 战略性自动化（1）以影响留存或转化的方式直接服务客户，（2）实现手动无法达到的运营规模，或（3）产生推动更好决策的数据。 ### 我应该计算监控智能体所花费的时间吗？ 是的。监控时间是真实的持续成本。 ### 如果这项任务是我就是讨厌做的事情呢？ 讨厌一项任务有真实的成本。对于我真正厌恶的任务，我会接受更长的回收期，但这不是空白支票。 --- ## 创始人主导的销售：在组建团队之前，如何找到并触达真正的买家 Source: https://alejandrorioja.com/zh/founder-led-sales-how-to-reach-decision-makers/ Published: 2026-07-09 Tags: Entrepreneurship, Growth, Marketing TL;DR: 在你雇销售团队之前，你得先证明自己能卖出去。创始人主导的销售归结为三件事：找到那个真正能拍板说“行”的人，做足够的调研以赢得一次回复，然后把你的渠道排出顺序——用邮件提出请求，用电话做时间敏感的跟进，用 LinkedIn 做温和的引荐。大多数交易卡住，不是因为话术弱，而是因为它落进了错误的收件箱。绕开这一点，你就能约到连付薪水的销售都约不来的会。 ## 目录 _发布于 2026 年 7 月。_ **太长不看：** 在你雇销售团队之前，你得先证明自己能卖出去。创始人主导的销售归结为三件事：找到那个真正能拍板说“行”的人，做足够的调研以赢得一次回复，然后把你的渠道排出顺序——用邮件提出请求，用电话做时间敏感的跟进，用 LinkedIn 做温和的引荐。大多数交易卡住，不是因为话术弱，而是因为它落进了错误的收件箱。绕开这一点，你就能约到连付薪水的销售都约不来的会。 **[操盘者视角]** 我见过的每一位真正把公司做起来的创始人，最早的几单都是自己亲手谈下来的——通常一开始很笨拙，后来才逐渐拿手。这条路没有捷径。你无法把一套自己从没跑过的销售流程交给别人，因为你还不知道你的买家究竟对什么会有反应。这就是我自己使用、也在辅导创始人时反复讲的流程：如何找到对的人，如何只做恰到好处的调研以赢得一次回复，以及如何在不向陌生人狂轰滥炸、也不购买爬虫工具的情况下触达他们。 ## 为什么创始人必须先亲自去卖 你无法把一套自己从没跑过的流程交出去。如果你在自己都还没成交几单之前就雇了销售，你不是在放大一套流程——你是在把“发现这套流程”的过程外包出去，还要付一份薪水去学那些你本该免费学到的东西。 创始人主导的销售不是一个你忍着熬到雇得起销售为止的阶段。它是你学到买家用哪些确切措辞、哪个异议能干掉十单里的九单、哪一句话能让人身体前倾的方式。这些认知后来会变成你的话术、你的手册，以及招人的标准线。跳过它，你的第一个销售雇员继承的就只是一个猜测。 好消息是：作为创始人，你拥有一个销售永远不会有的、不公平的优势。是你造出了这个东西。你能回答任何问题，能在一通电话里当场调整路线图，还能带着一种任何背着业绩指标的陌生人都伪装不出来的可信度去讲话。你的任务，就是频繁地出现在对的人面前，让这份优势真正发挥作用。 ## 第一步：找到那个能说“行”的人 触达失败最常见的单一原因，就是它触达了错误的角色。你的信息不会被拒绝——它会被一个从来就没有权限对它采取行动的人收到，然后悄无声息地死掉。 在大多数公司里，你和一单生意之间坐着三类人： - **拥护者**——切身感受到你的产品要解决的痛点，并希望它被解决。往往职位不高，但会在内部替你奔走的人。 - **经济买家**——掌控预算、能批准这笔支出。这才是最终拍板说“行”的人。 - **阻拦者／守门人**——采购、行政助理、IT，或是一个多疑的副手，其职责就是过滤噪音。不是你的敌人，但也不是你的目标。 在联系任何人之前，先决定你瞄准的是哪一位，以及为什么。第一次约会，你通常想找的是拥护者或经济买家——绝不是某个仅仅因为名字好找就被你找到的随便某位员工。触达错误的人不只是浪费了这条信息；它可能烧掉整个客户账户，因为现在你的名字已经和一条打偏的冷启动推销挂上了钩。 如果你说不清为什么某个具体的人是对的联系人，那你就还没准备好去触达。 ## 第二步：做足够的调研以赢得一次回复 联系人调研不是“找到一个邮箱地址”。它是拼凑出足够的背景信息，让你的信息看上去只可能是写给那一个人的。这才是在一个每周收到五十条推销的收件箱里赢得回复的方式。 在你动笔写任何东西之前，先弄清楚： 1. **触发点**——为什么是现在？一轮融资、一位相关岗位的新聘、一次产品发布、一则公开的抱怨、一个暴露出缺口的招聘启事。一个让时机对*他们*而言说得通的理由。 2. **具体的痛点**——不是“像你们这样的公司在 X 上很吃力”，而是能证明*这家*公司确实如此的证据。 3. **连接的纽带**——一个共同的人脉、一位处在他们领域的客户、一件你注意到而模板伪造不出来的事情。 公开来源不需要任何特殊工具就能让你拿到其中大部分：公司自己的网站和招聘页、LinkedIn、近期报道、播客露面、上市公司的财报电话会，以及你的买家真正出没的社群。如果你把市场验证做扎实了，其中一些功课你其实已经做过了——参见[如何在动手打造之前验证一个商业创意](/how-to-validate-a-business-idea/)，那份需求与竞品调研恰好也能充当销售情报。 判断你是否做够了的检验标准是：你能不能把信息的头两句话写成——发给任何别的公司都会*毫无意义*的样子？如果能，你就准备好了。如果你的开场白放在一百家公司身上都成立，那就继续调研。 ## 第三步：把你的渠道排出顺序——邮件、电话、LinkedIn 没有哪个渠道是唯一最好的。只有针对每个时刻的最佳渠道。错误在于挑一个死磕到底。功夫在于把它们排出顺序，让每一个都去做它真正擅长的活儿。 | 渠道 | 最佳用途 | 用不好的风险 | | --- | --- | --- | | 邮件 | 主要的请求、详细的跟进、任何买家需要在内部转发的东西 | 一读上去像模板就会被瞬间无视 | | 电话 | 时间敏感的跟进、给一单已约定却在拖延的生意排期、别人让你打的一个温暖引荐 | 在没有任何前情或理由的情况下会让人觉得被冒犯 | | LinkedIn | 温和的首次接触、给一个冷联系人预热、在两封邮件之间保持露面 | 拥挤、缓慢，容易看起来跟其他所有推销一模一样 | | 温暖引荐 | 任何场合，只要你能拿到 | 引荐人的信誉押在上面——别浪费它 | 一套在实践中管用的顺序：先发一封简短、具体、扣住你找到的触发点的邮件。如果没有回复，就在 LinkedIn 上创造价值——一条真诚的评论、一份有用的资源、一个带有背景说明的好友请求——好让你的名字不再是一个陌生的冷惊喜。只有当有一个真实理由时——一个截止日期、一次引荐、一单在对方表示兴趣后又归于沉默的生意——才升级到打电话。一通凭空冒出来、打给一个从没听过你名字的人的电话，是被归进垃圾类别最快的方式。 而且，只要你能挣来一次温暖引荐，就永远优先用它。一个来自买家信任之人的引荐，胜过二十封精心打磨的冷邮件。在你走冷启动这条路之前，先花实打实的功夫去梳理：你的人脉里谁能替你打开哪一扇门。 ## 第四步：写出会被回复的信息 一旦你挣得了触达的资格，就把信息写得简短，让对方容易说“行”。陌生人发来的长篇推销不会被读；它们会被归档。 一封好的冷邮件，在不到 90 个词内做四件事： 1. **点出触发点**——证明你在留意，这不是群发。 2. **陈述相关的痛点**——一句话，从他们的角度、而不是你的角度来框定。 3. **提出一个小小的请求**——一通 15 分钟的电话，而不是“我们来探讨一次合作吧”。 4. **给一个轻松的台阶**——“如果这事不归你管，能否帮我指个负责的人？” 大致是这个样子： > “你好，Priya——看到你们 RevOps 团队刚开了两个岗位，这通常意味着报表的痛苦增长得比招人补位还要快。我们帮 B 轮团队把手动做报表的时间砍掉约 60%，而不用把现有的技术栈全拆掉。下周花 15 分钟看看这事跟你们相不相关，值不值？另外，如果这不归你的范畴，我会很感激你帮我指个负责的人。” 这很具体，尊重了对方的时间，而且回复起来毫不费力——就算是“不”也有用，因为它会把你引到对的人那里。同样的自律适用于所有渠道；如果你想要在规模化触达时既不被标记、也不被无视的更深层机制，我在[打造成功的触达策略](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/)里做了拆解。 ## 第五步：像这是你唯一一次机会那样去准备会面 拿到接触点，只是给了你开场。做好准备，才挣来下一步。创始人常常苦战数周才约到一次会，然后走进去时却根本没把买家的世界想透彻——于是这单死掉，不是因为缺乏兴趣，而是因为缺乏准备。 在任何一通电话之前，你要能不假思索地回答： - 这个人的一天是什么样子，我的产品嵌进其中的哪个位置？ - 他们最在意、而我又能撬动的那一个结果是什么？ - 他们会提出的那两个异议是什么，我诚实的回答又是什么？ - 如果他们有兴趣但还没准备好，我能请求的最小的下一步是什么？ 产品是你造的，所以演示很容易。难的地方在于，把买家的优先事项装在脑子里，而不是你自己的。那些把触达变成收入的创始人，是那些一开口就听起来已经懂这门生意的人——因为他们在第二步就把功课做了。 ## 什么时候不该去触达 激进的触达烧掉的销售管道，比它建起来的还多。在下列情况下，跳过这次冷接触——或者放慢下来： - 你说不出为什么这个具体的人是对的联系人。 - 你已经跟进了两次以上却毫无回应。（放手吧；市场很大。） - 你的开场白发给另外一百家公司也照样成立。 - 你会在正常工作时间之外打电话，或是在没有任何前情的情况下打过去。 - 你挑中这个人的唯一理由，是他的联系方式好找。 好的触达，感觉像是一个做足了功课的人，在恰当的时机发来的一条切题的便条。糟糕的触达，感觉像是瞄得更准一点的垃圾信息。差别完全在于调研和克制。 ## 创始人主导销售的工具栈 我为此依赖的工具和习惯，没有一样需要销售团队： - **调研：** 公司自己的网站和招聘页、LinkedIn、近期报道，以及你的买家真正在聊天的社群 - **CRM：** 任何你真的会去更新的东西——一块简单的 Notion 看板或 Airtable，胜过一个你懒得管的企业级 CRM - **排序：** 一个轻量的跟踪表，记下谁处在哪个阶段、下一次接触是什么，好让没有一件事被落下 - **邮件：** 一个真实、已养熟的发信地址，以及纯文本信息——不要图片、不要跟踪像素，不要任何大喊“这是一场营销活动”的东西 - **日历：** 一个预约链接，让一个“行”一键就变成一次会面，而不是来回五封邮件 ## 操盘者的结论 你不需要一个销售团队才能开始卖。你需要的是：清楚地知道谁能说“行”，做足够的调研让你的信息看上去只可能是写给他们的，并把你的渠道排出顺序，让每一个都各司其职。邮件承载请求，LinkedIn 预热地面，电话补上一个时间敏感的缺口，而一次温暖引荐胜过它们全部。自己亲手把这些练习跑够久，直到学会什么才真正打中——然后，也只有到那时，才把这套来之不易的手册交给你的第一个雇员。 --- **相关阅读：** [打造成功的触达策略](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/) · [如何验证一个商业创意](/how-to-validate-a-business-idea/) · [增长营销策略指南](/growth-marketing-strategies-guide/) --- ## 如何建立独立创业者商业模式：2026年完整指南 Source: https://alejandrorioja.com/zh/how-to-build-a-solopreneur-business/ Published: 2026-07-07 Tags: Entrepreneurship, Growth TL;DR: 选择一种商业模式（内容、服务、SaaS或数字产品），围绕单一细分市场建立受众，在主要模式转化后再叠加次要收入来源。陷阱是同时启动全部四种——选择与你现有知识相匹配的模式，而不是听起来最被动的那种。 ## 目录 _更新于2026年7月。_ **TL;DR:** 选择一种商业模式（内容、服务、SaaS或数字产品），围绕单一细分市场建立受众，在主要模式转化后再叠加次要收入来源。陷阱是同时启动全部四种——选择与你现有知识相匹配的模式，而不是听起来最被动的那种。 **[运营者视角]** 多年来，我在没有全职员工的情况下运营这个网站、销售课程并管理联盟收入。这一切都不是从宏大计划开始的——从一件奏效的事情开始，然后有意识地扩展。这份指南是我希望在尝试同时做所有事情之前读到的内容。 ## 独立创业者业务究竟是什么 独立创业者独自经营业务——没有联合创始人，没有员工，当业务量需要时可能有合同工。目标是依靠专业知识和系统运营的业务，而非人员规模。 这与自由职业不同。自由职业者出售时间。独立创业者构建系统，在不需要为每一分钱贡献时间的情况下创造收入。 ## 独立创业者的4种商业模式 每个一人企业大致属于以下之一： 1. **内容业务。** 你发布内容（博客、新闻简报、YouTube、播客），通过广告、联盟收入、赞助和自有产品变现。进入门槛最低，增长周期最长。 2. **服务业务。** 你为客户提供特定成果——咨询、分时角色、全包服务。达到月入10万元最快的路径，扩展性最差。 3. **数字产品。** 课程、模板、电子书、工具。一旦建立高度杠杆，但没有现有受众很难带来流量。 4. **微型SaaS。** 解决一个特定问题的小型软件产品。天花板最高，技术门槛最高。 正确的模式取决于你已经拥有什么：技能、受众或资本。 ## 第一步：选择有真正深度的细分市场 宽泛的细分市场（营销、金融、健康）有流量但竞争激烈。窄细分市场（面向电商创始人的AI工具、新护士的个人理财）转化更好、排名更快。 我使用的测试：我能在这个主题上写出50篇真正有用的内容而不枯竭吗？如果能，细分市场有深度。如果连20个都难以说出，那就太窄了或者我对它了解不够。 你的细分市场应该处于以下交叉点： - 你从经验中了解的东西，而不仅仅是研究 - 有钱或时间可以支出的受众 - 一个反复出现的问题，而非一次性解决方案 ## 第二步：在需要之前建立受众 我看到的最大错误：向零受众发布产品。 受众先于产品是原则。以下是真正有效的方法： 1. **选择一个分发渠道并深入其中。** 博客+SEO慢但持久。新闻简报变现快。短视频天花板高但依赖算法。第一年不要把注意力分散在四个平台上。 2. **在有东西可卖之前持续发布。** 你在没有东西可卖时建立的受众，在你终于有东西卖时会信任你。 3. **从第一天起建立电子邮件列表。** 社交媒体粉丝是租来的土地。你的电子邮件列表是你的。我使用[ConvertKit](/recommends/convertkit)——它处理序列和广播而不妨碍工作。 一个有用的基准：1000名真正的粉丝（打开每封邮件的电子邮件订阅者）足以从数字产品中每年产生100万元收入。 ## 第三步：首先优化主要收入来源 一旦有了受众（或来自服务的客户），在添加次要收入来源之前，先集中全力优化主要收入来源。 **对于内容业务：** 联盟收入是最快的第一笔钱。你写关于你使用的工具的文章，通过推荐页面链接，赚取百分比。不需要构建产品，不需要客户支持。天花板是真实存在的——利润丰厚细分市场中的高流量网站每月可以赚5000到3万美元——但这是我发现的最好的自力更生机制。 **对于服务业务：** 收取超出舒适感的价格。定价过低是独立创业者最常见的错误。如果你的成交率是100%，那你就太便宜了。 **对于数字产品：** 保持范围紧凑。一个97美元的专注课程在转化率和完成率上胜过一个497美元的广泛课程。 **对于微型SaaS：** 为你个人的痛点而构建。当你自己就是目标客户时，共情优势是真实存在的。 ## 第四步：叠加次要收入来源 一旦你的主要模式开始转化，添加不需要相应时间的收入来源： - **联盟收入** ——即使是服务业务和SaaS运营者也可以从内容中获得联盟收入 - **数字产品** ——即使你主要是服务业务，一门课程或模板集也可以在你睡觉时赚钱 - **赞助** ——一旦你的受众超过约5000名参与订阅者 - **授权** ——如果你构建了系统或工具，将其授权给相邻细分市场中的其他人 叠加是结果，不是策略。先让一个流运转起来。 ## 独立创业者的技术栈 我用六个工具运营整个业务： | 工具 | 功能 | |---|---| | [Claude](/recommends/claude) | 内容、邮件和代码的初稿 | | [ConvertKit](/recommends/convertkit) | 邮件列表、自动化和广播 | | [Notion](/recommends/notion) | 编辑日历、客户文档和标准流程 | | [Canva](/recommends/canva) | 社交媒体图形和缩略图设计 | | [Airtable](/recommends/airtable) | 联盟追踪、CRM、内容数据库 | | [SEMrush](/recommends/semrush) | 关键词研究和排名追踪 | 每月总成本：不到2000元。替代这个技术栈的团队每月薪资将超过10万元。 ## 扼杀独立创业者业务的3个错误 1. **过早扩张。** 在商业模式得到验证之前招人会在有可重复收入之前消耗资源并增加管理负担。 2. **过早多元化。** 四个半途而废的收入来源赚的比一个完全优化的少。第一年要深入而非拓宽。 3. **没有分发就构建。** 没有受众的最好产品无法击败拥有大量参与列表的普通产品。分发是护城河。 ## 运营者的结论 独立创业者业务是用团队复杂性换取所有权和利润率的刻意选择。我见过的持续成功的业务都有同样的模式：一种模式、一个细分市场、一个分发渠道，坚持足够长的时间以实现复利增长。 选择与你现有技能相匹配的模式。在需要之前建立受众。只有在主要收入来源转化后才添加收入来源。其余的是执行。 --- **相关文章：** [如何验证商业创意](/how-to-validate-a-business-idea/) · [如何将新闻简报变现](/how-to-monetize-a-newsletter/) · [如何建立个人品牌](/how-to-build-a-personal-brand/) --- ## 如何用AI智能体自动化您的小型企业：实践指南 Source: https://alejandrorioja.com/zh/how-to-automate-your-small-business-with-ai-agents/ Published: 2026-07-04 Tags: AI Agents, Entrepreneurship, Operations TL;DR: 用AI智能体自动化小型企业并非为了取代人类，而是将重复性、基于规则的工作委托出去，让您能将时间用于只有您才能做出的决策。从一项任务开始，记录一切，对于直接涉及资金或客户的事务保留人工环节，然后逐步扩展。我在两家企业使用的技术栈每月总成本不到100美元。 ## 目录 _2026年7月更新。_ **TL;DR：** 用AI智能体自动化小型企业并非为了取代人类，而是将重复性、基于规则的工作委托出去，让您能将时间用于只有您才能做出的决策。从一项任务开始，记录一切，对于直接涉及资金或客户的事务保留人工环节，然后逐步扩展。我在两家企业使用的技术栈每月总成本不到100美元。 **运营者说明：** 我经营两家企业——德克萨斯州普夫卢格维尔市一个拥有九个场地的室内匹克球馆（Pickleland）和一个咨询品牌。两家企业加起来，我有超过30个AI智能体在生产环境中运行，处理从社交媒体评论回复到活动推广、通讯草稿和预订跟进的各项工作。这是一份关于真正有效的方法、时间浪费在哪里以及如何在不雇用开发人员的情况下起步的真实指南。 坦诚的框架：面向小型企业的AI智能体并非魔法。它们无法替代客户关系、产品质量或战略判断所需的艰辛工作。它们所做的是消除每位运营者每天要花两到三小时的行政杂务——收件箱整理、复制粘贴报告、社交媒体回复、数据格式化。这已经足以带来改变。 ## 4种能很好自动化的工作类型 在构建任何东西之前，先将您的工作负荷分为四个类别。其中只有一个适合AI智能体。 ### 1. 基于规则、重复性强、文本输入/文本输出 这是最佳切入点。对客户邮件分类、起草社交媒体评论回复、将一周的预订数据汇总成要点列表、将CSV重新格式化为报告。输入是文本；输出是文本；规则是一致的。这些任务只需一个单次提示和API的薄层封装即可自动化。 **Pickleland的示例：** - 对来自场地查询的邮件进行分类（问题/投诉/预订/其他） - 为即将举行的活动起草Facebook群组帖子 - 从预订系统生成每周入住率摘要 ### 2. 具有清晰交接的多步骤流水线 一项包含三个步骤的任务——获取数据、转换数据、发送通知——每个步骤都有清晰的输入和输出。这与轻量级编排层配合良好（我使用Cloudflare Workers Queues）。关键在于每个步骤可以独立失败并重试，而无需重做整个工作。 **Pickleland的示例：** - 新预订 → CRM更新 → 确认邮件 → Slack通知 - 表单提交 → 分类 → 定向回复草稿 → 人工审核队列 ### 3. 监控和警报 监视某个条件并在条件触发时通知您的智能体。这是一些投资回报率最高的AI自动化，因为它们取代了手动检查仪表板的认知负担。它们也是最简单的：逻辑仅仅是"X超过阈值了吗？如果是，发出警报。" **我的咨询品牌示例：** - Google Analytics异常警报（流量下降、峰值） - 预订取消率超过每周基准线 - 新评价发布——标记为需要人工回复 ### 4. 内容初稿（不是最终产品） AI智能体可以以实用质量起草社交帖子、电子邮件通讯、博客大纲和产品描述。问题在于：它们无法替代您的编辑判断。每个草稿都要经过人工审核步骤。投资回报来自于从70%的完成度开始，而不是从空白页面开始。 **不能很好自动化的工作：** 客户关系管理、定价决策、销售对话、招聘，以及任何出错会对真实的人产生真实成本的工作。这些任务保留人工参与。 ## 我实际使用的技术栈 您不需要企业级软件来做这些。以下是驱动我的自动化的工具： 1. **[Claude](/recommends/claude)** — 所有AI任务的模型层。我直接使用API，不使用图形界面。每美元的质量是我测试过的最好的，而[提示缓存](/prompt-caching-cut-your-claude-costs-without-switching-models/)在系统提示重复时进一步降低成本。 2. **Cloudflare Workers** — 智能体运行的地方。无服务器、全球分布，免费层覆盖大多数小型企业工作负载。`scheduled`处理程序运行cron任务；`fetch`处理程序接收事件触发流程的webhook。 3. **Airtable** — 数据骨干。每个智能体从Airtable表读取和写入。任务状态、审核队列和运营数据都存放在这里。非开发人员无需触碰代码即可编辑数据。 4. **Kit（前身为ConvertKit）** — 电子邮件和通讯自动化。我的通讯起草智能体写入Kit草稿；我审核后发送。 两家企业30多个智能体的月度总成本：不到100美元。最大的开销是Claude API使用费。其余都是免费层或接近免费。 ## 真实示例：Pickleland的自动化 ### 活动推广员 每个周日，一个定时智能体检查预订系统，查看未来四天内的活动。它将每个活动与相关的本地Facebook群组匹配，并为每个群组起草适合场地的推广帖子。草稿进入Airtable审核表。我花五分钟审核并点击"批准"——智能体完成40分钟的起草工作。没有我的批准，任何内容都不会自动发布。 这是[定时智能体模式](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/)——按计划运行，执行批量工作，并提交草稿供人工审核。 ### 社交评论分类器 当被监控的Facebook帖子收到新评论时，webhook触发，智能体对意图进行分类：问题、投诉、赞美或垃圾信息。对于置信度超过阈值的问题和投诉，它起草回复并标记以供审核。赞美被记录。垃圾信息被抑制。从评论到草稿30秒的循环。没有智能体时，每条评论都是手动的上下文切换；现在预先起草的回复队列只需五分钟而不是三十分钟。 这是[事件触发智能体模式](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/)——由webhook触发，必须快速响应。 ### 每周运营简报 每个周一早晨，一个智能体提取上周的预订数据、取消率、各场地类型的入住率以及任何标记的异常。它格式化五点摘要并存入Notion页面。我喝咖啡时阅读，用两分钟而不是二十分钟获得我一周所需的运营背景。 ## 从哪里开始：4个步骤 ### 第1步：选择您每周做的摩擦力最高的重复任务 不是最光鲜的，不是最战略性的——是您最头疼的那个。您从三个来源复制粘贴的每周报告。您花一小时处理的社交媒体回复。您一封一封发送的跟进邮件。那就是您的第一个智能体。 ### 第2步：将任务映射为输入和输出 写下： - 触发任务的是什么（时钟、事件、表单提交） - 它需要什么输入（数据源、文本、上下文） - 输出是什么（草稿、通知、数据库行） - 人工审核步骤是什么（每个第一个智能体都应该有一个） 如果您无法清晰地映射它，任务的定义还不够好，不能进行自动化。先手动澄清流程。 ### 第3步：构建尽可能小的版本 不是系统。一个提示，一次API调用，一个输出。一个TypeScript函数，接受输入，调用Claude，返回草稿。没有数据库，没有webhook，没有队列——只有核心逻辑。手动运行五次。输出质量能保持吗？如果可以，您就有了一个可运行的智能体。然后添加基础设施。 ```typescript // 最简单的第一个智能体：活动推广草稿 async function draftEventPromo(event: PadklelandEvent, env: Env): Promise { const msg = await env.ANTHROPIC.messages.create({ model: "claude-opus-4-8", max_tokens: 400, system: `You write Facebook event promo posts for Pickleland, an indoor pickleball facility in Pflugerville, TX. Tone: friendly, local, community-focused. Max 150 words.`, messages: [ { role: "user", content: `Write a promo post for this event: ${JSON.stringify(event)}`, }, ], }); return (msg.content[0] as { text: string }).text; } ``` ### 第4步：在添加更多功能之前添加可观测性 用跟踪ID记录每次运行。记录输入、输出和时间戳。您不需要花哨的工具——将结构化JSON输出到stdout足以开始。原因：您的第一个智能体会以您没有预料到的方式失败。当这发生时，您需要能够看到发生了什么，而不需要从记忆中重建状态。 这是将扩展其智能体栈的运营者与在一次糟糕经历后放弃的运营者区分开来的习惯。我在[如何在生产中调试AI智能体](/how-to-debug-an-ai-agent-in-production/)中深入探讨了这个问题。 ## 常见错误（以及如何避免） **在理解流程之前进行自动化。** 如果您自己不能以一致的方式完成这项任务，AI智能体只会在规模上以不一致的方式完成它。先手动记录流程，然后再自动化。 **过早删除人工审核步骤。** 从每个智能体的人工参与审核开始。让它运行两周，检查每个输出，建立信心，然后再让任何事物完全自动化运行。例外情况是低风险、易于逆转的操作（如将草稿写入文件夹）。 **在验证核心之前构建整个系统。** 首先构建最简单的版本。如果核心质量无法通过一个提示实现，更多基础设施也无法解决问题。 **忽视成本。** AI API成本随使用量增长。在大规模部署之前了解每次运行的成本。当您每周进行数千次运行时，[Haiku与Sonnet的成本计算](/ai-agent-cost-math-when-haiku-beats-sonnet/)很重要。 **将失败视为灾难。** 智能体会失败。提示会退化。API会宕机。构建重试逻辑，构建[评估框架](/the-eval-harness-i-use-to-ship-ai-agents/)，将失败视为数据而不是灾难。 ## 改变一切的思维转变 小型企业的瓶颈几乎从来不是资金——而是所有者的时间和注意力。您花在智能体可以处理的任务上的每一个小时，都是您没有用在客户、产品或战略上的时间。 我使用的框架：如果一项任务可以被写成具有清晰输入和输出的可重复流程，它就是智能体的候选。需要判断、关系或创造力的一切都留给我自己。智能体处理前者，这样我就可以专注于后者。 开始使用AI智能体不需要技术联合创始人、六位数的软件预算或数月的开发时间。它需要选择一项高摩擦任务，构建可运行的最小版本，并从输出中学习。大多数运营者在一个周末内找到他们的第一个可运行智能体。从那里，第二个只需要一个下午。 ## 常见问题 ### 为小型企业运行AI智能体需要多少成本？ 我的技术栈以每月不到100美元运行30多个智能体。最大的成本是AI API使用（Claude）。Cloudflare Workers每天免费提供100,000次请求，之后每月5美元。Airtable有免费层，覆盖大多数小型企业的数据需求。成本随使用量扩展——单个每周运行几次的智能体成本可以忽略不计。 ### 我需要开发人员来构建AI智能体吗？ 对于基本模式——定时cron、webhook处理程序、简单提示——只需一些JavaScript和阅读文档的意愿即可。对于更复杂的流水线、编排和生产级可观测性，开发人员会加快工作速度。我的课程（[AI智能体入门](/ai-agents-for-beginners-cowork-codex-guide/)）教授运营者的无代码和低代码路径。 ### 小型企业最好的第一个AI智能体是什么？ 每周运营简报。它按计划运行，有清晰的输入（您的数据源），产生一致的输出（格式化的摘要），下行风险为零——如果草稿错了，您只是不读它。它建立您对智能体能做什么和不能做什么的直觉，不会对客户或运营造成风险。 ### 我应该使用什么AI模型进行业务自动化？ 我在几乎所有智能体工作中使用Claude。API质量、可靠性和对运营者友好的定价（尤其是配合[提示缓存](/prompt-caching-cut-your-claude-costs-without-switching-models/)）使其成为生产使用的正确选择。对于便宜的、高容量的分类任务，Claude Haiku 4.5快速且经济。对于起草和细致的任务，Claude Sonnet或Opus。 ### 如何防止AI智能体犯错伤害我的业务？ 三个实践：对直接涉及客户或资金的一切保留人工参与；记录每次运行以便追踪出了什么问题；构建一个[评估框架](/the-eval-harness-i-use-to-ship-ai-agents/)，这样提示的更改不会悄然破坏生产。从低风险的内部任务开始，只有在信任输出质量后才扩展。 --- ## 如何在网上打造个人品牌：2026年从业者实战手册 Source: https://alejandrorioja.com/zh/how-to-build-a-personal-brand/ Published: 2026-07-02 Tags: Entrepreneurship, Growth TL;DR: 打造个人品牌的方法是：选择一个特定的受众群体，在单一渠道上持续发布有用内容，并拥有清晰的观点——而不是优化你的LinkedIn简介。缩小你的细分领域，从真实经验出发写作，建立电子邮件列表作为唯一自有渠道，然后不断重复，直到合适的人无法忽视你。 ## 目录 _更新于2026年7月。_ **TL;DR：** 打造个人品牌的方法是：选择一个特定的受众群体，在单一渠道上持续发布有用内容，并拥有清晰的观点——而不是优化你的LinkedIn简介。缩小你的细分领域，从真实经验出发写作，建立电子邮件列表作为唯一自有渠道，然后不断重复，直到合适的人无法忽视你。 **[从业者说明]** 我在多家企业中公开建设——Pickleland、AI代理咨询、这个网站——我不断看到同样的规律：打造出知名个人品牌的人并不是最有才华的。他们是最具体、最坚持的。以下是我使用和推荐的框架。 ## 个人品牌究竟是什么（以及不是什么） 个人品牌是一个问题的答案：*当你不在场时，人们怎么评价你？* 不是你的logo。不是你的配色方案。不是你有多少粉丝。个人品牌是人们听到你名字时形成的心理捷径——他们认为你能解决的特定问题，他们期待你持有的观点。 大多数人犯的错误：在还没有发展出观点之前就试图打造品牌。品牌是通过做真实的事情、并对自己的学习保持具体性而积累的——不是提前制造出来的。 你从一开始就能控制的： 1. 你在和谁说话 2. 你为他们解决什么问题 3. 他们在哪里找到你 4. 你出现的频率有多持续 随时间积累的： - 特定类型专业知识的声誉 - 信任你判断力的受众 - 不需要主动追求的入站机会 ## 第一步：选择你能接受的最窄细分领域 个人品牌建设中最常见的失败模式是过于宽泛。"营销专家。" "商业顾问。" "科技企业家。" 在人人都有这些标签的世界里，这些都是毫无意义的标签。 你定位越窄，就越快建立声誉。 用以下过滤条件测试你的细分领域： - **足够具体以便被搜索到。** 有人能在Google上搜索你的细分领域并找到围绕它的真实社区吗？ - **足够具体以便被推荐。** 如果有人遇到与你完全相同问题的人，他们会第一个想到你吗？ - **足够宽泛以产生2年以上的内容。** 使用像[Semrush](/recommends/semrush)这样的关键词工具来检查你的细分领域是否被搜索。 ## 第二步：选择一个主要渠道 试图同时无处不在，是一种保证在所有地方都平庸的方式。一开始，选择一个渠道并深入。 - **书面内容（博客/通讯）：** 最适合分析性、从业者受众。通过SEO随时间复利增长。 - **LinkedIn：** 最适合B2B和专业受众。 - **YouTube/视频：** 最适合受益于视觉演示的主题。 - **X/Twitter：** 最适合能传播的想法。 ## 第三步：找到你的观点 没有观点的内容就是噪音。让个人品牌被引用、推荐和寻求的，是独特的视角——一种关于世界如何运作的观点，由真实经验提供信息。 强有力的观点具有以下属性： - 基于你真正做过的事情，而不仅仅是读到的 - 挑战你受众至少一个传统假设 - 足够具体，以至于有些人会不同意 ## 第四步：建立自有受众 你在其上建设的每个平台都可能改变算法、封禁账户或关闭。你真正拥有的唯一分发渠道是你的电子邮件列表。 从第一天起就开始建立它。对于电子邮件，我使用[ConvertKit](/recommends/convertkit)——专为创作者通讯而设计。 从个人品牌扩大电子邮件列表的最快方式： 1. **创建一个真正有用的潜在客户磁铁。** 一份清单、模板或简短指南，解决受众面临的特定问题。 2. **在每个内容页面的折叠线以上添加订阅选项。** 3. **撰写3封欢迎邮件序列。** 4. **在每件内容中提及列表。** ## 第五步：持续发布——复利数学 如果你每周发布一篇长篇内容： - **第1-8周：** 几乎没有人阅读。这是正常的。 - **第3-4个月：** 一些内容开始获得有机流量。 - **第6-9个月：** 搜索流量复利增长。入站询问开始出现。 - **第2年：** 你有100件内容。你的名字出现在搜索结果和AI答案中。 我的规则：在评估是否有效之前，先坚持6个月。 ## 我对视觉品牌的思考 最小可行视觉品牌： - 脸部清晰可见的专业头像照片 - 所有平台上统一的头像照片 - 一个简单的网站，有清晰的标语和电子邮件订阅选项 [Canva](/recommends/canva)适合社交媒体图形和简单设计。 ## 常见错误 1. **试图吸引所有人。** 如果你为"企业家"写作，你就是在为任何人都不写。 2. **发布没有分发。** 写一篇文章然后等待流量不是策略。 3. **每季度改变焦点。** 个人品牌动力的最大杀手。 4. **衡量虚荣指标。** 衡量你的列表大小和转化率，而不是你的点赞数。 5. **等到"足够专业"。** 你不需要成为该主题的世界权威。 ## 个人品牌工具栈 - **电子邮件平台：** [ConvertKit](/recommends/convertkit) - **SEO研究：** [Semrush](/recommends/semrush) - **内容创作：** [Claude](/recommends/claude) - **设计：** [Canva](/recommends/canva) ## 常见问题 ### 建立个人品牌需要多长时间？ 实际上，在获得有意义的入站机会之前，需要12-24个月的持续发布。 ### 我需要在每个社交平台上都有存在吗？ 不需要。在一个平台上的深度胜过在五个平台上的浅层存在。 ### 内容质量和发布频率哪个更重要？ 两者都重要，但程度不同。质量设置下限。频率决定你是否获得改进所需的重复练习。 ### 我应该使用真实姓名还是品牌名称？ 使用你的真实姓名。与真实人物相关联的个人品牌在算法变化中存活得更好。 ### 如何从个人品牌中获利？ 四条可靠途径：(1) 课程/数字产品，(2) 咨询和顾问服务，(3) 联盟合作，以及(4) 赞助内容。 --- **相关文章：** [如何在建立之前验证商业想法](/how-to-validate-a-business-idea/) · [如何从零建立电子邮件列表](/how-to-build-an-email-list/) · [如何将通讯货币化](/how-to-monetize-a-newsletter/) --- ## 如何为AI代理添加记忆：生产环境中的状态持久化模式 Source: https://alejandrorioja.com/zh/how-to-add-memory-to-an-ai-agent/ Published: 2026-06-30 Tags: AI Agents TL;DR: 无状态代理——那种Worker退出时忘记一切的代理——适合一次性任务。一旦代理需要记住昨天发生的事情、识别回头客或基于之前的输出继续工作，就需要记忆。有三种模式：工作记忆（运行中的上下文，在KV中存活于一次运行期间）、情节记忆（发生了什么以及何时发生，一个可查询的日志）和语义记忆（你知道什么，通过向量搜索或结构化数据检索）。将正确的模式与正确的工作配对。 ## 目录 _2026年6月更新。_ **TL;DR:** 无状态代理——那种Worker退出时忘记一切的代理——适合一次性任务。一旦代理需要记住昨天发生的事情、识别回头客或基于之前的输出继续工作，就需要记忆。有三种模式：工作记忆（运行中的上下文，在KV中存活于一次运行期间）、情节记忆（发生了什么以及何时发生，一个可查询的日志）和语义记忆（你知道什么，通过向量搜索或结构化数据检索）。将正确的模式与正确的工作配对。 **[运营者的观点]** 我不止一次撞上无状态的墙。社交回复代理不断向它已经交谈过20次的客户自我介绍。每日简报代理连续四天标记同一个问题，因为它不记得昨天已经标记过了。添加正确类型的记忆解决了这两个问题。这就是我使用的方法。 ## 为什么无状态代理持续失败 无状态代理每次运行只从你明确传递的内容开始：系统提示、用户消息以及在调用时获取的新数据。它不了解之前的运行、之前的用户或之前的决策。 对于一次性分类任务——读取评论、返回类别——无状态是正确的。它快速、便宜且可预测。 一旦你需要连续性，故障面就会出现： - 面向客户的代理不认识客户的历史 - 内容代理推荐了它上周已经推荐过的文章 - 审核代理不断重新升级一个已解决的案例 - 每日简报无限期显示同一个过时警报 所有这些都是同一问题的症状：代理无法跨运行传递上下文。 ## 三种记忆类型 我在生产中发现有用的框架： 1. **工作记忆** — 代理在单次运行期间_当前_知道的内容。在调用生命周期内保存在KV或内存中。 2. **情节记忆** — 发生了什么以及何时发生。代理在每次运行开始时读取的结构化日志，以便定位自己。 3. **语义记忆** — 它对世界、客户或知识库的了解。在相关时通过结构化查询或向量搜索检索。 你不总是需要全部三种。我运行的大多数代理需要工作记忆+情节记忆。语义记忆最难构建，只有当知识库太大无法放入上下文窗口时才值得投入。 ## 工作记忆：运行中的上下文 工作记忆是在一次代理运行期间存在的状态。最简单的形式是函数作用域中的变量。更有趣的形式是共享KV键，同一次运行中的子任务读写它。 我的社交回复代理使用工作记忆在处理一个队列消息中的一批评论时积累上下文。它在开始时从KV读取每个客户的最近对话历史，在处理过程中添加新上下文，并在结束时写回。 ```typescript // workers/social-reply.ts async function processComment( comment: SocialCommentEvent, env: Env ): Promise { // 从KV加载该客户的最近历史（工作记忆） const historyKey = `customer:${comment.userId}:history`; const rawHistory = await env.AGENT_KV.get(historyKey); const history: ConversationTurn[] = rawHistory ? JSON.parse(rawHistory) : []; // 根据历史构建上下文感知的系统提示 const systemPrompt = buildSystemPrompt(history); const response = await anthropic.messages.create({ model: "claude-opus-4-8", max_tokens: 512, system: systemPrompt, messages: [{ role: "user", content: comment.text }], }); const reply = response.content[0].type === "text" ? response.content[0].text : ""; // 更新历史——保留最后10轮，TTL 30天 const updatedHistory: ConversationTurn[] = [ ...history.slice(-9), { role: "assistant", content: reply, timestamp: comment.timestamp }, ]; await env.AGENT_KV.put(historyKey, JSON.stringify(updatedHistory), { expirationTtl: 60 * 60 * 24 * 30, }); await postReply(comment, reply, env); } ``` 注意两点。历史限制为10轮——使用滑动窗口，不要让它无限增长。TTL为30天：如果客户沉默一个月，历史过期，代理重新开始。两者都是有意为之的。 ## 情节记忆：发生了什么以及何时 情节记忆是代理的日志。代理在每次新运行开始时读取的过去运行的结构化记录，以避免重复。 我的每日简报代理每天都显示相同的过时警报，因为每次运行都不知道之前已经标记了什么。解决方案：代理在生成简报之前读取的过去警报的结构化日志。 ```typescript // workers/daily-brief.ts interface AlertLogEntry { id: string; surfacedAt: string; // ISO时间戳 resolvedAt?: string; summary: string; } async function buildDailyBrief(env: Env): Promise { const [emails, calendar, tasks] = await Promise.all([ fetchOvernightEmails(env), fetchTodayCalendar(env), fetchTopTasks(env), ]); // 加载情节记忆：已经标记过什么 const rawLog = await env.AGENT_KV.get("brief:alert-log"); const alertLog: AlertLogEntry[] = rawLog ? JSON.parse(rawLog) : []; // 只过滤近期未解决的警报 const sevenDaysAgo = new Date( Date.now() - 7 * 24 * 60 * 60 * 1000 ).toISOString(); const recentAlerts = alertLog.filter( (e) => e.surfacedAt > sevenDaysAgo && !e.resolvedAt ); const brief = await synthesizeBrief( { emails, calendar, tasks, recentAlerts }, env ); // 用本次运行标记的新警报更新日志 const newAlerts: AlertLogEntry[] = brief.newAlerts.map((a) => ({ id: crypto.randomUUID(), surfacedAt: new Date().toISOString(), summary: a, })); const updatedLog = [...alertLog, ...newAlerts].slice(-100); // 保留最后100条 await env.AGENT_KV.put("brief:alert-log", JSON.stringify(updatedLog)); await writeToWorkspace(brief.content, env); } ``` 代理现在知道它已经说过什么了。重复警报不会出现在简报中，直到底层问题改变。当我将警报标记为已解决时，它从活动列表中消失。 这个模式可以推广：任何产生决策、标记或建议的代理都受益于日志。日志便宜（KV中的几KB），回报高（不再有冗余输出）。 ## 语义记忆：你知道什么 语义记忆是知识库。它在查询时回答"你对X了解什么？"，而不是预先将所有内容塞入系统提示。 最简单的形式是KV或数据库中的结构化查找。我的Pickleland预订代理在起草确认之前查找客户档案和场地偏好： ```typescript // workers/booking-agent.ts interface CustomerProfile { userId: string; preferredCourts: string[]; experienceLevel: "beginner" | "intermediate" | "advanced"; specialNotes: string; } async function draftConfirmation( booking: BookingEvent, env: Env ): Promise { // 从KV获取客户档案（语义记忆——事实性知识） const profileKey = `customer:${booking.userId}:profile`; const rawProfile = await env.AGENT_KV.get(profileKey); const profile: CustomerProfile | null = rawProfile ? JSON.parse(rawProfile) : null; const systemPrompt = profile ? `你起草个性化预订确认。该客户偏好${profile.preferredCourts.join("、")}，是${profile.experienceLevel}级别的球员。${profile.specialNotes}` : "你为匹克球场馆起草预订确认。"; const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 256, system: systemPrompt, messages: [ { role: "user", content: `为以下内容起草确认：${JSON.stringify(booking)}`, }, ], }); return response.content[0].type === "text" ? response.content[0].text : ""; } ``` 对于更大的知识库——产品文档、支持知识库、任何太大无法放入上下文窗口的内容——你需要向量存储。工作流程是：嵌入查询，检索最相关的k个片段，将它们注入上下文。如果你已经在Workers上，Cloudflare Vectorize可以原生处理这个问题。对于更大的索引，我使用了Upstash Vector。选择取决于规模，而不是原则。 关于语义记忆的诚实说明：它是三者中最难构建和维护的。索引需要保持最新。检索质量参差不齐。从结构化查找开始——KV、D1中的表——只有在结构化方法无法覆盖所需知识面时才考虑向量搜索。 ## 记忆决策框架 在向代理添加任何记忆之前，回答三个问题： 1. **代理需要跨运行记忆吗？** 如果每次调用都是真正独立的——翻译、分类、一次性生成——跳过记忆。无状态更简单、更便宜。 2. **代理是否在重复自己或对自己的历史视而不见？** 如果是，先添加情节记忆。这是最省力的修复，涵盖了大多数"代理一直做X"的投诉。 3. **代理是否在不应该的时候将每个用户或实体一视同仁？** 如果是，添加工作记忆（客户历史、用户档案）或语义记忆（搜索或检索系统）。 我在实践中最常见的错误：有人向一个代理添加了庞大的知识库（语义记忆），而该代理实际上因为没有情节记忆而失败——没有它已做过什么的日志。复杂性与问题不匹配。 ## 我在生产中实际使用的内容 在30多个代理中： - **所有代理**至少有工作记忆——运行内的某种状态形式，即使只是上下文窗口本身。 - **大约一半**有情节记忆——过去运行、决策或标记的日志。这几乎总是值得添加的。 - **三四个**有真正的语义记忆，由向量存储支持。这些是针对大型动态知识库回答问题的代理。 Cloudflare KV是我用于工作记忆和情节记忆的默认存储。它快速、便宜，并且原生集成到Workers中——不需要额外的客户端，不需要单独的凭据。限制：KV最终一致，不适合高频写入。对于每秒写入状态多次的代理，我改用Durable Objects或D1数据库。 对于向量支持的语义记忆，我对小到中等索引（少于~10万个向量）使用Cloudflare Vectorize，对更大的内容使用Upstash Vector。两者都有一流的JavaScript客户端。 ## 运营者的结论 只有当无状态行为导致真正的问题时才向代理添加记忆——重复输出、客户历史盲点、对过去决策的忽视。然后选择正确的层次：工作记忆用于运行中的上下文，情节记忆用于历史发生的事情，语义记忆用于你知道的内容。如果不确定，从情节记忆开始——它以最少的复杂性修复最常见的故障模式。在用尽结构化查找之前不要使用向量数据库。最好的记忆系统是让代理正确运行的最简单的系统。 --- **相关：** [我用来运行30多个生产代理的代理栈](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) · [事件触发代理与定时代理](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) · [我如何衡量AI代理是否真正有效](/how-i-measure-whether-an-ai-agent-is-actually-working/) **需要帮助为您的用例设计代理记忆吗？** [联系我](/contact/) — 我为运营团队设计生产代理系统。 --- ## 如何从零开始建立邮件列表：2026年完整指南 Source: https://alejandrorioja.com/zh/how-to-build-an-email-list/ Published: 2026-06-27 Tags: Entrepreneurship, Growth TL;DR: 邮件列表是你真正拥有的唯一分发渠道。从能解决具体问题的潜在客户磁铁开始，将订阅表单放在首屏，并在有人订阅时立即发送3封欢迎邮件。质量永远胜过数量——1,000名活跃订阅者胜过10,000名冷淡的订阅者。 ## 目录 _2026年6月更新。_ **摘要：** 邮件列表是你真正拥有的唯一分发渠道。从能解决具体问题的潜在客户磁铁开始，将订阅表单放在首屏，并在有人订阅时立即发送3封欢迎邮件。质量永远胜过数量——1,000名活跃订阅者胜过10,000名冷淡的订阅者。 **[运营者观点]** 我参与过的每一个建立了持久收入引擎的业务都有一个共同点：一个列表。不是粉丝。不是曝光量。而是一份主动要求听你说话的人的名单。以下是如何从零开始建立一个邮件列表的详细方法。 ## 你真正拥有的唯一资产 任何其他分发渠道都可能消失。谷歌算法更新会抹去搜索排名。平台政策变更会杀死你在Facebook上的触达。广告账户会在没有警告的情况下被暂停。 你的邮件列表是例外。当你拥有邮件列表时，你控制着投递。没有算法决定谁能看到你的内容。没有平台在你每次想接触受众时收取通行费。 这就是为什么我会把建立邮件列表作为告诉每个创始人的第一件事——在SEO之前，在付费广告之前，在社交媒体之前。 ## 第一步：选择邮件平台 在收集任何地址之前，你需要一个存储和发送的平台。不要使用Gmail。不要使用你的商业邮件。使用具有适当合规性和投递基础设施的专用工具。 我在2026年的两个选择： **[ConvertKit](/recommends/convertkit)** — 最适合创作者和独立运营者。订阅者标签和细分系统真的非常出色。1,000名订阅者以内免费。 **[Moosend](/recommends/moosend)** — 最适合想要自动化但不想付ConvertKit价格的小企业。稳固的拖放构建器和一贯良好的投递率。 如果你从零开始，两者都有免费计划，可以覆盖你的前几百名订阅者。在发送任何内容之前，在你的域名上设置DKIM、SPF和DMARC身份验证——自2024年起，Gmail和Yahoo对批量发件人有此要求，这能从第一天起保护你的发件人声誉。 ## 第二步：创建值得下载的潜在客户磁铁 潜在客户磁铁是你提供的、用于换取某人电子邮件地址的东西。大多数人犯的错误：提供一些通用的东西。 "订阅我们的通讯"不是潜在客户磁铁。这是一个没有任何回报的信任请求。 你的潜在客户磁铁需要为特定的人解决特定的问题。越具体，转化效果越好。 **2026年有效的格式：** 1. **速查表和模板** — 别人可以立即使用的单页资源。越接近即用型越好。 2. **迷你课程（3-5封邮件）** — 教授一项技能的短序列，自动发送。同时建立列表和关系。 3. **计算器或电子表格** — 高感知价值。市场规模测算工具、定价模型、预算模板。这些能转化是因为节省了真实的工作量。 4. **独家数据或研究** — 原创调查结果或基准报告。难以复制，可信度高。 5. **素材文件** — 真实案例的集合（广告文案、邮件主题行、落地页标题）。从业者愿意为此付费。 6. **网络研讨会或培训回放** — 将现有录音重新用作订阅礼品。设置只需20分钟。 一个不可谈判的条件：潜在客户磁铁必须与你的邮件内容直接相关。一个为B2B SaaS通讯获取订阅者的Facebook广告模板，是一场等待爆发的列表质量灾难。 ## 第三步：将订阅表单放在有效的位置 表单位置对转化的驱动力超过文案本身。将订阅表单放在注意力已经存在的地方： 1. **主页的首屏之上** — 不是页脚。不是侧边栏。首屏之上，并清楚描述他们将得到什么。 2. **每篇博客文章的末尾** — 读完整篇文章的人已经预先合格了。在他们仍然投入时抓住他们。 3. **退出意图弹窗** — 当访客准备关闭标签页时触发。有争议，但有效。 4. **专用落地页** — 没有导航的独立页面。这是你发送付费流量的地方。 5. **内容升级** — 增强特定文章的资源。TAM/SAM/SOM指南中的市场规模电子表格的转化率比同一页面上的通用内容高出3-5倍。 文案建议：从结果而非格式开始。"获取5页指南"不如"像风投一样了解你的市场规模"有力。 ## 第四步：撰写欢迎序列 当有人订阅的那一刻，你获得了他们最大的注意力。不要用沉默来浪费它。 至少发送3封邮件： **邮件1（立即）：** 发送潜在客户磁铁。确认他们注册的内容。设定对未来内容的期望。 **邮件2（第2天）：** 你最好的一篇内容——一篇文章、案例研究或框架。不要推销。只是证明订阅是值得的。 **邮件3（第4-5天）：** 你的起源故事和观点。你为什么关心这个话题？你相信什么是你所在领域大多数人不相信的？这里是建立信任的地方。 之后，保持一致的节奏。每周一次是标准。如果你无法保持每周的质量，每两周一次也有效。最糟糕的错误是在启动时发一封邮件，然后消失三个月。 ## 第五步：为你的订阅页面引流 没有流量的表单不会转化任何人。最可靠的增长渠道： **自然搜索** — 针对潜在客户磁铁解决的问题排名的博客文章。搜索你的主题并找到你文章的人已经预先合格了。这是成本最低、留存率最高的渠道。 **社交媒体（自然流量）** — LinkedIn帖子、Twitter/X推文串或短视频，将人们引导到你的订阅页面。每个帖子都应该是预告，而不是完整的故事。 **通讯互换和联合推广** — 在相邻领域找到通讯并互相提及。你推广他们的列表；他们推广你的。这是从500名增长到5,000名订阅者最快的方式之一。 **播客嘉宾出现** — 被低估的渠道。发送给2,000名细分听众的30分钟节目可以增加50-100名深度感兴趣的订阅者，他们更有可能打开你发送的每封邮件。 **付费广告** — 不要为未经验证的优惠投放广告。首先让你的订阅页面实现自然转化，然后用付费流量扩大规模。 ## 第六步：保持列表清洁 邮件列表会退化。人们会更换工作、更换邮件地址、改变兴趣。如果你不清理你的列表，投递率就会下降——这意味着即使是活跃的订阅者也会停止看到你的邮件。 最佳实践： - **每6个月进行一次重新激活活动** — 给90天以上未打开邮件的所有人发邮件。给他们一个留下来的理由。如果他们不参与，就删除他们。 - **立即删除硬退信** — 高退信率告诉邮件服务提供商你的列表很脏。 - **按参与度细分** — 分别标记活跃和冷淡的订阅者。只向活跃细分发送时间敏感的活动。 删除订阅者感觉像是失去了什么。实际上，这保护了你想要保留的订阅者。 ## 诚实的注意事项 **建立需要时间。** 仅靠自然方法从零开始，预计需要3-6个月才能达到1,000名订阅者。任何承诺几周内达到数千的人都在出售虚荣指标或你不想要的冷淡、不活跃的联系人。 **细分市场很重要。** B2B受众对数据和案例研究有反应。消费者受众对折扣和娱乐有反应。潜在客户磁铁和内容节奏必须与受众匹配。 **潜在客户磁铁会过时。** 今天转化效果好的东西可能在18个月后随着竞争对手复制格式而过时。计划每年更新你的潜在客户磁铁。 ## 现实基准 | 指标 | 行业平均 | 良好 | |--------|-----------------|------| | 弹窗订阅率 | 2-4% | 5-8% | | 落地页订阅率 | 20-30% | 40-60% | | 欢迎邮件打开率 | 50-60% | 70%+ | | 持续打开率 | 20-25% | 35-45% | | 点击率 | 2-3% | 5-10% | 前90天不要优化这些数字。建立基础设施，运行潜在客户磁铁，持续发送。然后迭代。 ## 2026年6月更新 **AI生成的潜在客户磁铁** — Claude等工具可以在几分钟内起草一份10页的PDF指南、素材文件或模板。创建高质量潜在客户磁铁的障碍接近于零。现在的差异化因素是承诺的具体性和与受众的相关性。 **Gmail和Yahoo身份验证** — 自2024年起，每天向1,000多个地址发送邮件的发件人需要DKIM、SPF和DMARC。[ConvertKit](/recommends/convertkit)和[Moosend](/recommends/moosend)都会在入职期间指导你完成设置。在需要之前就做好。 **AI搜索流量** — 一个具有清晰摘要和对搜索查询直接回答的结构良好的订阅页面可以在ChatGPT、Perplexity和谷歌AI概述中出现。我见过没有任何SEO工作的订阅落地页从AI搜索获得持续流量——因为该页面直接回答了一个具体问题。 ## 常见问题 **我需要多少订阅者才能变现？** 没有通用数字。我见过在高意向细分市场中拥有500名深度参与订阅者的通讯胜过拥有20,000个通用联系人的列表。问题是你的订阅者是否有问题，以及他们是否信任你来解决它。 **我应该购买邮件列表吗？** 不应该。购买的列表参与度极差，会让你被标记为垃圾邮件，并可能暂停你的账户。没有捷径。 **应该多频繁发邮件？** 在保持质量的前提下尽可能频繁。每周一次让你保持在受众脑海中。最大的错误是沉默几个月然后带着推销内容回来。 **双重确认还是单次确认？** 大多数情况下双重确认。确认减少了列表规模，但显著提高了参与度和投递率。例外情况是当你从特定来源驱动高意向、经过验证的流量时。 **初学者最好的邮件平台是什么？** 为建立个人品牌或内容业务的创作者推荐[ConvertKit](/recommends/convertkit)。为想要实惠和自动化的小企业推荐[Moosend](/recommends/moosend)。两者都远优于尝试使用Gmail。 ## 下一步该去哪里 邮件列表不是孤立存在的。你表现最好的文章应该有内容升级。你的邮件应该链接回深度指南。你的潜在客户磁铁应该解决你流量最高的页面所针对的确切问题。 那个循环——流量→订阅→培育→信任→报价——是我参与过的每一个持久在线业务的基础。 如果你想讨论如何针对你的具体情况来构建这个系统，[联系页面](/contact)是开始的正确地方。 --- ## 如何将电子报变现：5种真正有效的收入模式 Source: https://alejandrorioja.com/zh/how-to-monetize-a-newsletter/ Published: 2026-06-25 Tags: Entrepreneurship, Growth TL;DR: 大多数电子报之所以无法变现，是因为针对其列表规模追求了错误的模式。五种真正有效的模式：付费订阅（最适合细分权威定位）、赞助商合作（订阅者超过5000人后最有效）、联盟推荐（任何规模下阻力最小）、课程与产品漏斗（收入上限最高）以及服务增销（获得真实收入最快的途径）。从一种模式开始，仅当第一种奏效时才添加第二种。 ## Table of contents _2026年6月更新。_ **TL;DR:** 大多数电子报之所以无法变现，是因为针对其列表规模追求了错误的模式。五种真正有效的模式：付费订阅（最适合细分权威定位）、赞助商合作（订阅者超过5000人后最有效）、联盟推荐（任何规模下阻力最小）、课程与产品漏斗（收入上限最高）以及服务增销（获得真实收入最快的途径）。从一种模式开始，仅当第一种奏效时才添加第二种。 **[运营者视角]** 早在人们流行将其称为"电子报业务"之前，我就已经在运营电子报了。如实讲述这段历程：我曾试图同时做所有事情，几乎一无所获；后来专注于一种模式，才开始盈利。以下是我的经验总结，以及我在合作运营者身上持续看到的有效做法。 ## 为什么大多数电子报始终无法赚到一分钱 变现问题通常是排序问题。人们启动电子报，缓慢积累订阅者，然后试图一次性添加所有收入来源——这里一个付费层级，那里一个赞助商位，每期都塞进联盟链接。结果是一份像购物中心一样的电子报：处处都在销售，没有什么让人感觉真实，读者因此疏离。 持续盈利的电子报先做好一件事。它们证明某一模式对其特定受众有效，然后才——也只有在那时——叠加第二种模式。 邮件列表规模也决定了哪些模式可行。500名订阅者的列表是寻找赞助商的错误工具；而拥有50,000名订阅者的列表若只投放联盟链接，则白白浪费了大量潜在收入。模式必须与列表相匹配。 ## 模式一：付费订阅 **最适合：** 拥有明确专业或高度感兴趣受众的细分权威电子报。 付费订阅是电子报变现最纯粹的形式：读者直接为内容付费。Beehiiv和Substack等平台让免费列表轻松添加付费功能。 成功的关键： - 特定的高价值细分领域，信息稀缺或能节省时间（金融分析、行业情报、运营层面的战术） - 对"付费订阅者能获得什么免费订阅者得不到的东西"有清晰的答案 - 真正有价值的免费层级——不是稀释版，而是付费层级思路的预览 失败的根源： - 紧迫性低的通用话题（"营销技巧"、"个人成长"） - 在获得免费订阅者持续阅读内容的证据之前就推出付费层级 现实收入：每位订阅者每月5–20美元。以2000人列表5%的转化率计算，即100位付费订阅者，每月10美元，折合1000美元MRR。规模不大，但切实存在，且会持续积累。 ## 模式二：赞助商合作与原生广告 **最适合：** 拥有5000+订阅者且受众画像清晰的电子报。 赞助是最显眼的模式——将某期广告位出售给与受众相关的品牌。效果好时非常可观：针对细分B2B或高收入受众，每千人费用（CPM）通常达100–500+美元。 诚实的约束：赞助商需要规模和精准度。"我有1000个对营销感兴趣的订阅者"无法成交；而"我有6000名订阅者，均为10–500人规模公司的市场总监，开信率52%"则可以。 实现路径： 1. 以人口统计学语言而非兴趣标签**定义受众** 2. 在接触赞助商前，先达到5000订阅者的**最低可信门槛** 3. **证明互动质量**——开信率超过40%才是真正的差异化指标 4. **制作媒体资料包**——包含订阅人数、开信率、受众画像和赞助方案的单页PDF 5. **从被动获客开始**——先在赞助商平台上注册，再建立主动销售流程 CPM测算：若列表开信率为45%，每期以200美元CPM出售一个赞助位，5000人列表每期可产生1000美元。每月四期即4000美元；两个赞助位则达8000美元。数学逻辑成立——在一定规模之后。 ## 模式三：联盟推荐 **最适合：** 任何规模的列表、任何你真实使用过工具和服务的细分领域。 联盟营销启动阻力最小：推荐你实际使用的产品，读者点击，你从购买中获得佣金。无需管理赞助关系，无需构建产品，无需维护付费层级。 核心制约是信任。联盟推荐只有在建议真正有用且来源可信时才会转化。满是从未用过的产品的"精选"专区不仅表现不佳，甚至会损害列表信誉。 有效做法： - 推荐你自己在使用的工具（我的经验：邮件管理用[ConvertKit](/recommends/convertkit)，SEO和内容研究用[Semrush](/recommends/semrush)） - 情境化植入——在内容相关处自然提及工具，而非单独设置"本期赞助商"固定模块（读者会习惯性跳过） - 给出真实评价：喜欢什么、不喜欢什么，以及哪类人不适合 收入上限：联盟佣金因产品而异——SaaS工具通常按转化订阅者支付20–40%的持续佣金，复利效应明显。1000人列表中若2%的读者订阅了每月50美元的SaaS（佣金30%），每月可产生300美元的持续收入，随着新增订阅的留存持续增长。 ## 模式四：课程与数字产品漏斗 **最适合：** 在特定领域拥有教学权威的运营者。 电子报是漏斗顶端，课程或数字产品是转化节点。信任你、期期必读的读者，是购买你所教内容的付费产品的最高质量潜客。 这是即便列表规模不大也能实现最高收入上限的模式。一门497美元的课程，若向5000人列表中的2%销售，每次发布即可获得49,700美元。每年三次发布叠加列表增长，复利效应相当可观。 所需条件： - 特定领域的真实教学权威——不只是"我懂营销"，而是"我用这套具体的增长打法让三家B2B公司实现了增长" - 逐周展示权威的内容（不只是精选链接——而是你的原创框架和案例研究） - 经过充分预热的发布序列——不要向一个只接收内容的列表突然发出"购买我的课程"的陌生邮件 这是我在自己的工作中最依赖的模式。电子报建立信任，课程将信任转化为收入。 ## 模式五：服务增销 **最适合：** 早期阶段、运营者提供咨询、辅导或代执行服务的电子报。 这种模式是小规模列表实现真实收入最快的途径，也是最被低估的。电子报将你定位为专家；服务则是专家的实践。 若500人订阅了你关于增长营销的电子报，你每月发布一期展示你的思考，那500位读者中的1–2人会不定期"举手"，询问你是否提供咨询。如果你不提供，收入机会就白白流失了。 如何明确表达： - 在电子报页脚添加一行文字："每季度我与少数客户合作，专注于[具体成果]。如有意向，请直接回复此邮件。" - 在相关期次中提及客户成果（匿名处理）——不是炫耀，而是证明框架在实践中有效 - 有意保持接待能量有限——这里的稀缺不是刻意营造的，而是真实的；你的时间是有限的 收入现实：每月5000美元的一位咨询客户，加上一份200人的电子报，其经济效益优于50,000名订阅者通过零散联盟收入赚取的每人0.01美元。不要等到规模扩大才开始。 ## 如何选择正确的模式 决策框架： | 列表规模 | 最佳起步模式 | 添加第二种模式 | |---------|------------|-------------| | 0–1,000 | 服务增销 | 联盟推荐 | | 1,000–5,000 | 联盟 + 课程候补名单 | 付费订阅 | | 5,000–20,000 | 赞助商合作 | 课程发布 | | 20,000+ | 赞助商 + 课程 | 付费层级 | 有一条约束在任何规模下都不变：先专注于一种。模式分散会同时削弱所有模式的转化率。 ## 电子报运营者的工具栈 构建电子报业务，我使用并推荐的工具： - **邮件平台：** [ConvertKit](/recommends/convertkit) — 订阅者标签、细分和自动化序列，有效区分购买者与一般读者 - **SEO与话题研究：** [Semrush](/recommends/semrush) — 在写作前了解目标受众的搜索偏好 - **设计：** [Canva](/recommends/canva) — 媒体资料包、课程封面素材和社交内容，无需设计师 - **支付：** Stripe — 用于付费订阅层级或课程结账 ## 运营者的最终结论 2026年，电子报是你能建立的杠杆率最高的内容资产：电子邮件收件箱的注意力具有社交媒体无法比拟的稀缺性与价值。但只有当你选择了与列表规模相匹配的模式、以真实推荐和真正权威来执行，并抵制将所有变现方式一次性铺开的冲动时，这项资产才能真正转化为收入。 从当下最适合你现状的模式开始。当它稳定运作、持续积累成果之后，再添加下一种。 --- **相关阅读：** [如何在构建之前验证商业创意](/how-to-validate-a-business-idea/) · [增长营销策略指南](/growth-marketing-strategies-guide/) · [适合小企业的6大电子邮件营销服务](/6-best-email-marketing-services-for-small-business/) --- ## 如何构建你的第一个MCP服务器：实践指南 Source: https://alejandrorioja.com/zh/how-to-build-your-first-mcp-server/ Published: 2026-06-23 Tags: AI Agents TL;DR: MCP（模型上下文协议）是给Claude提供对外部工具和数据（数据库、文件、API）结构化访问的方式，而无需塞满上下文窗口。服务器比看起来简单：安装SDK，将工具定义为JSON schema，实现处理器，通过stdio连接。30分钟内就能让Claude调用你的自定义工具。 ## 目录 _2026年6月更新。_ **TL;DR：** MCP（模型上下文协议）是给[Claude](/recommends/claude)提供对外部工具和数据（数据库、文件、API）结构化访问的方式，而无需塞满上下文窗口。服务器比看起来简单：安装SDK，将工具定义为JSON schema，实现处理器，通过stdio连接。30分钟内就能让Claude调用你的自定义工具。 **[运营者视角]** 我定期将新工具接入我的智能体，MCP现在是干净实现这一点的标准路径。服务器一旦构建完成，每个支持MCP的客户端——Claude Desktop、Claude Code、任何使用Anthropic SDK的应用——都可以在不修改调用代码的情况下使用它。这就是价值所在：构建一次，随处复用。 ## MCP究竟是什么 **模型上下文协议**是一个开放协议，标准化了AI模型连接外部上下文和工具的方式。把它想象成AI集成的USB-C标准：在此之前，每个想让Claude读取数据库或调用API的应用都必须自己发明一套解决方案。有了它，你构建一个MCP服务器，任何兼容的主机都可以使用它。 MCP定义了服务器可以提供的三类内容： - **工具** — Claude可以调用的函数（读取文件、查询数据库、发送Slack消息） - **资源** — Claude可以读取的数据（文档、数据库行、文件树） - **提示词** — 主机可以注入的可复用提示词模板 对于大多数运营者用例，你在构建**工具服务器**。资源和提示词在基础工作运行后再处理。 架构是客户端-服务器模式，由客户端（Claude Desktop、Claude Code、你的自定义应用）控制一切。服务器是被动的——只是监听工具调用请求并返回结果。 ## 每个MCP服务器的三个组成部分 你构建的每个MCP服务器都有相同的结构： 1. **服务器对象** — 声明服务器的名称、版本和能力（工具、资源、提示词） 2. **工具定义** — 包含名称、描述和输入JSON schema的工具列表 3. **请求处理器** — Claude调用工具时运行的函数 就这些。开始时不需要数据库、HTTP栈或认证层。最小服务器不到30行TypeScript。 ## 前置条件（2分钟） - **Node.js 18+** — 用`node --version`检查 - **TypeScript 5+**（下面作为dev依赖包含） - 用于测试的MCP客户端 — Claude Desktop免费，是查看服务器运行最简单的方式 运行MCP服务器本身不需要Anthropic API密钥。API密钥在客户端（Claude Desktop）中，不在你的服务器中。 ## 第一步：设置项目（3分钟） ```bash mkdir my-mcp-server && cd my-mcp-server npm init -y npm install @modelcontextprotocol/sdk npm install -D typescript tsx @types/node ``` 添加到`package.json`： ```json { "type": "module", "scripts": { "build": "tsc", "dev": "tsx src/index.ts" } } ``` 创建`tsconfig.json`： ```json { "compilerOptions": { "target": "ES2022", "module": "Node16", "moduleResolution": "Node16", "outDir": "./build", "strict": true }, "include": ["src/**/*"] } ``` ## 第二步：编写最小服务器（5分钟） 创建`src/index.ts`： ```typescript import { Server } from "@modelcontextprotocol/sdk/server/index.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; import { CallToolRequestSchema, ListToolsRequestSchema, } from "@modelcontextprotocol/sdk/types.js"; const server = new Server( { name: "my-mcp-server", version: "1.0.0" }, { capabilities: { tools: {} } } ); // 声明此服务器提供的工具 server.setRequestHandler(ListToolsRequestSchema, async () => ({ tools: [ { name: "get_word_count", description: "统计文本块中的单词数。", inputSchema: { type: "object", properties: { text: { type: "string", description: "要统计单词的文本", }, }, required: ["text"], }, }, ], })); // 处理客户端的工具调用 server.setRequestHandler(CallToolRequestSchema, async (request) => { const { name, arguments: args } = request.params; if (name === "get_word_count") { const { text } = args as { text: string }; const count = text.trim().split(/\s+/).filter(Boolean).length; return { content: [{ type: "text", text: `单词数：${count}` }], }; } throw new Error(`未知工具：${name}`); }); // 通过stdio连接——这是Claude Desktop与服务器通信的方式 const transport = new StdioServerTransport(); await server.connect(transport); ``` 这就是完整的服务器。它注册一个工具（`get_word_count`）并实现它。结构才是关键。 ## 第三步：构建并在Claude Desktop中注册（5分钟） 构建TypeScript： ```bash npm run build ``` 在Claude Desktop的配置文件中注册它。 **macOS**：`~/Library/Application Support/Claude/claude_desktop_config.json` **Windows**：`%APPDATA%\Claude\claude_desktop_config.json` 如果文件不存在，创建它： ```json { "mcpServers": { "my-mcp-server": { "command": "node", "args": ["/my-mcp-server的绝对路径/build/index.js"] } } } ``` 使用绝对路径。保存后重启Claude Desktop。你会在消息输入栏看到锤子图标（🔨）——这意味着Claude已发现你的工具。 ## 第四步：构建一个有用的工具 词数统计是用于说明的。这里有个更有用的工具：从项目目录读取文件，这是我用于汇总代码库、changelog或配置文件的上下文注入智能体的方案。 ```typescript import { readFileSync, readdirSync } from "fs"; import { join, extname } from "path"; const ALLOWED_EXTENSIONS = [".md", ".txt", ".ts", ".json", ".yaml"]; const PROJECT_DIR = process.env.PROJECT_DIR ?? process.cwd(); ``` 逻辑是相同的：用精确的JSON schema定义工具，实现处理器，验证输入以防止路径遍历，并向客户端返回文本。 ## 我踩过的坑（让你不要再踩） **路径必须是绝对路径。** Claude Desktop配置中的相对路径不会按预期解析。始终使用完整路径`/home/user/...`。 **stdio意味着服务器中不能使用`console.log`。** Claude Desktop通过stdin/stdout与服务器通信。调试用的`console.log`会损坏JSON-RPC流。改用stderr记录日志： ```typescript process.stderr.write(`调试：${message}\n`); ``` **每次配置更改后重启Claude Desktop。** MCP服务器在启动时加载。编辑的配置文件在关闭并重新打开应用之前不会生效。 **工具描述就是产品。** Claude根据`description`字段决定是否调用你的工具。描述模糊意味着Claude不知道何时使用它。描述精确意味着Claude在正确时机使用它。在描述上花费比实现更多的时间。 ## 我如何在生产中使用MCP服务器 stdio模式非常适合Claude Desktop和Claude Code（本地）。对于生产智能体——[在Cloudflare Workers上运行的30个以上](/the-agent-stack-i-use-to-run-30-production-agents-no-python/)——我直接使用Anthropic SDK的tool-use API，因为我需要按步骤灵活路由到[Haiku还是Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet)。 我实际使用的模式： 1. **本地开发工具** — 为Claude Code提供项目特定工具的MCP服务器 2. **上下文注入** — 无需手动复制即可预加载相关文档的MCP服务器 3. **原型到API的桥梁** — 先构建MCP（迭代更快），然后将逻辑移植到SDK tool-use用于生产 ## 接下来构建什么 一旦服务器结构清晰，有用的工具就是那些访问Claude外部上下文的工具： - **数据库读取器** — 运行只读SQL查询并以JSON格式返回结果 - **Slack读取器** — 获取频道的最近N条消息 - **GitHub读取器** — 列出开放的PR，读取特定提交的文件 - **内部API封装器** — 使用内置认证头调用你自己的REST API ## 常见问题 ### 构建MCP服务器需要Anthropic API密钥吗？ 不需要。你的MCP服务器不调用Anthropic API。它只是响应客户端的工具调用请求。API密钥在客户端，不在服务器中。 ### 我的MCP服务器可以调用外部API吗？ 可以——处理器只是异步TypeScript代码。获取天气API、查询数据库、写入文件。服务器不关心处理器内部做什么。 ### stdio和HTTP传输有什么区别？ stdio用于本地服务器——与Claude Desktop或Claude Code在同一台机器上。HTTP with SSE用于可以部署为Web服务的远程服务器。从stdio开始；调试更简单。 ### Claude如何知道何时调用我的工具？ Claude根据工具的`description`字段和对话上下文做出决定。如果Claude持续忽略你的工具，请精炼描述。 --- ## 如何在构建之前验证商业创意 Source: https://alejandrorioja.com/zh/how-to-validate-a-business-idea/ Published: 2026-06-20 Tags: Entrepreneurship, Growth TL;DR: 大多数商业创意的失败不是因为执行不力，而是因为跳过了验证。最快的路径是：通过搜索需求和论坛证据确认问题确实存在，审查竞争对手以证明已有人在赚钱，构建尽可能小的烟雾测试，并在构建任何东西之前获得承诺——押金、候补名单注册或意向书。如果你无法让哪怕一个人做出承诺，那么这个创意还没准备好。 ## Table of contents _2026年6月更新。_ **TL;DR:** 大多数商业创意的失败不是因为执行不力，而是因为跳过了验证。最快的路径是：通过搜索需求和论坛证据确认问题确实存在，审查竞争对手以证明已有人在赚钱，构建尽可能小的烟雾测试，并在构建任何东西之前获得承诺——押金、候补名单注册或意向书。如果你无法让哪怕一个人做出承诺，那么这个创意还没准备好。 **[运营者视角]** 我在合作过的创始人和自己的项目中已经见过这种模式数十次：创意听起来很有说服力，创始人充满激情，执行也很扎实——然后他们在一片沉寂中发布了。不是因为他们构建了错误的东西，而是因为他们跳过了那个本可在花费六个月之前告诉他们的唯一步骤。以下是我使用和推荐的验证框架。 ## 为什么大多数验证努力会失败 明显的失败方式是完全不做验证——先构建，后提问。但更微妙的陷阱是验证剧场：进行调查、与朋友交谈、收集"好主意！"之类的模糊回应，并将其称为信号。 调查会说谎。人们总是很礼貌。在假设性情境中被问及"你会为此支付50美元吗？"时，答案几乎总是肯定的。唯一重要的信号是承诺：有人实际上给你钱、时间或书面意向书。 其他一切都是噪音消减，而非验证。 ## 第一步：确认问题确实大规模存在 在验证解决方案之前，请验证问题是真实的且有人在搜索。 **搜索需求是最快的代理指标。** 将问题输入Google。查看自动完成建议、"其他人也问"部分以及排名最高的页面。如果没有结果，就没有人在搜索——一个解决没人寻找的问题的企业会将所有精力花在教育而非转化上。 使用 [Semrush](/recommends/semrush) 等关键词工具检查实际的月搜索量。目标市场中每月有1,000–10,000次搜索的问题是可行的。每月20次搜索的问题是一个有分发问题的利基产品。 **论坛证据是一个额外的定性层。** 在Reddit、Quora、小众Facebook群组和Discord社区中搜索你的问题。人们是否在积极抱怨它？寻求解决方案？变通方法？真实的挫败感是金子——这意味着痛点足够强烈，能促使人们公开寻求帮助。 如果你找不到20个真实人描述该问题的论坛帖子，请保持怀疑。 ## 第二步：审查竞争对手——证明金钱已经存在 创始人的常见本能："没有竞争，所以我会主导市场。" 这几乎总是错误的。没有竞争通常意味着没有市场。竞争是客户存在并愿意付费的证明。 在Google上搜索你的解决方案类别。谁在排名？他们的落地页承诺了什么？他们收多少钱？阅读他们的推荐和评论——尤其是负面的。负面评论是产品路线图：它们精确地告诉你市场想要什么但没有得到什么。 如果你找到3–5家拥有真实产品和真实客户的成熟竞争对手，这是一个健康的迹象。如果找到零，在得出市场不存在的结论之前先深入挖掘——或将其视为红旗。 **需要回答的关键问题：** 1. 前3–5名玩家是谁？ 2. 他们收多少费用？ 3. 评论者在批评什么？ 4. 有没有我可以占据的定位空白？ ## 第三步：构建尽可能小的烟雾测试 一旦你知道问题存在且市场有钱，就构建测试*你的*版本是否获得牵引力所需的最小制品。 这不是完整的产品。这是一个信号捕获机制。 **选项A：带邮件捕获的落地页。** 描述问题和解决方案的单页网站，配有"加入候补名单"或"获取早期访问"的CTA。转化率告诉你定位是否引起共鸣。Webflow、Carrd甚至公开Notion页面等工具都很好用——不要过度设计。 **选项B：预售。** 用真实货币进行的实际结账流程。这是质量最高的信号。如果有人为尚不存在的东西付钱，他们相信这个解决方案。甚至可退款的押金也有效。 **选项C：礼宾MVP。** 在自动化之前手动完成。咨询而非SaaS。定制电子表格而非软件工具。手动策划的新闻通讯而非AI生成的。你用蛮力服务少数客户，准确了解他们重视什么，然后围绕这些构建产品。 ## 第四步：在构建之前获得承诺 这是将真正验证与一厢情愿分开的门槛。 在进行烟雾测试之前，定义"承诺"对你的创意意味着什么： - **SaaS / 软件：** 以折扣价格预售，或签署的意向书 - **内容 / 媒体：** 点击加入的邮件订阅者（而非仅仅是粉丝） - **服务 / 咨询：** 付费发现电话或签署的提案 - **实体产品：** Kickstarter押金或预订 如果你无法让至少一个人做出承诺——即使有折扣，即使有退款保证——那么创意还没准备好。这不是失败；这是系统在运作。它为你节省了数月的构建时间。 ## 第五步：在开始之前设定通过/失败阈值 陷阱是这样的：你运行烟雾测试，获得不温不火的结果，然后说服自己继续进行。"落地页文案不够好。""我推广不够。""它只需要更多时间。" 停下来。在运行测试之前，写下阈值： > "如果我在14天内以零付费广告获得50个候补名单注册，我就构建。如果没有达到50，我就不构建——要么调整定位，要么放弃这个创意。" 写下来。告诉朋友。如果可以的话公开它。然后遵守它。 数字是任意的；重要的是你提前做出决定，当数据冷漠地进来时不要移动球门柱。 ## 常见的验证错误 1. **询问人们是否会购买。** 出于礼貌，他们几乎总是说是。唯一重要的问题："你现在会买吗？" 2. **与朋友和家人验证。** 他们在为你加油。他们不是你的客户。 3. **解决自己的问题而不检查其他人是否也有。** 你的问题可能对你来说是独特的。检查论坛。 4. **将调查回应称为验证。** 调查可以产生想法。它无法验证需求。只有金钱或真实承诺才能做到。 5. **等待完美信息。** 验证是获取足够信号以采取下一步，而不是完全消除不确定性。 ## "前进"信号意味着什么 你在寻找以下的组合： 1. 核心问题关键词的月搜索量超过1,000次 2. 竞争活动——3家以上真实玩家收取真实费用 3. 至少20个论坛或社区帖子显示对该问题的积极挫败感 4. 定向流量上的烟雾测试转化率超过5% 5. 至少一个人做出承诺——付款、签署或押金——而无需你恳求 达到所有五个，你就有了可行的方向。达到两三个，你就有了值得提炼的信号。达到零，你需要一个根本不同的创意或受众。 ## 验证工具栈 我在这个过程中使用和推荐的工具： - **搜索需求：** [Semrush](/recommends/semrush)——关键词量、竞争分析和内容差距，一站汇集 - **论坛研究：** Reddit、Quora、小众Facebook群组、Discord社区 - **落地页：** Carrd（免费、快速）或Webflow获得更多设计控制 - **邮件捕获 / 候补名单：** Kit（ConvertKit）在验证时开始构建列表 - **付款：** Stripe——在构建产品之前直接链接到结账 - **分析：** 在烟雾测试页面上使用Google Analytics追踪真实行为 ## 运营者的结论 你能构建的最昂贵的东西是一个没人想要的产品。验证不是关于消除风险——而是在纸上快速失败，而不是在生产中缓慢失败。运行烟雾测试，获得承诺，在开始之前设定阈值，并尊重结果。如果信号在那里，你会知道。如果不在，你也会知道。 --- **相关：** [如何建立盈利业务](/how-to-build-profitable-business/) · [增长营销策略指南](/growth-marketing-strategies-guide/) · [如何成为创业者](/how-to-become-an-entrepreneur/) --- ## 使用 Claude API 进行提示缓存：在不更换模型的情况下降低输入成本 Source: https://alejandrorioja.com/zh/prompt-caching-cut-your-claude-costs-without-switching-models/ Published: 2026-06-18 Updated: 2026-06-18 Tags: AI Agents, Operations TL;DR: 提示缓存能将大型稳定输入（你的系统提示、工具定义、少样本示例）在重复请求时的成本降至正常输入定价的大约 10%。其机制是前缀匹配：在稳定内容的末尾放置一个 cache_control 标记，并将所有易变内容保留在它之后。摧毁缓存命中率的错误，就是让时间戳或 UUID 漂移进入前缀。 ## Table of contents _更新于 2026 年 6 月。_ **太长不看：** 提示缓存能将大型稳定输入（你的系统提示、工具定义、少样本示例）在重复请求时的成本降至正常输入定价的大约 10%。其机制是前缀匹配：在稳定内容的末尾放置一个 `cache_control` 标记，并将所有易变内容保留在它之后。摧毁缓存命中率的错误，就是让时间戳或 UUID 漂移进入前缀。 **【运营者视角】** 我在自己的咨询品牌和 Pickleland 上运行着 100 多个智能体。最大的开销项目并不是模型层级，而是我在每个请求上反复发送同一个 4,000 token 系统提示的频率。提示缓存在高频智能体上将这部分成本降到了几乎为零，而且完全不需要触碰模型或输出质量。下面就讲清楚它到底是如何工作的，以及陷阱在哪里。 ## 提示缓存究竟做了什么 每一次对 [Claude](/recommends/claude) API 的调用都会发送 token。在没有缓存的情况下，你请求中的每一个 token——系统提示、工具定义、少样本示例以及用户消息——都会按正常的输入费率计价。有了缓存后，这些 token 中的一个前缀会在第一次请求之后被存储在 Anthropic 的服务器上。在后续共享该精确前缀的请求中，你支付的是缓存*读取*价格，而不是从头重新处理它们。 成本差异是实实在在的： - **缓存写入：** 约为基础输入价格的 1.25 倍（5 分钟 TTL）或约 2 倍（1 小时 TTL） - **缓存读取：** 约为基础输入价格的 0.1 倍 - **盈亏平衡：** 5 分钟 TTL 下为 2 次请求，1 小时 TTL 下为 3 次请求 一旦越过盈亏平衡点——对于任何每天运行不止几次的智能体来说，这会很快发生——之后每一次额外的缓存命中，都意味着对这些 token 约 90% 的折扣。 ## 前缀匹配的不变量 这是其他一切都要遵循的唯一规则：**缓存键是对你渲染后提示的前缀匹配**。 Anthropic 的服务器会存储从你提示的开头一直到 `cache_control` 标记之间的渲染内容。要让下一次请求发生缓存命中，从提示开头到该标记之间的每一个 token 都必须完全一致——逐字节相同。 用于前缀匹配的渲染顺序是：tools → system → messages。因此你的 tools 数组会被最先哈希，然后是 system 块，最后是按顺序排列的 messages。 这在实践中意味着：稳定内容必须排在最前面。如果你的系统提示引用了任何动态内容——当前日期、用户 ID、请求追踪 ID——并且它出现在 `cache_control` 标记*之前*，那么缓存在每个请求上都会未命中，因为前缀一直在变。 ## 应该把缓存标记放在哪里 杠杆最高的目标是： **1. 你的系统提示** 系统提示通常是最大的稳定块。一段详细的智能体人设、一组行为规则、一套输出格式指令——所有这些在同一个智能体的每次调用中都是相同的。给它打上标记： ```typescript import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic(); const response = await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1024, system: [ { type: "text", text: `You are a content operations agent for alejandrorioja.com. Your job is to draft blog posts in Alejandro's voice: direct, practitioner, first-person, numbered lists, honest caveats. No hedging. No filler. Every section must earn its place. [... 2000 more tokens of stable instructions ...]`, cache_control: { type: "ephemeral" }, }, ], messages: [ { role: "user", content: "Draft a post about prompt caching.", }, ], }); ``` system 块上的 `cache_control: { type: "ephemeral" }` 告诉 Claude 缓存到该块为止（含该块）的所有内容。`messages` 数组是易变的——每个请求各不相同——并且停留在缓存边界之外。 **2. 工具定义** 如果你的智能体使用工具，那些定义可能相当可观。一个文档完善的工具 schema，包含描述、参数名和枚举值，每个工具可能达到 500–1,000 个 token。如果有 5 个工具，那就是多达 5,000 个 token，你每次调用都要付费重新处理它们： ```typescript const response = await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1024, tools: [ { name: "search_airtable", description: "Search the Airtable content queue...", input_schema: { type: "object", properties: { query: { type: "string" } } }, }, // ... more tools ... { name: "post_to_kit", description: "Schedule a broadcast via the Kit API...", input_schema: { /* ... */ }, // Mark the last tool to cache the entire tools array } as Anthropic.Tool & { cache_control: { type: "ephemeral" } }, ], system: "...", messages: [...], }); ``` 给数组中*最后一个*工具打标记。前缀匹配将从那一点起覆盖整个 tools 数组。 **3. messages 中的少样本示例** 如果你把静态的少样本示例作为 `messages` 数组中靠前的消息传入，那些也可以被缓存。把它们组织成前 N 条消息，并给最后一个示例轮次打标记： ```typescript const messages: Anthropic.MessageParam[] = [ { role: "user", content: [ { type: "text", text: "Here are examples of posts in my voice:\n\n[Example 1...]\n\n[Example 2...]", cache_control: { type: "ephemeral" }, } as Anthropic.TextBlockParam & { cache_control: { type: "ephemeral" } }, ], }, { role: "assistant", content: "Understood. I'll follow that voice.", }, // The actual user turn follows — this is volatile, no cache marker { role: "user", content: actualUserRequest, }, ]; ``` ## 不应该缓存什么（隐性失效因素） 这些是看起来稳定、实则不然的东西——它们会悄无声息地摧毁你的命中率。API 不会警告你。你只会看到每个请求上都出现 `cache_creation_input_tokens`，然后纳闷究竟为什么。 **系统提示中的时间戳。** 最常见的单一错误： ```typescript // This invalidates the cache on every request const system = `You are an agent. Current time: ${new Date().toISOString()}`; ``` 把时间戳移到它本该所在的用户消息里： ```typescript // Stable system prompt — cacheable const system = `You are an agent. Use the current time provided by the user.`; // Volatile user message — not cached const userMessage = `Current time: ${new Date().toISOString()}. Run the daily brief.`; ``` **随机 UUID 和追踪 ID。** 同样的问题。如果你为了记录日志而往 system 块里注入一个追踪 ID，那么每个请求都会得到一个全新的前缀。 **非确定性的 JSON 序列化。** 如果你把一个对象序列化进系统提示，而键的顺序无法保证，那么即使底层数据相同，渲染出来的字符串也可能不同。请用稳定的键顺序序列化，或者使用模板字符串。 **动态少样本选择。** 如果你根据当前查询来选择少样本示例并把它们放进被缓存的前缀里，那你就把那个“稳定”的前缀变成了依赖查询的。要么为缓存层固定使用一组示例，要么把动态示例移到未缓存的消息轮次里。 ## 验证你的缓存命中率 每个响应都包含用量元数据。检查它： ```typescript const response = await client.messages.create({ /* ... */ }); console.log({ inputTokens: response.usage.input_tokens, cacheRead: response.usage.cache_read_input_tokens, cacheWrite: response.usage.cache_creation_input_tokens, outputTokens: response.usage.output_tokens, }); ``` 在第一次请求时：`cache_creation_input_tokens` 会非零，`cache_read_input_tokens` 会是 0。那是写入。 在缓存命中时：`cache_read_input_tokens` 会非零，`cache_creation_input_tokens` 会是 0。那是读取。 如果你在每个请求上都看到 `cache_creation_input_tokens`，说明你的前缀在变。加一条日志语句，在每次调用前打印渲染后系统提示的前 200 个字符——一个漂移的时间戳会立刻跳出来。 ## 1 小时 TTL：何时值得付出额外的写入成本 默认 TTL 是 5 分钟。如果你的智能体运行频率很低——低于每 5 分钟一次——那么你将在大多数请求上支付缓存写入成本，却得不到读取。 ```typescript // Opt into a 1-hour TTL cache_control: { type: "ephemeral", ttl: "1h" } ``` 1 小时的写入成本约为基础输入价格的 2 倍，而非 1.25 倍。算一笔账：如果你每小时命中缓存 3 次或更多，那么 1 小时 TTL 能省钱。如果你的智能体每天只运行一次（比如我的每日简报），那么即使是 1 小时 TTL 也帮不上忙——你每次都在支付写入成本。在这种情况下，除非系统提示极其庞大，否则缓存带来的好处很有限。 我的每日简报智能体有一个 3,000 token 的系统提示，但每天只运行一次。缓存帮不上忙。我的新闻通讯智能体在起草过程中每个会话要运行几十次——缓存能省下相当可观的成本。 ## 预热：让第一次请求变便宜 如果你已知即将到来的流量高峰——一个批处理作业、一次 API 发布——你可以用一个低成本的虚拟请求来预热缓存： ```typescript // Pre-warm: write the cache at near-zero output cost await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1, // minimal output system: [{ type: "text", text: stableSystemPrompt, cache_control: { type: "ephemeral" } }], messages: [{ role: "user", content: "ping" }], }); // Now the real requests read from cache ``` 这主要在批处理场景中有用——当你同时启动许多并行请求，并希望每一个都命中一个已预热的缓存，而不是争相去写入它。 ## 智能体循环中的提示缓存 在多轮智能体循环中，对话历史在每一轮都会增长。缓存足够聪明，能处理这一点：它使用一个 20 块的回看窗口，在最近的 20 个内容块内寻找最长的匹配前缀。 实际含义是：把你的稳定内容（系统提示、工具定义）锚定在顶部。messages 数组末尾不断增长的对话历史不会破坏稳定块的前缀匹配——它们位于易变内容之前，而前缀匹配是从顶部开始的。 在实践中，我的智能体把轮次组织成这样： ``` System (cached) → Tools (cached) → Few-shot (cached) → Turn 1 → Turn 2 → ... → Current turn ``` 缓存覆盖到少样本标记为止的所有内容。它之后不断增长的轮次历史每次都会被重新处理，但这没关系——那些 token 是会话专属的，相对于稳定前缀来说很小。 ## 它在账单上是什么样子 拿一个高频智能体来说：每天 100 次调用，4,000 token 系统提示，Sonnet 定价。 不使用缓存： - 100 × 4,000 tokens × $3/1M = **每天 1.20 美元** 使用缓存（5 分钟 TTL，假设高峰期每小时 50 次调用）： - 每 5 分钟 1 次写入 × $3.75/1M × 4,000 tokens = 写入约每天 0.02 美元 - 每天约 98 次读取 × $0.30/1M × 4,000 tokens = **读取每天 0.12 美元** 那大约是对这些输入 token 的 90% 削减。当规模扩大时——每天 1,000 次调用——差距会进一步复合放大。而且这还是在任何模型路由节省之上的额外收益，参见 [Haiku 与 Sonnet 的算账](/ai-agent-cost-math-when-haiku-beats-sonnet)：缓存在每个层级都有效。 ## 运营者的结论 提示缓存是 Claude API 中最简单的成本优化：在你本就要写的内容块上多加一个字段。约束在于围绕前缀稳定性的自律——缓存标记之前不能有任何动态内容。如果你能让系统提示、工具和任何静态示例都不含易变内容，那么每次缓存命中你只需支付正常输入成本的约 10%。对于拥有大型稳定提示的高频智能体来说，这是一个比切换模型层级更大的杠杆。 --- **相关阅读：** [AI 智能体成本算账：Haiku 何时胜过 Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet/) · [事件触发型与定时型智能体](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) · [我真正用来经营业务的 5 个 AI 工具](/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/) --- ## Claude Fable 5 初体验：一位运营者的视角 Source: https://alejandrorioja.com/zh/claude-fable-5-first-impressions/ Published: 2026-06-12 Updated: 2026-06-12 Tags: AI Agents TL;DR: Fable 5 是 Anthropic 能力最强的模型，在高难度、长周期的智能体任务上表现尤其突出——但它并不是默认的升级选择。它每 token 的价格更高，使用了一种新的分词器，会让你的 token 数膨胀约 30%，运行着无法关闭的常驻 thinking，还可能在分类器层面拒绝请求。对于大多数工作负载，Opus 4.8 仍然是正确的选择。只有当任务真正困难时，才动用 Fable 5。 ## 目录 _2026 年 6 月更新。_ **TL;DR：** Fable 5 是 Anthropic 能力最强的模型，在高难度、长周期的智能体任务上表现尤其突出——但它并不是默认的升级选择。它每 token 的价格更高，使用了一种新的分词器，会让你的 token 数膨胀约 30%，运行着无法关闭的常驻 thinking，还可能在分类器层面拒绝请求。对于大多数工作负载，Opus 4.8 仍然是正确的选择。只有当任务真正困难时，才动用 Fable 5。 **【运营者视角】** 我在一个咨询品牌和一家匹克球场馆里运维着 30 多个生产级智能体，所以一个新的旗舰模型对我来说不是一个跑分——它是一笔开销，也是一次迁移。下面就讲讲我真正把 Fable 5 接入其中几个智能体时发生了什么变化，以及哪些地方我仍然保留着 Opus 4.8。 ## Fable 5 到底是什么 [Claude](/recommends/claude) Fable 5 是 Anthropic 大范围发布过的能力最强的模型。它瞄准的是难度光谱中最苛刻的那一端：深度推理和长周期智能体任务——也就是那些需要智能体在数十次工具调用之间始终守住整个计划、不让思路断线的运行。 它的 API 接口与 Opus 4.7/4.8 几乎完全一致，这让测试变得很容易。默认提供 100 万 token 的上下文窗口，每次请求最多可输出 128K token。如果你在近期的 Opus 系列上构建过任何东西，这种请求结构会让你倍感熟悉。差异藏在细节里，而细节正是钱和意外所在的地方。 提一个命名上的注意点，免得你搞混：**Mythos 5** 是同一个模型——同样的能力、同样的定价、同样的行为——只是仅通过 Anthropic 的 Project Glasswing 项目提供。如果你不在那个项目里，你想要的模型就是 `claude-fable-5`。下面所有内容对两者都适用。 ## 它真正变强的地方 我先把自己最难的智能体任务抛给了它：一个多步骤的研究与综合任务，要读一堆来源、交叉核对论断，并写出一份带引用的简报。这正是那种弱模型会漂移的活儿——大约十次工具调用之后，它们就记不清哪条论断来自哪个来源了。 Fable 5 守住了思路。综合更紧凑，引用始终牢牢挂在正确的论断上，而且它还抓出了两处来源之间的矛盾，这些是我那个 Opus 4.8 版本一直在悄悄"和稀泥"略过的。在长链条、结构化的推理上，它是实打实的进步——不是边际性的跑分提升。 这就是支持它的诚实理由。如果你的智能体的失败模式是"在最难的那 10% 上崩盘"，那么 Fable 5 能缩小那道差距。如果你的智能体只是在总结新闻邮件或起草社媒帖子，你根本感受不到差别——而且你还会为自己用不上的能力买单。 ## 没人提醒你的成本陷阱 这是一个如果你只是草草扫过发布说明就会被咬一口的点。Fable 5 搭载了一个**全新的分词器**，同样的内容分词后大约比 Opus 系列**多出 30% 的 token**。 再读一遍，因为它会和价格叠加放大。Fable 5 本来定价就在 Opus 这一档之上（每百万输入 token 10 美元，每百万输出 token 50 美元）。现在再在每条 prompt 和每次补全上叠加约 30% 的 token 膨胀。一个原封不动的工作负载——同样的 prompt、同样的输出——在迁移后可能花费明显更多，而你对智能体所做的事情还一个字都没改。 所以千万不要沿用你的旧数字。你的 `max_tokens` 设置、你的上下文窗口预算、你的每次运行成本估算——它们全都是在另一个分词器上测出来的。好消息是：当你传入 `model: "claude-fable-5"` 时，token 计数端点会返回**两种**分词器下的计数，所以你可以在动任何东西之前，先在你真实的 prompt 上测出这个差值。 ```bash # Measure the tokenizer delta on YOUR prompt before migrating. # The response includes input_tokens (new) AND input_tokens_prior_tokenizer (old). curl https://api.anthropic.com/v1/messages/count_tokens \ -H "x-api-key: $ANTHROPIC_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{ "model": "claude-fable-5", "messages": [{"role":"user","content":""}] }' ``` 我先在自己最重的那些 prompt 上跑了这个。差值并不均匀——它会因内容而异——但"预留约 30% 的额外量，再加上价格溢价"是正确的心智模型。 ## thinking 始终开启——而且你无法关闭它 在 Fable 5 上，自适应 thinking 始终在运行。相对于 Opus 系列唯一一个新的破坏性变更是：如果你发送一个显式的 `thinking: {type: "disabled"}`，你会收到一个 400。修复很简单——直接整个省略 `thinking` 参数即可——但如果你之前有为了便宜、快速的调用而显式禁用 thinking 的代码，那段代码现在会报错。 你也拿不回原始的思维链。Fable 5 会保护它：你会收到正常的 `thinking` 块，并且可以用 `display: "summarized"` 请求一份可读的摘要，但未经过滤的推理过程永远不会暴露出来。对大多数应用来说这无关紧要——需要可见性的话读摘要就行。真正要紧的地方是**多轮智能体**：当你在同一个模型上续接一段对话时，你必须把 thinking 块**原封不动地**传回去。丢掉它们或编辑它们，这一轮就会出错。如果你在构建智能体循环，请把 thinking 块当作你需要逐字向前携带的不透明 token。 ## 拒绝现在成了一个控制流问题 这是对你围绕模型编写代码的方式影响最大的变化。Fable 5 会对传入的请求运行安全分类器，主要针对研究型生物学和大部分网络安全相关内容。当一个请求被拒绝时，你会收到一个**成功的 HTTP 200**，带有 `stop_reason: "refusal"`——不是错误，也不是异常。`content` 数组可能为空。 如果你的代码在没有先检查 `stop_reason` 的情况下执行 `response.content[0].text`，那么在某个请求被拒绝的那一天，它就会崩溃。而且无害的相邻工作——合法的安全工具、生命科学任务——偶尔也会触发误报，所以这并不只是那些做可疑事情的人才会遇到的问题。 规则是：**基于 `stop_reason` 来分支，绝不要基于 `stop_details`。** ```typescript const res = await client.messages.create({ model: "claude-fable-5", max_tokens: 1024, messages, }); if (res.stop_reason === "refusal") { // classifiers declined — content is empty or partial. Don't read content[0]. await handleRefusal(res); } else { console.log(res.content[0].text); } ``` 在生产环境中，有一条更干净的路径：一个服务端的 `fallbacks` 参数（处于 beta 阶段），它会在同一次往返中自动把被拒绝的请求重试到 `claude-opus-4-8` 上，并应用类似抵扣额度的重新计价。如果你在无人值守地运行智能体，把它接上，这样一次误报式的拒绝就不会把整个运行带进死胡同。这正是我反复重新学到的关于智能体[在生产环境中不断失败](/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it/)的同一个教训：模型变聪明并不会消除你处理它边缘情况的需要——它只是把边缘情况挪了个位置。 ## 另外两个迁移细节 还有几件较小的事，它们花掉了我的时间，所以别让它们再花掉你的： - **没有 assistant 预填充。** 如果你之前是通过预填充最后一轮 assistant 回合来引导输出的，那种模式没了。改用结构化输出（`output_config.format`）或系统提示词指令。 - **必须接受 30 天数据保留。** Fable 5 在零数据保留下不可用。如果你出于合规原因处于 ZDR 状态，那么 Fable 5 就无从谈起，Opus 4.8 仍是你的上限。请在你规划迁移*之前*核实这一点，而不是之后。 ## 你到底该不该切换？ 下面是我和它共处一段时间之后的运营者判断。**Fable 5 并不是默认的"升级到最新模型"目标——Opus 4.8 才是。**这让人意外，但这才是正确的框架。Opus 4.8 相对于 4.7 只是一次模型 ID 的替换，没有新的破坏性变更，它更便宜，而且对于绝大多数智能体工作，它在输出质量上根本无法与之区分。 Fable 5 凭借真正困难的任务赢得自己的位置：必须在多个步骤之间保持连贯的长周期智能体、深度多来源推理，以及那些你想要消灭的失败本身很微妙的运行。对于这些，它的能力是实打实的，值这个溢价。而对于其他一切——内容起草、分类、路由、总结——你是在用更高的价格、更多的 token，去换你根本感知不到的质量。 我最后两个都在用。我的研究与综合智能体迁到了 Fable 5。其余一切都留在 Opus 4.8 上。这种分流正是关键所在：按任务挑模型，而不是按潮流。如果你运维着一支智能体舰队，我在[我的 2026 运营者技术栈](/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/)中写过的同一套纪律同样适用——把困难的活儿路由给昂贵的模型，别再为简单的活儿多花冤枉钱。 ## 运营者的结论 在你动其他任何东西之前，先在你那个唯一最难的任务上测试 Fable 5——那里才是它见效的地方，而且如果它在那里都没能拨动指针，那它在别处也不会。拿 token 计数器去跑你真实的 prompt，这样约 30% 的分词器膨胀和价格溢价就不会在账单上给你来个措手不及。在 Fable 5 触及生产的每一处，加上一个 `stop_reason: "refusal"` 检查（或服务端回退到 Opus 4.8）。然后有意识地路由：困难的那 10% 交给 Fable 5，其余交给 Opus 4.8。最好的模型不是能力最强的那个——而是与任务最匹配的那个。 --- ## AI智能体初学者终极指南：Cowork、Codex与真正完成工作的工具 Source: https://alejandrorioja.com/zh/ai-agents-for-beginners-cowork-codex-guide/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: AI智能体是超越聊天机器人的下一步：你用普通语言给它一个目标，它就完成工作——读取文件、起草内容、整理信息、编写并运行代码。Cowork是无代码入门通道；Codex和Claude Code面向需要处理代码库的人。真正重要的技能是写出清晰、范围明确的指令，而不是学习编程。 ## Table of contents _2026年6月更新。_ **TL;DR：** AI智能体是超越聊天机器人的下一步：你用普通语言给它一个目标，它就完成工作——读取文件、起草内容、整理信息、编写并运行代码，并自行检查结果。**Cowork**是面向非技术人员的无代码入门通道；**Codex**和**Claude Code**面向需要处理代码库的人。唯一重要的技能是写出清晰、范围明确的指令，而不是学习编程。 **「作者说」** 我每天运行30多个有代码的智能体，但大多数人不需要代码就能获取80%的价值。他们需要的是一条清晰的指令和一个运行它的地方。这份指南是我会递给一位从未写过代码的聪明朋友的入门读物。 ## 「AI智能体」究竟是什么 聊天机器人回答问题。**智能体**完成任务。区别在于：智能体可以循环执行动作——读取文档、决定下一步、写入文件、运行命令、检查结果、修复问题——而不需要你指导每一个步骤。 具体来说：你不是在问「我怎么清理这张表格？」你说的是「这是表格——去掉重复项，修正日期格式，标出缺少邮件地址的行」，智能体照做，然后把清理好的文件交给你。这种转变——从「建议」到「完成的工作」——正是关键所在。 ## 两大工具家族 进入这个世界有两扇门，你只需要走与自己工作相符的那扇。 ### 第一扇门：无代码智能体（不写代码的人从这里开始） **Claude Cowork**是一个工作空间，你给Claude一个目标加上材料——文件、链接、笔记——它生成你审阅和使用的成果：草稿、摘要、计划、清理好的表格。你写的是指令，不是代码。把它想成「一位读得飞快、永不疲倦的超级助手」，而不是「一个编程工具」。 这是营销人员、创始人、运营者、写作者、分析师的正确起点——凡是工作主要由文件、研究和决策构成的人，都适合从这里出发。 ### 第二扇门：编程智能体（一旦涉及代码库，就用这类工具） **OpenAI Codex**和**Claude Code**是生活在软件构建之处的智能体——终端、IDE或云端。你描述一个改动（「加一个深色模式开关」「修复这个失败的测试」「把这个文件迁移到新API」），智能体编辑代码、运行它，反复迭代直到成功。你仍然审查所有内容；智能体负责打字。 使用它们不需要是高级工程师。很多非开发者用编程智能体来上线小型网站、把表格自动化成脚本，以及修复自己没写过的工具中的bug。但确实有一定学习曲线，所以大多数初学者最好先从第一扇门开始，等遇到真正需要代码的任务时再走第二扇门。 ## 你的第一个成果（今天就做） 选一件你经常做的小而烦人的事情。好的第一选择： - 把一份乱糟糟的会议记录转成整洁的笔记加行动清单。 - 把一份长PDF总结成5条要点和3个值得追问的问题。 - 把一封粗糙的邮件改写得清晰、亲切、不超过120字。 然后使用让智能体可靠而非碰运气的结构——**角色→输入→精确指令→约束→一次核查**： > 你是我的助手。下面粘贴了一份[会议记录/PDF/邮件草稿]。请做到：[整理成清晰笔记，附加粗体「行动清单」/总结为5条要点＋3个后续问题/改写得清晰、亲切且不超过120字]。保持我的语气。如果有任何不清楚的地方，请在开始前问我一个问题。 > > [在此粘贴你的内容] 就这样。你刚刚完成了一次任务委托。结构就是全部——无论是在Cowork、ChatGPT还是编程智能体中，效果完全一样。 ## 让智能体可靠的四段式提示词 初学者以为秘诀是某句神奇的话。不是的。秘诀是具体性。每一条可靠的智能体指令都包含四个部分： 1. **角色**——智能体在这个任务中扮演谁（「你是我的调研助手」）。 2. **背景**——材料和「为什么」（「我在为与一位金融科技创始人的销售电话做准备」）。 3. **任务**——精确、范围明确的动作（「找出三条近期融资轮的事实，并起草两个开场问题」）。 4. **约束＋核查**——格式、长度、语气，以及一条「先问再猜」的指令（「只用要点，引用来源，如果公司名称有歧义请问我一个澄清问题」）。 模糊进，模糊出。智能体能做的越多，你的清晰度就越重要——一个理解错误的聊天机器人浪费一句话；一个理解错误的智能体浪费一下午需要撤销的工作。 ## 初学者常见错误 - **把它当搜索引擎用。** 别问单行问题。给它真实的工作和真实的文件。 - **省略约束。** 「给我写个计划」会得到一堵文字墙。「给我写一页计划，包含三个阶段，每个任务有负责人」会得到可用的东西。 - **不要求核查。** 加上「如果有不清楚的地方请先问我一个问题」，你就能在智能体运行之前而不是之后发现误解。 - **让编程智能体在重要代码上无人值守地运行。** 检查diff。智能体快速且大多数情况下是对的，但「大多数情况」这个词在那句话里承担了很多分量——在任何要上线的内容上都要保持人工把关。 - **太早跳到第二扇门。** 如果你的任务是文件和决策，永远不需要打开终端。 ## 如何选择你的第一个工具 - **你的工作是文件、研究和写作** → 从**Cowork**开始（或者你已经付费的聊天产品，切换到智能体模式使用）。 - **你想构建或修复软件** → **Claude Code**或**OpenAI Codex**。 - **你想要定期运行、无需干预的工作**（每日摘要、每周报告）→ 在手动掌握提示词之后，进阶到**[定时任务](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/)**。 ## AI智能体初学者常见问题——2026 ### 使用AI智能体需要会编程吗？ 不需要。Claude Cowork等无代码智能体是为非技术用户设计的——你用普通语言写指令。Codex和Claude Code等编程智能体确实有学习曲线，但即便如此，越来越多不认为自己是程序员的人也在使用它们。先从无代码开始，只在任务真正需要时才使用代码。 ### 聊天机器人和AI智能体有什么区别？ 聊天机器人回答问题；智能体完成任务。智能体可以在循环中执行一系列动作——读取、决策、行动、检查、修复——产出完成的工作而非建议。实际上，同一个产品通常两者都能做；「智能体模式」就是智能体行为。 ### Cowork比Codex更好吗？ 它们面向不同的工作，没有优劣之分。Cowork是面向文件、研究和运营的无代码工作空间。Codex（和Claude Code）是用于构建和修复软件的编程智能体。选择与你任务相符的那个。 ### 如何从AI智能体获得好的结果？ 具体性。使用四段式结构：角色、背景、精确任务，以及约束加核查。给它真实的材料，告诉它你想要的格式，并让它在开始前标注歧义。清晰的指令比任何「神奇提示词」都重要。 ### 让AI智能体自主运行安全吗？ 对于低风险、可撤销的任务（起草、摘要、整理），安全——检查输出然后继续。对于任何会改变真实系统的事情（发布代码、发送消息、删除数据），保持人工把关，在它行动之前先审查。可撤销性是正确的判断标准：一件事越容易撤销，智能体就可以越安全地拥有更多自主权。 **相关阅读：** [如何被ChatGPT回答引用](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) · [llms.txt实操手册](https://alejandrorioja.com/llms-txt-playbook/) · [如何使用Claude定时任务](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/) --- **想要帮助你在业务中使用智能体？** 我为运营团队构建AI智能体系统——[联系我](https://alejandrorioja.com/contact/)，或进一步了解[我的思考方式](https://alejandrorioja.com/seo-tips/)。 --- ## Anthropic如何赚钱？Claude商业模式详解 Source: https://alejandrorioja.com/zh/how-does-anthropic-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: Anthropic通过五个主要渠道销售其Claude AI模型的访问权限：按用量计费的API（按token付费）、消费者订阅（Claude Pro和Max）、企业方案（Team和Enterprise席位）、面向开发者的Claude Code，以及通过Amazon Bedrock和Google Vertex等云市场进行分销。API和企业业务——而非消费者应用——才是最主要的收入驱动力。 ## Table of contents _更新于2026年6月。_ **TL;DR：** Anthropic通过五个主要渠道销售其Claude AI模型的访问权限：**按用量计费的API**（按token付费）、**消费者订阅**（Claude Pro和Max）、**企业方案**（Team和Enterprise席位）、面向开发者的**Claude Code**，以及通过Amazon Bedrock和Google Vertex AI等**云市场分销**。API和企业业务——而非消费者聊天应用——才是最主要的收入驱动力。 **「运营者视角」** 我每天都在使用Anthropic的API进行开发，因此我从内部视角了解这门生意。关键在于：Anthropic是一家以企业客户（B2B）为核心的公司，消费者入口只是前台。你所使用的聊天应用是市场营销兼一条收入线；真正的钱在于开发者和企业通过API消耗token、并按规模付费购买席位。 ## Anthropic是什么 Anthropic是一家AI安全与研究公司，成立于2021年，致力于打造**Claude**系列大型语言模型。它将这些模型及其周边工具销售给消费者、开发者和企业。这是一家私营公司，获得了包括Amazon和Google在内的战略投资者的强力支持，两者同时也是其云服务和分销合作伙伴。 其产品本质是「智能即服务」：你不是购买一个装箱软件，而是租用一个能够代表你进行阅读、写作、推理和行动的模型的访问权限。以下每个渠道都是对同一核心资产的不同封装。 ## Anthropic如何赚钱？ ### 1. API（按用量计费，核心引擎） 业务的基础。开发者和公司通过API调用Claude，并**按token**付费——大致上，按输入和输出的文本块计费。价格随模型能力而变化： - **Claude Opus**（能力最强的层级）定价最高——每百万输入token数美元，输出token则是其数倍。 - **Claude Sonnet**（平衡型主力）居中。 - **Claude Haiku**（快速、低成本层级）价格最低，适合高量简单任务。 输出token比输入token贵，长上下文、prompt缓存和批量处理等功能有各自的定价。关键动态：**收入与使用量直接挂钩**。一家将Claude嵌入产品并增长至数百万用户的初创公司，每个月都会产生更多的API收入，无需Anthropic签署新合同。这种按用量计费的模式正是AI实验室谈论「运行收入」增长如此之快的原因——它随客户自身的增长而复利增长。 ### 2. 消费者订阅（Claude Pro和Max） Claude应用（网页端、桌面端、移动端）均可免费试用，重度使用者可选择付费套餐： - **Claude Pro** ——按月固定费用，获得更高的使用配额、最佳模型访问权限，以及更大上下文窗口和优先访问等功能。 - **Claude Max** ——面向突破Pro配额限制的重度用户的更高价格档位，使用空间大幅提升。 这是Anthropic最显眼的部分，但对于一家主要客户是企业的公司而言，其占比小于API和企业业务线。其战略价值在于充当漏斗和品牌展示面，而非单纯的收入来源。 ### 3. 企业版（Team和Enterprise席位） 大量持久性收入的来源。企业按**每席位**为员工购买Claude，方案专为组织设计： - **Team** ——适合小型企业：共享用量配额、集中账单管理、协作功能。 - **Enterprise** ——适合大型组织：更高安全性与合规标准、单点登录、更大上下文窗口、管理员控制及用量保障。 企业合同具有周期性，并随时间扩展（更多席位、更多用量），同时带来使收入具有粘性的转换成本。这是叠加在模型之上的经典SaaS模式。 ### 4. Claude Code（开发者工具） **Claude Code**是Anthropic的智能体编程工具——一个在终端、IDE或云端编写、编辑和运行代码的智能体。它通过相同的订阅和用量轨道变现（包含在Pro/Max/Team/Enterprise档位内，并计入你的方案配额）。从战略角度看，它具备双重价值：既是独立的收入来源，又能驱动大量高价值token使用，因为编程智能体会消耗大量的模型算力。 ### 5. 云市场分销（AWS、Google等） Anthropic不仅直接销售Claude——还通过主流云平台进行分销： - **Amazon Bedrock**和**Claude Platform on AWS** ——已在AWS上的客户可通过Amazon的基础设施和账单访问Claude。 - **Google Vertex AI**和**Microsoft Foundry** ——在Google Cloud和微软平台上实现相同的逻辑。 这些渠道在企业的云支出和采购流程所在地与其对接，降低了采用Claude的门槛。收入与平台分成，但覆盖范围巨大——而Amazon和Google的深度投资使这些合作具有战略意义，而不仅仅是商业关系。 ### 6. 新兴的智能体平台 Anthropic越来越多地销售的不仅是原始的模型调用，还有**智能体基础设施**——托管服务，由Anthropic运行智能体循环并托管智能体执行任务的环境。随着越来越多的客户从「向模型提问」转向「让智能体完成工作」，这一更高层级的平台成为在按token计费核心之上创造价值的新场所。 ## Anthropic盈利了吗？ Anthropic是私营公司，不公布经审计的财务报告，但公开信息与同行相同：**收入增长极其迅速**，而公司在算力（训练和推理模型）和研究人才上花费了巨额资金。与其他前沿AI实验室一样，公司正处于大规模投入阶段，营收增长而非当期利润才是重点。投资者的押注是：随着AI渗透进更多软件，基于用量的收入将持续复利增长，最终超越算力成本。 ## 与OpenAI的对比 两者结构相似——都通过消费者订阅、按用量计费的API、企业席位和开发者工具来变现。差异在于侧重点和合作关系：Anthropic重押开发者/企业API，背靠Amazon和Google；OpenAI在消费者市场占有更大份额，并与微软建立了深度合作。如需查看对比的另一面，请参阅[OpenAI如何赚钱](https://alejandrorioja.com/how-does-openai-make-money/)。 ## Anthropic收入模式——2026年常见问题 ### Anthropic的主要收入来源是什么？ **按用量计费的API**和**企业合同**是最主要的驱动力。开发者和公司按token付费调用Claude，而组织则为其团队购买按席位计费的方案。消费者Claude订阅是最显眼的产品，但在收入中的占比小于企业业务线。 ### Claude API的定价如何运作？ 按token付费——输入和输出以文本块为单位计量。能力更强的模型（Opus）每token价格高于平衡型（Sonnet）或快速型（Haiku）模型，且输出token价格高于输入token。长上下文、prompt缓存和批量处理等功能有各自的定价。收入直接随客户使用模型的程度而增长。 ### Anthropic是上市公司吗？ 不是。Anthropic是一家私营公司，获得包括Amazon和Google在内的战略投资者和风险投资支持。其股份不在公开证券交易所上市，也没有经确认的IPO计划。 ### Anthropic能从免费的Claude应用中赚钱吗？ 不能直接从免费用户处赚钱——免费层级是一个漏斗。当免费用户升级到**Pro**或**Max**时、当团队购买**企业席位**时，尤其是当开发者基于**API**进行构建时，才会产生收入。免费应用的作用是扩大覆盖面和品牌影响力；付费层级和API才是转化发生的地方。 ### Anthropic最大的客户是谁？ 主要是其他企业：通过API将Claude嵌入自身产品的软件公司，以及将Claude部署给员工使用的企业。通过AWS、Google和Microsoft云市场进行的分销，也吸引了大量通过现有云服务商进行采购的大型企业客户。 **相关阅读：**[OpenAI如何赚钱](https://alejandrorioja.com/how-does-openai-make-money/) · [AI智能体入门指南](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [如何在ChatGPT回答中被引用](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- ## 简短版本 Anthropic出租其Claude模型的访问权限。开发者通过API按token付费，消费者每月为Pro和Max付费，企业为Team和Enterprise按席位付费，工程师在同一方案下使用Claude Code，而云巨头（AWS、Google、Microsoft）则通过其市场将Claude转售给企业。这是一门以企业为核心的B2B业务，消费者端只是前台入口——计量器，而非聊天应用，才是钱所在的地方。 --- ## OpenAI如何赚钱？ChatGPT与API的商业模式 Source: https://alejandrorioja.com/zh/how-does-openai-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: OpenAI主要通过四种方式赚钱：ChatGPT订阅（Plus、Pro、Team、Enterprise、Edu）、开发者按Token付费的API、大型企业合同，以及与微软的合作伙伴关系（分销加收入分成协议）。与大多数AI实验室不同，OpenAI的消费者订阅业务是其最大的单一收入来源——ChatGPT的规模就是这台引擎。 ## Table of contents _更新于2026年6月。_ **TL;DR：**OpenAI主要通过四种方式赚钱：**ChatGPT订阅**（Plus、Pro、Team、Enterprise、Edu）、**按Token计费的API**（开发者按使用量付费）、大型**企业合同**，以及**与微软的合作伙伴关系**（分销加收入分成协议）。与大多数AI实验室不同，OpenAI的消费者订阅业务是其最大的单一收入来源——ChatGPT的庞大规模正是这台驱动引擎。 **【运营者视角】**OpenAI与典型的企业AI公司恰好相反：它先打造了一个消费者现象，其次才建立起面向开发者和企业的业务。数亿ChatGPT用户既是品牌，也是现金流的来源。这个领域的所有其他玩家都希望拥有这样的顶层流量入口。 ## OpenAI是什么？ OpenAI是**ChatGPT**和**GPT**系列模型背后的AI研究公司，旗下还有Sora视频模型、图像生成和Codex编程助手等产品。公司成立于2015年，2022年底ChatGPT上线后迅速引发广泛关注，成为历史上增长最快的消费类产品之一。 其架构颇为独特：最初以非营利组织形式成立，后来建立了一个有限盈利的商业部门，以筹集训练前沿模型所需的巨额资金。公司尚未上市，与**微软**建立了深度的多年合作伙伴关系，后者提供算力、分销渠道和资本。与所有AI实验室一样，其产品本质是「智能即服务」——通过消费者、开发者和企业三大渠道销售。 ## OpenAI如何赚钱？ ### 1. ChatGPT订阅（最大收入来源） 这正是OpenAI有别于同行的地方。ChatGPT免费可用，付费套餐将其庞大用户群中的一部分转化为经常性收入： - **ChatGPT Plus** — 固定月费，可使用最优质的模型、更高的使用上限和高级功能。面向大众市场的套餐。 - **ChatGPT Pro** — 面向重度用户的高价套餐，提供最大使用量和最强大的模型设置。 - **ChatGPT Team** — 面向小型企业的按席位计费方案，含共享工作区和管理工具。 - **ChatGPT Enterprise** — 面向大型组织：高级安全性、合规性、SSO、更大上下文窗口和使用量保障。 - **ChatGPT Edu** — 专为高校和学校定制的版本。 由于ChatGPT每周活跃用户多达数亿，即便付费转化率只有个位数的低比例，也能带来庞大的订阅收入。这种消费者规模是OpenAI的决定性优势，据报道订阅收入也是其最大的营收来源。 ### 2. API（按使用量计费，面向开发者） 开发者和企业将OpenAI的模型嵌入自己的产品，按**Token**付费——即按处理的每段文本（或图像、音频）收费。定价随模型能力提升：旗舰推理模型的每Token成本高于更小、更快、更便宜的模型，且输出定价高于输入。 API将每家基于GPT构建产品的公司变成按量计费的客户，其账单随自身使用量增长而增长。这与每家AI实验室所依赖的复利动态相同：一家嵌入OpenAI并扩展至数百万用户的初创公司，每个月无需新合同便能自动产生更多API收入。 ### 3. 企业合同 除自助API和Team套餐外，OpenAI还与大型公司签订大型定制协议——批量使用、专属算力、定制支持以及安全合规承诺。这类合同具有循环性，会随时间扩展，一旦企业在模型之上构建了关键业务流程便难以替换。这一企业市场动作与消费者业务并行，是重要的增长领域。 ### 4. 与微软的合作伙伴关系 微软是OpenAI最重要的战略合作伙伴，双方关系在多个维度展开： - **算力** — 微软Azure云提供OpenAI训练和部署模型所需的大部分基础设施。 - **分销** — OpenAI的模型通过微软平台（Azure AI服务、Copilot产品）提供，将GPT推送至微软庞大的企业客户群。 - **收入分成** — 两家公司在商业协议框架下共享收入，微软也对OpenAI进行了大规模投资。 这一合作伙伴关系既是资本层面的，也是市场拓展层面的：它使OpenAI能够接触到直接销售可能需要多年才能触达的企业客户。 ### 5. 新兴和周边产品 OpenAI持续扩大可变现的业务边界： - **Codex** — 其智能编程工具，通过订阅和API使用变现（也是Token消耗的重要驱动力）。 - **Sora** — 视频生成，内置于付费套餐，也作为独立产品提供。 - **图像生成及其他模态** — 捆绑于订阅，并通过API按量计费。 - **开发者/智能体生态** — 自定义GPT、智能体平台，以及让企业基于OpenAI模型进行构建的工具。 每一项都是对同一核心资产的又一层封装，目标是捕获用户和开发者愿意付费的更多价值。 ## OpenAI盈利了吗？ OpenAI是私营公司，不发布经过审计的财务报表。广泛流传的情况是：**收入非常可观且增长迅速**，但成本同样如此——训练前沿模型并服务数亿用户需要消耗惊人的算力。与同行一样，OpenAI正处于大规模投入阶段，优先目标是增长和能力建设，而非短期盈利。其押注逻辑是：规模加上企业采用率的持续提升，终将超越算力成本。 ## 与Anthropic相比如何？ 两者的基本构成相似——消费者订阅、按量计费API、企业合同、编程工具——但侧重点不同。OpenAI的决定性优势是**消费者规模**（ChatGPT）及其与**微软**的合作；Anthropic更侧重**开发者/企业API**，背后是亚马逊和谷歌的支持。欲了解对比的另一面，请参阅[Anthropic如何赚钱](https://alejandrorioja.com/how-does-anthropic-make-money/)。 ## OpenAI收入模式——2026年常见问题 ### OpenAI最大的收入来源是什么？ **ChatGPT订阅。**由于ChatGPT覆盖数亿用户，其付费套餐（Plus、Pro、Team、Enterprise、Edu）构成了OpenAI最大的单一收入线——这对AI实验室来说是不寻常的特征，大多数实验室从API和企业业务获得的收入高于消费者。 ### OpenAI的API如何赚钱？ 开发者在自己的应用中调用OpenAI模型时，按**Token**付费——即按处理的每段文本、图像或音频收费。能力更强的模型每Token成本更高，输出定价也高于输入。随着客户自身使用量增长，收入自动增加。 ### OpenAI是否上市？我能购买OpenAI的股票吗？ 不能。OpenAI是私营公司，其股份无法在公开交易所购买。绝大多数人无法直接投资。微软通过合作伙伴关系持有重要股份，但这与OpenAI上市是两回事。 ### 与微软的合作如何为OpenAI带来收入？ 微软提供Azure算力，通过其产品和云服务将OpenAI的模型分销给庞大的企业客户群，双方在商业协议下分享收入。微软也对OpenAI进行了大规模投资。这既是资金来源，也是分销渠道。 ### OpenAI能从ChatGPT免费用户身上赚钱吗？ 不能直接赚钱——免费套餐是漏斗入口。收入来自以下几种情况：免费用户升级为**Plus**或**Pro**、企业购买**Team**或**Enterprise**席位、开发者基于**API**进行构建。免费产品的作用是触达规模，付费套餐和API负责将其转化。 **相关阅读：**[Anthropic如何赚钱](https://alejandrorioja.com/how-does-anthropic-make-money/) · [SpaceX如何赚钱](https://alejandrorioja.com/how-does-spacex-make-money/) · [AI智能体入门指南](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) --- ## 简要版本 OpenAI将ChatGPT庞大的用户群转化为订阅收入（Plus、Pro、Team、Enterprise），通过API向开发者按Token收费，签署大型企业合同，并依托微软获取算力、分销渠道和收入分成。其决定性特征是消费者规模——大多数AI实验室优先从开发者处变现；OpenAI先打造了消费者现象，再在其背后建立起商业模式。 --- ## SpaceX如何赚钱？发射业务、Starlink与IPO问题 Source: https://alejandrorioja.com/zh/how-does-spacex-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business TL;DR: SpaceX通过三种方式赚钱：发射服务（在可重复使用的Falcon火箭上销售入轨机会）、Starlink（面向消费者、企业、海事/航空及政府的卫星互联网）以及政府合同（NASA载人和货运、月球着陆器、国家安全发射）。Starlink目前是最大的收入来源。SpaceX仍为私营公司；SpaceX本身的IPO并不迫在眉睫，不过Starlink的未来分拆上市早有讨论。 ## Table of contents _2026年6月更新。_ **TL;DR：** SpaceX通过三种方式赚钱：**发射服务**（在可重复使用的Falcon火箭上销售入轨机会）、**Starlink**（面向消费者、企业、海事/航空及政府的卫星互联网）以及**政府合同**（NASA载人和货运、月球着陆器、国家安全发射）。Starlink目前是最大的收入来源。SpaceX仍为私营公司；SpaceX本身的IPO并不迫在眉睫，不过Starlink的未来分拆上市早有讨论，且多次被泼冷水。 **【运营者解读】** SpaceX是当今最清晰的一个案例——一家公司利用硬件技术护城河（可重复使用的火箭），在其上构建了软件经济学的业务（卫星互联网）。发射业务赢得了生存权；Starlink才是持续、可扩展收入的所在。这就是整个故事的一句话总结。 ## SpaceX是什么 SpaceX（太空探索技术公司）设计、建造并飞行火箭和航天器，同时运营Starlink卫星互联网网络。该公司于2002年成立，长期目标是使人类成为多行星物种，通过做一件其他人没有大规模做到的事情——降落并重复使用轨道火箭的第一级——彻底压低了进入太空的成本，从而成为全球主导的发射服务商。 这一成本优势是一切的引擎。低廉、频繁、可靠的发射，使得由7000多颗卫星组成的星座在经济上成为可能；而这个星座，则将一个项目制的、收入不稳定的发射业务，转变为一个具有经常性收入的业务。 ## SpaceX如何赚钱？ ### 1. 发射服务 最初的业务。SpaceX向三类客户销售发射服务： - **商业卫星运营商**——需要将有效载荷送入轨道的公司，可支付费用购买专属发射，或在**拼车**任务中占据一个位置（多颗小型卫星共乘一枚火箭，按千克计价）。 - **政府和军事机构**——国家安全有效载荷和科学任务，通常因可靠性和保障需求而支付溢价。 - **其他航天公司**——包括越来越多的竞争对手，它们仍依赖SpaceX，因为这是最廉价、最易获得的发射途径。 单位经济之所以可行，在于**可重复使用性**：同一枚一级助推器可以多次飞行，因此每次发射的边际成本远低于售价。Falcon 9是主力机型；Falcon Heavy承担最重的有效载荷。 ### 2. Starlink（经常性收入的引擎） Starlink是一个由数千颗低地球轨道卫星组成的星座，向陆地宽带无法覆盖或不愿服务的地方提供高速互联网。它现在是SpaceX中最像真正订阅制业务的部分，拥有多个层次： - **消费者**——家庭用户支付天线费用（硬件）加上月度订阅费。 - **企业和移动**——面向企业、海事（船舶、游艇）和**航空**（与航空公司签订的机载Wi-Fi协议）的高价套餐。 - **政府**——包括**Starshield**，即面向军事和政府客户销售的国防导向变体。 - **直连手机**——与移动运营商合作，在盲区直接向普通手机提供卫星连接。 Starlink将硬件销售（终端设备）与数百万用户的每月经常性收入（订阅费）相结合——这是经典的「剃刀与刀片」模式，只是规模达到了行星级别。这也是为什么大多数估计现在将Starlink列为SpaceX最大的收入线，超过了发射服务。 ### 3. 政府合同 一个独立的、规模庞大的业务板块，与发射有所重叠，但值得单独拆分来看： - **NASA**——SpaceX通过**商业载人**计划（Crew Dragon）将宇航员送往国际空间站，并通过**Cargo Dragon**为其补给。公司还赢得了为NASA月球计划建造基于**Starship**的人类着陆系统的合同。 - **国家安全**——为国防和情报有效载荷提供的定期发射合同。 这些合同价值高昂、周期多年，并为商业端的大量研发提供了资金支持。 ### 4. Starship（未来的引擎，尚未成为盈利中心） Starship是SpaceX完全可重复使用的超重型运载火箭——Falcon的长期替代者，也是月球/火星任务以及下一代更大规模Starlink卫星部署的关键。目前它是一个成本中心，由其他三项业务提供资金支持。一旦实现常规飞行，它将再次大幅压低发射成本，并解锁更大规模的Starlink部署——这正是投资者真正押注的方向。 ## SpaceX盈利吗？ SpaceX是私营公司，不公布经审计的财务报告，因此任何精确数字都是估计。广为流传的图景是：得益于可重复使用性，发射业务在每次任务层面是盈利的；随着订阅用户规模扩大，Starlink已进入正现金流区间。公司将巨额资金再投入Starship的研发，因此「利润」在很大程度上取决于如何处理这部分研发支出。发展方向——在主导发射业务之上叠加不断增长的Starlink经常性收入——正是支撑公司巨额私人估值的关键所在。 ## IPO问题 这是所有人都关心的话题，以下是诚实的版本。 **SpaceX近期不太可能上市。** Elon Musk多次表示，在Starship和火星计划仍处于资本密集、长周期阶段时，他倾向于将SpaceX保持私营——公开市场的季度压力与数十年的使命不相匹配。取而代之的是，SpaceX通过定期**要约收购**（公司以固定价格促成股票出售）为员工和早期投资者提供流动性，使他们无需公开上市即可套现。这些二级销售正是产生头条估值数字的来源——SpaceX在近期融资轮次中的估值已达数千亿美元。 **Starlink分拆上市的话题由来已久**——Musk本人多年前曾暗示，一旦Starlink的收入趋于平稳且可预测，就可能考虑上市。但他也多次为近期时间表泼冷水。截至2026年，Starlink尚未IPO，也没有确认日期。除非消息来自公司本身，否则任何「Starlink IPO日期」的头条都应保持怀疑。 ## 结语 SpaceX的商业模式是一个堆栈：可重复使用的发射构建起成本护城河，这一护城河使Starlink在经济上成为可能，Starlink将整个商业版图转变为经常性收入业务，而政府合同则资助了前沿工作（Starship），后者将再次重置成本曲线。公司选择保持私营，以要约收购代替IPO——而通往公开市场的最可能路径，是未来Starlink的单独上市，而非整个SpaceX，时机由公司自行决定。 ## SpaceX收入模式——2026年常见问题 ### SpaceX最大的收入来源是什么？ 大多数估计现在将**Starlink**列为SpaceX最大的收入线，超过了发射服务，其驱动力来自数百万消费者、企业、移动端及政府订阅，以及终端硬件销售。发射服务在每次任务层面仍然规模庞大且高度盈利，但Starlink的经常性模式扩张更快。 ### SpaceX是否公开上市？我可以购买SpaceX股票吗？ 不能。SpaceX是一家私营公司，其股票无法在公开证券交易所购买。大多数人无法直接投资；通常只有员工和参与私募轮次或要约收购的合格投资者才能获得准入。请警惕任何暗示可以购买「SpaceX股票」的相关说法。 ### SpaceX或Starlink会上市吗？ 预计SpaceX近期不会上市——Musk表示希望在资本密集型的Starship/火星阶段保持私营。**Starlink** IPO多年来一直被讨论为一种可能性，等待其收入变得可预测，但截至2026年，没有确认日期。任何具体的「IPO日期」说法都应持怀疑态度，除非来自公司自身。 ### Starlink如何赚钱？ Starlink向客户收取卫星天线费用（硬件）加上月度订阅费，覆盖消费者、企业、海事、航空和政府等层级——包括国防导向的Starshield以及直连手机的运营商合作。这是「剃刀与刀片」模式：前期收取硬件费用，之后获得经常性收入。 ### 可重复使用性如何帮助SpaceX盈利？ 将同一枚火箭助推器多次降落并重新发射，使每次发射的边际成本大幅低于收取的价格。这一成本优势使SpaceX成为最廉价的发射服务商，也使部署由数千颗卫星组成的Starlink星座在经济上可行。 **相关阅读：** [Uber如何赚钱](https://alejandrorioja.com/how-does-uber-make-money/) · [Shopify如何赚钱](https://alejandrorioja.com/how-shopify-makes-money/) · [PayPal如何赚钱](https://alejandrorioja.com/how-does-paypal-make-money/) --- ## 简短版本 SpaceX以低廉价格销售入轨机会，因为它重复使用自己的火箭，然后将这一成本优势用于运营Starlink——一项卫星互联网订阅业务，目前是其最大收入来源——同时政府合同为下一代Starship提供资金。公司有意保持私营；Starlink上市（而非SpaceX整体上市）是最终通向公开市场的最可能路径，时机将由公司自行把握。 --- ## 如何使用 Claude 定时任务：用 cron 自动化重复性工作 Source: https://alejandrorioja.com/zh/how-to-use-claude-scheduled-tasks/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: 定时任务将一次性的 Claude 提示词变成周期性工作：它按 cron 式计划触发，完成工作并交付结果。个人周期性提示词（早间摘要、每周汇总）使用 Claude 应用；在云端运行的开发者自动化任务使用 Claude Code 例程或 Managed Agents 部署。其价值在于将你原本每天或每周手动重复的工作自动化。 ## Table of contents _2026年6月更新。_ **TL;DR：**定时任务将一次性的 Claude 提示词变成周期性工作：它按 cron 式计划触发，完成工作并交付结果。个人周期性提示词（早间摘要、每周汇总）使用 **Claude 应用**；在云端运行的开发者自动化任务使用 **Claude Code 例程**或 **Managed Agents 部署**。其价值在于将你原本每天或每周手动重复的工作自动化。 **[运营者须知]** 杠杆效应最高的自动化往往并不炫目——它们是那些每天悄悄吃掉你20分钟的小型重复任务。定时任务就是将这些任务一次性交给 Claude、从此不必再惦记的方式。我运行了好几个：早间竞争对手扫描、夜间 PR 状态检查、每周内容管道草稿。没有一个设置超过十分钟。 ## 什么是定时任务 普通的 Claude 会话是同步的：你输入，它响应，你在场。**定时任务**是异步且周期性的：你定义一个提示词（或整个智能体工作流）加上一个计划，Claude 自行运行——每个工作日早上7点、每周一、每小时——完成后将结果交给你。 底层是以 LLM 为核心的 cron 作业。你不需要编写代码来拼接各种 API；只需用自然语言描述结果，让智能体每次触发时自己搞清楚步骤。 ## 三个设置场景 不存在单一的按钮——有三个入口，针对不同的使用者。 ### 1. Claude 应用（面向所有人） 面向消费者的 Claude 应用支持周期性任务：保存一个提示词和一个节奏，Claude 按计划运行并将结果通知你。这是无代码路径——非常适合每日简报、周期性研究检索、"每天早上汇总我未读的新闻简报"等任务。如果你不是开发者，从这里开始。 ### 2. Claude Code 例程（面向终端重度用户） 如果你使用 **Claude Code**，可以将提示词或斜杠命令安排为按 cron 节奏运行的云端智能体——即"例程"。它在服务器端的你的仓库或工作空间中运行，即使笔记本电脑关闭也照常工作。典型用途：监视开放的 pull request、执行夜间 lint 和修复扫描、每天早上生成一篇待审草稿。你定义计划和任务；Claude Code 负责触发和运行记录。 ### 3. Managed Agents 部署（面向构建产品的开发者） 对于在 Claude API 上构建产品的团队，**定时部署**按周期性 cron 计划运行智能体——每次触发都会启动一个会话，自主完成工作（夜间合规扫描、每周报告、每小时监控）。你可以获得每次触发的运行记录，以便审计成功和失败。这是同一思路的程序化、生产级版本。 ## 如何思考计划安排 三种方式共用同一套心智模型——**什么任务、多长时间一次、如何处理输出**： 1. **任务** ——按写好智能体提示词的方式来写：角色、上下文、精确动作、约束条件和一项校验。定时任务在运行中无法向你提问，因此必须*提前完整指定*。这是与交互式使用最大的区别。 2. **节奏** ——每日、每周、每小时、仅工作日、你所在时区的特定时间。让节奏与底层事物实际变化的速度相匹配；对一个每周更新一次的来源做"每日"摘要，是在浪费运行次数。 3. **交付** ——结果落地的位置（通知、文件、消息、草稿）。提前决定好，这样输出到达时就能立刻派上用场。 ## 真正值得使用的模式 - **早间摘要。**「每个工作日早上7点，获取 [主题] 的最新信息，总结三件重要的事，给我发一份5条要点的简报。」替代20分钟的手动浏览。 - **每周报告。**「每周一，将 [指标] 整理成一页摘要，包含变化内容及原因。」将重复性杂务变成一次审阅。 - **夜间工作者。**一个代码例程，在你睡觉时执行长时间、充分指定的任务——重构、测试扫描、数据清理——让你醒来就有可审阅的结果。 - **监控器。**「每小时检查 [事项]；只在 [条件] 为真时通知我。」最好的自动化大多数时候保持沉默，只在重要时才开口。 ## 来自生产环境的配置建议 - **过度指定提示词。**运行中不可能提问。要说明格式、来源、约束条件以及边缘情况的处理方式。 - **先手动测试一次。**把准确的提示词手动运行一遍。如果交互式运行产生了你想要的结果，再安排计划。如果没有，先修复提示词——给一个糟糕的提示词安排计划，只会可靠地产出糟糕的输出。 - **让节奏与变化频率匹配。**不要对每周更新一次的内容进行每小时运行。 - **高风险时将输出保留为草稿。**对于任何发布到外部世界的内容——已发布的文章、已发送的邮件——让任务生成一份供你审阅的*草稿*，而非直接执行。把完全自主的"直接做"留给低风险、可撤销的工作。 - **观察最初几次运行。**定时任务会漂移——某个来源改变了格式，某个订阅源悄然沉寂。检查早期运行记录，之后再信任它。 ## Claude 定时任务——2026年常见问题 ### 什么是 Claude 定时任务？ 它们是周期性工作：你定义一个提示词或智能体工作流加上 cron 式计划，Claude 自动执行——每日、每周、每小时——无需你守在键盘旁便可交付结果。它们存在于面向消费者的 Claude 应用中（用于个人周期性提示词）、Claude Code 中（作为云端例程）以及 Claude API 中（作为 Managed Agents 部署）。 ### 使用它们需要是开发者吗？ 不需要。Claude 应用无需代码即可支持周期性任务——只需保存一个提示词和一个节奏。Claude Code 例程和 Managed Agents 部署是面向开发者的版本，用于自动化代码和产品工作流。 ### 定时任务与普通 Claude 聊天有何不同？ 普通聊天是交互式的——你在场回答后续问题。定时任务是自主且周期性的，因此提示词必须提前完整指定；Claude 无法在运行中暂停向你提问。它按计划触发，完成工作，然后将结果交给你。 ### 什么是好的第一个定时任务？ 早间摘要。「每个工作日早上7点，将 [你的主题] 的最新信息总结成五条要点。」风险低、易于验证，能立即替代一项重复性的手动杂务——在自动化更大的事情之前，这是学习工作流程的完美模板。 ### 定时任务可以执行真实操作，比如发送邮件吗？ 可以，但要有意识地使用。对于可撤销的低风险工作，让它直接行动。对于任何面向外部或难以撤销的事情，让任务生成一份你审批的草稿，而不是自动触发——尤其是在无人值守的运行中。可撤销性是判断授予多少自主权的正确标准。 **相关阅读：**[AI 智能体入门指南](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [Anthropic 如何盈利](https://alejandrorioja.com/how-does-anthropic-make-money/) · [如何被 ChatGPT 回答引用](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- **想要一套管理你重复性工作的定时智能体系统？**这正是我所构建的——[联系我](https://alejandrorioja.com/contact/)。 --- ## AI 智能体的成本算账：Haiku 何时胜过 Sonnet（何时不行） Source: https://alejandrorioja.com/zh/ai-agent-cost-math-when-haiku-beats-sonnet/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: 选择 Claude Haiku 而非 Sonnet 可以大幅削减每次调用的成本，但前提是任务能容忍更低的成功率。真正的指标不是每次调用的成本，而是每个成功结果的成本，其中包括重试和人工善后。我按任务路由，而不是按默认值。 ## 目录 _2026 年 6 月更新。_ **摘要：** 选择 Claude Haiku 而非 Sonnet 可以把每次调用的成本削减一个数量级，但前提是任务能容忍 Haiku 更低的成功率。真正要紧的指标是**每个成功结果的成本**——调用成本加上重试再加上人工善后——而不是每个 token 的标价。我按任务路由，需要判断的环节留给 Sonnet，而相当一部分高频环节跑在 Haiku 上。 **运营者视角：** 我运行着 100 多个智能体，推理是一笔实打实的开支。但我见过一些团队把所有东西硬塞进最便宜的模型来"省钱"，然后在重试、升级和愤怒的客户身上把成本吃了回去。成本算账只有在你衡量整个漏斗时才成立。 最便宜的模型并不是每 token 单价最低的那个。而是把活儿做对所需总成本最低的那个。这是两个不同的数字，而它们之间的差距，正是大多数智能体成本决策出错的地方。 ## token 经济学，直说 Anthropic 按每百万 token 对 Claude 计费，输入和输出分开计费，输出的成本是输入的数倍。确切数字会随时间变动，所以请查阅 Anthropic 当前的定价——但驱动决策的是**结构**： - **Haiku** 是廉价、快速的档位——在整个家族中每 token 成本最低，且优势明显。 - **Sonnet** 居中——明显比 Haiku 贵，明显比 Opus 便宜。 - **Opus** 是面向最难推理的高端档位。 由此引出两点。第一，在生成类任务中，输出 token 主导成本，所以一个啰嗦的模型即便单价相同也更贵。第二，Haiku 与 Sonnet 之间的每 token 价差足够大，以至于在高频环节上一定会反映到账单上。这是支持 Haiku 的*理由*。下面是反对的理由。 ## 真正要紧的指标：每个成功结果的成本 每次调用的成本是个面子数字。这是我真正使用的公式： ``` 每成功成本 = (调用成本 × 尝试次数) + 善后成本 ÷ 成功率 ``` 其中 `尝试次数` 计入重试，`善后成本` 是由人来修复那些漏网失败的预期成本。看看这对比较起了什么作用。 假设 Haiku 每次调用的成本大约是 Sonnet 的十分之一。如果在某个任务上 Haiku 有 80% 成功、Sonnet 有 98% 成功，每次调用的节省看起来巨大。但如果 Haiku 的每次失败都触发一次重试，且每 10 次仍有 1 次需要一个花真金白银的人，善后这一项就可能吞掉 token 上的节省。在低风险、高频的任务上，算账压倒性地有利于 Haiku。在一个失败就会给错误客户发邮件的任务上，结论可能完全反转。 不衡量每个模型的成功率，你就无法做这个决定——而这正是[评估框架](/the-eval-harness-i-use-to-ship-ai-agents/)所提供的。用同一套评估集分别跑两个模型，在同一把尺子上读出成功率。 ## Haiku 决定性胜出之处 当任务**狭窄、结构化且可验证**时，Haiku 是正确选择： - **分类与路由**——"这条进来的消息是预订、投诉还是垃圾信息？"三个桶，易于验证，持续运行。整天用 Haiku。 - **带模式的抽取**——从文本中拉出一个日期、一个名字、一个金额，用 Zod 校验。如果输出能解析，几乎可以肯定是对的。 - **短改写与格式化**——语气微调、对已知良好的输入做摘要、归一化数据。 - **首轮过滤**——Haiku 做分诊，只有模糊的情形才升级到 Sonnet。这是杠杆率最高的模式。 共同的脉络：Haiku 出错的代价低，且错误便于发现。当验证便宜、风险低时，便宜的模型胜出。 ## Sonnet 值回票价之处 当任务**开放式、多步骤，或出错代价高昂**时，Sonnet（有时是 Opus）才值得： - **多工具智能体循环**，其中一次错误的工具调用会层层级联。更高的推理可靠性会跨步骤累积——我在[多智能体编排](/multi-agent-orchestration-patterns-queues-state-handoffs/)中讲到的编排模式，正依赖于模型不丢失思路。 - **面向客户的生成**，其中一次糟糕的输出损失的是信任，而不只是一次重试。 - **任何验证本身就困难的场景。** 如果你无法廉价地判断输出是否正确，你就承担不起一个经常出错的模型。 这里的失败不止一次重试的代价——它的代价是退款、流失的客户，或我的时间。相比之下，每 token 的溢价只是舍入误差。 ## 我真正上线的路由规则 我不会为每个智能体选定一个模型。我在智能体内部按**任务**路由，通常由一个廉价的分类器决定由哪个下游模型来处理： ```typescript function pickModel(task: Task): string { // 廉价、可验证、高频 → Haiku if (task.type === "classify" || task.type === "extract") { return "claude-haiku"; } // 开放式或面向客户 → Sonnet if (task.customerFacing || task.steps > 2) { return "claude-sonnet"; } return "claude-sonnet"; // 默认采用安全选项 } ``` 这里编码了两条原则。**默认选用安全的模型**，而非便宜的——你是从一个可用的基线*向下*优化成本，而不是从一个破损的基线*向上*优化可靠性。以及**升级，别赌**：让 Haiku 处理容易的 80%，把困难的 20% 交给 Sonnet。这种混合方案几乎总是胜过把所有东西单独跑在任一模型上。 此外还有提示缓存可以叠加：如果你的系统提示很大且会被重复使用，缓存会在不分档位的情况下大幅削减输入成本，这有时会让 Sonnet 便宜到使 Haiku 的取舍变得无关紧要。 ## 来自我自己技术栈的一个实例 以一个高频的进站分诊环节为例。它运行成千上万次，任务是三分类，漏判也只是让条目落入一个审核队列——便于发现、风险低。这是教科书式的 Haiku 任务，把它从 Sonnet 上挪走，在不对要紧结果造成可测量影响的前提下，明显降低了该环节的成本。 再看一个起草真正回复客户内容的环节。频率较低、开放式，而一份糟糕的草稿发出去损失的是信任。这一环节留在 Sonnet 上。同一个智能体，两个模型，按风险路由。我会盯着两者的每次运行成本和成功指标，方式如我在[我如何衡量一个 AI 智能体是否真的在起作用](/how-i-measure-whether-an-ai-agent-is-actually-working/)中所述——而且只有在评估表明更便宜的模型能保住成功率之后，我才会把某个环节降一档。 ## 常见问题 ### 在实践中 Claude Haiku 总是比 Sonnet 便宜吗？ 按 token 算，是的——而且差距很大。按每个成功结果算，则不总是。如果 Haiku 较低的成功率触发了重试和人工善后，在那些错误难以发现或修复的任务上，总成本可能超过 Sonnet。 ### 对于某个给定任务，我该如何在 Haiku 和 Sonnet 之间抉择？ 从两个维度给任务打分：输出有多可验证，以及一次错误有多昂贵。验证便宜、低风险、高频的工作交给 Haiku；开放式、面向客户或难以验证的工作交给 Sonnet。按任务路由，而非按智能体。 ### 我应该追踪的唯一成本指标是什么？ 每个成功结果的成本——调用成本乘以尝试次数加上预期善后成本，再除以成功率。单看每次调用的价格会掩盖重试和人力时间，而那正是廉价模型悄悄变贵的地方。 ### 我能在一个智能体里同时用两个模型吗？ 可以，而且通常你应该这么做。最强的模式是一次廉价的首轮处理（Haiku 做分类或过滤），只把模糊的情形升级到 Sonnet。这种混合方案通常胜过把所有东西跑在单一档位上。 --- ## 如何在生产环境中调试 AI 智能体（实战指南） Source: https://alejandrorioja.com/zh/how-to-debug-an-ai-agent-in-production/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: 调试生产环境中的 AI 智能体，主要是隔离出是哪一层出了问题——提示词、工具、模型还是编排。我用追踪 ID 记录每一步，重放完全相同的输入，然后二分定位。在我的智能体中，约 70% 的“AI 故障”最终都是管道故障，而非模型故障。 ## 目录 _2026 年 6 月更新。_ **TL;DR：** 调试生产环境中的 AI 智能体，主要是隔离出是哪一层出了问题——提示词、工具调用、模型输出还是编排。我用追踪 ID 记录每一步，重放完全相同的输入，并从那里开始二分定位。在我的智能体中，看似“AI 故障”的问题大约有 70% 最终都是管道问题：格式错误的工具结果、被截断的输入、被悄悄吞掉的异常。 **操作者视角：** 我运行着 100 多个生产智能体——Pickleland 的预订流程、内容流水线、收件箱分拣器。它们会以一切软件都会坏掉的方式坏掉，再加上几种新的方式。这是我当初希望自己拥有的实战指南：如何在不盯着一堵 token 墙的情况下找到出故障的层。 当智能体在生产环境中出问题时，本能反应是怪罪模型。“Claude 产生了幻觉。”有时确实如此。通常不是。模型只是五六层堆栈中的一层，而 bug 远更常出现在你自己写的那一层，而不是 Anthropic 交付的那一层。这篇文章讲的就是我找出它的系统化方法。 ## 在调试任何东西之前，先让每次运行都可追踪 你无法调试你看不见的东西。你能做的最具杠杆效应的事情——在任何具体 bug 出现之前——就是给每次智能体运行附上一个追踪 ID，并记录它走过的每一步。 “一步”是指任何跨越边界的东西：传入的触发器、每次模型调用（带完整的消息数组）、每次工具调用（带参数）、每个工具结果，以及最终输出。把它们记录为以追踪 ID 为键的结构化 JSON。 ```typescript function logStep(traceId: string, step: string, payload: unknown) { console.log(JSON.stringify({ traceId, step, // "trigger" | "model_call" | "tool_call" | "tool_result" | "output" ts: Date.now(), payload, })); } ``` 在 Cloudflare Workers 上，我把这些发送到队列并写入一张表；在本地它们输出到 stdout。规则是绝对的：如果某一步没有被记录，那么就调试而言它就没有发生过。这与我在[我使用的智能体技术栈](/the-agent-stack-i-use-to-run-30-production-agents-no-python/)中描述的埋点一致——追踪 ID 是其他一切都挂靠其上的脊柱。 ## 隔离出那一层：提示词、工具、模型还是编排 一旦你有了追踪，调试就变成了二分查找。一共有四层，而大多数情况下 bug 恰好只住在其中一层。 ### 1. 输入层（最常见的元凶） 把进入失败模型调用的那个完全相同的 `messages` 数组拉出来。不是重建——而是日志里逐字逐句的载荷。然后像一个陌生人那样去读它。我那些“模型无视了指令”的 bug 中，有一半实际上是： - 一个工具结果因为某处字符串化出错而返回成了 `"[object Object]"`。 - 一个输入因为撑爆了上下文窗口、又被一次粗暴的切片砍断，从而在句子中途被截断。 - 一个变量被插值成了 `undefined`，悄无声息地毒化了提示词。 如果输入是错的，那么模型在垃圾之上完美地完成了它的工作。去修管道。 ### 2. 工具层 如果输入看起来干净，就检查是否有工具返回了一个被智能体当作成功对待的错误。一个经典案例：API 返回 `200`，正文却是 `{ "error": "rate limited" }`，而你的工具包装器没有检查正文，于是智能体自信满满地基于一条错误信息采取行动。把工具结果原样记录下来，并断言它的形状。 ### 3. 模型层 只有在排除 1 和 2 之后，我才会怀疑模型。即便如此，“模型 bug”通常意味着“我的提示词有歧义”。把那个完全相同的失败输入拿来，丢进一个针对相同模型和温度的一次性脚本，看它是否复现。如果复现，修复手段是提示词工作或一次[更严格的 eval](/the-eval-harness-i-use-to-ship-ai-agents/)，而不是慌张地换模型。 ### 4. 编排层 如果单独一步孤立来看没问题，但多步运行却失败，那么 bug 就在交接处——步骤之间丢失的状态、一个竞态条件、一次重新运行了非幂等操作的重试。这些是最棘手的，我在[多智能体编排模式](/multi-agent-orchestration-patterns-queues-state-handoffs/)中讲解了相关模式。 ## 复现非确定性，而不是与它搏斗 让智能体感觉无法调试的，是非确定性：相同的输入在不同运行间产生不同的输出。你可以驯服它。 第一，**能固定的就固定。** 调试期间设置 `temperature: 0`。这不会让 Claude 完全确定，但会大幅收窄方差，让你能把真正的 bug 与采样噪声区分开。 第二，**跑它 N 次。** 如果某个故障是每 20 次运行复现 1 次，就把那个完全相同的输入循环 50 次，并捕获每一个输出。现在你有了一个样本，而不是一则逸闻。一个 5% 概率触发的 bug 是真正的 bug——你只是需要足够的量才能看见它。 ```bash for i in $(seq 1 50); do node replay.mjs --trace=abc123 >> runs.jsonl done # 然后统计失败数 grep -c '"status":"fail"' runs.jsonl ``` 第三，**对通过的运行和失败的运行做差异比对。** 在固定温度且输入相同的情况下，输出的差异意味着存在一个你尚未发现的输入差异——提示词里的一个时间戳、一个会变化的工具结果、一个发生了变化的检索文档。 ## 搭建一个重放装置，从此不再在生产环境中调试 通过重新触发线上智能体来调试既慢又危险——它会发出真实的邮件、预订真实的场地。相反，捕获追踪并在离线状态下重放它。 重放装置加载一条已记录的追踪，重建对任意一步的完全相同的输入，并仅针对模型重新运行那一步。因为你记录了完整的 `messages` 数组，所以你根本不需要上游系统。这把生产环境中一次 10 分钟的往返变成了一个 2 秒的本地循环，是我调试工作流中最大的提速。 一个好的重放装置还让你能够**变异并重新运行**：改动系统提示词的一行，重放那同样的 50 条失败追踪，看看现在有多少条能通过。这就是从调试通向 eval 的桥梁——一旦你有了一批失败追踪的语料，你就有了一套回归测试的雏形。 ## 关注那些真正能预测崩坏的指标 有些故障从不抛出异常。智能体照常运行，返回某个看似合理的东西，却悄悄做了错事。要抓住这些，你得关注行为指标，而不只是错误率： - **工具调用成功率**（按每个工具）。这里的下降往往先于一次可见的故障。 - **输出 schema 有效性**——有多少 % 的输出能针对预期结构成功解析。我用 Zod 校验每一个输出，并在有效性下滑时告警。 - **循环长度**——每次运行的平均步数。突然的飙升通常意味着智能体卡在重试里了。 - **每次运行的成本**——一个失控的循环会先表现为成本飙升，然后才表现为一条投诉。（当成本重要时，[Haiku 对 Sonnet 的算账](/ai-agent-cost-math-when-haiku-beats-sonnet)值得了解。） 我追踪这些指标的方式和我追踪其他一切的方式一样——见[我如何衡量一个 AI 智能体是否真的在起作用](/how-i-measure-whether-an-ai-agent-is-actually-working/)。一个能抓住沉默故障的指标，抵得上十个只能抓住吵闹故障的指标。 ## 5 分钟分诊清单 当一个智能体崩了、而我又赶时间时，我会按顺序跑这套： 1. **拿到失败运行的追踪 ID。** 2. **读失败那一步的完全相同的输入。** 它格式良好吗？（在这里能解决约 50% 的情况。） 3. 在那条追踪里**检查工具结果**，找出伪装成成功的错误。 4. 在 `temperature: 0` 下**离线重放那一步。** 它复现吗？ 5. **如果复现，** 那是提示词/模型问题——修复并重跑追踪语料。**如果不复现，** 那是非确定性或状态/编排 bug——循环它 50 次来刻画它。 有纪律的隔离每一次都胜过巧妙的提示词。模型很少是问题所在；问题通常出在它周围的系统。 ## 常见问题 ### 我该如何调试一个只是偶尔失败的 AI 智能体？ 从一条已记录的追踪中捕获那个完全相同的输入，在温度 0 下重放它 50 次以上。间歇性故障是触发率很低的真正 bug——量会把逸闻变成一个可复现的样本，让你能够比对并修复。 ### bug 通常在模型里还是在我的代码里？ 在我的生产智能体中，看似的“AI 故障”大约有 70% 是管道问题：格式错误的工具结果、被截断的输入、被吞掉的异常，或步骤之间丢失的状态。在怀疑模型之前，先排除输入层和工具层。 ### 调试智能体我需要的最低限度日志是什么？ 每次运行一个追踪 ID，外加触发器、每次模型调用（完整消息数组）、每次工具调用及其原始结果、以及最终输出的结构化日志。如果一步没被记录，你就没法调试它。 ### 我该如何不再对着线上生产环境调试？ 搭建一个重放装置，它加载一条已记录的追踪，并使用捕获的输入在离线状态下重新运行任意单独的一步。它把一次缓慢、危险的生产往返变成一个快速的本地循环，并成为你回归测试套件的种子。 --- ## 如何衡量 AI 搜索是否真的在为你带来流量 Source: https://alejandrorioja.com/zh/how-to-measure-ai-search-traffic/ Published: 2026-06-08 Tags: GEO, Analytics TL;DR: 大多数 AI 搜索流量表现为来自 chatgpt.com、perplexity.ai 和 claude.ai 的涓涓引荐——但更大的影响是暗的：人们读完 AI 的回答后从不点击。我两者都衡量，用引荐来源衡量点击，用品牌搜索的提升衡量影响力。 ## 目录 _2026 年 6 月更新。_ **TL;DR：** 大多数 AI 搜索流量以来自 `chatgpt.com`、`perplexity.ai` 和 `claude.ai` 的一缕细流引荐到达——一旦你知道该看哪里就很容易统计。但更大的影响是**暗的**：人们读完 AI 的回答，吸收了你的品牌，却从不点击。我用引荐来源细分来跟踪点击，用品牌搜索提升、直接流量变化和引用监测来跟踪影响力。只统计点击会严重低估 AI 搜索。 **运营者视角：** 我运营着一台内容引擎，每天都盯着它的分析数据。"AI 搜索在带来流量吗？"这个问题有一个令人沮丧的答案：是的，但大部分价值不会出现在你的会话报告里。下面讲我如何衡量会出现的那部分，并推断不会出现的那部分。 每个人都想要一个数字——"ChatGPT 给我带来了多少流量？"。诚实的答案是，AI 搜索产生两种非常不同的效应，你需要两种不同的衡量。把它们混为一谈，你要么会恐慌（点击看起来微不足道），要么会自欺欺人（你会错过真正的影响）。 ## 效应 1：直接引荐——可统计，且比你期望的要小 当有人点击 ChatGPT、Perplexity 或 Claude 回答中的引用时，你的分析会记录一个引荐来源。这些是真实、可归因的会话。在 GA4 或任何分析工具中，构建一个捕获 AI 引擎的细分： ``` session source matches any of: chatgpt.com chat.openai.com perplexity.ai claude.ai gemini.google.com copilot.microsoft.com ``` 把它保存为一个"AI 搜索"渠道并随时间观察。几个会让人栽跟头的注意事项： - **引荐来源会泄漏。** 一些 AI 界面会剥离或篡改引荐来源，因此一部分真正的 AI 点击会落到"直接"里。你的引荐计数是一个下限，而非真相。 - **相对于回答展示次数而言，量很低。** AI 引擎在页面上回答问题；只有好奇的少数人会点击进来。每天少量的引荐可能对应着远多得多的、看到你被引用的人。 所以引荐细分是必要的但不充分。它告诉你 AI 搜索正在带来*一些*流量。它严重低估了影响力。 ## 效应 2：暗影响——更大、更难看见的那一半 真正的动作是零点击。有人向 ChatGPT 提问，你的品牌作为推荐来源出现在回答中，而他从不点击——他只是记住了你。这稍后会表现为一次**品牌搜索**或一次**直接访问**，不归因于任何东西。这与让精选摘要难以衡量的动态是同一种，只是被放大了。 你无法直接衡量暗影响，但你可以三角测量它： 1. **品牌搜索量。** 在 Google Search Console 中随时间跟踪对你的名字/品牌的搜索。如果你开始被 AI 引擎引用，且你的品牌展示次数在没有相应营销活动的情况下上升，那次提升就是 AI 影响的指纹。 2. **直接流量趋势。** "直接"会话持续上升却不跟随任何营销活动，往往反映了被剥离引荐来源的 AI 引荐，加上在 AI 提及后直接输入你的人。 3. **辅助转化。** 看看 AI 搜索会话，即便罕见，是否在转化旅程中作为*第一个*触点出现。一个按末次点击微不足道的渠道，按首次触点可能很有意义。 这些都不是干净的数字。合在一起，它们告诉你暗的那一半是否在移动。 ## 跟踪引用，而不只是点击 这是我对 AI 搜索最看重的指标，而它根本不在你的分析里：**我有没有被引用，又是针对哪些查询？** 维护一份对你的业务至关重要的 20-40 个查询的清单，按计划把它们跑一遍 ChatGPT、Perplexity 和 Claude——每周一次就足够了。针对每个查询和引擎记录：你被引用了吗，在什么位置？这是排名跟踪的 GEO 版本，也是领先指标。引用的变化*先于*下游流量和品牌提升，所以在这里你能看到你的 [面向本地企业的 GEO 工作](/geo-for-local-business-getting-a-brick-and-mortar-cited-by-ai-search/) 是否奏效。 我搭了一个小代理来运行这些检查并记录结果——一旦你有了代理栈，这就是件小事。如果你更愿意手动做，一个电子表格加每周 30 分钟的巡查作为起步就很好，或者如果你不想自己搭建代理，也可以用像 [mentioned.at](https://mentioned.at) 这样的专用检测工具。方法论与我的 [ChatGPT 对比 Google 引用测试](/chatgpt-search-vs-google-50-term-test/) 一致，只是持续运行而非一次性。 ## 搭建仪表盘：四个数字，每周 我不会淹没在指标里。对 AI 搜索我盯着四样东西并每周复盘： 1. **AI 引荐会话**——来自引荐来源细分的可统计点击。看趋势，而非绝对值。 2. **引用覆盖率**——我在三个引擎中被引用的、被跟踪查询的百分比。领先指标。 3. **品牌搜索展示次数**——来自 Search Console，作为暗影响的代理。 4. **AI 来源转化**——即便很小，看 AI 会话是否曾经开启一段转化旅程。 如果引用覆盖率在上升而引荐会话持平，那*不是*失败——这通常意味着暗的那一半正在增长，品牌搜索数字应当随之跟上。如果引用覆盖率在下降，那是一个早期警报，要在任何流量数字变动之前采取行动。这与我应用于代理的"衡量领先指标"是同一种纪律，见 [我如何衡量一个 AI 代理是否真的有效](/how-i-measure-whether-an-ai-agent-is-actually-working/)。 ## 拿这些数字怎么办 衡量只有在改变你的做法时才有用。行动手册： - **某个你在意的查询引用覆盖率低？** 那是内容 + [schema](/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/) 问题。页面要么不存在，要么没有为提取而结构化，要么不够权威而无法被拉进回答。 - **被引用了却没有引荐流量？** 在意料之中，没关系——AI 搜索在做品牌的活，不是点击的活。别靠追逐点击来"修复"它；要押注于成为被引用的来源。 - **来自一个引擎的引荐有，其他的却没有？** 各引擎在来源上分歧很大（我测得 ChatGPT 与 Google 之间约 40% 的重叠）。被一个引用并不会帮你拿下其他——分别经营每个引擎的覆盖率。 ## 关于归因诚实的一点说明 抵制住宣称你并不具备的精确度的冲动。2026 年的 AI 搜索衡量是三角测量，不是归因。任何向你兜售"ChatGPT 给你带来了 X 美元"这种干净数字的人，都是在夸大可知的范围，因为引荐来源会泄漏，而最大的效应在设计上就是零点击。正确的姿态：能数的就数，数不到的就盯着代理指标，并依据趋势做决定。即使绝对数字不可信，趋势也是可信的。 ## 常见问题 ### 我如何在 GA4 中看到来自 ChatGPT 或 Perplexity 的流量？ 构建一个把 AI 引擎域名——chatgpt.com、chat.openai.com、perplexity.ai、claude.ai、gemini.google.com、copilot.microsoft.com——作为会话来源进行匹配的渠道/细分。这能捕获点击引荐，尽管有些会被剥离到"直接"，所以把这个计数当作下限。 ### 为什么我的 AI 搜索引荐流量这么低？ 因为 AI 搜索大多是零点击——引擎在页面上回答，只有少数人点击进来。低引荐计数往往与大得多的引用展示次数同时出现。衡量引用和品牌搜索提升，以看到引荐遗漏的那部分。 ### AI 搜索最好的领先指标是什么？ 引用覆盖率：你被跟踪的、对业务至关重要的查询中，在 ChatGPT、Perplexity 和 Claude 中被引用的百分比。它先于流量和品牌提升而动，所以能早早告诉你 GEO 工作是否奏效。 ### 我能从 AI 搜索获得精确的营收归因吗？ 不能，在 2026 年无法可靠地做到。引荐来源会泄漏到"直接"，而大部分影响在设计上就是零点击。把 AI 搜索衡量当作三角测量——统计点击，盯着品牌搜索和直接流量的代理指标，依据趋势而非一个虚假精确的美元数字来做决定。 --- ## 多智能体编排模式：队列、状态与交接 Source: https://alejandrorioja.com/zh/multi-agent-orchestration-patterns-queues-state-handoffs/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: 可靠的多智能体系统靠的不是巧妙的提示词，而是枯燥的分布式系统纪律：智能体之间用持久队列、状态保存在模型之外、交接做到幂等以扛住重试。模型是工人，队列才是主干。 ## 目录 _2026 年 6 月更新。_ **TL;DR：** 可靠的多智能体系统不是靠巧妙的提示词赢来的，而是靠枯燥的分布式系统纪律赢来的。在智能体之间放一个持久**队列**，把**状态保存在模型之外**，并让每一次**交接都幂等**，这样重试就不会重复执行。模型是工人，队列才是主干。把这三点做对，编排就不再可怕。 **操作者视角：** 我那 100 多个智能体里，大多数都是单步的。那些不是单步的——先分类、再充实、再行动的流水线——只有当我不再把它想成"提示词链"、而开始把它想成"带 LLM 工人的任务队列"时，才变得可靠。这是架构，不是提示词工程。 "多智能体"听起来像是智能体彼此对话。实际上，可靠的版本恰恰相反：智能体根本不直接通信。它们把消息丢到队列上，再从队列里取活，编排就藏在它们之间的管道里。下面是那些能在生产环境中扛住的模式。 ## 模式 1：在每个智能体之间放一个持久队列 第一反应是从智能体 A 内部直接调用智能体 B。别这么做。直接调用把两者耦合在一起：B 慢，A 就阻塞；B 失败，A 的工作就丢了；想扩展 B，不动 A 就办不到。 正确的做法是，A 完成自己的工作，然后为 B **入队一条消息**。B 是一个独立的工人，按自己的节奏排空队列。 ```typescript // 智能体 A 完成后通过队列交接——不直接调用 B await env.ENRICH_QUEUE.send({ traceId, type: "enrich", payload: classifierResult, }); // A 的任务已完成。B 会独立地取走它。 ``` 在 Cloudflare 上，我正是用 Workers Queues 来做这件事——和[我使用的智能体技术栈](/the-agent-stack-i-use-to-run-30-production-agents-no-python/)背后是同样的原语。队列免费给你四样东西：**缓冲**（B 宕机也不丢工作）、**重试**（失败的消息会重新投递）、**背压**（峰值会排队而不是崩溃）和**解耦**（扩展或重新部署 B 都不必动 A）。这其中每一项，否则你都得自己手搓并搞砸。 ## 模式 2：始终把状态保存在模型之外 最常见的多智能体 bug，是假设模型在各步骤之间记得什么。它不记得。每次模型调用都是无状态的，唯一的记忆就是你放进提示词里的东西。所以"这个任务在流水线里走到哪儿了"的事实来源，必须存在数据库里，而不是对话里。 我维护一条单一的任务记录，每个智能体都读取并更新它： ```typescript interface JobState { traceId: string; stage: "classified" | "enriched" | "acted" | "done" | "failed"; data: Record; attempts: number; updatedAt: number; } ``` 每个智能体都跑同一个循环：**读取**任务状态、干自己的活、**写入**新状态、把下一阶段入队。模型从不持有状态——它把相关切片作为输入接收，并返回一个结果。这正是让系统可重启的关键：如果某个工人在任务中途挂掉，状态记录仍然准确地记着事情走到了哪儿，重新投递的队列消息会从那里接手。它也让调试变得可控，因为状态表是每个任务旅程的可查询记录——这和[我如何衡量一个智能体是否真的在工作](/how-i-measure-whether-an-ai-agent-is-actually-working/)里同样的度量心态。 ## 模式 3：让每一次交接都幂等 队列保证的是*至少一次*投递，而非恰好一次。这意味着一条消息可能被投递两次——网络抖动、重试、重新部署。如果你智能体的动作不是幂等的，双重投递就会重复执行：两封确认邮件、两份预订、两笔扣款。这是最棘手的一类编排 bug，也是团队在生产环境才发现的那一类。 修复办法是用一个键让动作幂等： ```typescript async function handleEnrich(msg: QueueMessage, env: Env) { const job = await getJob(env, msg.traceId); if (job.stage !== "classified") { // 已经处理过这一阶段——这是重复投递。跳过。 return; } const result = await enrich(job.data); await advanceJob(env, msg.traceId, "enriched", result); await env.ACT_QUEUE.send({ traceId: msg.traceId, type: "act" }); } ``` 阶段检查让操作可以安全地运行两次：第二次投递发现任务已经推进，就什么都不做。对于外部副作用（发邮件、扣信用卡），把一个幂等键传给下游 API，让*它*也去重。假设每条消息都会被投递两次，并把设计做到这无害——因为它迟早会发生。 ## 模式 4：编排者 vs 编舞——刻意做选择 接线流程有两种方式，正确的选择取决于复杂度。 **编舞**（我默认采用的）：每个智能体只知道下一步并把它入队。流程从链条中涌现。简单、去中心化、易于扩展——插入一个队列就能加一个阶段。缺点是没有一个单独的地方描述整个流程，所以复杂的流水线可能变得难以推理。 **编排**（一个中央协调者）：一个编排者掌握流程，依次调用每个智能体，并根据结果决定下一步。整个流程都住在一个可读的地方，分支逻辑是显式的。代价是一个本身必须持久的中央组件——如果编排者自己的状态没有外置（模式 2），它就成了单点故障。 我的规则：**在分支变复杂之前用编舞，之后用持久的编排者。** 一条线性的三阶段流水线是编舞。一个带条件路由、并行扇出和汇合的流程，需要一个状态存在数据库里、以便崩溃后能恢复的编排者。 ## 模式 5：扇出、扇入而不丢失任何一块 当一个任务衍生出 N 个并行子任务（充实 50 条记录、总结 20 份文档），而你需要等它们全部完成才能继续时，你就需要一次**汇合（join）**。诀窍是任务状态里的一个计数器： 1. 父任务入队 N 条子消息，并在任务记录里写入 `expected: N, completed: 0`。 2. 每个子任务干完自己的活，并**原子地递增** `completed`。 3. 把 `completed` 推到等于 `expected` 的那个子任务，把下一阶段入队。 这个原子递增是承重的——没有它，两个同时完成的子任务可能都以为自己不是最后一个，于是汇合永远不触发。用一个数据存储能原子递增的计数器，或者用一个事务。这个模式让你能把流水线中昂贵的中段并行化（往往是 Haiku 能廉价处理的活——见 [Haiku 与 Sonnet 的成本算账](/ai-agent-cost-math-when-haiku-beats-sonnet)），同时在末尾保持一次干净的汇合。 ## 我会略过的东西 做这一切，你都不需要一个重量级的智能体框架。队列、一张状态表和幂等键，都是每个平台早已具备的原语。我见过有团队为了拿到队列免费就给的功能，去搬来精心设计的多智能体框架，结果继承了一个比它所替换的管道更难调试的黑盒。从枯燥的原语开始。只有当你真切感受到某个框架能解决的具体痛点时，才去伸手拿它。 总结：智能体是无状态的工人，队列是持久的主干，状态住在数据库里，每一次交接都能安全地运行两次。这就是全部的游戏。 ## 常见问题 ### 智能体应该彼此直接调用，还是走队列？ 走队列。直接调用会耦合智能体——一方的失败或缓慢会传播到另一方，而且你无法独立扩展或重新部署。持久队列免费给你缓冲、重试、背压和解耦。 ### 多智能体状态应该存在哪里？ 存在模型之外、数据库里，作为一条每个智能体都读取并更新的任务记录。模型调用是无状态的，所以流水线进度的事实来源必须是外部的——这正是让系统在崩溃后可重启的关键。 ### 我如何防止一个智能体在同一个任务上执行两次？ 让交接幂等。行动前先检查任务的阶段，若已推进就什么都不做，并把幂等键传给外部 API。队列至少投递一次，所以假设每条消息都可能到达两次，并把设计做到重复无害。 ### 我需要一个多智能体框架吗？ 通常不需要。持久队列、一张状态表和幂等键，用你平台早已提供的原语就能覆盖大多数生产需求。只有当你撞上某个框架能独到解决的具体问题时才采用它，而不是默认就用。 --- ## 我用来无所畏惧地发布 AI 智能体的评估框架 Source: https://alejandrorioja.com/zh/the-eval-harness-i-use-to-ship-ai-agents/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: 无所畏惧地发布智能体来自一件事：一套评估框架。一组固定的评分测试用例，自动打分（断言加上一个 LLM 评判），在每次提示词或模型改动前运行。分数守住，就发布。测试集是用真实的生产故障构建的。 ## 目录 _2026 年 6 月更新。_ **摘要：** 我之所以能在一个上线的智能体上改提示词或换模型而不必屏住呼吸，靠的是一件事：一套**评估框架**。一组固定的评分测试用例，自动打分——能写硬断言的地方写硬断言，写不了的地方用 LLM 评判——在每次改动前运行。分数守住，我就发布。分数下降，我就不发。测试集不是合成的；它是用真实的生产故障构建的，所以每个 bug 都会变成一项永久的回归测试。 **操作者视角：** 在 100 多个智能体里，我有信心去碰的和我害怕去碰的，区别就在于有没有评估。没有评估框架，每一次提示词微调都是一场赌博。评估框架把"我觉得这个更好"变成"这个可量化地好了 4 分，而且什么都没弄坏"。这就是全部的解锁所在。 你不会不写测试就发布代码。人们却不停地不写评估就发布智能体，然后纳闷为什么一次"小小的提示词微调"搞坏了生产。评估框架就是为非确定性软件准备的测试套件。这是我实际运行的那一套。 ## 从真实故障构建的测试集开始 框架的好坏取决于它的测试用例，而最好的测试用例来自生产，而非你的想象。每次智能体在真实环境里失败时，我都会捕获确切的输入（我把每次运行都连同一个追踪 ID 记录下来——见[如何在生产环境中调试智能体](/how-to-debug-an-ai-agent-in-production)），并把它变成一个评估用例： ```typescript interface EvalCase { id: string; input: AgentInput; // 确切的生产输入 expected?: string; // 有标准答案时的基准真值 assertions: Assertion[]; // 必须通过的硬性检查 rubric?: string; // 用于 LLM 评判，当输出是开放式时 } ``` 这里有两条实践很重要。**从生产中提取**，这样你的评估测试的是真正会坏的东西，而不是你猜测可能会坏的东西。以及**覆盖整个范围**——正常路径、边缘情况、对抗性输入，以及那些会导致静默失败的空/格式错误输入。一套精选的 30 到 50 个用例的测试集，比 500 个敷衍的用例抓到的多得多。我宁愿有 40 个各自代表一种真实失败模式的用例，也不要一千个全都测试同一条简单路径的用例。 ## 先用断言打分，再用 LLM 评判 并非每个输出都需要一个模型来打分。我会去拿能用的最便宜的打分器。 对一切结构化的东西用**硬断言**。输出能解析为有效的 JSON 吗？包含必需字段吗？提取出的日期在范围内吗？它是否用正确的参数调用了正确的工具？这些是确定性的、免费的、毫无歧义的——能写多少就写多少。 ```typescript const assertions: Assertion[] = [ (out) => isValidJSON(out), (out) => parse(out).category in ALLOWED_CATEGORIES, (out) => parse(out).confidence >= 0 && parse(out).confidence <= 1, ]; ``` 对开放式的其余部分用 **LLM 评判**——语气、有用性、"它到底有没有回答问题"。在这里你给模型输入、输出和一份评分标准，让它打分。两条规则能让评判保持诚实：把评分标准做得**具体**（带有描述性锚点的 1 到 5 分量表胜过"给质量打分"），并用一个**强模型作为评判**——评判是一项推理任务，所以即便智能体本身按照[成本计算](/ai-agent-cost-math-when-haiku-beats-sonnet)跑在 Haiku 上，这也是我乐意为 Sonnet 付费的地方。模糊的评分标准或羸弱的评判会给你看起来像信号的噪声。 ## 在每次改动前运行框架 框架的存在是为了回答一个问题：*这次改动让智能体变好了还是变差了？* 所以我在每次提示词编辑、模型替换或工具改动之前都运行它。 ```bash # main 上的基准 npm run eval -- --suite=booking-agent > baseline.json # 做出改动，然后重新运行 npm run eval -- --suite=booking-agent > candidate.json # 比较 npm run eval:diff baseline.json candidate.json ``` 差异报告会显示汇总分数、逐用例的通过/失败，以及——至关重要的——**具体是哪些用例发生了回归。** 一个在三个用例静默损坏的同时往上走的汇总分，不是改进；那是一笔我想看到并批准的取舍，而不是悄悄溜过去的那种。盯着逐用例的差异，就是你避免"修好一个、弄坏两个"的办法——正是这种失败模式让人们害怕自己的提示词。 ## 设一道回归闸门，让它拦下来 一旦你信任了框架，就把它作为闸门接入通往生产的路径。我的规则很直白：**任何让分数跌破基准阈值的改动都不发布。** 不是"我回头看看"——而是被拦下，和一个失败的 CI 测试一样。 ```typescript const PASS_THRESHOLD = 0.90; // 90% 的用例必须通过 if (candidate.passRate < PASS_THRESHOLD || candidate.passRate < baseline.passRate) { throw new Error(`Eval regression: ${candidate.passRate} < ${baseline.passRate}`); } ``` 正是这一点把评估从一个锦上添花的东西，变成让你能快速行进的那件东西。闸门让"无所畏惧地发布"字面意义上成真：一次糟糕改动的最坏情况是一次飘红的评估运行，而不是一场生产事故。而且因为测试集每次有东西损坏时都会增长，闸门会随着时间自行变得更严格、更具保护性。 ## 在打分中考虑非确定性 一个让人栽跟头的微妙之处：同一个输入在不同运行中可能得到不同的分数，因为模型的采样方式不同。如果你每个用例只跑一次，你会看到幻影回归——一个"坏了"的用例其实只是采样噪声。 两种缓解办法。在 **`temperature: 0`** 下运行评估以缩小方差（它无法完全消除）。而对那些你见过闪烁的用例，**跑 N 次并取通过率**，而不是单次的通过/失败。一个 10 次通过 9 次的用例，状态比一个 10 次通过 5 次的更好，哪怕两者都能显示一次飘绿的单次运行。这与我[调试间歇性失败](/how-to-debug-an-ai-agent-in-production)时用的"用量胜于轶事"原则相同——一次运行是观点，五十次运行是数据。 ## 用生产监控闭合回路 评估框架针对已知用例做测试。生产则抛出新奇的用例。所以回路是这样的：监控线上行为，抓住一种新的失败模式，把它变成一个评估用例，修好它，于是它现在被永久守护了。监控这一侧——在线上流量中追踪成功率、输出有效性和每次运行的成本——是我在[我如何衡量一个 AI 智能体是否真的在工作](/how-i-measure-whether-an-ai-agent-is-actually-working/)中讲到的。评估和监控是同一系统的两半：监控找出 bug，评估确保它们保持死透。 那个反馈回路才是真正的产品。任何单一的评估集都会过时；而一个把每次生产故障都转化为永久测试的*流程*，每周都会变得更强。这就是一个智能体如何从"碰都不敢碰"变成我会在某个周五下午眼都不眨地重构的东西。 ## 常见问题 ### 一个 AI 智能体评估集里包含什么？ 把真实的生产输入变成评分用例——正常路径、边缘情况、对抗性和格式错误的输入——每个都配硬断言，对开放式输出再配一份 LLM 评判评分标准。从真实故障中提取的 30 到 50 个用例，胜过数百个全都测试简单路径的合成用例。 ### 我该用 LLM 来给智能体输出打分吗？ 凡是输出结构化的地方（有效 JSON、正确字段、正确的工具调用）都用硬断言——它们免费且确定。把 LLM 评判留给语气、有用性这类开放式特质，配上具体的评分标准和强评判模型，这样你得到的是信号，而不是噪声。 ### 我如何阻止一次提示词改动悄悄搞坏生产？ 在每次改动前运行评估框架并与基准做差异比对，盯着逐用例的回归，而不只是汇总分数。然后用结果为部署设闸，任何跌破基准阈值的改动都像失败的测试一样被拦下。 ### 我如何处理评估中的非确定性？ 在温度 0 下运行以降低方差，对会闪烁的用例，多次运行并用通过率打分，而不是单次运行。一个 10 次中通过 9 次的用例，比一个 10 次中通过 5 次的更健康，即便单次运行两者都显示为绿。 --- ## 如何用AI代理自动化你的新闻通讯 Source: https://alejandrorioja.com/zh/how-to-automate-your-newsletter-with-an-ai-agent/ Published: 2026-06-06 Updated: 2026-06-24 Tags: AI Agents, Growth TL;DR: Claude代理读取我的内容队列，选择本周最强的切入角度，用我的语气起草新闻通讯，按参与度层级分段列表，并通过Kit API安排发送——全程无需我打开编辑器。我查看渲染预览并点击批准。困难的创意工作是我的；机械执行是代理的。 ## 目录 _2026年6月更新。_ **TL;DR：** Claude代理读取我的内容队列，选择本周最强的切入角度，用我的语气起草新闻通讯，按参与度层级分段列表，并通过Kit API安排发送——全程无需我打开编辑器。我查看渲染预览并点击批准。困难的创意工作是我的；机械执行是代理的。 **[运营者阅读]** 一个持续发送的新闻通讯胜过那个"更好"但靠灵感驱动才发的。制约因素是执行开销，不是创意。我有想法；我没有每周格式化、安排和分段它们的带宽。代理消除了这个差距。 ## 大多数新闻通讯工作流中真正的瓶颈 大多数新闻通讯自动化建议关注错误的事情：欢迎序列、自动化、标签逻辑。这些都很好，但解决不了每周的创建问题。 真正的阻碍是：你知道想说什么，但坐下来格式化、写主题行变体、选择合适的受众段、在正确时间安排发送，每周需要2-3小时的上下文切换。乘以52周，你已经花了整整一周只是在*发送*新闻通讯。 代理处理"我知道本周的角度是什么"之后的每个步骤。 ## 我使用的技术栈 - **[Kit](/recommends/convertkit)**（前身为ConvertKit）——电子邮件平台。出色的API、稳固的订阅者标签、清晰的分析。代理友好的API是让我选择它的原因。 - **Claude (Anthropic SDK)**——生成层 - **Cloudflare Workers**——定时触发器（每周二上午8点CT运行） - **Airtable**——内容队列和审批收件箱 如果你不在Kit上，相同的模式适用于任何有REST API可以创建和安排广播的平台。 ## 第一步：内容队列 代理需要一个关于"我们在写什么"的真实来源。我的是一个[Airtable](/recommends/airtable)表，包含以下列： - `Topic`——角度或问题 - `Status`——Queue / Approved / Sent - `Tier`——是否面向所有订阅者或仅限高参与度订阅者 - `Notes`——任何约束（避免这种语气、包含这个链接等） 每周，我花10分钟在队列中添加2-3个主题。这是我的创意输入。其余的是代理的工作。 ## 第二步：起草代理 ```typescript // workers/newsletter-agent/index.ts import Anthropic from "@anthropic-ai/sdk"; import Airtable from "airtable"; const client = new Anthropic(); const VOICE_SYSTEM = `You are writing a weekly newsletter for Alejandro Rioja's subscribers. His audience: founders and operators interested in AI agents, SEO, and growing a one-person business. Voice: direct, first-person, practitioner. No hype, no "exciting times," no excessive bullet lists. Structure every newsletter as: 1. One-sentence hook (the problem or observation) 2. The core insight (3–5 paragraphs, no headers, conversational) 3. One concrete action the reader can take this week 4. A short sign-off (2 sentences max) Subject line: specific, outcome-oriented, under 50 chars. No clickbait. Return JSON: { "subject": "...", "preheader": "...", "body": "..." }`; async function getNextTopic(): Promise<{ id: string; topic: string; notes: string; tier: string }> { const base = new Airtable({ apiKey: process.env.AIRTABLE_API_KEY }).base(process.env.AIRTABLE_BASE_ID!); const records = await base("Newsletter Queue") .select({ filterByFormula: "{Status} = 'Queue'", sort: [{ field: "Created", direction: "asc" }], maxRecords: 1 }) .firstPage(); if (!records.length) throw new Error("Queue is empty. Add topics."); const r = records[0]; return { id: r.id, topic: r.get("Topic") as string, notes: (r.get("Notes") as string) ?? "", tier: (r.get("Tier") as string) ?? "all" }; } async function draftNewsletter(topic: string, notes: string): Promise<{ subject: string; preheader: string; body: string }> { const msg = await client.messages.create({ model: "claude-sonnet-4-6", max_tokens: 2048, system: VOICE_SYSTEM, messages: [{ role: "user", content: `Write this week's newsletter on: "${topic}". Additional notes: ${notes || "none"}` }], }); const text = (msg.content[0] as any).text.replace(/```json\n?/, "").replace(/```/, "").trim(); return JSON.parse(text); } async function scheduleWithKit(draft: { subject: string; preheader: string; body: string }, tier: string): Promise { const segmentId = tier === "engaged" ? process.env.KIT_ENGAGED_SEGMENT_ID : null; const sendAt = new Date(); sendAt.setDate(sendAt.getDate() + ((4 - sendAt.getDay() + 7) % 7)); // next Thursday sendAt.setHours(9, 0, 0, 0); // 9am CT const payload: any = { broadcast: { subject: draft.subject, content: draft.body, description: draft.preheader, send_at: sendAt.toISOString(), email_layout_template: "minimal", }, }; if (segmentId) payload.broadcast.segment_id = segmentId; const res = await fetch("https://api.kit.com/v4/broadcasts", { method: "POST", headers: { "Content-Type": "application/json", "X-Kit-Api-Key": process.env.KIT_API_KEY! }, body: JSON.stringify(payload), }); const data = await res.json(); return data.broadcast?.id ?? ""; } export default { async scheduled(_event: ScheduledEvent, env: Env) { // Inject env vars Object.assign(process.env, env); const { id, topic, notes, tier } = await getNextTopic(); const draft = await draftNewsletter(topic, notes); const broadcastId = await scheduleWithKit(draft, tier); // Mark as Approved in Airtable (not Sent — human reviews the Kit preview before confirm) const base = new Airtable({ apiKey: env.AIRTABLE_API_KEY }).base(env.AIRTABLE_BASE_ID); await base("Newsletter Queue").update(id, { Status: "Approved", KitBroadcastId: broadcastId }); console.log(`Scheduled broadcast ${broadcastId} for topic: ${topic}`); }, }; ``` ## 第三步：审批步骤 代理在Kit的草稿状态下创建广播，并将Airtable记录标记为"Approved"。Kit向我发送带有预览链接的通知。我点击它，阅读，如果看起来没问题，我确认发送。如果我想要更改，直接在Kit中编辑。 这是防止代理在外发邮件上完全自主的关卡。我信任草稿大约90%的时间。审查中发现的10%——语气稍微不对、我想验证的统计数据、想添加的链接——值得那3分钟的审查。 ## 代理处理的我再也不想做的事 - 编写主题行变体并选择最佳的 - 格式化预标题文本 - 计算正确的发送时间（我的受众在周四早上打开；代理知道这一点） - 根据主题层级正确分段 - 将所有内容记录到Airtable以保留记录 ## 我仍然拥有的 *想法*。队列中的主题是我的。角度是我的。代理是清晰简报的出色执行者；它不是战略层。如果我把一个糟糕的主题放入队列，我会得到一封关于糟糕主题的写得很好的新闻通讯。 还有：第一次审查关卡。每一次发送在发出之前都会经过我的眼睛。这不会改变。 ## 运营者的底线 如果你每周花超过一个小时在新闻通讯机制上——格式化、安排、分段——你应该自动化它。Kit API很干净，Worker cron触发器稳如磐石，Claude草稿质量足够高，让我可以批准约90%的第一稿而不作修改。在Airtable中建立队列，连接Worker，然后回归创造想法而不是执行发送。 --- ## 如何在AI搜索中排名，无需撰写任何新博文 Source: https://alejandrorioja.com/zh/how-to-rank-in-ai-search-without-writing-a-single-new-blog-post/ Published: 2026-06-06 Updated: 2026-06-28 Tags: GEO, SEO TL;DR: AI引擎引用直接回答问题、声明清晰作者身份、以便于检索的方式构建知识的内容。大多数现有博文可以通过编辑（而非重写）来满足这三个标准。方案：添加直接的TL;DR、强化实体信号、添加FAQ架构、提交到llms.txt。新内容是可选的；重组不是。 ## 目录 _2026年6月更新。_ **TL;DR：** AI引擎引用直接回答问题、声明清晰作者身份、以便于检索的方式构建知识的内容。大多数现有博文可以通过编辑（而非重写）来满足这三个标准。方案：添加直接的TL;DR、强化实体信号、添加FAQ架构、提交到llms.txt。新内容是可选的；重组不是。 **【运营者视角】** 在撰写第一篇新的GEO定向文章之前，我对341篇现有文章执行了这个流程。ChatGPT和Perplexity中的引用增加了。新内容加速了收益——但从现有内容审计开始，比预期更快地得到了回报。 ## 为什么AI引擎不引用你现有的内容 在写任何新内容之前，先问：为什么我已有的内容没有被引用？ 答案几乎从来都不是"内容不存在"。通常是以下之一： 1. **顶部没有直接答案** — 文章把答案埋在第6段 2. **作者信号薄弱** — 没有清晰的作者实体，内容中没有证书 3. **结构噪音** — 长篇介绍、无关章节、没有清晰的标题层次 4. **没有机器可读的问答** — AI引擎喜欢结构化的问答对；大多数博文没有 5. **不在任何AI可读索引中** — 没有llms.txt，没有爬虫能找到的站点地图 这五个问题都可以在现有内容上修复。没有一个需要新文章。 ## 四步改造流程 ### 第一步：在前100个字中添加直接的TL;DR AI引擎做的事与你浏览时做的类似——在深入之前寻找直接答案。如果你的文章以故事、问题或背景介绍开头，模型可能永远不会读得足够深来找到你的实际答案。 解决方案：在前100个字中添加 **TL;DR** 块。格式：结论 → 原因 → 限制或注意事项。两到四句话。不要废话。 改前示例： > *你有没有想过为什么有些企业似乎主导了谷歌搜索结果？在这篇文章中，我们将探讨排名最高的网站所使用的策略……* 改后示例： > **TL;DR：** 2026年推动本地SEO的三件事：Google商业档案完整性、目录引用一致性以及NAP数据的结构化架构。"每天发布"和"快速获得100条评论"等策略相对于这三点是次要的。上限是你GBP的准确性——先修复那个。 改写后不更长。只是内容前置了。 ### 第二步：强化实体信号 AI引擎构建知识图谱。他们想知道：谁写了这个、关于什么，作者在这个话题上是否可信？ 对于作者实体：确保你的关于页面从每篇文章链接，你的作者架构包含指向LinkedIn和Twitter的`sameAs`链接，每篇文章的作者简介提到具体证书（不是"营销专业人士"——"为三家SaaS公司从0运营SEO到每月100K访客"）。 对于主题实体：使用你受众搜索的精确术语。如果你在介绍"GEO"（生成引擎优化），请在某处说出"生成引擎优化"，而不只是缩写。模型使用术语共现来分类内容。 ### 第三步：为每篇回答问题的文章添加FAQ架构 FAQPage架构是GEO引用中杠杆最高的架构类型，因为它以模型可以直接解析的格式明确地将问题映射到答案。 取出你的文章隐式回答的3-5个问题，使它们明确： ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "How long does it take to rank in AI search?", "acceptedAnswer": { "@type": "Answer", "text": "Most sites see initial citation improvements within 4–8 weeks of restructuring existing content for direct answers and adding FAQ schema. Brand-new domains take longer — expect 3–6 months before consistent citations appear." } } ] } ``` 将其添加到文章的``或通过CMS的架构字段。每个主要AI引擎都会爬取并解析这个。 ### 第四步：提交到llms.txt和平台的AI索引 `llms.txt`是一个新兴标准——位于`yoursite.com/llms.txt`的纯文本文件，告诉AI爬虫哪些内容质量高以及如何优先排序。它类似于`robots.txt`但面向LLM。 基础llms.txt： ``` # llms.txt # alejandrorioja.com — AI agents and GEO for operators ## Priority content - /blog/geo-for-local-business (definitive guide, updated monthly) - /blog/schema-markup-for-ai-engines (technical reference) - /blog/how-to-get-cited-by-chatgpt (step-by-step) ## Author Alejandro Rioja — operator, AI agent builder, GEO practitioner. LinkedIn: https://linkedin.com/in/alejandrorioja ``` 结合包含`lastmod`时间戳的干净站点地图。AI爬虫会降低看起来过时的内容的优先级。 ## 如何优先选择哪些文章进行改造 并非每篇文章都值得改造。将第一轮重点放在： 1. **已经在问题格式关键词中排名第1页的文章** — 这些最接近被引用；它们只需要结构修复 2. **关于你有可验证公信力的主题的文章** — AI引擎非常重视作者身份；你的证书相关的文章从实体信号获得引用提升 3. **直接回答问题的文章vs提供信息的文章** — "如何做X"和"什么是X"比列表文章或观点文章改造效果更好 使用你的Search Console数据：过滤问题格式的查询（如何、什么、为什么、最好的方法）。排名5–15位的文章是你最好的改造候选——它们相关但还不够接近顶部被引用。 ## 大多数人犯的错误 他们在改造现有文章档案之前就为AI搜索写了新优化文章。新内容有帮助，但现有文章有年龄、反向链接和爬取历史的优势。一篇结构良好的三年老文章会在同一主题上几个月内超越新文章。 先做改造。在有真正缺口的地方写新内容——你现有文章根本没有回答的问题。这才是新胜过旧的时候。 ## 运营者的最终结论 如果你有超过20篇现有博文，你的GEO工作从审计和改造开始，而不是内容日历。在你的前20篇文章上添加TL;DR、强化实体信号、添加FAQ架构并提交到llms.txt，然后再写任何新内容。你会在数周而非数月内看到引用改善——并且你会有更清晰的基准来衡量新内容是否真正推动了指标。 --- ## 我构建了一个运行 Facebook 广告的 Claude 技能——这是代码 Source: https://alejandrorioja.com/zh/i-built-a-claude-skill-that-runs-my-facebook-ads-heres-the-code/ Published: 2026-06-06 Updated: 2026-06-20 Tags: AI Agents TL;DR: 我构建了一个 Claude 技能，通过 Graph API 读取我的 Meta Ads 账户，识别低效广告，以我的品牌语调重写广告文案，并创建新的广告集——所有这些无需我打开广告管理器。整个项目不超过 300 行 TypeScript。回报是立竿见影的：我将每周广告管理时间从约 3 小时缩短到约 20 分钟。 ## 目录 _2026 年 6 月更新。_ **TL;DR：** 我构建了一个 Claude 技能，通过 Graph API 读取我的 Meta Ads 账户，识别低效广告，以我的品牌语调重写广告文案，并创建新的广告集——所有这些无需我打开广告管理器。整个项目不超过 300 行 TypeScript。回报是立竿见影的：我将每周广告管理时间从约 3 小时缩短到约 20 分钟。 **[运营者视角]** 我为 Pickleland 和我的咨询品牌投放广告。两个账户，不同受众，持续的创意疲劳。我曾将周日下午花在广告管理器里做本该由模型完成的工作。于是我将其自动化了。 ## 为什么我停止手动管理 Facebook 广告 运营 Facebook 广告的实际工作分为三项任务： 1. **监控** — 检查哪些广告集在烧钱，哪些在赚钱 2. **诊断** — 弄清楚*为什么*某个广告效果不佳（创意疲劳？定向不准？落地页问题？） 3. **迭代** — 撰写新文案，创建新广告集，调整预算 任务 1 是机械性的。任务 3 大部分是机械性的（有语调约束）。任务 2 需要判断力——也是唯一需要人工介入的环节。 Claude 技能可以完成 1 和 3。在任何内容发布前，我会审核任务 2 的输出。这就是我最终确定的架构。 ## Meta Graph API 设置（这是烦人的部分） 在写任何代码之前：你需要一个 Meta Business 账户、一个系统用户和一个永久访问令牌。Facebook 的开发者门户体验不佳，但流程如下： 1. 在 developers.facebook.com 创建 **Meta App**（类型：Business） 2. 添加 **Marketing API** 产品 3. 在你的业务组合 → 设置 → 用户 → 系统用户下，创建一个系统用户，并赋予其在广告账户上的 `ADVERTISER` 角色 4. 生成具有以下权限的令牌：`ads_read`、`ads_management`、`business_management` 将令牌存储为 `META_ACCESS_TOKEN`，将广告账户 ID（格式：`act_XXXXXXXX`）存储为 `META_AD_ACCOUNT_ID`，写入 `.env` 文件。 ## 技能文件结构 ``` .claude/skills/fb-ads/ SKILL.md ← Claude 读取的指令 index.ts ← 实际的工具实现 types.ts ← 共享类型 ``` `SKILL.md` 告诉 Claude 何时以及如何使用该技能。我的文件内容如下： ```markdown # Facebook Ads Manager Skill Use this skill when the user says "check my ads", "run ads report", "pause underperformers", or "write new ad copy". Never run this without explicit user instruction — it touches live ad spend. ## What it can do - Pull performance data for all active ad sets (last 7 or 30 days) - Flag ad sets with ROAS < 1.5 or CTR < 0.8% as underperformers - Rewrite ad copy for flagged creatives in Ale's voice - Create new ad sets with revised copy (PAUSED by default — you approve before activating) ## What it will NOT do - Change budgets on live ad sets without explicit confirmation - Activate new ad sets automatically - Delete anything ``` "永不自动激活"的约束是不可协商的。该技能以暂停状态创建内容。我手动审核并激活。任何涉及实时广告支出的操作都需要人工检查点。 ## TypeScript 核心代码 （代码块保留英文——仅翻译周围的文字。） ## 日常使用方式 该技能从 Claude Code（我的日常工具）中调用。典型的周一早晨工作流： ``` > check my ads from the last 7 days ``` Claude 运行 `runAdsReport(7)`，将结果格式化为表格，标记低效广告，并询问是否需要重写文案。我说是。它生成新文案，并排显示两个版本，然后以新创意创建暂停状态的广告集。我在广告管理器中审核，激活喜欢的，归档失败的。 总耗时：20 分钟。告别周日下午的广告管理器时光。 ## 这无法替代的部分 该技能无法判断产品与市场契合度问题是否伪装成了文案问题。如果 ROAS 普遍糟糕，那是漏斗或产品本身的问题，而不是标题的问题。Claude 会忠实地在破损漏斗上重写文案——但重写无法拯救它。 诊断步骤仍然是我的职责。我阅读报告，查看漏斗数据，然后决定我们是在迭代创意，还是解决更上游的问题。代理在一切事务上都很快，*唯独*这个判断除外。 ## 运营者的结论 如果你在手动管理广告，每周打开广告管理器超过两次，那你在做脚本本该做的运营工作。Graph API 有完善的文档，Meta 的权限流程虽然烦琐，但只需配置一次。用一个下午构建这个技能。第一周就能看到时间回报。 --- ## 我实际用来运营业务的5款AI工具（2026年） Source: https://alejandrorioja.com/zh/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/ Published: 2026-06-06 Updated: 2026-06-21 Tags: AI Agents, Growth TL;DR: 五款工具：Claude（运营者层+编程）、Cursor（TypeScript开发）、Airtable（所有代理的数据骨干）、Kit（通讯+邮件自动化）和Cloudflare Workers（代理托管）。我尝试过的其他所有工具都被这些之一所取代或完全淘汰。如果今天必须重新开始，这就是我会重建的技术栈。 ## 目录 _2026年6月更新。_ **TL;DR：** 五款工具：Claude（运营者层+编程）、Cursor（TypeScript开发）、[Airtable](/recommends/airtable)（所有代理的数据骨干）、[Kit](/recommends/convertkit)（通讯+邮件自动化）和Cloudflare Workers（代理托管）。我尝试过的其他所有工具都被这些之一所取代或完全淘汰。如果今天必须重新开始，这就是我会重建的技术栈。 **【运营者视角】** 我经营两个业务：个人AI咨询品牌（alejandrorioja.com）和Pickleland——位于德克萨斯州普鲁格维尔的匹克球场馆。不同的背景、不同的受众、不同的运营。这五款工具驱动着两者。我列出它们不是因为它们流行；我列出它们是因为我已经删除了它们的替代品。 ## 1. Claude — 运营者层 Claude（通过Claude Code和Anthropic SDK）是一切运转的大脑。我以三种模式使用它： **Claude Code** 是我的日常开发工具。我编写TypeScript、构建代理、调试基础设施问题和管理内容——全部通过Claude Code界面完成。它不仅仅是自动补全；它是一个可以阅读500行文件、理解意图并提出我未曾考虑的重构方案的协作者。 **Anthropic SDK** 驱动着我构建的每一个代理。我的通讯代理、Facebook广告技能、内容流水线、OG卡片生成器——后端全部是Claude。模型质量足够高，约85%的时间我信任第一稿。 **Claude的语音和品牌**判断力被低估了。当我写需要听起来像我的内容时，我发现Claude加上详细的系统提示词优于我测试过的所有其他模型。诀窍是一个具体的、有观点的系统提示词——不是"用随意的语气写"，而是"像Alejandro一样写：直接、实践者视角、无炒作、编号、第一人称、带诚实的注意事项。" 我支付Claude Max费用。这是我使用最多的订阅，ROI无可比拟。 ## 2. Cursor — TypeScript在此编写 Cursor是IDE。大约一年前我从VS Code切换过来，没有回头。 Tab补全足够快，真正改变了我编写代码的方式——我在更高层次思考，让Cursor处理语法样板代码。AI建议的差异视图很清晰。多文件上下文窗口意味着我可以要求它更新一个函数，它也会更新调用者。 我不用Cursor做架构决策。我仍然在纸上或Claude中草拟这些。但一旦设计清晰，Cursor是从设计到运行TypeScript最快的路径。 最大突破：Cursor + Claude Code并行使用。我用Claude Code进行高层规划和代理编排；用Cursor进行具体的实现细节工作。它们不冲突——覆盖不同的层次。 ## 3. Airtable — 数据骨干 我运行的每个AI代理都需要一个读写的地方。那个地方是[Airtable](/recommends/airtable)。 以下是我在两个业务中使用它的方式： - **内容队列** — 进行中的文章和通讯主题，带状态跟踪 - **预订记录** — 从预订系统同步的Pickleland场地预订 - **联盟链接目录** — 105+个含元数据的slug，内容代理在生成时读取 - **代理审计日志** — 运行了什么、何时运行、产出了什么、任何错误 API清晰快速。Airtable不是高吞吐量工作负载的数据库——但对于代理辅助表、审查队列和人工审批工作流，它恰好是正确的工具。可视化界面意味着我可以在不写查询的情况下检查任何表。 我尝试过的替代方案：Notion数据库。Notion API较慢，数据模型对代理读取来说更笨拙。Airtable在代理相邻数据方面获胜。 ## 4. Kit — 通讯和邮件自动化 我切换到[Kit](/recommends/convertkit)（前身为ConvertKit）只有一个原因：API真的很好。 大多数邮件平台将API视为事后想法。Kit将其视为一流产品。我可以创建广播、安排发送、按标签分段并读取分析——全部以编程方式完成。我的通讯代理不需要我触碰编辑器就能完成所有这些。 我使用的Kit特定功能： - **广播API** — 我的代理每周以编程方式创建计划广播 - **订阅者标记** — 我按行为标记订阅者（打开了最近5次发送="活跃"；60天未打开="有风险"），代理相应地定向到各个细分群体 - **表单+着陆页** — 干净、快速加载、无代码。我不以编程方式操作这些；它们就是好用。 如果你在Mailchimp或遗留平台上：迁移值得。Mailchimp的API需要三个额外调用来完成Kit一次调用就能做到的事。 ## 5. Cloudflare Workers — 代理居住的地方 每个计划代理都在Cloudflare Workers上运行。理由：全球边缘部署、免费层零冷启动，以及一个真正有效的cron触发系统。 我的代理不需要服务器。它们需要一个可靠运行、能够进行外部API调用、在我的规模下成本接近零的计划函数。Workers就是答案。 我在Workers上运行的内容： - **内容流水线** — 生成英文文章，分发到12种翻译，生成OG卡片 - **通讯代理** — 起草并安排每周发送 - **Facebook广告监控器** — 读取性能、标记表现不佳者、通知我 - **Pickleland入住率报告器** — 读取预订数据，给我发送每日摘要 所有这些的每月总费用：约$5。这是付费Workers计划。代理按cron计划可靠运行；六个月内我遇到一次故障（Meta方面的DNS问题，不是我这边的）。 ## 我删减了什么以及原因 **Zapier** — 被Workers + 各平台API直接替代。Zapier增加延迟，规模化成本更高，有一个Workers没有的上限。 **ChatGPT** — Claude的上下文窗口、工具使用和系统提示词质量对运营者用例更好。我保留一个ChatGPT标签页用于快速网络搜索，但不在其上构建。 **Webflow** — 将网站迁移到Astro + Cloudflare Pages。更多控制、更好性能、可以脚本化的构建流程。 **Grammarly** — Claude做Grammarly所做的一切，而且更好地保持了我的声音。 ## 运营者的最终结论 上面五款工具不是最新的，也不是讨论最多的。它们是在两个不同业务中经受住日常生产使用考验的工具。在向技术栈添加新工具之前，问自己：这五款中哪一款能做这个工作？你会惊讶于"它们中有一款已经可以"这个答案出现的频率。 --- ## 为什么你的AI代理在生产环境中持续失败（以及如何修复） Source: https://alejandrorioja.com/zh/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it/ Published: 2026-06-06 Updated: 2026-06-18 Tags: AI Agents TL;DR: 大多数生产代理失败来自五个原因：无法处理边缘情况的脆弱提示词、缺少瞬态API错误的重试逻辑、无法看到故障的可观察性缺失、没有退出条件的失控循环，以及足够模糊使模型选错的工具定义。五个问题都可以在不更换模型或框架的情况下修复。 ## 目录 _2026年6月更新。_ **TL;DR：** 大多数生产代理失败来自五个原因：无法处理边缘情况的脆弱提示词、缺少瞬态API错误的重试逻辑、无法看到故障的可观察性缺失、没有退出条件的失控循环，以及足够模糊使模型选错的工具定义。五个问题都可以在不更换模型或框架的情况下修复。 **【运营者视角】** 我在生产中运行了30多个代理。我经历过所有这些失败。那些浪费时间最多的不是那些奇特的问题——而是我以为已经处理好的无聊基础设施故障。 ## 失败1：在边缘情况输入上崩溃的脆弱提示词 在测试用例上有效的提示词会在你未预料的输入上失败。这不是模型限制——这是指令编写问题。 **症状：** 代理产生无意义输出、调用错误工具，或在输入与测试内容略有不同时输出格式错误的JSON。 **根本原因：** 你的系统提示词只描述了快乐路径。它没有告诉模型当数据缺失、格式错误或模糊时该做什么。 **修复：** 在系统提示词中添加明确的边缘情况处理： ``` If the input data is missing a required field, return: { "status": "error", "reason": "missing_field", "field": "" } Do NOT attempt to infer or hallucinate missing values. If you are uncertain which tool to call, call no tool and return: { "status": "clarification_needed", "question": "..." } ``` 模型可靠地遵循边缘情况的明确指令。错误在于假设它会将快乐路径指令推广到处理混乱情况。 ## 失败2：瞬态API错误的重试逻辑缺失 你的代理调用的每个外部API最终都会失败。Claude API、Meta Graph API、你的数据库——它们都会返回5xx错误、超时或限流。如果代理没有重试逻辑，一个瞬态错误就会终止整个运行。 **症状：** 代理运行在不同步骤随机失败。日志显示503或429，没有后续尝试。 **修复：** 用指数退避重试包装每个外部调用： ```typescript async function withRetry(fn: () => Promise, retries = 3, baseDelayMs = 500): Promise { for (let attempt = 0; attempt <= retries; attempt++) { try { return await fn(); } catch (err: any) { const isTransient = err.status === 429 || err.status >= 500 || err.code === "ECONNRESET"; if (!isTransient || attempt === retries) throw err; const delay = baseDelayMs * Math.pow(2, attempt) + Math.random() * 100; await new Promise((r) => setTimeout(r, delay)); } } throw new Error("unreachable"); } // Usage const result = await withRetry(() => client.messages.create({ ... })); ``` 三次指数退避重试处理约99%的瞬态失败。将此添加到每个外部调用，你的一半随机失败会消失。 ## 失败3：无可观察性——你看不到什么在崩溃 这是生产中最常见的失败模式，也是调试成本最高的：代理静默失败或产生错误输出，你不知道链条中哪里出了问题。 **症状：** 你知道有问题但无法确定步骤。你添加`console.log`语句并手动重新运行尝试复现。 **修复：** 每个步骤的结构化日志记录，带有追踪整个执行的运行ID： ```typescript function createLogger(runId: string, agentName: string) { return { step: (step: string, data: object) => console.log(JSON.stringify({ runId, agent: agentName, step, ts: new Date().toISOString(), ...data })), error: (step: string, err: unknown) => console.error(JSON.stringify({ runId, agent: agentName, step, error: String(err), ts: new Date().toISOString() })), }; } const log = createLogger(crypto.randomUUID(), "newsletter-agent"); log.step("fetch_topic", { topicId: topic.id, topic: topic.name }); // ... do work ... log.step("draft_complete", { subject: draft.subject, wordCount: draft.body.split(" ").length }); ``` 如果你在Cloudflare Workers上，这些日志会进入Logpush或Workers Tail。本地运行或VPS上，将其传输到日志聚合器。结构化JSON意味着你可以按`runId`过滤，看到单次运行中发生的确切情况。 ## 失败4：没有退出条件的失控循环 代理循环——模型调用工具并迭代直到满足条件——如果条件从未满足或模型错误识别它，可能永远运行下去。 **症状：** 代理在超时前花费数百美元的API费用。或者它一遍又一遍地运行相同的工具调用而不取得任何进展。 **修复：** 始终设置硬性迭代上限和进度检查： ```typescript const MAX_ITERATIONS = 10; let iterations = 0; let lastToolCallName = ""; let sameToolCallCount = 0; while (true) { iterations++; if (iterations > MAX_ITERATIONS) { log.error("loop", { reason: "exceeded_max_iterations" }); break; } const response = await client.messages.create({ ... }); // Detect stuck loops: same tool called 3x in a row const toolCall = response.content.find(b => b.type === "tool_use"); if (toolCall?.name === lastToolCallName) { sameToolCallCount++; if (sameToolCallCount >= 3) { log.error("loop", { reason: "stuck_loop", tool: toolCall.name }); break; } } else { sameToolCallCount = 0; lastToolCallName = toolCall?.name ?? ""; } if (response.stop_reason === "end_turn") break; } ``` 这捕获了"运行太长"和"原地打转"两种失败模式。上限应该对快乐路径足够宽松，但足够紧以限制爆炸半径。 ## 失败5：模型错误解析的模糊工具定义 如果给模型两个描述重叠的工具，它有时会调用错误的那个。这在`search_database`与`get_record`或`send_email`与`create_draft`等工具中尤为常见。 **症状：** 模型调用了正确类别的工具，但选了错误的具体工具。或者在错误的上下文中调用工具（在只应读取时使用写入工具）。 **修复：** 使工具描述互斥，并明确添加"何时不要使用"： ```typescript const tools = [ { name: "get_subscriber", description: "Fetch a single subscriber record by email. Use ONLY when you have a specific email address. Do NOT use for searching or listing subscribers.", input_schema: { ... } }, { name: "search_subscribers", description: "Search subscribers by tag, segment, or status. Use when you need to find subscribers matching a criteria — NOT when you have a specific email address.", input_schema: { ... } } ]; ``` "当X时不要使用"条款是大多数人跳过的部分。这是最重要的部分。模型比从正面描述中推断更擅长遵循明确的负面约束。 ## 还有一件事：在糟糕的输入上测试代理 大多数代理只在干净的快乐路径输入上测试。生产环境有脏输入：空字符串、null字段、Unicode边缘情况、返回200但响应模式意外的API。 添加明确测试以下内容的测试套件： - 空或null输入 - 最大预期长度的输入 - 含特殊字符或非ASCII文本的输入 - 外部API返回意外响应形式 如果你的代理在任何这些情况下崩溃，在上线前修复它。生产环境会找到你做的每一个假设。 ## 运营者的最终结论 大多数生产代理失败是伪装成模型问题的基础设施问题。在切换模型之前，向提示词添加重试、结构化日志记录、循环上限和明确的边缘情况处理。修复模糊的工具定义。然后在糟糕的输入上测试。在责怪模型之前做所有这些——以我的经验，模型通常是最后需要改变的东西。 --- ## 如何在15分钟内构建你的第一个AI智能体 Source: https://alejandrorioja.com/zh/how-to-build-your-first-ai-agent-in-15-minutes/ Published: 2026-06-02 Updated: 2026-06-25 Tags: AI Agents TL;DR: 你不需要框架、课程或博士学位。你需要的是Node.js、Anthropic SDK，以及25行TypeScript。本教程将构建一个真实可用的智能体——一个结构化内容摘要器，你可以在同一次会话中将它部署到Cloudflare。唯一的前提条件是一个免费的API密钥。 ## 目录 _2026年6月更新。_ **TL;DR：** 你不需要框架、课程或博士学位。你需要的是Node.js、Anthropic SDK，以及25行TypeScript。本教程将构建一个真实可用的智能体——一个结构化内容摘要器，你可以在同一次会话中将它部署到Cloudflare。唯一的前提条件是一个免费的API密钥。 **[运营者视角]** 我从想用AI做自动化的创始人那里最常听到的一句话是"我得先多学一些"。其实不必。智能体的模式很简单，而理解它最快的方式就是亲手做一个。下面是如果我今天从零开始会走的确切路径。 ## 为什么大多数"构建AI智能体"教程帮不到你 它们要么使用Python（对ML工程师没问题，但对其他所有人都是阻力），要么把真正的代码藏在LangChain之类的框架背后，要么构建出过于抽象、无法与你的实际工作相连的东西。 本教程在三个方面有所不同： 1. **仅用TypeScript** —— 如果你写过JavaScript，就能跟上这篇教程 2. **不用框架** —— 你将看到每一行接触模型的代码 3. **有用的输出** —— 你将构建一个结构化摘要器，可以真正用在客户邮件、评论或会议记录上 ## 你将构建什么 一个**内容摘要智能体**：粘贴任意一段文本，返回格式一致的结构化摘要。一个HTTP请求进，一份干净的摘要出。 为什么把它作为第一个项目：这个模式——系统提示 + 用户输入 → 结构化输出——是我运行的每一个智能体的基础。替换系统提示，你就得到一个问答器、一个语气改写器、一个分类器或一个草稿生成器。学会这一次，你就掌握了生产环境智能体实际工作内容的80%。 ## 前提条件（2分钟） - **Node.js 18+** —— 用`node --version`检查。如有需要，从nodejs.org安装。 - **一个Anthropic API密钥** —— 在[Claude](/recommends/claude)注册，从控制台获取一个密钥。免费额度即可。 - 一个终端和一个文本编辑器。 不用Docker。不用虚拟环境。不用`pip install`任何东西。 ## 第1步：创建项目（2分钟） ```bash mkdir my-first-agent && cd my-first-agent npm init -y npm install @anthropic-ai/sdk npm install -D tsx typescript ``` 在`package.json`中添加一个脚本，以便轻松运行智能体： ```json { "scripts": { "agent": "tsx agent.ts" } } ``` ## 第2步：编写智能体（5分钟） 创建`agent.ts`并粘贴以下内容： ```typescript import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY, }); const SYSTEM_PROMPT = `You are a precise content summarizer. When given any block of text, return a structured summary in this exact format: **One-line summary:** **Key points:** - - - **Action item (if any):** Be specific. No filler. Under 150 words total.`; async function summarize(text: string): Promise { const message = await client.messages.create({ model: "claude-haiku-4-5", max_tokens: 512, system: SYSTEM_PROMPT, messages: [{ role: "user", content: text }], }); const block = message.content[0]; if (block.type !== "text") throw new Error("Unexpected response type"); return block.text; } const sample = ` Hey team — following up on the Q2 review meeting. We agreed to push the launch to July 15th instead of June 30th due to the payment integration delay. Marketing needs the new landing page copy by June 20th or we can't start the email campaign. Budget for the launch campaign is confirmed at $8,000. Please confirm receipt. `; const result = await summarize(sample); console.log(result); ``` ## 第3步：运行它（1分钟） ```bash ANTHROPIC_API_KEY=sk-ant-... npm run agent ``` 预期输出： ``` **One-line summary:** Launch pushed to July 15th due to payment delay; landing page copy needed by June 20th to unblock email campaign. **Key points:** - Launch date moved from June 30th to July 15th - Landing page copy deadline: June 20th (blocks email campaign) - Campaign budget confirmed at $8,000 **Action item (if any):** Confirm receipt and deliver landing page copy by June 20th. ``` 这就是一个可用的AI智能体。真实输入、自定义系统提示、结构化输出。整个东西只有30行代码。 ## 第4步：根据你的使用场景进行定制 系统提示是让这个智能体成为你专属智能体的唯一要素。下面是三个可以直接替换使用的方案： **客户评论分类器：** ```text Classify this customer review as POSITIVE, NEGATIVE, or MIXED. Then extract the main complaint or praise in one sentence. Format: SENTIMENT: