软技能 | 面条的草稿箱

AI 时代给年轻开发者的六条建议：写代码已经不够了有人问资深工程师 Matthias Endler，今天会给年轻开发者什么建议

Thu, 27 Aug 2026 02:52:30 GMT

AI 时代给年轻开发者的六条建议：写代码已经不够了

有人问资深工程师 Matthias Endler，今天会给年轻开发者什么建议。他的回答出人意料——几乎与代码无关。

学会做产品。 即使 LLM 能写大部分代码，市场仍然需要能理解用户需求、设计方案、根据反馈迭代的人。这项能力不随技术更替而贬值。

学会学习。 当信息唾手可得，真正稀缺的是批判性思维和基于数据做决策的能力。理解底层原理，远胜于死记硬背和简单的模式匹配。

学会沟通。 能把想法讲清楚、能激发他人协作的人，影响力是成倍放大的。别做独狼。

成为问题解决者。 当所有人都用同样的工具时，拉开差距的是你解决问题的速度和质量。选一个问题，深入领域，建立快速反馈循环，不断迭代。

拥有不止一项技能。 只会写代码的人很容易被替代。把编程能力和你真正感兴趣的领域结合起来——比如健身、金融、教育——这会大幅缩小你的竞争圈。好奇心驱动的探索比纯靠意志力更持久。

本质上什么都没变。 上一代人或许仅凭编码能力就能找到工作，但最优秀的开发者从来都不只是写代码。工具变强了，意味着"写代码"本身不再是护城河，你必须锻炼其他肌肉。

🔗 https://endler.dev/2026/advice-to-young-developers/

#开发者成长 #AI时代 #职业建议 #软技能 #产品思维

endler.dev

Advice to Young Developers

Someone recently asked me what advice I’d give …

BRAIN.md：为项目构建 AI 友好的决策记忆库在日常开发中，我们常用 README.md 告诉人类如何上手，用 AGENTS.md 指导 AI 怎么在项目中编写代码

Tue, 23 Jun 2026 16:23:30 GMT

BRAIN.md：为项目构建 AI 友好的决策记忆库

在日常开发中，我们常用 README.md 告诉人类如何上手，用 AGENTS.md 指导 AI 怎么在项目中编写代码。但项目的核心决策——比如“为什么选择 Postgres 而不是 MongoDB”、“架构设计的底层逻辑是什么”——应该记在哪里？

BRAIN.md 提出了一个全新的开源标准，旨在项目中建立一个专为 AI 和人类准备的决策记忆库。它不是零散的笔记，而是经过整理、权威的“决策级知识”。

核心特性

• 无外部依赖：无需运行任何后台服务或 MCP 服务器，仅基于纯 Markdown 文件约定和一个零依赖的本地 CLI 工具。
• Git 原生支持：所有知识和决策记录在项目根目录下的 brain/ 文件夹中，随代码一起进行版本控制。
• 结构化页面设计：核心页面包含 compiled_truth（当前权威结论）和 timeline（追加式的历史证据链）。AI 在读取时能瞬间掌握当前现状，并在需要时追溯历史决策过程。
• 智能体通用：目前已原生支持 Claude Code 和 Codex，通过简单的全局安装，即可让你的 AI 助手在开发时直接读取项目的“大脑”。

通过 BRAIN.md，AI 编程助手不仅是在盲目地写代码，而是能够真正理解项目背后的架构决策与技术取舍，从而产出更具上下文合理性的代码。

原链接：https://projectbrain.md/

#软件工程 #AI工具 #开发规范 #知识库 #项目管理

BRAIN.md

BRAIN.md — A persistent memory layer for your projects

An open, agent-agnostic standard for capturing a project's durable knowledge as plain Markdown — read and written through one small CLI. It lives in your repo and travels across agents, machines, and models.

聪明人的分工：让昂贵模型做规划，便宜模型去执行知名开源开发者 shadcn 刚刚开源了一个全新项目——improve

