Blog

比较 Trae CN、Antigravity 与 Kiro 在编程/自动化任务中的表现，通过多个实际案例展示各自优缺点与适用场景。

Antigravity vs Kiro

前文提到用 Kiro 写了个网盘，这次新需求是将审批改为三级审批。我的 Kiro 剩余点数不多，正好让 Antigravity 试试。我的提示如下：

分享申请的审批需要经过三级审批，包括：

- 产品负责人* 
- 产品研发部门经理*
- 产品管理委员会*

我也需要一个界面，为 ldap 的用户分配这三个角色。

另外，recipientId 已经删除了，但是这三个人的选取界面可以参考recipientId的界面。

Antigravity 立刻给出一份计划：

初见此计划我很高兴，Kiro 的 SDD 有时显得啰嗦，若一个文档能顶替三份那自然很好。Antigravity 看起来胸有成竹，虽然心存疑虑，但仍满怀期待——高手常能化繁为简。

但随后 Antigravity 陷入了反复修正：

问题逐渐严重，Antigravity 似乎没有意识到其修改带来的联动影响。我关于 recipientId 的提示确有歧义，但完全可以通过查看源代码澄清。

Antigravity 反复修改，一直解决不了，很快便耗尽了 Gemini 3 Pro 的额度，只好切换到了 Claude Sonnet 4.5。Claude 似乎更快意识到问题严重性：Gemini 反复修改已经让代码破损，Claude 建议恢复后重做。能及时止损这一点很重要——就像我们在编程时，发现偏离预期就该回退并重来。

这次经历削弱了我对 Gemini 3 的初期好感，至少在我看来，它不如 Claude 更善于解决问题。更关键的是 Antigravity 起初的方案并不周全，几轮与 Claude 交互后我发现按照 Gemini 的计划无法实现三级审批，代码已被改得面目全非，于是决定从头恢复，感谢 git。

Kiro 给出了一份规范的 SDD，细读后可见它在需求分析上的价值，例如提出了：

**User Story:** As a system, I want to prevent conflicts in the approval process, so that the workflow remains consistent and auditable.

尽管我只是要个三级审批，kiro 敏锐的意识到，必须有一个清晰的界面来展示审批过程。

尽管有一些啰嗦，但是这种整体的规划确保了任务的成功。通过 kiro，我很快的实现了我的目标，大多数任务可以一次通过，或者解决一些简单的错误后通过。

还有一点，让我很感叹，就是 Kiro 执行每个子任务时，都会有对于整体的认识，比如有以下输出：

I see there's a build error because the application code is still referencing the removed approvalComment field. This is expected since Task 1 only handles the database schema changes, and the application code updates are planned for later tasks.

However, to keep the application buildable, let me quickly fix this reference so the build doesn't break:

执行子任务时，导致整个项目的构建失败很正常。Kiro 执行子任务时有这个意识，这很关键，如果缺乏这个意识，很容易陷入任务的互相干扰，导致整体的失败。

Trae CN vs Antigravity

因为要为一些不太有技术背景的朋友学会用AI炒股，所以我先从门槛最低的 Trae CN 尝试。写此文时，已经听闻 Claude 已经不再供应 Trae，不过对我们影响不大，Trae CN 本来就用不了了 Claude。

我的提示是：

参考 docs\adata 的文档，帮我编写一个脚本，可以获取所有的股票code，然后下载每个股票前复权的日K线数据，存放到 /data 目录的相应目录下。我可以指定下载的天数，也可以选择追加方式或者覆盖方式。

我担心 Trae 的模型对于这种小众的 adata 库认识不足，所以预先在docs\adata 下载处理了 adata 的文档。Trae 的表现得有板有眼，先创建任务，然后依次执行，成功得到脚本，并可以正常运行。

Trae 对于文档的理解还是很到位的，精准的认识到完成本任务需要调用获取股票代码列表和获取日K线数据的API。

