这个思路很好。不过看了下，似乎透露的信息太少，不登录完全不知道内容是什么，至少把可视化的内容透露出来一些吧。

答案就在 OP 的头像里 :doge

同问。我也感觉现在自动化测试是 vibe coding 的核心关键，而限制自动化测试的就是成本。

我感觉只能等 token 价格下降了。刚试了这个帖子（ /t/1192001 ）的图片，125KB 左右的一个 jpeg 文件，问里面有几个小人儿，花费了 1 万多的输入 token （这里不排除有系统提示词之类的，但大体是 1 万 token ），说明截图还是很费 token 的，Sonnet4.5 的话大概两三毛钱。

有没有可能优化一下测试流程，尽量直接一步到位加载目标网页的数据，而不是逐步点击，也就是把测试也模块化，当然我没有做过测试，只是瞎猜。但 token 贵的话，只能人工优化测试流程了。

更大的可能是你被版主拉黑了： /t/1192367

@94 付诸行动吗，有些难点：1 是我觉得它是水到渠成的事，到未来真假难辨时，其他商业实体自然会去做，我的主要兴趣也不在那里。2 是那个帖子本意是看个人有哪些**低成本**的相关机会，讨论下来感觉都是硬件、厂商这些基础设施的事，没有太多外溢给个人的机会。

@94 没有任何削弱，反而加强了——事实是空气，无论对人类还是对 AI 。因为它们最终都要活在现实世界中，如《黑客帝国》这部电影讲述的，有几个愿意活在 matrix 的世界里面呢？

自建节点有屏蔽功能，你是不是被屏蔽了： /t/1187999

你说的有 2 个层次：

1 是人类还需不需要从前端来获取信息。肯定需要啊，又没有进化成直接读取 token 和 html 代码。
2 是前端还需不需要人来参与创建。这个视情况吧：
2a. AI 实时的动态创建，你给 AI 一个请求，AI 把数据动态拼装起来，再动态生成前端页面展示给你。
2b. AI 动态拼装太复杂太慢，或者不精确，那么就由用户指令 AI 「培育」一个符合用户喜好的 UI 界面。当然这种培育出来的 UI 都在本地了，也不需要产品开发者去发布了。
2c. UI 比较具有普适性（每个人用法差不多），或者较为复杂，没有必要每个人用 AI 自己开发一套，费时费钱，那一套打磨好的通用 UI 可能会比较节省成本。每个用户的 AI 可以自己拿过来接手定制，甚至有不同 UI 的竞争。到时候一套 UI 的开发者就会利用这个 UI 的定制授权来盈利。

我是在 cursor 里面试的。感觉上面的成绩，跟 ARC-AGI 这个图形推理的测试成绩高度相关：

https://arcprize.org/leaderboard

有意思，试了几个模型：
Opus 4.5 thinking ，对了 0 个。

Opus 4.6 thinking ，对了 2 个（ Bob 和 Adam ）。

GPT 5.2 codex extra high thinking ，对了 3 个（ Bob, Adm 和 Tommy ）。

GPT 5.3 codex extra high thinking ，对了 5 个：
Bob：从 Bob 右侧线头出发，沿线向右后下弯，终点箭头指向中间黄绿色小人。
Jack：从 Jack 下方线头出发，走上方并行线中下方那条，终点箭头指向右上浅橙（偏米黄）小人。
Jimmy：从 Jimmy 下方线头出发，走上方并行线中上方那条长线，再沿右侧外圈下绕，终点箭头指向右中深蓝小人。
Tom：从 Tom 下方竖线出发，向下再左弯，终点箭头指向左下黄色小人。
Adam：从 Adam 左侧长线出发，沿底部向左再沿左侧上行，终点箭头指向左上粉红/玫红小人。


GPT codex 是用的编程工具处理的，尝试用 opencv 失败，后来用的 ffmpeg 。我还特意把线加粗了，不行的还是不行。
在 GPT 5.2 尝试过程中，里面冒出了这样一句： “我在校准裁剪参数，马上拿到上半部分的放大细节来确认 Jack/Jimmy 这两条最容易混淆的线”