Wed, 10 Jun 2026 14:47:19 GMT

聪明人的分工：让昂贵模型做规划，便宜模型去执行

知名开源开发者 shadcn 刚刚开源了一个全新项目——improve。

这是一个非常巧妙的 Agent Skill，它的核心理念是：用你最聪明（也最昂贵）的 AI 模型来做高杠杆的脑力劳动（审计代码、写技术方案），然后把脏活累活（编写代码、跑测试）交给更便宜的 AI 模型去执行。

这个工具本身绝对不会直接修改你的一行代码，它的产出就是一份清晰、可执行的 Markdown 格式实施方案。

💡 它是如何工作的？

1. 项目审计 (/improve)：高阶模型会深度扫描并分析你的代码库，指出潜在的 Bug、性能瓶颈、安全隐患或技术债，并产出一份按“投入产出比”排序的发现清单。
2. 制定方案 (plans/)：当你挑选出需要解决的问题后，高阶模型会针对每个问题输出一份极其详尽的方案（Plan）。这些方案是“自包含”的，带有明确的验证命令、执行边界和异常中止条件（STOP conditions）。
3. 分发执行 (/improve execute <plan>)：你可以把这些高可读性的方案直接扔给任何便宜的轻量级 AI Agent。轻量级模型只需像个机械的执行者一样，按照步骤修改代码、运行测试，最后向你提交 Pull Request。

🚀 核心指令一览

• /improve：全局审计并输出优化点。
• /improve quick：快速扫描重点。
• /improve deep：对每个包、每个分类进行详尽审计。
• /improve plan <description>：跳过审计，直接为指定任务编写执行方案。
• /improve execute <plan>：派发给便宜的执行器模型并审核其成果。

安装方式

项目支持 Agent Skills 规范：

npx skills add shadcn/improve

https://github.com/shadcn/improve

#AI开发 #智能代理 #软件工程 #GitHub开源 #shadcn

Agent Skills

Agent Skills Overview - Agent Skills

A standardized way to give AI agents new capabilities and expertise.

慢即是快：如何利用 AI 写出更高质量的代码很多人认为，AI 编程的意义在于“快”——以最快的速度堆砌出勉强能运行的代码，然后匆忙合并发布

Fri, 29 May 2026 09:04:27 GMT

慢即是快：如何利用 AI 写出更高质量的代码

很多人认为，AI 编程的意义在于“快”——以最快的速度堆砌出勉强能运行的代码，然后匆忙合并发布。但这种“快”往往伴随着低质量和技术债。

实际上，大语言模型（LLM）非常灵活，我们完全可以反其道而行之：利用 AI，用更慢的速度写出质量更高的代码。

以下是这种“慢速 AI 编程”的核心思路：

• 让 AI 成为挑剔的 Review 助手：LLM 极其擅长寻找 Bug。你可以通过设置特定的“技能（Skills）”，让多个不同的模型（如 Claude 和 GPT）同时对你的 PR 进行审查并给 Bug 分级，通过交叉验证有效降低误报率。
• 主导修复与取舍：根据 AI 反馈的 Bug 列表，优先引导 AI 修复高危和中度漏洞。如果发现架构设计有根本性问题，甚至可以果断放弃现有的 PR 重新构思。
• 把“修 Bug”当成探索之旅：这种工作流虽然不会提升你的“开发速度”，但常常会帮你揪出代码库中早已存在的历史遗留 Bug。在解决这些问题的过程中，你会编写更多单测，深入理解系统的边缘情况。

这并不是那种吹嘘“10倍效率”的浮躁开发方式，而是一种更健康的编程状态：借力 AI，更严谨、更方法论地对待每一行代码，让代码库保持健康。

下次使用 AI 时，不妨慢下来，试着问问它：“我的这段代码可能会在哪里崩溃？”

https://nolanlawson.com/2026/05/25/using-ai-to-write-better-code-more-slowly/

#AI编程 #代码质量 #软件工程 #程序员

