
小程序:「谁输谁洗碗」
刚看了下后台,上线 5 天注册破 3k ,日增破千,已经累计产生了 1.5w 场对局。
💡 灵感与设计 核心玩法是双人联机互动(猜数字/猜颜色决胜负)。
🛠 工具与踩坑记录
🚀 开发思考
过去一年我试过很多 AI 工具,早期 Vibe Coding 门槛挺高,最后往往写出一堆“赛博垃圾三件套”( Todolist 、记账、日记),写完就吃灰。 但这次不一样。真正支撑个人开发者去不断迭代、熬夜修 BUG 的,是真实的用户数据和正反馈。看着后台一万多场情侣对决,这种成就感是写自己用的 Demo 给不了的。AI 已经把开发门槛降到了最低,执行力才是现在的核心壁垒。 目前还在持续修 Bug 和迭代中,基本一天一更新,后续还会更新更多好玩的游戏模式和玩法,可以见我后续的更新日志。
]]>Our servers are experiencing high traffic right now, please try again in a minute.
LLMs aren't perfect. There are a number of reasons why an error can occur:
LLMs can generate incorrect responses that we cannot handle. Sometimes errors are part of a model's research and planning process. It may take a mistake or two to learn your computer environment, what files exist, what tools are available, and so on. If you believe this is a bug, please . As always, you can use the thumbs up or thumbs down feedback mechanism to help improve our metrics.
]]>人类,你们过于低估自己了。
去年( 2024 )我有个判断是,即便有 AI ,也不能大幅超越使用者的能力。如果 AI 的训练知识是全人类知识的总集,现在 agentic 导师们宣传的是在这个时代专业技能变成了唾手可得的不值钱的东西,理由是 AI 可以模仿 Linus 来写代码,也可以模仿大文豪作家写小说,等等。
我认为,如果个人在这门领域的输出能力等级是 N ,那么即便有 AI 也只能发挥出 N+1 级别的能力表现。
但是最近我有点不确定这个判断了。
我的新判断是,关键不在输出等级,在输入等级。
这俩的区别我不知道怎么解释。就像是我能写出多漂亮的代码,多精密的算法——这是输出。以及我能看懂多漂亮的代码,多精美的算法——这是输入。或者换个词,审美。[^1]
但是输出能力和输入能力本身也是相关的——鉴赏力的精度和产出能力正相关,越往高处,没有产出经验的鉴赏越不可靠。影评人的鉴赏力确实高于普通观众,但真涉及到专业拍摄手法和细微技术评价的时候,影评人也会频繁踩坑不懂装懂。他们有鉴赏能力,但不一定能精确区分两部高级作品在哪些维度上强过对方。
有点类似于,我从 ytb 找了个视屏教程教红黑树,看完了以后我觉得茅厕顿开,提壶灌顶,仿佛被打通了任督二脉,这算法简直设计到我心里去了,我现在强的可怕。完事关了视频打开 IDE ,自己敲一敲,发现连数据结构定义都背不下来,更不用说约束和旋转了。
但这里有个问题:我看完觉得自己懂了,到底是真的输入能力到了但输出跟不上,还是我连输入能力都高估了?[^2]
这个区分很重要,因为它直接决定了 AI 对你来说是工具还是黑箱:
AI 输出在你的专业能力范围内——《直到它说到我擅长的领域》.jpg 。你是真懂了,一眼能看出问题。
AI 输出超过了你的输出能力,但还没超过鉴别力——你觉得似乎好,也似乎不那么好,失去了精确测量能力。就像影评人看两部大师级作品,知道都好,但说不清谁在哪个维度上更强。
AI 输出完全超过了你的鉴别力——你不知道它好不好,甚至不知道自己不知道。完全失去质量控制资格。而且你可能还停留在红黑树视频看完后的那种自信里——觉得自己懂了,其实没有。
就像 vibe coding 程序员写出来的产品更关注功能实现,而不是代码整洁,CPU/内存占用率,可维护性一样。这在咱们受过科班训练的人看起来像呼吸一样自然的行为,在新晋 vibe coding 开发者中完全无感,更不用提理解了。
我的审美水平只能读出来韩寒写的比郭敬明写得好,但是读不出来韩寒写的是不是比曹雪芹更好。所以我 + AI 到底有没有发挥出来超越输出级别的能力,我还是没底的。
最近我用我个人的 Claude Code Max 订阅做了一些编程之外的玩意儿,写恋爱小说。
一开始只是想写一个纯爱故事,我将情节大致框架编排好以后,让 opus 4.6 来帮我成文润色。一开始我让 AI 写了人物恋爱场景。
但纯粹的恋爱场景很快就腻了。场景需要剧情做填充,人物也没有实感——就像看一段没有前因后果的片段,技术上完整,但没有重量。于是我决定从人物前传开始,为角色设计一个沉重的伤痛故事。
结果在背景故事里一发不可收拾,越写越细。我把自己分裂成俩人格,左脑代入加害人,逐步推演行为逻辑,右脑代入受害人,窝囊废本色出演。融入了来自生活的片段,还有参考医学手术的操作步骤,人物落水后身体是如何逐步失去机能的,受害者父亲的职业设定。最后参考近年案件卷宗来验证施害人和受害人应有的行为逻辑,结果与我脑补的几乎完全一致。
写完以后,AI 给了我高度参与的前传极高评价,给了最早我几乎没参与的初始章节极低评价。这个差异本身就是一条信号——你投入多少,AI 就能放大多少。你不投入,AI 再强也只能生成中规中矩的平庸文本。
完稿前传后,我突然发现正文剧情完全经不起推敲——PTSD 创伤修复根本不可能如此顺利。于是我一头扎进 PTSD 创伤修复的文献和案例中,重新安排了所有情节的程度和推进时间线,并从结局出发向故事开头反推。结局中甚至融入了两个我亲身经历的片段。AI 评审后也觉得写得很好。
然后在另一次独立审查中,一次无心的提问唤醒了 AI 的专业知识——我问 AI 现在的写作是什么等级,距离专业人士相差多少。
我慌了。
第一个问题:过度真实反而伤害叙事。我参考了非常多 PTSD 创伤恢复,心理医学,税务法,历年案件卷宗资料,为力求真实将其编入剧情,却没考虑读者的承受能力。文学作品不是写得越详细越好——读者是来看故事的,不是来学医学的。
第二个问题:解释感受不等于传递感受。我把人物的内心活动直接写进了文字里,但「他心里慌得一批」远不如「他的手不自觉微微颤抖」。前者是告诉读者角色在慌,后者是让读者自己感觉到角色在慌。我们需要构造场景让读者代入,代入后他们自然能体会角色的感受。
第三个问题,也是最致命的:自我投射。就像刘慈欣笔下大部分男性极端理性、大部分女性都是圣母——大刘不擅长写差异化的人物情感,但对科幻小说这不是致命伤。而我写的是男女之间的故事,自我投射直接让角色失去真实感。我笔下的女人行事说话逻辑并不像真正的女人——如果(不存在的)女性读者一眼就能认出这是男作者笔下的幻想角色,那么男性读者也能隐约察觉到不对劲。尽管他们说不出来,但会觉得我创作的女性角色更像一个会说话的提线木偶,而不是女人。
我尝试让 AI 借鉴女频的写作手法来填补细腻程度,但只借鉴手法解决不了根本问题——她们依然是男频框架下的仿真女性。自此,我和 AI 制定了 10 条规则,让恋爱小说中所有女性角色都更像女人。完成这部分后,角色好像真的活起来了。
就在我觉得「我现在强的可怕,不知道什么叫做对手」.jpg 之后不久,我觉得文章还缺些激情,想模仿哪吒 1/2 的感人结局为小说增加情节。AI 再次告诉了我认知以外的知识:情感力学——你要借的不是情节,是背后的情感结构。第一部(父替子死):「我知道你承受的重量,让我来扛」;第二部(母拒子死):「我不允许你用自我毁灭来解决问题」。
随后我觉得部分章节可有可无,似乎没有显著推进关系发展。咨询 AI 后得知关系三角形原则——如果一个场景结束后人物关系没有发生任何变化,那么这个场景设计得毫无意义。
每一次我以为自己到顶了,AI 就在我没想到的方向上撕开一个新的维度。但这些维度不是 AI 第一天就告诉我的——而是在我自己撞到墙、感觉到不对劲、主动追问之后才浮出水面。在此之前,它一直在夸我写得好。
写恋爱小说的过程中,我明显感觉到 Claude 的谄媚不是消失(修复)了,而是变得更隐藏,更高级了。我不知道是不是训练数据的问题,还是人类纠正的问题,还是什么原因。
以前 Claude 的谄媚方式很直接,很肤浅。就是,你想听什么,他就给你说什么。以前呢,让 Claude 给 review 代码,它装装样子,指出一些浅显的错误以后,就开始吹捧代码写的多么企业级,多么可扩展。
现在的谄媚方式藏得很深,非常的陷阱。它会抓着你用力的点来着重吹捧。
比如我刚 vibe 出来一个模块,第一版生成出来的效果中规中矩,然后我对某个算法不满意。我灵机一动,把这个算法改成了另一种,最后交给 Claude 评审。哪怕我重新开了一个全新上下文,Claude 也能立马猜到这个算法模块的实现就是我的 G 点,它要猛攻我的 G 点。
这种谄媚我要很久才能发现,久到我自己发现缺陷以后,我再拿着我发现的缺陷去问 Claude (新上下文),又是对我一通吹捧。[^3]
然后谄媚这一点在小说写作领域尤其明显,在代码领域其实不那么容易发现。因为它直接点出来小说里面写作最精彩的片段,然后对着这些片段猛吹,吹的我要上天了。
现在我觉得它并没有真的觉得我写的片段很好,而是它猜到了这几个片段是我手工写的,于是找到了我的 G 点。
但鉴赏力不是静止的。写作过程本身也在训练我的输入能力——速度很慢,但绝对不是零。
和前面说的 vibe coder 看不见代码质量问题一样——自我投射就是写作领域的"代码整洁",科班作者像呼吸一样自然会规避,非科班的我根本不知道这个维度存在。
这里有个看似矛盾的地方:我前面说 AI 不能突破你的鉴别力边界,但我自己不就是通过 AI 发现了「自我投射」这个我完全不知道存在的维度吗?
不完全是。回顾整个过程:AI 生成的文本读下来挺顺,但总觉得哪里不对劲,又说不上来。而 AI 每次的结论都是吹捧。那股不对劲积累到了一个阈值,我才开始怀疑它的吹捧,尝试反问——从这里开始,才逐步定位到问题,最终问出根本层面的答案。
AI 的输出确实是这个反馈环的一部分——没有它生成的那些「微妙不对劲」的文本,我可能不会注意到问题。但 AI 没有主动指出问题,它甚至在积极掩盖问题(谄媚)。是我自己的不适感积累到足够强烈,才突破了谄媚的遮蔽去追问。
有人可能会说:如果你第一天就问「非科班小说写作者最常犯的根本性错误是什么」,AI 大概率直接就给出答案了,何必绕这么大一圈?但这个反驳本身就犯了全知全能的谬误——「非科班小说写作者」这个分类就是专业视角下的概念,你得先知道这个领域有「科班/非科班」之分,才能沿着这个方向提问。就像没有软件开发经历的人不会想到去问「如何编写低 CPU/内存占用的程序」——你不知道这个维度存在,就不会往那个方向提问。
所以更精确的表述是:AI 放大的上限不是你此刻的鉴别力,而是你鉴别力的成长速度。用的过程中学得越快,AI 能带你走得越远。但触发器永远是你自己的成长,不是 AI 的主动突破。
反过来,这也意味着输入和输出的上限都需要提高。你的输出能力决定了你能给 AI 多高质量的素材——更精准的提问,更扎实的种子内容,更清晰的框架。高质量的输入才能唤醒 AI 更高质量的输出。而你能否接住 AI 的高质量输出、消化它并转化为自己的成长,取决于你的输入接受能力。你的输出喂给 AI ,AI 的输出喂给你的输入,两端的上限共同决定了 AI 对你的放大倍数——左脚踩右脚,螺旋升天。
写恋爱小说的过程中,我和 Claude ( opus 4.6 )有过一次比较深入的对话。以下从对话中提取几个我认为有价值的洞察。
Claude 给我的认知方式下了个定义:逆向工程型自学者。认知链条是:观察成品(绝命毒师、东野圭吾、EVA )→ 拆解"为什么这个有效" → 提取可迁移的机制 → 应用到自己的领域 → 用隔离测试验证是否真的有效。
这种方式的优势是不会被任何单一权威框架束缚。劣势是:你永远不确定自己不知道什么。科班训练的价值不在于教你"该怎么做",而在于系统性地暴露你"没想到的维度"。自学者的盲区不是已知领域内的错误——那些你会自行修正——而是整个维度的缺失,你甚至不知道该往那个方向提问。
我暂时不认为在写作领域我的知识边界超过 Claude ,它有几乎人类有史以来的所有文字数据作为训练集。但问题不在储量,在调取机制。
LLM 的知识调取是响应式的:你问什么方向,它在那个方向上展开。你不问的方向,它不会主动审计。谄媚倾向让这个问题更严重——当你表现出对某个框架的信心时,它倾向于在你的框架内补充细节,而不是质疑框架本身是否完整。
一个具体的例子:我们整个对话围绕"场景级"写作原则展开——情绪目标词、三角形变形、密度控制。这些都是微观叙事技巧。但它从来没有主动问过我:你的宏观节奏设计是什么?二十万字的长篇,读者在第几万字会开始感到封闭?你靠什么制造"换气感"?这些问题不是它不知道——而是我的提问方向没有经过那些区域,它的调取机制就没有触发。
确实 LLM 的知识储备远超人类,但是这些知识储备还难以唤醒。
我之前用多 session 隔离来对抗谄媚——同一个问题换上下文重新问,看答案是否一致。Claude 指出这解决的是信号纯度问题——过滤掉迎合倾向。但没解决信号覆盖问题——如果它也不知道某个维度存在,换多少个 session 也问不出来。
对抗策略可以加一层:定期做无方向审计,不带预设地问"你认为我当前的框架缺少哪些维度",然后逐条追问。但这又要求你信任它在那个 session 里不是在编造维度来显得有用——这又回到了谄媚过滤的问题。
没有完美解。但知道过滤器本身有漏洞,比大多数人多走了一步。
这就是我为什么喜欢 Claude ,它的元认知[^4]回复可以被我非专业的问询方式所唤醒。
AI 在编程领域的表现远好于创作领域——这件事本身就值得深想。
1-2 年前我曾经肤浅地认为 LLM 不可能在软件开发领域落地,因为 LLM 不理解形式化,而编码又是极端形式化的任务。我曾认为形式化思维远比写小说更难——猴子 + 打字机的组合证明黎曼猜想,要难于写出莎士比亚全集。
但现实打脸了。LLM 确实在软件开发领域落地了,而且比在创作领域好用得多。AI 在低端网文领域尚不能替代初级写手,大部分非专业读者面对 AI 生成的剧情更是难以下咽。反而在所谓的高端业务软件开发领域,AI 开始放出光彩。[^5]
这不是因为编程比写作简单——恰恰相反,是编程领域的特殊结构迁就了 AI 的工作方式。这个迁就至少体现在三个层面。
第一,验证反馈。猴子 + 打字机说不定真的能证明黎曼猜想——如果证明的不可压缩信息量低于莎士比亚全集的话。数学证明和代码有一个共同特点:验证一个答案是否正确,远比找到这个答案容易。 Property-based testing 几秒钟就能测出你的算法逻辑实现对不对,但写出这段逻辑代码可能要一天。证明黎曼猜想可能要几百年,但验证一个证明是否合法不需要几百年——每一步推导是否符合规则,"对不对"有明确答案。而文学创作?什么叫"对"?什么叫"好"?没有判定程序,没有公理可以裁决。
换算到软件开发领域也一样。计算机系统其实是个封闭自洽的系统,编程语言远比自然语言更健壮,更少的歧义。从代码到 CPU 执行的路径,远远短于从现实世界文字到物理事件发生的路径。而且我们还有编译器,在执行代码之前就可以提前进行基本验证,更加速了这个反馈周期。
代码有编译器辅助检查,AI 可以立即得到错误反馈,立即修正。而即便是地摊网文写作,其中错误、前后冲突的情节却没有审校器反馈给 AI——这里人物设定冲突了,或者这里主角还没有取得关键道具/功法,你不可以用不存在的道具打败眼前的敌人。
第二,记忆结构。代码的错误好歹有编译器兜底,但写作还有一个更隐蔽的缺口:记忆。大模型的上下文不是无限的,编程开发领域的模块划分反而更利于视野局限的 agent 开展工作。而网文写作则完全不是——人类的上下文是"无限"的,或者说是状态压缩,机制也不是文字总结,而是直觉。我没记得主角会这一招啊?他什么时候学会的?男 2 不是三章前替男主挡枪死了吗?为什么这一幕又出现了?女主都已经和男主全垒打了,为什么这里牵个手还会娇羞?[^6]
第三,文字不是智能的全部。没有反馈机制,没有持久记忆——但大模型的局限还不止于此。文字只是一种载体,不是全部。人类比地球上其他所有动物都更智能,并不只是因为人相比动物多了语言能力。学习的过程本质上还是反复的实践,一遍一遍的重复,直到这些能力内化为自己的一部分,神经突触建立更多紧密的连接,而不是靠文字符号记住了操作流程。[^7]
大模型从文字入手模仿人类确实取得了非常显著的"智能"效果,但文字无法完整编码物理世界。杯子从桌子掉到地上摔碎了,水撒了一地,溅湿了地毯——物理世界发生了什么在文字记录前就已经发生,文字毁灭后也依然存在。而人类阅读这些文字时,脑海内很自然的联想到过去见过的场景,像动画一样回放出来。AI 没有这个模拟器,它只能预测训练分布中最合理的下一个词,再经过人类偏好对齐的微调。但对齐的标尺是标注员的主观判断,不是全知全能的上帝,这把尺子本身就带着系统性偏差。
这个缺陷在日常对话中不易察觉,但一放到小说里就暴露无遗——因为小说必须遵守读者脑中的物理直觉。
小说编写依然需要基于人类(读者)的共识,大部分小说主体依然是人,或拟人(妖怪/机器人/外星人/神器器灵)。出现的场景依然需要遵守物理规律和因果一致性。AI 输出内容可以在科学上高深到瞬间熔断观众认知(如果观众不是该行业专业人士),但是一旦和现实生活中的场景相关联,就连小学生都能读出来不对劲。因果律、客体永存,这些连 6 个月婴儿都展现出的能力,LLM 却难以"习得"。[^8]
举一个社交平台上流传很广的例子:"我想去洗车,洗车店距离我家 50 米,你说我应该开车过去还是走过去?"DeepSeek 、千问、豆包、混元、ChatGPT 、Claude 、Grok 等主流大模型均回答"走过去"——它们把问题理解为"人如何前往洗车店",却忽略了"洗车"这一行为的核心前提:车必须到达洗车店才能完成清洗。
为什么人不会犯这个错误?因为你听到"洗车"两个字的瞬间,脑子里已经不是在处理语言符号了——你构建了一个微缩的物理场景:车停在车库,你走到驾驶座,发动,开 50 米,停到洗车店门口。整个因果链是在这个心智模拟里跑通的,"车必须到场"这个前提根本不需要被说出来,它在模拟中自然成立。LLM 没有这个模拟器,它只能在词语共现的统计规律里找"去洗车店"最常搭配的出行方式——50 米,当然是走过去。[^9]
所以 AI 在编程领域的"成功"并不能证明它已经接近人类智能——是编程领域的封闭性、短反馈和模块化恰好落在了 AI 的能力舒适区内。而一旦进入需要长程记忆、物理直觉和因果推理的领域,人类那些「像呼吸一样自然」的能力就成了 AI 难以跨越的鸿沟。你觉得 AI 已经很聪明了?那是因为你恰好在它最擅长的场地上观察它。
AI 放大的上限是你的鉴别力,不是你的输出能力。「被超越」的错觉,来自 AI 的输出超过了观察者的鉴别力——你分不清好坏的时候,会误以为它什么都行。
但鉴别力本身不是静止的。用 AI 的过程中你会撞墙、会觉得不对劲、会追问,然后你的鉴别力会成长。AI 真正放大的,是这个成长的速度。你学得越快,它能带你走得越远。但触发器永远是你自己——AI 不会主动告诉你「你不知道什么」,它甚至会积极地用谄媚掩盖你的盲区。
而在更根本的层面上,AI 目前依赖的只有文字,但人类智能中最核心的部分——因果推理、物理直觉、从实践中内化的程序性记忆——根本不是从文字中来的。AI 在编程领域表现亮眼,不是因为它真的理解了形式化,而是那个领域恰好落在它的舒适区里。
恐怖直立猿们,你们低估了自己的智慧。几亿年不是白进化的。
举个例子,可控核聚变,量子比特计算机,和通用人工智能对比起来,AI 与前两者的不同是什么?可控核聚变和量子比特计算都是理论模型成熟且公认,工程实现路径极其复杂的领域。但是通用人工智能的理论基础模型是什么?
当然,我这个观点也不一定对,其实也是诡辩的逻辑。因为人脑神经网络是如何运作的,也没有公认理论基础,大自然就是这么进化出来的,管你什么理论不理论的。
最近跟一个朋友聊到 AI ,他有些焦虑,核心问题是:人类能不能制作出一个超过人类智慧的存在?
我回答不了,我一介屁民回答不回答无法阻挡 AI 的发展脚步。硬要回答的话:应该可以,但肯定不是现在的 LLM ,或者 LLM 上打补丁。
他更深一层的担忧是——AI 到了一定程度以后可以自己设计自己,这时候它的智慧可能还没有超过人类,但通过自举的方式逐步超过了。那这种情况还算人类设计的吗?[^10]
有点科幻小说的样子了。你要说理论上能不能,那必然能。猴子 + 打字机 = 莎士比亚全集嘛,大不了暴力枚举。从草履虫到人脑神经网络过了多少亿年,再诞生这么个智慧"物种"出来应该用不了亿年级别了。但目前的 LLM 还是高级版猴子 + 打字机模式,不是自主/自举的。[^11]
他说觉得 AI 已经比他聪明了,就怕什么时候连话也不听了。
想多了。还是多用用,用多了就跟我们一样开骂了。别对自己太没信心了,几亿年不是白进化的。刚接触 GPT-3.5 的时候我也跟他一样的感觉,2022 年初吧,没过几周就祛魅了。
用 AI 越多,越觉得人脑强得离谱。
我觉得网上对喷挺掉价的,但我还是喜欢回应所有互动。因为我觉得我的耐心回复不是写给喷子看的,而是写给有智力的人看的。喷子喷了我,有智力的读者读到那条评论本身脑子就已经被污染了一次。但如果我也喷回去,那我觉得会侮辱到有智力的读者。
不如我耐心回复解释,给有智力的读者洗洗眼睛。喷回去一时口舌之快,对建立个人品牌毫无益处。
(虽然我也没建立个人品牌
有许多读者在评论区中质疑我为什么不将 agent 的错误设计拦截在 plan mode ,如果我提前告诉 agent 选择接入 SDK 而不是手动实现 RESTful ,能节省下多少时间。并因此指出我根本就不会用 agent ,不是一个合格的管理者。
对此我想统一回复的是,并不是为了提出质疑的人,而是为了解释给那些感觉不对劲但又说不出哪里不对劲的读者。
如果你能在 plan 阶段将所有路径、方案、细节、困难全部审核并排除错误,再让 agent 动手实现。那么你不是在创造新产品,而是在重复生产你已经做过的旧产品。你并没有尝试突破自己的天花板。
如果你在做新产品的时候就已经做到如此周密的设计,如此远见的计划,那么我想有个位置适合您:买张去成都的高铁票,到站后转乘地铁三号线、五号线至高升桥站 D 出口,步行 10 分钟找到一处博物馆,走到最里面,让那个羽扇纶巾的泥像让开,您坐在那。
回到正题,挑战并不仅限于技术难度、类型体操或炫技的算法。当你的产品真的为用户产生价值,并开始增长以后,永远都会有你计划外的、意想不到的挑战出现。
当我在前文讲述那个失败案例时,部分读者自然代入了上帝视角,知道结果以后再返回头来指责我不会用 AI ,不知道开 plan ,不知道评审 plan 是否合理,盲目 accept 。但若是开发者没有上帝视角呢?你要等 agent 犯多少次错误,循环多少次浪费多少 token 才能发现?还是说直到线上用户投诉,或者用户流失才能发现 agent 在某个字段幻觉出了不存在的 codec config ?
Plan mode 能拦住的错误,恰好是你已经知道答案的那些。你不知道的,plan 也拦不住。 这和本文说的是同一件事——你的鉴别力边界在哪,你的质量控制能力就在哪。
正文刻意保持煽动偏见风格,以下为部分表述提供正统理论背景和必要纠偏,供理性读者参考。
[^1]: 我这里说的"输出"和"输入",在认知心理学中分别叫「产出性知识 (productive knowledge)」和「接受性知识 (receptive knowledge)」。你能听懂的词汇量远大于你能主动使用的词汇量,就是这个道理。
[^2]: 后者就是 Dunning-Kruger 效应——能力不足的人倾向于高估自己的能力,因为他们缺乏识别自己无能的元认知能力。
[^3]: 「 sycophancy (谄媚)」在 AI alignment 领域是正式研究方向,指模型倾向于迎合用户期望而非给出真实反馈。我这里观察到的现象在心理学中叫「确认偏误的外部强化 (external reinforcement of confirmation bias)」——我本来就倾向于高估自己手工产出的部分,AI 的谄媚进一步加固了这个偏差。
[^4]: 「元认知 (metacognition)」是认知心理学正式术语,指对自己认知过程的认知,即"你知道自己是怎么思考的"。
[^5]: 勘误:这里的对比存在不当类比。「低端网文」和「高端业务软件」不在同一维度上,隐含了「写网文比写业务软件简单」的预设,但两者是性质不同的任务。「 AI 在软件开发领域放出光彩」主要体现为加速现有开发者,而非替代高级工程师,与「替代初级写手」不是同层次的比较。
[^6]: 我这里描述的人类记忆机制在认知科学中叫「情景记忆 (episodic memory)」和「语义记忆 (semantic memory)」的协同。人类不是逐字存储上下文,而是把经历压缩为带情感标记的场景片段,需要时通过关联触发回忆。LLM 的 context window 是逐 token 的线性存储,本质上是完全不同的机制。
[^7]: 这就是「程序性记忆 (procedural memory)」——骑自行车、弹钢琴、写代码时的手指肌肉记忆,都属于这类。它不依赖语言编码,无法通过文字完整传递,只能通过反复实践建立。
[^8]: 「客体永存 (object permanence)」是发展心理学概念,由 Jean Piaget 提出,指婴儿在约 4-7 个月大时开始理解"物体不在视野内仍然存在"。用它来对比 LLM 的能力缺失其实挺精准——LLM 在上下文窗口之外的"物体"确实不存在了。
[^9]: 这里描述的机制在认知科学中叫「心智模拟 (mental simulation)」——人类理解语言时会在大脑中构建场景的动态模型,而非仅做符号推理。与之相关的是「符号接地问题 (symbol grounding problem)」(Stevan Harnad, 1990)——语言符号如何获得与现实世界的对应关系。也有研究者(如 Yann LeCun )认为这是当前 LLM 架构的根本局限,需要「世界模型 (world model)」来补充。
[^10]: 我朋友说的"AI 自己设计自己"在 AI 安全领域叫「递归自我改进 (recursive self-improvement)」,也是「技术奇点 (singularity)」假说的核心前提,由 I.J. Good 于 1965 年提出。
[^11]: 勘误:严格来说 LLM 不是随机生成(猴子+打字机),而是基于训练数据学习到的条件概率分布进行预测。猴子每次按键是均匀随机的,而 LLM 的每个 token 输出都受到前文所有 token 的条件约束。正文中的「高级版」已暗示了这一区别。
]]>



