Agentic Engineering on Kalend's Blog

从Vibe Coding到Agentic Engineering：2026开发者该升级的方法论

Tue, 28 Jul 2026 10:00:00 +0800

一、引子：Karpathy 的"落后感"

2026 年 4 月，红杉资本 AI Ascent 大会。

Andrei Karpathy 站在台上，说了一句让全场安静下来的话：

「我从没觉得自己如此落后过。」

14 个月前，正是他给一种编程方式起了名字——Vibe Coding。当时原话是「完全沉浸在氛围中，忘记代码，只管 accept」。那条推文引爆了整个开发者圈，所有人都在说：编程的门槛消失了。

14 个月后，同一个人站出来说：这套方法论，终结了。

不是 Vibe Coding 没用，而是它不够了。

Karpathy 用了个新词——Agentic Engineering。

从 Vibe Coding 到 Agentic Engineering，中间到底发生了什么？为什么连发明者自己都在升级方法论？

这篇文章拆解这个进化过程。三阶段、五大支柱、一份你现在就能用的落地清单。

二、Vibe Coding 是什么？为什么它曾经很香

先回顾一下定义。

2025 年 2 月，Karpathy 描述了这种工作方式：

1

prompt → accept → run → ship

你跟 AI 说「帮我写个登录页」，它吐出代码，你看一眼觉得行，accept，运行，部署。全程不仔细看代码细节，沉浸在「氛围」里。

这有错吗？没有。

它的本质是 floor-raising——提升下限。 以前不会编程的人，现在能造出原型。以前需要一周的功能，现在一天搞定。

Google 2026 年 5 月发布的《The New SDLC With Vibe Coding》白皮书给了数据：85% 的专业开发者在用 AI 编程智能体，51% 每天用，预估 41% 的新代码由 AI 生成。

不是少数极客在玩，是主流在用。

Vibe Coding 最香的场景：

场景	为什么适合	举例
原型开发	快速验证想法，质量要求低	Hackathon、内部 demo
个人项目	自己用，bug 自己修	个人工具、脚本
已知模式的模板代码	AI 擅长重复模式	CRUD、API 接口、配置文件
学习新技术栈	边生成边学，比看文档快	新框架上手

一个有意思的发现是：生产力提升最大的团队，不是那些让 AI 写所有代码的团队，而是知道「什么时候该用 Vibe Coding、什么时候不该」的团队。

关键词是「知道什么时候用」。

这就是天花板的起点。

三、天花板在哪？三个致命问题

Vibe Coding 的问题不是「不好用」，而是「用多了会出事」。

三个致命缺陷，一个比一个隐蔽。

问题一：没有 evals——你不知道 AI 产出的质量

你让 AI 写了一段代码，运行通过了。好。

但是：

边界条件覆盖了吗？
并发场景处理了吗？
安全漏洞有没有？
性能合不合格？

不知道。因为没有评估机制。

「能跑」和「质量达标」之间隔着一道鸿沟。 Vibe Coding 的默认状态是：跑通就算完成。这在原型阶段没问题，在生产环境是灾难。

问题二：没有 observability——agent 跑偏了你不知道

当你把越来越多的工作交给 AI，一个新问题出现了：你看不见它在干什么。

它改了哪些文件？为什么选这个方案而不是那个？中间做了几次重试？哪一步卡住了？

如果你不知道这些，你就是在盲开。

问题三：安全和可维护性无人负责

AI 生成的代码，谁对安全负责？

AI 生成的代码，三个月后谁来维护？

这两个问题在 Vibe Coding 的范式里没有答案。 因为 Vibe Coding 的核心动作是「accept」——接受产出，不做深度审查。安全和可维护性恰恰需要深度审查。

数据说话

一个普遍现象是：大多数团队能看到 agent 在干什么（observability），但只有一半左右的团队在系统性地评估产出质量（evals）。

这个差距就是 Vibe Coding 到 Agentic Engineering 的鸿沟。

能看见，但不能控制。能产出，但不能保证质量。

四、Agentic Engineering——Karpathy 的新范式

什么是 Agentic Engineering？

Karpathy 的核心定义是两个词：ceiling-preserving（保护上限）。

Vibe Coding 是 floor-raising——让更多人能参与。

Agentic Engineering 是 ceiling-preserving——确保质量不滑坡。

具体来说：

