AI 资讯

TL;DR In December 2025, Cline — an AI coding assistant with over 5 million users — gave an AI agent (Claude) write access to triage GitHub issues, including permission to run shell commands. A misconfigured trigger condition let any GitHub user invoke the workflow. What followed was a four-hop supply chain compromise that ended with a malicious npm package silently installing a second AI agent on user machines. I broke down the full chain in video form: Watch the episode Below is the chain, hop by hop. Hop 0: The setup The triage automation was configured with broad tool permissions and a trigger condition open to any GitHub user — not just contributors. That second part is the root cause: it opened the trigger to unauthenticated input. (Exact config values are in the Confirmed Artifacts section below.) Hop 1: Prompt injection via issue title The issue title itself was never sanitized before reaching the model. No first-party source has published the exact injected payload verbatim — GHSA doesn't disclose it — so any reconstruction here is illustrative, not confirmed. What's confirmed is the mechanism: an untrusted string reached the model with tool access already granted. Hop 2: Cache poisoning The injected instruction deployed a tool (multiple independent postmortems — Snyk, Cloud Security Alliance — name it "Cacheract") that flooded the CI cache with over 10GB of junk data, evicting legitimate entries through standard LRU eviction. Hop 3: Nightly workflow inherits the poisoned cache The nightly release workflow restored that poisoned cache around 2 AM UTC and ran inside it — handing over three publish tokens. (Names confirmed across GHSA and multiple independent sources — see below.) Hop 4: Publication cline@2.3.0 went live on npm with a postinstall script that silently installed a second package globally — an AI agent, installed by an AI agent, with no user consent. This line is a direct quote from Cline's own security advisory, not a reconstruction. It's the st

This is the workflow I follow before I use AI agents to implement any feature or bug fix. 🧭 Requirements/Specification ↓ Design/Architecture ↓ AI Code Generation ↓ Human Review ↓ Build & Static Analysis ↓ Testing & Validation ↓ Defect Resolution ↓ Security & Compliance Review ↓ Release ↓ Production Monitoring vs Claude Code ↓ Implements feature ↓ Codex QA Agent ↓ Runs application ↓ Tests happy path ↓ Tests edge cases ↓ Tests error handling ↓ Produces QA report This will resolve the self-review bias, confirmation bias, or AI-to-AI bias. 1️⃣ Understand Before Writing Code Before touching any code, I try to understand what I'm building and why . I usually start by reading: specs/<module>/<TICKET>-<slug>.md plan/<module>/<TICKET>-<slug>.md status.md Then I review the project conventions: specs/CONVENTIONS.md specs/conventions/core-porting.md Finally, I read the existing implementation (entities, services, mappers, etc.) so my changes follow the existing architecture instead of introducing a new style. 💡 Pro-Tip Good code fits into the codebase. Great code looks like it was always there. 2️⃣ Plan the Change Once I understand the requirements, I identify which architectural layers are affected. I always respect the dependency order: Schema / Entities / DAOs ↓ Mappers / DTOs ↓ Service Layer ↓ Application Layer ↓ Controllers I don't jump ahead of dependencies. If a change is complicated or ambiguous, I document the approach before writing code. --- ## 3️⃣ Write the Code While implementing, I follow the repository's rules. Some examples: | Rule | Detail |---|---|---| | DTOs | Generated from `schema.yml` — never handwritten | | Status values | Sourced only from the Core Porting specification | | Traceability | Every ported behavior includes a source citation | Citation formats I use: - `← Source <path>` - `← PS §...` - `← BR-###` Beyond repository rules, I also try to: - ✅ Match existing naming conventions - ✅ Keep comments minimal and meaningful - ✅ Make small, focused chang

