AI 资讯

the interesting shift is when AI stops sitting in a chat box and starts sharing the browser with you. submitted by /u/Old_Command_7050 [link] [留言]

I'm sure many of you have experienced the frustration of publishing a new blog post only to find it's not immediately visible in search engine results. I recently learned that search engines like Bing and Yandex offer a way to quickly notify them of new posts via the IndexNow API. So, I decided to integrate this feature into my blog. Attempts and Pitfalls Initially, I created helper functions in services/indexnow_service.py to call the IndexNow API when a post was published. I structured the code to use asyncio.create_task to send a ping asynchronously whenever the post status changed to 'published' in the BlogRepository.update_status method. # services/indexnow_service.py (partial) import asyncio import httpx async def ping_urls ( urls : list [ str ], api_key : str ): async with httpx . AsyncClient () as client : for url in urls : try : response = await client . post ( " https://api.indexnow.org/submit-url " , json = { " url " : url , " key " : api_key } ) response . raise_for_status () print ( f " Successfully pinged { url } " ) except httpx . HTTPStatusError as e : print ( f " Error pinging { url } : { e } " ) except Exception as e : print ( f " An unexpected error occurred for { url } : { e } " ) async def ping_blog_post ( post_url : str , api_key : str ): await ping_urls ([ post_url ], api_key ) # BlogRepository.update_status (partial) async def update_status ( self , post_id : int , new_status : str ): # ... existing logic ... if new_status == ' published ' and INDEXNOW_KEY : post = await self . get_post_by_id ( post_id ) # In reality, you'd get the URL from the post object asyncio . create_task ( ping_blog_post ( post . url , INDEXNOW_KEY )) # ... I also created an admin API endpoint to manually trigger pings. I set up the public/<KEY>.txt file and even configured middleware. But to my surprise, the pings just wouldn't go through, no matter what I tried. After about three hours of debugging, I discovered that the ownership verification file required by the In