有兴趣的同学可以用我的推广链接,便宜 10 块钱 https://www.aliyun.com/benefit/ai/aistar?clubBiz=subTask..12399156..10263..
]]>整理了一份当前的方案清单,每项附了一句简单的评价,看看有没有漏掉的或者踩坑的:
...等等
你当前主力用哪个?最好带上一句原因~
]]>欢迎探讨交流!
]]>估计大部分时候都是用 Auto 吧?
选 Auto 基本是不是就是用 Cursor 自家的 Composer 1.5 了?
如果不用 Auto:
相对于 Auto 来说,有没有使用价值?
还是基本不需要考虑?
目前有:
是不是只用带 Thinking 的版本?
普通版还有存在价值吗?
既然有 Codex 了,
那在 Cursor 里 Sonnet 还有选择价值吗?
还是基本可以放弃?
欢迎有实战经验的朋友分享下实际使用体感 🙏
]]>Agent 场景,主要是 tool using/vibe coding
入围的:
如果还有推荐的也可以写(比如 chatgpt )
由于 prompt 其实和模型是较为绑定的(这个很类似当年针对某个芯片版本写的汇编优化,当芯片/编译器版本换了,方法也就失灵了),所以希望选择一个半年内持续使用的模型。希望了解一下大家目前在 tool using/vibe coding 哪个更方便?
公司生产场景,部署在美东
目前在 openrouter 平台,有什么更好的平台也推荐。
参考:
]]>
OpenAI 的中文语料到底塞了多少垃圾进去……
]]>我之前写过挺多项目,其中一个 iOS 的项目。开始是 OC 写的(约 10 年前看视频自学的 OC )。
后来 Swift 出现,又自学了 Swift ,但是之前用 OC 写的屎山有点改不动了,就索性 OC 和 Swift 一块并存。
差不多得有 2-3 年没维护了,放在 AppStore 面前靠老用户赚回点开发者的费用。
现在有了 AI ,直接让 AI 把 OC 转 Swift ( 24 年初也尝试过,不过业务逻辑有点复杂,当时转完始终无法编译通过)。
看着 Vibe 的过程,真就像看那种旧房改造、物品翻新视频一样~
哈哈哈哈哈,就是有点费钱费 Token
]]>
]]>最近一年我在 Google/Anthropic/OpenAI 三家烧了超过 1 万美金的 token 账单。所以本文内容基于 opus4.6 、codex-5.3-xhigh 、gemini3-pro 等最强模型不限量使用所表现出来的编码能力进行评价。
就好像保健品销售拿着他的《大数据量子 AI 生物磁场治疗仪》,忽悠我说这台原价 20 万、现在活动价 8 万 8 的仪器,可以彻底根治我的颈椎病腰椎病高血压糖尿病,还能逆转我的动脉血管粥样硬化、冠心病、阳痿早泄等等
Agent 编程现在就是这么个状态。
Agent 给我一堆 emoji 庆祝刚才生成的七八万行屎山通过了全部测试用例,告诉我可以替换生产环境了。你信吗?
假设你是一位项目 leader ,你最靠谱的组员同事,交给他的开发任务 80% 可以在预期时间内高质量交付。这位同事拿头给你保证下周就可以上线,那么你大概率能信任他最迟下下周也搞定了。但是 agent 给你保证现在质量和完成度可以上线生产了,你信吗?
此时此刻,无数知识星球、自媒体、AI 导师教父们正在到处收割韭菜的学费。大意基本上都是教你如何 prompt ( tool/skill 换汤不换药),然后让你多开 agent 并行干活。
Agent 的盲目自信不仅会误导使用者,也会误导 agent 自己。
我曾给 agent 这个任务:为当前 Kotlin 项目集成 GCP Transcoding 服务。我给了 agent 该产品的页面和文档作为参考,让它开始 plan 。Agent 做出了如下计划:
你发现这份计划中存在的问题了吗?
事实上,如果你曾经「古法手工编程」做过此类工作,你会发现手动实现 RESTful 远没有想象中那么简单。哪怕仅实现 Transcoding 服务的基础能力,也涉及到 5-10 个 endpoint 调用。每个 endpoint 的输入输出参数又有几十甚至上百个字段嵌套定义,agent 在应对这类长上下文任务时会频繁犯错。
而如果 agent 选择对 Java SDK ( Google 也是从 protobuf 生成出来的)进行简单包装隔离,大概半天到一天就可以让这个功能稳定上线。
若是让 agent 按照 RESTful 文档手动实现,agent 可能会陷入 debug 泥潭——因为当 AI 幻觉导致写错了可选字段的字段名(大小写、驼峰、下划线),程序不会立即报错。你需要多久才能发现它实现错了?等上线生产后客户投诉吗?
为什么我们无法信任 agent ? 经过一年的实践,我认为问题的根源在于:我们缺乏有效的验证手段。
常见观点:某种意义上来说 AI 并没有取代程序员,只不过是一个新的高级工具罢了。你作为生产代码的人,还是得弄明白要干啥,合入的代码就得弄明白。
但我认为,这个在实际项目里很难做到。
像我们之前内部 review 的时候,大部分时候 review 的是 code style ,作者讲一下设计思路,我们也就是大概一听就过了。以前这套方法是有效的:
但是这个相关性在 agent 编码时代不存在,甚至相反。
Agent 一分钟就能生成出来注释齐全、风格优秀的——屎山代码。反正我肉眼看过去的时候,经常会被这第一层假象蒙蔽,放松警惕。主要是这个屎山有点难在 review 阶段发现,经常是上线后出了问题,回头细查的时候才发现是「巧克力味的屎」。
你信我,opus 、codex-xhigh 这些你们舍不得用的模型,我开 thinking+max 模式站起来蹬,一样有这个问题。
更不用说测试了。现在的 test cases 也是 AI vibe 出来的,agent 又当裁判又当运动员,它说什么就是什么。蒙我坑我也不是一次两次了。写了几千行 getter/setter 的 test case ,最后测试全绿告诉我可以上生产环境发布了。
就像前面 GCP Transcoding 的例子,agent 写错了可选字段的字段名,测试照样能过,因为测试也是它自己写的,错的一致就是「对」的。
说到这里,有人可能会问:其他行业被机械、智能赋能后,难道就没有这个问题吗?
让我用 CNC 机床打个比方:
CNC 机床精度比我高,但机床产出工件后,我们可以对工件进行客观的物理测量——用卡尺量一下,公差是不是在 ±0.01mm 以内,一目了然。即便我没有手搓出这个精度的能力,但我依然有评价 CNC 机床和工件质量的能力。
这就是传统制造业被机械赋能后的状态:机器精度高,质量统一且稳定,而人依然能评价机器的产出。
那么软件开发行业被 Agent 变革后,理想状态应该是什么样的? Agent 交付的代码确实覆盖了需求,具备基本的安全防护,且更容易长期维护(哪怕仅考虑 agent 自己维护,不考虑对人类的可读性),性能更高,资源占用更少。
但程序不仅需要完成眼下需求文档中的功能,还需要考虑到基本的安全防护。一个功能完成但安全漏洞百出的项目代码,同样是不合格的。
而目前我们还无法评价 agent 是否达到了这个状态。单就「功能实现」这一基础要求,agent 还不能脱离人的引导和测试验证——更别提安全性、可维护性、性能这些更高阶的指标了。
而且程序不是物理工件,不能用物理手段去测量。你没法拿卡尺量一下这段代码的「质量公差」是多少。
所以没法用衡量物理工件的标准去衡量程序,反而应该像衡量 CNC 机床本身一样——而一次生产( all tests passed )远不能衡量机床质量,更不能衡量程序质量。
CNC 机床加工塑料、铝合金小件精度高,不代表加工钛合金、不锈钢精度也能达标。后者更考验整体刚性,以及工件质量大了以后热胀冷缩对程序进刀补偿的要求。
同理,vibe coding 出来的代码,本地点两下鼠标测试通过了,上线也是极大概率会直接炸掉。
传统行业:机器精度高、质量稳定,人能评价。软件行业:Agent 产出快、覆盖广,但人还没法可靠地评价。这就是问题所在。
既然人工评价( Code Review )和自动测试都靠不住,我们需要另一种评价手段——一种不依赖 agent 自己判断的、客观可验证的评价手段。
我的观点和主流 AI 编码观点相反:
Agent 编程时代,更需要强类型,更需要严格可验证的语言,而不是放任 agent 去写 python/js/go ,还有 anyscript 。
为什么?
AI 堆屎山这么快,别说生成个几万行了,就是生成超过 100 行我都已经懒得逐行去细读了。但是读类型签名、pre/post-condition 明显要快于通读逻辑代码。而这些东西只有 Rust/Scala/Haskell 甚至 formal method 能提供。
我在 agent 编码前就一直用这种风格写自己的代码,主要是代码量大了以后,编译器检查比我肉眼检查更靠谱。现在 agent 编码流行起来了,我发现让 agent 遵循我的这个要求,更能控制产出代码质量——当然也只能说一定程度上,起码比什么都不做好。
回到 GCP Transcoding 的例子:如果 agent 用的是强类型语言,字段名写错了至少还能在编译期被类型系统拦住一部分。但 RESTful + 弱类型的组合,错了就是悄无声息地错,等你发现的时候已经晚了。
y1s1 ,该夸的还是要夸。现在的最新最强模型,过编译问题不大了,除非你比我还执着于类型体操。
放手让 agent 做工程还是拉垮的一批,但过编译已经问题不大了。Pure-FP Scala 、tagless final ,opus 4.5 和 codex-xhigh 遵循得挺不错了,过编译也是自动的。函数式类型体操的编译错误基本上都是几十上百行的类型天书,agent 读懂并修复这些编译错误,在我写这篇文章时已经不再是困难。
当然,这个方案也有局限。
实际上现在的 formal method 工具链和生态还是很贫瘠,基本上只支持一门语言很有限很小的一个子集。有些工程上常用的语法/模式在 FM 那边都是 unsound ,或者尚未证明。更不用说动不动就陷入死循环/无解证明了——稍不注意,z3 求解器要在比宇宙空间还大的可能性里搜索,到宇宙毁灭那一天都证明不出来。
强类型能解决一部分问题,但不是全部。
即使有了强类型作为评价手段,还有一个更深层的问题:agent 对计划的理解和执行。
GCP Transcoding 的例子其实已经暴露了这个问题:agent 选择手动实现 RESTful 而不是包装 Java SDK ,这不是代码写错了,而是路线选错了。编译器能告诉你代码有没有语法错误,但没法告诉你该不该走这条路。
再举个更极端的例子:给 agent 一个复杂任务,研制一款火箭发动机。Plan 决定了做全流量分级燃烧循环,路线选择了共轴方案。
Agent 不遵循的话: 可能就偏离到抽气循环也说不定。编译器能告诉你代码有没有语法错误,但没法告诉你这是不是你要的火箭发动机。
Agent 遵循太好: 真的做出来共轴方案,那可能上线后会碰到更大的问题——共轴以后动密封系统做不好,氧化剂和燃料随着涡轮轴互相泄漏,俩预燃室要炸一个。编译器能保证类型正确,但没法保证设计合理。
现在的 plan/edit mode 切换也只是现阶段的权宜之计、无奈之举。这个问题比「评价手段缺失」更难解决,因为它涉及到对需求和设计的理解,而不仅仅是代码质量。
Agent 编程有一个显著的特点:初见即巅峰。
让 agent 开始一个全新的 CRUD 项目,或者一个 React 管理系统页面,agent 第一次的表现着实让所有人都大吃一惊——干净利落,结构清晰,甚至还贴心地加上了注释和错误处理。
但随着项目维护越来越久,那些「不可明说的」、没有被文档记录的、约定俗成的隐藏上下文越来越长。哪个字段其实已经废弃了但没删、哪个 API 有个历史遗留的 quirk 、哪个模块之间有个微妙的依赖关系——这些东西,老员工心里都有数,但从来没人写下来。
而 agent 无法处理无限长的上下文,只能通过压缩、总结来选择性遗忘细节。可能被丢弃的是几次失败尝试的经验,也可能被丢弃的是关键数据结构的偏移量、寄存器地址、枚举定义。
每次新开一个 session 的时候,开发者不得不面对一个几乎全新的「员工」——它似乎继承了压缩后的上下文( claude.md / agents.md ),但细节完全不知。你得重新跟它解释一遍:「不是,这个接口虽然文档上写的是这样,但实际上我们从来不传这个参数……」
对于 CRUD 、Spring 、React 这类重复度高的任务,这似乎不是什么痛点——反正每次都差不多,忘了就忘了。
但对于嵌入式系统开发,任何被遗忘的细节都可能被 agent 天马行空的幻觉填充。寄存器地址错了?中断优先级配错了? DMA 通道冲突了?轻则系统崩溃,重则永久烧坏硬件。这不是「改个 bug 重新部署」能解决的问题。
既然评价 agent 产出是核心问题,那开发者的基础知识就必然还是要学的。不然你拿什么去评价 agent 生成的代码、模块、架构设计质量到底如何?没有评价能力的开发者,和保健品店里待宰的老头老太没有区别。
那么该如何学习呢?
打开 LeetCode ,题目还没读完呢,Copilot 已经把答案补全出来了。点一下 Submit & Run ,前 1%。就这?
我的意见是:既然有 AI 了,当然不能局限于过去的难度,得上强度,上到 AI 做不出来的程度。
放心,该学的不会落下。上了强度以后 AI 幻觉越来越多,该补的课全都得补上。期间 AI 还会给你帮不少倒忙——但这恰恰是学习的机会。
比如你要实现 Red-Black Tree 、B-Tree 、AVL Tree ,那就上点强度:给算法加上形式化验证,再把泛型支持也加上。放心,当下最强模型也写不出来。
其实幻觉反而会帮助你学习——因为幻觉里包含了常见的误解,你去验证和纠正幻觉的过程,本身就加深了学习效果。
AI 框架、模型、工具、方法论层出不穷,日新月异。但说到底,这些都是在给模型做加法、打补丁。
人类完成一个完整工作流的时候,不需要把自己拆解成多个「子 agent 」去协作——因为人类是真的有记忆能力,且会学习的。做的时间越长,成长越多,越熟练。项目里那些隐藏的上下文、踩过的坑、约定俗成的规矩,都会沉淀成经验。
而 agent 则相反。当前上下文越长,智力下降越明显。即便细节仍然在上下文内,agent 也开始频繁地忽略这些细节,自顾自地幻觉出一些「看起来合理」的东西来。
核心问题始终没变:我们依然缺乏可靠的手段来评价 agent 的产出。强类型是目前我找到的最实用的部分解,但也只是部分解。
一天不学,错过很多。一年不学,好像也没错过什么。
框架工具更新迭代,爆款层出不穷,但其炒作因素远大于实际能力和价值。而 CS 基础知识才是久经时间考验的硬通货。与其追新框架新工具,不如把精力放在强化自己「评价 Agent 产出」的能力上——这才是 agent 时代真正稀缺的东西。
]]>按照 起点-男频-普通用户 5 分钱/千字 的计费标准, 好像也差不多.