Read the Tea Leaves

Using AI to write better code more slowly

A lot of people seem convinced that the point of AI coding is to write low-quality code as fast as possible. Spew out barely-passable slop, open massive PRs, and merge them unvetted. Ship it! But t…

Claude Opus 4.5：让“能做”突然变得很容易作者分享了一个明显的转折：三个月前他还不相信“AI 代理能替代开发者”，但在体验 Claude Opus 4.5 后，他开始认为这件事正在发生——至少在相当一部分软件开发场景里

Mon, 12 Jan 2026 09:21:00 GMT

Claude Opus 4.5：让“能做”突然变得很容易

作者分享了一个明显的转折：三个月前他还不相信“AI 代理能替代开发者”，但在体验 Claude Opus 4.5 后，他开始认为这件事正在发生——至少在相当一部分软件开发场景里。

他用几个真实项目说明差异不在“会写代码”，而在于一次成功率、能自我迭代、能把复杂系统拼起来：

• Windows 右键图片格式转换工具：从文件资源管理器菜单到打包、安装/卸载脚本、发布网站、GitHub Actions 自动发布，整体接近“一次成型”。遇到报错会自己用 dotnet 构建、读错误、再修复。
• 录屏与简单剪辑工具：从类似 LICEcap 的录制开始，持续加到视频/图片编辑、裁剪、模糊、标注等功能，作者感叹“几小时就推进到很远”。
• AI 发帖工具（给小生意用）：iOS 端批量上传照片→AI 生成文案→定时发到 Facebook。后端涉及认证、存储、云函数、日志排错等一堆“胶水活”，但模型能通过 CLI 自己创建资源、查日志并修问题，还顺手做了管理后台。
• 订单与路线追踪：解析 Gmail 订单、规划路线、统计行驶时间（用于税务），作者强调：这种“手写很痛苦”的 Google/Firebase 集成，Opus 4.5 反而很顺。

文章也没有回避争议点：
作者承认自己并不完全理解这些应用“内部怎么搭起来的”（比如 Swift 不熟），但他的焦虑在减轻——因为当问题出现时，模型往往能定位并修复自己的 bug。于是他提出一个更激进的想法：代码也许不必主要面向人类可读，而是面向 LLM 可推理、可重写、可调试。

他甚至分享了一份自用的“AI-first 编码”提示词要点（概念层面）：

• 追求可预测、可调试、低耦合、入口清晰、控制流线性
• 少炫技抽象，减少层级与间接性
• 该删就删；重构也要分高/中/低优先级
• 安全需要更谨慎：API key、登录流程、敏感数据存储等不能盲信

结尾的态度是复杂的：既兴奋于“几小时能做出过去要几周/月的东西”，也沮丧于技能壁垒被压平。但他给出的建议很朴素：别等“都懂了”再开始，继续做东西，只是更快了；同时一定盯紧安全与密钥。

原文链接：https://burkeholland.github.io/posts/opus-4-5-change-everything/

#AI编程 #开发者工具 #Claude #软件工程 #生产力

Burke Holland

Opus 4.5 is going to change everything

Three months ago I would have dismissed claims that AI could replace developers. Today, after using Claude Opus 4.5, I believe AI coding agents can absolutely replace developers.

用好编码代理：Claude Code 2.0 的关键功能与“上下文工程”心法这篇长文把 Claude Code 2.0 当成一个“能动手的工作台”来拆解：不仅讲新功能，更强调如何用更好的流程与上下文管理，让代理稳定产出

Mon, 29 Dec 2025 00:50:48 GMT

用好编码代理：Claude Code 2.0 的关键功能与“上下文工程”心法

这篇长文把 Claude Code 2.0 当成一个“能动手的工作台”来拆解：不仅讲新功能，更强调如何用更好的流程与上下文管理，让代理稳定产出。

1) 先换个视角：你不是“追上更新”，而是“借力变强”

作者给了一个更实用的框架：

