AI推理 | 锤子前端

《十个防止 AI 代码泛滥的前端项目护栏》

Thu, 10 Sep 2026 23:23:08 GMT

《十个防止 AI 代码泛滥的前端项目护栏》

标签：
#前端 #TypeScript #React #AI编程 #代码质量 #ESLint #测试策略 #CI_CD #代码审查 #工程实践

总结：

本文针对 AI 生成代码速度远超人类审查能力的前端项目，提供了一套实用的十项防护清单。核心思路是通过自动化工具链（类型系统、Linter、变异测试、CI 门禁）在代码合并前拦截机械性错误，而非依赖人工逐行审查。

文章要点：

1. 用 OpenAPI 契约替代手写类型：通过 Hey API 等工具从 OpenAPI 规范直接生成 TypeScript 类型、客户端和 Zod 校验，避免 AI 臆造不存在的 API 字段（如 user.fullName），让编译器在构建期就报错。

2. 开启严格 TypeScript 配置：启用 noUncheckedIndexedAccess 等严格标志，让数组索引访问返回 T | undefined，迫使代码显式处理边界情况，减少 AI 常见的"想当然"代码。

3. 把 Linter 当作行为过滤器：使用 SonarJS、react-you-might-not-need-an-effect、vitest/playwright 插件、jsx-a11y 等 ESLint 插件，自动拦截认知复杂度过高、不必要的 Effect、可访问性违规等问题。

4. 设定架构层边界：使用 eslint-plugin-boundaries 或 dependency-cruiser 强制实施分层架构（如 UI 层不得直接访问 API 层），防止 AI 生成的代码逐渐退化为"GitHub 平均水平"的混乱结构。

5. 将重复出现的错误转化为自定义 Linter 规则：当同一种 bug 第二次出现时，立即编写自定义 ESLint 规则禁止该模式。例如禁止在服务层函数中使用 Math.round 和 toFixed，避免双重取整导致的薪资计算错误。

6. 把规则直接喂给 AI 模型：通过项目规则文件（如 .cursor/rules、CLAUDE.md）或技能文件（如 react-doctor），将项目约定、架构决策和禁止模式直接提供给 AI，让模型在生成代码时就遵循规范。

7. 用变异测试验证测试有效性：使用 Stryker 故意破坏代码（翻转运算符、反转条件、交换返回值），检查现有测试是否能捕获这些变异。存活的变异体通常暴露"只测形状不测内容"的无效测试。一个项目约 4,700 个变异体在 6 分钟内完成扫描。

8. 用 Knip 清理死代码：Knip 可以检测未使用的文件、导出和依赖，配合自定义可达性脚本填补其盲区，防止 AI 生成大量"以防万一"却无人调用的冗余代码。

9. 用 jscpd 检测重复代码：AI 倾向于在不同地方生成几乎相同的逻辑，jscpd 能发现这些重复，提示抽象机会或错误的复制粘贴。

10. 将所有检查强制设为 CI 门禁：上述所有工具（类型检查、Lint、测试、变异测试、重复检测）必须作为 CI 的强制通过项，而非可选建议，确保 AI 生成的代码无法绕过质量关卡。

11. 成本与局限：这些护栏会产生噪音（误报）、规则过时和新人上手摩擦等成本，建议按"类型 → Lint → 测试 → CI"的顺序渐进式推行。同时需注意，这些检查只能捕获机械性错误，无法识别糟糕的品味或错误的抽象。

URL：
https://evilmartians.com/chronicles/ten-anti-ai-slop-moves-for-frontend-projects-going-faster-than-humans-can-review

evilmartians.com

10 anti-AI slop moves for frontend projects going faster than humans can review—Martian Chronicles, Evil Martians’ team blog

Ten checks that catch what AI-written frontend code hides: contract codegen, boundary linting, mutation testing, and dead-code detectors.

《Domenic 的 Agentic 编码工作流：2026 年 7 月实战指南》

Mon, 03 Aug 2026 00:54:30 GMT

《Domenic 的 Agentic 编码工作流：2026 年 7 月实战指南》

标签：#前端 #AI_Agent #Claude_Code #ChatGPT #Tailscale #Git_Worktrees #DevOps #远程开发

