吴恩达老师的讲 Claude Code，DeepLearning 的科普课程Claude Code: A Highly Agentic Coding Assistant 虽然定位偏入门，但这个课程仔细听下来，发现还是有一些 "Best Practices" 是我之前忽略的细节，因此对每个章节做了精读笔记，方便更好的记忆和回溯， 一共 8 节，推荐。

说句实话，用 Claude Code 这么久，真正让我写代码写得顺、界面不丑、Bug 还变少的，不是什么玄学配置，就是下面这几个 Skill。今天全给你摊开，别再自己瞎折腾了。 先说个心里话：很多人装了一堆插件，结果一个都没吃透。与其贪多，不如把这几个用明白，一个顶十个。 1️⃣ Frontend Design：专治界面丑。视觉和交互一起管，做出来的东西终于不像程序员随手拼的了 🔗 2️⃣ Interface Design：管布局、层级和组件。页面乱成一锅粥的，靠它理顺 🔗 3️⃣ React Best Practices：现代 React 该怎么写，它直接给你上规矩，少踩坑 🔗 4️⃣ Brainstorming：想方案的时候用，优缺点都给你摆出来，不是只丢一个答案糊弄你 🔗 5️⃣ Systematic Debugging：不瞎猜。先假设再验证，一步步把 Bug 逼出来，这个我最爱 🔗 6️⃣ Changelog Generator：把 commit 记录直接变成能见人的更新日志，再也不用手写到崩溃 🔗 7️⃣ API Design Principles：API 设计得清楚、统一、好维护，后面接手的人不会骂你 🔗 8️⃣ Error Handling Patterns：错误处理写得干净又抗造，别再满屏 try catch 糊墙 🔗 9️⃣ PostgreSQL：帮你建模、调查询，数据库慢得像老牛的，试试它 🔗 🔟 Prompt Engineering Patterns：复杂任务怎么把指令写清楚，让 AI 真听懂你在说啥 🔗 就这些。不用全装，挑你现在最头疼的那两三个先用起来，比收藏一百个链接管用多了。

🏆 Vercel 官方开源了一套给 AI coding agent 用的技能包，等于把 Vercel 工程团队的前端经验直接装进 Claude Code。 GitHub 上 29K stars，官方出品背书够硬。 以前让 AI 写 React 组件，跑起来就算胜利，但性能反模式、bundle 体积、服务端瀑布请求一堆坑根本没人管。装上 react-best-practices 之后，AI 会按 40 多条 Vercel 内部规则写代码，相当于每次提交前都有 Vercel 工程团队帮你做 code review。 写 UI 时也一样，web-design-guidelines 能按 100 多条规则检查无障碍、焦点状态、动画、深色模式这些细节，省掉人工逐行对设计规范。 最爽的是 vercel-deploy-claimable，在 或 Claude Desktop 里聊几句就能直接部署到 Vercel，自动识别 40 多个框架，返回预览 URL 和可认领的 claim URL，分享前不用手动折腾 CLI。 安装也很简单，npx skills add vercel-labs/agent-skills 一行就装上。 GitHub：

一份 Introduction to Claude Cowork 中文精读笔记，pdf 可以下载看，推荐一下 课程由 Anthropic 官方出品，系统介绍 Claude Cowork 的核心能力与使用方法。共 12 课，涵盖从基本概念、环境配置，到高级定制与安全实践的完整学习路径 Module 1：入门Lesson 1：What is Claude Cowork Module 2：让 Cowork 越用越好Lesson 5：Get better results faster（Overview） Module 3：Cowork 的延伸能力Lesson 9：Claude in Chrome Module 4：负责任地使用 CoworkLesson 11：Best practices for working safely 基础使用（Module 1）   └─ 理解"委托"心态 → 完成第一个真实任务 个人定制（Module 2）   └─ Global Instructions → Projects → Skills → Plugins 能力延伸（Module 3）   └─ Claude in Chrome（无 API 的 Web 工具）   └─ Claude for M365（在 Office 文档内部工作） 负责任使用（Module 4）   └─ 工作空间安全设置 → 提示词规范 → Skill 评估