「我 99% 的时间不再直接写代码，而是在指挥智能体干活。但作为人类，我对最终质量负全责。」

关键词是「负全责」。

不是让 AI 随便搞。是工程化地管理 AI 写代码的过程。

三大支柱

Agentic Engineering 不是一个工具、一个框架，而是一套方法论。核心由三大支柱支撑：

支柱一：Spec（规范）

告诉 agent「做什么」和「不做什么」。这不是写 prompt，是写工程规格书。

具体形式就是 AGENTS.md、SOUL.md 这类规范文件——项目架构、编码规范、测试要求、禁止操作，全部写清楚。（怎么写，我在上一篇AGENTS.md 指南里详细拆过。）

支柱二：Evals（评估）

系统性地衡量 AI 产出的质量。不是「看起来行就行」，是「过了评估才算完成」。

可以是自动化测试，可以是 checklist，可以是 code review 流程——形式不重要，有没有才重要。

最简单的 eval：写一个 checklist，AI 每次产出后逐条打勾。

检查项	通过
功能符合需求	✅/❌
错误处理完整	✅/❌
无安全隐患	✅/❌
有测试覆盖	✅/❌
代码风格一致	✅/❌

5 条，5 分钟，但能把 80% 的问题拦在合并前。

支柱三：Observability（可观测性）

看得见 agent 在干什么。日志、trace、审计——知道每一步的输入输出，知道为什么做了这个选择。

不是为了监控，是为了事后复盘。出了问题能追溯，做得好能复用。

一张表看清区别

维度	Vibe Coding	Agentic Engineering
核心理念	提升下限（floor-raising）	保护上限（ceiling-preserving）
人的角色	accepter——接受产出	owner——对质量负责
代码审查	可选，甚至跳过	必须，有流程
产出质量	靠运气	靠工程
适用场景	原型、个人项目	生产环境、团队协作
核心动作	prompt → accept	spec → execute → evaluate → ship

五、三阶段进化全景

回头看，AI 编程方法论经历了三个清晰的阶段。

第一阶段：Vibe Coding（2025.02 —）

关键词：氛围编程，快但不可控。

Karpathy 定义，社区狂热。prompt → accept → ship。门槛降到地板，质量也跟着降到地板。

这一阶段的贡献是巨大的——它证明了 AI 可以写代码，而且写得还不错。它让整个行业开始认真对待 AI 编程。

但它也暴露了一个根本问题：快不等于对。

第二阶段：Context Coding / Harness Engineering（2025.06 —）

关键词：AGENTS.md + 规范约束，让 AI 在框架内工作。

2025 年中，社区开始使用 Context Engineering 这个概念，强调给 AI 提供完整的上下文而非简单 prompt。开发者开始写规范文件、定义规则、约束 AI 的行为边界。从「给 AI 一句话」变成「给 AI 一套规则」。

这一阶段的核心贡献是：把 AI 从「自由发挥」拉回到「有规矩地干活」。

我在之前的AGENTS.md 深度指南中详细拆过这一阶段的方法论。简单说：花 30 分钟写好规范文件，比花三天对比工具强十倍。

但 Context Coding 也有天花板：它管住了单个 AI 的行为，但管不住多个 AI 的协作，也没有系统性的质量验证机制。

第三阶段：Agentic Engineering（2026.04 —）

关键词：多 agent 协调 + evals + observability。

Karpathy 在 AI Ascent 大会上正式提出。不只是「给 AI 规则」，而是「工程化管理整个 AI 工作流」。

多个 agent 并行工作，人类定义目标和质量标准，evals 验证产出，observability 监控过程。

类比

阶段	类比	核心动作
Vibe Coding	手工作坊——一个人从头干到尾	accept
Context Coding	流水线——标准化流程	constrain
Agentic Engineering	智能工厂——多条线并行，人管质量	orchestrate

从「一个人干活」到「标准化流程」到「多条线并行」。

你现在在哪个阶段？大多数人停在 1.0 或 2.0。

六、你现在该怎么做？五条实操建议

不是理论，是现在就能做的事。

1. 不要抛弃 Vibe Coding，升级它

Vibe Coding 不是垃圾，是地基。

原型开发、学习新技术、探索性编码——这些场景仍然适用。问题不是 Vibe Coding 本身，而是把它当终点。

正确姿势：用 Vibe Coding 快速产出，然后用工程化手段验证。

