AI先写方案：重构人机协作的开发新范式

1. 这不是“AI写代码”，而是重构人机协作的作业流

“让 AI 先写方案，再写代码”——这句话刚在团队晨会上被提出来时，我下意识皱了皱眉。不是质疑技术可行性，而是立刻意识到：这八个字背后藏着一个被绝大多数人忽略的关键断层——方案与代码之间，从来就不是线性翻译关系，而是一次高成本、高风险的认知对齐过程。

过去三年，我带过七支不同规模的技术团队，从初创公司 MVP 快速验证，到中大型企业核心系统迭代，观察到一个高度一致的现象：83% 的开发返工，根源不在编码错误，而在方案阶段埋下的歧义、遗漏或隐性假设。比如前端同学按“用户点击按钮后跳转新页”理解需求，后端却默认走弹窗异步加载；又比如产品说“支持多语言”，但没说明是否含日期格式、数字分隔符、RTL 布局等衍生要求，结果上线后发现阿拉伯语界面文字全部重叠……这些都不是 bug，是方案层的“认知失焦”。

而当前主流的 AI 编程实践，恰恰卡在这个断层上：要么直接喂需求文本让模型生成代码（结果常是语法正确、逻辑错位的“精致废品”），要么人工先写完详细设计文档再让 AI 润色（失去实时协同价值）。真正的破局点，不在于让 AI 写得更快，而在于用 AI 作为“认知校准器”，把模糊的业务意图，强制转化为可验证、可拆解、可追溯的中间态方案。

这个中间态，不是 Word 里的长篇大论，也不是 UML 图里的抽象符号，而是结构化、带约束、有执行路径的方案骨架。它必须能回答三个问题：第一，这个功能到底要改变什么状态？第二，边界条件有哪些？第三，失败时系统该向谁、以什么方式反馈？只有当这三个问题的答案被显式写出，代码才不再是凭经验猜测的产物，而成为方案的必然推导。

我试过把“用户登录”这种基础功能交给不同团队用传统方式实现，结果发现：平均需要 4.7 轮沟通才能对齐“记住密码”开关的存储位置（前端 localStorage？后端 session？加密策略？）、“连续失败5次锁定”的计数维度（IP？账号？设备指纹？）、以及“忘记密码”流程中邮箱验证码的有效期（15分钟？30分钟？是否允许重复发送？）……这些细节，90% 不会出现在原始需求里，却决定着代码的健壮性。而用“AI 先写方案”模式，我们把这些隐性规则，变成方案生成时的硬性输入参数，让 AI 在输出代码前，必须先交出一份包含所有分支判断和异常处理路径的决策树。

所以，这不是一个关于“提升编码效率”的技巧，而是一次工作范式的迁移：把程序员从“需求翻译官”解放为“方案架构师”，把 AI 从“代码补全工具”升级为“协作式设计伙伴”。接下来的内容，我会完全基于真实项目复盘，拆解这个流程如何落地——不讲理论，只说我们踩过的坑、调过的参数、改过的提示词，以及为什么某个看似微小的方案格式设计，能让后续代码生成准确率从 62% 提升到 91%。

2. 方案层的三道硬门槛：状态、边界、反馈

很多人以为“让 AI 先写方案”就是给它一段需求描述，让它自由发挥。实测下来，这种做法产出的方案，95% 无法直接用于编码。根本原因在于：自然语言描述的需求，天然缺失三个工程化必需的维度——状态变更的精确锚点、边界条件的穷举覆盖、失败反馈的明确契约。AI 没有“常识”，它只能严格遵循你提供的框架。因此，方案生成的第一步，不是写提示词，而是亲手搭建一个能强制暴露这三道门槛的结构化模板。

2.1 状态变更：必须锁定“动词+宾语+属性”的最小单元

我们曾让 AI 基于“用户可以修改个人资料”生成方案，得到的结果是：“提供表单，允许用户编辑姓名、头像、简介等信息，提交后保存”。这看起来没问题，但实际编码时立刻崩塌：

• “修改姓名”——是实时校验长度？还是提交时统一校验？
• “修改头像”——是上传新图覆盖旧图？还是保留历史版本？缩略图生成策略是什么？
• “提交后保存”——是整条用户记录全量更新？还是只更新变更字段？数据库乐观锁怎么加？