总结：
Domenic 分享了他脱离企业环境后搭建的一套 AI 辅助开发工作流：以一台常驻开机的 Linux VM 为中枢，通过 Tailscale 构建跨设备私有网络，让 ChatGPT/Claude 桌面应用作为瘦客户端远程操控 Agent。核心亮点包括零审批的"YOLO"安全策略、Git worktrees 实现多 Agent 并行开发、Portless 自动暴露安全预览服务器、VS Code Remote-SSH 审查代码，以及 chezmoi 同步配置。最终效果惊人——他能在火车上用手机连接 VM，让前沿模型修复生产 bug 并直接合并 PR。

文章要点：
1. Linux VM + Tailscale 是地基：Agent 训练数据几乎全是 Bash/Unix 工具，Windows 下寸步难行。用 Ubuntu Server 搭一台可抛弃的 VM，配合 Tailscale 的魔法 SSH 和 HTTPS 证书，无论在哪台设备、哪个 Wi-Fi 下都能无缝接入，还能让 Agent 启动的开发服务器拥有安全上下文。
2. ChatGPT 桌面应用体验完胜 Claude：ChatGPT 原生支持远程 SSH 会话，断线重连优雅、worktree 管理清爽（默认放在 ~/.codex/worktrees/）；Claude 桌面应用则在 SSH/Remote Control 混合逻辑、会话同步、worktree 目录污染项目等方面表现糟糕，目前只能退而求其次用 Claude Code + tmux。
3. Git Worktrees 解锁并行开发：在 VM 上让多个 Agent 同时 hack 同一个仓库而不互相踩脚，ChatGPT 和 Claude 都支持一键勾选 worktree 模式。Agent 会自动处理 origin/main 同步、依赖安装和 .env 复制，人类完全不用操心。
4. Portless 让预览服务器"零摩擦"：不用改 npm run dev 绑定 0.0.0.0，也不用记端口。tportless 包装器自动把 localhost 服务代理到 Tailscale 专属域名（如 https://agents-base.tail234567.ts.net:8443/），多 Agent 并行时端口自动隔离，且外网无法访问。
5. "危险模式"下的生存策略：把 ~/.codex/config.toml 和 ~/.claude/settings.json 都设为"永不询问权限"，配合 sudo 和 gh CLI 登录，让 Agent 能自主装工具、发 PR、合并代码。风险靠"频繁推送到 GitHub 私有仓库"来对冲——VM 炸了代码也在云端。
6. 手机修生产 Bug 已成现实：完整闭环——聚会发现 bug → 火车上打开 ChatGPT App → 远程连接 VM 启动修复 → 收到推送通知里的预览链接验证 → 手机审阅 diff 并合并 PR → 到家前 GitHub Actions 已部署上线。这就是未来。

URL：https://domenic.me/agentic-coding-setup/

Domenic Denicola

My Agentic Coding Setup, July 2026

With the right tools, coding agents can run autonomously, in parallel, and be reachable from anywhere. Here's how I've stitched them together.

《Git Worktrees 入门指南：把分支变成平行工作空间》

Sat, 18 Jul 2026 15:26:37 GMT

《Git Worktrees 入门指南：把分支变成平行工作空间》

标签：#Git #工作流 #AI辅助编程 #开发工具 #分支管理

总结：

Git worktrees 是一个被低估十年的功能，它将分支检出到独立目录而非项目根目录，让开发者能在同一仓库中并行处理多个任务。文章从基础命令讲起，演示了如何创建、管理和清理 worktree，特别强调了它在 AI 编码代理时代的新价值——多个智能体可在独立工作树中自主工作互不干扰，完成后合并回主仓库，无需将代码推送到云端即可实现并行开发。

文章要点：