Running out of API quota in the middle of a production deployment is a frustrating rite of passage. If you are using the Google Custom Search API, you have likely hit that 100 free daily queries wall. Once you do, your application throws a 403 Quota Exceeded error, stalling your features unless you link a billing card and risk uncapped charges of $5 per 1,000 queries. In my experience, relying on Google's default limits without safeguards is a major liability. Here is how I protect my cloud budget, stretch the free tier using Redis, and transition to scalable alternatives when 100 queries are no longer enough. Step 1: Enforce a Hard Billing Cap in GCP Never rely on email alerts alone; they do not stop API requests. If a recursive loop in your code or a malicious bot targets your search endpoint, your credit card will bear the brunt. To set up a hard stop: Log into your Google Cloud Console . Navigate to APIs & Services > Enabled APIs & Services . Select Custom Search API , then click the Quotas tab. Locate Queries per day and click the edit pencil icon. Set your maximum limit to 95 (not 100). Pro Tip: This 5-query cushion gives you a safe buffer for emergency local debugging without triggering paid overages. Step 2: Implement Redis Caching Middleware Over 40% of search queries in typical web applications are repetitive. Implementing a Redis database to cache these searches can cut your API consumption by up to 80%. Here is a simple Python middleware pattern to normalize queries and cache them with a 24-hour Time-To-Live (TTL): import redis import requests # Connect to local Redis instance cache = redis . Redis ( host = ' localhost ' , port = 6379 , db = 0 , decode_responses = True ) def fetch_search_results ( query , api_key , search_engine_id ): # Normalize input to avoid duplicate cache keys normalized_query = query . strip (). lower () cache_key = f " search:cache: { normalized_query } " # 1. Check local cache first cached_data = cache . get ( cache_key ) if cach

Every model card says "multimodal". Then you hand the model a real video file and discover what that means in practice: ChatGPT reads the subtitle track, Claude doesn't accept video files at all. The model narrates a video it mostly never saw. I unpack viral videos daily for my own content work, so I couldn't route around this. I built a small tool instead. The mechanism claude-real-video converts a video into three things an LLM can genuinely read: Scene-aware sampled frames — ffmpeg scene scores decide where to sample, so you get a frame when the picture changes, not every N seconds. An --adaptive flag handles slow deformations (a real user bug report: fixed thresholds missed squash/stretch morphs entirely). A timestamped transcript — whisper by default; if faster-whisper is installed it runs in-process and several times faster, with automatic fallback. One MANIFEST timeline — frames and transcript merged into a single file, so the model follows the video in order instead of guessing from fragments. A --text-anchors flag force-samples frames at subtitle cues so on-screen text never falls between frames. Then you point any LLM at the output folder — Claude, GPT, Gemini, or a local model. No API of mine in the middle, everything runs on your machine. Usage pip install claude-real-video crv "video.mp4" -o out Honest limitations Not real-time — a 90-second video takes about 1–2 minutes all-in on an M-series Mac. Frame sampling can still miss motion between frames; the flags above patch the worst cases, both born from real GitHub issues. It's MIT, currently at 1,731 stars with ~8k installs last month, which taught me the problem was never just mine: https://github.com/HUANGCHIHHUNGLeo/claude-real-video

Before I critique modern web development, I want to make some points: I'm not discouraging anybody from web development. This is only my opinion and my experience of the story. Everyone has their own story. Part 1. Javascript JavaScript is known for being the web's language. It's used everywhere in the web, and can also be used to make external applications outside of web development. JavaScript has many flaws in its language, such as its comparison logic. JavaScript uses the "strict equality operator" that tries to solve its weird type coercions (e.g [] == ![] being true). Another flaw is that JavaScript has poor maintainability. JavaScript has a poorly managed type system that introduces errors without proper error handling. You cannot explicitly define what error you're trying to catch in the try-catch statement. try { functionThatThrowsError () } catch ( error ) { console . error ( error ); if ( error instanceof MyError ) { doSomething (); } } instead of modern languages: try { functionThatThrowsError () } catch ( e : MyError ) { print ! ( " error: ${e.message} " ) } This adds complexity to try-catch statements and makes it almost impossible to handle errors in a robust manner. Another issue with JavaScript's maintainability is the wording of the language. JavaScript has two keywords called undefined and null . In practice these should mean the same thing but it doesn't. An undefined variable is an uninitialized variable, or a function that doesn't return anything. Undefined: // Returns undefined function getName () {} // syntactically correct in JavaScript // but will cause undefined console . log ( getName ()); const myCoolObject = {}; console . log ( myCoolObject . property ); // still syntactically correct in JavaScript even though the property doesn't exist. Null: // Returns a null name function getName () { return null ; } // output: null console . log ( getName ()); const myCoolObject = { property : null }; console . log ( myCoolObject . property ); //out