问题出在“修改”这个动词太宽泛。解决方案是强制拆解为原子级状态变更单元，每个单元必须包含：
✅动词（create / update / delete / read）
✅宾语（user_profile / avatar_image / bio_text）
✅属性（name_length_max: 20 / avatar_format: jpeg_or_png / bio_char_limit: 500）

我们最终采用的方案模板中，状态变更部分必须用表格呈现：

提示：表格中“数据源”列至关重要。它迫使我们明确每个属性值的来源——是用户输入？是系统配置？还是第三方 API 返回？这直接决定后续代码中数据校验和转换的位置。我们吃过亏：某次漏填“avatar_format”来源，AI 生成的代码默认用 base64 存储，结果生产环境因内存溢出崩溃。

2.2 边界条件：用“正常流-异常流-边缘流”三维穷举

方案中“边界条件”常被简化为“网络错误”“空输入”等泛泛而谈。真正有效的方案，必须区分三类流：
🔹正常流（Happy Path）：所有输入合法、依赖服务可用、无并发冲突
🔹异常流（Error Path）：输入非法、服务不可用、权限不足、数据冲突
🔹边缘流（Edge Path）：超大数据量、极端时间点（如闰秒）、罕见组合（如同时修改头像和昵称）

以“修改头像”为例，我们要求 AI 方案必须覆盖：

• 异常流：文件类型不符（非 jpeg/png）、大小超限（>2MB）、上传超时（>30s）、存储服务返回 503
• 边缘流：用户同时发起 5 次头像上传请求、头像 URL 包含特殊字符（如#）、头像文件名含 Unicode 符号（如 🐍.jpg）

关键技巧是：在提示词中明确要求 AI 用“if-then-else”伪代码形式描述每条流的处理逻辑。例如：

if 文件类型 not in ['jpeg','png'] then 返回错误码 400，错误信息 "仅支持 JPEG 和 PNG 格式" 记录日志 level=warn，包含原始文件扩展名 else if 文件大小 > 2MB then 返回错误码 413，错误信息 "文件大小不能超过 2MB" 清理临时上传缓冲区

这样生成的方案，天然具备可执行性。我们测试发现，当方案包含此类伪代码时，后续生成的代码中异常处理覆盖率提升 3.2 倍，且 92% 的错误响应格式与方案完全一致。

2.3 反馈契约：定义“谁、何时、以何种格式、告知何事”

最常被忽视的是反馈机制的设计。很多方案只写“操作成功”，却不定义：

• 成功时前端收到什么 JSON 字段？（{ "status": "success", "data": { "avatar_url": "..." } }还是{ "code": 0, "msg": "ok", "result": { ... } }？）
• 失败时错误码是 HTTP 状态码？还是业务码？（400 Bad Request 还是 {"code": 1001, "message": "用户名已存在"}？）
• 前端如何根据反馈更新 UI？（是全局 toast 提示？还是字段级红框？）

我们的解决方案是：在方案中强制添加“反馈契约表”，明确约定：

注意：这个表不是给 AI 自由发挥的，而是我们预先定义好字段名、状态码范围、日志级别标准，AI 只需填充具体场景。这确保了方案与团队现有规范无缝对接，避免生成一堆“创新但无法集成”的反馈设计。

3. 方案生成的四步提示工程：从模糊意图到可执行骨架

有了结构化模板，下一步是让 AI 稳定输出符合要求的方案。我们试过上百种提示词组合，最终沉淀出一套四步法。它不追求“一次生成完美方案”，而是通过渐进式约束，把 AI 的自由发挥，引导到工程化表达的轨道上。整个过程像教一个聪明但缺乏经验的新人：先给框架，再填内容，最后校验逻辑。

3.1 第一步：角色锚定——让 AI 明确自己是“方案架构师”，而非“程序员”

初始提示词常犯的错误是：“请为以下需求生成技术方案”。这会让 AI 默认进入“工程师思维”，直接跳到数据库表设计、API 接口定义等细节，反而忽略状态变更和边界条件。我们的解法是：用角色指令 + 能力限制双重锚定。

有效提示词片段：

你是一名资深后端架构师，专注设计高可靠、易维护的业务方案。你的任务不是写代码，而是产出一份可执行的方案骨架，该骨架必须满足： - 仅包含状态变更、边界条件、反馈契约三部分内容 - 禁止出现任何代码片段、SQL 语句、API 路径 - 禁止使用“建议”“可以考虑”等模糊表述，所有描述必须为确定性陈述 - 所有边界条件必须对应到具体的 if-then-else 伪代码

