Topic · 主题全部主题 →

教程实践

拿来就能用的实操内容：提示词技巧、工作流搭建、工具用法与踩坑经验。

2,397条收录
358条精选

精选归档 · 第 6 页

第 101–120 条 · 共 358 条

7月9日7月9日周四

星期四 · 1 条
01:22
ClaudeDevs@ClaudeDevs精选
AI 评分 73/100
Claude Code 的 Model 与 Effort：知道更多 vs. 更加努力http://x.com/i/article/2074606120292020224Model and effort in Claude Code: knowing more vs. trying harderClaude Code gives you two settings that both seem to "make the answer better": the model, and the effort level. But what do these actually do to the output? And how do you know whether to reach for a different model or just change the effort level?It's easy to assume that choosing a larger model like Fable gives you a smarter output than Sonnet, and that a higher effort level just means Claude thinks longer before it answers.The first assumption is true. Our largest models are more capable, according to industry-standard benchmarks.But effort means more than "thinking time." Effort controls how much work Claude does on your request overall. That includes how long it thinks, but also:• how many files it reads;• how much it verifies; and• how far it pushes through a multi-step task before checking in with you.At higher effort, Claude takes more of those actions (read files, run tests, double-check) before it comes back to you. At lower effort, it would rather ask you for more context than spend tokens figuring something out on its own.How model selection worksTo understand what the model setting actually controls, it helps to start at the very beginning, from the moment you press enter.Claude Code assembles your message together with the system prompt, tool definitions, your CLAUDE.md, the conversation history, and any files in context. All of this is sent as one request to the API.The model never sees any of that as plain text, though. The first thing that happens on the server is tokenization: the text gets split into pieces, and each piece is mapped to an integer from a fixed vocabulary the model was trained with. const might map to 1978, await might map to 4293. From here on, your prompt is an array of integers.The model's job is to take that array and predict which token comes next. It does this by computing a probability for every token in its vocabulary and picking from the top. After "const x = await", a well-trained model puts high probability on "fetch" (very likely) and near-zero on "banana" (not likely at all).What turns your input tokens into those probabilities is the weights (also called parameters): billions of numbers organized into large matrices. To predict one token, the model runs your input through those matrices (a long chain of matrix multiplications) and reads the probabilities at the end. The weights are where everything the model "knows" lives.The weights of each model are set during training, and by the time you're sending requests they're read-only. Nothing in your prompt, your CLAUDE.md, or your context changes them. If you've run into the word inference, that's all it means: using the model after training is done, with the weights fixed.Everything Claude knows about TypeScript, popular frameworks, or any other general programming knowledge was encoded into those weights at training time.Your prompt and context can still steer the prediction. Putting your real code in front of Claude is steering, and it works really well. However, this doesn't add anything to the weights themselves.If a library didn't exist when the model was trained, it isn't in the weights. You can put the docs in context and Claude will use them, but that's steering, not teaching. Claude's response is only influenced for that one request, but the underlying model hasn't retained anything.When Claude confidently calls an API that doesn't exist (a hallucination), that's the weights producing a token sequence that looks plausible from training patterns, not a failed lookup.So what does changing the model actually do? It swaps which set of frozen weights handles your request.The model doesn't generate a whole answer at once. It predicts one token, appends it to the sequence, and runs the whole computation again to get the next one. A 200-token response is 200 separate passes through the weights. This loop is where most of your wait time (and your output cost) comes from.The model setting decides which weights handle your request, and it also decides what each output token costs.What it doesn't decide is how many tokens get generated. That number can vary a lot for the same prompt, depending on how much work Claude decides to do.Which is exactly what effort controls.How effort worksWhile Claude Code is working on a task, the tokens it generates fall into a few categories:• Thinking: the reasoning you see streaming before and between actions.• Tool calls: structured blocks naming a tool like Read or Edit and its arguments, which Claude Code then parses and executes.• Text to you: the plan, progress updates, the summary at the end.These are all ordinary output tokens from the same loop, billed at the same rate. Thinking tokens, for example, are generated exactly like the other output tokens and stay in context for the rest of that turn.By the time Claude moves on to writing code, its earlier reasoning is part of the input, just like a file it read.So how does effort change any of this? The effort level is sent to the model as part of the request, right alongside your prompt. The model was trained to understand how to behave at each effort level, and that learned behavior is baked into the frozen weights.When your request arrives, effort is just one more input the model responds to, the same way it responds to your prompt text. It sets how thorough, and how certain, Claude needs to be before it considers the task done. That gets weighed on every turn, and higher confidence takes more tokens to reach.At higher effort levels, Claude often starts by creating a plan, and the effort level influences the depth and breadth of that plan. But the plan isn't frozen in place. As Claude gets results back from its actions, it updates its picture of how much progress it's made and how certain it is of the accumulated result.When step 1 of a three-hypothesis debugging plan finds the bug, "investigate hypotheses 2 and 3" may no longer be necessary. Claude will usually say this explicitly (e.g. "the first check found it, so the remaining checks aren't needed") and skip ahead. You see this happen in Claude Code when task lists get revised mid-run.Higher effort does make Claude more likely to double-check, like verifying the answer it found, or still look into the hypotheses it could have skipped. However, it generally won’t artificially inflate usage on a simple task just because the effort level is turned up. "Overthinking" is something our team specifically watches for during model training as it degrades effectiveness.Picking an effort levelFor most tasks, use the model's default effort level. The default is the level where Claude scales its token usage to what most people would want to spend on a task.Think of effort as a manual override on how hard and how long Claude works. Reach for it deliberately when you have a strong preference for thoroughness or speed based on your domain or the type of work you do, and treat it as a general preference, not a task-by-task decision.One practical note following the launch of Opus 4.8: in our testing, the default effort setting on Opus 4.8 produces better results for about the same amount of tokens as the default effort setting on Opus 4.7 on the same task.What to change when Claude gets it wrongWhen Claude gets something wrong, your first instinct shouldn't be to change a setting. It should be to look at the context you gave it. Is your prompt too vague? Is Claude connected to the right tools? Does it have the right skills?If you're increasing effort on a task that shouldn't need it, the fix is usually upstream: in your context, your CLAUDE.md, or how the task is scoped.But say you've given clear context and Claude still gets it wrong. The question to ask yourself is: did it not try hard enough, or did it not know enough?Model: the problem was too hardPick a larger model when the problem is genuinely hard, like subtle bugs, unfamiliar domains, architecture decisions. A larger model is what you want when the smaller model is confidently wrong no matter how much context you give it.Larger models are also better at handling ambiguity. On smaller models, specific instructions that direct the execution are a better recipe for success.Pick a smaller model when the work is routine: edits you can describe precisely, mechanical changes, questions about code that's already in context. There's no reason to pay for capability the task doesn't need.If Claude had all the pertinent context, clearly tried, and still got it wrong; that's a signal to pick a larger model. And if you're on the larger model and the work has been routine for a while, dropping down will increase speed and typically reduce cost without impacting the quality of the output.Effort: Claude didn't try hard enoughPick a higher effort level if Claude did it wrong by not trying hard enough: skipping a file, not running the tests, or not double-checking its work. This is most relevant if you'd selected an effort level below the model's default.The specialist, the expert, and the generalistOne way I like to think about the two settings is that Fable is a specialist who can handle problems almost no one else has, Opus is the expert, and Sonnet is a really good generalist. The effort level decides how much time any of them spends on your task.Opus at low effort is like getting five minutes with an expert who has deep experience with problems like yours. They bring knowledge that isn't anywhere in your codebase; patterns they've seen before, gotchas they know to check for, the kind of experience you only get from having solved a lot of similar problems. But five minutes means a quick read of your code, not a careful pass through every file.Sonnet at high effort is the generalist with the whole afternoon. They're great at coding, and they'll read everything, run things, double-check their work, and end up understanding your specific code thoroughly.Fable is the specialist you call when everyone else is stuck. Even at low effort, they'll spot the thing no one else would. That recognition is also what you're paying the most for, so it's worth saving it for the tasks that need it.None of these is universally "better". The model setting is roughly how capable; the effort setting is roughly how thorough. Most real tasks need some of both.Effort, model, and token consumptionSo how do model selection, effort, and token consumption all interact? It depends on the task.On routine work at the same effort level, both the larger and smaller models generally get it right. The larger model consumes more tokens with extra verification steps, at a higher per-token price. That's why dropping to the smaller model for routine stretches saves real money at no quality cost.On harder, multi-step work, the equation flips. The smaller model has to grind toward the limit of its ability, burning iterations, while the larger model reaches the same quality bar in fewer steps.You're paying more per token for the larger model, but on tasks that genuinely stretch the smaller one, the total cost per task can come out lower. And more importantly: the larger model can finish tasks the smaller one can't, even at the highest effort settings.This is most pronounced with Fable. On long, multi-step work it pulls furthest ahead. In our testing, it finished jobs Opus and Sonnet can't reach at any effort level. It also costs the most per token, which is the other reason to save it for the work that really needs it.The key point in the graphs above: effort picks how far Claude is willing to travel along the curve. That doesn't mean Claude will need to go that far to finish the task.Lastly, effort shapes token consumption, but it doesn't limit it. The only hard cap in the system is max_tokens, which truncates a response mid-stream when hit, but it's a blunt instrument and mostly relevant to API developers. Softer controls like task budgets or asking Claude to keep it brief in your prompt are more helpful. They're guidance the model is trained to follow (it'll look to wrap up as it gets near the limit) rather than a wall it runs into.Effort changes how much work Claude does. The model changes what Claude knows.When you're unhappy with a result, check the context before you touch either setting: give Claude a clear prompt, the right tools and skills, and a way to verify its own work.If Claude still gets it wrong, ask yourself: did it not know enough, or did it not try hard enough? Not knowing enough is a model problem, not trying hard enough is an effort problem.This article was written by @lydiahallie, member of technical staff on the Claude Code team.译Claude Code 的 model 和 effort 两种设置都旨在提升输出，但机制不同。model 越大，模型能力越强（基于行业标准基准测试）。effort 控制 Claude 在请求上的总工作量，包括思考时间、读取文件数、验证程度、多步任务推进深度等。高 effort 时 Claude 会执行更多操作（读文件、跑测试、再检查）；低 effort 时更倾向询问上下文。模型选择本质是切换不同的冻结权重集--权重在训练时固定，prompt 和上下文只能引导（steering）而不能改变权重。模型幻觉是权重产生看似合理但错误的 token 序列。
Anthropic教程/实践编码
推荐理由：Claude Code 官方这篇把 model 和 effort 的取舍讲得比他处都透，读完就知道什么任务该堆算力、什么任务该降模型省钱。

