AI 资讯

Substack will now help users determine whether what they're reading may have been written by AI. A new tool coming to the platform can scan posts, notes, replies, and comments to provide an estimate of how much text could be AI-generated or written with AI assistance, according to a blog post published on Tuesday. The […]

Pat Gelsinger wants to pave the way to ever more powerful artificial intelligence using tiny beams of light.

The latest release of Android Studio, Quail 2, now stable, expands Gemini/AI Agent Mode inside the IDE by enabling multiple AI conversations in parallel and further advancing Google's push to integrate AI-powered workflows directly into Android Studio. It also enhances debugging and profiling capabilities and makes it easier to explore experimental features. By Sergio De Simone

With code coming in faster and faster, we've been losing track of context, what's out of date, the source of truth, etc. Also with individuals spending less and less time on any one problem, finding an expert to answer questions has become challenging. People don't have that single domain of expertise like we used to. There's too much surface area to cover. Are we the only ones dealing with this? How's everyone else handling it?

Substack is partnering with Pangram to add an AI detection feature.

Apple reportedly fixed the Hide My Email vulnerability that left iCloud+ users' emails not especially hidden.

Most "AI agent" libraries fall into one of two buckets. Either they're a big framework you spend an afternoon configuring, or they're a tiny toy that drops the one feature you actually need in production: the ability to stop and ask a human before the agent does something you can't undo. I wanted the middle. So I wrote yieldagent : a small agent loop you can read end to end, with human-in-the-loop pause/resume built in, and no runtime dependencies. This post walks through how it works and why it's built the way it is. What an agent loop actually is Strip away the branding and an "agent" is a loop: Send the conversation to the model, along with the tools it's allowed to call. If the model asks to call a tool, run it and append the result. Repeat until the model answers without asking for a tool. That's it. The model decides the control flow at runtime; your job is to run the tools and feed the results back. Here's the core, lightly trimmed: for ( let step = 0 ; step < maxSteps ; step ++ ) { const reply = await call ( messages , toolSpecs ); messages . push ( reply ); if ( ! reply . tool_calls ?. length ) { yield { type : " final " , text : reply . content , messages }; return ; } for ( const tc of reply . tool_calls ) { const args = JSON . parse ( tc . function . arguments ); const result = await tools [ tc . function . name ]. run ( args ); messages . push ({ role : " tool " , tool_call_id : tc . id , content : JSON . stringify ( result ) }); } } Everything else in the library is in service of making this loop observable, testable, and safe to run against the real world. Why an async generator Notice the yield . The loop is an async generator, so the caller drives it: for await ( const step of agent ({ call , tools , messages })) { if ( step . type === " tool-start " ) console . log ( " -> " , step . tool , step . args ); if ( step . type === " final " ) console . log ( step . text ); } Every step (each tool call, each result, and the final answer) is handed back to

For a long time, I believed coding was only for people who studied computer science or worked as professional developers. Whenever I saw a screen filled with code, it looked like a completely different language. There were brackets, symbols, functions, and terms I did not understand. I assumed learning it would require years of study before I could create anything useful. That changed when I encountered a repetitive task at work. I was regularly copying information from a spreadsheet, checking each row, preparing an email, sending it, and updating the status manually. The work was manageable, but completing the same process repeatedly took time and left room for mistakes. I started wondering if the spreadsheet could do some of the work for me. That question led me to Google Apps Script. At first, I did not even know where to begin. I understood the result I wanted, but I did not know how to translate it into code. I could explain the process clearly to another person, but explaining it to a computer felt different. AI became my starting point. I described the task and asked it to create a script. Within seconds, it gave me several lines of code. I copied them, ran the script, and immediately received an error. My first reaction was frustration. I had expected the code to work because it looked complete. But I soon realized that generated code was not automatically working code. I went back and explained the error. AI suggested a change, so I tested it again. Another issue appeared. I repeated the process until the automation finally worked. The moment it worked, something changed in the way I viewed coding. I did not suddenly become a programmer, but I had created something useful. A task that previously required several manual steps could now happen automatically. I became curious about what else I could build. I started experimenting with confirmation emails, timestamps, form submissions, missing-data checks, and automatic reports. Each project introduced me to a

It started with one simple question: Why am I still doing this manually? I was working on a spreadsheet, checking information row by row, sending emails, and updating statuses. The process was not difficult, but it was repetitive. One small mistake could mean sending incorrect information, overlooking a request, or forgetting to update a row. I knew there had to be an easier way. I wanted the spreadsheet to detect when a status changed to Sent , find the email address in the same row, send the correct message, and add a timestamp after the email was sent. The idea sounded simple in my head. The problem was that I did not know how to build it. I was still learning how to code, so I asked AI for help. My first prompt was something like: Create a script that sends an email from Google Sheets. AI immediately generated a script. It looked impressive, but it did not work the way I expected. The script checked the wrong column, used information from the wrong cells, and failed when some required details were missing. That was when I realized the problem was not only the code. My instructions were too vague. I tried again, but this time I described the entire process: When the status in Column G changes to "Sent," get the email address from Column E and send a confirmation email. After the email is sent successfully, add a timestamp to Column H. Do not send the email if any required information is missing. The result was much closer to what I needed. When I changed the status to Sent and received the email automatically, I felt genuinely excited. It was only a small automation, but it removed several manual steps from the process. After building that first workflow, I started noticing repetitive tasks everywhere. A form submission could automatically send a confirmation email. A spreadsheet could detect missing information before processing a request. A completed action could record the date and time. Reports could be organized without manually copying every row. Tasks that