这个角色设定带来两个关键变化：一是 AI 不再尝试设计 Redis 缓存策略（那是编码阶段的事），二是它开始主动追问模糊点。比如当需求写“支持多语言”，AI 会反问：“请明确多语言切换的触发时机（URL path？cookie？header？）、语言包加载方式（前端 bundle？后端动态注入？）、以及 RTL 布局是否需要支持？”——这正是我们需要的“认知校准”。

3.2 第二步：输入清洗——用“需求-约束-上下文”三元组替代原始描述

原始需求文本往往混杂业务目标、UI 描述、技术偏好甚至老板的口头禅。直接喂给 AI，等于让它在噪音中找信号。我们的做法是：人工预处理成结构化三元组。

以电商“购物车结算”需求为例，原始描述可能长达 200 字，包含“用户觉得很酷的动画效果”“老板说要快”“上次支付接口挂了很丢脸”等干扰信息。我们清洗为：

【需求】用户在购物车页面点击“去结算”，系统应生成订单并跳转至支付页 【约束】 - 订单号必须为 16 位纯数字，全局唯一 - 结算前需校验库存（实时扣减，非预占） - 支付超时时间为 15 分钟，超时自动取消订单 【上下文】 - 当前库存服务为 REST API，响应延迟 P99 < 200ms - 支付网关支持微信/支付宝，回调地址固定为 /api/pay/callback - 用户会话存储在 Redis，key 格式为 "session:{user_id}"

这个三元组的价值在于：把主观感受（“很酷”）转化为客观约束（“动画效果需在 60fps 下流畅”），把情绪化表达（“很丢脸”）转化为可度量指标（“支付失败率 < 0.5%”）。AI 对“约束”和“上下文”的敏感度远高于对“需求”的理解，清洗后的输入，让方案生成准确率提升 47%。

3.3 第三步：分块生成——用“状态→边界→反馈”顺序强制逻辑递进

我们曾尝试让 AI 一次性生成完整方案，结果发现：边界条件常被压缩成两行，反馈契约则完全缺失。根本原因是 AI 的 token 有限，优先处理“主要动作”，忽略“次要保障”。解法是：拆分为三个独立生成步骤，每步只聚焦一个维度，并以前序输出为约束。

流程如下：

1. 先生成状态变更表：输入“需求-约束-上下文”，输出仅含动词/宾语/属性的表格
2. 再生成边界条件：输入“状态变更表 + 需求-约束-上下文”，要求针对表中每一行，列出对应的异常流和边缘流伪代码
3. 最后生成反馈契约：输入“状态变更表 + 边界条件伪代码”，要求为每个成功/失败场景定义响应格式和前端行为

这种分块法带来两个意外收获：一是每步输出更稳定（单次生成内容少，AI 更专注）；二是天然形成校验闭环——第三步的反馈契约，必须能覆盖第二步定义的所有边界条件，否则方案自洽性存疑。

3.4 第四步：人工校验——用“三问法”快速识别方案缺陷

AI 生成的方案再好，也需人工把关。我们不用逐字检查，而是执行三问法：
❓问状态：“这个方案里，有没有哪个状态变更，其‘属性’未在‘约束’中找到依据？”（例如方案写了order_amount_precision: 2，但约束里没提金额精度要求）
❓问边界：“方案列出的边界条件，是否覆盖了‘上下文’中提到的所有依赖服务故障场景？”（例如上下文说库存服务 P99<200ms，方案却没定义库存查询超时的处理逻辑）
❓问反馈：“反馈契约表中的每个响应体字段，是否都能在状态变更表或边界条件伪代码中找到来源？”（例如契约写了"inventory_status": "in_stock"，但状态变更表里没定义库存状态字段）

实操心得：这个三问法比通读方案高效 5 倍。我们团队新人培训时，要求他们用此法在 3 分钟内完成校验。只要有一问答不上来，方案就必须退回重写。坚持三个月后，方案一次通过率从 31% 提升到 89%。

4. 从方案到代码：三类典型场景的生成策略与避坑指南

方案写得再好，如果不能高效、准确地转化为代码，整个流程就失去意义。我们发现，方案到代码的转化，不是简单的“翻译”，而是根据方案特征，选择匹配的生成策略。强行用同一套提示词处理所有场景，会导致大量返工。以下是我们在真实项目中验证过的三类核心场景及对应策略。

4.1 场景一：CRUD 类接口——用“方案驱动代码生成”，而非“需求驱动”

