@NewYear #4 丰俭由己。我上次只吃了 15 块，荤+素+饭+咸菜。
@zoeliu 主打一个实惠+创新，天天人爆满。我也怀念羊肉串，还有之前的自助水果。

@zhmouV2 称重确实便宜，适合经济下行时期，以及饭量普遍变小的时代。
写错了，是“馄饨”。之前就是三样儿：米饭、羊肉串、馄饨。后来搞起了小火锅，单人吃的那种小火锅。现在搞起了称重。“南城香”也写错了。

@huaweii 可以注意到同一个字是有细微变化的。比如倒数第 4 行「 x 」的大小，最后一行的第 1 个「 0 」和第 2 个「 0 」，倒数第 2 行和倒数第 3 行的「米」字。

不过这模拟的也太逼真了，反面的透字是 AI 模拟的吗？「厘米」这 2 个字好像没有翻转。

这个机制就是为了防止直接注册后就推广的吧。

AI 的品味是需要，而且也在不断提高的。今天我刚好有一个例子。

我有一个 VectorBuilder<T>的组件，这个组件是纯函数的，它接受 N 个 T 类型的输入，给出一个 vector<T>类型的输出。

问题来了，在代码中，可以用 VectorBuilder<number>这样方式简单定义，但实际业务中，需要由用户在 UI 界面上选择这个 T 类型。在 UI 界面中，怎么决定某个组件是不是有可以配置的选项呢？这些选项又怎么呈现在 UI 界面上，供用户选择呢？

AI 给出了它的通用解决方案（这个通用的方案，还是在我一再要求下给的，之前它给的就是针对这个组件写死的方案），它的方案就是在 VectorBuilder<T>这个类型的定义里面，添加一个配置项 genericConfig ，再添加一个 applyGenericConfig()函数。
```
getGenericConfig?(): Record<string, {
label: string; // 菜单显示名
type: 'select' | 'number'; // 控件类型
value: any; // 当前值
options?: any[]; // select 的可选值
min?: number; // number 的最小值
max?: number; // number 的最大值
}> | null;

applyGenericConfig?(config: Record<string, any>): BaseComponent;
```

然后被我一通批判：
```
我觉得，最好不要将这些接口，比如 applyGenericConfig ，放到组件的定义里面！我来说明一下理由，这些接口，本质上仅仅是替换一下类型，与组件本身的功能几乎没有关系，比如 VectorBuilder 这个组件，将 number 替换为 string 类型，不应该由 VectorBuilder 来考虑实现类型替换这件事。可选的类型或者可以选择的配置，也不应该是 VectorBuilder 这个组件本身需要关心的事，因为 VectorBuilder 就是一个包含泛型的类！

所以，我完全不能接受将这些东西放到组件定义里面！！

当然，你的这个通过配置来实现通用化的方法，还是比较好的，但是能不能拿到组件定义的外面呢？而且，最好也不要写一个统一管理的函数，在里面用 if else 来分别判断！
```

@nenseso #6 一样的，也是一个点一个点推进。局部的可以不用理解，只要测试通过就行，全局的（比如大的架构、设计），自己必须清楚。

上次做自己的项目（ /t/113381 ），我给了 AI 一个长长的提示词，让它一键做一个复杂的界面切换（组件编辑器，切换到复合组件编辑器），看起来只是一个界面切换，但涉及到了功能的复用（编辑过程类似、画布也要复用）、状态的切换（ 2 个编辑器里面的数据内容需要切换）、数据的交换（需要从组件编辑中选取一些东西传递到复合组件编辑中）等等，结果它改好多次，总是顾此失彼。

最后只好自己定义好复用的框架、拆分大文件为小文件、添加打印信息，总之就是让自己能在 AI 的编码过程中，自己能理解每一步。最后重构完成了，自己也掉了一层皮。深刻的教训。

所以我觉得还是自己把握住度：局部的可以不用理解，只要测试通过就行，全局的或复杂的（比如大的架构、设计），自己必须清楚。

兼职是远程的吗，工作是在哪些时间段呢？