1. Worktree 的本质就是"检出到不同目录的分支"，它共享完整提交历史，能正常推拉远程，唯一区别是文件物理位置不同
2. 创建命令 git worktree add ../project.worktrees/feature-name -b feature/name main 会在指定目录新建分支，但依赖需要重新安装（如 node_modules 不共享），且该分支在 worktree 存在时无法在别处检出
3. 目录组织有两种风格：与主仓库平级的直接兄弟目录，或统一放在 .worktrees 共享父目录下；后者更整洁，尤其适合 AI 代理批量创建工作树
4. 合并变更既可以通过常规的 push + PR 流程，也可以在本地用 rebase 后 merge；清理时用 git worktree remove 删除目录但保留分支，确认无用后再 git branch -d 删除分支
5. git worktree list 能查看所有工作树状态，配合 git config --global alias.wt worktree 设置别名后，整个工作流（创建、查看、移除）都能用简短的 wt 命令完成
6. 核心价值在于"本地并行"：AI 编码工具现在常用 worktrees 让多个代理同时修改代码，既避免了分支切换的上下文丢失，也省去了云端暂存的麻烦

URL：https://humanwhocodes.com/blog/2026/07/introduction-git-worktrees/

Human Who Codes

A gentle introduction to Git worktrees - Human Who Codes

Git worktrees let you check out multiple branches into separate directories simultaneously, making parallel local development straightforward whether you're working solo or alongside AI coding agents.

《永不浪费一个Token：AI推理流的可恢复性设计》

Wed, 17 Jun 2026 01:11:36 GMT

《永不浪费一个Token：AI推理流的可恢复性设计》

标签：#后端 #AI推理 #Cloudflare #DurableObject #流式恢复 #Token计费优化

总结：
本文探讨了AI Agent在推理过程中因进程崩溃或重新部署导致流式连接中断、已付费Token被重复计费的痛点。核心方案是在Agent与LLM提供商之间引入一个持久化缓冲区（Durable Object），将流式数据实时写入SQLite，使连接与Agent进程解耦。Agent重启后可通过游标恢复，避免重复调用和重复付费。该机制同时解决了浏览器断网重连和进程崩溃恢复两种场景，且即将集成到Cloudflare AI Gateway中，实现一键开启的持久化推理。

文章要点：
1. 隐藏的成本黑洞：Agent进程崩溃或重新部署时，正在进行的LLM流式请求会中断，已付费的生成Token全部丢失，恢复后必须重新调用并重新付费，且旗舰模型（如GPT-5.5）的重复成本是小模型的15倍。
2. 解耦连接与进程：将LLM提供商连接移出Agent进程，部署为独立的持久化缓冲区（Durable Object），在后台持续将流式数据写入SQLite。即使Agent进程被替换，缓冲区仍继续接收数据，Token不再浪费。
3. 一份日志，两种用途：持久化缓冲区存储的原始字节流既支持浏览器断网重连（追赶实时游标），也支持进程崩溃恢复（回放已存储的片段）。两者共用同一套SQLite日志机制，仅需判断生产者是否仍在运行。
4. 零自定义解析：存储原始字节而非解析后的SSE事件，恢复时通过各提供商的官方插件（如OpenAI、Anthropic）重新解析，避免维护多套格式解析器，且能自动适配格式变更。
5. 行业现状对比：OpenAI Responses API已原生支持后台模式恢复；Anthropic和Google Gemini均不支持服务端续流，只能重新提示并重复计费；Vercel的resumable-stream为应用层方案，无法承受部署替换。
6. 即将落地AI Gateway：Cloudflare AI Gateway正在集成该持久化恢复能力，未来只需在Agent基类中设置durableBuffer = true即可一键开启，实现跨提供商的Token零浪费。

URL：https://sunilpai.dev/posts/never-waste-a-token/

Solving the decision problem

never waste a token

durable inference: resumable streams, crash recovery, and why the LLM request shouldn't die with your process.

《Chrome DevTools MCP v1 发布：为 AI 编码代理赋予浏览器调试超能力》

Mon, 25 May 2026 08:33:43 GMT

《Chrome DevTools MCP v1 发布：为 AI 编码代理赋予浏览器调试超能力》

标签：#前端 #AI_Tools #Chrome_DevTools #MCP #Browser_Automation #Performance_Debugging

总结：
Chrome 团队正式发布 DevTools MCP v1，通过 Model Context Protocol 将 Chrome DevTools 的完整调试能力开放给 AI 编码代理。它让 Claude、Cursor、Copilot 等 AI 助手能够实时控制浏览器、抓取性能 trace、分析网络请求、检查控制台日志，甚至处理 1500 万行级别的性能数据，从而把"盲写代码"的 AI 变成能看、能测、能调优的闭环调试器。