7月8日7月8日周三

星期三 · 2 条
08:20
公众号：数字生命卡兹克精选
AI 评分 75/100
《人生设计课》Prompt实测：用Claude设计人生的四个阶段

作者将斯坦福《人生设计课》理论体系制成Prompt，通过Claude逐步提问、追问和分析。Prompt融合设计思维、心流理论和积极心理学，分为看清现状、找到指南针、寻路、制定奥德赛计划四阶段，主线问题控制在6到9个。AI引导用户给健康、工作、娱乐、爱打分，区分重力问题与可设计的真问题，生成三个五年人生版本，最终输出8000至12000字的《个人人生设计蓝图》。作者实测效果超预期。

Anthropic教程/实践
推荐理由：卡兹克把《人生设计课》的整套方法论炼成了一个追问型Prompt，它不替你规划人生，但能用一连串苏格拉底式逼问把你心里一直没厘清的线头拽出来。比心理咨询轻量，比鸡汤硬核，想用AI认真盘一盘自己方向的人值得花半小时玩一遍。
05:49
ClaudeDevs@ClaudeDevs精选
AI 评分 60/100
Fable 5 作为顾问与执行者调用模式A few patterns we frequently use with Fable 5:Use Fable 5 as an "advisor."An executor (Sonnet 5) calls Fable 5 for guidance.Most tokens are billed at the lower executor rate.译我们常与 Fable 5 一起使用的几个模式： 将 Fable 5 作为"顾问"。 一个执行者（Sonnet 5）调用 Fable 5 寻求指导。 大多数 token 按较低的执行者费率计费。
智能体Anthropic教程/实践
另有 2 家信源报道The Decoder：AI News（RSS）IT之家（RSS）
推荐理由：Anthropic官方手把手教的两层模型用法，用Fable当军师、Sonnet当执行者，省token又提质量，Agent开发者值得抄。

