Search: #软技能

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

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

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

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

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

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

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

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

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

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

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

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

    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 — A persistent memory layer for your projects

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

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

    知名开源开发者 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 Overview - Agent Skills

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

    慢即是快:如何利用 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编程 #代码质量 #软件工程 #程序员

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

    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 #软件工程 #生产力 Opus 4.5 is going to change everything

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

    用好编码代理: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工具 #软件工程

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

    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

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

    规范驱动开发(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 #软件开发 #编程 #规范驱动开发 The Limits of Spec-Driven Development - Isoform

1px