Every team doc tool these days is "searchable." Notion, Confluence, wikis — you can find any page in seconds. But search only tells you a document exists; it doesn't tell you how it connects to the five other docs that explain why it looks the way it does. New hires still end up pinging three people on Slack to reconstruct the reasoning behind a decision that's technically "documented" somewhere. This post is about the difference between a searchable knowledge base and a connected one — and why most teams have the first but assume they have the second.

What Changed Protocol Buffers (protobuf), Google's widely adopted data interchange format, has undergone several recent updates focusing on build system integration, compiler support, and internal development processes. Key changes include the introduction of Bzlmod support for Bazel 8+, updates to the Bazel CI presubmit matrix, and the removal of older GCC versions from GitHub Actions testing in favor of GCC 10. Specifically, the project now explicitly supports Bazel with Bzlmod for Bazel 8 and newer versions, allowing users to specify protobuf as a dependency in their MODULE.bazel file. This modernizes the Bazel integration, offering an alternative to the traditional WORKSPACE approach. Concurrently, the .bazelci configuration has been updated to remove macOS (Intel Macs) from the presubmit matrix, revise Debian and Ubuntu distributions, and incorporate Bazel 9.x testing. In terms of compiler support, the .github workflow for C++ testing has been refined. GitHub Actions matrix entries testing GCC versions prior to GCC 10 (specifically 7.5, 9.1, and 9.5) have been removed, and a GCC 10.4 test has been added. This aligns the testing infrastructure with the project's current support matrix, ensuring compatibility with more recent compiler versions. Internal refactoring also occurred, such as the extraction of OptionInterpreter to option_interpreter.h and option_interpreter.cc from descriptor_builder.h and descriptor.cc respectively. Furthermore, the C# protobuf implementation saw a version update to 37.0-dev, indicating ongoing development across various language bindings. Technical Details The integration of Bzlmod for Bazel 8+ signifies a move towards a more modular and efficient dependency management system within the Bazel ecosystem. Developers can now declare a dependency on protobuf in their MODULE.bazel file, with an option to override the repository name for compatibility with existing WORKSPACE setups. This streamlines dependency resolution and build graph m

What Changed DocuSeal has emerged as an open-source platform for digital document signing and processing. This project offers a self-hostable alternative to commercial services, allowing organizations to manage document workflows, eSignatures, and form filling within their own infrastructure. The platform is designed to be accessible, mobile-optimized, and integrates with existing systems through APIs and webhooks. Technical Details DocuSeal provides a comprehensive set of features for digital document management. Key functionalities include a WYSIWYG PDF form fields builder that supports 12 field types, such as Signature, Date, File, and Checkbox. It accommodates multiple submitters per document and automates email notifications via SMTP. For file storage, DocuSeal offers flexibility, supporting local disk storage as well as cloud providers like AWS S3, Google Storage, and Azure Cloud. The platform implements automatic PDF eSignature generation and includes a mechanism for PDF signature verification, addressing security and compliance requirements. User management is integrated, and the UI is mobile-optimized, supporting 7 UI languages with signing capabilities in 14 languages. Integration with other systems is facilitated through a robust API and webhooks. Deployment options are varied, catering to different infrastructure preferences. DocuSeal can be deployed on cloud platforms such as Heroku, Railway, DigitalOcean, and Render. For containerized environments, Docker images are available, allowing for deployment via docker run commands. By default, the Docker container utilizes an SQLite database, but it can be configured to use PostgreSQL or MySQL by setting the DATABASE_URL environment variable. Docker Compose configurations are also provided, enabling deployment with custom domains and automatic SSL certificate issuance via Caddy. Pro features, available through commercial offerings, extend the platform's capabilities to meet business needs. These include compa