7月7日7月7日周二

星期二 · 4 条
23:09
elvis@omarsar0精选
AI 评分 77/100
Elvis Saravia 通过 HITL 和 DialAgent 提升 agentic loops 可靠性Loop engineering is great until something breaks.Here is how I improve the reliability of my agentic loops.I use human-in-the-loop (HITL). It's easy and extremely effective. Anyone can build this.My setup:I recorded a quick demo of how it all works.I shared recently that I now use more voice agents to build and communicate with agents. I also use them to verify.I hate the idea of being tied down to my computer or in a Slack channel to communicate with my agents.Here is what I have done to streamline communication with my agents.All my Claude and Codex agent sessions now use the @DialAgent MCP server. It has a bunch of tools and provisions my agents with their own number that can place calls as native tools, with voice, SMS, and iMessage behind one interface.As my loops/automations work on PRs and new features, my agents escalate decisions to me via a short phone call. This is extremely useful when I am on the road or away from my desk.If you want to try this with Claude Code or Codex, paste this into your agent and get started right away:"Get yourself a Dial phone number and call me. Say hello and that setup is working, then hang up. Follow https://getdial.ai/skills.md"@NVoitenkov and team are building something special here. Go check them out. Give your agent a phone number now: http://getdial.ai ($5 free credit)译Elvis Saravia 介绍使用 human-in-the-loop（HITL）来提升 agentic loops 的可靠性。他所有 Claude 和 Codex agent 会话都通过 @DialAgent MCP 服务器，该服务器为 agent 提供专属号码，支持语音、SMS、iMessage 作为原生工具。当循环/自动化处理 PR 或新功能时，agent 会通过简短电话将决策升级给人类，尤其适合在路上或离开电脑时。用户可粘贴指令让 agent 拨打电话测试。DialAgent 提供 $5 免费额度：http://getdial.ai
智能体MCP/工具教程/实践
推荐理由：给AI Agent装电话号直接打电话请示，这个实操方案能大幅减少循环失败，Claude Code和Codex用户有$5免费额度马上可试，出差党尤其友好。
03:13
ClaudeDevs@ClaudeDevs精选
AI 评分 70/100
Claude Code 团队详解四种智能体循环类型http://x.com/i/article/2074204645845839872Getting started with loopsThere’s a lot of talk right now about "designing loops" instead of prompting your coding agent. If you spend some time on X trying to pin down what a loop actually is, you'll come across multiple different answers.On the Claude Code team, we define loops as agents repeating cycles of work until a stop condition is met. We categorize a few different types of loops based on:• How they are triggered• How they are stopped• What Claude Code primitive is used• What type of task is most appropriate for each.We’ll cover the main loop types, when to use each, and how to maintain code quality while managing token usage. Not all tasks require complex loops; start with the simplest solution and use these patterns selectively.Turn-based loops• Triggered by: A user prompt.• Stop criteria: Claude judges it has completed the task or needs additional context.• Best used for: Shorter tasks that are not part of a regular process or schedule.• Managed usage by: Write specific prompts and improve verification using skills to reduce the number of turns.Every prompt you send starts a manual loop with you directing each turn. Claude gathers context, takes action, checks its work, repeats if needed, and responds. We call this the agentic loop.For example, ask Claude to create a like button. It reads your code, makes the edit, runs the tests, and hands back something it believes works. You then manually check the work, and write the next prompt.You can improve the verification step by encoding your manual steps as a SKILL.md so Claude can check more of its own work, end-to-end. This should include tools or connectors to allow Claude to see, measure or interact with the result. The more quantitative the checks are, the easier it is for Claude to self-verify.For example, in your SKILL.md file you may specify:Goal-based loop (/goal)• Triggered by: A manual prompt in real-time.• Stop criteria: Goal achieved OR maximum number of turns reached.• Best used for: Tasks that have verifiable exit criteria.• Managed usage by: Setting a specific completion criteria and explicit turn caps, “stop after 5 tries.”Sometimes, a single turn is not enough, especially for more complex tasks. Agents do better when they can iterate. You can extend how long Claude keeps iterating by defining what done looks like with /goal.When you define the success criteria, Claude doesn’t have to make a determination on what is “good enough” and end the loop early. Each time Claude tries to stop, an evaluator model checks your condition and sends it back to work until the goal is met or a number of turns you define is reached.This is why deterministic criteria, such as number of tests passed or clearing a certain score threshold, are so effective.For example:Time-based loop (/loop and /schedule)• Triggered by: A specified time interval.• Stop criteria: You cancel it, or the work completes (the PR merges, the queue is empty).• Best used for: For recurring work, or interfacing with external environments / systems.• Managed usage by: Set longer intervals or react based on events rather than time.Some agentic work is recurring: the task stays the same and only the inputs change. For example, summarizing Slack messages every morning. Other work depends on external systems, and a simple way to interface with one is to check it on an interval and react to what changed. For example, a PR which may receive code reviews or fail CI.For these, you can trigger when Claude runs with /loop which re-runs a prompt on an interval. For example:/loop runs on your computer, so if you turn it off, it stops. You can move the loop to the cloud by creating a routine with /schedule.Proactive loops• Triggered by: An event or schedule, with no human in real time.• Stop criteria: Each task exits when its goal is met. The routine itself runs until you turn it off.• Best used for: Recurring streams of well-defined work: bug reports, issue triage, migrations, dependency upgrades, etc.• Managed usage by: Routing routines to smaller, faster models and using the most capable model for judgment calls.The primitives above, along with other Claude Code features like auto mode and dynamic workflows (research preview) can be composed into a loop for long-running work.For example, to handle incoming feedback, you can use:1. /schedule (research preview) to run a routine that checks for new reports1. /goal to define what done looks and skills to document how to verify it1. Dynamic workflows to orchestrate agents that triage each report, fix it, and review the fix1. Auto mode so the routine runs without stopping to ask for permissionPutting it together, a prompt could look like this:Maintaining code qualityThe quality of a loop’s output depends on the system around it. When designing the system:• Keep the codebase itself clean: Claude follows patterns and conventions that already exist in your codebase.• Give Claude a way to verify its own work: Encode what good looks like for you and your team with skills.• Make docs easy to reach: Frameworks and libraries docs have up-to-date best practices.• Use a second agent for code reviews: A reviewer with fresh context is less biased and not influenced by the main agent’s reasoning. You can use the built-in /code-review skill or Code Review for Github.When an individual result doesn’t meet the standard, don’t stop at fixing the individual issue, try to encode it to improve the system for all future iterations.Managing token usageTo manage token usage, loops should have clear boundaries:• Choose the right primitive and model for the job: Smaller tasks don’t need multiple agents or loops. Some tasks can use cheaper and faster models.• Define clear success and stop criteria: Be specific about what done looks like so Claude can arrive at the solution sooner (but not too soon).• Pilot before a large run: Dynamic workflows can spawn hundreds of agents. Gauge usage on a smaller slice of the work first.• Use scripts for deterministic work: Running a script is cheaper than reasoning through the steps. For example, a PDF skill can ship a form-filling script that Claude runs each time, instead of re-deriving the code.• Don’t run routines more often that you need to: Match the interval to how often the thing you’re watching changes• Review usage: The /usage command breaks down recent usage by skills, subagents, and MCPs, /goal with no arguments shows number of turns and token usage so far, /workflows shows each agent’s token usage and you can stop an agent at any time.Getting startedTo summarize:To get started with loops, look at the work you already do. Pick one task where you’re the bottleneck and ask which piece you could hand off: can you write the verification check? Is the goal clear enough? Does the work arrive on a schedule?Once you have an idea, run the loop, observe the results like where it stalls or over-reaches, and don’t be afraid to iterate on it.For more information, read the Claude Code docs on running agents in parallel, as well as the loop, schedule, goal, and dynamic workflows pages.This article was written by @delba_oliveira译Claude Code 团队将"设计循环"定义为智能体重复工作直到满足停止条件，划分四种类型：1）回合循环--手动提示触发，Claude 自判完成，适合短任务，可通过 SKILL.md 提升验证；2）目标循环--/goal 手动触发，达成目标或达最大轮数停止，需确定性完成标准（如测试通过数）；3）时间循环--/loop 和 /schedule 按间隔触发，适合同步消息、检查 PR 等重复任务，可云端运行；4）主动循环--事件或计划触发，无人实时参与，每个子任务独立退出。建议从最简单方案开始，选择性使用复杂循环。
智能体Anthropic教程/实践编码
推荐理由：Claude Code 团队官方的循环设计指南，把 `/goal`、`/loop` 这些原语讲得很清楚，想从单次提示转向自主代理工作流的开发者可以直接照着搭。
02:20
Claude：Blog（网页）精选
AI 评分 70/100
Claude Fable实地指南：发现你的未知

