[翻译]70% 的问题: 关于人工智能辅助编码的残酷事实

The 70% problem: Hard truths about AI-assisted coding

A field guide and why we need to rethink our expectations

文章出处: The 70% problem: Hard truths about AI-assisted coding

相关: The 70% problem: Hard truths about AI-assisted coding | Hacker News

一. 前言

编程和编码两个词的区别(豆包编写)

在日常语境中, " 编程" ( Programming) 和 " 编码" ( Coding) 经常被互换使用, 但严格来讲, 它们存在一定的区别, 具体如下:

概念范畴

• 编程
  • 编程是一个更广泛, 更全面的概念, 它涵盖了从理解问题, 设计解决方案到最终实现代码并进行测试, 维护的整个软件开发过程.
  • 编程不仅仅涉及到代码的编写, 还包括需求分析, 算法设计, 软件架构规划, 系统测试, 项目管理等多个方面.
  • 例如开发一个电商网站, 编程人员需要先与客户沟通, 明确网站的功能需求, 如商品展示, 购物车, 订单结算等; 然后设计数据库结构和系统架构; 接着进行代码编写; 最后对网站进行测试, 修复发现的漏洞和问题, 并在上线后持续维护和优化.
• 编码
  • 编码主要侧重于将设计好的算法或解决方案用具体的编程语言表达出来, 是编程过程中的一个重要环节.
  • 它更关注于代码的语法, 规则和实现细节, 通过编写一行行的代码来实现特定的功能.
  • 例如根据已经设计好的排序算法, 使用 Python 语言将其实现为具体的代码

1.1 作者

AddyOsmani.com

Addy Osmani is an Irish Software Engineer and leader currently working on the Google Chrome web browser. A developer for 20+ years, he has worked at Google for over twelve years, focused on making the web fast and better for users and web developers. He previously worked on Fortune 500 sites. Addy is the author of a number of books including Learning JavaScript Design Patterns, Leading Effective Engineering Teams, Stoic Mind and Image Optimization. You can try his recent apps.You can find him on LinkedIn, Twitter or TikTok. He's given over 175 talks worldwide. You can find Addy's writing on his blog, Substack and on LeadDev.

资深工程师, 现为在Google chrome项目主管.

1.2 文中提及的AI产品

文中作者提及的主要 ai 编程辅助产品:

• v0 by Vercel
• bolt
• Cursor - The AI Code Editor
• GitHub Copilot - Your AI pair programmer - GitHub
• screenshot-to-code
• Windsurf AI IDE - 下一代智能代码编辑器 | 超越 Cursor 和传统 IDE
• Cline - Autonomous Coding Agent for VSCode

1.3 个人简单看法

目前个人所用的ai辅助编程工具为: 通义灵码_智能编码助手-阿里云/通义tongyi.ai_你的全能AI助手-通义千问, 作为编辑器的扩展在vscode和pycharm两个编辑器上使用.

除此之外, 还有web ai, 当然除此之外, 也会使用chatgpt, deepseek 等

• 文心一言
• 豆包 - 字节跳动旗下 AI 智能助手

对于使用 ai 辅助编程, 个人感觉这些方面的确已经很大程度改变了编写代码的作业流程:

• 代码重构, 可以认为这是ai的绝对强点, 实际上代码的重构过程对于ai而言, 可视作使用自有代码对模型进行了自定义的微调, 经过二次训练的ai可以非常精准地给出如代码注释, 重构的新代码等. 这对于拥有巨量优质代码的科技公司或者是个人, 这种经过针对性训练的ai将表现的完全和通用型的完全的差异, 深圳更进一步, 假如某种开发语言, 是以ai 为核心构建的呢?!
• 产品原型, 就是初始的可实现相关功能的初始代码, 也许代码存在各种小问题, 但是通过快速构建出原型, 然后在这个基础之上进行快速的迭代.
• 构思和学习新的代码, 在很多时候在构思新的代码时, 没有明确的方向, 可以通过ai预先生成的代码来探索实现的可能, 同时也能够对他人的代码的结构来学习新的内容.

对于各种媒体渲染的 ai 可上天, 可入海, 目前暂未感受到如此威力, 反而需要重点注意的是本文所提及的纸牌屋代码, 那种看似可行的代码, 往往存在隐性问题, 而这些问题的成本远远超过手动编写的代码.

但需要重点关注的是ai chat 转为 ai agent这一重大的变化.