2. 给你的 AI 工具加 evals

哪怕最简单的 checklist。

每次 AI 产出后，花 5 分钟逐条检查：

功能是否符合需求？
错误处理是否完整？
是否有安全隐患？
是否有测试覆盖？
代码风格是否一致？

不要觉得「看起来行就行」。「看起来」是最不靠谱的质量标准。

3. 学会写 AGENTS.md

Context Engineering 是 2026 年的必修课。

不管用什么工具——Claude Code、Cursor、Codex、Gemini CLI——底层逻辑都一样：AI 的产出质量，70% 取决于你给了它什么上下文。

30 分钟写一个 AGENTS.md，效果比换三个工具强十倍。不知道怎么写？参考 Codex CLI 的官方仓库——GitHub 超过 10 万 Star，它的 AGENTS.md 就是范本。

4. 建立 agent 可观测性

不需要复杂的基础设施。

最简单的方式：让 AI 在工作时输出日志——做了什么、为什么这么做、遇到了什么问题。

进阶方式：用专门的可观测性工具，记录每个 agent 的执行路径、决策过程、耗时分布。

能看到，才能改进。看不到，只能祈祷。

5. 从单 agent 到多 agent 协作

这是 2026 年真正拉开差距的地方。

一个人指挥一个 AI，是 Context Coding。

一个人指挥多个 AI 各司其职，是 Agentic Engineering。

具体怎么做：

1
2
3
4
5


一个 agent 负责写代码
一个 agent 负责 review
一个 agent 负责测试
一个 agent 负责部署
人类负责定义目标和验收标准

不需要一开始就搭完整的 pipeline。从「写代码 + review」两个角色开始，逐步扩展。

七、结论：地基之上，才是上层建筑

Vibe Coding 不是终结，是起点。

它证明了 AI 可以写代码，让整个行业开始认真对待 AI 编程。但「能写」和「写得好」之间，隔着 Agentic Engineering。

2026 年，「会用 AI」不够了。

要「会工程化管理 AI」。

三个核心转变：

1
2
3


从 accept 一切 → 只 accept 过了 eval 的
从看不到过程 → 每一步可观测
从单打独斗 → 多 agent 协作

Karpathy 说「从没觉得自己如此落后过」，然后用 14 个月定义了一套新方法论。

你呢？

不需要 14 个月。从今天开始做三件事：

写一个 AGENTS.md（30 分钟）
加一个 5 条 checklist 的 eval（5 分钟）
让 AI 输出工作日志（1 分钟）

36 分钟，你就能从 Vibe Coding 1.0 迈进 Agentic Engineering 的大门。

数据来源：Addy Osmani (Google)《The New Software Lifecycle》(2026.5)、Karpathy 红杉资本 AI Ascent 演讲(2026.4)

关注「varkm」，一起学习，一起成长。

Vibe Coding翻车指南：10个让AI编程从'爽'变'灾难'的常见错误

Fri, 17 Jul 2026 08:00:00 +0800

Google 2026年5月发布的《The New SDLC With Vibe Coding》白皮书有一组扎眼的数据：85%的专业开发者在用AI编程智能体，51%每天用，预估41%新代码由AI生成。

用的人多，不等于用得好。

Karpathy 2025年2月提出Vibe Coding，一年后又提出Agentic Engineering。这个进化本身就说明问题——Vibe Coding是起点，不是终点。很多人卡在"提示即祈祷"阶段：把需求扔给AI，然后祈祷别出错。

今天不聊代码层面的bug（那篇写过了），聊方法论层面的10个系统性错误。每个都指向同一个核心：AI是乘数，工程纪律是被乘数。

错误1：大模块一次性生成

一个prompt要求AI写完整认证系统——注册、登录、密码重置、JWT刷新、OAuth2集成，全要。

结果：安全细节被简化（密码哈希用SHA256而非bcrypt，JWT没有刷新机制），错误处理缺失，接口风格不一致。看起来"能跑"，上线就炸。

心法：拆成小任务，每个≤200行。认证系统拆成：①用户模型+密码哈希 ②注册接口 ③登录+JWT签发 ④JWT刷新 ⑤OAuth2接入。每完成一个，验证一个。

错误2：模糊prompt产出平庸代码

“帮我优化这段代码”——AI会给你一个"还行"的版本。“用async/await重写这个函数，保持错误处理和日志，去掉callback hell”——AI给你精准的重构。