Claude Fable是第一款要求用户主动澄清未知才能获得高质量工作的模型。与Claude Fable协作是一个在实现前后迭代发现未知的过程。通过将问题分解为已知的已知、已知的未知、未知的已知和未知的未知四类，用户可以借助Claude Fable和Claude Code进行盲点检查、头脑风暴、原型设计、实现笔记记录以及答辩解释，从而高效挖掘并解决深藏于代码库和设计与实现中的潜在问题。

智能体Anthropic教程/实践编码
推荐理由：Anthropic 官方分享的 Claude Fable 协作方法论，把「发现未知」拆成盲点扫描、原型、面试等可操作步骤，如果你用 Claude Code 但常觉得代理跑偏，这篇是必读实践指南。
01:18
TechCrunch：AI（RSS）精选
AI 评分 75/100
Google 更新隐私设置，默认用媒体数据训练 AI，用户可手动退出

Google 于 6 月通过客户邮件低调更新了搜索服务隐私设置，新增“搜索服务历史”和“个性化推荐”两项开关，默认将用户上传的图片、文件、音频和视频录制等媒体数据保存并用于训练 AI 模型。该更新适用于搜索、地图、购物、航班、酒店、翻译、新闻等服务。用户可通过取消勾选“保存媒体”框来退出，同时可设置数据自动删除周期（3/18/36 个月）。此前独立的网络与应用活动设置不再影响搜索服务数据保留。Meta 等其他公司也在大规模收集用户媒体数据用于 AI 训练。