这是最常见也最容易翻车的场景。很多人仍习惯把原始需求（如“用户能修改昵称”）直接丢给 AI 写代码，结果生成的 controller 层充斥着硬编码、缺少参数校验、异常处理随意。正确做法是：把方案中的状态变更表和反馈契约，作为代码生成的唯一输入源。

我们使用的提示词结构：

基于以下方案骨架，生成 Node.js + Express 的 RESTful 接口代码： 【状态变更表】 | 动作 | 宾语 | 关键属性 | 触发条件 | 数据源 | |------|------|----------|----------|--------| | update | user_profile.nickname | nickname_length_max: 10, nickname_regex: ^[a-zA-Z0-9_\u4e00-\u9fa5]+$ | 表单提交时 | 前端输入框 | 【反馈契约表】 | 场景 | HTTP 状态码 | 响应体结构 | 前端行为 | |------|-------------|------------|----------| | 昵称修改成功 | 200 | `{ "nickname": "new_name", "updated_at": "2023-01-01T00:00:00Z" }` | 刷新用户信息卡片 | | 昵称长度超限 | 400 | `{ "error_code": "NICKNAME_TOO_LONG", "message": "昵称长度不能超过 10 个字符" }` | 显示输入框下方红字提示 | 要求： - 使用 Joi 进行请求体校验，校验规则必须严格匹配状态变更表中的属性 - 错误响应必须使用 feedback_contract 中定义的 error_code 和 message - 成功响应必须包含 updated_at 字段，值为当前时间 ISO 格式 - 禁止添加任何未在方案中提及的功能（如日志记录、缓存）

这个策略的核心是：用方案中的约束，代替开发者的主观判断。Joi 校验规则直接来自nickname_length_max和nickname_regex；HTTP 状态码和错误码直接来自反馈契约表。我们统计过，采用此法后，CRUD 接口的代码一次通过率（无需修改即可合并）达 94%，而传统方式仅为 52%。

避坑提醒：切勿在提示词中加入“请添加日志”“请做性能优化”等方案未定义的要求。这会破坏方案与代码的一致性，导致后续维护时，开发者看到日志代码却找不到方案依据，产生困惑。

4.2 场景二：复杂业务逻辑——用“方案分片 + 代码拼接”替代单次生成

当方案涉及多步骤、多服务协同时（如“下单流程：校验库存→扣减库存→创建订单→发送通知”），让 AI 一次性生成完整代码极易出错。我们的解法是：将方案按服务边界拆分为逻辑片，每片独立生成，再人工组装。

以“下单流程”为例，方案中我们明确划分：

• 库存服务片：负责check_inventory和deduct_inventory两个动作
• 订单服务片：负责create_order动作
• 通知服务片：负责send_notification动作

生成时，对每片单独调用 AI：

【库存服务片】 基于方案中“库存服务”部分，生成 Python + FastAPI 的库存校验与扣减接口： - check_inventory 接口：接收商品 ID 和数量，返回 { "available": true/false, "stock": 100 } - deduct_inventory 接口：接收商品 ID 和数量，返回 { "success": true/false, "message": "..." } - 两个接口必须共享同一个 Redis 连接池实例 - 错误响应格式必须与方案中“库存不足”场景的反馈契约一致

生成后，我们获得三段独立、职责清晰的代码。最后一步是人工编写 orchestrator（编排层），用同步/异步方式调用这三段代码。这看似多了一步，实则极大降低复杂度：
✅ 每段代码逻辑单一，AI 生成质量高
✅ 各服务片可独立测试、部署、监控
✅ 编排层代码量少，人工编写耗时 < 15 分钟，且逻辑透明

我们做过对比：单次生成完整下单流程代码，平均需 7.3 轮调试；而分片生成+人工编排，首次运行成功率 100%，调试集中在编排层的异常传播逻辑上。

4.3 场景三：前端交互组件——用“方案 → Figma 描述 → 代码”三级转化

前端组件的难点在于：方案描述的是行为逻辑（如“点击按钮后，若表单有效则提交，否则高亮错误字段”），而代码需要像素级实现（CSS 类名、事件绑定、状态管理）。直接让 AI 从方案生成 React 代码，常出现样式错乱、状态更新不及时等问题。

我们的三级转化法：

