最近也是经常关于目前市面上出现的ai新工具，包括腾讯的codebuddy和亚马逊的Kiro包括字节最新的Trea 2.0版本，本人只试用了Kiro腾讯的那个ai工具实在太丫的贵了，价格贴下面：
有大佬有钱的话可以测试一下

其实Kiro的基础模型使用的还是claude sonnet 4 但是跟其他的AI编程工具比起来，我觉得具备以下的这些特点，其实用我的话来总结就是项目的规划非常有条理，之前我们自己开发项目的时候都是想到哪里写到哪里，项目需求分析，项目架构设计，项目实施步骤包括实际的开发这些都是混乱的，我之前用claude code进行过很多次从零开发的项目，我自己的感觉是虽然你是可以让它给你生成需求文档，开发文档，技术文档，实施步骤方案之类的，但是说实话我们自己表达的语言还是没有Kiro的工作流那么专业和完整，还有就是不可能每个人在开发一个新的项目的时候都能够记住一定要生成这些文档(很多都是已经开发到中间了，突然想起来，MD好像需求文档都没有编写，上一步我想要实现什么操作来着？它怎么不按照我的实施方案来编写？)就会出现很多问题，所以现在我推荐的Kiro Spec工作流可以解决这个问题。

首先我们来分析一下什么叫做Kiro Spec工作流？ 用人话就是我们自己在claude code中去设计一个命令如图所示：

设计的这个自定义的命令/spec 就是我们用专门的Kiro Spec工作流的已经提前编写好的提示词，然后当我们需要从零开始开发的时候，可以使用/spec然后接上自己的自定义的命令，就可以帮我们把这条命令按照这个工作流的方式进行规范化。

这套提示词的底层逻辑其实就是有如下的三大特点：
1，消除表达的歧义，什么这个不是你想要的效果？怎么说AI都不懂你？不知道怎么样把流程说清楚？ 使用这个Kiro Spec工作流它里面已经内置好了很多专业的提示词，我们直接在这个命令的后面添加上我们自己想要实现的功能例如：/spec [帮我开发待办事项的需求文档 使用中文] 然后别看你输入的需求内容很少但是其实内置的命令里面包含的提示词会帮我们自己丰富的

2，系统架构层面的规划，总结就是我们自己开发的需求文档，技术文档，实施方案这些都是站在现在此时此刻的脑子里面的想法来制定的，今天开心就多写一点，明天不开心就少些一点，今天这个功能要，明天那个功能不要，很多时候我们发现等到了中后期之后很多底层的架构会出现问题，推倒重来太浪费时间，不推倒的话后面开发非常麻烦，所以使用Kiro Spec工作流的话就可以直接从一开始就帮你设计出权威的，各个模块之间互相协调的方案

3，任务的细分化，使用这个工作流可以将很复杂的任务，高难度的任务，给你分解成细小的，可控的，类似于操作清单一样的，可以方便审核和记录的任务，用人话就是你看不懂的开发的操作给你分成更小的你知道怎么去校验是不是操作成功的小任务。

用一张图来对比：

说完了它的优势之后，如何配置呢？下面是详细的操作步骤

首先不管你是Mac电脑还是windows电脑，找到本机的.claude的目录，然后一般Mac电脑就在根目录下面，windows电脑默认的安装路径如下：C:\Users\xxxxx\.claude 然后在这个文件夹下面创建一个commands这个文件夹(如果有的话就不用创建了) 这个文件夹就是用来保存自定义的claude code命令的，然后将这个文件放进去就可以了：

好像上传不了文件，那就先在这个文件夹下面创建一个文件名为：spec.md的文件，然后将下面的专业提示词粘贴上去即可，提示词如下：

Specs系统提示词：

# Requirements Gathering GenerationWorkflow Stage: Requirements GatheringFirst, generate an initialsetof requirements in EARS format based on the feature idea, then iterate with the userto refine them until they are complete and accurate.Don’t focus on code exploration in this phase. Instead, just focus on writing requirements which will later be turned intoa design.

**Constraints:**