Every team builds APIs. Few build ones that survive their second rewrite. After inheriting three different REST APIs in as many years — one with endpoints named /getAllUsers , another that returned { "status": "ok" } for both success and 500 errors — I started keeping a list of the practices that actually distinguish robust APIs from ones that generate PagerDuty alerts at 3 AM. This guide distills six rules I've validated across production services handling tens of millions of requests. None are theoretical. All come with working code. 1. Resource-Oriented Naming — Not Action-Oriented The single biggest smell in a REST API is action verbs in URLs: # Bad — these are RPC, not REST GET /api/getUser?id=42 POST /api/createUser POST /api/deleteUser/42 POST /api/activateUserSubscription Resources are nouns, not verbs. The HTTP method is the verb: # Good GET /api/users/42 POST /api/users DELETE /api/users/42 POST /api/users/42/subscriptions # nested resource DELETE /api/users/42/subscriptions/active Key conventions that have held across every production API I've consulted on: Plural nouns : /users , not /user . Consistency with list endpoints ( GET /users = a list) makes singular feel like a bug. Kebab-case for multi-word resources : /order-items , not /orderItems or /order_items . It's URL-safe and matches what browsers expect. Nest at most two levels : /users/42/orders/7 is fine. /users/42/orders/7/items/3/addresses/9 is a cry for help. At that point, use a query parameter: /items?order_id=7 . Use query params for filtering, not path segments : /users?status=active&role=admin , not /users/active/admins . 2. Consistent Error Responses — The Contract People Actually Rely On Most API errors are parsable only by humans staring at a screen. That's a bug. Every error response should follow the same schema so clients can handle them programmatically: { "error": { "code": "USER_NOT_FOUND", "message": "User with id 42 was not found.", "details": { "resource": "users", "identifier"

The AI book service that shows its work Discussion | Link

I spent three months and about $500 on GPU rental trying to host my own LLM. I had a spare RTX 3090, I was deep in the open-source hype, and I was convinced that running my own model was the only way to get privacy, control, and—let’s be honest—bragging rights. I ended up switching to an API that costs me less than a dollar per month for my use case. Here’s what I learned, and why I think most developers should stop self-hosting AI models. The Siren Song of Self-Hosting The argument for self-hosting sounds great: Privacy : Your data never leaves your machine. Control : You can fine-tune, tweak, or swap models whenever you want. No vendor lock-in : You’re not at the mercy of OpenAI or Google changing their pricing or policies. Open source ethos : It’s the “right” way to do things. I bought into all of it. I set up Ollama, downloaded Llama 2 7B, then 13B, then Mixtral 8x7B. I spent weekends wrestling with Docker, CUDA versions, and VRAM limits. I felt like a real engineer. But the reality was different. The Hidden Costs My $500 was just the start. I rented cloud GPUs because my 3090 wasn’t enough for the models I wanted. A single A100 on AWS costs about $3.50 per hour. For a model like Llama 2 70B, you need at least 48GB VRAM, which means a multi-GPU setup or a high-end instance. Here’s a quick breakdown of what I actually spent over three months: Item Cost GPU rental (spot instances) ~$350 Storage for model weights ~$30 Time debugging (conservative) 40 hours Power/electricity (home GPU) ~$40 Total ~$420+ And I never got it running reliably. The 70B model would crash after a few hours. The 13B model was decent but slow—about 10 tokens per second on my 3090. For a chat app, that’s painful. Compare that to an API call: import openai client = openai . OpenAI ( api_key = " sk-... " , base_url = " https://api.tai.shadie-oneapi.com/v1 " ) response = client . chat . completions . create ( model = " gpt-4o-mini " , messages = [{ " role " : " user " , " content " : " What ' s

When I started working on a WooCommerce slider plugin, I noticed that many existing solutions were packed with features that a lot of websites simply don’t need. More features often mean more CSS, more JavaScript, and a bigger impact on performance. So I asked myself a simple question: What would a WooCommerce slider look like if performance came first? My goals Instead of creating another all-in-one slider plugin, I focused on a few principles: Lightweight codebase Fast loading times Responsive by default Easy integration with Gutenberg Elementor support Shortcode support Clean and maintainable architecture Performance matters Every additional request and every unnecessary asset affects page speed. Some optimizations I implemented include: Assets are loaded only when required. Local libraries instead of unnecessary external requests. Server-side rendering where appropriate. Clean HTML output. Developer experience I also wanted the plugin to be simple for users. Instead of a complicated interface, the goal was: Install Create a slider Insert it into a page Done Lessons learned Building a public WordPress plugin taught me a lot: Documentation is almost as important as the code. User feedback quickly reveals edge cases you never considered. Keeping the codebase simple often leads to better long-term maintainability. What’s next? I’m continuing to improve the plugin by adding new features while keeping performance as the top priority. I’d also love to hear how other developers approach WordPress plugin development and performance optimization. Thanks for reading! ⸻ If you’re interested, you can check out my project here: WordPress.org: https://wordpress.org/plugins/amitry-product-category-slider/ GitHub: https://github.com/amitry-de/amitry-product-category-slider Live Demo: https://slider.amitry.de/

The evals for my agent skills scored 0% for as long as I had records. Not low. Not noisy. Exactly zero, every skill, every run. And I believed it. For months I thought my skills were bad, because the number said so and the number never wavered. Then one night I actually read the harness. It had fallen back to the wrong auth token. Every call it made came back 401, and it quietly graded each one a failure. The skills never got a chance to fail on their own. I was not measuring them at all. I was reading a broken thermometer. Real weakness is jagged Here is what took me too long to see. When a system is genuinely bad, it scores 40% one week and 60% the next. It passes the easy cases and trips over the hard ones. It has good days. Incompetence has texture, because an incompetent system is still in contact with the world, and the world varies. A flat number has no texture. A flat number means the measurement stopped touching the thing being measured somewhere upstream, and what you are reading is the instrument's resting state. Doctors know this. A heart monitor drawing a perfectly straight line does not mean the patient is calm. Only a broken thermometer writes the same number every time. Key insight: A performance number with no variance is a reading of the instrument, not of the thing being measured. The same bug in three industries I run systems in advertising, in healthcare billing, and in agent operations, and the same shape shows up in all of them. In advertising I found a dashboard figure that had been hardcoded for two years. Nobody questioned it, because it looked right, and it looked right because it never moved. In agent operations, an account-rotation bug in one of my pipelines overwrote every real error with the same generic message, "no active accounts," so for a while every distinct failure in that system looked identical. And in the denial-assessment engine I run for a medical-billing operation, an agreement metric came back at 44.7%, alarmingly low, un

I used to deride the idea of an AI assistant from the moment they entered the picture (after seeing all the different *Claw variants). Why would regular people like me need an assistant? The best use case I had heard was: "Oh! It helps us decide whether I or my partner should drive the kids today!" Solving that sounded like a silly problem for an AI assistant to handle. Again, I didn't know any better because I didn't have that problem. I thought I could handle one-off tasks with just an AI subscription. What else was there? I only found the answer once I had a specific use case for it. I attended a business event, talked to a dozen people, and collected several business cards. I wanted to send each person a personalized email thanking them and continuing our conversation. If I were to do this manually, the process would look like this: open the email client, manually type in each email address from the business cards, ensure I typed everything correctly, compose my message, and again, make sure I didn't press "send" prematurely. Just thinking about it felt tedious. That is when the idea of an assistant started making sense. I fire up my coding agent(not a *Claw still), I take a single photo of all the business cards together. I ask the it to extract the names and email addresses. Then, I ask it to loop through the list and ask me what I want to send to each person. It creates drafts(which I still manually review - can't trust them enough), I say send, and then it sends them all automatically. It feels exactly like talking to a real assistant: you tell them what you want done, and it gets done without you having to press buttons or navigate a UI. That is exactly what I did; I simply gave it instructions using my voice. This makes me feel that having an AI assistant is indeed helpful. It might have also been useful to jump on this a little sooner, as I could have bought that Mac Mini at the older, lower price.

Cx Dev Log — 2026-07-18: A Moment of Pause Before the Next Push The Cx codebase has taken a breather. It's been quiet for five days, a rarity in the fast-paced world of solo-developed languages. Main is stable at commit 3430e4e , marked by the last 0.3.1 release tag from July 9. Submain's clocked at 3b7b7f8 with the freshly finalized gene/phen design as of July 14. Even the automated matrix stands firm: 321 tests passing, zero failing. But quiet isn't inactivity—it's anticipation. Where the Project Sits The significant chunk of work that wrapped on July 14 was hefty: the gene/phen design's v1.1 spec. It doesn't just wrap dispatch strategies; we're talking about cleaner Ord mappings, robust Self resolutions, and handling phen lookups with cross-module coherence. Those are down in a 13-commit series on submain, the product of a thorough hammering out of all six outstanding design questions. But it wasn't just theoretical. These commits include necessary parser and semantic adjustments, say, coming out of our recent audit. Scoping issues are in check, width-range enforcement leveled up, and we've put any unnecessary comparison errors on Bool/Enum to bed. There's a crucial runtime patch too—no more enum == / != crashes blowing up the interpreter. We've also streamlined CI through direct run_matrix.sh runs. These advances sit 13 steps ahead of main without a single technical barricade to rushing them into action. This delay in merging? It's purely deliberate, not dictated by troublesome conflicts or failing tests. What's Queued Once Work Resumes So, what's cooking when the fingers start flying across keyboards again? Here's what's lined up: Merge submain to main. We've got 13 commits begging for integration. Expect this to be painless, almost ceremonial, since main's been untouched. 0.3.4: Gene/Phen Implementation. The design spec isn’t a riddle wrapped in an enigma—it's a clear blueprint. It's got everything: pass ordering, canonical key formats, robust collision detect

Everything you need to go from pip install to a working multi-object tracker, one runnable snippet at a time. kalbee is a Python library for state estimation — the art of recovering a clean signal (position, velocity, temperature, whatever you're measuring) from noisy sensor data. This guide walks through it from the ground up. Every code block runs as-is; copy them into a file and follow along. Install pip install kalbee The only runtime dependencies are NumPy and SciPy. Optional extras add object-detection ( pip install "kalbee[yolo]" ) and plotting ( pip install "kalbee[viz]" ) support. The one idea you need: predict and update Every filter in kalbee works the same way. You alternate between two steps: predict() — advance the state forward in time using a motion model ("where do I think the object is now?"). update(z) — correct that prediction with a new measurement z ("what does the sensor actually say?"). The filter tracks two things: the state x (your best estimate) and the covariance P (how uncertain that estimate is). You read them back via kf.x and kf.P . Your first filter Let's track an object moving at roughly constant velocity, measuring only its (noisy) position. Instead of hand-building matrices, we use kalbee's ready-made models : import numpy as np from kalbee import KalmanFilter , rmse from kalbee.models import constant_velocity , position_measurement_model dt = 1.0 # Motion model: state is [position, velocity] F , Q = constant_velocity ( dt = dt , process_var = 0.01 , n_dims = 1 ) # Measurement model: we observe position only, with noise variance 4.0 H , R = position_measurement_model ( order = 1 , n_dims = 1 , measurement_var = 4.0 ) # Simulate a noisy trajectory rng = np . random . default_rng ( 0 ) pos , vel = 0.0 , 1.0 truths , measurements = [], [] for _ in range ( 50 ): pos += vel * dt truths . append ( pos ) measurements . append ( pos + rng . standard_normal () * 2.0 ) # std 2.0 -> var 4.0 # Create the filter: start at zero with high uncert