文章要点：
1. 告别盲写时代：以前 AI 编码代理只能凭空推理代码，无法看到实际渲染效果。DevTools MCP 直接给 AI 装上"眼睛"，让它能截图、查 DOM、读控制台、抓网络请求，基于真实浏览器状态做判断。
2. 40+ 工具全覆盖：从点击、填表、导航等自动化操作，到性能 trace 录制、Lighthouse 审计、内存堆快照、网络请求分析，几乎把 DevTools 面板的能力完整暴露给了 AI。
3. 性能分析是杀手锏：Paul Irish 演示了如何处理 1500 万行 JSON 的复杂性能 trace，MCP 服务器会解析并提炼出关键洞察，让 AI 帮你做原本需要资深性能专家才能完成的初步诊断。
4. 接入零门槛：支持 Claude Code、Cursor、Copilot、Gemini CLI、VS Code 等主流工具，一条 npx 命令即可启动，还能自动连接本地已运行的 Chrome 实例，无需额外配置。
5. 架构扎实可靠：底层基于 Chrome DevTools Protocol 和 Puppeteer，自动化操作自带智能等待，避免 flaky；同时支持 headless 和有头模式，适应不同场景需求。

URL：https://developer.chrome.com/blog/devtools-for-agents-v1

Chrome for Developers

Streamline your AI coding workflow with Chrome DevTools for agents 1.0 | Blog | Chrome for Developers

Chrome DevTools for agents provides your coding agent with the visibility it needs to verify, debug, and optimize code in real time.

《Agent Harness 的解剖学：将 LLM 转化为工作引擎的系统工程》

Sat, 09 May 2026 01:18:04 GMT

《Agent Harness 的解剖学：将 LLM 转化为工作引擎的系统工程》

标签：#AI_Agent #LLM #LangChain #Harness_Engineering #Context_Management #Tool_Orchestration

总结：Agent Harness 是包裹在大模型之外的全套"脚手架"——包括系统提示词、工具调用、文件系统、沙盒环境、记忆管理和编排逻辑等。它把只能输入输出文本的"裸模型"，改造成能持久化状态、执行代码、自主规划并长期协作的合格智能体。文章从模型能力边界出发，逆向推导出每个 Harness 组件存在的必然性，并指出 Harness 工程与模型训练正在协同进化，优化 Harness 本身就能让同一模型在基准测试上从 Top 30 跃升至 Top 5。

文章要点：
- Agent = Model + Harness：如果你不是模型本身，那你就是 Harness。Harness 是除模型权重外的一切代码、配置与执行逻辑，负责把模型的"智商"转化为"产能"
- 模型天生会"健忘"：裸模型只能处理上下文窗口内的信息，无法跨会话记住状态、执行代码或获取实时知识，这些"超能力"全靠 Harness 赋予
- 文件系统是最底层的基础设施：给 Agent 一个工作目录，它就能读写数据、卸载超长上下文、还能让多个 Agent 像同事一样通过共享文件协作
- Bash + 代码执行是万能瑞士军刀：与其为每个场景预写工具，不如直接给 Agent 一个终端，让它现场写代码、装依赖、自己造工具解决问题
- 沙盒让 Agent 安全地"动手"：在隔离环境里跑代码、测效果、看日志，既防手滑删库，又能按需扩容、用完即焚
- 记忆靠"上下文注入"实现：通过 AGENTS.md 等记忆文件标准，把历史经验塞进新会话；再配合网络搜索和 MCP 工具，突破训练数据的时间 cutoff
- 上下文腐烂是隐形杀手：随着对话变长，模型性能会断崖下跌。Harness 通过 Compaction（智能摘要）、Tool 输出卸载和 Skills 渐进式加载来保护宝贵的上下文空间
- 长程任务需要"接力跑"：Ralph Loop 机制让 Agent 在上下文耗尽时，从文件系统读取进度、换一块"干净"上下文继续干；配合 git 记录和自验证循环，实现跨会话的复杂项目开发
- Harness 与模型在"共同进化"：Claude Code、Codex 等产品会把 Harness 逻辑也放进后训练环节，但有趣的是——换一套更优 Harness，同一模型排名能从 30 名外冲进前 5
- 未来 Harness 会"瘦身"但不会消失：随着模型原生规划、验证能力变强，部分 Harness 功能会被模型吸收；但就像提示工程至今仍有价值，Harness 工程作为"围绕模型智能设计系统"的学科，仍将持续发光

