开发者体验 | 锤子前端

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

Sun, 20 Sep 2026 07:02:41 GMT

《与 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/

Human Who Codes

Five software engineering roles for working with AI - Human Who Codes

Software engineers can work with AI in different ways, from observing every change to managing an entire software factory.

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

Fri, 28 Aug 2026 01:09:36 GMT

《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

TanStack AI Enters the RC Phase | TanStack Blog

TanStack AI enters the release candidate phase. The architecture is locked in, with 24 providers, AG-UI, media generation, MCP, sandboxes, and persistence.

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

Tue, 21 Jul 2026 15:41:41 GMT

《深入理解 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

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

《深入理解 AI Agent：设计原理与工程实践》（李博杰著）开源主仓库：全书正文、编译版 PDF 与按章配套代码 - bojieli/ai-agent-book

《开源健身数据集：1324条多语言结构化运动数据与开发者脚手架》

Mon, 13 Jul 2026 06:04:17 GMT

《开源健身数据集：1324条多语言结构化运动数据与开发者脚手架》

标签：#数据科学 #健身 #开源数据集 #多语言 #开发者工具

总结：
这是一个面向开发者的健身运动结构化数据集，收录1324条运动记录，涵盖部位、器械、目标肌群等元数据，并提供英语、西班牙语、意大利语、土耳其语、俄语和中文六种语言的步骤说明。仓库还附带开箱即用的交互式浏览器和开发者配置向导（含SQL建表、API代码模板、LLM提示词），可快速搭建健身类应用后端。运动媒体文件（图片/GIF）因版权争议未包含，仅保留原始媒体ID引用。

文章要点：
1. 数据规模很扎实：一共1324条运动记录，覆盖从手臂、腿部到背部、核心等10个身体部位，器械类型也多达12种，其中约25%是自重训练，居家健身App也能直接用
2. 多语言支持很贴心：每条运动都配了英、西、意、土、俄、中六种语言的步骤说明，做国际化健身产品不用自己翻译了
3. 开发者体验拉满：仓库里塞了一个纯前端的运动浏览器（index.html）和一个配置向导（setup.html），能直接生成SQL建表语句、多语言API调用代码，还能一键复制LLM提示词让AI帮你搭后端
4. 版权处理很谨慎：图片和GIF动画因为存在多方权属争议，仓库里故意没打包，只留了media_id，需要的话可以通过原始CDN地址自行获取，避免法律风险
5. 数据结构很规范：JSON格式，字段包含ID、名称、部位、器械、目标肌群、协同肌群、六语说明、媒体引用等，还提供了TypeScript类型定义，类型安全直接拿捏

URL：https://github.com/hasaneyldrm/exercises-dataset

GitHub

GitHub - hasaneyldrm/exercises-dataset: 1,324-exercise fitness dataset — animation GIFs, 180×180 thumbnails, muscle-group & equipment…

1,324-exercise fitness dataset — animation GIFs, 180×180 thumbnails, muscle-group & equipment data, and step-by-step instructions in 6 languages. The exercise data layer behind the LogPress...

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

Fri, 12 Jun 2026 01:47:25 GMT

《现代工程价值观：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

cpojer.net

Modern Engineering Values

Modern engineering values.

《AI辅助工程师正在倦怠，这真的没问题吗？》

Fri, 29 May 2026 08:29:31 GMT

《AI辅助工程师正在倦怠，这真的没问题吗？》

标签：#软件工程 #AI辅助编程 #职业倦怠 #心理健康 #开发者体验 #生产力陷阱

总结：

文章揭示了AI辅助编程带来的隐性危机——AI倦怠。尽管AI让代码产出速度翻倍，但工程师们实际工作强度更高、成就感更低。文章通过"Ben和Alice"的认知负荷对比分析，指出AI将编程从"计划→ crafting→结果"的愉悦循环，变成了高强度审查和调试的消耗模式。同时探讨了失去代码库上下文、被动思考时间被挤压、虚假期望膨胀等日常 burnout 诱因，并提供了五条可落地的自救建议：认可自身价值、重构AI工作流、保留手工编码时间、严守工作边界、探索新兴趣领域。

文章要点：

1. AI让产出翻倍，却让工作强度翻倍——Alice用2小时完成Ben 4小时的活，但认知负荷极高且停不下来，最终4小时内做了2倍高强度工作，成就感反而更低

2. 编程的快乐循环被打破了——以前"计划→写代码→看到结果"的过程很治愈，现在变成"计划→直接看AI生成的结果"，跳过了最享受的crafting环节，只剩下累人的审查工作

3. 你的代码库正在"离开你"——AI代理帮你记住了架构和边界情况，你不再需要在脑中维护整个系统，久而久之直觉判断力下降， supervising一个自己不懂的系统超级累

4. 被动思考时间被AI偷走了——以前洗澡、散步时大脑后台会默默解题，现在跟AI几分钟来回就"搞定"了，但往往是次优解，后面还要返工

5. 虚假期望是个陷阱——AI初期进展顺利，客户/老板把冲刺速度当成基线，等瓶颈出现时你反而要拼命维持那个不可能的节奏

6. 审查瓶颈在转移压力——AI生成代码量远超单人审查能力， senior工程师被迫承担不成比例的风险和认知负荷，维护系统 sanity 越来越吃力

7. 五条自救建议超实用——包括写胜利日志、Plan模式优先、不连续做AI任务、保护手工编码时间、到点就停不补任务等，帮你把AI从"消耗品"变回"助手"

URL：

https://evilmartians.com/chronicles/ai-assisted-engineers-are-burning-out-is-this-fine

evilmartians.com

AI-assisted engineers are burning out, is this fine?—Martian Chronicles, Evil Martians’ team blog

AI-assisted code generation is not free. It comes with a hidden cost: burnout. Are we dangerously ignorant to this problem? And how can we cope with it? In this post, we discuss this question.

《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

《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