Are you tired of wrestling with raw cURL requests, parsing Server-Sent Events (SSE) by hand, and building complex polling loops just to interact with trading APIs? If you are a PHP developer or a Laravel enthusiast looking to dive into algorithmic trading, your life is about to get a whole lot easier. Meet coinquant-php , the official PHP and Laravel SDK for the CoinQuant Public API. CoinQuant is revolutionizing the way we approach algorithmic trading. It takes a trading idea described in plain English and turns it into a backtestable strategy using advanced AI. However, integrating such powerful tools into your own applications can often be a daunting task. That is where coinquant-php steps in. This robust SDK wraps the public API, providing a seamless, developer-friendly experience that lets you focus on what really matters: building profitable trading strategies. In this comprehensive guide, we will explore why coinquant-php is a game-changer for PHP developers, delve into its standout features, and show you how to get started in minutes. Why Choose CoinQuant PHP? The landscape of algorithmic trading is often dominated by Python, but PHP remains a powerhouse for web development, especially with frameworks like Laravel. coinquant-php bridges the gap, allowing PHP developers to leverage the cutting-edge AI capabilities of CoinQuant without leaving their preferred ecosystem. 1. Built for Modern PHP The library is designed for the modern era of PHP. It requires PHP 8.1+ and embraces strict typing, ensuring your code is robust and free from legacy baggage. Whether you are building a standalone script or a complex enterprise application, the SDK provides a solid foundation. 2. First-Class Laravel Integration If you are using Laravel 10, 11, 12, or 13, you are in for a treat. The package auto-registers its ServiceProvider and Facade , meaning there is absolutely zero manual wiring required. You can simply install the package and start using the CoinQuant facade anywhere

The bug reports all sounded the same. "It disconnected again." No error, no warning, nothing on screen to explain it. Someone would open a GitHub issue, start a planning-poker vote, then stop to actually read the thing they were estimating. Thirty seconds later they'd look back and the room had quietly gone still. Other people's votes weren't showing up, and their own weren't reaching the room. It had simply stopped, without a word. If you've ever built anything real on Chrome's Manifest V3, you can probably guess where this is going. The socket didn't drop because the network hiccupped. It dropped because Chrome reached over and killed the process it was living in. This is the story of that bug, and what it actually takes to keep a WebSocket alive inside a Manifest V3 extension. TL;DR: Manifest V3 runs your background code in a service worker that Chrome terminates after ~30s idle. If your WebSocket lives there, it dies with it, silently. The fix is three parts: a heartbeat so extension activity keeps the worker awake, auto-reconnect that pulls a fresh snapshot so drops are invisible, and a try/catch around every port message because the worker can die between your null-check and the call. Why the socket doesn't live where you'd expect First, some context on how the extension is wired, because it explains why this bug was even possible. It puts a button on GitHub issues and boards. Click it, and a live planning-poker room opens right there in the page. Votes flow over a WebSocket to a Cloudflare Durable Object that owns the room's state. Standard real-time stuff. The obvious place to open that socket is the content script, the code injected into the GitHub page. That's where the UI lives, so why not open the socket right next to it? Firefox is why not. A content script runs in the page's world, which means it inherits the page's Content Security Policy. GitHub ships a strict connect-src , and Firefox enforces it against content scripts. Try to open wss://… from the

I built this with Claude cause I always wanted to tinker with a simulation economoy and I love space themes. A space-economy sim where nothing is scripted. A few hundred autonomous ships each run their own planner. Some chase the best trade route, take a delivery contract, refuel, retrofit at a shipyard, or dock so the crew can rest before morale tanks. Markets price everything off supply with shortage-urgency multipliers, factions tax and subsidize, populations migrate when they're unhappy, and

An app called ToneAdapt is pulling in roughly $25K/month, five months after launch, built by one person with no funding and no team. It solves one narrow problem: guitarists want to sound like their favorite recordings, but tutorials and gear reviews rarely match what's actually sitting in their room. Input your guitar, amp, and pedals, pick a song, and it spits out the exact settings to get there. It's not a big, category-defining idea. It's a small, sharp one, solved well, and marketed relentlessly. That combination is worth breaking down. The Numbers The founder shared these publicly: combined web and mobile revenue is running around $25K/month, split roughly evenly between a Stripe-powered website and a mobile app on RevenueCat. Mobile has under 400 active subscribers. Pricing is aggressive for a mobile app, $10/week, or about $60/year, which works because it's solving a moment of real frustration rather than sitting as a passive subscription people forget about. Worth noting: these numbers come from a founder interview, so treat them as a snapshot of where the business was at that point rather than a live dashboard. The shape of the story, fast growth on a narrow niche with aggressive pricing, is the part worth paying attention to. Marketing: Almost Entirely UGC The founder posted three times a day across Instagram, TikTok, YouTube, and Facebook. Most of it didn't land. Once a specific format started converting, he stopped experimenting and went all-in, bringing in UGC creators and running paid ads on top of the format that already worked. That's the actual playbook: post relentlessly, watch for the one format that converts, then stop spreading effort thin and pour it all into what's already working. The Pattern Behind It The reason this works isn't guitar tone specifically. It's a translation problem: someone sees a result they want, but the instructions that got that result assume gear they don't have. The gap between "here's what worked for them" and "here's