文章URL：https://www.langchain.com/blog/the-anatomy-of-an-agent-harness

Langchain

The Anatomy of an Agent Harness

Learn how agent harnesses transform AI models into autonomous work engines. Explore core components: filesystems, sandboxes, and memory.

《MCP已死，CLI万岁》

Wed, 29 Apr 2026 06:23:59 GMT

《MCP已死，CLI万岁》

标签：#AI工具 #开发工具 #MCP #CLI #LLM工具链 #Anthropic #AI代理

总结：
作者认为Anthropic推出的MCP协议正走向消亡，主张LLM应直接使用CLI工具而非专用协议。CLI具备可组合性、调试友好、认证成熟、无额外进程等优势，而MCP存在初始化不稳定、重复认证、权限粒度粗等实际痛点。最好的工具应同时服务人类与机器，开发者应优先打磨API和CLI。

文章要点：
- LLM天生就会用命令行：它们在海量man page、Stack Overflow和shell脚本中训练过，给Claude一个CLI和文档，它就能直接上手，根本不需要新协议
- 调试体验天差地别：CLI出问题你可以亲自跑一遍同样的命令，看到和AI完全一致的输入输出；MCP出错却要钻JSON传输日志，排查像考古
- 管道和组合才是生产力：CLI能通过`jq`、`grep`、重定向灵活处理数据；MCP面对大型Terraform计划只能全塞进上下文窗口，或额外写过滤逻辑，费力不讨好
- 认证体系早已成熟：`aws`、`gh`、`kubectl`都有经过实战检验的SSO和凭证管理，AI和人类共用同一套流程，坏了就按老办法修，不用学MCP专属排错
- 没有后台进程更省心：MCP服务器是常驻进程，会挂起、会掉线、需要状态管理；CLI只是磁盘上的二进制文件，随用随走，干净利落
- 日常使用的真实摩擦：MCP初始化经常抽风要重启，多工具反复认证让人崩溃，权限控制只有白名单名字做不到只读或参数级限制；CLI完全没有这些烦恼
- MCP并非毫无价值：只有当某个工具确实没有CLI时，MCP才是合理选择，标准化接口在极少数场景也有意义
- 给工具开发者的建议：如果你公司在砸钱做MCP服务器却没有官方CLI，赶紧停下来——先把API和CLI做好，AI代理自己会搞定剩下的

文章URL：https://ejholmes.github.io/2026/02/28/mcp-is-dead-long-live-the-cli.html

《为AI智能体设计产品：从界面思维到智能体思维》

Mon, 27 Apr 2026 03:03:03 GMT

《为AI智能体设计产品：从界面思维到智能体思维》

标签：#AI产品 #MCP #智能体交互设计 #产品架构 #API设计 #Salesforce #Ramp #Notion

总结：
本文由Ramp产品负责人Teddy Riker撰写，探讨了AI智能体时代产品设计的范式转变。作者指出，未来80%的软件交互将通过AI智能体完成，产品团队需要从"为用户设计界面"转向"为智能体设计能力"。文章以Ramp、Salesforce、Notion等案例，提出了三大核心设计原则：主动提供成功所需的上下文规范、建立基于工具调用的反馈循环、识别并填补智能体间的上下文缺口。

文章要点：

- **交互范式正在翻转**：传统模式是"用户→界面→数据库"，而AI时代正在变成"用户→用户智能体→软件智能体→数据库"。界面不会消失，但80%的交互将发生在智能体之间，产品团队需要为"看不见的用户"重新设计。

- **Salesforce的激进转型**：这家27年的传统软件巨头推出"Headless 360"计划，将平台所有能力暴露为API、MCP工具或CLI命令，承认图形界面CRM的护城河正在被侵蚀，主动拥抱"无界面"未来。

