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

标签:#Product

找到 2493 篇相关文章

AI 资讯

Stop your coding agent from cat-ing .env: a Claude Code hooks cookbook

Your coding agent is a process that reads your filesystem and runs shell commands with your credentials. Most of the time that is exactly what you want. Occasionally it is cat .env while debugging - and now your production keys live in a transcript forever - or a confident rm -rf on a path that resolved differently than expected. Everyone's first fix is to add rules to CLAUDE.md: "never read .env, never force push". Those are suggestions to a language model. They work until they don't, and you will not be watching when they don't. Claude Code has a mechanism that is not a suggestion: hooks. A hook is a program you register for specific events - before a tool call, after it, when the session tries to end. It runs outside the model, sees the exact tool call as JSON on stdin, and its verdict is enforced by the harness itself. The model cannot talk its way past it, but it CAN read a structured denial and route around it productively. This is a cookbook for writing them. Everything below is plain Python stdlib and works on current Claude Code as of August 2026. The mechanics in ninety seconds Hooks are registered in settings ( .claude/settings.json in a project, ~/.claude/settings.json globally): { "hooks" : { "PreToolUse" : [ { "matcher" : "Read|Grep|Bash" , "hooks" : [ { "type" : "command" , "command" : "python3 \" ${CLAUDE_PROJECT_DIR}/.claude/hooks/secret-guard.py \" " , "timeout" : 10 } ] } ] } } The matcher filters by tool name. Your command receives a JSON object on stdin describing the event; for PreToolUse it includes tool_name and tool_input (the exact arguments about to run). You respond on stdout with JSON. Three responses cover almost everything: Deny a tool call, with a reason the model will read: { "hookSpecificOutput" : { "hookEventName" : "PreToolUse" , "permissionDecision" : "deny" , "permissionDecisionReason" : "why, and what to do instead" } } Block a session from ending (Stop event), sending work back: { "decision" : "block" , "reason" : "lint failed

2026-08-11 原文 →
AI 资讯

phi – the 12 MB alternative to Pi: no Ts, any model, hashline edit

Hi everyone I’ve been hacking on a terminal coding agent called phi https://github.com/pulseaiclub/phi for the past few months, and I’d love to share what it is and why it exists. If you’ve used tools like Pi, Claude Code, Aider, or Goose, phi tries to hit the same workflow—but deliberately strips away the runtime baggage. It’s a single Go binary, ~12 MB, with no Node, Electron, or Python in sight. Here’s what makes it tick: No model lock-in This is the whole reason phi exists. Model releases are moving faster than any agent maintainer can keep up with. Instead of chasing every new provider, phi tr eats the model as a pluggable config: anything OpenAI-compatible or Anthropic-native works out of the box. You can swap models in seconds without waiting for a n author to add support. Config is a single YAML file, and there’s also a tiny HTML editor so you can point-and-click your way through ~/.phi/config.yaml. As light as it gets Go is the secret sauce here. A stripped release build (CGO_ENABLED=0) comes in at ~12 MB, cold idle RSS around ~21 MB, and a first frame in roughly 40 ms. Ther e are only 6 direct module dependencies. If you want a coding agent you can go build in half a second and read in an afternoon, this is it. A permission gate that actually matters One thing that always makes me nervous with coding agents is the "model deletes your files" moment. Phi defaults to read-only: the agent can scan your codebase , but writes and shell commands require explicit approval. The approval dialog gives you three choices—allow, deny with feedback, or allow everything for the r est of the session. Rules are granular: • bash.allow → go test ./... is fine. • bash.deny → rm -rf * is blocked. • fetch.allowed_hosts → restrict which domains the agent can reach. Sub-agents that don’t bloat your context One big agent is fine for small tasks, but long-running work pollutes the context window with noise. Phi ships a full set of sub-agent tools (agent_spawn, agen t_task, agent_wai

2026-08-11 原文 →
AI 资讯

Ski - A voice for your coding agent

You know the moment. You've handed Claude Code (or Codex, or Cursor, or whatever you're driving today) a real task , not "fix this typo," but "refactor the auth middleware and update the tests." It goes off and works. Even if you've turned off the "ask before edit" prompts and let it run end to end without interruptions, you still want to check in to see what it actually did, watch it reason through a tricky part, catch something before it goes further than you meant. That can take minutes. And in those minutes, you're either sitting there watching a terminal scroll, or you wander off and genuinely forget to come back and check. Nobody was watching. That's the whole problem in one sentence: coding agents got capable enough to work unattended for real stretches of time, but the interface is still "stare at a terminal or forget about it." So, what is SKI SKI is a free desktop app that gives your coding agent a voice - in both directions. You talk to Claude Code, Codex, Cursor, Gemini CLI, and a growing list of other agents by speaking instead of typing. And this is the part that actually changes the workflow - you hear them reply out loud. When the agent finishes a task or hits a decision point, it says so: "Tests pass, want me to ship it?" You don't have to be staring at the terminal to catch that. You can be in another window, another room, or heads-down on a different project entirely. It lives as a small ambient widget on your desktop - a floating pill, or, if you're on a MacBook, a notch bar docked right under the camera housing , you hold a key to talk, and everything - speech-to-text and text-to-speech both runs locally on your machine. Why "voice for coding agents" and not just "voice dictation" This distinction actually matters, and it's the one thing I'd want you to walk away with if you read nothing else. Dictation tools have existed for a while, and good ones too, they turn your speech into text and drop it wherever your cursor is. That's genuinely useful,

