把需求写清楚比写代码难多了，AI 时代真正的瓶颈其实是我们的工作流

很多人在讨论 AI Engineering 这种听起来很高级的词，什么 Agentic Development 或是 Spec-driven 之类的，但把这些名词剥掉，核心其实就一件事：AI 现在已经能覆盖从需求分析、挑战 PRD、架构推理到写代码和验证的全流程了。但这里有个很吊诡的现象，AI 撸代码的速度快得离谱，结果反而把我们开发流程中那些“慢动作”给给放大了。

我把目前的开发流程拆解成五个阶段：需求定义 → 细节精炼 → 方案规划 → 代码实现 → 验证。这五步本身没什么新鲜的，但 AI 介入后的化学反应很奇怪。以前我们习惯在需求文档里写一句“优化用户体验”，团队里的人通过开会、聊天能心照不宣地知道这意味着什么。但 AI 没有这种“默契”，它需要极其明确的边界、约束条件和预期结果。

这时候 AI 的一个反直觉用途出现了：它其实是个非常完美的“杠精”评审员。你可以把 PRD 扔给它，让它扮演一个挑剔的架构师，专门问你“如果这里接口超时了怎么办？”或者“这两页的需求是不是自相矛盾了？”。这种利用 AI 挖掘模糊地带的操作，比直接让它写代码要高效得多。

最让我感触深的是，代码实现可能已经不再是瓶颈了。在很多公司，产品、UX 和工程之间来回拉扯两周，最后定稿给开发，开发用 AI 跑代码可能只要半小时。这种极端的速度差让传统的“接力棒”式交付变得极其低效。如果 AI 能快速出 Demo，那么工程师和 UX 应该在需求定义阶段就介入，用 AI 快速出轻量级原型去验证想法，而不是在文档里死磕。

关于给 AI 提供上下文这件事，很多人有个误区，觉得文档给得越多、Wiki 页面越多，AI 表现就越好。其实完全相反。如果你的文档里有三份文件用不同的口径描述同一个功能，AI 不会觉得它学到了更多，它只会更困惑。

真正对 AI 友好的不是“海量文档”，而是“可导航的结构”。一个清晰的项目目录、聚焦的文档、明确的架构决策记录（ADR）以及组织良好的代码库，比一份万字长文的规格说明书有用得多。本质上，我们要做的是让 AI 能在需要的时候快速定位到正确的信息，而不是把它淹没在信息垃圾里。

最后我想吐槽一下现在的 Ticket（任务单）切分方式。很多任务单写得像这样：

Task: 实现用户认证模块
Description: 完成登录、注册、找回密码等所有功能，确保安全性。

这种粒度的任务对 AI 来说简直是灾难，它在推理时极易丢失细节。如果把任务切碎成“实现密码重置的邮件触发逻辑”这种具体到原子级的任务，AI 的交付质量会有一个质的飞跃。

说白了，AI 正在逼着我们承认：很多所谓的“工程能力”，其实在 AI 面前毫无意义，真正的竞争力现在变成了如何精准地定义问题，以及如何构建一个让 AI 能够高效索引的知识结构。