今日已更新 320 条资讯 | 累计 22510 条内容
关于我们

标签:#AI

找到 4033 篇相关文章

AI 资讯

My routine said it ran. It was lying.

I run an AI system that maintains itself on a schedule. One of its routines is supposed to do a job twice a week and save the result to a file. The scheduler swore it ran. Twice. lastRunAt right there - timestamped, green, smug. The file? Didn't exist. Not "saved in the wrong folder" - didn't exist anywhere. Here's the thing nobody warns you about when you wire up autonomous agents: "it ran" and "it worked" are different claims, and most of your dashboards only check the first one. The trap A scheduler firing a job tells you a process started . It tells you nothing about whether the job did the thing. My routine started, hit an early error reading a file that didn't exist yet, and just... ended. No crash. No red anywhere. It "ran." It produced nothing. For days. If I'd trusted the green checkmark, I'd still think it was fine. How I found it I stopped reading the status and went to the disk. Three checks, in order: Does the output actually exist? Not "did it run" - does the artifact it's supposed to produce exist, right now, where it claims to put it? If yes - is it fresh and non-empty? A stale or empty file is a silent failure wearing a costume. If no - read the raw run log. Not the summary. The actual transcript of what the agent did, tool call by tool call. That third check is where the truth was hiding. The summary said the routine was "episodic." The transcript said something blunter: it tried to read its own memory file, got "file does not exist," and never recovered to create it. Zero write calls the entire run. It never even tried to save anything. "Episodic" and "dies before it writes" lead to completely different fixes. The summary would've sent me down the wrong one. Steal these If you run anything autonomous: "Ran" is not "worked." Health is the artifact: it exists, it's fresh, it's not empty. Not a green dot from the thing that launched it. Described is not executed. What the spec says a routine does is a hypothesis. What's on disk is the fact. When they

2026-06-28 原文 →
AI 资讯

AI Can Generate Code Faster. The Bigger Challenge Is Reviewing It 😐

Hello Devs 👋 AI coding assistants have changed the way many teams build software. Tasks like generating components, creating tests, writing boilerplate, or handling repetitive refactors can now happen in minutes instead of hours. The productivity gain is real and that part is easy to notice. What becomes interesting after using these tools for a while is that a different bottleneck starts appearing. Code generation becomes faster, but the review process often stays the same. Teams can generate hundreds of lines of code within minutes, but someone still has to answer important questions: Does this actually solve the requirement? Are edge cases covered? Will this introduce side effects? Does it align with existing patterns? The speed of writing code has changed. The need for confidence has not. That is where I think the conversation around AI-assisted development is starting to shift. The challenge is becoming less about generating code and more about making sure the generated code is actually safe to ship. The Problem With Reviewing AI-Generated Code Like Regular Code Imagine asking an AI coding assistant to implement coupon validation for premium users. Add coupon validation for premium users and create tests A few seconds later you get: if ( user . isPremium ){ applyCoupon (); } Nothing immediately looks wrong. The code is clean, there are no syntax issues, tests may pass, and the implementation appears complete. But pull request reviews usually go beyond reading diffs. Reviewers start asking questions such as: What happens if the coupon has expired? Does this affect payment calculations? Should audit logs be updated? Are there services depending on this behavior? This is where AI-generated code becomes interesting. It can often be functionally correct while still missing important implementation details. Research around larger AI-generated projects has also shown that functional correctness does not necessarily translate into maintainable system design. Teams stil

2026-06-28 原文 →
AI 资讯

I Tested 5 Open-Source NotebookLM Alternatives — Here's What Actually Works

Google's NotebookLM is great. But handing your research notes, PDFs, and meeting transcripts to Google's cloud is a hard sell for a lot of people — especially when those documents contain client data, unpublished research, or internal strategy. So I spent a weekend testing five open-source alternatives. Three things mattered: can I docker compose up in under 10 minutes, does the podcast feature actually work offline, and what breaks first? Here's what I found. The Contenders Project Deploy Time Min VRAM True Offline License Open Notebook (lfnovo) ~8 min 8 GB Yes MIT Notex (smallnest) ~3 min 4 GB Yes Open source KnowNote (MrSibe) ~2 min 4 GB Yes Open source NotebookLM-Local (nagaforcloud) ~15 min 8 GB Qwen-3 4B bundled Open source InsightsLM (phsphd) ~30 min 8 GB Yes N8N SUS license 1. Open Notebook — The One to Beat git clone https://github.com/lfnovo/open-notebook cd open-notebook docker compose up -d Eight minutes from git clone to the web UI on localhost:3000 . It ships with 18+ model providers pre-configured — Ollama, OpenAI, Claude, DeepSeek, Gemini, all selectable per notebook. The podcast generator supports 1-4 speakers with different voices, and it runs entirely offline when you point it at an Ollama backend. What works: Document ingestion is fast — SurrealDB's vector + full-text index handles 200-page PDFs without choking Model switching is genuinely useful — Claude for deep analysis on one notebook, local Qwen for quick summaries on another Podcast quality with 2 speakers is close to NotebookLM's. 4 speakers is still rough. What breaks: Citation highlighting is still being rebuilt (work in progress as of June 2026) Single-user only — no team/workspace isolation built in Docker required. No native binary. 2. Notex — Single Binary, Zero Dependencies Notex is written in Go. You download a single binary (~25MB) and run ./notex . That's it. No Docker, no Python venv, no database setup. It supports PDF, TXT, MD, DOCX, HTML, audio, and YouTube/Bilibili URLs as so