- **教会智能体如何成功**：Notion的MCP设计是个正面教材——它在工具描述中明确要求智能体先读取Markdown规范再操作，确保格式准确。相比之下，Slack MCP让智能体"自己摸索"格式规则，结果用户反而要花更多时间修正。产品团队应该主动告诉调用方"你需要知道什么才能成功"。

- **用反馈循环驱动产品迭代**：Ramp通过三个机制解决智能体交互的可观测性难题：要求每次工具调用附带`rationale`参数解释意图、提供独立的反馈提交工具、在特定工具中预埋上下文种子。这些反馈比人类用户更具体、更一致，能直接转化为新功能需求。

- **填补上下文缺口是核心设计挑战**：在"用户智能体↔️软件智能体"的协作中，双方各自掌握对方没有的信息。优秀的设计不是让智能体去猜技术细节（如GL code），而是让它们交换语义上下文（如"这是客户晚餐还是团队建设"），由各自擅长的那一方完成最终决策。

- **敷衍智能体支持的产品会被淘汰**：仅仅发布一个MCP服务器、勾上"支持AI"的 checkbox 是不够的。客户最终会流向那些认真打磨智能体体验、真正理解"最后签支票的可能是AI"的产品。

文章URL：https://baoyu.io/blog/2026-04-24/teddy-riker-2047312986696454584

baoyu.io

为 Agent 设计产品

UI 并没有死，但软件交互的 80% 正在转向 Agent。产品团队需要像过去为人设计界面一样，认真为 Agent 设计工具、上下文和反馈闭环。

《从基础学科到通用人工智能：25学科知识地图》

Sun, 26 Apr 2026 00:12:46 GMT

《从基础学科到通用人工智能：25学科知识地图》

标签：#AI教育 #知识图谱 #AGI #跨学科学习 #深度学习 #机器学习 #强化学习 #认知科学 #DataWhale

总结：
这是一份由DataWhale社区维护的AI跨学科知识导航页，将支撑通用人工智能的25门基础学科按数学、计算、认知、决策、物理哲学五大簇组织，并提供多条能力形成路径（表示训练、结构关系、智能体控制、自然智能与AGI），帮助学习者从"学科目录"走向"能力路径"，降低跨学科学习成本，避免在庞杂专题中迷路。

文章要点：
- AI本质是跨学科汇流系统，从1943年McCulloch-Pitts神经元到2022年后大模型与Agent，历史脉络清晰展示了数学、工程、认知、哲学等学科的交汇
- 25门学科被系统分为五大簇：数学与形式基础（概率/线代/优化/信息论等）、计算与系统工程（数值分析/控制论/硬件并行等）、认知生物与语言（神经科学/心理学/语言学等）、决策交互与社会机制（运筹学/博弈论/经济学）、物理与哲学基础（统计物理/哲学）
- 提供了五条能力形成路径：表示与训练、结构与关系、不确定性与因果、控制与智能体、自然智能与AGI，让学习围绕"能力如何长出来"而非"学科如何分类"来组织
- 针对不同目标读者定制了四条入门路线：机器学习/深度学习、结构化AI/图学习、强化学习/智能体、推理/AGI，并精选10个优先专题作为"最短抓手"
- 核心定位是"导航页"而非"正文替代者"，强调通过横向跳转、反向链接和跨学科汇流点来提升学习效率，避免线性单学科推进

文章URL：https://github.com/datawhalechina/Path2AGI

GitHub

GitHub - datawhalechina/Path2AGI: 从基础学科到通用人工智能 - 跨学科知识图谱

从基础学科到通用人工智能 - 跨学科知识图谱. Contribute to datawhalechina/Path2AGI development by creating an account on GitHub.

《OpenHarness：开源智能体基础设施框架》

Sat, 04 Apr 2026 00:52:30 GMT

《OpenHarness：开源智能体基础设施框架》

标签：#AI #Agent #智能体 #开源 #Python #工具调用

总结：
OpenHarness是港大数据智能实验室（HKUDS）推出的轻量级开源智能体基础设施框架，仅用Python实现，代码量比Claude Code轻44倍（1.1万行vs 51万行），提供完整的工具调用、技能加载、记忆管理和多智能体协调功能，让开发者快速构建安全可靠的AI Agent应用。