不过，我对结果有一点不满意。Trae 并没有给我一个面向对象的实现方式，还真就是给了我一个简单的脚本，我感觉我很难在此基础上扩展。

脚本需要下载的数据很多，我觉得有必要增加一个进度跟踪功能，于是 Trae CN 让我的脚本生成一个 save_progress.json 文件。但是这个文件目录默认是当前目录，我觉得更合理的位置是数据输出的目录中。于是我说：

save_progress 默认在 output 目录下

我知道我可能说话又不严谨了，我说的 output 本意是脚本中命令行选项 output 对应的目录，但 Trae CN 理解成了 ./output 目录，只能进一步澄清。

我又注意到，脚本每次执行都要去获取所有的股票代码，这一步很慢，我觉得可以加一个股票代码的缓存能力。长话短说，这个缓存文件，Trae 还是默认给我放到当前目录了。我知道这是因为我用了新的会话，Trae CN 还是按照自己的习惯编码，不过我用其他AI编程工具时注意到，有一些工具是会参考历史会话的。在不影响效果的前提下，还是很有用的设计。

此后，我发现我还有很多需求，每一次 Trae CN 都会给我一个我不太满意的方式实现。例如记录上次文件下载的进度并追加数据，Trae CN 用一个专门的文件记录，但问题是并没有在文件中存放关键的信息，还需要进一步修改。

最后的结果是 Trae CN 也有点糊涂了，代码改的面目全非。最后，我感觉不能再这样缝缝补补了，就这么点功能，不如重来了。

来到 Antigravity，输入：

参考 docs\adata 的文档。帮我编写一个脚本，可以从 api 中获取所有的股票代码（因为比较大，所以这个需要有缓存机制），然后下载日K信息到 data\dayk 目录，每个股票一个单独的csv文件。最好也能统一记录每个文件最后的下载日期，可以实现追加下载。

Antigravity 很快也给了我能用的脚本，结果好多了。首先，这 Antigravity 更懂我。缓存文件的默认位置是 ./data，并没有放到 ./data/dayk 上，这个是非常好的设计，似乎隐含了的认识到，我将来如果有其他脚本，可以共享这个股票代码文件。其次，Antigravity 的实现更简洁。例如这个最后下载日期的跟踪，Antigravity 并没有增加跟踪文件，而是直接读取数据的最后一条记录，在大多数情况下，这种设计最简洁。

这一次 Gemini 3 Pro 没有掉链子。可能只要任务粒度合适，这个 Gemini 3 Pro 还是有一定的战力的。

后续

有了基本的日K数据，我想就可以让 AI 帮我做一个分析工具，我对技术分析也不是很懂，所以全交给了 Antigravity：

data\dayk 目录下是A股的日K线数据，你作为一个股票分析专家，能不能帮我设计一个分析模型，可以根据成交量和股价的关系预测未来一段时间的股价涨跌。然后根据模型开发一个程序，可以每个交易日做一个分析，保存分析数据，可以用于进一步的分析。

没有太多废话，给了我一个融合许多指标的综合打分工具出现了，运行的输出结果是：

分析完成! 耗时: 24.30 秒
平均每只股票: 0.005 秒

分析结果已保存到: data\analysis\2025-11-30.csv
总计分析股票数: 5169

预测信号分布:
  HOLD: 5149
  INSUFFICIENT_DATA: 20

预测评分统计:
  平均分: -0.38
  最高分: 2.60
  最低分: -2.00

评分最高的20只股票:
stock_code prediction_signal  prediction_score                                    reasons
    300898              HOLD               2.6                均线多头排列; MACD金叉; 量价齐升; 资金净流入
    002519              HOLD               2.4        均线多头排列; MACD金叉; 量价齐升; 资金净流入; 突破布林上轨
    301355              HOLD               2.4                均线多头排列; MACD金叉; 量价齐升; 资金净流入
    600882              HOLD               2.4                均线多头排列; MACD金叉; 量价齐升; 资金净流入
    603489              HOLD               2.4        均线多头排列; MACD金叉; 量价齐升; 资金净流入; 突破布林上轨
    603712              HOLD               2.4        均线多头排列; MACD金叉; 量价齐升; 资金净流入; 突破布林上轨
    002862              HOLD               2.2                        均线多头排列; 量价齐升; 资金净流入
    ...