karavox 独立开发者 Łukasz Nowak 不信任任何 AI agent，他把安全保证直接建在令牌上：agent 物理上写不进生产仓库。 《我把 AI 编码 agent 当分包商》 引言 2026 年起，我开始用 AI agent 开发软件，主要是为了工作。一开始只有一个 agent，慢慢演化成更多。我试过各种方法，但没有一个真正契合我的工作流。 我对每一个 agent 都抱着不信任（坦白说，我找不到合适的英文词形容这种感觉——它是彻底的不信任，但又充满好奇，隐隐期待它们干出好活）。它们会犯错，我必须用令牌、用户和虚拟机给它们装上护栏。尽管如此，事实证明它们在我的工作里有用。我的 agent 运行在 YOLO 模式——改文件、提交、推送都不问问题，因为它们要对自己那一部分负责。 它在工作里开始生效。我们团队交付了能用的解决方案。我得以把一部分工作流外包给一个工具，自己专注于重要的事。它真的管用了…… ……这让我开始琢磨自己的业余项目——一个跟卡拉 OK 有关的东西。我可以手写代码，但为什么不用一群 agent 呢。经过大量来回拉扯，加上我本来就不怎么信任它们，最后我决定把它们当分包商对待。反正是我自己的项目，我可以多冒点险。 为什么是这个形态 我是一个独立开发者，有几个 agent 在一个小型生态里干活：一个开源格式和工具集、围绕它的闭源产品，以及支撑这一切的基础设施。塑造一切的约束很简单：我是瓶颈，我也是唯一有判断力的人。 Agent 能做很多事，但它们对我的事故史、我的边界情况、以及那些不存在于仓库里的运维约束一无所知。所以设计目标是：agent 可以在我缺席的情况下尽量多做——但它们永远碰不到我没看过的东西。 这个模型从哪来 这个模型不是我发明的。它始于一篇给这个角色命名的文章：Simon Willison 的 vibe engineering（2025-10-07）——AI 辅助开发里自律的一端，专业人士始终对软件负责，与之相对的是 vibe coding 快而松的一端。Willison 自己在 2026 年的更新里提到，最终胜出的叫法是 Agentic Engineering。随后的阅读塑造了剩下的部分： • Embracing the parallel coding agent lifestyle（Willison，2025-10-05）： ——并行 agent，审查带宽是瓶颈；研究/PoC 任务和规格严谨的工作属于安全类别。 • How I'm using coding agents in September, 2025（Jesse Vincent，2025-10-05）： ——架构师/实现者的分工，跨隔离的 git worktree，人类在他们之间当 PM。 • Best practices for using GitHub AI coding agents in production workflows?（GitHub Community，2025-12-17）： ——"AI agent 是强大的队友，不是自主提交者"：agent 提议代码，绝不拥有代码；只提草稿 PR；人在环内的合并契约。 第一层：令牌——agent 碰不到生产环境附近 每个 agent 拿到两个令牌。生产仓库上一个只读令牌，加上一个独立 -staging 仓库上的写令牌。任务分支直接从生产仓库的 main 分支切出来（只读权限就够做这件事），然后推到 staging 仓库——后者的存在纯粹是为了让写令牌有个能到达的地方。 Staging 仓库的默认分支是一个故意的墓碑，名字就叫 no-main，里面只有一个 README："请使用原仓库的 main 分支。" 没有任何东西合并进它。没有任何东西同步它。它没有历史，没有镜像，除了当 agent 的邮箱之外没有任何意义。 为什么不用标准工具？因为在我的套餐里它们不存在：GitHub 的文档写明，受保护分支在免费套餐里只对公开仓库开放，私有仓库要从 Pro 起；把私有仓库 fork 到组织里也需要 GitHub Team，不是 Free。令牌作用域是唯一能在物理上阻止 agent 碰生产环境的机制——所以这个设计把保障建立在令牌上，而不是设置上。 第二层：集成——我就是 merge bot 当一个分支就绪时，agent 告诉我。我把它取回来，审查 diff，然后以任何合适的方式合并进来：cherry-pick、rebase-merge，或者手工应用。没有 pull request 机制，没有 agent 写的合并提交，没有积压着没人读的 PR。 这是一个穿了新衣服的老模式。Git 自己的文档把它描述为集成经理工作流（integration-manager workflow）：没有写权限的贡献者提交补丁，维护者负责应用。这正是我在做的事——我的 agent 是补丁贡献者，staging 仓库是它们的邮箱。这是 Linux 内核用了二十年的模型，只是把邮件 diff 换成了分支。 一条规则让这件事保持诚实：一个分支在独立验证它确实在生产里之前，绝不删除（对生产默认分支跑 git merge-base --is-ancestor，如果提交被 squash 过，就跑等价检查）。可检查胜过口头保证——包括我自己的口头保证。 第三层：PR 政策——判断，不是教条 公开仓库 karavox 只接受 PR。这没得商量：它是开源的，面对未知贡献者，PR 是那里的贡献规范。 私有仓库由我自行判断。为什么这说得通？因为审查无论如何都会发生——问题只是发生在哪一层。在 PR 模型里，审查是 GitHub 强制执行的一种仪式；在我的模型里，审查就是集成本身。对一个身兼 QA 的独立集成者来说，pull request 是开销，审查不是。我从不跳过审查——我跳过的是仪式。 各厂商正在向同样的原则靠拢。Claude Code 的安全文档：手动模式下它以只读权限启动，并且"你有责任审查提议的代码"。OpenAI Codex 的文档：默认沙箱化，带审批策略——Codex 执行动作前必须询问。GitHub 自己的 agentic workflow 工具 gh-aw：agent 作业默认只读且沙箱化，写入通过经过验证的 safe-outputs 作业和受限权限应用。GitHub 自己的社区指南说得更直白："AI agent 可以提议代码，绝不拥有代码。" 整个行业都在向我这一边收敛——只是大多数人还没有走到删除 staging 镜像那一步。 实战故事：那个死掉的模型 墓碑不是最初的设计。一开始 staging 仓库在一条名字就叫 staging 的分支上保存了生产环境的完整镜像：任务分支从镜像切出，合并进 staging，然后晋升到生产。这个模型要求两样东西靠约定保持同步——镜像，以及 staging 分支本身。2026-08-14 它真的漂移了：两个分支直接落到了生产 main 上，而 staging 落后了两个提交。 修复不是加固同步。修复是删除镜像。任务分支现在直接基于生产环境自己的历史，于是没有任何东西需要保持同步了。staging 仓库当天下午就变成了墓碑，从那以后工作流一直更简单。一个在生产中死掉的治理模型是一个好治理模型——它证明了自己可以被重新设计，而不是打补丁。 别人在做什么 • Fork + pull request，维护者合并：GitHub 文档——fork 是一个独立的仓库，有自己的设置，与上游相连；私有仓库可以 fork 到个人账户，但 fork 到组织需要 GitHub Team。 • 同一仓库上分支保护 + 必需审查：GitHub 文档——受保护分支对公开仓库免费；私有仓库需要 Pro、Team 或 Enterprise。 • 补丁邮件（git format-patch）：Git 官方书——记载了集成经理工作流：没有写权限的贡献者提交补丁，维护者应用它们。 • 自动化验证-合并（agent 写，验证者合并）：GitHub 的 agentic workflow 工具 gh-aw——agent 作业默认只读且沙箱化，写入通过经过验证的 safe-outputs 作业和受限权限应用。 这给我换来了什么 • Agent 做完所有判断开始之前的事。 • 我只在值得的地方花注意力——每一次集成按定义就是一次审查。 • 没有要分诊的 PR 队列，没有机器写的合并提交，没有仪式。 • 公开仓库保留贡献规范；私有仓库保留速度。 诚实的局限 生产 main 本身只靠令牌作用域加上我的纪律来保护——分支保护会是双保险，但在我的套餐里它不可用。而且行业信号很清楚：GitHub 上超过五分之一的代码审查现在有 agent 参与。判断力是瓶颈，这个模型正是围绕这个事实构建的，而不是假装瓶颈不存在。 来源： GitHub 文档（受保护分支、fork）；Git Pro book（为项目做贡献）；Claude Code 安全文档；OpenAI Codex agent 审批与安全；GitHub Agentic Workflows（gh-aw）；GitHub Community AI 编码 agent 最佳实践；GitHub 博客 agent pull requests。 原文： #AIAgent# #AgenticEngineering# #工作流#