不记得是谁说的了，要做那些「基础模型越强大，你越高兴」的东西或事情。他举的一个例子就是 Agent ，Agent 里面的基础模型越强大，就促使越多人用 Agent 。反过来就是说，不要做那些「基础模型越强大，你越难受」的工作，比如在一个狭窄的领域里面搞 CRUD 编程，而这在今天已经应验了。

但，他这话有些鸡贼——什么是基础模型越强大我越高兴的工作呢？他并没有说清楚。

其实仔细想想，它等于是在说「要做那些基础模型做不了的事情」，就是这么个意思，对吧？越是基础模型做不了的事，随着基础模型的越来越强大，基础模型对你能力的放大就越显著。比如你善于商业，那基础模型就相当于百十个任劳任怨的员工。

问题在于，什么是基础模型做不了的事呢？怎么就知道基础模型后面做不了呢？举例来说，编程里面的架构，现在基础模型（配合 Agent ）还不太行，这也是 v 站大多数人的看法，比人类的架构品味还要差不少，那是不是说，现在学架构就安全了呢？很明显学架构并不能让人安心，因为你不知道 AI 什么时候能以多快的速度学会架构。而且每个人擅长的不一样，不一定都适合。

AI 的发展就像海水涨潮，而人类则是在陆地。涨潮时，浪潮在不断冲刷新的高度，我们人类是在不断的后退，后退到 AI 够不着的高地。只要它够不着我们，我们甚至可以充分利用浪潮的能量。然而，假如涨潮最终会淹没我们所在的整个岛屿，那么后退到不同的高地，其实只是在被淹没的时间上有所区别。

现在的 AI ，用它带来的巨大震撼，揭示了一个道理给我们人类：智能没有什么特殊的，AGI 迟早会实现。认识到这一点并不代表一定要悲观，因为后续殊难预料。

在这一前提下，「在 AI 浪潮下该做什么」这个问题，就变成了在 AI 浪潮面前，各个「不同的高地」，它们被淹没的时间先后顺序是什么？直觉、抽象、架构、深入思考、目标、品味、审美、创新，甚至情绪、同理心，所有这些人类具有的智能属性，到底分别在什么时候会被 AI 赶上？这决定了退到哪个高地更合适。

我也不知道该退守到哪里。但我愿意分享一下我的想法。

之前举了编程的例子，毫无疑问，普通的 CRUD 已经被 AI 替代了。再来看编程架构，现在很多人都在说 AI Agent 的品味还不信、架构还不行、执行丢三落四，就目前这确实是事实。但这些高地会是下一批被淹没的吗？我觉得是。不要说不可能，毕竟谁也不会料想到，编程这个会吓退普通人的职业，竟然是被 AI 第一批占领的高地。而我之所以比较肯定，是因为软件行业的基本特点就是能以很低的成本进行验证。架构、品味这些东西，虽然比功能更难量化，但也不算非常难。代码简洁、低耦合高内聚，这些准则，并非难以描述，难以比较。即使是现在，给到 AI 两个架构方案，它们也能轻易判断出优劣。最关键的是，它们是可以低成本验证的东西，架构、品味，总是要以具体的代码实现来体现出来的，只要有具体的实现，AI 就可以测试它们、比较它们，甚至可以迭代式的改进它们，这时低验证成本这个关键就体现出来了。所以我个人觉得架构师也是一个会很快失守的高地，届时软件工程行业将无险可守。

再举一个例子，比如科普，你让人类讲清楚一个东西的原理，人类会根据他自己的学习思路，路途中遇到的困难，清楚的知道该把哪些困难点讲清楚，因为他学习过、经历过，他知道怎么讲怎么打比方才能让小白理解，他知道人类的心理构造。最明显的就是那些好书、好视频、好电影，让人茅塞顿开豁然开朗（比如《编码》这本书）。但 AI 没有这个经历，它不知道人类的心理构造。你只能追问它。什么时候 AI 可以充分建模人类的心理模型呢？比较难说，我觉得应该会比较晚吧，毕竟如果 AI 能建模人类心理，就意味着它也可以在其他行业发挥作用。

其他例子就不说了，预测未来的东西，很难靠的住。但是否可以低成本验证，可以作为一个重要的标准。以这个标准来说，开发人员是时候早做准备了。我写这么一大通，也是想表达这点。

楼主你说的方向是啥呢？