为什么AI这么能编？深度解析大模型的“幻觉”机制 - 少数派, 从这个角度来看, 使用 ai 在某些需要专业化能力的领域, 新手更容易进入 ai 编织的幻象中去.

1.4 本文摘要

摘要为 百度文心一言 撰写:

1. 人工智能辅助编码现状
   • 开发人员使用AI工具进行开发的两种模式: 引导者和迭代器. 引导者利用AI快速启动新项目, 迭代器则在日常开发中使用AI进行代码完成, 重构等任务.
2. AI辅助编码的问题
   • 隐性成本: 虽然AI加速开发, 但高级工程师需重构代码, 处理边缘情况等, 初级工程师则可能构建脆弱系统.
   • 知识悖论: AI对经验丰富的开发人员帮助更大, 初级人员易接受不正确或过时的解决方案.
   • 70%问题: 非工程师使用AI能快速完成70%工作, 但剩余的30%变得困难.
3. 有效方法
   • " AI初稿" 模式: AI生成代码后, 手动审查和重构.
   • " 持续对话" 模式: 保持与AI的紧密反馈回路.
   • " 信任但要核实" 模式: 使用AI进行初始代码生成, 但手动审查关键路径和边缘情况.
4. 未来展望
   • 代理软件工程的兴起: AI将更具自主性, 成为开发人员的合作者.
   • 英语优先的开发环境: 清晰思考和自然语言沟通变得重要.
5. 软件质量回归
   • AI快速构建软件可能导致质量下降, 需要人类判断来处理极端情况, 确保安全性和性能.
6. 个人软件复兴
   • 随着AI处理常规任务, 开发人员可专注于用户体验和极端情况处理, 推动个人软件复兴.

文章揭示了人工智能辅助编码的隐性成本和问题, 提出了有效方法, 并展望了AI在软件开发中的未来趋势. 同时, 强调了保持工程纪律和人类判断的重要性, 以及个人软件开发的复兴机遇.

---

简单归纳, ai对于编程有非常大的作用, 如大大简化重复性工作, 极短时间内生成产品原型等, 但是需要注意 ai 辅助编程的一些问题, 如作者所提及的"纸牌屋代码", 即可看而不可用, 以及这些问题导致的隐性成本. 同时ai辅助编程总体对于老手也许更有帮助, 但对于新手, 也许ai辅助编程会起到反作用.

二. 正文

After spending the last few years embedded in AI-assisted development, I've noticed a fascinating pattern. While engineers report being dramatically more productive with AI, the actual software we use daily doesn’t seem like it’s getting noticeably better. What's going on here?

I think I know why, and the answer reveals some fundamental truths about software development that we need to reckon with. Let me share what I've learned.

在过去几年深入研究人工智能辅助开发后, 我注意到一个有趣的现象. 虽然工程师报告称人工智能显著提高了他们的工作效率, 但我们日常使用的实际软件似乎并没有得到明显的改善. 这是怎么回事呢?

译者注: 很常见的, ai很多时候生成各种有问题的代码, 有时这些代码简单运行时就报错, 有一些却是在特定条件下出现问题, 修复这种问题, 也许花费的时间远超个人所写的代码.

我想我知道原因, 答案揭示了我们需要考虑的一些软件开发基本事实. 让我分享我所学到的东西.

三. 开发者实际上是如何使用 AI 的

How developers are actually using AI

I've observed two distinct patterns in how teams are leveraging AI for development. Let's call them the "bootstrappers" and the "iterators." Both are helping engineers (and even non-technical users) reduce the gap from idea to execution (or MVP).

我观察到, 团队在利用 AI 进行开发时, 主要呈现两种模式- - " 启动者(bootstrappers) " 和" 迭代者(iterators) " . 这两种模式都在帮助工程师( 甚至非技术用户) 缩小从想法到执行( 或 MVP) 的距离

3.1 启动者: 从零到 MVP

The Bootstrappers: Zero to MVP

Tools like Bolt, v0, and screenshot-to-code AI are revolutionizing how we bootstrap new projects. These teams typically:

• Start with a design or rough concept
• Use AI to generate a complete initial codebase
• Get a working prototype in hours or days instead of weeks
• Focus on rapid validation and iteration

The results can be impressive. I recently watched a solo developer use Bolt to turn a Figma design into a working web app in next to no time. It wasn't production-ready, but it was good enough to get very initial user feedback.

像Bolt, v0 以及" 截图转代码" 一类 AI 工具正在彻底改变我们启动新项目的方式. 这些团队通常会:

• 从一个设计或大致概念开始
• 使用 AI 生成一个完整的初始代码库
• 在数小时或数天内就能拿到一个可用的原型, 而不是几周
• 专注于快速验证和迭代

成果常常令人惊叹. 我最近看到一位独立开发者使用 Bolt, 只花很短时间就把 Figma 设计变成了可运行的 Web 应用. 虽然它还不具备生产环境所需的完备性, 但足以收集最初的用户反馈.

3.2 迭代者: 日常开发

The Iterators: daily development

The second camp uses tools like Cursor, Cline, Copilot, and WindSurf for their daily development workflow. This is less flashy but potentially more transformative. These developers are:

• Using AI for code completion and suggestions
• Leveraging AI for complex refactoring tasks
• Generating tests and documentation
• Using AI as a "pair programmer" for problem-solving

But here's the catch: while both approaches can dramatically accelerate development, they come with hidden costs that aren't immediately obvious.

第二种模式是使用像 Cursor, Cline, Copilot 和 WindSurf 这样的工具来辅助日常开发工作. 这种做法没那么耀眼, 但可能更具变革性. 这些开发者通常会:

• 用 AI 完成代码补全和建议
• 利用 AI 进行复杂的重构任务
• 生成测试和文档
• 将 AI 当作" 结对程序员" 来共同解决问题

但问题在于, 尽管这两种模式都能极大地加快开发进度, 却有一些隐性的成本并不那么明显.

四. " AI速度" 的隐形成本

The hidden cost of "AI Speed"

When you watch a senior engineer work with AI tools like Cursor or Copilot, it looks like magic. They can scaffold entire features in minutes, complete with tests and documentation. But watch carefully, and you'll notice something crucial: They're not just accepting what the AI suggests. They're constantly:

• Refactoring the generated code into smaller, focused modules
• Adding edge case handling the AI missed
• Strengthening type definitions and interfaces
• Questioning architectural decisions
• Adding comprehensive error handling

In other words, they're applying years of hard-won engineering wisdom to shape and constrain the AI's output. The AI is accelerating their implementation, but their expertise is what keeps the code maintainable.

Junior engineers often miss these crucial steps. They accept the AI's output more readily, leading to what I call "house of cards code" – it looks complete but collapses under real-world pressure.

当你看着一位资深工程师使用 Cursor 或 Copilot 等 AI 工具时, 会觉得非常神奇. 他们能在短短几分钟内搭起完整的功能结构, 还包括测试和文档. 但如果你仔细观察, 就会发现他们实际上在不停地:

• 将生成的代码重构为更小, 更专注的模块
• 补充 AI 漏掉的边界情况
• 加强类型定义和接口设计
• 质疑架构决策
• 添加健全的错误处理

换言之, 他们是在用自己多年积累的工程经验, 对 AI 的输出进行(二次)塑造和约束. AI 加快了他们的实现过程, 但真正让代码可维护的是他们的专业知识.

初级工程师往往会忽视这些关键步骤. 他们更容易接受 AI 的输出, 导致我称之为"纸牌屋代码" 的现象 - - 看起来完整, 但在实际场景下一碰就倒.

五. 知识悖论

The knowledge paradox

Here's the most counterintuitive thing I've discovered: AI tools help experienced developers more than beginners. This seems backward – shouldn't AI democratize coding?

The reality is that AI is like having a very eager junior developer on your team. They can write code quickly, but they need constant supervision and correction. The more you know, the better you can guide them.

This creates what I call the "knowledge paradox":

• Seniors use AI to accelerate what they already know how to do
• Juniors try to use AI to learn what to do
• The results differ dramatically

I've watched senior engineers use AI to:

• Rapidly prototype ideas they already understand
• Generate basic implementations they can then refine
• Explore alternative approaches to known problems
• Automate routine coding tasks

Meanwhile, juniors often:

• Accept incorrect or outdated solutions
• Miss critical security and performance considerations
• Struggle to debug AI-generated code
• Build fragile systems they don't fully understand

我发现的最耐人寻味的一点在于: AI 工具对有经验的开发者帮助更大, 而不是对新手更大. 这似乎跟我们期待的相反- - 难道 AI 不应该让编程更加民主化吗?

事实上, AI 就像你团队里一个非常热情的初级开发者. 他们可以很快写出代码, 但需要持续的监督和纠正. 你对开发了解得越深, 就越能更好地引导 AI.

**这就产生了我所说的" 知识悖论" **:

• 资深开发者使用 AI 来加速他们"已经知道怎么做" 的事情
• 初级开发者试图用 AI 来" 学会如何做"
• 二者结果大相径庭

我见过的资深开发者会:

• 快速做出他们心中已有把握的原型
• 让 AI 生成初步实现, 然后进行精炼
• 探索已知问题的不同解决方案
• 自动化各种常规编码任务

而初级开发者往往会:

• 接受不正确或已过时的解决方案
• 忽视关键的安全和性能考量
• 调试 AI 生成的代码时感到困难
• 构建出脆弱而自己并不真正理解的系统

六. 70% 问题: AI 的学习曲线悖论

The 70% problem: AI's learning curve paradox

A tweet that recently caught my eye perfectly captures what I've been observing in the field: Non-engineers using AI for coding find themselves hitting a frustrating wall. They can get 70% of the way there surprisingly quickly, but that final 30% becomes an exercise in diminishing returns.

This "70% problem" reveals something crucial about the current state of AI-assisted development. The initial progress feels magical - you can describe what you want, and AI tools like v0 or Bolt will generate a working prototype that looks impressive. But then reality sets in.

最近我看到一条 推文 完美诠释了我在实践中观察到的现象: 非专业工程师在使用 AI 进行编码时, 会很快实现 70% 的功能, 但余下的 30% 却陷入痛苦的" 边际收益递减" 之中.

作为一个非专业工程师, 以下是我对使用AI编程的真实感受:

它能帮你完成70%的工作, 但最后30%令人非常沮丧. 每前进一步, 就会因为新的bug和问题而后退两步.

如果我知道代码是如何运作的, 也许我自己就能修复这些问题. 但由于我不懂, 我开始怀疑自己是否真的学到了什么.

这个"70% 问题" 揭示了当前 AI 辅助开发的一个关键点. 最初的进展令人惊叹- - 你描述你想要的功能, 工具( 如 v0 或 Bolt) 就能生成一个看上去相当不错的原型. 但接下来, 现实(问题)就会浮现.

6.1 " 后退两步" 的模式

The two steps back pattern

What typically happens next follows a predictable pattern:

• You try to fix a small bug
• The AI suggests a change that seems reasonable
• This fix breaks something else
• You ask AI to fix the new issue
• This creates two more problems
• Rinse and repeat

This cycle is particularly painful for non-engineers because they lack the mental models to understand what's actually going wrong. When an experienced developer encounters a bug, they can reason about potential causes and solutions based on years of pattern recognition. Without this background, you're essentially playing whack-a-mole with code you don't fully understand.

接下来通常会出现一个很典型的循环:

• 你想修复一个小 Bug
• AI 给出一个看似合理的修改建议
• 结果这个修改又引发了其他问题
• 你再让 AI 修复新问题
• 于是又产生更多问题
• 如此反复循环

对于非专业工程师来说, 这种循环尤其痛苦, 因为他们缺少必要的心智模型来理解到底哪里出了问题. 当一名有经验的开发者遇到 Bug 时, 他们会基于自己多年的模式识别来推测可能的原因和解决方案. 但如果你没有这种背景, 那就只能像打地鼠一样, 不停敲击那些自己并不了解的" 冒出来的错误" .

6.2 持续学习悖论

The learning paradox continued

There's a deeper issue here: The very thing that makes AI coding tools accessible to non-engineers - their ability to handle complexity on your behalf - can actually impede learning. When code just "appears" without you understanding the underlying principles:

• You don't develop debugging skills
• You miss learning fundamental patterns
• You can't reason about architectural decisions
• You struggle to maintain and evolve the code

This creates a dependency where you need to keep going back to AI to fix issues, rather than developing the expertise to handle them yourself.

更深层的麻烦在于: AI 工具能为你" 代劳" 很多复杂的事情, 这恰恰使得非专业工程师更难真正学到软件开发的本质. 当代码在你眼前" 凭空出现" , 而你并不理解它背后的原理时:

• 你不会培养调试技能
• 你会错过学习基本模式的机会
• 你无法对架构决策进行推理
• 你也难以维护和升级这些代码

这就造成了一种依赖- - 你只能不断求助于 AI 来修复问题, 而不是掌握亲自解决它们的能力.

6.3 知识鸿沟

The knowledge gap

The most successful non-engineers I've seen using AI coding tools take a hybrid approach:

1. Use AI for rapid prototyping
2. Take time to understand how the generated code works
3. Learn basic programming concepts alongside AI usage
4. Build up a foundation of knowledge gradually
5. Use AI as a learning tool, not just a code generator

But this requires patience and dedication - exactly the opposite of what many people hope to achieve by using AI tools in the first place.

我见到最成功的非专业工程师, 会采用一种" 混合式" 的方法:

1. 用 AI 进行快速原型
2. 花时间去理解生成代码的工作原理
3. 在使用 AI 的同时学习基本的编程概念
4. 一步步打好知识基础
5. 把 AI 视为学习工具, 而不仅仅是" 代码生成器"

但这需要耐心和投入- - 而这恰恰与很多人使用 AI 工具时所期待的" 省时省力" 背道而驰.

6.4 对未来的启示

Implications for the future

This "70% problem" suggests that current AI coding tools are best viewed as:

• Prototyping accelerators for experienced developers
• Learning aids for those committed to understanding development
• MVP generators for validating ideas quickly

But they're not yet the coding democratization solution many hoped for. The final 30% - the part that makes software production-ready, maintainable, and robust - still requires real engineering knowledge.

The good news? This gap will likely narrow as tools improve. But for now, the most pragmatic approach is to use AI to accelerate learning, not replace it entirely.

这个" 70% 问题" 说明, 当前的 AI 编码工具更适合被视为:

• 对资深开发者而言, 用来加速原型的工具
• 对想认真学习开发的人而言, 用来辅助学习的工具
• 用于快速验证想法的 MVP 生成器

但它们还远不能成为" 所有人都能轻松做出成熟软件" 的神奇方案. 最后那" 至关重要的 30%" - - 让软件真正具备生产力, 可维护性, 健壮性- - 依然需要真正的工程知识.

好消息是: 随着工具的进步, 这个差距有望逐步缩小. 但在当下, 最务实的做法还是把 AI 当作加速学习的手段, 而不是用来完全替代你对软件开发本质的理解.

七. 实际可行的做法: 实用模式

What actually works: practical patterns

After observing dozens of teams, here's what I've seen work consistently:

1. The "AI first draft" pattern

   • Let AI generate a basic implementation
   • Manually review and refactor for modularity
   • Add comprehensive error handling
   • Write thorough tests
   • Document key decisions

2. The "Constant conversation" pattern

   • Start new AI chats for each distinct task
   • Keep context focused and minimal
   • Review and commit changes frequently
   • Maintain tight feedback loops

3. The "Trust but verify" pattern

   • Use AI for initial code generation
   • Manual review of all critical paths
   • Automated testing of edge cases
   • Regular security audits

在观察了数十个团队之后, 我发现以下做法行之有效:

1. "AI 初稿" 模式

   • 让 AI 生成一个基础实现
   • 由人工对代码进行模块化审查和重构
   • 加入完备的错误处理
   • 编写充分的测试
   • 补充并记录关键的技术决策

2. "持续对话" 模式

   • 针对每个独立任务都开启一个新的 AI 对话
   • 保持上下文精简, 集中
   • 频繁地审查和提交变更
   • 建立紧凑的反馈循环

3. "信任但要验证" 模式

   • 用 AI 做初始代码生成
   • 对关键路径进行人工审查
   • 编写自动化测试, 以覆盖各种边界情况
   • 定期进行安全审计

八. 展望未来: AI 的真正潜力是什么?

Looking forward: The real promise of AI?

Despite these challenges, I'm optimistic about AI's role in software development. The key is understanding what it's really good for:

1. Accelerating the known
   AI excels at helping us implement patterns we already understand. It's like having an infinitely patient pair programmer who can type really fast.
2. Exploring the possible
   AI is great for quickly prototyping ideas and exploring different approaches. It's like having a sandbox where we can rapidly test concepts.
3. Automating the routine
   AI dramatically reduces the time spent on boilerplate and routine coding tasks, letting us focus on the interesting problems.

尽管面临这些挑战, 我对 AI 在软件开发中的作用依然保持乐观. 关键在于我们要明白 AI 真正擅长什么:

1. 加速已知的
   AI 在帮助我们实现已知的模式时非常出色, 就像拥有一个永不疲倦, 打字飞快的结对程序员.
2. 探索新的可能性
   AI 让我们可以快速构建原型并探索不同思路, 就像在一个实验沙盒里可以极速测试各种概念.
3. 自动化常规任务
   AI 大幅减少我们在样板代码和常规任务上花费的时间, 让我们可以更专注于那些真正有意思的问题.