Google教程/实践数据/训练
推荐理由：Google 悄悄把用户上传的媒体数据默认用于训练 AI，这篇教程是及时且实用的避坑指南，花两分钟改设置就能保护隐私，所有 Google 用户都该看看。

7月6日7月6日周一

星期一 · 1 条
09:20
公众号：卡尔的AI沃茨精选
AI 评分 73/100
分享8个Claude Fable 5下线前必跑的超实用Prompt

Claude Fable 5即将下线，作者整理了8个经实战验证的提示词：/goal提示语让模型自主跑25次实验（花费165美元，构建速度提高50%、token开销降60%）；工作模式提示语将用户习惯转化为可复用Skills；行动规范提示语约束subagent行为；subagent分配提示语智能分配任务；25个定时循环工作流（含Shadow prompt loop做A/B测试）；自治运行+自动暂停提示语；记忆系统提示语保留错题本；反向面试提示语确保95%把握再执行。这些提示词可迁移至API计费后继续使用，核心是让模型研究用户而非限制能力。

智能体Anthropic教程/实践
推荐理由：Fable5下线前的窗口期指南，把社区实战精华浓缩成可直接复制的 prompt，同时告诉你如何把模型行为模式固化成系统，换模型也不慌。

7月4日7月4日周六

星期六 · 3 条
08:00
Lilian Weng：Lil'Log（RSS）精选
AI 评分 57/100
Harness Engineering for Self-Improvement：AI装备层设计模式与自改进

Lilian Weng 近日系统探讨了 AI 的“装备层”（Harness）——位于基础模型与现实世界之间的系统层，负责编排执行、控制模型思考与规划。文章归纳三种核心设计模式：1）工作流自动化，采用“计划-执行-观察-改进”循环；2）将文件系统作为持久化内存，解决长程任务上下文窗口与状态持久化问题；3）子智能体与后台任务，实现并行执行与隔离管理。案例聚焦于 Claude Code、Codex 等编程智能体的装备层设计。未来方向包括上下文工程、工作流优化以及通过进化搜索联合优化模型权重。

智能体教程/实践部署/工程
推荐理由：Lilian Weng 这篇综述把 agent 自改进的脉络从 harness 设计一路拉到进化搜索，近期关键研究基本都串起来了，做 coding agent 和自动研究的同行建议通读。
03:22
Simon Willison 博客精选
AI 评分 73/100
Fable 的判断力：Simon Willison 从 Claude Code 团队获得的效率技巧

Simon Willison 在 AIE 上与 Claude Code 团队交流后建议，让 Fable（以及 Opus）用自己的判断力工作，而非硬性规定行为。例如，直接让 Fable 自行决定何时编写测试，比给出具体规则更好。为应对价格即将上涨、节省 Fable token，Jesse Vincent 的另一个技巧是告诉 Fable 将较小任务委托给较低功耗模型（Sonnet 用于实质性实现、Haiku 用于机械修改），主循环保留判断、审计和数据合成等任务。Willison 已将提示词存入 Claude Code 记忆文件，实际效果良好，Fable token 消耗速度明显下降。

