软件开发 | 面条的草稿箱

聪明人的分工：让昂贵模型做规划，便宜模型去执行知名开源开发者 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…

以“推理速度”交付：AI 编程把瓶颈从写代码变成了等模型这篇文章的核心观点很直接：AI 编程代理的能力跃迁后，作者交付软件的速度越来越不取决于“敲代码”，而更受限于两件事——模型推理时间（inference time）和少数真正需要深度思考的设计决策

Sun, 18 Jan 2026 02:00:29 GMT

以“推理速度”交付：AI 编程把瓶颈从写代码变成了等模型

这篇文章的核心观点很直接：AI 编程代理的能力跃迁后，作者交付软件的速度越来越不取决于“敲代码”，而更受限于两件事——模型推理时间（inference time）和少数真正需要深度思考的设计决策。

作者回顾了今年的变化：从最初“有些提示能一次跑通就很惊喜”，到现在“默认就该一次跑通”。在这种前提下，他甚至不再逐行读代码，而是看执行/修改流，关注系统结构是否合理、关键组件在哪里、整体是否按预期运转。

文章也给了不少可复用的工作方法：

• 先从 CLI 做起：任何产品先做命令行版本，方便代理直接运行验证，形成闭环；核心逻辑稳了再上 UI（比如扩展、App）。
• 关键决策是生态与依赖：语言/框架/依赖选对了，代理更容易一次完成；作者常用 TypeScript（Web）、Go（CLI）、Swift（macOS/iOS）。
• 更偏向“对话式协作”，而不是复杂流程：先和模型聊清楚、让它探索代码、共创方案，满意后再让它开干；他认为“Plan mode”更像旧时代不得已的手段。
• 对比 codex 与 Opus：codex 常会先长时间读代码再动手，虽然更慢但更稳，尤其适合大型功能和重构；Opus 更“急”，适合小改动但更容易漏上下文。
• 迭代式构建，不依赖回滚：不喜欢 checkpoint/频繁 revert，更多是让模型继续改、继续朝更好的方向“绕山而上”。
• 自动化与多项目并行：同时推进多个项目，用队列把想法排进去；瓶颈往往是人而不是编排系统。
• 配置思路：提高工具输出 token 上限、合理设置自动压缩阈值，让模型能一次读更多文件；作者强调新压缩机制更可靠，甚至像一次“复查”。

如果用一句话总结：当“写代码”越来越像可并行外包给代理的体力活，工程师的价值更集中在选型、架构、数据流、约束定义与验收标准上；而真正影响交付速度的，往往是推理等待时间和你是否想清楚要做什么。

原链接：https://steipete.me/posts/2025/shipping-at-inference-speed
#AI编程 #Codex #开发工作流 #效率工具 #软件工程

steipete.me

Shipping at Inference-Speed | Peter Steinberger

Why I stopped reading code and started watching it stream by.

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.

Agent-native 应用：把“功能”变成“结果”这篇文章提出一种新范式：与其把产品能力写成一堆固定功能，不如构建一个能反复调用工具、直到达成目标的“软件代理（agent）”

Mon, 12 Jan 2026 08:37:11 GMT

Agent-native 应用：把“功能”变成“结果”

这篇文章提出一种新范式：与其把产品能力写成一堆固定功能，不如构建一个能反复调用工具、直到达成目标的“软件代理（agent）”。核心在于：让代理拥有与用户同等的操作能力（UI 能做的，代理也能通过工具做到），并把工具设计成足够原子化的“积木”。这样，新功能往往不再是写代码，而是写一段描述结果的提示词；同时，用户提出的意外需求会推动系统“涌现”出新用法，并反过来指导你补齐工具与能力缺口。

五个核心原则

• 对等（Parity）：任何 UI 动作，代理都应能通过工具实现同样的结果；否则代理会卡死。
• 粒度（Granularity）：工具是原子能力；“功能”是代理在循环中用工具达成的结果。改行为优先改提示词，而不是重构代码。
• 可组合（Composability）：有了原子工具 + 对等能力，就能通过新提示词快速拼出新“功能”（开发者/用户都能做）。
• 涌现能力（Emergent capability）：用户会提你没设计过的需求；代理若能组合工具完成，就是新机会；若失败，则暴露工具缺口。
• 持续变好（Improvement over time）：通过沉淀上下文（context 文件）与迭代提示词，应用可在不发版的情况下持续变强。

落地方法（把原则变成工程实践）

• 先做“能力地图”：列出用户能做的事，逐项确认代理具备创建/读取/更新/删除（CRUD）能力，避免“能新建不能修改/删除”的断腿体验。
• 先原语、后领域工具：先用文件、bash、读写等基础工具跑通；再为高频模式加领域工具，用于效率、校验、术语锚定，但不要把“判断”写进工具里。
• 文件作为通用接口：文件天然可读、可审计、可迁移，代理也最擅长操作；内容放文件、结构化高频数据放数据库（或混合：文件作可读真相，DB 做索引与性能）。
• 明确完成信号：不要靠“看起来差不多了”判断结束；让工具/编排层返回明确的 complete 信号，避免无限循环或半成品。
• 透明的代理行为：工具调用、进度、状态变化要让 UI 可见；“沉默的代理”会让用户觉得坏了。
• 把“授权”做成产品能力：根据风险与可逆性决定自动执行还是强确认；尤其是发送邮件、发布内容等高风险动作。

对移动端的启示

• 移动应用容易被后台杀死，代理任务却可能很长：需要checkpoint/恢复机制，尽可能在每次工具结果后存档。
• iCloud 之类的文件同步能让多设备共享“同一工作区”，但要处理冲突与未下载文件等边界。