九. 这对你意味着什么?

What does this mean for you?

If you're just starting with AI-assisted development, here's my advice:

1. Start small
   • Use AI for isolated, well-defined tasks
   • Review every line of generated code
   • Build up to larger features gradually
2. Stay modular
   • Break everything into small, focused files
   • Maintain clear interfaces between components
   • Document your module boundaries
3. Trust your experience
   • Use AI to accelerate, not replace, your judgment
   • Question generated code that feels wrong
   • Maintain your engineering standards

如果你正准备开始使用 AI 辅助开发, 我的建议是:

1. 从小处着手
   • 让 AI 先处理独立且定义清晰的小任务
   • 审查 AI 生成的每一行代码
   • 再逐步扩展到更大规模的功能
2. 保持模块化
   • 把所有东西拆分成小而专注的文件
   • 为各组件设定清晰的接口
   • 在模块边界处做好文档
3. 相信你的经验
   • 用 AI 来加速, 而不是替代你的判断
   • 对那些" 感觉不对劲" 的生成代码保持质疑
   • 坚守你的工程规范与标准

十. 自主型软件工程的崛起

The rise of agentic software engineering

agentic: 吴恩达: 从 Agent 到 Agentic, 超越基础模型的下一代 AI_agentic ai-CSDN博客

特性	Agentic AI	AI Agent
定义	Agentic AI 描述的是人工智能具备自主性的能力和行为.	AI Agent 是一种具体的实现形式, 指的是一个用于执行特定任务的人工智能代理.
焦点	关注的是能力和特性, 如自主决策, 目标导向性和适应性.	关注的是实体形式, 通常是实现某种任务的代理实例.
作用范围	是一种更广泛的能力框架, 可以用于多种场景和任务类型.	是一个具体的" 工具" 或" 角色" , 为完成特定任务而创建.

无需关注各种花里胡哨的营销词汇, 二者的差异, 简单点理解, 目前各种 ai 和用户交互的模式主要还是依赖于 chat, 这种方式能够很好的处理检索问题, 但是对于ai这种耗费如此巨大的技术而言, 显然这一块的市场难以满足, 那么就需要让 ai 进一步接入实际生产生活中, 所谓的 ai agent就出来了, 也就是将 ai 整合各种软件/流程当中去, 如最简单的浏览器自动化, 桌面自动化等等

想象一下这样的场景, 当你打开浏览器去观看某个视频

• 打开浏览器 => 检索电影 => 找到电影 => 打开

所谓的ai agent, 在桌面输入: 帮我播放柯南最新剧场版, 免费的

然后浏览器自动打开, 检索, 找到视频, 播放, 整个过程都是ai自主控制.

简而言之就是, 从 say 转到 say and do .

• MCP 简介 - MCP 中文文档
• 大模型开发 - 一文搞懂 Function Calling（函数调用）-CSDN博客

The landscape of AI-assisted development is shifting dramatically as we head into 2025. While the current tools have already changed how we prototype and iterate, I believe we're on the cusp of an even more significant transformation: the rise of agentic software engineering.

What do I mean by "agentic"? Instead of just responding to prompts, these systems can plan, execute, and iterate on solutions with increasing autonomy.

If you’re interested in learning more about agents, including my take on Cursor/Cline/v0/Bolt, you may be interested in my recent JSNation talk above.

We're already seeing early signs of this evolution:

随着我们迈向 2025, AI 辅助开发的格局正在发生巨变. 虽然现有工具已经改变了我们原型设计和迭代的方式, 但我相信更具革命性的转变即将到来- - " 自主型( agentic) 软件工程" 的崛起.

我所说的"自主型" , 指的是这些系统将不再仅仅是应答式工具, 而是能够进行规划, 执行和迭代, 具备越来越高的自主性.

如果你想深入了解" 智能体(agents) " 的相关内容, 以及我对 Cursor/Cline/v0/Bolt 的观点, 可以点击上方链接观看我在 JSNation 的 最新演讲 *. *

我们已经开始看到这一演变的早期迹象:

10.1 从应答者到协作者

From responders to collaborators

Current tools mostly wait for our commands. But look at newer features like Anthropic's computer use in Claude, or Cline's ability to automatically launch browsers and run tests. These aren't just glorified autocomplete - they're actually understanding tasks and taking initiative to solve problems.

Think about debugging: Instead of just suggesting fixes, these agents can:

• Proactively identify potential issues
• Launch and run test suites
• Inspect UI elements and capture screenshots
• Propose and implement fixes
• Validate the solutions work (this could be a big deal)

目前的工具大多会等着我们下指令. 但是, 看看 Anthropic 在 Claude 中对" 计算机使用" 的新特性, 或 Cline 能够自动打开浏览器并运行测试的能力- - 这些已经不再是" 自动补全" 那么简单, 而是在真正理解任务并主动执行.

比如在调试中, 它们可能会:

• 主动发现潜在问题
• 启动并运行测试套件
• 检查 UI 元素并截屏
• 提出并实现修复方案
• 验证修复是否有效( 这可能是个重大突破)

10.2 多模态的未来

The Multimodal future

The next generation of tools may do more than just work with code - they could seamlessly integrate:

• Visual understanding (UI screenshots, mockups, diagrams)
• Verbal language conversations
• Environment interaction (browsers, terminals, APIs)

This multimodal capability means they can understand and work with software the way humans do - holistically, not just at the code level.

下一代的工具可能不仅能读写代码, 还会无缝结合:

• 对视觉内容的理解(UI 截图, 模型图, 流程图)
• 对自然语言的理解与对话
• 对环境的交互(浏览器, 终端, API)

具备多模态能力的系统, 能像人类一样, 从整体角度去理解和处理软件, 而不只是停留在代码层面.

10.3 自主但需引导

Autonomous but guided

The key insight I've gained from working with these tools is that the future isn't about AI replacing developers - it's about AI becoming an increasingly capable collaborator that can take initiative while still respecting human guidance and expertise.

The most effective teams in 2025 may be those that learn to:

• Set clear boundaries and guidelines for their AI agents
• Establish strong architectural patterns that agents can work within
• Create effective feedback loops between human and AI capabilities
• Maintain human oversight while leveraging AI autonomy

我的实践告诉我, 未来并不是要让 AI 取代开发者, 而是让 AI 成为一个更强大的协作者, 既能主动执行, 又能尊重人类的引导与专业知识.

到 2025 年, 最有效的团队或许将是那些懂得:

• 为 AI 代理设定清晰的边界和准则
• 建立强大的架构模式, 供 AI 代理在其中工作
• 建立人机之间高效的反馈回路
• 在利用 AI 的自主性的同时, 保持人类的审查与监督

10.4 " 英语优先" 的开发环境

The English-first development environment

As Andrej Karpathy noted:

"English is becoming the hottest new programming language."

This is a fundamental shift in how we'll interact with development tools. The ability to think clearly and communicate precisely in natural language is becoming as important as traditional coding skills.

This shift towards agentic development will require us to evolve our skills:

• Stronger system design and architectural thinking
• Better requirement specification and communication
• More focus on quality assurance and validation
• Enhanced collaboration between human and AI capabilities

Andrej Karpathy 曾指出:

" 英语正成为最热门的编程语言. "

这句话反映了我们与开发工具交互方式的根本转变 - - 清晰的思考和精确的自然语言表达, 正变得与传统的编码技能一样重要.

迈向自主型开发的道路需要我们提升以下能力:

• 更强的系统设计和架构思维
• 更好的需求规范和沟通技巧
• 更专注于质量保证和验证
• 更流畅的人机协作能力

十一. 软件艺术的回归?

The return of software as craft?

While AI has made it easier than ever to build software quickly, we're at risk of losing something crucial - the art of creating truly polished, consumer-quality experiences.

尽管 AI 让我们比以往更容易快速构建软件, 但我们也面临一个风险: 我们可能会失去软件创作的那份" 艺术感" , 或者说" 工匠精神" . 有些人 认为, 这种对打造" 真正优质的消费级体验" 的追求, 恰恰是目前最容易被忽视的部分.

现在软件可以很快地被开发出来, 但要让它实现自助服务且达到消费级质量, 却正在成为一门失传的艺术.

你必须打磨所有边角, 修复所有P2级别的bug, 而不是仅仅关注演示路径.

今年, 个人软件将会强势回归.

( 注: P2通常指优先级2级的bug, 在软件开发中属于比较重要需要修复的问题, 仅次于最高优先级P1)

11.1 演示质量的陷阱

The Demo-quality trap

It's becoming a pattern: Teams use AI to rapidly build impressive demos. The happy path works beautifully. Investors and social networks are wowed. But when real users start clicking around? That's when things fall apart.

I've seen this firsthand:

• Error messages that make no sense to normal users
• Edge cases that crash the application
• Confusing UI states that never got cleaned up
• Accessibility completely overlooked
• Performance issues on slower devices

These aren't just P2 bugs - they're the difference between software people tolerate and software people love.

一个越来越常见的现象是: 团队们用 AI 快速做出一个令人惊艳的 Demo, 在"幸福路径" 下表现得很棒, 投资人和社交媒体都称赞不已. 但当真正的用户来使用时, 就会暴露出各种问题:

• 提示信息根本不符合普通用户的理解
• 稍微超出预期的操作就会导致程序崩溃
• 混乱的 UI 状态从未被真正梳理过
• 无人关注的可访问性问题( Accessibility)
• 在较慢设备上出现严重性能问题

这些问题不仅仅是"P2 Bug" . 它们往往决定了软件是被用户" 勉强接受" 还是" 真心喜爱" .

11.2 被遗忘的打磨过程

The lost art of polish

Creating truly self-serve software - the kind where users never need to contact support - requires a different mindset:

• Obsessing over error messages
• Testing on slow connections
• Handling every edge case gracefully
• Making features discoverable
• Testing with real, often non-technical users

This kind of attention to detail (perhaps) can't be AI-generated. It comes from empathy, experience, and caring deeply about craft.

要想让软件真正做到"自助式" (用户无需随时联系客服) , 需要完全不同的思维方式:

• 对错误信息孜孜不倦地打磨
• 在糟糕的网络条件下测试
• 在所有边界情况都做优雅的处理
• 让功能" 能被发现" 并易于使用
• 和真正的, 常常不那么懂技术的用户一起测试

这种对细节的关注(也许) 无法单纯靠 AI 生成. 它更来自于对用户的共情, 丰富的实践经验, 以及对软件打磨的极致追求.

11.3 个人软件时代的复兴

The renaissance of personal software

I believe we're going to see a renaissance of personal software development. As the market gets flooded with AI-generated MVPs, the products that will stand out are those built by developers who:

• Take pride in their craft
• Care about the little details
• Focus on the full user experience
• Build for the edge cases
• Create truly self-serve experiences

The irony? AI tools might actually enable this renaissance. By handling the routine coding tasks, they free up developers to focus on what matters most - creating software that truly serves and delights user

我相信, 我们将会看到一个"个人软件开发" 重新崛起的时代. 随着市场上充斥着大量"AI 生成的 MVP" , 真正能脱颖而出的, 往往是那些由开发者精心雕琢的产品, 他们:

• 以工匠般的态度审视自己的作品
• 在意那些" 看似微小却不可或缺" 的细节
• 真正从用户体验全局出发
• 重视各种极端使用场景
• 努力让软件实现"真正自助"

有意思的是, AI 工具或许能推动这种新"工匠精神" 的发展. 因为 AI 可以处理许多繁琐的基础工作, 从而让开发者有更多时间和精力来打磨用户体验和细节.

十二. 总结

The bottom line

AI isn't making our software dramatically better because software quality was (perhaps) never primarily limited by coding speed. The hard parts of software development – understanding requirements, designing maintainable systems, handling edge cases, ensuring security and performance – still require human judgment.

What AI does do is let us iterate and experiment faster, potentially leading to better solutions through more rapid exploration. But only if we maintain our engineering discipline and use AI as a tool, not a replacement for good software practices. Remember: The goal isn't to write more code faster. It's to build better software. Used wisely, AI can help us do that. But it's still up to us to know what "better" means and how to achieve it.

What's your experience been with AI-assisted development? I'd love to hear your stories and insights in the comments.

AI 并没有让我们的软件"质的飞跃" , 或许是因为软件质量本就不是由"开发速度" 来决定的. 软件开发中最艰难的部分 - - 理解需求, 设计可维护的系统, 处理各种边界情况, 兼顾安全和性能- - 依然需要人类的判断力.

AI 真正的价值在于让我们迭代, 试验得更快, 通过加速探索让我们可能找到更好的解决方案. 但这只有在我们保持良好的工程实践, 并将 AI 当作工具而非" 万能替代品" 时才能实现. 请记住: 我们的目标不是" 更快地写更多代码" , 而是要" 构建更好的软件" . 如果使用得当, AI 可以帮助我们实现这一目标. 但要知道, 如何定义" 更好" 以及如何达成, 仍掌握在我们自己手中.

你在使用 AI 辅助开发方面有什么经验或见解吗? 欢迎在评论区分享你的故事和想法.