看代码比写代码的时间还长？我是不信的。除非水平写的很差，低内聚高耦合那种，但目前的 AI 明显没有这么差。
多次的话，不能让它反复覆写以前的代码，那样相当于每次都要重新看。这确实需要一些技巧，一个技巧就是自己还是要统领全局，提前想清楚思路，或者逐步推进，不能指望一口吃个胖子。

讲讲程序员的工作是什么。

前 20 分钟，可以从计算机是怎么工作的，开始讲起。中间可以夹杂着孩子们玩肉体门电路的游戏（刘慈欣小说中的举旗）。下面讲述门电路的视频只有 18 分钟，有现成的软件可以下载使用。
https://www.youtube.com/watch?v=QZwneRb-zqA

门电路还可以参考《编码的奥秘》（第一版），使用继电器来模拟，可以在淘宝上买一些自己组装。
https://book.douban.com/subject/1024570/

后 20 分钟，可以讲程序员做的工作是如何把人与计算机连接起来的。
/t/749227

可以用一个有意思的搬箱子机器人游戏作为切入点。
https://i4ds.github.io/CargoBot

前后的 2 个 20 分钟，都是以游戏作为出发点，激发孩子的兴趣，同时让它们了解一些关于软件编程职业的特征信息。

key point -> “传统聊天方式发送的指令会被自动同步进 Design Doc 。当然你也可以直接修改 Design Doc ，在修改后 LLM 可以根据改动部分的 diff 去实现改动。”

想法非常赞！尤其是这个 diff 的想法，妙。这样的话，就从迭代代码，变成了迭代设计图纸了。

有道理哎，OP 有商业头脑。
关于第 3 点，产品经理他们通过 AI 开发遇到了难题，AI 又绕圈子解决不了，就需要一个引路人把他们从迷宫带出去。

你给的这图啥也看不出来啊，那些密密麻麻的黑黢黢的点、蓝色的线，都是啥？

似乎是不支持国内的。我通过 PayPal 购买 v 站的会员，也会提示需要关联银行卡。但同样的 PayPal 账号买 github copilot 就可以。

方案 A 没看懂：「不需要平台判断谁对谁错」，然后「任何一方违约 → 押金罚没给对方」。

怎么判断违约？货不对板怎么办？「卖家寄出商品后上传物流凭证」这个也需要判断是不是真的凭证吧，假如上传一个假的，买家拒收就要没收买家的押金吗？

我觉得，去中心化的交易，涉及到主观判断（不同人有不同判断）的，或者涉及到信息不对称（如电商交易，只有交易双方知道完整的信息，外人都不知道）的，需要特殊处理。因为去中心化本身不能做价值评判，也不能掌握没有暴露出来的信息。所以去中心化无法就这些问题达成共识，也没有必要达成共识。

我觉得合适的解决方案，是引入一个双方都认同的仲裁者，比如方案 B 就是。另外，现在有了 AI ，AI 可以充当这个仲裁者了。假如双方经过双盲测试，都认同了某个 AI ，可以把这个 AI 存档，发生纠纷时，把证据提交给这个 AI 。这个 AI 是否被篡改可以经过对权重参数的哈希和双方的签名确认。

方案 C 仍然没有解决刷评论的问题。声誉系统需要结合信任网络来执行，每个人都有自己的信任网络（而不是大家共享同一个信任网络，即声誉系统），这样可以把那些刷分的屏蔽掉，因为它们不在自己的信任网络中。

最大的 bug 是，第一步棋，我走当头炮，它不把马跳，然后送我一个白白的空头大炮。
AI 的棋力明显不行，最多思考一步棋。

@TabGre #18 我发的完整链接是 3blue1brown 的一个播放列表（关于机器学习的），不止包含上面那个视频，可惜链接被自动截断了，可以在 3blue1brown 频道的播放列表里面找到这个列表，包含了 7 ，8 个神经网络的视频，非常通俗易懂。

感谢 OP 提供了一个实际的例子，我刚好在实践“如何保存数据跨越 50 年”： /t/1173178