• 跟进工具：定期用、定期看更新（不必天天追）。
• 深耕领域：懂业务/系统设计/工程习惯，才能把“未知”变成“可提问、可验证”。
• 多玩多试：用不同模型做同一件事，快速建立直觉与边界。

2) Claude Code 2.0 值得关注的体验升级

一些偏“日常效率”的改动，叠加起来很实用：

• 语法高亮 + 更舒服的评审体验（作者因此更愿意在 CLI 里完成 review）
• /context 看上下文占用（建议复杂任务到 60% 左右就交接或压缩）
• Checkpointing（Esc+Esc / /rewind）：能回到某个检查点，回滚代码与对话
• Prompt suggestions / 历史搜索（Ctrl + R）：减少重复输入
• 更快的模糊文件搜索、队列导航、LSP 插件 等

3) Sub-agents（子代理）怎么用才不浪费

作者重点讲了“子代理不是魔法，是上下文与工具调用策略”：

• Explore：偏“只读搜索专家”，适合快速扫代码库、定位文件与线索。
• general-purpose / plan：更像“全能协作者”，通常会继承更多上下文。
• 关键提醒：不要只依赖 Explore 的摘要。摘要是“有损压缩”，重要文件最好让主代理再读一遍，让信息彼此“交叉注意力”，推理更稳。

4) 核心概念：Context Engineering（上下文工程）

代理之所以“烧 tokens”，不是它话多，而是：

• 工具调用本身 + 工具返回结果都会进入上下文；
• 上下文越长，检索与注意力越容易退化（作者称为 context rot / degradation）。

因此，上下文工程的目标是：

• 把最相关的信息放进来
• 控制“噪音”和重复指令
• 用清晰结构（计划、scratchpad、handoff）对抗跑偏

5) Hooks / Skills / MCP：把“提示词”产品化

作者把这三者放在一起看：

• Hooks：在对话生命周期某个节点自动触发脚本（比如 Stop 后自动提醒/继续下一步）。
• Skills：把领域指令与脚本做成“按需加载”的技能包，避免常驻系统提示导致上下文膨胀。
• MCP：连接外部工具/服务，但要注意“工具定义与中间结果”同样会吃上下文与成本；文中也提到用代码执行环境来降低这种膨胀的思路。

6) 一个很实战的工作流建议

作者的默认搭配大意是：

• Claude（Opus 4.5）偏执行与沟通：更像结对编程伙伴、反馈快。
• Codex 偏 review/找 bug：更克制、误报少，适合做“第二视角审查”。
• 面对难功能：先跑一个“可丢弃的草稿版本”，用它暴露模型的偏差，再用更精准的提示第二轮迭代。

原文链接：https://sankalp.bearblog.dev/my-experience-with-claude-code-20-and-how-to-get-better-at-using-coding-agents/

#ClaudeCode #编码代理 #上下文工程 #AI工具 #软件工程

sankalp's blog

A Guide to Claude Code 2.0 and getting better at using coding agents

A deep dive into Claude Code 2.0 features, Opus 4.5 workflows, and context engineering. Learn sub-agents, MCP servers, hooks, skills, and practical tips to boost your AI-assisted coding productivity.

Beyond Vibe Coding：AI 辅助开发完整指南Google 工程负责人 Addy Osmani 发布了一份全面的 AI 辅助开发指南，帮助开发者从"氛围编程"迈向生产级工程实践

Tue, 09 Dec 2025 15:10:26 GMT

Beyond Vibe Coding：AI 辅助开发完整指南

Google 工程负责人 Addy Osmani 发布了一份全面的 AI 辅助开发指南，帮助开发者从"氛围编程"迈向生产级工程实践。

核心观点

70% 问题：AI 能快速完成 70% 的功能原型，但剩余 30% 需要深厚的工程知识。修一个 bug 可能引入新问题，安全漏洞风险也不容忽视。

AI 开发光谱

