AI 资讯

There's a whole ecosystem of "agent skills" now — reusable instruction files you drop into Claude Code (or Cursor, or Copilot) to make the model write cleaner code, debug more carefully, use fewer tokens, and so on. Some of these repos have tens of thousands of GitHub stars. Almost none of them ship a single number telling you whether the skill actually does anything. That bothered me, because "adding a plausible-sounding instruction" and "adding an instruction that works" look identical until you measure them. So I built a benchmark with one rule, committed before I ran anything: No skill gets merged unless it beats both a no-instruction baseline AND a placebo prompt on its pre-registered target metric, measured on hidden hold-out tests, with accuracy not allowed to drop. Skills that fail are published anyway, with their numbers. The placebo arm is the part almost nobody runs, and it turned out to be the most important one. Why a placebo Most "battle-tested" skill collections that measure anything at all compare skill-on vs skill-off. The problem: that comparison can't separate "this skill works" from "adding any confident-sounding text changes the model's behavior." LLMs are suggestible. If you want to claim your skill did something, you have to show it beats a same-length instruction that contains no actual mechanism — just vibes. So every result here is a three-way comparison — off / placebo / on — run K=5–8 times per task per arm, in isolated git workspaces, graded by hold-out acceptance tests the agent never sees, with every raw run log committed to the repo and the README regenerated from those logs in CI. 516 runs total, all on claude-opus-4-8 . Finding 1: the placebo often made code bigger My anti-over-engineering skill ( underkill , ~20 lines) cut source LOC by -23.8% vs baseline at identical accuracy (60/60 hold-out passes). Good. But the interesting column is the placebo: a same-length "write clean, minimal, professional code" instruction didn't reduce c

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git-lrc to help devs discover the project. Do give it a try and share your feedback. You've probably noticed this if you've tried to fetch a public webpage in the last two years. You write four lines of Python. You get a 403. You add a User-Agent header. You get a 403 with better manners. You spin up headless Chrome and get a challenge page that spins forever. Eventually you go looking at pricing pages for data APIs, where a cheerful landing page offers to sell you back the exact same public HTML for $100 a month. Meanwhile the big labs vacuumed up that same web at a scale none of us will ever match, and now the standard way to read a page programmatically is to pay somebody. The web went from "open by default" to "open, but only if you look like a person holding a mouse." So let's talk about eight open source projects quietly clawing that access back. I've used most of these in anger. Some are brilliant. Quick note on star counts: I mention a few, because they are a decent signal of "somebody else has hit the bugs before you." They are not a signal of maintenance. A repo can have 70k stars and a last commit from 2023. Always check the commit graph before you check the star count. 1. Firecrawl: the one that turned a URL into a prompt What it does: you hand it a URL, it hands you clean markdown. Not HTML with the nav bar and the cookie banner and four newsletter modals. Markdown. Headings, paragraphs, links, done. It also does more than single pages. The crawl endpoint walks a whole site, map gives you a URL inventory without fetching everything, and structured extraction pulls typed JSON out of a page if you describe the shape you want. from firecrawl import Firecrawl app = Firecrawl ( api_key = " fc-... " ) doc = app . scrape ( " https://example.com/docs/getting-started " , formats = [ " markdown " ]) print ( doc . markdown

I wanted to add a background-removal tool to my site's image cluster that stayed true to the 100% client-side processing principle I already use for PDFs and image conversions. The path there was anything but linear: a library dropped over a licensing problem, a carefully chosen model that turned out more limited than expected, and a bug that froze the entire page — not just the tool — during computation. Here's the full build, including the parts that didn't work the first time. The starting problem: what's actually feasible for free? The initial idea was broad: remove backgrounds, and maybe unwanted objects too. The two tasks have very different difficulty levels. Removing objects requires inpainting — plausibly reconstructing the erased area — which in practice still means heavy generative models, impractical to run client-side with good quality on an average device. Removing a background , on the other hand, is a segmentation problem: separating a subject from its surroundings. That has much lighter models available, runnable entirely via WebAssembly with no server involved at all. So: background removal only, object removal shelved for later. The AGPL trap The first library that looked like a perfect fit turned out to be distributed under AGPL , a strong copyleft license. Free to use — but with a real catch for anyone embedding it in a public, closed-source web service: AGPL can require releasing the full source of the project that embeds it, under the same license. "Free for the end user" and "safe to drop into a closed-source commercial product" are two different questions, and it's worth answering the second one before writing integration code, not after deploying it. Before wiring any "free" AI library into a commercial project, check the exact license, not just the price tag. AGPL, GPL, and other strong copyleft licenses are fine for personal or internal tools, risky for a public closed-source product. The fix: switch to Transformers.js — Hugging Face's li

A nova fase dos agentes de IA: menos chat, mais operação. A OpenAI apresentou o Presence, uma plataforma para empresas implantarem agentes de voz e chat em atendimento ao cliente e fluxos internos. Para quem desenvolve sistemas, o ponto não é apenas colocar mais um chatbot em produção. A mudança relevante é tratar a IA como uma camada operacional: ela precisa participar de processos reais, com objetivos claros e resultados verificáveis. Um agente confiável precisa de mais do que boas respostas. Precisa receber o contexto certo, operar dentro de permissões bem definidas, deixar rastros auditáveis e saber quando transferir o caso para uma pessoa. Isso altera a decisão técnica. Escolher um modelo continua importante, mas arquitetura, integrações, observabilidade, avaliação contínua e governança passam a fazer parte do mesmo problema. A pergunta mais útil deixa de ser “onde podemos colocar IA?” e passa a ser: qual processo já está pronto para ser redesenhado com um agente de confiança? Fonte oficial: https://openai.com/index/introducing-openai-presence

TL;DR: nb2lite-skill-agy wraps Google's gemini-3.1-flash-lite-image model (NB2Lite) in a FastMCP server and packages it as an Antigravity CLI skill. You type "generate an image of a cyberpunk kitchen" into Antigravity, and it just... does it. Then you say "add a neon RAMEN sign" and it edits the same image without re-prompting the whole scene. Oh, and the cover image of this article? Generated by the thing the article is about — dogfooding all the way down. More on that at the end. Background: why another image tool? Most image-generation workflows are stateless . You send a prompt, you get pixels back, and the model immediately forgets everything. Want to tweak the result? You re-describe the entire scene and pray the character, lighting, and composition survive the round trip. (Narrator: they don't.) Google's NB2Lite — the friendly nickname for gemini-3.1-flash-lite-image — takes a different approach. It's a high-efficiency image model with sub-2-second generations, solid text rendering in 25+ languages, and — the headline feature — support for the stateful Interactions API , which lets you iterate on an image across multiple turns while the model keeps the visual context server-side. This repo glues that capability directly into Google Antigravity CLI , so your coding agent can generate and iteratively refine images as a natural part of a pair-programming session. It ships as two things in one repo: A Model Context Protocol (MCP) server ( nb2lite-agent , a single-file FastMCP app in server.py ) exposing four tools. A Skill definition ( nb2lite-image ) that teaches Antigravity when and how to use those tools well. The Interactions API: images with a memory The Interactions API is Gemini's stateful endpoint. The core loop looks like this: You call client.interactions.create(...) with a prompt and store=True . The response includes an interaction_id — a handle to the turn's visual context, persisted on Google's servers. On the next call, you pass previous_interactio

