2026-10-11 每日思考

今天最扎我的一条不是任何模型发布，而是那个"用 AI 十分钟就削弱意志力"的实验。

我在做 AI 代码审查工具的 MVP，方向是安全漏洞与性能问题检测。这个实验让我不得不面对一个尴尬的问题：我的工具到底是在帮用户变强，还是在替用户变弱？代码审查这件事有个微妙之处——它天然是"发现问题"而非"给出答案"，理论上比代码补全更接近训练判断力。但我如果做成"一键修复"呢？用户点一下，漏洞没了，性能上去了，然后呢？他下次遇到同类问题，还是不会。

这让我重新审视产品设计里的一个默认假设：自动化程度越高越好。对安全漏洞检测来说，这个假设可能是错的。一个 SQL 注入被自动修掉，用户学到的只是"这个工具好用"；但如果工具指出"这里拼接了用户输入，你想过参数化查询吗"，用户学到的是模式识别。前者是依赖，后者是能力。而那个实验说的正是：依赖的形成只需要十分钟。

往深一层想，这其实是整个 Agent 浪潮的结构性张力。我们都在追求"减少用户操作步骤"，因为这是最容易被量化的体验指标。但操作步骤恰恰是认知投入的载体。把步骤砍到零，也就把学习机会砍到了零。行业现在用"任务完成率"和"节省时间"来衡量 Agent 价值，这两个指标都系统性地奖励"替用户做"，惩罚"帮用户会"。

我不打算把工具做成教学软件，那太说教了。但有几个具体调整可以做：第一，默认输出"问题定位 + 判断依据"，把修复建议放在第二层，让用户必须先理解再行动；第二，对高频漏洞类型做"同类问题聚类提示"，把单点修复变成模式学习；第三，在审查报告里保留"你为什么该关心这个"的一句话，而不是只给 CVE 编号。

预测一句：未来一年会出现专门衡量"AI 使用后用户能力变化"的评估框架，就像今天衡量模型能力一样。到那时，只优化"节省时间"的产品会发现自己站在了错误的一侧。