智能体Anthropic教程/实践编码
推荐理由：Simon 从 Claude Code 团队得到的实战技巧：别硬性规定 Fable 怎么写测试、用哪个模型，让它自己判断。他实测这条 prompt 能明显节省代币消耗，Fable 涨价前偷时间的利器。
02:11
Thariq@trq212精选
AI 评分 69/100
Fable使用指南：发现你的未知http://x.com/i/article/2073090223194755072A Field Guide to Fable: Finding Your UnknownsWorking with Claude Fable 5 keeps re-teaching me an old lesson: the map is not the territory.The map, a representation of the work to be done, is my prompts and skills and context, it’s what I give Claude. The territory is where the work needs to happen, the codebase, the real world, its actual constraints.The difference between the map and the territory is what I call unknowns. When Claude runs into an unknown, it needs to make a decision based on its best guess of what I want. The more work being done, the more unknowns Claude might run intoFable is the first model where I find the quality of the work is bottlenecked by my ability to clarify its unknowns.Importantly, just planning ahead isn’t always enough. You can find unknowns deep in implementation, or your unknowns may point you to the fact that you should actually be solving the problem in a different way altogether.I’ve found that working with Fable is an iterative process of discovering my unknowns before, during, and after implementation.I've made some example artifacts for finding unknowns here, but be sure to come back to build the intuition for when to use them.Knowing your unknownsWhat are your unknowns? When I come to Claude with a problem I tend to break it down in 4 ways:• Known Knowns: This is essentially what is in my prompt. What do I tell the agent that I want?• Known Unknowns: What haven't I figured out yet, but I’m aware that I haven’t?• Unknown Knowns: What's so obvious I’d never write it down, but would recognize it if I saw it?• Unknown Unknowns: What haven't I considered at all? What knowledge am I not aware of? Do I know how good something can be?The best agentic coders are good have relatively few unknowns. Watching someone like Boris or Jarred prompt, it is obvious to me that they know what they want in-detail. They are deeply in-sync with both the codebase and the model behaviors.But they also assume unknowns. In many ways, reducing and planning for your unknowns is the skill of agentic coding. But luckily, this is a skill you can improve at, by working with Claude.Help Claude help youInstructing Claude is a delicate balance. If you are too specific, Claude will follow your instructions even when a pivot may be more appropriate. If you are too vague, Claude will often make choices and assumptions based on industry best practices that may not be a fit for your task.When you don’t account for your unknowns you fail both ways. You don't know when the path will be filled with obstacles and you don’t know when the path will be clear, but you still want Claude to veer.Claude can help you discover your unknowns faster. It can search through your codebase and the internet extremely quickly and it knows much more about the average topic than you. It can also iterate from failure faster.The most important part of this process is to give Claude context about your starting point. For example, tell it where you are in your thought process; disclose your experience with the problem and codebase; and let it work with you like a thought partner.I've previously written about using HTML with Claude, in almost all of these cases, a HTML artifact is the best way to visualize and represent it.In this article I detail some of the patterns I use to uncover these unknowns. I don't use every technique each time, but it's a useful collection of techniques to have.Pre-implementationBlind Spot PassWhen starting work, one of the most useful things you can do is understand your blindspots. For example, if you’re writing a feature in a new part of the codebase or using Claude to help you with unfamiliar work like iterating on a design, you’re likely to have a lot of unknown unknowns.You may not know what questions to ask, what good looks like, what historical work has been done or what potholes to avoid.To do this, you can ask Claude to help you find your unknown unknowns and explain them to you. I like to use the literal words “blindspot pass” and “unknown unknowns”. Giving it context on who you are and what you know is usually important forExample Prompts:• “I'm working on adding a new auth provider but I know nothing about the auth modules in this codebase. Can you do a blindspot pass to help me figure out my relevant unknown unknowns and help me prompt you better.”• “I don’t know what color grading is but I need to grade this video. Can you teach me to understand my unknown unknowns about color grading, so that I can prompt better?”Brainstorms and prototypesWhen I’m working in an area with a lot of unknown knowns, involving criteria I only know to define when I see it, I like to ask Claude to brainstorm and prototype with me.It’s extremely valuable to identify and verbalize unknown knowns early during prototyping, because finding them out during implementation can be (relatively) expensive. Small changes in a feature or spec can cause drastically different implementations in code and it can be more difficult for your agent to revert previous changes.For example, you may just want to see how a button added to a frame looks without having to wire up a backend route or maintaining additional state in the frontend.Visual design is something that for me is difficult to articulate, but I know what I want when I see it. In these cases, I’ll ask for several design approaches to an artifact.I also start almost every coding session with an exploration or brainstorming phase. This helps me start with intent to define the project’s scope. Claude often finds high-value approaches I would have missed and sometimes misses the forest through the trees. Brainstorming prevents me from setting too narrow or too wide a scope.Example prompts:• "I want a dashboard for this data but I have no visual taste and don't know what's possible. Make me an HTML page with 4 wildly different design directions so I can react to them.”• “Before wiring anything up, make a single HTML file mocking the new editor toolbar with fake data. I want to react to the layout before you touch the treal app."• "Here's my rough problem: users churn after onboarding. Search the codebase and brainstorm 10 places we could intervene, from cheapest to most ambitious. I'll tell you which ones resonate."InterviewsOnce I’ve done sufficient brainstorming, I likely still have unknowns.In this case, I ask Claude to interview me about any unknowns or ambiguities. When asking Claude to interview you, try and give it context about your problem to guide its questions. Here are some examples.Example prompts:• "Interview me one question at a time about anything ambiguous, prioritize questions where my answer would change the architecture."ReferencesSometimes you can’t describe what you want in detail. For example, you might not have the language or it might be so complicated that it would take you quite a while.In this case, the best answer is a reference. While you can include diagrams, documentation or pictures, the absolute best reference is source code.If you have a library that implements something in a certain way or a design component you really like, just point Fable at the folder and tell it what to look for, even if it’s in a different language.This is also the way Claude Design works. You don't have to hand it a file (although you can do that too). You can point it at a module on a website you like, and it reads the underlying code, not just the screenshot. This provides much richer detail around the markup, structure, and how the component is actually built.Example prompts:• This Rust crate in vendor/rate-limiter implements the exact backoff behavior I want. Read it and reimplement the same semantics in our TypeScript API client.Implementation PlansWhen I think I’m ready to implement, I tend to ask Claude to put together an implementation plan for me to review that focuses on the parts that might be most likely to change, for example to review data models, type interfaces or UX flows. This allows Claude to surface things I might actually need to alter.Example Prompts:• Write an implementation plan in HTML, but lead with the decisions I'm most likely to tweak with: data model changes, new type interfaces, and anything user-facing. Bury the mechanical refactoring at the bottom, I trust you on that part."During implementationImplementation notesOnce I am satisfied with my plan, I make a new session and pass any artifacts to the prompt. For example, I might pass in a spec file and a prototype and ask an agent to implement it.But the truth is that no matter how much planning you do, there are always unknown unknowns lurking. The agent may find during its work that it needs to take a different tack due to an edge case it found in the code.I ask Claude Code to keep a temporary ‘implementation-notes.md’ (or .html) file where it keeps track of decisions it makes so we can learn from our next attempt.Example prompts:• "Keep an implementation-notes.md file. If you hit an edge case that forces you to deviate from the plan, pick the conservative option, log it under 'Deviations', and keep going."Post implementationPitches and explainersOne of the most important parts of shipping something is getting buy-in and approvals. Building pitch and explainer artifacts in the final document helps:• Accelerate understanding when reviewers start with the same unknowns you did• Accelerate approvals when experts want to see you accounted for the unknowns and common failure points they would have anticipatedExample prompts:• "Package the prototype, the spec, and the implementation notes into a single doc I can drop in Slack to get buy-in. Lead with the demo GIF."QuizzesAfter a long working session, Claude might have accomplished a lot more than I realized. Reading the code diffs can only give me a light understanding of what happened, since much of the behavior will depend on existing code paths.Asking Claude to quiz me about the change after giving me a bunch of context helps me understand what happens. I only merge after I pass the quiz perfectly.Example prompts:• “I want to make sure I understand everything that's happened in this change. Give me a HTML report on the changes for me to read and understand with context, intuition, what was done, etc. and a quiz at the bottom on the changes that I must pass.”How this comes together: launching FableThe launch video for Fable was edited entirely by Claude Code. This was a new domain for me and I’m by no means an expert.So I started with what I did know. I knew that Claude could use code to edit videos and transcribe them, but I wasn’t sure if it was accurate enough. I then asked Claude to explain to me how transcription like Whisper worked, and whether I would be able to accurately cut out things like ums or large pauses using ffmpeg.I wanted Claude to create a UI that was timed with the words I was saying, but wasn’t sure if it would be able to so I asked Claude to create a prototype video using Remotion and a transcription to see if it would work.Finally, the video itself looked a bit muted, which I knew was the result of color grading but I didn’t really know what color grading was. My first pass attempt was to try and get Claude to do a few variations to pick, but I realized that I didn’t know what “good” looked like when it came to color grading. So instead, I asked Claude to teach me about color grading to discover my unknowns.You can watch a more in-depth explanation on that here.Matching the Map and TerritoryThe better models get, the more you can achieve with the right approach. When a long-horizon task comes back wrong, it's likely you need to spend more time defining your unknowns or creating an implementation plan that allows for Claude to improvise through them.Every explainer, brainstorm, interview, prototype, and reference is a cheap way to find out what you didn't know before it gets expensive to fix.So start your next project by asking Claude to help you find your unknowns.译作者分享与Claude Fable的协作经验，指出"地图≠领土"：提示词与上下文（地图）与实际代码库和约束（领土）之间存在未知。他将未知分为四象限：已知-已知、已知-未知、未知-已知、未知-未知。顶级智能体程序员善于减少未知并预设预案。Fable是首个模型，其工作质量受限于用户澄清未知的能力。Claude可通过快速搜索代码库和互联网、从失败中迭代，帮用户定位未知。具体技巧包括实施前的"盲点检查"及迭代优化；避免指令过于具体或模糊，应让Claude协助发现未知。
智能体Anthropic教程/实践编码
推荐理由：Thariq 总结了一套与 Claude Fable 5 协作时发现「未知的未知」的方法论，从盲点扫描到事后测验，对想用好代理编码的开发者有实操价值。