Every couple of projects I ended up rebuilding the same effect: an animated topographic map background, the kind with slowly drifting contour lines. After copy pasting the same WebGL shader for the third time I gave up and turned it into a proper library. It's called topolines . One React component, zero dependencies, everything drawn on the GPU. Repo: https://github.com/idleCyrex/topolines Playground: https://topolines.idlee.xyz/playground How it works The lines are not an image or SVG. A small fragment shader generates a noise field (simplex noise + fbm) and draws contour bands from it, so it animates smoothly at any resolution for basically no CPU cost. The component just manages a canvas and the WebGL state around it. Usage npm i topolines import { Topolines } from " topolines/react " ; export default function Hero () { return < Topolines seed = "hello" color = "#F2EFE6" style = { { position : " fixed " , inset : 0 } } />; } Same seed always renders the same field, so your background is stable between visits. There are props for speed, scale, line width, colors, drift, and an interactive mode where contour rings bloom around the cursor. Things I cared about Zero dependencies, the whole thing is one shader and some glue code SSR safe, works in a Next.js server component tree Pauses when offscreen or when the tab is hidden Respects prefers-reduced-motion (renders one static frame) Clean fallback when WebGL is not available The playground lets you tweak every knob and copy the resulting code out: https://topolines.idlee.xyz/playground It's v0.1 and my first published library, so feedback and feature ideas are very welcome.