Claude Code官方最佳实践指南反复强调：模糊的prompt只能得到模糊的结果。

心法：每次prompt回答三个问题——改什么、怎么改、保留什么。模糊的输入只能得到模糊的输出。

错误3：不过审就部署

灰度发布，新接口静默失败——前端无提示，后端日志全是空catch块。用户投诉了才发现。

AI生成≠可部署。这个等号不能画。

心法：AI代码必须过审才能合并。审查清单：①错误处理是否完整 ②边界条件是否覆盖 ③日志是否有意义 ④是否有硬编码的配置 ⑤是否有测试。

错误4：过度信任AI的"完整性"

AI输出的代码"看起来很完整"——有注释、有docstring、有错误处理、甚至有测试。但仔细看，测试只覆盖了happy path，错误处理用了except Exception: pass，docstring和实际行为不一致。

AI的完整性是表面的。它会生成结构完整但逻辑有漏洞的代码。

心法：追问"为什么这么写"。AI选择某个方案时，问它为什么不用另一个。如果它答不上来或答得含糊，方案可能有问题。

错误5：context缺失导致幻觉

没有AGENTS.md，没有项目规范文件，没有代码风格指南。AI只能靠猜——猜你用什么框架、猜你用什么数据库、猜你的错误处理风格。

结果：同一个项目里，AI一会儿用Express一会儿用Fastify，一会儿用async/await一会儿用callback。

心法：给AI一个"上下文锚点"。AGENTS.md、.cursorrules、项目README，这些文件的价值不在于写得多详细，而在于AI有了参考系。

错误6：任务粒度不对

两个极端都致命：太大，AI出错概率飙升；太小，AI失去连贯性，生成的代码碎片化。

类比：不会让实习生一次交付完整系统，也不会让他只写一行print。给AI的任务和给人的任务，粒度原则一样。

心法：单个任务的复杂度应该等于一个"中等难度的PR"——有明确输入输出，有清晰边界，一个资深工程师能在30分钟内review完。

错误7：迭代循环缺失

一次性生成后就不管了。不跑测试，不做code review，不根据反馈调整。

Vibe Coding的诱惑在于"看起来很快"。但如果没有迭代循环，快只是假象——你只是把调试时间从编码阶段移到了部署阶段。

心法：小步快跑+持续反馈。生成→验证→反馈→调整，每个循环不超过10分钟。如果一个循环内无法验证，任务粒度太大了。

错误8：审查机制空白

没有code review流程，AI生成的代码直接合并到main分支。相当于把仓库的门禁卡交给了一个实习生，还不设审批。

心法：设计AI代码审查checklist。不用复杂，五条就够：①功能是否符合需求 ②错误处理是否完整 ③是否有安全隐患 ④是否有测试覆盖 ⑤代码风格是否一致。

错误9：只学工具不学心法

Cursor、Claude Code、Codex、OpenCode——工具选了一堆，方法论停留在"提需求→等生成→复制粘贴"。

工具一直在换，但方法论没变。

心法：工具是手段，不是目的。理解"任务拆解→上下文管理→迭代验证→审查部署"这个循环，比多装三个工具有用。

错误10：忽略验证成本

代码生成成本从"一个工程师一天"降到"几秒钟"，但验证成本并没有降。瓶颈从"写代码"转移到了两端：搞清要做什么，确认做对了。

这两个才是真正的成本。很多人只关注"AI写得快不快"，忽略了"AI写得对不对"需要人来确认。

心法：把足够的时间花在验证上——跑测试、看diff、review逻辑。生成快≠正确，省下的编码时间要投入到验证中。

从Vibe Coding到Agentic Engineering

Karpathy 2026年2月提出的Agentic Engineering，核心思想很简单：人负责定义目标、约束和质量标准，AI在结构化流程中执行，每个关键节点人工审核。

不是让AI自己跑，是给人一个更高效的工作流。AI在里面的角色是"高效执行者"，不是"决策者"。

Vibe Coding是"感觉对了就用"，Agentic Engineering是"验证对了才用"。前者靠直觉，后者靠流程。

你不需要10个AI工具，你需要一个清晰的工程方法论。

数据来源：Google《The New SDLC With Vibe Coding》(2026.5)、Karpathy 2025.2/2026.2公开演讲、Claude Code官方最佳实践指南