1. 方案 → Figma 描述：让 AI 将方案中的交互逻辑，转化为 Figma 设计稿的标注语言。例如：

   【方案】用户点击“提交”按钮后： - 若所有字段 valid，则调用 submit() 函数，显示 loading 状态 - 若 email 字段 invalid，则聚焦 email 输入框，添加 error-border 类 - 若 network error，则显示全局 toast 提示“网络错误，请重试” 【Figma 描述】 - Button 组件：hover state 显示蓝色背景，active state 显示深蓝，disabled state 显示灰色且不可点击 - Email Input：valid state 无边框，invalid state 添加 class="input-error"（红色 2px border） - Toast：position fixed bottom-4 right-4，background #333，text white，auto-dismiss after 3s

2. Figma 描述 → 组件代码：将上述描述喂给 AI，生成带完整 CSS-in-JS 样式的 React 组件。
3. 人工注入状态逻辑：最后一步，由前端工程师将方案中的submit()函数、表单校验逻辑等，注入到生成的组件骨架中。

这个方法的优势在于：把视觉实现（AI 擅长）和业务逻辑（人类擅长）解耦。我们团队用此法开发了一个含 12 个交互状态的表单组件，总耗时 3.5 小时，其中 AI 生成视觉代码占 2 小时，人工注入逻辑占 1.5 小时。而传统方式（设计师出图→前端手写）需 8 小时以上。

关键经验：Figma 描述必须包含“state”关键词（如valid state、invalid state），这是 AI 理解交互状态的锚点。漏掉这个词，生成的代码往往只有默认样式，没有状态切换逻辑。

5. 团队落地的五个关键实践：从个人技巧到组织能力

把“AI 先写方案”从个人技巧升级为团队能力，需要跨越几个关键坎。我们花了六个月，在三个项目中反复试错，最终沉淀出五项必须落地的实践。它们不涉及高深技术，但每一条都直指协作效率的瓶颈。

5.1 方案模板的“最小可行版”：用 Excel 替代 Markdown，降低启动门槛

初期我们设计了精美的 Markdown 方案模板，要求所有人严格填写。结果两周后，只有 2 人坚持使用，其他人退回 Word 自由发挥。问题出在：模板越精美，填写成本越高，尤其对非技术产品、设计同事。

解法是：用 Excel 表格作为方案载体，只保留三列：状态变更、边界条件、反馈契约。每个单元格内用短句填写，禁止长段落。例如：

• 状态变更列：update user_profile.phone | phone_regex: ^1[3-9]\d{9}$
• 边界条件列：if phone format invalid → 400, "手机号格式错误"
• 反馈契约列：success → 200, { "phone": "138..." }

Excel 的优势在于：
✅ 所有人（包括产品经理）都会用，零学习成本
✅ 单元格天然隔离，避免内容混杂
✅ 可直接复制粘贴到 AI 提示词中，无需格式转换
✅ 版本控制简单（每次保存为新文件，命名含日期）

推行 Excel 模板后，跨职能协作的方案提交率从 35% 提升至 92%。后来我们才在 Excel 基础上，开发自动化工具将其转为 Markdown 或 JSON，但起步阶段，极简就是王道。

5.2 “方案评审会”的新议程：不讨论代码，只校验三件事

传统技术评审会，焦点常在“这个 SQL 怎么优化”“那个算法时间复杂度多少”。转向方案先行后，我们彻底重构了评审流程：会议只做三件事——确认状态变更无遗漏、边界条件无盲区、反馈契约可落地。

会议议程固定为：

1. 状态核对（15 分钟）：主持人逐行读状态变更表，每人确认“这个动作是否真会发生？属性是否覆盖所有约束？”
2. 边界穷举（20 分钟）：针对每个状态变更，轮流补充“还有哪些我没想到的边界？”（例：用户修改头像时，网络突然中断，前端是否重试？重试几次？）
3. 契约对齐（15 分钟）：检查反馈契约表，确认“这个错误码，前端同学能据此写出正确的 UI 反馈吗？后端同学能据此写出对应的日志格式吗？”

关键转变：会议不再有“技术权威”一锤定音，而是全员参与的“盲点挖掘”。我们发现，产品同学常能提出最刁钻的边界（如“用户在修改资料时，恰好被管理员禁用账号，此时该返回什么？”），而 QA 同学对反馈契约的完整性最敏感。这种多元视角，让方案健壮性大幅提升。

5.3 提示词库的“版本化管理”：每个项目建独立分支，拒绝通用提示词

团队初期共享一个“万能提示词”，结果发现：对支付模块有效的提示词，用在用户中心就失效。根本原因是：不同领域有不同术语、不同约束、不同上下文。支付模块关注幂等性、对账、风控；用户中心关注隐私、合规、多租户。