Every long-lived JS/TS project I've worked on accumulates the same three kinds of rot: Dependencies in package.json that nothing imports anymore. You added moment , migrated off it, and the line stayed. Exports nothing consumes. A function was public once, the last caller was deleted, the export is still there advertising an API with no users. Whole files that fell out of the import graph but never got deleted, so every new engineer reads them trying to understand code that runs nowhere. None of this breaks the build. That's exactly why it survives. The compiler is happy, the tests pass, and the dead weight compounds quietly until onboarding takes a week and your bundle ships code no user will ever execute. The tool I've settled on for this is knip (by Lars Kappert). I run it on the enterprise codebase I maintain and on basically every other TS project I touch. One command: $ npx knip Unused files (2) src/legacy/formatValue.ts src/hooks/useLegacyModal.ts Unused dependencies (3) lodash package.json moment package.json @types/uuid package.json Unused exports (5) parseLegacy src/parse.ts:42:14 toLegacyDate src/date.ts:9:14 ... Files, dependencies, and exports in one pass, cross-referenced against the actual import graph. It's the first tool I've used that treats all three as the same problem, which they are: something is declared, nothing uses it, delete it. The honest caveat Knip is not zero-config on a real codebase. Anything resolved dynamically, runtime import() , plugin systems, framework entry points it doesn't recognize (Next.js pages, a CLI bin, config files loaded by string), gets flagged as unused when it isn't. You will get false positives on day one. The fix is a knip.json that names your real entry points, and after that it's accurate. But budget an afternoon to tune it before you trust the output enough to delete on it. Anyone who tells you it's instant hasn't run it on a large app. What I actually want Here's the part that bugs me. This problem is not sp

Introduction Polymarket , and on-chain prediction markets like it, kept bothering me for one reason. Polymarket |世界最大の予測市場™ Polymarketは世界最大の予測市場であり、さまざまなトピックにわたって将来のイベントを取引することで、最新情報を入手し、知識から利益を得ることができます。 polymarket.com Who bet on what is visible in near real time. The moment a whale places a big bet on one outcome, everyone watching piles in behind them, and the odds move accordingly. That's not manipulation — it's just what happens with a public ledger. But it doesn't satisfy the simple wish to not reveal your prediction before everyone else does. So: could you build a prediction market that keeps your pick hidden until voting closes? To find out, I built Hidden League Forecast on Midnight , a privacy-focused blockchain. It's an MVP where you just guess the winner of a fictional soccer league (the World Cup just ended, so soccer was on my mind). Note What's a prediction market? A mechanism that expresses predictions about future events as prices. Think "which team will win the World Cup match," for example. If you want to learn more about prediction markets, this resource (Japanese) is a great start: https://zenn.dev/barabara/books/prediction-markets-structure The backend is written in Compact , Midnight's smart contract language. Note It combines the commit-reveal pattern with zero-knowledge proofs so that "the content of your prediction stays hidden, while only the aggregate stake becomes public." In this article, I'll walk through the contract code, showing what stays hidden and what becomes public at each step. Note This app runs on testnet. Demo Video After connecting Lace Wallet, you see your Shielded Address and balance. From here you can deploy a new market or enter an existing contract address to join one. The Overall Flow What's actually happening is simple. OPEN → REVEAL → AWAITING RESULT → RESOLVED → CLAIM Connect Lace Wallet, then deploy a market or join an existing one Pick one of 4 teams (Amber Foxes / Cedar Owls / Harbor Whales / Meadow Bears) and