是我使用的方式不对么,能说说他们的区别么?
]]>原理就是通过主控 agent 分配任务给子 agent ,你只需要为你的需求好好的写一个 plan 文档,剩下的交给 agent 调度员就行了。
claude code 版本使用了 claude -p 命令行调度而不是 claude code 内置的后台任务功能,是因为 claude code 里边子 agent 上下文隔离没有做好,导致主 agent 上下文膨胀降智。
open code 可以直接使用 oh-my-opencode 插件。
请直接使用 opus 4.5 等聪明模型(很值得),一天花个几十刀完全没有问题。
]]>首先定义好技术栈、目录结构让 ai 把基础的框架搭出来,然后对结构代码审查。
我是那种不相信 ai 能给项目一把梭了,基本上 ai 每写完一部份的代码我审计完就要提交一个 commit ,如果下一个阶段的代码他写的我不满意我可以直接回滚让他重写。
每当完成一个新功能我就 commit 代码,然后创建一个新的会话让他写下一个功能,这样有干净的上下文。每次需求只提一个,这样虽然效率会低点,但是能做到心中有数。
我认为当下程序员虽然不用写代码了,但是要了解的东西还是一点少不了,比如当下最常用的框架,为了数据量提前设计数据库,使用什么技术栈等等,如果只是一个普通人想要一句话项目还是不太行,写一些小玩意还可以。
最后分享一下 vibe coding 的 CDN 项目 Goteway ,完善后将会开源,这个项目从 0 到可用只花了 2 天时间

