AI 资讯

Everyone's talking about AI agents right now, but most tutorials stop at "call an LLM in a loop." If...

If you've ever localized an iOS or macOS app, you know the drill: you've got a .plist file full of UI strings sitting in Base.lproj , and now you need the same file in fr.lproj , th.lproj , de.lproj ... and so on for every language you support. You can pay for a translation service, hand it to a freelancer, or sit there manually retyping strings into fifteen copies of the same file. I didn't want to do any of those things, so I spent a day building pListTranslatorApp — a small SwiftUI macOS app that opens an Xcode plist, finds the string values you want translated, batch-translates them using Apple's built-in Translation framework, and writes out a ready-to-use localized plist. It's free, it runs entirely on-device, and it's now sitting on GitHub for anyone who wants it. The constraint that shaped the whole thing I'm developing on a MacBook Air with a 256GB SSD and 8GB of RAM — not a lot of headroom. That ruled out a couple of obvious approaches: Cloud translation APIs (DeepL, Google Cloud Translate, etc.) work well, but even a generous free tier means an external dependency, an API key to manage, and a network round-trip for something that's ultimately just short UI strings. Downloading a pile of on-device language models "just in case" eats real disk space fast — Apple's Translation framework models are shared system-wide across apps, which helps, but they still add up if you're not paying attention. So the app leans entirely on Apple's Translation framework , downloading exactly one language pack at a time, on demand, and lets you delete it once you're done with that language. What it actually does Open a plist. Pick any Xcode .plist via a standard file importer. Choose which keys to translate. Originally I hardcoded it to look for a key called itemTitle , but that's obviously too narrow for anyone else's project — so it's now a comma-separated text field. Type itemTitle, title, label and it'll pick up all of them, anywhere in the plist's nested dictionaries and

As developers, we use authorization libraries almost every day. Whether it's a web application, an API, or an internal tool, we often rely on packages that decide who can do what. But I realized I had never actually built one. So instead of using an existing library, I decided to build my own Role-Based Access Control (RBAC) library in Go using only the standard library. This project eventually became GateKeeper v1.0.0. Why I Built One As a beginner in backend development, I wanted to get exposure on how to make public APIs and how to make them work under the hood. It also made me fight my old syntax habits. Go has strict error handling, which I also learned. I built it because I wanted to understand the engineering decisions behind public libraries. Instead of watching another tutorial, I built it myself. Project Goals Before writing any code, I brainstorm the architecture in my mind. No external library used, only the standard Go library. Keeping the public APIs simple and easy to read for developers to use. Write tests for each and every function, no matter how small. These constraints forced me to think more carefully about the design instead of depending on external packages. The Core Model Engine ├── Users ├── Roles └── Permissions Relationships are straightforward: Users | V Roles | V Permissions A user can have multiple roles, and roles can have multiple permissions. Permissions describe access to a resource and an action. Designing The API One thing I learned the hard way is that API design matters more than the implementation itself. I wanted to keep the library easy to read even without documentation. The public API ended up looking something like this: CreateUser() CreateRole() CreatePermission() AssignRole() AssignPermission() Can() DeleteUser() DeleteRole() DeletePermission() RenameUser() RenameRole() I had to redesign the API many times before eventually coming up with the final one. The time spent fighting the design was worth it. It taught me API de

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