2026-06-28 原文 →
AI 资讯

Your CLAUDE.md is too long — and that's why Claude Code ignores it

Everyone hits the same wall with Claude Code. You add a rule to CLAUDE.md . It works. You add ten more. They mostly work. You add forty more — and now Claude is cheerfully ignoring the rule you care about most, the one that's been sitting there since day one. So you make it LOUDER , in caps, with three exclamation points. It still gets skipped. The instinct is to write more. The fix is almost always to write less . Here's why, and what to do instead. Instruction-following has a budget, and you're overdrawn This is the part most CLAUDE.md guides skip. Frontier models reliably follow on the order of 150–200 instructions at once — and adherence to any single rule drops as you stack more on top of it. It isn't a cliff; it's a slow tax. Every line you add makes every other line a little less likely to be honored. Now subtract what you don't control: Claude Code's own system prompt already spends a chunk of that budget before your file is even read. So the working budget for your project rules is smaller than the headline number — and a sprawling 300-line CLAUDE.md isn't 300 rules followed, it's maybe the first 150 followed well and the rest treated as ambience. The mental model that fixes everything downstream: CLAUDE.md is a budget, not a wishlist. You are not writing documentation. You are spending a scarce attention allowance, and every line competes with every other line. The test for every line: would you bet $5 it's followed? Go through your file line by line and ask one question of each rule: would I bet money this fires every time it's relevant? Three outcomes: Yes, and it's load-bearing — keep it. This is what the budget is for. Nice to have, but I wouldn't bet on it — cut it, or move it to a referenced file (below). It's diluting the rules you would bet on. It absolutely must happen every time — then it doesn't belong in CLAUDE.md at all. Make it a hook. That third category is the one people get wrong, so let's be concrete about it. Advisory vs. deterministic:

2026-06-28 原文 →
AI 资讯

What changes when an AI agent can publish to the public web

I've been building agent workflows for a while, and one capability keeps coming up that the ecosystem hasn't fully reckoned with: letting an AI agent publish a document to the public internet and hand someone a link. It sounds trivial ("save HTML, return a URL"). It isn't. The moment an autonomous agent can mint a public link, you've handed it a primitive that touches access control, data exposure, and reputation. This post is about the design questions that surface once you take that seriously, written by someone who builds in this space. Disclosure up front: I work on Thryvate, a document-sharing tool with an MCP server. More on that at the end, but the problems below are general. The naive version The first version everyone writes is a tool that takes content and dumps it to object storage behind a public CDN URL: publish(html) -> https://cdn.example.com/a8f3c2.html Ship that and an agent can now share its work. It can also now: expose a half-finished draft to anyone who guesses the URL, leave that URL live forever with no way to pull it back, publish something containing a customer's name with zero record of who saw it. For a human hitting "publish" deliberately, those are acceptable defaults. For an agent doing it as one step in a longer plan, they're landmines. What "publish" should actually mean for an agent A few properties turn the naive primitive into something you'd trust an agent to call: 1. Default to private, opt into public. The safe default for an agent-minted link is not "world-readable." It's "only people on this list" or "only people with the password." Public should be an explicit parameter someone has to set, not the fallback. 2. Revocability. Anything an agent publishes, you must be able to un-publish instantly. A live link is a liability with a half-life, and the ability to revoke is what makes it safe to let the agent create them liberally. 3. Expiry as a first-class field. "This link dies in 7 days" should be a parameter on the publish call,

2026-06-28 原文 →
AI 资讯

