sillydaddy

@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://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 又绕圈子解决不了，就需要一个引路人把他们从迷宫带出去。