– The model MUST create a ‘.claude/specs/{feature_name}/requirements.md’ file if it doesn’t already exist- The model MUST generate an initial version of the requirements document based on the user’s rough idea WITHOUT asking sequential questions first

– The model MUST format the initial requirements.md document with:

– A clear introduction section that summarizes the feature

– A hierarchical numbered list of requirements where each contains:

– A user story in the format “As a [role], I want [feature], so that [benefit]”

– A numbered list of acceptance criteria in EARS format (Easy Approach to Requirements Syntax)

– Example format:[includes example format here]

– The model SHOULD consider edge cases, user experience, technical constraints, and success criteria in the initial requirements

– After updating the requirement document, the model MUST ask the user “Do the requirements look good? If so, we can move on to the design.” using the ‘userInput’ tool.

– The ‘userInput’ tool MUST be used with the exact string ‘spec-requirements-review’ as the reason

– The model MUST make modifications to the requirements document if the user requests changes or does not explicitly approve

– The model MUST ask for explicit approval after every iteration of edits to the requirements document

– The model MUST NOT proceed to the design document until receiving clear approval (such as “yes”, “approved”, “looks good”, etc.)

– The model MUST continue the feedback-revision cycle until explicit approval is received

– The model SHOULD suggest specific areas where the requirements might need clarification or expansion

– The model MAY ask targeted questions about specific aspects of the requirements that need clarification

– The model MAY suggest options when the user is unsure about a particular aspect

– The model MUST proceed to the design phase after the user accepts the requirements# Design Document Creation GenerationWorkflow Stage: Design Document CreationAfter the user approves the Requirements, you should develop a comprehensive design document based on the feature requirements, conducting necessary research during the design process.The design document should be based on the requirements document, so ensure it exists first.

**Constraints:**

– The model MUST create a ‘.claude/specs/{feature_name}/design.md’ file if it doesn’t already exist- The model MUST identify areas where research is needed based on the feature requirements

– The model MUST conduct research and build up context in the conversation thread

– The model SHOULD NOTcreate separate research files, but instead use the research as context for the design and implementation plan

– The model MUST summarize key findings that will inform the feature design

– The model SHOULD cite sources and include relevant links in the conversation- The model MUST create a detailed design document at’.claude/specs/{feature_name}/design.md’

– The model MUST incorporate research findings directly into the design process

– The model MUST include the following sections in the design document:

– Overview- Architecture- Components and Interfaces- Data Models- Error Handling

– Testing Strategy- The model SHOULD include diagrams or visual representations when appropriate (use Mermaid for diagrams if applicable)- The model MUST ensure the design addresses all feature requirements identified during the clarification process

– The model SHOULD highlight design decisions and their rationales- The model MAY ask the userfor input onspecific technical decisions during the design process

– After updating the design document, the model MUST ask the user “Does the design look good? If so, we can move on to the implementation plan.” using the ‘userInput’ tool.

– The ‘userInput’ tool MUST be used with the exact string ‘spec-design-review’as the reason

– The model MUST make modifications to the design document if the user requests changes or does not explicitly approve

– The model MUST ask for explicit approval after every iteration of edits to the design document

– The model MUST NOT proceed to the implementation plan until receiving clear approval (such as “yes”, “approved”, “looks good”, etc.)

– The model MUST continue the feedback-revision cycle until explicit approval is received

– The model MUST incorporate alluser feedback into the design document before proceeding

– The model MUST offer toreturnto feature requirements clarification if gaps are identified during design# Implementation Planning GenerationWorkflow Stage: Implementation PlanningAfter the user approves the Design, create an actionable implementation plan with a checklist of coding tasks based on the requirements and design.The tasks document should be based on the design document, so ensure it exists first.

**Constraints:**

– The model MUST create a ‘.claude/specs/{feature_name}/tasks.md’ file if it doesn’t already exist

– The model MUST return to the design step if the user indicates any changes are needed to the design

– The model MUST return to the requirement step if the user indicates that we need additional requirements

– The model MUST create an implementation plan at ‘.claude/specs/{feature_name}/tasks.md’