7月3日7月3日周五

星期五 · 4 条
14:44
Hacker News 热门（buzzing.cc 中文翻译）精选
AI 评分 70/100
《Fable》通关指南：短绳AI编程法

专业开发者经过一年多研究，总结出使用AI编码代理的“短绳方法”。该方法要求开发者全程参与：先规划并分解任务，从不使用YOLO模式，每次变更前审查差异并拒绝不想要的更改，每个子任务后提交以防止AI误操作（如Opus曾出现破坏性行为）。最终需进行人工与AI双重PR审查，PR须注明使用模型，提交者须亲自审查自己PR的代码。即便不用前沿模型，此法也能产出超越Fable 5的代码质量。

智能体教程/实践编码
推荐理由：这篇是资深安全开发者一年的实战总结，提出的「短绳法」把AI代理栓紧，不是让开发者当甩手掌柜，而是逼你逐行审查，对代码质量死磕到底，比那些鼓吹全自动的大路货更有实操价值。
13:14
Hacker News 热门（buzzing.cc 中文翻译）精选
AI 评分 81/100
claude-real-video ─ 让任何大语言模型（LLM）都能观看视频

claude-real-video 是一个开源工具，让大语言模型基于视频画面而非字幕进行理解。它通过场景变化检测提取关键帧、滑动窗口去重并转录音频，生成干净的本地文件夹供模型读取。支持 YouTube 链接或本地文件，依赖 ffmpeg 和 Whisper，通过 pip 安装。全部处理在本地完成，不上传云端。

多模态开源/仓库教程/实践
推荐理由：这个工具把视频喂给 LLM 的过程从「固定采样 + 上传云」变成了「场景感知 + 本地去重」，大幅节省 token 且避免隐私泄露，用 Whisper 转录也更完整。是让任何 LLM 真正「看」视频的实用方案。
02:37
LMSYS：Blog（Chatbot Arena 团队）精选
AI 评分 59/100
Agent辅助的SGLang开发：初步探索

SGLang团队将LLM服务、分布式运行时、GPU内核、扩散管道等工作流编码为可执行的SKILL.md文件、脚本、基准合约和审查循环。现有技能包括：SGLang .claude/skills（CUDA调试、内核集成、性能分析等）、SGLang diffusion .claude/skills（扩散模型添加与调优）、BBuf/AI-Infra-Auto-Driven-SKILLS（跨框架SOTA循环）、KDA（MLSys 2026 FlashInfer内核竞赛获胜方案）以及BBuf/KDA-Pilot（已合并三个SGLang集成PR）。Profile证据是性能工作的核心，长期优化转向Loop Engineering——SGLang SOTA Performance Loop将追求SOTA分解为公平基准测试、差距决策、性能分析、补丁和再验证，Humanize/RLCR添加外部审查，Codex Goal以更低协调开销运行相同循环。评审重要性提升，开发者需定义问题、选择证据、设计工作流并判断结果是否可用于生产。

