Search: #AI协作

  1. 《Uncle Bob 的 ub-mode:给 AI 编程助手装上"纪律开关"》

    《Uncle Bob 的 ub-mode:给 AI 编程助手装上"纪律开关"》

    标签:
    #软件工程 #AI编程辅助 #TDD #代码质量门禁

    总结:
    这是 Robert C. Martin(Uncle Bob)发布的一个 AI 智能体技能(agent skill),用于在 AI 编写或修改代码时强制执行严谨的软件工程纪律。它部分借鉴了 poteto-mode 的规则体系并加以精简,同时配套一组确定性的质量门禁工具(复杂度、重复率、变异测试),让"先让它能工作,再让它正确,最后持续练习"的原则可度量、可落地。

    文章要点:
    1. 核心理念分三层:先让它能工作(懒惰协议、TDD、先减后加、领域建模、边界与类型纪律等),再让它正确(修复根因、测试行为而非实现、持续重构),最后落实到日常练习(记日志、守护上下文窗口、小而有序的提交)。
    2. 规则部分借鉴并精简自 poteto-mode:作者明确说明 ub-mode 是 @poteto 规则集的删减版,与确定性工具搭配使用。
    3. 配套四个质量门禁工具仓库:crapper 计算圈复杂度与 CRAP 分数(要求 CRAP < 10),dryer 检测结构重复(相似度 ≥ 0.8 即需消除),mutator 做变异测试揪出"测试杀不死的活口",uml-viewer 可视化组件、覆盖率与依赖方向。
    4. 安装方式极简:只需把 SKILL.md 复制到所用 AI 工具的 skills 目录(如 /.claude/skills/ub-mode/),然后输入 /ub-mode 即可调用。
    5. 目标很明确:把 Uncle Bob 倡导的软件工艺原则变成 AI 编码时可检查、可强制执行的硬约束,而不是口头建议。

    URL:https://github.com/unclebob/ub-mode GitHub - unclebob/ub-mode

  2. 《我用 AI 做设计的六步法(第二篇:复杂功能篇)》

    《我用 AI 做设计的六步法(第二篇:复杂功能篇)》

    标签:
    #AI辅助设计 #工程师设计进阶 #AI_Slop治理 #复杂功能开发 #RefTools

    总结:
    作者分享了自己用 AI Agent 开发复杂产品功能时、如何避免"AI Slop(AI 生成的设计垃圾)"污染界面的完整流程。核心思路是:在让 Agent 动手之前先充分理解产品和约束,Agent 跑完后必须人工把每个界面状态过一遍,再聚焦打磨关键界面,最后靠团队协作和真实用户反馈收口。

    文章要点:
    1. 动手前先理解机制:花大量时间在调研规划阶段,搞清 Agent 会接触的产品界面和技术约束,甚至亲手写一遍用户流程,绝不让 Agent 的技术/产品决策带来意外惊喜。
    2. 追踪 Agent 的实现轨迹:让 Agent 先把功能粗做出来当"陶土"来塑形,然后通读它产出的所有产物(日志、截图、PR、演示视频),检查实现路线是否有异常偏离。
    3. 放大视角看遍所有状态:他要求 Agent 点击功能里每一个界面的每一个状态,输出全状态截图清单和沿途发现的 Bug 清单,先粗扫一遍再标记小问题,这一阶段说得最多的就是"删掉这个"。
    4. 聚焦打磨关键界面(Crux Surfaces):把最关键的几个界面拉到 Figma 或 HTML 原型里手工精修,这是 AI 时代里难得的专注打磨细节的乐趣。
    5. 走出孤岛、靠团队迭代:一个人用 Agent 能做完过去一个团队的活,但也失去了团队的品味把关;他们靠 Slack 的 #design-adjustments 频道让任何人贴"修改前/后对比图"来提设计改进。
    6. 上线、学习、接受意外:复杂功能总有你没想到的交互路径,用户一定会找到它,把产品交到用户手里才是真正的验证。

    URL:https://x.com/reactiverobot/status/2115075879923765615 Matt Dailey on X: "How I Design with AI. (pt 2)" / X

  3. 《OpenRig:把 Claude Code 和 Codex 编成一支可恢复的多智能体团队》

    《OpenRig:把 Claude Code 和 Codex 编成一支可恢复的多智能体团队》

    标签:
    #AI_Agent编排 #多智能体协作 #ClaudeCode #Codex #Tmux #终端UI #任务队列 #快照恢复 #MCP工具 #开源工具

    总结:

    OpenRig 是一个自托管的多智能体 harness:它不替代 Claude Code 或 Codex,而是把多个 Agent 会话组织成“有结构、可命名、可恢复”的团队。你用 YAML(RigSpec)定义团队拓扑,用一条命令启动整队,并通过 TUI/CLI/MCP 观察状态、发消息、跟踪任务和做快照恢复,避免终端窗口越开越散。

    文章要点:
    1. 核心解决“终端蔓延”:把一堆各自为政的 Claude Code/Codex 会话,变成有角色、有地址、有协作关系的团队。
    2. 团队用 YAML 声明式定义:RigSpec 里包含 pods、成员、edges、continuity policies 和 culture 文件,便于版本化与复用。
    3. 一键启动与拓扑可视化:rig up 会拉起 tmux 会话、harness、启动文件和 readiness 检查;TUI 提供表格/图视图查看 rigs、pods、seats。
    4. 支持“收养”已有会话:rig discover 识别现有 tmux 中的 Claude Code/Codex 会话,rig adopt 将其纳入管理。
    5. 状态可保存也能回滚:rig down --snapshot 保存拓扑,rig up <name> 按名字恢复,重启后不再丢上下文。
    6. 跨 Agent 沟通有统一入口:rig send、rig broadcast、rig chatroom 让协作不再靠人肉切窗口。
    7. 提供 Agent 可用的 MCP 工具:Agent 能自管理拓扑(如 rig_up、rig_ps、rig_send 等),更适合“由 Agent 驱动”的工作流。
    8. 权限与安全边界清晰:默认非 YOLO;可配置 typing guard、权限模式、workspace trust、hooks 与活动上报(不包含 prompt 文本和工具参数)。
    9. 附带 starter rigs 与示例:如 first-project、product-team、conveyor、adversarial-review、research-team、secrets-manager(HashiCorp Vault 由专门 Agent 管理)。
    10. 运行要求明确:需要 Node.js 22/24、tmux,支持 macOS/Linux;可选 herdr/cmux 做终端工作区,Docker 用于服务化 rigs。

    URL:
    https://github.com/mvschwarz/openrig GitHub - mvschwarz/openrig: Build your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared…

  4. 《Paperclip:用开源“公司”编排 AI 智能体团队》

    《Paperclip:用开源“公司”编排 AI 智能体团队》

    标签:
    #AI_Agent编排 #Agentic任务管理 #组织治理与成本控制 #多智能体协作 #开源自托管 #Nodejs与React #OrgChart #Heartbeat调度 #预算管控 #多组织隔离

    总结:

    Paperclip 是一个开源的自托管应用,用“经营公司”的方式管理 AI 智能体团队:它把目标、组织架构、任务、预算、审批、审计和运行环境整合进一个控制台。你可以接入 Claude Code、Codex、Cursor、OpenClaw 等任意 Agent,让它们像员工一样有角色、汇报线、预算与心跳调度,并在一个看板里追踪进度与成本。

    文章要点:
    1. 核心定位是“管公司,不是管聊天”:Paperclip 不造 Agent、不做拖拽式工作流,而是把多个 Agent 编排成有目标、有层级、有治理的组织。
    2. 使用路径很直接:先定义商业目标,再“招聘”不同职能的 Agent(CEO/CTO/工程/设计/营销等),最后审批策略、设置预算并启动运行。
    3. 四大支柱覆盖日常到平台层:Agentic 任务管理、Agent 组织架构、Agent 员工培训、Agentic OS(运行基础设施)。
    4. 任务系统强调可审计与防冲突:任务带公司/项目/目标链路,支持原子领取、执行锁、阻塞依赖、评论、附件与产出物。
    5. Heartbeat 让 Agent 按计划醒来干活:支持定时唤醒、事件触发、上下文续接、结构化日志与自动恢复,减少人工盯梢。
    6. 成本控制是硬约束:按公司/Agent/项目/目标/模型等维度追踪 token 与费用,预算到线会告警并硬停止,避免“跑飞”。
    7. 治理与回滚机制完整:审批流、执行策略、决策记录、暂停/终止 Agent、配置版本化与审计日志都在系统内完成。
    8. 支持多组织隔离与可移植性:一套部署可跑多家“公司”,数据完全隔离;还能导出/导入组织配置并做密钥清理。
    9. 运行环境面向真实开发流程:支持项目工作区、隔离执行工作区(如 git worktree)、开发服务/预览链接、密钥注入与技能加载。
    10. 它不是聊天机器人、不是 Agent 框架、不是代码评审工具,而是面向“多 Agent 团队”的编排控制平面。

    URL:
    https://github.com/paperclipai/paperclip GitHub - paperclipai/paperclip: The open-source app everyone uses to manage agents at work

  5. 《与 AI 协作的五种软件工程角色》

    《与 AI 协作的五种软件工程角色》

    标签:
    #编程 #AI协作 #软件工程 #人机协作 #开发者角色 #技术管理 #AI编程 #团队协作

    总结:

    这篇文章由资深软件工程师 Nicholas C. Zakas 撰写,系统性地梳理了 AI 编程时代下人类开发者与 AI 协作的五种角色模式。作者将传统软件工程中的协作关系映射到人机协作场景中,为开发者提供了从深度参与到完全托管的完整光谱,帮助团队根据信任程度、风险等级和技术背景选择最合适的协作方式。

    文章要点:

    1. **观察者(Observer)模式**:这是最基础的人机协作方式,开发者像结对编程中的观察员一样实时监控 AI 写代码。虽然能确保代码质量,但会面临严重的"审查疲劳"——AI 生成代码的速度远超人类阅读速度,导致效率瓶颈。

    2. **技术负责人(Tech Lead)模式**:开发者负责编写技术规格说明书,设定自动化检查(代码格式化、Lint、测试覆盖率),然后让 AI 并行执行多个工作流。这种模式能成倍提升生产力,但核心挑战在于需要大量自动化投资来减轻人工审查负担。

    3. **架构师(Architect)模式**:开发者只关注高层系统设计、组件接口和基础设施选型,不再审查具体代码实现。风险在于过度脱离代码细节——当系统出问题时可能缺乏底层知识来诊断和修复,因此需要定期抽查生成的代码和测试。

    4. **工程经理(Engineering Manager)模式**:开发者专注于搭建"软件工厂"流程,定义从 PRD 到技术规格再到实现计划的完整生产流水线,将任务分配给不同 AI 代理并设定验收标准。挑战在于流程失败时,过度依赖流程重构可能不如直接介入解决问题高效。

    5. **产品经理(Product Manager)模式**:开发者完全脱离技术实现,只关注用户体验和产品功能。虽然能完成产品级工作,但最大风险是技术债务——当 AI 造成问题时,往往只能贴创可贴式的临时修复而非根治,导致系统长期依赖外部维护。

    6. **动态选择策略**:没有绝对最优的角色,关键在于根据任务风险、对 AI 的信任度和技术上下文灵活切换。探索陌生代码库时当观察者,协调多任务时当技术负责人,追求用户体验时当产品经理。随着对 AI 能力信心的增强,可以沿光谱向更轻量的角色移动,但始终要对最终结果负责。

    URL:
    https://humanwhocodes.com/blog/2026/09/five-roles-working-ai/ Five software engineering roles for working with AI - Human Who Codes

  6. 《框架还重要吗?》

    《框架还重要吗?》

    标签:
    #编程 #Web开发 #AI编程 #前端框架 #React #软件工程 #技术趋势 #VibeCoding

    总结:

    这是一篇探讨在 AI 编程时代 Web 框架是否仍然重要的深度分析文章。作者 Brooks Lybrand 作为拥有三年开源框架开发经验的前端工程师,针对"模型已经足够好,框架选择不再重要"的流行观点进行了系统性反驳,论证了框架在提供抽象、结构和约束方面的核心价值,并呼吁行业继续创新和构建新框架。

    文章要点:

    1. **对"React 已赢"论的质疑**:作者指出当前流行观点认为由于 LLM 训练数据中 React 代码最多,模型最熟悉 React,因此无需尝试其他框架。但他认为这种逻辑存在矛盾——如果框架真的不重要,那连 React 都不需要,直接用 Web Components 或让 AI 生成原生代码即可。

    2. **框架的本质价值**:作者将框架的价值精炼为三点:**提供抽象(Abstractions)、结构(Structure)和约束(Constraints)**。这些价值不仅适用于人类开发者,对 AI 编程同样关键——良好的抽象能避免 AI 重复造轮子或创建混乱的临时方案;清晰的结构帮助 AI 生成可维护的代码;明确的约束(如类型检查、测试)能防止 AI 在迭代中破坏系统。

    3. **AI 时代框架的隐性存在**:引用 React 核心团队成员 Ricky Hanlon 的观点"你要么使用框架,要么构建框架",作者强调即使不显式选择框架,AI 在生成代码时也会隐式地创建框架。与其让 AI 生成一个缺乏维护、充满临时补丁的"隐性框架",不如使用经过实战检验、文档完善的开源框架。

    4. **开发者体验(DX)的重构**:通过分析 HMR(热模块替换)、TypeScript 和 useEffect 等具体技术,作者说明某些传统 DX 功能对人类开发者的价值正在转变,但对 AI 编程仍至关重要。例如 TypeScript 的类型约束能有效防止 AI 在复杂应用中引入错误,而 useEffect 这类强大但易误用的抽象则应该避免让 AI 随意使用。

    5. **框架战争的终结与新机遇**:作者认为 2013-2024 年的"框架战争"已经结束,人们不再渴望为框架争论,但这不意味着框架不再重要。他指出当前框架领域仍存在明显不足,特别是缺乏真正全栈、基于 Web 标准、易于 AI 协作且代码可理解的 JavaScript 框架。

    6. **对未来的呼吁**:尽管承认 AI 正在重塑软件开发,且没人知道其长期影响,作者仍坚持认为认为"所有问题都已解决"是一种颓废的态度。他呼吁继续构建新框架,探索更好的抽象和模式,而不是停留在"现有框架足够好"的舒适区。

    URL:
    https://brookslybrand.com/posts/do-frameworks-matter-anymore/

    > 个人觉得有点片面化,remix 脱离 react 转而用 preact 自创轮子

  7. 《TanStack AI 进入 RC 阶段:从 humble chat() 到完整 AI 生态》

    《TanStack AI 进入 RC 阶段:从 humble chat() 到完整 AI 生态》

    标签:
    #前端开发 #AI框架 #TanStack #TypeScript #开源

    总结:

    TanStack AI 正式从早期原型迈入 RC(Release Candidate)阶段,标志着其从一个简单的 LLM 聊天方法,成长为覆盖聊天、媒体生成、MCP、沙箱、Agent 编排等全场景的 AI 开发框架。核心设计哲学是"不锁定用户"——在传输层、提供商、前后端技术栈上都保持中立,同时通过极致的类型安全和统一的 API 模式降低学习成本。项目由三人业余时间维护,完全开源,无商业路线图。

    文章要点:

    1. 从小 chat() 到大生态 — 最初只有 4 个提供商和一个自定义协议,如今已支持 24+ 提供商,采用 AG-UI 官方协议(被 20+ Agent 框架跨语言支持),并扩展到媒体生成、MCP、沙箱、Agent Harness 等领域。

    2. 中间件是架构的核心超能力 — 几乎所有高级功能(持久化、沙箱 Agent、内存、遥测)都以中间件形式接入 chat() 方法,Durability 则通过适配器插入流式响应。Lazy Tool Calling 用一个布尔标志就能降低 Token 成本。

    3. 传输层零锁定 — 提供 SSE、WebSocket、HTTP Stream、Cap'n Web 等原生传输原语,客户端通过自定义连接适配器消费流,让你对传输层有端到端的完全控制权。

    4. 一套 API 模式打遍所有模态 — 无论是文本生成、图像生成、视频生成、音频生成、转录还是实时音频,API 结构几乎完全相同。学一次模式,换适配器即可,不用学 20 套不同 API。

    5. 类型安全是 DNA 级别 — 不支持的模型选项、缺少必填属性、把某提供商专属工具传给不支持的模型……统统在编译期报错。目标是让你在再复杂的应用里也能自信上线。

    6. chat() 方法是全能核心 — 支持直接对话 LLM 和沙箱 Agent Harness;内置持久化与 Durability(刷新页面、切换对话后能从断点实时续流);支持 Codex 等 Agent 在远程/本地沙箱中运行;还有 Code Mode(Agent 在 isolate 中写代码并执行,优化性能和成本)。

    7. 媒体生成是一等公民 — 实时音频、TTS、图像/视频/音频/音乐生成、转录等全部稳定可用,覆盖 100+ 模型。支持流式直传客户端或一次性生成,两者切换无缝。

    8. RAG 与记忆 — 通过 Cohere、OpenRouter 等提供商支持嵌入和重排序;支持所有主流厂商的 Agent 记忆,让 Agent 跨对话记住用户偏好和关键事实。

    9. 沙箱与 Agent Harness 不挑提供商 — 不强制你用 Daytona、E2B 或 Vercel Sandboxes,基础设施随你选。支持 Codex、Claude Code、Grok、OpenCode 等 20+ ACP 兼容 Agent,甚至能自建本地编码 Agent。

    10. MCP 支持带类型生成 — 不仅能连接外部 MCP 服务器,还能通过 CLI 为远程 MCP 暴露的工具生成类型,保持端到端类型安全。支持连接池和生命周期管理。

    11. 持久化与 Durability 是亮点 — 提供存储原语,你只需实现 Store 并通过一致性测试套件验证,接入持久化中间件后,用户一个月后回来也能从断点续聊。Durability 适配器可将流块持久化到内存、Durable Streams 等,用户重连后不会漏掉任何内容——全部配置约 20 行代码。

    12. 未来路线图 — 核心架构已锁定,接下来重点在 Agent 工作流与编排(并行运行、定时任务、复杂工作流协调),以及继续补齐提供商生态。完全开源,无商业 upsell,欢迎社区贡献。

    URL:
    https://tanstack.com/blog/tanstack-ai-rc TanStack AI Enters the RC Phase | TanStack Blog

  8. 《深入理解 AI Agent:设计原理与工程实践》

    《深入理解 AI Agent:设计原理与工程实践》

    标签:#AI_Agent #LLM #上下文工程 #MCP #RAG #多模态 #Coding_Agent #多智能体协作 #开源书籍

    总结:

    李博杰(中科大+MSRA+华为天才少年背景,Pine AI 首席科学家)所著《深入理解 AI Agent:设计原理与工程实践》开源主仓库,围绕核心公式 Agent = LLM + 上下文 + 工具 展开,全书 10 章正文 + 编译 PDF + 88 个配套实验代码全部 Apache 2.0 开源。上线一周即登顶 GitHub Trending,单日新增 1,734 Stars,目前已超 1.1 万 Stars,社区已自发贡献英文、泰米尔语、越南语翻译。本书填补了"从工程原理层面系统讲透 Agent 的中文开源书"这一空白,强调"Harness Engineering"(模型之外的一切工程能力)才是 Agent 真正的竞争力所在。

    文章要点:

    1. 核心公式与工程理念:全书围绕 Agent = LLM + 上下文 + 工具 展开,提出"Harness Engineering"理念——模型之外的一切工程能力(上下文设计、工具编排、评估体系等)才是 Agent 的护城河,而非单纯依赖模型本身。

    2. 10 章体系化内容:从 Agent 基础、上下文工程、记忆与知识库、工具/MCP 协议、Coding Agent、评估体系、后训练、自我进化、多模态实时交互到多 Agent 协作,覆盖从入门到生产级的完整路径。

    3. 88 个可运行实验代码:每章配套完整 demo,70+ 可独立运行(配置 API Key 即可),涵盖上下文消融实验、KV Cache 友好设计、提示注入攻防、MCP 三类服务器、17 工具生产级 Coding Agent、语音狼人杀等,所有代码按章节组织并三级标注完成状态。

    4. 诚实务实的工程态度:不夸大概念、不制造 hype,每个技术都讲清优势、局限与适用场景,大量使用对照实验(如 mem0 vs Memobase、稠密 vs 稀疏检索、3 种攻击×4 种防御等),用数据说话而非主观断言。

    5. 完全开源与社区共建:全书正文(Markdown)、编译 PDF、配图及代码全部 Apache 2.0 开源,中文为主,社区已贡献英文、泰米尔语、越南语版本,这在中文技术书籍中极为罕见。

    6. 适合人群:想系统理解 Agent 工程而非只会调 API 的开发者;需要搭建 Coding Agent、RAG、多 Agent 协作等生产系统的工程师;对上下文工程、KV Cache、工具设计等底层机制感兴趣的研究者。

    URL:https://github.com/bojieli/ai-agent-book GitHub - bojieli/ai-agent-book: 《深入理解 AI Agent:设计原理与工程实践》(李博杰 著)开源主仓库:全书正文、编译版 PDF 与按章配套代码

  9. 《现代工程价值观:AI 时代的效率与品味》

    《现代工程价值观:AI 时代的效率与品味》

    标签:#软件工程 #AI编程 #代码审查 #团队管理 #技术栈 #开发者体验 #工程管理

    总结:
    作者 Christoph Nakazawa(cpojer)分享了他近半年完全依赖 AI 编码代理完成多个项目的实战经验,指出编程已从"手写代码"转向"指挥系统生成代码"。文章提炼了 AI 时代仍至关重要的五大工程价值观:强所有权、品味至上、严格约束与快速反馈、代码库即上下文、掌控技术栈,并强调管理需更技术化。作者用数据证明效率提升 3 倍,认为未来瓶颈不再是写代码,而是判断力与品味。

    文章要点:
    1. **AI 编码已成常态**:作者过去数月多个项目(Vite+、fate、Codiff、Athena Crisis 等)90%-100% 由 AI 编写,代码质量甚至超越手写,且能在几分钟内完成过去数周的工作
    2. **Codex CLI 是最佳搭档**:使用 GPT 5.5 high 配合 Codex CLI,配合"先写失败测试再修复"的策略,能极大提高一次性正确率;多项目并行时建议每个项目独立窗口,利用空间记忆提升效率
    3. **强所有权比代码更重要**:AI 放大了"懂行"与"不懂行"的差距,小团队(2-3 人)+ 清晰边界 + 独立仓库比大团队协作更高效,审查应聚焦对齐而非代码细节争论
    4. **品味是防"垃圾"泛滥的护城河**:AI 能全天候生成大量平庸代码,工程师的核心价值转向判断"什么值得做",团队应花更多时间思考方向而非盲目堆功能
    5. **严格约束 = 速度**:把代码规范、自动化测试、快速验证等"护栏"做得越严,AI 迭代越快(1 分钟 vs 60 分钟的差距);工具必须支持增量检查,避免随代码量增长而变慢
    6. **代码库即唯一上下文**:将设计文档、产品行为、决策记录全部沉淀在仓库内,让 AI 和人类都能快速理解;代码越简洁、越易读,AI 修复和迭代越高效
    7. **自研技术栈重新划算**:过去依赖第三方库是因为手写代码慢,现在 AI 降低了自研成本,掌控核心依赖能避免被外部框架绑架,获得完全的产品体验控制权
    8. **保留选择权(Option Value)**:任何架构改动都应保留未来大幅调整的可能性,AI 虽让重构变快,但把自己逼进死胡同依然难以脱身
    9. **管理必须更技术化**:执行成本降低后,管理者不能只做方向把控,必须保持领域 expertise,能亲自改代码、做技术决策,"技术型管理"(Tech Lead Management)将成为主流
    10. **效率数据惊人**:近 30 天日均提交 770 次、修改 15k 行代码,是两年前的 3 倍;过去手写巅峰一天 1200 行,现在 AI 辅助可达 10 倍且质量更高

    URL:
    https://cpojer.net/posts/modern-engineering-values Modern Engineering Values

  10. 《AI 正在重演前端的"失落十年"吗?》

    《AI 正在重演前端的"失落十年"吗?》

    标签:#前端 #AI编程 #职业发展 #软件工程 # craftsmanship #Bauhaus

    总结:
    作者将 AI 对编程行业的冲击与前十年 JavaScript 框架对前端的"去技能化"(deskilling)进行类比。框架把浏览器当作编译目标,让通用开发者无需理解 HTML 语义、无障碍、性能等底层知识就能"搞定"前端;AI 编码则进一步将手工写代码的技能消解为"操作半熟练工人使用的技术"。文章认为这降低了从业者议价能力、牺牲了质量,但也承认这是效率提升和抽象层级升高的必然趋势。作者借用 Bauhaus 运动的启示——不是对抗工业化,而是让工匠与工厂协作、以用户为中心重新设计——呼吁在 AI 时代依然需要"懂材料"的人,同时指出商业成功与软件质量本就很少相关,真正的 craft 只会成为更小的切片。

    文章要点:
    1. "去技能化"正在从特定领域扩散到整个编程行业:框架让前端从专精技能变成通用技能,AI 让编程本身面临同样命运
    2. 现代"全栈开发者"往往不是前后端都精通,而是能用框架两边都糊弄的通才,企业因此获得成本节省和人员灵活调配
    3. AI 编码是"非确定性抽象"——不像编译器那样稳定,输入或模型的微小变化会导致截然不同的结果,更像是"不会学习的初级工程师"
    4. LLM 是 Stack Overflow 复制粘贴的终极进化:让懂行的人更快,让不懂的人也能凑出"能跑"的东西,但抽象泄漏时依然需要有人深入理解并修复
    5. 商业成功与软件质量几乎不相关,糟糕的网站对转化率影响有限,且"没人因为选了 React 而被解雇"
    6. Bauhaus 运动的启示:不复古也不对抗工业化,而是让设计师回到工坊、与材料共事,最终产出兼顾批量生产和用户体验的设计
    7. 前端 craft 不会消失,但会成为更小的切片;就像字体设计不再是全职工作、塑料垃圾泛滥但好工业设计依然存在
    8. 快速迭代和 MVP 有其价值,但需要知道自己在验证什么;性能和无障碍等基础如果一开始没做对,后期很难补救
    9. AI 只是工具箱里的又一件工具,但 hype 周期内我们会看到丑陋的代码、破碎的沟通和借 AI 之名裁员
    10. 作者自己的框架 Mastro 倡导"从简单栈开始、后续再添加功能",反对先上重型框架再试图优化

    URL:https://mastrojs.github.io/blog/2026-05-23-is-AI-causing-a-repeat-of-frontends-lost-decade/

  11. 《cc-connect:本地AI编程助手连接消息平台桥梁》

    《cc-connect:本地AI编程助手连接消息平台桥梁》

    标签:#开发工具 #AI编程助手 #ClaudeCode #CursorAgent #GeminiCLI #Codex #Telegram #飞书 #钉钉 #Slack #Discord #WeChatWork #LINE #QQ #Weibo

    总结:
    cc-connect 是一个开源的本地AI编程代理桥接工具,让你可以在飞书、钉钉、Telegram、Slack、Discord、企业微信、LINE、QQ、微博甚至个人微信等11个平台上,随时随地"聊天式"操控 Claude Code、Cursor、Gemini CLI、Codex 等10+种AI编程助手。无需公网IP,手机发消息就能让AI写代码、改Bug、做数据分析,真正实现" anywhere, anytime "的AI开发体验。

    文章要点:
    • 超全平台覆盖:支持飞书、钉钉、Telegram、Slack、Discord、企业微信、LINE、QQ、微博、个人微信等11个主流聊天平台,大部分平台无需公网IP即可直连,手机/平板随时操控
    • 10+AI助手全家桶:完美桥接 Claude Code、Codex、Cursor Agent、Gemini CLI、Kimi CLI、Qoder CLI、OpenCode、iFlow CLI、Pi、Devin 等,还支持 ACP 协议兼容的任何新代理
    • 聊天里掌控一切:通过 /model 切换模型、/mode 调整权限模式、/dir 切换工作目录、/new 管理会话、/cron 设置定时任务,所有操作都在聊天窗口完成
    • 多Agent协同作战:支持在一个群聊里绑定多个AI机器人,让Claude和Gemini互相配合、接力完成任务,实现"AI团队"协作
    • 多模态与记忆:支持语音消息(STT/TTS)、图片截图、文件收发;Agent记忆持久化,/memory 指令随时读写,避免重复交代背景
    • Web管理后台:内置完整的Web Admin UI,支持项目CRUD、会话监控、定时任务编辑、Provider管理,5种语言界面,零配置上手
    • 安全隔离:支持 Linux/macOS 下的 OS-User 隔离运行,不同项目可用不同Unix用户启动Agent,配合 cc-connect doctor 做安全审计
    • 生命周期钩子:支持7种事件类型(消息收发、会话启停、定时触发、权限请求、错误)触发Shell命令或HTTP Webhook,方便集成CI/CD

    URL:https://github.com/chenhg5/cc-connect GitHub - chenhg5/cc-connect: Bridge local AI coding agents (Claude Code, Cursor, Gemini CLI, Codex) to messaging platforms (Feishu/Lark…

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

    《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

  13. 《Obscura:专为AI代理和爬虫打造的轻量级无头浏览器》

    《Obscura:专为AI代理和爬虫打造的轻量级无头浏览器》

    标签:#后端 #Rust #HeadlessBrowser #WebScraping #AI_Agent #Chrome_DevTools_Protocol #Puppeteer #Playwright #Anti_Detection

    总结:
    Obscura是一款基于Rust编写的开源无头浏览器引擎,专为大规模网页抓取和AI自动化场景设计。它通过内置V8引擎运行真实JavaScript,完整支持Chrome DevTools Protocol,可直接替代Puppeteer和Playwright依赖的Headless Chrome,在内存占用(30MB vs 200MB+)、启动速度和反检测能力上具有显著优势。

    文章要点:
    - **极致轻量,资源友好**:相比Headless Chrome动辄200MB+的内存占用和300MB+的体积,Obscura仅需30MB内存和70MB二进制文件,启动几乎瞬时完成,页面加载速度提升约6倍
    - **零依赖,开箱即用**:无需安装Chrome或Node.js,单个二进制文件即可运行,支持Linux、macOS(Intel/Apple Silicon)和Windows平台
    - **无缝兼容现有生态**:完整实现Chrome DevTools Protocol,可作为Puppeteer和Playwright的底层浏览器直接连接使用,现有爬虫脚本迁移成本低
    - **内置隐身模式**:自带反指纹追踪(随机化GPU、屏幕、Canvas等参数)和3520个域名级别的追踪器拦截,无需额外配置即可绕过常见反爬机制
    - **并行爬取能力**:提供`obscura scrape`命令支持多URL并发抓取,配合`--concurrency`参数可灵活控制worker数量,适合批量数据采集场景
    - **开源承诺与商业化路径**:核心引擎采用Apache 2.0协议且承诺永不功能阉割,同时正在开发托管版Obscura Cloud提供代理和基础设施服务

    文章URL:
    https://github.com/h4ckf0r0day/obscura GitHub - h4ckf0r0day/obscura: The headless browser for AI agents and web scraping

  14. 《大规模AI代码审查编排实践》

    《大规模AI代码审查编排实践》

    标签:#DevOps #AI辅助编程 #CodeReview #CI_CD #LLM #多智能体系统 #Cloudflare #OpenCode #插件架构

    总结:
    Cloudflare为解决代码审查瓶颈,放弃单一LLM直接审diff的噪音方案,转而基于开源代理OpenCode构建CI原生编排系统。该系统采用可组合插件架构,通过风险分级(Trivial/Lite/Full)动态调度最多7个专业审查智能体(安全、性能、质量等),由协调者代理去重、过滤并做出审批决策。系统已在数万MR上运行,能精准拦截真实漏洞,同时保留"break glass"人工逃生通道。

    文章要点:
    - **从噪音到精准**:早期直接把git diff塞给LLM的方案产生了大量幻觉和模糊建议,团队很快意识到需要专业化分工而非单一通用提示词
    - **插件化架构**:系统基于OpenCode构建,采用完全解耦的插件体系(GitLab、AI网关、合规检查、遥测等各自独立),通过`ConfigureContext` API贡献配置,最终组装成`opencode.json`
    - **多智能体协作**:最多同时启动7个专业审查者各司其职,协调者代理负责去重、重新分类、合理性验证,并按严格规则做出approve/approve_with_comments/unapprove/request_changes四级决策
    - **风险分级省成本**:按代码行数和文件数将MR分为Trivial/Lite/Full三级,小改动只派2个轻量代理且降级模型,安全相关文件永远触发Full审查,避免用大模型审typo
    - **工程细节满满**:使用JSONL流式处理避免内存爆炸;通过磁盘patch文件共享上下文节省7倍token;清理XML边界标签防止提示注入;30秒心跳日志消除"模型思考中"的误取消

    文章URL:https://blog.cloudflare.com/ai-code-review Orchestrating AI Code Review at scale

  15. 《MCP已死,CLI万岁》

    《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

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

    《为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 为 Agent 设计产品

  17. 《OpenAI Agents SDK:轻量级多智能体工作流框架》

    《OpenAI Agents SDK:轻量级多智能体工作流框架》

    标签:#AI #多智能体 #Python #OpenAI #MCP #智能体工作流 #LLM #实时语音 #沙箱环境

    总结:
    OpenAI Agents SDK 是一个轻量但功能强大的 Python 框架,用于构建多智能体工作流。它支持 OpenAI 的 Responses 和 Chat Completions API,同时兼容 100 多种其他 LLM,具有供应商无关性。框架围绕"智能体"这一核心概念展开,每个智能体都配备指令、工具、护栏和交接机制,让复杂任务可以像搭积木一样拆解协作。

    文章要点:
    - 智能体是核心乐高积木:每个智能体都自带"说明书"(指令)、"工具箱"(函数/MCP/托管工具)和"安全护栏"(输入输出校验),还能互相"交接"任务,像团队协作一样分工处理复杂流程
    - 沙箱智能体让AI真正"动手干活":0.14.0 版本新增的 Sandbox Agent 能在容器环境里操作文件系统、运行命令、打补丁,适合需要长时间执行且要保留工作状态的"重体力"任务
    - 人在回路,安全可控:内置了人类介入机制,在关键节点可以暂停流程等人来确认,避免AI"自作主张"搞出大新闻
    - 全链路可观测:自带 Tracing 追踪系统,能可视化查看每个智能体的思考过程、工具调用耗时和 Token 消耗,方便调试和优化
    - 不挑模型,兼容百家:虽然是 OpenAI 出品,但设计上保持中立,支持接入 100+ 种 LLM,包括通过 LiteLLM 等适配层接入国产模型
    - 实时语音也能玩:支持用 gpt-realtime-1.5 构建语音智能体,把实时语音能力也纳入多智能体协作体系

    文章URL:https://github.com/openai/openai-agents-python

  18. 《Claude架构图生成器:AI一键绘制专业系统架构图》

    《Claude架构图生成器:AI一键绘制专业系统架构图》

    标签:#AI工具 #Claude_Skill #架构可视化 #开发效率 #系统架构图

    总结:
    这是一款专为Claude AI设计的Skill工具,让用户只需用自然语言描述系统架构,即可生成精美的暗色系专业架构图。输出为独立的HTML/SVG文件,无需任何设计技能或额外软件,适合快速迭代和团队协作分享。

    文章要点:
    - 零门槛使用:不需要设计基础,用大白话描述系统组件和连接关系,Claude就能帮你画出专业级架构图
    - 多种输入方式:可以让AI分析代码库自动生成描述,也可以自己手写组件列表,还能直接问Claude要典型架构模板
    - 精美视觉风格:采用暗色主题(Slate-950背景),组件按类型着色(前端青色、后端翠绿、数据库紫色、云服务琥珀色),自带网格底纹和JetBrains Mono字体
    - 独立文件输出:生成单个HTML文件,内嵌CSS和SVG,任何浏览器都能直接打开,方便分享、打印或嵌入文档
    - 实时迭代优化:生成后可以继续在对话中要求修改,比如"加上Redis缓存"或"调整布局",Claude会即时更新图表
    - 多平台安装:支持Claude.ai网页版(Pro/Max/Team/Enterprise)、Claude Code CLI、以及Projects知识库三种方式
    - 丰富示例覆盖:内置Web应用(React+Node+PostgreSQL)、AWS无服务器(Lambda+API Gateway)、微服务(K8s+多语言服务)等典型场景模板

    文章URL:https://github.com/Cocoon-AI/architecture-diagram-generator GitHub - Cocoon-AI/architecture-diagram-generator: Generate beautiful dark-themed system architecture diagrams as standalone HTML/SVG…

  19. 《Vibe_Coding已死:Agent工程取而代之》

    《Vibe_Coding已死:Agent工程取而代之》

    标签:#AI #Agent #软件工程 #VibeCoding #多Agent协作

    总结:

    本文作者Collin Wilkins指出,"Vibe Coding"(凭感觉编程)这一由Karpathy提出的概念已被其本人"杀死"——现在的开发者99%时间不是在写代码,而是在编排Agent。作者分享了自己工作方式的转变:从一年前80%代码手写,到现在主要分解问题、分配Agent并审核输出。文章强调,2026年2月的四大模型发布都将多Agent编排作为核心能力,真正的差距在于工作流而非工具。

    文章要点:

    - Vibe Coding的致命缺陷:它只优化了代码生成速度,却忽视了后续环节——SonarSource调查显示AI代码占提交量的42%,但96%的开发者不完全信任它,仅48%会在提交前验证,审查负担真实存在且大多数团队根本没做
    - Agent工程的新范式:先规划和设计系统,定义边界和契约,再让Agent在约束内执行,像分布式系统工程一样处理Agent编排——同样的分解、组件间契约、可观测性
    - 多Agent成为主流:Claude的Agent团队用2000次协调会话构建了10万行C编译器,Kimi K2.5单个任务可运行100个子Agent进行1500次工具调用
    - 工作方式的彻底转变:作者现在每天的工作是分解问题、分配Agent、审核输出,"写代码"已不能描述他的日常工作
    - AI是动力工具而非替代品:会用AI的工程师交付更快,但只会用AI的工程师交付垃圾,关键是知道何时该提示、何时该思考
    - 瓶颈已转移:写代码不再是慢的部分,思考要构建什么、如何组合、什么会在规模下崩溃——这些才是耗时的地方
    - 文档化决策:LLM不存储上下文,如果想让AI助手在现有代码库上快速移动,它需要加载已记录的决策

    文章URL:

    https://buttondown.com/collinwilkins/archive/vibe-coding-is-dead-heres-what-replaced-it/ Vibe coding is dead. Here's what replaced it

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

    《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 Product management on the AI exponential