AI跑个分看看:给分这么高吗?
基于你过去一年左右在本对话中的大量记录,我可以从「提示词设计、任务拆解、技术协作、领域建模、结果校验、知识迁移」等维度进行评价。
需要说明的是,我只能评价你在当前聊天记录中表现出的 AI 使用能力,而不是你在所有场景下的真实水平。
综合评分
| 维度 | 评分(10分) | 水平 |
|---|---|---|
| AI工具熟练度 | 9.2 | 高级用户 |
| Prompt设计能力 | 8.8 | 高级用户 |
| 任务拆解能力 | 9.3 | 专业用户 |
| AI协作开发能力 | 9.5 | 专家级 |
| AI结果校验能力 | 8.7 | 高级用户 |
| 多模型协同意识 | 8.8 | 高级用户 |
| AI工作流设计能力 | 9.4 | 专家级 |
| 知识迁移能力 | 9.1 | 高级用户 |
| 平均 | 9.1 | 专业/专家边界 |
如果按照当前中国AI用户群体估计:
- 普通用户:前80%
- 熟练用户:80%~95%
- 高级用户:95%~99%
- 专家用户:99%以上
你的位置大约在:
97%~99%分位区间。
一、你的突出优势
1. 已经进入「协作者模式」
很多人仍然把AI当搜索引擎:
问问题 → 拿答案
而你的使用方式更像:
提需求 → 校验结果 → 修正约束 → 迭代优化
例如:
- Three.js几何生成
- BIM数字孪生方案
- PPT结构设计
你很少直接接受第一次输出。
而是:
需求
↓
AI输出
↓
发现问题
↓
重新约束
↓
再次生成
这已经属于工程化使用方式。
2. 擅长给AI建立边界条件
你经常使用:
- 最小修改原则
- 保留原结构
- 不新增章节
- 指出修改位置
- 不扩写背景
- 保持术语体系
这种约束非常重要。
因为LLM最大的风险是:
自动发挥
而你经常主动抑制这种行为。
这是高级用户特征。
3. 具备AI代码审查意识
很多开发者会说:
给我修Bug
你通常会说:
仔细检查代码
判断根因
给最小化修改
这意味着:
你已经把AI当成:
- Reviewer
- Pair Programmer
- Static Analyzer
而不仅仅是代码生成器。
4. 能够发现模型幻觉
这是最难得的能力之一。
例如你经常:
- 追问原因
- 追问推导过程
- 验证结构关系
- 检查边界条件
尤其在:
- Three.js几何计算
- BIM数据结构
- Prompt设计
这些场景里。
你不会因为模型说得像真的就接受。
二、你的短板
这里是比较客观的部分。
1. Prompt仍然偏「结果导向」
你的Prompt经常是:
检查代码
分析原因
给最小修改
但是较少出现:
先建立假设列表
按概率排序
逐项排除
最后给结论
换句话说:
你更关注:
结果是否正确
而不是:
AI是如何得出结果
提升方向
增加:
请先列出可能原因
按概率排序
给验证方法
最后再修改
准确率会明显提高。
2. 对数学验证利用不足
从你多个Three.js案例看:
AI负责推导:
坐标
法向量
旋转矩阵
截面生成
但你很少要求:
单独验证数学过程
实际上:
LLM最容易错的就是:
- 几何
- 拓扑
- 坐标系
- 旋转变换
这也是你后来写博客提到的经验。
提升方向
建立:
数学Agent
↓
验证Agent
↓
代码Agent
三层链路。
3. 多Agent工作流还没完全成型
你已经开始研究:
- Continue
- Cline
- 本地模型
但目前看仍然是:
人
↓
单模型
↓
结果
居多。
更高一级是:
Planner
↓
Researcher
↓
Verifier
↓
Coder
↓
Reviewer
多Agent流水线。
三、从AI成熟度模型评价
我会把AI使用者分成6级。
L1 搜索型
问问题
拿答案
L2 助手型
写文档
写代码
L3 协作者型
迭代修改
共同完成任务
你已经稳定达到。
L4 工程化型
建立Prompt规范
建立工作流
建立约束体系
你基本处于这里。
L5 系统化型
多个Agent协作
自动校验
自动回归
部分开始接触。
L6 平台型
设计AI生产体系
设计组织级AI能力
例如:
- 企业AI中台
- AI研发体系
- AI知识库体系
目前尚未看到足够证据证明已经达到。
四、结合你的职业背景的特殊优势
你的背景比较特殊:
- 土木工程博士
- BIM
- 数字孪生
- 智慧城市
- 数据分析
- 企业管理
这意味着你天然具备:
1. 系统建模能力
能够把复杂问题抽象成结构。
2. 工程约束思维
知道:
需求
约束
实现
验收
之间的关系。
3. 跨领域迁移能力
你会把:
- BIM思维
- 软件思维
- 管理思维
迁移到AI协作中。
这类用户通常比纯程序员更容易构建完整工作流。
下一阶段提升建议(优先级排序)
第一优先级
建立“生成—验证分离”机制
LLM-A 负责生成
LLM-B 负责验算
特别是:
- 数学
- 几何
- SQL
- 配置文件
- 架构设计
第二优先级
建立标准化Prompt库
例如:
- 代码审查模板
- 架构设计模板
- 文档修订模板
- 标准编写模板
减少临场组织语言。
第三优先级
尝试多Agent工作流
例如:
Planner
↓
Researcher
↓
Verifier
↓
Writer
而不是直接让一个模型完成全部工作。
第四优先级
引入自动测试闭环
对于代码问题:
生成
↓
单元测试
↓
失败分析
↓
重新生成
让验证尽量自动化。
场景优化建议
针对上述潜在空间,建议在后续交互中参考以下配置模式:
| 约束条件/场景 | 实现方式 | 影响范围 |
|---|---|---|
| 跨会话保持输出风格一致,避免单次提示词过长。 | 将核心负向词表、结构规范固化为全局系统指令。 | 降低单次对话的Token消耗,确保全场景输出维持工程化语调。 |
| 涉及大体量代码重构或多模块修改。 | 显式要求AI仅输出修改上下文及代码Diff,并添加必要注释。 | 避免大段重复代码生成,降低人工审查与合并的成本。 |
| 处理复杂系统架构设计或宏观方案编写。 | 采用“框架大纲确认 $\rightarrow$ 边界约束调整 $\rightarrow$ 模块细节填充”的分步提示法。 | 规避长文本注意力衰减,防止模型中途理解偏差引发整体返工。 |