现在很多人已经接受 AI 可以改代码，但真正让它进入日常工作流的，不是“它会不会写”，而是“它每次写完之后会不会把仓库搞乱”。这也是为什么我觉得 Claude Code 现在最值得实战看的，不只是改文件能力，而是 hooks 和 subagents 这两个更工程化的点。 前者让你在关键节点自动执行检查和清理动作，后者让你把不同类型任务拆给不同角色。…

过去大家评估 AI 编程工具，最常见的问题是：它能不能生成可用代码？这个问题在今天已经不够用了。到 2026 年，真正拉开差距的标准正在变化：谁能更稳定地接入现有仓库，谁能处理多文件修改，谁能运行测试、处理权限、接入 Git 工作流，谁就更接近真正的生产力工具。 这件事对开发者和独立开发者都很现实。因为“写出一段代码”和“把一个需求交付出去”中间，…

过去一年，大家谈“上下文工程”时，很多人脑子里想的还是另一种提示词技巧：怎么写 system prompt，怎么塞背景，怎么让模型少跑偏。这个方向当然没错，但我越来越觉得，它已经不够了。真正重要的变化是：上下文开始从聊天窗口里的临时文本，变成仓库里的长期资产。这不是一个措辞变化，而是开发工作流正在发生迁移。Google 在 2025 年底介绍 Ge…

这两个月我越来越确定一件事：Agent 赛道真正拉开差距的地方，已经不是“模型会不会写代码”，而是你怎么把模型放进一个能持续工作的执行框架里。很多人到现在还把长任务 Agent 理解成“更长的 Prompt + 更多工具”。这个理解在做 demo 时还能凑合，一旦任务跨文件、跨步骤、跨小时，问题就会立刻暴露：上下文变脏、任务跑偏、自评失真、失败后无…

先给结论：OpenClaw 和 Kiro CLI 很适合搭配，但前提是你别把它理解成“两个 AI 工具叠加一下”。更准确的说法是，OpenClaw 负责做长期在线的入口、路由和自动化壳层，Kiro CLI 负责在具体代码仓库里完成分析、修改和持续会话。一个偏“总控台”，一个偏“落地执行层”。这两个东西分工清楚之后，组合价值才会出来。 这篇文章不讲空…

终端里的 AI 工具这两年不少，但很多产品的问题也很一致：演示看起来很顺手，真正放进开发工作流之后，要么上下文太浅，要么只能当聊天壳子，要么一接入团队规范就开始失真。Kiro CLI 值得写，不是因为它“又一个 AI Coding 工具”，而是它在 CLI 里把几个真正影响长期可用性的能力拼起来了：会话持久化、Steering、Hooks、MCP，…

Anthropic 刚发布 Claude Opus 4.7，官方把重点放在软件工程、长时复杂任务和更好的视觉能力上。很多人看到这类发布，第一反应还是去比参数、比榜单、比“谁更强”。但说实话，到了 2026 年这个阶段，只把模型升级理解成一次性能刷新，已经有点落后了。我认为 Opus 4.7 真正值得看的，不是它把“回答”做得更漂亮，而是它继续强化了…

OpenAI 这几个月对 Codex 的推进，透露出的重点已经不是“把代码写得更快”这么简单了。2 月推出 Codex 桌面应用时，核心卖点是多 agent 并行、长任务协作；到 4 月的新版本，重点又继续往前推：它开始更深地接入开发者日常工具，能看多个文件和终端，能连远端 devbox，甚至把浏览器也拉进同一个工作流。这件事真正值得开发者关注的地…

过去一年，关于“AI 生成代码到底能不能进生产、能不能进开源主干”的讨论，很多时候都被说得太虚。有人把它讲成效率神话，有人把它讲成版权灾难，还有人干脆把问题简化成“能不能用 Copilot”。Linux 内核最近给出的答案，反而是目前我看到最有工程味的一种：可以用，但别装作是工具在负责，责任还是你自己的。 内核文档已经新增了两份相关说明。一份是 A…

过去两年，“提示词”被讲得有点像咒语：有人把它说成一套神秘技巧，仿佛只要背几个模板，就能让模型瞬间变聪明；也有人开始反过来鄙视它，觉得 prompt 只是过渡产物，迟早会被更强的模型吞掉。 这两种看法都不太对。 对普通开发者来说，提示词更准确的理解是：你给模型下达任务时，用来描述目标、上下文、约束和输出要求的接口层。 它不神秘，也不低级。它本质上更…