• 自动补全：预测下一行代码
• 聊天机器人：自然语言问答
• 智能代理：自主处理多步骤任务

关键最佳实践

1️⃣ 先规划，后编码：让 AI 先提供架构方案，而非直接生成代码
2️⃣ 上下文为王：提供相关代码、设计文档、错误信息
3️⃣ 视觉辅助：截图胜过千言万语
4️⃣ 每次改动后测试：小步快跑，避免调试噩梦
5️⃣ 清晰描述意图：说明你想实现什么，而非仅描述表面症状

进阶技巧

• 提示工程：分解复杂任务、提供输入输出示例、善用角色扮演
• 上下文工程：像操作系统管理内存一样动态组装信息
• CLI 代理：Claude Code、Gemini CLI 等工具让终端成为强大的开发环境
• 多代理协作：不同专业代理并行处理任务

生产就绪原则

⚠️ 始终审查 AI 生成的代码——像审查初级开发者的代码一样
🔒 安全第一：输入验证、凭证管理、SQL 注入防护

未来的模型只会越来越强大。今天学会与 AI 协作，就是在为明天的工程实践做准备。

🔗 原文链接

#AI辅助开发 #VibeCoding #提示工程 #软件工程 #AddyOsmani

beyond.addy.ie

Beyond Vibe Coding - A Guide To AI-Assisted Development

Transform your development workflow with AI. Learn from Google Chrome's Engineering Leader how to master AI-assisted development and build better software.

规范驱动开发（SDD）的局限性随着 AI 编程的兴起，一种旧模式正在回归：编写详细的规范文档（Spec），然后期望 AI 能稳定地生成“正确”的代码

Thu, 04 Dec 2025 01:43:23 GMT

规范驱动开发（SDD）的局限性

随着 AI 编程的兴起，一种旧模式正在回归：编写详细的规范文档（Spec），然后期望 AI 能稳定地生成“正确”的代码。然而，这种规范驱动开发（Spec-Driven Development, SDD）在实践中往往会碰壁，原因与当年瀑布流开发模式失败类似——现实的变化总比规范文档快。

为什么规范驱动开发会失败？

1️⃣ 维护成本高昂

编写详尽的规范耗时巨大，而且在需求变更、约束调整时，保持规范与代码同步会产生巨大的维护成本，有时甚至会加倍工作量。

2️⃣ 规范无法反映所有上下文

规范描述了系统“做什么”，却无法解释“为什么”这么做。而“为什么”恰恰承载了关键背景信息，如技术权衡、团队在迭代中的学习、以及塑造解决方案的现实约束。

3️⃣ 过度规范化造成虚假的安全感

一份详细的规范会给人一种“一切尽在掌握”的错觉，但这往往是虚假的。软件开发是一个探索性过程，最重要的洞见往往在构建开始后才会出现。

4️⃣ 抽象层次错误

多数 SDD 工具关注的是实现的细节（“如何做”），比如字段定义、函数签名等，但更重要的是其背后的意图、约束和上下文（“为什么做”）。

什么才是真正重要的？—— 上下文工程

文章认为，AI 编程缺失的不是更详细的规范，而是更完善的上下文保留。AI 原生的开发流程应该：

• 从意图出发，明确要解决的问题和核心约束。
• 保持上下文的实时更新，让团队与 AI 保持同步。
• 让规范跟随代码库，成为动态演进的文档。
• 保留决策背后的“为什么”，而不仅仅是需求。

总而言之，对于需求稳定、边界清晰的领域，SDD 是有效的。但对于不断演化的探索性开发，上下文驱动的方法能更好地适应变化。

原文链接：https://isoform.ai/blog/the-limits-of-spec-driven-development

#AI #软件开发 #编程 #规范驱动开发

isoform.ai

The Limits of Spec-Driven Development - Isoform

We enable private equity firms and mid-market companies to build bespoke AI products 5x faster. Services include AI feature shipping, AI-led integration, data migration, and legacy system modernization.