文章要点：
- 极简架构设计：相比Claude Code的51万行TypeScript代码，OpenHarness仅用1.1万行Python实现，去除了企业级复杂依赖如遥测和OAuth，专注于核心Harness架构
- 五大核心模块：包含Agent循环（支持流式工具调用、并行执行、成本追踪）、工具套件（43种工具覆盖文件/Shell/搜索/Web/MCP）、上下文记忆（CLAUDE.md自动注入、MEMORY.md持久化）、权限治理（多级权限模式、交互式审批）、Swarm多智能体协调（子智能体委派、任务管理）
- 生态兼容性：完全兼容anthropics/skills技能格式和claude-code/plugins插件生态，支持OpenClaw、nanobot、Cursor等CLI工具集成
- 开箱即用：一条命令oh即可启动，内置114个单元测试和6个E2E测试套件，提供稳定可靠的基础能力

文章URL：
https://github.com/HKUDS/OpenHarness

GitHub

GitHub - HKUDS/OpenHarness: "OpenHarness: Open Agent Harness with a Built-in Personal Agent--Ohmo!"

"OpenHarness: Open Agent Harness with a Built-in Personal Agent--Ohmo!" - HKUDS/OpenHarness

《AI指数级增长时代的产品管理》

Mon, 30 Mar 2026 05:38:39 GMT

《AI指数级增长时代的产品管理》

标签：#产品管理 #AI #ClaudeCode #敏捷开发 #原型优先

总结：

本文由Anthropic的Claude Code产品负责人撰写，探讨了AI模型指数级进步如何颠覆传统产品管理范式。作者指出，过去PM依赖"项目开始时确定技术边界"的假设已失效，因为模型能力在项目周期内可能跃升数十倍。新的工作流强调快速实验、原型优先、角色融合和持续迭代，PM的核心价值转向在不确定性中创造清晰度、推动团队大胆设想可能性，并加速产品交付。

文章要点：

- 传统假设被打破**：过去PM基于"技术能力在项目周期内相对稳定"制定长期路线图，但AI模型能力呈指数级增长（如Claude在16个月内任务处理能力提升41倍），项目初期的技术约束可能在开发中途消失
- **角色边界模糊化**：AI工具让设计师能写代码、工程师做产品决策、PM直接构建原型和评估，产品/设计/工程从线性流程变为高度重叠的协作模式
- **原型优先于文档**：用Claude Code等工具几小时就能做出可演示的原型，团队用Demo代替PRD进行内部验证，错误决策的成本大幅降低
- "支线任务"文化**：鼓励成员在正式路线图外进行短期自主实验，Claude Code桌面版、AskUserQuestion等热门功能都源自这种探索
- **模型迭代即产品迭代**：每个新模型发布都应触发对已有功能的重新审视，作者建议每天主动测试"可能太难"的任务，当模型能完成时就是产品该升级的信号
- **简单至上原则**：避免为绕过模型限制而设计复杂方案，这些"巧妙"的workaround会在新模型发布后变成技术债务，Claude Code的系统提示词已随模型升级精简了20%

文章URL：

https://claude.com/blog/product-management-on-the-ai-exponential

Claude

Product management on the AI exponential

Claude Code's Head of Product Cat Wu on AI product management: how to rethink your workflows and roadmaps as model intelligence compounds.

#AI 2025 年是 LLM 从“玩具”走向“工具”的转折年：推理模型+代码 Agent+异步任务+手机编程，构成了新的开发范式

Sun, 04 Jan 2026 14:10:59 GMT

#AI 2025 年是 LLM 从“玩具”走向“工具”的转折年：推理模型+代码 Agent+异步任务+手机编程，构成了新的开发范式。中国模型崛起、Google 发力、OpenAI 失领先，格局已变。

https://simonwillison.net/2025/Dec/31/the-year-in-llms/

Simon Willison’s Weblog

2025: The year in LLMs

This is the third in my annual series reviewing everything that happened in the LLM space over the past 12 months. For previous years see Stuff we figured out about …