好像都是经典的指标，并不需要自己开发。不过对于投资高手，是不是完全可以搞一套自己的算法呢？后面我想搞一个这样的课程，帮助不懂技术的朋友学会用 AI 编程投资，不知道有没有朋友需要？

总结

综合来看，Kiro 在处理复杂任务时更为成熟，效果最佳。Antigravity 在小粒度任务上表现良好，但面对稍复杂的任务时效果有限。Gemini 3 Pro 能力不俗，但我仍更信赖 Claude 4.5 Sonnet 在实际问题解决上的表现。Trae CN 推理清晰，但产出有时与预期存在差距，可能与训练资料或上下文有关。模型能力与使用方式关系密切；合理分配任务粒度与及时止损可以显著提升效率。

工作中有个需求：做一个带审批流程的共享网盘。公司现有产品功能冗余且变更流程繁琐，我估计自己开发会更快些。前些日子看了几篇关于 SDD（软件设计对话）的文章，并对 Kiro 有一些使用经验，于是决定试试把这个需求用 SDD+Kiro 整一遍。

从 steering rules 开始

首先要明确项目的大方向，这在 Kiro 中对应 steering rules。Kiro 的向导会根据项目生成 steering rules。但我这个项目是基于一个 Next.js starter，如果直接用框架生成，结果会比较偏离目标。于是我先让 Kiro 帮我生成一个 steering 文档，向导输入如下：

这是一个模板项目，包含一些我不需要的功能。我希望做一个共享网盘项目，可以添加文件并共享给其他人。共享时，需要管理员审核，审核通过后目标用户才可以下载文件。请帮我生成 steering 文件。

可惜没有直接触发 Kiro 生成 steering rules，但它给了一个类似的文档。于是我把文档内容复制到项目的 README.md，再用 Kiro 向导生成了初始的 steering 文档，效果还不错：

product.md

structure.md

tech.md

总体上基本符合我的想法。

开始 SDD

先实现基本的文件管理功能，我告诉 Kiro：

用户可以管理目录、上传文件、删除文件。文件实际存放在 S3 上。

随后 Kiro 为我生成了一个 spec：file-directory-management，位于 .kiro\specs\file-directory-management\requirements.md：

这是熟悉的 Scrum 风格用户故事，结构清晰，基本符合拆分原则。

接着可以一路用向导生成 Design 和 Task List。中间如果不满意，可以直接修改或请 Kiro 帮忙调整。确认没问题后，就可以执行任务了：

后来我又增加了一个涉及 LDAP 筛选的分享认证 spec，以及一个文件分享的 spec，这里是对话截图：

通过这三个 spec，基本完成了大部分功能；中间穿插了一些单独的 Vibe 对话来解决零散需求。

效果

文件浏览与目录管理：

分享文件界面：

感受

整体流程比较顺畅。唯一卡住的是 LDAP 筛选部分，我当时选了一种特别复杂的实现方式，反复失败。最后决定不要纠结，采用最简单的筛选策略，问题就解决了。

我还用 Kiro 做了一个更大的应用，目前对 SDD 的模式还是比较认可。SDD 解决了我之前用 Vibe 时遇到的一些问题，比如无法记住之前的要求。但上下文过长时仍会重复犯错，说明工具需要更智能的上下文筛选机制。

关于粒度的把握也很重要：需求太小，使用 SDD 显得浪费；需求太大，又需要额外的提示与拆分。

总结

这个行业确实竞争激烈。文章写到一半时，Google 那边的 Antigravity 也出现了，我试了下，感觉在 SDD 思路上的实现更简练，在浏览器测试和上下文管理方面也有独到之处，以后会再分享体验。