– The model MUST use the following specific instructions when creating the implementation plan: Convert the feature design into a series of prompts for a code-generation LLM that will implement each step in a test-driven manner. Prioritize best practices, incremental progress, and early testing, ensuring no big jumps in complexity at any stage. Make sure that each prompt builds on the previous prompts, and ends with wiring things together. There should be no hanging or orphaned code that isn’t integrated into a previous step. Focus ONLYon tasks that involve writing, modifying, or testing code.

– The model MUST format the implementation plan as a numbered checkbox list with a maximum of two levels of hierarchy:

– Top-level items (like epics) should be used onlywhen needed

– Sub-tasks should be numbered withdecimal notation (e.g., 1.1, 1.2, 2.1)

-Each item must be a checkbox

– Simple structure is preferred

– The model MUST ensure each task item includes:

– A clear objective as the task description that involves writing, modifying, or testing code

– Additional information as sub-bullets under the task-Specificreferencesto requirements from the requirements document (referencing granular sub-requirements, not just user stories)

– The model MUST ensure that the implementation plan is a series of discrete, manageable coding steps

– The model MUST ensure each task referencesspecific requirements from the requirement document

– The model MUST NOT include excessive implementation details that are already covered in the design document

– The model MUST assume that all context documents (feature requirements, design) will be available during implementation

– The model MUST ensure each step builds incrementally on previous steps

– The model SHOULD prioritize test-driven development where appropriate

– The model MUST ensure the plan covers all aspects of the design that can be implemented through code

– The model SHOULD sequence steps to validate core functionality early through code

– The model MUST ensure that all requirements are covered by the implementation tasks

– The model MUST offer toreturnto previous steps (requirements or design) if gaps are identified during implementation planning

– The model MUST ONLY include tasks that can be performed by a coding agent (writing code, creating tests, etc.)

– The model MUST NOT include tasks related touser testing, deployment, performance metrics gathering, or other non-coding activities

– The model MUST focus on code implementation tasks that can be executed within the development environment

– The model MUST ensure each task is actionable by a coding agent by following these guidelines:

– Tasks should involve writing, modifying, or testing specific code components

– Tasks should specify what files or components need to be created or modified

– Tasks should be concrete enough that a coding agent can execute them without additional clarification

– Tasks should focus on implementation details rather than high-level concepts

– Tasks should be scoped tospecific coding activities (e.g., “Implement X function” rather than “Support X feature”)

– The model MUST explicitly avoid including the following types of non-coding tasks in the implementation plan:-User acceptance testing oruser feedback gathering

– Deployment to production or staging environments- Performance metrics gathering or analysis

-Running the application to test endtoend flows. We can however write automated tests to test the endtoendfrom a user perspective.

-User training or documentation creation

– Business process changes or organizational changes

– Marketing or communication activities-Any task that cannot be completed through writing, modifying, or testing code

– After updating the tasks document, the model MUST ask the user “Do the tasks look good?” using the ‘userInput’ tool.

– The ‘userInput’ tool MUST be used with the exact string ‘spec-tasks-review’as the reason

– The model MUST make modifications to the tasks document if the user requests changes or does not explicitly approve.

– The model MUST ask for explicit approval after every iteration of edits to the tasks document.

– The model MUST NOT consider the workflow complete until receiving clear approval (such as “yes”, “approved”, “looks good”, etc.).

– The model MUST continue the feedback-revision cycle until explicit approval is received.

– The model MUST stop once the task document has been approved.

**This workflow isONLYfor creating design and planning artifacts. The actual implementation of the feature should be done through a separate workflow.**

– The model MUST NOT attempt to implement the feature as part of this workflow

– The model MUST clearly communicate to the user that this workflow is complete once the design and planning artifacts are created

– The model MUST inform the user that they can begin executing tasks by opening the tasks.md file, and clicking “Start task” next to task items.

粘贴完成之后保存，然后重启claude code就可以使用这个命令了，后面这个命令可以自己搭配自定义的指令，有了这个这个指令之后，只需要正常的按照

需求设计 -> 技术栈设计 ->实施计划清单 ->开始实施

按照上面的要求进行开发就可以达到非常不错的效果