原链接：https://every.to/guides/agent-native

#AgentNative #软件代理 #AI产品 #工具调用 #产品架构

every.to

Agent-native Architectures

A technical guide for building applications where agents are first-class citizens

2025 年 AI 编程现状：效率在涨，工具与模型在分化Greptile 发布的《The State of AI Coding 2025》梳理了 AI 编程在 2025 年的关键趋势：工程产出显著提升，开发工具生态快速扩张，而不同大模型在“响应速度、吞吐、成本”上的取舍越来越清晰

Fri, 26 Dec 2025 13:19:39 GMT

2025 年 AI 编程现状：效率在涨，工具与模型在分化

Greptile 发布的《The State of AI Coding 2025》梳理了 AI 编程在 2025 年的关键趋势：工程产出显著提升，开发工具生态快速扩张，而不同大模型在“响应速度、吞吐、成本”上的取舍越来越清晰。

1) 工程效率：PR 更大，个人产出更高

• PR 规模变大：2025 年 3 月到 11 月，PR 的中位改动行数从 57 增至 76，约 +33%。
• 开发者产出上升：人均代码产出从 4,450 增至 7,839 行，约 +76%，AI 工具被视为“产能放大器”。
• 中型团队提升更明显：6–15 人团队的人均产出从 7,005 增至 13,227 行，约 +89%。
• 单文件改动更密：每个文件的改动行数中位数从 18 增至 22，约 +20%，说明 PR 不只变大，也更“集中”。

2) 工具采用：从“能用”到“形成标准层”

• 记忆/Memory 基建：mem0 以 59% 份额领跑（按 PyPI + npm 月下载量口径）。
• 向量数据库：没有绝对赢家；Weaviate 约 25%，其余多家在 10–25% 之间拉锯。
• AI 规则文件：CLAUDE.md 使用率 67%；不少团队多格式并存，且 17% 的仓库三种格式都用。
• AI SDK 增长：Anthropic SDK 以 43M 下载领先（约 8 倍增长）；Pydantic AI 增长 3.7× 到 6M。
• LLMOps：LiteLLM 月下载量增长 4× 至 41M（LangSmith 与 LangChain 安装存在绑定关系）。

3) 模型格局：生态差距在收敛

• SDK 下载量：OpenAI 约 130M 领先；Anthropic 自 2023 年 4 月起增长 1,547×；Google 约 13.6M。
• 差距缩小：OpenAI 与 Anthropic 的下载量比从 2024 年 1 月的 47:1，降至 2025 年 11 月的 4.2:1。

4) 作为“编程 Agent 后端”，模型各有侧重

报告用统一参数对多模型做了延迟、吞吐、成本等基准：

• 首 token 响应（TTFT）：Claude Sonnet/Opus（p50 < 2.5s）明显更快，更利于交互式编程保持“心流”。
• 生成吞吐：GPT-5 Codex / GPT-5.1 吞吐更高，长输出更快结束，利于并行跑更多 Agent/CI。
• 成本倍率（以 GPT-5 Codex = 1× 归一）：GPT-5 Codex ≈ GPT-5.1（1×）；Gemini 3 Pro（1.4×）；Sonnet 4.5（2×）；Opus 4.5（3.3×）。

结论很直接：选型不再是“谁最强”，而是你更在意 响应速度、吞吐效率，还是预算。

5) 研究方向：规模、上下文与 Agent 的“系统工程”

报告还汇总了 2025 年影响工具与应用的一批研究线索，包括：

• MoE 的效率设计（如 DeepSeek-V3：关注 KV cache、路由与训练信号密度）。
• 长上下文 vs RAG 的边界（不同数据结构下各有优势；以及 KV 级检索等新思路）。
• Agent 训练与检索策略（用 RL 学会“何时搜索”、如何管理长程记忆、如何降低噪声上下文干扰等）。

原文链接：https://www.greptile.com/state-of-ai-coding-2025

#AI编程 #开发效率 #LLM工具链 #模型评测 #软件工程趋势

Greptile

AI Code Review | Greptile | Merge 4X Faster, Catch 3X More Bugs

AI Code Reviews that understand your entire codebase. Automate PR reviews, catch bugs faster, improve code quality with AI-driven analysis. Try Greptile free!

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.

这篇文章探讨了“制造软件”的真正含义. 作者认为，这远不止是编写代码，而是一个发现、创造和交付价值的完整过程. 它始于深入理解问题和用户需求，终于创造出能为他人生活带来积极改变的工具.真正的挑战在于处理那些模糊不清、充满人性的部分：理解混乱的需求、平衡不同的观点、并在不断变化的环境中找到前进的道路.软件开发是一门手艺，它结合了解决问题的智慧和创造有用工具的乐趣. 从一个想法到最终产品，这个过程充满了挑战，但也带来了巨大的满足感.原文链接：Making Software#软件开发 #产品思维 #编程 #创造力

Mon, 24 Nov 2025 10:22:42 GMT

这篇文章探讨了“制造软件”的真正含义. 作者认为，这远不止是编写代码，而是一个发现、创造和交付价值的完整过程. 它始于深入理解问题和用户需求，终于创造出能为他人生活带来积极改变的工具.

真正的挑战在于处理那些模糊不清、充满人性的部分：理解混乱的需求、平衡不同的观点、并在不断变化的环境中找到前进的道路.

软件开发是一门手艺，它结合了解决问题的智慧和创造有用工具的乐趣. 从一个想法到最终产品，这个过程充满了挑战，但也带来了巨大的满足感.

原文链接：Making Software

#软件开发 #产品思维 #编程 #创造力