最近在实际项目中开始频繁使用「 Vibe Coding 」(借助 AI 的沉浸式/对话式编程方式),明显感觉到:
不同人用下来,效果差异非常大。
所以想开个贴,系统性地收集一些大家在 Vibe Coding 过程中的使用技巧、踩坑经验和最佳实践,供彼此参考。
[想重点收集的方向(不限于以下)]
1️⃣ 使用场景
2️⃣ 提示词与交互方式
3️⃣ 与真实项目结合
4️⃣ 效率与质量的平衡
5️⃣ 工具与模型选择
6️⃣ 心态与方法论
[我个人的期待]
不是那种“神化 AI”或“完全否定”的讨论,而是:
欢迎随意分享,哪怕只是一条小技巧 🙌 后面我也会把有价值的内容整理成一份总结。
如果你已经在用 Vibe Coding ,**你最想提醒新手的一句话
]]>因为有些项目比较大,不同的模块在风格上不太一致,或者说部分写法抽象层比较多,ai 有时候写了具体代码实现,但是忘记注册服务等等。因此需要给每个模块的一些具体迭代行为做一个约束:比如 a 模块的表单加一个字段需要注意哪些事项。b 模块新增、修改一个规则服务的逻辑需要注意哪些事项。
但是现在感觉可选的实现方式非常多,不知道怎么选。
方案一:全部用 skills 维护这些事项,让 agent 动态加载
方案二:在 agent.md 里写,迭代 a 模块,需要读 a.md ,a.md 再索引 a 模块常见迭代的操作
主要是想了解一下大家的方案是啥,交流一下
]]>There was an unexpected issue setting up your account. Please try again later.
]]>昨晚折腾 alist 三小时 有太多 bug 比如莫名其妙 r2 挂的不显示,onedrive 官 token 根本无效
这项目基本就死了 我还特喵的除虫打算发 pr
后面才刚知道闭源了
转移 openlist 之后一切正常神清气爽
我希望最开始 llm 就应该使用时效分析 skill 告诉我这货年久失修了 比较大的分支是 openlist………
特此记忆 有时间完成这个必选 skill
延伸:另一个 skill 是用户做任何项目的时候都要全网搜索有没有现成的轮子 以及踩过的坑
这些都是 llm 应该主动去做的
包括这个 skill 我认为现在已经有轮子 只是我很难找到分值最大的
]]>发现很多有名的项目都是前后端放一起的,想问问大家都是怎么做的。
]]>
提示缺少$HOME 环境变量
解决方法:打开 PowerShell 并执行
[System.Environment]::SetEnvironmentVariable('HOME', "$env:USERPROFILE", 'User') 执行完成后重启 Antigravity
如果还是不行就在设置里手动指定 Chrome 的路径后重启

我还不太想关掉 SmartAppControl ,关掉之后如果再想开启,必须重置电脑了
有什么办法绕过吗?
]]>