2026-08-11 原文 →
开发者

Why a live payment is not a release test

Why a live payment is not a release test The riskiest way to test a SaaS checkout is to make a real payment to yourself. It feels reassuring: the live checkout opened, the card worked, the webhook fired and the refund came back. But that proof mixes engineering QA with revenue evidence. Three different proofs A cleaner billing release process separates three questions: Does billing behave correctly? Test payment, refund, webhook and subscription edge cases in a Stripe sandbox. Is production configured correctly? Verify the live price, currency, checkout destination, webhook configuration and deployed revision without moving money. Did a customer pay? Treat a genuine live transaction as customer activity and revenue evidence, not as an engineering fixture. Stripe documents sandboxes as isolated testing environments and separates sandbox credentials from live credentials. The practical lesson is broader than Stripe: operational proof and commercial proof should not share the same transaction. A useful boundary Use this sequence: Sandbox QA → read-only production verification → genuine customer payment . It keeps release evidence, reconciliation and revenue numbers easier to interpret. We recently tightened the same boundary in VendorOS. That does not prove live customer revenue; it is a workflow lesson about keeping evidence categories separate. If your release process still requires a live self-payment, ask which part of the verification can become read-only. Sources: Stripe Sandboxes Stripe API keys Stripe testing VendorOS release boundary

2026-08-11 原文 →
AI 资讯

What AI Coding Tools Are Actually Changing About Technical Interviews

A few years ago, a technical interview mostly tested one thing: can you write correct code, from memory, under pressure. That bar has quietly shifted — and a lot of developers preparing for interviews right now haven't fully clocked it. AI coding assistants are part of daily work at most companies now, from big IT services firms to small product teams. Interview panels have adjusted to that reality faster than most prep guides have. What's actually different now Interviewers care less about whether you can produce a function from scratch, and more about whether you understand what code is doing and why. It's increasingly common to be handed a piece of AI-generated code and asked to find the bug, justify a design decision, or optimize it — instead of writing something from zero on a whiteboard. Some companies go further and let you use AI tools during the technical round, then evaluate how well you direct the tool, verify its output, and catch its mistakes. The skill being tested has moved from "can you write code" to "can you reason clearly with code as your material." Three things I keep seeing candidates get wrong Treating a finished course or degree as the finish line. Completing a syllabus tells an employer you were exposed to concepts. It doesn't tell them you can apply those concepts to a messy, real-world problem — which is exactly what open-ended interview scenarios are designed to expose. Leaning on AI tools without understanding the output. Using an AI assistant while practicing at home is fine. The problem shows up when that habit surfaces in a live interview as an inability to explain your own solution. If you can't walk through why a piece of code works, a couple of follow-up questions will make that obvious fast. Underrating communication and debugging skills. As AI tools take on more initial code-writing, the human value shifts toward reviewing, debugging, and explaining decisions to teammates. Candidates who only practiced writing code — and never pr

2026-08-11 原文 →
AI 资讯

Dev log #16 Typographic Hierarchy and the Great Obsidian Purge

Spent the week redesigning my portfolio’s blog layout and nuking thousands of stale notes in my Obsidian vault. Between the UI polish and some deep dives into libp2p DHT de-flaking, I pushed 36 commits and managed to delete almost 16,000 lines of clutter. TL;DR I’ve always believed that your digital space needs a good pruning every now and then to stay healthy. This week was the embodiment of that philosophy. I pushed 36 commits across four primary projects, resulting in over 23,000 additions and nearly 16,000 deletions. Most of that churn came from a massive redesign of my portfolio's blog and a long-overdue "fresh start" for my Obsidian vault. On the open-source side, I spent some quality time in the weeds of py-libp2p , chasing down flaky DHT tests and proposing better subnet diversity limits. What I Built Portfolio Redesign: The Typography Pivot My main focus this week was my portfolio. I’ve been feeling like the blog layout was getting a bit cluttered, so I opened and merged PR #15, which was all about "typographic hierarchy instead of decoration." I’m moving away from unnecessary borders and boxes and letting the type do the heavy lifting. I spent a lot of time in components/blog and app/blog refining the layout. I implemented borderless filter pills and full-width rows to give the content more room to breathe. One of the bigger technical shifts was moving the blog list to be fully server-rendered. It feels snappier, and it allowed me to implement more "honest" dates and better hover states on the rows. I also added a real focus ring for accessibility (because we’ve all been frustrated by keyboard navigation that feels like a guessing game). By the time I was done, I’d touched over 200 files in that repo alone. The Obsidian Purge I also took a metaphorical chainsaw to my obsidian-vault . I nuked nearly 10,000 lines of stale content. I removed entire directories for "Projects," "Rust," and "Backend" notes that were just gathering digital dust. It’s easy to let

2026-08-11 原文 →