AI 发展的速度实在太快了在 GPT-3 横空出世的阶段那个时候只能使用对话框一问一答到现在各种 RAG、AI Workflow、AI Agent 等各类技术使得 AI 可以做更多的事情实现更加强大的功能。在 cursor、trae 等 AI IDE 出现后很多人便彻底迷上了这项足以颠覆传统工作模式的技术尤其在编程领域这场变革的浪潮来得尤为迅猛 —— 最初当我们面对复杂的业务功能、晦涩的语法实现或是陌生的框架调用时无需再耗费大量时间翻阅文档、调试代码只需通过自然语言向 AI 描述需求就能借助它的问答式回复获取可用的代码片段这不仅大大降低了编程的门槛更让开发者从重复的基础编码工作中得到了初步解放也为后续对话式代码生成、Vibe Code 乃至 Spec Code 等更先进的编程范式埋下了充满无限可能的种子。目前主流的 AI 辅助编程主要是 AI Agent在 AI IDE 中输入要做的功能AI 会自动读取项目文件经过思考后编写对应的代码并且会自动修正代码错误确保代码可以编译通过。这便是大语言模型催生的对话式 AI 代码生成开启了自然语言交互生成代码的时代开发者通过多轮对话让 AI 产出代码片段并手动整合AI 仅作为辅助工具随后演进的 Vibe Code氛围编程范式让开发者只需描述高阶意图即可驱动 AI 完成全量代码的编写与迭代人类角色从编码者转向需求引导者与测试者聚焦快速原型与创意验证。但是AI Agent 模式下的 AI 辅助编程也存在一些常见的问题所以在 IT 圈流行着这图感谢热心网友【迪迦】提供的图片。虽然上图有搞笑成分这里我们将问题分为大语言模型和 AI IDE 两部分下面介绍常见的 AI 辅助编程问题。大语言模型目标漂移在多步骤、长流程的编程任务中如复杂功能开发、项目重构AI 执行到中后阶段易偏离初始目标例如原本需求是优化数据库查询性能后续却无端重写 UI 组件本质是缺乏有效的目标锚定机制。重复犯错对已出现过的错误缺乏长期记忆相同问题会反复出现如未正确处理异步函数的await关键字、文件路径引用错误无法自动沉淀历史解决方案。上下文爆炸为让 AI 掌握完整项目信息需将大量代码、需求文档、历史对话塞进上下文窗口导致模型处理效率下降、响应延迟且易忽略关键信息。进度丢失依赖对话窗口存储任务状态一旦对话重置、刷新或中断之前的开发进度、中间决策、已积累的项目认知会全部消失无法无缝续工。幻觉生成在缺乏明确参考依据时可能编造不存在的 API 方法、语法规则或项目配置生成看似合理但实际无法运行的代码增加调试成本。AI IDE上下文管理能力不足多数 AI IDE 未建立独立的外部记忆机制仍依赖模型自带的上下文窗口无法高效关联项目文件、历史操作记录难以支撑复杂任务的连贯开发。任务追踪与可视化缺失缺乏对编程任务的结构化拆解与进度可视化功能无法像task_plan.md那样清晰呈现阶段划分、完成状态、决策依据开发者难以掌控 AI 的工作轨迹。错误记录与复用薄弱未集成错误追踪体系AI 遇到的报错、修复方案无法自动归档既不便于开发者回溯问题根源也无法让 AI 后续快速复用已验证的解决方案。文件协同与持久化不足对 AI 生成的中间产物如调研笔记、技术选型文档缺乏统一的存储与管理机制文件分散且易丢失无法形成可追溯、可复用的项目知识库。人机协作衔接不畅开发者难以直接干预 AI 的任务执行流程例如无法通过编辑结构化计划文件调整开发方向也缺乏便捷的方式审查 AI 的决策逻辑导致人机协同效率低下。性能与成本失衡处理大规模项目时频繁加载全量上下文会导致 IDE 运行卡顿且重复处理相同静态内容如项目框架定义、工具配置会增加 Token 消耗提升使用成本。所以在目前的技术局限下要玩 AI 编程其实还不能为所欲为同时使用 AI 编程时也会碰到很多阻碍问题降低了编程的体验和项目代码质量。AI 编程下的团队协作痛点与核心诉求前面介绍了 AI 编程本身容易出现的问题和技术局限回到以团队为单位进行 AI 编程协作时当团队缺乏标准化协作机制时AI 编程易陷入 “单兵作战” 的困境会出现更加多的头疼的问题。因为笔者在公司带一个项目组已经有很多成员使用 AI 写代码在经过一段时间的观察和思考后发现了一些问题所以才想到写这篇文章的相信这些问题在大家的公司里面也会存在。代码碎片化很多同事发现用 AI 写代码可以早点下班于是大家都用 AI 写代码你写你的我写我的导致成员各自使用 AI 生成代码风格、逻辑差异显著模块衔接困难后期维护成本激增。反正同事用 AI 写的代码我是压根不想维护。规范失控大家应该都有感受在不同提示词、编写不同功能时AI 编写的代码风格各异没有统一的规范和风格AI 生成代码可能偏离团队代码规范、安全标准埋下质量隐患。知识孤岛个人使用 AI 积累的经验无法共享团队整体效率难以提升。你用 cursor我用 kiro各写各的代码没法为团队沉淀知识经验提示词、功能历史记录、背景上下文等完全没法在团队内共享每个人都得在本地使用 AI 阅读代码生成上下文记忆。协作低效AI 写的代码实际上会出现一个简单的功能写一堆代码的情况也有可能 A 同事写 A 功能时生成了 CB 同事写 B 功能时又生成了一个类似的 C项目各种代码错综复杂。导致难以统一任务分配、进行代码评审流程导致信息传递滞后冲突频发。除了以上问题在团队编程中需要解决很多公司都有代码质量规范要求、安全要求、单元测试覆盖率要求所以基于这些问题和常见公司编程要求笔者认为团队 AI 编程的核心诉求应聚焦维持一致代码质量防止安全漏洞减少重复工作量标准化协作流程加快开发周期实现从 “快速原型” 到 “工程化落地” 的跨越。很多领导对 AI 编程的想法很难评觉得可以 ”降本增效“ 一个项目平时需要一个月做完用 AI 一天就行代码还能写得比开发还好这样可以开除很多开发人员所以号召大家在公司使用 AI 编程。后面会提到 AI 辅助编程大约可以提高多少速度但不可能是一天写完一个月的代码。而实际上除非原因开盲盒产品做得怎么样取决于 AI 怎么写前期速度确实很快。但是到了中后期AI 写的代码难以维护反而会因为要 AI 写代码花费大量时间编写提示词为了实现一个小需求可能要跟 AI 一直对骂最终陷入混乱。其实正如笔者前面所说的大语言模型和 AI IDE 在目前有一些技术局限而且在团队使用 AI 编程时会带来很多协作问题如果没有应对这些问题的解决方法那么使用 AI 编写的代码最终可能是一片混乱而且生成代码人类可能无法阅读鬼才知道 AI 写的是啥。公司落地 AI 编程确实可以提高开发速度缩短开发周期但是不应该荒谬到认为 ”一个月工作量使用 AI 一天就行“ 。笔者认为除了提速应当更多聚焦实现前面提到的 AI 编程的核心诉求。很多公司天天鼓吹单元测试、代码规范、高性能高质量代码给开发指定单元测试覆盖率和代码审查等指标反复折腾开发人员但是公司存在各种各样的开发管理和技术问题盲目定制高要求的开发指标完全解决不了当前的问题又会使得开发身心疲倦。笔者之所以要说这些是因为代码审查、代码规范、单元测试等做起来没有那么简单有多少公司折腾这些又能最终真正做到能不能做好这些其实跟公司基因有关系跟落地难度也有关系。其实只有足够简单规范才能真正落地。所以笔者一直在思考如何解决 AI 编程下的团队协作痛点与满足核心诉求并且真正落地单元测试、代码审查等技术要求。这就是本文的重点AI Spec到底要怎么做接下来本文将以架构师的角度去思考去研究我们是架构师那么应该怎么把 AI 编程落地到团队协作中。规范开发(Spec development)前面提到AI 辅助编程逐渐成为主流大部分开发人员已经在日常工作中使用 AI 编写代码但是也会引入很多问题导致生成很多不可预测的、质量参差不齐的代码。那么为了解决这些问题出现了 SDD(Spec-Driven Development) 这种概念强调在使用 AI 编写代码之前先有 Specification以便约束 AI 生成高质量的、符合业务需求和技术要求的代码。目前社区中主要存在三类 SDD 工具OpenSpec、Kiro、Spec-Kit。为了实现 Spec development选择 SDD 工具时需要考虑工具与流程适配选择 Kiro 这类支持规范定制、多场景协作的 AI 工具避免工具功能与团队流程脱节重视规范落地将团队规则转化为可执行的钩子、Spec 模板借助 AI 强制落地而非仅停留在文档层面构建协作文化鼓励成员主动共享 AI 使用经验、参与流程优化避免 “单兵作战” 思维平衡自动化与人工AI 负责标准化、重复性工作如测试、规范检查人类聚焦核心架构与创意决策实现人机协同增效。在本文笔者要讲解的是 Kiro 落地的内容。在搜索资料的过程中笔者发现几篇写得不错的文章这里供读者参考本文就不单独讲解这些 SDD 工具了。AI 规范驱动开发“三剑客”深度对比Spec-Kit、Kiro 与 OpenSpec 实战指南 - 技术栈https://jishuzhan.net/article/1988226029513670657Transforming Dev Practices with Kiro’s Spec-Driven Tools | AI Native Devhttps://ainativedev.io/transforming-dev-practices-with-kiros-spec-driven-tools这里简单介绍一下 Kiro。Kiro 是亚马逊云科技推出的 AI IDE以 “规范驱动开发” 为核心完美适配团队协作需求。对国内用户友好无需特殊网络配置。团队对齐AI 编程核心概念解析在深入团队协作实践前需先明确支撑 AI 编程的关键技术概念无论是产品还是测试也必须了解 LLM、MCP、Agent 等概念需要团队对一些知识都过关确保整个团队交流协作不存在知识障碍。这些概念的知识笔者就不赘述了。主流大语言模型用于编程的评分作为架构师需要清晰了解不同模型的特长和优缺点在编程领域哪个模型最优秀最适合用于编程。笔者发现几个网站很不错有各类模型的介绍和评分地址Best LLMs for Coding | LLM Leaderboardshttps://llm-stats.com/https://www.aibase.com/zh主流企业使用 AI 辅助编程提升的效率。要是领导觉得你一个月写的代码不如 AI 一天写的那就尴尬了。作为技术人员必须合理评估使用 AI 编程后整个团队到底提升了多少效率编码速度提高了多少。比如根据这篇研究报告完成任务的编码速度大概提升了21%报告地址 https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/而根据豆包联网搜索总结的内容来看提升的开发速度并没有那么夸张。总而言之打造 AI 辅助编程团队要求团队人员对 AI 有足够的认识了解基础知识并且争取在 AI 编程上的认知一致否则可能会闹出各种笑话被人引为笑谈。知识和认知都很重要否则团队分分钟散架。项目模板为什么要使用开发框架这个事情不用多说C# 开发应该知道 ABP 框架Go 开发应该知道 gin、beego使用框架后大大简化了开发负担。在使用开发框架的情况下其实团队还需要定制项目模板以便适配公司技术栈以及约束公司内的一些技术要求例如审计属性、微服务通讯方式和鉴权等好的项目模板可以统一开发模式和习惯。笔者在写个人开源项目过程中结合 DDD 、清洁架构、CQRS 的一些概念辅以 AI 编程形成了个人开发习惯所以为了写这篇文章整理了一个模板项目https://github.com/whuanle/aispec如果以我的开发习惯来定我会使用模块化 CQRS每个业务领域遵循三层模块化架构无论开发还是做单元测试都比较简单。src/{domain}/ ├── MoAI.{Domain}.Shared/ # 共享层 - DTO、Command、Query 定义 ├── MoAI.{Domain}.Core/ # 核心层 - Handler 实现、业务逻辑 └── MoAI.{Domain}.Api/ # API 层 - Controller/Endpoint 暴露依赖关系Api → Core → Shared具体参考代码编写约束参考https://github.com/whuanle/aispec/blob/master/.kiro/steering/cqrs-conventions.md具体设计思路和各类细节就不讲解本节其实目的是说无论你使用何种开发框架是否使用 DDD还是传统三层结构团队应该要有一个统一的项目模板以及开发习惯约束AI 会参考项目已有代码和约束文件编写符合要求的代码避免代码天马行空。关于模板项目就不展开说了读者可以在这里找到这个本身用于实战演示的模板项目https://github.com/whuanle/aispec准备定制团队规则与项目索引在使用 AI 编程时会有一些常见问题1开发跟 AI 容易陷入盲目对话AI 始终没有给出想要的代码导致代码可用率和确定性低下。2开发难以清晰准确向 AI IDE表达目标方案和代码3前置需要大量精力对项目的 Rules、Docs 进行编写和积累4啥都让 AI 写但是 AI 写出来的方案总是不满意解决这些问题本身不难但是要落到团队协作中作为架构师就要思考更多了需要保证代码质量和开发效率避免反复处理这些问题。什么是 Steering这里的 steering 其实是 Kiro 里面的概念目的是让 AI 编程过程中始终遵循团队已建立的 patterns、libraries、standards。https://kiro.dev/docs/steering/也就是说基于团队的项目模板我们要指定一些跟业务无关的技术约束例如审计属性怎么定这个开发框架/项目模板怎么使用不同功能的代码文件怎么命名等都可以写到 Kiro steering 里面。AI 在写代码时会一直围绕这些 steering 去写如果写出的代码不符合 steering 要求则 AI 会逐步修正代码。那么团队要落地代码规范是不是变简单了前面提到的 AI 编程的问题和核心诉求是不是可以解决了是的所以要重视项目模板和 steering在团队开发实现需求之前就应该定制团队乃至公司研发部门的 steering。常见 Steering 文件策略后面会提到 Kiro 默认会有的 steering 规则模板但是从团队的角度考虑可能还需要这些 steering API 标准(api-standards.md) - 定义 REST 约定、错误响应格式、认证流程和版本策略。包括端点命名模式、HTTP 状态码使用和请求/响应示例。测试方法(testing-standards.md) - 建立单元测试模式、集成测试策略、模拟方法和覆盖率期望。记录首选测试库、断言样式和测试文件组织。代码风格(code-conventions.md) - 指定命名模式、文件组织、导入排序和架构决策。包括首选代码结构、组件模式和要避免的反模式示例。安全指南(security-policies.md) - 记录认证要求、数据验证规则、输入清理标准和漏洞预防措施。包括特定于您应用程序的安全编码实践。部署流程(deployment-workflow.md) - 概述构建程序、环境配置、部署步骤和回滚策略。包括 CI/CD 管道详细信息和环境特定要求。当然这些 steering 不需要都首选可以先做一个项目模板然后让 Kiro 阅读代码并生成即可。不同公司团队可能有不同要求只要看着写就行可以在摸索的过程中逐渐积累团队经验逐渐完善 steering。核心执行AI 驱动的协作流程设计团队协作 AI 编程把要做的功能丢在对话框让 AI 写代码就行No大错特错让我们回到 Kiro 的介绍Agentic AI development from prototype to production翻译过来是从原型到产品的 Agentic AI 开发。注意要玩 AI 编程我们是要做从原型到产品整个周期的东西而不单单是用 AI 写完代码早点下班。所以要考虑团队的角色有哪些大家应该怎么参与协作更重要的是怎么设计新的团队研发流程。不同公司的团队组成不一样所以笔者按照常规团队产品、UI设计师、前后端开发、测试组成来讲解后面的内容。感谢这位作者的文章给了我很多想法https://aicodingtools.blog/zh/kiro/kiro-spec-guide使用 AI 编程后团队中各个角色要负责的内容会发生变化要求工作输出的内容能够被 AI 识别并引用并且在团队内流通。如果产品输出的需求文档AI 都不会分析总结你给开发看逻辑狗屁不通AI 怎么写代码产品的需求文档可以经过开发整理后作为让 AI 编写代码的提示词和需求约束大大减轻开发的负担。开发和测试将会大大依赖需求文档或其它形式的文档因为需求文档会作为开发、测试和验收依据在 AI 编程阶段就要让 AI 知道写代码还要考虑怎么测试和验收不能等让 AI 写完代码再叫 AI 写单元测试、检查验收能不能过。另外前期准备阶段也依赖架构师或 leader 的架构设计和功能实现设计而不是说 ”实现一个短链接服务将长链接缩短为短链接“技术负责人需要思考和设计使用何种算法缩短地址、还原地址怎么存储到数据库高并发环境下怎么提高并发量和减少对数据库的压力。所以要思考使用 AI 编程落地后团队需要哪些角色每个角色要负责哪些内容整个研发流程应该分哪些阶段每个公司情况都是不一样的所以针对这些问题笔者没有什么说法和观点不过后面实战部分会提到 Kiro Specs 是怎么划分研发流程阶段。笔者设想未来围绕 AI 辅助编程开发团队的角色和参与内容可能发生重大改变。一是团队开发流程发生改变不再像以往从产品原型设计、需求会、开发、提测的模式而是围绕 AI 编程更加靠敏捷开发模式接近。二是团队角色负责的内容发生改变更多围绕产生的资料能够被 AI 吸收知识可以沉淀减少信息流通的难度以及降低产品、设计师、开发、测试之间的知识和职责边界。三是可能会出现以 AI 编程为中心的产品研发一体化平台无论是产品、设计师、开发、测试都可以围绕这个平台进行符合自己角色的参与例如产品编写需求文档和验收文档时可以借助 AI 平台检测需求是否合理、调整设计、细化需求转化为开发人员便于阅读的文档。产品、设计师通过需求文档借助 AI 平台快速实现产品原型设计。开发人员则可以将需求导入 AI创建开发任务逐步与 AI 协作编写代码还可以借助 AI 快速生成单元测试、集成测试等最后根据验收文档验证检测最终输出。而关于团队的研发流程则会在 工作流程 一节详细讲解。总结作为文章的第二部分主要是思考怎么建设使用 AI 辅助编程的团队以及进行团队协作。第三部分将会讲解实战从原型到产品的整个环节每个步骤应该做什么。实战作为文章的第三部分内容将会以短链接服务为案例去讲解如何落地实战团队协作和 AI 编程去设计一个以 AI 辅助开发为核心的项目研发流程。思考整体架构AI 时代还需要我去设计项目是的开发人员要自行对技术方案进行调研、上手尝试然后让 AI 根据你的方案和设计做出来不要都让 AI 帮你做解决方案。只需要一个 ideaAI 就可以写代码可是 AI 写出来的东西可能跟专业人员需要的东西相去甚远并且还有大量细节满足不了需求开发人员可能会陷入跟 AI 的对骂中不断调整提示词不断等待 AI 生成最终生成了 90% 的内容剩下的 10%开发人员只能对着键盘一点点敲完。虽然是 AI 编程但是编程的重点是人的想法和需求而不是 AI 的天马行空虽然 AI 实现的项目可能有很多很好的创意和想法质量可能很好但是对于专业领域和公司业务项目来说需求的中心是公司对应的业务而不是一个 idea。而且 AI 有上下文限制有幻觉等你只需要一个简单的一个登录功能可能 AI 把单点登录、OAuth2 等一堆东西给你加上去了目标偏移。所以即使在 AI 时代我们也要构思项目设计和功能实现的算法和逻辑让 AI 在这个边界内实现代码和测试。当然我们可以利用 AI 去帮助我们验证想法和构思设计然后将这些内容生成为架构设计和技术方案。短链接服务的架构由于本文的重点不是怎么实现一个短链接服务所以笔者这里只简单讲解这个服务的一些算法和实现思路以便后续使用 AI 写出符合需求的代码。核心问题1短链接生成和还原核心问题2短链接存储和查找笔者的设计是短链接跟长链接无直接映射关系也就是不能通过算法转换直接将长链接生成短链接。对于每个长链接创建记录存到数据库时会使用 int64 雪花做主键存到数据库。例如新增一个长链接https://whuanle.cn当前雪花id 是 2009194627277520896经过检查数据库没有重复数据后存储到数据库。接着将雪花 id 使用 base62 生成短链接编码。之所以使用 base62 做缩短编码是因为[0-9]、[a-z]、[A-Z]刚刚好是 62 个字符能够在不使用特殊符号的情况下使用数字和大小写字母表达值也就是相当于 62 进制。将 2009194627277520896 使用 base62 编码是得出字符串是00E3uWKkzx而存数据只需要一个 int64 就行。满足能够将长链接生成短链接存储空间小不容易被人碰撞规则的需求。有了短链接生成和还原算法后我们继续聊一下数据查找。用户访问/00E3uWKkzx时还原得到 2009194627277520896然后通过这个 id 从数据库查找数据得到https://whuanle.cn然后让用户跳转到这个地址即可。每次都要查数据库数据库压力大而且万一被人攻击机器人随机拼接的字符串也要到数据库检查数据在不在数据库迟早被打崩。所以第一层是使用 redis 的布隆过滤器先判断数据是否存在。第二层数据分片将数据存储到 redis避免频繁从数据库查找。还可以做本地离线缓存避免高频度从 redis 查找数据。也就是最终是三层缓存。其它就不多说了前面提到的算法处理逻辑将会作为后续 AI 编写功能的依据。模板项目首选是安装笔者提供的项目模板。dotnet new install Maomi.AiSpec.Templates执行命令从模板创建新的项目将MyShortUri替换为你需要的项目名称即可。dotnet new aispec -n MyShortUri后端开发原则和规范使用 Kiro 打开MyShortUri项目 在 AGENT STEERING 菜单可以看到已经模板自带四个 steering 文件。Kiro 通过.kiro/steering/目录中的 markdown 文件设置项目约束规定Kiro 只规定了 product.md、tech.md、structure.md 三个文件这些基础文件默认包含在每次交互中形成 Kiro 项目理解的基线。cqrs-conventions.md 则是笔者的模板项目的开发规则约定 AI 生成的代码文件如何存放以及代码格式约束AI 会生成符合项目要求的代码。读者也可以创建一些其它文件例如rest-api.md要求生成的 api 接口需要符合 restapi 格式将公司研发规范等写入到.kiro/steering/目录。后端代码规范约束cqrs-conventions.md是笔者自定义的 steering 文件用来约束 AI 生成的代码必须分为Command/Query、Api、Handler三层的 CQRS 结构。定义了很多约束规范这里就不讲解了自己研究一下。我要做什么样的产品拉取项目模板后第一步是修改product.md告诉 AI 这是一个短链接项目。产品概述(product.md) - 定义产品的目的、目标用户、关键功能和业务目标。一般来说产品概述(product.md) 是产品经理的工作任务开发只需要将产品经理写的文档拷贝到代码项目即可不过既然现在没有产品经理我们可以一句话描述核心需求让 Kiro 帮助我们生成具体的产品说明等 AI 生成后根据实际情况调整好product.md文件。生成效果项目结构项目结构(structure.md) - 概述文件组织、命名约定、导入模式和架构决策这确保生成的代码无缝融入现有的代码结构里面这样 AI 不会乱创建文件以及随便找个地方塞代码。structure.md要常常随着项目的进展而更新不要一直不变每次新增模块后都要重新生成structure.md。现在我们点击 Kiro 的Refine重新生成structure.md。技术约定技术栈(tech.md) - 记录这个项目选择的框架、库、开发工具和技术约束当 Kiro 建议实现方案时它会优先选择已建立的技术栈而非替代方案。突然想起来一个事情某同事写 Go 语言程序需要解决一个打印功能结果用 AI 写的代码引入了 python后面被我发现了我要求用 Go 重写然后某同事又用 AI 劈里啪啦写了一天总算用 Go 写出来了。所以tech.md可以避免这种情况不然 AI 为了实现一个功能到处查资料然后引入一堆依赖用一种意想不到的方式去实现功能。现在我们点击 Kiro 的Refine重新生成tech.md例如这个项目使用的技术栈如下| Category | Technology | |----------|------------| | Framework | ASP.NET Core 9 | | Language | C# 12 (nullable reference types enabled) | | ORM | Entity Framework Core 9 (MySQL) | | CQRS | MediatR | | Validation | FluentValidation | | Authentication | JWT Bearer tokens | | Logging | Serilog | | API Docs | OpenAPI/Swagger with Scalar UI | | Caching | Redis (StackExchange.Redis) | | Module System | Maomi.Core | | Code Analysis | StyleCop.Analyzers |作者还可以加上接口设计约定等文件这里不再赘述。数据库设计现在出现了一个使用 AI 做数据库设计方案的方向Text2SQL。Text2SQL 指将自然语言转换为 SQL 的技术当一个项目从零开始时我们可以借助 AI 构思、设计项目架构最后总结输出 SQL这一步其实比较简单。但是后续项目迭代后需要 AI 去了解整个数据库表结构需要 AI 根据业务情况设计新的索引、字段约束等这就要求 AI 需要挖掘数据价值应对复杂的分析任务才能给出合理的数据库变更建议。可以借助专业的 AI DB 客户端去做例如 Chat2DB、也可以在 Kiro 装上 MCP 工具读取数据库由于不是本文重点这里只讲解思路就不再详细讲述。数据库创建表以便后续实战让 AI 写代码。CREATE TABLE short_url ( id bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 唯一ID对应短链接编码, long_url varchar(2048) NOT NULL COMMENT 原始长链接, hash varbinary(32) NOT NULL COMMENT 网址哈希值方便对比, create_user_id int(11) NOT NULL DEFAULT 0 COMMENT 创建人, create_time datetime NOT NULL DEFAULT current_timestamp() COMMENT 创建时间, update_user_id int(11) NOT NULL DEFAULT 0 COMMENT 更新人, update_time datetime NOT NULL DEFAULT current_timestamp() ON UPDATE current_timestamp() COMMENT 更新时间, is_deleted bigint(20) NOT NULL DEFAULT 0 COMMENT 软删除, PRIMARY KEY (id), KEY short_url_hash_index (hash) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT短链接 CREATE TABLE user ( id int(11) NOT NULL AUTO_INCREMENT COMMENT 用户ID, user_name varchar(50) NOT NULL COMMENT 用户名, email longtext NOT NULL COMMENT 邮箱, password varchar(255) NOT NULL COMMENT 密码, nick_name varchar(50) NOT NULL COMMENT 昵称, password_salt varchar(255) NOT NULL COMMENT 计算密码值的salt, is_deleted bigint(20) NOT NULL COMMENT 软删除, create_user_id int(11) NOT NULL COMMENT 创建人, create_time datetime NOT NULL DEFAULT utc_timestamp() COMMENT 创建时间, update_user_id int(11) NOT NULL COMMENT 最后修改人, update_time datetime NOT NULL DEFAULT utc_timestamp() COMMENT 最后更新时间, PRIMARY KEY (id), UNIQUE KEY users_user_name_is_deleted_uindex (user_name,is_deleted) ) ENGINEInnoDB AUTO_INCREMENT2 DEFAULT CHARSETutf8mb4 COMMENT用户修改数据库链接启动 MysqlScaffold 还原数据库生成代码将Database目录的文件放到对应位置接口。您看有个项目模板多重要很多时候省下大量的时间例如笔者这个模板先设计数据库然后定制数据库生成代码的步骤使得生成的实体结构和 数据库上下文类能够符合业务需求大大提高开发效率。UI 原型设计UI 原型设计就是 UI 设计师根据产品原型设计页面的过程随着专业的原型设计工具支持 AI 后产品经理跟 UI 设计师更好地协作有时候一句话就可以生成一个不错的界面。产品经理可以借助这些 AI 工具快速实现原型页面。由于墨刀的 AI 需要付费使用太贵了本来想演示 AI 根据设计稿生成页面代码的最后放弃了用这钱买了几盒凤爪。本节意思读者理解就行就是说目前市面上有很多 AI 生成设计稿的产品产品可以不用化那么多时间画原型了可以专心思考产品设计和流程逻辑最大程度输出文档把画原型这些事情留给 AI然后还可以进一步转换为 UI设计师也可以借助 AI 快速实现初版界面。后端开发实战基于项目模板和 steering其实一句话需求就可以让 Kiro 给我们编写一个模块的后端代码。但是 Kiro 提出了 Specs让团队协作和开发人员早点下班的神器。Specs 弥合了概念产品需求和技术实施细节之间的差距确保了一致性并减少了开发迭代。Specs 提供了一种系统化的方法将需求和想法转化为详细的实施计划生成验收标准、技术实现和代码生成及测试验收计划。接下来我们将会使用 Kiro Specs 生成某个功能的工作流程最后根据方案生成代码并通过测试验收代码。实现创建短链接的接口要做短链接服务第一步是实现一个长链接转短链接的功能Kiro Specs 要求编码之前需要按照三阶段工作流程进行需求 → 设计 → 实施。在 Kiro 面板中点击Specs下的按钮或者从聊天面板中选择Spec在对话框内输入要做的功能。Create Spec: 实现创建短链接的接口创建的数据存储到 ShortUrlEntity使用雪花id赋值id将长地址使用 SHA-256 生成 32 字节存储到 hash 字段。插入数据时要判断数据库是否存在对应的数据。按照引导操作后最后一步会显示 “保留可选任务更快完成 MVP”、“全部设为必需完整测试覆盖”。如果选择了 “全部设为必需完整测试覆盖”AI 在任务列表加上基于属性的测试要求和执行步骤Kiro 从提出的需求中提取属性并生成测试用例以便确保 AI 生成的代码符合开发者的意图。Kiro 文档里面解释属性对于任何一组具有特定前提条件的输入某些预期行为是成立的。Kiro 从格式化的需求中提取属性 (例如“THE System SHALL 允许经过认证的用户查看活动车辆列表”)确定哪些属性可以进行逻辑测试然后在你选择运行它们时生成数百或数千个随机测试用例。结果一顿操作后需求已经下发到.kiro/specs/create-short-urlKiro 会生成三个关键文件这三个文件构成一个 spec。requirements.md使用结构化的 EARS 记号法捕获用户故事和验收标准design.md记录技术架构、序列图和实施考虑因素tasks.md提供详细的实施计划包含离散的、可跟踪的任务
团队落地 AI 辅助编程和 AI Specs 实战
发布时间：2026/6/20 14:29:29
AI 发展的速度实在太快了在 GPT-3 横空出世的阶段那个时候只能使用对话框一问一答到现在各种 RAG、AI Workflow、AI Agent 等各类技术使得 AI 可以做更多的事情实现更加强大的功能。在 cursor、trae 等 AI IDE 出现后很多人便彻底迷上了这项足以颠覆传统工作模式的技术尤其在编程领域这场变革的浪潮来得尤为迅猛 —— 最初当我们面对复杂的业务功能、晦涩的语法实现或是陌生的框架调用时无需再耗费大量时间翻阅文档、调试代码只需通过自然语言向 AI 描述需求就能借助它的问答式回复获取可用的代码片段这不仅大大降低了编程的门槛更让开发者从重复的基础编码工作中得到了初步解放也为后续对话式代码生成、Vibe Code 乃至 Spec Code 等更先进的编程范式埋下了充满无限可能的种子。目前主流的 AI 辅助编程主要是 AI Agent在 AI IDE 中输入要做的功能AI 会自动读取项目文件经过思考后编写对应的代码并且会自动修正代码错误确保代码可以编译通过。这便是大语言模型催生的对话式 AI 代码生成开启了自然语言交互生成代码的时代开发者通过多轮对话让 AI 产出代码片段并手动整合AI 仅作为辅助工具随后演进的 Vibe Code氛围编程范式让开发者只需描述高阶意图即可驱动 AI 完成全量代码的编写与迭代人类角色从编码者转向需求引导者与测试者聚焦快速原型与创意验证。但是AI Agent 模式下的 AI 辅助编程也存在一些常见的问题所以在 IT 圈流行着这图感谢热心网友【迪迦】提供的图片。虽然上图有搞笑成分这里我们将问题分为大语言模型和 AI IDE 两部分下面介绍常见的 AI 辅助编程问题。大语言模型目标漂移在多步骤、长流程的编程任务中如复杂功能开发、项目重构AI 执行到中后阶段易偏离初始目标例如原本需求是优化数据库查询性能后续却无端重写 UI 组件本质是缺乏有效的目标锚定机制。重复犯错对已出现过的错误缺乏长期记忆相同问题会反复出现如未正确处理异步函数的await关键字、文件路径引用错误无法自动沉淀历史解决方案。上下文爆炸为让 AI 掌握完整项目信息需将大量代码、需求文档、历史对话塞进上下文窗口导致模型处理效率下降、响应延迟且易忽略关键信息。进度丢失依赖对话窗口存储任务状态一旦对话重置、刷新或中断之前的开发进度、中间决策、已积累的项目认知会全部消失无法无缝续工。幻觉生成在缺乏明确参考依据时可能编造不存在的 API 方法、语法规则或项目配置生成看似合理但实际无法运行的代码增加调试成本。AI IDE上下文管理能力不足多数 AI IDE 未建立独立的外部记忆机制仍依赖模型自带的上下文窗口无法高效关联项目文件、历史操作记录难以支撑复杂任务的连贯开发。任务追踪与可视化缺失缺乏对编程任务的结构化拆解与进度可视化功能无法像task_plan.md那样清晰呈现阶段划分、完成状态、决策依据开发者难以掌控 AI 的工作轨迹。错误记录与复用薄弱未集成错误追踪体系AI 遇到的报错、修复方案无法自动归档既不便于开发者回溯问题根源也无法让 AI 后续快速复用已验证的解决方案。文件协同与持久化不足对 AI 生成的中间产物如调研笔记、技术选型文档缺乏统一的存储与管理机制文件分散且易丢失无法形成可追溯、可复用的项目知识库。人机协作衔接不畅开发者难以直接干预 AI 的任务执行流程例如无法通过编辑结构化计划文件调整开发方向也缺乏便捷的方式审查 AI 的决策逻辑导致人机协同效率低下。性能与成本失衡处理大规模项目时频繁加载全量上下文会导致 IDE 运行卡顿且重复处理相同静态内容如项目框架定义、工具配置会增加 Token 消耗提升使用成本。所以在目前的技术局限下要玩 AI 编程其实还不能为所欲为同时使用 AI 编程时也会碰到很多阻碍问题降低了编程的体验和项目代码质量。AI 编程下的团队协作痛点与核心诉求前面介绍了 AI 编程本身容易出现的问题和技术局限回到以团队为单位进行 AI 编程协作时当团队缺乏标准化协作机制时AI 编程易陷入 “单兵作战” 的困境会出现更加多的头疼的问题。因为笔者在公司带一个项目组已经有很多成员使用 AI 写代码在经过一段时间的观察和思考后发现了一些问题所以才想到写这篇文章的相信这些问题在大家的公司里面也会存在。代码碎片化很多同事发现用 AI 写代码可以早点下班于是大家都用 AI 写代码你写你的我写我的导致成员各自使用 AI 生成代码风格、逻辑差异显著模块衔接困难后期维护成本激增。反正同事用 AI 写的代码我是压根不想维护。规范失控大家应该都有感受在不同提示词、编写不同功能时AI 编写的代码风格各异没有统一的规范和风格AI 生成代码可能偏离团队代码规范、安全标准埋下质量隐患。知识孤岛个人使用 AI 积累的经验无法共享团队整体效率难以提升。你用 cursor我用 kiro各写各的代码没法为团队沉淀知识经验提示词、功能历史记录、背景上下文等完全没法在团队内共享每个人都得在本地使用 AI 阅读代码生成上下文记忆。协作低效AI 写的代码实际上会出现一个简单的功能写一堆代码的情况也有可能 A 同事写 A 功能时生成了 CB 同事写 B 功能时又生成了一个类似的 C项目各种代码错综复杂。导致难以统一任务分配、进行代码评审流程导致信息传递滞后冲突频发。除了以上问题在团队编程中需要解决很多公司都有代码质量规范要求、安全要求、单元测试覆盖率要求所以基于这些问题和常见公司编程要求笔者认为团队 AI 编程的核心诉求应聚焦维持一致代码质量防止安全漏洞减少重复工作量标准化协作流程加快开发周期实现从 “快速原型” 到 “工程化落地” 的跨越。很多领导对 AI 编程的想法很难评觉得可以 ”降本增效“ 一个项目平时需要一个月做完用 AI 一天就行代码还能写得比开发还好这样可以开除很多开发人员所以号召大家在公司使用 AI 编程。后面会提到 AI 辅助编程大约可以提高多少速度但不可能是一天写完一个月的代码。而实际上除非原因开盲盒产品做得怎么样取决于 AI 怎么写前期速度确实很快。但是到了中后期AI 写的代码难以维护反而会因为要 AI 写代码花费大量时间编写提示词为了实现一个小需求可能要跟 AI 一直对骂最终陷入混乱。其实正如笔者前面所说的大语言模型和 AI IDE 在目前有一些技术局限而且在团队使用 AI 编程时会带来很多协作问题如果没有应对这些问题的解决方法那么使用 AI 编写的代码最终可能是一片混乱而且生成代码人类可能无法阅读鬼才知道 AI 写的是啥。公司落地 AI 编程确实可以提高开发速度缩短开发周期但是不应该荒谬到认为 ”一个月工作量使用 AI 一天就行“ 。笔者认为除了提速应当更多聚焦实现前面提到的 AI 编程的核心诉求。很多公司天天鼓吹单元测试、代码规范、高性能高质量代码给开发指定单元测试覆盖率和代码审查等指标反复折腾开发人员但是公司存在各种各样的开发管理和技术问题盲目定制高要求的开发指标完全解决不了当前的问题又会使得开发身心疲倦。笔者之所以要说这些是因为代码审查、代码规范、单元测试等做起来没有那么简单有多少公司折腾这些又能最终真正做到能不能做好这些其实跟公司基因有关系跟落地难度也有关系。其实只有足够简单规范才能真正落地。所以笔者一直在思考如何解决 AI 编程下的团队协作痛点与满足核心诉求并且真正落地单元测试、代码审查等技术要求。这就是本文的重点AI Spec到底要怎么做接下来本文将以架构师的角度去思考去研究我们是架构师那么应该怎么把 AI 编程落地到团队协作中。规范开发(Spec development)前面提到AI 辅助编程逐渐成为主流大部分开发人员已经在日常工作中使用 AI 编写代码但是也会引入很多问题导致生成很多不可预测的、质量参差不齐的代码。那么为了解决这些问题出现了 SDD(Spec-Driven Development) 这种概念强调在使用 AI 编写代码之前先有 Specification以便约束 AI 生成高质量的、符合业务需求和技术要求的代码。目前社区中主要存在三类 SDD 工具OpenSpec、Kiro、Spec-Kit。为了实现 Spec development选择 SDD 工具时需要考虑工具与流程适配选择 Kiro 这类支持规范定制、多场景协作的 AI 工具避免工具功能与团队流程脱节重视规范落地将团队规则转化为可执行的钩子、Spec 模板借助 AI 强制落地而非仅停留在文档层面构建协作文化鼓励成员主动共享 AI 使用经验、参与流程优化避免 “单兵作战” 思维平衡自动化与人工AI 负责标准化、重复性工作如测试、规范检查人类聚焦核心架构与创意决策实现人机协同增效。在本文笔者要讲解的是 Kiro 落地的内容。在搜索资料的过程中笔者发现几篇写得不错的文章这里供读者参考本文就不单独讲解这些 SDD 工具了。AI 规范驱动开发“三剑客”深度对比Spec-Kit、Kiro 与 OpenSpec 实战指南 - 技术栈https://jishuzhan.net/article/1988226029513670657Transforming Dev Practices with Kiro’s Spec-Driven Tools | AI Native Devhttps://ainativedev.io/transforming-dev-practices-with-kiros-spec-driven-tools这里简单介绍一下 Kiro。Kiro 是亚马逊云科技推出的 AI IDE以 “规范驱动开发” 为核心完美适配团队协作需求。对国内用户友好无需特殊网络配置。团队对齐AI 编程核心概念解析在深入团队协作实践前需先明确支撑 AI 编程的关键技术概念无论是产品还是测试也必须了解 LLM、MCP、Agent 等概念需要团队对一些知识都过关确保整个团队交流协作不存在知识障碍。这些概念的知识笔者就不赘述了。主流大语言模型用于编程的评分作为架构师需要清晰了解不同模型的特长和优缺点在编程领域哪个模型最优秀最适合用于编程。笔者发现几个网站很不错有各类模型的介绍和评分地址Best LLMs for Coding | LLM Leaderboardshttps://llm-stats.com/https://www.aibase.com/zh主流企业使用 AI 辅助编程提升的效率。要是领导觉得你一个月写的代码不如 AI 一天写的那就尴尬了。作为技术人员必须合理评估使用 AI 编程后整个团队到底提升了多少效率编码速度提高了多少。比如根据这篇研究报告完成任务的编码速度大概提升了21%报告地址 https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/而根据豆包联网搜索总结的内容来看提升的开发速度并没有那么夸张。总而言之打造 AI 辅助编程团队要求团队人员对 AI 有足够的认识了解基础知识并且争取在 AI 编程上的认知一致否则可能会闹出各种笑话被人引为笑谈。知识和认知都很重要否则团队分分钟散架。项目模板为什么要使用开发框架这个事情不用多说C# 开发应该知道 ABP 框架Go 开发应该知道 gin、beego使用框架后大大简化了开发负担。在使用开发框架的情况下其实团队还需要定制项目模板以便适配公司技术栈以及约束公司内的一些技术要求例如审计属性、微服务通讯方式和鉴权等好的项目模板可以统一开发模式和习惯。笔者在写个人开源项目过程中结合 DDD 、清洁架构、CQRS 的一些概念辅以 AI 编程形成了个人开发习惯所以为了写这篇文章整理了一个模板项目https://github.com/whuanle/aispec如果以我的开发习惯来定我会使用模块化 CQRS每个业务领域遵循三层模块化架构无论开发还是做单元测试都比较简单。src/{domain}/ ├── MoAI.{Domain}.Shared/ # 共享层 - DTO、Command、Query 定义 ├── MoAI.{Domain}.Core/ # 核心层 - Handler 实现、业务逻辑 └── MoAI.{Domain}.Api/ # API 层 - Controller/Endpoint 暴露依赖关系Api → Core → Shared具体参考代码编写约束参考https://github.com/whuanle/aispec/blob/master/.kiro/steering/cqrs-conventions.md具体设计思路和各类细节就不讲解本节其实目的是说无论你使用何种开发框架是否使用 DDD还是传统三层结构团队应该要有一个统一的项目模板以及开发习惯约束AI 会参考项目已有代码和约束文件编写符合要求的代码避免代码天马行空。关于模板项目就不展开说了读者可以在这里找到这个本身用于实战演示的模板项目https://github.com/whuanle/aispec准备定制团队规则与项目索引在使用 AI 编程时会有一些常见问题1开发跟 AI 容易陷入盲目对话AI 始终没有给出想要的代码导致代码可用率和确定性低下。2开发难以清晰准确向 AI IDE表达目标方案和代码3前置需要大量精力对项目的 Rules、Docs 进行编写和积累4啥都让 AI 写但是 AI 写出来的方案总是不满意解决这些问题本身不难但是要落到团队协作中作为架构师就要思考更多了需要保证代码质量和开发效率避免反复处理这些问题。什么是 Steering这里的 steering 其实是 Kiro 里面的概念目的是让 AI 编程过程中始终遵循团队已建立的 patterns、libraries、standards。https://kiro.dev/docs/steering/也就是说基于团队的项目模板我们要指定一些跟业务无关的技术约束例如审计属性怎么定这个开发框架/项目模板怎么使用不同功能的代码文件怎么命名等都可以写到 Kiro steering 里面。AI 在写代码时会一直围绕这些 steering 去写如果写出的代码不符合 steering 要求则 AI 会逐步修正代码。那么团队要落地代码规范是不是变简单了前面提到的 AI 编程的问题和核心诉求是不是可以解决了是的所以要重视项目模板和 steering在团队开发实现需求之前就应该定制团队乃至公司研发部门的 steering。常见 Steering 文件策略后面会提到 Kiro 默认会有的 steering 规则模板但是从团队的角度考虑可能还需要这些 steering API 标准(api-standards.md) - 定义 REST 约定、错误响应格式、认证流程和版本策略。包括端点命名模式、HTTP 状态码使用和请求/响应示例。测试方法(testing-standards.md) - 建立单元测试模式、集成测试策略、模拟方法和覆盖率期望。记录首选测试库、断言样式和测试文件组织。代码风格(code-conventions.md) - 指定命名模式、文件组织、导入排序和架构决策。包括首选代码结构、组件模式和要避免的反模式示例。安全指南(security-policies.md) - 记录认证要求、数据验证规则、输入清理标准和漏洞预防措施。包括特定于您应用程序的安全编码实践。部署流程(deployment-workflow.md) - 概述构建程序、环境配置、部署步骤和回滚策略。包括 CI/CD 管道详细信息和环境特定要求。当然这些 steering 不需要都首选可以先做一个项目模板然后让 Kiro 阅读代码并生成即可。不同公司团队可能有不同要求只要看着写就行可以在摸索的过程中逐渐积累团队经验逐渐完善 steering。核心执行AI 驱动的协作流程设计团队协作 AI 编程把要做的功能丢在对话框让 AI 写代码就行No大错特错让我们回到 Kiro 的介绍Agentic AI development from prototype to production翻译过来是从原型到产品的 Agentic AI 开发。注意要玩 AI 编程我们是要做从原型到产品整个周期的东西而不单单是用 AI 写完代码早点下班。所以要考虑团队的角色有哪些大家应该怎么参与协作更重要的是怎么设计新的团队研发流程。不同公司的团队组成不一样所以笔者按照常规团队产品、UI设计师、前后端开发、测试组成来讲解后面的内容。感谢这位作者的文章给了我很多想法https://aicodingtools.blog/zh/kiro/kiro-spec-guide使用 AI 编程后团队中各个角色要负责的内容会发生变化要求工作输出的内容能够被 AI 识别并引用并且在团队内流通。如果产品输出的需求文档AI 都不会分析总结你给开发看逻辑狗屁不通AI 怎么写代码产品的需求文档可以经过开发整理后作为让 AI 编写代码的提示词和需求约束大大减轻开发的负担。开发和测试将会大大依赖需求文档或其它形式的文档因为需求文档会作为开发、测试和验收依据在 AI 编程阶段就要让 AI 知道写代码还要考虑怎么测试和验收不能等让 AI 写完代码再叫 AI 写单元测试、检查验收能不能过。另外前期准备阶段也依赖架构师或 leader 的架构设计和功能实现设计而不是说 ”实现一个短链接服务将长链接缩短为短链接“技术负责人需要思考和设计使用何种算法缩短地址、还原地址怎么存储到数据库高并发环境下怎么提高并发量和减少对数据库的压力。所以要思考使用 AI 编程落地后团队需要哪些角色每个角色要负责哪些内容整个研发流程应该分哪些阶段每个公司情况都是不一样的所以针对这些问题笔者没有什么说法和观点不过后面实战部分会提到 Kiro Specs 是怎么划分研发流程阶段。笔者设想未来围绕 AI 辅助编程开发团队的角色和参与内容可能发生重大改变。一是团队开发流程发生改变不再像以往从产品原型设计、需求会、开发、提测的模式而是围绕 AI 编程更加靠敏捷开发模式接近。二是团队角色负责的内容发生改变更多围绕产生的资料能够被 AI 吸收知识可以沉淀减少信息流通的难度以及降低产品、设计师、开发、测试之间的知识和职责边界。三是可能会出现以 AI 编程为中心的产品研发一体化平台无论是产品、设计师、开发、测试都可以围绕这个平台进行符合自己角色的参与例如产品编写需求文档和验收文档时可以借助 AI 平台检测需求是否合理、调整设计、细化需求转化为开发人员便于阅读的文档。产品、设计师通过需求文档借助 AI 平台快速实现产品原型设计。开发人员则可以将需求导入 AI创建开发任务逐步与 AI 协作编写代码还可以借助 AI 快速生成单元测试、集成测试等最后根据验收文档验证检测最终输出。而关于团队的研发流程则会在 工作流程 一节详细讲解。总结作为文章的第二部分主要是思考怎么建设使用 AI 辅助编程的团队以及进行团队协作。第三部分将会讲解实战从原型到产品的整个环节每个步骤应该做什么。实战作为文章的第三部分内容将会以短链接服务为案例去讲解如何落地实战团队协作和 AI 编程去设计一个以 AI 辅助开发为核心的项目研发流程。思考整体架构AI 时代还需要我去设计项目是的开发人员要自行对技术方案进行调研、上手尝试然后让 AI 根据你的方案和设计做出来不要都让 AI 帮你做解决方案。只需要一个 ideaAI 就可以写代码可是 AI 写出来的东西可能跟专业人员需要的东西相去甚远并且还有大量细节满足不了需求开发人员可能会陷入跟 AI 的对骂中不断调整提示词不断等待 AI 生成最终生成了 90% 的内容剩下的 10%开发人员只能对着键盘一点点敲完。虽然是 AI 编程但是编程的重点是人的想法和需求而不是 AI 的天马行空虽然 AI 实现的项目可能有很多很好的创意和想法质量可能很好但是对于专业领域和公司业务项目来说需求的中心是公司对应的业务而不是一个 idea。而且 AI 有上下文限制有幻觉等你只需要一个简单的一个登录功能可能 AI 把单点登录、OAuth2 等一堆东西给你加上去了目标偏移。所以即使在 AI 时代我们也要构思项目设计和功能实现的算法和逻辑让 AI 在这个边界内实现代码和测试。当然我们可以利用 AI 去帮助我们验证想法和构思设计然后将这些内容生成为架构设计和技术方案。短链接服务的架构由于本文的重点不是怎么实现一个短链接服务所以笔者这里只简单讲解这个服务的一些算法和实现思路以便后续使用 AI 写出符合需求的代码。核心问题1短链接生成和还原核心问题2短链接存储和查找笔者的设计是短链接跟长链接无直接映射关系也就是不能通过算法转换直接将长链接生成短链接。对于每个长链接创建记录存到数据库时会使用 int64 雪花做主键存到数据库。例如新增一个长链接https://whuanle.cn当前雪花id 是 2009194627277520896经过检查数据库没有重复数据后存储到数据库。接着将雪花 id 使用 base62 生成短链接编码。之所以使用 base62 做缩短编码是因为[0-9]、[a-z]、[A-Z]刚刚好是 62 个字符能够在不使用特殊符号的情况下使用数字和大小写字母表达值也就是相当于 62 进制。将 2009194627277520896 使用 base62 编码是得出字符串是00E3uWKkzx而存数据只需要一个 int64 就行。满足能够将长链接生成短链接存储空间小不容易被人碰撞规则的需求。有了短链接生成和还原算法后我们继续聊一下数据查找。用户访问/00E3uWKkzx时还原得到 2009194627277520896然后通过这个 id 从数据库查找数据得到https://whuanle.cn然后让用户跳转到这个地址即可。每次都要查数据库数据库压力大而且万一被人攻击机器人随机拼接的字符串也要到数据库检查数据在不在数据库迟早被打崩。所以第一层是使用 redis 的布隆过滤器先判断数据是否存在。第二层数据分片将数据存储到 redis避免频繁从数据库查找。还可以做本地离线缓存避免高频度从 redis 查找数据。也就是最终是三层缓存。其它就不多说了前面提到的算法处理逻辑将会作为后续 AI 编写功能的依据。模板项目首选是安装笔者提供的项目模板。dotnet new install Maomi.AiSpec.Templates执行命令从模板创建新的项目将MyShortUri替换为你需要的项目名称即可。dotnet new aispec -n MyShortUri后端开发原则和规范使用 Kiro 打开MyShortUri项目 在 AGENT STEERING 菜单可以看到已经模板自带四个 steering 文件。Kiro 通过.kiro/steering/目录中的 markdown 文件设置项目约束规定Kiro 只规定了 product.md、tech.md、structure.md 三个文件这些基础文件默认包含在每次交互中形成 Kiro 项目理解的基线。cqrs-conventions.md 则是笔者的模板项目的开发规则约定 AI 生成的代码文件如何存放以及代码格式约束AI 会生成符合项目要求的代码。读者也可以创建一些其它文件例如rest-api.md要求生成的 api 接口需要符合 restapi 格式将公司研发规范等写入到.kiro/steering/目录。后端代码规范约束cqrs-conventions.md是笔者自定义的 steering 文件用来约束 AI 生成的代码必须分为Command/Query、Api、Handler三层的 CQRS 结构。定义了很多约束规范这里就不讲解了自己研究一下。我要做什么样的产品拉取项目模板后第一步是修改product.md告诉 AI 这是一个短链接项目。产品概述(product.md) - 定义产品的目的、目标用户、关键功能和业务目标。一般来说产品概述(product.md) 是产品经理的工作任务开发只需要将产品经理写的文档拷贝到代码项目即可不过既然现在没有产品经理我们可以一句话描述核心需求让 Kiro 帮助我们生成具体的产品说明等 AI 生成后根据实际情况调整好product.md文件。生成效果项目结构项目结构(structure.md) - 概述文件组织、命名约定、导入模式和架构决策这确保生成的代码无缝融入现有的代码结构里面这样 AI 不会乱创建文件以及随便找个地方塞代码。structure.md要常常随着项目的进展而更新不要一直不变每次新增模块后都要重新生成structure.md。现在我们点击 Kiro 的Refine重新生成structure.md。技术约定技术栈(tech.md) - 记录这个项目选择的框架、库、开发工具和技术约束当 Kiro 建议实现方案时它会优先选择已建立的技术栈而非替代方案。突然想起来一个事情某同事写 Go 语言程序需要解决一个打印功能结果用 AI 写的代码引入了 python后面被我发现了我要求用 Go 重写然后某同事又用 AI 劈里啪啦写了一天总算用 Go 写出来了。所以tech.md可以避免这种情况不然 AI 为了实现一个功能到处查资料然后引入一堆依赖用一种意想不到的方式去实现功能。现在我们点击 Kiro 的Refine重新生成tech.md例如这个项目使用的技术栈如下| Category | Technology | |----------|------------| | Framework | ASP.NET Core 9 | | Language | C# 12 (nullable reference types enabled) | | ORM | Entity Framework Core 9 (MySQL) | | CQRS | MediatR | | Validation | FluentValidation | | Authentication | JWT Bearer tokens | | Logging | Serilog | | API Docs | OpenAPI/Swagger with Scalar UI | | Caching | Redis (StackExchange.Redis) | | Module System | Maomi.Core | | Code Analysis | StyleCop.Analyzers |作者还可以加上接口设计约定等文件这里不再赘述。数据库设计现在出现了一个使用 AI 做数据库设计方案的方向Text2SQL。Text2SQL 指将自然语言转换为 SQL 的技术当一个项目从零开始时我们可以借助 AI 构思、设计项目架构最后总结输出 SQL这一步其实比较简单。但是后续项目迭代后需要 AI 去了解整个数据库表结构需要 AI 根据业务情况设计新的索引、字段约束等这就要求 AI 需要挖掘数据价值应对复杂的分析任务才能给出合理的数据库变更建议。可以借助专业的 AI DB 客户端去做例如 Chat2DB、也可以在 Kiro 装上 MCP 工具读取数据库由于不是本文重点这里只讲解思路就不再详细讲述。数据库创建表以便后续实战让 AI 写代码。CREATE TABLE short_url ( id bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 唯一ID对应短链接编码, long_url varchar(2048) NOT NULL COMMENT 原始长链接, hash varbinary(32) NOT NULL COMMENT 网址哈希值方便对比, create_user_id int(11) NOT NULL DEFAULT 0 COMMENT 创建人, create_time datetime NOT NULL DEFAULT current_timestamp() COMMENT 创建时间, update_user_id int(11) NOT NULL DEFAULT 0 COMMENT 更新人, update_time datetime NOT NULL DEFAULT current_timestamp() ON UPDATE current_timestamp() COMMENT 更新时间, is_deleted bigint(20) NOT NULL DEFAULT 0 COMMENT 软删除, PRIMARY KEY (id), KEY short_url_hash_index (hash) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT短链接 CREATE TABLE user ( id int(11) NOT NULL AUTO_INCREMENT COMMENT 用户ID, user_name varchar(50) NOT NULL COMMENT 用户名, email longtext NOT NULL COMMENT 邮箱, password varchar(255) NOT NULL COMMENT 密码, nick_name varchar(50) NOT NULL COMMENT 昵称, password_salt varchar(255) NOT NULL COMMENT 计算密码值的salt, is_deleted bigint(20) NOT NULL COMMENT 软删除, create_user_id int(11) NOT NULL COMMENT 创建人, create_time datetime NOT NULL DEFAULT utc_timestamp() COMMENT 创建时间, update_user_id int(11) NOT NULL COMMENT 最后修改人, update_time datetime NOT NULL DEFAULT utc_timestamp() COMMENT 最后更新时间, PRIMARY KEY (id), UNIQUE KEY users_user_name_is_deleted_uindex (user_name,is_deleted) ) ENGINEInnoDB AUTO_INCREMENT2 DEFAULT CHARSETutf8mb4 COMMENT用户修改数据库链接启动 MysqlScaffold 还原数据库生成代码将Database目录的文件放到对应位置接口。您看有个项目模板多重要很多时候省下大量的时间例如笔者这个模板先设计数据库然后定制数据库生成代码的步骤使得生成的实体结构和 数据库上下文类能够符合业务需求大大提高开发效率。UI 原型设计UI 原型设计就是 UI 设计师根据产品原型设计页面的过程随着专业的原型设计工具支持 AI 后产品经理跟 UI 设计师更好地协作有时候一句话就可以生成一个不错的界面。产品经理可以借助这些 AI 工具快速实现原型页面。由于墨刀的 AI 需要付费使用太贵了本来想演示 AI 根据设计稿生成页面代码的最后放弃了用这钱买了几盒凤爪。本节意思读者理解就行就是说目前市面上有很多 AI 生成设计稿的产品产品可以不用化那么多时间画原型了可以专心思考产品设计和流程逻辑最大程度输出文档把画原型这些事情留给 AI然后还可以进一步转换为 UI设计师也可以借助 AI 快速实现初版界面。后端开发实战基于项目模板和 steering其实一句话需求就可以让 Kiro 给我们编写一个模块的后端代码。但是 Kiro 提出了 Specs让团队协作和开发人员早点下班的神器。Specs 弥合了概念产品需求和技术实施细节之间的差距确保了一致性并减少了开发迭代。Specs 提供了一种系统化的方法将需求和想法转化为详细的实施计划生成验收标准、技术实现和代码生成及测试验收计划。接下来我们将会使用 Kiro Specs 生成某个功能的工作流程最后根据方案生成代码并通过测试验收代码。实现创建短链接的接口要做短链接服务第一步是实现一个长链接转短链接的功能Kiro Specs 要求编码之前需要按照三阶段工作流程进行需求 → 设计 → 实施。在 Kiro 面板中点击Specs下的按钮或者从聊天面板中选择Spec在对话框内输入要做的功能。Create Spec: 实现创建短链接的接口创建的数据存储到 ShortUrlEntity使用雪花id赋值id将长地址使用 SHA-256 生成 32 字节存储到 hash 字段。插入数据时要判断数据库是否存在对应的数据。按照引导操作后最后一步会显示 “保留可选任务更快完成 MVP”、“全部设为必需完整测试覆盖”。如果选择了 “全部设为必需完整测试覆盖”AI 在任务列表加上基于属性的测试要求和执行步骤Kiro 从提出的需求中提取属性并生成测试用例以便确保 AI 生成的代码符合开发者的意图。Kiro 文档里面解释属性对于任何一组具有特定前提条件的输入某些预期行为是成立的。Kiro 从格式化的需求中提取属性 (例如“THE System SHALL 允许经过认证的用户查看活动车辆列表”)确定哪些属性可以进行逻辑测试然后在你选择运行它们时生成数百或数千个随机测试用例。结果一顿操作后需求已经下发到.kiro/specs/create-short-urlKiro 会生成三个关键文件这三个文件构成一个 spec。requirements.md使用结构化的 EARS 记号法捕获用户故事和验收标准design.md记录技术架构、序列图和实施考虑因素tasks.md提供详细的实施计划包含离散的、可跟踪的任务