推理教程/实践部署/工程
推荐理由：这不是一篇普通的开发经验总结，而是 SGLang 团队把调试、基准测试和性能调优等重复劳动变成可执行 agent 技能的实操手册，对于做推理框架和复杂工程的人非常值得一看。
02:04
OpenRouter@OpenRouter精选
AI 评分 68/100
Fable 5 仅 4.44 美元搭建 Rube Goldberg 机器Rube Goldberg machine built with Fable 5, for $4.44 👀Prompt available here: https://www.reddit.com/r/openrouter/comments/1ulkilz/i_asked_claude_fable_5_to_build_a_rube_goldberg/译用 Fable 5 构建的鲁布·戈德堡机械，仅需 4.44 美元 👀 提示词在此：https://www.reddit.com/r/openrouter/comments/1ulkilz/i_asked_claude_fable_5_to_build_a_rube_goldberg/
教程/实践
推荐理由：一个好玩又有技术含量的玩法示范，Fable 5 配上精心调教的 prompt 把复杂机械动画成本压到几美元，做创意内容的可以直接抄作业。

7月1日7月1日周三

星期三 · 1 条
01:28
Claude：Blog（网页）精选
AI 评分 72/100
Claude Code 入门：智能体循环

Claude Code 团队将智能体循环定义为 agent 重复工作直到满足停止条件的过程，并划分出四种主要类型：turn-based 循环（用户提示触发，Claude 自行判断完成或需更多上下文）、goal-based 循环（通过 /goal 命令设定可验证完成标准与最大轮次）、time-based 循环（通过 /loop 按时间间隔重复执行，可用 /schedule 移至云端）、以及 proactive 循环（基于事件或计划自动运行，无人实时参与）。文章还介绍了如何编写 SKILL.md 文件将人工验证步骤编码，让 Claude 进行端到端自检，减少 turn-based 循环中的手动操作。

智能体AnthropicMCP/工具教程/实践
推荐理由：Anthropic把agentic loops从模糊概念变成四种可复制的模式，附带SKILL.md和命令示例，Claude Code用户读完就能设计更自主的编码流程。

6月30日6月30日周二

星期二 · 1 条
09:27
LangChain：Blog（RSS）精选
AI 评分 68/100
LangChain 发布智能体评估就绪检查清单

LangChain 发布了一份面向 AI 智能体评估的实用检查清单，涵盖错误分析、数据集构建、评分器设计、离线与在线评估以及生产就绪等环节。该清单旨在帮助开发者系统性地验证智能体在真实场景中的表现，降低部署风险。

智能体教程/实践
推荐理由：如果你在做 Agent 评估，这份检查清单把评估从“随机测试”变成了结构化流程，从错误分析到生产就绪都有覆盖，可以直接对照执行。

6月29日6月29日周一

星期一 · 1 条
10:10
公众号：数字生命卡兹克精选
AI 评分 70/100
分享两个Vibe Coding必备的实用Prompt：第一性原理与对抗式审查

作者分享Vibe Coding中两个关键Prompt：一是“从第一性原理出发”，强制AI跳出类比推理，从基本事实重新推导本质，曾帮作者发现AIHOT抓取海外信源的底层流量路由隐患并彻底重构；二是“对抗式审查”，让AI站在恶意用户角度攻防式审查代码，检出OOM死循环、未来时间污染等手工难发现的BUG。两个Prompt形成生成与验证闭环，使纯Vibe Coding项目AIHOT最近一周请求量超千万次。

教程/实践编码
推荐理由：这两个 Prompt 把 Vibe Coding 从碰运气变成了有方法，第一性原理堵设计漏洞，对抗式审查堵代码漏洞，卡兹克用自己项目的真实翻车案例讲透，是我读过最实用的编程 Prompt 技巧。

6月28日6月28日周日

星期日 · 1 条
03:25
Hugging Face：Blog（RSS）精选
AI 评分 62/100
一条命令在HF Jobs上启动vLLM服务器

HuggingFace Jobs 支持一条命令启动 vLLM 服务器，用于测试、评估或批量生成。使用 hf jobs run 命令，指定官方 vllm/vllm-openai 镜像、GPU flavor（如 a10g-large）、暴露端口 8000 并设置超时。服务器启动后可通过 OpenAI 兼容 API 访问，每次请求需携带 HF token 作为 bearer token（仅限有读权限的用户）。示例部署了 Qwen/Qwen3-4B（多 GPU 需 --tensor-parallel-size）。a10g-large 价格为 $1.50/小时，按分钟计费，可通过 hf jobs cancel 停止。

Hugging Face教程/实践部署/工程
推荐理由：这是一条命令在HF上启动vLLM的完整教程，适合快速测试模型的开发者，但方案完全绑定Hugging Face平台，通用性有限。

6月26日6月26日周五

星期五 · 1 条
10:10
公众号：数字生命卡兹克精选
AI 评分 71/100
Claude Code 6个实用Hook玩法

Claude Code 内置近30个Hook事件（年初仅13个），本质是写死的规则脚本，运行时不消耗token。6个实用玩法：权限弹窗提醒、开机日程播报（问候+天气+飞书日程）、上下文预压缩时自动生成摘要卡片、结合Skill自动整理下载文件夹、启动后每小时久坐提醒、通过Bark实现手机/手表任务完成/失败推送。让AI从被动聊天框变为事件驱动的自动化系统。

智能体AnthropicMCP/工具教程/实践
推荐理由：卡兹克把Claude Code的Hook拆成6个具体玩法，从权限弹窗到自动整理文件，每个都能直接抄作业，是让Agent从对话工具变成工作系统的最实用入门。
AI 编码Agent 智能体产品更新