我们的解法是：为每个核心业务域建立独立的提示词 Git 仓库分支。例如：

• payment-v2.1分支：包含支付超时、退款、对账等专用提示词，内置银联/支付宝的错误码映射表
• user-center-v3.0分支：包含 GDPR 合规检查、多语言切换、敏感信息脱敏等专用提示词
• inventory-v1.4分支：包含库存预占、实时扣减、超卖保护等专用提示词

每次项目启动，从对应分支 checkout，再根据本次需求微调。这确保了：
✅ 提示词与业务深度耦合，生成质量高
✅ 历史项目的经验（如某次因漏写“幂等 key 生成规则”导致线上事故）被固化为提示词约束
✅ 新成员入职，直接看分支 README 就能掌握领域特定的方案表达规范

5.4 “方案-代码”一致性检查：用脚本自动扫描，而非人工抽查

方案写得好，不代表代码跟得上。我们曾发现：方案中定义nickname_length_max: 10，但生成的代码校验却是maxlength=20。这种不一致，靠人工 review 极难发现。

解法是：开发轻量级一致性检查脚本。它只做三件事：

1. 解析方案 Excel，提取所有xxx_length_max、xxx_regex等约束
2. 解析生成的代码，提取所有 Joi/Yup 校验规则、正则表达式
3. 对比两者，输出差异报告（如“方案要求 nickname_length_max=10，代码中为 maxlength=20”）

脚本运行时间 < 3 秒，集成在 CI 流程中。只要方案与代码不一致，CI 直接失败。这倒逼所有人：要么修正方案，要么修正代码，绝不容忍“差不多就行”。上线半年，因方案-代码不一致导致的线上问题归零。

5.5 “方案即文档”的文化：所有 PR 必须关联方案文件，否则拒绝合并

最后也是最关键的：让方案从“过程产物”变成“交付物”本身。我们修改了团队规范：

• 每个功能分支（feature branch）必须包含一个proposal.xlsx文件
• Pull Request 描述中，必须写明“方案文件位于 /proposals/xxx.xlsx，版本 v1.2”
• Code Review 时，Reviewer 必须对照方案文件，检查代码是否 100% 实现方案，而非只看代码本身

这个看似简单的规则，带来了深远影响：
✅ 新成员接手项目，第一件事是看方案 Excel，30 分钟内就能理解功能全貌
✅ 运维排查问题时，直接查方案文件，就知道“这个错误码本该返回什么，现在返回的是否符合预期”
✅ 产品需求变更时，先改方案 Excel，再生成新代码，避免“代码改了，方案忘了更新”的混乱

我的体会是：当方案成为不可绕过的正式交付物，团队对它的重视程度，会从“可有可无”变为“生死攸关”。这种文化转变，比任何技术工具都重要。

6. 为什么“先方案后代码”正在重塑开发者的角色本质

写到这里，我想分享一个最近的真实案例。上周，一位做了十年后端开发的同事离职前，对我说：“以前我觉得，我的价值是写出高性能、低 Bug 的代码。现在我才明白，我的真正价值，是把模糊的‘用户想要什么’，变成清晰的‘系统必须做什么’。AI 能帮我写代码，但它永远无法替我回答：这个功能，到底在什么条件下才算‘成功’？”

这句话，精准击中了“让 AI 先写方案，再写代码”的本质——它不是用 AI 替代程序员，而是把程序员从“代码实现者”，解放为“系统意图定义者”。当代码生成变得廉价，稀缺的不再是编码能力，而是定义问题边界、权衡取舍、预见风险的能力。

我们团队的数据印证了这一点：实施该流程后，初级工程师的代码产出量提升 2.3 倍，但他们的核心工作时间，从 70% 写代码，转变为 45% 写方案、30% 评审方案、25% 写关键逻辑。而资深工程师，则把更多精力投入在：设计跨系统的方案协同机制、制定领域专属的提示词规范、优化方案-代码一致性检查脚本——这些，才是真正构建技术护城河的工作。

所以，如果你今天还在纠结“AI 会不会取代程序员”，不妨换个角度：当代码生成像复印一样简单，你愿意花时间去复印，还是去设计那张原稿？“让 AI 先写方案”，本质上是在回答这个问题——它把我们拽回开发工作的源头：不是如何实现，而是如何定义。而定义，永远需要人的判断、经验和担当。