sillydaddy

@udisyue 不需要懂开发啊。我在主题里发的那两个工具，都是以用户的角度要求修改的，完全没有看过代码。
看着哪里不合适就告诉 AI 自己的想法。比如 v2tracker 里面，关注的帖子要展示最新的回复，如果新回复超过了 3 条就折叠起来。比如标题比较长的，之前是自动换行，让 AI 换成了单行并用省略号折叠。还有很多类似的，用户看到了实际产品的样子，甚至实际用起来，才能给出反馈。

@adgfr32 #7 浏览器插件方便些。第一时间没想到 API 。

@Skifary #11
我仔细想了下，你提到“把需求描述清楚并逻辑自洽”，其实是在 AI 出现之前的时代，前 AI 时代，用户没办法看到效果，没法操作的，所以，它不能像瀑布流开发中的需求分析一样，一下子把所有的需求系统地描述出来。所以，前 AI 时代，会有敏捷开发，讲究快速接触客户获取反馈，快速调整。也有借助原型的概念。
到 AI 时代，一个软件可以从用户的一个非常模糊的需求开始，然后用户看到反馈，才给出进一步调整的指示。这也符合软件迭代的模式。需求是逐渐细化的，需求与开发与测试，是纠缠在一起的。这是一个逐渐将限制精确化的过程，也是补足信息的过程。这个过程如果在前 AI 时代，需要很多次的沟通，成本很高。特别是用户突然改变想法的情况下。

@Tose 感谢夸奖。其实设计方面，我只介入了很少的一点，就是让它尽量紧凑排布，然后让它用 solarized light 主题配色。

真如你所说，真就一个「土鸡瓦狗」「鸡零狗碎」，门外的看都看不懂。。。。

@purringpal
@darksword21
想来点劲爆的？可以考虑成本的边际效应，如何影响软件行业的生态。
比较下面 2 种方式：
1 种是用户将自己的需求表达出来，然后由 AI 直接处理（或者生成对应的软件来处理）。
2 是用户在市面上搜索对应的软件，或者找到对应的供应商然后将软件需求表达出来，由供应商制作。
上述的哪个成本更低？用户会如何选择？如果说

@Test22 #12 我指的是断点 debug 那种，可以获取精确的状态信息。除非大模型能肉眼看出 bug 所在（现在显然还不太能做到），否则还是需要 debug 的吧？当然也可以不用打断点，而是通过打印日志。。。。


@cincout
@kapr1k0rn #4 #5 原帖文意思是，当 AI 能像人类一样（持续）编码，就不需要**人类** review 代码了！即使输出的代码有不确定性，有 bug ，那也是 AI 自己修 bug 的事了。从自主性来说，给定了输入（需求），就无需人工介入了，人类需要检视的是给定的需求是否恰当，就像编译器的作者只需要检视编译器的规则一样。

其实我最好奇的是，为什么现在还没有 AI 能自主 debug ？

如果这不叫浪费而是叫促进经济，那天下就没有道理可讲了。