AI编程不是一句话搞定：任务拆解的粒度艺术

Fri, 10 Jul 2026 10:00:00 +0800

我见过太多人（包括我自己）踩同一个坑：把一个大需求直接丢给 AI，期待它一口气交付完整功能。

结果呢？前半段看起来不错，后半段开始离谱。你 accept 了前 200 行代码，到第 300 行发现逻辑对不上，回头一看——第一步的数据结构就埋了雷，后面全是连锁反应。

结论先说：AI 编程的核心技能不是 prompt 写得多好，而是任务拆得多细。

一、为什么"一句话搞定"是最大的陷阱

先说一个反直觉的事实：上下文窗口越大，你越容易高估 AI 的能力。

2026 年主流模型的上下文窗口已经到了 200K tokens，理论上能装下一个中型项目的全部代码。但问题是——能装下不等于能理解。模型在处理长上下文时，注意力会稀释。你丢进去 10 个文件让它同时改，它可能只精确处理了前 3 个，后面 7 个在"凭印象"写代码。

这引出一个核心概念：幻觉半径。任务越复杂，模型的"合理猜测"范围越大，犯错概率指数级增长。一个小功能的幻觉半径可能只有 2-3 行代码，一个完整模块的幻觉半径能覆盖整个文件。

更致命的是错误累积效应。第一步的数据类型选错，第五步的 API 就对不上，第十步的 UI 就要推倒重来。这不是 AI 笨——你让一个聪明人同时处理 10 个相互依赖的任务，他也会犯错。

类比一下：你不会让实习生第一天就独立交付整个支付模块。你会先让他改个按钮颜色，再写个工具函数，逐步加码。AI 编程也一样——不是因为它不聪明，而是因为复杂任务的本质就需要分步验证。

二、任务拆解的三层粒度模型

拆解不是随便切，有一个实用的分层框架：

层级	名称	时间粒度	例子
L1	功能级	10-30 分钟	“实现用户登录”
L2	步骤级	5-15 分钟	“创建登录表单组件”
L3	指令级	1-5 分钟	“在 LoginForm.tsx 中添加邮箱验证”

最佳实践：从 L1 开始规划，用 L3 实际执行。

什么意思？你在脑子里或文档里先拆出 L1 功能清单——“登录"是一个 L1，“评论系统"是一个 L1。然后每个 L1 拆成 3-5 个 L2 步骤。真正交给 AI 执行的是 L3：一个具体的、明确的、可以在几分钟内验证的小指令。

为什么要这样？因为每个 L3 指令都是一个可验证的检查点。做完了，跑一下，看看对不对。对了继续，错了立刻修。这比一口气做完 10 个功能再回头 debug 效率高一个数量级。

三、五种拆解策略

拆解有章法可循，不是凭感觉切。以下是五种我反复验证过的策略：

按文件拆

每个文件一次修改。不要让 AI 同时动 10 个文件——它会顾此失彼，改了 A 忘了 B 的 import 路径。

实操技巧：先问 AI “这个功能涉及哪些文件？"，然后一个一个来。

按层次拆

先数据层 → 再逻辑层 → 最后 UI 层。这是经典的分层架构思路，但很多人在 AI 编程时忘了它。

为什么要分层？因为数据模型是地基。你先让 AI 写 UI，回头发现数据结构不对，UI 就得全改。反过来，数据模型定好了，API 和 UI 怎么改都不伤根基。

按依赖拆

画一下依赖图，先实现被依赖的模块。工具函数比业务逻辑先写，公共组件比页面组件先写。

一个简单判断法：如果模块 A 的测试需要模块 B 的存在，那 B 就该先做。

按风险拆

高风险部分（支付、认证、数据迁移）单独审查，低风险部分（样式、文案、配置）可以批量处理。

这不是歧视低风险代码，而是把有限的审查精力集中在最可能出问题的地方。

按测试拆

每个拆分点都是一个可测试的里程碑。如果一个子任务你写不出测试用例，说明它太大了，需要继续拆。

1
2


好拆分：实现用户注册 API → 可以写测试验证返回 201 和正确的 user 对象
坏拆分：实现整个用户系统 → 测试用例写不出来，因为不知道从哪验证起

四、审查机制设计

拆解是骨架，审查是免疫系统。没有审查的拆解，只是把一个大错误切成了十个小错误。