感谢 OP 分享。

楼上的都在扯啥呢？尤其#1 楼，把人家「自曝其短」的东西照搬过来： https://www.anthropic.com/engineering/building-c-compiler#:~:text=not%20without%20limitations.-,These%20include,-%3A

只看到了那些缺点，这是个极简的脚手架你怎么不说呢？那 Agents 不能联网怎么不说呢？人类几乎没有介入怎么不说呢？ Opus4.6 相比 Opus4.0 甚至 Opus4.5 的跨越怎么不说呢？

重点中的重点是 16 个 Agent （ Agent 团队）的协作，实现长时间大规模的无介入协作编程，不是吗？即使把这篇文章给到 AI ，也不至于抓不到重点吧。

我最近恰好遇到了类似问题，来分享一下：

最近不是 AI 编程嘛，我开了多个任务（大概 4 ，5 个吧），想着在某个任务等待 AI 的间隙，切换到其他任务，提高效率。结果是，那些遇到稍微难啃骨头的任务（比如思考下一步的规划），在并行过程中，被我无情抛弃了，只走那些进展顺利的任务，最终只有 1 ，2 个任务在跑，其他都是做一半。而且精力分散，导致每个任务都不能深入思考。那些只做一半的任务，后续还要重新拾起来，还要面临再拾起时自信心受挫，摩擦阻力大的问题（因为知道当初遇到了难点）。

问题关键就在于大脑注意力的专注，可以产生复利效应（或者叫边际成本递减，无论怎么称呼它），意思就是越做越快，越来越熟悉，遇到难题也能披荆斩棘的感觉，这提高了专注的价值。而且专注可以快速出成果获取反馈。

当然，这种情况也有例外，比如你苦思冥想一个问题，就是解决不了，也许此时换个任务是一个更好的办法，回过头来之前的问题可能会突然迎刃而解。

每个人都不一样，所以，我感觉你现在的做法就很好啊。没必要强求，找到适合自己的方法就行。

很有意思的想法。目前看来就是你说的 2 个方案：
1 是借助冷冰冰的物理和算法，像 vdf 这种本地挑战难题，甚至无法用硬件加速。它只需要你在电脑上一直跑解密程序，跑个几年。
2 是借助外界(如区块链)监督，如各种智能合约。

哪种更让人安心，因人而异。但合约明显更方便吧。

@JoeJoeJoe 可以最小化发布吗？ 6 个月太久了。给你个提示词（哈哈）：只给你 1 个月，逼自己一下，哪些模块可以不用一下子放进来，哪些可以先用中心化的逻辑。

你这精力，比我还分散，哈哈，不过执行力比我强多了。
这个领空投的 v2ex.info 网站不错，还可以发布 v 币任务。
建议就是集中注意力快速把第一个弄出来 /doge ，好奇问下需要什么前置工具啊？

你说的这些都不是问题。

AI 编程，最关键的区别，就在于它是可以低成本验证的。

你提到的测试失效的问题，只要稍微想一下，它跟什么机床测量没有任何区别。软件最终是要验收结果的，它不考虑内部实现，就跟机床的验收一模一样！没有任何区别。

想通了这点，你后面就这点的讨论就都不成立了。你说 AI 会自己编写 case ，放过自己编写的 bug ，难道你使用 2 个不同的 AI 去做，也会这样吗？
我现在做一个项目（带有前后端），让 AI 去生成测试用例，它生成的测试用例很丰富，很详细。问题主要出在，它编码完成时，会「由于时间原因」跳过某些测试用例。（这是 AI 亲口告诉我的，由于时间原因，我想可能是迫于某些原因。）

所以跳过测试是一个问题吗？我觉得不是。你如果让某个 Agent 实例，专门只测试 1 个测试用例，那应该完全不会有这个问题。有了测试用例，就不用担心 AI 的实现跑飞。

然后有人会质疑，这些测试用例不会覆盖到所有情况。这里我觉得要拿你的矛来攻你的盾——「如果一个工程代码，能将应用的核心用例和路径跑通，同时跑通一些极端用例，那么它出错的概率是比较小的，这就是功能的相关性。就像如果一个 AI 可以编写出最复杂的算法，就难以想象它无法编写简单的排序算法一样的道理。」

谎报军情