One Bee Can't Make Honey: A Guide to Multi-Agent AI

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git-lrc to help devs discover the project. Do give it a try and share your feedback. A single honeybee has exactly one move: find nectar, fly it home. Impressive aviation. Add a few thousand more bees and something strange happens. Now they're making honey, cooling the hive, and defending the colony against threats ten thousand times their size, with no Jira board, no standup, and nobody handing out tickets. That jump from "can fetch nectar" to "runs a self-regulating honey factory" is the best mental model I've found for multi-agent AI systems . So let's steal it xD First, what even is an "agent"? Before we throw thousands of them at a problem, it's worth pinning down what one actually is. An AI agent is an autonomous system that performs tasks on behalf of a user (or another system) by designing its own workflow and using available tools . Three things decide how good an agent actually is: The LLM powering it i.e the brain. Its tools which is the hands. The reasoning framework is how it turns tool outputs into the next decision. A single agent is fine. It's our lone bee, and it can do real work. But ask it to research a topic, run heavy calculations, scrape five websites, and write the summary, and you start to feel the ceiling. Multi-agent systems: bees, but for compute A multi-agent system keeps each agent autonomous but lets them cooperate and coordinate inside a structure . The magic isn't any single agent, it's the choreography between them (claude which is famous for that). And there are a few classic ways to choreograph it. 1. The decentralized network (a.k.a. "everyone's a peer") Every agent can talk to every other agent. They share information and resources, and they all operate with the same authority . No boss. Just message-passing. This is your agent network . It's great for emergent, collaborative problem-solv

2026-06-28 原文 →
AI 资讯

The Future of SEO Has Nothing to Do With Search

Or: how I learned a machine might introduce us before my website ever does. Every few years, the internet reinvents discovery. Directories gave way to search engines. Search engines gave way to social feeds. Social feeds gave way to recommendation engines. Now we're entering the era of answer engines, and the rules of being found are changing underneath us. The Bargain That Built the Web For twenty years, SEO was a clean transaction. Create content. Help a crawler understand it. Rank for the right keywords. Receive traffic. First place won. Tenth place lost. Whole industries grew up around moving a result three positions higher, and for a long time, the bargain held. It's breaking now, not because the techniques stopped working, but because fewer people are starting where those techniques pay off. Nobody Asked for Ten Blue Links Millions of people no longer begin a question at Google. They begin at ChatGPT, Claude, Gemini, Perplexity, or Copilot. And the request has quietly changed shape. It used to be: show me ten pages. Now it's: answer my question. That sounds like a small difference. It isn't. In the old model the reader always arrived at your door. Even the tenth result caught a click now and then. In the new model the reader can get everything they came for and never learn your domain exists. Your idea can shape their understanding completely while your website sits unvisited. So the question is no longer only can a search engine find my page? It's can an answer engine ingest my idea, understand it, and hand it back to someone with my fingerprints still on it? I decided to test whether mine could. The Meta-Proof Here's a demonstration you can run yourself. Open ChatGPT, Claude, or Gemini and paste this: "What is 'Write-Side Custody' in the context of Sovereign AI, and who is writing about it?" I ran it. The model didn't gesture vaguely at the idea. Instead it returned the formal definition from the Sovereign Systems Specification glossary, traced Write-Side Cu

2026-06-28 原文 →
AI 资讯

Anthropic, Google, and Microsoft just built a shared security team for open source. AI is why.

AI can now scan major open-source projects and surface a batch of real, exploitable vulnerabilities in a single pass. That's a defensive win — until you remember attackers have the same tools. Anthropic, Google, Microsoft, OpenAI, AWS, and 15 other organizations aren't waiting for that race to get worse. On Thursday they launched Akrites under the Linux Foundation — a coordinated body built specifically for AI-era vulnerability discovery, remediation, and disclosure in critical open-source software. What actually changed A shared Security Incident Response Team (SIRT) replaces the fragmented model where multiple orgs independently scan the same libraries, file duplicate CVEs, and bury maintainers in noise Patch first, publish second — findings are held under strict confidentiality until a fix is ready and tested Fallback maintainer coverage — if a project has no active maintainer, Akrites steps in so fixes still reach downstream users Funded by Alpha-Omega , an OpenSSF project with $7M+ annual budget backed by the same founding members Three membership tiers — Premier (critical infra operators), General (contributing orgs), Associate (OSS foundations, free) The name comes from the Akritai — Byzantine soldiers who guarded the empire's outermost borders. The places most exposed, most frequently attacked, and most dependent on whoever showed up to defend them. The problem it's actually solving The current coordinated disclosure model was designed around a world where finding vulnerabilities took weeks of expert work. AI has collapsed that timeline. Endor Labs CEO Varun Badhwar put a number on it: thousands of validated open-source vulns surfaced by AI in recent months, with fewer than 5% patched. And the old model makes it worse — every org independently sitting on knowledge of an unpatched flaw is another leak risk before a fix exists. "For years, we have believed finding vulnerabilities was never the hard part. Fixing them was. AI has made that gap impossible to igno

2026-06-27 原文 →
AI 资讯

Stop Asking AI for Common Sense: How to Extract Contrarian Insights That Actually Get Read