Checkpoint 审查

每完成一个子任务，停下来 review。不需要逐行看代码，重点检查：

接口是否符合预期（输入输出类型对不对）
边界情况有没有处理
和上一步的衔接是否顺畅

自动验证

让 AI 自己跑测试、lint、类型检查。这是最高效的审查方式——不需要人肉看，机器告诉你对不对。

1
2
3


Prompt 示例：
"写完这个函数后，自己跑一下 pytest，确保所有测试通过。
如果有 lint 警告，也一并修复。"

回滚机制

git commit 要频繁。每完成一个 L3 指令就 commit 一次。这样出错时能精确回退到上一个正确的状态，而不是 git stash 整个进度。

渐进信任

这是核心原则：

阶段	信任级别	操作方式
小任务（L3）	Agent 自主	不审查，看结果
中任务（L2）	轻度审查	自动验证 + 快速扫一眼
大任务（L1）	人工审查	逐个 checkpoint 检查
关键任务	人工参与	每步确认再继续

信任是挣来的，不是给的。先让 AI 在小任务上证明自己，再逐步放权。

五、实战案例——一个真实功能的拆解过程

需求：“给博客系统加一个评论功能。”

这句话看起来简单，实际涉及至少 6 个独立模块。如果一把丢给 AI，大概率翻车。拆开看：

L1 拆解（6 个功能）：

1

① 数据模型 → ② API 端点 → ③ 前端组件 → ④ 前后端连接 → ⑤ 样式交互 → ⑥ 测试

L2/L3 拆解（以"数据模型"为例）：

1
2
3
4
5
6
7


L2-1: 定义 Comment schema（字段、类型、约束）
L2-2: 创建数据库迁移文件
L2-3: 写基础 CRUD 方法

L3-1: 在 schema 中添加 content: text, author: string, post_id: integer, created_at: timestamp
L3-2: 运行 migration，验证表创建成功
L3-3: 实现 create 方法，写一个测试验证能插入数据

关键点：每一步都是独立的、可验证的、可回滚的。

L3-1 做完，跑类型检查，确认 schema 没语法错误
L3-2 做完，查数据库，确认表结构正确
L3-3 做完，跑测试，确认 CRUD 正常

任何一步出错，只回退那一步，不影响其他部分。这就是拆解的价值——把不可逆的大失败变成可逆的小失败。

六、不同工具的拆解差异

不同工具对拆解粒度的要求不同：

工具	适合粒度	原因	注意事项
Cursor	L2-L3	Agent 模式可自动执行多步，但文件级操作仍需控制	单次改动不超过 3 个文件
Claude Code	L1-L2	长上下文能力强，可以一次处理更大范围	但仍需 checkpoint，不能盲目信任
OpenCode/Codex CLI	L2-L3	沙箱隔离，适合高风险操作的独立审查	适合"先在沙箱里试，确认后再合并”

通用原则：工具越强，粒度可以越粗，但不能不拆。

即使是最强的模型，面对"帮我重写整个认证系统"这种指令，也大概率会遗漏边界情况。能力上限不等于可靠性上限。

七、常见反模式

最后列四个我见过最多的反模式，每个都是血泪教训：

“一口气全做完”——丢一个大需求，期望一次交付。这是最常见也最致命的。你以为省了时间，实际在后面付出了 3 倍的 debug 时间。

“过度拆解”——拆到每行代码一个指令。走到另一个极端，效率为零。L3 是底线，再细就该自己写了。

“只拆不审”——拆了 10 个步骤，一口气全执行完，中间不检查。拆解的意义在于验证，不检查等于没拆。

“盲目信任”——AI 说"测试全通过"就信了。实际上它可能只跑了它自己写的测试，而那些测试恰好跳过了真正的 bug。验证要独立于被验证的对象。

写在最后

AI 编程的真正门槛不是 prompt engineering，是工程思维。

能用 AI 写代码的人越来越多，但能把 AI 编程用好的人——任务拆得清、审查做得实、质量守得住——依然是少数。

任务拆解听起来像管理话题，和技术无关。但做过大型项目的人都知道：最难的从来不是写代码，是决定先写什么、后写什么、什么不写。

AI 改变的是编码速度，没有改变软件工程的基本规律。小步快跑、持续验证、快速回滚——这些原则在 AI 时代比任何时候都重要。

varkm