又又又是年更了
打算整理一下近期AI使用的感受。
第一感受还是发展太快了,国外三家断档领先,国内全靠性价比。
因为公司本身的协助流程还远未达到全员AI协同,所以目前还是「单机模式」,所以考虑自己能提效就好了,使用场景主要是新功能、新产品的需求输入输出,方案的整合。
然后怎么用AI,就是丰俭由人了。毕竟有些公司每个月给200,有些公司给账号,有些公司啥也没有(嗯,就是我),当然啥也没有也不算坏处,至少没有这方面考核了。预算充足的话,就算纯靠一句句对话加上好的模型也能得到好的产出了。
在用什么工具
IDE(Cursor、Trae-cn)、Codex、豆包(是的,你没看错)
IDE的相比网页版对话的优势还是在整体项目的理解和规范的输出上可以做很多事情,光对话的话只有短记忆适合有一搭没一搭的日常问答。
Cursor一个月140左右,外部模型大概够出4.5套原型了。自家的模型差一些,基本用不完。
Trae-cn,目前处于白嫖阶段,国模随便用能力虽然差,架不住性价比高,需要花时间要反复反复的调试,缺点就是要排队。刚出的SOLO移动端也不错,打算替换部分豆包的活儿了。
Antigravity,之前用过,但是改成一周重置一次后就不用了,不然装一堆IDE就臃肿。
Codex,一周重置一次,用GPT5.5每次够出一个方案,可以白嫖。
豆包,日常对话、问答、举一反三全用他。
都怎么用的
排除预算充足的,个人理解目前最省钱的方式还是自己花时间将项目背景、输出规范整理后,再进行方案的输出。
先用Trae国模御三家,哪家排队快就哪家,MiniMax2.7、GLM5.1、Kimi2.6,如果有图片需要解析理解的,可以用Kimi2.6。
流程就是:
创建项目文件
创建产品背景、参考用例(包括功能用例、交互用例)
创建输出规范(项目级)、SKILLS
开始话聊
继续话聊修改,也可以手动修改(遵循Markdown格式)
举个几个工具混用的例子🌰
先用Trae的KIMI2.6整理方案
·输出黑白原型HTML(这个我喜欢用Codex输出,Trae也可以就是效果没这么理想)

再用Codex的GPT5.4出带交互的HTML文件
·再反复调试(这里就是最费token的地方),小调整一般就手动了,大面积有交互的调整还是继续话聊。

最后用Cursor直接话聊微调
·最后汇总输出材料(需求说明.md和带交互的HTML文件)交付给技术,钉钉或者传到Git分享给技术。
·如果技术不适应的话,只能花点时间页面截图和需求说明里拆分说明做标注,放axure里上传蓝湖。

基本上现在就是这么一套流程应用在工作里。
说实话,这套流程不算优雅,也不算什么最佳实践,更像是一个公司没有统一AI流程前,个人先凑出来的“野路子”。
目的就是:先低成本的跑起来。
把前期整理需求的工作提效起来。比如业务直接给你一堆材料、表格、页面你要先要靠自己一边想一边写。现在至少可以先把这些东西扔进一个项目文件夹,让AI帮忙归类、补全、拆结构。
当然,不是说丢进去就完事了,定规范给背景还是要自己来的。AI工具最适合干的还是帮你把一堆零散信息快速变成一个可以继续讨论的东西。
比如最近要做企业报表需求特别多各个业务条线要梳理,AI可以先帮我提供的背景、目标、业务路径理解后,再把各种报表全部分析结构化的列出来。然后再看哪些是合理的,哪些是废话,哪些是它脑补的。原型也是一样。
黑白HTML原型当然不一定比Axure的精致,尤其是细节交互和组件规范上,很多时候还得手动调。但它有一个好处,就是快也不干扰UI出视觉。只要前面需求说清楚了,几分钟能出一个可以讨论的版本。
对我来说,这个阶段的原型不追求好看,主要是为了降低沟通成本。
尤其是一些有流程、列表、表单、配置的标准B端功能,光靠文字说半天,技术和测试脑子里可能还是各想各的。有个HTML页面摆在那里,哪怕很粗糙,也能让大家先对齐思路。
碰到的几个坑
第一个坑,不要期望一版成型。
AI出页面和猜拳一样,如果你喂的资料少,那他出的东西经常看起来很完整,但仔细看会发现很多地方是“合理但不准确”。比如字段名看起来像那么回事,流程也像那么回事,但和真实业务不一定匹配。所以第一版我一般只当草稿,不当结果,还有持续话聊。
第二个坑,是别把所有问题都交给AI猜。
有些信息缺失,它不会真的停下来等你补材料,而是会自己补一套看起来还挺顺的逻辑,就是类似之前对话里经常出现的“AI幻觉”。这个在需求场景里挺危险的,因为它写得越顺,你越容易忽略它其实没依据。
所以还是要先把规范、边界、模版这些它不确定的地方都先整理好,第一次会觉得麻烦后面就可以变成SKILL复用了。
第三个坑,是不要沉迷调原型。
这个特别容易发生。
一开始只是想让它改个按钮位置,后来变成改布局、改交互、改样式、改状态,再来一轮又一轮。最后token烧了不少,时间也没省多少。
所以我现在会给自己设一个边界:原型只要能表达流程,就先停。真正的视觉和组件规范,还是交给后面的设计或前端规范去处理。
如果你也想这么用,可以先别搞太复杂。
一些建议
从一个很小的场景开始,比如写周报、整理会议纪要、输出一个简单需求说明。
先准备三个文件就够了:产品背景.md、参考材料.md、输出规范.md
然后再让AI基于这三个文件工作。
这里有一个我最近常用的提示词,简单但够用:
你先不要直接输出最终方案。请先基于我提供的项目背景、参考材料和输出规范,帮我做四件事:1. 提炼这个需求的核心目标2. 整理用户操作流程和关键页面3. 列出当前材料里缺失的信息4. 标注哪些内容是你推测的,哪些内容是已有材料明确提到的
等我确认后,再继续输出正式需求说明。
这个提示词的核心不是让AI少干活,而是让它先别急着装懂。
前期让它整理,中期让它生成,后期让它检查。
切忌不要一上来就让它交最终稿。
结论
如果公司有统一AI工具和流程,那当然最好,权限、知识库、规范、交付物都能统一起来。
但如果没有,也不是不能用。
单机模式的问题是麻烦一点,需要自己整理背景、自己维护规范、自己判断输出质量。但好处是自由,想试什么就试什么,没人管,也没人考核,可以自己来做自己的规范。
目前对我来说,AI最大的价值不是让我少做事,而是让我更快进入可讨论状态。
以前很多工作是从一张白纸开始,现在至少可以从一版草稿开始,这也是一种提效了。

最近主要还是再研究怎么把AI输出的东西交付给技术,而不是只停留在自己觉得爽的阶段。
后面有空的话,还会继续研究一下几个具体场景:
比如怎么用AI写出更符合技术评审的需求说明,怎么用AI出黑白HTML原型同时也可以附加标注。
如果有好的思路也可以留言讨论,一起进步~
夜雨聆风