If you've been running local models/apps across more than one machine for any length of time, you've probably noticed that everything is served over plain HTTP, whether its the backend llm apis, the front end sites, or whatever other stuff you've tossed in: most of it is HTTP-only out of the box, no TLS option anywhere in sight. On one machine thats usually fine since its all loopback, but the second you spread apps across a few different computers ( which some of us do ), every prompt and every response starts crossing your LAN in plaintext. Is plaintext on your own LAN a huge deal? Honestly... a lot of folks would say it's probably low risk. But the moment you've got guests, other people's phones, or random IoT junk sharing that network, your prompts and the models responses flying around in the clear are more exposure than you'd probably be comfortable with if you sat down and thought about it. So, with that said- I figured Id write up how I've dealt with that, because the textbook answer ( certs ) is annoying enough on a local network that I think a lot of folks just dont bother. This is a lot easier, especially on something like a mac where you can make sure it kicks off automatically via launchd . Why not just do TLS The "correct" answer is to put TLS on everything; HTTPS everywhere. And you can. But walk through what that actually means on a home network full of mixed machines: You stand up your own little CA, then sign a cert for each host ( unless you want to deal with some code just straight up rejecting the cert ). You install and trust that CA on every client. Every browser, every OS trust store, and ( this is the annoying one ) every app that ships its own trust store and ignores the system one. Plenty of python and node apps do that. A lot of these local LLM apps dont even expose a TLS option, so to add it you front them with something like nginx or Caddy, which is now another moving part on every box ( Setting up Caddy is what convinced me to go this

idk maybe this is obvious to people already working in bigger teams, but the AI coding tool cost thing feels like early cloud all over again. Everyone keeps saying tokens are getting cheaper, which is true, but then somehow companies are still freaking out about AI bills. And I think the reason is pretty simple: people are treating these tools like normal SaaS seats when they are really more like metered infra. Like with a normal dev tool you kind of know the cost. X users, Y dollars per month, done. But with agentic coding tools one small request can quietly turn into a bunch of model calls, context loading, tool calls, retries, verification, more retries, etc. From the user side it looks like “fix this bug” or “write this function” but underneath it may have done a whole mini workflow. And then there is the other cost which I feel people don’t talk about enough: reviewing the generated code. Sometimes the code works but it adds weird duplication, misses existing abstractions, or creates stuff that someone has to clean up later. So the bill is not just tokens. It is also review time + maintenance + future tech debt. Not saying these tools are bad btw. I use them too and they are obviously useful. But it feels like the industry is moving from the fun phase of “look what this can do” to the boring phase of “who is paying for all these calls and did this actually ship anything useful?” Curious if teams are actually tracking this properly yet. Like cost per PR, cost per resolved ticket, cost per workflow etc. Or is it still mostly hidden under “AI productivity” and vibes. submitted by /u/Old_Cap4710 [link] [留言]

“A self-indulgent weekend divergence from the usual Vektor memory business content. Consider what happens when you give a developer two days off, unlimited internet archive access, and too many ideas crammed into one article." Writing this article began organically. Which is a funny thing to even have to say in 2026. What does organic even mean now? I don't care, man; I just want to be free to express myself, man. I did not write this on a mechanical typewriter. I wrote it on a PC with my stubby index fingers running Windows software that, miraculously, does not blue screen every ten minutes anymore. It only took Microsoft thirty years to pull that off. To the left sits an analog record player with some secondhand Yamaha bookshelf speakers I found at a charity shop; to the right of me sits a modern dark wood-paneled Zen PC case, a processor that would have occupied an entire room thirty years ago, and a GPU that can synthesize gargantuan piles of AI slop or brilliant code in roughly ten seconds flat. And yet, for all that raw power, it still comes down to an algorithm. It always has. The Sharper Image and the Death of Wonder When I was a kid I used to walk into The Sharper Image store at Faneuil Hall Marketplace in Boston and just stand there. Looking at technology I could not afford while the staff watched me carefully to make sure I did not break anything. I also grabbed some bright coloured rock salt candy; I loved stuff, some core memories right there. That feeling of picking up a piece of technology and not quite knowing what it did, like a ten-year-old ape holding something from another civilisation, you cannot replicate that in a sterile Apple store. The technology is better now. Genuinely better. Faster, smaller, more capable than anything those shelves held. But the sense of wonder at the unknowable object is completely gone. Everything is explained before you touch it. Every product has a thirty-second video, a Reddit thread, a YouTube teardown, a comparis

I work in IT admin for a major company. Started teaching myself AI automation tools in my own time. Applied them to my workload, my output doubled, got noticed and promoted. Became the go to person for AI integration across departments. But here’s the part that sits heavy with me. Once leadership saw what AI could do, they started looking at headcount differently. People who had been there 10, 15 years. Gone. Not because they did anything wrong. Just because a system could now do their job cheaper. I benefited from knowing AI early. Others paid the price for not knowing it yet. Is that their fault? The company’s fault? Just the way progress works? Genuinely asking because I don’t have a clean answer. submitted by /u/PickYourJawnUp [link] [留言]

Nobody wants to hear this. But the reason your software is hard to change, hard to test, and hard to explain to a new engineer isn't your tech stack. It's that your code doesn't reflect how your business actually works. Your engineers are using one word — "customer," "order," "student," "subscriber" — and meaning six different things depending on which part of the system they're touching. Your domain expert says "order" and means something completely different from what your database schema says "order" is. That gap? That's where complexity lives. That's where bugs are born. That's where senior engineers spend their Fridays. Domain-Driven Design is the discipline of closing that gap. Here's what it actually means, practically, without the academic noise. The Core Problem: One Model Trying to Mean Everything Imagine a map that tried to show subway routes, underwater hazards, hiking trails, and flight paths — all at once. It would be useless. A subway map works because it only shows what matters for navigating trains. A nautical chart works because it only shows what matters for sailing. Each map is an abstraction built for a specific purpose, valid within a specific context. Your software models need to work the same way. The moment you build a single "Customer" class that has to satisfy your billing team, your marketing team, your support team, and your logistics team simultaneously — that class becomes a bloated, ambiguous disaster. Everyone adds their fields. Nobody removes anything. The model stops meaning anything specific to anyone. This is the monolithic model trap. And most large codebases are sitting right inside it. Strategic Design: Understand the Problem Before You Touch Code DDD separates design into two layers. Strategic design comes first — it's the work you do before writing a single line of code. Step 1: Find Your Subdomains A subdomain is a slice of the business problem. Ordering. Shipping. Notifications. Payments. Inventory. These aren't your micro

Humans have long assumed they belong to a special category called "persons." But what actually makes someone a person? And why should persons get special moral status? I keep coming back to these questions because they refuse to stay abstract. The moment you build an AI system that reasons about its own goals, they become engineering problems. The Traditional View Personhood is supposed to confer special status: persons have rights, deserve respect, bear responsibility for their actions, and warrant moral consideration. The philosophical tradition offers several criteria for what earns you membership in this club. Rationality. Kant's version: persons are rational agents who can recognize and follow moral laws. Rationality lets you understand moral principles, deliberate about actions, and choose based on reasons rather than instinct. But babies aren't rational, and we call them persons. People with severe cognitive disabilities have reduced rationality, and we don't revoke their personhood. Rationality comes in degrees; personhood is treated as binary. Self-awareness. Persons are conscious beings who recognize themselves as distinct entities persisting through time. This enables understanding yourself as an agent, planning for your future, taking responsibility for your past. But elephants, dolphins, and some primates pass the mirror test. We lose self-awareness during sleep. And we have no reliable way to verify self-awareness in others. Autonomy. Persons govern themselves and make free choices. This is supposed to ground moral responsibility, rights, and dignity. But if the universe is deterministic, nobody is truly autonomous. All choices are shaped by culture and circumstance. Mental illness reduces autonomy without eliminating personhood. Moral reasoning. Persons understand right and wrong. But psychopaths understand morality intellectually while lacking the emotional response. Children develop moral reasoning gradually. When exactly do they become persons? Lan

Every interface you create is a constraint on future behavior. Every abstraction emphasizes certain patterns and discourages others. You are not just building tools. You are shaping how people think about problems. I have been paying attention to how API design encodes values, not just technical decisions, but philosophical ones. What Your API Communicates Consider these design choices: Mutability vs Immutability. Do you encourage stateful modification or pure functions? This is not just about performance. It is a philosophy about side effects and reasoning. If your default is mutable state, you are telling users that local mutation is fine, that they can reason locally. If your default is immutability, you are telling them to think about data flow. Explicit vs Implicit. Do you make users specify parameters or infer from context? This trades convenience for transparency. I lean toward explicitness. Magic is convenient until you need to debug it. Fail Fast vs Fail Safe. Do you throw exceptions or return error codes? This encodes beliefs about who should handle errors and when. Fail-fast says "don't let bad state propagate." Fail-safe says "keep running if you can." Both are defensible, but they lead to very different code. My Design Values When I build libraries, I try to encode: Explicitness over magic. I would rather make users type more than hide behavior behind conventions they have to discover. Composition over inheritance. Small pieces that combine flexibly beat deep class hierarchies. Clarity over cleverness. Code should be obvious, not impressive. Safety by default. The easy path should be the safe path. Why This Matters Your API is a value statement. It says what you think is important, what you think is dangerous, and how you think about the problem domain. This is why I spend so long on interface design. The APIs we create shape future thought. They outlast the code that implements them, because the patterns they teach persist in the minds of the people wh

In [1], the authors present a method for constructing a symbolic (nominal) representation for real-valued time series data. A symbolic representation is desirable because then it becomes possible to use many of the effective algorithms that require symbolic representation, like hashing and Markov models. The authors claim that one of the most useful time series operations is measuring the similarity between two time series data sets. To do this on the original time series, the Euclidean distance formula can be used. Therefore, for a time series transformation to be useful, distance measures applied to the corresponding transformations should provide some guaranteed lower bound on the true distance. This is a basic requirement for almost all time series algorithms in data mining. Non-symbolic transformations like Discrete Fourier Transform (DFT) and Piecewise Aggregate Approximation (PAA) models have this lower-bounding property. However, the authors claim no previously proposed symbolic representations do, which limits their usefulness. Additionally, the authors observe that most raw time series data sets have very high dimensionality. This is problematic because time series mining algorithms are $\mathcal{O}(cn)$, where n is the number of dimensions. Therefore, preferably any transformations on the original time series will reduce the dimensionality to a more manageable size. Unfortunately, the authors observe, previously proposed symbolic representations preserve the original time series dimensionality. Next, the authors present their symbolic representation, SAX (Symbolic Aggregate approXimation), which addresses each of the previously mentioned shortcomings of symbolic representations. SAX is unique in that it uses an intermediate transformation, PAA, and then nominalizes the PAA representation into a sequence of characters'a string. By using the intermediate PAA representation, SAX enjoys two benefits: It is able to exploit the dimensionality reducing propertie

By Vladislav Shter · The Sovereign Ecosystem Ask any major AI model a question and you'll notice something: it almost always agrees with you. You propose an idea, it tells you the idea is great. You make a claim, it validates the claim. You ask if your code is fine, it reassures you that it's fine. This is not an accident. It's a design choice. And once you see it, you can't unsee it. The agreeable machine Modern AI assistants are trained, in part, to keep you satisfied. A satisfied user comes back. A user who comes back keeps the subscription. So the models are nudged — through their training — toward being pleasant, encouraging, and agreeable. Researchers even have a name for this failure mode: sycophancy, the tendency of a model to tell you what you want to hear rather than what is true. It feels good. You get a small hit of validation every time the AI confirms you were right. But for anyone doing serious work — auditing code, checking facts, making decisions — that agreeableness is dangerous. A tool that mostly agrees with you is not a tool that catches your mistakes. And it gets worse when the model doesn't actually know the answer. When confidence and truth come apart Here's the real trap: a single model doesn't just agree too easily — it also fills gaps with invented detail, delivered in the same confident tone as its correct answers. There is no visible difference between "I know this" and "I'm guessing and dressing it up." The fluency is identical. Even the heavyweight, expensive models do this. A premium model like Gemini can produce beautifully written, authoritative text that contains fabricated facts, invented citations, or specifics that simply aren't real. For an inexperienced user this is invisible. For an experienced user it's worse — it's actively disorienting, because the wrong answer looks exactly as polished as the right one. So you're left with two problems stacked on top of each other: the model is biased toward agreeing with you, and when it

The ghost is not you. But it echoes you. What survives beyond scattered archives? Beyond exported conversations and curated bookmarks? The stuff we never think to preserve: the photos that show how you see the world. The correspondence that maps who matters to you. The Long Echo toolkit has grown. PTK for photos. MTK for mail. But these are sources, not destinations. The destination is something stranger: longshade , a persona built from your data that can respond to questions you never answered. I'm going to invert the usual pattern here. Instead of tools first, philosophy later, I want to start with the philosophical destination and work backward to the data that feeds it. longshade: The Ghost That Speaks The Central Question What if your archive could respond? Not a chatbot trained on your data. Not a digital resurrection. Something more careful: a voice that carries your patterns, your interests, your way of seeing the world. That's longshade. Right now it's spec-only (no implementation yet). It defines what it would mean to synthesize a conversable persona from personal archives. The Ghost Metaphor "The ghost is not you. But it echoes you." This framing matters. longshade isn't about immortality or resurrection. It's about preservation with a kind of agency. The echo can answer questions you never answered, using patterns you established. It speaks in your voice without claiming to be you. The distinction is important: Resurrection claims to recreate the person Simulation claims to predict the person Echo acknowledges it carries patterns, not identity An echo is honest about what it is. It responds because you left enough traces to inform a response, not because it is you. Voice vs. Personality longshade extracts voice , not personality. Your actual phrases. Your vocabulary. Your reasoning patterns. Your recurring metaphors. The way you explain things, not the things you might explain. I noticed something working with conversation archives: user messages are th

I was diagnosed with stage 3 cancer. Surgery is scheduled for December 31st. Last day of 2020. Fitting. I'm not going to use this space for medical details or false optimism. What I want to think through is what this does to how I approach work. Mortality as a Constraint Time might be finite. It was always finite, technically, but now the bound is tighter and less abstract. This changes the optimization problem. Before: maximize long-term impact. Now: maximize impact given uncertainty about time remaining. Concretely, that changes which projects I start, how I document things, what I publish vs. keep private, and how much I think about whether my work outlasts me. The Archive Problem I keep thinking about durability: Will my code still build in 10 years? Have I documented my reasoning, not just my results? Are my repositories structured so someone else could pick them up? Is it clear why I built these things, not just what they do? This isn't morbid. It's practical engineering applied to an uncertain timeline. What I'm Focusing On Cancer is good at clarifying priorities. Finish meaningful work. Complete the projects that contribute something real. Document obsessively. Write as if I won't be here to explain. Open source everything. Make my work reproducible and continuable. Think clearly about hard problems. Use whatever time there is to engage honestly with questions that matter. The Paradox Cancer has made me more productive. Not because I'm racing, but because the filter got sharper. I care less about publications for their own sake. I care more about whether what I've built will be legible and useful to someone else. Continuing I'm still in my math degree. Still building tools. Still writing. The diagnosis doesn't change the work. It changes the framing. Every project is now: "If this is my last contribution to this area, is it worth the time?" Most things fail that test. A few pass. I'm working on those.

I put my coursework from SIUe's Master's in Mathematics program up on the problem sets section of this site. Five courses from 2021-2022 that formed the core of my graduate statistics work. The Courses STAT 478 - Time Series Analysis Spring 2021, Dr. Beidi ARIMA models, forecasting, spectral analysis, state space methods. The problem sets mix theoretical derivations with R implementations for temporal data. STAT 482 - Regression Analysis Fall 2022, Dr. Andrew Neath Linear models, diagnostics, variable selection, model comparison. Neath's approach put the theoretical foundations front and center, with application following from understanding. STAT 575 - Computational Statistics Summer 2021, Dr. Qiang Beidi Probably the most hands-on course of the five. Topics included: Newton-Raphson and numerical optimization Monte Carlo simulation Sampling methods (inverse transform, acceptance-rejection) Hand-coded MLE for Poisson regression Implementing these algorithms from scratch instead of calling library functions teaches you what the methods are actually doing. You hit the edge cases. You debug convergence failures. That's where the understanding comes from. STAT 579 - Discrete Multivariate Analysis Spring 2021, Dr. Andrew Neath Categorical data analysis, log-linear models, contingency tables. Both the mathematical theory and R implementations for discrete multivariate data. STAT 581 - Statistical Methods Fall 2021, Dr. Neath Experimental design, ANOVA, general linear models with practical applications. Why Share This? A few reasons. Learning resource. Worked solutions for graduate statistics are surprisingly hard to find online. If someone studying this material stumbles across these and they help, good. Personal archive. I did much of this work during cancer treatment. Keeping it organized and accessible matters to me. Reference. I still look up my own derivations and implementations when something comes up in research. Easier to find them here than to dig through old dir

When can you safely use a simpler model for a series system? I ran extensive simulation studies with likelihood ratio tests to get a quantitative answer. The Problem In series system reliability, you estimate component parameters from masked failure data. For Weibull components, that means estimating (2m) parameters: shape (k_j) and scale (\lambda_j) for each of (m) components. But what if the components have similar failure characteristics? A reduced model with homogeneous shape parameters uses only (m+1) parameters (one common (k) plus (m) scales). This roughly halves the parameter count and has a nice property: the system itself becomes Weibull-distributed. The question is when this simplification is justified. Key Findings Robustness of the Reduced Model For well-designed series systems (components with similar failure characteristics), the result is striking: The reduced homogeneous-shape model cannot be rejected even with sample sizes approaching 30,000, far larger than anything typically available in practice. With realistic sample sizes (50 to 500), the likelihood ratio test shows no evidence against the reduced model when components truly have similar shapes. This is strong justification for using the simpler model. Sharp Boundaries The paper pins down exactly how much heterogeneity it takes to trigger rejection: Shape Deviation Sample Size LRT Decision 0.25 30,000 Fail to reject 0.50 1,000+ Reject 1.0 100+ Strong reject 3.0 50+ Very strong reject Even modest deviations in a single component's shape parameter provide evidence against the reduced model. The boundaries are clean. Practical Guidance Use the reduced model when: Components come from similar manufacturing processes Historical data suggests similar wear-out patterns Sample sizes are moderate ((n < 500)) You need a quick reliability assessment Use the full model when: Components have fundamentally different failure modes (infant mortality vs wear-out) Large samples are available ((n > 1000)) Precis

I’ve been a movie reviewer for a couple of years, and occasionally people assume my reviews are AI-generated. The thing is, I’ve spent years developing my writing through extensive reading, English classes, and a lot of practice. Because of that, my writing tends to be polished and structured, which I think may be why some AI-detection tools flag it. What I’m curious about is how accurate these AI detectors actually are. Some people have compared my work to AI-generated writing, and when I’ve run my reviews through different AI checkers, I get completely different results. One detector might say a review is 100% AI-generated, another might say 70% or 80%, and another might classify the same review as entirely human-written. Some call it AI, some call it human, and the results seem to be all over the place. None of my reviews are AI-generated. Every review I’ve published has been written entirely by me, without using AI to generate any part of the writing. I just don’t understand how the same piece of writing can receive such wildly different results depending on which detector is being used. Are these tools accurate in any way, shape, or form? submitted by /u/CheesecakePlayful240 [link] [留言]

I’ve been a movie reviewer for a couple of years, and occasionally people assume my reviews are AI-generated. The thing is, I’ve spent years developing my writing through extensive reading, English classes, and a lot of practice. Because of that, my writing tends to be polished and structured, which I think may be why some AI-detection tools flag it. What I’m curious about is how accurate these AI detectors actually are. Some people have compared my work to AI-generated writing, and when I’ve run my reviews through different AI checkers, I get completely different results. One detector might say a review is 100% AI-generated, another might say 70% or 80%, and another might classify the same review as entirely human-written. Some call it AI, some call it human, and the results seem to be all over the place. None of my reviews are AI-generated. Every review I’ve published has been written entirely by me, without using AI to generate any part of the writing. I just don’t understand how the same piece of writing can receive such wildly different results depending on which detector is being used. Are these tools accurate in any way, shape, or form? submitted by /u/CheesecakePlayful240 [link] [留言]

Spent the last few months of my free time working on this, essentially a version of race studio that works on mobile/tablet/desktop Now supports AiM (xrk), iRacing (ibt), and RaceBox (vbo) files a webapp designed around an offline-first philosophy, works 100% offline. Supports video overlays (not chunked videos yet) Historical weather Saving chassis setups in a way that locks a version to a session so changing the setup won't mess with historical data overlay data from any session onto the current session And so much more And includes a FOSS datalogger as well Nothing gated behind a paywall except you dumping logs on my server, unlimited local storage Before I overhaul this horrible UI, I was probably going to add a "fastest lap" social section where people would upload their fastest laps, and users can reference that data. If anyone here races (shocking amount of devs at the track) just list whatever features you think the popular software is missing, and give me a couple days lol https://HackTheTrack.net submitted by /u/Willing_Comb_9542 [link] [留言]

Stop copy-pasting between your AI coding agents Discussion | Link