. 先说个常见的情况大家应该有遇到过这种情况接到一个需求图省事直接一句话甩给 AI ——帮我实现 xxx然后它啪地给你写了一大坨代码。乍一看挺像样但细看就会冒出一些问题它可能顺手改了几个你没让它动的文件、自己脑补了一些你没交代过的边界处理、或者明明项目里已经有现成的工具函数它非要自己再写一个。最后你花在读它到底写了啥、再把多余的改动择出去上的时间未必比自己写少多少。这不是 AI 不行而是它在信息不全的时候只能靠猜。我们没把要做什么、不要做什么讲清楚它就只好替我们做主。2. Spec-First 工作流先约定再实现2.1 一句话定义做需求前先让 AI 输出一份可被人工 review 的实现方案spec人工确认后再让它按方案写代码。注意三个关键词可被 review方案是中文说明不是直接的代码其他同学也能都看得懂人工确认spec 要通过确认后才能让 AI 去执行避免在错误前提上累积工作量按方案写第二轮 prompt 把 spec 喂回去让 AI 按既定方案写约束自由发挥的空间2.2 五步概览1. 喂上下文提示词、产品需求说明、设计稿、AGENTS.md、相关代码/文档、... 2. 出方案让 AI 输出 spec 3. Review 改方案重要的一步人工主导必须经人工确认后才可进行下一步 4. 按方案实现让 AI 严格依据 spec 编码 5. 验收 reveiwAI reveiw 人工 reveiw2.3 适用 / 不适用场景是否适用备注新功能开发✅最佳场景旧模块重构✅spec 阶段需要先对齐边界技术方案调研✅spec 就是调研报告本身Bug 修复⚠️修复 bug 主要在于问题排查改动往往是小范围的效果有限纯 Code Review❌代码审查是为了提前发现问题没有必要3. 完整案例Step 1 · 给 AI 足够的上下文AI 出方案之前先要让它看到足够的信息。对于一个常规需求我们的输入主要有用户提示词手动书写需要包含基本的一些描述需求说明形式可以为截图或文本描述需要注意脱敏figma 设计稿形式可以是截图或 MCP 读取推荐使用 MCPAGENTS.mdagent 自动读取Step 2 · 让 AI 出方案上下文准备好之后这一轮的目标不是写代码是写方案。给 AI 的提示词大致是这样我要在菜单下新增一个模块 - 需求原型见上传的截图需要手动上传 - figma设计稿如下 https://www.figma.com/xxx 请根据需求原型、figma设计稿和当前代码上下文输出详细实现的方案。 注意 - 需求原型截图和figma设计稿中的顶部导航栏和侧边菜单栏是已有的不需要实现 - 原型截图中的红色文案是业务逻辑相关描述要重点关注 - 不清楚的地方需要和我进行确认禁止随意推测可以指定编程工具当前为 plan 模式这个 claude、codex、cursor 都支持输出实现方案。AI 输出方案示例Step 3 · 人工 Review 并修正方案我们 review 方案的时候通常会改这几类东西需求理解偏差AI 复述的需求和我们想的不一样及时纠正spec 阶段发现成本最低越界改动AI 顺手要改一些跟当前需求无关的文件要砍掉保持最小范围复用顺序错AI 想自己新写一个工具函数但目前项目里已经有了假设没说明AI 默默地假设了一些边界条件要让它显式写出来或主动进行确认遗漏边缘情况加载状态、空状态、权限、异常分支等Review 完后让 AI 重新生成 spec再进行确认直到 spec 双方都认可才进入 Step 4。示例Step 4 · 让 AI 按方案实现第二轮的提示词示例请严格按照上面确认的方案实现。 - 不引入方案之外的改动 - 实现完成后请按方案的实现步骤逐条说明你做了什么 - 如果实现过程中发现方案有问题先停下来告诉我不要自行调整或者有的 AI 工具直接提供了 spec 的 build 按钮可以不需要额外提示词。AI 生成代码示例import React, { useCallback, useEffect, useState } from react; import OverviewPanel from ./components/overviewPanel; import RecordTable from ./components/recordTable; // ...省略 const ApiMonitor: React.FC () { const [overviewData, setOverviewData] useStateIApiMonitorOverview(); const [overviewLoading, setOverviewLoading] useState(false); // ...省略 return ( div classNameapi-monitor OverviewPanel data{overviewData} loading{overviewLoading} / RecordTable data{recordData} loading{recordLoading} total{total} current{listParams.current ?? 1} pageSize{listParams.size ?? DEFAULT_PAGE_SIZE} sortField{sortField} sortOrder{sortOrder} searchForm{ SearchForm callerOptions{callerOptions} onSearch{handleSearch} onReset{handleReset} / } onPageChange{handlePageChange} onTableChange{handleTableChange} / /div ); }; export default ApiMonitor;页面效果Step 5 · 对照 Spec 做代码 Review可以让 AI 根据 spec 先 reveiw 一遍再人工进行 reveiw强烈建议大家做好本地 AI 自己人工 review 这一步可以大幅减少 MR reveiw 者的工作量。对于 MR reveiw我们主要都是在 gitlab 页面上人工 reveiw可以使用 gitlab mcp 获取 MR 信息然后让 AI 给出详细 reveiw 意见本地 AI reveiw 和 gilab 上的 AI review 不太一样本地上下文会更全也可以使用更强的 AI 模型reveiw 效果一般会比 gilab 上的好。经过 AI reveiw 后仍然需要人工仔细 review 一遍。补充说明使用 gitlab mcp 可能会导致上下文比较大可以使用内部的 gitlab-MR-code-review skill 替换也可以使用 Superpowers 的 code reveiw 功能5. 让 Spec-First 跑顺的基础设施工作流要跑顺靠的不是某次 prompt 写得好而是底下基础设施在持续起作用。5.1 AGENTS.md始终在线的团队 specAGENTS.md是仓库根的一份 Markdown 文件被 Cursor、Codex 等工具识别后每次会话自动加载。它解决了一个核心问题团队约定不需要每次都靠人工敲进 promptAI 默认就遵守。我们的 AGENTS.md 分四层按优先级从高到低层级关注点例子安全边界哪些事不能做不读.env、不自动git push、不主动pnpm install仓库边界改动作用域monorepo 多产品隔离、跨产品改动须确认工程约束技术栈 / 复用顺序React、复用顺序 公共包 → antd → 新增行为约定沟通 / 验证默认中文沟通、交付前必须跑 lint check-types下面是真实的一段摘录感受一下硬规则的写法### 3.3 安全边界 - 不自动提交代码、不自动推送分支、不改写 git 历史 commit / push / reset / rebase / git add . 等写类操作 仅在用户显式要求时执行。 - 不读取 .env*、应用运行期配置以及密钥/凭证类文件 不修改 node_modules/、构建产物、工具缓存目录。 - 不主动执行 curl / wget / ssh / scp 以及带 deploy / release / publish 关键字的命令。 - 非必要不新增依赖、不执行 pnpm install / add / update。 - 不主动启动 pnpm dev / pnpm start 等长驻服务。5.2 MCPSpec 的输入端MCP 让 AI 能像调工具一样直接读外部系统它们为什么重要以前给 AI 喂上下文靠的是人肉中转——自己看 Figma、整理成一段文字再粘给它光这一步就能耗掉小半天。MCP 把这层中转去掉了让 AI 直接拿到你能拿到的东西。MCP 的本质就是让 AI 拿到你拿到的东西。Spec-first 之所以能跑顺很大程度上靠 MCP 把上下文喂入这一步的人力成本降了下来。6. 还没解决的问题诚实讲这套工作流还有几个我们没解决的事列出来一起想6.1 怎么知道这套真的有效目前我们对AI 帮我们提了多少效率基本靠感觉。为了让这件事可量化我们最近在做一个ai-coding-stats的 skill基于 git-ai 在 commit 上记录的元数据能统计出 AI 代码有效采纳率、AI 代码提交留存率、AI 代码占比等指标。个人维度已经能跑团队维度跨仓库聚合、可视化看板还在跟进中。6.2 Spec-Driven Development 的正式形态是怎样的我目前的做法本质上是轻量版 Spec-Driven DevelopmentSDD。SDD 作为一个更系统的方法论把 spec 的形态、版本管理、自动化测试生成都做了更完整的设计。这块我也还在学欢迎讨论。6.3 跨岗位的延伸这套工作流不只前端能用但不同岗位用起来的角度可能不一样后端spec 阶段是不是天然适合做接口设计测试能不能拿 spec 直接当测试用例的输入产品spec 是不是可以为 PRD 查缺补漏需求文档的颗粒度需不需要为AI 友好做调整运维基础设施变更能不能也跑 spec-first7. 总结整篇重点让 AI 先写方案再让它按方案写代码reveiw 环节要重视用 AGENTS.md 把团队规范沉淀成 AI 默认能看到的上下文用 MCP 让 AI 拿到你想拿到的东西最后一句话AI Coding 不是“AI 替我们写代码”而是我们用一种新的方式表达意图由 AI 把意图翻译成代码。意图表达得越清楚AI 的产出就越接近你想要的。Spec-first 就是把意图表达清晰化的一个具体实践。最后欢迎关注【袋鼠云数栈 UED 团队】~袋鼠云数栈 UED 团队持续为广大开发者分享技术成果相继参与开源了欢迎 star大数据分布式任务调度系统——Taier
一套 Spec-First 的 AI 编程工作流
发布时间：2026/6/30 5:37:03
. 先说个常见的情况大家应该有遇到过这种情况接到一个需求图省事直接一句话甩给 AI ——帮我实现 xxx然后它啪地给你写了一大坨代码。乍一看挺像样但细看就会冒出一些问题它可能顺手改了几个你没让它动的文件、自己脑补了一些你没交代过的边界处理、或者明明项目里已经有现成的工具函数它非要自己再写一个。最后你花在读它到底写了啥、再把多余的改动择出去上的时间未必比自己写少多少。这不是 AI 不行而是它在信息不全的时候只能靠猜。我们没把要做什么、不要做什么讲清楚它就只好替我们做主。2. Spec-First 工作流先约定再实现2.1 一句话定义做需求前先让 AI 输出一份可被人工 review 的实现方案spec人工确认后再让它按方案写代码。注意三个关键词可被 review方案是中文说明不是直接的代码其他同学也能都看得懂人工确认spec 要通过确认后才能让 AI 去执行避免在错误前提上累积工作量按方案写第二轮 prompt 把 spec 喂回去让 AI 按既定方案写约束自由发挥的空间2.2 五步概览1. 喂上下文提示词、产品需求说明、设计稿、AGENTS.md、相关代码/文档、... 2. 出方案让 AI 输出 spec 3. Review 改方案重要的一步人工主导必须经人工确认后才可进行下一步 4. 按方案实现让 AI 严格依据 spec 编码 5. 验收 reveiwAI reveiw 人工 reveiw2.3 适用 / 不适用场景是否适用备注新功能开发✅最佳场景旧模块重构✅spec 阶段需要先对齐边界技术方案调研✅spec 就是调研报告本身Bug 修复⚠️修复 bug 主要在于问题排查改动往往是小范围的效果有限纯 Code Review❌代码审查是为了提前发现问题没有必要3. 完整案例Step 1 · 给 AI 足够的上下文AI 出方案之前先要让它看到足够的信息。对于一个常规需求我们的输入主要有用户提示词手动书写需要包含基本的一些描述需求说明形式可以为截图或文本描述需要注意脱敏figma 设计稿形式可以是截图或 MCP 读取推荐使用 MCPAGENTS.mdagent 自动读取Step 2 · 让 AI 出方案上下文准备好之后这一轮的目标不是写代码是写方案。给 AI 的提示词大致是这样我要在菜单下新增一个模块 - 需求原型见上传的截图需要手动上传 - figma设计稿如下 https://www.figma.com/xxx 请根据需求原型、figma设计稿和当前代码上下文输出详细实现的方案。 注意 - 需求原型截图和figma设计稿中的顶部导航栏和侧边菜单栏是已有的不需要实现 - 原型截图中的红色文案是业务逻辑相关描述要重点关注 - 不清楚的地方需要和我进行确认禁止随意推测可以指定编程工具当前为 plan 模式这个 claude、codex、cursor 都支持输出实现方案。AI 输出方案示例Step 3 · 人工 Review 并修正方案我们 review 方案的时候通常会改这几类东西需求理解偏差AI 复述的需求和我们想的不一样及时纠正spec 阶段发现成本最低越界改动AI 顺手要改一些跟当前需求无关的文件要砍掉保持最小范围复用顺序错AI 想自己新写一个工具函数但目前项目里已经有了假设没说明AI 默默地假设了一些边界条件要让它显式写出来或主动进行确认遗漏边缘情况加载状态、空状态、权限、异常分支等Review 完后让 AI 重新生成 spec再进行确认直到 spec 双方都认可才进入 Step 4。示例Step 4 · 让 AI 按方案实现第二轮的提示词示例请严格按照上面确认的方案实现。 - 不引入方案之外的改动 - 实现完成后请按方案的实现步骤逐条说明你做了什么 - 如果实现过程中发现方案有问题先停下来告诉我不要自行调整或者有的 AI 工具直接提供了 spec 的 build 按钮可以不需要额外提示词。AI 生成代码示例import React, { useCallback, useEffect, useState } from react; import OverviewPanel from ./components/overviewPanel; import RecordTable from ./components/recordTable; // ...省略 const ApiMonitor: React.FC () { const [overviewData, setOverviewData] useStateIApiMonitorOverview(); const [overviewLoading, setOverviewLoading] useState(false); // ...省略 return ( div classNameapi-monitor OverviewPanel data{overviewData} loading{overviewLoading} / RecordTable data{recordData} loading{recordLoading} total{total} current{listParams.current ?? 1} pageSize{listParams.size ?? DEFAULT_PAGE_SIZE} sortField{sortField} sortOrder{sortOrder} searchForm{ SearchForm callerOptions{callerOptions} onSearch{handleSearch} onReset{handleReset} / } onPageChange{handlePageChange} onTableChange{handleTableChange} / /div ); }; export default ApiMonitor;页面效果Step 5 · 对照 Spec 做代码 Review可以让 AI 根据 spec 先 reveiw 一遍再人工进行 reveiw强烈建议大家做好本地 AI 自己人工 review 这一步可以大幅减少 MR reveiw 者的工作量。对于 MR reveiw我们主要都是在 gitlab 页面上人工 reveiw可以使用 gitlab mcp 获取 MR 信息然后让 AI 给出详细 reveiw 意见本地 AI reveiw 和 gilab 上的 AI review 不太一样本地上下文会更全也可以使用更强的 AI 模型reveiw 效果一般会比 gilab 上的好。经过 AI reveiw 后仍然需要人工仔细 review 一遍。补充说明使用 gitlab mcp 可能会导致上下文比较大可以使用内部的 gitlab-MR-code-review skill 替换也可以使用 Superpowers 的 code reveiw 功能5. 让 Spec-First 跑顺的基础设施工作流要跑顺靠的不是某次 prompt 写得好而是底下基础设施在持续起作用。5.1 AGENTS.md始终在线的团队 specAGENTS.md是仓库根的一份 Markdown 文件被 Cursor、Codex 等工具识别后每次会话自动加载。它解决了一个核心问题团队约定不需要每次都靠人工敲进 promptAI 默认就遵守。我们的 AGENTS.md 分四层按优先级从高到低层级关注点例子安全边界哪些事不能做不读.env、不自动git push、不主动pnpm install仓库边界改动作用域monorepo 多产品隔离、跨产品改动须确认工程约束技术栈 / 复用顺序React、复用顺序 公共包 → antd → 新增行为约定沟通 / 验证默认中文沟通、交付前必须跑 lint check-types下面是真实的一段摘录感受一下硬规则的写法### 3.3 安全边界 - 不自动提交代码、不自动推送分支、不改写 git 历史 commit / push / reset / rebase / git add . 等写类操作 仅在用户显式要求时执行。 - 不读取 .env*、应用运行期配置以及密钥/凭证类文件 不修改 node_modules/、构建产物、工具缓存目录。 - 不主动执行 curl / wget / ssh / scp 以及带 deploy / release / publish 关键字的命令。 - 非必要不新增依赖、不执行 pnpm install / add / update。 - 不主动启动 pnpm dev / pnpm start 等长驻服务。5.2 MCPSpec 的输入端MCP 让 AI 能像调工具一样直接读外部系统它们为什么重要以前给 AI 喂上下文靠的是人肉中转——自己看 Figma、整理成一段文字再粘给它光这一步就能耗掉小半天。MCP 把这层中转去掉了让 AI 直接拿到你能拿到的东西。MCP 的本质就是让 AI 拿到你拿到的东西。Spec-first 之所以能跑顺很大程度上靠 MCP 把上下文喂入这一步的人力成本降了下来。6. 还没解决的问题诚实讲这套工作流还有几个我们没解决的事列出来一起想6.1 怎么知道这套真的有效目前我们对AI 帮我们提了多少效率基本靠感觉。为了让这件事可量化我们最近在做一个ai-coding-stats的 skill基于 git-ai 在 commit 上记录的元数据能统计出 AI 代码有效采纳率、AI 代码提交留存率、AI 代码占比等指标。个人维度已经能跑团队维度跨仓库聚合、可视化看板还在跟进中。6.2 Spec-Driven Development 的正式形态是怎样的我目前的做法本质上是轻量版 Spec-Driven DevelopmentSDD。SDD 作为一个更系统的方法论把 spec 的形态、版本管理、自动化测试生成都做了更完整的设计。这块我也还在学欢迎讨论。6.3 跨岗位的延伸这套工作流不只前端能用但不同岗位用起来的角度可能不一样后端spec 阶段是不是天然适合做接口设计测试能不能拿 spec 直接当测试用例的输入产品spec 是不是可以为 PRD 查缺补漏需求文档的颗粒度需不需要为AI 友好做调整运维基础设施变更能不能也跑 spec-first7. 总结整篇重点让 AI 先写方案再让它按方案写代码reveiw 环节要重视用 AGENTS.md 把团队规范沉淀成 AI 默认能看到的上下文用 MCP 让 AI 拿到你想拿到的东西最后一句话AI Coding 不是“AI 替我们写代码”而是我们用一种新的方式表达意图由 AI 把意图翻译成代码。意图表达得越清楚AI 的产出就越接近你想要的。Spec-first 就是把意图表达清晰化的一个具体实践。最后欢迎关注【袋鼠云数栈 UED 团队】~袋鼠云数栈 UED 团队持续为广大开发者分享技术成果相继参与开源了欢迎 star大数据分布式任务调度系统——Taier
)
![华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
![华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