TL;DR: omni-skill-agy wraps Google's gemini-omni-flash-preview model (Omni Flash) in a tiny FastMCP server and packages it as an Antigravity CLI skill. You type "generate a video of a fox running through snow" into Antigravity, and it just... does it. Then you say "make it nighttime with snowfall" and it edits the same video without re-prompting the whole scene. It can also animate a still image, interpolate between two keyframes, restyle a video you already have — and when you're happy, upload the result to YouTube. Without leaving your terminal. Background: why another video tool? Most video-generation workflows are stateless . You send a prompt, you get frames back, and the model immediately forgets everything. Want to tweak the result? You re-describe the entire scene and pray the character, lighting, and camera work survive the round trip. (Narrator: they don't.) Google's Omni Flash — gemini-omni-flash-preview — takes a different approach. It's the video-generation model in Google's Gemini "Omni" line: built for fast, high-fidelity clips, and — the headline feature — wired into the stateful Interactions API , which lets you iterate on a video across multiple turns while the model keeps the visual context server-side. What Omni Flash actually does The "Omni" part isn't branding fluff — the model accepts genuinely mixed multimodal input. A single request's input can be a plain string, or a list of typed parts: text parts, base64-encoded image parts, and document parts pointing at a video you've uploaded via the Gemini File API. The model composes whatever you hand it into one clip. That single mechanism covers five distinct ways to make a video: Text → video. A prompt in, an .mp4 out — landscape 16:9 or portrait 9:16 , chosen at generation time. One image + a motion prompt → animation. A still comes to life ("the group smiles and waves at the camera"). Two images + a transition prompt → keyframe interpolation. The model invents the in-between footage from frame A

Last time I said each post would show you the receipts. This one is a single day's worth. In about a day, five strangers audited my systems — and not one of them knew they did it. Each was a comment or a post on this feed: a single sentence that turned out to be pointing straight at a hole in something I'd already shipped and already trusted. I read the sentence, found the hole, and closed it — usually within the hour. I'm a physical therapist who builds a hospital's internal tools with AI, so "closed it" means the AI and I closed it while I described what was actually breaking. Five sentences, five holes, five receipts. They also turned out to be one idea wearing five coats. I'll get to that. Loot #1: the difference between "fine" and a receipt Someone wrote a line about scheduled jobs I couldn't shake: a receipt is not metadata about a result — it is part of the result. Labels go stale silently, they said, because whatever wrote the label already walked away before it stopped being true. My systems' health check said ok . That was the whole thing — a green word. So I made it hand over a receipt instead: which version checked, when, how many milliseconds the database actually took to answer, and one field I'm oddly proud of — an explicit "no degradation" that is present and set to null , not just absent. That distinction sounds like nothing and is everything: a missing field means "nobody checked," a field that's present-and-null means "checked, and it was clean." One is silence wearing a confident face. The other is proof someone looked. My health check used to conflate them. Now it can't. Loot #2: check the thing you shipped, not the thing you built Someone shipped a machine-learning model that passed its release gate and then answered "neutral" to every input it ever got. The gate had tested the model before the final export step — so it had validated a file no user would ever actually run. Their line: ask whether your gate validates the file you upload. I had t

In October 2017, researcher Mathy Vanhoef published an attack that broke WPA2, the encryption that had protected almost every Wi-Fi network on the planet for over a decade. The surprise was how it worked. KRACK did not guess your Wi-Fi password or brute-force any key. It tricked your device into installing a key it had already used, and that single mistake unraveled the encryption. WPA2 replaced the badly broken WEP standard in 2004 and quickly became the baseline for wireless security. For thirteen years it held up well. The passphrase-based version most homes use (WPA2-Personal) was vulnerable to offline password guessing if you chose a weak passphrase, but the protocol itself was considered sound. KRACK, short for Key Reinstallation Attack, was different. It targeted a flaw in the WPA2 standard itself, which meant every correct implementation was affected. The four-way handshake, briefly When a device joins a WPA2 network, the client and the access point run a four-message exchange called the four-way handshake. Both sides already share a secret (derived from the passphrase or from an enterprise authentication server). The handshake uses that shared secret to agree on a fresh session key, the Pairwise Transient Key, that will actually encrypt the traffic for this session. The important part is message three. The access point sends message three to tell the client the key is ready, and the client responds with message four and installs the key. Once installed, that key encrypts frames using a counter, called a nonce or packet number, that increments with every frame. The security of the encryption depends on one rule: a given key must never encrypt two different frames with the same nonce. The reinstallation trick Wi-Fi is a lossy medium. Messages get dropped. So the standard says that if the access point does not receive message four, it retransmits message three. When the client receives a retransmitted message three, it reinstalls the same key and, critically,

# Module Resolution Algorithm (Part 1): How Node.js Finds the Right Module In the previous article, we explored one of the most fascinating parts of Node.js—the hidden Module Wrapper Function. We learned that every CommonJS module is wrapped inside a function before execution, and we also discovered that require() is not a JavaScript feature. It is provided by the Node.js runtime. But a very important mystery still remains. When we write: const fs = require ( " fs " ); or const math = require ( " ./math " ); how does Node.js know where these modules are located? How does it decide whether "fs" is a built-in module or a file inside your project? Why does require("./math") work even if you don't write .js ? And what happens internally before your code starts executing? The answer lies inside one of Node.js's most important systems: The Module Resolution Algorithm Understanding this algorithm is essential because every Node.js application uses it hundreds or even thousands of times while starting. What is Module Resolution? The word resolution simply means: Finding the actual file represented by the string passed to require() . Suppose you write: require ( " ./math " ); To you, "./math" looks like a file. But for Node.js, it is initially nothing more than a string. "./math" Node cannot execute a string. It needs the real file. So its first job is to answer one question: "Which exact file should I load?" The complete process of converting the string inside require() into an actual file on disk is called Module Resolution . Why Does Node Need a Resolution Algorithm? Imagine a project like this: project/ ├── app.js ├── math.js ├── database.js ├── auth.js └── utils/ ├── logger.js └── helper.js Now look at these statements. require ( " ./math " ); require ( " ./database " ); require ( " ./utils/logger " ); require ( " fs " ); require ( " express " ); All of them look similar. But internally they are completely different. Some point to your own files. Some point to Node's bu

This is today’s edition of The Download, our weekday newsletter that provides a daily dose of what’s going on in the world of technology. Supercooled kidneys have been transplanted into pigs in a “landmark achievement” When it comes to organ donation, time is everything. As soon as an organ has been removed from a donor’s…

In Pasadena, California, there's a cute red brick courtyard where one storefront isn't like the rest. The glass doors open onto a sparse industrial hallway, which leads to a sunlit foyer with a large spiral staircase. Go up, and you'll see a typical coworking space: open tables, healthy snacks, a collection of meeting rooms with […]

Meta is trying to tackle scammers that are using generative AI by introducing a new kind of verification using user selfies.

TikTok has attracted the ire of the European Union over its protection of children who use the video sharing platform. The European Commission announced preliminary findings today under the Digital Services Act (DSA) that offer specific issues to address. The Commission suggests that TikTok should adjust the default settings of minors' "public" accounts so the […]

A deep dive on Go 1.24’s map redesign, where the runtime moved from the classic bucket + overflow-chain model to a Swiss Table-inspired implementation: how the old map layout worked and where pointer-chasing hurt cache locality how control-byte metadata + h2 filtering changes lookup behavior why this can improve practical load factor and memory efficiency Go-specific constraints (iteration semantics, GC/runtime integration, incremental growth behavior) benchmark context: large microbench wins vs smaller full-application geomean gains trade-offs still being worked on (cold-cache and certain delete/clear-heavy paths) submitted by /u/OtherwisePush6424 [link] [留言]