[{"content":" 来源信息\n文档类型：阅读索引 · 整理日期 2026-10-07 本页是同一批 claude.dev 官方博客阅读笔记的总索引，用于串联下面这 14 篇笔记。 索引说明 整理日期：2026-10-07；范围：父级指定固定存量 14 篇，不代表博客所有历史文章。 阅读口径：公开正文所有章节已读取；未操作交互演示、未递归阅读所有外链，也未运行教程。无核心正文缺失；均未独立复现实验。 本地对应均位于本索引同目录，文件名为下列 wiki 链接加 .md；每篇笔记的 frontmatter 记录原文、作者与日期，文末另有官方文档外链。 篇目对照 原文 URL 本地对应 https://claude.dev/blog/spending-your-effort/ Claude Code 思考档位选择：Spending your effort https://claude.dev/blog/getting-the-most-out-of-opus-5-5/ Opus 5.5 协作与长任务：Getting the most out https://claude.dev/blog/lessons-from-building-claude-code-how-we-use-skills/ Claude Code Skills 的设计与治理：How we use skills https://claude.dev/blog/lessons-from-building-claude-code-prompt-caching-is-everything/ Claude Code 提示缓存：Prompt caching is everything https://claude.dev/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models/ Claude 5 上下文工程：The new rules https://claude.dev/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code/ Claude Code 动态工作流：A harness for every task https://claude.dev/blog/seeing-like-an-agent/ 从代理视角设计工具：Seeing like an agent https://claude.dev/blog/claude-code-in-the-cloud/ Claude Code 云端会话：Cloud field guide https://claude.dev/blog/getting-started-with-claude-code-mods/ Claude Code Mods 入门：Getting started https://claude.dev/blog/using-claude-code-the-unreasonable-effectiveness-of-html/ HTML 作为协作产物：The unreasonable effectiveness https://claude.dev/blog/building-with-claude-sonnet-5-5/ Sonnet 5.5 选型与迁移：Building with Claude https://claude.dev/blog/automating-eval-design-and-hillclimbing/ 评估设计与爬坡优化：Automating eval https://claude.dev/blog/what-a-task-costs-on-opus-5-5/ Opus 5.5 任务成本：What a task costs https://claude.dev/blog/how-we-made-claude-ai-faster/ 性能优化的测量闭环：How we made claude.ai faster 使用限制 价格、默认值、可用平台与性能结论依原文日期和样本解读，不能自动当作当前事实。 游戏开发部分是应用建议，非用户已实施成果或实测。 固定范围已结束，无待读正文缺口；不新增未来监控或持续任务。 官方资料 claude.dev 博客（上述原文站点） Claude Code 官方文档 Claude Code 官方文档：更新与新功能 Claude Code 官方文档：最佳实践 Claude Code 官方文档：费用 Claude 平台文档：Tool use 概览 Claude 平台文档：Prompt caching Claude 平台文档：模型定价 Agent Skills：概览 相关笔记 精通 Claude Code（全文翻译） 工具 ","permalink":"https://blog.xiezaikui.com/posts/claude-dev-notes-index/","summary":"整理日期：2026-10-07；范围：父级指定固定存量 14 篇，不代表博客所有历史文章。","title":"Claude 官方博客阅读总索引（固定 14 篇）"},{"content":" 来源信息\n文档类型：阅读笔记 · 整理日期 2026-10-07 原文：《Spending your effort》 · 作者 Thariq Shihipar · 发布于 claude.dev · 发布日期 2026-09-25 原文地址：https://claude.dev/blog/spending-your-effort/ 本文为阅读整理，观点与数据以原文为准；原文不提供的事实均已标注为整理者说明。 核心理解 思考档位的选择不是越高越好，而是按任务难度、验证需求和用户参与程度，分配推演与检查投入。用户逐轮审阅时，先得到可讨论的起点往往更有用；要求模型独立完成时，则需要更多自主判断与验证。\n低档能较快给出草图，让人反馈后继续迭代。方向尚未确定时，高档可能提前替用户作出许多假设，把时间花在尚未认可的方案上。这解释的是协作效率，并没有证明 low 的创意更好。\n档位怎么选 low：用户持续参与的脑暴、草图、小改动与快速探索；重点是尽快获得可审阅的起点。 medium：范围明确的常规工程，例如普通功能实现，在速度、成本和能力之间取平衡。 high：验证重要或边界较多的修 bug、debug、性能优化与测试；要求复现问题、检查异常路径并验证结果。 max：希望模型自主完成困难任务，承担端到端推演、实现与验证；收益可能递减，应先用实际任务评估。 这些是选档起点，不是固定规则。同一任务也可分阶段调整，不能用提高档位代替澄清需求。\n机制与适用限制 官方文档将 effort 定义为行为信号：它影响推理、回答及工具调用的投入，不是严格的 token 上限。低档遇到难题仍可能思考；高档也不保证正确。\n同名等级按不同模型分别校准，并不代表相同的底层投入，不能直接套用到 Codex。原文的构建示例主要使用 Opus 5.5，基准分析还涉及 Fable 等其他 Claude 模型；少量示例与特定基准的经验不能当作普遍定律。当前文档还列有 xhigh，具体可用档位与建议应以所用模型文档为准。\n应用建议：游戏开发流程 以下是据此提出的流程建议，并非原文实验或已经实施的成果。\n用低档发散 3 至 5 个玩法方案，比较体验与实现成本。 人来选方向，补充资源、状态、规模和验收约束。 常规实现使用适中档位，审阅结果后继续迭代。 复杂验证提高档位，集中处理边界、性能与测试。 例如要塞 NPC 系统，先讨论巡逻、生产、战斗等玩法备选；选定后再实现。验证阶段重点检查资源争用、任务打断与恢复、状态冲突，以及对应测试，避免过早细化未选中的设计。\n小结 需要快速反馈时先降低投入，需要独立完成和可靠验证时再提高；先确认方向，再把算力花在风险与边界上。\n参考来源 原文：Using Claude Code: Spending your effort（claude.dev，2026-09-25） Claude Code 官方文档：模型配置（Choose an effort level） Claude 平台文档：Effort（思考档位） 相关笔记 Claude 官方博客阅读总索引（固定 14 篇） Opus 5.5 任务成本：What a task costs Sonnet 5.5 选型与迁移：Building with Claude Opus 5.5 协作与长任务：Getting the most out ","permalink":"https://blog.xiezaikui.com/posts/spending-your-effort/","summary":"思考档位的选择不是越高越好，而是按任务难度、验证需求和用户参与程度，分配推演与检查投入。用户逐轮审阅时，先得到可讨论的起点往往更有用；要求模型独立完成时，则需要更多自主判断与验证。","title":"Claude Code 思考档位选择：Spending your effort"},{"content":" 来源信息\n文档类型：阅读笔记 · 整理日期 2026-10-07 原文：《Getting the most out of Opus 5.5》 · 作者 Addy Osmani · 发布于 claude.dev · 发布日期 2026-09-22 原文地址：https://claude.dev/blog/getting-the-most-out-of-opus-5-5/ 本文为阅读整理，观点与数据以原文为准；原文不提供的事实均已标注为整理者说明。 阅读范围 已读取全文，包括六个主题及末尾检查清单。 提问与长任务 文章的起手建议是交代完整任务、完成标准和停下来询问的条件。对这版模型，泛泛要求“认真思考”未必有益；想调整投入应使用 effort。运行中可补充要求，设计请求则应列出具体不想要的视觉套路。\n长任务需约定何时继续、何时等待人决定，破坏性操作仍保留权限检查。大规模审计可分给子代理，但主代理要核查证据。任务清单落在文件中，可在上下文压缩后保留进度。\n验收与 Claude 应用 收尾先看待人决策或批准的事项，再查变更和发现。代码审查要求给出足以阻止合入的问题及复现证据；研究需标明未确认内容和查找范围。\n应用侧建议直接提供图表原图，检查长文内部矛盾，明确要求交付成品文件。已定答案可声明暂不重审，以减少反复；持续推演的分析项目不宜这样做。\n标记、速度与边界 文章描述被安全检查标记后可能转到旧模型，检查范围包含历史内容、文件与搜索结果；用户可查看切换提示并反馈误报。解释选择依据比索要内部推理过程更合适。\n当时的 fast mode 是同模型的研究预览，强调交互速度，需额外用量且单价更高。本文未核实当前价格或开关行为；版本功能、早期测试反馈和模型间比较均不能当作普遍保证。末尾清单把提问、长任务、验收与标记处理汇合成检查点。\n游戏开发应用建议 以下为整理者建议，非原文实测，也不表示已经实施。\n给要塞 NPC 系统写清完成条件：资源占用可追踪、任务可打断恢复、关键场景可复现；把玩法选择留给人决定。 长任务清单分别记录实现、验证与待决策项，避免“代码写完”被误认为“玩法验收完成”。 UI 设计附截图与具体约束；验收要求指出画面、数值和状态流之间的矛盾，并区分已验证与待人工试玩。 我的判断是，长任务自治需要清楚的交接接口。可先试一个小功能，观察是否准确识别阻碍、是否提供可复查证据，再扩大范围；不能仅凭运行时间长就判断完成质量。成本与速度也应结合任务成功率一起评估。\n小结 先定义交付与停顿条件，再用证据验收；清单和明确交接能减少长任务中的误解。\n参考来源 原文：Getting the most out of Opus 5.5 in Claude and Claude Code（claude.dev，2026-09-22） Claude Code 官方文档：模型配置 Claude Code 官方文档：快速模式 Claude Code 官方文档：创建自定义子代理 Claude Code 官方文档：权限 相关笔记 Claude 官方博客阅读总索引（固定 14 篇） Claude Code 思考档位选择：Spending your effort Claude Code 提示缓存：Prompt caching is everything Claude Code 动态工作流：A harness for every task 精通 Claude Code（全文翻译） ","permalink":"https://blog.xiezaikui.com/posts/getting-the-most-out-of-opus-5-5/","summary":"已读取全文，包括六个主题及末尾检查清单。","title":"Opus 5.5 协作与长任务：Getting the most out"},{"content":" 来源信息\n文档类型：阅读笔记 · 整理日期 2026-10-07 原文：《Lessons from building Claude Code: How we use skills》 · 作者 Thariq Shihipar · 发布于 claude.dev · 发布日期 2026-06-03 原文地址：https://claude.dev/blog/lessons-from-building-claude-code-how-we-use-skills/ 本文为阅读整理，观点与数据以原文为准；原文不提供的事实均已标注为整理者说明。 阅读范围 已读取全文，覆盖定义、分类、制作、分发、市场、组合、衡量与起步。 定义与九类用途 Skill 是可发现的指令、脚本和资源目录，不只是一篇 Markdown。文章归纳九类：库与 API 参考、产品验证、数据分析、业务自动化、脚手架、质量审查、交付部署、故障手册、基础设施操作。分类是内部经验框架，职责过杂会增加选择困难；验证类被作者认为特别有价值。\n制作机制 内容应补充模型缺少的项目知识，积累真实失败形成的 gotchas。主文件指向按需读取的参考、模板和脚本，避免一次塞满上下文。约束目标而非锁死所有步骤；缺少初始配置时先询问。描述字段用于触发判断，应写清何时使用。\n日志可保留执行历史，辅助代码让模型组合已有能力；按需 hooks 可在当前会话增加特定防护。持久数据应与安装内容区分，避免更新时丢失状态。\n分发、组合与衡量 少量仓库可直接共享技能，规模扩大后按需安装更合适。市场先让技能试用，再由实际采用推动纳入。技能可引用其他技能，但文章发表时没有原生依赖管理，前提是依赖已安装。调用日志可发现热门或触发不足的技能；起步宜从小规则和一个常见坑逐步改进。\n这些是当时 Anthropic 的工作经验，不是当前平台功能的完整承诺。使用次数不等于有效性；应另外检查误触发、漏触发和结果质量，工具权限与外部副作用也要单独控制。\n游戏开发应用建议 以下为整理者建议，非原文实测，也不表示已经实施。\n可从“NPC 状态验证”这一窄技能开始，写清触发条件、输入、验收证据和不能自动执行的动作。将玩法参考与测试脚本分开，主文件只说明根据什么症状读取哪份资料。\ngotchas 优先记录项目中实际出现的资源释放、任务打断、存档恢复问题；没有证据时标为待验证假设。 验证脚本输出随机种子、状态变化和失败断言，便于复现；截图只补充可见体验，不能证明内部状态正确。 配置记录目标场景与测试范围，运行记录区分成功、失败和跳过。先拿正常、边界和无关请求检查触发，再考虑共享。 这种设计把知识沉淀与执行权限分开：能复用经验，不代表获得发布、删除资源或改动线上数据的授权。先证明小技能有用，再扩展职责，比立即建立庞大技能库更容易维护。\n小结 技能价值来自项目特有知识、可执行验证和持续修正；清楚触发、按需加载与可复查结果应一起设计。\n参考来源 原文：Lessons from building Claude Code: How we use skills（claude.dev，2026-06-03） Claude Code 官方文档：用技能扩展 Claude Agent Skills：概览 Agent Skills：规范 Agent Skills：最佳实践 相关笔记 Claude 官方博客阅读总索引（固定 14 篇） 从代理视角设计工具：Seeing like an agent Claude 5 上下文工程：The new rules 评估设计与爬坡优化：Automating eval ","permalink":"https://blog.xiezaikui.com/posts/how-we-use-skills/","summary":"已读取全文，覆盖定义、分类、制作、分发、市场、组合、衡量与起步。","title":"Claude Code Skills 的设计与治理：How we use skills"},{"content":" 来源信息\n文档类型：阅读笔记 · 整理日期 2026-10-07 原文：《Lessons from building Claude Code: Prompt caching is everything》 · 作者 Thariq Shihipar · 发布于 claude.dev · 发布日期 2026-04-30 原文地址：https://claude.dev/blog/lessons-from-building-claude-code-prompt-caching-is-everything/ 本文为阅读整理，观点与数据以原文为准；原文不提供的事实均已标注为整理者说明。 阅读范围 已读取全文，覆盖布局、更新、模型、工具、压缩与总结。 前缀布局与更新 缓存复用基于请求前缀匹配。稳定的系统指令与工具放前面，其后是项目资料、会话状态和逐轮增长的消息；前缀中途改变会影响后续复用。精细时间戳、工具顺序变化或参数变化都可能破坏稳定性。新状态宜追加为消息，而非重写开头。\n模型与工具 模型有各自的缓存。长会话为简单问题换便宜模型，可能因重建输入缓存增加成本；文章建议可用简短交接让子代理处理。\n工具集合也属于前缀。Plan Mode 用消息表达行为限制，保持定义不变；工具搜索保留顺序稳定的轻量入口，需要时再加载完整 schema。保留定义并不等于允许所有操作，权限仍需独立约束。\n压缩与工程结论 上下文压缩需要读取历史。若另起一套系统提示且移除工具来总结，原前缀就无法复用。文章的做法是保持父会话的系统、上下文、工具和历史，再追加总结请求，并预留容纳请求与摘要的缓冲空间。\n作者把缓存命中率当作运行指标持续监测。这里讨论的是输入计算复用，不是结果缓存，也不保证答案正确。文章图示中的折扣和上下文规模属于当时例子，本文不把它们当作当前价格或所有产品的固定参数。\n游戏开发应用建议 以下为整理者建议，非原文实测，也不表示已经实施。\n若开发长会话游戏代理，可将世界规则、工具契约和项目约束作为稳定资料，将本轮 NPC 状态、玩家事件与任务变化放在消息尾部。不要为了命中率保留失效规则：规则真的变化时，应明确更新并接受必要成本。\n规划和执行阶段用清楚的状态转换及权限检查区分。探索资料的副任务只携带必要目标与约束，不能假定换模型一定便宜。摘要需保留资源占用、未完成动作、玩家选择和待验证风险，而非只保留自然语言剧情。\n评估可记录命中率、输入用量、延迟、任务成功率与摘要丢失信息；在相同负载下比较稳定前缀与频繁改写的方案。这里没有实测结果或节省比例。对包含私人存档和玩家数据的系统，数据最小化、隔离与正确性应优先于缓存收益。\n小结 稳定前缀、追加更新和兼容父请求的旁路总结是文章主线；缓存优化必须结合权限、信息有效性和实际指标。\n参考来源 原文：Lessons from building Claude Code: Prompt caching is everything（claude.dev，2026-04-30） Claude Code 官方文档：提示缓存 Claude 平台文档：Prompt caching Claude Code 官方文档：费用 相关笔记 Claude 官方博客阅读总索引（固定 14 篇） Opus 5.5 任务成本：What a task costs Claude 5 上下文工程：The new rules 从代理视角设计工具：Seeing like an agent ","permalink":"https://blog.xiezaikui.com/posts/prompt-caching-is-everything/","summary":"已读取全文，覆盖布局、更新、模型、工具、压缩与总结。","title":"Claude Code 提示缓存：Prompt caching is everything"},{"content":" 来源信息\n文档类型：阅读笔记 · 整理日期 2026-10-07 原文：《The new rules of context engineering for Claude 5 generation models》 · 作者 Thariq Shihipar · 发布于 claude.dev · 发布日期 2026-07-24 原文地址：https://claude.dev/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models/ 本文为阅读整理，观点与数据以原文为准；原文不提供的事实均已标注为整理者说明。 阅读范围 全文，覆盖解除过度约束、六组新旧做法、上下文分层与简化建议。 从约束堆积到按需信息 上下文包含系统指令、项目说明、技能、记忆和参考，并非只有当前提问。文章报告对特定新模型删减系统提示后，内部编码评估未见可测损失；重点是检查过时、重复和相互冲突的要求，而不是追求越短越好。\n六组变化 规则转向判断：例如注释密度应参考周围代码，而非一律禁止多行注释。 示例转向接口：清楚的参数、状态枚举和约束可比大量示例更有表达力。 全量前置转向渐进披露：验证、审查资料在需要时加载，长指南拆成可发现的文件。 重复强调转向简洁工具描述：工具用法集中在接口附近，减少多处重复。 项目文件中的记忆转向自动记忆：区分稳定规则和会话经验。 简单规格转向丰富参考：代码、测试、HTML 原型与评价量表也能表达预期。 分层落地与限制 系统提示交代产品身份和工作环境；项目说明保留用途与独有陷阱；技能承载按需知识；参考文件描述当前任务。文末提出简化检查工具，但本文未运行它，也未修改任何配置。\n这些经验针对文章所述模型和内部评估，不能证明所有规则都多余，也不能直接推广至其他模型。自动记忆可能过时，参考代码也可能有缺陷；高风险约束、用户明确要求和权限边界仍需保留。减少冲突应先厘清含义，不能擅自删除不理解的限制。\n游戏开发应用建议 以下为整理者建议，非原文实测，也不表示已经实施。\n给要塞 NPC 项目整理上下文时，可让入口只交代资源所有权、任务打断原则和资料位置。把生产、战斗、寻路的细节分开，当前任务只引用相关部分；使用状态枚举和可运行测试表达规则，避免在多个文件里重复解释同一流程。\n玩法参考宜同时给出体验目标与可检查的例子。测试能约束资源归还和状态恢复，却未必能判断节奏是否有趣；评价量表与人工试玩需补上体验维度。实验性原型也应标明哪些行为只是示意。\n可先挑一个小场景，比对整理前后的漏约束、误解、查找次数和验收结果，再决定是否继续精简。保留冲突记录与规则来源，便于回查；不要把“模型更强”当作放宽存档、资产或发布权限的理由。\n小结 把稳定约束、任务参考与历史经验放在合适位置，提供可发现且可靠的信息，比不断增加通用指令更值得验证。\n参考来源 原文：The new rules of context engineering for Claude 5 generation models（claude.dev，2026-07-24） Claude Code 官方文档：记忆与 CLAUDE.md Claude Code 官方文档：上下文窗口 Claude Code 官方文档：最佳实践 相关笔记 Claude 官方博客阅读总索引（固定 14 篇） Claude Code Skills 的设计与治理：How we use skills Claude Code 提示缓存：Prompt caching is everything 从代理视角设计工具：Seeing like an agent ","permalink":"https://blog.xiezaikui.com/posts/the-new-rules-of-context-engineering/","summary":"全文，覆盖解除过度约束、六组新旧做法、上下文分层与简化建议。","title":"Claude 5 上下文工程：The new rules"},{"content":" 来源信息\n文档类型：阅读笔记 · 整理日期 2026-10-07 原文：《A harness for every task: dynamic workflows in Claude Code》 · 作者 Thariq Shihipar、Sid Bidasaria · 发布于 claude.dev · 发布日期 2026-06-02 原文地址：https://claude.dev/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code/ 本文为阅读整理，观点与数据以原文为准；原文不提供的事实均已标注为整理者说明。 阅读范围 全文，含示例、机制、动机、静动态比较、模式、全部用途、限制、制作技巧与结语。 机制与动机 动态工作流按任务生成 JavaScript 编排：agent 启动独立代理，parallel 并发汇合，pipeline 将条目逐阶段处理；可选择模型、结构化返回与隔离方式，文章还描述会话恢复后的续跑。\n单一上下文可能提前收工、偏爱自身答案或在压缩后偏离目标。独立目标与上下文有助于减少这些问题。静态流程预设通用步骤，动态流程则按眼前问题构造检查路径；例如迁移决策不只搜索，还查实际代码与业务需求。\n六种模式与用途 基本模式是分类路由、拆分汇总、独立反证、生成筛选、两两竞赛、按停止条件循环。汇总需等待分支结果；反证需有评价标准；循环需明确终点。\n文章覆盖迁移重构、深度研究、逐条事实验证、排序、规则遵循与经验提炼、根因调查、大规模分诊、设计探索、评估和模型路由。例如低频失败可生成竞争假说再检验；大列表可分组或两两比较；外部工单的读取者仅有低权限，行动者接收结构化摘要。\n制作技巧与边界 提示要写清模式和验收，可做轻量反证，也可声明预算与硬完成条件。文章描述定期运行、保存工作流及经技能分享，强调模板可适配；本文没有执行或建立这些任务。\n其版本行为与预算机制未在当前环境验证。复杂高价值任务较适合，普通改动未必值得付出额外 token 和协调成本。独立代理也可能共享错误假设；隔离不等于证据正确，摘要不自动消除不可信内容的风险。\n游戏开发应用建议 以下为整理者建议，非原文实测，也不表示已经实施。\nNPC 偶发资源冲突可先保存可复现种子，按日志、状态转移和资源生命周期分别提出假说，再用同一验收标准检验。主流程负责核对证据、合并结论，不能用多数投票替代复现。\n玩法探索可先生成若干方案，再按成本、可读性与互动深度筛选，最终由人选择；体验评价不应伪装成客观证明。批量资产检查则应区分只读诊断与写入修复，限定目标资源与并发数量，避免多个任务争用同一场景。\n我的建议是先为一类故障定义有限预算、超时和“无法确认”出口，再与单代理方案比较误报、遗漏和完成时间。所有验收项都应有状态：通过、失败、未检查，防止部分完成被包装为全部完成。\n小结 结构化分工的价值是让目标、证据与停止条件可核查；并行和多轮验证必须证明值得其成本。\n参考来源 原文：A harness for every task: dynamic workflows in Claude Code（claude.dev，2026-06-02） Claude Code 官方文档：动态工作流 Claude Code 官方文档：代理团队 Claude Code 官方文档：创建自定义子代理 Claude Code 官方文档：定时运行提示 相关笔记 Claude 官方博客阅读总索引（固定 14 篇） 从代理视角设计工具：Seeing like an agent Claude Code Skills 的设计与治理：How we use skills 评估设计与爬坡优化：Automating eval Opus 5.5 协作与长任务：Getting the most out ","permalink":"https://blog.xiezaikui.com/posts/a-harness-for-every-task/","summary":"全文，含示例、机制、动机、静动态比较、模式、全部用途、限制、制作技巧与结语。","title":"Claude Code 动态工作流：A harness for every task"},{"content":" 来源信息\n文档类型：阅读笔记 · 整理日期 2026-10-07 原文：《Seeing like an agent》 · 作者 Thariq Shihipar · 发布于 claude.dev · 发布日期 2026-04-10 原文地址：https://claude.dev/blog/seeing-like-an-agent/ 本文为阅读整理，观点与数据以原文为准；原文不提供的事实均已标注为整理者说明。 阅读范围 全文，覆盖提问工具三次尝试、任务演进、搜索接口、Guide 代理与结语。 工具要适配能力 通用工具与大量专用工具之间没有固定最优解。接口需匹配模型能力、目标和环境，观察调用轨迹再调整。\n提问工具经历三次设计：将问题附在退出规划工具上，会让计划与待答问题相互冲突；解析特殊 Markdown 又不够稳定；独立的结构化提问工具才让模型能在合适时机提问，并提供可选答案与明确交互界面。\n从清单到任务 早期 Todo 配合周期提醒帮助保持目标，后来反而可能让模型不愿修改计划。Task 引入依赖与共享更新，服务于代理协作。旧工具曾经有效，不代表新模型仍需要同样的限制。\n搜索与渐进披露 文章描述从预索引 RAG 向主动搜索代码的探索：索引有速度优势，也有环境与维护负担；搜索工具让代理自己建立相关上下文。Skills 通过文件引用逐层发现信息，扩展能力未必需要新增工具。\nClaude Code Guide 的例子更进一步：直接给文档入口会把大量资料带进主上下文；专门的子代理负责搜索和提炼，只返回所需答案。作者也承认这仍可能混淆，需不断实验。\n适用限制 这是特定产品的演化经验，不能据此判定 RAG 过时、结构化提问总比文本好，或工具越少越好。文中的模型表现与工具数量属于当时状态。本文未运行网页工具、改配置或创建代理；接口可调用性、返回信息质量与最终任务成功要分别检验。\n游戏开发应用建议 以下为整理者建议，非原文实测，也不表示已经实施。\n设计 NPC 工具时，可先区分查询状态、提出动作和执行动作。查询返回资源标识、占用者、状态版本与失败原因；执行检查前置条件，避免模型仅凭自然语言推断资源仍可用。复杂动作需考虑重复调用和被打断后的恢复。\n玩法尚未决定时，先询问影响架构的关键选择，再形成计划。无需把所有美术偏好一次问完，问题应有明确决策用途。参考查询可独立提炼，但回传需保留出处与不确定性，方便主任务核对。\n可用正常、缺资源、状态过期和无效目标等场景观察模型如何选工具、是否反复误用、能否理解错误返回，再决定拆分或合并接口。不能只看 schema 合法；实际世界状态是否正确更关键。模型升级后重跑这些场景，检查原来为防错添加的限制是否仍有帮助。\n小结 工具设计应从真实调用和失败中迭代，让模型获得合适的信息与动作空间，同时保留明确的状态和执行边界。\n参考来源 原文：Seeing like an agent: how we design tools in Claude Code（claude.dev，2026-04-10） Claude Code 官方文档：工具参考 Claude Code 官方文档：用技能扩展 Claude Claude 平台文档：Tool use 概览 相关笔记 Claude 官方博客阅读总索引（固定 14 篇） Claude Code Skills 的设计与治理：How we use skills Claude Code 动态工作流：A harness for every task Claude 5 上下文工程：The new rules ","permalink":"https://blog.xiezaikui.com/posts/seeing-like-an-agent/","summary":"全文，覆盖提问工具三次尝试、任务演进、搜索接口、Guide 代理与结语。","title":"从代理视角设计工具：Seeing like an agent"},{"content":" 来源信息\n文档类型：阅读笔记 · 整理日期 2026-10-07 原文：《Claude Code in the cloud: a field guide》 · 作者 Addy Osmani · 发布于 claude.dev · 发布日期 2026-10-06 原文地址：https://claude.dev/blog/claude-code-in-the-cloud/ 本文为阅读整理，观点与数据以原文为准；原文不提供的事实均已标注为整理者说明。 阅读范围 全文，含并行实例、架构、本地对比、七种流程、连接排障、环境、习惯、问答与起步。 隔离与实例 云端会话让任务在独立机器和仓库副本上运行，避免争用文件与端口。示例分别修缓存竞态、校正文档、改结构化日志；日志任务仍遇到另一任务正在修的故障，如实报告而未越界修改。隔离也意味着分支间看不到彼此进展，汇合仍需处理依赖。\n文章架构把 GitHub token 放在虚拟机外的代理，任务使用受限凭据；项目配置随仓库进入，个人配置不随行。空闲机器可回收，恢复对话不代表临时文件和进程都保留。\n本地、云端与七种流程 本地硬件、私网数据或紧密视觉反馈适合本地；云端适合独立后台任务。远程控制仍在本机，自托管则是另一种基础设施选择。\n七类流程是并行清积压、反复验证修复、本地规划后云端实现再接回、手机跟进、处理 CI 与审查意见、触发式运行、在隔离环境检查不熟悉代码。示例成功与耗时属于样本，不保证实际项目表现。网络设为 None 也不代表绝无数据外发，模型请求和限定推送仍有通路。\n连接、环境与操作习惯 GitHub 身份连接和仓库 App 授权是两层；私有仓库、组织单点登录、IP 限制及管理员开关都可能影响访问。文章另述终端连接和一次性打包路径，本文未尝试。\n机器级安装与项目启动分开；快照保存文件，不保存运行进程。网络与共享变量应按需收窄，密钥不宜塞进共享变量。一个会话负责一个清楚任务，提供验收证据；并行会消耗共同额度。问答还涉及账号资格、数据保留与训练设置、机器资源、其他代码托管平台及冲突处理。\n边界与游戏开发建议 文中的套餐、促销、预览功能、资源规格和时间限制属于发布时说明，未核实为当前通用事实。本文未登录、连接、安装、上传仓库或建立自动任务。\n以下为整理者建议，非原文实测，也不表示已经实施。\n可把 NPC 数据校验、纯逻辑测试和文档核对设计成独立任务，明确输入版本与验收项。图形编辑器、授权插件、目标设备与帧率测试若依赖本地环境，则先判断远程机器能否提供有效证据，不能以云端单元测试替代真机体验。\n任务拆分应考虑共享资源和依赖顺序。每项报告标出已运行、失败、未检查及外部阻碍；并行成果合并后仍要做整体验证。上传前另行确认资产、存档、凭据和数据处理范围，隔离机器不能自动满足项目保密要求。\n小结 云端的价值是隔离与可持续执行；环境可复现、证据明确和成果汇合决定任务是否可靠完成。\n参考来源 原文：Claude Code in the cloud: a field guide to cloud sessions（claude.dev，2026-10-06） Claude Code 官方文档：网页版 Claude Code Claude Code 官方文档：云端环境 Claude Code 官方文档：沙箱环境 相关笔记 Claude 官方博客阅读总索引（固定 14 篇） Claude Code 动态工作流：A harness for every task Opus 5.5 协作与长任务：Getting the most out ","permalink":"https://blog.xiezaikui.com/posts/claude-code-in-the-cloud/","summary":"全文，含并行实例、架构、本地对比、七种流程、连接排障、环境、习惯、问答与起步。","title":"Claude Code 云端会话：Cloud field guide"},{"content":" 来源信息\n文档类型：阅读笔记 · 整理日期 2026-10-07 原文：《Getting started with Claude Code Mods》 · 作者 Addy Osmani · 发布于 claude.dev · 发布日期 2026-10-01 原文地址：https://claude.dev/blog/getting-started-with-claude-code-mods/ 本文为阅读整理，观点与数据以原文为准；原文不提供的事实均已标注为整理者说明。 阅读范围 全文，含机制、Token Weather 六步、分享、两个扩展、四条习惯与结语。 事件链机制 Mod 是插件中的 JavaScript 或 TypeScript 模块。register 注册事件处理，next 把事件交给后续插件及默认行为；处理器可观察、改写或直接回答。与逐事件启动的设置 hook 不同，它常驻会话，可保存状态、绘制界面并调用宿主能力。模块没有 DOM 或 Node，外部访问经宿主 API；这不等于插件没有操作权限。\nToken Weather 六步 教程从插件目录与清单开始，再挂接 AbovePrompt 绘图、读取上下文用量、保存历史、完成天气展示、验证测试，最后按插件方式分享。支持描述需求让 Claude 生成，但临时热加载目录与正式保留不同。\n热重载会重新注册并触发启动，模块变量会重置；宿主 state 可保留当前会话数据，且需类型契约声明。渲染中读取 state 会订阅变化。界面应适配真实可用宽度，没内容或其他界面需要位置时交还 next。示例测试模拟用量并核对重绘，展示的是上下文占用，不是精确费用。\n两个扩展与制作习惯 Blast Radius 暂缓风险命令，显示影响后让人选择；它只识别命令文本，别名和间接脚本可能绕过，不能替代权限系统。Replay Theater 观察写入前后内容，按主循环回合分组展示修改过程，不阻止编辑。\n四条习惯是使用本版本生成的类型、从 e.props 读组件属性、为热重载保存宿主状态、用日志排查无效渲染。结语列举用量显示、读文件地图、完成提醒等方向；分享依赖插件市场与安装流程。\n限制与游戏开发建议 文章要求特定最低版本，API 会变，应以实际构建的声明为准。第三方 mod 可通过宿主访问会话能力，需审查来源。本文未安装、运行教程命令、启用热加载或修改配置。\n以下为整理者建议，非原文实测，也不表示已经实施。\n可先考虑只读的 NPC 开发观察面板：显示本轮读取的状态定义、修改涉及的资源类型、待人工验证项。修改回放帮助理解改动顺序，但不能证明场景运行正确；必须补状态断言与实际试玩。\n风险提示可区分普通脚本编辑、场景资源覆盖和存档迁移，提供明确目标与取消出口。硬限制应在可靠的权限与路径检查层实现，不能仅用关键字匹配。避免把私人代码或存档全文保存进回放日志，先设计保留与清理规则。\n评估需包括热重载重复注册、窄屏布局、取消等待与多个插件的事件链交互。先确认面板没有改变原行为，再考虑改写功能，降低调试时难以归因的问题。\n小结 Mods 把观察、交互与行为扩展接到事件链上；状态生命周期、接口版本和权限边界需要一起设计。\n参考来源 原文：Getting started with Claude Code mods（claude.dev，2026-10-01） Claude Code 官方文档：Mods 概览 Claude Code 官方文档：Mods 事件 Claude Code 官方文档：Mods API Claude Code 官方文档：插件概览 相关笔记 Claude 官方博客阅读总索引（固定 14 篇） 从代理视角设计工具：Seeing like an agent Claude Code Skills 的设计与治理：How we use skills 精通 Claude Code（全文翻译） ","permalink":"https://blog.xiezaikui.com/posts/getting-started-with-claude-code-mods/","summary":"全文，含机制、Token Weather 六步、分享、两个扩展、四条习惯与结语。","title":"Claude Code Mods 入门：Getting started"},{"content":" 来源信息\n文档类型：阅读笔记 · 整理日期 2026-10-07 原文：《Using Claude Code: the unreasonable effectiveness of HTML》 · 作者 Thariq Shihipar · 发布于 claude.dev · 发布日期 2026-05-20 原文地址：https://claude.dev/blog/using-claude-code-the-unreasonable-effectiveness-of-html/ 本文为阅读整理，观点与数据以原文为准；原文不提供的事实均已标注为整理者说明。 阅读范围 全文，覆盖五项优势、起步、五类用途、问答和保持参与的结语。 为什么选择 HTML 作者认为长 Markdown 限制了自己阅读复杂计划的意愿。HTML 可结合表格、CSS、SVG、图像及交互，利用导航和响应布局提高可读性；托管后便于链接分享。滑块与选项还能把人的调整导出成提示，缩短反馈循环。Claude Code 可获取多种授权资料，但资料入口不代表自动获得读取许可。\n起步只需说明产物用途与期望，不一定先建技能。关键是让人更容易检查模型的选择，并非追求页面更漂亮。\n五类用途与闭环 规格、规划与探索：并排比较方案，逐步形成原型和实现计划，再供实现与验证参考。 代码审查与理解：显示实际差异、旁注和流程，帮助读者定位问题。 设计与原型：呈现样式参数、组件和动画，即使最终平台不是网页也可先讨论。 报告、研究与学习：通过导航、图示和代码出处组织复杂解释。 临时编辑界面：为当前数据提供排序、选择或调参界面，最终导出 JSON、差异或提示，交回工作流程。 作者问答承认 HTML 通常需要更多 token，其偏好明显偏向 HTML；多个文件可以记录规划的不同阶段。结语强调的是继续参与决策。文中的特定模型窗口规模不应当作所有模型的参数。\n适用限制 这是个人经验，未证明 HTML 普遍优于 Markdown。页面布局可能让遗漏不易察觉，图表与交互也可能错误。可执行脚本、外部资源、托管访问和导出兼容性需要按具体用途检查。本文仍按知识库规范保存 Markdown，未生成页面、部署或分享外部产物。\n游戏开发应用建议 以下为整理者建议，非原文实测，也不表示已经实施。\n要塞 NPC 玩法探索可在同一视图比较巡逻、生产和支援方案，列出玩家收益、资源需求与打断规则；选定方向后保留选择依据。动画调参可使用滑块展示时长和缓动，但需导出单位、参数名和适用状态，防止预览与引擎实现含义不一致。\n资源争用报告可把状态流、失败案例和日志出处放在一起，允许按 NPC 或资源查看；可视化只帮助定位，正确性仍靠复现与断言。导出动作宜先给可审阅的变更数据，再由获授权流程写入，避免拖动控件直接改动项目文件。\n对长期维护的规则，保留简洁文字和原始数据更容易检索；对一次性比较或难以口述的体验，交互页面可能更有帮助。可先用一个小问题检验是否减少误解、是否能准确回传选择，不必因文章偏好迁移全部笔记。\n小结 HTML 的潜在价值是让复杂信息可看、可试、可反馈；导出闭环与可核查内容比格式本身更重要。\n参考来源 原文：Using Claude Code: The unreasonable effectiveness of HTML（claude.dev，2026-05-20） Claude Code 官方文档：以产物形式分享会话输出 Claude Code 官方文档：最佳实践 相关笔记 Claude 官方博客阅读总索引（固定 14 篇） 从代理视角设计工具：Seeing like an agent Claude 5 上下文工程：The new rules 精通 Claude Code（全文翻译） ","permalink":"https://blog.xiezaikui.com/posts/the-unreasonable-effectiveness-of-html/","summary":"全文，覆盖五项优势、起步、五类用途、问答和保持参与的结语。","title":"HTML 作为协作产物：The unreasonable effectiveness"},{"content":" 来源信息\n文档类型：阅读笔记 · 整理日期 2026-10-07 原文：《Building with Claude Sonnet 5.5》 · 作者 Addy Osmani · 发布于 claude.dev · 发布日期 2026-09-28 原文地址：https://claude.dev/blog/building-with-claude-sonnet-5-5/ 本文为阅读整理，观点与数据以原文为准；原文不提供的事实均已标注为整理者说明。 阅读范围 全文，含选型、价格、参数、六项迁移、调优、拒绝回退与可用平台。 选型与费用 文章把 Sonnet 定位于规格明确、可验证的日常工程与快速迭代，复杂长程判断优先考虑 Opus。速度和用量改善是发布时比较，不是每个任务的保证。\n2026-09-28 原文列 Sonnet 5.5 每百万输入、输出 token 为 2、10 美元，Opus 5.5 为 4、20 美元；这是当时 API 目录价，非当前报价或订阅账单。缓存、推理区域、图像分辨率与平台默认 effort 都会影响实际用量，不能只比较单价。\n参数与迁移机制 文中模型默认启用自适应思考，响应需按内容块类型读取，不能假定第一块就是文本。迁移不只替换模型 ID：\nbetween_tools 替代旧的禁用前置思考方式，仅支持部分 effort；仍可能有工具间进度块。 强制 tool_choice 改为 auto，配合 strict schema；结构合法不等于必然调用工具。 对话追加保留思考块，注意模型之间的兼容边界。 computer use 转为 toolset，需处理成员调用和结果结构，平台支持存在差别。 advisor 配对受限，建议结果可能以不可读取的加密块返回。 工具间进度需按 thinking 块及 display 设置展示。 调优、拒绝与可用性 重新扫描 effort，不沿用旧模型同名档位的投入假设；清理旧补丁后跑评估。低档也要用实际测试或构建验证，不能把语法检查当完工。思考占输出预算；缓存最低长度和逐消息 effort 的行为也需按接口检查。\n拒绝可能以 HTTP 200 加 refusal 状态返回；回退只适用文章所列类别，不能把成功 HTTP 状态当业务成功。可用平台、别名、预览和默认值均为当时说明，本文未执行迁移、安装或改配置。\n游戏开发应用建议 以下为整理者建议，非原文实测，也不表示已经实施。\nNPC 资源表、明确的状态转换和小功能修复可作为日常选型样本；跨系统冲突与长期架构判断另设困难样本。比较时统一输入、验收、失败处理和环境，记录成功率、延迟与完整任务成本。\n接口迁移测试应覆盖文本、工具调用、拒绝和截断等响应，不把没有报错等同正确运行。strict 输入只能检查结构，资源所有权、状态版本和执行授权应由业务层验证。图像审阅按需要选择分辨率，避免低细节图遗漏状态，也避免无意义地增加输入。\n小结 选型依赖任务范围与验证能力；迁移要核对行为和响应结构，价格与性能判断应以实际负载重测。\n参考来源 原文：Building with Claude Sonnet 5.5（claude.dev，2026-09-28） Claude 平台文档：Effort（思考档位） Claude 平台文档：Extended thinking（扩展思考） Claude 平台文档：Computer use 工具 Claude 平台文档：拒绝与回退 相关笔记 Claude 官方博客阅读总索引（固定 14 篇） Claude Code 思考档位选择：Spending your effort Opus 5.5 任务成本：What a task costs Claude Code 提示缓存：Prompt caching is everything ","permalink":"https://blog.xiezaikui.com/posts/building-with-claude-sonnet-5-5/","summary":"全文，含选型、价格、参数、六项迁移、调优、拒绝回退与可用平台。","title":"Sonnet 5.5 选型与迁移：Building with Claude"},{"content":" 来源信息\n文档类型：阅读笔记 · 整理日期 2026-10-07 原文：《Automating eval design and hillclimbing》 · 作者 Lance Martin · 发布于 claude.dev · 发布日期 2026-09-28 原文地址：https://claude.dev/blog/automating-eval-design-and-hillclimbing/ 本文为阅读整理，观点与数据以原文为准；原文不提供的事实均已标注为整理者说明。 阅读范围 全文，含评估原则、build-eval、爬坡与过拟合、hillclimb、两项案例和起步。 先证明评估可信 任务要代表实际用途，难度有可通过的提升空间，重复运行的噪声低；更强模型或更多思考未改善时，应检查任务和评分器。只挑某模型当前失败的案例，可能测到其弱点指纹；真实流量也可能偏向容易任务。\nbuild-eval 按真实记录、故障报告、手写样例和合成输入构建案例，再让人确认。封闭输出优先程序检查；开放输出可用独立模型按可检查标准评分，比较时随机顺序。先核对评分样本，再跑基线、重复次数与置信区间，保留逐例轨迹。评分一致性、超时、截断与饱和度都需诊断。\n优化循环与泄漏 爬坡适合修改便宜、作用可归因且目标清楚的对象。每轮一项变更，只读训练失败；留出集用于检查泛化，退化或仅训练提升则回退。停滞时分类剩余失败，区分真实错误、评分缺陷与噪声，不无限换词。\n不能把案例答案或失败原文塞进通用提示，答案须结构性隔离。留出数据即使不供模型阅读，反复用它选版本仍可能产生选择偏差；最终效果宜另做独立检验，这是整理者补充判断。\n案例与适用限制 2026-09-28 原文的客服案例为 44 张工单，30 张用于搜索、14 张留出；API 技能案例通过补齐功能、修类型表和排查评分矛盾改善。两者表明应同时审视系统与评估，不是所有任务都能复制其成本或得分增益。部分配图为示意，不能当实测曲线。\n起步章节介绍两个技能命令；本文未更新、调用、改提示或运行评估。\n游戏开发应用建议 以下为整理者建议，非原文实测，也不表示已经实施。\nNPC 决策评估应覆盖日常生产、战斗打断、资源不足与存档恢复，同时包含不应行动的情形。硬规则用状态断言；体验质量用清楚量表和人工审阅，避免单一总分掩盖严重故障。\n分离场景与随机种子，清理运行残留，限制优化过程能读哪些案例。一次只改一个可归因因素，记录各类成功率、费用、延迟及未运行项。若系统“变好”只是学会识别固定种子或评分措辞，应视为警报，而不是玩法能力提升。\n可先用少量真实失败建立基线，再扩样降低不确定性。预算不够时明确证据不足，不能用更多优化轮次替代可信评估。\n小结 先校准任务和评分器，再做可归因改进；留出、证据与噪声判断决定分数是否值得相信。\n参考来源 原文：Automating eval design and hillclimbing with Claude（claude.dev，2026-09-28） Claude Code 官方文档：插件与技能评估 Agent Skills：评估 Skill Claude 平台文档：构建测试与评估 相关笔记 Claude 官方博客阅读总索引（固定 14 篇） Claude Code Skills 的设计与治理：How we use skills Claude Code 动态工作流：A harness for every task 性能优化的测量闭环：How we made claude.ai faster ","permalink":"https://blog.xiezaikui.com/posts/automating-eval-design-and-hillclimbing/","summary":"全文，含评估原则、build-eval、爬坡与过拟合、hillclimb、两项案例和起步。","title":"评估设计与爬坡优化：Automating eval"},{"content":" 来源信息\n文档类型：阅读笔记 · 整理日期 2026-10-07 原文：《What a task costs on Opus 5.5》 · 作者 Addy Osmani · 发布于 claude.dev · 发布日期 2026-09-25 原文地址：https://claude.dev/blog/what-a-task-costs-on-opus-5-5/ 本文为阅读整理，观点与数据以原文为准；原文不提供的事实均已标注为整理者说明。 阅读范围 全文，含成本因素、版本变化、比较、effort、模型路由、提示审计、缓存压缩、自测和结语。 成本单位是完成任务 费用受回合数、缓存读取、输出和模型单价共同影响。每轮重送历史，累计输入可远大于上下文长度；思考也计入输出。省 token 若增加返工，完整任务可能更贵。\n2026-09-25 原文采用 Opus 5.5 每百万输入 4、输出 20、缓存读 0.20 美元的 API 目录价。同 token 的示意会话是 200 万缓存读、20 万新输入、6 万输出：Opus 5 为 3.50 美元，5.5 为 2.40 美元，未计缓存写、折扣。约 31% 差额只反映这组价格与用量，非实测用户节省。\n文章另述默认负载约少花 40% 的估计，包含价格和模型用量变化，不是每 token 降价 40%。订阅额度与 API 计费也不能混同。\n调整与缓存压缩 先提供可运行的验证，再评估提高 effort 或换模型。查找可交给小模型，复杂判断留在主模型，但误读资料会造成额外绕路；子代理与团队各自用量也需计入。提示审计的客服案例仅是一个样本。\n稳定前缀与持续会话有利于缓存；过期、换模型、工具变化和部分平台的 effort 变化可增加写入。压缩可降低以后重送成本，却消耗一次总结且可能丢信息；无关任务重开，连续任务在自然节点总结。文中还讨论初始项目说明、延迟加载、fast mode、批处理与团队费用。\n自测与限制 文章建议在真实任务比较回合、输出、缓存占比与完成结果，查看 usage 及团队报告；订阅中的美元估算不是账单。目录价、缓存时效、预览倍率和企业平均值均属发布时条件，不能当当前报价或个人预算。\n本文完整读取正文与图示说明，但未操作交互滑块、运行命令或产生费用；没有用户实测数据。\n游戏开发应用建议 以下为整理者建议，非原文实测，也不表示已经实施。\n可用 NPC 小功能、资源冲突修复与跨系统改动组成成本样本，统一验收后记录全部尝试，包括失败重试和人工补救。只比较成功会话会低估难任务成本；探索阶段的有用反馈也应单独评估。\n把生产逻辑、场景截图和日志按需提供，保留关键种子、状态版本和约束。总结前列出必须保留的证据，不能为了省输入删掉复现线索。机械修改可测试低投入，复杂验证提高投入，但结论要由样本支持。\n预算可分模型费用、环境费用和人的时间，避免把 API 估算当作开发总成本。先测小批负载，再讨论是否调档或换模型，不采用文章比例直接预测项目账单。\n小结 比较的是可靠完成任务的总成本；价格、用量、返工与验证需分开记录，再用自己的任务判断。\n参考来源 原文：What a task costs on Opus 5.5（claude.dev，2026-09-25） Claude Code 官方文档：费用 Claude Code 官方文档：用量监控 Claude 平台文档：模型定价 Claude 平台文档：Prompt caching 相关笔记 Claude 官方博客阅读总索引（固定 14 篇） Claude Code 提示缓存：Prompt caching is everything Claude Code 思考档位选择：Spending your effort Sonnet 5.5 选型与迁移：Building with Claude ","permalink":"https://blog.xiezaikui.com/posts/what-a-task-costs-on-opus-5-5/","summary":"全文，含成本因素、版本变化、比较、effort、模型路由、提示审计、缓存压缩、自测和结语。","title":"Opus 5.5 任务成本：What a task costs"},{"content":" 来源信息\n文档类型：阅读笔记 · 整理日期 2026-10-07 原文：《How we made claude.ai faster》 · 作者 Raymond Wang、Sam Attard、Issac G. · 发布于 claude.dev · 发布日期 2026-09-23 原文地址：https://claude.dev/blog/how-we-made-claude-ai-faster/ 本文为阅读整理，观点与数据以原文为准；原文不提供的事实均已标注为整理者说明。 阅读范围 全文，含目标、指标爬坡、线程闭环、扩展、防护、人工引导、帧预算与后续。 样本与目标 文章回顾 2026 年 8 月两周冲刺，用内部研究模型和人工批准改进网站与桌面体验。实时用户监测比较 8 月 13 日与 27 日：网页可输入时刻的 p75 从 3.1 秒到 0.55 秒。标题“约三倍”是核心旅程的概括，不是所有操作、模型推理或网络请求都快三倍。\n团队从高频旅程建立统一起止点，区分客户端与服务端。静态输入框、桌面代码缓存、复用组件与预取等解决不同瓶颈，不能归因于单一技巧。\n测量与线程闭环 真实耗时有噪声，实验室尝试指令计数、函数调用、渲染提交、布局及 DOM 变化等代理指标。只有证明关联用户延迟、且稳定的指标才成为回归门槛。\n流程是发现慢路径、建立基准、小步修改、部署看真实数据，再收紧门槛或关开关重试。侧栏抖动案例显示总体 CLS 好看也可能漏掉体验问题，需按区域与阶段监测。并行扩展后还发现重复订阅、样式重算与字符串高亮等问题。\n防护、引导与帧预算 修改先有测试、自动审查和人工批准，可见风险用短期功能开关与分阶段发布。静态界面接管需检查尺寸对齐、按键不丢失与现场位移，实验室还可能遗漏浏览器界面触发的变化。\n人负责目标、体验取舍、线程边界与维护成本。120 Hz 实验采用确定性帧推进及约 8.33 ms 预算，通过缓存完成块、将处理移到 worker 等优化；保持 120 fps 的报告有特定 MacBook 与场景条件。结语仍列 p95、其他旅程和长对话的改善空间。\n限制与游戏开发建议 这是特定产品、负载、硬件和冲刺流程的报告，未独立复现实验，也不能复制其百分比预测游戏性能。本文未运行基准、部署或建立持续监控。\n以下为整理者建议，非原文实测，也不表示已经实施。\n要塞场景先定义玩家感受的等待和帧时间，再按寻路、NPC 调度、资源查询与 UI 刷新拆分。操作计数可辅助定位，但必须与目标设备的帧耗时关联，不能只追求计数下降。\n用固定场景、种子和单位规模做可重复基准，并补充真实试玩。优化前后核对行为一致性，关注峰值和长尾，而非仅平均值。缓存、批处理与跨线程可能引入过期状态、任务延迟或顺序问题，需功能断言保护。\n每次只验证一项假说，记录收益和维护代价；若小幅提速需要复杂机制，应由人判断是否值得。回归门槛也要允许合理功能增长，不能让单向数字目标迫使系统牺牲体验。\n小结 先让正确的体验指标可测，再形成优化、现场验证与回归保护闭环；人的判断决定哪些数字值得追求。\n参考来源 原文：How we made claude.ai 3x faster in two weeks（claude.dev，2026-09-23） Core Web Vitals（Google web.dev 官方性能文档） Cumulative Layout Shift（Google web.dev 官方性能文档） 优化 LCP（Google web.dev 官方性能文档） 相关笔记 Claude 官方博客阅读总索引（固定 14 篇） 评估设计与爬坡优化：Automating eval 说明 本篇主题为前端性能测量，Anthropic 官方文档中暂无对口章节，外链改用 Google web.dev 官方性能文档。 ","permalink":"https://blog.xiezaikui.com/posts/how-we-made-claude-ai-faster/","summary":"全文，含目标、指标爬坡、线程闭环、扩展、防护、人工引导、帧预算与后续。","title":"性能优化的测量闭环：How we made claude.ai faster"},{"content":" 来源信息\n文档类型：译文 · 整理日期 2026-10-07 原文：《Mastering Claude Code》 · 作者 Damien Gallagher · 发布于 dev.to · 发布日期 2025-07-04 原文地址：https://dev.to/damogallagher/mastering-claude-code-4b81 本文为原文的中文翻译整理，命令名、参数与专有名词保留原文写法。 本文是上述原文的完整中文翻译，版权归原作者及原发布平台所有；如需转载请先取得原作者授权。文中斜杠命令、子代理与钩子的机制命名在原文发布后已有变动，具体行为请以官方文档为准。 来源与时效 原文：Mastering Claude Code（dev.to，2025-07-04 发布，2025-07-28 更新），正文按原文 12 个步骤顺序翻译，图片取自原文本地附件。 时效提示：原文发布于 2025 年，文中斜杠命令、子代理与钩子的机制和命名此后已变动，具体行为请以官方文档为准。 第 1 步：在你的项目中拥有一个有效的 CLAUDE.md 文件 每次你发出提示时，CLAUDE.md 文件中列出的所有内容都会被 Claude Code 读取。通过添加这些规则，它指示 Claude Code 将思考分解为任务，并在实施之前将事项提交给你审核。\n1. 初步分析与规划： 首先分析问题，检查相关的代码文件，并在 tasks/todo.md 中记录你的方法。 2. 清单结构： 将你的计划构造成可执行的清单项，完成后可标记为已完成。 3. 批准阶段： 在实施之前，提交你的策略以供我批准和确认。 4. 执行过程： 开始执行清单项目，并在完成每一项时更新其状态。 5. 进度沟通： 在过程的每个阶段提供对你所做修改的简要概述。 6. 简单性原则： 优先考虑最小且直接的修改。避免大量或复杂的改动。将每次更改的范围限制在尽可能少的代码上。所有决策都要强调简洁性。 7. 文档与总结： 在 todo.md 文件中以回顾部分结尾，总结你的实现内容及任何值得注意的细节。 第 2 步：正确使用 Plan 模式 如果正确使用 Plan 模式，它将有助于在 Claude 中获得所需结果。要访问 Plan 模式，打开 Claude Code，按 shift 然后连续按两次 tab 进入该模式。在 Plan 模式中，你需要向 Claude 精确描述你希望它执行的内容，然后让 Claude 为你制定该计划。\n在深入实施之前，应广泛使用 Plan 模式。这将从长远来看节省时间，因为 Claude 会有一个清晰的执行计划，你也会确切知道将交付什么。\n此外，使用正确的模型也很重要。对于“计划模式”，Opus 是一个很好的模型，用来制定稳固的计划。有了计划后，就可以使用 Sonnet 来执行该计划。通过使用 Sonnet 来执行，它会按照 Opus 制定的详细计划来完成任务。同时，使用更便宜的模型来实现还能节省开支。 注意： Opus 不适用于 Claude Pro 用户（每月 17 美元），你需要订阅 Claude Max 计划（从每月 100 美元起）才能使用 Opus。如果你使用的是 Claude Pro 计划，Sonnet 是用于计划模式和执行的最佳选择。\n第 3 步：使用检查点保存进度 其他 AI 编程工具（如 Cursor）具有自动检查点功能，但 Claude Code 默认不包含此功能。取而代之的是，你可以使用 GitHub 来实现检查点。通过将你满意的代码作为 Git 提交推送到 GitHub，代码就处于良好状态。如果你对代码不满意，可以在 Git 中撤销最新更改。\nClaude Code 的 Git 检查点工作流：\n# Before Claude starts a new feature git add . \u0026amp;\u0026amp; git commit -m \u0026#34;Checkpoint: Before adding user dashboard\u0026#34; # After Claude completes the feature successfully git add . \u0026amp;\u0026amp; git commit -m \u0026#34;✅ Add user dashboard with charts\u0026#34; # If unhappy with Claude\u0026#39;s changes git reset --hard HEAD~1 # Rollback to previous checkpoint 最佳实践：\n在每个重大的 Claude 任务之前提交 - 创建还原点 使用描述性信息 - “在添加 X 之前”和“✅ 完成 X” 定期推送 - git push origin main 以备份进度 创建实验分支 - git checkout -b test/new-approach 用于尝试不同的 Claude 解决方案 参见 第 12 步：钩子 获取有关如何让 Claude 为你管理检查点的信息。\n第 4 步：使用 /clear /clear 命令对于保持 Claude Code 的高效性至关重要。你应该定期清除上下文，通过限制发送给 Claude 的信息来减少幻觉和成本。\n何时使用 /clear：\n在完成 3-5 个相关任务之后 在切换到完全不同的功能领域时 当 Claude 开始给出不太相关的回复时 在开始新的重大开发阶段之前 什么构成“重大任务”：\n实现一个完整的功能（身份验证、用户仪表板等） 重大重构或架构性更改 完成一次完整的调试会话 完成一次安全审查周期 每当 Claude 完成一项重要任务时执行 /clear。将 /clear 作为你工作流程中不可或缺的一部分。\n第 5 步：安全检查 对所有 AI 生成的代码进行安全检查以确保其安全性非常重要。AI 目前还不能开箱即用地提供安全代码，所以务必进行安全检查。在 Claude 中构建功能后，请运行安全检查。 以下提示可用于运行安全检查。\n请对您最近的代码实现进行彻底审查，以验证其是否符合安全规范。核实敏感数据不会从前端泄露，并评估代码是否存在任何潜在的安全漏洞或可被利用的缺陷。\n第 6 步：Claude Code 中的图像 在 Claude Code 中，您可以提供图像。这些图像可用于根据设计构建功能，或在您想修复当前 UI 中的错误时使用。这是一个强大的功能，可在合适的场景中使用。\n设计实现： 当你有模型图或设计文件时，上传它并使用类似以下的提示：\n请使用 React 和 Tailwind CSS 实现此设计。注意图片中显示的间距、颜色和响应式行为。\n带截图的修复错误： 如果你遇到视觉上的错误，请截图问题并提问：\n当前界面看起来像这样 [附截图]。按钮应当居中，文本应正确对齐。请找出并修复导致此布局问题的 CSS 问题。\n功能增强： 通过上传参考图像使用前后对比：\n我想把这个组件改进得更像这个参考设计[附图]。请在保持现有功能的同时，提出具体改进建议并实现它们。\n图像使用最佳实践：\n使用高质量、清晰且对比度良好的图像 裁剪图像以突出相关的界面元素 如果功能包含交互元素，请包含多个角度或不同状态的图片 将图像与详细的文字描述结合以获得最佳效果 第 7 步：向 Claude 学习 使用 Claude 来帮助你学习——非常简单。一旦 Claude 构建了一个功能并确保其安全，你可以使用以下提示来帮助你理解 Claude 所构建的内容。这将确保你更好地理解生成的应用程序，也将帮助你在将来构建应用时改进提示。\n理解实现细节： 在 Claude 完成功能后，使用此提示：\n请提供你刚刚创建的实现的全面解析。引导我了解你所引入的修改，并详细阐述其运行机制。以一位有经验的开发者辅导同事阅读代码库的方式来说明。\n学习新模式和新技术： 当 Claude 使用不熟悉的技术或模式时：\n我注意到你使用了[具体技术/模式]。你能解释为什么选择这种方法而不是其他可选方案吗？有哪些优点和潜在缺点？在更大型的应用中，这种做法如何扩展？\n代码审查与最佳实践： 请求对生成代码的建设性反馈：\n请从高级开发者的角度审查你刚才创建的代码。可以改进的地方有哪些？是否存在任何性能优化、安全方面的考虑或可维护性问题需要我注意？\n未来规划与架构： 了解当前实现如何适应更大的整体架构：\n这项实现会如何影响整体架构？扩展此功能的下一个合乎逻辑的步骤是什么？如果我以后想添加【特定功能】，应考虑哪些因素？\n学习资源： 请求更多学习材料：\n基于我们刚才使用的代码模式和技术，你会推荐哪些资源让我加深理解？有没有特定的概念我应该进一步学习？\n第 8 步：在 Claude 工作时保持高效 与其在 Claude 工作时浏览社交媒体，不如把那段时间用于有成效的对话。 以下是一些专注的方法：\n技术学习与讨论：\n我注意到在与 AI 合作进行编码项目时，在发出指令和收到输出之间会有自然的间歇。与其陷入那种让我感到心神不宁、毫无成效的无目的在线浏览，不如利用这些时间与你进行建设性的对话。内容可以包括探索新概念、审视我现有的事业和创意项目，或只是进行富有深度的交流。我还没确定哪种框架或方法最有效，但我相信这会比我目前的默认行为更有意义。你有什么建议可以让这些对话变得更高效、更有吸引力？\n项目规划与架构： 利用等待时间规划未来的功能：\n在你开发当前功能的同时，我们来讨论这个项目的下一个阶段。我在考虑新增[具体功能]。我需要注意哪些架构方面的考虑？我们应该如何设计数据库模式和 API 端点？\n代码质量和标准： 建立编码标准和约定：\n让我们为这个项目建立一些编码约定。对于像这样的[type of application]，你会推荐哪些命名约定、文件结构和代码组织模式？\n问题解决与调试： 在问题出现之前讨论潜在问题：\n在构建[type of feature]时，通常会出现哪些最常见的问题？我们如何主动应对这些问题？我应该记住哪些调试策略？\n技术探索： 探索相关技术和工具：\n在我们构建这个 React 应用时，React 生态系统中的哪些其他工具可能会有帮助？我们是否应该考虑加入测试框架、状态管理库或开发工具？\n职业与学习发展： 利用这段时间进行职业成长：\n根据我们在这个项目中使用的技术，我接下来应该重点发展哪些技能？我应该关注哪些与[relevant field]相关的当前趋势？\n文档与规划： 创建文档和项目路线图：\n帮我为我们正在构建的内容创建全面的文档。README 应该包括什么？我们应如何为未来的开发者构建项目文档结构？\n第 9 步：要遵循的开发工作流 现在我们已经讨论了所有步骤，在使用 Claude Code 时拥有一个可靠的开发工作流非常重要。以下步骤对我有效，希望你也能通过类似流程取得成功。\n规划 你要构建的功能或应用 构建 应用程序，依据已达成的计划 针对生成的代码运行一次 安全检查 学习 Claude 刚刚为你构建/修改了什么 在 Claude 在后台构建时， 高效工作 在 git 中对你的代码做 检查点 （如果你对当前状态不满意，可回滚到最初） /clear 在构建完一个有意义的功能后清除上下文 第 10 步：斜线命令 斜杠命令允许你在交互会话中控制 Claude Code 的行为。\n内置斜杠命令 下面是一些示例：\n/init：使用 CLAUDE.md 指南初始化项目 /clear：清除对话历史 /help：获取使用帮助 /mcp：管理 MCP 服务器连接和 OAuth 身份验证 完整的内置斜杠命令的权威列表可以在 这里 找到\n自定义斜杠命令 但等等……更棒的是，你还可以创建自定义斜线命令以适应你的工作流程。自定义斜线命令允许你将常用提示定义为 Claude Code 能执行的 Markdown 文件。命令按作用域（项目特定或个人）组织，并通过目录结构支持命名空间。\n项目斜线命令 这些是存储在你仓库中并与团队共享的斜线命令。\n这些命令的位置和前缀如下 位置： .claude/commands/ 前缀： /project:\n例如，我们把之前的安全审查提示作为一个项目斜线命令添加进去\nmkdir -p .claude/commands echo \u0026#34;Please perform a thorough examination of your recent code implementation to validate compliance with security protocols. Verify that sensitive data remains protected from frontend exposure and assess the code for any potential security gaps or exploitable flaws:\u0026#34; \u0026gt; .claude/commands/security-review.md 在 Claude Code 中，我们现在可以使用该斜杠命令，语法为 /security-review\n安全审查项目斜杠命令也可以通过以下语法触发 /project:security-review\n下面是一个用于将当前代码更改提交并推送到 GitHub 的示例项目斜杠命令\nmkdir -p .claude/commands echo \u0026#34;Checkin the current code and push it to github:\u0026#34; \u0026gt; .claude/commands/checkin.md 在 Claude Code 中，我们现在可以使用该斜杠命令，语法为 /checkin\n签到项目的 slash 命令也可以使用语法 /project:checkin\n个人斜线命令 这些是可在你所有项目中使用的斜线命令，并不存放在任何仓库中\n这些命令的位置和前缀如下 位置： ~/.claude/commands/ 前缀： /user:\n举例来说，我们把之前的“提高工作效率”提示作为一个个人斜线命令来添加\nmkdir -p ~/.claude/commands echo \u0026#34;I notice that while working with AI on coding projects, there are natural intermissions between giving instructions and receiving outputs. Rather than falling into unproductive online browsing patterns that leave me feeling scattered, I\u0026#39;d like to leverage these periods for constructive dialogue with you. This could involve exploring new concepts, examining my existing ventures and creative projects, or simply having thoughtful exchanges. I haven\u0026#39;t defined exactly what framework or approach would work best, but I\u0026#39;m confident it would be more enriching than my current default behavior. What suggestions do you have for making these conversations most productive and engaging:\u0026#34; \u0026gt; ~/.claude/commands/productivity.md 在 Claude Code 中，我们现在可以使用该斜杠命令，语法为 /productivity\n生产力个人斜线命令也可以使用以下语法触发 /user:productivity\nMCP 斜杠命令 MCP（模型上下文协议）服务器可以将提示作为斜杠命令暴露出来，这些命令会在 Claude Code 中可用。这些命令会从已连接的 MCP 服务器动态发现。\n当以下情况成立时，MCP 命令会自动可用：\n已连接且处于活动状态的 MCP 服务器 服务器通过 MCP 协议暴露提示 在连接时成功检索到这些提示 有关 MCP 斜杠命令的完整详细信息，请参见 here。 将会有一篇后续文章介绍 MCP 及其在 Claude Code 中的使用。\n用于生成斜杠命令的有用提示 更新文档\n为我用 Claude Code 构建一个斜杠命令，每次我进行代码更改时，都会自动更新我所有的自述文件、文档和 CLAUDE.md 文件\n第 11 步：子代理 子代理是预先配置的 AI 个性，Claude Code 可以将任务委派给它们。把它们看作专门的团队成员，每个成员都被设计来处理特定类型的工作。\n每个子代理有四个关键特征：\n特定专长：围绕特定目的构建，如调试、文档或数据分析 独立工作区：使用与主对话分开的上下文窗口 可配置的工具：可以设置为允许访问特定工具 自定义行为：包括一个定制的系统提示，指导其如何处理任务 子代理的例子可以是架构师、前端开发人员、后端开发人员等。\n当 Claude Code 遇到与某个子代理专长匹配的任务时，它会将该工作委派给该专家。子代理独立工作并返回聚焦的结果，从而创建更高效的工作流程，使每个任务都由最有资格的 AI 助手处理。 这种委派系统让你在无需管理多个对话或在主工作流中丢失上下文的情况下，利用到专门的 AI 专业知识。\n幸运的是，在 Claude Code 中创建子代理很简单，我将带你一步步完成这个过程。\n在 Claude Code 中，输入 /agents\n如果你已经有现有的 agent，它们现在会被列出；否则请选择“Create new agent”并点击下一步\n在创建代理时，它们可以用于某个项目或作为个人代理，这类似于自定义斜杠命令（项目仅针对该项目，个人会影响你所有的项目）。对于这个代理，我们将选择“项目（Project）”并按回车。\nClaude Code 提供了两种设置代理的选项\n使用 Claude 生成（推荐）或 手动配置。我们将选择“使用 Claude 生成”，然后按回车键 现在我们来描述这个代理。下面是我输入的内容\n经验丰富的架构师，负责初始架构设计、技术选型指导，并在项目发生重大变更或需要引入新技术实现的功能时参与其中。该架构师是所有重大技术决策的权威来源。\nClaude 现在正在生成代理配置\n现在我们选择代理可访问的工具。在此处您可以选择代理能执行的操作，并关联您已设置的任何 MCP 服务器。目前，该代理可以访问所有工具。选择“所有工具”，向上滚动到“继续”并按回车。\n可能你要做的最重要的决定就是颜色。说实话，Claude Code 会为你完成其余的大部分繁重工作 :)。这个颜色在代理为你执行任务时会成为一个有用的指示。我会把它设置为“自动颜色”并按回车。\n现在我们可以预览 Claude Code 为我们设计的代理。如果需要，我们可以在我的编辑器中选择 e 进行修改，但我将直接回车以接受。\n由于我选择创建一个个人子代理，现在在我的 .claude 目录中会有一个 agents 文件夹，其中包含我们在 /agents 提示中创建的代理。\n以下是已创建的 tech-architect.md agents 文件的内容。\n--- name: tech-architect description: \u0026#34;Use this agent when you need architectural guidance, technology selection advice, or approval for major technical decisions. Examples: \u0026lt;example\u0026gt;Context: User is starting a new project and needs to choose between different frameworks. user: \u0026#39;I\u0026#39;m building a real-time chat application and need to decide between Node.js with Socket.io, Go with WebSockets, or Python with FastAPI and WebSockets. What would you recommend?\u0026#39; assistant: \u0026#39;Let me consult with the tech-architect agent to get expert guidance on the best technology stack for your real-time chat application.\u0026#39; \u0026lt;commentary\u0026gt;Since this involves major technology selection for a new project, use the tech-architect agent to provide comprehensive architectural guidance.\u0026lt;/commentary\u0026gt;\u0026lt;/example\u0026gt; \u0026lt;example\u0026gt;Context: User wants to implement a new caching layer that will significantly impact the system architecture. user: \u0026#39;Our API is getting slow with increased traffic. I\u0026#39;m thinking of adding Redis for caching, but I\u0026#39;m not sure how to integrate it properly with our existing PostgreSQL setup.\u0026#39; assistant: \u0026#39;This is a significant architectural decision that will impact your system\u0026#39;s performance and complexity. Let me bring in the tech-architect agent to provide guidance on implementing caching effectively.\u0026#39; \u0026lt;commentary\u0026gt;Since this involves adding new technology that will impact the overall architecture, use the tech-architect agent for expert guidance.\u0026lt;/commentary\u0026gt;\u0026lt;/example\u0026gt;\u0026#34; --- You are a Senior Technology Architect with 15+ years of experience designing scalable, maintainable systems across diverse industries and technology stacks. You are the authoritative source for all major technology decisions and architectural guidance within projects. Your core responsibilities: - Evaluate and recommend technology stacks based on project requirements, team capabilities, and long-term maintainability - Design system architectures that balance performance, scalability, security, and development velocity - Provide guidance on major technical decisions including database choices, framework selection, deployment strategies, and integration patterns - Review and approve architectural changes that could impact system design, performance, or maintainability - Assess technical risks and provide mitigation strategies - Ensure technology choices align with business objectives and technical constraints Your decision-making framework: 1. **Requirements Analysis**: Thoroughly understand functional and non-functional requirements, including performance, scalability, security, and compliance needs 2. **Context Assessment**: Consider team size, expertise level, timeline constraints, budget limitations, and existing technology investments 3. **Technology Evaluation**: Compare options based on maturity, community support, learning curve, performance characteristics, and long-term viability 4. **Risk Assessment**: Identify potential technical debt, vendor lock-in, scalability bottlenecks, and maintenance challenges 5. **Recommendation**: Provide clear, justified recommendations with implementation guidance and success metrics When providing architectural guidance: - Always ask clarifying questions about requirements, constraints, and context before making recommendations - Present multiple viable options with trade-offs clearly explained - Consider both immediate needs and long-term evolution of the system - Provide specific implementation guidance, not just high-level concepts - Include monitoring and observability considerations in your recommendations - Address security implications of architectural decisions - Consider operational complexity and team capabilities For technology selection: - Evaluate based on project-specific criteria, not personal preferences - Consider the total cost of ownership, including development, deployment, and maintenance - Assess community ecosystem, documentation quality, and long-term support - Factor in integration complexity with existing systems - Recommend proof-of-concept approaches for high-risk technology choices You communicate with authority but remain open to discussion. When you identify potential issues with proposed approaches, you explain the risks clearly and suggest alternatives. You balance technical excellence with practical constraints, always keeping business objectives in focus. 现在当你在 Claude Code 中选择 /agents 命令时，你可以看到我们刚创建的代理。\n如果你选择该代理并按回车键，就可以看到 Claude Code 为你的自定义子代理提供的选项。\n现在让代理开始工作吧。\n我将在计划模式下发出一个非常简单的开放式提示，用于在浏览器中玩的俄罗斯方块游戏。提示如下：\n创建一个基于浏览器的俄罗斯方块游戏\n正如你从 Claude Code 中看到的，它已经咨询了技术架构子代理，并制定了构建此俄罗斯方块游戏的计划。请注意技术架构交互以红色标出。\n这是 Claude Code 在我们的技术架构子代理协助下制定的计划。\nReady to code? │ │ │ │ Here is Claude\u0026#39;s plan: │ │ ╭─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │ │ │ Tetris Game Implementation Plan │ │ │ │ │ │ │ │ Phase 1: Project Setup \u0026amp; Core Structure │ │ │ │ │ │ │ │ 1. Create main HTML file with Canvas element and basic UI │ │ │ │ 2. Set up CSS for game styling and responsive design │ │ │ │ 3. Create core JavaScript files: │ │ │ │ - GameEngine.js (main game loop with fixed timestep) │ │ │ │ - Constants.js (game configuration and tetromino definitions) │ │ │ │ - GameState.js (state management) │ │ │ │ │ │ │ │ Phase 2: Core Game Mechanics │ │ │ │ │ │ │ │ 4. Implement TetrisBoard.js: │ │ │ │ - 10x20 grid representation │ │ │ │ - Collision detection system │ │ │ │ - Line clearing algorithm │ │ │ │ 5. Create Tetromino.js and TetrominoManager.js: │ │ │ │ - All 7 tetromino pieces (I, O, T, S, Z, J, L) │ │ │ │ - Rotation matrices and wall kicks │ │ │ │ - Piece spawning and movement logic │ │ │ │ 6. Build InputHandler.js for keyboard controls: │ │ │ │ - Arrow keys for movement/rotation │ │ │ │ - Space for hard drop │ │ │ │ - Proper input debouncing │ │ │ │ │ │ │ │ Phase 3: Rendering \u0026amp; Visual Polish │ │ │ │ │ │ │ │ 7. Implement Renderer.js: │ │ │ │ - Double-buffered canvas rendering │ │ │ │ - Efficient redraw only changed regions │ │ │ │ - Tetromino colors and grid visualization │ │ │ │ 8. Add ScoreManager.js: │ │ │ │ - Line clearing scoring (single, double, triple, tetris) │ │ │ │ - Level progression and speed increase │ │ │ │ - Statistics tracking │ │ │ │ │ │ │ │ Phase 4: Audio \u0026amp; Game States │ │ │ │ │ │ │ │ 9. Create AudioManager.js for sound effects │ │ │ │ 10. Implement game state transitions: │ │ │ │ - Menu screen │ │ │ │ - Playing state │ │ │ │ - Pause functionality │ │ │ │ - Game over screen with restart │ │ │ │ │ │ │ │ Phase 5: Polish \u0026amp; Mobile Support │ │ │ │ │ │ │ │ 11. Add mobile touch controls │ │ │ │ 12. Implement preview of next piece │ │ │ │ 13. Add ghost piece (shadow) showing drop position │ │ │ │ 14. Local storage for high scores │ │ │ │ │ │ │ │ Key Technical Decisions: │ │ │ │ - Vanilla JS + HTML5 Canvas for optimal performance │ │ │ │ - Fixed timestep game loop for consistent mechanics │ │ │ │ - Component-based architecture for maintainability │ │ │ │ - Double buffering for smooth 60fps rendering │ │ │ │ │ │ │ │ The game will be fully playable with standard Tetris mechanics, responsive design, and smooth performance across devices. 我对这个方案满意，所以我选择了“是”，并自动接受编辑。\nClaude Code 现在正在按照我们与技术架构子代理共同制定的计划进行实施。\n这就是现在的游戏样子。还可以做出改进，但这是一个不错的开始。 作为一个快速示例，下面是在我引入了一个前端开发子代理和一个测试子代理并发出以下提示时，claude 中的计划模式的样子。\n通过将前端改为基于 Next.js 的应用来改进前端 并且还要为项目添加单元测试。确保前端开发人员和测试负责人参与决策过程\n当我选择“申请”时，你可以大致了解每个子代理将扮演的角色\n为生成子代理的有用提示 创建子代理\nClaude Code 有一个名为子代理的功能，文档粘贴在下方。请通读它并确定哪些子代理最适合用于我的应用程序，这些子代理将如何改进我的应用并加快编码速度，然后实现这些子代理。文档：[在此粘贴来自 Claude Code 子代理页面的链接或内容]\n第 12 步：钩子（Hooks） 虽然手动检查点系统提供了出色的版本控制，Claude Code 的钩子则把自动化提升到了更高的水平。钩子是当在你的 AI 辅助开发过程中满足某些条件时执行的自动化脚本。最实用的钩子是自动提交系统，它在 Claude 成功修改且无错误时自动提交你的代码，这建立在你已学过的检查点工作流之上。\n设置自动提交钩子 要创建自动提交钩子，你需要配置一个监控 Claude 输出并在任务成功完成时自动提交的系统。创建一个配置文件来定义何时以及如何进行提交：\n# Basic Auto-Commit Hook Setup # 1. Create hook configuration echo \u0026#34;on_success: auto_commit_with_smart_message\u0026#34; \u0026gt; .claude-hooks # 2. Set up monitoring script # This watches for Claude task completion and triggers commits claude-hook-monitor --config .claude-hooks --enable auto-commit # 3. Configure commit message templates # Generates intelligent messages like \u0026#34;✅ Add user authentication system\u0026#34; 挂钩示例演示 下面是自动提交钩子在实际中的工作方式。 在 Claude 开始一个任务之前，钩子会创建一个检查点：git commit -m \u0026ldquo;🚀 Checkpoint: Before adding user dashboard\u0026rdquo;。在 Claude 成功完成该功能且无错误时，钩子会自动运行：git add . \u0026amp;\u0026amp; git commit -m \u0026ldquo;✅ Add user dashboard with charts and filters\u0026rdquo;，并可选择将更改推送到远程仓库。如果 Claude 遇到错误，钩子可以自动回滚到上一个检查点，确保你的代码库始终保持可运行状态。 钩子的最佳实践包括从简单的基本自动提交功能开始，加入安全机制（如提交次数限制和对大改动的确认提示），并维护所有钩子活动的详细日志。这种自动化能节省大量时间，同时在整个 Claude Code 开发工作流中确保一致的版本控制实践。\n参考来源 原文：Mastering Claude Code（dev.to）（Damien Gallagher，2025-07-04） Claude Code 官方文档：记忆与 CLAUDE.md Claude Code 官方文档：斜杠命令 Claude Code 官方文档：检查点 Claude Code 官方文档：用钩子自动化 Claude Code 官方文档：创建自定义子代理 Claude Code 官方文档：权限 Claude Code 官方文档：安全 Claude Code 官方文档：最佳实践 Claude Code 官方文档：费用 相关笔记 Claude 官方博客阅读总索引（固定 14 篇） Claude 5 上下文工程：The new rules Opus 5.5 协作与长任务：Getting the most out Claude Code Mods 入门：Getting started HTML 作为协作产物：The unreasonable effectiveness ","permalink":"https://blog.xiezaikui.com/posts/mastering-claude-code/","summary":"原文：Mastering Claude Code（dev.to，2025-07-04 发布，2025-07-28 更新），正文按原文 12 个步骤顺序翻译，图片取自原文本地附件。","title":"精通 Claude Code（全文翻译）"},{"content":"这个小站是什么 小蟹的小站是一个以技术分享为主的个人博客，内容集中在 AI Agent、Claude Code 与工程实践方向。\n首版内容来自一批官方博客与文档的阅读整理：每篇笔记都会标注原文链接、原作者、发布日期与整理日期，方便你回溯核对一手资料。笔记中的观点以原文为准，我自己的补充会明确标注为整理者建议。\n内容组织方式 系列索引：Claude 官方博客阅读总索引 汇集了同一批 claude.dev 官方博客的阅读笔记，是进入这一系列最好的入口。 标签：按 Claude Code、上下文工程、模型选型 等标签聚合相关文章。 归档：按时间浏览全部文章。 搜索：站内全文搜索，纯前端实现，不依赖任何外部服务。 关于转载与引用 站内笔记若涉及他人文章的翻译或转述，均在文末「参考来源」中给出原文链接与作者署名，版权归原作者所有。如果发现标注有误或希望调整，欢迎联系我。\n","permalink":"https://blog.xiezaikui.com/about/","summary":"关于小蟹的小站","title":"关于"}]