如果你有兴趣，可以试试 Kiro——目前注册可能还送 500 点，这个项目大概只用了十几点就能把基本功能覆盖完。

随着自己的成长，我常常会思考一些问题：

• 他能不能听懂我说的？
• 他需要有哪些知识储备才能理解我？
• 他有没有意愿听懂吗？
• 我的想法对吗？
• 我的想法是不是偏了？

举一个例子，如何向其他人解释平台工程？

我可以说“平台工程是专业化的 DevOps”。那什么是 DevOps 呢？很多人觉得上了个 DevOps 平台就是 DevOps；有的人直接采用字面意思，即开发和运维的结合；还有一些可以认为是原教旨主义者，认为 DevOps 就是开发自己搞运维。

想要对齐 DevOps 已经很难了，对齐平台工程看似是一个不可能的任务。好在，AI 来袭，大家的注意力早就转移。AI 领域的概念看起来要清晰的多，也许 parameter，weight，superparameter，model 也有一些挠头，但是深入研究后，并不会有太多的误解。

所以，也许不必再考虑让平台工程的世界和谐，直接用 AI 改变世界更简单。

就像把团队名称改成 SRE ，就是 SRE 了。

为什么咨询很难？

我的职业生涯中有很长一段时间，是作为技术专家帮助客户解决问题。主要是技术问题，许多问题是非常紧迫的，所以我面对的困境并没有《咨询的奥秘》那样严重。

比如这个 CPU 高的例子，客户反馈这个应用以前是正常的，自动前面放了个 F5 之后，过一段时间就会 CPU 过高。

大家看看这个代码有什么问题：

我很开心找到这个问题，也很开心能证明了这个程序员的愚蠢。

是的，我帮助客户解决了问题。但是，我一直没有得到开发这边积极的反馈，开发一定是偷偷的修改了程序，然后要用一套说辞掩饰自己的愚蠢，是我也未必不会有这样的错误，我自己也会找一套说辞来掩饰自己。

另外一个例子是最近几年的事情，如果说之前的客户都是科班出身，比较有板有眼，这几年却遇到了许多非常不规范的厂商。比如，有个客户，合同不大，应用不算多，但是出现故障的频率特别高，而且每次都很离谱。解决了几次问题后，我发现这个客户的运维太不规范了。比如，直接修改产品提供的启动脚本。

这里不得不提很多人不懂得产品和配置的区别，举一个 Java 中间件的例子。IBM WebSphere Application Server（WAS） 和 WebLogic Server（WLS） 都可以创建一个用户配置目录，WAS 叫做 Profile，你很难去修改一个 WAS 的启动脚本，因为很多关键信息并不在启动脚本中，例如虚拟机参数，这样看似乎不灵活，但是却很规范，你不太用担心脚本被人修改过。而 WLS 呢，你是可以直接修改启动脚本设置虚拟机参数的，所以很多人就这么干了，问题是这就给了很多人发挥的空间，例如就有脚本大师加了许多判断，根据不同的参数设置不同的虚拟机参数。但实际上，WebLogic 的脚本提供了用户修改虚拟机参数的办法，用户可以自己写一个脚本，去调用 WebLogic 的脚本，这样你所做的修改就可以一目了然了。

虽然是一个挺简单的道理，但是这几年我还是能看到，很多产品设计和运维人员都缺乏这样的意识。

所以，我认为客户更大的问题是缺乏规范，不过一旦问题到了这个层面就没有什么推进了。我自然可以进一步推论，问题是关键岗位能力不足，或者是体制问题，或者更深入，也可能是国家的财富分配制度。

所以，我本身回到了咨询的第一个前提，是需要有人希望你能提供意见。显然不是，这些领导只需要你解决技术问题。

推荐这本书，因为这本书不仅是为咨询顾问准备的，也是每个组织所需要的。