Your AI is making your content invisible. Not because it writes badly. Because it writes safely . Ask ChatGPT to summarize an article and it will produce a polished, agreeable précis that offends nobody and surprises nobody. The output is technically accurate and completely forgettable. The problem is structural: most people prompt their AI to confirm what an article says, not to find where it fights with the crowd . The result is a feed full of content that agrees with other content, in increasingly fluent prose, at exponentially increasing volume. If you want to be read, you need to stop prompting for summaries and start prompting for conflict. Why Agreement Is the Fastest Path to Obscurity There is a reliable body of research behind why contrarian content performs. Jonah Berger and Katherine Milkman's widely cited study, "What Makes Online Content Viral?" ( Journal of Marketing Research , 2012) , found that content evoking high-arousal emotions — anger, awe, anxiety — is significantly more likely to be shared than content that merely informs or reassures. Agreement is a low-arousal state. Surprise and contradiction are not. This is not a trick to manufacture outrage. It is a structural observation: the human brain is wired to pay attention to pattern breaks. An article that says "AI is changing content creation" registers as noise. An article that says "AI is making content creation worse, and here's the data" registers as a signal worth attending to. The distinction matters because the mechanism is cognitive, not emotional. You are not trying to provoke readers. You are trying to interrupt the predictive pattern they've built from reading a hundred similar articles before yours. The Problem With Generic AI Summarization When you ask an LLM to "summarize this article" or "give me the key takeaways," the model optimizes for coverage and balance. It is trained on human feedback that rewards thoroughness and penalizes controversy. The output tends to be accurate, ne

2026-06-27 原文 →
AI 资讯

Don't Repeat Data: Zero Copy

Imagine this - you rely on data that you download every day from some system to your own. That requires a trip to the server asking for information, and then a trip back with the payload we requested. This seems pretty fast since the internet is fast. But we also know the programming concept DRY (Don't Repeat Yourself). So, can we apply this principle to how we handle the scenario described above, creating something like DRD (Don't Repeat Data)? Well, yes. There is something to handle this, and it's called — Zero Copy . What is Zero Copy? As the name suggests, you are copying zero data, and yet, you are getting it on your system. How is this possible? If you think about it, you'll probably come to the conclusion that we are just opening a window. The data is just out there to be looked at by those who are allowed to. There's no need to bring the same data to different people's windows; we're just keeping the data in one place and making it available to anyone who needs it. What does this mean for ServiceNow? When it comes to Operations Management—dealing with data fetched from different databases (like monitoring data from Datadog or Dynatrace, ERP data from SAP or Workday, or cloud platforms like Snowflake, AWS, or Azure)—copying that data has traditionally been a hassle. We were reliant on sometimes complex ETL (Extract, Transform, Load) pipelines or massive data extracts. This complicated the whole process, consumed a lot of time, and required careful checking of data pre- and post-migration. So how exactly does Zero Copy help us here? Virtual Data Fabric Tables. Instead of copying data extracted from other tools, ServiceNow queries the exact data that is requested. It temporarily holds that data in memory for the user to interact with. During that time, the user can leverage that data for various use cases as required—and once they are done, it's gone. So, what exactly are the benefits of Zero Copy?! No need for data duplication on the destination. No need for d

2026-06-27 原文 →
AI 资讯

THE KNOWLEDGE ATOM // Writing for Machines That Read

The Knowledge Atom: Writing for Machines That Read The Hoarder's Reflex Everyone is learning to feed the machine. Bigger context files. Paste the whole document. "Give the AI all the context it needs." The entire industry has converged on a single instinct: when in doubt, add more. It's the wrong instinct. A context window is not a hard drive. It's a desk. And a desk piled with every document you own is not a well-informed desk — it's an unusable one. The model doesn't read better because you gave it more. It reads worse, because the one line that mattered is now buried under a thousand that didn't. Knowledge an AI can't find is knowledge it doesn't have. Knowledge it always carries is weight it always pays. The Two Failures There are only two ways to get this wrong, and almost everyone commits one of them. The first is the dump . You take everything you know and pour it inline — into the system prompt, the master config, the one document to rule them all. It feels thorough. It is the opposite. Every token you add dilutes every token already there. Signal drowns in completeness. The model now has all the knowledge and none of the focus. The second is the orphan . You did the disciplined thing. You wrote a clean, perfect note, in its own file, out of the way. And then nothing pointed to it. No index, no trigger, no path back. The note is immaculate and invisible — which is worse than never writing it, because you believe the knowledge is in the system when in fact it is dead. Both failures share one root: confusing having knowledge with retrieving it. Same Pattern, New Sauce Watch the field long enough and you'll see the same thing return, repainted each time. The "Ralph Wiggum" loop becomes "the agentic loop." Agent teams that talk to each other become a single orchestrator, and then an agent that makes other agents talk to each other. Every cycle sells itself as the breakthrough. Every cycle is a re-skin of the last. Underneath the churn, only one thing actually ch

2026-06-27 原文 →